|Publication number||US7742477 B1|
|Application number||US 11/347,182|
|Publication date||Jun 22, 2010|
|Filing date||Feb 3, 2006|
|Priority date||Feb 3, 2006|
|Publication number||11347182, 347182, US 7742477 B1, US 7742477B1, US-B1-7742477, US7742477 B1, US7742477B1|
|Inventors||James N. Guichard, Robert Hanzl, Mohammed Sayeed, Sumit Mukhopadhyay|
|Original Assignee||Cisco Technology, Inc.|
|Export Citation||BiBTeX, EndNote, RefMan|
|Patent Citations (13), Non-Patent Citations (5), Referenced by (5), Classifications (11), Legal Events (3)|
|External Links: USPTO, USPTO Assignment, Espacenet|
Before discussing the present invention, certain terms, used throughout the description, will be defined.
An Autonomous System Border Router (ASBR) is a router located on an edge of an autonomous system and functions as an autonomous system's link to other routing domains. The ASBR exchanges router information with routers belonging to other routing domains. Such a router has AS external routes that are advertised throughout the autonomous system. The path to each ASBR is known to every other router in the autonomous system.
Routers support Virtual Routing and Forwarding instances (VRFs). A VRF includes a network address routing table, a derived forwarding table, a set of interfaces or VLANs that use the forwarding table, and a set of rules and routing protocols that determine what goes into the forwarding table.
A Virtual Private Network (VPN) is a network that uses a public telecommunication infrastructure, such as the Internet, to provide remote offices or individual users with secure access to their organization's network. A VPN works by using the shared public infrastructure while maintaining privacy through security procedures and tunneling protocols.
Multi-Protocol Border Gateway Protocol (MPBGP) is an exterior gateway routing protocol that enables groups of routers (called autonomous systems) to share routing information so that efficient, loop-free routes can be established.
Multi-Protocol Label Switching (MPLS) is a standards-approved technology for speeding up network traffic flow and making it easier to manage. MPLS involves setting up a specific path for a given sequence of packets, identified by a label put in each packet, thus saving the time needed for a router to look up the address to the next node to forward the packet to. MPLS is called multiprotocol because it works with the Internet Protocol (IP), Asynchronous Transport Mode (ATM), and frame relay network protocols.
A Service Level Agreement (SLA) is a contract between a network service provider and a customer that specifies, usually in measurable terms, what services the network service provider will furnish. Many Internet service providers (ISP)s provide their customers with an SLA. More recently, IS departments in major enterprises have adopted the idea of writing a service level agreement so that services for their customers (users in other departments within the enterprise) can be measured, justified, and compared with those of outsourcing network providers.
Routing type (RT) identifies a particular routine header variant. If a router does not recognize the routing type value, it must discard the packet.
Route distinguisher (RD) is an address qualifier used to distinguish the distinct Virtual Private Network (VPN) routes of separate customers who connect to the provider. The route distinguisher is an 8-byte field prefixed to the customer's Internet Protocol address (IPv4). The resulting 12-byte field is a unique “VPN-IPv4” address. The route distinguisher is used to make IPv4 or Ipv6 prefixes globally unique. It is not used for forwarding, but it is used by the routers BGP process to identify each prefix as unique, even though the 4 byte IP-address may be equal. For example, for a PE router to be able to distinguish between the IP address 10.0.0.0 of one customer from the 10.0.0.0 of another customer, the network administrator must add a unique route distinguisher to each.
On the Internet and in other networks, QoS (Quality of Service) is the idea that transmission rates, error rates, and other characteristics can be measured, improved, and, to some extent, guaranteed in advance. QoS is of particular concern for the continuous transmission of high-bandwidth video and multimedia information. Transmitting this kind of content dependably is difficult in public networks using ordinary “best effort” protocols. Using the Internet's Resource Reservation Protocol (RSVP), packets passing through a gateway host can be expedited based on policy and reservation criteria arranged in advance. Using ATM, which also lets a company or user preselect a level of quality in terms of service, QoS can be measured and guaranteed in terms of the average delay at a gateway, the variation in delay in a group of cells (cells are 53-byte transmission units), cell losses, and the transmission error rate.
A Label Forwarding Information Base (LFIB) is a subset of a Label Information Base (LIB). The LFIB contains an incoming label, an outgoing label, a next hop and an outgoing interface. The LFIB contains what is actually being used to forward packets via label swapping, whereas the LIB contains all possible routes (generated by the underlying routing Link State Protocol) with labels already assigned (assuming frame mode MPLS). The LFIB has only routes that are considered “best” by the routing protocols. The LIB has IP information, label and interface information, but no indication of which is the shortest path to the given destination. Any route in the LFIB will also be in the LIB, but not the other way around.
The industry has standardized on a few Inter-Autonomous System (AS) models that the service providers may deploy. The current industry standards for Inter-AS solutions include the models defined as 10 a (also referred to as option A), 10 b (also referred to as option B), and 10 c.
The first model defined and deployed by many service providers is the 10 a model. The 10 a model requires the provider to build on their ASBR a VRF per VPN, a unique peering interface per VRF, and a unique routing process per VRF. The peer ASBR does the same thereby creating a one-for-one relationship between the two ASBR's. The advantages of the 10 a model include discrete interfaces facilitating QoS mechanisms and explicit resource management methods that protect the memory and processing resources. Likewise, the exposure of the ASBR and the attached network is limited.
The second model defined and deployed by a few service providers is the 10 b model. The 10 b model only requires the provider to build a single interface for each peer and a single routing process on the interface. The routing process (MP-BGP) is able to maintain the segregation of VPN prefixes without having to use discrete VRF's per VPN. The advantages include less memory consumption for the routing prefixes and interfaces, less processor consumption for the routing process, and automatic VPN session binding between the ASBR's.
The third model defined and rarely deployed by service providers is the 10 c method. The 10 c model only requires the provider to build a single interface for each peer and a single routing process on the interface. A routing process (MP-BGP) is able to maintain the segregation of VPN prefixes without requiring a presence on the ASBR. The advantages include even less memory consumption for the routing prefixes since the VPN prefixes are passed around the ASBR. The ASBR has even less processor consumption since the ASBR serves as a core device providing connectivity between the two AS's.
The two most commonly used models—10 a and 10 b—have orthogonal capabilities. Where 10 a is strong, 10 b is weak and vice-a-versa. Table 1 provides a synopsis of the existing solutions.
Routing processes are complex state machines that keep track of the prefixes and the paths to reach the prefixes. Routing processes can be constrained by a number of factors such as the number of peers or adjacencies, the number of routing entries, and the number of potentially viable paths for each routing entry. As the number of prefixes and interfaces increase, the computation complexity increases thereby requiring more processor schedule time. Excessive computational routing complexity on the ASBR may impact any or all the VPN's. As shown in Table 1, the 10 a method requires many routing processes, while the 10 b and 10 c methods require a single routing process.
Interfaces consume memory constructs and typically require an operator to configure the interface and the associate peer entity. The cost of a VPN interface is usually not too cumbersome in an Inter-AS solution as the number of VPNs is typically small. Nevertheless, the interface must be created and correctly associated with the appropriate customer. The 10 a method requires many interfaces, while the 10 b and 10 c methods require a single interface.
Memory is allocated for VPN prefixes. VPN prefixes can create a resource burden on the ASBR. The number of prefixes is not directly controlled by a single provider or customer, but by the aggregate set of operators and customers. For this reason, memory allocated for VPN prefixes may be very precious. The 10 a method requires memory on a per-prefix basis, while the 10 b and 10 c methods require memory on a per-label basis.
The customers of the MPLS VPN are particularly interested in QoS, especially at provider boundaries where SLA's tend to be difficult to enforce. Each enterprise has unique QoS requirements that may be difficult to handle in aggregate; however, provisioning a QoS model per customer is also a challenge especially when there is no discrete point where the QoS model may be applied. The 10 a method requires QoS on a per-VPN basis, whereas the 10 b and 10 c methods require QoS on a global basis.
The Inter-AS model requires a configuration that establishes a relationship between the ASBR's for each VPN. The configuration should be simple to implement and should be easy to replicate. The 10 a method requires more manual configuration, while the 10 b and 10 c methods utilize dynamic configuration.
Resources (memory, interfaces, and processor schedule time) are precious for a service provider. In particular, the provider is interested in conducting “One Time Provisioning” for many services. In addition, the management of the allocated resources can become a burden. To minimize the Operation Expenditures, the provider will frequently over-provision many of the components in a solution if the Capital Costs of the components are negligible. On the contrary, the expensive components are monitored closely and judiciously allocated. Resource management plays a critical role insuring SLA's are met. The 10 a method provides strong resource management, while the 10 b and 10 c methods provide weak resource management.
Closely related with resource management is security. Security requirements permeate the solution such that the provider can protect their assets, their ability to provide services, as well as one customer from another customer. Security is based on a risk management model where the law of diminishing returns plays a critical role. The cost of security (capital costs, functional costs, operational costs) must be balanced against the potential risk (liability costs, credibility, etc.). Clearly, failure to address the security requirements of a solution makes the previous points highlighted somewhat pointless. The 10 a method provides for strong security, while the 10 b method provides weaker security and the 10 c method provides even weaker security than the 10 b method.
Customers of a 2547bis-based VPN service often need to connect to multiple Service Providers in order to achieve connectivity for all of their sites. The Service Providers need to setup peering points where they exchange VPN prefixes and data traffic. The various types of connections between 2547bis Service Providers are described in draft-ietf-13vpn-rfc2547bis-03.txt.
Many providers select the peering based on a per-VRF basis, i.e. for each customer (VRF), they have a dedicated interface (either physical or logical) where they exchange customer prefixes and traffic. This is a good solution from a security and QOS point of view, the individual customers are isolated from each other and customer SLAs could be applied on such interfaces. This option is called option A, since it's documented as such in chapter 10 paragraph A in draft-ietf-13vpn-rfc2547bis-03.txt.
However, this option does not scale well with the increase in the number of customers. There are two areas where scalability becomes an issue—their needs to be one interface for each customer, and one routing protocol session running on that interface. The routing protocol session is usually BGP-4. This idea addresses the second limitation —the need to have one routing protocol session per customer.
Conventional mechanisms such as those explained above suffer from a variety of deficiencies. One such deficiency is that the conventional 10 a model consumes more resources on the ASBR which limits the scalability of the model. Resources include establishment of routing entries, interfaces, and routing processes. Routing entries and interfaces consume memory while routing processes consume processing resources. In addition, each of the constructs must be manually configured per customer.
Regarding the 10 b model, the single interface exposes the ASBR (and the attached provider network) to the peer network and their customers. There is no distinct point of enforcement for applying resource management and QoS mechanisms on a per customer basis.
Embodiments of the invention significantly overcome such deficiencies and provide mechanisms and techniques that provide a combination of interprovider options A and B to provide a scalable 2547bis interconnect environment.
In a particular embodiment of a method for providing autonomous system interconnect, the method includes decoupling a control plane and a data plane for a network device. The method also includes providing a single interface for control plane exchange for all customers for the network device and providing an interface for each customer for that customer's data plane for the network device.
Other embodiments include a computer readable medium having computer readable code thereon for providing autonomous system interconnect. The medium includes instructions for decoupling a control plane and a data plane for a network device. The computer readable medium further includes instructions for providing a single interface for control planes for all customers for the network device, and instructions for providing an interface for each customer for that customer's data plane for the network device.
Still other embodiments include a computerized device, configured to process all the method operations disclosed herein as embodiments of the invention. In such embodiments, the computerized device includes a memory system, a processor, communications interface in an interconnection mechanism connecting these components. The memory system is encoded with a process that provides concatenation of interprovider models A and B as explained herein that when performed (e.g. when executing) on the processor, operates as explained herein within the computerized device to perform all of the method embodiments and operations explained herein as embodiments of the invention. Thus any computerized device that performs or is programmed to perform up processing explained herein is an embodiment of the invention.
Other arrangements of embodiments of the invention that are disclosed herein include software programs to perform the method embodiment steps and operations summarized above and disclosed in detail below. More particularly, a computer program product is one embodiment that has a computer-readable medium including computer program logic encoded thereon that when performed in a computerized device provides associated operations providing concatenation of interprovider models A and B as explained herein. The computer program logic, when executed on at least one processor with a computing system, causes the processor to perform the operations (e.g., the methods) indicated herein as embodiments of the invention. Such arrangements of the invention are typically provided as software, code and/or other data structures arranged or encoded on a computer readable medium such as an optical medium (e.g., CD-ROM), floppy or hard disk or other a medium such as firmware or microcode in one or more ROM or RAM or PROM chips or as an Application Specific Integrated Circuit (ASIC) or as downloadable software images in one or more modules, shared libraries, etc. The software or firmware or other such configurations can be installed onto a computerized device to cause one or more processors in the computerized device to perform the techniques explained herein as embodiments of the invention. Software processes that operate in a collection of computerized devices, such as in a group of data communications devices or other entities can also provide the system of the invention. The system of the invention can be distributed between many software processes on several data communications devices, or all processes could run on a small set of dedicated computers, or on one computer alone.
It is to be understood that the embodiments of the invention can be embodied strictly as a software program, as software and hardware, or as hardware and/or circuitry alone, such as within a data communications device. The features of the invention, as explained herein, may be employed in data communications devices and/or software systems for such devices such as those manufactured by Cisco Systems, Inc. of San Jose, Calif.
The foregoing will be apparent from the following more particular description of preferred embodiments of the invention, as illustrated in the accompanying drawings in which like reference characters refer to the same parts throughout the different views. The drawings are not necessarily to scale, emphasis instead being placed upon illustrating the principles of the invention.
VPN customers often need to connect to multiple RFC2547-bis service providers in order to achieve connectivity for all their sites. The service providers need to setup peering points where they exchange VPN prefixes and data traffic. The various types of connections between RFC2547-bis service providers are described in draft-ietf-13vpn-rfc2547bis-03.txt.
Many providers select the peering based on per-VRF basis, i.e. for each customer (VRF), they have a dedicated interface (either physical or logical) where they exchange customer prefixes and traffic. This is a good solution from security and QOS point of view, the individual customers are isolated from each other and customer SLAs could be applied on such interfaces. This option is called option A, since it's documented in chapter 10 paragraph A in draft-ietf-13vpn-rfc2547bis-03.txt.
However, this option does not scale well with the number of customers. There are two areas where scalability becomes an issue—their needs to be one interface for each customer, and one routing protocol session running on that interface. The routing protocol session is usually BGP.
Regarding the option B model, the single interface exposes the ASBR (and the attached provider network) to the peer network and their customers. There is no distinct point of enforcement for applying resource management and QoS mechanisms on a per customer basis.
The present method and apparatus for performing concatenation of interprovider models A and B for an autonomous system interconnect decouples control and data planes on network devices (e.g., ASBRs), preserving per customer data forwarding on separate interfaces from option A, and using a single BGP VPNv4 or VPNv6 session between the ASBRs from option B. This allows better scaling of the routing protocol sessions between the adjacent ASBRs. Only one BGP session is needed independently of the number of customers that are connected to both providers. Data forwarding is still done on individual VRF interfaces, one interface per customer. This separation of customer traffic allows implementation of per-customer SLA (QOS, traffic shaping and policing, etc).
Although the following paragraphs explicitly talk about VPNv4 and IPv4 address families, the feature is fully applicable to VPNv6 and IPv6 address families as well.
Referring now to
The present concatenation of interprovider models A and B in an autonomous system interconnect requires the installation of VRF forwarding entries. VPN prefixes learned from a remote ASBR are installed in the individual VRFs based on its RT values (and alternately other parameters specified in import maps). This procedure is called import.
VPNv4 prefixes are learned from the remote ASBR via a routing protocol session (e.g., BGP) that is in the global routing table context. Accordingly, in the conventional method, the learned nexthop address is also in the global routing table context. In order to force the traffic to go via the VRF interfaces, it is necessary to install the VRF forwarding entries using a nexthop that is in the importing VRF context. The address of the nexthop could be the same as the address of the remote ASBR in the global table, this would require to use the same IP addresses on the VRF interfaces as the corresponding global table VPNv4 session. If the provider needs to number the VRF interfaces differently from the global table VPNv4 session, a configuration command is used to map the corresponding global table VPNv4 neighbor address to an IP address reachable in the given VRF. In one embodiment the command is “nexthop map <global_nexthop><vrf_nexthop>” in the VRF configuration submode. Alternatively, the nexthop and nexthop context (VRF) could be set in inbound route map.
The advertising of the prefixes (learned from A+B peer) to IBGP peers has certain complications. First of all, the ASBR needs to always do next-hop-self towards the IBGP peers, so the traffic for the given prefix arrives at the ASBR which can route it to the VRF interface.
In certain scenarios, the prefix is imported to a single VRF, and has the same RD. In this situation, the ASBR advertises the prefix as is, only with doing next-hop-self.
When the prefix is imported to a single VRF with a different RD, the import process produces a new VPNV4 prefix with the RD of the VRF, and the IP prefix from the original VPNv4 prefix. The BGP table has two VPNv4 prefixes, the learned one, and the one created by import process. Conventional BGP behavior is that the learned one is advertised towards the other VPNv4 peers, but this is not the desired behavior here, since the learned prefix is not associated with any VRF. Instead, it is desirable to advertise the imported prefix (as if the prefix was learned on a VRF interface), but customers may want to also advertise the learned one. By default, the learned prefixes (except of the “same RD” import cases) are not advertised. If desired, some mechanism could be added to advertise the learned prefixes in addition to the imported ones. If the learned prefix is advertised with changed nexthop, it may be necessary to also install the VPNv4 MPLS forwarding entry.
When the prefix is imported into multiple VRFs, multiple VPNv4 copies with the appropriate RDs are created by the import process. In order to route the traffic (coming from other PEs towards this prefix) via the appropriate VRF interface, all the imported prefixes are advertised with a separate label. Remote PEs will need to select the right ones for installing to the appropriate VRFs.
When advertising the imported prefixes, the question is what to do with the learned RTs. Advertising the prefix as is would make it difficult to do the import correctly on the PEs. One way is to manipulate the RTs in an outbound route map (using RT rewrite feature). However, using the mechanisms described within this invention, by default, all RTs are deleted and only those specified in the “export” statement in the given VRF are added (to behave as if the prefix was learned on the VRF interface).
It's possible that a prefix is not imported into any VRF. A customer may use regular option B style forwarding for those prefixes (and install the VPNv4 MPLS forwarding entries), or just drop such prefixes altogether. This is controlled by the existing command “no bgp default route-target filter”.
In the conventional implementation of option B, the VPNv4 MPLS forwarding entries are created when a label is allocated and prefix advertised to a BGP peer. Since the advertising of the learned prefixes is suppressed (the imported ones are advertised instead), no VPNv4 entries forwarding will be installed. If the mechanism is added for allowing the learned prefixes to be advertised, the VPNv4 entries are installed as usual upon the label allocation.
In certain environments, the end customer may run a MPLS network, so the service providers need to be able to exchange MPLS labels and forward MPLS packets on the PE-CE interfaces. When carrying such a MPLS enabled VRF between the A+B ASBRs, there is also a need to exchange labeled packets between the ASBRs. The ASBR VRF interfaces are configured with “mpls bgp forwarding” to allow processing of MPLS packets on the VRF interfaces.
There are multiple solutions for determining whether there is a need to install the rewrite with or without the outgoing label.
One solution is when installing MPLS forwarding entries for interface with “mpls bgp forwarding” enabled, the learned outlabel is used, while without the command, packets are sent from such an interface as unlabeled. Configuring or removing this command on an interface would require a walk of the given VRF routing table and update the forwarding entries.
Another solution requires a new command (different from “mpls bgp forwarding”) which is used on the interface to enable/disable outlabel imposition. Again toggling this command requires a RIB walk.
Yet another solution is to use an inbound route map on the VPNv4 session to mark the entries that need to be installed with an outlabel. Changes in the route map would require a soft clear of the session.
The present method and apparatus providing concatenation of interprovider models A and B in an autonomous system interconnect allows improved scaling of the routing protocol sessions between the adjacent ASBRs. Only one MP-BGP session is needed independently of the number of customers that are connected to both providers. Data forwarding is still done on individual VRF interfaces, one interface per customer. This separation of customer traffic allows simple implementation of per-customer SLA (QOS, traffic shaping and policing, etc).
A flow chart of the presently disclosed method is depicted in
Referring now to
Processing block 104 states providing a single interface for control planes for all customers for the network device. As described in processing block 106, this requires running a routing protocol session (e.g., BGP). As further described in processing block 108, running a routing protocol session includes installing VRF forwarding entries into individual VRF's. Running a routing protocol also includes, as recited by processing block 110, advertising learned prefixes to peers.
The advertising of learned prefixes to peers can be accomplished in several manners for various scenarios. In processing block 112, advertising learned prefixes comprises advertising the prefix with next-hop-self. This is done when the learned prefix is imported to a single VRF and said VRF has a same Route Distinguisher (RD) as the prefix. In processing block 114, advertising learned prefixes comprises advertising the imported prefix with next-help-self. This is done when the prefix is imported to a single VRF having a different Route Distinguisher (RD) than an RD of the prefix and setting the next-hop accordingly. In processing block 116, advertising learned prefixes comprises advertising all imported prefixes when the prefix is imported into multiple VRFs. In processing block 118, advertising learned prefixes comprises one of the group comprising forwarding prefixes upon determination that said prefixes are not imported into any VRF and dropping said prefixes upon determination that said prefixes are imported into any VRF.
Processing continues with processing block 120 which discloses providing an interface for each customer for that customer's data plane for said network device. In this way, data forwarding is done on individual VRF interfaces, one interface per customer. This separation of customer traffic allows implementation of per-customer SLA (QoS, traffic shaping and policing, etc.).
In some embodiments it may be desirable to process MPLS packets. Processing block 122 recites processing of Multi Point Label Switching (MPLS) packets on the network device. The processing of MPLS packets may be accomplished in multiple ways. Processing block 124 states processing of MPLS packets comprises determining if MPLS forwarding is enabled for a predetermined interface and upon determination that MPLS forwarding is enabled using learned outlabels for the entries and upon determination that MPLS forwarding is not enabled sending unlabeled packets, and further by enabling a command for selecting outlabel imposition for a predetermined interface.
The memory system 212 may be any type of computer readable medium that is encoded with an application 255-A that represents software code such as data and/or logic instructions (e.g., stored in the memory or on another computer readable medium such as a disk) that embody the processing functionality of embodiments of the invention for the agent 255 as explained above. The processor 213 can access the memory system 212 via the interconnection mechanism 211 in order to launch, run, execute, interpret or otherwise perform the logic instructions of the applications 255-A for the host in order to produce a corresponding process 255-B. In other words, the process 255-B represents one or more portions of the application 255-A performing within or upon the processor 213 in the computer system.
It is to be understood that embodiments of the invention include the applications (i.e., the un-executed or non-performing logic instructions and/or data) encoded within a computer readable medium such as a floppy disk, hard disk or in an optical medium, or in a memory type system such as in firmware, read only memory (ROM), or, as in this example, as executable code within the memory system 212 (e.g., within random access memory or RAM). It is also to be understood that other embodiments of the invention can provide the applications operating within the processor 213 as the processes. While not shown in this example, those skilled in the art will understand that the computer system may include other processes and/or software and hardware components, such as an operating system, which have been left out of this illustration for ease of description of the invention.
Having described preferred embodiments of the invention, it will now become apparent to those of ordinary skill in the art that other embodiments incorporating these concepts may be used. Additionally, the software included as part of the invention may be embodied in a tangible computer program product that includes a computer useable medium. For example, such a computer usable medium can include a readable memory device, such as a hard drive device, a CD-ROM, a DVD-ROM, or a computer diskette, having computer readable program code segments stored thereon. Accordingly, it is submitted that the invention should not be limited to the described embodiments but rather should be limited only by the spirit and scope of the appended claims.
|Cited Patent||Filing date||Publication date||Applicant||Title|
|US6680940 *||May 19, 1999||Jan 20, 2004||3Com Corporation||System for transporting ethernet frames over very high speed digital subscriber lines|
|US7116665 *||Jun 4, 2002||Oct 3, 2006||Fortinet, Inc.||Methods and systems for a distributed provider edge|
|US7152115 *||Jul 9, 2002||Dec 19, 2006||Nortel Networks Limited||Virtual private networks|
|US7590074 *||Dec 2, 2004||Sep 15, 2009||Nortel Networks Limited||Method and apparatus for obtaining routing information on demand in a virtual private network|
|US20030118036 *||Dec 21, 2001||Jun 26, 2003||Mark Gibson||Routing traffic in a communications network|
|US20030174706 *||Mar 4, 2003||Sep 18, 2003||Broadcom Corporation||Fastpath implementation for transparent local area network (LAN) services over multiprotocol label switching (MPLS)|
|US20040081154 *||May 1, 2003||Apr 29, 2004||Cisco Technology, Inc.||Internal BGP downloader|
|US20040131079 *||Jan 7, 2003||Jul 8, 2004||Hegde Shriharsha S.||Apparatus and method for configuring data plane behavior on network forwarding elements|
|US20050025069 *||Dec 23, 2003||Feb 3, 2005||Nortel Networks Limited||Method and apparatus for implementing hub-and-spoke topology virtual private networks|
|US20050188106 *||Feb 11, 2004||Aug 25, 2005||Alcatel||Managing L3 VPN virtual routing tables|
|US20060039391 *||Jan 29, 2004||Feb 23, 2006||Cisco Technology, Inc.||Computing inter-autonomous system MPLS traffic engineering LSP paths|
|US20060133265 *||Dec 22, 2004||Jun 22, 2006||Alcatel||Virtual private networking methods and systems|
|US20070011351 *||Jul 7, 2006||Jan 11, 2007||Aurelien Bruno||Method and system for gateway selection in inter-region communication on IP networks|
|1||*||MPLS and Label switching Networks published by Uyless Black on Dec. 2002.|
|2||*||Non Patent Literature "MPLS and Label Switching Networks" published by Black.|
|3||*||RFC 2547 BGP/MPLS VPNs (Hereinafter RFC 2547) published by the Networking Group on Mar. 1999.|
|4||*||RFC 2547 BGP/MPLS VPNs published by the Networking Group on Mar. 1999. See whole Document.|
|5||Rosen, Eric C., RFC 2547bis, IETF, dated Oct. 2004.|
|Citing Patent||Filing date||Publication date||Applicant||Title|
|US8379649 *||Jun 29, 2009||Feb 19, 2013||Alaxala Networks Corporation||Arrangements for constructing a virtual private network (VPN) using forwarding techniques|
|US8432894 *||Feb 27, 2007||Apr 30, 2013||Alcatel Lucent||Asymmetrical forwarding in layer 3 IP VPNs|
|US20080205410 *||Feb 27, 2007||Aug 28, 2008||Alcatel Lucent||Asymmetrical forwarding in layer 3 IP VPNs|
|US20100080235 *||Jun 29, 2009||Apr 1, 2010||Keiichirou Yamate||Forwarding Apparatus, Forwarding Method, and Computer Program Product|
|WO2014059550A1 *||Oct 18, 2013||Apr 24, 2014||Iix Corp.||Method and apparatus for a distributed internet architecture|
|U.S. Classification||370/392, 709/222, 370/395.31, 370/471|
|Cooperative Classification||H04L45/50, H04L45/04, H04L45/02|
|European Classification||H04L45/50, H04L45/04, H04L45/02|
|Feb 3, 2006||AS||Assignment|
Owner name: CISCO TECHNOLOGY, INC.,CALIFORNIA
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:GUICHARD, JAMES N.;HANZL, ROBERT;SAYEED, MOHAMMED;AND OTHERS;REEL/FRAME:017548/0018
Effective date: 20060203
|Aug 10, 2010||CC||Certificate of correction|
|Dec 23, 2013||FPAY||Fee payment|
Year of fee payment: 4