--- 1/draft-ietf-teas-rsvp-rmr-extension-00.txt 2018-06-29 15:13:18.804866273 -0700 +++ 2/draft-ietf-teas-rsvp-rmr-extension-01.txt 2018-06-29 15:13:18.836867051 -0700 @@ -1,132 +1,138 @@ TEAS WG A. Deshmukh Internet-Draft K. Kompella Intended status: Standards Track Juniper Networks, Inc. -Expires: December 21, 2018 June 19, 2018 +Expires: December 30, 2018 June 28, 2018 RSVP Extensions for RMR - draft-ietf-teas-rsvp-rmr-extension-00 + draft-ietf-teas-rsvp-rmr-extension-01 Abstract - Rings are the most common topology in access and aggregation - networks. However, the use of MPLS as the transport protocol for - rings is very limited today. draft-ietf-mpls-rmr-02 describes a - mechanism to handle rings efficiently using MPLS. This document - describes the extensions to the RSVP protocol for signaling MPLS - label switched paths in rings. - -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 [RFC2119]. + Ring topology is commonly found in access and aggregation networks. + However, the use of MPLS as the transport protocol for rings is very + limited today. draft-ietf-mpls-rmr-02 describes a mechanism to + handle rings efficiently using MPLS. This document describes the + extensions to the RSVP-TE protocol for signaling MPLS label switched + paths in rings. 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 https://datatracker.ietf.org/drafts/current/. 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 December 21, 2018. + This Internet-Draft will expire on December 30, 2018. Copyright Notice Copyright (c) 2018 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 (https://trustee.ietf.org/license-info) 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 + 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. RSVP Extensions . . . . . . . . . . . . . . . . . . . . . . . 4 3.1. Session Object . . . . . . . . . . . . . . . . . . . . . 4 3.2. SENDER_TEMPLATE,FILTER_SPEC Objects . . . . . . . . . . . 5 4. Ring Signaling Procedures . . . . . . . . . . . . . . . . . . 5 4.1. Differences from regular RSVP-TE LSPs . . . . . . . . . . 5 - 4.2. LSP signaling . . . . . . . . . . . . . . . . . . . . . . 5 - 4.2.1. Path Propagation for RMR . . . . . . . . . . . . . . 7 + 4.2. LSP signaling . . . . . . . . . . . . . . . . . . . . . . 6 + 4.2.1. Path Propagation for RMR . . . . . . . . . . . . . . 8 4.2.2. Resv Processing for RMR . . . . . . . . . . . . . . . 8 4.3. Protection . . . . . . . . . . . . . . . . . . . . . . . 9 4.4. Ring changes . . . . . . . . . . . . . . . . . . . . . . 10 - 4.5. Bandwidth management . . . . . . . . . . . . . . . . . . 11 + 4.5. Express Links . . . . . . . . . . . . . . . . . . . . . . 11 + 4.6. Bandwidth management . . . . . . . . . . . . . . . . . . 11 5. Security Considerations . . . . . . . . . . . . . . . . . . . 13 6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 13 - 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 - 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 - 8.1. Normative References . . . . . . . . . . . . . . . . . . 13 + 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 + 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 + 8.1. Normative References . . . . . . . . . . . . . . . . . . 14 8.2. Informative References . . . . . . . . . . . . . . . . . 14 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 1. Introduction This document extends RSVP-TE [RFC3209] to establish label-switched path (LSP) tunnels in the ring topology. Rings are auto-discovered using the mechanisms mentioned in the [draft-ietf-mpls-rmr-02]. Either IS-IS [RFC5305] or OSPF[RFC3630] can be used as the IGP for auto-discovering the rings. - After the rings are auto-discovered, each ring node knows its + After the rings are auto-discovered, each node in the ring knows its clockwise (CW) and anti-clockwise (AC) ring neighbors and its ring links. All of the express links in the ring also get identified as part of the auto-discovery process. At this point, every node in the ring informs the RSVP protocol to begin the signaling of the ring LSPs. Section 2 covers the terminology used in this document. Section 3 presents the RSVP protocol extensions needed to support MPLS rings. Section 4 describes the procedures of RSVP LSP signaling in detail. +1.1. Requirements Language + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and + "OPTIONAL" in this document are to be interpreted as described in BCP + 14 [RFC2119] [RFC8174] when, and only when, they appear in all + capitals, as shown here. + 2. Terminology - A ring consists of a subset of n nodes {R_i, 0 <= i < n}. We define - the direction from node R_i to R_i+1 as "clockwise" (CW) and the - reverse direction as "anti-clockwise" (AC). As there may be several - rings in a graph, we number each ring with a distinct ring ID RID. + Assuming there are n nodes in the network, a ring gets formed by a + subset of those n nodes {Ri, Ri+1, Ri+2,...Rn}. We define the + direction from node Ri to Ri+1 as "clockwise" (CW) and the reverse + direction as "anti-clockwise" (AC). As there might be several rings + in a graph, each ring is identified by it's own distinct ring ID - + RID. R0 . . . R1 . . R7 R2 Anti- | . Ring . | Clockwise | . . | Clockwise v . RID = 17 . v R6 R3 . . R5 . . . R4 Figure 1: Ring with 8 nodes The following terminology is used for ring LSPs: Ring ID (RID): A non-zero number that identifies a ring; this is - unique in some scope of a Service Provider's network. A node may - belong to multiple rings. + unique in a Service Provider's network. A node may belong to + multiple rings. Ring node: A member of a ring. Note that a device may belong to several rings. Node index: A logical numbering of nodes in a ring, from zero upto one less than the ring size. Used purely for exposition in this document. Ring neighbors: Nodes whose indices differ by one (modulo ring size). @@ -161,76 +167,78 @@ | Ring ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ SESSION Object Ring anchor node address: IPv4 address of the anchor node. Each anchor node creates a LSP addressed to itself. Ring Instance ID: A 16-bit identifier used in the SESSION. This Ring Instance ID is useful for graceful ring changes. If a new - node is being added to the ring or some existing node goes down - and we have to signal a smaller ring, in those cases, anchor node - creates a new tunnel with a different Ring Instance ID. + node is being added to the ring(resulting in signaling of a larger + ring) or some existing node goes down(resulting in signaling of a + smaller ring), in those cases, anchor node creates a new tunnel + with a different Ring Instance ID. Ring ID: A 32-bit number that identifies a ring; this is unique in some scope of a Service Provider's network. This number remains constant throughout the existence of ring. Ring Flags: For each ring, the anchor node starts signaling of a - ring LSP. Ring LSP RL_i, anchored on node R_i, consists of two - counter-rotating unicast LSPs that start and end at R_i. One LSP - will be in the clockwise direction and other LSP will be in the - anti-clockwise direction. A ring LSP is "multipoint": any node - R_j can use RL_i to send traffic to R_i; this can be in either the - CW or AC directions, or both (i.e., load balanced). Two new flags - are defined in the SESSION object which define the ring direction - of the corresponding Path message. + ring LSP. Ring LSP named RLi, anchored on node Ri, consists of + two counter-rotating unicast LSPs that start and end at Ri. One + LSP will be in the clockwise direction and other LSP will be in + the anti-clockwise direction. A ring LSP is "multipoint": any + node along the ring can use LSP RLi to send traffic to Ri; this + can be in either the CW or AC directions, or both (i.e., load + balanced). Two new flags are defined in the SESSION object which + define the ring direction of the corresponding Path message. ClockWise(CW) Direction 0x01: This flag indicates that the corresponding Path message is traveling in the ClockWise(CW) direction along the ring. Anti-ClockWise(AC) Direction 0x02: This flag indicates that the corresponding Path message is traveling in the Anti-ClockWise(AC) direction along the ring. 3.2. SENDER_TEMPLATE,FILTER_SPEC Objects There will be no changes to the SENDER_TEMPLATE and FILTER_SPEC objects. The format of the above 2 objects will be similar to the definitions in RFC 3209. [RFC3209] Only the semantics of these objects will slightly change. This will be explained in section - Section 4.5 below. + Section 4.6 below. 4. Ring Signaling Procedures A ring node indicates in its IGP updates the ring LSP signaling protocols that it supports. This can be LDP and/or RSVP-TE. Ideally, each node should support both. If the ring is configured with RSVP as the signaling protocol, then once a ring node R_i knows the RID, its ring links and directions, it kicks off ring RSVP LSP signaling automatically. 4.1. Differences from regular RSVP-TE LSPs Ring LSPs differ from regular RSVP-TE LSPs in several ways: 1. Ring LSPs (by construction) form a loop. 2. Ring LSPs are multipoint-to-point. Any ring node can inject traffic into a ring LSP. - 3. The bandwidth of a ring LSP can change hop-to-hop. + 3. The bandwidth of a ring LSP can change hop-by-hop. 4. Ring LSPs are protected without the use of bypass or detour LSPs. - Ring LSP protection is akin to SONET/SDH ring protection. + Protection is handled by the ring LSP traversing in the opposite + direction. 4.2. LSP signaling After the ring auto-discovery process, each anchor node creates a LSP addressed to itself. This ring LSP contains of a pair of counter- rotating unicast LSPs. So, for a ring containing N nodes, there will be 2N total LSPs signaled. There is no need for ERO object in the Path message. The Path message for ring LSPs has the following format: @@ -242,59 +250,60 @@ [ ] ::= | ::= The anchor node creates 2 Path messages traveling in opposite directions. The SESSION format MUST be as per the description in Section 3.1. The anchor node which creates the LSP will insert it's - own address in the "Ring node anchor address" field of the SESSION + own address in the "Ring anchor node address" field of the SESSION object. So effectively, the Path messages are addressed to the originating node itself. The SESSION flags of these 2 Path messages are different. The Path message sent to the CW neighbor MUST have the CW flag set in the SESSION object to signal the LSP going in the clockwise direction. The Path message sent to the AC neighbor MUST have the AC flag set to - signal the LSP in the anti-clockwise direction. The details for - signaling over express links will be given in a future version. + signal the LSP in the anti-clockwise direction. - When an incoming Path message is received at the ring node R_i, it + When an incoming Path message is received at the ring node Ri, it consults the results of auto-discovery to find the appropriate ring neighbor. If the incoming Path message has CW direction flag set, - then R_i sends a Path message to its CW ring neighbor (and vice - versa) after including its own SENDER_DESCRIPTOR in the path message. - Thus, there is no need of ERO in the Path message. The Path message - is routed locally at each ring based on the ring auto-discovery - calculations. + then Ri includes its own SENDER_DESCRIPTOR in the path message and + forwards the Path message to its CW ring neighbor(Ri+1). Similarly + if the incoming Path message has AC direction flag set, then Ri + includes its own SENDER_TEMPPLATE and forwards that Path message to + it's AC ring neighbor(Ri-1). Thus, there is no need of ERO in the + Path message. The Path message is routed locally at each ring based + on the ring auto-discovery calculations. The RESV message for ring LSPs also uses the new RING_IPv4 SESSION - object. When the Path message originated from the anchor node R_i - reaches back to R_i, R_i generates a Resv message. Note that this + object. When the Path message originated from the anchor node Ri + reaches back to Ri, Ri generates a Resv message. Note that this means that anchor node is both Ingress and Egress for the Path message. The Resv message copies the same ring flags as received in the corresponding Path message. So, a Resv message for a CW LSP goes in the AC direction (unlike the Path message, which goes CW). This is done to correctly match Path and corresponding Resv messages at transit ring nodes. Upon receiving Resv message with CW flag set, the ring node will forward the Resv message to its AC neighbor. - Each ring node R_i allocates CW and AC labels for each ring LSP RL_k. - As the signaling propagates around the ring, CW and AC labels are - exchanged. When R_i receives CW and AC labels for RL_k from its ring - neighbors, primary and fast reroute (FRR) paths for RL_k are - installed at R_i. + Each ring node Ri allocates CW and AC labels for each ring LSP RLx(x + between i..n). As the signaling propagates around the ring, CW and + AC labels are exchanged. When Ri receives CW and AC labels for LSP + RLx from its ring neighbors, primary and fast reroute (FRR) paths for + RLx are installed at Ri. Consider the following three nodes of the ring, and their signaling - interactions for LSP RL_5 originating from anchor node R5: + interactions for LSP RL5 originating from anchor node R5: P5_CW -> P5_CW -> Q5_CW <- Q5_CW <- ... ------ R7 --------- R8 --------- R9 ------ ... P5_AC <- P5_AC <- Q5_AC -> Q5_AC -> P corresponds to the Path message and Q corresponds to the Resv message. @@ -304,22 +313,22 @@ TE. There are some benefits to this: Having a ring LSP form a loop allows the anchor node R1 to ping itself and thus verify the end-to-end operation of the LSP. This, in conjunction with link-level OAM, offers a good indication of the operational state of the LSP. Also, having R1 to be the ingress means that R1 can initiate the Path messages for the two ring LSPs. This avoids R1 having to coordinate with its neighbors to signal the LSPs, and simplifies the case where a ring update changes R1's ring neighbors. The cost of this is a little more signaling and a couple - more label entries in the LFIB. However, we will let implementation - guide us to the wisdom of this approach. + more label entries in the LFIB. However, we will let experiences + from implementation guide us when we evaluate this approach. 4.2.1. Path Propagation for RMR Ring LSPs are MP2P in nature. It means that every non-egress node is also an ingress and a merge-point for the LSP. Focussing on ring- LSP-0 (i.e ring-LSPs starting at R0): R0---->R1---->R2---->R3---->R4---->R5---->R6--->R7--->R0(CW LSP) R0---->R7---->R6---->R5---->R4---->R3---->R2--->R1--->R0(ACW LSP) @@ -456,23 +465,28 @@ the same way as the original Path message. Each ring neighbor SHOULD forward the Path message to it's appropriate neighbor based on the new auto-discovery calculations. For the ring links which are common between the old and new LSPs, the LSPs will share resources(SE style reservation) on those ring links. Note that here we are using Ring Instance ID in the SESSION object to share resources instead of the LSP_ID in the SENDER_TEMPLATE Object(which is used in RSVP-TE for sharing resources as described in RFC 3209 [RFC4090]). The LSP_ID use is reserved for a different - functionality as described in section Section 4.5. + functionality as described in section Section 4.6. -4.5. Bandwidth management +4.5. Express Links + + The details for signaling over express links will be given in a + future version. + +4.6. Bandwidth management For RSVP-TE LSPs, bandwidths may be signaled in both directions. However, these are not provisioned either; rather, one does "reverse call admission control". When a service needs to use an LSP, the ring node where the traffic enters the ring attempts to increase the bandwidth on the LSP to the egress. If successful, the service is admitted to the ring. . R0 . . . R1 . __________|| . @@ -593,20 +606,24 @@ [I-D.ietf-mpls-rmr] Kompella, K. and L. Contreras, "Resilient MPLS Rings", draft-ietf-mpls-rmr-07 (work in progress), March 2018. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . + [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC + 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, + May 2017, . + 8.2. Informative References [I-D.dai-mpls-rsvp-te-mbb-label-reuse] Dai, M. and M. Chaudhry, "MPLS RSVP-TE MBB Label Reuse", draft-dai-mpls-rsvp-te-mbb-label-reuse-01 (work in progress), September 2015. [RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, DOI 10.17487/RFC2205,