US6463061B1 - Shared communications network employing virtual-private-network identifiers - Google Patents

Shared communications network employing virtual-private-network identifiers Download PDF

Info

Publication number
US6463061B1
US6463061B1 US09/232,947 US23294799A US6463061B1 US 6463061 B1 US6463061 B1 US 6463061B1 US 23294799 A US23294799 A US 23294799A US 6463061 B1 US6463061 B1 US 6463061B1
Authority
US
United States
Prior art keywords
router
vpn
provider
customer
address
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.)
Expired - Lifetime
Application number
US09/232,947
Inventor
Yakov Rekhter
Eric C. Rosen
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.)
Cisco Technology Inc
Original Assignee
Cisco Technology Inc
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
Application filed by Cisco Technology Inc filed Critical Cisco Technology Inc
Priority to US09/232,947 priority Critical patent/US6463061B1/en
Priority to US10/246,936 priority patent/US7307990B2/en
Application granted granted Critical
Publication of US6463061B1 publication Critical patent/US6463061B1/en
Anticipated expiration legal-status Critical
Expired - Lifetime legal-status Critical Current

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00Routing or path finding of packets in data switching networks
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00Data switching networks
    • H04L12/28Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/46Interconnection of networks
    • H04L12/4641Virtual LANs, VLANs, e.g. virtual private networks [VPN]
    • H04L12/4645Details on frame tagging
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00Routing or path finding of packets in data switching networks
    • H04L45/50Routing or path finding of packets in data switching networks using label swapping, e.g. multi-protocol label switch [MPLS]
    • 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

Definitions

  • the present invention is directed to communications networking. It is directed particularly to providing routing for private wide-area networks.
  • An enterprise that has many sites can build a private wide-area network by placing routers at each site and using leased lines to interconnect them.
  • a router that has a wide-area connection to another router may be called a “backbone router.”
  • the “backbone network” is the set of backbone routers and their interconnections.
  • the backbone network is said to be “fully meshed.”
  • data that travel from one site to another go through the backbone router at an origin site (“ingress router”), travel over the leased line to the backbone router at the target site (“egress router”), and then enter the target site.
  • the backbone network is not fully meshed; a router is connected to only a small number of others (three or four). In such a sparse topology, the ingress and egress routers may not be directly connected. In this case, data may have to pass through several additional, “transit” routers on the way from ingress to egress.
  • a leased line is not actually a piece of wire going from one site to another. It is really a circuit through some circuit-switching network. But this is of no import to the enterprise network manager, to whom those circuits can be considered simple unstructured pipes.
  • the telephone network itself requires considerable management, the telephone-network managers do not need to know anything about the enterprise backbone network; to them, the telephone network just provides point-to-point connections. They do not need to know what role these connections might be playing in an enterprise data network.
  • the enterprise network is “overlaid” on top of the telephone network.
  • the enterprise network can be called the “higher layer” network, the telephone network the “lower layer” network. Both networks exist, but each is transparent to the other.
  • the enterprise's backbone routers exchange routing information with each other, but the telephone switches do not store or process that routing information. That is, backbone routers are “routing peers” of each other, but they are not routing peers of the telephone switches. This way of building a higher-layer network on top of a lower-layer network is called the “overlay model.”
  • Wide-area enterprise networks are now more likely to be built on top of frame-relay and ATM networks than on top of circuit-switched (telephone) networks.
  • a telephone network really provides circuits between backbone routers
  • a frame-relay or ATM network provides “virtual circuits” between backbone routers.
  • the overlay model still applies even though the lower-layer network is now a frame-relay or ATM network rather than a circuit-switched one, i.e., even though virtual rather than fixed circuits make the point-to-point connections between backbone routers.
  • the two networks are still transparent to each other.
  • the enterprise network manager still has a wide-area backbone to design and operate. However, because the circuits are “virtual,” this is usually called a “virtual private network” (VPN) instead of a “private network.”
  • VPN virtual private network
  • the overlay model also tends to result in extra traffic when multicast is in use. It is usually impractical or undesirable for the “lower layer” network to do the necessary packet replication, so all packet replication must be done in the “higher layer” network, even if a number of replicated packets must then follow the same “lower layer” path up to a point.
  • a service provider can afford its customers greater value if it absorbs the task of designing and operating the backbone. More specifically, the SP should so organize and operate the backbone that, from the point of view of a particular site administrator, every enterprise network address not located at a given site is reachable through the SP's backbone network. How the SP's backbone decides to route the traffic is the SP's concern, not that of the customer enterprise. So the customer enterprise does not really need to maintain a backbone router at each site; it just needs a router that attaches to one of the SP's backbone routers. As will become apparent, providing such an organization involves abandoning the overlay model for a different model. The new model will be called the “peer model” for reasons that will be set forth below.
  • C-network the enterprise network, consisting of C-routers, which are maintained and operated by the enterprise.
  • P-network the SP network, consisting of P-routers, which the SP maintains and operates.
  • CE-router an “edge router” in the C-network, i.e., a C-router that attaches directly to a P-router and is a routing peer of the P-router.
  • PE-router an “edge router” in the P-network, i.e., a P-router that attaches directly to a C-router and is a routing peer of the C-router.
  • a P-router is not a PE-router, i.e., not an edge router, it is a transit router.
  • edge and transit routers are relative to specific VPNs. If a given one of the SP's routers receives a given VPN's traffic from and forwards it to only others of the SP's routers, the given router is a transit router vis-à-vis the given VPN. Yet that same router may receive another VPN's traffic from and/or forward it to one of that other VPN's edge routers, in which case the given SP router is an edge router from the other VPN's point of view.
  • IP Internet-Protocol
  • the SP makes use of a “virtual router.”
  • the PE router When a PE router receives a packet received from a CE router, the PE router “tags” the packet with an indication of the C-network where it originated. It then bases its determination of what router to forward the packet to not only on the packet's destination address but also on the identity of the originating C-network. At each subsequent hop, the router looks up the packet's destination address in the forwarding table specific to the C-network that the tag designates.
  • a provider network employing this technique associates internal and external identifiers, which we call “VPN IDs,” with a customer network and employs these selectively in forwarding reachability messages relating to customer nodes.
  • a provider edge router linked to a given customer's edge router in a system that employs the present invention's teachings will ordinarily relay reachability information concerning customer sites from that router only to provider edge routers similarly linked to other edge routers of the same customer, to which they will in turn forward the reachability information. In doing so, it will include the customer's internal VPN ID in the message so that the receiving provider router can disambiguate the possibly non-unique IP address that the reachability message specifies. Those other provider edge routers will not forward the information to other outside routers that are not part of the nework of the customer involved.
  • a provider edge router When a provider edge router then receives from outside that customer network a packet directed to the address whose reachability was advertised with the customer's external VPN ID, it forwards the toward the provider edge router that attached the external VPN ID to the reachability message that advertised the destination, and that router can send it to the firewall site. In contrast, packets from within the customer network can be sent to through provider edge routers that used the internal VPN ID for reporting the destination's visibility.
  • FIG. 1 is a topological diagram of a VPN and a tagging sequence that its routers employ;
  • FIG. 2 is a diagram that illustrates the format of a tagged packet
  • FIG. 3 is a diagram of the environment and format of a tag-distribution-protocol protocol data unit
  • FIG. 4 is a diagram that illustrates the format of a conventional Border Gateway Protocol protocol data unit and its environment
  • FIG. 5 is a diagram that illustrates the format and environment of a Border Gateway Protocol protocol data unit used to distribute VPN-distinguishing reachability information and tags;
  • FIG. 6 is a diagram that illustrates the format of another conventional Border Gateway Protocol protocol data unit and its environment
  • FIG. 7 is a topological diagram of a VPN that employs ATM switches in implementing the present invention's teachings
  • FIG. 8 is a diagram of an ATM frame used in the FIG. 7 embodiment.
  • FIG. 9 is a topological diagram used to illustrate inter-VPN communication.
  • FIG. 1 Before we describe an embodiment of the invention in detail, we will employ FIG. 1 to present a brief overview of its operation.
  • FIG. 1 depicts a very simplified topology for illustrating an SP's connections between two parts of a customer enterprise C's VPN.
  • Two of the enterprise's edge routers CE 1 and CE 2 are located remotely from each other, and the customer enterprise has contracted with the SP to provide connections between the customer's routers such as CE 1 and CE 2 to form a VPN V.
  • the SP's resources are edge routers PE 1 and PE 2 and further, transit routers P 1 and P 2 that together form a path between CE 1 and CE 2 .
  • the SP network has another customer for which it uses those same resources to implement a different VPN, W, that also includes a (differently located) host having the same address D 1 .
  • W that also includes a (differently located) host having the same address D 1 .
  • PE 2 can tell which D 1 -addressed system should receive the packet.
  • the VPNs that the SP cooperates with its customers to implement follow the peer model, so PE 2 contains customer-network topological information that the customers have “leaked” to it. It stores this information in a separate routing table for each customer VPN to which PE 2 is directly connected, so it can disambiguate the otherwise ambiguous address D 1 . From this information, PE 2 knows that PE 1 is the SP edge router to which it should direct the packet in order to reach the D 1 -addressed system in VPN V.
  • PE 1 forwards the packet to CE 1 so that the packet will reach the D 1 -addressed location in VPN V rather that the one in VPN W, to which PE 1 may also be able to forward packets. Therefore, PE 2 needs to include in the forwarded packet some indication that the intended D 1 -addressed host is the one in VPN V. But this should be done without requiring that transit routers P 1 and P 2 also maintain the VPN-specific information that the edge routers store.
  • PE 2 achieves this by adding to the packet an internal-routing field that in the illustrated embodiment includes two constituent fields, namely, an egress-router field and an egress-channel field.
  • the egress-router field takes the form of a tag that P 2 can map to the next hop in the route to the egress edge router PE 1 , upon which the transit routers can base their routing decisions without requiring knowledge of the VPN involved.
  • the egress-channel field takes the form of a tag that PE 1 can interpret as specifying its interface with CE 1 or as otherwise representing the channel that links it to VPN V.
  • the goal of avoiding VPN-specific forwarding information could be achieved, though to a lesser degree, by having the internal-routing field include only an egress-channel field, not an egress-router field.
  • the transit routers would then be basing their routing decisions on fields that in a sense do designate particular VPNs, but only because a given channel may lead only to nodes in a particular VPN. The transit routers still would not need to store information concerning locations in any of the customer sites.
  • PE 2 “tags” the packet with two tags T 2 and T 3 .
  • P 2 has arranged with its neighbors, including PE 2 , to tag with T 2 any packets sent to P 2 for forwarding along a route in which the SP edge router is PE 1 .
  • T 3 is a tag with which PE 1 has arranged for the other edge routers to tag packets destined for certain VPN V locations if PE 1 is the egress router.
  • FIG. 2 illustrates an exemplary link-level-protocol format.
  • Different link-level protocols may be employed on different links. Examples of such protocols are the IEEE 802 protocol family and the point-to-point protocol (PPP) specified in the Internet community's Requests for Comments (“RFCs”) 1331 and 1332. Similar to the former is the Ethernet protocol. If the links connecting CE 2 to PE 2 and PE 2 to P 2 are Ethernet links, the link-layer frame that CE 2 sends to PE 2 takes the form that FIG. 2 's top row depicts. Specifically, it consist of a link-level payload encapsulated by an Ethernet heater and trailer.
  • the Ethernet trailer consists of a cyclic-redundancy-code (CRC) field used for error detection.
  • the Ethernet header includes destination-address and source-address fields, which respectively contain the link-level (“hardware”) addresses of PE 2 's and CE 2 's interfaces to that link, and it also includes a type field used for demultiplexing the link packet's contents.
  • the code represents the Internet Protocol (IP): the receiving router should interpret the contents as an IP “datagram” (as the IP protocol data unit is called), consisting of the IP header and IP data.
  • IP Internet Protocol
  • Routers generally use network-protocol information to forward packets from one link to another along an inter-network path from the source interface to the ultimate destination interface.
  • FIG. 2 's second row depicts the corresponding link-layer frame after PE 2 has added T 2 and T 3 .
  • the Ethernet header and trailer take the same form as before.
  • the link-level protocol is the same on the new link, although most embodiments will not exhibit such protocol uniformity.
  • the link-level source and destination are different, of course, the corresponding header fields' contents differ from those in the CE 2 -to-PE 2 frame, and the CRC field contents, having been calculated from different frame contents, are different, too.
  • the difference most relevant to the present discussion is the type-field difference. Even though the frame does include an IP datagram, the type field does not contain the IP-indicating code. Instead, the code that it contains tells P 2 's interface that the frame's contents should be interpreted as a tagged packet.
  • the four bytes immediately following the link-level header should be interpreted as an entry in a “tag stack,” whose format FIG. 2 's third row illustrates. Specifically, the first twenty bits should be interpreted as the tag, and the twenty-fourth, bottom-of-stack-indicator bit S tells whether the packet contains any more tag-stack entries.
  • Appendix A contains a thorough description of the manner in which a tag-switching router can use the various fields, so we will not discuss the other, COS and TTL fields here.
  • the tag field contains the “top” tag value T 2 , while the S bit is zero, indicating that this is not the bottom tag-stack entry. Therefore, P 2 should interpret the next four bytes as a tag-stack entry, too. In the example, that entry contains a tag value of T 3 and an indication that it is the bottom stack entry.
  • P 2 forwards the packet to P 1 , it replaces tag T 2 with a new tag, T 1 , which P 1 has asked its neighbors to attach to any packets that should be sent though PE 1 -egress routes, and P 1 similarly makes its routing decision without having had to maintain separate routing information for the destination VPN.
  • P 1 's stored routing information tells it to remove a tag rather than replace it, so it does so before forwarding the packet to PE 1 .
  • PE 1 From tag T 3 , PE 1 knows that it should forward the packet to the edge router CE 1 that affords access to the D 1 -addressed location in VPN V. So PE 1 forwards the packet to CE 1 after removing tag T 3 . Since CE 1 is concerned only with destination addresses in its own VPN, it is able to base its routing decision on D 1 alone.
  • router circuitry for performing functions described below will be provided as communications hardware operated by one or more processors software-configured to perform the described operations.
  • processors software-configured to perform the described operations.
  • Those skilled in the art will recognize that such an approach is usually the most practical, because software configuration of a general-purpose processor enables a relatively small amount of hardware to serve as circuitry for performing many different functions concurrently. But the present invention can instead be implemented in any circuitry that performs the functions described.
  • each router maintains a table, sometimes called the “Forwarding Information Base” (FIB), that it uses to map from “address prefixes” to “next hops.”
  • FIB Forming Information Base
  • a router that receives a packet whose destination address begins with a given address prefix employs the next-hop entry as described below to determine the direction in which to forward the packet.
  • FIB The manner in which the FIB is constructed is not critical to the present invention. In principle, a system administrator can provide it manually. More typically, routers build such tables automatically by employing routing algorithms to share topological information. But regardless of how the FIB is constructed, a conventional router R executes the following procedure (in principle) to find the next hop for a particular packet:
  • N is the address of a router to which R is directly connected (i.e., if there are no routers between R and the next hop), then the procedure ends, and R forwards the packet over its link to the router whose address is N.
  • R performs a recursive lookup. That is, it searches the FIB for the longest address prefix that matches N, fetches the corresponding next-hop IP address N 2 , determines whether N 2 is directly connected, etc. The recursion ends when R finds a next hop directly connected to it, and it R forwards the packet over its link to the router whose interface has that address.
  • a normal Internet router maintains only one FIB table. But routers in a provider of connections for many enterprises' peer-model VPNs need different tables for different VPNs, because a router may need to distinguish between potentially identical prefixes in different VPNs. (Each SP router also needs to maintain a general, i.e., non-VPN-specific, FIB. Unless explicitly stated otherwise, references below to the FIB mean the general FIB.) But transit routers, i.e., routers that are not directly attached to customer's VPN, do not need to maintain VPN-specific FIBs.
  • PE router we consider a PE router to be “directly attached” to a particular VPN if it is directly attached to a CE router in that VPN.) And an edge router such as PE 1 or PE 2 needs to maintain, in addition to a general FIB, a separate FIB only for each VPN to which it is connected directly. The reason why this is so will become apparent as the description proceeds.
  • each FIB entry actually differs somewhat from that described above, because the illustrated embodiment uses “tag switching.”
  • tag switching When data-transmission speeds become high and network sizes become large, searching for longest matches to the packet's ultimate-destination address becomes onerous. So proposals have been made to reduce this burden by “tagging” the packets.
  • a tag is a field that routers use to make routing decisions. Unlike a network-level address, though, a tag is a true (unique) index to a given router's routing table, whereas the network (e.g., IP) address in the destination field of a packet's header is merely an invitation to a router to find the address prefix that constitutes the best match.
  • IP network address
  • One way to implement tag switching is to have routers tell their neighbors the tags they want to see in the packets that they receive. Specifically, a given router may decide to associate a particular tag with (“bind a particular tag to”) a particular address prefix. If so, it tells its neighbor routers that, when they forward it a packet destined for an address having that prefix, they should attach the specified tag so that the given router can go straight to the right table entry without having to do a best-match search. (Although the illustrated embodiment bases tagging on address prefixes, other embodiments may base it on some other packet attribute that is relevant to routing.)
  • the forwarding table does not merely map an address prefix to a next-hop IP address; it maps the address prefix to an ordered pair whose first element is a next-hop IP address and whose second element is a tag-stack operation. That is, an FIB next-hop entry contains both a next-hop IP address and a tag-stack operation.
  • the “no op” value is the default tag-stack-operation entry. As will be explained below, neighbors' requests may result in that entry's being modified to contain a push operation.
  • router R When router R receives an untagged packet, it finds the longest address-prefix match to R's destination IP address, and it fetches the corresponding next-hop entry. If that next-hop entry's tag operation is “push a specified tag value onto the stack,” it pushes the specified tag value onto the tag stack that the packet includes. If it is necessary for R to perform a recursive lookup, it searches for another next-hop entry. If that next-hop entry also has a “push a specified tag value onto the stack” operation in it, that specified value is also pushed. If the recursion ends as a result of the second lookup, then two tag values may have been pushed onto the tag stack.
  • R When the recursion ends (or if there is no recursion), R knows which of its directly connected neighbors is the next hop for the packet. It then transmits the packet to that next hop, using whatever data-link protocol is necessary in order to reach that next hop.
  • a router R When a router R uses tag switching, it fetches next-hop information in response to a tag, so it uses a routing table separate from the FIB, from which it fetches next-hop information in response to a destination address. This separate table is sometimes called the Tag Information Base (TIB).
  • TIB next-hop entries contain a next-hop IP address and a tag-stack operation. For our purposes, we need consider only three tag-stack operations:
  • router R When router R receives a tagged packet, it uses the packet's top tag as an index into the TIB and fetches the indicated entry. (Those skilled in the art will recognize that security requirements, local-link constraints, or other considerations may in some cases necessitate that the index into the TIB actually consist of both the incoming packet's tag and the interface on which it arrived, but the principle is best explained without complicating the discussion with those details.) In accordance with the fetched TIB entry, it either replaces the tag with a different value or pops the tag stack.
  • R uses the appropriate data-link protocol to send the tagged packet to that neighbor. If the next hop specified in the TIB entry is not a directly connected neighbor, on the other hand, then R (again, in principle) performs a recursive lookup by finding the FIB entry that corresponds to that address. (The FIB is used since this part of the search is based on an address, not a tag.) Then processing proceeds as described in “The FIB” above.
  • the present invention does not require any particular mechanism for providing the contents of the FIB and the TIB. But considering one such mechanism, namely, routing protocols, helps one appreciate those contents' purpose.
  • the types of protocols that it uses can be divided into interior gateway protocols (IGPs), exterior gateway protocols (EGPs), and tag-distribution protocols (TDPs).
  • IGPs interior gateway protocols
  • EGPs exterior gateway protocols
  • TDPs tag-distribution protocols
  • Routers in an inter-networking domain under single administration use IGPs to share topological information about that domain.
  • Routers use EGPs to share extra-domain topological information. They use TDPs to distribute tags.
  • every router runs an IGP.
  • IGP Interoperability for Mobile Communications
  • a router sends to its same-domain neighbor routers IGP messages that “advertise” destinations to which it accords direct access.
  • the neighbors in turn forward the messages to their neighbors.
  • the forwarding routers modify the messages in such a way that a message tells what route it took to reach the recipient, or at least how long the route was.
  • the recipient thereby amasses topological information and decides on the basis of that information whether to enter into its FIB as the next hop to the advertised destinations the address of the router that forwarded it the message. So FIB entries that an IGP creates are always non-recursive: the next hop is always a directly connected neighbor.
  • the customer-enterprise routers may also use an IGP. Although the drawing does not show them, the customer enterprise would typically also have further routers at the same sites as CE 1 and CE 2 , and those routers may use an IGP. But the customer enterprise's nodes that have access to each other only through the provider network do not use an IGP to exchange routing information with each other, so the routers at, for instance, CE 1 's site use an IGP only for routing-information exchange with other routers at the same site (or other sites to which there is customer-managed access), not for such exchange with routers at CE 2 's site.
  • IGP When IGP maps address prefix X to next hop N, it may modify both the FIB and the TIB.
  • the FIB modifications are as follows:
  • IGP inserts an entry that maps X to N and removes any entry that maps X to a different router.
  • the IGP process determines whether N has sent R a message that binds X to some tag value T. If not, the FIB entry is inserted with the tag-stack operation “no op.” Otherwise, the FIB entry is inserted with the tag-stack operation “push T onto the stack.”
  • R determines whether it has told any of its directly connected neighbors to tag X-destined packets with some tag value T. If not, it makes no TIB modifications. Otherwise, it looks up the TIB entry that corresponds to T.
  • R inserts one for tag T having a next-hop entry of N. If there is a corresponding TIB entry, it replaces the next-hop entry with N.
  • R determines whether N has asked it to tag X-destined tags with some tag value T 2 . If not, the tag-stack operation is “discard the packet.” Otherwise:
  • N's requested “tag” T 2 for X-destined packets is a actually a distinguished tag value that means “pop the tag stack,” then N has not really asked that R place a tag on such packets but instead has asked that it merely remove one already in the packet. So TIB entry's tag-stack operation is “pop the tag stack.”
  • the TIB entry's tag-stack operation is “replace the packet's top tag-stack value with T2.”
  • a distinguished value of “next hop” that may exist in both the FIB and the TIB is “me.” This means that a packet has reached its final hop, and is delivered to local software rather than forwarded over a data link to a next hop.
  • IGP speakers periodically advertise address ranges to which they afford direct access. If P 1 is on a subnet in which all hosts' addresses start with 192.3.45, for instance, it will advertise this prefix, and every IGP speaker in the SP network will have an entry for that prefix in its FIB. Therefore, if PE 1 has an interface on the same subnet, say with an address of 192.3.45.12, then those IGP speakers will be able to determine how to reach PE 1 . But it will become apparent as the description proceeds that, in order to assign certain tags, the illustrated embodiment requires each SP router additionally to have PE 1 's full address as a prefix in its FIB. And, in general, each SP router should have such a “host route” for every PE-router.
  • edge routers in the illustrated embodiment advertise not only the address ranges to which they have access but also their own complete addresses. (Actually, as will shortly be explained, the edge routers are also “BGP speakers,” which would conventionally advertise their host routes in IGP anyway.)
  • IGPs are used for propagating routing information among routers connected by routes within a commonly administered domain.
  • the assumption is that routers are generally to cooperate in routing any received packets and that they will accumulate routing information from all sources within that domain.
  • a domain administered by one entity may additionally be connected to domains administered by others.
  • a given domain may choose to be selective about what traffic it will forward and which of its resources it will make available for that purpose.
  • an update message contains an address prefix, a “BGP next hop,” and an AS Path, which lists the autonomous systems traversed in reaching the advertised destinations. With tag switching, this is modified to add a tag to each address prefix.
  • a router R When a router R receives a BGP update message for address prefix X from a BGP peer R 2 , R runs the BGP decision process. Policies that the BGP process implements may or may not result in R's installation of R 2 's route to X. But if they do, then:
  • R adds an entry that maps X to the specified next hop, and it removes any previous entry for X.
  • This next hop will not in general be a directly connected neighbor of R, so the FIB entry may be a recursive one.
  • R 2 will specify itself as the BGP next hop, in which case the FIB entry will map X to R 2 .
  • R 2 's BGP Update message specified tag value T for address prefix X If R 2 's BGP Update message specified tag value T for address prefix X, then the tag-stack operation in the FIB entry is “push T onto the tag stack.” Otherwise, the tag-stack operation is “no op.”
  • the FIB entry's next-hop field is left unchanged. If R 2 's BGP Update message specified tag value T for address prefix X, then the FIB entry's tag-stack operation is changed (if necessary) to be “push T onto the tag stack.” If R 2 's BGP Update message specifies no tag value for X, then the tag stack operation in the FIB entry is changed (if necessary) to “no op.”
  • a router In most tag-switching proposals, a router is allowed to bind a tag to an address prefix if the router's FIB table includes an entry that corresponds to that address prefix.
  • the FIB-entry “prefix” is the complete address (“host route”) of a router in the SP's network, then binding a tag to that prefix is not only permitted but required.
  • X is the (thirty-two-bit) address of the router R itself, then the tag value that R binds to X is the distinguished value that means “pop the tag stack.”
  • R When a tag T is bound to an address prefix X, and the FIB entry for X was inserted as a result of running the IGP, R will distribute the tag binding to its directly connected neighbors by using a tag-distribution protocol that will be described below.
  • R When a tag T is bound to an address prefix X, and the FIB entry for X was inserted as a result of running BGP, R will use BGP to distribute the tag binding, in a manner that will be described below, to any BGP peer to which it distributes the route to X.
  • router R binds to an address prefix X a tag T other than the distinguished value that means “pop the tag stack,” then R also creates a T-indexed TIB entry in its own TIB table.
  • the TIB entry is created as follows.
  • R is a PE router
  • address prefix X is one for which the next hop is a directly attached CE router.
  • the prefix value will have been enhanced to distinguish X in CE's VPN from X in others'.
  • the TIB entry will specify the CE router as the next hop, and its tag-stack-operation entry will be “pop the tag stack.”
  • the FIB entry corresponding to X specifies a next hop of N and a tag-stack operation of “push value T 2 onto the stack.” Then the TIB entry will give N as the next hop and “replace the value at the top of the stack with T” as the tag-stack operation.
  • the FIB entry corresponding to X specifies a next hop of N and a tag-stack operation of “no op.” Then the TIB entry will specify a next hop of N, and a tag-stack operation of “discard the packet.”
  • FIG. 1 All of FIG. 1 's P routers (PE 1 , PE 2 , P 1 , and P 2 ) participate in a common IGP.
  • CE 1 and CE 2 do not participate in this IGP.
  • CE 1 , PE 1 , CE 2 , and PE 2 are BGP speakers.
  • CE 1 has an External BGP (EBGP) connection to PE 1
  • PE 1 has an Internal BGP (IBGP) connection to PE 2
  • PE 2 has an External BGP connection to CE 2 .
  • EBGP External BGP
  • IBGP Internal BGP
  • CE 2 External BGP connection to CE 2 .
  • PE 1 Since PE 1 is an edge router, it exports its own thirty-two-bit address into the P-network's IGP. As a result:
  • PE 2 has an FIB entry that maps PE 1 to a next-hop value of P 2 . Since P 2 is directly connected to PE 2 , this entry is non-recursive.
  • P 2 has an FIB entry that maps PE 1 to a next-hop value of P 1 . Since P 1 is directly connected to P 2 , this entry is non-recursive.
  • P 1 has a FIB entry that maps PE 1 to a next hop value of PE 1 . Since PE 1 is directly connected to P 1 , this entry is non-recursive.
  • PE 1 has a FIB entry that maps PE 1 to a next hop value of “me.”
  • each of the SP's routers construct a TIB by assigning tags to all of the prefixes for which its FIB has entries and that it ask its neighbors to use those tags in forwarding data packets to it.
  • a mechanism that they can use to make those requests is a tag-distribution protocol (TDP).
  • TDP tag-distribution protocol
  • TDP is a two-party protocol. It requires a connection-oriented transport layer that provides guaranteed sequential delivery.
  • FIG. 3 's second row therefore depicts TDP's protocol data units (PDUs) as being carried in a data stream delivered by the well-known Transport Control Protocol (TCP) whose segments are delivered in Internet Protocol (IP) datagrams whose format FIG. 3 's first row depicts. (That row omits the link-level-protocol header and trailer fields that usually encapsulate the IP datagram for transmission between hosts on the same link.)
  • TCP Transport Control Protocol
  • IP Internet Protocol
  • the IP datagram begins with a header that includes various types of information such as the datagram's length, the network address of the destination host interface, and a code for the next-higher-level protocol in accordance with which the destination host should interpret the datagram's payload.
  • that protocol is TCP, which handles matters such as ensuring that data have been received reliably.
  • the destination host's TCP process interprets the first part of the IP field as a header used in carrying out these TCP functions.
  • that header includes a field that specifies the “port” application that is to receive the TCP segment's remainder, payload portion. In the case under consideration, the port field indicates that the host's TDP application is to receive it.
  • TCP-segment payloads results in a data stream that contains the TDP PDUs.
  • a TDP PDU begins with a fixed-length four-field header.
  • the header's two-byte version field gives the number of the TDP version that the sender is using.
  • the two-byte length field gives the length in bytes of the remainder of the PDU; i.e., it gives the total PDU length minus four.
  • TDP communications occur in sessions, of which a given router can be conducting more than one at a time.
  • the first four bytes of the six-byte TDP ID field encode an IP address assigned to the router that started the TDP session, and the TDP ID field's last two bytes identify the particular session.
  • PIEs protocol information elements
  • Each PIE's type field specifies its purpose, while its length field gives the length of its value field.
  • Various PIE types have housekeeping purposes, such as instituting a TDP session between two routers, negotiating protocol versions, providing error notifications, and keeping the session alive. (If a router does not receive a same-session communication within a certain timeout period, it ends the session and discards the tags installed during the session.) But the protocol's main mission, i.e., distributing tag bindings, is carried out by PIEs of the TDP_PIE_BIND type, for which the type field's contents are 0200 16 .
  • FIG. 3 depicts this PIE type's value segment.
  • the request-ID field is zero unless the PIE is being sent in response to a request from the other session participant, in which case that field's request ID matches that of the request. (Such a request would have been sent as another PIE type.)
  • the AFAM (Address Family Numbers) field is set to 1, indicating that the address prefixes contained in the PIE's binding list are intended to be interpreted as IP version 4 (IPv 4 ).
  • the Blist Type field is set to 6 (“32-bit downstream assigned VCI tag”) to indicate that, as will be seen below, the tag has a format and location specific to the ATM protocol. Otherwise it is set to 2, which means “32-bit downstream assigned.” Downstream assigned means that a tag's meaning is being set by the router that will base its routing decisions on it, as opposed to the router that will tag the packet with it.
  • Blist Length field gives the length in bytes of the Binding-List field, and the optional-parameters field is sometimes included to present related information.
  • the field of most interest here is the Binding-List field, whose format FIG. 3 's fifth row depicts. That field contains one or more entries.
  • each of the entries includes precedence, tag, prefix-length, and prefix fields, as FIG. 3 's fifth row indicates.
  • the prefix-length field contains X's length in bits
  • the prefix field contains X's value right padded with as many bits as needed to make it end on a byte boundary
  • the precedence field is an eight-bit field that specifies the precedence with which the router that issued the PDU will service traffic that bears T as a tag.
  • a router So to request that a neighbor router use a given tag value when it forwards packets destined for a given prefix, a router sends a TDP message containing a TDP_PIE_BIND type PIE whose binding-list portion's tag and prefix fields respectively contain that tag and prefix.
  • PE 1 uses this mechanism to ask that P 1 bind to PE 1 's own address a distinguished tag value that means “pop the tag stack.” (It makes a similar request to any other of the SP's transit routers to which it is directly connected.) The purpose of this request is to establish PE 1 , an edge router, as one that should see the lower, ultimate-destination-designating tag (T 3 in FIG. 1) hidden from the transit routers.
  • P 1 As a result of PE 1 's having advertised its host route, P 1 already has an FIB entry that maps PE 1 's address to a next hop of PE 1 and a tag-stack operation of “no op.” As was stated above, the SP's routers are required to create TIB entries for all prefixes that they have FIB entries for, so P 1 assigns a tag T 1 to PE 1 by creating a TIB entry that maps T 1 to the destination PE 1 . And, in accordance with PE 1 's bind request, that entry's tag-stack operation is “pop the stack.”
  • P 1 must also distribute the new tag, so it uses TDP to ask that P 2 use the T 1 tag whenever it sends P 1 a packet destined for PE 1 .
  • PE 1 's advertisement of its host route has resulted in P 2 's already having a FIB entry that maps PE 1 's address to a next hop of P 1 and a tag-stack operation of “no op.”
  • P 2 now modifies this FIB entry so that the tag-stack operation is “push T1.”
  • PE 1 Since PE 1 is a destination in P 2 's FIB, P 2 must bind a tag value to PE 1 's address. That is, it creates a TIB entry that maps T 2 to a next hop of P 1 —i.e., to its FIB's next-hop entry for PE 1 —and to a tag-stack operation of “replace the top tag value with T1.” P 2 then uses TDP to ask that PE 2 use tag value T 2 whenever it sends P 2 a packet destined for PE 1 .
  • PE 2 already has a FIB entry that maps PE 1 's address to a next hop of P 2 and a tag-stack operation of “no op.” In response to P 2 's TDP message, PE 2 now modifies this FIB entry so that the tag-stack operation is “push T 2 .”
  • the CE 1 router is a routing adjacency of the PE 1 router. That is, when CE 1 forwards a packet destined for a remote system that can be reached through PE 1 , CE 1 explicitly directs that packet to PE 1 . In the illustrated example as it will be elaborated on in connection with FIG. 2, it performs the explicit direction by encapsulating the packet in a link-level header containing PE 1 's hardware address on a common multinode network. In other configurations, it may do so by, for instance, placing that packet on a point-to-point link with or by sending the packet in transmission cells whose headers include a code that represents a channel between CE 1 and PE 1 .
  • Yet another way of providing the explicit direction is to use, e.g., encapsulated IP, whereby the packet includes an IP datagram whose destination address is PE 1 's network address but whose payload is another IP datagram, this one having the destination address of the remote destination.
  • IP IP datagram
  • the packet includes an IP datagram whose destination address is PE 1 's network address but whose payload is another IP datagram, this one having the destination address of the remote destination.
  • an internetwork route between CE 1 and PE 1 acts as a “link” in a higher-level inter-network route.
  • CE 1 is not in general a routing adjacency of CE 2 . That is, even when CE 1 forwards a packet destined for a remote system reachable through CE 2 , it never explicitly specifies CE 2 as a router through which the packet should pass on the way. True, the fact that CE 2 is in the route may have been included in the reachability information that CE 1 amassed in the course of filling its forwarding-information database. But in the course of actually forwarding a packet, CE 1 simply notes that PE 1 is the next hop to the ultimate destination.
  • CE 1 In the FIG. 1 topology, suppose that CE 1 is to tell PE 1 which hosts are reachable at its site. For this purpose, it must use an external routing protocol, and we have assumed for the sake of example that it uses BGP. Together with RFC 1655, RFC 1654 and its predecessors describe that protocol's operation exhaustively, and we will not repeat that description here. For present purposes, we mention only a few features of most interest to the illustrated embodiment's operation.
  • BGP uses the TCP transport protocol. Concatenation of TCP-segment payloads results in a data stream in which the BGP application looks for a predetermined marker sequence. It interprets the marker and subsequent fields as a BGP message header that contains information such as the message's length and type. To share routing information, the type of message that CE 1 uses is the BGP “Update” message, whose format FIG. 4 's second row depicts.
  • the drawing uses a section labeled “header+” to represent the header and a number of fields not of particular interest to the present discussion.
  • the message ends with a list of interface address prefixes referred to as Network-Level Reachability Information (NLRI), and a Path Attributes field describes a path to hosts whose IP addresses begin with those prefixes.
  • NLRI Network-Level Reachability Information
  • PAL Path Attribute Length field
  • CE 1 is at a site where all the hosts have IP addresses whose first byte is 10 (OA 16 ) and whose second byte is 1 (01 10 ). That is, they can be represented by the two-byte prefix 0A01 16 (which the literature conventionally represents as “10.1.”)
  • OA 16 IP address
  • 0A01 16 which the literature conventionally represents as “10.1.”
  • CE 1 places in an NLRI-field length segment an indication that the prefix to follow is two bytes in length, and it puts 0A01 16 in the following, prefix field, as FIG. 4 's third row indicates.
  • FIG. 4 's third row depicts the message's path-attributes portion as having three attribute fields, of which FIG. 4 's fourth row illustrates one in detail.
  • Attribute fields take the ⁇ type, length, value> form.
  • the type field's second, “attribute code” half is shown as containing the code value of 2, which indicates that the value field is to be interpreted as describing a path to the hosts that the message advertises as being reachable. Specifically, it is to be interpreted as listing the “autonomous systems” that have to be traversed to reach those hosts.
  • ASN Autonomous System Number
  • AS Autonomous system
  • CE 1 cannot communicate with CE 2 without using the SP's resources, the customer-enterprise-administered resources comprise at least two ASs. So we will assume that CE 1 's ASN is A 1 , CE 2 's ASN is A 2 , and the PE routers' ASN is A 3 .
  • the AS-path attribute's value includes a first field that identifies it a sequence of ASs, a second field that gives the number of ASNs in the list as one, and a third field that contains the list's sole ASN, A 1 .
  • FIG. 4 's fifth row depicts another of that message's attribute fields, one whose attribute-code byte identifies it as specifying the “next hop” to be used in reaching the advertised host-address range.
  • the value field contains CE 1 's address, thereby indicating that CE 1 can forward traffic to those reachable destinations.
  • CE 1 has told PE 1 that it undertakes to forward traffic to hosts whose IP address prefixes are 10.1.
  • PE 1 assigns a tag, T 3 , to that address prefix in CE 1 's VPN, VPN V.
  • T 3 a tag
  • PE 1 may use the same tag value for every address prefix mentioned by CE 1 .
  • PE 1 creates an entry, indexed by this tag value, that specifies CE 1 as the next hop.
  • the entry specifies a tag-stack operation of “pop the tag stack” so that the tag used will be discarded to reveal the network-layer header to CE 1 .
  • PE 1 sends BGP update messages to certain other of the SP's routers to tell them that they can forward to PE 1 any packets destined for hosts whose addresses are in the 10.1 range.
  • PE 1 's SP network provides service to other customer enterprises that may also have 10.1-prefix hosts: those hosts' addresses may not be unique. So the SP assigns a different VPN identifier to each of its customers' VPNs.
  • the code is a 16-bit identifier V.
  • PE 1 prepends the VPN identifier V to the IPv 4 address prefix (10.1 in the example) and uses it in the BGP message to the other provider routers.
  • the SP may assign VPN V more than one VPN identifier.
  • VPN V uses the SP not only as its backbone but also as its connection to outside systems, such as the SP's other customers or the public internet.
  • CE 1 or another of VPN V's edge routers could also send PE 1 information regarding routes over which VPN V would permit outside-origin traffic. For example, one route to a given node may be shorter and thus preferred for traffic from within the VPN, but a different route to the same node may include a firewall and therefore be preferred for traffic from outside the VPN.
  • CE 1 could specify the permitted scope of dissemination by using, say, the BGP communities attribute (RFC 1997) in the update message, or it could distinguish between different dissemination scopes by using separate channels between it and PE 1 (e.g., by using different ones of PE 1 's IP addresses) for the different scopes.
  • RRC BGP communities attribute
  • PE 1 must make this distinction in BGP messages that it sends to others of the SP's routers, because the roles of various SP routers as edge and transit routers is not in general the same for intra-VPN traffic as they are for inter-VPN traffic.
  • PE 1 may prepend a first VPN identifier, say, V I , to prefixes in routes intended only for intra-VPN advertisement and a second identifier, say, V E , to prefixes in routes whose extra-VPN advertisement is permitted.
  • Further identifiers may be used for further dissemination scopes. For the sake of discussion, though, we will assume that VPN V uses the SP as its internal backbone only and that the SP has accordingly assigned VPN V only one VPN identifier.
  • transit routers do not need the reachability information that CE 1 has shared with PE 1 . So PE 1 does not send the BGP message to the transit routers, and it may not send it to all edge routers. But FIG. 1 depicts only one other edge router, router PE 2 , and PE 1 does send the BGP message to PE 2 , because that router is connected directly to VPN V. Those skilled in the art will recognize, though, that the message does not have to be sent as part of an actual BGP session between PE 1 and PE 2 . In some large service providers, it is not considered practical for each BGP speaker to maintain BGP sessions with all other BGP speakers.
  • route reflectors act as intermediaries, maintaining sessions either directly or through other route reflectors with each of the BGP speakers and thereby propagating the necessary routing information. In that way, the number of IBGP sessions increases only linearly with the number of BGP speakers. But the diagram shows only two PE routers, so it includes no route reflectors.
  • FIG. 5 illustrates that message's format. Since it is a BGP update message, its format is similar to the one that CE 1 sent to PE 1 . Instead of using the conventional NLRI field to contain reachability information, though, PE 1 obtains the greater format flexibility needed for the VPN-IPv 4 address by using a “multiprotocol reachability information” type of attribute field, which has its own NLRI subfield. As FIG. 5 's fourth row indicates, this type of attribute's code is 14 . The first three octets of this type of field specify the address family that the attribute value will use to represent the reachability information in the NLRI field, and FIG.
  • the Tagged VPN-IPv 4 format starts with a four-byte tag, whose value is T 3 in the example. This is followed by a field representing the prefix-field length, which is four bytes in the example.
  • the prefix field's first two bytes encode the value V, which identifies the VPN, and the second two bytes have the value 0A01 16 , i.e., the sixteen-bit address prefix 10.1.
  • the other fields that FIG. 5 's fifth row depicts include a next-hop field and a field that tells how long the next-hop field is.
  • the next-hop field contains a six-byte VPN-IPv 4 address whose first two bytes are zero the next hop is not one of the customers' routers—and whose remaining four bytes are PE 1 's IP address.
  • Appendix C describes messages of this general type in more detail.
  • PE 2 extracts the NLRI field's VPN-IPv 4 value and decodes it into a VPN identifier and an IPv 4 address prefix. In its FIB for that VPN, it creates an FIB entry that maps the IPv 4 prefix to a next hop and a tag-stack operation.
  • the next-hop value is PE 1 's address (since PE 1 's address appeared in the message's next-hop field).
  • the tag-stack operation is “push tag value T3 onto the tag stack.” Since PE 1 is not a direct neighbor of PE 2 , this is a recursive FIB entry.
  • BGP Update messages concerning VPN-IPv 4 address prefixes cause modification only of the VPN-specific FIB, not of the general FIB.
  • PE 2 would additionally install that IPv 4 prefix, next hop, and tag-stack operation in the FIBs for all the VPNs to which that information's dissemination.
  • the illustrated embodiment employs only a single service provider to provide the VPN's backbone, there is no reason why more than one SP, whose facilities constitute more than one autonomous system, cannot cooperate to implement the present invention's teachings. In that case, the tag-binding and reachability information would further flow from one SP to the next by EBGP in the FIG. 5 format.
  • the egress PE router in one of the SP networks could use BGP to distribute a tag binding for a particular VPN-IPv 4 address to the BGP border router between the two SP networks. That BGP border router would then distribute a tag binding for that address to the ingress PE router.
  • PE 2 then relays this information to CE 2 by sending it an EBGP message similar to the one that CE 1 sent to PE 1 .
  • this message's NLRI field indicates that hosts whose addresses begin with prefix 10.1 are reachable
  • its next-hop attribute field indicates that the next hop in the route to those hosts is PE 2
  • the AS-path attribute field indicates that the path to that prefix traverses autonomous systems A 1 and A 3 .
  • CE 2 When CE 2 receives this message, it creates an FIB entry that maps prefix 10.1 to a next hop of PE 2 . Note that CE 2 need not support tag switching. CE 2 must also use its own IGP to inform other routers (not shown) at its site that it has a route to hosts whose addresses begin with prefix 10.1.
  • the various routers have the routing information that they need when CE 2 sends to PE 2 a data packet P whose destination address is 10.1.0.1, which FIG. 1 depicts as “D1”.
  • CE 2 To send P, CE 2 looks up address 10.1.0.1 in its FIB and finds that the longest matching address prefix is the sixteen-bit prefix 10.1. The corresponding next hop is PE 2 . CE 2 is directly attached to PE 2 , so it forwards P to PE 2 over the data link connecting the two routers.
  • PE 2 receives packet P and notes that it received that packet from a particular VPN, VPN V. For the sake of simplicity, we assume that PE 2 concludes this from the fact that it receives the packet over a point-to-point interface dedicated to communication with CE 2 . But edge routers can base that determination on other factors instead. For example, suppose that the interface the interface is a local-area-network interface over which packets from different VPNs could arrive. In that case, CE 2 might rely on the data-link source address and base the determination on its knowledge of the VPN's constituent systems. Other implementations may base the source determination on cryptographic authentication data that the packet contains. In a similar vein, the log-in procedure performed by a customer contacting the PE router by way of a dial-in link may result in the PE router's obtaining information from an authentication server, and it may base its identification of the source VPN on this further information.
  • the PE router identifies the source VPN, and the source VPN in this case is VPN V. So PE 2 looks up P's destination address in its FIB that is specific to VPN V. It finds that the longest matching address prefix is the sixteen-bit prefix 10.1. (In this example, which focuses on intra-VPN communication, we assume that PE 2 further infers from the source determination that the packet is not to be permitted outside VPN V, so PE 2 would not look further if it failed to find a match.
  • PE 2 might look in the FIBs of other VPNs, which may have indicated their availability to forward packets to that address.)
  • the corresponding next hop is PE 1 , and the tag-stack operation is “push T 3 on the tag stack.” So PE 2 creates a tag stack for P and pushes T 3 onto it. Since PE 2 is not directly connected to PE 1 , P 2 performs a recursive lookup in its general FIB.
  • PE 2 has an FIB entry corresponding to PE 1 's thirty-two-bit address, that the next hop in that FIB entry is P 2 , and that the tag-stack operation in that FIB entry is “push T 2 onto the tag stack.” So PE 2 pushes T 2 onto P's tag stack. The stack now has two tags; the top tag T 2 , and the bottom tag is T 3 . PE 2 tags P with this stack and sends P over the data link to P 2 , as FIG. 1 shows diagrammatically.
  • T 2 maps to a TIB entry whose next hop is P 1 and whose tag-stack operation is “replace the top tag value with T 1 .” So P 2 as performs the tag-stack operation and sends the packet over the data link to P 1 . (At this point, packet P's top tag is T 1 , and its bottom tag is T 3 .)
  • T 1 maps to a TIB entry whose next hop is PE 1 and whose tag-stack operation is “pop the tag stack.” So P 1 performs the tag-stack operation and sends the packet over the data link to PE 1 . (At this point, packet P is carrying only one tag, T 3 .)
  • PE 1 When PE 1 receives packet P, it attempts to forward it by looking T 3 up (which is now at the top of the stack) in its TIB.
  • T 3 maps to a TIB entry whose next hop is CE 1 and whose tag-stack operation is “pop the tag stack.” So PE 1 performs the tag-stack operation and sends the packet over the data link to CE 1 . Note that PE 1 has popped the last tag off the tag stack before sending the packet to CE 1 . So CE 1 receives an untagged packet, which it forwards in the conventional way.
  • FIG. 7 whose topology is identical to that of FIG. 1, but we assume that P 1 and P 2 are ATM switches and that PE 1 and PE 2 are routers that attach to P 1 and P 2 , respectively, over ATM interfaces.
  • FIG. 8 depicts the typical data message that, say, PE 2 would send to P 2 in such an arrangement.
  • FIG. 8 is best understood by comparison with the second row of FIG. 2 's Ethernet example.
  • the Ethernet header ( DEST . ADDRESS , SOURCE ADDRESS , and TYPE ) and trailer (CRC) encapsulate a payload in the form of tag fields and an IP datagram.
  • FIG. 7 whose topology is identical to that of FIG. 1, but we assume that P 1 and P 2 are ATM switches and that PE 1 and PE 2 are routers that attach to P 1 and P 2 , respectively, over ATM interfaces.
  • FIG. 8 depicts the typical data message that, say, PE 2 would send to P 2 in such an arrangement.
  • FIG. 8 is best understood by comparison with
  • FIG. 8 's third row depicts an ATM frame, and that drawing's fourth and fifth rows show that the frame's payload is similar to that of FIG. 2 's Ethernet frame.
  • the only difference in the payloads is that FIG. 8 's fifth row represents the left (top) tag by question marks, which indicate that the top tag's contents do not matter.
  • FIG. 8 's third row is the basic unit of transmission, and it can vary in length to as much as 64 Kbytes of payload.
  • FIG. 8 's third row depicts one, known as “AAL5,” that would typically be employed for user data.
  • ATM actually breaks such frames into fixed-size cells.
  • Each cell consists of a header and a payload, as FIG. 8 's second row illustrates.
  • the header's PTI field depicted in FIG. 8 's first row, is to indicate whether the cell is the last one in a frame. If it is, its last eight bytes form the frame trailer field that FIG. 8 's third row depicts.
  • the trailer indicates how much of the preceding cell contents are actual payload, as opposed to padding used to complete fixed-size cell.
  • VPI/VCI field The only other header field of interest to the present discussion is the VPI/VCI field of FIG. 8 's first row.
  • ATM systems organize their routes into “virtual channels,” which may from time to time be grouped into “virtual paths.”
  • Each switch associates a local virtual path/virtual channel indicator (VPI/VCI) with a channel or path that runs through it.
  • VPI/VCI virtual path/virtual channel indicator
  • an ATM switch consults the cell's VPI/VCI field to identify by table lookup the interface by which to forward it, replaces that field's contents with a value indicated by the table as being the next switch's code for that path or channel, and sends the resultant cell to the next switch.
  • the function performed by the VPI/VCI field enables it to serve as the stack's top tag.
  • PE 1 will bind a VPI/VCI tag, call it VC 1 , to the address of PE 1 and distribute that binding to P 1 .
  • P 1 will bind a VPI/VCI tag, call it VC 2 , to the address of PE 1 and distribute that binding to P 2 .
  • P 2 will bind a VPI/VCI tag, call it VC 3 , to the address of PE 1 and distribute that binding to PE 2 .
  • PE 2 when PE 2 receives from CE 2 a packet destined for a site that is in CE 2 's VPN and is reachable via CE 1 , it does the following.
  • P 2 on a cell-by-cell basis, replaces VC 3 with VC 2 and forwards the resultant cells to P 1 .
  • P 1 replaces VC 2 with VC 1 on a cell-by-cell basis and forwards the resultant cells to PE 1 .
  • PE 1 eventually collects all the frame's cells and reassembles them.
  • PE 1 then extracts the resultant frame's user data, pops the tag stack, and forwards the resultant frame in accordance with the resultant tag stack (which now contains a single tag, T 3 ).
  • T 3 which now contains a single tag
  • the top tag in the tag-stack field never has any meaning. But now suppose that only P 1 is an ATM switch: P 2 and PE 1 are routers attached to P 1 via ATM interfaces. Then the PE 2 -P 2 link would contain FIG. 2 -style packets, P 2 would base its decision on the top tag-field tag, and it would forward ATM cells in response.
  • each VPN will have two VPN IDs. One will be the “Internal VPN ID,” and one will be the “External VPN ID.”
  • Each PE router will translate the IPv 4 addresses from its attached VPNs to one or the other or to both of these VPN-IPv 4 addresses. The rules for doing so will be discussed later.
  • a VPN-IPv 4 address whose VPN ID is the Internal VPN ID of its VPN must not be distributed by any PE router to any CE router, unless that CE router is in that VPN.
  • a PE router that distributes an IPv 4 address to another PE router must assign it the NO_EXPORT Community Attribute.
  • NO_EXPORT Community Attribute According to RFC 1997, “BGP Communities Attribute,” this attribute means:
  • NO_EXPORT_OUTSIDE_VPN a new Community Attribute value
  • NO_EXPORT seems adequate and makes it easy to accommodate the case where the CE router itself specifies a NO_EXPORT attribute.
  • ASN Autonomous System Number
  • the P-network is already in use as an internet transit network, it will likely already have a globally unique ASN, and this can be used on these IBGP connections.
  • a particular site is a “stub site,” it is not necessary for the CE router to talk BGP to the PE router, though under certain circumstances it may be desirable for it to do so.
  • the CE router will need to talk BGP to the PE router. This is true whether the C routers talking BGP are talking to other C routers at the site, to other C routers at different sites of the same VPN, to other C routers of different VPNs, or even to routers in the public internet.
  • a CE router When a CE router distributes routing information to a PE router, the intention is that the information ultimately be distributed to one or more other CE routers.
  • One PE router uses IBGP to distribute the information to another, and the latter redistributes it to another CE router.
  • the number of globally unique ASNs is limited, and it is not feasible to assign one to each individual VPN site. There is however a “private ASN” numbering space containing 1023 ASNs, which a service provider can administer as he sees fit. So the Site ASNs must be taken from the private ASN space. Since the size of the private ASN space is limited, it is desirable to use the same ASN numbers in different VPNs.
  • CEBGP Confederation EBGP
  • a BGP confederation is a set of Autonomous Systems (ASs) that appear as a single AS to all ASs not in the Confederation. Only within the Confederation are the component ASs visible. That is, externally to the Confederation, the Confederation has a single ASN. Within the Confederation, each “Member AS” of the Confederation has its own ASN, which is distinct from the Confederation's ASN. The distinction shows up primarily in BGP Confederation procedures for AS-path manipulation, which we recommend for inter-VPN communication. (This does not imply that BGP Confederation procedures affecting other attributes should also be used.)
  • BGP maintains loop freedom by associating an AS-path with each route. Roughly, this is a list of the ASs through which a packet must travel to reach the destination.
  • a router distributes a route via EBGP, it adds its own ASN to the AS-path.
  • a router receives a route via EBGP it checks to see if its own ASN is already in the AS-path. If so, it discards the route, in order to prevent the loop.
  • a router that is in a Confederation When a router that is in a Confederation receives a route over an EBGP connection, it will discard the route if the AS-path contains the Confederation's ASN. When a router receives a route over a CEBGP connection, it will discard that route if the AS-path contains the Member ASN of that router, and that Member ASN is marked as being within the Confederation.
  • each site containing a CE router that talks BGP to a PE router would have a Site ASN taken from the Private ASN space. Then these Site ASNs need be unique only within a single VPN: they can be reused in other VPNs.
  • the P network is part of each such Confederation and needs to have a Member ASN that can be used within each Confederation.
  • the P network can have a single ASN that it uses as its Member ASN in all Confederations. If it has a globally unique ASN, this can be used.
  • a VPN spans multiple service providers, then its Site ASNs must be unique across all the providers, and each P network must use a globally unique ASN.
  • a router When a router receives a route whose AS-path contains its site number, it conventionally rejects the route if the site number is not marked as being part of the confederation, and it is preferable for CE routers to follow this policy. Otherwise, since a VPN is modeled as a Confederation, care must be taken to ensure that whenever two C routers in the same VPN have a direct BGP connection with each other (i.e., a “backdoor” connection between routers in the same VPN, at the same or different sites), they talk either IBGP or CEBGP, never regular EBGP. When talking CEBGP, each router would use its Site ASN as its ASN, for the purpose of (a) filling in the “My Autonomous System Number” field in the BGP Open message, and (b) adding its ASN to the AS-path.
  • a PE router When a PE router receives from a CE router over a CEBGP connection, routes to IPv 4 addresses, the PE router will immediately translate those addresses to VPN-IPv 4 addresses, using the Internal VPN ID of the CE's VPN. (“Immediate translation” means that the addresses appear in BGP's “adj-rib-in” table as VPN-IPv 4 addresses.)
  • VPN-IPv 4 addresses When a PE router distributes VPN-IPv 4 addresses to a CE router over a CEBGP connection, it first converts them to IPv 4 addresses by stripping off the VPN ID.
  • the External VPN ID of a particular VPN can have the same value as the VPN ASN.
  • the Internal VPN ID must have a different value. It may be convenient for these values to be algorithmically related, but this is not required.
  • a VPN spans multiple service providers, its Internal VPN ID and its External VPN ID must be globally unique. Otherwise, they must be unique only within the scope of a single service provider. Note also that any quantity that is used as an External VPN ID of one VPN may not be used as an Internal VPN ID of any other VPN, and vice versa.
  • each VPN Since each VPN is modeled as a BGP Confederation, each VPN appears as an AS to each other VPN. Communication between two VPNs is modeled as communication between two ASs, using the P network as the transit AS. Therefore if a CE router uses BGP to export routes, via a PE router, to another VPN, it must do so via a regular EBGP connection to the PE router. Of course, on the EBGP connection it uses the VPN ASN, not the Site ASN.
  • the P-network has a globally unique ASN, it can be used both within a Confederation and between Confederations.
  • each router would use its Confederation ASN as its ASN for the purposes of (a) filling in the “My Autonomous System Number” field in the BGP Open message, and (b) adding its ASN to the AS-path.
  • a CE router may need to have two BGP connections to a PE router, an EBGP connection (for inter-VPN connectivity) and a CEBGP connection (for intra-VPN connectivity).
  • a PE router When a PE router receives, from a CE router over an EBGP connection, routes to IPv 4 addresses, the PE router will immediately translate those addresses to VPN-IPv 4 addresses, using the External VPN ID of the CE's VPN. When a PE router distributes VPN-IPv 4 addresses to a CE router over an EBGP connection, it will first convert them to IPv 4 addresses by stripping off the VPN ID.
  • a site in a VPN may maintain a backdoor connection to the public internet, via an EBGP connection. If this EBGP connection is not via the same service provider that is providing the VPN, the VPN ASN must be from the public AS numbering space. Otherwise, it may be from the private AS numbering space, and the C router maintaining the EBGP connection to the internet should be configured to strip all private ASNs from the AS-path.
  • P routers with EBGP connections to routers outside the P network will not accept routes to VPN-IPv 4 addresses over those connections. To do so would allow routers outside the Service Provider's control to spoof routes to the VPN, thereby compromising the security that the customer expects. If it is necessary to make any exceptions to this rule (to support, say, multi-provider VPNs), the security effects of those exceptions would need to be carefully considered.
  • CE router's site does not have any backdoor connections, neither a CEBGP nor an EBGP connection is necessary. In this case, all the information that would be passed via BGP can be statically configured in the PE router. The site will not have a Site ASN. IBGP between PE routers is still used to pass routing information about one site to the others.
  • a “backdoor connection” we mean a BGP connection between a C router at the site and any router other than a PE router. If two sites in a particular VPN are inter-connected via static routing and/or IGP, then we model them as a single site, rather than as two sites with a backdoor connection.
  • CE router's site does not have any backdoor connections to other VPNs (or to the public internet), but it is desired to have a BGP connection to the PE router (either for the reason given in the prior paragraph, or because there are backdoor connections to other sites in the VPN), it is necessary to have a CEBGP connection between CE router and PE router.
  • routes distributed over CEBGP will not thereby be distributed to any other VPN.
  • distribution of routes to other VPNs can still be achieved via configuration of the PE router.
  • the CE router's site has backdoor connections to other VPNs (or to the public internet), and if it serves as a transit network for traffic from other VPNs (or the public internet), then the CE router must run EBGP with the PE router, in order to properly distribute the routes for which it is a transit network.
  • a VPN has multiple sites that have EBGP connections to PE routers, then there must also be a CEBGP connection from each of those sites to a PE router.
  • NO_EXPORT Community Attribute will be included as an attribute of that route if the VPN ID of that address is an Internal VPN ID.
  • a PE router uses IBGP to distribute a route to a VPN-IPv 4 address to another PE router (or route reflector), and the VPN ID of that address is an External VPN ID, Community Attributes must be included that specify the set of VPNs to which the address in question is to be exported.
  • the Community Attribute that is used to indicate that an address is to be exported to a particular VPN should be algorithmically derivable from that VPN's ASN, and vice versa.
  • the CE router may, with each address it distributes, include a set of Community Attributes, indicating the set of other VPNs (possibly including the public internet) to which the address is to be exported. If so, the PE router may be configured with a set of addresses from the C network that the CE router is authorized to export to a set of other VPNs. In that case, the PE router will remove (via inbound filtering) any unauthorized Community Attributes sent by the CE router. The PE router may be configured with a set of addresses from the C network that are to be exported to a set of other VPNs, even if the CE router does not include the necessary Community Attributes. In this case, the PE router must add (via inbound filtering) the missing Community Attributes.
  • a PE router When a PE router receives a route to an external VPN-IPv 4 address and that route is associated with a Community Attribute that identifies the VPN of a CE router to which that PE router is attached, then the route is a candidate for redistribution to the CE router. (Of course, a VPN-IPv 4 address is translated into an IPv 4 address, by having its VPN ID stripped off, before being distributed to a CE router.)
  • the PE router may be configured to allow only particular VPN-IPv 4 addresses to be distributed to a particular CE router, regardless of the Community Attribute. Or it may be configured to prevent the distribution of particular VPN-IPv 4 addresses to a particular CE router, regardless of the Community Attribute. In such cases, outbound filtering should be used to prevent distribution of such addresses to the CE router.
  • the Community Attribute can be used in a similar though somewhat different way to represent “Closed User Groups” (CUGs) of VPNs, rather than target VPNs.
  • CCGs Click User Groups
  • a CUG is a set of VPNs.
  • a CE router could associate a route to a particular address with one or more CUGs.
  • the PE router would strip any CUGs that the CE router is not authorized to use.
  • the PE router could also add additional CUGs, or could add CUGs when the CE router has not specified any.
  • the PE router would need to know which VPNs are members of which CUGs, so it could determine which other PE routers it needs to distribute the routes to.
  • a route with a CUG When a route with a CUG is received, it will be distributed over an EBGP connection to a CE router only if the PE router is configured with the knowledge that the CE router is a member of that CUG.
  • CUGs may simplify the configuration of the PE routers.
  • the set of EBGP/CEBGP speakers in a given AS is supposed to be “fully meshed” (or “fully reflected” through route reflectors). Otherwise, there is no way to ensure that communication between any two points is possible.
  • VPNs we do not want to require that communication between every pair of points be possible, so the PE routers need not in general be fully meshed.
  • a PE router A needs to talk IBGP to a PE router B only if A and B both attach to CE routers in the same VPN, or if A attaches to a CE router in VPN 1 that is exporting addresses to a VPN 2 , and B attaches to a CE router in VPN 2 .
  • the given PE router For each PE router that is to be an IBGP peer of a given PE router, the given PE router will know which VPNs the peer is interested in. If a PE router A has an IBGP peer B, and B is interested in VPN 1 , then A shall distribute a route to B if and only if one of the following two conditions holds:
  • the address corresponding to the route is a VPN-IPv 4 address in VPN 1 , or
  • the VPN ID of the VPN-IPv 4 address is the Internal VPN ID for VPN 1 , or
  • the VPN ID of the VPN-IPv 4 address is the External VPN ID for VPN 1
  • the route has a Community Attribute that indicates that it should be distributed into VPN 1 .
  • Each PE router before distributing a route, will also assign a tag for that route. This will be encoded, in a way to be defined, as an attribute of that route.
  • a PE router When a PE router redistributes over IBGP a route received from a CE router (whether it is received over EBGP or CEBGP), it should always put itself in as the next hop. This ensures that the next hop is always reachable in the P network's IGP (i.e., it does not require routes to all the CE routers to be injected into the P-networks' IGP). It also ensures proper interpretation of the tag that the PE router assigns to the distributed address prefix; the tag associated with an address prefix should be a tag assigned by the “next hop” for that prefix.
  • PE routers For the purpose of supporting VPNs, PE routers need to support the following capabilities:
  • PE routers may have “ordinary” EBGP and IBGP connections that have nothing to do with VPNs. On such ordinary connections, IPv 4 NLRI rather than VPN-IPv 4 NLRI is used; routes learned from CE routers will not be sent on such connections, unless the PE router is configured to export those routes to the public internet.
  • Any router with a BGP connection to the internet must ensure, through proper filtering, that it does not leak any routes to the internet that are not part of the P network's AS, or of the AS of some client network of the P network. When routes are leaked to the internet, all private AS numbers must be removed (via outbound filtering) from the AS-path.
  • Each PE router must be configured with the following information:
  • the PE router may maintain a static route to this address and need not redistribute this address into the IGP of the P network (as long as the PE router always sets itself as the next hop before redistributing routes received from the CE router). In this case, the same address may be reused for other CE routers, subject to the constraint that all the CE routers attaching to a given PE router have distinct addresses. If the PE router distributes this address into the P network's IGP, though, the address should be a unique address in the P network's address space.
  • This parameter can be omitted if no CEBGP connection is to be formed.
  • This parameter can be omitted if no EBGP connection is to be formed.
  • This parameter can be omitted if no CEBGP connection is to be formed.
  • viii A list of VPNs or CUGs to which the CE router can export addresses, and, for each such VPN, the set of addresses that are authorized to be exported to it.
  • the set of addresses may be “all.” For each such set of addresses, there needs to be an indication as to whether the PE router should allow the addresses to be exported if is the CE router attempts to export them, or whether the PE router should initiate the export of the addresses independently of any action on the part of the CE router. (The latter would be the only way to get export if there is no EBGP connection to the CE router.)
  • This set may be “all.”
  • the public internet shall be represented as VPN 0 .
  • IBGP connections will be opened to all such PE routers. If these are provided by only a few route reflectors, manual configuration is acceptable, but auto-discovery will be required as a practical matter if they are provided by a large number of other PE routers.
  • the addresses to be distributed intra-VPN will be those addresses distributed by the CE router over the CEBGP connection. Otherwise, the PE router needs to be configured with those addresses, or it needs to obtain them in some other way (such as ODR or RIP).
  • the addresses to be distributed inter-VPN will be those addresses distributed by the CE router over the EBGP connection. Otherwise, the PE router needs to be configured with those addresses.
  • the CE router will need to be configured to set up a CEBGP connection, or both a CEBGP and an EBGP connection, to a PE router. It must then be configured with an address of the PE router for each such connection. This address will be from the address space of the P network.
  • the CE router should have a static route to the PE router address. This route need not be redistributed into the C-network's IGP (though it should be safe to do so, because we are not trying to handle the case where there is addressing conflict between the C network and the P network).
  • the CE router does not use VPN-IPv 4 addressing, and does not assign tags to the addresses it distributes to the PE router.
  • CE router is not at a stub site, then proper administration must be done to ensure that BGP routes and/or default routes are injected into the IGP in a proper manner.
  • a CE router will distribute all routes to all destinations on its site over its CEBGP connection to a PE router. Routes to destinations on other sites (through backdoor routes) may also be distributed to the PE router on the CEBGP connection; this is a matter of policy of the C network.
  • a PE router When a PE router receives routes on the CEBGP connection, it will of course translate the IPv 4 addresses to VPN-IPv 4 addresses. It will also remove from each route any VPN Community attributes that may be present. It will add the NO_EXPORT community attribute, to prevent the route from being distributed out of the Confederation.
  • the PE router should check the AS-path of each route it receives from the CE outer to ensure that the appropriate Site ASN appears at the beginning.
  • a CE router may distribute any routes to a PE router on an EBGP connection. However, it should avoid distributing any route on such a connection unless it intends to export that route to another VPN, or to the public internet.
  • the PE router will ignore routes to any destinations that, according to the PE router's configuration, are not to be exported to other VPNs (including the public internet).
  • the PE router will, before further distributing it, add the VPN community for each other VPN to which the route may be exported, according to the PE router's configuration.
  • the PE router will remove any Community Attributes that do not correspond to VPNs to which the route may be exported, according to the PE router's configuration.
  • this procedure allows the CE router to specify a subset of those VPNs to which it should be exported. If this is allowed, then the PE router must be able to detect when an EBGP update removes a Community Attribute that used to be there, so the route can be withdrawn from the corresponding VPN.
  • the PE router should check the AS-path of each route it receives from the CE router to ensure that the correct value of the VPN ASN appears at the beginning. If not, the PE router may replace it with the correct value.
  • the PE router will convert all IPv 4 addresses from the CE router to VPN-IPv 4 addresses, using the External VPN ID of the CE router's VPN, before redistributing them. There is one exception: if a route is to be distributed to VPN 0 , it should be distributed as an IPv 4 address, without any Community Attribute. (This allows for distribution to the public internet via a BGP speaker that is not VPN-aware.)
  • a PE router will distribute to a CE router, over a CEBGP connection, routes to all VPN-IPv 4 addresses whose VPN ID is the Internal VPN ID of the CE router's VPN. No other routes shall be distributed on this connection.
  • the VPN-IPv 4 addresses will be translated to IPv 4 addresses before distribution.
  • the AS-path should be modified by prepending the P network's ASN.
  • a PE router will distribute a route with VPN-IPv 4 NLRI to a CE router on an EBGP connection only if both the following conditions hold:
  • the PE router is configured to allow the particular VPN-IPv 4 address to be exported to the CE router, and
  • the PE router received the router with a Community Attribute that corresponds to the VPN of the CE router, or to a CUG that is associated with that CE router.
  • VPN-IPv 4 addresses should be translated into IPv 4 addresses.
  • the AS-path should be modified by prepending the P network's ASN.
  • a PE router will distribute a route with IPv 4 NLRI to a CE router on an EBGP connection only if the PE router is explicitly configured to allow that address to be exported to the CE router's VPN. This allows the VPN to import addresses from the public internet.
  • FIG. 9 depicts a service-provider network simply as an oval, omitting all individual routers except PE 1 , PE 2 , and PE 3 .
  • PE 1 and PE 2 are edge routers with respect to customer nodes in a first VPN, VPN A
  • PE 3 is an edge router with respect to a second VPN, VPN B.
  • a target destination D in one VPN A is reached most directly through a customer edge router CE 1 at the same site.
  • VPN A has a firewall in CE 2 , and the policy is that any packets froth outside VPN A must go through CE 2 before they go to any VPN A destination.
  • CE 1 uses EBGP to advertise to PE 1 its access to D.
  • PE 1 recognizes that advertisement as being only for VPN A consumption.
  • PE 1 may be configured to recognize the interface used by CE 1 as one that advertises only intra-VPN reachability, or CE 1 may employ a NO_EXPORT value of the BGP community attribute in its advertisement.
  • PE 1 reports itself by IBGP as the next hop to destination Int(D) (where “Int(D)” represents the concatenation of VPN A's internal VPN ID with D's network address or prefix).
  • Int(D) represents the concatenation of VPN A's internal VPN ID with D's network address or prefix.
  • it knows which routers are edge routers with respect to VPN A and makes this advertisement only to them.
  • it is not so discriminating, but it is only such routers that adjust their FIBs in accordance with that information.
  • PE 2 thereby learns this information and uses it to construct an FIB entry in its per-VPN FIB corresponding to VPN A.
  • PE 3 attaches to a CE router that is in VPN A, then it, too, uses that information to construct an FIB entry in its per-VPN FIB corresponding to VPN A.
  • CE 2 Since CE 2 is to operate as the firewall, it must advertise itself as according access to all systems that the enterprise is willing to accord extra-VPN visibility, so it also uses EBGP to advertise node D's reachability. In some manner determined by local configuration, PE 2 recognizes that advertisement as being for extra-VPN A consumption, and it reports itself as the next hop to destination Ext(D) (where “Ext(D)” represents the concatenation of VPN A's external VPN ID with D's network address).
  • PE 3 thereby learns this information and uses it to construct an FIB entry in its per-VPN FIB corresponding to VPN A. (If, as the drawing does not show, PE 2 attaches to a CE router that is in VPN B, then it, too, would use that information to construct an FIB entry in its per-VPN FIB corresponding to VPN B.)
  • PE 2 looks in its per-VPN FIB for VPN A and sees that the next hop is PE 1 . This is the intra-VPN case.
  • PE 3 looks in its per-VPN FIB for VPN B and sees that the next hop is PE 2 .
  • the packet then gets sent to PE 2 , which sends it on to CE 2 .
  • CE 2 runs the packet through the firewall, and CE 2 attempts to forward the packet if the firewall does not reject it. Since the destination is not on-site, the packet gets sent to PE 2 .
  • PE 2 identifies the packet as coming from if VPN A.
  • PE 2 looks up D in its per-VPN FIB for VPN A, and sees that PE 1 is the next hop. The packet is then sent to PE 1 .
  • PE router when PE router receives a packet from a CE router, it can always identify the CE router from which the packet was just transmitted, so it can identify the VPN from which it just came. This enables the PE router to select the proper per-VPN FIB.
  • CE 2 ran the packet that it received in the above scenario through the firewall, it would ordinarily be preferred that only packets from outside VPN A receive this treatment, in which case CE 2 will need to know whether a packet that it receives is from a different VPN.
  • the way in which this is accomplished is in general a local-configuration matter, but the most-common approach would likely be for CE 2 to have two channels to PE 2 .
  • CE 2 has two different CE 2 interfaces for such communication. It would run BGP on both interfaces. On one of the interfaces, it would advertise reachability to some set of addresses in VPN A (including D) and possibly specify appropriate community attributes to ensure that this information is exported to VPN B.
  • PE 2 would use VPN A's external VPN ID for information received over this BGP connection. On the other interface, it would advertise reachability to its on-site addresses, and PE 2 would use VPN A's internal VPN ID for information received over this BGP connection.
  • tags to contain both the egress-router routing information and the egress-channel routing information, this is by no means a requirement.
  • tag switching because it tends to be more efficient, to use less overhead, and to lend itself to uses where the network administration controls the routes to a greater degree than dynamic IP routing ordinarily allows.
  • tag switching supports arrangements in which different VPN sites are attached to the networks of different autononmous service-providers that use BGP to exchange routing information and together form the back-bone-providing service-provider network.
  • tag switching lends itself to applications in which part of the backbone is an ATM link: tags can be put in the ATM header's VCI field.
  • tags can represent the exterior-routing information in a way different from the one that the illustrated embodiment employs.
  • the illustrated embodiment interprets the exterior-routing tag exemplified by T 3 to specify a next hop, it could instead simply contain, say, a VPN identifier that the egress router uses to disambiguate the regular IP address.
  • the applicability of the present invention's teachings is not so limited.
  • the internal-routing field could be provided simply as a tag associated with such an interface. That is, there would be no separate tag for the egress router's interface with the previous P router.
  • edge routers could use IGP to install host routes to all of their interfaces with client edge routers.
  • PE 2 For instance, would use BGP to specify the IP address of the interface between PE 2 and CE 2 as the next-hop address for VPN-IPv 4 addresses reachable through CE 2 .
  • PE 2 , P 2 , and P 1 would all use TDP to bind tags to the host route to that interface; PE 2 would not use the distinguished tag value meaning “pop the tag stack.”

Abstract

A service provider's routers (PE1, P1, P2, PE2) provide connections between and share routing information with routers (CE1, CE2) of a customer virtual private network (VPN) as well as routers of other customers' VPNs, which may have overlapping address spaces. A service provider's edge router (PE1) informed by the customer's router (CE1) that it will forward packets to a given prefix notifies the other edge router (PE2) that PE1 can forward packets to that address prefix if the destination is in the VPN to which CE1 belongs. PE1 also tells PE2 to tag any thus-destined packets with a particular tag T3. PE2 stores this information in a forwarding information base that it separately keeps for that VPN so that when PE2 receives from a router CE2 in the same VPN a packet whose destination address has that prefix, it tags the packet as requested. But PE2 also tags it with a tag T2 that the router P2 to which PE2 first sends it has asked PE2 to apply to packets to be sent to PE1. P2 routes the packet in accordance with T2, sending it to P1 after replacing T2 with a tag T1 that P1 has similarly asked P2 to use. P1 removes T1 from the packet and forwards it in accordance with T1 to PE1, which in turn removes T3 from the packet and forwards it in accordance with T3 to CE1. In this manner, only the edge routers need to maintain separate routing information for separate VPNs.

Description

CROSS REFERENCE TO RELATED APPLICATION
This is a division of U.S. patent application Ser. No. 08/997,343, now U.S. Pat. No. 6,399,595 which was filed by Yakov Rekhter and Eric C. Rosen on Dec. 23, 1997, for Peer-Model Support for Virtual Private Networks with Potentially Overlapping Addresses.
BACKGROUND OF THE INVENTION
The present invention is directed to communications networking. It is directed particularly to providing routing for private wide-area networks.
1. Private Wide-Area Networks
An enterprise that has many sites can build a private wide-area network by placing routers at each site and using leased lines to interconnect them. A router that has a wide-area connection to another router may be called a “backbone router.” The “backbone network” is the set of backbone routers and their interconnections.
If every backbone router is connected to every other backbone router, the backbone network is said to be “fully meshed.” In a fully meshed backbone network, data that travel from one site to another go through the backbone router at an origin site (“ingress router”), travel over the leased line to the backbone router at the target site (“egress router”), and then enter the target site. More commonly, though, the backbone network is not fully meshed; a router is connected to only a small number of others (three or four). In such a sparse topology, the ingress and egress routers may not be directly connected. In this case, data may have to pass through several additional, “transit” routers on the way from ingress to egress.
In a private network like this, the design and operation of the backbone network is the responsibility of the enterprise. A routing algorithm must run in the backbone routers, enabling them to tell each other the addresses of the destinations to which they can respectively afford access.
It is worth noting that a leased line is not actually a piece of wire going from one site to another. It is really a circuit through some circuit-switching network. But this is of no import to the enterprise network manager, to whom those circuits can be considered simple unstructured pipes. Conversely, although the telephone network itself requires considerable management, the telephone-network managers do not need to know anything about the enterprise backbone network; to them, the telephone network just provides point-to-point connections. They do not need to know what role these connections might be playing in an enterprise data network.
We may say that the enterprise network is “overlaid” on top of the telephone network. The enterprise network can be called the “higher layer” network, the telephone network the “lower layer” network. Both networks exist, but each is transparent to the other. The enterprise's backbone routers exchange routing information with each other, but the telephone switches do not store or process that routing information. That is, backbone routers are “routing peers” of each other, but they are not routing peers of the telephone switches. This way of building a higher-layer network on top of a lower-layer network is called the “overlay model.”
2. Virtual Private Networks
Wide-area enterprise networks are now more likely to be built on top of frame-relay and ATM networks than on top of circuit-switched (telephone) networks. Whereas a telephone network really provides circuits between backbone routers, a frame-relay or ATM network provides “virtual circuits” between backbone routers. But this changes nothing as far as the enterprise's routing task is concerned; the overlay model still applies even though the lower-layer network is now a frame-relay or ATM network rather than a circuit-switched one, i.e., even though virtual rather than fixed circuits make the point-to-point connections between backbone routers. The two networks are still transparent to each other. The enterprise network manager still has a wide-area backbone to design and operate. However, because the circuits are “virtual,” this is usually called a “virtual private network” (VPN) instead of a “private network.”
Since the two networks are transparent to each other in the overlay model, that model is distinguished by the fact that the enterprise's backbone routers do not share with the (service provider's) frame-relay or ATM switches the routing information that they must share with each other. This causes inefficiency when the enterprise's backbone routers are not fully meshed. In such networks, some packets go from the ingress router through one or more transit routers before they reach the egress router. At each one of these “hops,” the packet leaves the frame-relay or ATM network and then enters it again. This is sub-optimal—there is little value in having a packet go in and out of the frame-relay or ATM network multiple times.
This problem can be avoided by making the enterprise backbone fully meshed, but that causes problems of its own. The number of virtual circuits the enterprise has to pay the service provider for to make the network fully meshed grows as the square of the number of backbone routers. Apart from the cost, routing algorithms tend to scale poorly as the number of direct connections between routers grows. This causes additional problems.
The overlay model also tends to result in extra traffic when multicast is in use. It is usually impractical or undesirable for the “lower layer” network to do the necessary packet replication, so all packet replication must be done in the “higher layer” network, even if a number of replicated packets must then follow the same “lower layer” path up to a point.
3. The Peer Model
Since these considerations all impose upon the resources of an enterprise for which communications is not necessarily a core competence, a service provider (“SP”) can afford its customers greater value if it absorbs the task of designing and operating the backbone. More specifically, the SP should so organize and operate the backbone that, from the point of view of a particular site administrator, every enterprise network address not located at a given site is reachable through the SP's backbone network. How the SP's backbone decides to route the traffic is the SP's concern, not that of the customer enterprise. So the customer enterprise does not really need to maintain a backbone router at each site; it just needs a router that attaches to one of the SP's backbone routers. As will become apparent, providing such an organization involves abandoning the overlay model for a different model. The new model will be called the “peer model” for reasons that will be set forth below.
Terminology:
C-network: the enterprise network, consisting of C-routers, which are maintained and operated by the enterprise.
P-network: the SP network, consisting of P-routers, which the SP maintains and operates.
CE-router: an “edge router” in the C-network, i.e., a C-router that attaches directly to a P-router and is a routing peer of the P-router.
PE-router: an “edge router” in the P-network, i.e., a P-router that attaches directly to a C-router and is a routing peer of the C-router.
If a P-router is not a PE-router, i.e., not an edge router, it is a transit router. The concept of edge and transit routers is relative to specific VPNs. If a given one of the SP's routers receives a given VPN's traffic from and forwards it to only others of the SP's routers, the given router is a transit router vis-à-vis the given VPN. Yet that same router may receive another VPN's traffic from and/or forward it to one of that other VPN's edge routers, in which case the given SP router is an edge router from the other VPN's point of view.
In the conventional peer model, where “virtual routers” (i.e., one instance of the routing algorithm per VPN) are used, all C-routers within the same VPN are routing peers of each other. But two C-routers will be routing adjacencies of each other only if they are at the same site. Each site has at least one CE router, each of which is directly attached to at least one PE router, which is its routing peer. Since CE routers do not exchange routing information with each other, there is no virtual backbone for the enterprise to manage, and there is never any need for data to travel through transit CE routers. Data go from the ingress CE router through a sequence of P-routers to the egress CE router. So the resultant routing is optimal. These clear customer benefits have led certain SPs to adopt the peer model.
The conventional peer-model approach also enables the SP to solve certain problems that arise from using a common backbone network for more than one client. One of these is address duplication. Although there is an international assigned-number authority from which unique addresses can be obtained, many enterprise networks simply assign sign their private-network addresses themselves. So their addresses are unique only within the particular enterprise: they may duplicate addresses that another customer enterprise uses. An SP trying to use, say, an Internet-Protocol (“IP”) backbone as the backbone for different enterprise networks having overlapping address spaces needs to provide its P-routers with a way of identifying and selecting a route to the one of potentially many same-address destinations to which it should forward a packet.
So the SP makes use of a “virtual router.” When a PE router receives a packet received from a CE router, the PE router “tags” the packet with an indication of the C-network where it originated. It then bases its determination of what router to forward the packet to not only on the packet's destination address but also on the identity of the originating C-network. At each subsequent hop, the router looks up the packet's destination address in the forwarding table specific to the C-network that the tag designates.
This also solves another multiple-customer problem, that of the access control. If an enterprise buys network-backbone service from an Internet SP, it wants some assurance that its network receives only packets that originated in its own network. It also wants to be sure that packets originating in its network do not leave the enterprise network by accident. Of course, two enterprises might want to be able to communicate directly, or to communicate over the Internet. But they want such communication to occur only through “firewalls.” By using the virtual router, the SP solves this problem, too.
SUMMARY OF THE INVENTION
The above-identified parent patent applicaton describes a way for an SP to provide its customers the peer model's advantages at costs considerably lower than those that the conventional virtual-router approach exacts. The present invention can be used to enable such systems to help support the customer network's security measures. A provider network employing this technique associates internal and external identifiers, which we call “VPN IDs,” with a customer network and employs these selectively in forwarding reachability messages relating to customer nodes.
Specifically, a provider edge router linked to a given customer's edge router in a system that employs the present invention's teachings will ordinarily relay reachability information concerning customer sites from that router only to provider edge routers similarly linked to other edge routers of the same customer, to which they will in turn forward the reachability information. In doing so, it will include the customer's internal VPN ID in the message so that the receiving provider router can disambiguate the possibly non-unique IP address that the reachability message specifies. Those other provider edge routers will not forward the information to other outside routers that are not part of the nework of the customer involved. But there is at least one of the same customer's edge routers from which a reachability message will cause the provider edge router linked to it to relay the reachability information to other provider edge routers and include the customer network's external VPN ID in doing so. This will typically be a router through which packets entering the customer's network must pass through a firewall, so it is the one to which traffic from outside that network should be sent.
When a provider edge router then receives from outside that customer network a packet directed to the address whose reachability was advertised with the customer's external VPN ID, it forwards the toward the provider edge router that attached the external VPN ID to the reachability message that advertised the destination, and that router can send it to the firewall site. In contrast, packets from within the customer network can be sent to through provider edge routers that used the internal VPN ID for reporting the destination's visibility.
BRIEF DESCRIPTION OF THE DRAWINGS
The invention description below refers to the accompanying drawings, of which:
FIG. 1 is a topological diagram of a VPN and a tagging sequence that its routers employ;
FIG. 2 is a diagram that illustrates the format of a tagged packet;
FIG. 3 is a diagram of the environment and format of a tag-distribution-protocol protocol data unit;
FIG. 4 is a diagram that illustrates the format of a conventional Border Gateway Protocol protocol data unit and its environment;
FIG. 5 is a diagram that illustrates the format and environment of a Border Gateway Protocol protocol data unit used to distribute VPN-distinguishing reachability information and tags; and
FIG. 6 is a diagram that illustrates the format of another conventional Border Gateway Protocol protocol data unit and its environment;
FIG. 7 is a topological diagram of a VPN that employs ATM switches in implementing the present invention's teachings;
FIG. 8 is a diagram of an ATM frame used in the FIG. 7 embodiment; and
FIG. 9 is a topological diagram used to illustrate inter-VPN communication.
DETAILED DESCRIPTION OF AN ILLUSTRATIVE EMBODIMENT
Overview
Before we describe an embodiment of the invention in detail, we will employ FIG. 1 to present a brief overview of its operation.
FIG. 1 depicts a very simplified topology for illustrating an SP's connections between two parts of a customer enterprise C's VPN. Two of the enterprise's edge routers CE1 and CE2 are located remotely from each other, and the customer enterprise has contracted with the SP to provide connections between the customer's routers such as CE1 and CE2 to form a VPN V. Among the SP's resources are edge routers PE1 and PE2 and further, transit routers P1 and P2 that together form a path between CE1 and CE2.
Consider a packet that a router CE2 receives from a location (not shown) in VPN V, and suppose that the contents D1 of the packet's destination-address field is the address of a system in VPN V at CE1's location. We assume that CE2 has interfaces over which it could potentially have forwarded the packet to routers, not shown in the drawing, to which it is directly linked but that it concludes by consulting stored routing information that it should forward the packet over its interface to edge router PE2 in the SP.
We also assume that the SP network has another customer for which it uses those same resources to implement a different VPN, W, that also includes a (differently located) host having the same address D1. From the fact that PE2 has received the packet over its link with CE2, which is part of V rather than W, PE2 can tell which D1-addressed system should receive the packet. The VPNs that the SP cooperates with its customers to implement follow the peer model, so PE2 contains customer-network topological information that the customers have “leaked” to it. It stores this information in a separate routing table for each customer VPN to which PE2 is directly connected, so it can disambiguate the otherwise ambiguous address D1. From this information, PE2 knows that PE1 is the SP edge router to which it should direct the packet in order to reach the D1-addressed system in VPN V.
Now, the goal is to have that other edge router, PE1, forward the packet to CE1 so that the packet will reach the D1-addressed location in VPN V rather that the one in VPN W, to which PE1 may also be able to forward packets. Therefore, PE2 needs to include in the forwarded packet some indication that the intended D1-addressed host is the one in VPN V. But this should be done without requiring that transit routers P1 and P2 also maintain the VPN-specific information that the edge routers store.
PE2 achieves this by adding to the packet an internal-routing field that in the illustrated embodiment includes two constituent fields, namely, an egress-router field and an egress-channel field. The egress-router field takes the form of a tag that P2 can map to the next hop in the route to the egress edge router PE1, upon which the transit routers can base their routing decisions without requiring knowledge of the VPN involved. The egress-channel field takes the form of a tag that PE1 can interpret as specifying its interface with CE1 or as otherwise representing the channel that links it to VPN V.
Note that the goal of avoiding VPN-specific forwarding information could be achieved, though to a lesser degree, by having the internal-routing field include only an egress-channel field, not an egress-router field. The transit routers would then be basing their routing decisions on fields that in a sense do designate particular VPNs, but only because a given channel may lead only to nodes in a particular VPN. The transit routers still would not need to store information concerning locations in any of the customer sites.
But we prefer to use both an egress-router field and and egress-channel field. Specifically, PE2 “tags” the packet with two tags T2 and T3. As will be explained in detail below, P2 has arranged with its neighbors, including PE2, to tag with T2 any packets sent to P2 for forwarding along a route in which the SP edge router is PE1. T3 is a tag with which PE1 has arranged for the other edge routers to tag packets destined for certain VPN V locations if PE1 is the egress router.
To describe one way to tag a packet, we begin with FIG. 2's first row, which illustrates an exemplary link-level-protocol format. Different link-level protocols may be employed on different links. Examples of such protocols are the IEEE 802 protocol family and the point-to-point protocol (PPP) specified in the Internet community's Requests for Comments (“RFCs”) 1331 and 1332. Similar to the former is the Ethernet protocol. If the links connecting CE2 to PE2 and PE2 to P2 are Ethernet links, the link-layer frame that CE2 sends to PE2 takes the form that FIG. 2's top row depicts. Specifically, it consist of a link-level payload encapsulated by an Ethernet heater and trailer. The Ethernet trailer consists of a cyclic-redundancy-code (CRC) field used for error detection. The Ethernet header includes destination-address and source-address fields, which respectively contain the link-level (“hardware”) addresses of PE2's and CE2's interfaces to that link, and it also includes a type field used for demultiplexing the link packet's contents. In this case, the code represents the Internet Protocol (IP): the receiving router should interpret the contents as an IP “datagram” (as the IP protocol data unit is called), consisting of the IP header and IP data. (Of course, the payload could be a protocol data unit of some other network-level protocol, such as IPX or Appletalk.) Routers generally use network-protocol information to forward packets from one link to another along an inter-network path from the source interface to the ultimate destination interface.
FIG. 2's second row depicts the corresponding link-layer frame after PE2 has added T2 and T3. The Ethernet header and trailer take the same form as before. (For the sake of discussion, we assume that the link-level protocol is the same on the new link, although most embodiments will not exhibit such protocol uniformity.) Since the link-level source and destination are different, of course, the corresponding header fields' contents differ from those in the CE2-to-PE2 frame, and the CRC field contents, having been calculated from different frame contents, are different, too. But the difference most relevant to the present discussion is the type-field difference. Even though the frame does include an IP datagram, the type field does not contain the IP-indicating code. Instead, the code that it contains tells P2's interface that the frame's contents should be interpreted as a tagged packet.
This means that the four bytes immediately following the link-level header should be interpreted as an entry in a “tag stack,” whose format FIG. 2's third row illustrates. Specifically, the first twenty bits should be interpreted as the tag, and the twenty-fourth, bottom-of-stack-indicator bit S tells whether the packet contains any more tag-stack entries. (Appendix A contains a thorough description of the manner in which a tag-switching router can use the various fields, so we will not discuss the other, COS and TTL fields here.) In the example the tag field contains the “top” tag value T2, while the S bit is zero, indicating that this is not the bottom tag-stack entry. Therefore, P2 should interpret the next four bytes as a tag-stack entry, too. In the example, that entry contains a tag value of T3 and an indication that it is the bottom stack entry.
We now return to FIG. 1 and assume that PE2 has just sent P2 a packet thus tagged. Since T2 is a tag that P2 has arranged to have PE2 attach to packets that should follow routes in which PE1 is the egress router, P2 knows to forward that packet to the neighbor, P1, to which it sends PE1-directed traffic. (Again, P2 must make a routing decision because we assume that it additionally has direct links to other routers.) Note that P2 is able to make this decision without having had to maintain separate routing information for the VPN to which the packet is ultimately destined.
When P2 forwards the packet to P1, it replaces tag T2 with a new tag, T1, which P1 has asked its neighbors to attach to any packets that should be sent though PE1-egress routes, and P1 similarly makes its routing decision without having had to maintain separate routing information for the destination VPN. P1's stored routing information tells it to remove a tag rather than replace it, so it does so before forwarding the packet to PE1.
From tag T3, PE1 knows that it should forward the packet to the edge router CE1 that affords access to the D1-addressed location in VPN V. So PE1 forwards the packet to CE1 after removing tag T3. Since CE1 is concerned only with destination addresses in its own VPN, it is able to base its routing decision on D1 alone.
General Routing Features
Having now considered the illustrated embodiment's overall operation, we turn to a review of certain network-operation concepts that will provide a foundation for a more-detailed discussion of the operation described in the above overview. In a typical implementation, router circuitry for performing functions described below will be provided as communications hardware operated by one or more processors software-configured to perform the described operations. Those skilled in the art will recognize that such an approach is usually the most practical, because software configuration of a general-purpose processor enables a relatively small amount of hardware to serve as circuitry for performing many different functions concurrently. But the present invention can instead be implemented in any circuitry that performs the functions described.
1. The FIB
In conventional IP forwarding, each router maintains a table, sometimes called the “Forwarding Information Base” (FIB), that it uses to map from “address prefixes” to “next hops.” A router that receives a packet whose destination address begins with a given address prefix employs the next-hop entry as described below to determine the direction in which to forward the packet.
The manner in which the FIB is constructed is not critical to the present invention. In principle, a system administrator can provide it manually. More typically, routers build such tables automatically by employing routing algorithms to share topological information. But regardless of how the FIB is constructed, a conventional router R executes the following procedure (in principle) to find the next hop for a particular packet:
It searches the FIB for longest address prefix that matches the IP (or other network-level) address in the packet's network-level destination-address field.
It fetches the next-hop IP address, N, that corresponds to that address prefix.
If N is the address of a router to which R is directly connected (i.e., if there are no routers between R and the next hop), then the procedure ends, and R forwards the packet over its link to the router whose address is N.
If N is not the address of a router to which R is directly connected, then R performs a recursive lookup. That is, it searches the FIB for the longest address prefix that matches N, fetches the corresponding next-hop IP address N2, determines whether N2 is directly connected, etc. The recursion ends when R finds a next hop directly connected to it, and it R forwards the packet over its link to the router whose interface has that address.
In practice, as those skilled in the art will recognize, the FIB will have been preprocessed to eliminate the need to perform the recursion during actual packet processing. To avoid complicating the discussion unnecessarily, though, we omit a description of such conventional preprocessing.
A normal Internet router maintains only one FIB table. But routers in a provider of connections for many enterprises' peer-model VPNs need different tables for different VPNs, because a router may need to distinguish between potentially identical prefixes in different VPNs. (Each SP router also needs to maintain a general, i.e., non-VPN-specific, FIB. Unless explicitly stated otherwise, references below to the FIB mean the general FIB.) But transit routers, i.e., routers that are not directly attached to customer's VPN, do not need to maintain VPN-specific FIBs. (We consider a PE router to be “directly attached” to a particular VPN if it is directly attached to a CE router in that VPN.) And an edge router such as PE1 or PE2 needs to maintain, in addition to a general FIB, a separate FIB only for each VPN to which it is connected directly. The reason why this is so will become apparent as the description proceeds.
In the illustrated embodiment, each FIB entry actually differs somewhat from that described above, because the illustrated embodiment uses “tag switching.” When data-transmission speeds become high and network sizes become large, searching for longest matches to the packet's ultimate-destination address becomes onerous. So proposals have been made to reduce this burden by “tagging” the packets.
A tag is a field that routers use to make routing decisions. Unlike a network-level address, though, a tag is a true (unique) index to a given router's routing table, whereas the network (e.g., IP) address in the destination field of a packet's header is merely an invitation to a router to find the address prefix that constitutes the best match. By reducing the need for best-match searches, conventional tagging reduces a router's processing burden. And we use tagging in such a way as additionally to reduce routers' storage burdens, as will become apparent after a discussion of further tag-switching and other features.
One way to implement tag switching is to have routers tell their neighbors the tags they want to see in the packets that they receive. Specifically, a given router may decide to associate a particular tag with (“bind a particular tag to”) a particular address prefix. If so, it tells its neighbor routers that, when they forward it a packet destined for an address having that prefix, they should attach the specified tag so that the given router can go straight to the right table entry without having to do a best-match search. (Although the illustrated embodiment bases tagging on address prefixes, other embodiments may base it on some other packet attribute that is relevant to routing.)
When tag switching is used, the forwarding table does not merely map an address prefix to a next-hop IP address; it maps the address prefix to an ordered pair whose first element is a next-hop IP address and whose second element is a tag-stack operation. That is, an FIB next-hop entry contains both a next-hop IP address and a tag-stack operation.
Initially, we need to consider only two tag-stack operations:
No op.
Push a specified tag value onto the stack.
The “no op” value is the default tag-stack-operation entry. As will be explained below, neighbors' requests may result in that entry's being modified to contain a push operation.
When router R receives an untagged packet, it finds the longest address-prefix match to R's destination IP address, and it fetches the corresponding next-hop entry. If that next-hop entry's tag operation is “push a specified tag value onto the stack,” it pushes the specified tag value onto the tag stack that the packet includes. If it is necessary for R to perform a recursive lookup, it searches for another next-hop entry. If that next-hop entry also has a “push a specified tag value onto the stack” operation in it, that specified value is also pushed. If the recursion ends as a result of the second lookup, then two tag values may have been pushed onto the tag stack.
When the recursion ends (or if there is no recursion), R knows which of its directly connected neighbors is the next hop for the packet. It then transmits the packet to that next hop, using whatever data-link protocol is necessary in order to reach that next hop.
2. The TIB
When a router R uses tag switching, it fetches next-hop information in response to a tag, so it uses a routing table separate from the FIB, from which it fetches next-hop information in response to a destination address. This separate table is sometimes called the Tag Information Base (TIB). The TIB next-hop entries contain a next-hop IP address and a tag-stack operation. For our purposes, we need consider only three tag-stack operations:
remove the tag stack's last-added (“top”) value (“pop the stack”);
replace the top tag-stack value with a specified value; and
discard the packet.
When router R receives a tagged packet, it uses the packet's top tag as an index into the TIB and fetches the indicated entry. (Those skilled in the art will recognize that security requirements, local-link constraints, or other considerations may in some cases necessitate that the index into the TIB actually consist of both the incoming packet's tag and the interface on which it arrived, but the principle is best explained without complicating the discussion with those details.) In accordance with the fetched TIB entry, it either replaces the tag with a different value or pops the tag stack.
If the TIB entry's next-hop field is the address of one of R's directly connected neighbors, R uses the appropriate data-link protocol to send the tagged packet to that neighbor. If the next hop specified in the TIB entry is not a directly connected neighbor, on the other hand, then R (again, in principle) performs a recursive lookup by finding the FIB entry that corresponds to that address. (The FIB is used since this part of the search is based on an address, not a tag.) Then processing proceeds as described in “The FIB” above.
3. How Interior Routing Algorithms Modify the FIB and the TIB
As was stated above, the present invention does not require any particular mechanism for providing the contents of the FIB and the TIB. But considering one such mechanism, namely, routing protocols, helps one appreciate those contents' purpose. The types of protocols that it uses can be divided into interior gateway protocols (IGPs), exterior gateway protocols (EGPs), and tag-distribution protocols (TDPs). Routers in an inter-networking domain under single administration use IGPs to share topological information about that domain. Routers use EGPs to share extra-domain topological information. They use TDPs to distribute tags.
Typically, every router runs an IGP. Examples of such protocols are OSPF, EIGRP, and IS-IS. From time to time, a router sends to its same-domain neighbor routers IGP messages that “advertise” destinations to which it accords direct access. The neighbors in turn forward the messages to their neighbors. In some protocols the forwarding routers modify the messages in such a way that a message tells what route it took to reach the recipient, or at least how long the route was. In any case, the recipient thereby amasses topological information and decides on the basis of that information whether to enter into its FIB as the next hop to the advertised destinations the address of the router that forwarded it the message. So FIB entries that an IGP creates are always non-recursive: the next hop is always a directly connected neighbor.
The customer-enterprise routers may also use an IGP. Although the drawing does not show them, the customer enterprise would typically also have further routers at the same sites as CE1 and CE2, and those routers may use an IGP. But the customer enterprise's nodes that have access to each other only through the provider network do not use an IGP to exchange routing information with each other, so the routers at, for instance, CE1's site use an IGP only for routing-information exchange with other routers at the same site (or other sites to which there is customer-managed access), not for such exchange with routers at CE2's site.
When IGP maps address prefix X to next hop N, it may modify both the FIB and the TIB. The FIB modifications are as follows:
If the FIB already contains an entry that maps X to a next hop, and the next hop is N, then no change is made.
If the FIB does not already contain an entry that maps X to any next hop, or if the FIB already contains an entry that maps X to a next hop other than N, then IGP inserts an entry that maps X to N and removes any entry that maps X to a different router. In a tag-switching routine, the IGP process then determines whether N has sent R a message that binds X to some tag value T. If not, the FIB entry is inserted with the tag-stack operation “no op.” Otherwise, the FIB entry is inserted with the tag-stack operation “push T onto the stack.”
The TIB modifications are as follows:
If no FIB modification has been made, then no TIB modification is made, either.
If an FIB modification has been made, then R determines whether it has told any of its directly connected neighbors to tag X-destined packets with some tag value T. If not, it makes no TIB modifications. Otherwise, it looks up the TIB entry that corresponds to T.
If there is no corresponding TIB entry, R inserts one for tag T having a next-hop entry of N. If there is a corresponding TIB entry, it replaces the next-hop entry with N.
R then determines whether N has asked it to tag X-destined tags with some tag value T2. If not, the tag-stack operation is “discard the packet.” Otherwise:
If N's requested “tag” T2 for X-destined packets is a actually a distinguished tag value that means “pop the tag stack,” then N has not really asked that R place a tag on such packets but instead has asked that it merely remove one already in the packet. So TIB entry's tag-stack operation is “pop the tag stack.”
Otherwise, the TIB entry's tag-stack operation is “replace the packet's top tag-stack value with T2.”
A distinguished value of “next hop” that may exist in both the FIB and the TIB is “me.” This means that a packet has reached its final hop, and is delivered to local software rather than forwarded over a data link to a next hop.
4. Edge Routers and the IGP
Now, it was stated above that IGP speakers periodically advertise address ranges to which they afford direct access. If P1 is on a subnet in which all hosts' addresses start with 192.3.45, for instance, it will advertise this prefix, and every IGP speaker in the SP network will have an entry for that prefix in its FIB. Therefore, if PE1 has an interface on the same subnet, say with an address of 192.3.45.12, then those IGP speakers will be able to determine how to reach PE1. But it will become apparent as the description proceeds that, in order to assign certain tags, the illustrated embodiment requires each SP router additionally to have PE1's full address as a prefix in its FIB. And, in general, each SP router should have such a “host route” for every PE-router. (A host route is one whose prefix is the length of a complete IP address and thus corresponds to only one host.) So edge routers in the illustrated embodiment advertise not only the address ranges to which they have access but also their own complete addresses. (Actually, as will shortly be explained, the edge routers are also “BGP speakers,” which would conventionally advertise their host routes in IGP anyway.)
5. How BGP Modifies the TIB and the FIB
It was mentioned above that IGPs are used for propagating routing information among routers connected by routes within a commonly administered domain. In such a domain, the assumption is that routers are generally to cooperate in routing any received packets and that they will accumulate routing information from all sources within that domain. But a domain administered by one entity may additionally be connected to domains administered by others. For such connections, a given domain may choose to be selective about what traffic it will forward and which of its resources it will make available for that purpose. Additionally, it typically is not practical to accumulate routing information from all routers in every other domain, even if the other domains were inclined to supply it, so inter-domain topology-information sharing calls for some selectivity.
This is not something to which IGPs are well suited. For communicating information of that type, therefore, routers involved in communication among such “autonomous systems,” as they are called, use external routing protocols, such as External Gateway Protocol (EGP). For the sake of concreteness, we assume here that the external routing protocol used here is the one specified in RFC 1654 and referred to as the Border Gateway Protocol (BGP).
In BGP, the type of message used to advertise a route is called an “update” message. In a conventional, non-tag-switching BGP implementation, an update message contains an address prefix, a “BGP next hop,” and an AS Path, which lists the autonomous systems traversed in reaching the advertised destinations. With tag switching, this is modified to add a tag to each address prefix.
When a router R receives a BGP update message for address prefix X from a BGP peer R2, R runs the BGP decision process. Policies that the BGP process implements may or may not result in R's installation of R2's route to X. But if they do, then:
If the FIB does not already contain an entry that maps X to a next hop, or if it contains an entry that maps X to a next hop other than the one specified in R2's BGP update message, then R adds an entry that maps X to the specified next hop, and it removes any previous entry for X. This next hop will not in general be a directly connected neighbor of R, so the FIB entry may be a recursive one. (In the cases in which we are interested, R2 will specify itself as the BGP next hop, in which case the FIB entry will map X to R2.) If R2's BGP Update message specified tag value T for address prefix X, then the tag-stack operation in the FIB entry is “push T onto the tag stack.” Otherwise, the tag-stack operation is “no op.”
If the FIB already contains an entry that maps X to a next hop, and the next hop is the same as the one specified in R2's BGP Update message, then the FIB entry's next-hop field is left unchanged. If R2's BGP Update message specified tag value T for address prefix X, then the FIB entry's tag-stack operation is changed (if necessary) to be “push T onto the tag stack.” If R2's BGP Update message specifies no tag value for X, then the tag stack operation in the FIB entry is changed (if necessary) to “no op.”
6. The Decision to Distribute a Tag Binding
The preceding discussion concerned what happens when a router has asked another router to associate a tag with a prefix. We now describe the circumstances under which a router makes such a request.
In most tag-switching proposals, a router is allowed to bind a tag to an address prefix if the router's FIB table includes an entry that corresponds to that address prefix. In the illustrated embodiment, if the FIB-entry “prefix” is the complete address (“host route”) of a router in the SP's network, then binding a tag to that prefix is not only permitted but required.
If X is the (thirty-two-bit) address of the router R itself, then the tag value that R binds to X is the distinguished value that means “pop the tag stack.”
When a tag T is bound to an address prefix X, and the FIB entry for X was inserted as a result of running the IGP, R will distribute the tag binding to its directly connected neighbors by using a tag-distribution protocol that will be described below.
When a tag T is bound to an address prefix X, and the FIB entry for X was inserted as a result of running BGP, R will use BGP to distribute the tag binding, in a manner that will be described below, to any BGP peer to which it distributes the route to X.
If router R binds to an address prefix X a tag T other than the distinguished value that means “pop the tag stack,” then R also creates a T-indexed TIB entry in its own TIB table.
The TIB entry is created as follows.
Suppose that R is a PE router, and address prefix X is one for which the next hop is a directly attached CE router. (As will be explained below, the prefix value will have been enhanced to distinguish X in CE's VPN from X in others'.) Then the TIB entry will specify the CE router as the next hop, and its tag-stack-operation entry will be “pop the tag stack.”
Suppose that the FIB entry corresponding to X specifies a next hop of N and a tag-stack operation of “push value T2 onto the stack.” Then the TIB entry will give N as the next hop and “replace the value at the top of the stack with T” as the tag-stack operation.
Suppose that the FIB entry corresponding to X specifies a next hop of N and a tag-stack operation of “no op.” Then the TIB entry will specify a next hop of N, and a tag-stack operation of “discard the packet.”
Detailed Example
We now have enough background to describe in detail the way in which the illustrated embodiment performs the operations mentioned briefly in connection with FIG. 1 For this purpose, we return to FIG. 1.
All of FIG. 1's P routers (PE1, PE2, P1, and P2) participate in a common IGP. CE1 and CE2 do not participate in this IGP. CE1, PE1, CE2, and PE2 are BGP speakers. CE1 has an External BGP (EBGP) connection to PE1, PE1 has an Internal BGP (IBGP) connection to PE2, and PE2 has an External BGP connection to CE2. (As those skilled in the art are aware, the way in which a BGP speaker reacts to BGP messages originating in its own autonomous system differ from the way in which it responds to BGP messages that originate in a different autonomous system. The BGP session is commonly referred to as “internal” in the former case and “external” in the latter.)
1. FIB Entries that IGP Creates
Since PE1 is an edge router, it exports its own thirty-two-bit address into the P-network's IGP. As a result:
PE2 has an FIB entry that maps PE1 to a next-hop value of P2. Since P2 is directly connected to PE2, this entry is non-recursive.
P2 has an FIB entry that maps PE1 to a next-hop value of P1. Since P1 is directly connected to P2, this entry is non-recursive.
P1 has a FIB entry that maps PE1 to a next hop value of PE1. Since PE1 is directly connected to P1, this entry is non-recursive.
PE1 has a FIB entry that maps PE1 to a next hop value of “me.”
2. TDP Messages; TIB Entries Created as a Result of TDP Processing
As was mentioned above, the illustrated embodiment requires that each of the SP's routers construct a TIB by assigning tags to all of the prefixes for which its FIB has entries and that it ask its neighbors to use those tags in forwarding data packets to it. A mechanism that they can use to make those requests is a tag-distribution protocol (TDP). Appendix B describes that protocol in detail. Here we only digress briefly to mention certain salient features.
TDP is a two-party protocol. It requires a connection-oriented transport layer that provides guaranteed sequential delivery. FIG. 3's second row therefore depicts TDP's protocol data units (PDUs) as being carried in a data stream delivered by the well-known Transport Control Protocol (TCP) whose segments are delivered in Internet Protocol (IP) datagrams whose format FIG. 3's first row depicts. (That row omits the link-level-protocol header and trailer fields that usually encapsulate the IP datagram for transmission between hosts on the same link.)
The IP datagram begins with a header that includes various types of information such as the datagram's length, the network address of the destination host interface, and a code for the next-higher-level protocol in accordance with which the destination host should interpret the datagram's payload. In the illustrated example, that protocol is TCP, which handles matters such as ensuring that data have been received reliably. As the drawing illustrates, the destination host's TCP process interprets the first part of the IP field as a header used in carrying out these TCP functions. In particular, that header includes a field that specifies the “port” application that is to receive the TCP segment's remainder, payload portion. In the case under consideration, the port field indicates that the host's TDP application is to receive it.
Concatenation of TCP-segment payloads results in a data stream that contains the TDP PDUs.
A TDP PDU begins with a fixed-length four-field header. The header's two-byte version field gives the number of the TDP version that the sender is using. The two-byte length field gives the length in bytes of the remainder of the PDU; i.e., it gives the total PDU length minus four.
As will be explained shortly, TDP communications occur in sessions, of which a given router can be conducting more than one at a time. The first four bytes of the six-byte TDP ID field encode an IP address assigned to the router that started the TDP session, and the TDP ID field's last two bytes identify the particular session.
A two-byte field reserved for further enhancements completes the header, and the remainder of the PDU comprises one or more protocol information elements (PIEs), which take the type-length-value format that FIG. 3's third row illustrates.
Each PIE's type field specifies its purpose, while its length field gives the length of its value field. Various PIE types have housekeeping purposes, such as instituting a TDP session between two routers, negotiating protocol versions, providing error notifications, and keeping the session alive. (If a router does not receive a same-session communication within a certain timeout period, it ends the session and discards the tags installed during the session.) But the protocol's main mission, i.e., distributing tag bindings, is carried out by PIEs of the TDP_PIE_BIND type, for which the type field's contents are 020016.
FIG. 3's fourth row depicts this PIE type's value segment. In that segment the request-ID field is zero unless the PIE is being sent in response to a request from the other session participant, in which case that field's request ID matches that of the request. (Such a request would have been sent as another PIE type.) The AFAM (Address Family Numbers) field is set to 1, indicating that the address prefixes contained in the PIE's binding list are intended to be interpreted as IP version 4 (IPv4). If either the sender or the receiver of this PIE is using ATM switching hardware to implement the tag switch forwarding path, the Blist Type field is set to 6 (“32-bit downstream assigned VCI tag”) to indicate that, as will be seen below, the tag has a format and location specific to the ATM protocol. Otherwise it is set to 2, which means “32-bit downstream assigned.” Downstream assigned means that a tag's meaning is being set by the router that will base its routing decisions on it, as opposed to the router that will tag the packet with it. The next, Blist Length field gives the length in bytes of the Binding-List field, and the optional-parameters field is sometimes included to present related information.
Of these fields, the field of most interest here is the Binding-List field, whose format FIG. 3's fifth row depicts. That field contains one or more entries. When the Blist Type is 2, each of the entries includes precedence, tag, prefix-length, and prefix fields, as FIG. 3's fifth row indicates. To bind tag T to prefix X, the prefix-length field contains X's length in bits, the prefix field contains X's value right padded with as many bits as needed to make it end on a byte boundary, and the precedence field is an eight-bit field that specifies the precedence with which the router that issued the PDU will service traffic that bears T as a tag.
So to request that a neighbor router use a given tag value when it forwards packets destined for a given prefix, a router sends a TDP message containing a TDP_PIE_BIND type PIE whose binding-list portion's tag and prefix fields respectively contain that tag and prefix.
Now, PE1 uses this mechanism to ask that P1 bind to PE1's own address a distinguished tag value that means “pop the tag stack.” (It makes a similar request to any other of the SP's transit routers to which it is directly connected.) The purpose of this request is to establish PE1, an edge router, as one that should see the lower, ultimate-destination-designating tag (T3 in FIG. 1) hidden from the transit routers. As a result of PE1's having advertised its host route, P1 already has an FIB entry that maps PE1's address to a next hop of PE1 and a tag-stack operation of “no op.” As was stated above, the SP's routers are required to create TIB entries for all prefixes that they have FIB entries for, so P1 assigns a tag T1 to PE1 by creating a TIB entry that maps T1 to the destination PE1. And, in accordance with PE1's bind request, that entry's tag-stack operation is “pop the stack.”
P1 must also distribute the new tag, so it uses TDP to ask that P2 use the T1 tag whenever it sends P1 a packet destined for PE1.
PE1's advertisement of its host route has resulted in P2's already having a FIB entry that maps PE1's address to a next hop of P1 and a tag-stack operation of “no op.” P2 now modifies this FIB entry so that the tag-stack operation is “push T1.”
Since PE1 is a destination in P2's FIB, P2 must bind a tag value to PE1's address. That is, it creates a TIB entry that maps T2 to a next hop of P1—i.e., to its FIB's next-hop entry for PE1—and to a tag-stack operation of “replace the top tag value with T1.” P2 then uses TDP to ask that PE2 use tag value T2 whenever it sends P2 a packet destined for PE1.
PE2 already has a FIB entry that maps PE1's address to a next hop of P2 and a tag-stack operation of “no op.” In response to P2's TDP message, PE2 now modifies this FIB entry so that the tag-stack operation is “push T2.”
3. EBGP Messages from CE Routers to PE Routers
So far we have described only the tag binding that results from the routing information that the SP's routers have used an IGP to share with each other. But the present invention is intended to be used to implement a peer-model VPN, so the client enterprise, too, shares routing information with some of the SP's routers.
The CE1 router is a routing adjacency of the PE1 router. That is, when CE1 forwards a packet destined for a remote system that can be reached through PE1, CE1 explicitly directs that packet to PE1. In the illustrated example as it will be elaborated on in connection with FIG. 2, it performs the explicit direction by encapsulating the packet in a link-level header containing PE1's hardware address on a common multinode network. In other configurations, it may do so by, for instance, placing that packet on a point-to-point link with or by sending the packet in transmission cells whose headers include a code that represents a channel between CE1 and PE1. Yet another way of providing the explicit direction is to use, e.g., encapsulated IP, whereby the packet includes an IP datagram whose destination address is PE1's network address but whose payload is another IP datagram, this one having the destination address of the remote destination. In this way, an internetwork route between CE1 and PE1 acts as a “link” in a higher-level inter-network route.
In contrast, CE1 is not in general a routing adjacency of CE2. That is, even when CE1 forwards a packet destined for a remote system reachable through CE2, it never explicitly specifies CE2 as a router through which the packet should pass on the way. True, the fact that CE2 is in the route may have been included in the reachability information that CE1 amassed in the course of filling its forwarding-information database. But in the course of actually forwarding a packet, CE1 simply notes that PE1 is the next hop to the ultimate destination.
In the FIG. 1 topology, suppose that CE1 is to tell PE1 which hosts are reachable at its site. For this purpose, it must use an external routing protocol, and we have assumed for the sake of example that it uses BGP. Together with RFC 1655, RFC 1654 and its predecessors describe that protocol's operation exhaustively, and we will not repeat that description here. For present purposes, we mention only a few features of most interest to the illustrated embodiment's operation.
As FIG. 4's first row indicates, BGP uses the TCP transport protocol. Concatenation of TCP-segment payloads results in a data stream in which the BGP application looks for a predetermined marker sequence. It interprets the marker and subsequent fields as a BGP message header that contains information such as the message's length and type. To share routing information, the type of message that CE1 uses is the BGP “Update” message, whose format FIG. 4's second row depicts.
The drawing uses a section labeled “header+” to represent the header and a number of fields not of particular interest to the present discussion. The message ends with a list of interface address prefixes referred to as Network-Level Reachability Information (NLRI), and a Path Attributes field describes a path to hosts whose IP addresses begin with those prefixes. A Path Attribute Length field (“PAL” in the drawing) tells how long the Path Attributes field.
In the present example, let us suppose that CE1 is at a site where all the hosts have IP addresses whose first byte is 10 (OA16) and whose second byte is 1 (0110). That is, they can be represented by the two-byte prefix 0A0116 (which the literature conventionally represents as “10.1.”) To communicate this, CE1 places in an NLRI-field length segment an indication that the prefix to follow is two bytes in length, and it puts 0A0116 in the following, prefix field, as FIG. 4's third row indicates.
FIG. 4's third row depicts the message's path-attributes portion as having three attribute fields, of which FIG. 4's fourth row illustrates one in detail. Attribute fields take the <type, length, value> form. The type field's second, “attribute code” half is shown as containing the code value of 2, which indicates that the value field is to be interpreted as describing a path to the hosts that the message advertises as being reachable. Specifically, it is to be interpreted as listing the “autonomous systems” that have to be traversed to reach those hosts.
Now, whenever a system has a BGP connection of any sort, it must use an Autonomous System Number (ASN). This is a number that the assigned number authority issues so that independently administered systems can identify each other when they use an external routing protocol. An “autonomous system” (AS) is a system under administration separate from others, and connection among an AS's hosts, whether direct or indirect, must be possible by way of the AS's resources only. Since CE1 cannot communicate with CE2 without using the SP's resources, the customer-enterprise-administered resources comprise at least two ASs. So we will assume that CE1's ASN is A1, CE2's ASN is A2, and the PE routers' ASN is A3.
From PE1, only AS A1 is involved in reaching the hosts represented by prefix 10.1. To indicate this, the AS-path attribute's value includes a first field that identifies it a sequence of ASs, a second field that gives the number of ASNs in the list as one, and a third field that contains the list's sole ASN, A1.
FIG. 4's fifth row depicts another of that message's attribute fields, one whose attribute-code byte identifies it as specifying the “next hop” to be used in reaching the advertised host-address range. The value field contains CE1's address, thereby indicating that CE1 can forward traffic to those reachable destinations.
So CE1 has told PE1 that it undertakes to forward traffic to hosts whose IP address prefixes are 10.1. In response, PE1 assigns a tag, T3, to that address prefix in CE1's VPN, VPN V. (Actually, PE1 may use the same tag value for every address prefix mentioned by CE1.) In its TIB, PE1 creates an entry, indexed by this tag value, that specifies CE1 as the next hop. The entry specifies a tag-stack operation of “pop the tag stack” so that the tag used will be discarded to reveal the network-layer header to CE1.
4. IBGP Messages from PE1 to PE2
Additionally, PE1 sends BGP update messages to certain other of the SP's routers to tell them that they can forward to PE1 any packets destined for hosts whose addresses are in the 10.1 range. But PE1's SP network provides service to other customer enterprises that may also have 10.1-prefix hosts: those hosts' addresses may not be unique. So the SP assigns a different VPN identifier to each of its customers' VPNs. In the case of CE1's enterprise, let us assume that the code is a 16-bit identifier V. PE1 prepends the VPN identifier V to the IPv4 address prefix (10.1 in the example) and uses it in the BGP message to the other provider routers.
Indeed, the SP may assign VPN V more than one VPN identifier. A reason for doing so could arise if VPN V uses the SP not only as its backbone but also as its connection to outside systems, such as the SP's other customers or the public internet. In addition to the above-described reachability advertisement, which VPN V does not intend the SP to share with systems outside the VPN, CE1 or another of VPN V's edge routers could also send PE1 information regarding routes over which VPN V would permit outside-origin traffic. For example, one route to a given node may be shorter and thus preferred for traffic from within the VPN, but a different route to the same node may include a firewall and therefore be preferred for traffic from outside the VPN. CE1 could specify the permitted scope of dissemination by using, say, the BGP communities attribute (RFC 1997) in the update message, or it could distinguish between different dissemination scopes by using separate channels between it and PE1 (e.g., by using different ones of PE1's IP addresses) for the different scopes.
PE1 must make this distinction in BGP messages that it sends to others of the SP's routers, because the roles of various SP routers as edge and transit routers is not in general the same for intra-VPN traffic as they are for inter-VPN traffic. To distinguish between different routes to the same destination, PE1 may prepend a first VPN identifier, say, VI, to prefixes in routes intended only for intra-VPN advertisement and a second identifier, say, VE, to prefixes in routes whose extra-VPN advertisement is permitted. Further identifiers may be used for further dissemination scopes. For the sake of discussion, though, we will assume that VPN V uses the SP as its internal backbone only and that the SP has accordingly assigned VPN V only one VPN identifier.
In the illustrated system, transit routers do not need the reachability information that CE1 has shared with PE1. So PE1 does not send the BGP message to the transit routers, and it may not send it to all edge routers. But FIG. 1 depicts only one other edge router, router PE2, and PE1 does send the BGP message to PE2, because that router is connected directly to VPN V. Those skilled in the art will recognize, though, that the message does not have to be sent as part of an actual BGP session between PE1 and PE2. In some large service providers, it is not considered practical for each BGP speaker to maintain BGP sessions with all other BGP speakers. So “route reflectors” act as intermediaries, maintaining sessions either directly or through other route reflectors with each of the BGP speakers and thereby propagating the necessary routing information. In that way, the number of IBGP sessions increases only linearly with the number of BGP speakers. But the diagram shows only two PE routers, so it includes no route reflectors.
Regardless of how PE1 sends the message, FIG. 5 illustrates that message's format. Since it is a BGP update message, its format is similar to the one that CE1 sent to PE1. Instead of using the conventional NLRI field to contain reachability information, though, PE1 obtains the greater format flexibility needed for the VPN-IPv4 address by using a “multiprotocol reachability information” type of attribute field, which has its own NLRI subfield. As FIG. 5's fourth row indicates, this type of attribute's code is 14. The first three octets of this type of field specify the address family that the attribute value will use to represent the reachability information in the NLRI field, and FIG. 5's fifth row shows that PE1 assigns these bytes a value representing the Tagged VPN-IPv4 format. As FIG. 5's sixth row illustrates, the Tagged VPN-IPv4 format starts with a four-byte tag, whose value is T3 in the example. This is followed by a field representing the prefix-field length, which is four bytes in the example. The prefix field's first two bytes encode the value V, which identifies the VPN, and the second two bytes have the value 0A0116, i.e., the sixteen-bit address prefix 10.1.
The other fields that FIG. 5's fifth row depicts include a next-hop field and a field that tells how long the next-hop field is. The next-hop field contains a six-byte VPN-IPv4 address whose first two bytes are zero the next hop is not one of the customers' routers—and whose remaining four bytes are PE1's IP address. Appendix C describes messages of this general type in more detail.
In response to this message, PE2 extracts the NLRI field's VPN-IPv4 value and decodes it into a VPN identifier and an IPv4 address prefix. In its FIB for that VPN, it creates an FIB entry that maps the IPv4 prefix to a next hop and a tag-stack operation. The next-hop value is PE1's address (since PE1's address appeared in the message's next-hop field). The tag-stack operation is “push tag value T3 onto the tag stack.” Since PE1 is not a direct neighbor of PE2, this is a recursive FIB entry.
Note also that BGP Update messages concerning VPN-IPv4 address prefixes cause modification only of the VPN-specific FIB, not of the general FIB. However, if the original BGP message from CE1 had indicated that the reachability information could be disseminated beyond VPN V (or a broader dissemination scope could be inferred from, e.g., the channel by which it came, then PE2 would additionally install that IPv4 prefix, next hop, and tag-stack operation in the FIBs for all the VPNs to which that information's dissemination.
Although the illustrated embodiment employs only a single service provider to provide the VPN's backbone, there is no reason why more than one SP, whose facilities constitute more than one autonomous system, cannot cooperate to implement the present invention's teachings. In that case, the tag-binding and reachability information would further flow from one SP to the next by EBGP in the FIG. 5 format.
Specifically, the egress PE router in one of the SP networks could use BGP to distribute a tag binding for a particular VPN-IPv4 address to the BGP border router between the two SP networks. That BGP border router would then distribute a tag binding for that address to the ingress PE router.
5. EBGP Message from PE2 to CE2
PE2 then relays this information to CE2 by sending it an EBGP message similar to the one that CE1 sent to PE1. As FIG. 6 shows, this message's NLRI field indicates that hosts whose addresses begin with prefix 10.1 are reachable, its next-hop attribute field indicates that the next hop in the route to those hosts is PE2, and the AS-path attribute field indicates that the path to that prefix traverses autonomous systems A1 and A3.
When CE2 receives this message, it creates an FIB entry that maps prefix 10.1 to a next hop of PE2. Note that CE2 need not support tag switching. CE2 must also use its own IGP to inform other routers (not shown) at its site that it has a route to hosts whose addresses begin with prefix 10.1.
6. Tracing a Data Packet
As a result of these operations, the various routers have the routing information that they need when CE2 sends to PE2 a data packet P whose destination address is 10.1.0.1, which FIG. 1 depicts as “D1”.
To send P, CE2 looks up address 10.1.0.1 in its FIB and finds that the longest matching address prefix is the sixteen-bit prefix 10.1. The corresponding next hop is PE2. CE2 is directly attached to PE2, so it forwards P to PE2 over the data link connecting the two routers.
PE2 receives packet P and notes that it received that packet from a particular VPN, VPN V. For the sake of simplicity, we assume that PE2 concludes this from the fact that it receives the packet over a point-to-point interface dedicated to communication with CE2. But edge routers can base that determination on other factors instead. For example, suppose that the interface the interface is a local-area-network interface over which packets from different VPNs could arrive. In that case, CE2 might rely on the data-link source address and base the determination on its knowledge of the VPN's constituent systems. Other implementations may base the source determination on cryptographic authentication data that the packet contains. In a similar vein, the log-in procedure performed by a customer contacting the PE router by way of a dial-in link may result in the PE router's obtaining information from an authentication server, and it may base its identification of the source VPN on this further information.
In any event, the PE router identifies the source VPN, and the source VPN in this case is VPN V. So PE2 looks up P's destination address in its FIB that is specific to VPN V. It finds that the longest matching address prefix is the sixteen-bit prefix 10.1. (In this example, which focuses on intra-VPN communication, we assume that PE2 further infers from the source determination that the packet is not to be permitted outside VPN V, so PE2 would not look further if it failed to find a match. In other circumstances, though, PE2 might look in the FIBs of other VPNs, which may have indicated their availability to forward packets to that address.) The corresponding next hop is PE1, and the tag-stack operation is “push T3 on the tag stack.” So PE2 creates a tag stack for P and pushes T3 onto it. Since PE2 is not directly connected to PE1, P2 performs a recursive lookup in its general FIB.
We know from the preceding discussion that PE2 has an FIB entry corresponding to PE1's thirty-two-bit address, that the next hop in that FIB entry is P2, and that the tag-stack operation in that FIB entry is “push T2 onto the tag stack.” So PE2 pushes T2 onto P's tag stack. The stack now has two tags; the top tag T2, and the bottom tag is T3. PE2 tags P with this stack and sends P over the data link to P2, as FIG. 1 shows diagrammatically.
When P2 receives packet P, it attempts to forward it by looking up T2 in its TIB. From the tag-distribution discussion, we know that T2 maps to a TIB entry whose next hop is P1 and whose tag-stack operation is “replace the top tag value with T1.” So P2 as performs the tag-stack operation and sends the packet over the data link to P1. (At this point, packet P's top tag is T1, and its bottom tag is T3.)
When P1 receives packet P, it attempts to forward it by looking up T1 in its TIB. We know from the tag-distribution discussion that T1 maps to a TIB entry whose next hop is PE1 and whose tag-stack operation is “pop the tag stack.” So P1 performs the tag-stack operation and sends the packet over the data link to PE1. (At this point, packet P is carrying only one tag, T3.)
When PE1 receives packet P, it attempts to forward it by looking T3 up (which is now at the top of the stack) in its TIB. We know from the tag-distribution discussion that T3 maps to a TIB entry whose next hop is CE1 and whose tag-stack operation is “pop the tag stack.” So PE1 performs the tag-stack operation and sends the packet over the data link to CE1. Note that PE1 has popped the last tag off the tag stack before sending the packet to CE1. So CE1 receives an untagged packet, which it forwards in the conventional way.
Now, although we introduced the foregoing example with FIG. 2's illustration of Ethernet as the link-level protocol, those skilled in the art will recognize that other protocols can readily be substituted. The adaptations required for that purpose are largely straightforward and do not in general require separate discussion. But there may be some value in briefly discussing an Asynchronous Transfer Mode (ATM) example, because such an adaptation moves part of the tag stack to the ATM header.
To that end, we consider FIG. 7, whose topology is identical to that of FIG. 1, but we assume that P1 and P2 are ATM switches and that PE1 and PE2 are routers that attach to P1 and P2, respectively, over ATM interfaces. FIG. 8 depicts the typical data message that, say, PE2 would send to P2 in such an arrangement. FIG. 8 is best understood by comparison with the second row of FIG. 2's Ethernet example. In that diagram, the Ethernet header (DEST. ADDRESS, SOURCE ADDRESS, and TYPE) and trailer (CRC) encapsulate a payload in the form of tag fields and an IP datagram. FIG. 8's third row depicts an ATM frame, and that drawing's fourth and fifth rows show that the frame's payload is similar to that of FIG. 2's Ethernet frame. The only difference in the payloads is that FIG. 8's fifth row represents the left (top) tag by question marks, which indicate that the top tag's contents do not matter.
The reason why they do not is that the routing decisions made by FIG. 1's P2 on the basis of those contents are made by FIG. 7's (ATM) router P2 on the basis of an ATM VPI/VCI field in the header of an ATM “cell.” From the point of view of an ATM client, the frame of FIG. 8's third row is the basic unit of transmission, and it can vary in length to as much as 64 Kbytes of payload. (Those skilled in the art will recognize that there are also other possible ATM frame formats, but FIG. 8's third row depicts one, known as “AAL5,” that would typically be employed for user data.) For communication between ATM switches, however, ATM actually breaks such frames into fixed-size cells.
Each cell consists of a header and a payload, as FIG. 8's second row illustrates. Among the purposes of the header's PTI field, depicted in FIG. 8's first row, is to indicate whether the cell is the last one in a frame. If it is, its last eight bytes form the frame trailer field that FIG. 8's third row depicts. Among other things, the trailer indicates how much of the preceding cell contents are actual payload, as opposed to padding used to complete fixed-size cell.
The only other header field of interest to the present discussion is the VPI/VCI field of FIG. 8's first row. As is well known to those skilled in the art, ATM systems organize their routes into “virtual channels,” which may from time to time be grouped into “virtual paths.” Each switch associates a local virtual path/virtual channel indicator (VPI/VCI) with a channel or path that runs through it. When an ATM switch receives a cell, it consults the cell's VPI/VCI field to identify by table lookup the interface by which to forward it, replaces that field's contents with a value indicated by the table as being the next switch's code for that path or channel, and sends the resultant cell to the next switch. In other words, the function performed by the VPI/VCI field enables it to serve as the stack's top tag.
So PE1 will bind a VPI/VCI tag, call it VC1, to the address of PE1 and distribute that binding to P1. P1 will bind a VPI/VCI tag, call it VC2, to the address of PE1 and distribute that binding to P2. P2 will bind a VPI/VCI tag, call it VC3, to the address of PE1 and distribute that binding to PE2.
Now, when PE2 receives from CE2 a packet destined for a site that is in CE2's VPN and is reachable via CE1, it does the following.
First, it looks up the destination address of that packet in its VPN-specific forwarding table. It finds a recursive entry whose tag operation is “push on T3”. On performing the recursive lookup, it finds that the next hop is an ATM switch and that the tag value is the VPI/VCI value VC3. It accordingly forms the frame depicted in FIG. 8's bottom three rows. It then breaks the frame into cells of the type that FIG. 8's top two rows depict, placing the VC3 value in the VPI/VCI field, and sends them in sequence to P2.
P2, on a cell-by-cell basis, replaces VC3 with VC2 and forwards the resultant cells to P1. Similarly, P1 replaces VC2 with VC1 on a cell-by-cell basis and forwards the resultant cells to PE1. PE1 eventually collects all the frame's cells and reassembles them. PE1 then extracts the resultant frame's user data, pops the tag stack, and forwards the resultant frame in accordance with the resultant tag stack (which now contains a single tag, T3). Note that in this scenario it is PE1, not P1, that pops the stack to get to the tag, T3, that indicates the extra-SP route. This is because P1 in this scenario is an ATM switch, and ATM switches do not have the capability of popping the stack themselves.
In the foregoing ATM example, the top tag in the tag-stack field never has any meaning. But now suppose that only P1 is an ATM switch: P2 and PE1 are routers attached to P1 via ATM interfaces. Then the PE2-P2 link would contain FIG. 2-style packets, P2 would base its decision on the top tag-field tag, and it would forward ATM cells in response.
Considerations for Extension to Inter-VPN Use
The foregoing discussion focused mainly on intra-VPN communication. We now turn to the way in which systems that employ the present invention's teachings can perform inter-VPN communication.
1. Internal vs. External VPN-IPV4 Addresses
As was explained above, it may be necessary to maintain two routes to a particular IPv4 address exported from one VPN to another. One route is used for intra-VPN traffic, and the other is used for inter-VPN traffic. When a particular IPv4 address is exported from one VPN to another,. For example, suppose that the system bearing a particular address is in site S1. Intra-VPN traffic to that system should certainly go directly to S1. However, there may be a firewall located at site S2, and it may be desired to pass all inter-VPN traffic through that firewall. In this case, inter-VPN traffic to the system in question should travel via S2.
In order to be sure that BGP can simultaneously install an intra-VPN and an inter-VPN route to the same address, it is necessary to use a different VPN-IPv4 address for intra-VPN connectivity than for inter-VPN connectivity.
Therefore, each VPN will have two VPN IDs. One will be the “Internal VPN ID,” and one will be the “External VPN ID.”
Each PE router will translate the IPv4 addresses from its attached VPNs to one or the other or to both of these VPN-IPv4 addresses. The rules for doing so will be discussed later.
A VPN-IPv4 address whose VPN ID is the Internal VPN ID of its VPN must not be distributed by any PE router to any CE router, unless that CE router is in that VPN. To prevent any unintended redistribution, a PE router that distributes an IPv4 address to another PE router must assign it the NO_EXPORT Community Attribute. According to RFC 1997, “BGP Communities Attribute,” this attribute means:
All routes received carrying a communities attribute containing this value MUST NOT be advertised outside a BGP confederation boundary (a stand-alone autonomous system that is not part of a confederation should be considered a confederation itself).
As we shall see below, this will prevent the corresponding address from being advertised outside the VPN. (One could instead define a new Community Attribute value, e.g., NO_EXPORT_OUTSIDE_VPN, for this purpose, but NO_EXPORT seems adequate and makes it easy to accommodate the case where the CE router itself specifies a NO_EXPORT attribute.
(An alternative would be to install filters that prevent VPN-IPv4 addresses with Internal VPN IDs from being transmitted outside a BGP confederation. This could be done if one could tell by inspection that a particular VPN ID is Internal, rather than External.)
2. Autonomous System Numbers
a. ASN Used by PE Router on IBGP Connections
Since the PE routers (in the same P-network) are to use IBGP to distribute routes among themselves, it follows that there must be some Autonomous System Number (ASN), known to all the PE routers, which they use when setting up these connections. (A BGP connection is not treated as an IBGP connection unless both BGP speakers have used the same ASN.)
If the P-network is already in use as an internet transit network, it will likely already have a globally unique ASN, and this can be used on these IBGP connections.
b. ASN Used CE Routers on EBGP Connections
When a particular site is a “stub site,” it is not necessary for the CE router to talk BGP to the PE router, though under certain circumstances it may be desirable for it to do so. However, whenever a particular site has a C router that is talking BGP to another C router, then the CE router will need to talk BGP to the PE router. This is true whether the C routers talking BGP are talking to other C routers at the site, to other C routers at different sites of the same VPN, to other C routers of different VPNs, or even to routers in the public internet.
When a CE router distributes routing information to a PE router, the intention is that the information ultimately be distributed to one or more other CE routers. One PE router uses IBGP to distribute the information to another, and the latter redistributes it to another CE router.
Since routes learned over IBGP are in general not redistributed over IBGP, and since PE routers have IBGP connections to each other, it follows that the CE routers must talk EBGP to the PE routers. Each site where a CE router talks EBGP to a PE router must have an ASN. Call this a “Site ASN.”
The number of globally unique ASNs is limited, and it is not feasible to assign one to each individual VPN site. There is however a “private ASN” numbering space containing 1023 ASNs, which a service provider can administer as he sees fit. So the Site ASNs must be taken from the private ASN space. Since the size of the private ASN space is limited, it is desirable to use the same ASN numbers in different VPNs.
This can be done by modeling each VPN as a “BGP Confederation.” This means that the CE router and the PE router do not run “regular” EBGP between them: they run “Confederation EBGP (CEBGP).” CEBGP uses some of the procedures of regular EBGP, some of the procedures of IBGP, and some procedures of its own. However, these procedures are all well-defined and implemented.
3. Using BGP-Confederation Techniques for AS-Path Manipulation
A BGP confederation is a set of Autonomous Systems (ASs) that appear as a single AS to all ASs not in the Confederation. Only within the Confederation are the component ASs visible. That is, externally to the Confederation, the Confederation has a single ASN. Within the Confederation, each “Member AS” of the Confederation has its own ASN, which is distinct from the Confederation's ASN. The distinction shows up primarily in BGP Confederation procedures for AS-path manipulation, which we recommend for inter-VPN communication. (This does not imply that BGP Confederation procedures affecting other attributes should also be used.)
BGP maintains loop freedom by associating an AS-path with each route. Roughly, this is a list of the ASs through which a packet must travel to reach the destination. When a router distributes a route via EBGP, it adds its own ASN to the AS-path. When a router receives a route via EBGP, it checks to see if its own ASN is already in the AS-path. If so, it discards the route, in order to prevent the loop.
With Confederations, this procedure is slightly changed. When a router distributes a route on a CEBGP connection, it adds its own AS to the AS-path, but it marks that AS as being within the Confederation. When a router that is within a Confederation distributes a route on an EBGP connection, it first removes from the AS-path all ASs that are marked as being within the Confederation. Then it adds the Confederation's ASN to the AS-path.
When a router that is in a Confederation receives a route over an EBGP connection, it will discard the route if the AS-path contains the Confederation's ASN. When a router receives a route over a CEBGP connection, it will discard that route if the AS-path contains the Member ASN of that router, and that Member ASN is marked as being within the Confederation.
Since the Member ASNs of a Confederation are never seen outside the Confederation, they can be assigned from the Private ASN space.
In a VPN, each site containing a CE router that talks BGP to a PE router would have a Site ASN taken from the Private ASN space. Then these Site ASNs need be unique only within a single VPN: they can be reused in other VPNs. The P network is part of each such Confederation and needs to have a Member ASN that can be used within each Confederation. The P network can have a single ASN that it uses as its Member ASN in all Confederations. If it has a globally unique ASN, this can be used.
If a VPN spans multiple service providers, then its Site ASNs must be unique across all the providers, and each P network must use a globally unique ASN.
When a router receives a route whose AS-path contains its site number, it conventionally rejects the route if the site number is not marked as being part of the confederation, and it is preferable for CE routers to follow this policy. Otherwise, since a VPN is modeled as a Confederation, care must be taken to ensure that whenever two C routers in the same VPN have a direct BGP connection with each other (i.e., a “backdoor” connection between routers in the same VPN, at the same or different sites), they talk either IBGP or CEBGP, never regular EBGP. When talking CEBGP, each router would use its Site ASN as its ASN, for the purpose of (a) filling in the “My Autonomous System Number” field in the BGP Open message, and (b) adding its ASN to the AS-path.
When a PE router receives from a CE router over a CEBGP connection, routes to IPv4 addresses, the PE router will immediately translate those addresses to VPN-IPv4 addresses, using the Internal VPN ID of the CE's VPN. (“Immediate translation” means that the addresses appear in BGP's “adj-rib-in” table as VPN-IPv4 addresses.) When a PE router distributes VPN-IPv4 addresses to a CE router over a CEBGP connection, it first converts them to IPv4 addresses by stripping off the VPN ID.
The External VPN ID of a particular VPN can have the same value as the VPN ASN. The Internal VPN ID must have a different value. It may be convenient for these values to be algorithmically related, but this is not required.
If a VPN spans multiple service providers, its Internal VPN ID and its External VPN ID must be globally unique. Otherwise, they must be unique only within the scope of a single service provider. Note also that any quantity that is used as an External VPN ID of one VPN may not be used as an Internal VPN ID of any other VPN, and vice versa.
4. Inter-VPN Communication as Communication Between Two Confederations
Since each VPN is modeled as a BGP Confederation, each VPN appears as an AS to each other VPN. Communication between two VPNs is modeled as communication between two ASs, using the P network as the transit AS. Therefore if a CE router uses BGP to export routes, via a PE router, to another VPN, it must do so via a regular EBGP connection to the PE router. Of course, on the EBGP connection it uses the VPN ASN, not the Site ASN.
If the P-network has a globally unique ASN, it can be used both within a Confederation and between Confederations.
Whenever two C routers in different VPNs have a direct BGP connection with each other (i.e., a “backdoor” connection between routers in different VPNs), care must be taken to ensure that they talk EBGP with each other. When talking (non-confederation) EBGP, each router would use its Confederation ASN as its ASN for the purposes of (a) filling in the “My Autonomous System Number” field in the BGP Open message, and (b) adding its ASN to the AS-path.
So in the most general case, a CE router may need to have two BGP connections to a PE router, an EBGP connection (for inter-VPN connectivity) and a CEBGP connection (for intra-VPN connectivity). There may be only one BGP connection between a given pair of IP addresses. So if a given pair of routers need to have two BGP connections between them, each router must use a distinct address on each connection.
When a PE router receives, from a CE router over an EBGP connection, routes to IPv4 addresses, the PE router will immediately translate those addresses to VPN-IPv4 addresses, using the External VPN ID of the CE's VPN. When a PE router distributes VPN-IPv4 addresses to a CE router over an EBGP connection, it will first convert them to IPv4 addresses by stripping off the VPN ID.
A site in a VPN may maintain a backdoor connection to the public internet, via an EBGP connection. If this EBGP connection is not via the same service provider that is providing the VPN, the VPN ASN must be from the public AS numbering space. Otherwise, it may be from the private AS numbering space, and the C router maintaining the EBGP connection to the internet should be configured to strip all private ASNs from the AS-path.
In general, P routers with EBGP connections to routers outside the P network will not accept routes to VPN-IPv4 addresses over those connections. To do so would allow routers outside the Service Provider's control to spoof routes to the VPN, thereby compromising the security that the customer expects. If it is necessary to make any exceptions to this rule (to support, say, multi-provider VPNs), the security effects of those exceptions would need to be carefully considered.
5. How to Determine when a CE Router Needs Zero, One, or Two BGP Connections to a PE Router
If the CE router's site does not have any backdoor connections, neither a CEBGP nor an EBGP connection is necessary. In this case, all the information that would be passed via BGP can be statically configured in the PE router. The site will not have a Site ASN. IBGP between PE routers is still used to pass routing information about one site to the others.
By a “backdoor connection,” we mean a BGP connection between a C router at the site and any router other than a PE router. If two sites in a particular VPN are inter-connected via static routing and/or IGP, then we model them as a single site, rather than as two sites with a backdoor connection.
Even in the absence of backdoor connections, it can be desirable to use BGP between the CE and the PE router, if the site has a significant number of address prefixes that are sometimes up and sometimes down, or if there are address prefixes that move from one site to another. This can also be desirable simply as a way to avoid the configuration task associated with static routing.
If the CE router's site does not have any backdoor connections to other VPNs (or to the public internet), but it is desired to have a BGP connection to the PE router (either for the reason given in the prior paragraph, or because there are backdoor connections to other sites in the VPN), it is necessary to have a CEBGP connection between CE router and PE router. As we will see below, routes distributed over CEBGP will not thereby be distributed to any other VPN. However, distribution of routes to other VPNs can still be achieved via configuration of the PE router.
If the CE router's site has backdoor connections to other VPNs (or to the public internet), and if it serves as a transit network for traffic from other VPNs (or the public internet), then the CE router must run EBGP with the PE router, in order to properly distribute the routes for which it is a transit network.
If a VPN has multiple sites that have EBGP connections to PE routers, then there must also be a CEBGP connection from each of those sites to a PE router.
6. Using Community Attributes to Control the Exporting of Addressed from One VPN to Another
As stated previously, whenever a PE router uses IBGP to distribute to another PE router (or route reflector) a route to a VPN-IPv4 address, the NO_EXPORT Community Attribute will be included as an attribute of that route if the VPN ID of that address is an Internal VPN ID.
When a PE router uses IBGP to distribute a route to a VPN-IPv4 address to another PE router (or route reflector), and the VPN ID of that address is an External VPN ID, Community Attributes must be included that specify the set of VPNs to which the address in question is to be exported.
This requires a distinguished class of Community Attributes that are used only for this purpose. In general, when such attributes are received by P routers over EBGP connections, they should be removed (via inbound filtering), unless there is explicit configuration of the P router that allows them to be passed on unchanged.
The Community Attribute that is used to indicate that an address is to be exported to a particular VPN should be algorithmically derivable from that VPN's ASN, and vice versa.
If a CE router talks EBGP to a PE router, the CE router may, with each address it distributes, include a set of Community Attributes, indicating the set of other VPNs (possibly including the public internet) to which the address is to be exported. If so, the PE router may be configured with a set of addresses from the C network that the CE router is authorized to export to a set of other VPNs. In that case, the PE router will remove (via inbound filtering) any unauthorized Community Attributes sent by the CE router. The PE router may be configured with a set of addresses from the C network that are to be exported to a set of other VPNs, even if the CE router does not include the necessary Community Attributes. In this case, the PE router must add (via inbound filtering) the missing Community Attributes.
When a PE router receives a route to an external VPN-IPv4 address and that route is associated with a Community Attribute that identifies the VPN of a CE router to which that PE router is attached, then the route is a candidate for redistribution to the CE router. (Of course, a VPN-IPv4 address is translated into an IPv4 address, by having its VPN ID stripped off, before being distributed to a CE router.)
The PE router may be configured to allow only particular VPN-IPv4 addresses to be distributed to a particular CE router, regardless of the Community Attribute. Or it may be configured to prevent the distribution of particular VPN-IPv4 addresses to a particular CE router, regardless of the Community Attribute. In such cases, outbound filtering should be used to prevent distribution of such addresses to the CE router.
7. A Slightly Different Way to Use Community Attributes: Closed User Groups
The Community Attribute can be used in a similar though somewhat different way to represent “Closed User Groups” (CUGs) of VPNs, rather than target VPNs.
A CUG is a set of VPNs. A CE router could associate a route to a particular address with one or more CUGs. The PE router would strip any CUGs that the CE router is not authorized to use. The PE router could also add additional CUGs, or could add CUGs when the CE router has not specified any. The PE router would need to know which VPNs are members of which CUGs, so it could determine which other PE routers it needs to distribute the routes to.
When a route with a CUG is received, it will be distributed over an EBGP connection to a CE router only if the PE router is configured with the knowledge that the CE router is a member of that CUG.
The use of CUGs may simplify the configuration of the PE routers.
8. IBGP Between PE Routers
In conventional uses of BGP, the set of EBGP/CEBGP speakers in a given AS is supposed to be “fully meshed” (or “fully reflected” through route reflectors). Otherwise, there is no way to ensure that communication between any two points is possible. For VPNs, we do not want to require that communication between every pair of points be possible, so the PE routers need not in general be fully meshed. A PE router A needs to talk IBGP to a PE router B only if A and B both attach to CE routers in the same VPN, or if A attaches to a CE router in VPN 1 that is exporting addresses to a VPN 2, and B attaches to a CE router in VPN 2.
For each PE router that is to be an IBGP peer of a given PE router, the given PE router will know which VPNs the peer is interested in. If a PE router A has an IBGP peer B, and B is interested in VPN 1, then A shall distribute a route to B if and only if one of the following two conditions holds:
the address corresponding to the route is a VPN-IPv4 address in VPN 1, or
one of the following conditions holds:
the VPN ID of the VPN-IPv4 address is the Internal VPN ID for VPN 1, or
the VPN ID of the VPN-IPv4 address is the External VPN ID for VPN 1, and the route has a Community Attribute that indicates that it should be distributed into VPN 1.
Each PE router, before distributing a route, will also assign a tag for that route. This will be encoded, in a way to be defined, as an attribute of that route.
When a PE router redistributes over IBGP a route received from a CE router (whether it is received over EBGP or CEBGP), it should always put itself in as the next hop. This ensures that the next hop is always reachable in the P network's IGP (i.e., it does not require routes to all the CE routers to be injected into the P-networks' IGP). It also ensures proper interpretation of the tag that the PE router assigns to the distributed address prefix; the tag associated with an address prefix should be a tag assigned by the “next hop” for that prefix.
For the purpose of supporting VPNs, PE routers need to support the following capabilities:
Tag distribution via BGP
VPN-IPv4 Address Family
VPN “edge capabilities,” i.e., whatever special procedures are needed in order to interact with the CE routers—e.g., translation between VPN-IPv4 and IPv4 addresses, per-VPN lookup tables, etc.
BGP Capability Negotiation, as described in Appendix D, should be used to determine whether an IBGP peer has the appropriate capabilities.
9. IBGP Between a PE Router and a P Router that is not a PE Router
PE routers may have “ordinary” EBGP and IBGP connections that have nothing to do with VPNs. On such ordinary connections, IPv4 NLRI rather than VPN-IPv4 NLRI is used; routes learned from CE routers will not be sent on such connections, unless the PE router is configured to export those routes to the public internet.
Any router with a BGP connection to the internet must ensure, through proper filtering, that it does not leak any routes to the internet that are not part of the P network's AS, or of the AS of some client network of the P network. When routes are leaked to the internet, all private AS numbers must be removed (via outbound filtering) from the AS-path.
10. Configuration of the PE Routers
Each PE router must be configured with the following information:
a. Per CE Router that Attaches to the PE Router
i. The address of the CE router to use when participating in a CEBGP connection.
The PE router may maintain a static route to this address and need not redistribute this address into the IGP of the P network (as long as the PE router always sets itself as the next hop before redistributing routes received from the CE router). In this case, the same address may be reused for other CE routers, subject to the constraint that all the CE routers attaching to a given PE router have distinct addresses. If the PE router distributes this address into the P network's IGP, though, the address should be a unique address in the P network's address space.
This parameter can be omitted if no CEBGP connection is to be formed.
ii. The address of the CE router to use when participating with it in an EBGP connection.
This parameter can be omitted if no EBGP connection is to be formed.
iii. The address of the PE router to use when participating in a CEBGP connection with the above-specified CE router.
iv. The address of the PE router to use when participating in an EBGP connection with the above-specified CE router.
(Can be omitted if no EBGP connection is to be formed.)
v. The CE router's Site ASN.
This parameter can be omitted if no CEBGP connection is to be formed.
vi. The CE router's Internal VPN ID.
vii. The CE router's External VPN ID.
This doubles as its VPN ASN if an EBGP connection is to be formed.
viii. A list of VPNs or CUGs to which the CE router can export addresses, and, for each such VPN, the set of addresses that are authorized to be exported to it.
The set of addresses may be “all.” For each such set of addresses, there needs to be an indication as to whether the PE router should allow the addresses to be exported if is the CE router attempts to export them, or whether the PE router should initiate the export of the addresses independently of any action on the part of the CE router. (The latter would be the only way to get export if there is no EBGP connection to the CE router.)
ix. A list of VPNs or CUGs that can export addresses to the VPN of the CE router, and, for each such VPN, a set of addresses that are authorized for export into the VPN of the CE router.
This set may be “all.” For distribution of an address between the public internet and a VPN, the public internet shall be represented as VPN 0.
b. Per VPN or CUG, for Each VPN to which the PE Router Attaches Via a CE Router, and for each VPN or CUG to which One of the Attached VPNs Can Export Addresses: the Set of PE Routers Interested in that VPN or CUG.
IBGP connections will be opened to all such PE routers. If these are provided by only a few route reflectors, manual configuration is acceptable, but auto-discovery will be required as a practical matter if they are provided by a large number of other PE routers.
If the PE router has a CEBGP connection to the CE router, the addresses to be distributed intra-VPN will be those addresses distributed by the CE router over the CEBGP connection. Otherwise, the PE router needs to be configured with those addresses, or it needs to obtain them in some other way (such as ODR or RIP).
If the PE router has an EBGP connection to the CE router, the addresses to be distributed inter-VPN will be those addresses distributed by the CE router over the EBGP connection. Otherwise, the PE router needs to be configured with those addresses.
11. Configuration of the CE Routers
If the CE router is talking BGP to a PE router, the CE router will need to be configured to set up a CEBGP connection, or both a CEBGP and an EBGP connection, to a PE router. It must then be configured with an address of the PE router for each such connection. This address will be from the address space of the P network.
The CE router should have a static route to the PE router address. This route need not be redistributed into the C-network's IGP (though it should be safe to do so, because we are not trying to handle the case where there is addressing conflict between the C network and the P network).
The CE router does not use VPN-IPv4 addressing, and does not assign tags to the addresses it distributes to the PE router.
If the CE router is at a stub site, then:
if it uses the same PE router(s) for intra-VPN as for inter-VPN traffic, it should be configured to have a default route pointing to the PE router(s), and should inject “default” into its IGP.
if it uses a different PE router for inter-VPN traffic than for intra-VPN traffic, then it must be configured with appropriate static routes, and must inject them into its IGP.
(Even if the CE router talks BGP to the PE router, there is no reason to redistribute the BGP routes into the IGP.)
If the CE router is not at a stub site, then proper administration must be done to ensure that BGP routes and/or default routes are injected into the IGP in a proper manner.
12. Distribution of Routes from CE Routers to PE Routers on CEBGP Connections
a. CE Router Procedures
A CE router will distribute all routes to all destinations on its site over its CEBGP connection to a PE router. Routes to destinations on other sites (through backdoor routes) may also be distributed to the PE router on the CEBGP connection; this is a matter of policy of the C network.
b. PE Router Procedures
When a PE router receives routes on the CEBGP connection, it will of course translate the IPv4 addresses to VPN-IPv4 addresses. It will also remove from each route any VPN Community attributes that may be present. It will add the NO_EXPORT community attribute, to prevent the route from being distributed out of the Confederation.
The PE router should check the AS-path of each route it receives from the CE outer to ensure that the appropriate Site ASN appears at the beginning.
13. Distribution of Routes from CE Routers to PE Routers on EBGP Connections
a. CE Router Procedures
A CE router may distribute any routes to a PE router on an EBGP connection. However, it should avoid distributing any route on such a connection unless it intends to export that route to another VPN, or to the public internet.
b. PE Router Procedures
The PE router will ignore routes to any destinations that, according to the PE router's configuration, are not to be exported to other VPNs (including the public internet).
If a route from the CE router does not have a Community Attribute associated with it, the PE router will, before further distributing it, add the VPN community for each other VPN to which the route may be exported, according to the PE router's configuration.
If a route from the CE router does have one or more Community Attributes associated with it, the PE router will remove any Community Attributes that do not correspond to VPNs to which the route may be exported, according to the PE router's configuration.
If the PE router allows a particular route to be exported to a number of VPNs, this procedure allows the CE router to specify a subset of those VPNs to which it should be exported. If this is allowed, then the PE router must be able to detect when an EBGP update removes a Community Attribute that used to be there, so the route can be withdrawn from the corresponding VPN.
The PE router should check the AS-path of each route it receives from the CE router to ensure that the correct value of the VPN ASN appears at the beginning. If not, the PE router may replace it with the correct value.
The PE router will convert all IPv4 addresses from the CE router to VPN-IPv4 addresses, using the External VPN ID of the CE router's VPN, before redistributing them. There is one exception: if a route is to be distributed to VPN 0, it should be distributed as an IPv4 address, without any Community Attribute. (This allows for distribution to the public internet via a BGP speaker that is not VPN-aware.)
14. Distribution of Routes from PE Routers to CE Routers on CEBGP Connections
A PE router will distribute to a CE router, over a CEBGP connection, routes to all VPN-IPv4 addresses whose VPN ID is the Internal VPN ID of the CE router's VPN. No other routes shall be distributed on this connection. The VPN-IPv4 addresses will be translated to IPv4 addresses before distribution.
The AS-path should be modified by prepending the P network's ASN.
15. Distribution of Routes from PE Routers to CE Routers on BGP Connections
A PE router will distribute a route with VPN-IPv4 NLRI to a CE router on an EBGP connection only if both the following conditions hold:
the PE router is configured to allow the particular VPN-IPv4 address to be exported to the CE router, and
the PE router received the router with a Community Attribute that corresponds to the VPN of the CE router, or to a CUG that is associated with that CE router.
This ensures that the route came from a proper place, and is going to a proper place.
Community Attributes that represent target VPNs or CUGs should be stripped before the route is distributed to the CE router.
VPN-IPv4 addresses should be translated into IPv4 addresses.
The AS-path should be modified by prepending the P network's ASN.
A PE router will distribute a route with IPv4 NLRI to a CE router on an EBGP connection only if the PE router is explicitly configured to allow that address to be exported to the CE router's VPN. This allows the VPN to import addresses from the public internet.
Inter-VPN-Routing Example
To illustrate the use of internal and external VPN IDs, FIG. 9 depicts a service-provider network simply as an oval, omitting all individual routers except PE1, PE2, and PE3. PE1 and PE2 are edge routers with respect to customer nodes in a first VPN, VPN A, and PE3 is an edge router with respect to a second VPN, VPN B. A target destination D in one VPN A is reached most directly through a customer edge router CE1 at the same site. But VPN A has a firewall in CE2, and the policy is that any packets froth outside VPN A must go through CE2 before they go to any VPN A destination.
In this situation, CE1 uses EBGP to advertise to PE1 its access to D. In some manner determined by local configuration, PE1 recognizes that advertisement as being only for VPN A consumption. For example, PE1 may be configured to recognize the interface used by CE1 as one that advertises only intra-VPN reachability, or CE1 may employ a NO_EXPORT value of the BGP community attribute in its advertisement. In any case, PE1 reports itself by IBGP as the next hop to destination Int(D) (where “Int(D)” represents the concatenation of VPN A's internal VPN ID with D's network address or prefix). Preferably, it knows which routers are edge routers with respect to VPN A and makes this advertisement only to them. Alternatively, it is not so discriminating, but it is only such routers that adjust their FIBs in accordance with that information.
In either case, PE2 thereby learns this information and uses it to construct an FIB entry in its per-VPN FIB corresponding to VPN A. (If, as the drawing does not show, PE3 attaches to a CE router that is in VPN A, then it, too, uses that information to construct an FIB entry in its per-VPN FIB corresponding to VPN A.)
Since CE2 is to operate as the firewall, it must advertise itself as according access to all systems that the enterprise is willing to accord extra-VPN visibility, so it also uses EBGP to advertise node D's reachability. In some manner determined by local configuration, PE2 recognizes that advertisement as being for extra-VPN A consumption, and it reports itself as the next hop to destination Ext(D) (where “Ext(D)” represents the concatenation of VPN A's external VPN ID with D's network address).
PE3 thereby learns this information and uses it to construct an FIB entry in its per-VPN FIB corresponding to VPN A. (If, as the drawing does not show, PE2 attaches to a CE router that is in VPN B, then it, too, would use that information to construct an FIB entry in its per-VPN FIB corresponding to VPN B.)
Now, when a packet addressed to D arrives at PE2 from CE2, the packet is identified by, for instance, its incoming interface as coming from VPN A. PE2 looks in its per-VPN FIB for VPN A and sees that the next hop is PE1. This is the intra-VPN case.
When a packet addressed to D arrives at PE3 from CE3, the packet is identified, again possibly by virtue of its incoming interface, as coming from VPN B. PE3 looks in its per-VPN FIB for VPN B and sees that the next hop is PE2. The packet then gets sent to PE2, which sends it on to CE2. CE2 runs the packet through the firewall, and CE2 attempts to forward the packet if the firewall does not reject it. Since the destination is not on-site, the packet gets sent to PE2. This time PE2 identifies the packet as coming from if VPN A. PE2 looks up D in its per-VPN FIB for VPN A, and sees that PE1 is the next hop. The packet is then sent to PE1.
In short, when PE router receives a packet from a CE router, it can always identify the CE router from which the packet was just transmitted, so it can identify the VPN from which it just came. This enables the PE router to select the proper per-VPN FIB.
Although CE2 ran the packet that it received in the above scenario through the firewall, it would ordinarily be preferred that only packets from outside VPN A receive this treatment, in which case CE2 will need to know whether a packet that it receives is from a different VPN. The way in which this is accomplished is in general a local-configuration matter, but the most-common approach would likely be for CE2 to have two channels to PE2. Suppose, for instance, that CE2 has two different CE2 interfaces for such communication. It would run BGP on both interfaces. On one of the interfaces, it would advertise reachability to some set of addresses in VPN A (including D) and possibly specify appropriate community attributes to ensure that this information is exported to VPN B. PE2 would use VPN A's external VPN ID for information received over this BGP connection. On the other interface, it would advertise reachability to its on-site addresses, and PE2 would use VPN A's internal VPN ID for information received over this BGP connection.
Although the use of different interfaces would be the most-typical way to provide the different channels by which the achieve the internal- and external-route information and traffic are distinguished, internal routes and external routes could be mapped to the same interface, too, with the demultiplexing provided by, say, the presence or absence of cryptographic information in the packet header.
Alternatives
The foregoing discussion describes an advantageous approach to implementing the present invention's teachings, one whose advantages extend not only to situations in which the customer VPNs' address spaces overlap. But the particular approach there described is far from the only one that can implement the present invention's teachings. For example, some of the routing could be set statically rather than in response to routing protocols such as BGP. Also, although we have described VPN-specific information as being stored in separate tables because that approach seems most convenient, there is no reason in principle why a common table containing VPN-identifying entries could not be used instead.
And our focus on tag switching should not be interpreted to mean that the present invention's teachings are so limited. For instance, although we use tags to contain both the egress-router routing information and the egress-channel routing information, this is by no means a requirement. One could instead use, say, encapsulated IP to hide the inner, egress-channel (and thereby VPN-distinguishing) routing information from the transit routers. We prefer tag switching because it tends to be more efficient, to use less overhead, and to lend itself to uses where the network administration controls the routes to a greater degree than dynamic IP routing ordinarily allows. Also, unlike encapsulated IP, tag switching supports arrangements in which different VPN sites are attached to the networks of different autononmous service-providers that use BGP to exchange routing information and together form the back-bone-providing service-provider network. And tag switching lends itself to applications in which part of the backbone is an ATM link: tags can be put in the ATM header's VCI field.
But even when tags are used, they can represent the exterior-routing information in a way different from the one that the illustrated embodiment employs. For example, although the illustrated embodiment interprets the exterior-routing tag exemplified by T3 to specify a next hop, it could instead simply contain, say, a VPN identifier that the egress router uses to disambiguate the regular IP address.
Although we prefer to use tags for both the egress-router and egress-channel fields, moreover, the applicability of the present invention's teachings is not so limited. In an architecture in which every PE router always uses different interfaces for links to different VPNs' nodes, for example, the internal-routing field could be provided simply as a tag associated with such an interface. That is, there would be no separate tag for the egress router's interface with the previous P router. In such an arrangement, edge routers could use IGP to install host routes to all of their interfaces with client edge routers. To advertise external reachability, PE2, for instance, would use BGP to specify the IP address of the interface between PE2 and CE2 as the next-hop address for VPN-IPv4 addresses reachable through CE2. And PE2, P2, and P1 would all use TDP to bind tags to the host route to that interface; PE2 would not use the distinguished tag value meaning “pop the tag stack.”
In short, the present invention's advantages can be obtained from a wide variety of embodiments. It therefore constitutes a significant advance in the art.
Figure US06463061-20021008-P00001
Figure US06463061-20021008-P00002
Figure US06463061-20021008-P00003
Figure US06463061-20021008-P00004
Figure US06463061-20021008-P00005
Figure US06463061-20021008-P00006
Figure US06463061-20021008-P00007
Figure US06463061-20021008-P00008
Figure US06463061-20021008-P00009
Figure US06463061-20021008-P00010
Figure US06463061-20021008-P00011
Figure US06463061-20021008-P00012
Figure US06463061-20021008-P00013
Figure US06463061-20021008-P00014
Figure US06463061-20021008-P00015
Figure US06463061-20021008-P00016
Figure US06463061-20021008-P00017
Figure US06463061-20021008-P00018
Figure US06463061-20021008-P00019
Figure US06463061-20021008-P00020
Figure US06463061-20021008-P00021
Figure US06463061-20021008-P00022
Figure US06463061-20021008-P00023
Figure US06463061-20021008-P00024
Figure US06463061-20021008-P00025
Figure US06463061-20021008-P00026
Figure US06463061-20021008-P00027
Figure US06463061-20021008-P00028
Figure US06463061-20021008-P00029
Figure US06463061-20021008-P00030
Figure US06463061-20021008-P00031
Figure US06463061-20021008-P00032
Figure US06463061-20021008-P00033
Figure US06463061-20021008-P00034
Figure US06463061-20021008-P00035
Figure US06463061-20021008-P00036
Figure US06463061-20021008-P00037
Figure US06463061-20021008-P00038
Figure US06463061-20021008-P00039
Figure US06463061-20021008-P00040
Figure US06463061-20021008-P00041
Figure US06463061-20021008-P00042
Figure US06463061-20021008-P00043
Figure US06463061-20021008-P00044
Figure US06463061-20021008-P00045
Figure US06463061-20021008-P00046
Figure US06463061-20021008-P00047
Figure US06463061-20021008-P00048
Figure US06463061-20021008-P00049
Figure US06463061-20021008-P00050
Figure US06463061-20021008-P00051
Figure US06463061-20021008-P00052
Figure US06463061-20021008-P00053
Figure US06463061-20021008-P00054
Figure US06463061-20021008-P00055
Figure US06463061-20021008-P00056
Figure US06463061-20021008-P00057
Figure US06463061-20021008-P00058
Figure US06463061-20021008-P00059
Figure US06463061-20021008-P00060
Figure US06463061-20021008-P00061
Figure US06463061-20021008-P00062
Figure US06463061-20021008-P00063
Figure US06463061-20021008-P00064
Figure US06463061-20021008-P00065
Figure US06463061-20021008-P00066
Figure US06463061-20021008-P00067
Figure US06463061-20021008-P00068
Figure US06463061-20021008-P00069
Figure US06463061-20021008-P00070
Figure US06463061-20021008-P00071
Figure US06463061-20021008-P00072

Claims (5)

What is claimed is:
1. A communications system comprising:
A) a set of customer nodes so divided into at least first and second customer-node subsets that no node of any given subset is a routing adjacency of any other subset's node, the first customer-node subset including a target node associated with a target network address;
B) a set of outside nodes separate from the set of customer nodes, at least one of the outside nodes being an outside edge router, and
C) a service-provider network that associates internal and external VPN IDs with the set of customer nodes, forms a virtual private network with the set of customer nodes, and includes a plurality of provider nodes, including provider edge routers associated with the set of customer nodes, the provider edge routers associated with the set of customer nodes making routing decisions based on contents of reachability messages that they have received and together forming routing adjacencies with at least one node in every one of the customer-node subsets, each provider edge router associated with the set of customer nodes forming a routing adjacency with at least one customer node, denominated a customer edge router, to which the provider edge router is linked by at least one provider-customer channel, such that at least first and second ones of the provider-customer channels (i) are formed between the first customer-node subset and the service-provider network, (ii) provide access to the target node, and (iii) carry from at least one said customer edge router to at least one said provider edge router reachability messages that advertise a network-address range that includes the target network address, the provider nodes further including at least one provider edge router that is associated with the set of outside nodes, makes routing decisions based on the contents of reachability messages that it has received, and forms a provider-exterior channel with the outside edge router, wherein:
i) when a said provider edge router receives through the first provider-customer channel a reachability message that advertises a network-address range that includes the target network address, the provider edge router sends a reachability message that advertises a combination of the internal VPN ID and the network-address range to each other provider edge router that forms a provider-customer channel with the set of customer communications nodes;
ii) when a said provider edge router receives through the second provider-customer channel a reachability message that advertises a network-address range that includes the target network address, the provider edge router sends a reachability message that advertises a combination of the external VPN ID and the network-address range to at least one provider edge router associated with the set of outside nodes;
iii) when a said provider edge router associated with the set of customer nodes receives from a provider router a reachability message that advertises a combination of a network-address range and the internal VPN ID associated with the set of customer nodes, the provider edge router sends to one said customer edge router with which it forms a provider-customer channel a reachability message that advertises the network-address range; and
iv) when a said provider edge router associated with the set of outside nodes receives from a provider router a reachability message that advertises a combination of a network-address range and the external VPN ID associated with the set of customer nodes, it sends to at least one said customer edge, router with which it forms a provider-exterior channel a reachability message that advertises the network-address range.
2. A communications system is defined in claim 1 wherein at least one said provider edge router associated with the set of customer nodes includes circuitry for:
A) receiving by way of a provider-customer channel that links the provider edge router to a customer edge router in one of the customer-node subsets data packets that include destination-address fields that specify customer nodes in another of the customer-node subsets;
B) for each of a plurality of such received packets;
i) making a routing decision based on the contents of the packet's destination-address field;
ii) inserting into the packet an internal-routing field, determined at least in part in accordance with a source from which the edge router received the packet, that specifics a route to a channel that links another of the provider edge routers; and
iii) forwarding the resultant packet to another router in the service-provider network in accordance with the routing decision; and
C) receiving, from other routers in the service provider network, packets that include internal-routing fields and forwarding them without their internal-routing fields by way of a provider-customer channel that the provider edge router selects in accordance with the contents of the packets' internal-routing fields.
3. A communications system as defined in claim 2 wherein:
A) when a provider edge router associated with the set of customer nodes receives therefrom a data packet whose destination-address field contains the target network address, it inserts into the packet an internal-routing field that specifies a route to the first provider-customer channel that provides access to the target node; and
B) when a provider edge router associated with the set of outside nodes receives therefrom a data packet whose destination-address field contains the target network address, it inserts into the packet an internal-routing field that specifies a route to the second provider-customer channel that provides access to the target node.
4. A communications system as defined in claim 2 wherein the plurality of provider nodes includes provider transit routers that form no routing adjacencies with any node of the set of customer or outside nodes, each provider transit router including circuitry for:
A) receiving, from other routers in the service-provider network, packets that include internal-routing fields and destination-address fields;
B) making routing decisions based on the contents of the packets' internal-routing fields without reference to the contents of the packets' destination-address fields; and
C) in accordance with the routing decisions, forwarding the packets to other routers in the service-provider network.
5. A communications system as defined in claim 4 wherein:
A) when a provider edge router associated with the set of customer nodes receives therefrom a data packet whose destination-address field contains the target network address, the provider edge router inserts into the packet an internal-routing field that specifies a route to the first provider-customer channel that provides access to the target node; and
B) when a provider edge router associated with the set of outside nodes receives therefrom a data packet whose destination-address field contains the target network address, the provider edge router inserts into the packet an internal-routing field that specifies a route to the second provider-customer channel that provides access to the target node.
US09/232,947 1997-12-23 1999-01-19 Shared communications network employing virtual-private-network identifiers Expired - Lifetime US6463061B1 (en)

Priority Applications (2)

Application Number Priority Date Filing Date Title
US09/232,947 US6463061B1 (en) 1997-12-23 1999-01-19 Shared communications network employing virtual-private-network identifiers
US10/246,936 US7307990B2 (en) 1999-01-19 2002-09-19 Shared communications network employing virtual-private-network identifiers

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US08/997,343 US6339595B1 (en) 1997-12-23 1997-12-23 Peer-model support for virtual private networks with potentially overlapping addresses
US09/232,947 US6463061B1 (en) 1997-12-23 1999-01-19 Shared communications network employing virtual-private-network identifiers

Related Parent Applications (1)

Application Number Title Priority Date Filing Date
US08/997,343 Division US6339595B1 (en) 1997-12-23 1997-12-23 Peer-model support for virtual private networks with potentially overlapping addresses

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US10/246,936 Continuation US7307990B2 (en) 1999-01-19 2002-09-19 Shared communications network employing virtual-private-network identifiers

Publications (1)

Publication Number Publication Date
US6463061B1 true US6463061B1 (en) 2002-10-08

Family

ID=25543907

Family Applications (5)

Application Number Title Priority Date Filing Date
US08/997,343 Expired - Lifetime US6339595B1 (en) 1997-12-23 1997-12-23 Peer-model support for virtual private networks with potentially overlapping addresses
US09/217,976 Expired - Lifetime US6526056B1 (en) 1997-12-23 1998-12-21 Virtual private network employing tag-implemented egress-channel selection
US09/232,947 Expired - Lifetime US6463061B1 (en) 1997-12-23 1999-01-19 Shared communications network employing virtual-private-network identifiers
US10/001,516 Expired - Lifetime US7154889B1 (en) 1997-12-23 2001-10-23 Peer-model support for virtual private networks having potentially overlapping addresses
US10/868,720 Expired - Fee Related US7668166B1 (en) 1997-12-23 2004-06-15 Peer-model support for virtual private networks having potentially overlapping addresses

Family Applications Before (2)

Application Number Title Priority Date Filing Date
US08/997,343 Expired - Lifetime US6339595B1 (en) 1997-12-23 1997-12-23 Peer-model support for virtual private networks with potentially overlapping addresses
US09/217,976 Expired - Lifetime US6526056B1 (en) 1997-12-23 1998-12-21 Virtual private network employing tag-implemented egress-channel selection

Family Applications After (2)

Application Number Title Priority Date Filing Date
US10/001,516 Expired - Lifetime US7154889B1 (en) 1997-12-23 2001-10-23 Peer-model support for virtual private networks having potentially overlapping addresses
US10/868,720 Expired - Fee Related US7668166B1 (en) 1997-12-23 2004-06-15 Peer-model support for virtual private networks having potentially overlapping addresses

Country Status (1)

Country Link
US (5) US6339595B1 (en)

Cited By (99)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20020152373A1 (en) * 2000-09-13 2002-10-17 Chih-Tang Sun Tunnel interface for securing traffic over a network
US20020154635A1 (en) * 2001-04-23 2002-10-24 Sun Microsystems, Inc. System and method for extending private networks onto public infrastructure using supernets
US20030002468A1 (en) * 2001-06-28 2003-01-02 Mohamed Khalil Virtual private network identification extension
US20030088697A1 (en) * 2000-06-16 2003-05-08 Naoki Matsuhira Communication device having VPN accommodation function
US20030115480A1 (en) * 2001-12-17 2003-06-19 Worldcom, Inc. System, method and apparatus that employ virtual private networks to resist IP QoS denial of service attacks
US20030112799A1 (en) * 2001-11-17 2003-06-19 Ravi Chandra Method and apparatus for multiple contexts and layer 3 virtual private networks
US20030118036A1 (en) * 2001-12-21 2003-06-26 Mark Gibson Routing traffic in a communications network
US20030132539A1 (en) * 2000-06-22 2003-07-17 Olaf Althoff Device for producing dental workpieces
US20030161312A1 (en) * 2002-02-27 2003-08-28 International Business Machines Corporation Apparatus and method of maintaining two-byte IP identification fields in IP headers
US20030205354A1 (en) * 2000-03-16 2003-11-06 Dong Xu Sliding gate for liquid metal flow control
US20030223361A1 (en) * 2002-06-04 2003-12-04 Zahid Hussain System and method for hierarchical metering in a virtual router based network switch
US20030223418A1 (en) * 2002-06-04 2003-12-04 Sachin Desai Network packet steering
US6693878B1 (en) * 1999-10-15 2004-02-17 Cisco Technology, Inc. Technique and apparatus for using node ID as virtual private network (VPN) identifiers
US20040078621A1 (en) * 2002-08-29 2004-04-22 Cosine Communications, Inc. System and method for virtual router failover in a network routing system
US20040076165A1 (en) * 2002-10-22 2004-04-22 Le Pennec Jean-Francois Virtual private network based upon multi-protocol label switching adapted to measure the traffic flowing between single rate zones
US20040093424A1 (en) * 2002-11-05 2004-05-13 Kozo Kojima Packet routing device
US20040095934A1 (en) * 2002-11-18 2004-05-20 Cosine Communications, Inc. System and method for hardware accelerated packet multicast in a virtual routing system
FR2851706A1 (en) * 2003-02-20 2004-08-27 6Wind Virtual private networks interconnecting method, involves embedding encapsulation mechanism in access router of operator, where mechanism calculates header for desired messages to be transmitted
US20040208122A1 (en) * 2001-03-20 2004-10-21 Mcdysan David E. Virtual private network (VPN)-aware customer premises equipment (CPE) edge router
US20040215793A1 (en) * 2001-09-30 2004-10-28 Ryan Grant James Personal contact network
US20040260949A1 (en) * 2003-06-20 2004-12-23 Aoki Norihiro Edwin Chaining of services
US20050066053A1 (en) * 2001-03-20 2005-03-24 Worldcom, Inc. System, method and apparatus that isolate virtual private network (VPN) and best effort traffic to resist denial of service attacks
US20050074003A1 (en) * 2003-10-02 2005-04-07 Ball David Alexander Distributed software architecture for implementing BGP
US20050074001A1 (en) * 2002-11-12 2005-04-07 Cisco Technology, Inc. System and method for local packet transport services within distributed routers
US20050086502A1 (en) * 2003-10-16 2005-04-21 Ammar Rayes Policy-based network security management
US20050086368A1 (en) * 2003-10-15 2005-04-21 Dell Products L.P. System and method for determining nearest neighbor information
US20050175001A1 (en) * 2004-02-09 2005-08-11 Becker Hof Onno M. Context selection in a network element through subscriber flow switching
US20050195835A1 (en) * 2004-03-02 2005-09-08 Savage Donnie V. Router configured for outputting update messages specifying a detected attribute change of a connected active path according to a prescribed routing protocol
US6970941B1 (en) 1999-12-10 2005-11-29 Sun Microsystems, Inc. System and method for separating addresses from the delivery scheme in a virtual private network
US20050265308A1 (en) * 2004-05-07 2005-12-01 Abdulkadev Barbir Selection techniques for logical grouping of VPN tunnels
US6973072B1 (en) 2001-02-22 2005-12-06 Cisco Technology, Inc. High performance protocol for an interconnect system of an intermediate network node
US6977929B1 (en) 1999-12-10 2005-12-20 Sun Microsystems, Inc. Method and system for facilitating relocation of devices on a network
US20060007939A1 (en) * 2004-07-09 2006-01-12 Anusankar Elangovan Scaling VLANs in a data network
US20060013209A1 (en) * 2003-06-19 2006-01-19 Cisco Technology, Inc. Apparatus and methods for handling shared services through virtual route forwarding(VRF) -aware- NAT
US20060182115A1 (en) * 2005-02-16 2006-08-17 Himanshu Shah System for scheduling scans of interior nodes of a network domain for reachability events
US20060198368A1 (en) * 2005-03-04 2006-09-07 Guichard James N Secure multipoint internet protocol virtual private networks
US20060215698A1 (en) * 2003-11-19 2006-09-28 Amen Hamdan Communication subsystem controlled information dissemination
US7154889B1 (en) 1997-12-23 2006-12-26 Cisco Technology, Inc. Peer-model support for virtual private networks having potentially overlapping addresses
WO2007006193A1 (en) * 2005-07-07 2007-01-18 Huawei Technologies Co., Ltd. A method for preventing the user from obtaining the service provider network information and the equipment as well as the system thereof
CN1297105C (en) * 2003-01-06 2007-01-24 华为技术有限公司 Method for implementing multirole main machine based on virtual local network
US7174372B1 (en) 2000-09-13 2007-02-06 Fortinet, Inc. System and method for managing router metadata
US7177311B1 (en) 2002-06-04 2007-02-13 Fortinet, Inc. System and method for routing traffic through a virtual router-based network switch
US7184437B1 (en) * 2002-07-17 2007-02-27 Juniper Networks, Inc. Scalable route resolution
US20070091793A1 (en) * 2005-10-20 2007-04-26 Clarence Filsfils Method and apparatus for managing forwarding of data in an autonomous system
US20070091794A1 (en) * 2005-10-20 2007-04-26 Clarence Filsfils Method of constructing a backup path in an autonomous system
US20070091795A1 (en) * 2005-10-20 2007-04-26 Olivier Bonaventure Method of constructing a backup path in an autonomous system
US20070091796A1 (en) * 2005-10-20 2007-04-26 Clarence Filsfils Method of implementing a backup path in an autonomous system
US20070104119A1 (en) * 2000-09-13 2007-05-10 Fortinet, Inc. System and method for managing and provisioning virtual routers
US20070115979A1 (en) * 2004-11-18 2007-05-24 Fortinet, Inc. Method and apparatus for managing subscriber profiles
US20070121615A1 (en) * 2005-11-28 2007-05-31 Ofer Weill Method and apparatus for self-learning of VPNS from combination of unidirectional tunnels in MPLS/VPN networks
US20070121579A1 (en) * 2000-09-13 2007-05-31 Fortinet, Inc. Packet routing system and method
CN1323525C (en) * 2003-06-12 2007-06-27 华为技术有限公司 Method for communication in VPN by using route distinguisher (RD)
US20070189157A1 (en) * 2006-02-13 2007-08-16 Cisco Technology, Inc. Method and system for providing safe dynamic link redundancy in a data network
US20070217419A1 (en) * 2006-03-14 2007-09-20 Jean-Philippe Vasseur Technique for efficiently routing IP traffic on CE-CE paths across a provider network
US20070237095A1 (en) * 2006-04-05 2007-10-11 Cisco Technology, Inc. System and method for improving network performance and security by controlling topology information
US7286529B1 (en) 1999-02-26 2007-10-23 Cisco Technology, Inc. Discovery and tag space identifiers in a tag distribution protocol (TDP)
US20070260746A1 (en) * 2006-05-08 2007-11-08 Sina Mirtorabi Maintaining IGP transparency of VPN routes when BGP is used as a PE-CE protocol
US7336790B1 (en) 1999-12-10 2008-02-26 Sun Microsystems Inc. Decoupling access control from key management in a network
US7340535B1 (en) 2002-06-04 2008-03-04 Fortinet, Inc. System and method for controlling routing in a virtual router system
US7369556B1 (en) 1997-12-23 2008-05-06 Cisco Technology, Inc. Router for virtual private network employing tag switching
US20080112418A1 (en) * 2006-11-14 2008-05-15 Cisco Technology, Inc. Modification to as_path elements
US7376125B1 (en) 2002-06-04 2008-05-20 Fortinet, Inc. Service processing switch
US20080117917A1 (en) * 2004-11-18 2008-05-22 Fortinet, Inc. Method and apparatus for managing subscriber profiles
US7389358B1 (en) * 2000-09-13 2008-06-17 Fortinet, Inc. Distributed virtual system to support managed, network-based services
US20080198849A1 (en) * 2007-02-20 2008-08-21 Jim Guichard Scaling virtual private networks using service insertion architecture
US7420958B1 (en) * 2004-01-30 2008-09-02 Juniper Networks, Inc. Providing transparent virtual private network connectivity across intermediate networks
US20080219153A1 (en) * 2006-09-08 2008-09-11 Cisco Technology, Inc. Constructing a repair path in the event of failure of an inter-routing domain system link
US7444398B1 (en) 2000-09-13 2008-10-28 Fortinet, Inc. System and method for delivering security services
US20090097492A1 (en) * 2007-10-12 2009-04-16 Telefonaktiebolaget Lm Ericsson (Publ) Support of triple play services in user devices
US7539744B2 (en) 2000-09-13 2009-05-26 Fortinet, Inc. Network operating system for maintaining redundant master control blade management information
US7574495B1 (en) 2000-09-13 2009-08-11 Fortinet, Inc. System and method for managing interworking communications protocols
US7580373B2 (en) 2001-06-28 2009-08-25 Fortinet, Inc. Identifying nodes in a ring network
US7583672B2 (en) 2006-04-05 2009-09-01 Cisco Technology, Inc. Techniques to support asymmetrical static/dynamic adjacency in routers
US7607021B2 (en) 2004-03-09 2009-10-20 Cisco Technology, Inc. Isolation approach for network users associated with elevated risk
US20090296579A1 (en) * 2008-05-30 2009-12-03 Cisco Technology, Inc. Efficient convergence of grouped vpn prefixes
US7633874B1 (en) 2004-04-28 2009-12-15 Cisco Technology, Inc. Soft notification messaging for a routing protocol
US20100008361A1 (en) * 2008-07-08 2010-01-14 Cisco Technology, Inc. Carrier's carrier without customer-edge-to-customer-edge border gateway protocol
US7710899B1 (en) 2005-08-16 2010-05-04 Cisco Technology, Inc. System and method for speeding border gateway protocol graceful restart
US7710872B2 (en) 2005-12-14 2010-05-04 Cisco Technology, Inc. Technique for enabling traffic engineering on CE-CE paths across a provider network
US7724745B1 (en) 2006-03-09 2010-05-25 Cisco Technology, Inc. Method and device for efficient transmission of flood data frames in a backbone network
US20100142527A1 (en) * 2004-09-24 2010-06-10 Fortinet, Inc. Scalable IP-Services Enabled Multicast Forwarding with Efficient Resource Utilization
US7765581B1 (en) 1999-12-10 2010-07-27 Oracle America, Inc. System and method for enabling scalable security in a virtual private network
US7779461B1 (en) * 2004-11-16 2010-08-17 Juniper Networks, Inc. Point-to-multi-point/non-broadcasting multi-access VPN tunnels
US20100296517A1 (en) * 2001-10-19 2010-11-25 Juniper Networks, Inc. Network routing using indirect next hop data
US7860115B1 (en) * 2003-12-18 2010-12-28 Cisco Technology, Inc. Withdrawing multiple advertised routes based on a single tag which may be of particular use in border gateway protocol
US20110010413A1 (en) * 2009-07-09 2011-01-13 International Business Machines Corporation Tcp/ip host name resolution on a private network
US20110010463A1 (en) * 2009-07-09 2011-01-13 International Business Machines Corporation Propogation of dns server ip addresses in a private network
US20110055374A1 (en) * 2009-08-31 2011-03-03 International Business Machines Corporation Computer implemented dns server ip address lookup mechanism
US20120227102A1 (en) * 2011-03-03 2012-09-06 Cisco Technology, Inc. Dynamic Tunneling over Virtual Private Network Connections based on Network Conditions
US8503463B2 (en) 2003-08-27 2013-08-06 Fortinet, Inc. Heterogeneous media packet bridging
US20130346555A1 (en) * 1999-06-15 2013-12-26 Tectia Oyj Method and arrangement for providing security through network address translations using tunneling and compensations
TWI423616B (en) * 2008-07-31 2014-01-11 Broadcom Corp Data path acceleration of a network stack
US8705374B1 (en) * 2006-10-31 2014-04-22 At&T Intellectual Property Ii, L.P. Method and apparatus for isolating label-switched path impairments
US20140139865A1 (en) * 2012-11-20 2014-05-22 Fuji Xerox Co., Ltd. Information processing apparatus, information processing method, and non-transitory computer readable medium
US20140160981A1 (en) * 2001-03-19 2014-06-12 Juniper Networks, Inc. Transport networks supporting virtual private networks, and configuring such networks
US8937961B1 (en) 2010-12-07 2015-01-20 Juniper Networks, Inc. Modular software architecture for a route server within an internet exchange
US9049148B1 (en) 2012-09-28 2015-06-02 Juniper Networks, Inc. Dynamic forwarding plane reconfiguration in a network device
US9338080B2 (en) 2012-09-14 2016-05-10 Cisco Technology, Inc. Performing offline BGP prefix origin and path validation at route reflectors
US20160381573A1 (en) * 2015-06-04 2016-12-29 Telefonaktiebolaget L M Ericsson (Publ) Controlling communication mode of a mobile terminal

Families Citing this family (403)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE69928504T2 (en) * 1998-03-13 2006-07-27 Schlumberger Omnes, Inc., Houston Providing secure access to network services
US6665271B1 (en) * 1998-03-17 2003-12-16 Transnexus, Llc System for real-time prediction of quality for internet-based multimedia communications
US6501755B1 (en) 1998-06-11 2002-12-31 Alcatel Canada Inc. Stacked address transport in connection oriented networks
US6330598B1 (en) * 1998-06-23 2001-12-11 Ameritech Corporation Global service management system for an advanced intelligent network
US6717942B1 (en) * 1998-06-25 2004-04-06 Avici Systems, Inc. Space-efficient source routing
US7095740B1 (en) * 1998-06-30 2006-08-22 Nortel Networks Limited Method and apparatus for virtual overlay networks
US7039687B1 (en) * 1998-08-07 2006-05-02 Nortel Networks Limited Multi-protocol label switching virtual private networks
US6584093B1 (en) * 1998-08-25 2003-06-24 Cisco Technology, Inc. Method and apparatus for automatic inter-domain routing of calls
CA2254813A1 (en) * 1998-11-18 2000-05-18 Northern Telecom Limited Distribution of reachability information in data virtual private networks
US8713641B1 (en) 1998-12-08 2014-04-29 Nomadix, Inc. Systems and methods for authorizing, authenticating and accounting users having transparent computer access to a network using a gateway device
US7194554B1 (en) 1998-12-08 2007-03-20 Nomadix, Inc. Systems and methods for providing dynamic network authorization authentication and accounting
US8266266B2 (en) 1998-12-08 2012-09-11 Nomadix, Inc. Systems and methods for providing dynamic network authorization, authentication and accounting
US6609153B1 (en) 1998-12-24 2003-08-19 Redback Networks Inc. Domain isolation through virtual network machines
US6903755B1 (en) * 1998-12-31 2005-06-07 John T. Pugaczewski Network management system and graphical user interface
US6611872B1 (en) * 1999-01-11 2003-08-26 Fastforward Networks, Inc. Performing multicast communication in computer networks by using overlay routing
US6980515B1 (en) 1999-02-23 2005-12-27 Alcatel Multi-service network switch with quality of access
US6717913B1 (en) * 1999-02-23 2004-04-06 Alcatel Multi-service network switch with modem pool management
US6789118B1 (en) * 1999-02-23 2004-09-07 Alcatel Multi-service network switch with policy based routing
US6674756B1 (en) 1999-02-23 2004-01-06 Alcatel Multi-service network switch with multiple virtual routers
US6487167B1 (en) * 1999-03-10 2002-11-26 Nortel Networks Limited Exclusion list of senders to an autonomous system
US6640251B1 (en) * 1999-03-12 2003-10-28 Nortel Networks Limited Multicast-enabled address resolution protocol (ME-ARP)
US6885677B1 (en) * 1999-03-12 2005-04-26 Fujitsu Limited Multiprotocol label switching routers
US6788681B1 (en) * 1999-03-16 2004-09-07 Nortel Networks Limited Virtual private networks and methods for their operation
US6873618B1 (en) * 1999-03-16 2005-03-29 Nortel Networks Limited Multipoint network routing protocol
US6473421B1 (en) * 1999-03-29 2002-10-29 Cisco Technology, Inc. Hierarchical label switching across multiple OSPF areas
US6654808B1 (en) * 1999-04-02 2003-11-25 Lucent Technologies Inc. Proving quality of service in layer two tunneling protocol networks
WO2000072533A1 (en) * 1999-05-21 2000-11-30 Broadcom Corporation Stacked network switch configuration
US6813268B1 (en) * 1999-05-21 2004-11-02 Broadcom Corporation Stacked network switch configuration
US6879588B1 (en) * 1999-05-21 2005-04-12 Broadcom Corporation Address resolution snoop support for CPU
US6728777B1 (en) * 1999-06-02 2004-04-27 Nortel Networks Limited Method for engineering paths for multicast traffic
GB9913239D0 (en) * 1999-06-08 1999-08-04 Marconi Comm Ltd Communications arrangement
JP3449294B2 (en) * 1999-06-18 2003-09-22 日本電気株式会社 Multiprotocol processing device, line interface, and multiprotocol switch system having the same
US6512744B1 (en) 1999-06-25 2003-01-28 Cisco Technology, Inc. Virtual-channel merging
US7444407B2 (en) * 2000-06-29 2008-10-28 Transnexus, Inc. Intelligent end user devices for clearinghouse services in an internet telephony system
US6628654B1 (en) * 1999-07-01 2003-09-30 Cisco Technology, Inc. Dispatching packets from a forwarding agent using tag switching
US6473431B1 (en) * 1999-07-02 2002-10-29 Sun Microsystems, Inc. System and method facilitating determination by router nodes in a network of ranges of addresses for which each router node is responsible
US6882643B1 (en) * 1999-07-16 2005-04-19 Nortel Networks Limited Supporting multiple services in label switched networks
US6675225B1 (en) * 1999-08-26 2004-01-06 International Business Machines Corporation Method and system for algorithm-based address-evading network snoop avoider
US6523068B1 (en) * 1999-08-27 2003-02-18 3Com Corporation Method for encapsulating and transmitting a message includes private and forwarding network addresses with payload to an end of a tunneling association
US6680933B1 (en) * 1999-09-23 2004-01-20 Nortel Networks Limited Telecommunications switches and methods for their operation
US7151775B1 (en) * 1999-09-23 2006-12-19 Pluris, Inc. Apparatus and method for forwarding data on multiple label-switched data paths
US7298693B1 (en) * 1999-10-21 2007-11-20 Tellabs Operations, Inc. Reverse notification tree for data networks
AU1340201A (en) * 1999-10-21 2001-04-30 Tellabs Operations, Inc. Reverse notification tree for data networks
US7315510B1 (en) 1999-10-21 2008-01-01 Tellabs Operations, Inc. Method and apparatus for detecting MPLS network failures
US7197556B1 (en) * 1999-10-22 2007-03-27 Nomadix, Inc. Location-based identification for use in a communications network
US7804767B1 (en) 1999-10-25 2010-09-28 Tellabs Operations, Inc. Protection/restoration of MPLS networks
ATE265774T1 (en) 1999-12-07 2004-05-15 Broadcom Corp MIRROR IN A NETWORK SWITCH STACK ARRANGEMENT
US6594704B1 (en) * 1999-12-15 2003-07-15 Quarry Technologies Method of managing and using multiple virtual private networks in a router with a single routing table
US20020010866A1 (en) * 1999-12-16 2002-01-24 Mccullough David J. Method and apparatus for improving peer-to-peer bandwidth between remote networks by combining multiple connections which use arbitrary data paths
US7203956B2 (en) 1999-12-22 2007-04-10 Transnexus, Inc. System and method for the secure enrollment of devices with a clearinghouse server for internet telephony and multimedia communications
US6738354B1 (en) * 2000-02-18 2004-05-18 Nortel Networks Limited Label selection for end-to-end label-switched traffic through a communications network
US7076559B1 (en) * 1999-12-28 2006-07-11 Nortel Networks Limited System, device, and method for establishing label switched paths across multiple autonomous systems
US20020091855A1 (en) * 2000-02-02 2002-07-11 Yechiam Yemini Method and apparatus for dynamically addressing and routing in a data network
US7310671B1 (en) * 2000-02-10 2007-12-18 Paradyne Corporation System and method for a trouble shooting portal to allow temporary management access to a communication device
US6725264B1 (en) * 2000-02-17 2004-04-20 Cisco Technology, Inc. Apparatus and method for redirection of network management messages in a cluster of network devices
US7343413B2 (en) 2000-03-21 2008-03-11 F5 Networks, Inc. Method and system for optimizing a network by independently scaling control segments and data flow
US8380854B2 (en) 2000-03-21 2013-02-19 F5 Networks, Inc. Simplified method for processing multiple connections from the same client
US6947931B1 (en) * 2000-04-06 2005-09-20 International Business Machines Corporation Longest prefix match (LPM) algorithm implementation for a network processor
US7028334B2 (en) * 2000-04-12 2006-04-11 Corente, Inc. Methods and systems for using names in virtual networks
US7028333B2 (en) * 2000-04-12 2006-04-11 Corente, Inc. Methods and systems for partners in virtual networks
US7181766B2 (en) * 2000-04-12 2007-02-20 Corente, Inc. Methods and system for providing network services using at least one processor interfacing a base network
US7181542B2 (en) * 2000-04-12 2007-02-20 Corente, Inc. Method and system for managing and configuring virtual private networks
US6631416B2 (en) 2000-04-12 2003-10-07 Openreach Inc. Methods and systems for enabling a tunnel between two computers on a network
US6996628B2 (en) * 2000-04-12 2006-02-07 Corente, Inc. Methods and systems for managing virtual addresses for virtual networks
US7085854B2 (en) * 2000-04-12 2006-08-01 Corente, Inc. Methods and systems for enabling communication between a processor and a network operations center
US7047424B2 (en) * 2000-04-12 2006-05-16 Corente, Inc. Methods and systems for hairpins in virtual networks
US7123620B1 (en) * 2000-04-25 2006-10-17 Cisco Technology, Inc. Apparatus and method for scalable and dynamic traffic engineering in a data communication network
US7151773B1 (en) * 2000-05-05 2006-12-19 Fujitsu Limited System and method for connectionless/connection oriented signal transport
US7103626B1 (en) * 2000-05-24 2006-09-05 Hewlett-Packard Development, L.P. Partitioning in distributed computer system
JP4168574B2 (en) * 2000-06-02 2008-10-22 株式会社日立製作所 Packet transfer apparatus, packet transfer control method, and packet transfer apparatus setting method
JP2001358756A (en) * 2000-06-09 2001-12-26 Nec Corp Method and device for setting router
US6751220B1 (en) * 2000-06-12 2004-06-15 Nortel Networks Limited Apparatus and method of managing virtual private network routing data
US20020013823A1 (en) * 2000-06-16 2002-01-31 Eubanks Thomas Marshall Multicast peering in multicast points of presence (MULTIPOPs) network - neutral multicast internet exchange
US7158515B1 (en) * 2000-07-06 2007-01-02 Nortel Networks Limited Method of optical network bandwidth representation for optical label switching networks
JP2002026972A (en) * 2000-07-10 2002-01-25 Fujitsu Ltd Icmp data frame filtering method and its node unit
US7274704B1 (en) * 2000-07-14 2007-09-25 Nortel Networks Limited Piggybacking VPN information in BGP for network based VPN architectures
US6714556B1 (en) * 2000-07-17 2004-03-30 Advanced Micro Devices, Inc. In-band management of a stacked group of switches by a single CPU
US7023846B1 (en) * 2000-07-18 2006-04-04 Nortel Networks Limited System, device, and method for establishing and removing a label switched path in a communication network
US7336682B2 (en) * 2000-07-25 2008-02-26 Juniper Networks, Inc. Network architecture and methods for transparent on-line cross-sessional encoding and transport of network communications data
US6856651B2 (en) * 2000-07-25 2005-02-15 Peribit Networks, Inc. System and method for incremental and continuous data compression
US7042834B1 (en) * 2000-07-28 2006-05-09 Cisco Technology, Inc. Method and system for routing communications among computer networks
US6772226B1 (en) * 2000-08-15 2004-08-03 Avaya Technology Corp. VPN device clustering using a network flow switch and a different mac address for each VPN device in the cluster
US7586899B1 (en) 2000-08-18 2009-09-08 Juniper Networks, Inc. Methods and apparatus providing an overlay network for voice over internet protocol applications
US7002993B1 (en) * 2000-08-18 2006-02-21 Juniper Networks, Inc. Method and apparatus providing media aggregation in a packet-switched network
US6836462B1 (en) 2000-08-30 2004-12-28 Cisco Technology, Inc. Distributed, rule based packet redirection
ATE362251T1 (en) 2000-09-11 2007-06-15 Transnexus Inc BILLING SERVER FOR INTERNET AND MULTIMEDIA COMMUNICATIONS
US20020105965A1 (en) * 2000-09-22 2002-08-08 Narad Networks, Inc. Broadband system having routing identification based switching
US7139247B2 (en) * 2000-09-22 2006-11-21 Narad Networks, Inc. Broadband system with topology discovery
US8023421B2 (en) 2002-07-25 2011-09-20 Avaya Inc. Method and apparatus for the assessment and optimization of network traffic
US7720959B2 (en) 2000-10-17 2010-05-18 Avaya Inc. Method and apparatus for characterizing the quality of a network path
AU2002213287A1 (en) 2000-10-17 2002-04-29 Routescience Technologies Inc Method and apparatus for performance and cost optimization in an internetwork
US7080161B2 (en) * 2000-10-17 2006-07-18 Avaya Technology Corp. Routing information exchange
US7363367B2 (en) 2000-10-17 2008-04-22 Avaya Technology Corp. Systems and methods for robust, real-time measurement of network performance
US7406539B2 (en) 2000-10-17 2008-07-29 Avaya Technology Corp. Method and apparatus for performance and cost optimization in an internetwork
US7336613B2 (en) 2000-10-17 2008-02-26 Avaya Technology Corp. Method and apparatus for the assessment and optimization of network traffic
US7487237B2 (en) * 2000-10-17 2009-02-03 Avaya Technology Corp. Load optimization
US7756032B2 (en) 2000-10-17 2010-07-13 Avaya Inc. Method and apparatus for communicating data within measurement traffic
US7349994B2 (en) 2000-10-17 2008-03-25 Avaya Technology Corp. Method and apparatus for coordinating routing parameters via a back-channel communication medium
US6985447B2 (en) * 2000-10-20 2006-01-10 Nortel Networks Limited Label switched traffic routing and signaling in a label switched communication packet network
US6985959B1 (en) * 2000-11-01 2006-01-10 Nortel Networks Limited Constraint route dissemination using distributed route exchanges
JP4183379B2 (en) * 2000-11-27 2008-11-19 富士通株式会社 Network and edge router
US6901076B2 (en) * 2000-11-30 2005-05-31 Sun Microsystems, Inc. Dynamic LAN boundaries
JP4225681B2 (en) * 2000-12-06 2009-02-18 富士通株式会社 Virtual closed network construction method and apparatus, and relay apparatus
US20020124066A1 (en) * 2000-12-15 2002-09-05 International Business Machines Corporation Method and system for unambiguous addressability in a distributed application framework in which duplicate network addresses exist across multiple customer networks
US7051104B1 (en) * 2000-12-21 2006-05-23 Cisco Technology, Inc. System and method for extending the ITU Q.922 LAPF virtual circuit disconnect logic to prevent unsynchronized virtual circuit establishment
US20020087724A1 (en) * 2000-12-29 2002-07-04 Ragula Systems D/B/A Fatpipe Networks Combining connections for parallel access to multiple frame relay and other private networks
US6775235B2 (en) 2000-12-29 2004-08-10 Ragula Systems Tools and techniques for directing packets over disparate networks
US6618388B2 (en) * 2001-01-05 2003-09-09 Extreme Networks Method and system for VMAN protocol
US7525956B2 (en) 2001-01-11 2009-04-28 Transnexus, Inc. Architectures for clearing and settlement services between internet telephony clearinghouses
US20020101868A1 (en) * 2001-01-30 2002-08-01 David Clear Vlan tunneling protocol
WO2002065607A1 (en) * 2001-02-12 2002-08-22 Maple Optical Systems, Inc. Multiple level fault protection in a communications network
US6901073B2 (en) * 2001-02-14 2005-05-31 Northrop Grumman Corporation Encapsulation method and apparatus for communicating fixed-length data packets through an intermediate network
US20020110087A1 (en) * 2001-02-14 2002-08-15 David Zelig Efficient setup of label-switched connections
US7739497B1 (en) * 2001-03-21 2010-06-15 Verizon Corporate Services Group Inc. Method and apparatus for anonymous IP datagram exchange using dynamic network address translation
US7533409B2 (en) * 2001-03-22 2009-05-12 Corente, Inc. Methods and systems for firewalling virtual private networks
US20020144144A1 (en) * 2001-03-27 2002-10-03 Jeffrey Weiss Method and system for common control of virtual private network devices
JP3945297B2 (en) * 2001-04-24 2007-07-18 株式会社日立製作所 System and management system
US7099912B2 (en) * 2001-04-24 2006-08-29 Hitachi, Ltd. Integrated service management system
KR100385136B1 (en) * 2001-05-07 2003-05-23 엘지전자 주식회사 MAP Message Processing System And Method For Heterogenous Network Interworking
US7272137B2 (en) * 2001-05-14 2007-09-18 Nortel Networks Limited Data stream filtering apparatus and method
US6728220B2 (en) * 2001-05-24 2004-04-27 Riverstone Networks, Inc. Method and system for preventing transmission loops in a label switching domain
KR20020023100A (en) * 2001-05-28 2002-03-28 박현제 System for virtual multicast network depolyment
US8385342B2 (en) 2001-05-31 2013-02-26 Fujitsu Limited System and method of virtual private network route target filtering
US20020184388A1 (en) * 2001-06-01 2002-12-05 Nimer Yaseen Layered approach to virtual private routing
US7450505B2 (en) * 2001-06-01 2008-11-11 Fujitsu Limited System and method for topology constrained routing policy provisioning
US8014283B2 (en) * 2001-06-01 2011-09-06 Fujitsu Limited System and method for topology constrained QoS provisioning
JP4728511B2 (en) * 2001-06-14 2011-07-20 古河電気工業株式会社 Data relay method, apparatus thereof, and data relay system using the apparatus
US8135834B1 (en) * 2001-06-18 2012-03-13 Packet Design, Inc. Method and system for causing intra-AS network traffic to be more evenly balanced
US7441017B2 (en) * 2001-06-29 2008-10-21 Thomas Lee Watson System and method for router virtual networking
US20030026271A1 (en) * 2001-07-03 2003-02-06 Erb Guy C. L2/L3 network with LSP-enabled virtual routing
US7127523B2 (en) * 2001-07-27 2006-10-24 Corrigent Systems Ltd. Spanning tree protocol traffic in a transparent LAN
US7145878B2 (en) 2001-07-27 2006-12-05 Corrigent Systems Ltd. Avoiding overlapping segments in transparent LAN services on ring-based networks
WO2003019870A2 (en) * 2001-08-24 2003-03-06 Peribit Networks, Inc. Dynamic multi-point meshed overlay network
US8880709B2 (en) * 2001-09-12 2014-11-04 Ericsson Television Inc. Method and system for scheduled streaming of best effort data
US7095736B1 (en) * 2001-09-17 2006-08-22 Nortel Networks Limited System, device, and method for localized information processing in a multiprotocol label switching network
US7609689B1 (en) * 2001-09-27 2009-10-27 Cisco Technology, Inc. System and method for mapping an index into an IPv6 address
US7406526B2 (en) * 2001-09-28 2008-07-29 Uri Benchetrit Extended internet protocol network address translation system
FI20011949A0 (en) * 2001-10-05 2001-10-05 Stonesoft Corp Managing a Virtual Private Network
US7013347B1 (en) * 2001-10-16 2006-03-14 Cisco Technology, Inc. Distance vector extension to the address resolution protocol
US7356035B1 (en) * 2001-11-05 2008-04-08 Cisco Technology, Inc. System and method for AAL5 enhanced encapsulation
WO2003043289A2 (en) * 2001-11-13 2003-05-22 Ems Technologies, Inc. Performance enhancing proxy techniques for internet protocol traffic
US7813346B1 (en) * 2001-11-21 2010-10-12 Juniper Networks, Inc. Filter-based forwarding in a network
US20030128688A1 (en) * 2001-12-26 2003-07-10 Lg Electronics Inc. ATM based MPLS-LER system and method for establishing connection
US7533183B1 (en) * 2001-12-28 2009-05-12 Nortel Networks Limited Central control of multiple address domains within a router
KR20040103917A (en) * 2002-01-22 2004-12-09 코네샌트 시스템즈, 인코포레이티드 Low-processor-load aggregation
US7154899B2 (en) * 2002-02-01 2006-12-26 Corrigent Systems Ltd. Protecting the filtering database in virtual bridges
US7298746B1 (en) 2002-02-11 2007-11-20 Extreme Networks Method and system for reassembling and parsing packets in a network environment
US7321926B1 (en) 2002-02-11 2008-01-22 Extreme Networks Method of and system for allocating resources to resource requests
US7447777B1 (en) 2002-02-11 2008-11-04 Extreme Networks Switching system
US7584262B1 (en) 2002-02-11 2009-09-01 Extreme Networks Method of and system for allocating resources to resource requests based on application of persistence policies
US7814204B1 (en) 2002-02-11 2010-10-12 Extreme Networks, Inc. Method of and system for analyzing the content of resource requests
US7027396B1 (en) 2002-02-13 2006-04-11 At&T Corp. Traffic matrix computation for a backbone network supporting virtual private networks
US7395354B2 (en) * 2002-02-21 2008-07-01 Corente, Inc. Methods and systems for resolving addressing conflicts based on tunnel information
US20030210696A1 (en) * 2002-04-25 2003-11-13 Globespanvirata Incorporated System and method for routing across segments of a network switch
AU2003216304A1 (en) * 2002-02-21 2003-09-09 Globespanvirata Incorporated System and method for routing a cross segments of a network switch
SE0200640D0 (en) * 2002-02-28 2002-02-28 Ericsson Telefon Ab L M Arrangement and method for routing in virtual private network
JP3898535B2 (en) * 2002-03-14 2007-03-28 株式会社日立製作所 Data transfer device
US7376743B1 (en) * 2002-04-02 2008-05-20 Cisco Technology, Inc. Method and apparatus for load balancing in a virtual private network
US8611363B2 (en) * 2002-05-06 2013-12-17 Adtran, Inc. Logical port system and method
US7095738B1 (en) * 2002-05-07 2006-08-22 Cisco Technology, Inc. System and method for deriving IPv6 scope identifiers and for mapping the identifiers into IPv6 addresses
EP1361705A1 (en) * 2002-05-07 2003-11-12 Alcatel Method for forwarding data packets as cell sequences within a subnetwork of a data packet network
CN1173529C (en) * 2002-06-05 2004-10-27 华为技术有限公司 Protection method for controlling message safety based on message of border gateway protocol
US7483399B2 (en) * 2002-06-05 2009-01-27 David Zelig Signaling MPLS over RPR rings
US7239634B1 (en) * 2002-06-17 2007-07-03 Signafor, Inc. Encryption mechanism in advanced packet switching system
US7801021B1 (en) 2002-07-01 2010-09-21 Cisco Technology, Inc. Generic routing encapsulation tunnel keepalives
US7260096B2 (en) * 2002-07-09 2007-08-21 International Business Machines Corporation Method and router for forwarding internet data packets
US8737406B1 (en) 2002-08-01 2014-05-27 Cisco Technology, Inc. Method for transmitting IP routes to prioritize convergence
US20040034702A1 (en) * 2002-08-16 2004-02-19 Nortel Networks Limited Method and apparatus for exchanging intra-domain routing information between VPN sites
JP3521904B2 (en) * 2002-08-22 2004-04-26 日本電気株式会社 Frame transfer method and node in Ethernet (R)
US7339929B2 (en) * 2002-08-23 2008-03-04 Corrigent Systems Ltd. Virtual private LAN service using a multicast protocol
US7453888B2 (en) * 2002-08-27 2008-11-18 Alcatel Lucent Stackable virtual local area network provisioning in bridged networks
US7310685B2 (en) * 2002-08-29 2007-12-18 International Business Machines Corporation Method and system for reducing look-up time in packet forwarding on computer networks
US7467408B1 (en) 2002-09-09 2008-12-16 Cisco Technology, Inc. Method and apparatus for capturing and filtering datagrams for network security monitoring
US7209551B1 (en) * 2002-09-19 2007-04-24 Sbc Properties, L.P. Provisioning unified messaging system services
US7447739B1 (en) 2002-09-19 2008-11-04 At&T Intellectual Property I, L.P. Data and voice messaging system
US7539185B2 (en) * 2002-10-07 2009-05-26 Broadcom Corporation Fast-path implementation for an uplink double tagging engine
DE60233145D1 (en) * 2002-10-31 2009-09-10 Alcatel Lucent Method for processing data packets on layer three in a telecommunication device
US7317692B2 (en) * 2002-11-13 2008-01-08 Intel Corporation Network path discovery
US7185106B1 (en) 2002-11-15 2007-02-27 Juniper Networks, Inc. Providing services for multiple virtual private networks
US7596629B2 (en) * 2002-11-21 2009-09-29 Cisco Technology, Inc. System and method for interconnecting heterogeneous layer 2 VPN applications
US7283534B1 (en) * 2002-11-22 2007-10-16 Airespace, Inc. Network with virtual “Virtual Private Network” server
KR100617720B1 (en) * 2002-11-30 2006-08-28 삼성전자주식회사 Dynamic management method for forwarding information in distributed router architecture
US7283465B2 (en) * 2003-01-07 2007-10-16 Corrigent Systems Ltd. Hierarchical virtual private LAN service protection scheme
US7558265B2 (en) * 2003-01-31 2009-07-07 Intel Corporation Methods and apparatus to limit transmission of data to a localized area
US7382769B1 (en) 2003-02-07 2008-06-03 Juniper Networks, Inc. Automatic filtering to prevent network attacks
US20040177157A1 (en) * 2003-02-13 2004-09-09 Nortel Networks Limited Logical grouping of VPN tunnels
US7397795B2 (en) * 2003-02-24 2008-07-08 Intel California Method and system for label-based packet forwarding among multiple forwarding elements
US7340519B1 (en) * 2003-03-05 2008-03-04 At&T Corp. Reducing configuration errors for managed services in computer networks
US7664056B2 (en) 2003-03-10 2010-02-16 Meetrix Corporation Media based collaboration using mixed-mode PSTN and internet networks
US20040193730A1 (en) * 2003-03-25 2004-09-30 Vernon Stephen K. Method and computer programs for providing special processing of a communication sent across a communication network
US7028101B2 (en) * 2003-03-25 2006-04-11 Nokia Corporation Optimal location service for managing next hop addressing for messages associated with multiple address schemes
US6970464B2 (en) 2003-04-01 2005-11-29 Cisco Technology, Inc. Method for recursive BGP route updates in MPLS networks
JP2004320389A (en) * 2003-04-16 2004-11-11 Nec Corp System and device for transferring data, method for the same, and control program
US7747716B2 (en) * 2003-04-28 2010-06-29 Alcatel-Lucent Usa Inc. Injecting addresses to enable OAM functions
US7529257B1 (en) 2003-04-30 2009-05-05 Cisco Technology, Inc. Method for supporting a GMPLS hierarchy through multiple routing instances
FR2855697B1 (en) * 2003-05-26 2005-09-23 At & T Corp IPv4-BASED DATA CONVERSION SYSTEM IN IPv6-BASED DATA TO BE TRANSMITTED THROUGH IP-SWITCHED NETWORK
US8078758B1 (en) 2003-06-05 2011-12-13 Juniper Networks, Inc. Automatic configuration of source address filters within a network device
US7388862B2 (en) * 2003-06-19 2008-06-17 Cisco Technology, Inc. Technique for notifying EIGRP neighbors when destroying adjacencies in a computer network
US8301738B1 (en) 2003-07-31 2012-10-30 Novell, Inc. Systems and methods for private network addressing in IP protocols
US7366181B2 (en) * 2003-09-06 2008-04-29 Fujitsu Limited Virtual private network (VPN) with channelized ethernet over sonet (EoS) interface and method
US7698456B2 (en) * 2003-09-29 2010-04-13 Cisco Technology, Inc. Methods and apparatus to support routing of information
US7680943B2 (en) * 2003-10-20 2010-03-16 Transwitch Corporation Methods and apparatus for implementing multiple types of network tunneling in a uniform manner
US8024437B2 (en) * 2003-10-30 2011-09-20 Paul Unbehagen Autodiscovery for virtual networks
US7620732B2 (en) * 2003-11-18 2009-11-17 Kabushiki Kaisha Toshiba Apparatus for and method of setting communication path
US8146148B2 (en) * 2003-11-19 2012-03-27 Cisco Technology, Inc. Tunneled security groups
GB2408415B (en) * 2003-11-19 2008-04-09 Vodafone Plc Networks
DE60312347T2 (en) 2003-12-16 2007-11-15 Alcatel Lucent Arrangement with a terminal, an access multiplexer and a network
US6929507B2 (en) * 2003-12-30 2005-08-16 Huang Liang Precision Enterprise Co., Ltd. Coaxial connector structure
US7305706B2 (en) * 2004-01-15 2007-12-04 Cisco Technology, Inc. Establishing a virtual private network for a road warrior
US7496688B2 (en) * 2004-01-30 2009-02-24 Ixia Label switched data unit content evaluation
US8265058B2 (en) * 2004-02-05 2012-09-11 Ericsson Ab Method and an apparatus for route selection in routing protocols
US7457248B1 (en) 2004-02-10 2008-11-25 Cisco Technology, Inc. Graceful shutdown of network resources in data networks
US7925778B1 (en) * 2004-02-13 2011-04-12 Cisco Technology, Inc. Method and apparatus for providing multicast messages across a data communication network
US7773596B1 (en) * 2004-02-19 2010-08-10 Juniper Networks, Inc. Distribution of traffic flow criteria
WO2005089147A2 (en) * 2004-03-11 2005-09-29 Transnexus, Inc. Method and system for routing calls over a packet switched computer network
US7551599B2 (en) * 2004-03-29 2009-06-23 Corrigent Systems Ltd. Layer-3 network routing with RPR layer-2 visibility
US8340102B2 (en) 2004-04-05 2012-12-25 Verizon Business Global Llc Apparatus and method for providing a network termination point
US8249082B2 (en) 2004-04-05 2012-08-21 Verizon Business Global Llc System method for a communications access network
US8289973B2 (en) 2004-04-05 2012-10-16 Verizon Business Global Llc System and method for indicating classification of a communications flow
US20050220059A1 (en) * 2004-04-05 2005-10-06 Delregno Dick System and method for providing a multiple-protocol crossconnect
US7869450B2 (en) 2004-04-05 2011-01-11 Verizon Business Global Llc Method and apparatus for processing labeled flows in a communication access network
US7821929B2 (en) * 2004-04-05 2010-10-26 Verizon Business Global Llc System and method for controlling communication flow rates
US8948207B2 (en) * 2004-04-05 2015-02-03 Verizon Patent And Licensing Inc. System and method for transporting time-division multiplexed communications through a packet-switched access network
US7633961B2 (en) * 2004-04-07 2009-12-15 Alcatel Lucent Edge-router scaling for BGP peering with virtual private routed networks (VPRN)
US7568047B1 (en) * 2004-04-30 2009-07-28 Nortel Networks Limited Method and apparatus for adaptive service label management
US7746872B2 (en) 2004-05-21 2010-06-29 Hewlett-Packard Development Company, L.P. Packet routing as a function of direction
US7430210B2 (en) * 2004-05-26 2008-09-30 Fujitsu Limited Application of an Ethernet/MPLS “half bridge” to provide emulated Ethernet LAN functions in SONET networks
US7787396B1 (en) * 2004-05-27 2010-08-31 Cisco Technology, Inc. Automatic ORF-list creation for route partitioning across BGP route reflectors
US7433359B2 (en) * 2004-05-28 2008-10-07 Fujitsu Limited Application of an Ethernet/MPLS half bridge to provide Ethernet multiplexing functions (EMF) in SONET network elements (NEs)
CN100372340C (en) * 2004-06-11 2008-02-27 华为技术有限公司 Method for realizing virtual special network
US7423980B2 (en) * 2004-07-01 2008-09-09 Nortel Networks Limited Full mesh status monitor
US7411975B1 (en) * 2004-08-26 2008-08-12 Juniper Networks, Inc. Multimedia over internet protocol border controller for network-based virtual private networks
US7567573B2 (en) 2004-09-07 2009-07-28 F5 Networks, Inc. Method for automatic traffic interception
CA2549577A1 (en) * 2004-09-09 2006-03-16 Avaya Technology Corp. Methods of and systems for network traffic security
US7623535B2 (en) * 2004-09-09 2009-11-24 Cisco Technology, Inc. Routing protocol support for half duplex virtual routing and forwarding instance
US7752600B2 (en) 2004-09-30 2010-07-06 Citrix Systems, Inc. Method and apparatus for providing file-type associations to multiple applications
US8613048B2 (en) * 2004-09-30 2013-12-17 Citrix Systems, Inc. Method and apparatus for providing authorized remote access to application sessions
US7680758B2 (en) 2004-09-30 2010-03-16 Citrix Systems, Inc. Method and apparatus for isolating execution of software applications
US7853947B2 (en) 2004-09-30 2010-12-14 Citrix Systems, Inc. System for virtualizing access to named system objects using rule action associated with request
US20060069662A1 (en) * 2004-09-30 2006-03-30 Citrix Systems, Inc. Method and apparatus for remapping accesses to virtual system resources
US8095940B2 (en) * 2005-09-19 2012-01-10 Citrix Systems, Inc. Method and system for locating and accessing resources
US8171479B2 (en) 2004-09-30 2012-05-01 Citrix Systems, Inc. Method and apparatus for providing an aggregate view of enumerated system resources from various isolation layers
US7748032B2 (en) * 2004-09-30 2010-06-29 Citrix Systems, Inc. Method and apparatus for associating tickets in a ticket hierarchy
US8117559B2 (en) * 2004-09-30 2012-02-14 Citrix Systems, Inc. Method and apparatus for virtualizing window information
US7711835B2 (en) * 2004-09-30 2010-05-04 Citrix Systems, Inc. Method and apparatus for reducing disclosure of proprietary data in a networked environment
US20060083215A1 (en) * 2004-10-19 2006-04-20 James Uttaro Method and apparatus for providing a scalable route reflector topology for networks
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
US7516174B1 (en) 2004-11-02 2009-04-07 Cisco Systems, Inc. Wireless network security mechanism including reverse network address translation
US7974223B2 (en) * 2004-11-19 2011-07-05 Corrigent Systems Ltd. Virtual private LAN service over ring networks
US7551551B2 (en) * 2004-12-10 2009-06-23 Cisco Technology, Inc. Fast reroute (FRR) protection at the edge of a RFC 2547 network
GB2435587B (en) * 2004-12-13 2008-10-01 Transnexus Inc Method and system for securely authorizing VOIP interconnections between anonymous peers of VOIP networks
US8238329B2 (en) 2005-12-13 2012-08-07 Transnexus, Inc. Method and system for securely authorizing VoIP interconnections between anonymous peers of VoIP networks
US7630318B2 (en) * 2004-12-15 2009-12-08 Agilent Technologies, Inc. Filtering wireless network packets
US7633859B2 (en) * 2005-01-26 2009-12-15 Cisco Technology, Inc. Loop prevention technique for MPLS using two labels
US8024568B2 (en) * 2005-01-28 2011-09-20 Citrix Systems, Inc. Method and system for verification of an endpoint security scan
US7620975B2 (en) * 2005-02-17 2009-11-17 Cisco Technology, Inc. Internal routing protocol support for distributing encryption information
US7664013B2 (en) * 2005-02-28 2010-02-16 Cisco Technology, Inc. Loop prevention technique for MPLS using service labels
US20060253409A1 (en) * 2005-03-04 2006-11-09 Nokia Corporation Method, apparatus and computer program product providing local service discovery with browser search
US7535828B2 (en) 2005-03-18 2009-05-19 Cisco Technology, Inc. Algorithm for backup PE selection
US7477593B2 (en) * 2005-04-04 2009-01-13 Cisco Technology, Inc. Loop prevention techniques using encapsulation manipulation of IP/MPLS field
US7599313B2 (en) * 2005-04-28 2009-10-06 Cisco Technology, Inc. Method to scale hierarchical route reflectors using automated outbound route filtering-list mechanism
US7974202B2 (en) * 2005-05-06 2011-07-05 Corrigent Systems, Ltd. Tunnel provisioning with link aggregation
US7630392B2 (en) * 2005-05-31 2009-12-08 Cisco Technology, Inc. Multi-homing using controlled route leakage at a backup service provider
CN100442766C (en) 2005-07-08 2008-12-10 华为技术有限公司 Method for realizing retransmission business of data communication equipment
US20070030846A1 (en) * 2005-08-08 2007-02-08 Mark Szczesniak Method and apparatus for enabling routing of label switched data packets
US20070030852A1 (en) * 2005-08-08 2007-02-08 Mark Szczesniak Method and apparatus for enabling routing of label switched data packets
US7920572B2 (en) * 2005-09-20 2011-04-05 Cisco Technology, Inc. Modifying operation of peer-to-peer networks based on integrating network routing information
US8131825B2 (en) * 2005-10-07 2012-03-06 Citrix Systems, Inc. Method and a system for responding locally to requests for file metadata associated with files stored remotely
US20070083610A1 (en) * 2005-10-07 2007-04-12 Treder Terry N Method and a system for accessing a plurality of files comprising an application program
US7779034B2 (en) * 2005-10-07 2010-08-17 Citrix Systems, Inc. Method and system for accessing a remote file in a directory structure associated with an application program executing locally
WO2007051490A1 (en) * 2005-10-31 2007-05-10 Hewlett-Packard Development Company, L.P. Distributing routing information in autonomous systems
US20070133604A1 (en) * 2005-12-08 2007-06-14 International Business Machines Corporation Virtual network adapter for automatically maximizing frame sizes and avoiding physical network IP fragmentation
US7924884B2 (en) * 2005-12-20 2011-04-12 Citrix Systems, Inc. Performance logging using relative differentials and skip recording
US7889738B2 (en) 2005-12-21 2011-02-15 Solace Systems Inc. Shared application inter-working with virtual private networks
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
US7983150B2 (en) * 2006-01-18 2011-07-19 Corrigent Systems Ltd. VPLS failure protection in ring networks
US20070174429A1 (en) * 2006-01-24 2007-07-26 Citrix Systems, Inc. Methods and servers for establishing a connection between a client system and a virtual machine hosting a requested computing environment
US7668920B2 (en) * 2006-03-01 2010-02-23 Fortinet, Inc. Electronic message and data tracking system
US7808931B2 (en) * 2006-03-02 2010-10-05 Corrigent Systems Ltd. High capacity ring communication network
US7673061B2 (en) * 2006-03-28 2010-03-02 Tellabs San Jose, Inc. Method and apparatus for neighborhood discovery across disparate point-to-point networks
US9542642B2 (en) 2006-04-06 2017-01-10 Samuel F. Wood Packet data neural network system and method
US7796511B2 (en) * 2006-04-06 2010-09-14 Wood Samuel F Self-routed layer 4 packet network system and method
US7545740B2 (en) * 2006-04-07 2009-06-09 Corrigent Systems Ltd. Two-way link aggregation
US7613188B1 (en) * 2006-04-27 2009-11-03 Alcatel Lucent Ethernet VLL spoke termination at an IP interface
US7567511B1 (en) 2006-05-10 2009-07-28 At&T Intellectual Property Ii, L.P. Method and apparatus for computing the cost of providing VPN service
US7593400B2 (en) * 2006-05-19 2009-09-22 Corrigent Systems Ltd. MAC address learning in a distributed bridge
CN101529814B (en) * 2006-06-12 2012-08-01 北方电讯网络有限公司 Supporting multi-protocol label switching (MPLS) applications over Ethernet switch paths
US7660303B2 (en) 2006-08-22 2010-02-09 Corrigent Systems Ltd. Point-to-multipoint functionality in a bridged network
US7660234B2 (en) * 2006-09-22 2010-02-09 Corrigent Systems Ltd. Fault-tolerant medium access control (MAC) address assignment in network elements
US20080080517A1 (en) * 2006-09-28 2008-04-03 At & T Corp. System and method for forwarding traffic data in an MPLS VPN
US7929524B2 (en) 2006-09-29 2011-04-19 Cisco Technology, Inc. Apparatus and method to hide transit only multi-access networks in OSPF
US20080101385A1 (en) * 2006-10-30 2008-05-01 At&T Knowledge Ventures, L.P. System and method for filtering routing updates
PL3503449T3 (en) 2006-10-31 2021-03-08 Telefonaktiebolaget Lm Ericsson (Publ) Method and apparatus for error control in telecommunications systems
US8533846B2 (en) * 2006-11-08 2013-09-10 Citrix Systems, Inc. Method and system for dynamically associating access rights with a resource
US8576840B2 (en) * 2006-11-13 2013-11-05 World Wide Packets, Inc. Assigning packets to a network service
US7995500B2 (en) * 2006-11-30 2011-08-09 Cisco Technology, Inc. Managing an amount of tunnels in a computer network
US7680993B2 (en) * 2006-12-21 2010-03-16 Tandberg Television, Inc. Local digital asset storage management technique
US7697525B2 (en) * 2006-12-21 2010-04-13 Corrigent Systems Ltd. Forwarding multicast traffic over link aggregation ports
US7653063B2 (en) * 2007-01-05 2010-01-26 Cisco Technology, Inc. Source address binding check
US8526325B2 (en) * 2007-01-31 2013-09-03 Hewlett-Packard Development Company, L.P. Detecting and identifying connectivity in a network
US8233395B2 (en) 2007-02-21 2012-07-31 At&T Intellectual Property I, Lp System for advertising routing updates
US7865589B2 (en) 2007-03-12 2011-01-04 Citrix Systems, Inc. Systems and methods for providing structured policy expressions to represent unstructured data in a network appliance
US8490148B2 (en) 2007-03-12 2013-07-16 Citrix Systems, Inc Systems and methods for managing application security profiles
US7853678B2 (en) 2007-03-12 2010-12-14 Citrix Systems, Inc. Systems and methods for configuring flow control of policy expressions
US8631147B2 (en) 2007-03-12 2014-01-14 Citrix Systems, Inc. Systems and methods for configuring policy bank invocations
US7853679B2 (en) 2007-03-12 2010-12-14 Citrix Systems, Inc. Systems and methods for configuring handling of undefined policy events
US8249992B2 (en) * 2007-03-22 2012-08-21 The Nielsen Company (Us), Llc Digital rights management and audience measurement systems and methods
US20080294647A1 (en) * 2007-05-21 2008-11-27 Arun Ramaswamy Methods and apparatus to monitor content distributed by the internet
US7885294B2 (en) * 2007-08-23 2011-02-08 Cisco Technology, Inc. Signaling compression information using routing protocols
US8908700B2 (en) 2007-09-07 2014-12-09 Citrix Systems, Inc. Systems and methods for bridging a WAN accelerator with a security gateway
US8238338B2 (en) * 2007-09-14 2012-08-07 Cisco Technology, Inc. Interior gateway protocol summarization preserving internet protocol reachability information
US20090106449A1 (en) * 2007-10-19 2009-04-23 Michael Satterlee Method and apparatus for providing dynamic route advertisement
US8171483B2 (en) * 2007-10-20 2012-05-01 Citrix Systems, Inc. Method and system for communicating between isolation environments
US8018873B1 (en) * 2007-11-08 2011-09-13 Juniper Networks, Inc. Enhanced link state protocol for identifying broadcast networks
CN101179444B (en) * 2007-12-11 2010-12-08 华为技术有限公司 Configuration take-effective method, configuration system and configuration gateway
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
EP2227883B1 (en) * 2008-01-09 2012-05-02 Telefonaktiebolaget L M Ericsson (publ) Setting up a virtual private network
US20090187652A1 (en) * 2008-01-21 2009-07-23 International Business Machines Corporation Inferred Discovery Of Devices Of A Data Communications Network
US8037286B2 (en) * 2008-01-23 2011-10-11 Arm Limited Data processing apparatus and method for instruction pre-decoding
US8743740B2 (en) * 2008-04-08 2014-06-03 At&T Intellectual Property I, L.P. Methods and apparatus to implement a partial mesh virtual private local area network service
US8806053B1 (en) 2008-04-29 2014-08-12 F5 Networks, Inc. Methods and systems for optimizing network traffic using preemptive acknowledgment signals
GB0809966D0 (en) * 2008-06-02 2008-07-09 Artificial Lift Co Ltd Drive means
JP5292951B2 (en) * 2008-07-03 2013-09-18 日本電気株式会社 Route control method, route control system, route control device, and route control program
US8064362B2 (en) * 2008-08-21 2011-11-22 Cisco Technology, Inc. Wide area network optimization proxy routing protocol
US8289978B2 (en) * 2008-10-15 2012-10-16 At&T Intellectual Property I, Lp Broadcast interactive television system
US7804781B2 (en) * 2008-11-20 2010-09-28 At&T Intellectual Property I, L.P. Methods and apparatus to detect border gateway protocol session failures
US7885277B2 (en) * 2008-12-09 2011-02-08 At&T Intellectual Property I, L.P. Methods and apparatus to analyze autonomous system peering policies
CN101459606B (en) 2008-12-31 2011-04-20 华为技术有限公司 Extranet networking method, system and device for multicast VPN
US7944924B2 (en) * 2009-04-16 2011-05-17 Alcatel-Lucent Canada Inc. Handling of received implicit null packets
US8432912B2 (en) * 2009-04-22 2013-04-30 Hewlett-Packard Development Company, L.P. Router packet filtering and mapping
US8090797B2 (en) * 2009-05-02 2012-01-03 Citrix Systems, Inc. Methods and systems for launching applications into existing isolation environments
US8687621B2 (en) 2009-06-04 2014-04-01 Cisco Technology, Inc. Dynamically right-sizing prefixes for network and application performance
US8868961B1 (en) 2009-11-06 2014-10-21 F5 Networks, Inc. Methods for acquiring hyper transport timing and devices thereof
US10721269B1 (en) 2009-11-06 2020-07-21 F5 Networks, Inc. Methods and system for returning requests with javascript for clients before passing a request to a server
US8411667B2 (en) * 2009-12-15 2013-04-02 At&T Intellectual Property I, L.P. Methods, apparatus and articles of manufacture to manipulate packet routing
CN102118371B (en) * 2009-12-30 2013-10-09 华为技术有限公司 Method, device and system for controlling network traffic switch
US9141625B1 (en) 2010-06-22 2015-09-22 F5 Networks, Inc. Methods for preserving flow state during virtual machine migration and devices thereof
US10015286B1 (en) 2010-06-23 2018-07-03 F5 Networks, Inc. System and method for proxying HTTP single sign on across network domains
US8347100B1 (en) 2010-07-14 2013-01-01 F5 Networks, Inc. Methods for DNSSEC proxying and deployment amelioration and systems thereof
US9083760B1 (en) 2010-08-09 2015-07-14 F5 Networks, Inc. Dynamic cloning and reservation of detached idle connections
US8886981B1 (en) 2010-09-15 2014-11-11 F5 Networks, Inc. Systems and methods for idle driven scheduling
US9563751B1 (en) 2010-10-13 2017-02-07 The Boeing Company License utilization management system service suite
EP2633667B1 (en) 2010-10-29 2017-09-06 F5 Networks, Inc System and method for on the fly protocol conversion in obtaining policy enforcement information
US9300642B2 (en) * 2010-11-09 2016-03-29 Cisco Technology, Inc. Restarting network reachability protocol sessions based on transport layer authentication
US8838069B2 (en) 2010-12-08 2014-09-16 At&T Intellectual Property I, L.P. Devices, systems, and methods for sharing network services
US10135831B2 (en) 2011-01-28 2018-11-20 F5 Networks, Inc. System and method for combining an access control system with a traffic management system
US9246819B1 (en) 2011-06-20 2016-01-26 F5 Networks, Inc. System and method for performing message-based load balancing
WO2013059683A1 (en) * 2011-10-19 2013-04-25 The Regents Of The University Of California Comprehensive multipath routing for congestion and quality-of-service in communication networks
US8719450B2 (en) 2011-10-31 2014-05-06 Cable Television Laboratories, Inc. Internet protocol (IP) address translation
US8861345B2 (en) * 2011-11-03 2014-10-14 Futurewei Technologies, Inc. Border gateway protocol extension for the host joining/leaving a virtual private network
US20130142201A1 (en) * 2011-12-02 2013-06-06 Microsoft Corporation Connecting on-premise networks with public clouds
US9270766B2 (en) 2011-12-30 2016-02-23 F5 Networks, Inc. Methods for identifying network traffic characteristics to correlate and manage one or more subsequent flows and devices thereof
US10230566B1 (en) 2012-02-17 2019-03-12 F5 Networks, Inc. Methods for dynamically constructing a service principal name and devices thereof
US9231879B1 (en) 2012-02-20 2016-01-05 F5 Networks, Inc. Methods for policy-based network traffic queue management and devices thereof
US9172753B1 (en) 2012-02-20 2015-10-27 F5 Networks, Inc. Methods for optimizing HTTP header based authentication and devices thereof
US10140049B2 (en) 2012-02-24 2018-11-27 Missing Link Electronics, Inc. Partitioning systems operating in multiple domains
EP2853074B1 (en) 2012-04-27 2021-03-24 F5 Networks, Inc Methods for optimizing service of content requests and devices thereof
CN102638413B (en) * 2012-05-14 2015-06-10 杭州华三通信技术有限公司 Route issuing method and provider edge device
US20130305344A1 (en) * 2012-05-14 2013-11-14 Alcatel-Lucent India Limited Enterprise network services over distributed clouds
US9300570B2 (en) * 2012-05-22 2016-03-29 Harris Corporation Multi-tunnel virtual private network
US10031782B2 (en) 2012-06-26 2018-07-24 Juniper Networks, Inc. Distributed processing of network device tasks
CN103812772B (en) * 2012-11-13 2017-10-27 新华三技术有限公司 Method and apparatus for realizing the quick heavy-routes of MPLS TE
US10375155B1 (en) 2013-02-19 2019-08-06 F5 Networks, Inc. System and method for achieving hardware acceleration for asymmetric flow connections
US9780993B2 (en) * 2013-06-26 2017-10-03 Amazon Technologies, Inc. Producer computing system leasing on behalf of consumer computing system
US9843631B2 (en) 2013-06-26 2017-12-12 Amazon Technologies, Inc. Producer system selection
US9369518B2 (en) 2013-06-26 2016-06-14 Amazon Technologies, Inc. Producer system partitioning among leasing agent systems
US9350801B2 (en) 2013-06-26 2016-05-24 Amazon Technologies, Inc. Managing client access to a plurality of computing systems
CN103634217B (en) * 2013-11-13 2017-02-08 华为技术有限公司 Method for issuing route information, method and device for transmitting massage
US10187317B1 (en) 2013-11-15 2019-01-22 F5 Networks, Inc. Methods for traffic rate control and devices thereof
US10193801B2 (en) 2013-11-25 2019-01-29 Juniper Networks, Inc. Automatic traffic mapping for multi-protocol label switching networks
US10015143B1 (en) 2014-06-05 2018-07-03 F5 Networks, Inc. Methods for securing one or more license entitlement grants and devices thereof
US11838851B1 (en) 2014-07-15 2023-12-05 F5, Inc. Methods for managing L7 traffic classification and devices thereof
US10122630B1 (en) 2014-08-15 2018-11-06 F5 Networks, Inc. Methods for network traffic presteering and devices thereof
US10182013B1 (en) 2014-12-01 2019-01-15 F5 Networks, Inc. Methods for managing progressive image delivery and devices thereof
US11895138B1 (en) 2015-02-02 2024-02-06 F5, Inc. Methods for improving web scanner accuracy and devices thereof
US10834065B1 (en) 2015-03-31 2020-11-10 F5 Networks, Inc. Methods for SSL protected NTLM re-authentication and devices thereof
US9906442B2 (en) * 2015-04-17 2018-02-27 Dell Products Lp Systems and methods for increasing the multiprotocol label switching stack
US11350254B1 (en) 2015-05-05 2022-05-31 F5, Inc. Methods for enforcing compliance policies and devices thereof
US10505818B1 (en) 2015-05-05 2019-12-10 F5 Networks. Inc. Methods for analyzing and load balancing based on server health and devices thereof
US10455387B2 (en) * 2015-05-13 2019-10-22 CyberReef Solutions Inc. Network-based Machine-to-Machine (M2M) private networking system
US9923818B2 (en) * 2015-09-14 2018-03-20 Citrix Systems, Inc. Systems and methods of achieving equal distribution of packets in a multicore system which acts as a tunnel end point
US10075304B2 (en) 2015-10-30 2018-09-11 Microsoft Technology Licensing, Llc Multiple gateway operation on single operating system
US11757946B1 (en) 2015-12-22 2023-09-12 F5, Inc. Methods for analyzing network traffic and enforcing network policies and devices thereof
US10404698B1 (en) 2016-01-15 2019-09-03 F5 Networks, Inc. Methods for adaptive organization of web application access points in webtops and devices thereof
US10797888B1 (en) 2016-01-20 2020-10-06 F5 Networks, Inc. Methods for secured SCEP enrollment for client devices and devices thereof
US11178150B1 (en) 2016-01-20 2021-11-16 F5 Networks, Inc. Methods for enforcing access control list based on managed application and devices thereof
US10791088B1 (en) 2016-06-17 2020-09-29 F5 Networks, Inc. Methods for disaggregating subscribers via DHCP address translation and devices thereof
US11063758B1 (en) 2016-11-01 2021-07-13 F5 Networks, Inc. Methods for facilitating cipher selection and devices thereof
US10505792B1 (en) 2016-11-02 2019-12-10 F5 Networks, Inc. Methods for facilitating network traffic analytics and devices thereof
US10225182B2 (en) * 2017-02-28 2019-03-05 Juniper Networks, Inc. Apparatus, system, and method for facilitating label-identified routing decisions by iBGP peers
US10812266B1 (en) 2017-03-17 2020-10-20 F5 Networks, Inc. Methods for managing security tokens based on security violations and devices thereof
US10425330B2 (en) * 2017-04-24 2019-09-24 International Business Machines Corporation Routing packets in multiple destination networks with overlapping address spaces
US10972453B1 (en) 2017-05-03 2021-04-06 F5 Networks, Inc. Methods for token refreshment based on single sign-on (SSO) for federated identity environments and devices thereof
US11115323B2 (en) * 2017-05-10 2021-09-07 Saudi Arabian Oil Company Securing Layer-3 virtual private network
US11122042B1 (en) 2017-05-12 2021-09-14 F5 Networks, Inc. Methods for dynamically managing user access control and devices thereof
US11343237B1 (en) 2017-05-12 2022-05-24 F5, Inc. Methods for managing a federated identity environment using security and access control data and devices thereof
US10810033B2 (en) * 2017-08-11 2020-10-20 International Business Machines Corporation Propagating external route changes into a cloud network
US11122083B1 (en) 2017-09-08 2021-09-14 F5 Networks, Inc. Methods for managing network connections based on DNS data and network policies and devices thereof
US10735371B2 (en) 2017-09-21 2020-08-04 Mastercard International Incorporated Systems and methods for accessing computer networks using a virtual infrastructure
WO2019142202A1 (en) * 2018-01-20 2019-07-25 Telefonaktiebolaget Lm Ericsson (Publ) Robust message processing for a software-defined networking (sdn) controller cluster
US11044200B1 (en) 2018-07-06 2021-06-22 F5 Networks, Inc. Methods for service stitching using a packet header and devices thereof
US11683308B2 (en) * 2019-06-06 2023-06-20 Cisco Technology, Inc. Systems and methods for generating contextual labels
US11489930B2 (en) * 2019-06-11 2022-11-01 At&T Intellectual Property I, L.P. Telecommunication network edge cloud interworking via edge exchange point

Citations (19)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5243342A (en) 1990-09-28 1993-09-07 Stratacom, Inc. Integrated PCM level control and conversion using a lookup table
US5309430A (en) * 1991-07-22 1994-05-03 Alcatel N.V. Telecommunication system
US5353283A (en) 1993-05-28 1994-10-04 Bell Communications Research, Inc. General internet method for routing packets in a communications network
US5394402A (en) 1993-06-17 1995-02-28 Ascom Timeplex Trading Ag Hub for segmented virtual local area network with shared media access
US5426637A (en) 1992-12-14 1995-06-20 International Business Machines Corporation Methods and apparatus for interconnecting local area networks with wide area backbone networks
US5452294A (en) 1994-07-05 1995-09-19 Motorola, Inc. Method and apparatus for adaptive route selection in communication networks
US5491692A (en) 1991-06-14 1996-02-13 Digital Equipment International Limited Hybrid units for a communication network
US5500860A (en) 1991-06-14 1996-03-19 Digital Equipment Corporation Router using multiple hop redirect messages to enable bridge like data forwarding
US5519704A (en) 1994-04-21 1996-05-21 Cisco Systems, Inc. Reliable transport protocol for internetwork routing
US5555256A (en) 1994-04-28 1996-09-10 Hewlett-Packard Company Channel identifier generation
US5561669A (en) 1994-10-26 1996-10-01 Cisco Systems, Inc. Computer network switching system with expandable number of ports
US5623492A (en) 1995-03-24 1997-04-22 U S West Technologies, Inc. Methods and systems for managing bandwidth resources in a fast packet switching network
US5650993A (en) 1995-03-20 1997-07-22 Bell Communications Research, Inc. Drop from front of buffer policy in feedback networks
US5651002A (en) 1995-07-12 1997-07-22 3Com Corporation Internetworking device with enhanced packet header translation and memory
US5917820A (en) * 1996-06-10 1999-06-29 Cisco Technology, Inc. Efficient packet forwarding arrangement for routing packets in an internetwork
US5949786A (en) * 1996-08-15 1999-09-07 3Com Corporation Stochastic circuit identification in a multi-protocol network switch
US5996021A (en) * 1997-05-20 1999-11-30 At&T Corp Internet protocol relay network for directly routing datagram from ingress router to egress router
US6055575A (en) * 1997-01-28 2000-04-25 Ascend Communications, Inc. Virtual private network system and method
US6081524A (en) * 1997-07-03 2000-06-27 At&T Corp. Frame relay switched data service

Family Cites Families (15)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE69123149T2 (en) * 1991-09-03 1997-03-13 Hewlett Packard Co Message routing apparatus
DE69226088T2 (en) * 1991-11-08 1999-02-11 Teledesic Llc A Delaware Limit MEDIATION METHOD AND DEVICE FOR A SATELLITE COMMUNICATION SYSTEM
US5425021A (en) * 1993-01-28 1995-06-13 International Business Machines Corporation Packet switching resource management within nodes
US5621727A (en) * 1994-09-16 1997-04-15 Octel Communications Corporation System and method for private addressing plans using community addressing
US5684800A (en) * 1995-11-15 1997-11-04 Cabletron Systems, Inc. Method for establishing restricted broadcast groups in a switched network
US6229809B1 (en) * 1996-10-11 2001-05-08 Novell, Inc. Method and system for combining computer network protocols
US6157647A (en) * 1996-11-06 2000-12-05 3Com Corporation Direct addressing between VLAN subnets
US6275492B1 (en) * 1996-12-03 2001-08-14 Nortel Networks Limited Method and apparatus for routing data using router identification information
US6301257B1 (en) * 1997-03-19 2001-10-09 Nortel Networks Limited Method and apparatus for transmitting data frames between switches in a meshed data network
US5938736A (en) * 1997-06-30 1999-08-17 Sun Microsystems, Inc. Search engine architecture for a high performance multi-layer switch element
US6169740B1 (en) * 1997-10-30 2001-01-02 Nortel Networks Limited Method of and apparatus for virtual link management
US6339595B1 (en) 1997-12-23 2002-01-15 Cisco Technology, Inc. Peer-model support for virtual private networks with potentially overlapping addresses
US6038322A (en) 1998-10-20 2000-03-14 Cisco Technology, Inc. Group key distribution
US6490290B1 (en) 1998-12-30 2002-12-03 Cisco Technology, Inc. Default internet traffic and transparent passthrough
US6337861B1 (en) 1999-02-02 2002-01-08 Cisco Technology, Inc. Method and apparatus to properly route ICMP messages in a tag-switching network

Patent Citations (19)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5243342A (en) 1990-09-28 1993-09-07 Stratacom, Inc. Integrated PCM level control and conversion using a lookup table
US5500860A (en) 1991-06-14 1996-03-19 Digital Equipment Corporation Router using multiple hop redirect messages to enable bridge like data forwarding
US5491692A (en) 1991-06-14 1996-02-13 Digital Equipment International Limited Hybrid units for a communication network
US5309430A (en) * 1991-07-22 1994-05-03 Alcatel N.V. Telecommunication system
US5426637A (en) 1992-12-14 1995-06-20 International Business Machines Corporation Methods and apparatus for interconnecting local area networks with wide area backbone networks
US5353283A (en) 1993-05-28 1994-10-04 Bell Communications Research, Inc. General internet method for routing packets in a communications network
US5394402A (en) 1993-06-17 1995-02-28 Ascom Timeplex Trading Ag Hub for segmented virtual local area network with shared media access
US5519704A (en) 1994-04-21 1996-05-21 Cisco Systems, Inc. Reliable transport protocol for internetwork routing
US5555256A (en) 1994-04-28 1996-09-10 Hewlett-Packard Company Channel identifier generation
US5452294A (en) 1994-07-05 1995-09-19 Motorola, Inc. Method and apparatus for adaptive route selection in communication networks
US5561669A (en) 1994-10-26 1996-10-01 Cisco Systems, Inc. Computer network switching system with expandable number of ports
US5650993A (en) 1995-03-20 1997-07-22 Bell Communications Research, Inc. Drop from front of buffer policy in feedback networks
US5623492A (en) 1995-03-24 1997-04-22 U S West Technologies, Inc. Methods and systems for managing bandwidth resources in a fast packet switching network
US5651002A (en) 1995-07-12 1997-07-22 3Com Corporation Internetworking device with enhanced packet header translation and memory
US5917820A (en) * 1996-06-10 1999-06-29 Cisco Technology, Inc. Efficient packet forwarding arrangement for routing packets in an internetwork
US5949786A (en) * 1996-08-15 1999-09-07 3Com Corporation Stochastic circuit identification in a multi-protocol network switch
US6055575A (en) * 1997-01-28 2000-04-25 Ascend Communications, Inc. Virtual private network system and method
US5996021A (en) * 1997-05-20 1999-11-30 At&T Corp Internet protocol relay network for directly routing datagram from ingress router to egress router
US6081524A (en) * 1997-07-03 2000-06-27 At&T Corp. Frame relay switched data service

Non-Patent Citations (26)

* Cited by examiner, † Cited by third party
Title
"Digital Subscriber Signaling System No. 1 (DSS 1)-Signalling Specification for Frame Mode Basic Call Control," ITU-T Recommendation Q.933, International Telecommunication Union, Geneva, 1994.
"ISDN Data Link Layer Specification for Frame Mode Bearer Services," CCITT Recommendation Q.922, International Telecommunication Union, Geneva, 1992.
"Digital Subscriber Signaling System No. 1 (DSS 1)—Signalling Specification for Frame Mode Basic Call Control," ITU-T Recommendation Q.933, International Telecommunication Union, Geneva, 1994.
A. Viswanathan et al., "ARIS: Aggregate Route-Bases IP Switching," Internet Draft, (Mar. 1997).
Amendment 1, International Standard ISO/IEC, (Oct. 1, 1995).
Callon et al., "A Framework for Multiprotocol Label Switching, " IETF Network Working Group Internet Draft draft-ietf-mpls-framework-02.txt, Nov. 21, 1997.
D. Ginsberg, ATM Solutions for Enterprise Internetworking, Addison-Wesley Longman 1996, pp. xv-xiv, 36-41, 72-76.
G. P. Chandranmenon and G. Varghese, "Trading Packet Headers for Packet Processing," Proc.
Information Technology-Telecommunications And Information Exchange Between Systems-Protocol For Exchange Of Inter-Domain Routeing Information Among Intermediate Systems To Support Forwarding Of ISO 8473 PDU's, International Standard ISO/IEC, Oct. 1, 1994.
Information Technology—Telecommunications And Information Exchange Between Systems—Protocol For Exchange Of Inter-Domain Routeing Information Among Intermediate Systems To Support Forwarding Of ISO 8473 PDU's, International Standard ISO/IEC, Oct. 1, 1994.
J. Heinanen, "Multiprotocol Encapsulation over ATM Adaptation Layer 5," Internet Community's Request for Comments No. 1483, (Jul. 1993).
K. Nagami et al., "Toshiba's Flow Attribute Notification Protocol (FANP) Specification," Internet Community's Request for Comments No. 2129, (Apr. 1997).
Kalyaranaman et al., "Performance and Buffering Requirements of Internet Protocol over ATM ABR and UBR Services," IEEE Communications Magazine, vol. 36, No. 6, Jun. 1998.
M. Laubach, "Classical IP and ARP over ATM," Internet Community's Request for Comments No. 1577, (Jan. 1994).
M. Laubach, "IP over ATM Working Group's Recommendations for the ATM Forum's Multiprotocol BOF Version 1," Internet Community's Request for Comments No. 1754, (Jan. 1995).
M. McGovern, et al., "CATNIP: Common Architecture For The Internet," Internet Community's Request for Comments No. 1707, (Oct. 1994).
M. Perez et al., "ATM Signaling Support for IP over ATM," Internet Community's Request for Comments No. 1755, (Feb. 1995).
Martin de Prycker, Asynchronous Transfer Mode Solution for Broadband ISDN, Prentice Hall, 1995, pp. 5-11, 87-90.
N. Feldman, "ARIS Specification," Internet Draft (Mar. 1997).
P. Newman et al., "Ipsilon Flow Management Protocol Specification for Ipv4 Version 1.0, " Internet Community's Request for Comments No. 1953, (May 1996).
P. Newman et al., "Ipsilon's General Switch Management Protocol Specification Version 1.1," Internet Community's Request for Comments No. 1987, (Aug. 1996).
R. Ullmann, "Rap: Internet Route Access Protocol," Internet Community's Request for Comments No. 1476, (Jun. 1993).
Rosen et al., "A proposed Architecture for MPLS," IETF Network Working Group Internet Draft draft-ietf-mpls-arch-00.txt, Aug. 1997.
S. Deering, et al., "Internet Protocol, Version 6," Internet Community's Request for Comments No. 1883, (Dec. 1995).
Woundy et al., "ARIS: Aggregate Route-Based IP Switching,", Internet Draft draft-woundy-aris-ipswitching-00.txt, Nov. 1996.
Y. Katsube et al., "Toshiba's Router Architecture Extensions for ATM: Overview," Internet Community's Request for Comments No. 2098, (Feb. 1997).

Cited By (254)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7668166B1 (en) 1997-12-23 2010-02-23 Cisco Technology, Inc. Peer-model support for virtual private networks having potentially overlapping addresses
US7369556B1 (en) 1997-12-23 2008-05-06 Cisco Technology, Inc. Router for virtual private network employing tag switching
US7154889B1 (en) 1997-12-23 2006-12-26 Cisco Technology, Inc. Peer-model support for virtual private networks having potentially overlapping addresses
US7286529B1 (en) 1999-02-26 2007-10-23 Cisco Technology, Inc. Discovery and tag space identifiers in a tag distribution protocol (TDP)
US9667594B2 (en) 1999-06-15 2017-05-30 Ssh Communications Security Oyj Maintaining network address translations
US8973126B2 (en) 1999-06-15 2015-03-03 Ssh Communications Security Oyj Determining occurrence of a network address translation
US20130346555A1 (en) * 1999-06-15 2013-12-26 Tectia Oyj Method and arrangement for providing security through network address translations using tunneling and compensations
US20130346556A1 (en) * 1999-06-15 2013-12-26 Tectia Oyj Method and arrangement for providing security through network address translations using tunneling and compensations
US9071578B2 (en) * 1999-06-15 2015-06-30 Ssh Communications Security Oyj Maintaining network address translations
US8973127B2 (en) 1999-06-15 2015-03-03 Ssh Communications Security Oyj Communications across a network address translator
US8914872B2 (en) 1999-06-15 2014-12-16 Ssh Communications Security Oyj Revealing occurrence of network address translations
US8914873B2 (en) * 1999-06-15 2014-12-16 Ssh Communications Security Oyj Revealing address information in systems where network address translations occur
US8918858B2 (en) 1999-06-15 2014-12-23 Ssh Communications Security Oyj Communications across a network address translator
US6693878B1 (en) * 1999-10-15 2004-02-17 Cisco Technology, Inc. Technique and apparatus for using node ID as virtual private network (VPN) identifiers
US7974201B1 (en) * 1999-10-15 2011-07-05 Cisco Technology, Inc. Technique and apparatus for using node ID as virtual private network (VPN) identifiers
US6977929B1 (en) 1999-12-10 2005-12-20 Sun Microsystems, Inc. Method and system for facilitating relocation of devices on a network
US7765581B1 (en) 1999-12-10 2010-07-27 Oracle America, Inc. System and method for enabling scalable security in a virtual private network
US7336790B1 (en) 1999-12-10 2008-02-26 Sun Microsystems Inc. Decoupling access control from key management in a network
US7685309B2 (en) 1999-12-10 2010-03-23 Sun Microsystems, Inc. System and method for separating addresses from the delivery scheme in a virtual private network
US20060077977A1 (en) * 1999-12-10 2006-04-13 Sun Microsystems, Inc. System and method for separating addresses from the delivery scheme in a virtual private network
US6970941B1 (en) 1999-12-10 2005-11-29 Sun Microsystems, Inc. System and method for separating addresses from the delivery scheme in a virtual private network
US20030205354A1 (en) * 2000-03-16 2003-11-06 Dong Xu Sliding gate for liquid metal flow control
US8423669B2 (en) * 2000-06-16 2013-04-16 Fujitsu Limited Communication device having VPN accommodation function
US8489767B2 (en) * 2000-06-16 2013-07-16 Fujitsu Limited Communication device having VPN accommodation function
US20100223401A1 (en) * 2000-06-16 2010-09-02 Fujitsu Limited Communication Device Having VPN Accommodation Function
US9413657B2 (en) 2000-06-16 2016-08-09 Fujitsu Limited Communication device having VPN accommodation function
US20030088697A1 (en) * 2000-06-16 2003-05-08 Naoki Matsuhira Communication device having VPN accommodation function
US20030132539A1 (en) * 2000-06-22 2003-07-17 Olaf Althoff Device for producing dental workpieces
US7885207B2 (en) 2000-09-13 2011-02-08 Fortinet, Inc. Managing and provisioning virtual routers
US20090046728A1 (en) * 2000-09-13 2009-02-19 Fortinet, Inc. System and method for delivering security services
US8250357B2 (en) 2000-09-13 2012-08-21 Fortinet, Inc. Tunnel interface for securing traffic over a network
US20100094980A1 (en) * 2000-09-13 2010-04-15 Fortinet, Inc. Managing and provisioning virtual routers
US8069233B2 (en) 2000-09-13 2011-11-29 Fortinet, Inc. Switch management system and method
US9258280B1 (en) 2000-09-13 2016-02-09 Fortinet, Inc. Tunnel interface for securing traffic over a network
US8260918B2 (en) * 2000-09-13 2012-09-04 Fortinet, Inc. Packet routing system and method
US20080259934A1 (en) * 2000-09-13 2008-10-23 Fortinet, Inc. Distributed virtual system to support managed, network-based services
US9160716B2 (en) 2000-09-13 2015-10-13 Fortinet, Inc. Tunnel interface for securing traffic over a network
US9124555B2 (en) 2000-09-13 2015-09-01 Fortinet, Inc. Tunnel interface for securing traffic over a network
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
US8320279B2 (en) 2000-09-13 2012-11-27 Fortinet, Inc. Managing and provisioning virtual routers
US9667604B2 (en) 2000-09-13 2017-05-30 Fortinet, Inc. Tunnel interface for securing traffic over a network
US7912936B2 (en) 2000-09-13 2011-03-22 Nara Rajagopalan Managing interworking communications protocols
US9391964B2 (en) 2000-09-13 2016-07-12 Fortinet, Inc. Tunnel interface for securing traffic over a network
US9853948B2 (en) 2000-09-13 2017-12-26 Fortinet, Inc. Tunnel interface for securing traffic over a network
US7539744B2 (en) 2000-09-13 2009-05-26 Fortinet, Inc. Network operating system for maintaining redundant master control blade management information
US7574495B1 (en) 2000-09-13 2009-08-11 Fortinet, Inc. System and method for managing interworking communications protocols
US7174372B1 (en) 2000-09-13 2007-02-06 Fortinet, Inc. System and method for managing router metadata
US20110032942A1 (en) * 2000-09-13 2011-02-10 Fortinet, Inc. Fast path complex flow processing
US20070121579A1 (en) * 2000-09-13 2007-05-31 Fortinet, Inc. Packet routing system and method
US7272643B1 (en) * 2000-09-13 2007-09-18 Fortinet, Inc. System and method for managing and provisioning virtual routers
US8583800B2 (en) 2000-09-13 2013-11-12 Fortinet, Inc. Packet routing system and method
US20090300159A1 (en) * 2000-09-13 2009-12-03 Fortinet, Inc. Managing interworking communications protocols
US7818452B2 (en) 2000-09-13 2010-10-19 Fortinet, Inc. Distributed virtual system to support managed, network-based services
US7639632B2 (en) 2000-09-13 2009-12-29 Fortinet, Inc. System and method for managing and provisioning virtual routers
US20070104119A1 (en) * 2000-09-13 2007-05-10 Fortinet, Inc. System and method for managing and provisioning virtual routers
US20020152373A1 (en) * 2000-09-13 2002-10-17 Chih-Tang Sun Tunnel interface for securing traffic over a network
US6973072B1 (en) 2001-02-22 2005-12-06 Cisco Technology, Inc. High performance protocol for an interconnect system of an intermediate network node
US20140160981A1 (en) * 2001-03-19 2014-06-12 Juniper Networks, Inc. Transport networks supporting virtual private networks, and configuring such networks
US9042271B2 (en) * 2001-03-19 2015-05-26 Juniper Networks, Inc. Transport networks supporting virtual private networks, and configuring such networks
US20040208122A1 (en) * 2001-03-20 2004-10-21 Mcdysan David E. Virtual private network (VPN)-aware customer premises equipment (CPE) edge router
US7447151B2 (en) 2001-03-20 2008-11-04 Verizon Business Global Llc Virtual private network (VPN)-aware customer premises equipment (CPE) edge router
US7809860B2 (en) * 2001-03-20 2010-10-05 Verizon Business Global Llc System, method and apparatus that isolate virtual private network (VPN) and best effort traffic to resist denial of service attacks
US20050066053A1 (en) * 2001-03-20 2005-03-24 Worldcom, Inc. System, method and apparatus that isolate virtual private network (VPN) and best effort traffic to resist denial of service attacks
US20130283379A1 (en) * 2001-03-20 2013-10-24 Verizon Corporate Services Group Inc. System, method and apparatus that employ virtual private networks to resist ip qos denial of service attacks
US9009812B2 (en) * 2001-03-20 2015-04-14 Verizon Patent And Licensing Inc. System, method and apparatus that employ virtual private networks to resist IP QoS denial of service attacks
US8543734B2 (en) 2001-03-20 2013-09-24 Verizon Business Global Llc System, method and apparatus that isolate virtual private network (VPN) and best effort traffic to resist denial of service attacks
US20020154635A1 (en) * 2001-04-23 2002-10-24 Sun Microsystems, Inc. System and method for extending private networks onto public infrastructure using supernets
US7890663B2 (en) 2001-06-28 2011-02-15 Fortinet, Inc. Identifying nodes in a ring network
US9998337B2 (en) 2001-06-28 2018-06-12 Fortinet, Inc. Identifying nodes in a ring network
US7580373B2 (en) 2001-06-28 2009-08-25 Fortinet, Inc. Identifying nodes in a ring network
US20030002468A1 (en) * 2001-06-28 2003-01-02 Mohamed Khalil Virtual private network identification extension
US9602303B2 (en) 2001-06-28 2017-03-21 Fortinet, Inc. Identifying nodes in a ring network
US7110375B2 (en) * 2001-06-28 2006-09-19 Nortel Networks Limited Virtual private network identification extension
US10373272B2 (en) 2001-09-30 2019-08-06 Intel Corporation Social network systems and methods of operation
US7904511B2 (en) * 2001-09-30 2011-03-08 Realcontacts Limited Personal contact network
US11069004B2 (en) 2001-09-30 2021-07-20 Intel Corporation Mobile computing device for facilitating electronic communication among users in a network including professional acquaintances
US10949933B2 (en) 2001-09-30 2021-03-16 Intel Corporation Server for facilitating electronic communication among users in a network including professional acquaintances
US8521817B2 (en) 2001-09-30 2013-08-27 Intel Corporation Social network system and method of operation
US20040215793A1 (en) * 2001-09-30 2004-10-28 Ryan Grant James Personal contact network
US9519937B2 (en) 2001-09-30 2016-12-13 Intel Corporation System and method for social network access
US9305318B2 (en) * 2001-09-30 2016-04-05 Intel Corporation Social network system and method of operation
US9391873B1 (en) 2001-10-19 2016-07-12 Juniper Networks, Inc. Network routing using indirect next hop data
US20100296517A1 (en) * 2001-10-19 2010-11-25 Juniper Networks, Inc. Network routing using indirect next hop data
US8953626B2 (en) 2001-10-19 2015-02-10 Juniper Networks, Inc. Network routing using indirect next hop data
US8532127B2 (en) 2001-10-19 2013-09-10 Juniper Networks, Inc. Network routing using indirect next hop data
US7484003B2 (en) * 2001-11-17 2009-01-27 Redback Networks Inc. Method and apparatus for multiple contexts and layer 3 virtual private networks
US20030112799A1 (en) * 2001-11-17 2003-06-19 Ravi Chandra Method and apparatus for multiple contexts and layer 3 virtual private networks
US20030115480A1 (en) * 2001-12-17 2003-06-19 Worldcom, Inc. System, method and apparatus that employ virtual private networks to resist IP QoS denial of service attacks
US20030118036A1 (en) * 2001-12-21 2003-06-26 Mark Gibson Routing traffic in a communications network
US7139278B2 (en) * 2001-12-21 2006-11-21 Nortel Networks Limited Routing traffic in a communications network
US20030161312A1 (en) * 2002-02-27 2003-08-28 International Business Machines Corporation Apparatus and method of maintaining two-byte IP identification fields in IP headers
US7283527B2 (en) * 2002-02-27 2007-10-16 International Business Machines Corporation Apparatus and method of maintaining two-byte IP identification fields in IP headers
US20030223418A1 (en) * 2002-06-04 2003-12-04 Sachin Desai Network packet steering
US7376125B1 (en) 2002-06-04 2008-05-20 Fortinet, Inc. Service processing switch
US8306040B2 (en) 2002-06-04 2012-11-06 Fortinet, Inc. Network packet steering via configurable association of processing resources and network interfaces
US7522604B2 (en) 2002-06-04 2009-04-21 Fortinet, Inc. Routing traffic through a virtual router-based network switch
US8638802B2 (en) 2002-06-04 2014-01-28 Cisco Technology, Inc. Network packet steering via configurable association of packet processing resources and network interfaces
US9967200B2 (en) 2002-06-04 2018-05-08 Fortinet, Inc. Service processing switch
US7203192B2 (en) 2002-06-04 2007-04-10 Fortinet, Inc. Network packet steering
US8064462B2 (en) 2002-06-04 2011-11-22 Fortinet, Inc. Service processing switch
US20070127382A1 (en) * 2002-06-04 2007-06-07 Fortinet, Inc. Routing traffic through a virtual router-based network switch
US20090238181A1 (en) * 2002-06-04 2009-09-24 Fortinet, Inc. Network packet steering via configurable association of processing resources and network interfaces
US7340535B1 (en) 2002-06-04 2008-03-04 Fortinet, Inc. System and method for controlling routing in a virtual router system
US7161904B2 (en) 2002-06-04 2007-01-09 Fortinet, Inc. System and method for hierarchical metering in a virtual router based network switch
US7720053B2 (en) 2002-06-04 2010-05-18 Fortinet, Inc. Service processing switch
US8111690B2 (en) 2002-06-04 2012-02-07 Google Inc. Routing traffic through a virtual router-based network switch
US20030223361A1 (en) * 2002-06-04 2003-12-04 Zahid Hussain System and method for hierarchical metering in a virtual router based network switch
US8848718B2 (en) 2002-06-04 2014-09-30 Google Inc. Hierarchical metering in a virtual router-based network switch
US7177311B1 (en) 2002-06-04 2007-02-13 Fortinet, Inc. System and method for routing traffic through a virtual router-based network switch
US7668087B2 (en) 2002-06-04 2010-02-23 Fortinet, Inc. Hierarchical metering in a virtual router-based network switch
US20080259936A1 (en) * 2002-06-04 2008-10-23 Fortinet, Inc. Service processing switch
US9215178B2 (en) 2002-06-04 2015-12-15 Cisco Technology, Inc. Network packet steering via configurable association of packet processing resources and network interfaces
US8068503B2 (en) 2002-06-04 2011-11-29 Fortinet, Inc. Network packet steering via configurable association of processing resources and netmods or line interface ports
US7184437B1 (en) * 2002-07-17 2007-02-27 Juniper Networks, Inc. Scalable route resolution
US8014293B1 (en) * 2002-07-17 2011-09-06 Juniper Networks, Inc. Scalable route resolution
US7746790B1 (en) * 2002-07-17 2010-06-29 Juniper Networks, Inc. Scalable route resolution
US7761743B2 (en) 2002-08-29 2010-07-20 Fortinet, Inc. Fault tolerant routing in a non-hot-standby configuration of a network routing system
US7278055B2 (en) 2002-08-29 2007-10-02 Fortinet, Inc. System and method for virtual router failover in a network routing system
US7096383B2 (en) 2002-08-29 2006-08-22 Cosine Communications, Inc. System and method for virtual router failover in a network routing system
US20040078621A1 (en) * 2002-08-29 2004-04-22 Cosine Communications, Inc. System and method for virtual router failover in a network routing system
US8412982B2 (en) 2002-08-29 2013-04-02 Google Inc. Fault tolerant routing in a non-hot-standby configuration of a network routing system
US20100011245A1 (en) * 2002-08-29 2010-01-14 Fortinet, Inc. Fault tolerant routing in a non-hot-standby configuration of a network routing system
US8819486B2 (en) 2002-08-29 2014-08-26 Google Inc. Fault tolerant routing in a non-hot-standby configuration of a network routing system
US20070162783A1 (en) * 2002-08-29 2007-07-12 Fortinet, Inc. System and method for virtual router failover in a network routing system
US7668181B2 (en) * 2002-10-22 2010-02-23 At&T Intellectual Property Ii, L.P. Virtual private network based upon multi-protocol label switching adapted to measure the traffic flowing between single rate zones
US20040076165A1 (en) * 2002-10-22 2004-04-22 Le Pennec Jean-Francois Virtual private network based upon multi-protocol label switching adapted to measure the traffic flowing between single rate zones
US20040093424A1 (en) * 2002-11-05 2004-05-13 Kozo Kojima Packet routing device
US20050074001A1 (en) * 2002-11-12 2005-04-07 Cisco Technology, Inc. System and method for local packet transport services within distributed routers
US7424014B2 (en) 2002-11-12 2008-09-09 Cisco Technology, Inc. System and method for local packet transport services within distributed routers
US9054980B2 (en) 2002-11-12 2015-06-09 Cisco Technology, Inc. System and method for local packet transport services within distributed routers
US7843930B2 (en) 2002-11-12 2010-11-30 Cisco Technology, Inc. System and method for local packet transport services within distributed routers
US20080198854A1 (en) * 2002-11-12 2008-08-21 Cisco Technology, Inc. System and method for local packet transport services within distributed routers
US8687632B2 (en) 2002-11-12 2014-04-01 Cisco Technology, Inc. System and method for local packet transport services within distributed routers
US20040095934A1 (en) * 2002-11-18 2004-05-20 Cosine Communications, Inc. System and method for hardware accelerated packet multicast in a virtual routing system
US7266120B2 (en) 2002-11-18 2007-09-04 Fortinet, Inc. System and method for hardware accelerated packet multicast in a virtual routing system
US9407449B2 (en) 2002-11-18 2016-08-02 Fortinet, Inc. Hardware-accelerated packet multicasting
US10200275B2 (en) 2002-11-18 2019-02-05 Fortinet, Inc. Hardware-accelerated packet multicasting
US9014186B2 (en) 2002-11-18 2015-04-21 Fortinet, Inc. Hardware-accelerated packet multicasting
US8644311B2 (en) 2002-11-18 2014-02-04 Fortinet, Inc. Hardware-accelerated packet multicasting in a virtual routing system
CN1297105C (en) * 2003-01-06 2007-01-24 华为技术有限公司 Method for implementing multirole main machine based on virtual local network
WO2004084495A1 (en) * 2003-02-20 2004-09-30 6Wind Method for interconnecting virtual private networks in non-connected mode
FR2851706A1 (en) * 2003-02-20 2004-08-27 6Wind Virtual private networks interconnecting method, involves embedding encapsulation mechanism in access router of operator, where mechanism calculates header for desired messages to be transmitted
US20060179480A1 (en) * 2003-02-20 2006-08-10 6Wind Method for interconnecting virtual private networks in non-connected mode
CN1323525C (en) * 2003-06-12 2007-06-27 华为技术有限公司 Method for communication in VPN by using route distinguisher (RD)
US7715380B2 (en) * 2003-06-19 2010-05-11 Cisco Technology, Inc. Apparatus and methods for handling shared services through virtual route forwarding (VRF)-aware-NAT
US20060013209A1 (en) * 2003-06-19 2006-01-19 Cisco Technology, Inc. Apparatus and methods for handling shared services through virtual route forwarding(VRF) -aware- NAT
CN1781297B (en) * 2003-06-19 2011-05-11 思科技术公司 Apparatus and methods for handling shared services through virtual route forwarding (VRF) -aware-NAT
US20040260949A1 (en) * 2003-06-20 2004-12-23 Aoki Norihiro Edwin Chaining of services
US9853917B2 (en) 2003-08-27 2017-12-26 Fortinet, Inc. Heterogeneous media packet bridging
US9331961B2 (en) 2003-08-27 2016-05-03 Fortinet, Inc. Heterogeneous media packet bridging
US9509638B2 (en) 2003-08-27 2016-11-29 Fortinet, Inc. Heterogeneous media packet bridging
US8503463B2 (en) 2003-08-27 2013-08-06 Fortinet, Inc. Heterogeneous media packet bridging
US20050074003A1 (en) * 2003-10-02 2005-04-07 Ball David Alexander Distributed software architecture for implementing BGP
US20050086368A1 (en) * 2003-10-15 2005-04-21 Dell Products L.P. System and method for determining nearest neighbor information
US7237267B2 (en) 2003-10-16 2007-06-26 Cisco Technology, Inc. Policy-based network security management
US20050086502A1 (en) * 2003-10-16 2005-04-21 Ammar Rayes Policy-based network security management
US20060215698A1 (en) * 2003-11-19 2006-09-28 Amen Hamdan Communication subsystem controlled information dissemination
US8488470B2 (en) 2003-12-18 2013-07-16 Cisco Technology, Inc. Withdrawing multiple advertised routes based on a single tag which may be of particular use in border gateway protocol
US20110069639A1 (en) * 2003-12-18 2011-03-24 Cisco Technology, Inc., A Corporation Of California Withdrawing Multiple Advertised Routes Based On A Single Tag Which May Be Of Particular Use In Border Gateway Protocol
US7860115B1 (en) * 2003-12-18 2010-12-28 Cisco Technology, Inc. Withdrawing multiple advertised routes based on a single tag which may be of particular use in border gateway protocol
US7848310B1 (en) 2004-01-30 2010-12-07 Juniper Networks, Inc. Providing transparent virtual private network connectivity across intermediate networks
US7420958B1 (en) * 2004-01-30 2008-09-02 Juniper Networks, Inc. Providing transparent virtual private network connectivity across intermediate networks
US7420973B2 (en) 2004-02-09 2008-09-02 Redback Networks Inc. Context selection in a network element through subscriber flow switching
US20050175001A1 (en) * 2004-02-09 2005-08-11 Becker Hof Onno M. Context selection in a network element through subscriber flow switching
US20050195835A1 (en) * 2004-03-02 2005-09-08 Savage Donnie V. Router configured for outputting update messages specifying a detected attribute change of a connected active path according to a prescribed routing protocol
US7720054B2 (en) 2004-03-02 2010-05-18 Cisco Technology, Inc. Router configured for outputting update messages specifying a detected attribute change of a connected active path according to a prescribed routing protocol
US7607021B2 (en) 2004-03-09 2009-10-20 Cisco Technology, Inc. Isolation approach for network users associated with elevated risk
US7633874B1 (en) 2004-04-28 2009-12-15 Cisco Technology, Inc. Soft notification messaging for a routing protocol
US20050265308A1 (en) * 2004-05-07 2005-12-01 Abdulkadev Barbir Selection techniques for logical grouping of VPN tunnels
US7672314B2 (en) 2004-07-09 2010-03-02 Cisco Technology, Inc. Scaling VLANs in a data network
US20060007939A1 (en) * 2004-07-09 2006-01-12 Anusankar Elangovan Scaling VLANs in a data network
US7881244B2 (en) 2004-09-24 2011-02-01 Fortinet, Inc. Scalable IP-services enabled multicast forwarding with efficient resource utilization
US10038567B2 (en) 2004-09-24 2018-07-31 Fortinet, Inc. Scalable IP-services enabled multicast forwarding with efficient resource utilization
US8213347B2 (en) 2004-09-24 2012-07-03 Fortinet, Inc. Scalable IP-services enabled multicast forwarding with efficient resource utilization
US9167016B2 (en) 2004-09-24 2015-10-20 Fortinet, Inc. Scalable IP-services enabled multicast forwarding with efficient resource utilization
US20110122872A1 (en) * 2004-09-24 2011-05-26 Fortinet, Inc. Scalable ip-services enabled multicast forwarding with efficient resource utilization
US9166805B1 (en) 2004-09-24 2015-10-20 Fortinet, Inc. Scalable IP-services enabled multicast forwarding with efficient resource utilization
US8369258B2 (en) 2004-09-24 2013-02-05 Fortinet, Inc. Scalable IP-services enabled multicast forwarding with efficient resource utilization
US9319303B2 (en) 2004-09-24 2016-04-19 Fortinet, Inc. Scalable IP-services enabled multicast forwarding with efficient resource utilization
US20100142527A1 (en) * 2004-09-24 2010-06-10 Fortinet, Inc. Scalable IP-Services Enabled Multicast Forwarding with Efficient Resource Utilization
US20120137358A1 (en) * 2004-11-16 2012-05-31 Juniper Networks, Inc. Point-to-multi-point/non-broadcasting multi-access vpn tunnels
US8127349B2 (en) * 2004-11-16 2012-02-28 Juniper Networks, Inc. Point-to-multi-point/non-broadcasting multi-access VPN tunnels
US20100278181A1 (en) * 2004-11-16 2010-11-04 Juniper Networks, Inc. Point-to-multi-point/non-broadcasting mutli-access vpn tunnels
US7779461B1 (en) * 2004-11-16 2010-08-17 Juniper Networks, Inc. Point-to-multi-point/non-broadcasting multi-access VPN tunnels
US7876683B2 (en) 2004-11-18 2011-01-25 Fortinet, Inc. Managing hierarchically organized subscriber profiles
US7843813B2 (en) 2004-11-18 2010-11-30 Fortinet, Inc. Managing hierarchically organized subscriber profiles
US20090007228A1 (en) * 2004-11-18 2009-01-01 Fortinet, Inc. Managing hierarchically organized subscriber profiles
US20080117917A1 (en) * 2004-11-18 2008-05-22 Fortinet, Inc. Method and apparatus for managing subscriber profiles
US7869361B2 (en) 2004-11-18 2011-01-11 Fortinet, Inc. Managing hierarchically organized subscriber profiles
US7808904B2 (en) 2004-11-18 2010-10-05 Fortinet, Inc. Method and apparatus for managing subscriber profiles
US20070115979A1 (en) * 2004-11-18 2007-05-24 Fortinet, Inc. Method and apparatus for managing subscriber profiles
US7961615B2 (en) 2004-11-18 2011-06-14 Fortinet, Inc. Managing hierarchically organized subscriber profiles
US20080320553A1 (en) * 2004-11-18 2008-12-25 Fortinet, Inc. Managing hierarchically organized subscriber profiles
US20080317231A1 (en) * 2004-11-18 2008-12-25 Fortinet, Inc. Managing hierarchically organized subscriber profiles
US20080317040A1 (en) * 2004-11-18 2008-12-25 Fortinet, Inc. Managing hierarchically organized subscriber profiles
US20060182115A1 (en) * 2005-02-16 2006-08-17 Himanshu Shah System for scheduling scans of interior nodes of a network domain for reachability events
US7969907B2 (en) 2005-02-16 2011-06-28 Cisco Technology, Inc. System for scheduling scans of interior nodes of a network domain for reachability events
US20060198368A1 (en) * 2005-03-04 2006-09-07 Guichard James N Secure multipoint internet protocol virtual private networks
US7724732B2 (en) * 2005-03-04 2010-05-25 Cisco Technology, Inc. Secure multipoint internet protocol virtual private networks
WO2007006193A1 (en) * 2005-07-07 2007-01-18 Huawei Technologies Co., Ltd. A method for preventing the user from obtaining the service provider network information and the equipment as well as the system thereof
US7710899B1 (en) 2005-08-16 2010-05-04 Cisco Technology, Inc. System and method for speeding border gateway protocol graceful restart
US7852772B2 (en) 2005-10-20 2010-12-14 Cisco Technology, Inc. Method of implementing a backup path in an autonomous system
US7864669B2 (en) 2005-10-20 2011-01-04 Cisco Technology, Inc. Method of constructing a backup path in an autonomous system
US20070091796A1 (en) * 2005-10-20 2007-04-26 Clarence Filsfils Method of implementing a backup path in an autonomous system
US20070091795A1 (en) * 2005-10-20 2007-04-26 Olivier Bonaventure Method of constructing a backup path in an autonomous system
US20070091794A1 (en) * 2005-10-20 2007-04-26 Clarence Filsfils Method of constructing a backup path in an autonomous system
US7855953B2 (en) 2005-10-20 2010-12-21 Cisco Technology, Inc. Method and apparatus for managing forwarding of data in an autonomous system
US20070091793A1 (en) * 2005-10-20 2007-04-26 Clarence Filsfils Method and apparatus for managing forwarding of data in an autonomous system
US20070121615A1 (en) * 2005-11-28 2007-05-31 Ofer Weill Method and apparatus for self-learning of VPNS from combination of unidirectional tunnels in MPLS/VPN networks
US8588238B2 (en) 2005-11-28 2013-11-19 Cisco Technology, Inc. Method and apparatus for self-learning of VPNS from combinations of unidirectional tunnels in MPLS/VPN networks
US8270413B2 (en) 2005-11-28 2012-09-18 Cisco Technology, Inc. Method and apparatus for self-learning of VPNS from combination of unidirectional tunnels in MPLS/VPN networks
US7710872B2 (en) 2005-12-14 2010-05-04 Cisco Technology, Inc. Technique for enabling traffic engineering on CE-CE paths across a provider network
US8155000B2 (en) 2005-12-14 2012-04-10 Cisco Technology, Inc. Technique for enabling traffic engineering on CE-CE paths across a provider network
US20100208741A1 (en) * 2005-12-14 2010-08-19 Cisco Technology, Inc. Technique for enabling traffic engineering on ce-ce paths across a provider network
US20070189157A1 (en) * 2006-02-13 2007-08-16 Cisco Technology, Inc. Method and system for providing safe dynamic link redundancy in a data network
US8644137B2 (en) 2006-02-13 2014-02-04 Cisco Technology, Inc. Method and system for providing safe dynamic link redundancy in a data network
US7724745B1 (en) 2006-03-09 2010-05-25 Cisco Technology, Inc. Method and device for efficient transmission of flood data frames in a backbone network
US20070217419A1 (en) * 2006-03-14 2007-09-20 Jean-Philippe Vasseur Technique for efficiently routing IP traffic on CE-CE paths across a provider network
US7522603B2 (en) 2006-03-14 2009-04-21 Cisco Technology, Inc. Technique for efficiently routing IP traffic on CE-CE paths across a provider network
US7583672B2 (en) 2006-04-05 2009-09-01 Cisco Technology, Inc. Techniques to support asymmetrical static/dynamic adjacency in routers
US8023517B2 (en) * 2006-04-05 2011-09-20 Cisco Technology, Inc. System and method for improving network performance and security by controlling topology information
US20070237095A1 (en) * 2006-04-05 2007-10-11 Cisco Technology, Inc. System and method for improving network performance and security by controlling topology information
US7865615B2 (en) 2006-05-08 2011-01-04 Cisco Technology, Inc. Maintaining IGP transparency of VPN routes when BGP is used as a PE-CE protocol
US20070260746A1 (en) * 2006-05-08 2007-11-08 Sina Mirtorabi Maintaining IGP transparency of VPN routes when BGP is used as a PE-CE protocol
US8111616B2 (en) 2006-09-08 2012-02-07 Cisco Technology, Inc. Constructing a repair path in the event of failure of an inter-routing domain system link
US20080219153A1 (en) * 2006-09-08 2008-09-11 Cisco Technology, Inc. Constructing a repair path in the event of failure of an inter-routing domain system link
US8705374B1 (en) * 2006-10-31 2014-04-22 At&T Intellectual Property Ii, L.P. Method and apparatus for isolating label-switched path impairments
US20080112418A1 (en) * 2006-11-14 2008-05-15 Cisco Technology, Inc. Modification to as_path elements
US8065438B2 (en) * 2006-11-14 2011-11-22 Cisco Technology, Inc. Modification to AS—path elements
US8675656B2 (en) 2007-02-20 2014-03-18 Cisco Technology, Inc. Scaling virtual private networks using service insertion architecture
US20080198849A1 (en) * 2007-02-20 2008-08-21 Jim Guichard Scaling virtual private networks using service insertion architecture
US20090097492A1 (en) * 2007-10-12 2009-04-16 Telefonaktiebolaget Lm Ericsson (Publ) Support of triple play services in user devices
US8867334B2 (en) 2008-05-30 2014-10-21 Cisco Technology, Inc. Efficient convergence of grouped VPN prefixes
US8121032B2 (en) 2008-05-30 2012-02-21 Cisco Technology, Inc. Efficient convergence of grouped VPN prefixes
US20090296579A1 (en) * 2008-05-30 2009-12-03 Cisco Technology, Inc. Efficient convergence of grouped vpn prefixes
US8098663B2 (en) * 2008-07-08 2012-01-17 Cisco Technology, Inc. Carrier's carrier without customer-edge-to-customer-edge border gateway protocol
US20100008361A1 (en) * 2008-07-08 2010-01-14 Cisco Technology, Inc. Carrier's carrier without customer-edge-to-customer-edge border gateway protocol
TWI423616B (en) * 2008-07-31 2014-01-11 Broadcom Corp Data path acceleration of a network stack
US8578055B2 (en) 2009-07-09 2013-11-05 International Business Machines Corporation Propogation of DNS server IP addresses in a private network
US20110010413A1 (en) * 2009-07-09 2011-01-13 International Business Machines Corporation Tcp/ip host name resolution on a private network
US20110010463A1 (en) * 2009-07-09 2011-01-13 International Business Machines Corporation Propogation of dns server ip addresses in a private network
US8103795B2 (en) 2009-07-09 2012-01-24 International Business Machines Corporation TCP/IP host name resolution on a private network
US20110055374A1 (en) * 2009-08-31 2011-03-03 International Business Machines Corporation Computer implemented dns server ip address lookup mechanism
US8140669B2 (en) * 2009-08-31 2012-03-20 International Business Machines Corporation Resolving hostnames on a private network with a public internet server
US8937961B1 (en) 2010-12-07 2015-01-20 Juniper Networks, Inc. Modular software architecture for a route server within an internet exchange
US8627449B2 (en) * 2011-03-03 2014-01-07 Cisco Technology, Inc. Dynamic tunneling over virtual private network connections based on network conditions
US20120227102A1 (en) * 2011-03-03 2012-09-06 Cisco Technology, Inc. Dynamic Tunneling over Virtual Private Network Connections based on Network Conditions
US9338080B2 (en) 2012-09-14 2016-05-10 Cisco Technology, Inc. Performing offline BGP prefix origin and path validation at route reflectors
US9049148B1 (en) 2012-09-28 2015-06-02 Juniper Networks, Inc. Dynamic forwarding plane reconfiguration in a network device
US20140139865A1 (en) * 2012-11-20 2014-05-22 Fuji Xerox Co., Ltd. Information processing apparatus, information processing method, and non-transitory computer readable medium
US9197488B2 (en) * 2012-11-20 2015-11-24 Fuji Xerox Co., Ltd. Information processing apparatus, information processing method, and non-transitory computer readable medium
US20160381573A1 (en) * 2015-06-04 2016-12-29 Telefonaktiebolaget L M Ericsson (Publ) Controlling communication mode of a mobile terminal
US9906912B2 (en) * 2015-06-04 2018-02-27 Telefonaktiebolaget Lm Ericcson (Publ) Controlling communication mode of a mobile terminal

Also Published As

Publication number Publication date
US6339595B1 (en) 2002-01-15
US7668166B1 (en) 2010-02-23
US6526056B1 (en) 2003-02-25
US7154889B1 (en) 2006-12-26

Similar Documents

Publication Publication Date Title
US6463061B1 (en) Shared communications network employing virtual-private-network identifiers
US7307990B2 (en) Shared communications network employing virtual-private-network identifiers
US7369556B1 (en) Router for virtual private network employing tag switching
CN110086714B (en) Handling multicast connection messages by multi-homed devices in Ethernet VPNs
Gleeson et al. A framework for IP based virtual private networks
US5361256A (en) Inter-domain multicast routing
US5996021A (en) Internet protocol relay network for directly routing datagram from ingress router to egress router
US6295296B1 (en) Use of a single data structure for label forwarding and imposition
US7756998B2 (en) Managing L3 VPN virtual routing tables
CA2287721C (en) Router device and label switched path control method using upstream initiated aggregation
JP4183379B2 (en) Network and edge router
US8045547B2 (en) Method and apparatus for routing and forwarding between virtual routers within a single network element
US7620069B2 (en) Transport networks supporting virtual private networks, and configuring such networks
US5600644A (en) Method and apparatus for interconnecting LANs
US8467394B2 (en) Automatic route tagging of BGP next-hop routes in IGP
EP0836359B1 (en) Internet NCP (network control point) over ATM
US7653074B2 (en) Method and apparatus for virtual private networks
US20050265308A1 (en) Selection techniques for logical grouping of VPN tunnels
US7274704B1 (en) Piggybacking VPN information in BGP for network based VPN architectures
US20040078469A1 (en) Managing VLAN traffic in a multiport network node using customer-specific identifiers
US20080198849A1 (en) Scaling virtual private networks using service insertion architecture
US20040177157A1 (en) Logical grouping of VPN tunnels
EP1475942A2 (en) Address Resolution in IP Internetworking Layer 2 point-to-point connections
JP2013158034A (en) Implementation of vpns over link state protocol controlled ethernet network
JPH10190715A (en) Network switching system

Legal Events

Date Code Title Description
STCF Information on status: patent grant

Free format text: PATENTED CASE

FPAY Fee payment

Year of fee payment: 4

FPAY Fee payment

Year of fee payment: 8

FPAY Fee payment

Year of fee payment: 12