Network Working Group. Expires: April 19, 2014 The University of Arizona M. Boucadair France Telecom October 16, 2013

Transcription

1 Network Working Group Internet-Draft Intended status: Informational Expires: April 19, 2014 J. Dong M. Zhang Huawei Technologies B. Zhang The University of Arizona M. Boucadair France Telecom October 16, 2013 Requirements for Power Aware Network draft-dong-panet-requirement-02 Abstract Energy consumption of networks is rising fast, which results in the increase of network operational costs. There are emerging demands from operators for power-aware networking (PANET) which could adaptively reduce the network energy consumption when possible. This document presents the requirements which should be considered in building a power aware network. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on April 19, Copyright Notice Dong, et al. Expires April 19, 2014 [Page 1]

2 Internet-Draft PANET Requirement October 2013 Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust s Legal Provisions Relating to IETF Documents ( in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction Requirements on Network Elements Requirements on the Whole Network Requirements on Network Control Plane Requirements on Management Plane IANA Considerations Security Considerations Acknowledgements References Normative References Informative References Authors Addresses Introduction With the increase of network services and exponential growth of traffic volume, the network operators are expanding their infrastructures with more high-capacity, full-featured network devices, which also leads to the increase of network energy consumption. Besides, today s service provider networks are mostly designed for high performance and reliability, without much consideration of energy efficiency. These networks usually have redundant routers and links, over-provisioned link capacity, and multiple paths for load-balancing and protection, which make the networks far from energy efficient. As energy price continues to rise, the increasing network energy consumption becomes a significant portion of the network operational costs. The energy consumption problem in service provider networks is detailed in [I-D.zhang-panet-problem-statement]. Some use cases of reducing network energy consumption are described in [I-D.zhang-panet-use-cases]. Dong, et al. Expires April 19, 2014 [Page 2]

3 Internet-Draft PANET Requirement October 2013 While energy consumption has become an important issue, network operators are very cautious about energy conservation solutions due to the concerns about the potential impacts on the network performance and resiliency. This document presents a set of requirements for building a Power Aware NETwork (PANET) while meeting operators requirements on performance and resiliency. 2. Requirements on Network Elements Today s network elements are mostly designed for high throughput and availability. With the increase of throughput capacity, energy consumption of network element is also rising accordingly. Since most of time the network elements in the network would not work in the full loaded state, if the energy consumption of network elements could be proportional to the carried traffic load, energy conservation could be achieved. Typically after a network element is turned on, the base energy consumption is relatively high, and the energy consumption of the device does not vary a lot from zero load state to full loaded state. While there has been a lot of efforts aiming at making the energy consumption of network device proportional to the load it carries, it is not quite easy for the network elements getting to this stage in the near term. Thus for near term energy saving, In practical the network elements should meet the following requirements: o Network elements should support a set of energy saving modes (e.g. sleeping mode, etc. as defined in IETF EMAN working group). The energy consumption under energy saving modes should be much lower than that under the normal mode. o Network elements should support the report of energy consumption and state information. o The transition between different energy modes SHOULD not cost a lot of energy, otherwise there will not be no much benefit of transiting between different energy modes. o Network elements should support the transition between different energy modes within acceptable time period, e.g. subsecond. o Network elements should support some approach of reducing the packet loss during the transition of energy modes. 3. Requirements on the Whole Network Dong, et al. Expires April 19, 2014 [Page 3]

4 Internet-Draft PANET Requirement October 2013 While energy awareness and conservation of individual network element is fundamental, currently there are many limits in reducing the energy consumption at network element level. Besides, different from terminal devices like PC and mobile phones, network elements usually cannot be shut down arbitrarily as this may affect the services carried in the network. Thus mechanisms which could reduce the energy consumption from the whole network point of view should also be considered. Most of the existing networks are over-provisioned for better service performance and redundancy, which means they are not energy efficient by default. In order to save energy, the entire network should become power aware, then it can make appropriate decisions to save energy when possible. Since in most time the network does not carry the peak traffic volume, which means there is chance for the network to coordinate network elements and create opportunity for some of the network elements to enter energy saving modes. Meanwhile, reducing energy consumption of the network should not undermine the performance of services carried by the network. For energy conservation of the whole network, the network should meet the following requirements: o The network should try to keep all the active network elements with a reasonable utilization rate, network elements with low utilization should be informed to enter energy saving modes. For example, the network elements with utilization lower than specific threshold may be put into low rate mode to reduce energy consumption, or the traffic carried by these network elements may be migrated to other paths such that these network elements could be put into sleeping mode. o With energy conservation, the network should retain enough network availability and resiliency against node and link failures. In other words, the redundancy of the network should be kept at a reasonable level, e.g. 2-connected. o Energy saving of the network should not induce increase of latency nor induce traffic loss which exceed the tolerance of the services in the network. QoS metrics such as end-to-end delay, loss and jitter should be kept at a desired level. o The network should reserve enough spare capacity or be able to react quickly to absorb traffic spikes in order to minimize packet loss due to congestions. o The network stability should be preserved. Particularly, traffic oscillation should be avoided. Dong, et al. Expires April 19, 2014 [Page 4]

5 Internet-Draft PANET Requirement October 2013 o Energy saving should not conflict with other policies (e.g. performance at the highest priority) in the network. 4. Requirements on Network Control Plane Most of the existing network control protocols do not take energy awareness or efficiency into consideration, and some protocols may not work properly when some of the network elements in the network are in energy saving modes. For example, when a network link is put into sleeping mode, the protocols run on this link may be impacted. For energy saving of the whole network, control plane should meet the following requirements: o Control plane should be able to work properly when some of the network elements are in energy saving mode. o Control plane should support the advertisement of energy related information (e.g. current energy saving mode) of network elements in the network. o Control plane should be able to coordinate the energy saving operations of network elements to achieve the overall network energy saving. o Control plane should be able to maximize the opportunity for network elements to enter the energy saving modes. o Control plane should be aware of the network elements in energy saving modes, and should be able to calculate available paths (e.g. which do not traverse the network elements in sleeping mode). o Control plane should be able to calculate the path set for all services carried by the network in a way that energy conservation of the whole network is achieved. Some considerations on control plane when using energy saving mechanism are also specified in [I-D.retana-rtgwg-eacp]. 5. Requirements on Management Plane Dong, et al. Expires April 19, 2014 [Page 5]

6 Internet-Draft PANET Requirement October 2013 Management plane would also be necessary for building a power aware network. IETF EMAN working group is working on the requirements [I-D.ietf-eman-requirements]and mechanisms for energy management. Such management requirements include identification of energy-managed devices and their components, monitoring of a series of power states and power properties. It may further includes controlling of the power supply and power states of the managed devices. 6. IANA Considerations This document makes no request of IANA. Note to RFC Editor: this section may be removed on publication as an RFC. 7. Security Considerations TBD 8. Acknowledgements TBD 9. References 9.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March Informative References [I-D.ietf-eman-requirements] Quittek, J., Chandramouli, M., Winter, R., Dietz, T., and B. Claise, "Requirements for Energy Management", draftietf-eman-requirements-14 (work in progress), May [I-D.retana-rtgwg-eacp] Retana, A., White, R., and M. Paul, "A Framework and Requirements for Energy Aware Control Planes", draftretana-rtgwg-eacp-01 (work in progress), February [I-D.zhang-panet-problem-statement] Zhang, B., Shi, J., Dong, J., Zhang, M., and M. Boucadair, "Power-Aware Networks (PANET): Problem Statement", draftzhang-panet-problem-statement-03 (work in progress), October Dong, et al. Expires April 19, 2014 [Page 6]

7 Internet-Draft PANET Requirement October 2013 [I-D.zhang-panet-use-cases] Zhang, M., Dong, J., Zhang, B., and B. Khargharia, "Use Cases for Power-Aware Networks", draft-zhang-panet-usecases-03 (work in progress), October Authors Addresses Jie Dong Huawei Technologies Beijing China Mingui Zhang Huawei Technologies Beijing China Beichuan Zhang The University of Arizona USA Mohamed Boucadair France Telecom France Dong, et al. Expires April 19, 2014 [Page 7]

8 Routing Area Working Group Internet-Draft Intended status: Informational Expires: April 24, 2014 G. Enyedi, Ed. A. Csaszar Ericsson A. Atlas, Ed. C. Bowers Juniper Networks A. Gopalan University of Arizona October 21, 2013 Algorithms for computing Maximally Redundant Trees for IP/LDP Fast- Reroute draft-enyedi-rtgwg-mrt-frr-algorithm-04 Abstract A complete solution for IP and LDP Fast-Reroute using Maximally Redundant Trees is presented in [I-D.ietf-rtgwg-mrt-frrarchitecture]. This document defines the associated MRT Lowpoint algorithm that is used in the default MRT profile to compute both the necessary Maximally Redundant Trees with their associated next-hops and the alternates to select for MRT-FRR. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on April 24, Copyright Notice Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust s Legal Provisions Relating to IETF Documents Enyedi, et al. Expires April 24, 2014 [Page 1]

9 Internet-Draft MRT FRR Algorithm October 2013 ( in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction Terminology and Definitions Algorithm Key Concepts Partial Ordering for Disjoint Paths Finding an Ear and the Correct Direction Low-Point Values and Their Uses Blocks in a Graph Determining Local-Root and Assigning Block-ID Algorithm Sections MRT Island Identification Root Selection Initialization MRT Lowpoint Algorithm: Computing GADAG using lowpoint inheritance Augmenting the GADAG by directing all links Compute MRT next-hops MRT next-hops to all nodes partially ordered with respect to the computing node MRT next-hops to all nodes not partially ordered with respect to the computing node Computing Redundant Tree next-hops in a 2-connected Graph Generalizing for graph that isn t 2-connected Complete Algorithm to Compute MRT Next-Hops Identify MRT alternates Finding FRR Next-Hops for Proxy-Nodes MRT Lowpoint Algorithm: Complete Specification Algorithm Alternatives and Evaluation Algorithm Evaluation Algorithm Work to Be Done IANA Considerations Security Considerations References Normative References Informative References Appendix A. Option 2: Computing GADAG using SPFs Appendix B. Option 3: Computing GADAG using a hybrid method.. 53 Authors Addresses Enyedi, et al. Expires April 24, 2014 [Page 2]

10 Internet-Draft MRT FRR Algorithm October Introduction MRT Fast-Reroute requires that packets can be forwarded not only on the shortest-path tree, but also on two Maximally Redundant Trees (MRTs), referred to as the MRT-Blue and the MRT-Red. A router which experiences a local failure must also have pre-determined which alternate to use. This document defines how to compute these three things for use in MRT-FRR and describes the algorithm design decisions and rationale. The algorithm is based on those presented in [MRTLinear] and expanded in [EnyediThesis]. Just as packets routed on a hop-by-hop basis require that each router compute a shortest-path tree which is consistent, it is necessary for each router to compute the MRT-Blue next-hops and MRT-Red next-hops in a consistent fashion. This document defines the MRT Lowpoint algorithm to be used as a standard in the default MRT profile for MRT-FRR. As now, a router s FIB will contain primary next-hops for the current shortest-path tree for forwarding traffic. In addition, a router s FIB will contain primary next-hops for the MRT-Blue for forwarding received traffic on the MRT-Blue and primary next-hops for the MRT- Red for forwarding received traffic on the MRT-Red. What alternate next-hops a point-of-local-repair (PLR) selects need not be consistent - but loops must be prevented. To reduce congestion, it is possible for multiple alternate next-hops to be selected; in the context of MRT alternates, each of those alternate next-hops would be equal-cost paths. This document defines an algorithm for selecting an appropriate MRT alternate for consideration. Other alternates, e.g. LFAs that are downstream paths, may be prefered when available and that policybased alternate selection process[i-d.ietf-rtgwg-lfa-manageability] is not captured in this document. [E]---[D]--- [E]<--[D]<-- [E]-->[D] ^ V V [R] [F] [C] [R] [F] [C] [R] [F] [C] ^ ^ V [A]---[B]--- [A]-->[B] [A]---[B]<-- (a) (b) (c) a 2-connected graph MRT-Blue towards R MRT-Red towards R Figure 1 Enyedi, et al. Expires April 24, 2014 [Page 3]

11 Internet-Draft MRT FRR Algorithm October 2013 Algorithms for computing MRTs can handle arbitrary network topologies where the whole network graph is not 2-connected, as in Figure 2, as well as the easier case where the network graph is 2-connected (Figure 1). Each MRT is a spanning tree. The pair of MRTs provide two paths from every node X to the root of the MRTs. Those paths share the minimum number of nodes and the minimum number of links. Each such shared node is a cut-vertex. Any shared links are cutlinks. [E]---[D] [J] [R] [F] [C]---[G] [A]---[B] [H] (a) a graph that isn t 2-connected [E]<--[D]<-- [J] [E]-->[D] [J] ^ ^ V V V V [R] [F] [C]<--[G] [R] [F] [C]<--[G] ^ ^ ^ ^ V V [A]-->[B] [H] [A]<--[B]<-- [H] (b) MRT-Blue towards R (c) MRT-Red towards R Figure 2 2. Terminology and Definitions network graph: 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. Redundant Trees (RT): A pair of trees where the path from any node X to the root R on the first tree is node-disjoint with the path from the same node X to the root along the second tree. These can be computed in 2-connected graphs. Maximally Redundant Trees (MRT): A pair of trees where the path from any node X to the root R along the first tree and the path from the same node X to the root along the second tree 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. Any RT is an MRT but many MRTs are not RTs. Enyedi, et al. Expires April 24, 2014 [Page 4]

12 Internet-Draft MRT FRR Algorithm October 2013 MRT-Red: MRT-Red is used to describe one of the two MRTs; it is used to described the associated forwarding topology and MT-ID. Specifically, MRT-Red is the decreasing MRT where links in the GADAG are taken in the direction from a higher topologically ordered node to a lower one. MRT-Blue: MRT-Blue is used to describe one of the two MRTs; it is used to described the associated forwarding topology and MT-ID. Specifically, MRT-Blue is the increasing MRT where links in the GADAG are taken in the direction from a lower topologically ordered node to a higher one. cut-vertex: A vertex whose removal partitions the network. cut-link: 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. 2-connected: A graph that has no cut-vertices. This is a graph that requires two nodes to be removed before the network is partitioned. spanning tree: A tree containing links that connects all nodes in the network graph. back-edge: In the context of a spanning tree computed via a depthfirst search, a back-edge is a link that connects a descendant of a node x with an ancestor of x. 2-connected cluster: A maximal set of nodes that are 2-connected. In a network graph with at least one cut-vertex, there will be multiple 2-connected clusters. block: Either a 2-connected cluster, a cut-edge, or an isolated vertex. DAG: Directed Acyclic Graph - a digraph containing no directed cycle. ADAG: Almost Directed Acyclic Graph - a digraph that can be transformed into a DAG whith removing a single node (the root node). GADAG: Generalized ADAG - a digraph, which has only ADAGs as all of its blocks. The root of such a block is the node closest to the global root (e.g. with uniform link costs). Enyedi, et al. Expires April 24, 2014 [Page 5]

13 Internet-Draft MRT FRR Algorithm October 2013 DFS: Depth-First Search DFS ancestor: A node n is a DFS ancestor of x if n is on the DFStree path from the DFS root to x. DFS descendant: A node n is a DFS descendant of x if x is on the DFS-tree path from the DFS root to n. ear: A path along not-yet-included-in-the-gadag nodes that starts at a node that is already-included-in-the-gadag and that ends at a node that is already-included-in-the-gadag. The starting and ending nodes may be the same node if it is a cut-vertex. X >> Y or Y << X: Indicates the relationship between X and Y in a partial order, such as found in a GADAG. X >> Y means that X is higher in the partial order than Y. Y << X means that Y is lower in the partial order than X. X > Y or Y < X: Indicates the relationship between X and Y in the total order, such as found via a topological sort. X > Y means that X is higher in the total order than Y. Y < X means that Y is lower in the total order than X. proxy-node: A node added to the network graph to represent a multihomed prefix or routers outside the local MRT-fast-reroutesupporting island of routers. The key property of proxy-nodes is that traffic cannot transit them. 3. Algorithm Key Concepts There are five key concepts that are critical for understanding the MRT Lowpoint algorithm and other algorithms for computing MRTs. The first is the idea of partially ordering the nodes in a network graph with regard to each other and to the GADAG root. The second is the idea of finding an ear of nodes and adding them in the correct direction. The third is the idea of a Low-Point value and how it can be used to identify cut-vertices and to find a second path towards the root. The fourth is the idea that a non-2-connected graph is made up of blocks, where a block is a 2-connected cluster, a cut-edge or an isolated node. The fifth is the idea of a local-root for each node; this is used to compute ADAGs in each block Partial Ordering for Disjoint Paths Given any two nodes X and Y in a graph, a particular total order means that either X < Y or X > Y in that total order. An example would be a graph where the nodes are ranked based upon their unique IP loopback addresses. In a partial order, there may be some nodes Enyedi, et al. Expires April 24, 2014 [Page 6]

14 Internet-Draft MRT FRR Algorithm October 2013 for which it can t be determined whether X << Y or X >> Y. A partial order can be captured in a directed graph, as shown in Figure 3. In a graphical representation, a link directed from X to Y indicates that X is a neighbor of Y in the network graph and X << Y. [A]<---[R] [E] R << A << B << C << D << E ^ R << A << B << F << G << H << D << E V Unspecified Relationships: [B]--->[C]--->[D] C and F ^ C and G C and H V [F]--->[G]--->[H] Figure 3: Directed Graph showing a Partial Order To compute MRTs, the root of the MRTs is at both the very bottom and the very top of the partial ordering. This means that from any node X, one can pick nodes higher in the order until the root is reached. Similarly, from any node X, one can pick nodes lower in the order until the root is reached. For instance, in Figure 4, from G the higher nodes picked can be traced by following the directed links and are H, D, E and R. Similarly, from G the lower nodes picked can be traced by reversing the directed links and are F, B, A, and R. A graph that represents this modified partial order is no longer a DAG; it is termed an Almost DAG (ADAG) because if the links directed to the root were removed, it would be a DAG. [A]<---[R]<---[E] R << A << B << C << R ^ ^ R << A << B << C << D << E << R R << A << B << F << G << H << D << E << R V [B]--->[C]--->[D] Unspecified Relationships: ^ C and F C and G V C and H [F]--->[G]--->[H] Figure 4: ADAG showing a Partial Order with R lowest and highest Enyedi, et al. Expires April 24, 2014 [Page 7]

15 Internet-Draft MRT FRR Algorithm October 2013 Most importantly, if a node Y >> X, then Y can only appear on the increasing path from X to the root and never on the decreasing path. Similarly, if a node Z << X, then Z can only appear on the decreasing path from X to the root and never on the inceasing path. When following the increasing paths, it is possible to pick multiple higher nodes and still have the certainty that those paths will be disjoint from the decreasing paths. E.g. in the previous example node B has multiple possibilities to forward packets along an increasing path: it can either forward packets to C or F Finding an Ear and the Correct Direction For simplicity, the basic idea of creating a GADAG by adding ears is described assuming that the network graph is a single 2-connected cluster so that an ADAG is sufficient. Generalizing to multiple blocks is done by considering the block-roots instead of the GADAG root - and the actual algorithm is given in Section 4.4. In order to understand the basic idea of finding an ADAG, first suppose that we have already a partial ADAG, which doesn t contain all the nodes in the block yet, and we want to extend it to cover all the nodes. Suppose that we find a path from a node X to Y such that X and Y are already contained by our partial ADAG, but all the remaining nodes along the path are not added to the ADAG yet. We refer to such a path as an ear. Recall that our ADAG is closely related to a partial order, more precisely, if we remove root R, the remaining DAG describes a partial order of the nodes. If we suppose that neither X nor Y is the root, we may be able to compare them. If one of them is definitely lesser with respect to our partial order (say X<<Y), we can add the new path to the ADAG in a direction from X to Y. As an example consider Figure 5. E---D--- E<--D--- E<--D<-- ^ ^ V V R F C R F C R F C ^ ^ ^ V V A---B--- A-->B--- A-->B--- (a) (b) (c) (a) A 2-connected graph (b) Partial ADAG (C is not included) (c) Resulting ADAG after adding path (or ear) B-C-D Enyedi, et al. Expires April 24, 2014 [Page 8]

16 Internet-Draft MRT FRR Algorithm October 2013 Figure 5 In this partial ADAG, node C is not yet included. However, we can find path B-C-D, where both endpoints are contained by this partial ADAG (we say those nodes are *ready* in the sequel), and the remaining node (node C) is not contained yet. If we remove R, the remaining DAG defines a partial order, and with respect to this partial order we can say that B<<D, so we can add the path to the ADAG in the direction from B to D (arcs B->C and C->D are added). If B were strictly greater than D, we would add the same path in reverse direction. If in the partial order where an ear s two ends are X and Y, X << Y, then there must already be a directed path from X to Y already in the ADAG. The ear must be added in a direction such that it doesn t create a cycle; therefore the ear must go from X to Y. In the case, when X and Y are not ordered with each other, we can select either direction for the ear. We have no restriction since neither of the directions can result in a cycle. In the corner case when one of the endpoints of an ear, say X, is the root (recall that the two endpoints must be different), we could use both directions again for the ear because the root can be considered both as smaller and as greater than Y. However, we strictly pick that direction in which the root is lower than Y. The logic for this decision is explained in Section 4.6 A partial ADAG is started by finding a cycle from the root R back to itself. This can be done by selecting a non-ready neighbor N of R and then finding a path from N to R that doesn t use any links between R and N. The direction of the cycle can be assigned either way since it is starting the ordering. Once a partial ADAG is already present, we can always add ears to it: just select a non-ready neighbor N of a ready node Q, such that Q is not the root, find a path from N to the root in the graph with Q removed. This path is an ear where the first node of the ear is Q, the next is N, then the path until the first ready node the path reached (that second ready node is the other endpoint of the path). Since the graph is 2-connected, there must be a path from N to R without Q. Enyedi, et al. Expires April 24, 2014 [Page 9]

17 Internet-Draft MRT FRR Algorithm October 2013 It is always possible to select a non-ready neighbor N of a ready node Q so that Q is not the root R. Because the network is 2-connected, N must be connected to two different nodes and only one can be R. Because the initial cycle has already been added to the ADAG, there are ready nodes that are not R. Since the graph is 2-connected, while there are non-ready nodes, there must be a nonready neighbor N of a ready node that is not R. Generic_Find_Ears_ADAG(root) Create an empty ADAG. Add root to the ADAG. Mark root as IN_GADAG. Select an arbitrary cycle containing root. Add the arbitrary cycle to the ADAG. Mark cycle s nodes as IN_GADAG. Add cycle s non-root nodes to process_list. while there exists connected nodes in graph that are not IN_GADAG Select a new ear. Let its endpoints be X and Y. if Y is root or (Y << X) add the ear towards X to the ADAG else // (a) X is root or (b)x << Y or (c) X, Y not ordered Add the ear towards Y to the ADAG Figure 6: Generic Algorithm to find ears and their direction in 2-connected graph Algorithm Figure 6 merely requires that a cycle or ear be selected without specifying how. Regardless of the way of selecting the path, we will get an ADAG. The method used for finding and selecting the ears is important; shorter ears result in shorter paths along the MRTs. The MRT Lowpoint algorithm s method using Low-Point Inheritance is defined in Section 4.4. Other methods are described in the Appendices (Appendix A and Appendix B). As an example, consider Figure 5 again. First, we select the shortest cycle containing R, which can be R-A-B-F-D-E (uniform link costs were assumed), so we get to the situation depicted in Figure 5 (b). Finally, we find a node next to a ready node; that must be node C and assume we reached it from ready node B. We search a path from C to R without B in the original graph. The first ready node along this is node D, so the open ear is B-C-D. Since B<<D, we add arc B->C and C->D to the ADAG. Since all the nodes are ready, we stop at this point. Enyedi, et al. Expires April 24, 2014 [Page 10]

18 Internet-Draft MRT FRR Algorithm October Low-Point Values and Their Uses A basic way of computing a spanning tree on a network graph is to run a depth-first-search, such as given in Figure 7. This tree has the important property that if there is a link (x, n), then either n is a DFS ancestor of x or n is a DFS descendant of x. In other words, either n is on the path from the root to x or x is on the path from the root to n. global_variable: dfs_number DFS_Visit(node x, node parent) D(x) = dfs_number dfs_number += 1 x.dfs_parent = parent for each link (x, w) if D(w) is not set DFS_Visit(w, x) Run_DFS(node root) dfs_number = 0 DFS_Visit(root, NONE) Figure 7: Basic Depth-First Search algorithm Given a node x, one can compute the minimal DFS number of the neighbours of x, i.e. min( D(w) if (x,w) is a link). This gives the highest attachment point neighbouring x. What is interesting, though, is what is the highest attachment point from x and x s descendants. This is what is determined by computing the Low-Point value, as given in Algorithm Figure 9 and illustrated on a graph in Figure 8. [E]--- [J] [I] [P]---[O] [R] [D]---[C]--[F] [H]---[K] [N] [A] [B] [G]--- [L]---[M] (a) a non-2-connected graph [E]---- [J] [I] [P]------[O] (5, ) (10, ) (9, ) (16, ) (15, ) [R] [D]---[C]---[F] [H]----[K] [N] Enyedi, et al. Expires April 24, 2014 [Page 11]

19 Internet-Draft MRT FRR Algorithm October 2013 (0, ) (4, ) (3, ) (6, ) (8, ) (11, ) (14, ) [A] [B] [G]---- [L]------[M] (1, ) (2, ) (7, ) (12, ) (13, ) (b) with DFS values assigned (D(x), L(x)) [E]---- [J] [I] [P]------[O] (5,0) (10,3) (9,3) (16,11) (15,11) [R] [D]---[C]---[F] [H]----[K] [N] (0, ) (4,0) (3,0) (6,3) (8,3) (11,11) (14,11) [A] [B] [G]---- [L]------[M] (1,0) (2,0) (7,3) (12,11) (13,11) (c) with low-point values assigned (D(x), L(x)) Figure 8 global_variable: dfs_number Lowpoint_Visit(node x, node parent, interface p_to_x) D(x) = dfs_number L(x) = D(x) dfs_number += 1 x.dfs_parent = parent x.dfs_parent_intf = p_to_x x.lowpoint_parent = NONE for each interface intf of x: if D(intf.remote_node) is not set Lowpoint_Visit(intf.remote_node, x, intf) if L(intf.remote_node) < L(x) L(x) = L(intf.remote_node) x.lowpoint_parent = intf.remote_node x.lowpoint_parent_intf = intf else if intf.remote_node is not parent if D(intf.remote_node) < L(x) L(x) = D(intf.remote) x.lowpoint_parent = intf.remote_node x.lowpoint_parent_intf = intf Run_Lowpoint(node root) dfs_number = 0 Enyedi, et al. Expires April 24, 2014 [Page 12]

20 Internet-Draft MRT FRR Algorithm October 2013 Lowpoint_Visit(root, NONE, NONE) Figure 9: Computing Low-Point value From the low-point value and lowpoint parent, there are two very useful things which motivate our computation. First, if there is a child c of x such that L(c) >= D(x), then there are no paths in the network graph that go from c or its descendants to an ancestor of x - and therefore x is a cut-vertex. This is useful because it allows identification of the cut-vertices and thus the blocks. As seen in Figure 8, even if L(x) < D(x), there may be a block that contains both the root and a DFS-child of a node while other DFS-children might be in different blocks. In this example, C s child D is in the same block as R while F is not. Second, by repeatedly following the path given by lowpoint_parent, there is a path from x back to an ancestor of x that does not use the link [x, x.dfs_parent] in either direction. The full path need not be taken, but this gives a way of finding an initial cycle and then ears Blocks in a Graph A key idea for an MRT algorithm is that any non-2-connected graph is made up by blocks (e.g. 2-connected clusters, cut-links, and/or isolated nodes). To compute GADAGs and thus MRTs, computation is done in each block to compute ADAGs or Redundant Trees and then those ADAGs or Redundant Trees are combined into a GADAG or MRT. [E]--- [J] [I] [P]---[O] [R] [D]---[C]--[F] [H]---[K] [N] [A] [B] [G]--- [L]---[M] (a) A graph with four blocks that are: 3 2-connected clusters and a cut-link [E]<-- [J]<------[I] [P]<--[O] ^ ^ V V V [R] [D]<--[C] [F] [H]<---[K] [N] ^ ^ ^ V Enyedi, et al. Expires April 24, 2014 [Page 13]

21 Internet-Draft MRT FRR Algorithm October 2013 [A] >[B] [G]--- [L]-->[M] (b) MRT-Blue [E]--- [J] >[I] [P]-->[O] V V V [R] [D]-->[C]<---[F] [H]<---[K] [N] ^ ^ ^ V V [A]< [B] [G]<-- [L]<--[M] (c) MRT-Red Figure 10 Consider the example depicted in Figure 10 (a). In this figure, a special graph is presented, showing us all the ways 2-connected clusters can be connected. It has four blocks: block 1 contains R, A, B, C, D, E, block 2 contains C, F, G, H, I, J, block 3 contains K, L, M, N, O, P, and block 4 is a cut-edge containing H and K. As can be observed, the first two blocks have one common node (node C) and blocks 2 and 3 do not have any common node, but they are connected through a cut-edge that is block 4. No two blocks can have more than one common node, since two blocks with at least 2 common nodes would qualify as a single 2-connected cluster. Moreover, observe that if we want to get from one block to another, we must use a cut-vertex (the cut-vertices in this graph are C, H, K), regardless of the path selected, so we can say that all the paths from block 3 along the MRTs rooted at R will cross K first. This observation means that if we want to find a pair of MRTs rooted at R, then we need to build up a pair of RTs in block 3 with K as a root. Similarly, we need to find another one in block 2 with C as a root, and finally, we need the last one in block 1 with R as a root. When all the trees are selected, we can simply combine them; when a block is a cut-edge (as in block 4), that cut-edge is added in the same direction to both of the trees. The resulting trees are depicted in Figure 10 (b) and (c). Similarly, to create a GADAG it is sufficient to compute ADAGs in each block and connect them. It is necessary, therefore, to identify the cut-vertices, the blocks and identify the appropriate local-root to use for each block. Enyedi, et al. Expires April 24, 2014 [Page 14]

22 Internet-Draft MRT FRR Algorithm October Determining Local-Root and Assigning Block-ID Each node in a network graph has a local-root, which is the cutvertex (or root) in the same block that is closest to the root. The local-root is used to determine whether two nodes share a common block. Compute_Localroot(node x, node localroot) x.localroot = localroot for each DFS child c if L(c) < D(x) //x is not a cut-vertex Compute_Localroot(c, x.localroot) else mark x as cut-vertex Compute_Localroot(c, x) Compute_Localroot(root, root) Figure 11: A method for computing local-roots There are two different ways of computing the local-root for each node. The stand-alone method is given in Figure 11 and better illustrates the concept; it is used by the MRT algorithms given in the Appendices Appendix A and Appendix B. The method for local-root computation is used in the MRT Lowpoint algorithm for computing a GADAG using Low-Point inheritance and the essence of it is given in Figure 12. Get the current node, s. Compute an ear(either through lowpoint inheritance or by following dfs parents) from s to a ready node e. (Thus, s is not e, if there is such ear.) if s is e for each node x in the ear that is not s x.localroot = s else for each node x in the ear that is not s or e x.localroot = e.localroot Figure 12: Ear-based method for computing local-roots Once the local-roots are known, two nodes X and Y are in a common block if and only if one of the following three conditions apply. o Y s local-root is X s local-root : They are in the same block and neither is the cut-vertex closest to the root. Enyedi, et al. Expires April 24, 2014 [Page 15]

23 Internet-Draft MRT FRR Algorithm October 2013 o Y s local-root is X: X is the cut-vertex closest to the root for Y s block o Y is X s local-root: Y is the cut-vertex closest to the root for X s block Once we have computed the local-root for each node in the network graph, we can assign for each node, a block id that represents the block in which the node is present. This computation is shown in Figure Algorithm Sections global_var: max_block_id Assign_Block_ID(x, cur_block_id) x.block_id = cur_block_id foreach DFS child c of x if (c.local_root is x) max_block_id += 1 Assign_Block_ID(c, max_block_id) else Assign_Block_ID(c, cur_block_id) max_block_id = 0 Assign_Block_ID(root, max_block_id) Figure 13: Assigning block id to identify blocks This algorithm computes one GADAG that is then used by a router to determine its MRT-Blue and MRT-Red next-hops to all destinations. Finally, based upon that information, alternates are selected for each next-hop to each destination. The different parts of this algorithm are described below. These work on a network graph after, for instance, its interfaces are ordered as per Figure Compute the local MRT Island for the particular MRT Profile. [See Section 4.1.] 2. Select the root to use for the GADAG. [See Section 4.2.] 3. Initialize all interfaces to UNDIRECTED. [See Section 4.3.] 4. Compute the DFS value,e.g. D(x), and lowpoint value, L(x). [See Figure 9.] 5. Construct the GADAG. [See Section 4.4] Enyedi, et al. Expires April 24, 2014 [Page 16]

24 Internet-Draft MRT FRR Algorithm October Assign directions to all interfaces that are still UNDIRECTED. [See Section 4.5.] 7. From the computing router x, compute the next-hops for the MRT- Blue and MRT-Red. [See Section 4.6.] 8. Identify alternates for each next-hop to each destination by determining which one of the blue MRT and the red MRT the computing router x should select. [See Section 4.7.] To ensure consistency in computation, all routers MUST order interfaces identically. This is necessary for the DFS, where the selection order of the interfaces to explore results in different trees, and for computing the GADAG, where the selection order of the interfaces to use to form ears can result in different GADAGs. The required ordering between two interfaces from the same router x is given in Figure 14. Interface_Compare(interface a, interface b) if a.metric < b.metric return A_LESS_THAN_B if b.metric < a.metric return B_LESS_THAN_A if a.neighbor.loopback_addr < b.neighbor.loopback_addr return A_LESS_THAN_B if b.neighbor.loopback_addr < a.neighbor.loopback_addr return B_LESS_THAN_A // Same metric to same node, so the order doesn t matter anymore. // To have a unique, consistent total order, // tie-break based on, for example, the link s linkdata as // distributed in an OSPF Router-LSA if a.link_data < b.link_data return A_LESS_THAN_B return B_LESS_THAN_A Figure 14: Rules for ranking multiple interfaces. Order is from low to high MRT Island Identification The local MRT Island for a particular MRT profile can be determined by starting from the computing router in the network graph and doing a breadth-first-search (BFS), exploring only links that aren t MRTineligible. MRT_Island_Identification(topology, computing_rtr, profile_id) for all routers in topology rtr.in_mrt_island = FALSE Enyedi, et al. Expires April 24, 2014 [Page 17]

25 Internet-Draft MRT FRR Algorithm October 2013 computing_rtr.in_mrt_island = TRUE explore_list = { computing_rtr } while (explore_list is not empty) next_rtr = remove_head(explore_list) for each interface in next_rtr if interface is not MRT-ineligible if ((interface.remote_node supports profile_id) and (interface.remote_node.in_mrt_island is FALSE)) interface.remote_node.in_mrt_island = TRUE add_to_tail(explore_list, interface.remote_node) 4.2. Root Selection Figure 15: MRT Island Identification In [I-D.atlas-ospf-mrt], a mechanism is given for routers to advertise the GADAG Root Selection Priority and consistently select a GADAG Root inside the local MRT Island. Before beginning computation, the network graph is reduced to contain only the set of routers that support the specific MRT profile whose MRTs are being computed. Off-line analysis that considers the centrality of a router may help determine how good a choice a particular router is for the role of GADAG root Initialization Before running the algorithm, there is the standard type of initialization to be done, such as clearing any computed DFS-values, lowpoint-values, DFS-parents, lowpoint-parents, any MRT-computed next-hops, and flags associated with algorithm. It is assumed that a regular SPF computation has been run so that the primary next-hops from the computing router to each destination are known. This is required for determining alternates at the last step. Initially, all interfaces must be initialized to UNDIRECTED. Whether they are OUTGOING, INCOMING or both is determined when the GADAG is constructed and augmented. It is possible that some links and nodes will be marked as unusable, whether because of configuration, IGP flooding (e.g. MRT-ineligible links in [I-D.atlas-ospf-mrt]), overload, or due to a transient cause such as [RFC3137]. In the algorithm description, it is assumed that such links and nodes will not be explored or used and no more discussion is given of this restriction. Enyedi, et al. Expires April 24, 2014 [Page 18]

26 Internet-Draft MRT FRR Algorithm October MRT Lowpoint Algorithm: Computing GADAG using lowpoint inheritance As discussed in Section 3.2, it is necessary to find ears from a node x that is already in the GADAG (known as IN_GADAG). There are two methods to find ears; both are required. The first is by going to a not IN_GADAG DFS-child and then following the chain of low-point parents until an IN_GADAG node is found. The second is by going to a not IN_GADAG neighbor and then following the chain of DFS parents until an IN_GADAG node is found. As an ear is found, the associated interfaces are marked based on the direction taken. The nodes in the ear are marked as IN_GADAG. In the algorithm, first the ears via DFS-children are found and then the ears via DFS-neighbors are found. By adding both types of ears when an IN_GADAG node is processed, all ears that connect to that node are found. The order in which the IN_GADAG nodes is processed is, of course, key to the algorithm. The order is a stack of ears so the most recent ear is found at the top of the stack. Of course, the stack stores nodes and not ears, so an ordered list of nodes, from the first node in the ear to the last node in the ear, is created as the ear is explored and then that list is pushed onto the stack. Each ear represents a partial order (see Figure 4) and processing the nodes in order along each ear ensures that all ears connecting to a node are found before a node higher in the partial order has its ears explored. This means that the direction of the links in the ear is always from the node x being processed towards the other end of the ear. Additionally, by using a stack of ears, this means that any unprocessed nodes in previous ears can only be ordered higher than nodes in the ears below it on the stack. In this algorithm that depends upon Low-Point inheritance, it is necessary that every node have a low-point parent that is not itself. If a node is a cut-vertex, that may not yet be the case. Therefore, any nodes without a low-point parent will have their low-point parent set to their DFS parent and their low-point value set to the DFSvalue of their parent. This assignment also properly allows an ear between two cut-vertices. Finally, the algorithm simultaneously computes each node s localroot, as described in Figure 12. This is further elaborated as follows. The local-root can be inherited from the node at the end of the ear unless the end of the ear is x itself, in which case the local-root for all the nodes in the ear would be x. This is because whenever the first cycle is found in a block, or an ear involving a bridge is computed, the cut-vertex closest to the root would be x itself. In all other scenarios, the properties of lowpoint/dfs parents ensure that the end of the ear will be in the same block, and Enyedi, et al. Expires April 24, 2014 [Page 19]

27 Internet-Draft MRT FRR Algorithm October 2013 thus inheriting its local-root would be the correct local-root for all newly added nodes. The pseudo-code for the GADAG algorithm (assuming that the adjustment of lowpoint for cut-vertices has been made) is shown in Figure 16. Construct_Ear(x, Stack, intf, type) ear_list = empty cur_node = intf.remote_node cur_intf = intf not_done = true while not_done cur_intf.undirected = false cur_intf.outgoing = true cur_intf.remote_intf.undirected = false cur_intf.remote_intf.incoming = true if cur_node.in_gadag is false cur_node.in_gadag = true add_to_list_end(ear_list, cur_node) if type is CHILD cur_intf = cur_node.lowpoint_parent_intf cur_node = cur_node.lowpoint_parent else type must be NEIGHBOR cur_intf = cur_node.dfs_parent_intf cur_node = cur_node.dfs_parent else not_done = false if (type is CHILD) and (cur_node is x) //x is a cut-vertex and the local root for //the block in which the ear is computed localroot = x else // Inherit local-root from the end of the ear localroot = cur_node.localroot while ear_list is not empty y = remove_end_item_from_list(ear_list) y.localroot = localroot push(stack, y) Construct_GADAG_via_Lowpoint(topology, root) root.in_gadag = true root.localroot = root Initialize Stack to empty push root onto Stack while (Stack is not empty) Enyedi, et al. Expires April 24, 2014 [Page 20]