A network device computes a set of maximally redundant trees from an ingress network device to a plurality of egress network devices based on a network graph, in which each of the set of maximally redundant trees comprises a spanning tree to the plurality of egress network devices rooted at the network device. The network device computes the maximally redundant trees such that each of the links along each of the set of maximally redundant trees satisfies a specified traffic-engineering constraint. The ingress network device establishes a plurality of point to multipoint (p2mp) label switched paths (LSPs) from the network device as an ingress network device to the plurality of egress network devices along the set of maximally redundant trees, wherein each of the p2mp LSPs corresponds to a different one of the maximally redundant trees.
|
19. A non-transitory computer-readable storage medium comprising instructions for causing a programmable processor to:
calculate a plurality of maximally redundant trees from an ingress network device to a plurality of egress network devices based on a network graph, in which each of the plurality of maximally redundant trees comprises a spanning tree to the plurality of egress network devices rooted at the ingress network device, wherein each of the maximally redundant trees is calculated to comprise a point to multipoint (p2mp) path from the ingress network device to the plurality of egress network devices that is as disjoint as possible from a respective p2mp path from the ingress network device to the plurality of egress network devices for each other one of the plurality of maximally redundant trees, and wherein the maximally redundant trees are calculated such that each link along each of the plurality of maximally redundant trees satisfies a specified traffic-engineering constraint;
in response to determining that the plurality of maximally redundant trees includes at least one node whose removal partitions a network represented by the network graph:
modify the specified traffic-engineering constraint to have a less restrictive value;
modify the network graph to add links to the network graph that satisfy the modified traffic-engineering constraint to obtain a modified network graph; and
re-calculate at least a portion of the plurality of maximally redundant trees based on the modified network graph to obtain a plurality of maximally redundant trees in which at least two nodes must be removed before the network is partitioned; and
establish a plurality of p2mp label switched paths (LSPs) from the ingress network device to the plurality of egress network devices along each of the plurality of maximally redundant trees, wherein each of the p2mp LSPs corresponds to a different one of the plurality of maximally redundant trees.
1. A method comprising:
by a network device, calculating a plurality of maximally redundant trees from an ingress network device to a plurality of egress network devices based on a network graph, in which each of the plurality of maximally redundant trees comprises a spanning tree to the plurality of egress network devices rooted at the ingress network device, wherein each of the maximally redundant trees is calculated to comprise a point to multipoint (p2mp) path from the ingress network device to the plurality of egress network devices that is as disjoint as possible from a respective p2mp path from the ingress network device to the plurality of egress network devices for each other one of the plurality of maximally redundant trees, and wherein the maximally redundant trees are calculated such that each link along each of the plurality of maximally redundant trees satisfies a specified traffic-engineering constraint;
in response to determining, by the network device, that the plurality of maximally redundant trees include at least one node whose removal partitions a network represented by the network graph:
modifying, by the network device, the specified traffic-engineering constraint to have a less restrictive value;
modifying the network graph to add links to the network graph that satisfy the modified traffic-engineering constraint to obtain a modified network graph; and
re-calculating, by the network device, at least a portion of the plurality of maximally redundant trees based on the modified network graph to obtain a plurality of maximally redundant trees in which at least two nodes must be removed before the network is partitioned; and
with the ingress network device, establishing a plurality of p2mp label switched paths (LSPs) from the ingress network device to the plurality of egress network devices along each of the plurality of maximally redundant trees in which at least two nodes must be removed before the network is partitioned, wherein each of the p2mp LSPs corresponds to a different one of the plurality of maximally redundant trees in which at least two nodes must be removed before the network is partitioned.
15. A network device comprising:
a processor;
a constrained maximally redundant tree module configured for execution by the processor to calculate a plurality of maximally redundant trees from the network device to a plurality of egress network devices based on a network graph, in which each of the plurality of maximally redundant trees comprises a spanning tree to the plurality of egress network devices rooted at the network device, wherein each of the maximally redundant trees is calculated to comprise a point to multipoint (p2mp) path from the network device to the plurality of egress network devices that is as disjoint as possible from a respective p2mp path from the network device to the plurality of egress network devices for each other one of the plurality of maximally redundant trees, and wherein the maximally redundant trees are calculated such that each link along each of the plurality of maximally redundant trees satisfies a specified traffic-engineering constraint,
wherein the constrained maximally redundant tree module is configured to, in response to determining that the plurality of maximally redundant trees includes at least one node whose removal partitions a network represented by the network graph:
modify the specified traffic-engineering constraint to have a less restrictive value;
modify the network graph to add links to the network graph that satisfy the modified traffic-engineering constraint to obtain a modified network graph; and
re-calculate at least a portion of the plurality of maximally redundant trees based on the modified network graph to obtain a plurality of maximally redundant trees in which at least two nodes must be removed before the network is partitioned; and
a resource reservation protocol module configured for execution by the processor to establish a plurality of p2mp label switched paths (LSPs) from the network device as an ingress network device to the plurality of egress network devices along each of the plurality of maximally redundant trees in which at least two nodes must be removed before the network is partitioned, wherein each of the p2mp LSPs corresponds to a different one of the plurality of maximally redundant trees in which at least two nodes must be removed before the network is partitioned.
2. The method of
concurrently sending multicast traffic from a multicast source device to a plurality of destination devices on each p2mp LSP of the plurality of p2mp LSPs.
3. The method of
4. The method of
5. The method of
6. The method of
7. The method of
8. The method of
detecting a change to a network topology yielding a modified network graph; and
with the ingress network device, automatically re-calculating the plurality of maximally redundant trees based on the modified network graph.
9. The method of
prior to calculating the plurality of maximally redundant trees on the network graph, modifying the network graph to remove links from the network graph that do not satisfy the traffic-engineering constraint to obtain a modified network graph, wherein calculating the plurality of maximally redundant trees based on the network graph comprises calculating the plurality of maximally redundant trees based on the modified network graph.
10. The method of
11. The method of
12. The method of
sending resource reservation requests to label-switching routers (LSRs) along each of the maximally redundant trees, wherein the resource reservation requests each include an identifier associating the requests with the respective maximally redundant tree; and
receiving resource reservation messages in response to the resource reservation requests that specify reserved resources and labels allocated to the respective one of the plurality of p2mp LSPs to be used for forwarding network traffic to corresponding next hops, wherein the resource reservation messages each include an identifier associating the messages with the respective maximally redundant tree.
13. The method of
a maximum link bandwidth for each of the one or more network links, wherein the maximum link bandwidth defines a maximum amount of bandwidth capacity associated with a network link;
a residual bandwidth for each of the one or more network links, wherein the residual bandwidth defines an amount of bandwidth capacity for a network link that is a maximum link bandwidth less a bandwidth of the network link reserved by operation of a resource reservation protocol; and
an available bandwidth for each of the one or more network links, wherein the available bandwidth defines an amount of bandwidth capacity for the network link that is neither reserved by operation of a resource reservation protocol nor currently being used by the first router to forward traffic using unreserved resources.
14. The method of
16. The network device of
17. The network device of
18. The network device of
20. The method of
21. The method of
|
|||||||||||||||||||||||||||
The disclosure relates to computer networks and, more particularly, to forwarding network traffic within computer networks.
The term “link” is often used to refer to the connection between two devices on a computer network. The link may be a physical medium, such as a copper wire, a coaxial cable, any of a host of different fiber optic lines or a wireless connection. In addition, network devices may define “virtual” or “logical” links, and map the virtual links to the physical links. As networks grow in size and complexity, the traffic on any given link may approach a maximum bandwidth capacity for the link, thereby leading to congestion and loss.
Multi-protocol Label Switching (MPLS) is a mechanism used to engineer traffic patterns within Internet Protocol (IP) networks. By utilizing MPLS, a source device can request a path through a network, i.e., a Label Switched Path (LSP). An LSP defines a distinct path through the network to carry packets from the source device to a destination device. A short label associated with a particular LSP is affixed to packets that travel through the network via the LSP. Routers along the path cooperatively perform MPLS operations to forward the MPLS packets along the established path. LSPs may be used for a variety of traffic engineering purposes including bandwidth management and quality of service (QoS).
A variety of protocols exist for establishing LSPs. For example, one such protocol is the label distribution protocol (LDP). Procedures for LDP by which label switching routers (LSRs) distribute labels to support MPLS forwarding along normally routed paths are described in L. Anderson, “LDP Specification,” RFC 3036, Internet Engineering Task Force (IETF), January 2001, the entire contents of which are incorporated by reference herein. Another type of protocol is a resource reservation protocol, such as the Resource ReserVation Protocol with Traffic Engineering extensions (RSVP-TE). RSVP-TE uses constraint information, such as bandwidth availability, to compute and establish LSPs within a network. RSVP-TE may use bandwidth availability information accumulated by a link-state interior routing protocol, such as the Intermediate System-Intermediate System (IS-IS) protocol or the Open Shortest Path First (OSPF) protocol. RSVP-TE establishes LSPs that follow a single path from an ingress device to an egress device, and all network traffic sent on the LSP must follow exactly that single path. The use of RSVP-TE, including extensions to establish LSPs in MPLS, are described in D. Awduche, “RSVP-TE: Extensions to RSVP for LSP Tunnels,” RFC 3209, IETF, December 2001, the entire contents of which are incorporated by reference herein.
In some cases, RSVP-TE can be used to establish a point-to-multipoint (P2MP) LSP that can be used for sending traffic across a network from a single ingress to multiple egress routers. The use of RSVP-TE for establishing P2MP LSPs is described in R. Aggarwal, “Extensions to RSVP-TE for P2MP TE LSPs,” RFC 4875, May 2007, the entire contents of which are incorporated by reference herein. A P2MP LSP is comprised of multiple source-to-leaf (S2L) sub-LSPs. These S2L sub-LSPs are set up between the ingress and egress LSRs and are appropriately combined by the branch LSRs using RSVP semantics to result in a P2MP TE LSP.
In general, techniques are described for using maximally redundant trees (MRTs) to establish a set of P2MP LSPs for delivering redundant multicast streams across a network from an ingress device to multiple egress devices of the network. MRTs are a set of trees where, for each of the MRTS, a set of paths from a root node of the MRT to one or more leaf nodes share a minimum number of nodes and a minimum number of links. Techniques are described herein for a network device of a network to compute a set of MRTs that traverse links that satisfy certain constraints. For example, a network device, such as a router, can compute a set of constrained MRTs on a network graph that includes only links that satisfy one or more configured traffic-engineering (TE) constraints, such as bandwidth, link color, and the like. The network device can then use a resource reservation protocol (e.g., RSVP-TE) for establishing P2MP LSPs along the paths of the constrained MRTs to several egress network devices, yielding multiple P2MP LSPs that traverse different maximally redundant tree paths from the same ingress to egresses.
Using MRTs for computing the spanning trees for the P2MP LSPs generally provides link and node disjointness of the spanning trees to the extent physically feasible, regardless of topology, based on the topology information distributed by a link-state Interior Gateway Protocol (IGP). The techniques set forth herein provide mechanisms for handling real networks, which may not be fully 2-connected, due to previous failure or design. A 2-connected graph is a graph that requires two nodes to be removed before the network is partitioned.
The techniques may provide one or more advantages. For example, the techniques can allow for dynamically adapting in network environments in which the same traffic is sent on two or more diverse paths, such as in multicast live-live. Multicast live-live functionality can be used to reduce packet loss due to network failures on any one of the paths. The techniques of this disclosure can provide for dynamically adapting to network changes in the context of multicast live-live for RSVP-TE P2MP. The techniques can provide a mechanism that is responsive to changes in network topology without requiring manual configuration of explicit route objects or heuristic algorithms. The techniques of this disclosure do not require operator involvement to recalculate the P2MP LSPs in the case of network topology changes. The use of MRTs in this manner can provide multicast live-live functionality, and provide a mechanism for sending live-live multicast streams across an arbitrary network topology so that the disjoint trees can be dynamically recalculated by the ingress device as the network topology changes.
In one aspect, a method includes with a network device, computing a set of maximally redundant trees from an ingress network device to a plurality of egress network devices based on a network graph, in which each of the set of maximally redundant trees comprises a spanning tree to the plurality of egress network devices rooted at the ingress network device, wherein the maximally redundant trees are computed such that each of the links along each of the set of maximally redundant trees satisfies a specified traffic-engineering constraint, and with the ingress network device, establishing a plurality of point to multipoint (P2MP) label switched paths (LSPs) from the ingress network device to the plurality of egress network devices along the set of maximally redundant trees, wherein each of the P2MP LSPs corresponds to a different one of the maximally redundant trees.
In another aspect, a network device includes a constrained maximally redundant tree module to compute a set of maximally redundant trees from the network device to a plurality of egress network devices based on a network graph, in which each of the set of maximally redundant trees comprises a spanning tree to the plurality of egress network devices rooted at the network device, wherein the maximally redundant trees are computed such that each of the links along each of the set of maximally redundant trees satisfies a specified traffic-engineering constraint. The network device also includes a resource reservation protocol module to establish a plurality of P2MP LSPs from the network device as an ingress network device to the plurality of egress network devices along the set of maximally redundant trees, wherein each of the P2MP LSPs corresponds to a different one of the maximally redundant trees.
In another aspect, a computer-readable storage medium includes instructions. The instructions cause a programmable processor to compute a set of maximally redundant trees from an ingress network device to a plurality of egress network devices based on a network graph, in which each of the set of maximally redundant trees comprises a spanning tree to the plurality of egress network devices rooted at the ingress network device, wherein the maximally redundant trees are computed such that each of the links along each of the set of maximally redundant trees satisfies a specified traffic-engineering constraint, and establish a plurality of point to multipoint (P2MP) label switched paths (LSPs) from the ingress network device to the plurality of egress network devices along the set of maximally redundant trees, wherein each of the P2MP LSPs corresponds to a different one of the maximally redundant trees.
The details of one or more examples are set forth in the accompanying drawings and the description below. Other features, objects, and advantages will be apparent from the description and drawings, and from the claims.
PE routers 12 and routers 20 are coupled by links 22A-22M (“links 22”). Links 22 may be a number of physical and logical communication links that interconnect routers 12, 20 of network 14 to facilitate control and data communication between the routers. Physical links of network 14 may include, for example, Ethernet PHY, Synchronous Optical Networking (SONET)/Synchronous Digital Hierarchy (SDH), Lambda, or other Layer 2 data links that include packet transport capability. Logical links of network 14 may include, for example, an Ethernet Virtual local area network (LAN), an MPLS LSP, or an MPLS-TE LSP.
System 10 also includes multicast source device 16 sends multicast traffic into network 14 via ingress PE router 12A, and multicast receiver devices 18A-18C (“multicast receivers 18”) that receive multicast traffic from egress PE router 12C and egress PE router 12D, respectively. The multicast traffic may be, for example, multicast video or multimedia traffic. For distribution of multicast traffic, including time-sensitive or critical multicast traffic, it can be desirable for routers 12, 20 of network 14 to employ multicast live-live techniques, in which the same traffic is sent on two or more diverse paths. Multicast live-live functionality can be used to reduce packet loss due to network failures on any one of the paths. As explained in further detail below with respect to
Changes in the network topology may be communicated among routers 12, 20 in various ways, for example, by using a link-state protocol, such as interior gateway protocols (IGPs) like the Open Shortest Path First (OSPF) and Intermediate System to Intermediate System (IS-IS) protocols. That is, routers 12, 20 can use the IGPs to learn link states and link metrics for communication links 22 within the interior of network 14. If a communication link fails or a cost value associated with a network node changes, after the change in the network's state is detected by one of the routers 12, 20, that router may flood an IGP Advertisement communicating the change to the other routers in the network. In other examples, routers 12, 20 can communicate the network topology using other network protocols, such as an interior Border Gateway Protocol (iBGP), e.g., BGP-Link State (BGP-LS). In this manner, each of the routers eventually “converges” to an identical view of the network topology.
For example, ingress PE router 12A may use OSPF or IS-IS to exchange routing information with routers 12, 20. Ingress PE router 12A stores the routing information to a routing information base that ingress PE router 12A uses to compute optimal routes to destination addresses advertised within network 14. In addition, ingress PE router 12A can store to a traffic engineering database (TED) any traffic engineering (TE) metrics or constraints received via the IGPs advertisements.
In accordance with the techniques of this disclosure, ingress PE router 12A uses a method of computing the maximally redundant trees that also considers traffic-engineering constraints, such as bandwidth, link color, priority, and class type, for example. Ingress PE router 12A creates multicast trees by computing the entire trees as MRTs and signaling each branch of a P2MP LSP (e.g., using a resource reservation protocol such as RSVP-TE). As a further example, a path computation element (PCE) may alternatively or additionally provide configuration information to router 12A, e.g., may compute the MRTs and provide them to ingress router 12A. For example, network 14 may include a PCE that can learn the topology from IGP, BGP, or another mechanism and then perform a constrained MRT computation and provide the result to ingress PE router 12A.
In accordance with one example aspect of this disclosure, ingress PE router 12A computes a set of spanning trees that are maximally redundant trees (MRTs) over a network graph that represents at least a portion of links 22 and nodes (routers 12, 20) in network 14. For example, ingress PE router 12A can execute a shortest-path first (SPF) algorithm over its routing information base to compute forwarding paths through network 14 to egress PE routers 12B, 12C, and 12D. In some instances, ingress PE router 12A may execute a constrained SPF (CSPF) algorithm over its routing information base and its traffic engineering database to compute paths for P2MP LSPs subject to various constraints, such as link attribute requirements, input to the CSPF algorithm. For example, source router 212 may execute a CSPF algorithm subject to a bandwidth constraint that requires each link of a computed path from ingress PE router 12A to egress PE routers 12B, 12C, and 12D to have at least a specified amount of maximum link bandwidth, residual bandwidth, or available bandwidth.
Prior to computing the set of MRTs, ingress PE router 12A may prune from the network graph any links 22 that do not satisfy one or more specified TE constraints. In some examples, ingress PE router 12A may obtain the network graph having links that each satisfy the TE constraints by starting with an initial network graph based on stored network topology information, and pruning links of the initial network graph to remove any network links that do not satisfy the TE constraints, resulting in a modified network graph. In this example, ingress PE router 12A uses the modified network graph for computing the set of MRTs. In this manner, ingress PE router 12A computes the set of MRTs over a network graph in which all links satisfy the specified constraints, resulting in a set of “constrained MRTs.” In some examples, ingress PE router 12A may prune the links from the network graph as part of the CSPF computation.
In some aspects, ingress PE router 12A may compute the MRTs in response to receiving a request to traffic-engineer a diverse set of P2MP LSPs to the plurality of egress PE routers 12B-12D, such as to be used for multicast live-live redundancy in forwarding multicast content. For example, a network administrator may configure ingress PE router 12A with the request. The request may specify that the P2MP LSPs satisfy certain constraints, including, for example, one or more of bandwidth, link color, Shared Risk Link Group (SRLG), priority, class type, and the like.
For example, suppose that ingress PE router 12A is configured to compute a set of MRTs and establish a set of corresponding P2MP LSPs along trees in which all links have an available bandwidth of 50 megabytes per second (mBps). Assume that all of the links 22 of the initial network graph 26 of
The following terminology is used herein. A network graph is a graph that reflects the network topology where all links connect exactly two nodes and broadcast links have been transformed into the standard pseudo-node representation. The term “2-connected,” as used herein, refers to a graph that has no cut-vertices, i.e., a graph that requires two nodes to be removed before the network is partitioned. A “cut-vertex” is a vertex whose removal partitions the network. A “cut-link” is a link whose removal partitions the network. A cut-link by definition must be connected between two cut-vertices. If there are multiple parallel links, then they are referred to as cut-links in this document if removing the set of parallel links would partition the network.
A “2-connected cluster” is a maximal set of nodes that are 2-connected. The term “2-edge-connected” refers to a network graph where at least two links must be removed to partition the network. The term “block” refers to either a 2-connected cluster, a cut-edge, or an isolated vertex. A Directed Acyclic Graph (DAG) is a graph where all links are directed and there are no cycles in it. An Almost Directed Acyclic Graph (ADAG) is a graph that, if all links incoming to the root were removed, would be a DAG. A Generalized ADAG (GADAG) is a graph that is the combination of the ADAGs of all blocks. Further information on MRTs may be found at A. Atlas, “An Architecture for IP/LDP Fast-Reroute Using Maximally Redundant Trees,” Internet-Draft, draft-atlas-rtgwg-mrt-frr-architecture-01, October, 2011; A. Atlas, “Algorithms for Computing Maximally Redundant Trees for IP/LDP Fast-Reroute, Internet-Draft, draft-enyedi-rtgwg-mrt-frr-algorithm-01, November, 2011; A. Atlas, “An Architecture for Multicast Protection Using Maximally Redundant Trees,” Internet-Draft, draft-atlas-rtgwg-mrt-mc-arch-00, March 2012; the entire contents of each of which are incorporated by reference herein.
Redundant trees are directed spanning trees that provide disjoint paths towards their common root. These redundant trees only exist and provide link protection if the network graph is 2-edge-connected and node protection if the network graph is 2-connected. Such connectiveness may not be the case in real networks, either due to architecture or due to a previous failure. Maximally redundant trees are useful in a real network because they may be computable regardless of network topology. Maximally Redundant Trees (MRT) are a set of trees where the path from any node X to the root R along one tree and the path from the same node X to the root along any other tree of the set of trees share the minimum number of nodes and the minimum number of links. Each such shared node is a cut-vertex. Any shared links are cut-links. That is, the maximally redundant trees are computed so that only the cut-edges or cut-vertices are shared between the multiple trees. In any non-2-connected graph, only the cut-vertices and cut-edges can be contained by both of the paths. That is, a pair of MRTs, such as MRT 25A and MRT 25B, are a pair of trees that share a least number of links possible and share a least number of nodes possible. Any RT is an MRT but many MRTs are not RTs. MRTs are practical to maintain redundancy even after a single link or node failure. If a pair of MRTs is computed rooted at each destination, all the destinations remain reachable along one of the MRTs in the case of a single link or node failure. The MRTs of a pair of MRTs may be individually referred to as a Red MRT and a Blue MRT.
Computationally practical algorithms for computing MRTs may be based on a common network topology database. A variety of algorithms may be used to calculate MRTs for any network topology. These may result in trade-offs between computation speed and path length. Many algorithms are designed to work in real networks. For example, just as with SPF, an algorithm is based on a common network topology database, with no messaging required. In one example aspect, MRT computation for multicast Live-Live may use a path-optimized algorithm based on heuristics. Some example algorithms for computing MRTs can be found in U.S. patent application Ser. No. 13/418,212, entitled “Fast Reroute for Multicast Using Maximally Redundant Trees,” filed on Mar. 12, 2012, the entire contents of which are incorporated by reference herein.
In the example of
In one example aspect, for constraints based upon path, as compared to link attributes, the SPF-based MRT algorithm used by ingress PE router 12A can keep track of the constraint at each node, for each direction. The algorithm would then not attach to a node in the GADAG if that node would cause too large a value. If the first try does not find an acceptable tree to egress PE routers 12B, 12C, and 12D, ingress PE router 12A can be configured to relax one or more of the constraints and try again to find an acceptable tree. That is, if the re-computed pair of maximally redundant trees MRTs is not 2-connected, ingress PE router 12A may repeat the steps of modifying the specified traffic-engineering constraint, modifying the network graph, and re-computing the pair of maximally redundant trees until re-computing the pair of maximally redundant trees yields a pair of maximally redundant trees that are 2-connected.
For example, if the computed pair of maximally redundant trees MRTs is not 2-connected, ingress PE router 12A can modify the specified traffic-engineering constraint to have a less restrictive value, and modify the network graph to add back links to the network graph that satisfy the modified traffic-engineering constraint to obtain a modified network graph. Ingress PE router 12A can then re-compute the pair of maximally redundant trees based on the modified network graph, to attempt to obtain a pair of 2-connected MRTs.
There may be a trade-off between how much the network graph is pruned based on constraints, and whether this will result in a 2-connected network after the pruning. The service provider may prefer to scale back or add costs in some fashion. How this is done depends on whether it is more important to meet the constraints or more important to have path diversity. These preferences may be a configurable option on ingress PE router 12A.
So for example, ingress PE router 12A may do an initial computation based on initial specified constraints. If the resulting trees are not 2-connected, ingress PE router 12A identifies the cut nodes and cut links, looks at the links that were removed from the topology that were connected to that cut-node and cut-links, and makes a selection among the removed links based on preferences, such as cost of the removed links, or preference as to which constraint to drop off first.
In some aspects, ingress PE router 12A would not necessarily do a whole re-pruning of the entire tree, but instead might be targeted to a certain part of the tree where it is not 2-connected. This is because it may be better to only add back in additional links when needed in order to get path diversity, and the algorithm would otherwise respect the initial pruning that was done.
The paths taken by packets that traverse the network in this manner are referred to as LSPs, and in the current example may be P2MP LSPs. To establish a traffic-engineered P2MP LSP, ingress PE router 12A computes a P2MP path, and initiates signaling along the P2MP path. LSRs along the P2MP path modify their forwarding tables based on the signaling. LSRs use MPLS-TE techniques to establish LSPs that have guaranteed bandwidth under certain conditions. For example, the TE-LSPs may be signaled through the use of the RSVP protocol and, in particular, by way of RSVP-TE signaling messages sent between routers 12, 20.
In the example of
Generally stated, ingress PE router 12A establishes the first P2MP LSP 30A along the first maximally redundant tree 25A by sending resource reservation requests 32 to routers 20 (LSRs) along the first maximally redundant tree 25A. The resource reservation requests 32 can each include an identifier associating the requests with the first maximally redundant tree. In addition, ingress PE router 12A receives resource reservation messages 34 in response to the resource reservation requests 32, where the resource reservation messages 34 specify reserved resources and labels allocated to the P2MP LSP to be used for forwarding network traffic to corresponding next hops along the sub-paths of the P2MP LSP, wherein the resource reservation messages each include an identifier associating the messages with the same P2MP LSP. The same process is used for establishing the second P2MP LSP 30B along the MRT 25B.
The example of
A P2MP LSP is comprised of multiple source-to-leaf (S2L) sub-LSPs. These S2L sub-LSPs are set up between the ingress and egress LSRs and are appropriately combined by the branch LSRs using RSVP semantics to result in a P2MP TE LSP. One Path message may signal one or multiple S2L sub-LSPs for a single P2MP LSP. Hence the S2L sub-LSPs belonging to a P2MP LSP can be signaled using one Path message or split across multiple Path messages. Details of the RSVP-TE signaling semantics for establishing P2MP LSPs are described in R. Aggarwal, “Extensions to RSVP-TE for P2MP TE LSPs,” RFC 4875, May 2007, the entire contents of which are incorporated by reference herein.
After receiving a Path message 32, routers 20 may update their forwarding tables, allocate an MPLS label, and forward the Path message 32 to the next hop along the path specified in the Path message. To establish the P2MP LSP (data flow) between the receiver and the sender, egress PE routers 12D may return RSVP-TE Reserve (Resv) messages 34 upstream along the paths of the MRTs to ingress PE router 12A to confirm the attributes of the P2MP LSPs, and provide respective LSP labels.
The P2MP LSPs 30A and 30B of
After establishing the P2MP LSPs 30, ingress PE router 12A may receive multicast data traffic from multicast source device 16, and ingress PE router 12A can forward the multicast data traffic along both of P2MP LSPs 30A and 30B. That is, ingress PE router 12A concurrently sends multicast traffic received from the multicast source device 16 to the plurality of multicast receivers 18 on both of the first P2MP LSP 30A and the second P2MP LSP 30B. In this manner, ingress PE router 12A sends redundant multicast data traffic along both of P2MP LSPs 30A and 30B, which provides multicast live-live service.
The techniques of this disclosure allow for dynamically adapting multicast live-live for RSVP-TE P2MP, and provides a mechanism that is responsive to changes in network topology without requiring manual configuration of explicit route objects or heuristic algorithms. Operator involvement is not needed to recalculate the P2MP LSPs in the case of network topology changes.
If ingress PE router 12A detects that changes have occurred to the topology of system 10, ingress PE router 12A may re-compute MRTs 25, or portions of MRTs 25, to determine whether changes are needed to P2MP LSPs 30. For example, if ingress PE router 12A detects that that a new multicast receiver is added to system 10 coupled to egress PE router 12B, ingress PE router 12A can send an updated Path message to add a branch to each of P2MP LSPs 30, e.g., from router 20D to egress PE router 12B and from router 20E to egress PE router 12B, without needing to re-signal the entire P2MP LSPs 30.
For multicast live-live to provide the desired protection, a safe way is needed of transitioning multicast traffic from being sent on the pair of MRTs computed on the old topology to the pair of MRTs computed on the new topology. A make-before-break process may be used. For example, as the topology of network 14 changes, ingress PE router 12A can compute and signal a new set of MRTs (not shown), and once state for those new MRTs is successfully created and usable, ingress PE router 12A can easily transition from sending on the old MRTs 25 to sending multicast traffic on the new MRTs. Then ingress PE router 12A can then tear down the old MRTs 25.
In some aspects, ingress PE router 12A may be configured to run a periodic re-optimization of the MRT computation, which may result in a similar transition from old MRTs to new MRTs. For example, ingress PE router 12A can periodically rerun the CSPF computation to recompute the pair of MRTs, to determine whether a more optimal pair of MRTs exists on the network graph.
Router 12A can use any of a variety of advertised link bandwidths as bandwidth information for pruning a network graph to remove links that do not satisfy specified TE constraints. As one example, the advertised link bandwidth may be a “maximum link bandwidth.” The maximum link bandwidth defines a maximum amount of bandwidth capacity associated with a network link. As another example, the advertised link bandwidth may be a “residual bandwidth,” i.e., the maximum link bandwidth less the bandwidth currently reserved by operation of a resource reservation protocol, such as being reserved to RSVP-TE LSPs. This is the bandwidth available on the link for non-RSVP traffic. Residual bandwidth changes based on control-plane reservations.
As a further example, the advertised link bandwidth may be an “available bandwidth” (also referred to herein as “currently available bandwidth”). The available bandwidth is the residual bandwidth less measured bandwidth used to forward non-RSVP-TE packets. In other words, the available bandwidth defines an amount of bandwidth capacity for the network link that is neither reserved by operation of a resource reservation protocol nor currently being used by the first router to forward traffic using unreserved resources. The amount of available bandwidth on a link may change as a result of SPF, but may be a rolling average with bounded advertising frequency.
As one example, the computing router (e.g., routers 12, 20) can determine an amount of bandwidth capacity for a network link that is reserved by operation of a resource reservation protocol, and can determine an amount of bandwidth capacity that is currently being used by the router to forward traffic using unreserved resources, by monitoring traffic through the data plane of the computing router, and may calculate the amount of residual bandwidth and/or available bandwidth based on the monitored traffic.
In the example of currently available bandwidth, routers 12, 20 may advertise currently available bandwidth for the links 22 of network 16, which takes into account traffic that may otherwise be unaccounted for. That is, routers 12, 20 can monitor and advertise currently available bandwidth for a link, expressed as a rate (e.g., mBps), that takes into account bandwidth that is neither reserved via RSVP-TE nor currently in use to transport Internet Protocol (IP) packets or LDP packets over the link, where an LDP packet is a packet having an attached label distributed by LDP. Currently available bandwidth for a link is therefore neither reserved nor being used to transport traffic using unreserved resources. Routers 12, 20 can measure the amount of bandwidth in use to transport IP and LDP packets over outbound links and compute currently available bandwidth as a difference between the link capacity and the sum of reserved bandwidth and measured IP/LDP packet bandwidth.
Routers 12, 20 can exchange computed available bandwidth information for their respective outbound links as link attributes in extended link-state advertisements of a link-state interior gateway protocol and store received link attributes to a respective Traffic Engineering Database (TED) that is distinct from the generalized routing information base (including, e.g., the IGP link-state database). The computing device, such as ingress PE router 12A, may execute an IGP-TE protocol, such as OSPF-TE or IS-IS-TE that has been extended to advertise link bandwidth information. For example, routers 12, 20 may advertise a maximum link bandwidth, a residual bandwidth, or a currently available bandwidth for the links 22 of network 14 using a type-length-value (TLV) field of a link-state advertisement. As another example, an OSPF-TE protocol may be extended to include an OSPF-TE Express Path that advertises maximum link bandwidth, residual bandwidth and/or available bandwidth. Details on OSPF-TE Express Path can be found in S. Giacalone, “OSPF Traffic Engineering (TE) Express Path,” Network Working Group, Internet Draft, September 2011, the entire contents of which are incorporated by reference herein.
When router 40 receives a packet via one of input links 56, control unit 42 determines via which of output links 57 to send the packet. Control unit 42 includes routing component 44 and forwarding component 46. Routing component 44 determines one or more routes through a network, e.g., through interconnected devices such as other routers. Control unit 42 provides an operating environment for protocols 48, which are typically implemented as executable software instructions. As illustrated, protocols 48 include RSVP-TE 48A and intermediate system to intermediate system (IS-IS) 48B. Router 40 uses RSVP-TE 48A to set up LSPs. As described herein, RSVP-TE 48A is programmatically extended to allow for establishment of LSPs that include a plurality of sub-paths on which traffic is load balanced between the ingress router and the egress router of the LSPs. Protocols 48 also include Protocol Independent Multicast 48C, which can be used by router 40 for transmitting multicast traffic. Protocols 48 may include other routing protocols in addition to or instead of RSVP-TE 48A and IS-IS 48B, such as other Multi-protocol Label Switching (MPLS) protocols including LDP; or routing protocols, such as Internet Protocol (IP), the open shortest path first (OSPF), routing information protocol (RIP), border gateway protocol (BGP), interior routing protocols, other multicast protocols, or other network protocols.
By executing the routing protocols, routing component 44 identifies existing routes through the network and determines new routes through the network. Routing component 44 stores routing information in a routing information base (RIB) 50 that includes, for example, known routes through the network. RIB 50 may simultaneously include routes and associated next-hops for multiple topologies, such as the Blue MRT topology (e.g., MRT 25A) and the Red MRT topology (e.g., MRT 25B).
Forwarding component 46 stores forwarding information base (FIB) 52 that includes destinations of output links 57. FIB 52 may be generated in accordance with RIB 50. FIB 52 may be a radix tree programmed into dedicated forwarding chips, a series of tables, a complex database, a link list, a radix tree, a database, a flat file, or various other data structures. FIB 52 may include MPLS labels, such as for RSVP-TE LSPs. FIB 52 may simultaneously include labels and forwarding next-hops for multiple topologies, such as the Blue MRT topology MRT 25A and the Red MRT topology MRT 25B.
A system administrator (“ADMIN 66”) may provide configuration information to router 40 via user interface 64 (“UI 64”) included within control unit 42. For example, the system administrator 66 may configure router 40 or install software to provide constrained MRT functionality as described herein. As another example, the system administrator 66 may configure RSVP-TE 48A with a request to traffic-engineer a set of P2MP LSPs from an ingress router to a plurality of egress routers. As a further example, a path computation element (PCE) 67 may alternatively or additionally provide configuration information to router 40, e.g., may compute the set of MRTs and provide them to router 40.
Router 40 includes a data plane 68 that includes forwarding component 46. In some aspects, IFCs 54 may be considered part of data plane 68. Router 40 also includes control plane 70. Control plane 234 includes routing component 44 and user interface (UI) 64. Although described for purposes of example in terms of a router, router 40 may be, in some examples, any network device capable of performing the techniques of this disclosure, including, for example, a network device that includes routing functionality and other functionality.
As shown in
Constrained MRT module 60 computes a set of MRTs from router 40 as the ingress device, to a plurality of egress devices. Router 40 computes the set of MRTs on a network graph having links that each satisfy stored traffic engineering (TE) constraints obtained from TE constraints database 62 in the control plane 70 of router 40. In some examples, constrained MRT module 60 may obtain the network graph having links that each satisfy the TE constraints by starting with an initial network graph based on network topology information obtained from TED 58, and pruning links of the initial network graph to remove any network links that do not satisfy the TE constraints, resulting in a modified network graph. In this example, constrained MRT module 60 uses the modified network graph for computing the set of MRTs.
After computing the set of MRTs, router 40 establishes multiple P2MP LSPs from router 40 to the egress network devices, such as by using a resource reservation protocol (e.g., RSVP-TE) to send Path messages that specify a constrained path for setting up the P2MP LSPs. For example, constrained MRT module 60 invokes RSVP-TE 48A to carry out the signaling of P2MP LSPs along the trees, and each of the LSRs along the signaled tree installs the necessary forwarding state based on the signaling. For example, constrained MRT module 60 can communicate with RSVP-TE 48A to provide RSVP-TE module 48A with the computed set of MRTs to be used for signaling the P2MP LSPs. Router 40 can establish a different P2MP LSP for each MRT of the set of MRTs, such as shown in
In the example of
After computing the set of MRTs, router 40 uses RSVP-TE 48A to establish multiple P2MP LSPs from router 40 to the egress network devices (110), such as by using a resource reservation protocol (e.g., RSVP-TE) to send Path messages that specify a constrained path for setting up the P2MP LSPs. Router 40 can establish a different P2MP LSP for each MRT of the set of MRTs. In some aspects, router 40 may establish a P2MP LSP along only a subset of branches/paths of an MRT, when there are egress devices included as leaf nodes of the MRT that router 40 does not need for sending multicast traffic to any receiver devices. In this case, router 40 may establish the P2MP LSP along a subset of the computed MRT.
Ingress PE router 12A can prune from the network graph of network 14 any links that do not meet specified TE constraints (150). Ingress PE router 12A computes a set of maximally redundant trees from ingress PE router 12A to the egress devices 12B-12D on the network graph 28 (
If ingress PE router 12A finds an acceptable set of MRTs (YES branch of 154), then ingress PE router 12A can establish a P2MP LSP along each of the computed MRTs to the egress routers of interest, as described above (158).
If ingress PE router 12A does not find an acceptable set of MRTs (NO branch of 154), e.g., perhaps the pair of MRTs are not 2-connected, then ingress PE router 12A may be configured to relax one or more of the specified TE constraints (156) to obtain a new modified network graph having links that satisfy the relaxed constraints, and re-compute the set of MRTs having links that satisfy the relaxed TE constraints (152). Ingress PE router 12A may relax the TE constraints more than once, or may first relax a first specified TE constraint (e.g., link color), followed by relaxing a second specified TE constraint (e.g., bandwidth) if relaxing the link color constraint does not yield a pair of 2-connected MRT paths.
In some aspects, ingress PE router 12A would not necessarily do a whole re-pruning of the entire tree, but instead might be targeted to a certain part of the tree where it is not 2-connected. This is because it may be better to only add back in additional links when needed in order to get path diversity, and the algorithm would otherwise respect the initial pruning that was done.
The techniques described in this disclosure may be implemented, at least in part, in hardware, software, firmware or any combination thereof. For example, various aspects of the described techniques may be implemented within one or more processors, including one or more microprocessors, digital signal processors (DSPs), application specific integrated circuits (ASICs), field programmable gate arrays (FPGAs), or any other equivalent integrated or discrete logic circuitry, as well as any combinations of such components. The term “processor” or “processing circuitry” may generally refer to any of the foregoing logic circuitry, alone or in combination with other logic circuitry, or any other equivalent circuitry. A control unit comprising hardware may also perform one or more of the techniques of this disclosure.
Such hardware, software, and firmware may be implemented within the same device or within separate devices to support the various operations and functions described in this disclosure. In addition, any of the described units, modules or components may be implemented together or separately as discrete but interoperable logic devices. Depiction of different features as modules or units is intended to highlight different functional aspects and does not necessarily imply that such modules or units must be realized by separate hardware or software components. Rather, functionality associated with one or more modules or units may be performed by separate hardware or software components, or integrated within common or separate hardware or software components.
The techniques described in this disclosure may also be embodied or encoded in a computer-readable medium, such as a computer-readable storage medium, containing instructions. Instructions embedded or encoded in a computer-readable medium may cause a programmable processor, or other processor, to perform the method, e.g., when the instructions are executed. Computer-readable media may include non-transitory computer-readable storage media and transient communication media. Computer readable storage media, which is tangible and non-transitory, may include random access memory (RAM), read only memory (ROM), programmable read only memory (PROM), erasable programmable read only memory (EPROM), electronically erasable programmable read only memory (EEPROM), flash memory, a hard disk, a CD-ROM, a floppy disk, a cassette, magnetic media, optical media, or other computer-readable storage media. It should be understood that the term “computer-readable storage media” refers to physical storage media, and not signals, carrier waves, or other transient media.
Various aspects of this disclosure have been described. These and other aspects are within the scope of the following claims.
Atlas, Alia, Konstantynowicz, Maciek
| Patent | Priority | Assignee | Title |
| 10158457, | Dec 02 2014 | AVAGO TECHNOLOGIES INTERNATIONAL SALES PTE LIMITED | Coordinating frequency division multiplexing transmissions |
| 10506037, | Dec 13 2016 | Alcatel Lucent | Discovery of ingress provider edge devices in egress peering networks |
| 10554425, | Jul 28 2017 | Juniper Networks, Inc.; Juniper Networks, Inc | Maximally redundant trees to redundant multicast source nodes for multicast protection |
| 10637764, | Dec 19 2017 | Juniper Networks, Inc.; Juniper Networks, Inc | Systems and methods for facilitating transparent service mapping across multiple network transport options |
| 10666550, | Dec 07 2015 | Orange | Method for combating micro-looping during the convergence of switching tables |
| 11444793, | Jul 28 2017 | Juniper Networks, Inc | Maximally redundant trees to redundant multicast source nodes for multicast protection |
| 11467566, | Dec 04 2018 | Siemens Aktiengesellschaft | Communication device, communication terminal, communication device and method for operating a communication system for transmitting time-critical data |
| 11509568, | Sep 27 2019 | Dell Products L.P. | Protocol independent multicast designated networking device election system |
| 11539627, | Dec 28 2020 | NOKIA SOLUTIONS AND NETWORKS OY | Load balancing in packet switched networks |
| 11838201, | Jul 23 2021 | Cisco Technology, Inc. | Optimized protected segment-list determination for weighted SRLG TI-LFA protection |
| 9614726, | Jan 21 2014 | Telefonaktiebolaget L M Ericsson (publ) | Method and system for deploying maximally redundant trees in a data network |
| 9832102, | Aug 07 2013 | Telefonaktiebolaget L M Ericsson (publ); TELEFONAKTIEBOLAGET L M ERICSSON PUBL | Automatic establishment of redundant paths with cautious restoration in a packet network |
| Patent | Priority | Assignee | Title |
| 7630298, | Oct 27 2004 | Cisco Technology, Inc. | Method and apparatus for forwarding data in a data communications network |
| 8274989, | Mar 31 2006 | RPX CLEARINGHOUSE LLC | Point-to-multipoint (P2MP) resilience for GMPLS control of ethernet |
| 8351418, | Feb 19 2009 | Futurewei Technologies, Inc.; FUTUREWEI TECHNOLOGIES, INC | System and method for point to multipoint inter-domain multiprotocol label switching traffic engineering path calculation |
| 20030152024, | |||
| 20050135276, | |||
| 20060050690, | |||
| 20060087965, | |||
| 20080031130, | |||
| 20080123533, | |||
| 20080219272, | |||
| 20090010272, | |||
| 20090185478, | |||
| 20090219806, | |||
| 20100080120, | |||
| 20110051727, | |||
| 20110069609, | |||
| 20110158128, | |||
| 20110199891, | |||
| 20110211445, | |||
| 20110286336, | |||
| 20120039164, | |||
| 20120281524, | |||
| 20130077475, | |||
| 20130121169, | |||
| 20130232259, | |||
| 20130322231, | |||
| 20140016457, | |||
| WO2010055408, |
| Executed on | Assignor | Assignee | Conveyance | Frame | Reel | Doc |
| Sep 07 2012 | ATLAS, ALIA | Juniper Networks, Inc | ASSIGNMENT OF ASSIGNORS INTEREST SEE DOCUMENT FOR DETAILS | 028939 | /0255 | |
| Sep 10 2012 | KONSTANTYNOWICZ, MACIEK | Juniper Networks, Inc | ASSIGNMENT OF ASSIGNORS INTEREST SEE DOCUMENT FOR DETAILS | 028939 | /0255 | |
| Sep 11 2012 | Juniper Networks, Inc. | (assignment on the face of the patent) | / |
| Date | Maintenance Fee Events |
| Aug 23 2019 | M1551: Payment of Maintenance Fee, 4th Year, Large Entity. |
| Jul 20 2023 | M1552: Payment of Maintenance Fee, 8th Year, Large Entity. |
| Date | Maintenance Schedule |
| Feb 23 2019 | 4 years fee payment window open |
| Aug 23 2019 | 6 months grace period start (w surcharge) |
| Feb 23 2020 | patent expiry (for year 4) |
| Feb 23 2022 | 2 years to revive unintentionally abandoned end. (for year 4) |
| Feb 23 2023 | 8 years fee payment window open |
| Aug 23 2023 | 6 months grace period start (w surcharge) |
| Feb 23 2024 | patent expiry (for year 8) |
| Feb 23 2026 | 2 years to revive unintentionally abandoned end. (for year 8) |
| Feb 23 2027 | 12 years fee payment window open |
| Aug 23 2027 | 6 months grace period start (w surcharge) |
| Feb 23 2028 | patent expiry (for year 12) |
| Feb 23 2030 | 2 years to revive unintentionally abandoned end. (for year 12) |