Applicability of Maximally Redundant Trees to IEEE 802.1Qca Path Control and Reservation

IEEE 802.1Qaq Shortest Path Bridging (SPB) is an amendment to IEEE Std 802.1Q that allows bridged frames to travel on the shortest path between their source and destination(s), as opposed to traveling along paths determined by shared spanning trees. and specify extensions to IS-IS that allow bridges to share the topology information needed to construct shortest path trees. These extensions are referred to here as ISIS-SPB. has been already incorporated in . is an amendment to that specifies explicit path control, bandwidth assignment, and protection mechanisms for data flows for bridged networks. is an extension to IS-IS that builds upon the ISIS-SPB extensions and extends them further as described in . These extensions (referred to here as ISIS-PCR) allow bridges to share the information needed to construct explicit trees. specifies five different methods for the construction of explicit trees as well as how to share the information needed to construct these trees. These five different methods of explicit trees are referred to as Strict Tree, Loose Tree, Loose Tree Set, MRT, and MRT with GADAG. This document is concerned with the MRT and 'MRT with GAGAG' explicit tree methods (algorithms). Both methods produce Maximally Redundant Trees (MRTs) . This document is intended to explain the relationship between and . The text should not be interpreted as normative with respect to either.

The algorithm for computing Maximally Redundant Trees in has been specified with a focus on supporting fast-reroute for the protection of unicast IP and LDP traffic, as described in . The computation described in starts with the topology of an IGP area, prunes it to form an MRT Island topology, constructs a GADAG, and then uses that GADAG to construct a complete set of destination-based MRT-Blue and MRT-Red trees rooted at each node in the MRT Island, where each tree spans all nodes in the MRT Island. supports this mode of operation, but it also supports other modes of operation as described below.

In , the flooding of an SPB Instance sub-TLV () with the MRT ECT Algorithm value in the absence of a Topology sub-TLV () results in the creation of an MRT-Blue and an MRT-Red tree rooted at each node in the domain, and each tree spans all nodes in the domain. This is equivalent to the behavior described in . In addition, allows one to affect both the number and structure of the MRT-Blue and Red trees by including the Topology sub-TLV in the MT-Capability TLV (type 144 ). In the context of the MRT ECT Algorithm, Hop sub-TLVs in the Topology sub-TLV specify nodes with flags that can indicate Root, Exclude, or Edge Bridge. In the context of the MRT algorithm, all nodes with the Exclude flag set are excluded from the MRT Island. The GADAG is then computed for the MRT Island. For each node with the Root flag set, an MRT-Blue and an MRT-Red tree rooted at that node is constructed. Note that the Edge Bridge flag does not affect the construction of the MRTs. It is used to determine which filtering database (FDB) entries to install once the trees have been determined.

In the previous section, each node will compute the same GADAG based on the same topology information using the algorithm steps in sections 5.4 and 5.5 of . Each node then applies the algorithm steps in section 5.6.5 of to that GADAG, in order to compute the MRT-Blue and MRT-Red next-hops for the trees of interest. can operate in a mode where each node is supplied with a common GADAG (communicated via ISIS-PCR), from which each node then determines the MRT-Blue and MRT-Red next-hops for the trees of interest. That is, this mode of operation bypasses the algorithm steps in section 5.4 and 5.5 of and only applies the algorithm steps in section 5.6.5 to the GADAG communicated directly via ISIS-PCR. This behavior is controlled in by flooding an SPB Instance sub-TLV with the 'MRT with GADAG' ECT Algorithm value as well as a Topology sub-TLV. Hop sub-TLVs in this Topology sub-TLV are used to describe the common GADAG using an ear decomposition. The first Hop sub-TLV is the GADAG root followed by a sequence of Hop sub-TLVs describing an ordered ear that terminates on the GADAG root. Subsequent ears are described as sequences of Hop sub-TLVs. Setting the Root flag for a given Hop sub-TLV indicates that MRT-Blue and Red trees rooted at that node should be constructed.

A Path Computation Element can also implement each computation step of and compute the MRTs. The MRTs can be then specified by Topology sub-TLVs, one for each. The SPB Instance sub-TLV then conveys the ST ECT Algorithm value.

specifies that if two SPB Link Metrics are different at each end of a link, the maximum of the two values is used in SPB calculations. In order to provide symmetry and maintain consistency with , places the same requirement on the Link Metrics for the topology graph that is used in the MRT algorithm. In order to accomplish this, makes the same modification to link metrics before applying the MRT algorithm. This change of metric values can affect the ordering of interfaces on a given node through the Interface_Compare function in section 5 of , which in turn can affect the GADAG computed. The change of metric values can also affect the results of the SPF_No_Traverse_Root function used in determining MRT next-hops, since the SPF traversal depends on metric values. This modification of link metrics applies ONLY to . When the MRT lowpoint inheritance algorithm in is applied to IP/LDP FRR, the topology graph with the link metrics advertised by the IGP are used without modification by the MRT algorithm.

In the algorithm described in a given node computes and installs its own MRT-Blue and MRT-Red next-hops for all destinations. This computation is all that is required for the IP/LDP FRR application to function properly. An individual node does not need to compute the MRT-Blue and MRT-Red next-hops used by other nodes. Instead the complete MRT tree structure is created in the network as the result of each node computing and installing the appropriate MRT next-hops. This is analogous to the way that shortest path trees are instantiated in shortest path routing, with each node needing to compute and install only its own shortest path next-hops. In some scenarios, a bridge using may need to know more than just its own MRT-Blue and MRT-Red next-hops. This can be accomplished by having a bridge perform the MRT next-hop computation specified in section 5.6.5 of from the point of view of one or more other bridges. The result of computing an MRT next-hop from the point of view of another bridge is the normative result. An implementation may use another method to compute MRT next-hops from the point of view of remote bridges as long as it produces the same result. This does not modify the MRT algorithm with respect to its use for the IP/LDP FRR application as described in .

MRTs can be used for the protection of SPTs in a bridged network similarly to IP/LDP FRR application of MRTs. A pair of MRT-Blue and MRT-Red then protect the SPT rooted at the MRT Root. The MRTs are only used for protection, i.e. MRTs do not carry traffic during normal operation, similarly to IP/LDP FRR operations. The Point of Local Repair (PLR) is responsible for redirecting traffic from SPTs to MRTs upon detection of a failure event. In 802.1Qca, recalculation of MRTs after a topology change follows the general method specified in Section 12.2 of , with an additional requirement. Immediately after a failure, the PLR or PLRs redirect some traffic onto MRTs. In the meantime, all nodes receive notification of the failure, recompute SPTs, and install them in their FIBs. The PLRs take the traffic off of the MRTs, and put the traffic on the new SPTs. Based on , at this point it is safe recompute and install the new MRTs corresponding to the new topology. 802.1Qca places an additional requirement on when it is safe to install the new MRTs. The new MRTs should not be recomputed and installed if there is any reason to suspect that the nodes of the domain do not share a common view on the network topology. This is in order to prevent loops in the MRT paths that may be used by PLRs at the next failure event. The loop prevention method to be used for MRTs in 802.1Qca is the Agreement Protocol, which is specified in and also described in . Note that while 802.1Qca requires that the Agreement Protocol be used to avoid loops on MRTs, it does not mandate the use of the Agreement Protocol for the shortest path trees, where other loop mitigation techniques can be used.

This document introduces no new IANA Considerations.

The ISIS-PCR extensions for the use of the MRT algorithm are not believed to introduce new security concerns.

The authors would like to thank Alvaro Retana for his suggestions and review.