Network nodes forward packets using forwarding tables. Network nodes may take form in one or more routers, one or more bridges, one or more switches, one or more servers, or any other suitable communications processing device. A packet is a formatted unit of data that typically contains control information and payload data. Control information may include: source and destination IP addresses, error detection codes like checksums, sequencing information, etc. Control information is typically found in packet headers and trailers, with payload data in between.
Packet forwarding requires a decision process that, while simple in concept, can be complex. Since packet forwarding decisions are handled by nodes, the total time required for this can become a major limiting factor in overall network performance.
Multiprotocol Label Switching (MPLS) is one packet forwarding mechanism. MPLS Nodes make packet forwarding decisions based on Label Distribution Protocol (LDP) labels attached to packets and LDP forwarding tables. LDP is a process in which network nodes capable of MPLS exchange LDP labels (hereinafter labels). Packet forwarding based on labels stands in stark contrast to traditional Internet Protocol (IP) routing in which packet forwarding decisions are made by nodes using IP addresses contained within the packet.
1. Overview
An apparatus and method is disclosed for seamless segment routing (SR). In one embodiment, a packet and a segment ID stack is received at a node. The segment ID stack includes a plurality of segment IDs, one of which is a first area-segment ID that identifies a first area of a subdivided network. One of a plurality of forwarding tables at the node is selected based on the first area-segment ID. Thereafter, the packet is forwarded based on information contained in the selected forwarding table.
2. Packet Forwarding Mechanisms
IP routing and MPLS are distinct packet forwarding mechanisms. IP routing uses IP addresses inside packet headers to make packet forwarding decisions. In contrast, MPLS implements packet forwarding decisions based on short path identifiers called labels attached to packets. Segment routing (SR) is yet another packet forwarding mechanism. SR is similar to MPLS in many regards. For example, packet forwarding decisions in SR can be based on short path identifiers called segment IDs attached to packets. However, substantial differences exist between SR and MPLS as will be more fully described below.
2.1 IP Routing
IP routing uses IP forwarding tables, which are created at nodes using routing information distributed between nodes via one or more protocols like the internal gateway protocol (IGP) and/or the border gateway protocol (BGP). In simple terms, IP forwarding tables map destination addresses to the next hops that packets take to reach their destinations. When a node receives a packet, the node can access a forwarding table using the destination address in the packet and lookup a corresponding egress interface for the next hop. The node then forwards the packet through the egress interface. The next hop that receives the packet performs its own forwarding table lookup using the same destination IP address, and so on.
2.2 MPLS and LDP
MPLS is commonly employed in provider networks. Packets enter an MPLS network via an ingress edge node, travel hop-by-hop along a label-switched path (LSP) that typically includes one or more core nodes, and exit via an egress edge node.
Packets are forwarded along an LSP based on labels and LDP forwarding tables. Labels allow for the use of very fast and simple forwarding engines in the data plane of nodes. Another benefit of MPLS is the elimination of dependence on a particular Open Systems Interconnection (OSI) model data link layer technology to forward packets.
A label is a short, fixed-length, locally significant identifier that can be associated with a forwarding equivalence class (FEC). Packets associated with the same FEC should follow the same LSP through the network. LSPs can be established for a variety of purposes, such as to guarantee a certain level of performance when transmitting packets, to forward packets around network congestion, to create tunnels for network-based virtual private networks, etc. In many ways, LSPs are no different than circuit-switched paths in ATM or Frame Relay networks, except that they are not dependent on a particular Layer 2 technology.
LDP is employed in the control planes of nodes. Two nodes, called LDP peers, can bi-directionally exchange labels on a FEC by FEC basis. LDP can be used in a process of building and maintaining LDP forwarding tables that map labels and next hop egress interfaces. These forwarding tables can be used to forward packets through MPLS networks as more fully described below.
When a packet is received by an ingress edge node of an MPLS network, the ingress node may determine a corresponding FEC. Characteristics for determining the FEC for a packet can vary, but typically the determination is based on the packet's destination IP address. Quality of Service for the packet or other information may also be used to determine the FEC. Once determined, the ingress edge node can access a table to select a label that is mapped to the FEC. The table may also map a next hop egress interface to the FEC. Before the ingress edge node forwards the packet to the next hop via, the ingress node attaches the label.
When a node receives a packet with an attached label (i.e., the incoming label), the node accesses an LDP forwarding table to read a next hop egress interface and another label (i.e., an outgoing label), both which are mapped to the incoming label. Before the packet is forwarded via the egress interface, the node swaps the incoming label with the outgoing label. The next hop receives the packet with label and may perform the same process. This process is often called hop-by-hop forwarding along a non-explicit path. The penultimate node in the LSP may pop or remove the incoming label before forwarding the packet to an egress edge node in the network, which in turn may forward the packet towards its destination using the packet's destination address and an IP forwarding table. To illustrate MPLS aspects,
2.3 Segment Routing
Segment routing (SR) is a mechanism in which nodes forward packets using SR forwarding tables and segment IDs. Like MPLS, SR enables very fast and simple forwarding engines in the data plane of nodes. SR is not dependent on a particular Open Systems Interconnection (OSI) model data link layer technology to forward packets.
SR nodes (i.e., nodes employing SR) make packet forwarding decisions based on segment IDs as opposed to labels, and as a result SR nodes need not employ LDP in their control planes. Unless otherwise indicated, the SR nodes described below lack LDP in the control plane.
Packets can enter an SR enabled network (i.e., a network of nodes that are SR enabled) via an ingress edge node, travel hop-by-hop along a segment path (SP) that includes one or more core nodes, and exit the network via an egress edge node.
Like labels, segment IDs are short (relative to the length of an IP address or a FEC), fixed-length identifiers. Segment IDs may correspond to topological segments of a network, services provided by network nodes, etc. Topological segments represent one hop or multi hop paths to SR nodes. Topological segments act as sub-paths that can be combined to form an SP. Stacks of segment IDs can represent SPs, and SPs can be associated with FECs as will be more fully described below.
There are several types of segment IDs including nodal-segment IDs, adjacency-segment IDs, etc. Nodal-segment IDs are assigned to nodes so that no two SR nodes belonging to a network domain are assigned the same nodal-segment ID. Nodal-segment IDs can be mapped to unique SR node identifiers such as node loopback IP addresses (hereinafter node loopbacks). In one embodiment, all assigned nodal-segment IDs are selected from a predefined ID range (e.g., [32, 5000]). A nodal-segment ID corresponds to a one-hop or a multi-hop, shortest path (SPT) to an SR node assigned the nodal-segment ID as will be more fully described below.
An adjacency-segment ID represents a direct link between adjacent SR nodes in a network. Links can be uniquely identified. For purposes of explanation only, this disclosure will identify a link using the loopbacks of nodes between which the link is positioned. To illustrate, for a link between two nodes identified by node loopback X and node loopback Y, the link will be identified herein as link XY. Because loopbacks are unique, link IDs are unique. Link IDs should not be confused with adjacency-segment IDs; adjacency-segment IDs may not be unique within a network. This disclosure will presume that only one link exists between nodes in a network, it being understood the present disclosure should not be limited thereto.
Each SR node can assign a distinct adjacency-segment ID for each of the node's links. Adjacency-segment IDs are locally significant; separate SR nodes may assign the same adjacency-segment ID, but that adjacency-segment ID represents distinct links. In one embodiment, adjacency-segment IDs are selected from a predefined range that is outside the predefined range for nodal-segment IDs.
SR nodes can advertise routing information including nodal-segment IDs bound to loopbacks, adjacency-segment IDs mapped to link IDs, etc., using protocols such as IGP and/or BGP with SR extension. Nodes can use the routing information they receive to create or update SR forwarding tables. To illustrate, SR nodes may use the routing information they receive in order to create topology maps of the network, which in turn can be used to identify next hop egress interfaces of shortest paths (SPTs) to respective node loopbacks. The identified SPT or next hop egress interfaces are then mapped to respective nodal-segment IDs in an SR forwarding table. Nodes can also map their adjacency-segment IDs to egress interfaces for respective links in SR forwarding tables. Because adjacency-segment IDs are locally significant, however, adjacency-segment IDs should only be mapped in SR forwarding tables of the nodes that advertise the adjacency-segment IDs. In other words, an SR node that advertises an adjacency-segment ID should be the only node in the network area that has a SR forwarding table that maps the adjacency-segment ID to an egress interface.
As noted above, SR enables segment paths (SPs), which can be used for transporting packets through a network. SPs can be associated with FECs, and can be established for a variety of purposes. Packets associated with the same FEC normally traverse the same SP towards their destination. Nodes in SPs make forwarding decisions based on segment IDs, not based on the contents (e.g., destination IP addresses) of packets. As such, packet forwarding in SPs is not dependent on a particular Layer 2 technology.
Edge nodes and/or other devices (e.g., a centralized control plane server) of an SR network use routing information (nodal-segment IDs bound to loopbacks, adjacency-segment IDs mapped to link IDs, etc.) they receive in link advertisements to create ordered lists of segment IDs (i.e., segment ID stacks). Segment ID stacks correspond to respective SPs. Individual segment IDs in a stack may correspond to respective segments or sub paths of a corresponding SP.
When an SR ingress edge node receives a packet, the node or a centralized control plane server in data communication with the node, can select an SP for the packet based on information contained in the packet. In one embodiment, a FEC may be calculated for the packet using the packet's destination address. The FEC is then used to select a segment ID stack mapped thereto. The ingress edge node can attach the selected segment ID stack to the packet via an SR header. The packet with attached stack is forwarded along and can traverse the segments of the SP in an order that corresponds to the list order of the segment IDs in the stack. A forwarding engine operating in the data plane of each SR node can use the top segment ID within the stack to look up the egress for next hop. As the packet and attached segment ID stack are forwarded along the SP in a hop-by-hop fashion, segment IDs can be popped off the top of the stack. In another embodiment, the attached stack of segment IDs remains unchanged as the packet is forwarded along the SP. In this embodiment, a pointer to an active segment ID in the stack can be advanced as the packet is forwarded along the SP. In contrast to MPLS, however, segment IDs are typically not swapped as the packet and attached segment ID stack are forwarded along the SP.
To illustrate general concepts of SR,
Each of SR nodes 204-222 can advertise routing information to the other nodes in network 202 using IGP with SR extension. For example, node 208 can generate and send one or more link state advertisements that include adjacency-segment IDs 9001-9003 bound to link IDs CB, CD, and CO, respectively, and nodal-segment ID 66 bound to loopback C. One of ordinary skill understands that link state advertisements may contain additional information. Using the advertisements they receive, the control planes of nodes 204-222 can generate respective SR forwarding tables for use in the data planes. For example, node 208 can generate example SR forwarding table 240 that maps adjacency-segment IDs 9001-9003 to node interface IDs 1-3, respectively, and nodal-segment IDs such as 64, 65, 67, 70, and 72, to node 208 interfaces 1, 1, 2, 3, and 2, respectively, which are the SPT next hop egress interfaces determined by node 208 for loopbacks A, B, D, O, and Z respectively. It is noted that in the embodiment shown, only SR forwarding table 240 maps adjacency-segment IDs 9001-9003 to interfaces; SR forwarding tables in the other nodes of network 202 should not map adjacency-segment IDs 9001-9003.
In addition to creating SR forwarding tables based on received segment ID advertisements, SR nodes or a centralized control plane server (not shown) can create segment ID stacks for respective SPs. For example, ingress edge node 204 creates example segment ID stack 224 for an SP between ingress edge node 204 and egress edge node 222. Example segment stack 224 can be created for a particular FEC (e.g., FEC F). Example stack 224 includes three segment IDs: nodal-segment IDs 66 and 72 advertised by nodes 208 and 222, respectively, and adjacency-segment ID 9003 advertised by node 208. Stack 224 corresponds to an SP in which packets flow in order through nodes 204, 206, 208, 216, 218, and 222.
In response to receiving a packet from access node AE1, SR node 204 or a centralized control plane server (not shown) can select a segment ID stack based on information contained in the packet. For example, node 204 can calculate FEC F for a received packet P based on the destination IP address in packet P. FEC F is mapped to example stack 224 in a table not shown. Node 204 attaches stack 224 to packet P. Example segment stack 224 lists segment IDs that correspond to one hop and multi hop segments that packets traverse to reach egress edge node 222. The segments collectively form the SP corresponding to stack 224. Once the segment stack 224 is attached to packet P, ingress SR enable node 204 may access a SR forwarding table (not shown) using the top segment ID (e.g., segment ID=66) to read egress interface identifier 2, which is the next hop egress interface for the SPT to the SR node assigned nodal-segment ID 66.
With continuing reference to
With continuing reference to
3. Inter Area Segment Routing
A provider network may be subdivided into areas to simplify administration and optimize resource utilization. An area consists of nodes that have been administratively grouped together into an IGP domain. A backbone area typically forms the core of a subdivided network. Additional areas are connected to the backbone and referred to herein as aggregation areas. Nodes that are totally within an area are called internal nodes. All interfaces of internal nodes are directly connected to nodes within the area. Area border nodes have interfaces that are directly coupled to at least one node in the backbone area and at least one node in a connected aggregation area. Area border nodes can be viewed as being contained in more than one area. Inter-area packet forwarding happens via area border nodes. Edge nodes in aggregation areas may be connected to nodes (e.g., access network nodes) that are external to the subdivided provider network.
In one embodiment, nodal-segment IDs are unique in the areas in which their nodes are contained. As a result SR nodes in different areas may be assigned the same nodal-segment ID. For example, area border node 414 in area 404 is assigned nodal-segment ID 62, and area border node 422 in area 406 is also assigned nodal-segment ID 62.
Each of the areas 402-406 can implement its own IGP with SR extension. Border area nodes implement a separate instance of IGP with SR extension for each area in which they are contained. Each node in an area advertises routing information including nodal-segment IDs bound to loopbacks to the other nodes in the area in the same or similar fashion that nodes in
Internal BGP with SR extension can be employed to exchange routing information between area border nodes, edge nodes (e.g., nodes 410 and 442) and/or other devices like a centralized control plane server. The routing information exchanged via internal BGP can be used by the edge nodes and/or the dedicated devices to create segment ID stacks for edge-to-edge SPs. For example, area border node 422 may establish a session with area border node 414 in which area border node 422 advertises routing information to reach edge node 442. This routing information may indicate that loopback Z (node 442), which is bound to nodal-segment ID 73, can be reached via loopback J (node 422), which is bound to nodal-segment ID 62. Area border node 414 in turn may establish a session with edge node 410 in which area border node 414 advertises routing information to reach edge node 442. This routing information may indicate that loopback Z (node 442) bound to nodal-segment ID 73, can be reached via node loopback J (node 422) bound to nodal-segment ID 62, which in turn can be reached via loopback D (node 414) bound to nodal-segment ID 62.
4. Area-Segment IDs
Area-segment IDs, an additional type of segment ID, can be assigned to each area in a subdivided network. Area-segment IDs are assigned so that no two areas in a subdivided network are assigned the same area-segment ID.
Each node in an area can be assigned the area-segment ID for the area in which the node is contained. Each node may bind its assigned area-segment ID to its loopback. The ranges for nodal-segment IDs and adjacency-segment IDs may be different from the predefined ranges for area-segment IDs.
Area-segment IDs can be used for a variety of purposes. For example, area-segment IDs can be used to preclude forwarding errors that can arise from use of duplicate nodal-segment IDs in segment stacks. Stack 450 in
Each node in an area can use IGP with SR extension to advertise its routing information including nodal-segment IDs and area-segment IDs bound to loopbacks to other nodes in the area in the same or similar fashion as described above with reference to
Nodes in an area can use the routing information they receive to create SR forwarding tables for the area in which the nodes are contained in the same or similar fashion as described above with reference to
Area-segment IDs can be included in routing information exchanged between area border nodes, edge nodes and/or a centralized control plane server during internal BGP with SR extension sessions. To illustrate with reference to
SR edge nodes and centralized control plane servers can use the routing information they receive via IGP and internal BGP sessions to create segment ID stacks for edge-to-edge SPs. These segment ID stacks may contain one or more area-segment IDs. For example, using the routing information it received during the session with area border node 414 described above, edge node 410 creates a segment ID stack 524 for an SP that extends from edge node 410 to edge node 442 via area border nodes 414 and 422.
In one embodiment, area-segment IDs within a stack can be used by area border nodes, such as area border nodes 414 and 422, to select the appropriate SR forwarding table to use when making packet forwarding decisions. In another embodiment, area-segment IDs within a stack can be used by internal and/or edge nodes of an aggregation area to look up next hop egress interfaces for packets. To illustrate with continuing reference to
It is noted above that in an alternative embodiment, area border nodes advertise their loopbacks bound to the backbone area-segment ID into the aggregation. Edge and internal nodes within the aggregation area can map area-segment IDs to egress interfaces for the next hop toward the closest area border node. In this configuration, a more compact segment ID stack (i.e., less segment IDs) can be created and used for forwarding packets. To illustrate,
5. Access to Aggregation SR
The networks shown in
Each node is assigned a unique nodal-segment ID within an access network. These nodal-segment IDs are bound to respective loopbacks. Nodes 706-712 within an access network AN1 are assigned nodal-segment IDs 80-82, respectively, while nodes 714-718 in access network AN2 are assigned nodal-segment IDs 83-85, respectively.
Each of the access networks AN1 and AN2 can implement its own IGP with SR extension. Aggregation edge nodes implement separate instances of IGP with SR extension, one for the access network to which they are connected and one for the aggregation area in which they are contained. Access network nodes and the connected aggregation edge node exchange routing information (e.g., nodal-segment IDs bound to loopbacks). Aggregation edge nodes can advertise additional routing information into their connected access networks. This additional routing information may include the aggregation edge node's loopback bound to its nodal-segment ID and its area-segment ID. Internal BGP sessions between end nodes (e.g., node 716), aggregation edge nodes, area border nodes, and centralized control plane servers can be used to exchange additional routing information.
Nodes in an access network can use the routing information they receive to create SR forwarding tables for the access network in which they are contained in the same or similar fashion described above. Aggregation edge nodes may create separate SR forwarding tables: one for the access network they are connected to and one for the aggregation area they are contained in. The SR forwarding table for the aggregation area may be linked to the area-segment ID for that area.
Nodes within a local access network may be incapable or otherwise not configured to create or store segment stacks for end-to-end SPs to nodes in remote access networks. For example, node 706 may lack enough memory needed to store thousands of segment stacks for SPs that extend between node 706 and destination nodes (e.g., node 716 within remote access network AN2) in remote access networks. Thus, when an access network node (e.g., node 706) receives a packet P from a device (e.g., host 720), which is destined for a remote device (e.g., host 722), the access network node may need to rely on an alternative mechanism to provide a segment stack that can be used to transmit the packet P.
In one embodiment, a centralized control plane server (not shown) can provide segment stacks to nodes of access networks. Access network nodes, such as node 706, can generate and send a request for a segment stack. The request can be sent to the centralized control plane server that is capable of providing the stack. The request should contain SP related information that is needed by the centralized control plane server to create or select an appropriate segment stack. To that end the centralized control plane server may need either the destination address for packet P or the loopback of the node (i.e., destination node) in the remote access network that is closest to the destination address. In addition, the centralized control plane server may need the loopback of the aggregation edge node connected to the access network that contains the node requesting the segment stack.
The centralized control plane server can create the needed segment stack using the SP related information provided in the request, or the centralized control plane server may access memory to read a segment stack that is mapped to the SP related information provided in the request. Either way, the centralized control plane server can reply to the request with a segment stack for an SP that extends between the aggregation edge node and the remote access network destination node identified in the request.
The requesting access network node receives the reply and attaches the segment stack contained therein to packet P. Thereafter, the access node can add the nodal-segment ID and area-segment ID for the aggregation edge node to the top of the attached segment stack so that the nodal-segment ID is the top segment ID initially. Once the two segment IDs are added to the stack, the packet and attached stack can be forwarded along the SP toward its destination. The access network node that attaches the segment stack to packet P and each node in the SP that receives the packet with segment stack can make a forwarding decision employing the process shown within
The processors 850 and 860 of each line card 802 may be mounted on a single printed circuit board. When a packet or packet and header are received, the packet or packet and header with segment stack may be identified and analyzed by router 800 in the following manner. Upon receipt, a packet (or some or all of its control information) or packet and header is sent from the one of port processors 850(1,1)-(N,N) at which the packet or packet and header was received to one or more of those devices coupled to data bus 830 (e.g., others of port processors 850(1,1)-(N,N), forwarding engine 810 and/or processor 820). Handling of the packet or packet and header can be determined, for example, by forwarding engine 810. For example, forwarding engine 810 may determine that the packet or packet and header should be forwarded to one or more of port processors 850(1,1)-(N,N). This can be accomplished by indicating to corresponding one(s) of port processor controllers 860(1)-(N) that the copy of the packet or packet and header held in the given one(s) of port processors 850(1,1)-(N,N) should be forwarded to the appropriate one of port processors 850(1,1)-(N,N). In addition, or alternatively, once a packet or packet and header has been identified for processing, forwarding engine 810, processor 820 or the like can be used to process the packet or packet and header in some manner or add packet security information, in order to secure the packet. On a node sourcing such a packet or packet and header, this processing can include, for example, encryption of some or all of the packet's or packet and header's information, the addition of a digital signature or some other information or processing capable of securing the packet or packet and header. On a node receiving such a processed packet or packet and header, the corresponding process is performed to recover or validate the packet's or packet and header's information that has been thusly protected.
Although the present disclosure has been described in connection with several embodiments, the disclosure is not intended to be limited to the specific forms set forth herein. On the contrary, it is intended to cover such alternatives, modifications, and equivalents as can be reasonably included within the scope of the disclosure as defined by the appended claims.
The present patent application is a continuation of U.S. patent application Ser. No. 15/234,794, filed on Aug. 11, 2016 and entitled “Seamless Segment Routing,” which is a continuation of U.S. patent application Ser. No. 14/210,837, filed on Mar. 14, 2014 and entitled “Seamless Segment Routing” (now U.S. Pat. No. 9,450,829 issued on Sep. 20, 2016), which claims the domestic benefit under Title 35 of the United States Code § 119(e) of U.S. Provisional Patent Application Ser. No. 61/791,242, filed on Mar. 15, 2013 and entitled “Segment Routing.” All of these nonprovisional and provisional applications are hereby incorporated by reference in their entirety and for all purposes as if completely and fully set forth herein.
Number | Name | Date | Kind |
---|---|---|---|
5764624 | Endo | Jun 1998 | A |
6032197 | Birdwell | Feb 2000 | A |
6374303 | Armitage | Apr 2002 | B1 |
6577600 | Bare | Jun 2003 | B1 |
6647428 | Bannai et al. | Nov 2003 | B1 |
6963570 | Agarwal | Nov 2005 | B1 |
7023846 | Andersson et al. | Apr 2006 | B1 |
7031253 | Katukam et al. | Apr 2006 | B1 |
7031607 | Aswood Smith | Apr 2006 | B1 |
7061921 | Sheth | Jun 2006 | B1 |
7068654 | Joseph et al. | Jun 2006 | B1 |
7072346 | Hama | Jul 2006 | B2 |
7088721 | Droz et al. | Aug 2006 | B1 |
7154416 | Savage | Dec 2006 | B1 |
7174387 | Shand et al. | Feb 2007 | B1 |
7180887 | Schwaderer | Feb 2007 | B1 |
7260097 | Casey | Aug 2007 | B2 |
7286479 | Bragg | Oct 2007 | B2 |
7330440 | Bryant | Feb 2008 | B1 |
7359377 | Kompella et al. | Apr 2008 | B1 |
7373401 | Azad | May 2008 | B1 |
7420992 | Fang | Sep 2008 | B1 |
7430210 | Havala et al. | Sep 2008 | B2 |
7463639 | Rekhter | Dec 2008 | B1 |
7466661 | Previdi et al. | Dec 2008 | B1 |
7471669 | Sabesan et al. | Dec 2008 | B1 |
7564803 | Minei et al. | Jul 2009 | B1 |
7577143 | Kompella | Aug 2009 | B1 |
7602778 | Guichard et al. | Oct 2009 | B2 |
7610330 | Quinn | Oct 2009 | B1 |
7773630 | Huang et al. | Aug 2010 | B2 |
7817667 | Frederiksen et al. | Oct 2010 | B2 |
7885259 | Filsfils | Feb 2011 | B2 |
7885294 | Patel | Feb 2011 | B2 |
7894352 | Kompella et al. | Feb 2011 | B2 |
7894458 | Jiang | Feb 2011 | B2 |
7940695 | Bahadur et al. | May 2011 | B1 |
7983174 | Monaghan et al. | Jul 2011 | B1 |
8064441 | Wijnands et al. | Nov 2011 | B2 |
8339973 | Pichumani | Dec 2012 | B1 |
8422514 | Kothari et al. | Apr 2013 | B1 |
8542706 | Wang et al. | Sep 2013 | B2 |
8611335 | Wu | Dec 2013 | B1 |
8619817 | Everson | Dec 2013 | B1 |
8630167 | Ashwood Smith | Jan 2014 | B2 |
8711883 | Kang | Apr 2014 | B2 |
8792384 | Banerjee et al. | Jul 2014 | B2 |
8953590 | Aggarwal | Feb 2015 | B1 |
9036474 | Dibirdi et al. | May 2015 | B2 |
9049233 | Frost et al. | Jun 2015 | B2 |
9112734 | Edwards et al. | Aug 2015 | B2 |
9118572 | Sajassi | Aug 2015 | B2 |
9319312 | Filsfils et al. | Apr 2016 | B2 |
9571349 | Previdi et al. | Feb 2017 | B2 |
9660897 | Gredler | May 2017 | B1 |
9749227 | Frost et al. | Aug 2017 | B2 |
20010037401 | Soumiya | Nov 2001 | A1 |
20010055311 | Trachewsky | Dec 2001 | A1 |
20020103732 | Bundy et al. | Aug 2002 | A1 |
20030016678 | Maeno | Jan 2003 | A1 |
20030026271 | Erb et al. | Feb 2003 | A1 |
20030126272 | Corl et al. | Jul 2003 | A1 |
20030133412 | Iyer | Jul 2003 | A1 |
20030142674 | Casey | Jul 2003 | A1 |
20030142685 | Bare | Jul 2003 | A1 |
20030231634 | Henderson | Dec 2003 | A1 |
20040160958 | Oh | Aug 2004 | A1 |
20040174879 | Basso et al. | Sep 2004 | A1 |
20040196840 | Amrutur et al. | Oct 2004 | A1 |
20040202158 | Takeno | Oct 2004 | A1 |
20040240442 | Grimminger | Dec 2004 | A1 |
20050073958 | Atlas | Apr 2005 | A1 |
20050105515 | Reed | May 2005 | A1 |
20050213513 | Ngo | Sep 2005 | A1 |
20050259655 | Cuervo et al. | Nov 2005 | A1 |
20060002304 | Ashwood-Smith | Jan 2006 | A1 |
20060013209 | Somasundaram | Jan 2006 | A1 |
20060056397 | Aizu | Mar 2006 | A1 |
20060075134 | Aalto | Apr 2006 | A1 |
20060080421 | Hu | Apr 2006 | A1 |
20060092940 | Ansari | May 2006 | A1 |
20060146696 | Li | Jul 2006 | A1 |
20060187817 | Charzinski | Aug 2006 | A1 |
20060262735 | Guichard | Nov 2006 | A1 |
20060274716 | Oswal et al. | Dec 2006 | A1 |
20070019647 | Roy et al. | Jan 2007 | A1 |
20070053342 | Siereki | Mar 2007 | A1 |
20070058638 | Guichard et al. | Mar 2007 | A1 |
20070189291 | Tian | Aug 2007 | A1 |
20070245034 | Retana | Oct 2007 | A1 |
20080002699 | Rajsic | Jan 2008 | A1 |
20080075016 | Ashwood-Smith | Mar 2008 | A1 |
20080075117 | Tanaka | Mar 2008 | A1 |
20080084881 | Dharwadkar et al. | Apr 2008 | A1 |
20080101227 | Fujita et al. | May 2008 | A1 |
20080101239 | Goode | May 2008 | A1 |
20080172497 | Mohan et al. | Jul 2008 | A1 |
20080189393 | Wagner | Aug 2008 | A1 |
20080192762 | Kompella et al. | Aug 2008 | A1 |
20080212465 | Yan | Sep 2008 | A1 |
20080225864 | Aissaoui et al. | Sep 2008 | A1 |
20080253367 | Ould-Brahim | Oct 2008 | A1 |
20080259820 | White et al. | Oct 2008 | A1 |
20090041038 | Martini et al. | Feb 2009 | A1 |
20090049194 | Csaszar | Feb 2009 | A1 |
20090067445 | Diguet | Mar 2009 | A1 |
20090080431 | Rekhter | Mar 2009 | A1 |
20090135815 | Pacella | May 2009 | A1 |
20090296710 | Agrawal | Dec 2009 | A1 |
20100063983 | Groarke et al. | Mar 2010 | A1 |
20100088717 | Candelore et al. | Apr 2010 | A1 |
20100124231 | Kompella | May 2010 | A1 |
20100142548 | Sheth | Jun 2010 | A1 |
20100220739 | Ishiguro | Sep 2010 | A1 |
20100232435 | Jabr | Sep 2010 | A1 |
20100272110 | Allan et al. | Oct 2010 | A1 |
20100284309 | Allan et al. | Nov 2010 | A1 |
20110060844 | Allan et al. | Mar 2011 | A1 |
20110063986 | Denechaeu | Mar 2011 | A1 |
20110090913 | Kim | Apr 2011 | A1 |
20110228780 | Ashwood-Smith | Sep 2011 | A1 |
20110261722 | Awano | Oct 2011 | A1 |
20110268114 | Wijnands et al. | Nov 2011 | A1 |
20110280123 | Wijnands et al. | Nov 2011 | A1 |
20110286452 | Balus | Nov 2011 | A1 |
20120044944 | Kotha et al. | Feb 2012 | A1 |
20120063526 | Xiao | Mar 2012 | A1 |
20120069740 | Lu et al. | Mar 2012 | A1 |
20120069845 | Carney et al. | Mar 2012 | A1 |
20120075988 | Lu | Mar 2012 | A1 |
20120082034 | Vasseur | Apr 2012 | A1 |
20120106560 | Gumaste | May 2012 | A1 |
20120120808 | Nandagopal et al. | May 2012 | A1 |
20120170461 | Long | Jul 2012 | A1 |
20120179796 | Nagaraj | Jul 2012 | A1 |
20120213225 | Subramanian et al. | Aug 2012 | A1 |
20120218884 | Kini | Aug 2012 | A1 |
20120236860 | Kompella et al. | Sep 2012 | A1 |
20120287818 | Corti et al. | Nov 2012 | A1 |
20120307629 | Vasseur | Dec 2012 | A1 |
20130003728 | Kwong et al. | Jan 2013 | A1 |
20130051237 | Ong | Feb 2013 | A1 |
20130077476 | Enyedi | Mar 2013 | A1 |
20130077624 | Keesara et al. | Mar 2013 | A1 |
20130077625 | Khera | Mar 2013 | A1 |
20130077626 | Keesara et al. | Mar 2013 | A1 |
20130114402 | Ould-Brahim | May 2013 | A1 |
20130142052 | Burbidge | Jun 2013 | A1 |
20130188634 | Magee | Jul 2013 | A1 |
20130219034 | Wang et al. | Aug 2013 | A1 |
20130258842 | Mizutani | Oct 2013 | A1 |
20130266012 | Dutta et al. | Oct 2013 | A1 |
20130266013 | Dutta et al. | Oct 2013 | A1 |
20130343204 | Geib et al. | Dec 2013 | A1 |
20140160925 | Xu | Jun 2014 | A1 |
20140169370 | Filsfils et al. | Jun 2014 | A1 |
20140177638 | Bragg et al. | Jun 2014 | A1 |
20140189156 | Morris | Jul 2014 | A1 |
20140192677 | Chew | Jul 2014 | A1 |
20140254596 | Filsfils et al. | Sep 2014 | A1 |
20140269266 | Filsfils et al. | Sep 2014 | A1 |
20140269421 | Previdi et al. | Sep 2014 | A1 |
20140269422 | Filsfils et al. | Sep 2014 | A1 |
20140269698 | Filsfils et al. | Sep 2014 | A1 |
20140269699 | Filsfils et al. | Sep 2014 | A1 |
20140269721 | Bashandy et al. | Sep 2014 | A1 |
20140269725 | Filsfils et al. | Sep 2014 | A1 |
20140269727 | Filsfils et al. | Sep 2014 | A1 |
20140286195 | Fedyk | Sep 2014 | A1 |
20140317259 | Previdi et al. | Oct 2014 | A1 |
20140369356 | Bryant et al. | Dec 2014 | A1 |
20150023328 | Thubert et al. | Jan 2015 | A1 |
20150030020 | Kini | Jan 2015 | A1 |
20150109902 | Kumar | Apr 2015 | A1 |
20150256456 | Previdi et al. | Sep 2015 | A1 |
20150263940 | Kini | Sep 2015 | A1 |
20150326675 | Kini | Nov 2015 | A1 |
20150381406 | Francois | Dec 2015 | A1 |
20160006614 | Zhao | Jan 2016 | A1 |
20160021000 | Previdi et al. | Jan 2016 | A1 |
20160119159 | Zhao | Apr 2016 | A1 |
20160173366 | Saad | Jun 2016 | A1 |
20160191372 | Zhang | Jun 2016 | A1 |
20160254987 | Eckert et al. | Sep 2016 | A1 |
20160254988 | Eckert et al. | Sep 2016 | A1 |
20160254991 | Eckert et al. | Sep 2016 | A1 |
20160352654 | Filsfils et al. | Dec 2016 | A1 |
20170019330 | Filfils et al. | Jan 2017 | A1 |
20170104673 | Bashandy et al. | Apr 2017 | A1 |
20170111277 | Previdi et al. | Apr 2017 | A1 |
20170302571 | Frost et al. | Oct 2017 | A1 |
20170346718 | Psenak et al. | Nov 2017 | A1 |
20170346737 | Previdi et al. | Nov 2017 | A1 |
20170366453 | Previdi et al. | Dec 2017 | A1 |
20180083871 | Filsfils | Mar 2018 | A1 |
Number | Date | Country |
---|---|---|
1726 679 | Jan 2006 | CN |
101247 253 | Aug 2008 | CN |
101399 688 | Apr 2009 | CN |
101496 357 | Jul 2009 | CN |
101616 466 | Dec 2009 | CN |
101803 293 | Aug 2010 | CN |
101841 442 | Sep 2010 | CN |
101931 548 | Dec 2010 | CN |
102098 222 | Jun 2011 | CN |
102132 533 | Jul 2011 | CN |
102299 852 | Dec 2011 | CN |
102498 694 | Jun 2012 | CN |
102714 625 | Oct 2012 | CN |
Entry |
---|
Previdi, Stefano B. et al., “Segment Routing Extension Headers”, U.S. Appl. No. 15/677,210, filed Aug. 15, 2017; consisting of Specification, Claims, Abstract, and Drawings (58 pages). |
Psenak, Peter et al., “Enforcing Strict Shortest Path Forwarding Using Strict Segment Identifiers”; U.S. Appl. No. 15/165,794, filed May 26, 2016; consisting of Specification, Claims, Abstract, and Drawings (52 pages). |
Nainar, Nagendra Kumar et al., “Reroute Detection in Segment Routing Data Plane”; U.S. Appl. No. 15/266,498, filed Sep. 15, 2016; consisting of Specification, Claims, Abstract, and Drawings (61 pages). |
Frost, Daniel C. et al., “MPLS Segment Routing”; U.S. Appl. No. 15/637,744, filed Jun. 29, 2017; consisting of Specification, Claims, Abstract, and Drawings (26 pages). |
Filsfils, Clarence et al., “Seamless Segment Routing”; U.S. Appl. No. 15/639,398, filed Jun. 30, 2017; consisting of Specification, Claims, Abstract, and Drawings (31 pages). |
Aggarwal, R., et al., Juniper Networks; E. Rosen, Cisco Systems, Inc.; “MPLS Upstream Label Assignment and Context Specific Label Space;” Network Working Group; Internet Draft; Jan. 2005; pp. 1-8. |
Akiya, N. et al., “Seamless Bidirectional Forwarding Detection (BFD) for Segment Routing (SR)”; draft-akiya-bfd-seamless-sr-00; Internet Engineering Task Force; Internet-Draft; Jun. 7, 2013; 7 pages. |
Akiya, N. et al., “Seamless Bidirectional Forwarding Detection (BFD) for Segment Routing (SR)”; draft-akiya-bfd-seamless-sr-01; Internet Engineering Task Force; Internet-Draft; Dec. 5, 2013; 7 pages. |
Akiya, N. et al., “Seamless Bidirectional Forwarding Detection (BFD) for Segment Routing (SR)”; draft-akiya-bfd-seamless-sr-02; Internet Engineering Task Force; Internet-Draft; Jun. 7, 2014; 7 pages. |
Akiya, N. et al., “Seamless Bidirectional Forwarding Detection (BFD) for Segment Routing (SR)”; draft-akiya-bfd-seamless-sr-03; Internet Engineering Task Force; Internet-Draft; Aug. 23, 2014; 7 pages. |
Akiya, N. et al., “Seamless Bidirectional Forwarding Detection (BFD) for Segment Routing (SR)”; draft-akiya-bfd-seamless-sr-04; Internet Engineering Task Force; Internet-Draft; Feb. 23, 2015; 7 pages. |
Akiya, N., “Segment Routing Implications on BFD”; Sep. 9, 2013; 3 pages. |
Alcatel-Lucent, “Segment Routing and Path Computation Element—Using Traffic Engineering to Optimize Path Placement and Efficiency in IP/MPLS Networks”; Technology White Paper; 2015; 28 pages. |
Aldrin, S., et al., “Seamless Bidirectional Forwarding Detection (S-BFD) Use Cases”; draft-ietf-bfd-seamless-use-case-08; Network Working Group; Internet-Draft; May 6, 2016; 15 pages. |
Awduche, Daniel O., et al., “RSVP-TE: Extensions to RSVP for LSP Tunnels,” Network Working Group, Internet-Draft, Aug. 2000, pp. 1-12. |
Awduche, Daniel O., et al., “RSVP-TE: Extensions to RSVP for LSP Tunnels,” Network Working Group, Request for Comments 3209, Dec. 2001, pp. 1-61. |
Awduche, D. et al., “Requirements for Traffic Engineering Over MPLS”; Network Working Group; Request for Comments: 2702; Sep. 1999; pp. 1-29. |
Awduche, D. et al., “Overview and Principles of Internet Traffic Engineering”; Network Working Group; Request for Comments: 3272; May 2002; pp. 1-71. |
Backes, P. and Rudiger Geib, “Deutsche Telekom AG's Statement About IPR Related to Draft-Geig-Spring-OAM-Usecase-01,” Feb. 5, 2014, pp. 1-2. |
Bryant, S. et al., Cisco Systems, “IP Fast Reroute Using Tunnels-draft-bryant-ipfrr-tunnels-03”, Network Working Group, Internet-Draft, Nov. 16, 2007, pp. 1-30. |
Bryant, S., et al., Cisco Systems, “Remote LFA FRR,” draft-ietf-rtgwg-remote-lfa-04, Network Working Group, Internet-Draft, Nov. 22, 2013, pp. 1-24. |
CISCO Systems, Inc., “Introduction to Intermediate System-to-Intermediate System Protocol,” published 1992-2002; pp. 1-25. |
Crabbe, E., et al., “PCEP Extensions for MPLS-TE LSP Protection With Stateful PCE Draft-Crabbe-PCE-Stateful-PCE-Protection-00,” Network Working Group, Internet-Draft, Oct. 2012, pp. 1-12. |
Crabbe, E., et al., Stateful PCE Extensions for MPLS-TE LSPs, draft-crabbe-pce-stateful-pce-mpls-te-00; Network Working Group, Internet-Draft, Oct. 15, 2012, pp. 1-15. |
Deering, S., et al., Cisco, Internet Protocol, Version 6 (IPv6) Specification, Network Working Group, Request for Comments 2460, Dec. 1998, pp. 1-39. |
Eckert, T., “Traffic Engineering for Bit Index Explicit Replication BIER-TE, draft-eckert-bier-te-arch-00,” Network Working Group, Internet-Draft, Mar. 5, 2015, pp. 1-21. |
Eckert, T., et al., “Traffic Engineering for Bit Index Explicit Replication BIER-TE, draft-eckert-bier-te-arch-01,” Network Working Group, Internet-Draft, Jul. 5, 2015, pp. 1-23. |
Farrel, A., et al., Old Dog Consulting, A Path Computation Element (PCE)-Based Architecture, Network Working Group, Request for Comments 4655, Aug. 2006, pp. 1-80. |
Farrel, A., et al., Old Dog Consulting, Inter-Domain MPLS and GMPLS Traffic Engineering—Resource Reservation Protocol-Traffic Engineering (RSVP-TE) Extensions, Network Working Group, Request for Comments 5151, Feb. 2008, pp. 1-25. |
Fedyk, D., et al., Alcatel-Lucent, Generalized Multiprotocol Label Switching (GMPLS) Control Ethernet Provider Backbone Traffic Engineering (PBB-TE), Internet Engineering Task Force (IETF), Request for Comments 6060, Mar. 2011, pp. 1-20. |
Filsfils, C., et al., Cisco Systems, Inc., “Segment Routing Architecture,” draft-filsfils-rtgwg-segment-routing-00, Jun. 28, 2013; pp. 1-28. |
Filsfils, C., et al., Cisco Systems, Inc., “Segment Routing Architecture”; draft-filsfils-rtgwg-segment-routing-01, Network Working Group, Internet-Draft, Oct. 21, 2013, pp. 1-28. |
Filsfils, C. et al., Cisco Systems, Inc., “Segment Routing Interoperability with LDP”; draft-filsfils-spring-segment-routing-ldp-interop-01.txt; Apr. 18, 2014, pp. 1-16. |
Filsfils, C. et al., “Segment Routing Architecture”; draft-ietf-spring-segment-routing-07; Network Working Group, Internet-Draft; Dec. 15, 2015; pp. 1-24. |
Filsfils, C. et al.; “Segment Routing Use Cases”; draft-filsfils-rtgwg-segment-routing-use-cases-01; Network Working Group; Internet-Draft; Jul. 14, 2013; pp. 1-46. |
Filsfils, C. et al., “Segment Routing Use Cases”, draft-filsfils-rtgwg-segment-routing-use-cases-02; Network Working Group; Internet-Draft; Oct. 21, 2013; pp. 1-36. |
Filsfils, C. et al., “Segment Routing with MPLS Data Plane”, draft-ietf-spring-segment-routing-mpls-05; Network Working Group; Internet-Draft; Jul. 6, 2016; 15 pages. |
Frost, D., et al., Cisco Systems, Inc., “MPLS Generic Associated Channel (G-Ach) Advertisement Protocol,” draft-ietf-mpls-gach-adv-00, Internet-Draft, Jan. 27, 2012, pp. 1-17. |
Frost, D., et al., Cisco Systems, Inc., “MPLS Generic Associated Channel (G-Ach) Advertisement Protocol,” draft-ietf-mpls-gach-adv-08, Internet-Draft, Jun. 7, 2013, pp. 1-22. |
Frost, D., et al., Cisco Systems, Inc., “MPLS Generic Associated Channel (G-Ach) Advertisement Protocol,” Request for Comments 7212, Jun. 2014, pp. 1-23. |
Geib, R., “Segment Routing Based OAM Use Case,”IETF 87, Berlin, Jul./Aug. 2013, pp. 1-3. |
Geib, R., Deutsch Telekom, “Use Case for a Scalable and Topology Aware MPLS data plane monitoring System,” draft-geib-spring-oam-usecase-00; Internet-Draft, Oct. 17, 2013, pp. 1-7. |
Geib, R., Deutsch Telekom, “Use Case for a Scalable and Topology Aware MPLS Data Plane Monitoring System,” draft-geib-spring-oam-usecase-01; Internet-Draft, Feb. 5, 2014, pp. 1-10. |
Gredler, H., et al., Juniper Networks, Inc., “Advertising MPLS Labels in IS-IS draft-gredler-isis-label-advertisement-00,” Internet-Draft; Apr. 5, 2013; pp. 1-13. |
Gredler, H. et al., hannes@juniper.net, IETF87, Berlin, “Advertising MPLS LSPs in the IGP,” draft-gredler-ospf-label-advertisement, May 21, 2013; pp. 1-14. |
Guilbaud, Nicolas and Ross Cartlidge, “Google˜Localizing Packet Loss in a Large Complex Network,” Feb. 5, 2013, pp. 1-43. |
Imaizumi, H., et al.; Networks, 2005; “FMEHR: An Alternative Approach to Multi-Path Forwarding on Packed Switched Networks,” pp. 196-201. |
Kompella, K. et al, Juniper Networks, “Label Switched Paths (LSP) Hierarchy with Generalized Multi-Protocol Label Switching (GMPLS) Traffic Engineering (TE),” Network Working Group, Request for Comments 4206, Oct. 2005, pp. 1-14. |
Kompella, K., et al., Juniper Networks, Inc., “Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures,” Network Working Group, Request for Comments 4379, Feb. 2006, pp. 1-50. |
Kompella, K. et al., Juniper Networks,“Virtual Private Lan Service (VPLS) Using BGP for Auto-Discovery and Signaling,” Network Working Group, Request for Comments 4761, Jan. 2007, pp. 1-28. |
Kumar, N. et al., Cisco Systems, Inc., “Label Switched Path (LSP) Ping/Trace for Segment Routing Networks Using MPLS Dataplane,” draft-kumar-mpls-spring-lsp-ping-00, Oct. 21, 2013, pp. 1-12. |
Kumar, N. et al, “Label Switched Path (LSP) Ping/Trace for Segment Routing Networks Using MPLS Dataplane,” draft-kumarkini-mpls-spring-lsp-ping-00; Network Work Group; Internet-Draft; Jan. 2, 2014, pp. 1-15. |
Kumar, N. et al, “OAM Requirements for Segment Routing Network”; draft-kumar-spring-sr-oam-requirement-00; Spring; Internet-Draft; Feb. 14, 2014; 6 pages. |
Kumar, N. et al, “OAM Requirements for Segment Routing Network”; draft-kumar-spring-sr-oam-requirement-01;Spring; Internet-Draft; Jul. 1, 2014; 6 pages. |
Kumar, N. et al, “OAM Requirements for Segment Routing Network”; draft-kumar-spring-sr-oam-requirement-02; Spring; Internet-Draft; Dec. 31, 2014; 6 pages. |
Kumar, N. et al, “OAM Requirements for Segment Routing Network”; draft-kumar-spring-sr-oam-requirement-03; Spring; Internet-Draft; Mar. 9, 2015; 6 pages. |
Kumar, N. et al., “Label Switched Path (LSP) Ping/Trace for Segment Routing Networks Using MPLS Dataplane”, draft-ietf-mpls-spring-lsp-ping-00; Network Work Group; Internet Draft; May 10, 2016; 17 pages. |
Pignataro, C. et al., “Seamless Bidirectional Forwarding Detection (S-BFD) for IPv4, IPv6 and MPLS”, draft-ietf-bfd-seamless-ip-06; Internet Engineering Task Force; Internet-Draft; May 6, 2016; 8 pages. |
Pignataro, C. et al., “Seamless Bidirectional Forwarding Detection (S-BFD)”; draft-ietf-bfd-seamless-base-11; Internet Engineering Task Force; Internet-Draft; May 6, 2016; 21 pages. |
Previdi, S. et al., Cisco Systems, Inc., “Segment Routing with IS-IS Routing Protocol, draft-previdi-filsfils-isis-segment-routing-00,” IS-IS for IP Internets, Internet-Draft, Mar. 12, 2013, pp. 1-27. |
Previdi, S. et al., Cisco Systems, Inc., “Segment Routing with IS-IS Routing Protocol, draft-previdi-filsfils-isis-segment-routing-02,” Internet-Draft, Mar. 20, 2013, A55 pp. 1-27. |
Previdi, S. et al., “IS-IS Extensions for Segment Routing”; draft-ietf-isis-segment-routing-extensions-05; IS-IS for IP Internets, Internet-Draft; Jun. 30, 2015; pp. 1-37. |
Previdi, S. et al., “IS-IS Extensions for Segment Routing”; draft-ietf-isis-segment-routing-extensions-06; IS-IS for IP Internets, Internet-Draft; Dec. 14, 2015; pp. 1-39. |
Psenak, P., et al. “OSPF Extensions for Segment Routing”, draft-ietf-ospf-segment-routing-extensions-05; Open Shortest Path First IGP; Internet-Draft; Jun. 26, 2015; pp. 1-29. |
Raszuk, R., NTT I3, “MPLS Domain Wide Labels,” draft-raszuk-mpls-domain-wide-labels-00, MPLS Working Group, Internet-Draft, Jul. 14, 2013, pp. 1-6. |
Rosen, E. et al., Cisco Systems, Inc., “BGP/MPLS VPNs”, Network Working Group, Request for Comments: 2547; Mar. 1999, pp. 1-26. |
Sivabalan, S., et al.; “PCE-Initiated Traffic Engineering Path Setup in Segment Routed Networks; draft-sivabalan-pce-segmentrouting-00.txt,” Internet Engineering Task Force, IETF; Standard Working Draft, Internet Society (ISOC) 4, Rue Des Falaises CH-1205, Geneva, Switzerland, Jun. 2013, pp. 1-16. |
Li, T., et al., Redback Networks, Inc., “IS-IS Extensions for Traffic Engineering,” Network Working Group, Request for Comments 5305, Oct. 2008, 17 pages. |
Tian, Albert J. et al., Redback Networks, “Source Routed MPLS LSP Using Domain Wide Label, draft-tian-mpls-lsp-source-route-01.txt”, Network Working Group, Internet Draft, Jul. 2004, pp. 1-12. |
Vasseur, JP, et al.; Cisco Systems, Inc. “A Link-Type Sub-TLV to Convey the Number of Traffic Engineering Label Switched Paths Signaled with Zero Reserved Bandwidth Across a Link,” Network Working Group, Request for Comments 5330; Oct. 2008, 16 pages. |
Vasseur, JP, et al.; Cisco Systems, Inc. Path Computation Element (PCE) Communication Protocol (PCEP): Request for Comments: 5440, Internet Engineering Task Force, IETF; Standard, Internet Society (ISOC) 4, Rue Des Falaises CH-1205, Geneva, Switzerland, chapters 4-8, Mar. 2009; pp. 1-87. |
Wijnands, Ijsbrand and Bob Thomas, Cisco Systems, Inc,; Yuji Kamite and Hitoshi Fukuda, NTT Communications; “Multicast Extensions for LDP;” Network Working Group; Internet Draft; Mar. 2005; pp. 1-12. |
Number | Date | Country | |
---|---|---|---|
20170302561 A1 | Oct 2017 | US |
Number | Date | Country | |
---|---|---|---|
61791242 | Mar 2013 | US |
Number | Date | Country | |
---|---|---|---|
Parent | 15234794 | Aug 2016 | US |
Child | 15639398 | US | |
Parent | 14210837 | Mar 2014 | US |
Child | 15234794 | US |