CA2254813A1 - Distribution of reachability information in data virtual private networks - Google Patents
Distribution of reachability information in data virtual private networks Download PDFInfo
- Publication number
- CA2254813A1 CA2254813A1 CA002254813A CA2254813A CA2254813A1 CA 2254813 A1 CA2254813 A1 CA 2254813A1 CA 002254813 A CA002254813 A CA 002254813A CA 2254813 A CA2254813 A CA 2254813A CA 2254813 A1 CA2254813 A1 CA 2254813A1
- Authority
- CA
- Canada
- Prior art keywords
- vpn
- node
- reachability information
- received
- route reflector
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Abandoned
Links
- 238000000034 method Methods 0.000 claims abstract description 62
- 230000008569 process Effects 0.000 description 16
- 238000010586 diagram Methods 0.000 description 8
- 238000001914 filtration Methods 0.000 description 7
- 238000012217 deletion Methods 0.000 description 2
- 230000037430 deletion Effects 0.000 description 2
- 238000012986 modification Methods 0.000 description 2
- 230000004048 modification Effects 0.000 description 2
- 241000380800 Nordus Species 0.000 description 1
- 238000013459 approach Methods 0.000 description 1
- 230000005540 biological transmission Effects 0.000 description 1
- 230000008859 change Effects 0.000 description 1
- 238000013461 design Methods 0.000 description 1
- 230000000694 effects Effects 0.000 description 1
- 238000005516 engineering process Methods 0.000 description 1
- 238000011835 investigation Methods 0.000 description 1
- 230000008450 motivation Effects 0.000 description 1
- 238000012545 processing Methods 0.000 description 1
- 230000000644 propagated effect Effects 0.000 description 1
- 230000009467 reduction Effects 0.000 description 1
- 239000012925 reference material Substances 0.000 description 1
- 230000011664 signaling Effects 0.000 description 1
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/02—Network architectures or network communication protocols for network security for separating internal from external traffic, e.g. firewalls
- H04L63/0272—Virtual private networks
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
- H04L12/46—Interconnection of networks
- H04L12/4641—Virtual LANs, VLANs, e.g. virtual private networks [VPN]
- H04L12/4675—Dynamic sharing of VLAN information amongst network nodes
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L45/00—Routing or path finding of packets in data switching networks
- H04L45/02—Topology update or discovery
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L45/00—Routing or path finding of packets in data switching networks
- H04L45/02—Topology update or discovery
- H04L45/025—Updating only a limited number of routers, e.g. fish-eye update
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L45/00—Routing or path finding of packets in data switching networks
- H04L45/02—Topology update or discovery
- H04L45/033—Topology update or discovery by updating distance vector protocols
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L45/00—Routing or path finding of packets in data switching networks
- H04L45/02—Topology update or discovery
- H04L45/04—Interdomain routing, e.g. hierarchical routing
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L45/00—Routing or path finding of packets in data switching networks
- H04L45/50—Routing or path finding of packets in data switching networks using label swapping, e.g. multi-protocol label switch [MPLS]
- H04L45/502—Frame based
Abstract
In methods and apparatus for acquiring VPN
reachability information at a node of a data network, a VPN reachability information request is transmitted from a requesting node. The VPN reachability information request comprises a VPN identifier. Other nodes of the data network receive the VPN reachability information request and, if they have reachability information relevant to that VPN, they transmit such information to the requesting node where it is received and stored. The invention can be used in MPLS VPN architectures.
reachability information at a node of a data network, a VPN reachability information request is transmitted from a requesting node. The VPN reachability information request comprises a VPN identifier. Other nodes of the data network receive the VPN reachability information request and, if they have reachability information relevant to that VPN, they transmit such information to the requesting node where it is received and stored. The invention can be used in MPLS VPN architectures.
Description
DISTRIBUTION OF REACHABILITY INFORMATION IN DATA VIRTUAL
PRIVATE NETWORKS
Field of the Invention This invention relates to distribution of reachability information in data Virtual Private Networks (VPNs) .
to Background of the Invention A typical Internet network implementation comprises a Service Provider Network (SPN) connected to a plurality of customer data facilities, commonly referred to as Customer Premises Equipment (CPE). The SPN is operated by an Internet Service Provider (ISP), and comprises a network of interconnected routers including a plurality of Provider Edge (PE) nodes. Each PE node is connected to one or more instances of CPE by access links.
The PE nodes are connected within the SPN directly, via other nodes and via route reflectors. Each CPE may comprise a computer or network of computers operated by a customer, the computers being interconnected, for example, by a Local Area Network (LAN).
The Internet Engineering Task Force (IETF) is an industry consortium which seeks to define standards for implementation of Internet networks. Participants submit Internet Drafts to the IETF for discussion in working groups. Some proposals contained in Internet Drafts may eventually be adopted as standards by the IETF. Copies of 3o Internet Drafts are available at Internet address ftp://frp.ietf.org/internet-drafts.
Recent IETF drafts make proposals concerning the implementation of Virtual Private Networks (VPNs) in SPNs using Multi-Protocol Label Switching (MPLS). Such drafts include:
{1} J. Heinanen et al, "VPN Support with MPLS", <draft-heinanen-mpls-vpn-0l.txt>, March 1998.
PRIVATE NETWORKS
Field of the Invention This invention relates to distribution of reachability information in data Virtual Private Networks (VPNs) .
to Background of the Invention A typical Internet network implementation comprises a Service Provider Network (SPN) connected to a plurality of customer data facilities, commonly referred to as Customer Premises Equipment (CPE). The SPN is operated by an Internet Service Provider (ISP), and comprises a network of interconnected routers including a plurality of Provider Edge (PE) nodes. Each PE node is connected to one or more instances of CPE by access links.
The PE nodes are connected within the SPN directly, via other nodes and via route reflectors. Each CPE may comprise a computer or network of computers operated by a customer, the computers being interconnected, for example, by a Local Area Network (LAN).
The Internet Engineering Task Force (IETF) is an industry consortium which seeks to define standards for implementation of Internet networks. Participants submit Internet Drafts to the IETF for discussion in working groups. Some proposals contained in Internet Drafts may eventually be adopted as standards by the IETF. Copies of 3o Internet Drafts are available at Internet address ftp://frp.ietf.org/internet-drafts.
Recent IETF drafts make proposals concerning the implementation of Virtual Private Networks (VPNs) in SPNs using Multi-Protocol Label Switching (MPLS). Such drafts include:
{1} J. Heinanen et al, "VPN Support with MPLS", <draft-heinanen-mpls-vpn-0l.txt>, March 1998.
- 2 -{2} D. Jamieson et al, "MPLS VPN Architecture", <draft-jamieson-mpls-vpn-OO.txt>, August 1998.
{3} T. Li, "CPE Based VPNs using MPLS", <draft-li-mpls-vpn-OO.txt>, October 1998.
{4} E. Rosen et al, "BGP/MPLS VPNs", <draft-rosen-vpn-mpls-OO.txt>, November 1998.
To implement VPNs on SPNs using MPLS, {3}
proposes that a CPE will transmit a Border Gateway Protocol (BGP) message to the SPN to indicate its presence in the network and to indicate the set of VPNs in which the CPE wants to participate. The BGP message includes "VPN reachability information", including the CPE's address in the ISP's address space and a VPN identifier.
The BGP message is received by the PE node which is connected to the CPE. The PE node can filter or otherwise examine the message to ensure that it complies with the ISP's policies. If the message does comply with the ISP's policies, the message is propagated to other PE
nodes of the SPN according to the specifications of BGP
(see IETF document RFC 1771).
The other PE nodes of the SPN store the VPN
reachability information and forward the BGP message to any of their connected CPE that are participating in the same VPN. The CPE receiving the BGP message can then use MPLS signalling protocol to set up a MPLS tunnel to the CPE which has just joined the VPN. The PE nodes use the stored VPN reachability information to establish the MPLS
tunnels.
The method described in {3} requires very little or no intervention by an ISP when a new CPE is added to a VPN. However, in a large SPN which supports a large number of VPN subscribers, each PE node of the SPN would be required to store a very large amount of VPN
reachability information. Moreover, only a small percentage of the stored VPN reachability information may actually be needed by any particular PE node.
For example, in an SPN having 2000 PE nodes and 1000 VPN interfaces per PE node with an average of 10 sites per VPN, 2 million VPN reachability information records would be distributed to each PE node. Assuming conservatively that each VPN reachability information record requires 30 bytes of storage, the VPN reachability information would require 60 Mbytes of storage at each PE
node. However, according to the above assumptions, only 10,000 of the stored VPN reachability information records 1o would actually be used by a typical PE node to establish VPN tunnels. The remaining 1.99 million of the 2 million reachability information records, stored at a typical PE
node, i.e. 99.50 of the stored records, would not be used.
{4} proposes that PE nodes transmitting BGP
messages apply outbound filtering so as not to propagate VPN reachability information to other PE nodes which are not participating in the VPN identified in the BGP
message. Alternatively, {4} proposes that PE nodes receiving BGP messages apply inbound filtering so as not to store VPN reachability information for VPNs in which they are not participating. These filtering approaches may address the storage inefficiencies noted above.
However, should CPE requiring access to a particular VPN
be connected to a PE node not previously participating in that VPN, such filtering would result in the PE node lacking VPN reachability information for that VPN. The required VPN reachability information would need to be provided to the PE node, either by operator provisioning or by dropping and re-establishing the connection between the PE node and other PE nodes of the SPN so that all other PE nodes of the SPN automatically transmit all of their accumulated VPN reachability information to the PE
node. The former method for acquiring the required VPN
reachability information is time-consuming, error-prone and expensive. In a large network, the latter method for acquiring the required VPN reachability information would take too long and have too great an impact on SPN
performance to be acceptable.
Summary of the Invention The invention seeks to reduce or eliminate the above problems by enabling a particular PE node to solicit specified VPN reachability information from other PE nodes when such information is needed at the particular PE node.
One aspect of the invention provides a method for to distributing VPN reachability information in a data network. The method comprises transmitting a VPN
reachability information request from a requesting node of the data network to another node of the data network, the VPN reachability information request comprising a VPN
identifier. The method further comprises receiving the VPN reachability information request at another node of the data network; retrieving VPN reachability information associated with the VPN identifier at the other node;
transmitting the retrieved VPN reachability information 2o from the other node to the requesting node; and receiving the transmitted VPN reachability information at the requesting node.
Another aspect of the invention provides a method for acquiring VPN reachability information at a node of a data network. The method comprises transmitting a VPN
reachability information request from the node, the VPN
reachability information request comprising a VPN
identifier. The method further comprises receiving VPN
reachability information at the node.
3o Yet another aspect of the invention provides a method for providing VPN reachability information at a node of a data network. The method comprises receiving a VPN reachability information request at the node, the VPN
reachability information request comprising a VPN
identifier. The method further comprises retrieving VPN
reachability information associated with the VPN
To implement VPNs on SPNs using MPLS, {3}
proposes that a CPE will transmit a Border Gateway Protocol (BGP) message to the SPN to indicate its presence in the network and to indicate the set of VPNs in which the CPE wants to participate. The BGP message includes "VPN reachability information", including the CPE's address in the ISP's address space and a VPN identifier.
The BGP message is received by the PE node which is connected to the CPE. The PE node can filter or otherwise examine the message to ensure that it complies with the ISP's policies. If the message does comply with the ISP's policies, the message is propagated to other PE
nodes of the SPN according to the specifications of BGP
(see IETF document RFC 1771).
The other PE nodes of the SPN store the VPN
reachability information and forward the BGP message to any of their connected CPE that are participating in the same VPN. The CPE receiving the BGP message can then use MPLS signalling protocol to set up a MPLS tunnel to the CPE which has just joined the VPN. The PE nodes use the stored VPN reachability information to establish the MPLS
tunnels.
The method described in {3} requires very little or no intervention by an ISP when a new CPE is added to a VPN. However, in a large SPN which supports a large number of VPN subscribers, each PE node of the SPN would be required to store a very large amount of VPN
reachability information. Moreover, only a small percentage of the stored VPN reachability information may actually be needed by any particular PE node.
For example, in an SPN having 2000 PE nodes and 1000 VPN interfaces per PE node with an average of 10 sites per VPN, 2 million VPN reachability information records would be distributed to each PE node. Assuming conservatively that each VPN reachability information record requires 30 bytes of storage, the VPN reachability information would require 60 Mbytes of storage at each PE
node. However, according to the above assumptions, only 10,000 of the stored VPN reachability information records 1o would actually be used by a typical PE node to establish VPN tunnels. The remaining 1.99 million of the 2 million reachability information records, stored at a typical PE
node, i.e. 99.50 of the stored records, would not be used.
{4} proposes that PE nodes transmitting BGP
messages apply outbound filtering so as not to propagate VPN reachability information to other PE nodes which are not participating in the VPN identified in the BGP
message. Alternatively, {4} proposes that PE nodes receiving BGP messages apply inbound filtering so as not to store VPN reachability information for VPNs in which they are not participating. These filtering approaches may address the storage inefficiencies noted above.
However, should CPE requiring access to a particular VPN
be connected to a PE node not previously participating in that VPN, such filtering would result in the PE node lacking VPN reachability information for that VPN. The required VPN reachability information would need to be provided to the PE node, either by operator provisioning or by dropping and re-establishing the connection between the PE node and other PE nodes of the SPN so that all other PE nodes of the SPN automatically transmit all of their accumulated VPN reachability information to the PE
node. The former method for acquiring the required VPN
reachability information is time-consuming, error-prone and expensive. In a large network, the latter method for acquiring the required VPN reachability information would take too long and have too great an impact on SPN
performance to be acceptable.
Summary of the Invention The invention seeks to reduce or eliminate the above problems by enabling a particular PE node to solicit specified VPN reachability information from other PE nodes when such information is needed at the particular PE node.
One aspect of the invention provides a method for to distributing VPN reachability information in a data network. The method comprises transmitting a VPN
reachability information request from a requesting node of the data network to another node of the data network, the VPN reachability information request comprising a VPN
identifier. The method further comprises receiving the VPN reachability information request at another node of the data network; retrieving VPN reachability information associated with the VPN identifier at the other node;
transmitting the retrieved VPN reachability information 2o from the other node to the requesting node; and receiving the transmitted VPN reachability information at the requesting node.
Another aspect of the invention provides a method for acquiring VPN reachability information at a node of a data network. The method comprises transmitting a VPN
reachability information request from the node, the VPN
reachability information request comprising a VPN
identifier. The method further comprises receiving VPN
reachability information at the node.
3o Yet another aspect of the invention provides a method for providing VPN reachability information at a node of a data network. The method comprises receiving a VPN reachability information request at the node, the VPN
reachability information request comprising a VPN
identifier. The method further comprises retrieving VPN
reachability information associated with the VPN
- 5 -identifier at the node; and transmitting retrieved VPN
reachability information from the node.
The methods as defined above enable a node in a data network to acquire VPN reachability information when it is required without unduly disrupting operation of the data network. Because the VPN reachability information is acquired at the node only when required, storage of large quantities of uneeded VPN reachability information at the data node is avoided, enabling cost reduction of the data l0 node .
Modifications to the operation of route reflectors in data networks provide further benefits. In particular, by enabling route reflectors to filter VPN
reachability information so that it is provided only to client peer nodes nodes participating in the VPNs to which the reachability information applies, processing and storage at non-participating peer nodes can be reduced.
Thus, another aspect of the invention provides a method for operating a route reflector in a data network.
2o The method comprises receiving VPN reachability information from particular client peer node connected to the route reflector, the VPN reachability information including a VPN identifier identifying a particular VPN.
The method further comprises reflecting the received VPN
reachability information to all non-client peer nodes connected to the route reflector; reflecting the received VPN reachability information to all non-solicit-capable client peer nodes connected to the route reflector; and reflecting the received VPN reachability information to 3o only those solicit-capable peer nodes connected to the route reflector which are currently participating in the particular VPN.
Another aspect of the invention provides a method for operating a route reflector in a data network, comprising receiving VPN reachability information from a non-client peer node connected to the route reflector, the VPN reachability information including a VPN identifier
reachability information from the node.
The methods as defined above enable a node in a data network to acquire VPN reachability information when it is required without unduly disrupting operation of the data network. Because the VPN reachability information is acquired at the node only when required, storage of large quantities of uneeded VPN reachability information at the data node is avoided, enabling cost reduction of the data l0 node .
Modifications to the operation of route reflectors in data networks provide further benefits. In particular, by enabling route reflectors to filter VPN
reachability information so that it is provided only to client peer nodes nodes participating in the VPNs to which the reachability information applies, processing and storage at non-participating peer nodes can be reduced.
Thus, another aspect of the invention provides a method for operating a route reflector in a data network.
2o The method comprises receiving VPN reachability information from particular client peer node connected to the route reflector, the VPN reachability information including a VPN identifier identifying a particular VPN.
The method further comprises reflecting the received VPN
reachability information to all non-client peer nodes connected to the route reflector; reflecting the received VPN reachability information to all non-solicit-capable client peer nodes connected to the route reflector; and reflecting the received VPN reachability information to 3o only those solicit-capable peer nodes connected to the route reflector which are currently participating in the particular VPN.
Another aspect of the invention provides a method for operating a route reflector in a data network, comprising receiving VPN reachability information from a non-client peer node connected to the route reflector, the VPN reachability information including a VPN identifier
- 6 -identifying a particular VPN; reflecting the received VPN
reachability information to all non-solicit-capable client peer nodes connected to the route reflector; and reflecting the received VPN reachability information to only those solicit-capable peer nodes connected to the route reflector which are currently participating in the particular VPN.
Yet another aspect of the invention provides a method for operating a route reflector in a data network, to comprising receiving VPN reachability information from an external node connected to the route reflector, the VPN
reachability information including a VPN identifier identifying a particular VPN; reflecting the received VPN
reachability information to all non-client peer nodes connected to the route reflector; reflecting the received VPN reachability information to all non-solicit-capable client peer nodes connected to the route reflector; and reflecting the received VPN reachability information to only those solicit-capable peer nodes connected to the 2o route reflector which are currently participating in the particular VPN.
Another aspect of the invention provides a method for distributing VPN reachability information in a data network. The method comprises maintaining at a node of the data network a VPN send list for each VPN in which the node currently participates, the VPN send list for a particular VPN identifying peer nodes of the node which also participate in that particular VPN. Upon receipt of VPN reachability information for the particular VPN, the 3o node transmits that VPN information only to peer nodes on the VPN send list for the particular VPN.
Another aspect of the invention provides a data network, comprising a plurality of nodes. Each node comprises means for transmitting a VPN reachability information request to another node of the data network, the VPN reachability information request comprising a VPN
identifier; means for receiving a VPN reachability information request from another node of the data network;
means for retrieving VPN reachability information associated with a VPN identifier in a received VPN
reachability information request; means for transmitting retrieved VPN reachability information to another node of the data network; and means for receiving VPN reachability information from another node of the data network.
Another aspect of the invention provides a node for a data network, comprising means for transmitting a VPN reachability information request, the VPN reachability information request comprising a VPN identifier; and means for receiving VPN reachability information.
Yet another aspect provides a node for a data network, comprising means for receiving a VPN reachability information request, the VPN reachability information request comprising a VPN identifier; means for retrieving VPN reachability information associated with the VPN
identifier; and means for transmitting retrieved VPN
reachability information.
2o Another aspect of the invention provides a route reflector for a data network, comprising means for receiving VPN reachability information from particular client peer node connected to the route reflector, the VPN
reachability information including a VPN identifier identifying a particular VPN; means for reflecting the received VPN reachability information to all non-client peer nodes connected to the route reflector; means for reflecting the received VPN reachability information to all non-solicit-capable client peer nodes connected to the route reflector; and means for reflecting the received VPN
reachability information to only those solicit-capable peer nodes connected to the route reflector which are currently participating in the particular VPN.
Another aspect of the invention provides a route reflector for a data network, comprising means for receiving VPN reachability information from a non-client peer node connected to the route reflector, the VPN
reachability information including a VPN identifier identifying a particular VPN; means for reflecting the received VPN reachability information to all non-solicit-capable client peer nodes connected to the route reflector; and means for reflecting the received VPN
reachability information to only those solicit-capable peer nodes connected to the route reflector which are currently participating in the particular VPN.
Yet another aspect of the invention provides a 1o route reflector for a data network, comprising means for receiving VPN reachability information from an external peer node connected to the route reflector, the VPN
reachability information including a VPN identifier identifying a particular VPN; means for reflecting the received VPN reachability information to all non-client peer nodes connected to the route reflector; means for reflecting the received VPN reachability information to all non-solicit-capable client peer nodes connected to the route reflector; and means for reflecting the received VPN
2o reachability information to only those solicit-capable peer nodes connected to the route reflector which are currently participating in the particular VPN.
Another aspect of the invention provides a node for a data network. The node comprises means for maintaining a VPN send list for each VPN in which the node currently participates, the VPN send list for a particular VPN identifying peer nodes of the node which also participate in that particular VPN. The node further comprises means for transmitting that VPN information only to peer nodes on the VPN send list for the particular VPN
upon receipt of VPN reachability information for the particular VPN.
_ g _ Brief Description of the Drawings Embodiments of the invention are described below with reference to the accompanying drawings, by way of example only. In the drawings:
Figure 1 is a block schematic diagram of a data network embodying a first implementation of the invention;
Figure 2 is a flow chart showing steps in a process performed by a solicit-capable PE node on receipt of a VPN connection request from CPE;
Figure 3 is a flow chart showing steps in a process performed by a solicit-capable PE node on receipt of a VPN reachability information request;
Figure 4 is a flow chart showing steps in a process performed by a solicit-capable PE node on receipt of VPN reachability information;
Figure 5 is a message flow diagram showing message flows resulting in distribution of VPN
reachability information;
Figure 6 is a flow chart showing steps in a process performed by a solicit-capable PE node on receipt of a VPN disconnect request from CPE;
Figure 7 is flow chart showing steps in a process performed by a solicit-capable PE node on receipt of a VPN
withdraw request;
Figure 8 is a message flow diagram showing message flows resulting in deletion of VPN reachability information;
Figure 9 is a block schematic diagram showing 3o a data network embodying a second implementation of the invention; and Figure 10 is flow chart showing steps in a process performed by a route reflector on receipt of VPN
reachability information.
Detailed Description of Embodiments Figure 1 is a block schematic diagram of a data network embodying a first implementation of the invention.
The data network comprises a Service Provider Network (SPN) 10 connected to a plurality of customer networks 20.
The SPN 10 comprises a plurality of Provider Edge (PE) nodes 12 interconnected by transmission facilities 14.
Each PE node 12 of the SPN 10 is connected to one or more Customer Premises Equipment CPE units 22 of a customer network 20.
A typical customer has data networks at multiple sites and contracts with the service provider to link those sites via the SPN 10. For the example illustrated in Figure l, customer 1 links customer networks 20 at site 1 and site 2 via PE3 and PE9 of the SPN 10, and customer 2 links customer networks 20 at site 1 and site 2 via the same PE3 and PE4 of the SPN 10. Because PE3 and PE4 of the SPN 10 are shared, the connections constitute Virtual Private Networks (VPNs).
In a Multi-Protocol Label Switching (MPLS) network, the PE nodes require VPN reachability information to establish MPLS tunnels corresponding to VPN
connections. As described above, in previously proposed MPLS VPN architectures, the PE nodes are each required to store a full set of VPN reachability information, only a small proportion of which is used at any one PE node.
In this description, the term "VPN Reachability Information" will be abbreviated to "VRI" for convenience.
In the SPN 20 constructed according to an embodiment of the invention, at least some of the PE nodes 12 are "solicit-capable" - i.e. they are provided with functionality that enables them to request VRI when they need it without unduly disrupting operation of the SPN 20.
Figure 2 is a flow chart showing steps in a process performed by a solicit-capable PE node on receipt of a VPN connection request from CPE, the connection request specifying a VPN identifier for the VPN in which the CPE wishes to participate. The PE node determines whether it already has another CPE registered for that VPN. If the PE node has another CPE registered for that VPN, it already has the required VRI and it has a send list identifying all peer nodes participating in that VPN.
Consequently, it transmits VRI received from the CPE with the VPN connection request to peer nodes on the send list for that VPN without requesting further VRI.
If, however, the PE node does not have the required VRI, it transmits the VRI received with the VPN
connection request together with specified overhead bits set to indicate that further VRI is required for that VPN
to all peer nodes. The resulting message acts as a VRI
request.
Figure 3 is a flow chart showing steps in a process performed by a solicit-capable PE node on receipt of a VPN reachability information request. The PE node determines whether it has VRI for that VPN. If the PE
2o node has the requested VRI, it retrieves the VRI and transmits it to the requesting peer node. The PE node receiving the VRI request also adds the requesting peer node to the send list for that VPN and forwards VRI
received in the request to CPE participating in that VPN.
Figure 4 is a flow chart showing steps in a process performed by a solicit-capable PE node on receipt of VPN reachability information. If the VRI is received from a non-solicit-capable PE node, the PE node stores the VRI for possible future use. If the VRI is received from 3o a solicit-capable PE node, the receiving PE node stores the VRI only if it is currently participating in that VPN.
The PE node adds the sending peer node to the send list for that VPN and forwards the received VRI to any CPE
participating in that VPN.
Figure 5 is a message flow diagram showing how the processes of Figures 2, 3 and 4 work together to provide message flows which result in distribution of VPN
reachability information. The CPE sends a VPN connection request to its PE node. If that PE node lacks VRI
required to enable the CPE to participate in the requested VPN, the PE node sends a VRI request to other PE nodes.
Those PE nodes having the required VRI send it back to the requesting PE node which stores the VRI and forwards it to the requesting CPE. This enables the CPE to request that MPLS tunnels be established to other CPE participating in the VPN.
l0 Figure 6 is a flow chart showing steps in a process performed by a solicit-capable PE node on receipt of a VPN disconnect request from CPE. If the receiving PE
node is connected to other CPE participating in that VPN, the sender list for that VPN is still required at that PE
node. However, if no other CPE connected to that node is participating in that VPN, the PE node deletes the send list for that VPN to free storage capacity. The PE node deletes VPN reachability information for that CPE for that VPN and sends a VPN withdraw message to peer PE nodes.
2o Should that PE node require the VRI for that VPN again in the future, it can request the required VRI using the processes described above.
Figure 7 is flow chart showing steps in a process performed by a solicit-capable PE node on receipt of a VPN
withdraw request. The receiving PE node deletes the VRI
for the CPE, VPN and peer node specified in the VPN
withdraw request so attempts to link to the disconnecting CPE via the VPN will no longer be made. The PE node also deletes the sending node from the send list for that VPN
if it has no VRI indicating that other CPE is registered for that VPN at the sending peer node.
Figure 8 is a message flow diagram showing how the processes of Figures 6 and 7 work together to provide message flows resulting in deletion of VPN reachability information.
Figure 9 is a block schematic diagram showing a data network embodying a second implementation of the invention. In this embodiment, PE nodes 12, 13 are connected to a route reflector 14, PE nodes 15, 16 are connected to another route reflector 17 and the two route reflectors 14, 17 are connected together. A PE node 32 of another SPN 30 is connected to one of the route reflectors 17. Route reflector 14 has as client peer nodes the PE
to nodes 12, 13, as non-client peer node the route reflector 17 and as external peer node the PE node 32. Route reflector 17 has as client peer nodes the PE nodes 15, 16, as non-client peer node the route reflector 14 and as external peer node the PE node 32.
Figure 10 is flow chart showing steps in a process performed by the route reflector 17 on receipt of VPN reachability information. If the VRI is received from one of the client peer nodes 15, the route reflector 17 forwards the received VRI to its non-client peer node 14 2o and to its other client peer node 16 provided that the other client peer node 16 is either a non-solicit-capable node or a solicit-capable node that is currently participating in that VPN. If the VRI is received from the external peer node 32, the route reflector 17 forwards the VRI to its non-client peer node 14 and to its client nodes 15, 16 if they are non-solicit-capable or if they are solicit-capable and currently participating in that VPN. If the VRI is received from the non-client peer 14, the route reflector forwards the VRI to its client nodes 15, 16 if they are non-solicit-capable or if they are solicit-capable and currently participating in that VPN.
Further information on embodiments of the invention may be found in an IETF Draft to be submitted to the IETF by Dwight Jamieson and Rong Wang on November 18, 1998. The text of this draft is reproduced below:
Internet Draft draft-ietf-bgp-solicit-OO.txt November 1998 Solicitation Extensions for BGP-4 <draft jamieson-bgp-solicit-OO.txt>
Status of this Memo to This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
2o To learn the current status of any Internet-Draft, please check the "1 id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast).
Abstract This document describes an extension to BGP-4 which may be used by a BGP-4 speaker to solicit Virtual Private Network (VPN) reachability 3o information from other IBGP speakers.
The motivation of the proposed technique is to provide a means of reducing the memory requirements of routers which use BGP-4 to distribute VPN reachability information as described in [1] and [4].
The extension is backward compatible in that a router which supports the extension can interoperate with a router which doesn't.
1. Introduction Recently, several drafts have described techniques to dynamically establish VPN tunnels across a provider network. Many of the drafts have proposed that BGP-4 be used to distribute either VPN
reachability information or VPN route information.
to The methods described in [1] generally don't depend on outbound policy filters to control the distribution of VPN reachability information. When a new VPN member site joins a VPN the information regarding that site is distributed to all other Provider Edge (PE) routers in the network. This allows new VPN member sites to join a VPN with very little or no intervention on the part of the provider.
On the other hand, the methods described in [4] do rely on outbound policy filtering to control the distribution of VPN route information. PE routers and route reflectors need to be provisioned Zo with a list of peers which require a set of VPN route information.
When a new VPN member site joins a VPN, policy filtering may have to be changed on multiple devices.
In a large provider network which supports a large number of VPN
subscribers, the methods described in both [1] and [4] could have serious scaling problems.
Using the methods described in [1], the amount of VPN reachability information that would be stored in the BGP-4 speakers' Adj-RIB-In 3o could be very large. Whereas, the percentage of that information relevant to any particular BGP-4 speaker might be small.
Using the methods described in [4], there would potentially be two problems. First, the amount of policy required to control VPN route information distribution would become onerous. Second, in a large network, route reflectors would be required. Depending on the distribution of VPN sites and the complexity of policy filtering, the route reflectors may be required to store huge amounts of information in their Adj-RIB-In.
The following network scenario is based on the methods described in [1 ]. The scenario makes some assumptions on the size of a future network. One can debate the numbers to a certain extent but it is clear that there is a problem:
Number of Provider Edge nodes in provider network: 2,000 to Number of VPN interfaces per Provider Edge (PE): 1,000 Average number of sites belonging to a VPN: 10 Number of VPN entries distributed to each PE: 2,000,000 Memory consumption estimate:
Conservative size of BGP Adj-RIB-In entry: 30 bytes Size of BGP Adj-RIB-In: 60,000,000 bytes Given the assumptions above, 10,000 VPN Adj-RIB-In entries on an average PE would be acted upon. In other words, those 10,000 entries 2o would be passed to the PE's directly connected Customer Premises Equipments (CPEs) for the purpose of establishing VPN tunnels.
Whereas, 1,990,000 or 99.5% of the entries would have no value and be ignored.
Some BGP-4 implementations allow entries which should be in Adj-RIB
In to be discarded; however, the entries may be required at a later time when a new VPN member joins. Currently, if a BGP-4 implementation allows Adj-RIB-In entries to be discarded, the only way to retrieve them at a later time is to close the peer connection 3o and re-establish it. In a large network, this would be very disruptive.
This draft proposes a technique which would allow BGP-4 to discard Adj-RIB-In entries that are not relevant and solicit those that are.
2. Terms and Definitions VPN Reachability Information (VRI) - A BGP route associated with a VPN. It contains route information as defined in [2] and VPN specific information.
Solicitation - A request for VRI from an IBGP speaker to other IBGP speakers.
Solicitation Capable IBGP (SC-IBGP) speakers - A router which has an implementation of BGP-4 that supports the solicitation extensions and solicitation is enabled on that router. All IBGP speakers on that router are called SC-IBGP
i5 speakers.
Non-Solicitation Capable IBGP (NSC-IBGP) speakers - A router which has an implementation of BGP-4 that either does not support the solicitation extensions or solicitation is 2o disabled on that router. All IBGP speakers on that router are called NSC-IBGP speakers.
3. Design Criteria BGP Solicitation was designed to satisfy the following criteria:
- Dynamic, non-disruptive distribution of VRI
- Ability to discard non-relevant VRI
- Compatibility It must be possible for NSC-IBGP speakers (including route reflectors) to continue supporting the general VPN architecture without any loss of VRI.
4. Solicitation Path Attributes This document introduces two new BGP-4 path attributes: Solicitation s Request and Solicitation Withdraw.
4.1. Solicitation Request Path Attribute (Type Code 16):
The Solicitation Request (SOL_REQ) path attribute is an optional to transitive attribute of length 0. It is used by a SC-IBGP speaker to solicit VRI from other SC-IBGP speakers.
4.2. Solicitation Withdraw Path Attribute (Type Code 17):
i5 The Solicitation Withdraw (SOL_WD) path attribute is an optional transitive attribute of variable length.
The SOL_WD path attribute consists of a list of four octet values, each of which indicates membership withdraw from a particular VPN.
ao Each SOL_WD path attribute is represented by a list of tuples of form <length, VPN identifiers>, where each tuple is encoded as shown below:
+_____________________________+
25 ~ Length (2 octets) +_____________________________+
~ VPN identifiers (variable) +_____________________________+
3o Length - total length of the VPN identifiers in octets VPN identifiers - a list of withdrawing VPN identifiers An UPDATE message that contains the SOL_WD attribute is not required to carry any other path attributes.
The solicitation extension path attributes must not be passed to EBGP
peers.
5. Solicitation of VPN Reachability Information The first time a SC-IBGP speaker A advertises a VRI for VPN X, A must include a SOL_REQ path attribute along with the VRI. This VRI must be distributed to all IBGP peers. It should be noted that subsequent VRIs advertised by A for VPN X should not include the SOL_REQ path attribute.
to When a SC-IBGP speaker B which supports VPN X receives the VRI
originated from A (may come from a route reflector), B must distribute all of its VRIs associated with VPN X back to the peer from which it received the solicitation.
A SC-IBGP speaker not in VPN X may discard the reachability information from A (i.e. may not store it in its Adj-RIB-In).
A NSC-IBGP speaker C receiving A's UPDATE message must ignore the 2o SOL_REQ path attribute, store the reachability information in its Adj-RIB-In and continue to distribute its VRIs for VPN X to all of its peers. Meanwhile, A should store all reachability information from C in its adj-RIB-In regardless whether C participates in the same VPN(s) or not.
6. VPN Membership Withdraw When a member of VPN X unsubscribes, a SC-IBGP speaker A will notify all other IBGP peers known to support VPN X. Multiple members of VPN
3o X may be supported by A. But if the last member of VPN X is withdrawn from A, all other SC-IBGP speakers that support X should stop sending VPN X's VRI to A.
To withdraw membership from VPN X, a SC-IBGP speaker A may include a SOL_WD path attribute along with the unfeasible routes) in its UPDATE message. Upon receiving this UPDATE message, a SC-IBGP
speaker B must withdraw the unfeasible route(s). B must also stop sending reachability information related to VPN X to A if the last reachability information related to VPN X from A has been withdrawn.
s Means to withdraw VRIs on NSC-IBGP speakers need further investigation.
reachability information to all non-solicit-capable client peer nodes connected to the route reflector; and reflecting the received VPN reachability information to only those solicit-capable peer nodes connected to the route reflector which are currently participating in the particular VPN.
Yet another aspect of the invention provides a method for operating a route reflector in a data network, to comprising receiving VPN reachability information from an external node connected to the route reflector, the VPN
reachability information including a VPN identifier identifying a particular VPN; reflecting the received VPN
reachability information to all non-client peer nodes connected to the route reflector; reflecting the received VPN reachability information to all non-solicit-capable client peer nodes connected to the route reflector; and reflecting the received VPN reachability information to only those solicit-capable peer nodes connected to the 2o route reflector which are currently participating in the particular VPN.
Another aspect of the invention provides a method for distributing VPN reachability information in a data network. The method comprises maintaining at a node of the data network a VPN send list for each VPN in which the node currently participates, the VPN send list for a particular VPN identifying peer nodes of the node which also participate in that particular VPN. Upon receipt of VPN reachability information for the particular VPN, the 3o node transmits that VPN information only to peer nodes on the VPN send list for the particular VPN.
Another aspect of the invention provides a data network, comprising a plurality of nodes. Each node comprises means for transmitting a VPN reachability information request to another node of the data network, the VPN reachability information request comprising a VPN
identifier; means for receiving a VPN reachability information request from another node of the data network;
means for retrieving VPN reachability information associated with a VPN identifier in a received VPN
reachability information request; means for transmitting retrieved VPN reachability information to another node of the data network; and means for receiving VPN reachability information from another node of the data network.
Another aspect of the invention provides a node for a data network, comprising means for transmitting a VPN reachability information request, the VPN reachability information request comprising a VPN identifier; and means for receiving VPN reachability information.
Yet another aspect provides a node for a data network, comprising means for receiving a VPN reachability information request, the VPN reachability information request comprising a VPN identifier; means for retrieving VPN reachability information associated with the VPN
identifier; and means for transmitting retrieved VPN
reachability information.
2o Another aspect of the invention provides a route reflector for a data network, comprising means for receiving VPN reachability information from particular client peer node connected to the route reflector, the VPN
reachability information including a VPN identifier identifying a particular VPN; means for reflecting the received VPN reachability information to all non-client peer nodes connected to the route reflector; means for reflecting the received VPN reachability information to all non-solicit-capable client peer nodes connected to the route reflector; and means for reflecting the received VPN
reachability information to only those solicit-capable peer nodes connected to the route reflector which are currently participating in the particular VPN.
Another aspect of the invention provides a route reflector for a data network, comprising means for receiving VPN reachability information from a non-client peer node connected to the route reflector, the VPN
reachability information including a VPN identifier identifying a particular VPN; means for reflecting the received VPN reachability information to all non-solicit-capable client peer nodes connected to the route reflector; and means for reflecting the received VPN
reachability information to only those solicit-capable peer nodes connected to the route reflector which are currently participating in the particular VPN.
Yet another aspect of the invention provides a 1o route reflector for a data network, comprising means for receiving VPN reachability information from an external peer node connected to the route reflector, the VPN
reachability information including a VPN identifier identifying a particular VPN; means for reflecting the received VPN reachability information to all non-client peer nodes connected to the route reflector; means for reflecting the received VPN reachability information to all non-solicit-capable client peer nodes connected to the route reflector; and means for reflecting the received VPN
2o reachability information to only those solicit-capable peer nodes connected to the route reflector which are currently participating in the particular VPN.
Another aspect of the invention provides a node for a data network. The node comprises means for maintaining a VPN send list for each VPN in which the node currently participates, the VPN send list for a particular VPN identifying peer nodes of the node which also participate in that particular VPN. The node further comprises means for transmitting that VPN information only to peer nodes on the VPN send list for the particular VPN
upon receipt of VPN reachability information for the particular VPN.
_ g _ Brief Description of the Drawings Embodiments of the invention are described below with reference to the accompanying drawings, by way of example only. In the drawings:
Figure 1 is a block schematic diagram of a data network embodying a first implementation of the invention;
Figure 2 is a flow chart showing steps in a process performed by a solicit-capable PE node on receipt of a VPN connection request from CPE;
Figure 3 is a flow chart showing steps in a process performed by a solicit-capable PE node on receipt of a VPN reachability information request;
Figure 4 is a flow chart showing steps in a process performed by a solicit-capable PE node on receipt of VPN reachability information;
Figure 5 is a message flow diagram showing message flows resulting in distribution of VPN
reachability information;
Figure 6 is a flow chart showing steps in a process performed by a solicit-capable PE node on receipt of a VPN disconnect request from CPE;
Figure 7 is flow chart showing steps in a process performed by a solicit-capable PE node on receipt of a VPN
withdraw request;
Figure 8 is a message flow diagram showing message flows resulting in deletion of VPN reachability information;
Figure 9 is a block schematic diagram showing 3o a data network embodying a second implementation of the invention; and Figure 10 is flow chart showing steps in a process performed by a route reflector on receipt of VPN
reachability information.
Detailed Description of Embodiments Figure 1 is a block schematic diagram of a data network embodying a first implementation of the invention.
The data network comprises a Service Provider Network (SPN) 10 connected to a plurality of customer networks 20.
The SPN 10 comprises a plurality of Provider Edge (PE) nodes 12 interconnected by transmission facilities 14.
Each PE node 12 of the SPN 10 is connected to one or more Customer Premises Equipment CPE units 22 of a customer network 20.
A typical customer has data networks at multiple sites and contracts with the service provider to link those sites via the SPN 10. For the example illustrated in Figure l, customer 1 links customer networks 20 at site 1 and site 2 via PE3 and PE9 of the SPN 10, and customer 2 links customer networks 20 at site 1 and site 2 via the same PE3 and PE4 of the SPN 10. Because PE3 and PE4 of the SPN 10 are shared, the connections constitute Virtual Private Networks (VPNs).
In a Multi-Protocol Label Switching (MPLS) network, the PE nodes require VPN reachability information to establish MPLS tunnels corresponding to VPN
connections. As described above, in previously proposed MPLS VPN architectures, the PE nodes are each required to store a full set of VPN reachability information, only a small proportion of which is used at any one PE node.
In this description, the term "VPN Reachability Information" will be abbreviated to "VRI" for convenience.
In the SPN 20 constructed according to an embodiment of the invention, at least some of the PE nodes 12 are "solicit-capable" - i.e. they are provided with functionality that enables them to request VRI when they need it without unduly disrupting operation of the SPN 20.
Figure 2 is a flow chart showing steps in a process performed by a solicit-capable PE node on receipt of a VPN connection request from CPE, the connection request specifying a VPN identifier for the VPN in which the CPE wishes to participate. The PE node determines whether it already has another CPE registered for that VPN. If the PE node has another CPE registered for that VPN, it already has the required VRI and it has a send list identifying all peer nodes participating in that VPN.
Consequently, it transmits VRI received from the CPE with the VPN connection request to peer nodes on the send list for that VPN without requesting further VRI.
If, however, the PE node does not have the required VRI, it transmits the VRI received with the VPN
connection request together with specified overhead bits set to indicate that further VRI is required for that VPN
to all peer nodes. The resulting message acts as a VRI
request.
Figure 3 is a flow chart showing steps in a process performed by a solicit-capable PE node on receipt of a VPN reachability information request. The PE node determines whether it has VRI for that VPN. If the PE
2o node has the requested VRI, it retrieves the VRI and transmits it to the requesting peer node. The PE node receiving the VRI request also adds the requesting peer node to the send list for that VPN and forwards VRI
received in the request to CPE participating in that VPN.
Figure 4 is a flow chart showing steps in a process performed by a solicit-capable PE node on receipt of VPN reachability information. If the VRI is received from a non-solicit-capable PE node, the PE node stores the VRI for possible future use. If the VRI is received from 3o a solicit-capable PE node, the receiving PE node stores the VRI only if it is currently participating in that VPN.
The PE node adds the sending peer node to the send list for that VPN and forwards the received VRI to any CPE
participating in that VPN.
Figure 5 is a message flow diagram showing how the processes of Figures 2, 3 and 4 work together to provide message flows which result in distribution of VPN
reachability information. The CPE sends a VPN connection request to its PE node. If that PE node lacks VRI
required to enable the CPE to participate in the requested VPN, the PE node sends a VRI request to other PE nodes.
Those PE nodes having the required VRI send it back to the requesting PE node which stores the VRI and forwards it to the requesting CPE. This enables the CPE to request that MPLS tunnels be established to other CPE participating in the VPN.
l0 Figure 6 is a flow chart showing steps in a process performed by a solicit-capable PE node on receipt of a VPN disconnect request from CPE. If the receiving PE
node is connected to other CPE participating in that VPN, the sender list for that VPN is still required at that PE
node. However, if no other CPE connected to that node is participating in that VPN, the PE node deletes the send list for that VPN to free storage capacity. The PE node deletes VPN reachability information for that CPE for that VPN and sends a VPN withdraw message to peer PE nodes.
2o Should that PE node require the VRI for that VPN again in the future, it can request the required VRI using the processes described above.
Figure 7 is flow chart showing steps in a process performed by a solicit-capable PE node on receipt of a VPN
withdraw request. The receiving PE node deletes the VRI
for the CPE, VPN and peer node specified in the VPN
withdraw request so attempts to link to the disconnecting CPE via the VPN will no longer be made. The PE node also deletes the sending node from the send list for that VPN
if it has no VRI indicating that other CPE is registered for that VPN at the sending peer node.
Figure 8 is a message flow diagram showing how the processes of Figures 6 and 7 work together to provide message flows resulting in deletion of VPN reachability information.
Figure 9 is a block schematic diagram showing a data network embodying a second implementation of the invention. In this embodiment, PE nodes 12, 13 are connected to a route reflector 14, PE nodes 15, 16 are connected to another route reflector 17 and the two route reflectors 14, 17 are connected together. A PE node 32 of another SPN 30 is connected to one of the route reflectors 17. Route reflector 14 has as client peer nodes the PE
to nodes 12, 13, as non-client peer node the route reflector 17 and as external peer node the PE node 32. Route reflector 17 has as client peer nodes the PE nodes 15, 16, as non-client peer node the route reflector 14 and as external peer node the PE node 32.
Figure 10 is flow chart showing steps in a process performed by the route reflector 17 on receipt of VPN reachability information. If the VRI is received from one of the client peer nodes 15, the route reflector 17 forwards the received VRI to its non-client peer node 14 2o and to its other client peer node 16 provided that the other client peer node 16 is either a non-solicit-capable node or a solicit-capable node that is currently participating in that VPN. If the VRI is received from the external peer node 32, the route reflector 17 forwards the VRI to its non-client peer node 14 and to its client nodes 15, 16 if they are non-solicit-capable or if they are solicit-capable and currently participating in that VPN. If the VRI is received from the non-client peer 14, the route reflector forwards the VRI to its client nodes 15, 16 if they are non-solicit-capable or if they are solicit-capable and currently participating in that VPN.
Further information on embodiments of the invention may be found in an IETF Draft to be submitted to the IETF by Dwight Jamieson and Rong Wang on November 18, 1998. The text of this draft is reproduced below:
Internet Draft draft-ietf-bgp-solicit-OO.txt November 1998 Solicitation Extensions for BGP-4 <draft jamieson-bgp-solicit-OO.txt>
Status of this Memo to This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
2o To learn the current status of any Internet-Draft, please check the "1 id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast).
Abstract This document describes an extension to BGP-4 which may be used by a BGP-4 speaker to solicit Virtual Private Network (VPN) reachability 3o information from other IBGP speakers.
The motivation of the proposed technique is to provide a means of reducing the memory requirements of routers which use BGP-4 to distribute VPN reachability information as described in [1] and [4].
The extension is backward compatible in that a router which supports the extension can interoperate with a router which doesn't.
1. Introduction Recently, several drafts have described techniques to dynamically establish VPN tunnels across a provider network. Many of the drafts have proposed that BGP-4 be used to distribute either VPN
reachability information or VPN route information.
to The methods described in [1] generally don't depend on outbound policy filters to control the distribution of VPN reachability information. When a new VPN member site joins a VPN the information regarding that site is distributed to all other Provider Edge (PE) routers in the network. This allows new VPN member sites to join a VPN with very little or no intervention on the part of the provider.
On the other hand, the methods described in [4] do rely on outbound policy filtering to control the distribution of VPN route information. PE routers and route reflectors need to be provisioned Zo with a list of peers which require a set of VPN route information.
When a new VPN member site joins a VPN, policy filtering may have to be changed on multiple devices.
In a large provider network which supports a large number of VPN
subscribers, the methods described in both [1] and [4] could have serious scaling problems.
Using the methods described in [1], the amount of VPN reachability information that would be stored in the BGP-4 speakers' Adj-RIB-In 3o could be very large. Whereas, the percentage of that information relevant to any particular BGP-4 speaker might be small.
Using the methods described in [4], there would potentially be two problems. First, the amount of policy required to control VPN route information distribution would become onerous. Second, in a large network, route reflectors would be required. Depending on the distribution of VPN sites and the complexity of policy filtering, the route reflectors may be required to store huge amounts of information in their Adj-RIB-In.
The following network scenario is based on the methods described in [1 ]. The scenario makes some assumptions on the size of a future network. One can debate the numbers to a certain extent but it is clear that there is a problem:
Number of Provider Edge nodes in provider network: 2,000 to Number of VPN interfaces per Provider Edge (PE): 1,000 Average number of sites belonging to a VPN: 10 Number of VPN entries distributed to each PE: 2,000,000 Memory consumption estimate:
Conservative size of BGP Adj-RIB-In entry: 30 bytes Size of BGP Adj-RIB-In: 60,000,000 bytes Given the assumptions above, 10,000 VPN Adj-RIB-In entries on an average PE would be acted upon. In other words, those 10,000 entries 2o would be passed to the PE's directly connected Customer Premises Equipments (CPEs) for the purpose of establishing VPN tunnels.
Whereas, 1,990,000 or 99.5% of the entries would have no value and be ignored.
Some BGP-4 implementations allow entries which should be in Adj-RIB
In to be discarded; however, the entries may be required at a later time when a new VPN member joins. Currently, if a BGP-4 implementation allows Adj-RIB-In entries to be discarded, the only way to retrieve them at a later time is to close the peer connection 3o and re-establish it. In a large network, this would be very disruptive.
This draft proposes a technique which would allow BGP-4 to discard Adj-RIB-In entries that are not relevant and solicit those that are.
2. Terms and Definitions VPN Reachability Information (VRI) - A BGP route associated with a VPN. It contains route information as defined in [2] and VPN specific information.
Solicitation - A request for VRI from an IBGP speaker to other IBGP speakers.
Solicitation Capable IBGP (SC-IBGP) speakers - A router which has an implementation of BGP-4 that supports the solicitation extensions and solicitation is enabled on that router. All IBGP speakers on that router are called SC-IBGP
i5 speakers.
Non-Solicitation Capable IBGP (NSC-IBGP) speakers - A router which has an implementation of BGP-4 that either does not support the solicitation extensions or solicitation is 2o disabled on that router. All IBGP speakers on that router are called NSC-IBGP speakers.
3. Design Criteria BGP Solicitation was designed to satisfy the following criteria:
- Dynamic, non-disruptive distribution of VRI
- Ability to discard non-relevant VRI
- Compatibility It must be possible for NSC-IBGP speakers (including route reflectors) to continue supporting the general VPN architecture without any loss of VRI.
4. Solicitation Path Attributes This document introduces two new BGP-4 path attributes: Solicitation s Request and Solicitation Withdraw.
4.1. Solicitation Request Path Attribute (Type Code 16):
The Solicitation Request (SOL_REQ) path attribute is an optional to transitive attribute of length 0. It is used by a SC-IBGP speaker to solicit VRI from other SC-IBGP speakers.
4.2. Solicitation Withdraw Path Attribute (Type Code 17):
i5 The Solicitation Withdraw (SOL_WD) path attribute is an optional transitive attribute of variable length.
The SOL_WD path attribute consists of a list of four octet values, each of which indicates membership withdraw from a particular VPN.
ao Each SOL_WD path attribute is represented by a list of tuples of form <length, VPN identifiers>, where each tuple is encoded as shown below:
+_____________________________+
25 ~ Length (2 octets) +_____________________________+
~ VPN identifiers (variable) +_____________________________+
3o Length - total length of the VPN identifiers in octets VPN identifiers - a list of withdrawing VPN identifiers An UPDATE message that contains the SOL_WD attribute is not required to carry any other path attributes.
The solicitation extension path attributes must not be passed to EBGP
peers.
5. Solicitation of VPN Reachability Information The first time a SC-IBGP speaker A advertises a VRI for VPN X, A must include a SOL_REQ path attribute along with the VRI. This VRI must be distributed to all IBGP peers. It should be noted that subsequent VRIs advertised by A for VPN X should not include the SOL_REQ path attribute.
to When a SC-IBGP speaker B which supports VPN X receives the VRI
originated from A (may come from a route reflector), B must distribute all of its VRIs associated with VPN X back to the peer from which it received the solicitation.
A SC-IBGP speaker not in VPN X may discard the reachability information from A (i.e. may not store it in its Adj-RIB-In).
A NSC-IBGP speaker C receiving A's UPDATE message must ignore the 2o SOL_REQ path attribute, store the reachability information in its Adj-RIB-In and continue to distribute its VRIs for VPN X to all of its peers. Meanwhile, A should store all reachability information from C in its adj-RIB-In regardless whether C participates in the same VPN(s) or not.
6. VPN Membership Withdraw When a member of VPN X unsubscribes, a SC-IBGP speaker A will notify all other IBGP peers known to support VPN X. Multiple members of VPN
3o X may be supported by A. But if the last member of VPN X is withdrawn from A, all other SC-IBGP speakers that support X should stop sending VPN X's VRI to A.
To withdraw membership from VPN X, a SC-IBGP speaker A may include a SOL_WD path attribute along with the unfeasible routes) in its UPDATE message. Upon receiving this UPDATE message, a SC-IBGP
speaker B must withdraw the unfeasible route(s). B must also stop sending reachability information related to VPN X to A if the last reachability information related to VPN X from A has been withdrawn.
s Means to withdraw VRIs on NSC-IBGP speakers need further investigation.
7. Operation of BGP Route Reflectors io Operation of BGP route reflectors which do not support solicitation remains the same as defined in section 5 of [3].
Operation of BGP route reflector which supports solicitation is i5 proposed to change to the following:
Each route reflector must keep track of the VPN associated with each of its SC-Client peers. When a route is received by a route reflector, it selects the best path based on its path selection rule.
2o After the best path is selected, it must do the following depending on the type of peer it is receiving the best path from:
1 ) A route from a Non-Client peer 25 - reflect to all SC-Client peers in the same VPN; and - reflect to all NSC-Client peers.
2) A route from a Client peer 30 - reflect to all Non-Client peers; and - reflect to SC-Client peers in the same VPN other than the originator; and - reflect to all NSC-Client peers other than the originator.
35 3) A route from an EBGP peer - reflect to all Non-Client peers; and - reflect to SC-Client peers in the same VPN; and - reflect to all NSC-Client peers.
Operation of BGP route reflector which supports solicitation is i5 proposed to change to the following:
Each route reflector must keep track of the VPN associated with each of its SC-Client peers. When a route is received by a route reflector, it selects the best path based on its path selection rule.
2o After the best path is selected, it must do the following depending on the type of peer it is receiving the best path from:
1 ) A route from a Non-Client peer 25 - reflect to all SC-Client peers in the same VPN; and - reflect to all NSC-Client peers.
2) A route from a Client peer 30 - reflect to all Non-Client peers; and - reflect to SC-Client peers in the same VPN other than the originator; and - reflect to all NSC-Client peers other than the originator.
35 3) A route from an EBGP peer - reflect to all Non-Client peers; and - reflect to SC-Client peers in the same VPN; and - reflect to all NSC-Client peers.
8. Security Considerations s Security issues are not discussed in this memo.
9. Intellectual Property Considerations to Nortel Networks may seek patent or other intellectual property protection for some of all of the technologies disclosed in this document. If any standards arising from this document are or become protected by one or more patents assigned to Nortel Networks, Nortel is Networks intends to disclose those patents and license them on reasonable and non-discriminatory terms.
10. References [1] T. Li, "CPE Based VPNs Using MPLS", draft-li-mpls-vpn-OO.txt, October 1998.
[2] Y. Rekhter, T. Li, "A Border Gateway Protocol 4 (BGP-4)" draft-2s ietf-idr-bgp4-08.txt, Augest 1998.
[3] T. Bates, R. Chandra, "BGP Route Reflection An Alternative to Full Mesh IBGP", RFC 1966, June 1996 [4] E. Rosen, Y. Rekhter "BGP/MPLS VPNs", draft-rosen-vpn-mpls-OO.txt, November 1998.
[2] Y. Rekhter, T. Li, "A Border Gateway Protocol 4 (BGP-4)" draft-2s ietf-idr-bgp4-08.txt, Augest 1998.
[3] T. Bates, R. Chandra, "BGP Route Reflection An Alternative to Full Mesh IBGP", RFC 1966, June 1996 [4] E. Rosen, Y. Rekhter "BGP/MPLS VPNs", draft-rosen-vpn-mpls-OO.txt, November 1998.
11. Author's Address Dwight Jamieson Nortel Networks, Ltd.
PO Box 3511 Station C
Ottawa ON K1Y 4H7 Canada Email: djamies@nortel.ca s Rong Wang Nortel Networks, Ltd.
PO Box 3511 Station C
Ottawa ON K1Y 4H7 Canada to Email: twang@nortel.ca The embodiments of the invention described above may be modified without departing from the broad principles of the invention.
15 For example, the order of some steps in some of the processes described above may be interchanged without appreciably altering their effect.
The format of the VRI request may be altered without departing from the principles of the invention. In 20 the embodiment described above, the VRI request is implemented as a flag in a VRI distribution message sent by a PE node to inform peer nodes that a CPE has registered for VPN participation at the sending PE node.
Alternatively, the VRI request could take the form of a 25 separate VRI request message.
These and other modifications of the embodiments described above are intended to be within the scope of the invention as defined by the claims which follow.
PO Box 3511 Station C
Ottawa ON K1Y 4H7 Canada Email: djamies@nortel.ca s Rong Wang Nortel Networks, Ltd.
PO Box 3511 Station C
Ottawa ON K1Y 4H7 Canada to Email: twang@nortel.ca The embodiments of the invention described above may be modified without departing from the broad principles of the invention.
15 For example, the order of some steps in some of the processes described above may be interchanged without appreciably altering their effect.
The format of the VRI request may be altered without departing from the principles of the invention. In 20 the embodiment described above, the VRI request is implemented as a flag in a VRI distribution message sent by a PE node to inform peer nodes that a CPE has registered for VPN participation at the sending PE node.
Alternatively, the VRI request could take the form of a 25 separate VRI request message.
These and other modifications of the embodiments described above are intended to be within the scope of the invention as defined by the claims which follow.
Claims (31)
1. A method for distributing VPN reachability information in a data network, comprising:
transmitting a VPN reachability information request from a requesting node of the data network to another node of the data network, the VPN reachability information request comprising a VPN identifier;
receiving the VPN reachability information request at another node of the data network;
retrieving VPN reachability information associated with the VPN identifier at the other node;
transmitting the retrieved VPN reachability information from the other node to the requesting node;
and receiving the transmitted VPN reachability information at the requesting node.
transmitting a VPN reachability information request from a requesting node of the data network to another node of the data network, the VPN reachability information request comprising a VPN identifier;
receiving the VPN reachability information request at another node of the data network;
retrieving VPN reachability information associated with the VPN identifier at the other node;
transmitting the retrieved VPN reachability information from the other node to the requesting node;
and receiving the transmitted VPN reachability information at the requesting node.
2. A method for acquiring VPN reachability information at a node of a data network, comprising:
transmitting a VPN reachability information request from the node, the VPN reachability information request comprising a VPN identifier; and receiving VPN reachability information at the node.
transmitting a VPN reachability information request from the node, the VPN reachability information request comprising a VPN identifier; and receiving VPN reachability information at the node.
3. A method as defined in claim 2, wherein the VPN reachability information request further comprises VPN
reachability information supplied by the requesting node, the supplied VPN reachability information designating customer network addresses that may be reached via the VPN.
reachability information supplied by the requesting node, the supplied VPN reachability information designating customer network addresses that may be reached via the VPN.
4. A method as defined in claim 3, wherein the VPN reachability information request is generated in response to a VPN connection request received by the requesting node from customer equipment connected to the requesting node.
5. A method as defined in claim 2, further comprising:
storing at the node VPN reachability information received from a solicit-capable node only if the VPN
reachability information is associated with a VPN in which the node is participating; and storing at the node all VPN reachability information received from a non-solicit-capable node.
storing at the node VPN reachability information received from a solicit-capable node only if the VPN
reachability information is associated with a VPN in which the node is participating; and storing at the node all VPN reachability information received from a non-solicit-capable node.
6. A method as defined in claim 2, further comprising:
transmitting a VPN withdraw message from the node when equipment connected to the node ceases participation in a particular VPN, the VPN withdraw message comprising a VPN identifier identifying the particular VPN.
transmitting a VPN withdraw message from the node when equipment connected to the node ceases participation in a particular VPN, the VPN withdraw message comprising a VPN identifier identifying the particular VPN.
7. A method for providing VPN reachability information at a node of a data network, comprising:
receiving a VPN reachability information request at the node, the VPN reachability information request comprising a VPN identifier;
retrieving VPN reachability information associated with the VPN identifier at the node; and transmitting retrieved VPN reachability information from the node.
receiving a VPN reachability information request at the node, the VPN reachability information request comprising a VPN identifier;
retrieving VPN reachability information associated with the VPN identifier at the node; and transmitting retrieved VPN reachability information from the node.
8. A method as defined in claim 7, wherein VPN
reachability information is received with the VPN
reachability information request, further comprising:
transmitting the received VPN reachability information to customer premises equipment connected to the node and participating in a VPN associated with the VPN identifier of the VPN reachability information request.
reachability information is received with the VPN
reachability information request, further comprising:
transmitting the received VPN reachability information to customer premises equipment connected to the node and participating in a VPN associated with the VPN identifier of the VPN reachability information request.
9. A method as defined in claim 7, further comprising:
receiving a VPN withdraw message from another node; and deleting stored VPN reachability information specified in the VPN withdraw message.
receiving a VPN withdraw message from another node; and deleting stored VPN reachability information specified in the VPN withdraw message.
10. A method for operating a route reflector in a data network, comprising:
receiving VPN reachability information from particular client peer node connected to the route reflector, the VPN reachability information including a VPN identifier identifying a particular VPN;
reflecting the received VPN reachability information to all non-client peer nodes connected to the route reflector;
reflecting the received VPN reachability information to all non-solicit-capable client peer nodes connected to the route reflector; and reflecting the received VPN reachability information to only those solicit-capable peer nodes connected to the route reflector which are currently participating in the particular VPN.
receiving VPN reachability information from particular client peer node connected to the route reflector, the VPN reachability information including a VPN identifier identifying a particular VPN;
reflecting the received VPN reachability information to all non-client peer nodes connected to the route reflector;
reflecting the received VPN reachability information to all non-solicit-capable client peer nodes connected to the route reflector; and reflecting the received VPN reachability information to only those solicit-capable peer nodes connected to the route reflector which are currently participating in the particular VPN.
11. A method for operating a route reflector in a data network, comprising:
receiving VPN reachability information from a non-client peer node connected to the route reflector, the VPN reachability information including a VPN identifier identifying a particular VPN;
reflecting the received VPN reachability information to all non-solicit-capable client peer nodes connected to the route reflector; and reflecting the received VPN reachability information to only those solicit-capable peer nodes connected to the route reflector which are currently participating in the particular VPN.
receiving VPN reachability information from a non-client peer node connected to the route reflector, the VPN reachability information including a VPN identifier identifying a particular VPN;
reflecting the received VPN reachability information to all non-solicit-capable client peer nodes connected to the route reflector; and reflecting the received VPN reachability information to only those solicit-capable peer nodes connected to the route reflector which are currently participating in the particular VPN.
12. A method for operating a route reflector in a data network, comprising:
receiving VPN reachability information from an external peer node connected to the route reflector, the VPN reachability information including a VPN identifier identifying a particular VPN;
reflecting the received VPN reachability information to all non-client peer nodes connected to the route reflector;
reflecting the received VPN reachability information to all non-solicit-capable client peer nodes connected to the route reflector; and reflecting the received VPN reachability information to only those solicit-capable peer nodes connected to the route reflector which are currently participating in the particular VPN.
receiving VPN reachability information from an external peer node connected to the route reflector, the VPN reachability information including a VPN identifier identifying a particular VPN;
reflecting the received VPN reachability information to all non-client peer nodes connected to the route reflector;
reflecting the received VPN reachability information to all non-solicit-capable client peer nodes connected to the route reflector; and reflecting the received VPN reachability information to only those solicit-capable peer nodes connected to the route reflector which are currently participating in the particular VPN.
13. A method for distributing VPN reachability information in a data network, comprising:
maintaining at a node of the data network a VPN
send list for each VPN in which the node currently participates, the VPN send list for a particular VPN
identifying peer nodes of the node which also participate in that particular VPN; and upon receipt of VPN reachability information for the particular VPN, transmitting that VPN information only to peer nodes on the VPN send list for the particular VPN.
maintaining at a node of the data network a VPN
send list for each VPN in which the node currently participates, the VPN send list for a particular VPN
identifying peer nodes of the node which also participate in that particular VPN; and upon receipt of VPN reachability information for the particular VPN, transmitting that VPN information only to peer nodes on the VPN send list for the particular VPN.
14. A method as defined in claim 13, further comprising:
receiving VPN reachability information for a particular VPN at the node from a peer node; and adding that peer node to the VPN send list for the particular VPN if that peer node is not already on the VPN send list for the particular VPN.
receiving VPN reachability information for a particular VPN at the node from a peer node; and adding that peer node to the VPN send list for the particular VPN if that peer node is not already on the VPN send list for the particular VPN.
15. A method as defined in claim 13, further comprising:
receiving a VPN withdraw message for particular equipment registered on a particular VPN at the node from a peer node; and deleting the peer node from the VPN send list for the particular VPN if the peer node has no other equipment currently registered for participation in the particular VPN.
receiving a VPN withdraw message for particular equipment registered on a particular VPN at the node from a peer node; and deleting the peer node from the VPN send list for the particular VPN if the peer node has no other equipment currently registered for participation in the particular VPN.
16. A method as defined in claim 13, further comprising:
receiving a VPN disconnect request for a particular VPN at the node from equipment connected to the PE node; and deleting the VPN send list for the particular VPN
if the node has no other equipment currently registered for participation in the particular VPN.
receiving a VPN disconnect request for a particular VPN at the node from equipment connected to the PE node; and deleting the VPN send list for the particular VPN
if the node has no other equipment currently registered for participation in the particular VPN.
17. A data network, comprising a plurality of nodes, each node comprising:
means for transmitting a VPN reachability information request to another node of the data network, the VPN reachability information request comprising a VPN
identifier;
means for receiving a VPN reachability information request from another node of the data network;
means for retrieving VPN reachability information associated with a VPN identifier in a received VPN
reachability information request;
means for transmitting retrieved VPN reachability information to another node of the data network; and means for receiving VPN reachability information from another node of the data network.
means for transmitting a VPN reachability information request to another node of the data network, the VPN reachability information request comprising a VPN
identifier;
means for receiving a VPN reachability information request from another node of the data network;
means for retrieving VPN reachability information associated with a VPN identifier in a received VPN
reachability information request;
means for transmitting retrieved VPN reachability information to another node of the data network; and means for receiving VPN reachability information from another node of the data network.
18. A node for a data network, comprising:
means for transmitting a VPN reachability information request, the VPN reachability information request comprising a VPN identifier; and means for receiving VPN reachability information.
means for transmitting a VPN reachability information request, the VPN reachability information request comprising a VPN identifier; and means for receiving VPN reachability information.
19. A node as defined in claim 18, further comprising:
means for receiving VPN reachability information supplied by the requesting node; and means for transmitting the received VPN
reachability information.
means for receiving VPN reachability information supplied by the requesting node; and means for transmitting the received VPN
reachability information.
20. A node as defined in claim 18, further comprising:
means for storing at the node VPN reachability information received from a solicitation-capable node only if the VPN reachability information is associated with a VPN in which the node is participating; and means for storing at the node all VPN
reachability information received from a non-solicitation-capable node.
means for storing at the node VPN reachability information received from a solicitation-capable node only if the VPN reachability information is associated with a VPN in which the node is participating; and means for storing at the node all VPN
reachability information received from a non-solicitation-capable node.
21. A node as defined in claim 18, further comprising:
means for transmitting a VPN withdraw message from the node when equipment connected to the node ceases participation in a particular VPN, the VPN withdraw message comprising a VPN identifier identifying the particular VPN.
means for transmitting a VPN withdraw message from the node when equipment connected to the node ceases participation in a particular VPN, the VPN withdraw message comprising a VPN identifier identifying the particular VPN.
22. A node of a data network, comprising:
means for receiving a VPN reachability information request, the VPN reachability information request comprising a VPN identifier;
means for retrieving VPN reachability information associated with the VPN identifier; and means for transmitting retrieved VPN reachability information.
means for receiving a VPN reachability information request, the VPN reachability information request comprising a VPN identifier;
means for retrieving VPN reachability information associated with the VPN identifier; and means for transmitting retrieved VPN reachability information.
23. A node as defined in claim 22, further comprising:
means for transmitting VPN reachability information received with the VPN reachability information request to customer premises equipment connected to the node and participating in a VPN associated with the VPN
identifier of the VPN reachability information request.
means for transmitting VPN reachability information received with the VPN reachability information request to customer premises equipment connected to the node and participating in a VPN associated with the VPN
identifier of the VPN reachability information request.
24. A node as defined in claim 22, further comprising:
means for receiving a VPN withdraw message from another node; and means for deleting stored VPN reachability information specified in the VPN withdraw message.
means for receiving a VPN withdraw message from another node; and means for deleting stored VPN reachability information specified in the VPN withdraw message.
25. A route reflector for a data network, comprising:
means for receiving VPN reachability information from particular client peer node connected to the route reflector, the VPN reachability information including a VPN identifier identifying a particular VPN;
means for reflecting the received VPN
reachability information to all non-client peer nodes connected to the route reflector;
means for reflecting the received VPN
reachability information to all non-solicit-capable client peer nodes connected to the route reflector; and means for reflecting the received VPN
reachability information to only those solicit-capable peer nodes connected to the route reflector which are currently participating in the particular VPN.
means for receiving VPN reachability information from particular client peer node connected to the route reflector, the VPN reachability information including a VPN identifier identifying a particular VPN;
means for reflecting the received VPN
reachability information to all non-client peer nodes connected to the route reflector;
means for reflecting the received VPN
reachability information to all non-solicit-capable client peer nodes connected to the route reflector; and means for reflecting the received VPN
reachability information to only those solicit-capable peer nodes connected to the route reflector which are currently participating in the particular VPN.
26. A route reflector for a data network, comprising:
means for receiving VPN reachability information from a non-client peer node connected to the route reflector, the VPN reachability information including a VPN identifier identifying a particular VPN;
means for reflecting the received VPN
reachability information to all non-solicit-capable client peer nodes connected to the route reflector; and means for reflecting the received VPN
reachability information to only those solicit-capable peer nodes connected to the route reflector which are currently participating in the particular VPN.
means for receiving VPN reachability information from a non-client peer node connected to the route reflector, the VPN reachability information including a VPN identifier identifying a particular VPN;
means for reflecting the received VPN
reachability information to all non-solicit-capable client peer nodes connected to the route reflector; and means for reflecting the received VPN
reachability information to only those solicit-capable peer nodes connected to the route reflector which are currently participating in the particular VPN.
27. A route reflector for a data network, comprising:
means for receiving VPN reachability information from an external peer node connected to the route reflector, the VPN reachability information including a VPN identifier identifying a particular VPN;
means for reflecting the received VPN
reachability information to all non-client peer nodes connected to the route reflector;
means for reflecting the received VPN
reachability information to all non-solicit-capable client peer nodes connected to the route reflector; and means for reflecting the received VPN
reachability information to only those solicit-capable peer nodes connected to the route reflector which are currently participating in the particular VPN.
means for receiving VPN reachability information from an external peer node connected to the route reflector, the VPN reachability information including a VPN identifier identifying a particular VPN;
means for reflecting the received VPN
reachability information to all non-client peer nodes connected to the route reflector;
means for reflecting the received VPN
reachability information to all non-solicit-capable client peer nodes connected to the route reflector; and means for reflecting the received VPN
reachability information to only those solicit-capable peer nodes connected to the route reflector which are currently participating in the particular VPN.
28. A node for a data network, comprising:
means for maintaining a VPN send list for each VPN in which the node currently participates, the VPN send list for a particular VPN identifying peer nodes of the node which also participate in that particular VPN; and means for transmitting that VPN information only to peer nodes on the VPN send list for the particular VPN
upon receipt of VPN reachability information for the particular VPN.
means for maintaining a VPN send list for each VPN in which the node currently participates, the VPN send list for a particular VPN identifying peer nodes of the node which also participate in that particular VPN; and means for transmitting that VPN information only to peer nodes on the VPN send list for the particular VPN
upon receipt of VPN reachability information for the particular VPN.
29. A node as defined in claim 28, further comprising:
means for receiving VPN reachability information for a particular VPN from a peer node; and means for adding that peer node to the VPN send list for the particular VPN if that peer node is not already on the VPN send list for the particular VPN.
means for receiving VPN reachability information for a particular VPN from a peer node; and means for adding that peer node to the VPN send list for the particular VPN if that peer node is not already on the VPN send list for the particular VPN.
30. A node as defined in claim 28, further comprising:
receiving a VPN withdraw message for particular equipment registered on a particular VPN at the PE node from a peer node; and deleting the peer node from the VPN send list for the particular VPN if the peer node has no other equipment currently registered for participation in the particular VPN.
receiving a VPN withdraw message for particular equipment registered on a particular VPN at the PE node from a peer node; and deleting the peer node from the VPN send list for the particular VPN if the peer node has no other equipment currently registered for participation in the particular VPN.
31. A node as defined in claim 28, further comprising:
means for receiving a VPN disconnect request for a particular VPN from equipment connected to the node; and means for deleting the VPN send list for the particular VPN if the node has no other equipment currently registered for participation in the particular VPN.
means for receiving a VPN disconnect request for a particular VPN from equipment connected to the node; and means for deleting the VPN send list for the particular VPN if the node has no other equipment currently registered for participation in the particular VPN.
Priority Applications (6)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CA002254813A CA2254813A1 (en) | 1998-11-18 | 1998-11-18 | Distribution of reachability information in data virtual private networks |
| CA 2290055 CA2290055C (en) | 1998-11-18 | 1999-11-17 | Distribution of reachability information in data virtual private networks |
| US09/441,367 US6813644B1 (en) | 1998-11-18 | 1999-11-17 | Distribution of reachability information in data virtual private networks |
| US10/978,909 US7415534B2 (en) | 1998-11-18 | 2004-11-01 | Distribution of reachability information in data virtual private networks |
| US10/978,684 US7296090B2 (en) | 1998-11-18 | 2004-11-01 | Distribution of reachability information in data virtual private networks |
| US11/974,674 US7698464B2 (en) | 1998-11-18 | 2007-10-15 | Distribution of reachability information in data virtual private networks |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CA002254813A CA2254813A1 (en) | 1998-11-18 | 1998-11-18 | Distribution of reachability information in data virtual private networks |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CA2254813A1 true CA2254813A1 (en) | 2000-05-18 |
Family
ID=29425743
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CA002254813A Abandoned CA2254813A1 (en) | 1998-11-18 | 1998-11-18 | Distribution of reachability information in data virtual private networks |
Country Status (2)
| Country | Link |
|---|---|
| US (4) | US6813644B1 (en) |
| CA (1) | CA2254813A1 (en) |
Families Citing this family (38)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US7274704B1 (en) * | 2000-07-14 | 2007-09-25 | Nortel Networks Limited | Piggybacking VPN information in BGP for network based VPN architectures |
| US8670446B2 (en) * | 2001-01-30 | 2014-03-11 | At&T Intellectual Property Ii, L.P. | Technique for Ethernet access to packet-based services |
| US7092389B2 (en) | 2001-01-30 | 2006-08-15 | At&T Corp. | Technique for ethernet access to packet-based services |
| US7120150B2 (en) * | 2001-01-30 | 2006-10-10 | At & T Corp. | Technique for ethernet access to packet-based services |
| US20020184388A1 (en) * | 2001-06-01 | 2002-12-05 | Nimer Yaseen | Layered approach to virtual private routing |
| US7152115B2 (en) * | 2001-07-12 | 2006-12-19 | Nortel Networks Limited | Virtual private networks |
| US20040034702A1 (en) * | 2002-08-16 | 2004-02-19 | Nortel Networks Limited | Method and apparatus for exchanging intra-domain routing information between VPN sites |
| JP4157409B2 (en) * | 2003-03-31 | 2008-10-01 | 富士通株式会社 | Virtual path construction apparatus and virtual path construction method |
| EP1517482A1 (en) * | 2003-09-18 | 2005-03-23 | Hewlett-Packard Development Company, L.P. | Discovery of virtual private networks |
| US20050074003A1 (en) * | 2003-10-02 | 2005-04-07 | Ball David Alexander | Distributed software architecture for implementing BGP |
| US7787396B1 (en) * | 2004-05-27 | 2010-08-31 | Cisco Technology, Inc. | Automatic ORF-list creation for route partitioning across BGP route reflectors |
| US8160076B1 (en) | 2004-08-30 | 2012-04-17 | Juniper Networks, Inc. | Auto-discovery of multicast virtual private networks |
| US7590119B2 (en) * | 2005-01-27 | 2009-09-15 | Cisco Technology, Inc. | Method and apparatus for context-based prefix updates in border gateway protocol |
| JP4282620B2 (en) * | 2005-02-28 | 2009-06-24 | 株式会社東芝 | Communication device, router device, communication method, and communication program |
| US7599313B2 (en) * | 2005-04-28 | 2009-10-06 | Cisco Technology, Inc. | Method to scale hierarchical route reflectors using automated outbound route filtering-list mechanism |
| US7769017B2 (en) * | 2005-07-26 | 2010-08-03 | Nortel Networks Limited | Using reachability information to facilitate peer-to-peer communications |
| US7668178B2 (en) * | 2005-08-30 | 2010-02-23 | Cisco Technology, Inc. | Methods and apparatus for implementing VPN services |
| US7554996B2 (en) * | 2005-09-14 | 2009-06-30 | Cisco Technology, Inc. | Controlled distribution of inter-area routing information |
| US7756072B1 (en) * | 2005-12-30 | 2010-07-13 | At&T Intellectual Property Ii, L.P. | System and method for passively monitoring customer control messages in a multicast VPN |
| US7742482B1 (en) | 2006-06-30 | 2010-06-22 | Juniper Networks, Inc. | Upstream label assignment for the resource reservation protocol with traffic engineering |
| US7839862B1 (en) | 2006-06-30 | 2010-11-23 | Juniper Networks, Inc. | Upstream label assignment for the label distribution protocol |
| US7787380B1 (en) | 2006-06-30 | 2010-08-31 | Juniper Networks, Inc. | Resource reservation protocol with traffic engineering point to multi-point label switched path hierarchy |
| WO2008055245A2 (en) | 2006-10-31 | 2008-05-08 | Sensient Colors Inc. | Inks comprising modified pigments and methods for making and using the same |
| KR101575913B1 (en) | 2007-08-23 | 2015-12-08 | 센션트 컬러스 인크. | Self-dispersed pigments and methods for making and using the same |
| US8396988B2 (en) * | 2007-12-19 | 2013-03-12 | At&T Intellectual Property I, L.P. | Method and system for survival of data plane through a total control plane failure |
| CN101350760B (en) * | 2008-08-15 | 2011-05-11 | 中兴通讯股份有限公司 | Method for forwarding data packet of virtual private network |
| CN102858886A (en) | 2009-04-07 | 2013-01-02 | 森馨颜色有限责任公司 | Self-dispersing particles and methods for making and using the same |
| US8644315B2 (en) * | 2009-06-04 | 2014-02-04 | Cisco Technology, Inc. | Label distribution protocol label filtering |
| EP2556628A4 (en) * | 2010-04-07 | 2014-12-17 | Hewlett Packard Development Co | System and method for automated discovery of customer-edge devices and interface connections in a virtual-private-networking environment |
| US8787394B2 (en) * | 2011-02-01 | 2014-07-22 | Ciena Corporation | Separate ethernet forwarding and control plane systems and methods with interior gateway route reflector for a link state routing system |
| CN103259726B (en) * | 2012-02-21 | 2017-04-12 | 华为技术有限公司 | Method, device and system for storing and sending MAC address table entries |
| US9438564B1 (en) * | 2012-09-18 | 2016-09-06 | Google Inc. | Managing pooled VPN proxy servers by a central server |
| WO2014082656A1 (en) * | 2012-11-27 | 2014-06-05 | Telefonaktiebolaget L M Ericsson (Publ) | Methods and routers for connectivity setup between provider edge routers |
| US8953500B1 (en) | 2013-03-29 | 2015-02-10 | Juniper Networks, Inc. | Branch node-initiated point to multi-point label switched path signaling with centralized path computation |
| US9722910B2 (en) | 2015-03-24 | 2017-08-01 | Cisco Technology, Inc. | Transit domain control |
| CN109412951B (en) | 2018-10-12 | 2021-06-22 | 华为技术有限公司 | Method and device for sending routing information |
| WO2020081830A1 (en) * | 2018-10-19 | 2020-04-23 | Futurewei Technologies, Inc. | Border gateway protocol (bgp) for routing policy distribution |
| US11374907B2 (en) * | 2020-08-27 | 2022-06-28 | Sedonasys Systems Ltd | Highly available software defined wide area network |
Family Cites Families (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US6339595B1 (en) * | 1997-12-23 | 2002-01-15 | Cisco Technology, Inc. | Peer-model support for virtual private networks with potentially overlapping addresses |
| US6516417B1 (en) * | 1998-08-07 | 2003-02-04 | Nortel Networks, Limited | Virtual private networks |
| US6205488B1 (en) * | 1998-11-13 | 2001-03-20 | Nortel Networks Limited | Internet protocol virtual private network realization using multi-protocol label switching tunnels |
| US6493349B1 (en) * | 1998-11-13 | 2002-12-10 | Nortel Networks Limited | Extended internet protocol virtual private network architectures |
-
1998
- 1998-11-18 CA CA002254813A patent/CA2254813A1/en not_active Abandoned
-
1999
- 1999-11-17 US US09/441,367 patent/US6813644B1/en not_active Expired - Lifetime
-
2004
- 2004-11-01 US US10/978,684 patent/US7296090B2/en not_active Expired - Fee Related
- 2004-11-01 US US10/978,909 patent/US7415534B2/en not_active Expired - Lifetime
-
2007
- 2007-10-15 US US11/974,674 patent/US7698464B2/en not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| US7698464B2 (en) | 2010-04-13 |
| US7296090B2 (en) | 2007-11-13 |
| US20080155121A1 (en) | 2008-06-26 |
| US6813644B1 (en) | 2004-11-02 |
| US20050177636A1 (en) | 2005-08-11 |
| US20050129015A1 (en) | 2005-06-16 |
| US7415534B2 (en) | 2008-08-19 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CA2254813A1 (en) | Distribution of reachability information in data virtual private networks | |
| EP1832056B1 (en) | Automatic route tagging of bgp next-hop routes in igp | |
| JP4231766B2 (en) | A communication apparatus and a communication method for performing path control between ASs. | |
| US6526056B1 (en) | Virtual private network employing tag-implemented egress-channel selection | |
| US8391303B2 (en) | Border gateway protocol (BGP) grouped route withdrawals | |
| US7675912B1 (en) | Method and apparatus for border gateway protocol (BGP) auto discovery | |
| US7953103B2 (en) | Multi-homing using controlled route leakage at a backup service provider | |
| US7983153B2 (en) | Fast reroute (FRR) protection at the edge of a RFC 2547 network | |
| US20150381482A1 (en) | Splitting and sharing routing information among several routers acting as a single border router | |
| US7590074B1 (en) | Method and apparatus for obtaining routing information on demand in a virtual private network | |
| JP2008079175A (en) | Frame transfer system | |
| EP1063814A1 (en) | A method to forward a multicast packet | |
| WO2005034440A1 (en) | Router selecting method and router apparatus | |
| Traina | Experience with the BGP-4 Protocol | |
| US20210250275A1 (en) | System and Method for Implementing Controller Border Gateway Protocol (cBGP) | |
| CN102271080A (en) | Method for preventing BGP (Border Gateway Protocol) session from being disconnected in the event of changing service, and applicable system thereof | |
| Uttaro et al. | Best Practices for Advertisement of Multiple Paths in IBGP | |
| JP2000341294A (en) | Packet repeater | |
| Ballardie et al. | Core Based Tree (CBT) Multicast | |
| KR100693043B1 (en) | Multicast system and the method in DiffServ for using encapsulation and Unicast routing | |
| Braden et al. | Internet architecture extensions for shared media | |
| Cisco | BGP Commands: neighbor peer-group (creating) Through timers bgp | |
| CA2290055C (en) | Distribution of reachability information in data virtual private networks | |
| Minei et al. | Scalability considerations in bgp/mpls ip vpns | |
| KR20050098950A (en) | Method for interconnecting virtual private networks in non-connected mode |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| EEER | Examination request | ||
| FZDE | Discontinued |