US20060190573A1 - Method and apparatus for multiple contexts and layer 3 virtual private networks - Google Patents

Method and apparatus for multiple contexts and layer 3 virtual private networks Download PDF

Info

Publication number
US20060190573A1
US20060190573A1 US11409193 US40919306A US2006190573A1 US 20060190573 A1 US20060190573 A1 US 20060190573A1 US 11409193 US11409193 US 11409193 US 40919306 A US40919306 A US 40919306A US 2006190573 A1 US2006190573 A1 US 2006190573A1
Authority
US
Grant status
Application
Patent type
Prior art keywords
vpn
layer
egp
network element
table
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
Application number
US11409193
Inventor
Ravi Chandra
Enke Chen
Jenny Yuan
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Ericsson AB
Original Assignee
Ravi Chandra
Enke Chen
Jenny Yuan
Priority date (The priority date 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 date listed.)
Filing date
Publication date

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/02Network architectures or network communication protocols for network security for separating internal from external traffic, e.g. firewalls
    • H04L63/0272Virtual private networks
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/16Implementing security features at a particular protocol layer
    • H04L63/166Implementing security features at a particular protocol layer at the transport layer
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/16Implementing security features at a particular protocol layer
    • H04L63/164Implementing security features at a particular protocol layer at the network layer

Abstract

A method an apparatus for multiple contexts and layer 3 virtual private networks is described. A method comprises providing a layer 3 virtual private network (VPN) to a first customer; providing backbone access to a second customer; and maintaining on a single network element a first set of information for the first customer separately from a second set of information for the second customer.

Description

    RELATED APPLICATIONS
  • This patent application is a divisional patent application of U.S. patent application Ser. No. 09/991,234, filed Nov. 17, 2001 (Attorney Docket No. 4906.P094), now pending.
  • FIELD OF THE INVENTION
  • The invention relates to the field of communication. More specifically, the invention relates to communication networks.
  • BACKGROUND OF THE INVENTION
  • Virtual Private Networks (VPNs) extend an entity's (e.g., a corporation, Internet Service Provider (ISP), etc.) network backbone out to the Internet. The connectivity costs for VPNs are less than leasing a line, and fault tolerance is improved because of multiple pathways between sites. Instead of an entity purchasing, administrating and maintaining additional network elements (e.g. routers, hubs, switches, subscriber management systems, etc.), an entity can securely transmit traffic through the Internet with VPNs.
  • BRIEF DESCRIPTION OF THE DRAWINGS
  • The invention may best be understood by referring to the following description and accompanying drawings that are used to illustrate embodiments of the invention. In the drawings:
  • FIG. 1 is a diagram of an exemplary network according to one embodiment of the invention.
  • FIG. 2A is a diagram of an exemplary network element that supports multiple contexts and layer 3 VPNs according to one embodiment of the invention.
  • FIG. 2B is a diagram of the exemplary network element 105 illustrating a relationship between network processes and the structures and tables illustrated in FIG. 2A according to one embodiment of the invention.
  • FIG. 2C is a diagram of the layer 3 VPN EGP table 215 as a tree according to one embodiment of the invention.
  • FIG. 2D is a diagram of the layer 3 VPN EGP table 215 as a tree with RD substructures according to one embodiment of the invention.
  • FIG. 2E is a diagram illustrating an alternative embodiment of the layer 3 VPN EGP table 215 as a hash table according to one embodiment of the invention.
  • FIG. 3A is a flow chart for processing an update message received from customer with RD substructures equipment according to one embodiment of the invention.
  • FIG. 3B is a flow chart continuing from the flow chart of FIG. 3A according to one embodiment of the invention.
  • FIG. 4A is a flow chart for processing an update message received from customer equipment according to one embodiment of the invention.
  • FIG. 4B is a flow chart continuing from the flow chart illustrated in FIG. 4A according to one embodiment of the invention.
  • FIG. 5 is flow chart for processing an update message received from a provider equipment according to one embodiment of the invention.
  • FIG. 6 is a flow chart for generating an update message for customer equipment according to one embodiment of the invention.
  • FIG. 7 is a flow chart for generating an update message for a provider equipment according to one embodiment of the invention.
  • FIG. 8 is a block diagram illustrating the exemplary network element 105 according to one embodiment of the invention.
  • DETAILED DESCRIPTION OF THE INVENTION
  • In the following description, numerous specific details are set forth to provide a thorough understanding of the invention. However, it is understood that the invention may be practiced without these specific details. In other instances, well-known circuits, structures, standards, and techniques have not been shown in detail in order not to obscure the invention.
  • FIG. 1 is a diagram of an exemplary network according to one embodiment of the invention. In FIG. 1, a virtual private network (VPN) A includes a VPN A customer equipment 101A and a VPN A customer equipment 103A. A VPN B includes a VPN B customer equipment 101B and a VPN B customer equipment 103B. The VPN A customer equipment 101A and the VPN B customer equipment 103A are located within an autonomous system (AS) 102 in FIG. 1, but could be located in different ASs. The VPN A customer equipment 101A and the VPN B customer equipment 103A are coupled with a network element 105. The network element 105 is also coupled with a non-VPN customer equipment 106 that is located within an AS 104. The network element 105 is located in an AS that is a backbone 111.
  • A network element 115 is also located within the backbone 111. The network element 115 is coupled with the VPN B customer equipment 103B. A network element 114, also located in the backbone 111, is coupled with the VPN A customer equipment 101B. The VPN B customer equipment 103B and the VPN A customer equipment 101B are respectively located within an AS 106 and an AS 108.
  • The network element 105 includes a context 107A and VPN contexts 109A-109B. The term context is used herein to refer to a set of information and/or collection of data structures for a customer of a network provider's network element. In the exemplary network illustrated in FIG. 1, the VPN A customer equipment 101A, the VPN B customer equipment 103A, and the non-VPN customer equipment 106 gain access to the backbone 111 via the network element 105. In FIG. 1, the context 107A has been created by the network provider that owns the network element 105 for the non-VPN customer. The context 109A has been created by the network provider for the VPN A customer. The context 109B has been created by the network provider for the VPN B customer.
  • From the perspective of the network element 105, a customer is an entity that corresponds to a single context within the network element. However, a single entity may correspond to multiple contexts. A single entity may have multiple VPN contexts configured on the network element 105 and a context configured on the network element 105. For example, one entity may own and/or operate the non-VPN customer equipment 106, the VPN A customer equipment 101A, and the VPN B customer equipment 103A. In another example, a first entity owns and/or operates the VPN B customer equipment 103A and a second entity owns the VPN A customer equipment 101A and the non-VPN customer equipment 106. In yet another example, a first entity owns the VPN A customer equipment 101A and the VPN B customer equipment 103A, while a second entity owns and/or operates the non-VPN customer equipment 106
  • The VPN context 109A includes information and/or data structures for the VPN A. Traffic received from the VPN A site 101A is processed in accordance with the VPN context 109A. The VPN context 109B includes information and/or data structures for the VPN B. Traffic received from the VPN B site 103A is processed in accordance with the VPN context 109B. Traffic is transmitted between the VPN A sites 101A and 101B in accordance with the VPN context 109A. Traffic is transmitted between the VPN B sites 103A and 103B in accordance with the VPN context 109B. Traffic received from the service provider network element 106 is processed in accordance with the context 107A.
  • Contexts enable isolation of traffic processed by the network element. Contexts also provide the network provider with the ability to give access to a given customer's information while restricting access to other information within the network element (e.g., a different customer's information). The context 107A includes a set of information for the service provider that owns the service provider network element 106. The owner of the service provider may be an Internet Service Provider (ISP), Application Service Provider (ASP), etc. in one embodiment, a network administrator for the service provider that owns the service provider network element 106 may log into the network element 105 and access and modify the context 107A, if permitted by the owner of the network element 105. The network element 105 may include additional contexts not illustrated.
  • Implementing VPNs at layer 3 provides numerous advantages. Layer 3 VPNs provide vast scalability and avoids administrative costs of tunnel configurations for layer 2 VPNs. Combining layer 3 VPNs with multiple contexts provides a powerful tool for servicing various customers that may include VPN customers and non-VPN customers. A network element supporting multiple contexts and layer 3 VPNs can support a large number of VPN customer and non-VPN customers and provide each customer access to their context.
  • FIG. 2A is a diagram of an exemplary network element that supports multiple contexts and layer 3 VPNs according to one embodiment of the invention. FIG. 2 illustrates the network element 105 illustrated in FIG. 1. FIG. 2, also illustrates the context 107A and the VPN context 109A and 109B illustrated in FIG. 1. The context 107A includes a peer data structure 201A, a configuration data structure 203A, a routing table 205A, an interior gateway protocol (IGP) table 207A, and an exterior gateway protocol (EGP) table 209A. The term table is a conventional term and not meant to be limiting upon the type of data structure. A table can be implemented with different data structures such as a hash table, search tree, combinations of data structures, etc.
  • The peer structure 201A includes data describing a peer. A peer is another network element that exchanges routing information with the network element 105. A peer can either be an internal peer or an external peer. An internal peer is a network element directly connected to the network element 105 that is located within the same autonomous system as the network element 105. An autonomous system is a collection of network elements under a single administrative authority that routes traffic in accordance with a common IGP (e.g., OSPF, IS-IS, RIP, etc.). An external peer of the network element 105 is a network element that is directly connected to the network element 105, but is located in a different autonomous system. The peer structure 201A may include a peer's network address and configuration information providing guidelines for communications between the peer and the network element 105.
  • The configuration structure 203A includes configurations specifically for the context 107A. The configurations in the configuration structure 203A may be entered by a network administrator of the network element 105 or the administrator for the owner of the context 107A. The routing table 205A is a routing table specifically for the context 107A. The routing table 205A is used to process traffic transmitted and received for the context 107A. The IGP table 207A is a forwarding table specifically for the context 107A. The IGP table 207A may be an OSPF forwarding table, a RIP forwarding table, an ISIS forwarding table, etc. The exterior gateway protocol forwarding table 209A is a forwarding table with routes specifically for the context 107A maintained by an EGP process (e.g., BGP, etc.). As previously stated, the owner of the context 107A can be given permission by the owner of the network element 105 to view and manipulate information for the context 107A.
  • Since the number of entries in a table for a non-VPN customer is typically large, separation of tables for non-VPN customers provides for efficient maintenance of the non-VPN tables. Since the number of entries in a VPN table are typically fewer than the number of entries in VPN tables, sharing a single EGP table for multiple VPNs provides for efficient walking of the shared VPN tables as describe in more detail later herein.
  • Various embodiments of the invention may implement the EGP tables, IGP tables, and routing tables differently. For example, one embodiment may maintain a single EGP table for non-VPN contexts and a single EGP table for layer 3 VPN contexts. Another embodiment may maintain a single IGP table for VPN contexts.
  • The VPN context 109A includes a peer structure 201I, a configuration structure 203I, a routing table 205I, and an IGP table 207I. Similarly, the VPN context 109B includes a peer structure 201J, a configuration structure 203J, a routing table structure 205J, and an IGP table 207J. The information included in the structures 210I and 203I and the tables 205I and 207I are similar to the structures 201A and 203A and the tables 205A and 207A, but are specific to the VPN context 109A. Likewise, the structures 201J and 203J and the tables 205J and 207J are specific to the VPN context 109B. As previously stated, the owners of the VPN context 109A and 109B can respectively access and configure the structures and tables in the VPN contexts 109A and 109B. Unlike the context 107A, the VPN contexts 109A and 109B do not have specific EGP tables. Instead, the VPN contexts 109A and 109B share a layer 3 VPN EGP table 215. The layer 3 VPN EGP table 215 includes EGP forwarding information for all VPN contexts in the network element 105.
  • In addition to the context 107A and the VPN contexts 109A and 109B, in one embodiment the network element 105 includes a local context 211. A peer structure 201X, a configuration structure 203X, a routing table 205X, an IGP table 207X, and an EGP table 209X contain information for the local context 211. The information included in the structure 201X and the tables 205X, 207X, and 209X is similar to the information included in the structure 201A and the tables 205A, 207A, and 209A, but is specific to the local context 211. The configuration structure 203X includes global configuration information (e.g., system time). Unlike the context 107A and the VPN contexts 109A and 109B, in one embodiment the owner of the local context 211, who is the owner of the network element 105, has access to many of the structures and tables of the contexts on the network element 105.
  • FIG. 2B is a diagram of the exemplary network element 105 illustrating a relationship between network processes and the structures and tables illustrated in FIG. 2A according to one embodiment of the invention. In FIG. 2B, a configuration interface (CI) 221 feeds configuration information into a configuration process 223. The CI may be a command line interface or a graphical user interface for entering configurations and commands for the network element 105. The configuration process 223 stores the configurations into one of the configuration structures 203X, 203A, 203I, and 203J. The configuration structures 203X, 203A, 203I, and 203J are illustrated in FIG. 2B as referencing the peer structures 201X, 201A, 201I, and 201J. The relationships are illustrated as follows: the peer structure 201J and the configuration structure 203J; the peer structure 201I and the configuration structure 203I; the peer structure 201A and the configuration structure 203A; and the peer structure 201X and the configuration structure 203X.
  • The peer structures may be implemented in a variety of ways. In one embodiment, a single peer structure has entries for all peers configured on a given network element. In such an embodiment, each entry identifies a peer and its corresponding context. In another embodiment, each peer configured on the given network element is allocated a single peer structure. In another embodiment, a single peer structure is allocated for each context configured on the network element.
  • The configuration process 223 also sends configurations to an IGP process 225, a RIB process 229, and an EGP process 227. The IGP process 225 represents one or more IGP processes that may include the following protocols: RIP, OSPF, IS-IS, etc. The EGP process 227 also represents one or more processes that may include BGP and other exterior gateway protocols. The IGP process 225 maintains the IGP tables 207X, 207A, 207I, and 207J. The RIB process 229 maintains the routing tables 205X, 205A, 205I, and 205J. The EGP process 227 maintains the EGP table 209X, 209A, the layer 3 VPN EGP table 215, and a mapping structure 226.
  • In an embodiment that provides for a single non-VPN EGP table and a single VPN EGP table, an identifier (e.g., context ID) is included in each entry of the single non-VPN EGP table. In another embodiment that provides for single non-VPN EGP table and a single VPN EGP table, each entry of the non-VPN EGP table indicates an identifier (e.g., context ID) and references a set of prefixes corresponding to the identifier.
  • The mapping structure 226 is a data structure that includes VPN context IDs and their corresponding RD. The mapping structure 226 may be implemented as a tree, hash table, linked list, etc. When the IGP process 225 downloads updates of one of the IGP tables, such as the IGP table 207X, the IGP process 225 passes the context ID indicated in the IGP table 207X to the RIB process 229. The EGP process 227 does the same for non-VPN EGP tables. However, the layer 3 VPN EGP table 215 does not correspond to a single context. Therefore, the EGP process 227 uses the mapping structure 226 to communicate with other processes in the network element 105 for communications related to VPN contexts. Communications with other processes may include passing updates to the RIB process 229, performing requests from the configuration process 223, etc.
  • Sharing a single EGP table for all of the VPN contexts of a network element improves the efficiency of update message generation for the network element supporting multiple contexts and layer 3 VPNs. Since the number of entries for an individual VPN customer is relatively small, combining entries for all layer 3 VPN customers into a single EGP table enables an EGP process to efficiently walk the combined data structure instead of numerous small EGP tables. In addition, a mapping structure enables efficient maintenance of the combined EGP table without extensive memory consumption.
  • FIG. 2C is a diagram of the layer 3 VPN EGP table 215 as a tree according to one embodiment of the invention. In FIG. 2C, the layer 3 VPN EGP table is implemented as a tree. Each of the nodes 241, 243, 245, 247, and 249 are labeled with the value RD:prefix. The mapping structure 226 is also illustrated in FIG. 2C. The EGP process 227 uses the mapping structure 226 as previously discussed to send and receive communication regarding the layer 3 VPN EGP table 215. If the EGP process 227 receives a communication affecting the layer 3 VPN EGP table 215, then the EGP process 227 maps the VPN-context ID indicated in the communication to a RD with the mapping structure 216. Maintaining the mapping structure 226 avoids including a VPN context ID in every node.
  • FIG. 2D is a diagram of the layer 3 VPN EGP table 215 as a tree with RD substructures according to one embodiment of the invention. Unlike the layer 3 VPN EGP table 215 illustrated in FIG. 2C, the right branch of the root node 241 references a node 251. Instead of RD:prefix, the node 251 is labeled with the route distinguisher. In addition to typical left and right branches of a tree, the node 251 references an RD substructure 257. The RD substructure 257 is a data structure that indicates prefixes corresponding to the RD identified in the node 251. A node 253 is similar to the node 251 in that it is only identified by the value RD instead of the value RD:prefix. The node 253 references an RD substructure 259. The RD substructure 259 includes prefixes corresponding to the RD identified in the node 253. The embodiment of the layer 3 VPN EGP table 215 further improves memory use. The embodiment illustrated in FIG. 2D reduces the number of nodes in the layer 3 VPN EGP table 215 with the route distinguisher value (currently defined as an 8 byte value), and group prefixes by route distinguisher. In addition, the EGP process 227 may group updates to be transmitted by RD as it encounters each node of the layer 3 VPN EGP table 215.
  • FIG. 2E is a diagram illustrating an alternative embodiment of the layer 3 VPN EGP table 215 as a hash table according to one embodiment of the invention. Each entry of the hash table 270 indicates a route distinguisher. Each entry of the hash table 260 references an RD substructure 271 or 273. As with the layer 3 VPN EGP table illustrated in FIG. 2D, the EGP process 227 may group updates by mapped VPN context ID as it walks through the hash table 260.
  • As illustrated in FIGS. 2C-2E, various embodiments of the invention may implement the layer 3 VPN EGP table 215 with different data structures and/or combinations of data structures.
  • FIG. 3A is a flow chart for processing an update message received from customer with RD substructures equipment according to one embodiment of the invention. At block 301, the EGP process 227 selects a peer that is a customer equipment. At block 303, the EGP process 227 receives an update message from the selected peer. At block 305, the EGP process 227 selects a prefix from the received update message. At block 307, the EGP process 227 determines if the context associated with the selected peer is a VPN context. If the associated context is not a VPN context, then at block 309 the EGP process 227 determines if the selected prefix is in the EGP table of the context associated with the selected peer. If the EGP process 227 determines that the selected prefix is within the associated context's EGP table, then control flows to block 313. If the EGP process 227 determines that the selected prefix is not within the associated context's EGP table, then control flows to block 315.
  • If at block 309 the EGP process 227 determines that the context associated with the selected peer is a VPN context, then at block 317 the EGP process 227 maps the VPN context ID of the associated context to a route distinguisher (RD). At block 318 the EGP process 227 locates the RD in the layer 3 VPN EGP table 215. At block 319, the EGP process 227 determines if the selected prefix is in the located RD sub-structure. If the EGP process 227 determines that the selected prefix is within the RD sub-structure, then control flows to block 323. If the EGP process 227 determines that the selected prefix is not within the located RD sub-structure, then control flows to block 321.
  • FIG. 3B is a flow chart continuing from the flow chart of FIG. 3A according to one embodiment of the invention. At block 313, the EGP process 227 inserts the selected prefix into the selected context EGP table. At block 315, the EGP process 227 updates an entry matching the selected prefix of the associated context's EGP table in accordance with the update message. At block 321, the EGP process 227 inserts a selected prefix into the located RD substructure. At block 323, the EGP process 227 updates an entry matching the selected prefix within the located RD substructure in accordance with the update message.
  • FIG. 4A is a flow chart for processing an update message received from customer equipment according to one embodiment of the invention. At block 401, the EGP process 227 selects a peer that is a customer equipment. At block 403, the EGP process 227 receives an update message from the selected peer. At block 405, the EGP process 227 selects a prefix from the received update message. At block 407, the EGP process 227 determines if the context associated with the selected peer is a VPN context. If the associated context is not a VPN context, then at block 409 the EGP process 227 determines if the selected prefix is in the EGP table of the context associated with the selected peer. If the EGP process 227 determines that the selected prefix is within the associated context's EGP table, then control flows to block 415. If the EGP process 227 determines that the selected prefix is not within the associated context's EGP table, then control flows to block 413.
  • If at block 407, the EGP process 227 determines that the selected context is a VPN context, then at block 417 the EGP process 227 maps the VPN context ID of the associated context to a (RD). At block 419 the EGP process 227 determines if the RD:selected prefix is within the layer 3 VPN EGP table 215. If the RD:selected prefix is within the later 3 VPN EGP table, then control flows to block 423. If the RD:selected prefix is not within the layer 3 VPN EGP table, then control flows to block 421.
  • FIG. 4B is a flow chart continuing from the flow chart illustrated in FIG. 4A according to one embodiment of the invention. At block 421, the EGP process 227 inserts RD:selected prefix into the layer 3 VPN EGP table 215. At block 423, the network element updates an entry matching the selected prefix in the layer 3 VPN EGP table in accordance with the update message. At block 413, the EGP process 227 inserts the selected prefix into the associated context's EGP table. At block 415, the EGP process 227 updates an entry matching a selected prefix in the associated context's EGP table in accordance with the update message.
  • FIG. 5 is flow chart for processing an update message received from a provider equipment according to one embodiment of the invention. At block 501, the EGP process 227 selects a peer that is a customer equipment. At block 503, the EGP process 227 receives an update message from the selected peer. At block 505, the EGP process 227 selects a prefix from the received update message. At block 507, the EGP process 227 determines if the selected peer is configured for the VPN address family. If the selected peer is not configured for the VPN address family, then at block 509 the EGP process 227 determines if the selected prefix is in the EGP table of the context associated with the selected peer. If the EGP process 227 determines that the selected prefix is within the associated context's EGP table, then control flows to control flows to block 415 of FIG. 4B. If the EGP process 227 determines that the selected prefix is not within the associated context's EGP table, then control flows to block 413 of FIG. 4B.
  • If at block 507, the EGP process 227 determines that the selected peer is not configured for the VPN address family, then at block 511 the EGP process 227 determines if the selected prefix matches an entry in the layer 3 VPN EGP table 215. If the selected prefix does not match an entry in the VPN EGP table 215, then at block 515 the EGP process 227 inserts the select prefix into the layer 3 VPN EGP table 215. If the selected prefix matches an entry in the layer 3 VPN EGP table 215, then at block 513 the EGP process 227 updates the matching entry in accordance with the update message.
  • FIG. 6 is a flow chart for generating an update message for customer equipment according to one embodiment of the invention. At block 601, the EGP process 227 selects a peer. At block 603, the EGP process 227 determines if the context associated with the selected peer is a VPN context. If the associated context is not a VPN context, then at block 607, the EGP process 227 creates an update message(s) for the associated context's EGP table. If the EGP process 227 determines at block 603 that the associated context is a VPN context, then at block 609 the EGP process 227 maps the VPN context ID of the associated VPN context to an RD. At block 613, the EGP process 227 locates the RD in the VPN EGP table 215. At block 615, the EGP process 227 walks through the VPN EGP table and select entries matching the mapped RD. At block 617, the EGP process 227 creates an update message(s) with prefixes of selected entries without the RD.
  • FIG. 7 is a flow chart for generating an update message for a provider equipment according to one embodiment of the invention. At block 701, the EGP process 227 selects a peer. At block 703, the EGP process 227 determines if the selected peer is configured for the VPN address family. If the selected peer is not configured for the VPN address family, then the EGP process 227 creates an update message(s) with the associated context's EGP table at block 705. If the selected peer is not configured for the VPN address family, then the EGP process 227 walks through the layer 3 VPN EGP table 215 to create update message(s) at block 707.
  • While the flow diagrams in the Figures show a particular order of operations performed by certain embodiments of the invention, it should be understood that such order is exemplary (e.g., alternative embodiments may perform certain of the operations in a different order, combine certain of the operations, perform certain of the operations in parallel, etc.).
  • FIG. 8 is a block diagram illustrating the exemplary network element 105 according to one embodiment of the invention. In FIG. 8, a control card 801 hosts the local context 211, the VPN context 109A, the VPN context 109B, the context 107A, and the Layer 3 VPN EGP table 215, the configuration process 223, the IGP process 225, the EGP process 227, and the RIB process 229. In various embodiments of the invention, the local context 211, the VPN context 109A, the VPN context 109B, the context 107, and the Layer 3 VPN EGP table 215, the configuration process 223, the IGP process 225, the EGP process 227, and the RIB process 229 may be hosted on a co-processor, an ASIC, etc. In alternative embodiments, the structures and tables of the context 107A and VPN contexts 109A and 109B may be stored on a storage device and/or memory coupled with the control card 801.
  • The control card 801 is coupled with a transmission medium cloud 803 (e.g., a system bus, a mesh, a system bus and a mesh, etc.). The transmission medium cloud 803 is coupled with line cards 807A-807D. The line cards 807A-807D are coupled to physical interfaces 809A-809D respectively. The network element 105 receives updates messages and transmits update messages via the physical interfaces 805A-805D.
  • The control card 801 and the line cards 807A-807D illustrated in FIG. 8 includes memories, processors, and/or ASICs. Such memories include a machine-readable medium on which is stored a set of instructions (i.e., software) embodying any one, or all, of the methodologies described herein. Software can reside, completely or at least partially, within this memory and/or within the processor and/or ASICs. For the purpose of this specification, the term “machine-readable medium” shall be taken to include any mechanism that provides (i.e., stores and/or transmits) information in a form readable by a machine (e.g., a computer). For example, a machine-readable medium includes read only memory (“ROM”), random access memory (“RAM”), magnetic disk storage media, optical storage media, flash memory devices, electrical, optical, acoustical, or other form of propagated signals (e.g., carrier waves, infrared signals, digital signals, etc.), etc.
  • A network element supporting multiple contexts and layer 3 VPNs provides the owner of the network element the ability to support VPNs for multiple customers at a cost lower than the cost of layer 2 VPNs and more efficiently than without multiple contexts. The owner can provide customers access to their own context. Providing access to contexts can be offered as a service and shifts some administrative tasks from the network element owner to it's customers. Hence, the network element owner can provide layer 3 VPNs to multiple VPN customers (e.g. corporations, service providers, education institutions, etc.) and backbone access to non-VPN customers. The network element owner can serve this variety of customers from a single network element while offering administrative access to the network element through multiple contexts.
  • The method and apparatus of the invention can be practiced with modification and alteration within the spirit and scope of the appended claims. The description is thus to be regarded as illustrative instead of limiting on the invention.

Claims (10)

  1. 1. A network element comprising:
    a control card to host an exterior gateway protocol (EGP) process and an interior gateway protocol (IGP) process;
    a machine readable medium coupled with the control card, the machine readable medium having a set of instructions to
    cause the network element to maintain a first set of information for a first layer 3 virtual private network (VPN) and separately maintain a second set of information for a second layer 3 VPN,
    to maintain a single exterior gateway protocol (EGP) table for the first layer 3 VPN and the second layer 3 VPN,
    to identify the first layer 3 VPN with a first value and to identify the second layer 3 VPN with a second value, and
    to associate a first route distinguisher (RD) with the first value and a second RD with the second value;
    a line card coupled with the control card, the first line card to process traffic for the first layer 3 VPN and the second layer 3 VPN;
    a first interface coupled with the line card, the first interface to receive traffic for the first layer 3 VPN; and
    a second interface coupled with the line card, the second interface to receive traffic for the second layer 3 VPN.
  2. 2. The network element of claim 1 further comprising:
    a second line card coupled with the control card and the line card, the second line card to process traffic for the first layer 3 VPN; and
    a third interface coupled with the second line card, traffic for the first layer 3 VPN to be received through the third interface.
  3. 3. The network element of claim 1 wherein
    the set of instructions also cause the network element to maintain a data structure to performing mappings between the first value and the first RD and between the second value and the second RD.
  4. 4. The network element of claim 1 wherein
    the set of instructions also cause the network element to maintain a third set of information for a non-VPN customer separately from the first and second sets of information, the third set of information including a third value identifying the non-VPN customer and to maintain a second EGP table for the non-VPN customer.
  5. 5. A system comprising:
    a first piece of customer equipment to transmit and receive traffic within a first layer 3 virtual private network (VPN);
    a second piece of customer equipment to transmit and receive traffic within a second layer 3 VPN; and
    a network element coupled with the first piece of customer equipment and the second piece of customer equipment, the network element to maintain a first set of information for the first layer 3 VPN and separately maintain a second set of information for the second layer 3 VPN, the first set of information to include a first value identifying the first layer 3 VPN and the second set of information to include a second value identifying the second layer 3 VPN, to maintain a single shared exterior gateway protocol (EGP) table for the first layer 3 VPN and the second layer 3 VPN, and to associate the first value with a first route distinguisher (RD) and the second value with a second RD.
  6. 6. The system of claim 5 wherein
    the first and second pieces of customer equipment correspond to a single entity.
  7. 7. The system of claim 5 wherein
    the first and second pieces of customer equipment correspond to different entities.
  8. 8. The system of claim 5 further comprising the network element to separately maintain a third set of information for a non-VPN customer and to maintain a second EGP table for the non-VPN customer.
  9. 9. The system of claim 5 further comprising the network element to exchange update messages with the first and second pieces of customer equipment.
  10. 10. The system of claim 5 wherein the network element also maintains a data structure to perform mappings between the first value and the first RD and between the second value and the second RD.
US11409193 2001-11-17 2006-04-21 Method and apparatus for multiple contexts and layer 3 virtual private networks Abandoned US20060190573A1 (en)

Priority Applications (2)

Application Number Priority Date Filing Date Title
US09991234 US7484003B2 (en) 2001-11-17 2001-11-17 Method and apparatus for multiple contexts and layer 3 virtual private networks
US11409193 US20060190573A1 (en) 2001-11-17 2006-04-21 Method and apparatus for multiple contexts and layer 3 virtual private networks

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
US11409193 US20060190573A1 (en) 2001-11-17 2006-04-21 Method and apparatus for multiple contexts and layer 3 virtual private networks

Related Parent Applications (1)

Application Number Title Priority Date Filing Date
US09991234 Division US7484003B2 (en) 2001-11-17 2001-11-17 Method and apparatus for multiple contexts and layer 3 virtual private networks

Publications (1)

Publication Number Publication Date
US20060190573A1 true true US20060190573A1 (en) 2006-08-24

Family

ID=25537012

Family Applications (2)

Application Number Title Priority Date Filing Date
US09991234 Active 2023-10-22 US7484003B2 (en) 2001-11-17 2001-11-17 Method and apparatus for multiple contexts and layer 3 virtual private networks
US11409193 Abandoned US20060190573A1 (en) 2001-11-17 2006-04-21 Method and apparatus for multiple contexts and layer 3 virtual private networks

Family Applications Before (1)

Application Number Title Priority Date Filing Date
US09991234 Active 2023-10-22 US7484003B2 (en) 2001-11-17 2001-11-17 Method and apparatus for multiple contexts and layer 3 virtual private networks

Country Status (3)

Country Link
US (2) US7484003B2 (en)
GB (1) GB2395875B (en)
WO (1) WO2003044685A1 (en)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20090158420A1 (en) * 2007-12-14 2009-06-18 Ks Girish Selective desktop control of virtual private networks (vpn's) in a multiuser environment
US20110149980A1 (en) * 2009-12-21 2011-06-23 Patel Keyur P Efficient generation of vpn-based bgp updates

Families Citing this family (34)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8250357B2 (en) 2000-09-13 2012-08-21 Fortinet, Inc. Tunnel interface for securing traffic over a network
US7111072B1 (en) 2000-09-13 2006-09-19 Cosine Communications, Inc. Packet routing system and method
US7487232B1 (en) 2000-09-13 2009-02-03 Fortinet, Inc. Switch management system and method
US7444398B1 (en) * 2000-09-13 2008-10-28 Fortinet, Inc. System and method for delivering security services
US7389358B1 (en) 2000-09-13 2008-06-17 Fortinet, Inc. Distributed virtual system to support managed, network-based services
US7181547B1 (en) 2001-06-28 2007-02-20 Fortinet, Inc. Identifying nodes in a ring network
US7484003B2 (en) 2001-11-17 2009-01-27 Redback Networks Inc. Method and apparatus for multiple contexts and layer 3 virtual private networks
US7533183B1 (en) * 2001-12-28 2009-05-12 Nortel Networks Limited Central control of multiple address domains within a router
US7376125B1 (en) 2002-06-04 2008-05-20 Fortinet, Inc. Service processing switch
US7116665B2 (en) * 2002-06-04 2006-10-03 Fortinet, Inc. Methods and systems for a distributed provider edge
US7177311B1 (en) * 2002-06-04 2007-02-13 Fortinet, Inc. System and method for routing traffic through a virtual router-based network switch
US7161904B2 (en) 2002-06-04 2007-01-09 Fortinet, Inc. System and method for hierarchical metering in a virtual router based network switch
US7203192B2 (en) * 2002-06-04 2007-04-10 Fortinet, Inc. Network packet steering
US7266120B2 (en) * 2002-11-18 2007-09-04 Fortinet, Inc. System and method for hardware accelerated packet multicast in a virtual routing system
US6970464B2 (en) * 2003-04-01 2005-11-29 Cisco Technology, Inc. Method for recursive BGP route updates in MPLS networks
US7720095B2 (en) 2003-08-27 2010-05-18 Fortinet, Inc. Heterogeneous media packet bridging
US7626948B1 (en) * 2003-09-12 2009-12-01 Cisco Technology, Inc. System and method for verifying the validity of a path in a network environment
US7925778B1 (en) 2004-02-13 2011-04-12 Cisco Technology, Inc. Method and apparatus for providing multicast messages across a data communication network
US7499419B2 (en) 2004-09-24 2009-03-03 Fortinet, Inc. Scalable IP-services enabled multicast forwarding with efficient resource utilization
US8619774B2 (en) * 2004-10-26 2013-12-31 Cisco Technology, Inc. Method and apparatus for providing multicast messages within a virtual private network across a data communication network
US7808904B2 (en) 2004-11-18 2010-10-05 Fortinet, Inc. Method and apparatus for managing subscriber profiles
US20060159091A1 (en) * 2005-01-19 2006-07-20 Arjen Boers Active multicast information protocol
US8179902B2 (en) * 2005-07-15 2012-05-15 Cisco Technology, Inc. Method and system for automatic generation of route distinguishers for virtual private networks
US7889655B2 (en) * 2006-01-17 2011-02-15 Cisco Technology, Inc. Techniques for detecting loop-free paths that cross routing information boundaries
US7609672B2 (en) * 2006-08-29 2009-10-27 Cisco Technology, Inc. Method and apparatus for automatic sub-division of areas that flood routing information
US7899005B2 (en) * 2006-09-12 2011-03-01 Cisco Technology, Inc. Method and apparatus for passing routing information among mobile routers
US8009591B2 (en) * 2006-11-30 2011-08-30 Cisco Technology, Inc. Automatic overlapping areas that flood routing information
US8166205B2 (en) * 2007-07-31 2012-04-24 Cisco Technology, Inc. Overlay transport virtualization
US7936732B2 (en) * 2007-09-27 2011-05-03 Cisco Technology, Inc. Selecting aggregation nodes in a network
US8488491B2 (en) * 2009-11-12 2013-07-16 Cisco Technology, Inc. Compressed virtual routing and forwarding in a communications network
US8694664B2 (en) 2010-11-23 2014-04-08 Cisco Technology, Inc. Active-active multi-homing support for overlay transport protocol
US9363227B2 (en) 2012-08-17 2016-06-07 Cisco Technology, Inc. Multicast source in group address mapping
US9548887B2 (en) 2013-08-09 2017-01-17 Cisco Technology, Inc. Proactive creation of multicast state in an overlay transport network to achieve fast convergence on failover
US9762545B2 (en) 2014-11-03 2017-09-12 Cisco Technology, Inc. Proxy forwarding of local traffic by edge devices in a multi-homed overlay virtual private network

Citations (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5517620A (en) * 1993-05-19 1996-05-14 Nec Corporation Dynamic updating of routing information for routing packets between LAN's connected to a plurality of routers via a public network
US5802316A (en) * 1995-01-26 1998-09-01 Ito; Yuji Routers connecting LANs through public network
US5916306A (en) * 1996-11-14 1999-06-29 Johnson Controls Technology Communication protocol for a router-based building automation and control network
US20010050914A1 (en) * 2000-06-02 2001-12-13 Shinichi Akahane VPN router and VPN identification method by using logical channel identifiers
US6339595B1 (en) * 1997-12-23 2002-01-15 Cisco Technology, Inc. Peer-model support for virtual private networks with potentially overlapping addresses
US6421731B1 (en) * 1996-10-29 2002-07-16 Telxon Corporation Dynamic next hop routing protocol
US6496510B1 (en) * 1997-11-14 2002-12-17 Hitachi, Ltd. Scalable cluster-type router device and configuring method thereof
US6553423B1 (en) * 1999-05-27 2003-04-22 Cisco Technology, Inc. Method and apparatus for dynamic exchange of capabilities between adjacent/neighboring networks nodes
US6704795B1 (en) * 1999-10-12 2004-03-09 Cisco Technology, Inc. Technique for reducing consumption of router resources after BGP restart
US6891793B1 (en) * 1999-01-20 2005-05-10 Fujitsu Limited Network system
US7039720B2 (en) * 2001-01-25 2006-05-02 Marconi Intellectual Property (Ringfence) , Inc. Dense virtual router packet switching
US7068661B1 (en) * 1999-07-13 2006-06-27 Alcatel Canada Inc. Method and apparatus for providing control information in a system using distributed communication routing
US7095740B1 (en) * 1998-06-30 2006-08-22 Nortel Networks Limited Method and apparatus for virtual overlay networks

Family Cites Families (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6226751B1 (en) * 1998-04-17 2001-05-01 Vpnet Technologies, Inc. Method and apparatus for configuring a virtual private network
US6609153B1 (en) * 1998-12-24 2003-08-19 Redback Networks Inc. Domain isolation through virtual network machines
US6662221B1 (en) * 1999-04-12 2003-12-09 Lucent Technologies Inc. Integrated network and service management with automated flow through configuration and provisioning of virtual private networks
US6990103B1 (en) * 1999-07-13 2006-01-24 Alcatel Canada Inc. Method and apparatus for providing distributed communication routing
JP2001237876A (en) * 2000-02-21 2001-08-31 Nec Corp Buildup method for ip virtual private network and the ip virtual private network
US20020090089A1 (en) * 2001-01-05 2002-07-11 Steven Branigan Methods and apparatus for secure wireless networking
US7099912B2 (en) * 2001-04-24 2006-08-29 Hitachi, Ltd. Integrated service management system
US7197550B2 (en) * 2001-08-23 2007-03-27 The Directv Group, Inc. Automated configuration of a virtual private network
US7484003B2 (en) 2001-11-17 2009-01-27 Redback Networks Inc. Method and apparatus for multiple contexts and layer 3 virtual private networks

Patent Citations (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5517620A (en) * 1993-05-19 1996-05-14 Nec Corporation Dynamic updating of routing information for routing packets between LAN's connected to a plurality of routers via a public network
US5802316A (en) * 1995-01-26 1998-09-01 Ito; Yuji Routers connecting LANs through public network
US6421731B1 (en) * 1996-10-29 2002-07-16 Telxon Corporation Dynamic next hop routing protocol
US5916306A (en) * 1996-11-14 1999-06-29 Johnson Controls Technology Communication protocol for a router-based building automation and control network
US6496510B1 (en) * 1997-11-14 2002-12-17 Hitachi, Ltd. Scalable cluster-type router device and configuring method thereof
US6339595B1 (en) * 1997-12-23 2002-01-15 Cisco Technology, Inc. Peer-model support for virtual private networks with potentially overlapping addresses
US7095740B1 (en) * 1998-06-30 2006-08-22 Nortel Networks Limited Method and apparatus for virtual overlay networks
US6891793B1 (en) * 1999-01-20 2005-05-10 Fujitsu Limited Network system
US6553423B1 (en) * 1999-05-27 2003-04-22 Cisco Technology, Inc. Method and apparatus for dynamic exchange of capabilities between adjacent/neighboring networks nodes
US7068661B1 (en) * 1999-07-13 2006-06-27 Alcatel Canada Inc. Method and apparatus for providing control information in a system using distributed communication routing
US6704795B1 (en) * 1999-10-12 2004-03-09 Cisco Technology, Inc. Technique for reducing consumption of router resources after BGP restart
US20010050914A1 (en) * 2000-06-02 2001-12-13 Shinichi Akahane VPN router and VPN identification method by using logical channel identifiers
US7039720B2 (en) * 2001-01-25 2006-05-02 Marconi Intellectual Property (Ringfence) , Inc. Dense virtual router packet switching

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20090158420A1 (en) * 2007-12-14 2009-06-18 Ks Girish Selective desktop control of virtual private networks (vpn's) in a multiuser environment
US8661524B2 (en) * 2007-12-14 2014-02-25 Novell, Inc. Selective desktop control of virtual private networks (VPN's) in a multiuser environment
US20110149980A1 (en) * 2009-12-21 2011-06-23 Patel Keyur P Efficient generation of vpn-based bgp updates
US8995446B2 (en) * 2009-12-21 2015-03-31 Cisco Technology, Inc. Efficient generation of VPN-based BGP updates

Also Published As

Publication number Publication date Type
GB0405089D0 (en) 2004-04-07 grant
US7484003B2 (en) 2009-01-27 grant
GB2395875A (en) 2004-06-02 application
GB2395875B (en) 2004-10-27 grant
WO2003044685A1 (en) 2003-05-30 application
US20030112799A1 (en) 2003-06-19 application

Similar Documents

Publication Publication Date Title
Gleeson et al. A framework for IP based virtual private networks
US8224971B1 (en) Using virtual networking devices and routing information to initiate external actions
US7831733B2 (en) Policy-based forwarding in open shortest path first (OSPF) networks
US8644188B1 (en) Providing virtual networking functionality for managed computer networks
US7483439B2 (en) VPN services using address translation over an IPv6 network
US20120144066A1 (en) Dynamically generating application-layer traffic optimization protocol maps
US20040165581A1 (en) Virtual access router
US7286479B2 (en) Routing for a communications network
US20060088031A1 (en) Method and apparatus for providing multicast messages within a virtual private network across a data communication network
US20080198849A1 (en) Scaling virtual private networks using service insertion architecture
US7274704B1 (en) Piggybacking VPN information in BGP for network based VPN architectures
US20040037275A1 (en) 3-Layer VPN and constructing method thereof
Loshin IPv6: Theory, protocol, and practice
US7463639B1 (en) Edge devices for providing a transparent LAN segment service and configuring such edge devices
US7408941B2 (en) Method for auto-routing of multi-hop pseudowires
US8166205B2 (en) Overlay transport virtualization
US20070112975A1 (en) Redirecting network traffic through a multipoint tunnel overlay network using distinct network address spaces for the overlay and transport networks
US6463061B1 (en) Shared communications network employing virtual-private-network identifiers
US8224931B1 (en) Managing use of intermediate destination computing nodes for provided computer networks
US20030016672A1 (en) Shared communications network employing virtual-private-network identifiers
US20080107043A1 (en) Distributed storage of routing information in a link state protocol controlled network
US20070115990A1 (en) Method of providing an encrypted multipoint VPN service
US7468956B1 (en) Managing routing information in a hub-and-spokes network
US20070286093A1 (en) Method of routing multicast traffic
US7792987B1 (en) Supporting virtual private networks using a first network topology for forwarding and a subset of the first network topology or a smaller topology for signaling

Legal Events

Date Code Title Description
AS Assignment

Owner name: ERICSSON AB,SWEDEN

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:REDBACK NETWORKS INC.;REEL/FRAME:024002/0363

Effective date: 20070125

Owner name: ERICSSON AB, SWEDEN

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:REDBACK NETWORKS INC.;REEL/FRAME:024002/0363

Effective date: 20070125