--- 1/draft-ietf-teas-rsvp-rmr-extension-01.txt 2019-07-08 16:14:54.667754272 -0700 +++ 2/draft-ietf-teas-rsvp-rmr-extension-02.txt 2019-07-08 16:14:54.703755179 -0700 @@ -1,48 +1,48 @@ TEAS WG A. Deshmukh Internet-Draft K. Kompella Intended status: Standards Track Juniper Networks, Inc. -Expires: December 30, 2018 June 28, 2018 +Expires: January 9, 2020 July 8, 2019 RSVP Extensions for RMR - draft-ietf-teas-rsvp-rmr-extension-01 + draft-ietf-teas-rsvp-rmr-extension-02 Abstract 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 + limited today. {{!I-D.ietf-mpls-rmr}} 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 30, 2018. + This Internet-Draft will expire on January 9, 2020. Copyright Notice - Copyright (c) 2018 IETF Trust and the persons identified as the + Copyright (c) 2019 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 @@ -70,23 +70,23 @@ 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 8.1. Normative References . . . . . . . . . . . . . . . . . . 14 8.2. Informative References . . . . . . . . . . . . . . . . . 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. + using the mechanisms mentioned in the {{!I-D.ietf-mpls-rmr}}. 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 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. @@ -194,20 +194,23 @@ 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. + Express Link 0x04: This flag indicates that the corresponding Path + message is traveling along the Express link in 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.6 below. 4. Ring Signaling Procedures @@ -359,23 +362,23 @@ 4.2.2. Resv Processing for RMR When Egress node R0 receives the modified Path message, it replies with the a Resv message containing multiple FLOW_DESCRIPTOR objects. There should be 1 FLOW_DESCRIPTOR object corresponding to each of the SENDER_TEMPLATE object in the incoming Path message. The SESSION object of the Resv message will exactly match with the received Path message. - [RFC 3209] already supports receiving a Resv message with multiple - flow-descriptors in it, as described in section 3.2 in that document. - In each flow-descriptor there is a separate: + RFC 3209[RFC3209] already supports receiving a Resv message with + multiple flow-descriptors in it, as described in section 3.2 in that + document. In each flow-descriptor there is a separate: a. FLOW_SPEC object corresponding to the SENDER_TSPEC that was sent in the Path message which could be admitted after admission-control downstream, and b. FILTER_SPEC object corresponding to SENDER_TEMPLATE that was sent in the Path message that could be admitted after admission-control downstream. Each transit node removes the FLOW-DESCRIPTOR corresponding to itself @@ -469,22 +472,36 @@ 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.6. 4.5. Express Links - The details for signaling over express links will be given in a - future version. + Express links are discovered once ring nodes, ring links and + directions have been established. As defined earlier, express links + are links joining non-neighboring ring nodes. Express links are both + clockwise and anti-clockwise. + + A ring node with an Express link replicates the incoming Path message + over the Express link. The "Express Link" flag is set in the SESSION + object of the replicated Path message. Also, the ring node Ri + includes an additional SENDER_DESCRIPTOR with a new LSP_ID in the + outgoing PATH message. + + When this Path message with Express link flag is received at the + other end of Express link, the other ring node replies with the Resv + message. It does not forward this Path message to any of it's ring + neighbors. Thus, the "Express" LSPs are effectively 1 hop LSPs + formed over the "Express Links". 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. @@ -599,21 +616,21 @@ 7. IANA Considerations Requests to IANA will be made in a future version of this document. 8. References 8.1. Normative References [I-D.ietf-mpls-rmr] Kompella, K. and L. Contreras, "Resilient MPLS Rings", - draft-ietf-mpls-rmr-07 (work in progress), March 2018. + draft-ietf-mpls-rmr-11 (work in progress), June 2019. [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, .