CA2578954C - Routing protocol support for half duplex virtual routing and forwarding instance - Google Patents
Routing protocol support for half duplex virtual routing and forwarding instance Download PDFInfo
- Publication number
- CA2578954C CA2578954C CA2578954A CA2578954A CA2578954C CA 2578954 C CA2578954 C CA 2578954C CA 2578954 A CA2578954 A CA 2578954A CA 2578954 A CA2578954 A CA 2578954A CA 2578954 C CA2578954 C CA 2578954C
- Authority
- CA
- Canada
- Prior art keywords
- forwarding
- routing
- spoke
- vrf
- hub
- 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 - Fee Related
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L45/00—Routing or path finding of packets in data switching networks
- H04L45/54—Organization of routing tables
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L45/00—Routing or path finding of packets in data switching networks
- H04L45/02—Topology update or discovery
Abstract
A method, apparatus and computer program product for providing dynamic routing support for Half-Duplex Virtual Routing and Forwarding (HDVRF) environments. The method, apparatus and computer program function to configure a forwarding Virtual Routing and Forwarding (VRF) table for a router with information to forward incoming packets to a central location within a hub and spoke environment. The method, apparatus and computer program also function to populate a routing Virtual Routing and Forwarding (VRF) table for the router with routing information received from ingress interfaces of the router. The method, apparatus and computer program function further forwards packets received on egress interfaces of the router according to the forwarding VRF table.
Description
ROUTING PROTOCOL SUPPORT FOR HALF DUPLEX
VIRTUAL ROUTING AND FORWARDING INSTANCE
BACKGROUND
Half-Duplex Virtual Routing and Forwarding (HDVRF) maintain separate routing policy information entries to forward network traffic through a network node depending on the direction of the network traffic. Maintaining separate routing policy information (e.g., half duplex VRF information) for different directional traffic ensures that such traffic can be forwarded through a specified node and eventually to a target even though the network traffic may have otherwise traversed a shorter, more direct path to reach the target.
A detailed description of HDVRF can be found in co-pending patent application publication number US
2005/0083955, having the same inventorship and Assignee as the present application.
One conventional implementation of HDVRF involves maintaining separate upstream routing policy information and downstream policy information at a first network node supporting throughput of network traffic. The upstream routing policy information at the first node is used to identify a second node to forward upstream traffic (e.g., network traffic received from one or multiple sources traveling in a first direction) received from a first client communicating through the first node. The downstream routing policy information at the first node is used to forward downstream network traffic (e.g., network traffic received from one or multiple sources traveling in a second direction) received from another node to the first client. Thus, in general, separate routing policy entries are maintained to support routing and forwarding of traffic depending on their direction. By preventing use of the downstream policy routing information to route upstream network traffic, the first node may forward or route traffic along a path that the network traffic otherwise would have not traveled. Thus, network traffic communicated through the first node can be forced to travel through a network node (e.g., a second node) that it would have not otherwise have traveled if the downstream policy information was used to route the network traffic.
It should be noted that use of the relative terms upstream and downstream merely identify network traffic in different directions. For example, in the context of a service provider network supporting transmission of messages between a client and a service provider network, upstream traffic may be network messages received from a client for
VIRTUAL ROUTING AND FORWARDING INSTANCE
BACKGROUND
Half-Duplex Virtual Routing and Forwarding (HDVRF) maintain separate routing policy information entries to forward network traffic through a network node depending on the direction of the network traffic. Maintaining separate routing policy information (e.g., half duplex VRF information) for different directional traffic ensures that such traffic can be forwarded through a specified node and eventually to a target even though the network traffic may have otherwise traversed a shorter, more direct path to reach the target.
A detailed description of HDVRF can be found in co-pending patent application publication number US
2005/0083955, having the same inventorship and Assignee as the present application.
One conventional implementation of HDVRF involves maintaining separate upstream routing policy information and downstream policy information at a first network node supporting throughput of network traffic. The upstream routing policy information at the first node is used to identify a second node to forward upstream traffic (e.g., network traffic received from one or multiple sources traveling in a first direction) received from a first client communicating through the first node. The downstream routing policy information at the first node is used to forward downstream network traffic (e.g., network traffic received from one or multiple sources traveling in a second direction) received from another node to the first client. Thus, in general, separate routing policy entries are maintained to support routing and forwarding of traffic depending on their direction. By preventing use of the downstream policy routing information to route upstream network traffic, the first node may forward or route traffic along a path that the network traffic otherwise would have not traveled. Thus, network traffic communicated through the first node can be forced to travel through a network node (e.g., a second node) that it would have not otherwise have traveled if the downstream policy information was used to route the network traffic.
It should be noted that use of the relative terms upstream and downstream merely identify network traffic in different directions. For example, in the context of a service provider network supporting transmission of messages between a client and a service provider network, upstream traffic may be network messages received from a client for
2 transmission to a target device such as a provider edge `hub' node or customer edge `hub' node. Downstream traffic may be network traffic received at the first node from a wholesale service provider network (or at least traffic routed through the service provider network).
In another conventional implementation of HDVRF, the first network node may be configured to receive a session initiation request from a client desiring to establish a session to communicate through the first node. The client may not yet be assigned a network address for transmitting and receiving data messages. Upon receipt of the session initiation request, the first node may obtain network address assignment information from a network address server (e.g., a RADIUS server that assigns IP addresses for use by requesting clients) for the first client that generated the session initiation request. The assignment information including network address information may be forwarded to the first node and other network nodes for creating routes. For example, an assigned network address may uniquely identify a client over other nodes in the network.
In addition to notifying the client of its assigned network address information, the first node may populate its downstream routing policy information to include the network address information identifying the requesting client node. Generally, inclusion of the network address information of the client in the downstream routing policy information enables the first node to route information received from other upstream nodes back to the client. In one application, the first node populates the downstream policy information (e.g., VRF
information for routing data packets to the clients) with network address information of each new client associated with a given service. Thus, a list of supported clients nodes may be dynamically updated depending on establishment and termination of client network sessions.
Because the upstream and downstream routing policy information varies depending on which direction of traffic they support, they each may include information associated with multiple clients. For example, the downstream routing policy information may be a VRF
including a list of multiple clients supported by or coupled to the first node. In contradistinction, conventional methods require tracking separate VRF
instances for each of multiple clients. According to an embodiment of HDVRF, one VRF for upstream information includes a default address (or aggregate) or target (e.g., a hub) to route the upstream traffic while another VRF for the downstream traffic includes a list of multiple client's network address information. Based on the reduction of the number of separate VRF
instances, overhead maintenance of VRFs and use of memory resources to store the VRFs is reduced.
In another conventional implementation of HDVRF, the first network node may be configured to receive a session initiation request from a client desiring to establish a session to communicate through the first node. The client may not yet be assigned a network address for transmitting and receiving data messages. Upon receipt of the session initiation request, the first node may obtain network address assignment information from a network address server (e.g., a RADIUS server that assigns IP addresses for use by requesting clients) for the first client that generated the session initiation request. The assignment information including network address information may be forwarded to the first node and other network nodes for creating routes. For example, an assigned network address may uniquely identify a client over other nodes in the network.
In addition to notifying the client of its assigned network address information, the first node may populate its downstream routing policy information to include the network address information identifying the requesting client node. Generally, inclusion of the network address information of the client in the downstream routing policy information enables the first node to route information received from other upstream nodes back to the client. In one application, the first node populates the downstream policy information (e.g., VRF
information for routing data packets to the clients) with network address information of each new client associated with a given service. Thus, a list of supported clients nodes may be dynamically updated depending on establishment and termination of client network sessions.
Because the upstream and downstream routing policy information varies depending on which direction of traffic they support, they each may include information associated with multiple clients. For example, the downstream routing policy information may be a VRF
including a list of multiple clients supported by or coupled to the first node. In contradistinction, conventional methods require tracking separate VRF
instances for each of multiple clients. According to an embodiment of HDVRF, one VRF for upstream information includes a default address (or aggregate) or target (e.g., a hub) to route the upstream traffic while another VRF for the downstream traffic includes a list of multiple client's network address information. Based on the reduction of the number of separate VRF
instances, overhead maintenance of VRFs and use of memory resources to store the VRFs is reduced.
3 PCT/US2005/031015 After the downstream policy information is populated in the first node for a new client, the first node may distribute the network address information populated in the downstream policy information (at the first node) to other nodes via use of a notification message distributed according to a system routing protocol such as BGP (Border Gateway Protocol). For example,. the first node may be a first provider edge node of a network to which multiple clients are coupled. The first provider edge node may distribute each new network address associated with corresponding clients to a second node such as a second provider edge node of a core network supporting MPLS. Generally, the network address information sent to the second node (or multiple relevant nodes in a wholesale service provider network) is used to update routing policy information at the second node. The routing policy information at the second node is used in turn to identify a route on which to forward appropriately destined traffic to the clients coupled to the first provider edge node.
As discussed, for traffic received from the clients (such as upstream traffic), the first node utilizes the upstream routing policy information to identify a target node to forward the traffic regardless of a destination address associated with the traffic. More specifically, the first node may receive a network message from a client coupled to communicate through the first node. The first node utilizes the upstream routing policy information in the first node to identify a path or default route on which to forward the network traffic. Even if a destination address of the network traffic is another client coupled to the first node, the first node looks up a target route in the upstream routing policy information to identify a default route or node (such as a provider edge hub node or customer edge hub node) to forward the traffic. This technique of preventing use of the downstream routing policy information at the first node forces the network traffic to travel - a path that it otherwise may not have traveled if the downstream routing policy information were available (e.g., in the same VRF
table) to route upstream traffic. For example, if a first client coupled to the first node sends a message to a second client coupled to the first node, the first node might route the message received from the first client directly to the second client if the downstream routing policy information were available to route data. According to principles of the present invention, the message is forwarded along a route or target (such as a default route or target) specified by the upstream routing policy information even though a shorter path may exist directly back to the second client.
According to one conventional implementation, the upstream routing policy information and downstream policy information at the first node enables establishment of a
As discussed, for traffic received from the clients (such as upstream traffic), the first node utilizes the upstream routing policy information to identify a target node to forward the traffic regardless of a destination address associated with the traffic. More specifically, the first node may receive a network message from a client coupled to communicate through the first node. The first node utilizes the upstream routing policy information in the first node to identify a path or default route on which to forward the network traffic. Even if a destination address of the network traffic is another client coupled to the first node, the first node looks up a target route in the upstream routing policy information to identify a default route or node (such as a provider edge hub node or customer edge hub node) to forward the traffic. This technique of preventing use of the downstream routing policy information at the first node forces the network traffic to travel - a path that it otherwise may not have traveled if the downstream routing policy information were available (e.g., in the same VRF
table) to route upstream traffic. For example, if a first client coupled to the first node sends a message to a second client coupled to the first node, the first node might route the message received from the first client directly to the second client if the downstream routing policy information were available to route data. According to principles of the present invention, the message is forwarded along a route or target (such as a default route or target) specified by the upstream routing policy information even though a shorter path may exist directly back to the second client.
According to one conventional implementation, the upstream routing policy information and downstream policy information at the first node enables establishment of a
4 VPN (Virtual Private Network) connection between the first node and the second node (e.g., the default hub node) on which to forward traffic from the first client. Based on routing policy information at the second node, a return path (such as another VPN) may be established between the second node and the first node on which to forward the network messages to the first client through the first node.
Forcing traffic to travel through a node that it otherwise would not have traveled serves multiple purposes. For example, a target-specific packet processing technique for monitoring data packet flows may be implemented at the second node (such as a node of an ISP network) to monitor an amount of traffic associated with a particular client. Thus, a service provider may identify how much to charge a client for transmitting data through the network. Additionally, a monitoring authority such as an agency may monitor contents of data packets at the second node to identify whether the network is being used for illicit purposes.
SUMMARY
Conventional mechanisms such as those explained above suffer from a variety of deficiencies. One such shortcoming is that conventional HDVRF cannot be used with a dynamic routing protocol such as Routing Information Protocol (RIP) or Open Shortest Path First (OSPF). With a dynamic routing protocol, routers learn about the topology of the network by communicating with other routers. Thus, if a router is moved, additional routers are added, or in the case where a router fails, the other routers learn about the change or failure and can adjust their routing tables accordingly. Since conventional HDVRF utilizes separate upstream and downstream routing tables for a router, a dynamic routing protocol cannot be used with conventional HDVRF. Accordingly, any changes to a network utilizing HDVRF must be manually entered into the upstream and downstream routing tables in order to provide proper network operation. This operation of manual entry of network changes can be time consuming, labor intensive and is prone to human error.
Embodiments of the invention significantly overcome such limitations and provide mechanisms and techniques that provide dynamic routing protocol support for HDVRF
environments. The routing protocols run completely in the downstream Virtual Routing and Forwarding (VRF) context, and have no knowledge of the upstream VRF. The connected interfaces are also in the downstream VRF in order to locally terminate packets destined for the router itself. The interface addresses with a /32 mask are injected into the upstream VRF
for the locally terminated packets, the context is switched to downstream so all the locally running applications and routing protocols receive the packets in the expected context.
In a particular embodiment, a method of providing dynamic routing support for Half-Duplex Virtual Routing and Forwarding (HDVRF) environments includes configuring a forwarding VRF table for a spoke router, wherein the forwarding VRF table includes information to forward incoming packets to a central location within a hub and spoke environment. The method also includes populating a routing Virtual Routing and Forwarding (VRF) table for the spoke router with routing information received from ingress interfaces of the spoke router. Packets received on ingress interfaces of the spoke router are forwarded according to the forwarding VRF table.
Other embodiments include a computer readable medium having computer readable code thereon for providing dynamic routing support for Half-Duplex Virtual Routing and Forwarding (HDVRF) environments. The medium includes instructions for configuring a forwarding Virtual Routing and Forwarding (VRF) table for a spoke router, the forwarding VRF table including information to forward incoming packets to a central location within a hub and spoke environment. The medium also includes instructions for populating a routing Virtual Routing and Forwarding (VRF) table for the spoke router with routing information received from the hub and from ingress interfaces of the router and for propagating the routing information learned from the egress interfaces of the spoke router to the hub. The medium further includes instructions for forwarding packets received on ingress interfaces of the router according to the forwarding VRF table.
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 dynamic routing support for HDVRF
environments 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 dynamic routing support for HDVRF environments 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, California.
BRIEF DESCRIPTION OF THE DRAWINGS
The foregoing and other objects, features and advantages of the invention 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.
Figure 1 shows a generic environment for providing dynamic routing in a Half-Duplex Virtual Routing and Forwarding (HDVRF) system in accordance with embodiments of the present invention;
Figure 2 shows an example environment for providing dynamic routing in a Half-Duplex Virtual Routing and Forwarding (HDVRF) system in accordance with embodiments of the present invention;
Figure 3 comprises a flow diagram of a method for providing dynamic routing in Half-Duplex Virtual Routing and Forwarding (HDVRF) in accordance with embodiments of the present invention; and Figure 4 illustrates an example computer system architecture for a computer system that performs dynamic routing in Half-Duplex Virtual Routing and Forwarding (HDVRF) environments in accordance with embodiments of the present invention.
DETAILED DESCRIPTION
A method and apparatus for providing dynamic routing protocol support for half duplex virtual routing and forwarding environments includes a forwarding Virtual Routing and Forwarding (VRF) table for a spoke router configured with information to forward incoming packets to a central location within a hub and spoke environment. The spoke router also includes a routing Virtual Routing and Forwarding (VRF) table populated with routing information received from the hub and from ingress interfaces of the router.
The spoke router forwards packets received on ingress interfaces according to the forwarding VRF table. As such, any changes to the network topology are reflected appropriately in the routing VRF
table and the forwarding VRF table of the spoke router.
Referring now to Figure 1, a particular embodiment of an environment 10 that provides dynamic routing protocol support for half duplex virtual routing and forwarding systems is shown. The environment 10 includes a spoke Provider Edge (PE) router 16. The spoke PE router 16 is in communication on one side (the downstream side) with a first Customer Edge (CE) router 12 and a second CE router 14. First CE 12 is also in communication with a first network (Nl) 28. Second CE router 14 is also in communication with a second network (N2) 30. A dynamic routing protocol (e.g. OSPF) is running on the CE router 12, CE router 14 and spoke PE router 16.
The spoke PE router 16 is also in communication (on an upstream side) with a network 22. The network 22 may be, for example, a packet switched network such as an Internet Protocol (IP) network or a Multi-Protocol Label Switching (MPLS) network. The network 22 is in communication with a hub PE router 24, which is in communication with a hub CE router 26.
The spoke PE router 16 includes a forwarding Virtual Routing and Forwarding (VRF) table 18. The forwarding VRF table 18 is populated with information received from the hub (in this example, a default route using the hub PE router 24) and is used for forwarding packets received from the first or second CE routers 12 and 14 to a central location within a hub and spoke environment according to the forwarding VRF table 18.
The spoke PE router 16 also includes a routing Virtual Routing and Forwarding (VRF) table 20. The routing VRF table 20 is populated with routing information received from the hub and also with information received from the ingress interfaces of the spoke PE
router 16. As shown in Figure 1, in a particular embodiment, the routing VRF
table includes the gateway (CE1) for network N1 and the gateway (CE2) for network N2. Routing information learned from CE 12 and CE 14 is propagated to the hub so the hub can reach CE
12 and CE 14.
Referring now to Figure 2, an example of a particular embodiment of a second environment 10' is shown. The environment 10' includes a spoke Provider Edge (PE) router 16'. The spoke PE router 16' is in communication on one side (the downstream side) with a first Customer Edge (CE) router 12 and a second CE router 14. First CE 12 is also in communication with a first network (Ni) 28. Second CE router 14 is also in communication with a second network (N2) 30. A dynamic routing protocol is running on the CE
router 12, CE router 14 and spoke PE router 16'.
The spoke PE router 16' is also in communication (on an upstream side) with a network 22. The network 22 may be, for example, a packet switched network such as an Internet Protocol (IP) network or a Multi-Protocol Label Switching (MPLS) network. The network 22 is in communication with a hub PE router 24, which is in communication with a hub CE router 26.
The spoke PE router 16' includes a forwarding Virtual Routing and Forwarding (VRF) table 18'. The forwarding VRF table 18' is populated with information received from the hub (in this example, a default route using the hub PE router 24) and with addresses having a host mask of /32 for each attached client in order to prevent direct communication between CE 12 and CE 14. A mask identifies the portion of the address that is used for routing purposes, therefore with a mask of /32, all 32 bits of the address are used for routing purposes. The forwarding VRF is used for forwarding packets received from the first or second CE routers 12 and 14 to a central location within a hub and spoke environment according to the forwarding VRF table 18'.
The spoke PE router 16' also includes a routing Virtual Routing and Forwarding (VRF) table 20'. The routing VRF table 20' is populated with routing information received from the hub and also with information received from the ingress interfaces of the spoke PE
router 16'. As shown in Figure 2, in this particular embodiment, the routing VRF table includes the gateway (CE I) for network N 1 and the gateway (CE2) for network N2, and with addresses having a non-host mask (e.g. a mask of /24) for each attached client so the correct routing information is propagated through the network. A mask of /24 defines that the first 24 bits of the address are used for routing purposes. As a result, the PE-CE
session runs directly between the PE and CE, while any CE-to-CE traffic is forced to go via the hub. In such a manner, a dynamic routing protocol can be run on the spoke PE router 16', CE 12 and CE 14.
A flow chart of the presently disclosed method is depicted in Figure 3. The rectangular elements are herein denoted "processing blocks" and represent computer software instructions or groups of instructions. Alternatively, the processing and decision blocks represent steps performed by functionally equivalent circuits such as a digital signal processor circuit or an application specific integrated circuit (ASIC). The flow diagrams do not depict the syntax of any particular programming language. Rather, the flow diagrams illustrate the functional information one of ordinary skill in the art requires to fabricate circuits or to generate computer software to perform the processing required in accordance with the present invention. It should be noted that many routine program elements, such as initialization of loops and variables and the use of temporary variables are not shown. It will be appreciated by those of ordinary skill in the art that unless otherwise indicated herein, the particular sequence of steps described is illustrative only and can be varied without departing from the spirit of the invention. Thus, unless otherwise stated the steps described below are unordered meaning that, when possible, the steps can be performed in any convenient or desirable order.
Referring now to Figure 3 (in conjunction with Figures 1 and 2) a particular embodiment of a method 100 of providing dynamic routing support for Half-Duplex Virtual Routing and Forwarding (HDVRF) environments is shown. The method starts with processing block 102 which states configuring a forwarding Virtual Routing and Forwarding (VRF) table for a spoke PE router in a hub and spoke environment. The forwarding VRF
table includes information received from the hub, and is used to forward incoming packets to a central location within the hub and spoke environment.
Processing block 104 recites that the configuring of a forwarding VRF table includes configuring the forwarding VRF table with addresses having a host mask for each attached client, and that the host mask is a mask of /32. This is done in order to prevent direct communication between clients connected directly to the spoke router.
Processing block 106 discloses populating a routing Virtual Routing and Forwarding (VRF) table for the spoke router. The routing VRF table is populated with routing information received from the hub and from ingress interfaces of the spoke router.
As stated in processing block 108, the addresses received from ingress interfaces of the spoke router are provided with a non-host mask (for example, a mask of /24) for each attached client. As a result, a PE-CE session runs directly between the PE and CE, while any CE-to-CE traffic is forced to traverse a path including the hub.
Processing block 110 discloses propagating the routing information learned from ingress interfaces of the spoke router to the hub, while processing block 112 states forwarding packets received on ingress interfaces of the spoke router according to the forwarding VRF table.
In processing block 114 a dynamic routing protocol is run on the spoke router and on devices in communication with the ingress interfaces of the spoke router. By way of such a method, dynamic routing support for HDVRF environments is provided.
Figure 4 illustrates example architectures of a spoke router 240. In this example, the router 240 includes an interconnection mechanism 211 that couples a memory system 212, a processor 213, and a communications interface 214. The communications interface 214 allows the router 240 to communicate with external devices or systems.
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 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 router.
It is to be understood that the router operates as explained in former examples are represented in Figure 4 by the application 255-A and/or the process 255-B.
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 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. The computer readable medium can also include a communications link, either optical, wired, or wireless, having program code segments carried thereon as digital or analog signals. Accordingly, it is submitted that 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.
Forcing traffic to travel through a node that it otherwise would not have traveled serves multiple purposes. For example, a target-specific packet processing technique for monitoring data packet flows may be implemented at the second node (such as a node of an ISP network) to monitor an amount of traffic associated with a particular client. Thus, a service provider may identify how much to charge a client for transmitting data through the network. Additionally, a monitoring authority such as an agency may monitor contents of data packets at the second node to identify whether the network is being used for illicit purposes.
SUMMARY
Conventional mechanisms such as those explained above suffer from a variety of deficiencies. One such shortcoming is that conventional HDVRF cannot be used with a dynamic routing protocol such as Routing Information Protocol (RIP) or Open Shortest Path First (OSPF). With a dynamic routing protocol, routers learn about the topology of the network by communicating with other routers. Thus, if a router is moved, additional routers are added, or in the case where a router fails, the other routers learn about the change or failure and can adjust their routing tables accordingly. Since conventional HDVRF utilizes separate upstream and downstream routing tables for a router, a dynamic routing protocol cannot be used with conventional HDVRF. Accordingly, any changes to a network utilizing HDVRF must be manually entered into the upstream and downstream routing tables in order to provide proper network operation. This operation of manual entry of network changes can be time consuming, labor intensive and is prone to human error.
Embodiments of the invention significantly overcome such limitations and provide mechanisms and techniques that provide dynamic routing protocol support for HDVRF
environments. The routing protocols run completely in the downstream Virtual Routing and Forwarding (VRF) context, and have no knowledge of the upstream VRF. The connected interfaces are also in the downstream VRF in order to locally terminate packets destined for the router itself. The interface addresses with a /32 mask are injected into the upstream VRF
for the locally terminated packets, the context is switched to downstream so all the locally running applications and routing protocols receive the packets in the expected context.
In a particular embodiment, a method of providing dynamic routing support for Half-Duplex Virtual Routing and Forwarding (HDVRF) environments includes configuring a forwarding VRF table for a spoke router, wherein the forwarding VRF table includes information to forward incoming packets to a central location within a hub and spoke environment. The method also includes populating a routing Virtual Routing and Forwarding (VRF) table for the spoke router with routing information received from ingress interfaces of the spoke router. Packets received on ingress interfaces of the spoke router are forwarded according to the forwarding VRF table.
Other embodiments include a computer readable medium having computer readable code thereon for providing dynamic routing support for Half-Duplex Virtual Routing and Forwarding (HDVRF) environments. The medium includes instructions for configuring a forwarding Virtual Routing and Forwarding (VRF) table for a spoke router, the forwarding VRF table including information to forward incoming packets to a central location within a hub and spoke environment. The medium also includes instructions for populating a routing Virtual Routing and Forwarding (VRF) table for the spoke router with routing information received from the hub and from ingress interfaces of the router and for propagating the routing information learned from the egress interfaces of the spoke router to the hub. The medium further includes instructions for forwarding packets received on ingress interfaces of the router according to the forwarding VRF table.
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 dynamic routing support for HDVRF
environments 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 dynamic routing support for HDVRF environments 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, California.
BRIEF DESCRIPTION OF THE DRAWINGS
The foregoing and other objects, features and advantages of the invention 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.
Figure 1 shows a generic environment for providing dynamic routing in a Half-Duplex Virtual Routing and Forwarding (HDVRF) system in accordance with embodiments of the present invention;
Figure 2 shows an example environment for providing dynamic routing in a Half-Duplex Virtual Routing and Forwarding (HDVRF) system in accordance with embodiments of the present invention;
Figure 3 comprises a flow diagram of a method for providing dynamic routing in Half-Duplex Virtual Routing and Forwarding (HDVRF) in accordance with embodiments of the present invention; and Figure 4 illustrates an example computer system architecture for a computer system that performs dynamic routing in Half-Duplex Virtual Routing and Forwarding (HDVRF) environments in accordance with embodiments of the present invention.
DETAILED DESCRIPTION
A method and apparatus for providing dynamic routing protocol support for half duplex virtual routing and forwarding environments includes a forwarding Virtual Routing and Forwarding (VRF) table for a spoke router configured with information to forward incoming packets to a central location within a hub and spoke environment. The spoke router also includes a routing Virtual Routing and Forwarding (VRF) table populated with routing information received from the hub and from ingress interfaces of the router.
The spoke router forwards packets received on ingress interfaces according to the forwarding VRF table. As such, any changes to the network topology are reflected appropriately in the routing VRF
table and the forwarding VRF table of the spoke router.
Referring now to Figure 1, a particular embodiment of an environment 10 that provides dynamic routing protocol support for half duplex virtual routing and forwarding systems is shown. The environment 10 includes a spoke Provider Edge (PE) router 16. The spoke PE router 16 is in communication on one side (the downstream side) with a first Customer Edge (CE) router 12 and a second CE router 14. First CE 12 is also in communication with a first network (Nl) 28. Second CE router 14 is also in communication with a second network (N2) 30. A dynamic routing protocol (e.g. OSPF) is running on the CE router 12, CE router 14 and spoke PE router 16.
The spoke PE router 16 is also in communication (on an upstream side) with a network 22. The network 22 may be, for example, a packet switched network such as an Internet Protocol (IP) network or a Multi-Protocol Label Switching (MPLS) network. The network 22 is in communication with a hub PE router 24, which is in communication with a hub CE router 26.
The spoke PE router 16 includes a forwarding Virtual Routing and Forwarding (VRF) table 18. The forwarding VRF table 18 is populated with information received from the hub (in this example, a default route using the hub PE router 24) and is used for forwarding packets received from the first or second CE routers 12 and 14 to a central location within a hub and spoke environment according to the forwarding VRF table 18.
The spoke PE router 16 also includes a routing Virtual Routing and Forwarding (VRF) table 20. The routing VRF table 20 is populated with routing information received from the hub and also with information received from the ingress interfaces of the spoke PE
router 16. As shown in Figure 1, in a particular embodiment, the routing VRF
table includes the gateway (CE1) for network N1 and the gateway (CE2) for network N2. Routing information learned from CE 12 and CE 14 is propagated to the hub so the hub can reach CE
12 and CE 14.
Referring now to Figure 2, an example of a particular embodiment of a second environment 10' is shown. The environment 10' includes a spoke Provider Edge (PE) router 16'. The spoke PE router 16' is in communication on one side (the downstream side) with a first Customer Edge (CE) router 12 and a second CE router 14. First CE 12 is also in communication with a first network (Ni) 28. Second CE router 14 is also in communication with a second network (N2) 30. A dynamic routing protocol is running on the CE
router 12, CE router 14 and spoke PE router 16'.
The spoke PE router 16' is also in communication (on an upstream side) with a network 22. The network 22 may be, for example, a packet switched network such as an Internet Protocol (IP) network or a Multi-Protocol Label Switching (MPLS) network. The network 22 is in communication with a hub PE router 24, which is in communication with a hub CE router 26.
The spoke PE router 16' includes a forwarding Virtual Routing and Forwarding (VRF) table 18'. The forwarding VRF table 18' is populated with information received from the hub (in this example, a default route using the hub PE router 24) and with addresses having a host mask of /32 for each attached client in order to prevent direct communication between CE 12 and CE 14. A mask identifies the portion of the address that is used for routing purposes, therefore with a mask of /32, all 32 bits of the address are used for routing purposes. The forwarding VRF is used for forwarding packets received from the first or second CE routers 12 and 14 to a central location within a hub and spoke environment according to the forwarding VRF table 18'.
The spoke PE router 16' also includes a routing Virtual Routing and Forwarding (VRF) table 20'. The routing VRF table 20' is populated with routing information received from the hub and also with information received from the ingress interfaces of the spoke PE
router 16'. As shown in Figure 2, in this particular embodiment, the routing VRF table includes the gateway (CE I) for network N 1 and the gateway (CE2) for network N2, and with addresses having a non-host mask (e.g. a mask of /24) for each attached client so the correct routing information is propagated through the network. A mask of /24 defines that the first 24 bits of the address are used for routing purposes. As a result, the PE-CE
session runs directly between the PE and CE, while any CE-to-CE traffic is forced to go via the hub. In such a manner, a dynamic routing protocol can be run on the spoke PE router 16', CE 12 and CE 14.
A flow chart of the presently disclosed method is depicted in Figure 3. The rectangular elements are herein denoted "processing blocks" and represent computer software instructions or groups of instructions. Alternatively, the processing and decision blocks represent steps performed by functionally equivalent circuits such as a digital signal processor circuit or an application specific integrated circuit (ASIC). The flow diagrams do not depict the syntax of any particular programming language. Rather, the flow diagrams illustrate the functional information one of ordinary skill in the art requires to fabricate circuits or to generate computer software to perform the processing required in accordance with the present invention. It should be noted that many routine program elements, such as initialization of loops and variables and the use of temporary variables are not shown. It will be appreciated by those of ordinary skill in the art that unless otherwise indicated herein, the particular sequence of steps described is illustrative only and can be varied without departing from the spirit of the invention. Thus, unless otherwise stated the steps described below are unordered meaning that, when possible, the steps can be performed in any convenient or desirable order.
Referring now to Figure 3 (in conjunction with Figures 1 and 2) a particular embodiment of a method 100 of providing dynamic routing support for Half-Duplex Virtual Routing and Forwarding (HDVRF) environments is shown. The method starts with processing block 102 which states configuring a forwarding Virtual Routing and Forwarding (VRF) table for a spoke PE router in a hub and spoke environment. The forwarding VRF
table includes information received from the hub, and is used to forward incoming packets to a central location within the hub and spoke environment.
Processing block 104 recites that the configuring of a forwarding VRF table includes configuring the forwarding VRF table with addresses having a host mask for each attached client, and that the host mask is a mask of /32. This is done in order to prevent direct communication between clients connected directly to the spoke router.
Processing block 106 discloses populating a routing Virtual Routing and Forwarding (VRF) table for the spoke router. The routing VRF table is populated with routing information received from the hub and from ingress interfaces of the spoke router.
As stated in processing block 108, the addresses received from ingress interfaces of the spoke router are provided with a non-host mask (for example, a mask of /24) for each attached client. As a result, a PE-CE session runs directly between the PE and CE, while any CE-to-CE traffic is forced to traverse a path including the hub.
Processing block 110 discloses propagating the routing information learned from ingress interfaces of the spoke router to the hub, while processing block 112 states forwarding packets received on ingress interfaces of the spoke router according to the forwarding VRF table.
In processing block 114 a dynamic routing protocol is run on the spoke router and on devices in communication with the ingress interfaces of the spoke router. By way of such a method, dynamic routing support for HDVRF environments is provided.
Figure 4 illustrates example architectures of a spoke router 240. In this example, the router 240 includes an interconnection mechanism 211 that couples a memory system 212, a processor 213, and a communications interface 214. The communications interface 214 allows the router 240 to communicate with external devices or systems.
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 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 router.
It is to be understood that the router operates as explained in former examples are represented in Figure 4 by the application 255-A and/or the process 255-B.
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 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. The computer readable medium can also include a communications link, either optical, wired, or wireless, having program code segments carried thereon as digital or analog signals. Accordingly, it is submitted that 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.
Claims (27)
1. A method of providing dynamic routing support for Half-Duplex Virtual Routing and Forwarding (HDVRF) environments comprising:
configuring a forwarding Virtual Routing and Forwarding (VRF) table for a spoke router in a hub and spoke environment, said forwarding VRF table including information received from the hub, said forwarding VRF table used to forward incoming packets to a central location within the hub and spoke environment;
populating a routing VRF table for said spoke router, said routing VRF table populated with routing information received from the hub and from ingress interfaces of said spoke router;
propagating the routing information learned from ingress interfaces of said spoke router to the hub; and forwarding packets received on at least one ingress interface of said plurality of ingress interfaces of said spoke router according to said forwarding VRF
table.
configuring a forwarding Virtual Routing and Forwarding (VRF) table for a spoke router in a hub and spoke environment, said forwarding VRF table including information received from the hub, said forwarding VRF table used to forward incoming packets to a central location within the hub and spoke environment;
populating a routing VRF table for said spoke router, said routing VRF table populated with routing information received from the hub and from ingress interfaces of said spoke router;
propagating the routing information learned from ingress interfaces of said spoke router to the hub; and forwarding packets received on at least one ingress interface of said plurality of ingress interfaces of said spoke router according to said forwarding VRF
table.
2. The method of claim 1 further comprising running a dynamic routing protocol on said spoke router and on devices in communication with the ingress interfaces of said spoke router.
3. The method of claim 1 wherein said configuring a forwarding VRF table includes configuring said forwarding VRF table with addresses having a host mask for each attached client.
4. The method of claim 1 wherein said populating said routing Virtual Routing and Forwarding (VRF) table includes populating said routing VRF table with addresses having a non-host mask for each attached client.
5. The method of claim 3 wherein said host mask comprises a mask of /32.
6. The method of claim 4 wherein said non-host mask comprises a mask of /24.
7. The method of claim 1 wherein said spoke router comprises a Provider Edge (PE) router.
8. A method of providing dynamic routing support for Half-Duplex Virtual Routing and Forwarding (HDVRF) environments comprising:
configuring a forwarding Virtual Routing and Forwarding (VRF) table for a Provider Edge (PE) spoke router with addresses having a host mask of /32 for addresses learned from a spoke of a hub and spoke environment, said forwarding VRF table including information used to forward incoming packets to a central location within the hub and spoke environment;
populating a routing VRF table for said spoke router with addresses received from ingress interfaces of said spoke router, and with addresses learned from the hub and wherein addresses received from ingress interfaces are provided with a non-host mask for each attached client;
propagating the routing information learned from the ingress interfaces of said spoke router to the hub; and forwarding packets received on at least one ingress interface of said plurality of ingress interfaces of said spoke router according to said forwarding VRF
table.
configuring a forwarding Virtual Routing and Forwarding (VRF) table for a Provider Edge (PE) spoke router with addresses having a host mask of /32 for addresses learned from a spoke of a hub and spoke environment, said forwarding VRF table including information used to forward incoming packets to a central location within the hub and spoke environment;
populating a routing VRF table for said spoke router with addresses received from ingress interfaces of said spoke router, and with addresses learned from the hub and wherein addresses received from ingress interfaces are provided with a non-host mask for each attached client;
propagating the routing information learned from the ingress interfaces of said spoke router to the hub; and forwarding packets received on at least one ingress interface of said plurality of ingress interfaces of said spoke router according to said forwarding VRF
table.
9. A computer readable medium having stored thereon computer readable instructions for providing dynamic routing support for Half-Duplex Virtual Routing and Forwarding (HDVRF) environments, the instructions, when executed by a processor, configured to implement the steps of:
configuring a forwarding Virtual Routing and Forwarding (VRF) table for a spoke router in a hub and spoke environment, said forwarding VRF table including information received from the hub, said forwarding VRF table used to forward incoming packets to a central location within the hub and spoke environment;
populating a routing VRF table for said spoke router, said routing VRF table populated with routing information received from the hub and from ingress interfaces of said spoke router;
propagating the routing information learned from ingress interfaces of said spoke router to the hub; and forwarding packets received on at least one ingress interface of said plurality of ingress interfaces of said spoke router according to said forwarding VRF
table.
configuring a forwarding Virtual Routing and Forwarding (VRF) table for a spoke router in a hub and spoke environment, said forwarding VRF table including information received from the hub, said forwarding VRF table used to forward incoming packets to a central location within the hub and spoke environment;
populating a routing VRF table for said spoke router, said routing VRF table populated with routing information received from the hub and from ingress interfaces of said spoke router;
propagating the routing information learned from ingress interfaces of said spoke router to the hub; and forwarding packets received on at least one ingress interface of said plurality of ingress interfaces of said spoke router according to said forwarding VRF
table.
10. The computer readable medium of claim 9 further comprising instructions for running a dynamic routing protocol on said spoke router and on devices in communication with the ingress interfaces of said spoke router.
11. The computer readable medium of claim 9 wherein said instructions for configuring a forwarding VRF table includes instructions for configuring said forwarding VRF
table with addresses having a host mask for each attached client.
table with addresses having a host mask for each attached client.
12. The computer readable medium of claim 9 wherein said instructions for populating said routing Virtual Routing and Forwarding (VRF) table includes instructions for populating said routing VRF table with addresses having a non-host mask for each attached client.
13. The computer readable medium of claim 11 wherein said instructions for configuring said forwarding VRF table with addresses having a host mask for each attached client include instructions for configuring said forwarding VRF table with addresses having a host mask of /32 for each attached client.
14. The computer readable medium of claim 12 wherein said instructions for populating said routing Virtual Routing and Forwarding (VRF) table includes instructions for populating said routing VRF table with addresses having a non-host mask of /24.
15. A computer readable medium having stored thereon computer readable instructions for providing dynamic routing support for Half-Duplex Virtual Routing and Forwarding (HDVRF) environments, the instructions, when executed by a processor, configured to implement the steps of:
configuring a forwarding Virtual Routing and Forwarding (VRF) table for a Provider Edge (PE) spoke router with addresses having a host mask of /32 for addresses learned from a spoke of a hub and spoke environment, said forwarding VRF table including information used to forward incoming packets to a central location within the hub and spoke environment;
populating a routing VRF table for said spoke router with addresses received from ingress interfaces of said spoke router, and with addresses learned from the hub and wherein addresses received from ingress interfaces are provided with a non-host mask for each attached client;
propagating the routing information learned from the ingress interfaces of said spoke router to the hub; and forwarding packets received on at least one ingress interface of said plurality of ingress interfaces of said spoke router according to said forwarding VRF
table.
configuring a forwarding Virtual Routing and Forwarding (VRF) table for a Provider Edge (PE) spoke router with addresses having a host mask of /32 for addresses learned from a spoke of a hub and spoke environment, said forwarding VRF table including information used to forward incoming packets to a central location within the hub and spoke environment;
populating a routing VRF table for said spoke router with addresses received from ingress interfaces of said spoke router, and with addresses learned from the hub and wherein addresses received from ingress interfaces are provided with a non-host mask for each attached client;
propagating the routing information learned from the ingress interfaces of said spoke router to the hub; and forwarding packets received on at least one ingress interface of said plurality of ingress interfaces of said spoke router according to said forwarding VRF
table.
16. A system providing dynamic routing support for Half-Duplex Virtual Routing and Forwarding (HDVRF) environments, comprising:
a network;
a spoke router in communication with said network, said spoke router including:
a forwarding Virtual Routing and Forwarding (VRF) table populated with routing information received from a hub; and a routing VRF table populated with routing information received from the hub and with information ingress interfaces of the spoke router; and at least one Customer Edge (CE) router in communication with said spoke router; and wherein said spoke router forwards packets received from said at least one CE
router to a central location within the hub and spoke environment according to said forwarding VRF
table.
a network;
a spoke router in communication with said network, said spoke router including:
a forwarding Virtual Routing and Forwarding (VRF) table populated with routing information received from a hub; and a routing VRF table populated with routing information received from the hub and with information ingress interfaces of the spoke router; and at least one Customer Edge (CE) router in communication with said spoke router; and wherein said spoke router forwards packets received from said at least one CE
router to a central location within the hub and spoke environment according to said forwarding VRF
table.
17. The system of claim 16 wherein a dynamic routing protocol is running on said spoke router and said at least one CE router in communication with said spoke router.
18. The system of claim 16 wherein said forwarding VRF table includes addresses having a host mask for each attached client.
19. The system of claim 16 wherein said forwarding VRF table includes addresses learned from the hub.
20. The system of claim 16 wherein said routing VRF table includes addresses having a non-host mask for each attached client.
21. The system of claim 18 wherein said host mask comprises a mask of /32.
22. The system of claim 20 wherein said non-host mask comprises a mask of /24.
23. A system providing dynamic routing support for Half-Duplex Virtual Routing and Forwarding (HDVRF) environments, comprising:
means for configuring a forwarding Virtual Routing and Forwarding (VRF) table for a spoke router in a hub and spoke environment, said forwarding VRF table including information received from the hub, said forwarding VRF table used to forward incoming packets to a central location within the hub and spoke environment;
means for populating a routing VRF table for said spoke router, said routing VRF
table populated with routing information received from the hub and from ingress interfaces of said spoke router;
means for propagating the routing information learned from ingress interfaces of said spoke router to the hub; and means for forwarding packets received on at least one ingress interface of said plurality of ingress interfaces of said spoke router according to said forwarding VRF table.
means for configuring a forwarding Virtual Routing and Forwarding (VRF) table for a spoke router in a hub and spoke environment, said forwarding VRF table including information received from the hub, said forwarding VRF table used to forward incoming packets to a central location within the hub and spoke environment;
means for populating a routing VRF table for said spoke router, said routing VRF
table populated with routing information received from the hub and from ingress interfaces of said spoke router;
means for propagating the routing information learned from ingress interfaces of said spoke router to the hub; and means for forwarding packets received on at least one ingress interface of said plurality of ingress interfaces of said spoke router according to said forwarding VRF table.
24. The system of claim 23 further comprising means for running a dynamic routing protocol on said spoke router and on devices in communication with the ingress interfaces of said spoke router.
25. The system of claim 23 wherein said means for configuring a forwarding VRF
table includes means for configuring said forwarding VRF table with addresses having a host mask for each attached client.
table includes means for configuring said forwarding VRF table with addresses having a host mask for each attached client.
26. The system of claim 23 wherein said means for populating said routing Virtual Routing and Forwarding (VRF) table includes means for populating said routing VRF table with addresses having a non-host mask for each attached client.
27. A system providing dynamic routing support for Half-Duplex Virtual Routing and Forwarding (HDVRF) environments, comprising:
means for configuring a forwarding Virtual Routing and Forwarding (VRF) table for a Provider Edge (PE) spoke router with addresses having a host mask of /32 for addresses learned from a spoke of a hub and spoke environment, said forwarding VRF table including information used to forward incoming packets to a central location within the hub and spoke environment;
means for populating a routing VRF table for said spoke router with addresses received from ingress interfaces of said spoke router, and with addresses learned from the hub and wherein addresses received from ingress interfaces are provided with a non-host mask for each attached client;
means for propagating the routing information learned from the ingress interfaces of said spoke router to the hub; and means for forwarding packets received on at least one ingress interface of said plurality of ingress interfaces of said spoke router according to said forwarding VRF table.
means for configuring a forwarding Virtual Routing and Forwarding (VRF) table for a Provider Edge (PE) spoke router with addresses having a host mask of /32 for addresses learned from a spoke of a hub and spoke environment, said forwarding VRF table including information used to forward incoming packets to a central location within the hub and spoke environment;
means for populating a routing VRF table for said spoke router with addresses received from ingress interfaces of said spoke router, and with addresses learned from the hub and wherein addresses received from ingress interfaces are provided with a non-host mask for each attached client;
means for propagating the routing information learned from the ingress interfaces of said spoke router to the hub; and means for forwarding packets received on at least one ingress interface of said plurality of ingress interfaces of said spoke router according to said forwarding VRF table.
Applications Claiming Priority (3)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US10/937,661 US7623535B2 (en) | 2004-09-09 | 2004-09-09 | Routing protocol support for half duplex virtual routing and forwarding instance |
| US10/937,661 | 2004-09-09 | ||
| PCT/US2005/031015 WO2006031443A2 (en) | 2004-09-09 | 2005-08-31 | Routing protocol support for half duplex virtual routing and forwarding instance |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CA2578954A1 CA2578954A1 (en) | 2006-03-23 |
| CA2578954C true CA2578954C (en) | 2011-02-22 |
Family
ID=35996087
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CA2578954A Expired - Fee Related CA2578954C (en) | 2004-09-09 | 2005-08-31 | Routing protocol support for half duplex virtual routing and forwarding instance |
Country Status (4)
| Country | Link |
|---|---|
| US (2) | US7623535B2 (en) |
| EP (1) | EP1787435B1 (en) |
| CA (1) | CA2578954C (en) |
| WO (1) | WO2006031443A2 (en) |
Families Citing this family (149)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US7643434B2 (en) * | 2004-09-30 | 2010-01-05 | Hewlett-Packard Development Company, L.P. | Method and system for managing network nodes which communicate via connectivity services of a service provider |
| US7602737B2 (en) * | 2006-03-01 | 2009-10-13 | Cisco Technology, Inc. | Methods and apparatus for providing an enhanced dynamic multipoint virtual private network architecture |
| US8432894B2 (en) | 2007-02-27 | 2013-04-30 | Alcatel Lucent | Asymmetrical forwarding in layer 3 IP VPNs |
| US20080298374A1 (en) * | 2007-06-04 | 2008-12-04 | At&T Knowledge Ventures, L.P. | Apparatus for monitoring network connectivity |
| US7804766B2 (en) * | 2007-11-16 | 2010-09-28 | At&T Intellectual Property Ii, L.P. | Devices, systems, and/or methods regarding virtual routing forwarding |
| US9456054B2 (en) * | 2008-05-16 | 2016-09-27 | Palo Alto Research Center Incorporated | Controlling the spread of interests and content in a content centric network |
| JP4931888B2 (en) * | 2008-09-29 | 2012-05-16 | アラクサラネットワークス株式会社 | Transfer device, transfer method, and computer program |
| US8923293B2 (en) | 2009-10-21 | 2014-12-30 | Palo Alto Research Center Incorporated | Adaptive multi-interface use for content networking |
| US8995446B2 (en) * | 2009-12-21 | 2015-03-31 | Cisco Technology, Inc. | Efficient generation of VPN-based BGP updates |
| KR102024930B1 (en) * | 2012-09-25 | 2019-09-24 | 삼성전자주식회사 | Source device, router and controlling method thereof |
| US9667536B2 (en) | 2012-10-16 | 2017-05-30 | Cisco Technology, Inc. | Network traffic shaping for Low power and Lossy Networks |
| US9280546B2 (en) | 2012-10-31 | 2016-03-08 | Palo Alto Research Center Incorporated | System and method for accessing digital content using a location-independent name |
| US9400800B2 (en) | 2012-11-19 | 2016-07-26 | Palo Alto Research Center Incorporated | Data transport by named content synchronization |
| US10430839B2 (en) | 2012-12-12 | 2019-10-01 | Cisco Technology, Inc. | Distributed advertisement insertion in content-centric networks |
| US9978025B2 (en) | 2013-03-20 | 2018-05-22 | Cisco Technology, Inc. | Ordered-element naming for name-based packet forwarding |
| US9935791B2 (en) | 2013-05-20 | 2018-04-03 | Cisco Technology, Inc. | Method and system for name resolution across heterogeneous architectures |
| US9185120B2 (en) | 2013-05-23 | 2015-11-10 | Palo Alto Research Center Incorporated | Method and system for mitigating interest flooding attacks in content-centric networks |
| US9444722B2 (en) | 2013-08-01 | 2016-09-13 | Palo Alto Research Center Incorporated | Method and apparatus for configuring routing paths in a custodian-based routing architecture |
| US9407549B2 (en) | 2013-10-29 | 2016-08-02 | Palo Alto Research Center Incorporated | System and method for hash-based forwarding of packets with hierarchically structured variable-length identifiers |
| US9276840B2 (en) | 2013-10-30 | 2016-03-01 | Palo Alto Research Center Incorporated | Interest messages with a payload for a named data network |
| US9282050B2 (en) | 2013-10-30 | 2016-03-08 | Palo Alto Research Center Incorporated | System and method for minimum path MTU discovery in content centric networks |
| US9401864B2 (en) | 2013-10-31 | 2016-07-26 | Palo Alto Research Center Incorporated | Express header for packets with hierarchically structured variable-length identifiers |
| US9311377B2 (en) | 2013-11-13 | 2016-04-12 | Palo Alto Research Center Incorporated | Method and apparatus for performing server handoff in a name-based content distribution system |
| US10129365B2 (en) | 2013-11-13 | 2018-11-13 | Cisco Technology, Inc. | Method and apparatus for pre-fetching remote content based on static and dynamic recommendations |
| US10101801B2 (en) | 2013-11-13 | 2018-10-16 | Cisco Technology, Inc. | Method and apparatus for prefetching content in a data stream |
| US9516061B2 (en) | 2013-11-26 | 2016-12-06 | Cisco Technology, Inc. | Smart virtual private network |
| US10089655B2 (en) | 2013-11-27 | 2018-10-02 | Cisco Technology, Inc. | Method and apparatus for scalable data broadcasting |
| US9503358B2 (en) | 2013-12-05 | 2016-11-22 | Palo Alto Research Center Incorporated | Distance-based routing in an information-centric network |
| US9379979B2 (en) | 2014-01-14 | 2016-06-28 | Palo Alto Research Center Incorporated | Method and apparatus for establishing a virtual interface for a set of mutual-listener devices |
| US10172068B2 (en) | 2014-01-22 | 2019-01-01 | Cisco Technology, Inc. | Service-oriented routing in software-defined MANETs |
| US10098051B2 (en) | 2014-01-22 | 2018-10-09 | Cisco Technology, Inc. | Gateways and routing in software-defined manets |
| US9374304B2 (en) | 2014-01-24 | 2016-06-21 | Palo Alto Research Center Incorporated | End-to end route tracing over a named-data network |
| US9954678B2 (en) | 2014-02-06 | 2018-04-24 | Cisco Technology, Inc. | Content-based transport security |
| US9531679B2 (en) | 2014-02-06 | 2016-12-27 | Palo Alto Research Center Incorporated | Content-based transport security for distributed producers |
| US9678998B2 (en) | 2014-02-28 | 2017-06-13 | Cisco Technology, Inc. | Content name resolution for information centric networking |
| US10089651B2 (en) | 2014-03-03 | 2018-10-02 | Cisco Technology, Inc. | Method and apparatus for streaming advertisements in a scalable data broadcasting system |
| US9836540B2 (en) | 2014-03-04 | 2017-12-05 | Cisco Technology, Inc. | System and method for direct storage access in a content-centric network |
| US9473405B2 (en) | 2014-03-10 | 2016-10-18 | Palo Alto Research Center Incorporated | Concurrent hashes and sub-hashes on data streams |
| US9391896B2 (en) | 2014-03-10 | 2016-07-12 | Palo Alto Research Center Incorporated | System and method for packet forwarding using a conjunctive normal form strategy in a content-centric network |
| US9626413B2 (en) | 2014-03-10 | 2017-04-18 | Cisco Systems, Inc. | System and method for ranking content popularity in a content-centric network |
| US9407432B2 (en) | 2014-03-19 | 2016-08-02 | Palo Alto Research Center Incorporated | System and method for efficient and secure distribution of digital content |
| US9916601B2 (en) | 2014-03-21 | 2018-03-13 | Cisco Technology, Inc. | Marketplace for presenting advertisements in a scalable data broadcasting system |
| US9363179B2 (en) | 2014-03-26 | 2016-06-07 | Palo Alto Research Center Incorporated | Multi-publisher routing protocol for named data networks |
| US9363086B2 (en) | 2014-03-31 | 2016-06-07 | Palo Alto Research Center Incorporated | Aggregate signing of data in content centric networking |
| US9716622B2 (en) | 2014-04-01 | 2017-07-25 | Cisco Technology, Inc. | System and method for dynamic name configuration in content-centric networks |
| US10075521B2 (en) | 2014-04-07 | 2018-09-11 | Cisco Technology, Inc. | Collection synchronization using equality matched network names |
| US9390289B2 (en) | 2014-04-07 | 2016-07-12 | Palo Alto Research Center Incorporated | Secure collection synchronization using matched network names |
| US9473576B2 (en) | 2014-04-07 | 2016-10-18 | Palo Alto Research Center Incorporated | Service discovery using collection synchronization with exact names |
| US9451032B2 (en) | 2014-04-10 | 2016-09-20 | Palo Alto Research Center Incorporated | System and method for simple service discovery in content-centric networks |
| US9203885B2 (en) | 2014-04-28 | 2015-12-01 | Palo Alto Research Center Incorporated | Method and apparatus for exchanging bidirectional streams over a content centric network |
| US9992281B2 (en) | 2014-05-01 | 2018-06-05 | Cisco Technology, Inc. | Accountable content stores for information centric networks |
| US9609014B2 (en) | 2014-05-22 | 2017-03-28 | Cisco Systems, Inc. | Method and apparatus for preventing insertion of malicious content at a named data network router |
| US9455835B2 (en) | 2014-05-23 | 2016-09-27 | Palo Alto Research Center Incorporated | System and method for circular link resolution with hash-based names in content-centric networks |
| US9276751B2 (en) | 2014-05-28 | 2016-03-01 | Palo Alto Research Center Incorporated | System and method for circular link resolution with computable hash-based names in content-centric networks |
| US9537719B2 (en) | 2014-06-19 | 2017-01-03 | Palo Alto Research Center Incorporated | Method and apparatus for deploying a minimal-cost CCN topology |
| US9467377B2 (en) | 2014-06-19 | 2016-10-11 | Palo Alto Research Center Incorporated | Associating consumer states with interests in a content-centric network |
| US9516144B2 (en) | 2014-06-19 | 2016-12-06 | Palo Alto Research Center Incorporated | Cut-through forwarding of CCNx message fragments with IP encapsulation |
| US9426113B2 (en) | 2014-06-30 | 2016-08-23 | Palo Alto Research Center Incorporated | System and method for managing devices over a content centric network |
| US9699198B2 (en) | 2014-07-07 | 2017-07-04 | Cisco Technology, Inc. | System and method for parallel secure content bootstrapping in content-centric networks |
| US9959156B2 (en) | 2014-07-17 | 2018-05-01 | Cisco Technology, Inc. | Interest return control message |
| US9621354B2 (en) | 2014-07-17 | 2017-04-11 | Cisco Systems, Inc. | Reconstructable content objects |
| US9729616B2 (en) | 2014-07-18 | 2017-08-08 | Cisco Technology, Inc. | Reputation-based strategy for forwarding and responding to interests over a content centric network |
| US9590887B2 (en) | 2014-07-18 | 2017-03-07 | Cisco Systems, Inc. | Method and system for keeping interest alive in a content centric network |
| US9535968B2 (en) | 2014-07-21 | 2017-01-03 | Palo Alto Research Center Incorporated | System for distributing nameless objects using self-certifying names |
| US9882964B2 (en) | 2014-08-08 | 2018-01-30 | Cisco Technology, Inc. | Explicit strategy feedback in name-based forwarding |
| US9503365B2 (en) | 2014-08-11 | 2016-11-22 | Palo Alto Research Center Incorporated | Reputation-based instruction processing over an information centric network |
| US9729662B2 (en) | 2014-08-11 | 2017-08-08 | Cisco Technology, Inc. | Probabilistic lazy-forwarding technique without validation in a content centric network |
| CN105337855B (en) * | 2014-08-14 | 2019-02-05 | 华为技术有限公司 | A kind of modified message method and apparatus of processing |
| US9391777B2 (en) | 2014-08-15 | 2016-07-12 | Palo Alto Research Center Incorporated | System and method for performing key resolution over a content centric network |
| US9800637B2 (en) | 2014-08-19 | 2017-10-24 | Cisco Technology, Inc. | System and method for all-in-one content stream in content-centric networks |
| US9467492B2 (en) | 2014-08-19 | 2016-10-11 | Palo Alto Research Center Incorporated | System and method for reconstructable all-in-one content stream |
| US9497282B2 (en) | 2014-08-27 | 2016-11-15 | Palo Alto Research Center Incorporated | Network coding for content-centric network |
| US10204013B2 (en) | 2014-09-03 | 2019-02-12 | Cisco Technology, Inc. | System and method for maintaining a distributed and fault-tolerant state over an information centric network |
| US9553812B2 (en) | 2014-09-09 | 2017-01-24 | Palo Alto Research Center Incorporated | Interest keep alives at intermediate routers in a CCN |
| US10069933B2 (en) | 2014-10-23 | 2018-09-04 | Cisco Technology, Inc. | System and method for creating virtual interfaces based on network characteristics |
| CN104394079B (en) * | 2014-11-26 | 2017-07-04 | 迈普通信技术股份有限公司 | A kind of next-hop route detecting method and device based on Border Gateway Protocol |
| US9536059B2 (en) | 2014-12-15 | 2017-01-03 | Palo Alto Research Center Incorporated | Method and system for verifying renamed content using manifests in a content centric network |
| US9590948B2 (en) | 2014-12-15 | 2017-03-07 | Cisco Systems, Inc. | CCN routing using hardware-assisted hash tables |
| US10237189B2 (en) | 2014-12-16 | 2019-03-19 | Cisco Technology, Inc. | System and method for distance-based interest forwarding |
| US9846881B2 (en) | 2014-12-19 | 2017-12-19 | Palo Alto Research Center Incorporated | Frugal user engagement help systems |
| US10003520B2 (en) | 2014-12-22 | 2018-06-19 | Cisco Technology, Inc. | System and method for efficient name-based content routing using link-state information in information-centric networks |
| US9473475B2 (en) | 2014-12-22 | 2016-10-18 | Palo Alto Research Center Incorporated | Low-cost authenticated signing delegation in content centric networking |
| US9660825B2 (en) | 2014-12-24 | 2017-05-23 | Cisco Technology, Inc. | System and method for multi-source multicasting in content-centric networks |
| US9946743B2 (en) | 2015-01-12 | 2018-04-17 | Cisco Technology, Inc. | Order encoded manifests in a content centric network |
| US9916457B2 (en) | 2015-01-12 | 2018-03-13 | Cisco Technology, Inc. | Decoupled name security binding for CCN objects |
| US9954795B2 (en) | 2015-01-12 | 2018-04-24 | Cisco Technology, Inc. | Resource allocation using CCN manifests |
| US9602596B2 (en) | 2015-01-12 | 2017-03-21 | Cisco Systems, Inc. | Peer-to-peer sharing in a content centric network |
| US9832291B2 (en) | 2015-01-12 | 2017-11-28 | Cisco Technology, Inc. | Auto-configurable transport stack |
| US9462006B2 (en) | 2015-01-21 | 2016-10-04 | Palo Alto Research Center Incorporated | Network-layer application-specific trust model |
| US9552493B2 (en) | 2015-02-03 | 2017-01-24 | Palo Alto Research Center Incorporated | Access control framework for information centric networking |
| US10333840B2 (en) | 2015-02-06 | 2019-06-25 | Cisco Technology, Inc. | System and method for on-demand content exchange with adaptive naming in information-centric networks |
| CN104683187B (en) * | 2015-03-12 | 2018-01-02 | 烽火通信科技股份有限公司 | A kind of method for realizing router two-layer VPN business physical interface end-to-end measurement |
| US10075401B2 (en) | 2015-03-18 | 2018-09-11 | Cisco Technology, Inc. | Pending interest table behavior |
| US10116605B2 (en) | 2015-06-22 | 2018-10-30 | Cisco Technology, Inc. | Transport stack name scheme and identity management |
| US10075402B2 (en) | 2015-06-24 | 2018-09-11 | Cisco Technology, Inc. | Flexible command and control in content centric networks |
| US9998428B2 (en) | 2015-06-29 | 2018-06-12 | Cisco Technology, Inc. | Virtual routing and forwarding (VRF) for asymmetrical virtual service provider (VSP) tunnels |
| US10701038B2 (en) | 2015-07-27 | 2020-06-30 | Cisco Technology, Inc. | Content negotiation in a content centric network |
| US9986034B2 (en) | 2015-08-03 | 2018-05-29 | Cisco Technology, Inc. | Transferring state in content centric network stacks |
| US10610144B2 (en) | 2015-08-19 | 2020-04-07 | Palo Alto Research Center Incorporated | Interactive remote patient monitoring and condition management intervention system |
| US9832123B2 (en) | 2015-09-11 | 2017-11-28 | Cisco Technology, Inc. | Network named fragments in a content centric network |
| US10355999B2 (en) | 2015-09-23 | 2019-07-16 | Cisco Technology, Inc. | Flow control with network named fragments |
| US10313227B2 (en) | 2015-09-24 | 2019-06-04 | Cisco Technology, Inc. | System and method for eliminating undetected interest looping in information-centric networks |
| US9977809B2 (en) | 2015-09-24 | 2018-05-22 | Cisco Technology, Inc. | Information and data framework in a content centric network |
| US10454820B2 (en) | 2015-09-29 | 2019-10-22 | Cisco Technology, Inc. | System and method for stateless information-centric networking |
| US10263965B2 (en) | 2015-10-16 | 2019-04-16 | Cisco Technology, Inc. | Encrypted CCNx |
| US9794238B2 (en) | 2015-10-29 | 2017-10-17 | Cisco Technology, Inc. | System for key exchange in a content centric network |
| US9807205B2 (en) | 2015-11-02 | 2017-10-31 | Cisco Technology, Inc. | Header compression for CCN messages using dictionary |
| US10009446B2 (en) | 2015-11-02 | 2018-06-26 | Cisco Technology, Inc. | Header compression for CCN messages using dictionary learning |
| US10021222B2 (en) | 2015-11-04 | 2018-07-10 | Cisco Technology, Inc. | Bit-aligned header compression for CCN messages using dictionary |
| US10097521B2 (en) | 2015-11-20 | 2018-10-09 | Cisco Technology, Inc. | Transparent encryption in a content centric network |
| US9912776B2 (en) | 2015-12-02 | 2018-03-06 | Cisco Technology, Inc. | Explicit content deletion commands in a content centric network |
| US10097346B2 (en) | 2015-12-09 | 2018-10-09 | Cisco Technology, Inc. | Key catalogs in a content centric network |
| US10078062B2 (en) | 2015-12-15 | 2018-09-18 | Palo Alto Research Center Incorporated | Device health estimation by combining contextual information with sensor data |
| US10257271B2 (en) | 2016-01-11 | 2019-04-09 | Cisco Technology, Inc. | Chandra-Toueg consensus in a content centric network |
| US9949301B2 (en) | 2016-01-20 | 2018-04-17 | Palo Alto Research Center Incorporated | Methods for fast, secure and privacy-friendly internet connection discovery in wireless networks |
| US10305864B2 (en) | 2016-01-25 | 2019-05-28 | Cisco Technology, Inc. | Method and system for interest encryption in a content centric network |
| US10043016B2 (en) | 2016-02-29 | 2018-08-07 | Cisco Technology, Inc. | Method and system for name encryption agreement in a content centric network |
| US10051071B2 (en) | 2016-03-04 | 2018-08-14 | Cisco Technology, Inc. | Method and system for collecting historical network information in a content centric network |
| US10003507B2 (en) | 2016-03-04 | 2018-06-19 | Cisco Technology, Inc. | Transport session state protocol |
| US10742596B2 (en) | 2016-03-04 | 2020-08-11 | Cisco Technology, Inc. | Method and system for reducing a collision probability of hash-based names using a publisher identifier |
| US10038633B2 (en) | 2016-03-04 | 2018-07-31 | Cisco Technology, Inc. | Protocol to query for historical network information in a content centric network |
| US9832116B2 (en) | 2016-03-14 | 2017-11-28 | Cisco Technology, Inc. | Adjusting entries in a forwarding information base in a content centric network |
| US10212196B2 (en) | 2016-03-16 | 2019-02-19 | Cisco Technology, Inc. | Interface discovery and authentication in a name-based network |
| US10067948B2 (en) | 2016-03-18 | 2018-09-04 | Cisco Technology, Inc. | Data deduping in content centric networking manifests |
| US11436656B2 (en) | 2016-03-18 | 2022-09-06 | Palo Alto Research Center Incorporated | System and method for a real-time egocentric collaborative filter on large datasets |
| US10091330B2 (en) | 2016-03-23 | 2018-10-02 | Cisco Technology, Inc. | Interest scheduling by an information and data framework in a content centric network |
| US10033639B2 (en) | 2016-03-25 | 2018-07-24 | Cisco Technology, Inc. | System and method for routing packets in a content centric network using anonymous datagrams |
| US10320760B2 (en) | 2016-04-01 | 2019-06-11 | Cisco Technology, Inc. | Method and system for mutating and caching content in a content centric network |
| US9930146B2 (en) | 2016-04-04 | 2018-03-27 | Cisco Technology, Inc. | System and method for compressing content centric networking messages |
| US10425503B2 (en) | 2016-04-07 | 2019-09-24 | Cisco Technology, Inc. | Shared pending interest table in a content centric network |
| US10027578B2 (en) | 2016-04-11 | 2018-07-17 | Cisco Technology, Inc. | Method and system for routable prefix queries in a content centric network |
| US10404450B2 (en) | 2016-05-02 | 2019-09-03 | Cisco Technology, Inc. | Schematized access control in a content centric network |
| US10320675B2 (en) | 2016-05-04 | 2019-06-11 | Cisco Technology, Inc. | System and method for routing packets in a stateless content centric network |
| US10547589B2 (en) | 2016-05-09 | 2020-01-28 | Cisco Technology, Inc. | System for implementing a small computer systems interface protocol over a content centric network |
| US10084764B2 (en) | 2016-05-13 | 2018-09-25 | Cisco Technology, Inc. | System for a secure encryption proxy in a content centric network |
| US10063414B2 (en) | 2016-05-13 | 2018-08-28 | Cisco Technology, Inc. | Updating a transport stack in a content centric network |
| US10103989B2 (en) | 2016-06-13 | 2018-10-16 | Cisco Technology, Inc. | Content object return messages in a content centric network |
| US10305865B2 (en) | 2016-06-21 | 2019-05-28 | Cisco Technology, Inc. | Permutation-based content encryption with manifests in a content centric network |
| US10148572B2 (en) | 2016-06-27 | 2018-12-04 | Cisco Technology, Inc. | Method and system for interest groups in a content centric network |
| US10009266B2 (en) | 2016-07-05 | 2018-06-26 | Cisco Technology, Inc. | Method and system for reference counted pending interest tables in a content centric network |
| US9992097B2 (en) | 2016-07-11 | 2018-06-05 | Cisco Technology, Inc. | System and method for piggybacking routing information in interests in a content centric network |
| US10122624B2 (en) | 2016-07-25 | 2018-11-06 | Cisco Technology, Inc. | System and method for ephemeral entries in a forwarding information base in a content centric network |
| US10069729B2 (en) | 2016-08-08 | 2018-09-04 | Cisco Technology, Inc. | System and method for throttling traffic based on a forwarding information base in a content centric network |
| US10956412B2 (en) | 2016-08-09 | 2021-03-23 | Cisco Technology, Inc. | Method and system for conjunctive normal form attribute matching in a content centric network |
| US10033642B2 (en) | 2016-09-19 | 2018-07-24 | Cisco Technology, Inc. | System and method for making optimal routing decisions based on device-specific parameters in a content centric network |
| US10212248B2 (en) | 2016-10-03 | 2019-02-19 | Cisco Technology, Inc. | Cache management on high availability routers in a content centric network |
| US10447805B2 (en) | 2016-10-10 | 2019-10-15 | Cisco Technology, Inc. | Distributed consensus in a content centric network |
| US10135948B2 (en) | 2016-10-31 | 2018-11-20 | Cisco Technology, Inc. | System and method for process migration in a content centric network |
| US10243851B2 (en) | 2016-11-21 | 2019-03-26 | Cisco Technology, Inc. | System and method for forwarder connection information in a content centric network |
Family Cites Families (36)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5515376A (en) | 1993-07-19 | 1996-05-07 | Alantec, Inc. | Communication apparatus and methods |
| US6009081A (en) | 1997-09-03 | 1999-12-28 | Internap Network Services | Private network access point router for interconnecting among internet route providers |
| US6339595B1 (en) | 1997-12-23 | 2002-01-15 | Cisco Technology, Inc. | Peer-model support for virtual private networks with potentially overlapping addresses |
| US6081508A (en) | 1998-02-25 | 2000-06-27 | Indus River Networks, Inc. | Remote computer communication |
| CA2239032A1 (en) | 1998-05-28 | 1999-11-28 | Newbridge Networks Corporation | Operator directed routing of soft permanent virtual circuits in a connection-orientated network |
| US6310882B1 (en) * | 1999-01-27 | 2001-10-30 | 3Com Corporation | High speed switch architecture using separate transmit and receive channels with independent forwarding tables |
| US6680940B1 (en) | 1999-05-19 | 2004-01-20 | 3Com Corporation | System for transporting ethernet frames over very high speed digital subscriber lines |
| US6724881B1 (en) | 1999-05-27 | 2004-04-20 | Alcatel Canada Inc. | Optimization of connection paths in a communications network |
| US6574224B1 (en) | 1999-07-02 | 2003-06-03 | Nortel Networks Limited | Processing communication traffic |
| US6680943B1 (en) | 1999-10-01 | 2004-01-20 | Nortel Networks Limited | Establishing bi-directional communication sessions across a communications network |
| US6683865B1 (en) | 1999-10-15 | 2004-01-27 | Nokia Wireless Routers, Inc. | System for routing and switching in computer networks |
| US6640239B1 (en) | 1999-11-10 | 2003-10-28 | Garuda Network Corporation | Apparatus and method for intelligent scalable switching network |
| JP3994614B2 (en) | 2000-03-13 | 2007-10-24 | 株式会社日立製作所 | Packet switch, network monitoring system, and network monitoring method |
| JP2002027340A (en) * | 2000-07-03 | 2002-01-25 | Alps Electric Co Ltd | Television tuner and visual instrument containing the same |
| US8385342B2 (en) | 2001-05-31 | 2013-02-26 | Fujitsu Limited | System and method of virtual private network route target filtering |
| US7152115B2 (en) | 2001-07-12 | 2006-12-19 | Nortel Networks Limited | Virtual private networks |
| US7221675B2 (en) * | 2001-12-07 | 2007-05-22 | Nortel Networks Limited | Address resolution method for a virtual private network, and customer edge device for implementing the method |
| SE0200640D0 (en) | 2002-02-28 | 2002-02-28 | Ericsson Telefon Ab L M | Arrangement and method for routing in virtual private network |
| US7116665B2 (en) * | 2002-06-04 | 2006-10-03 | Fortinet, Inc. | Methods and systems for a distributed provider edge |
| US7468956B1 (en) * | 2002-08-16 | 2008-12-23 | Juniper Networks, Inc. | Managing routing information in a hub-and-spokes network |
| FR2844415B1 (en) | 2002-09-05 | 2005-02-11 | At & T Corp | FIREWALL SYSTEM FOR INTERCONNECTING TWO IP NETWORKS MANAGED BY TWO DIFFERENT ADMINISTRATIVE ENTITIES |
| FR2846169B1 (en) * | 2002-10-22 | 2005-02-04 | At & T Corp | PRIVATE VIRTUAL NETWORK BASED ON THE LABEL PERMUTATION PROCEDURE (MPLS) ADAPTED TO MEASURE TRAFFIC EXCHANGE BETWEEN SINGLE TARIFF ZONES |
| US7965717B2 (en) | 2003-01-17 | 2011-06-21 | Nortel Networks Limited | Multi-staged services policing |
| CN1323522C (en) * | 2003-01-22 | 2007-06-27 | 华为技术有限公司 | Method for determining relation between routers at fringe of client site and virtual private network |
| US20040177157A1 (en) * | 2003-02-13 | 2004-09-09 | Nortel Networks Limited | Logical grouping of VPN tunnels |
| US7619966B2 (en) * | 2003-02-21 | 2009-11-17 | Alcatel Lucent | Hybrid virtual private LAN extensions |
| US7486659B1 (en) * | 2003-02-24 | 2009-02-03 | Nortel Networks Limited | Method and apparatus for exchanging routing information between virtual private network sites |
| US7313605B2 (en) | 2003-07-03 | 2007-12-25 | At&T Corp. | Externally controlled reachability in virtual private networks |
| US7075933B2 (en) | 2003-08-01 | 2006-07-11 | Nortel Networks, Ltd. | Method and apparatus for implementing hub-and-spoke topology virtual private networks |
| US7441023B2 (en) * | 2003-09-25 | 2008-10-21 | Emc Corporation | Method and apparatus for modeling and analyzing MPLS and virtual private networks |
| US7698456B2 (en) | 2003-09-29 | 2010-04-13 | Cisco Technology, Inc. | Methods and apparatus to support routing of information |
| US7450598B2 (en) * | 2003-12-15 | 2008-11-11 | At&T Intellectual Property I, L.P. | System and method to provision MPLS/VPN network |
| US7756998B2 (en) * | 2004-02-11 | 2010-07-13 | Alcatel Lucent | Managing L3 VPN virtual routing tables |
| US20050265308A1 (en) * | 2004-05-07 | 2005-12-01 | Abdulkadev Barbir | Selection techniques for logical grouping of VPN tunnels |
| US7400611B2 (en) * | 2004-06-30 | 2008-07-15 | Lucent Technologies Inc. | Discovery of border gateway protocol (BGP) multi-protocol label switching (MPLS) virtual private networks (VPNs) |
| US7463584B2 (en) * | 2004-08-03 | 2008-12-09 | Nortel Networks Limited | System and method for hub and spoke virtual private network |
-
2004
- 2004-09-09 US US10/937,661 patent/US7623535B2/en not_active Expired - Fee Related
-
2005
- 2005-08-31 EP EP05795626.0A patent/EP1787435B1/en active Active
- 2005-08-31 CA CA2578954A patent/CA2578954C/en not_active Expired - Fee Related
- 2005-08-31 WO PCT/US2005/031015 patent/WO2006031443A2/en active Application Filing
-
2009
- 2009-11-19 US US12/621,834 patent/US7957408B2/en not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| US7957408B2 (en) | 2011-06-07 |
| WO2006031443A2 (en) | 2006-03-23 |
| EP1787435A4 (en) | 2015-01-28 |
| US20060050653A1 (en) | 2006-03-09 |
| EP1787435A2 (en) | 2007-05-23 |
| US20100061281A1 (en) | 2010-03-11 |
| WO2006031443A3 (en) | 2006-05-04 |
| CA2578954A1 (en) | 2006-03-23 |
| US7623535B2 (en) | 2009-11-24 |
| EP1787435B1 (en) | 2020-08-19 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CA2578954C (en) | Routing protocol support for half duplex virtual routing and forwarding instance | |
| US11134006B2 (en) | Loop conflict avoidance in a spine-and-leaf network topology | |
| US10454821B2 (en) | Creating and maintaining segment routed traffic engineering policies via border gateway protocol | |
| EP1678884B1 (en) | Method and apparatus for routing of information depending on the traffic direction | |
| US20050025069A1 (en) | Method and apparatus for implementing hub-and-spoke topology virtual private networks | |
| US7894430B2 (en) | Hub and spoke multicast model | |
| US11362954B2 (en) | Tunneling inter-domain stateless internet protocol multicast packets | |
| EP3697038A1 (en) | Support for multiple virtual networks over an underlay network topology | |
| US20090092140A1 (en) | Method and apparatus for providing a hierarchical structure for routing | |
| WO2009042050A1 (en) | Method and apparatus for providing a distributed forwarding plane for a mobility home agent | |
| US20240056359A1 (en) | Automated Scaling Of Network Topologies Using Unique Identifiers | |
| US11757928B2 (en) | Distributed denial-of-service mitigation |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| EEER | Examination request | ||
| MKLA | Lapsed |
Effective date: 20220301 |
|
| MKLA | Lapsed |
Effective date: 20200831 |