--- 1/draft-ietf-teas-p2mp-loose-path-reopt-04.txt 2016-03-11 08:18:48.324250887 -0800 +++ 2/draft-ietf-teas-p2mp-loose-path-reopt-05.txt 2016-03-11 08:18:48.428253471 -0800 @@ -1,67 +1,67 @@ TEAS Working Group T. Saad, Ed. Internet-Draft R. Gandhi, Ed. Intended status: Standards Track Z. Ali -Expires: May 19, 2016 Cisco Systems, Inc. +Expires: September 12, 2016 Cisco Systems, Inc. R. Venator Defense Information Systems Agency Y. Kamite NTT Communications Corporation - November 16, 2015 + March 11, 2016 RSVP Extensions For Re-optimization of Loosely Routed Point-to-Multipoint Traffic Engineering Label Switched Paths (LSPs) - draft-ietf-teas-p2mp-loose-path-reopt-04 + draft-ietf-teas-p2mp-loose-path-reopt-05 Abstract For a Traffic Engineered (TE) Point-to-Multipoint (P2MP) Label Switched Path (LSP), it is preferable in some cases to re-evaluate and re-optimize the entire P2MP-TE LSP by re-signaling all its Source-to-Leaf (S2L) sub-LSP(s). Existing mechanisms, a mechanism for an ingress Label Switched Router (LSR) to trigger a new path re-evaluation request and a mechanism for a mid-point LSR to notify an availability of a preferred path, operate on an individual or a sub-group of S2L sub-LSP(s) basis only. This document defines Resource Reservation Protocol (RSVP) signaling extensions to allow an ingress node of a P2MP-TE LSP to request the re-evaluation of the entire LSP tree containing one or more S2L sub-LSPs whose paths are loose (or abstract) hop expanded, and for a mid-point LSR to notify to the ingress node that a preferable tree exists for the entire P2MP-TE LSP. For re-optimizing a group of S2L sub-LSP(s) in a tree, an S2L sub-LSP descriptor list can be used to signal one or more S2L sub-LSPs in an RSVP message. This document - defines markers to indicate beginning and end of an S2L sub-LSP - descriptor list when the RSVP message needs to be fragmented due to - large number of S2L sub-LSPs in the message when performing sub-group - based re-optimization. + defines fragment identifier for the S2L sub-LSP descriptor list when + the RSVP message needs to be fragmented due to large number of S2L + sub-LSPs in the message when performing sub-group based + re-optimization. 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 http://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." Copyright Notice - Copyright (c) 2015 IETF Trust and the persons identified as the + Copyright (c) 2016 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 (http://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 @@ -75,30 +75,31 @@ Re-optimization . . . . . . . . . . . . . . . . . . . . . 5 1.3. Existing Mechanism For Sub-Group-Based P2MP-TE LSP Re-optimization . . . . . . . . . . . . . . . . . . . . . 6 2. Conventions Used in This Document . . . . . . . . . . . . . . 7 2.1. Key Word Definitions . . . . . . . . . . . . . . . . . . . 7 2.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 7 2.3. Nomenclatures . . . . . . . . . . . . . . . . . . . . . . 8 3. Signaling Procedure For Loosely Routed P2MP-TE LSP Re-optimization . . . . . . . . . . . . . . . . . . . . . . . 8 3.1. Tree-Based Re-optimization . . . . . . . . . . . . . . . . 8 - 3.2. Sub-Group-Based Re-optimization Using Markers . . . . . . 9 + 3.2. Sub-Group-Based Re-optimization Using Fragment + Identifier . . . . . . . . . . . . . . . . . . . . . . . . 9 4. Message and Object Definitions . . . . . . . . . . . . . . . . 10 4.1. P2MP-TE Tree Re-evaluation Request Flag . . . . . . . . . 10 4.2. Preferable P2MP-TE Tree Exists Path Error Sub-code . . . . 10 - 4.3. Markers For S2L sub-LSP Descriptor . . . . . . . . . . . . 11 - 5. Compatibility . . . . . . . . . . . . . . . . . . . . . . . . 11 + 4.3. Fragment Identifier For S2L sub-LSP Descriptor . . . . . . 11 + 5. Compatibility . . . . . . . . . . . . . . . . . . . . . . . . 12 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 6.1. P2MP-TE Tree Re-evaluation Request Flag . . . . . . . . . 12 6.2. Preferable P2MP-TE Tree Exists Path Error Sub-code . . . . 12 - 6.3. BEGIN and END Markers For S2L sub-LSP Descriptor . . . . . 13 + 6.3. Fragment Identifier For S2L sub-LSP Descriptor . . . . . . 13 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 8.1. Normative References . . . . . . . . . . . . . . . . . . . 15 8.2. Informative References . . . . . . . . . . . . . . . . . . 15 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 16 Author's Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 1. Introduction This document defines Resource Reservation Protocol - Traffic @@ -249,26 +250,28 @@ using the same LSP-ID or tree based re-optimization using a different LSP-ID. o An LSR may fragment a large RSVP message (when a combined message may not be large enough to fit all S2L sub-LSPs). In this case, the ingress node may receive multiple PathErrs with sub-sets of S2L sub-LSPs in each (either due to the combined Path message got fragmented or combined PathErr message got fragmented) and would require additional logic to infer to re-optimize the LSP tree (for example, waiting for some time to aggregate all possible PathErr - messages before taking an action). + messages before taking an action). When fragmented, RSVP messages + may arrive out of order, and the receiver has no way of knowing the + beginning and end of the S2L sub-LSP list. - In order to address the above mentioned issue due to the RSVP message - fragmentation, this document defines markers to indicate beginning - and end of an S2L sub-LSP descriptor list when combining large number - of S2L sub-LSPs in an RSVP message. + In order to address the above mentioned issues due to the RSVP + message fragmentation, this document defines fragment identifier for + the S2L sub-LSP descriptor list when combining large number of S2L + sub-LSPs in an RSVP message. 2. Conventions Used in This Document 2.1. Key Word Definitions 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]. 2.2. Abbreviations @@ -346,21 +349,21 @@ one or more S2L sub-LSP path(s) SHOULD select one of the S2L sub- LSP(s) of the P2MP-TE LSP tree to send this PathErr message to the ingress node. The sending of an RSVP PathErr Notify message "Preferable P2MP-TE Tree Exists" to the ingress node SHALL notify the ingress node of the existence of a preferable P2MP-TE LSP tree and upon receiving this PathErr, the ingress node MAY trigger re-optimization of the LSP using a different LSP-ID. -3.2. Sub-Group-Based Re-optimization Using Markers +3.2. Sub-Group-Based Re-optimization Using Fragment Identifier It might be preferable, as per [RFC4875], to re-optimize the entire P2MP-TE LSP by re-signaling all of its S2L sub-LSP(s) (Section 14.1, "Make-before-Break") or to re-optimize individual or group of S2L sub-LSP(s) i.e. individual or group of destination(s) (Section 14.2 "Sub-Group-Based Re-Optimization" in [RFC4875]), both using the same LSP-ID. For loosely routed S2L sub-LSPs, this can be achieved by using the procedures defined in [RFC4736] to re-optimize one or more S2L sub-LSP(s) of the P2MP-TE LSP. @@ -370,42 +373,40 @@ [RFC4875]. An S2L sub-LSP descriptor list is created using a series of S2L_SUB_LSP Objects as defined in [RFC4875]. Similarly, a mid- point LSR may send a PathErr message (with Error code 25, sub-code 6, Preferable Path Exists) containing a list of S2L sub-LSPs transiting through the LSR using an S2L sub-LSP descriptor list to notify the ingress node of preferable paths available. As per [RFC4875] (Section 5.2.3, "Transit Fragmentation of Path State Information"), when a Path message is not large enough to fit all S2L sub-LSPs in the descriptor list, an LSR may fragment the message. In - this case, the LSR MAY add S2L_SUB_LSP_MARKER_BEGIN and - S2L_SUB_LSP_MARKER_END Objects defined in this document at the - beginning and at the end of the S2L sub-LSP descriptor list, - respectively. + this case, the LSR MAY add S2L_SUB_LSP_FRAG Object defined in this + document in the S2L sub-LSP descriptor list to be able to rebuild the + list from the received fragments that may arrive out of order. - Both S2L_SUB_LSP_MARKER_BEGIN and S2L_SUB_LSP_MARKER_END Objects - defined in this document are optional. However, a node MUST add the - S2L_SUB_LSP_MARKER_END Object if it has added - S2L_SUB_LSP_MARKER_BEGIN Object in the S2L sub-LSP descriptor list. + The S2L_SUB_LSP_FRAG Object defined in this document is optional. + However, a node MUST add the S2L_SUB_LSP_FRAG Object for each + fragment in S2L sub-LSP descriptor list when the RSVP message needs + to be fragmented. A mid-point LSR SHOULD wait to accumulate all S2L sub-LSPs before attempting to re-evaluate preferable path when a Path message for - "Path Re-evaluation Request" is received with - S2L_SUB_LSP_MARKER_BEGIN Object. An ingress node SHOULD wait to - accumulate all S2L sub-LSPs before attempting to trigger - re-optimization when a PathErr message with "Preferable Path Exists" - is received with S2L_SUB_LSP_MARKER_BEGIN Object. + "Path Re-evaluation Request" is received with S2L_SUB_LSP_FRAG + Object. An ingress node SHOULD wait to accumulate all S2L sub-LSPs + before attempting to trigger re-optimization when a PathErr message + with "Preferable Path Exists" is received with a S2L_SUB_LSP_FRAG + Object. - New objects S2L_SUB_LSP_MARKER_BEGIN and S2L_SUB_LSP_MARKER_END - defined in this document have a wider applicability other than the - P2MP-TE LSP re-optimization but it is outside the scope of this - document. + The new object S2L_SUB_LSP_FRAG defined in this document has a wider + applicability other than the P2MP-TE LSP re-optimization but it is + outside the scope of this document. 4. Message and Object Definitions 4.1. P2MP-TE Tree Re-evaluation Request Flag In order to trigger a tree re-evaluation request, a new flag is defined in Attributes Flags TLV of the LSP_ATTRIBUTES Object [RFC5420] as follows: Bit Number (to be assigned by IANA): P2MP-TE Tree Re-evaluation @@ -420,65 +421,69 @@ tree exists, the following new sub-code for PathErr code 25 (Notify Error) [RFC3209] is defined: Sub-code (to be assigned by IANA): Preferable P2MP-TE Tree Exists sub-code When a preferable path for P2MP-TE LSP tree exists, the mid-point LSR sends a solicited or unsolicited "Preferable P2MP-TE Tree Exists" PathErr notification to the ingress node of the P2MP-TE LSP. -4.3. Markers For S2L sub-LSP Descriptor +4.3. Fragment Identifier For S2L sub-LSP Descriptor An S2L_SUB_LSP Object [RFC4875] identifies a particular S2L sub-LSP belonging to the P2MP-TE LSP. An S2L sub-LSP descriptor list is created using a series of S2L_SUB_LSP Objects as defined in - [RFC4875]. In order to indicate the beginning and end of the S2L - sub-LSP descriptor list when the RSVP message needs to be fragmented - due to large number of S2L sub-LSPs, the following new types are - defined for the S2L_SUB_LSP Object [RFC4875]. - - S2L_SUB_LSP_MARKER_BEGIN : + [RFC4875]. The RSVP message may need to be fragmented due to large + number of S2L sub-LSPs added in the descriptor list, and such + fragments may be received our of order. To be able to rebuild the + fragmented S2L sub-LSP descriptor list correctly, the following new + type is defined for the S2L_SUB_LSP Object [RFC4875]. - Class-Num 50, C-Type TBA by IANA + S2L_SUB_LSP_FRAG: Class-Num 50, C-Type TBA by IANA - +-----------------+---------------+--------------------------+ - | Length (4 bytes)| Class_Num 50 | S2L_SUB_LSP_MARKER_BEGIN | - +-----------------+---------------+--------------------------+ + +---------------+---------------+---------------+---------------+ + | Len (12 bytes)| Reserved | Class_Num 50 | SUB_LSP_FRAG | + +---------------+---------------+---------------+---------------+ + | Reserved | Fragment ID | + +---------------+---------------+---------------+---------------+ + | Fragments Total | Fragment Number | + +---------------+---------------+---------------+---------------+ - S2L_SUB_LSP_MARKER_END : + Fragment ID: 16-bit integer in the range of 1 to 65535. This value + is incremented for each new RSVP message that needs to be + fragmented. - Class-Num 50, C-Type TBA by IANA + Fragments Total: 16-bit integer in the range of 1 to 65535. This + value indicates the number of fragments sent for the given RSVP + message. - +-----------------+---------------+--------------------------+ - | Length (4 bytes)| Class_Num 50 | S2L_SUB_LSP_MARKER_END | - +-----------------+---------------+--------------------------+ + Fragment Number: 16-bit integer in the range of 1 to 65535. This + value indicates the position of this fragment in the given RSVP + message. - The S2L_SUB_LSP_MARKER_BEGIN Object is added before adding the first - S2L_SUB_LSP_IPv4 or S2L_SUB_LSP_IPv6 Object and the - S2L_SUB_LSP_MARKER_END Object is added after adding the last - S2L_SUB_LSP_IPv4 or S2L_SUB_LSP_IPv6 Object in the S2L sub-LSP - descriptor list. + The S2L_SUB_LSP_FRAG Object is added before adding the + S2L_SUB_LSP_IPv4 or S2L_SUB_LSP_IPv6 Object in the fragmented + message. 5. Compatibility The LSP_ATTRIBUTES Object has been defined in [RFC5420] with class numbers in the form 11bbbbbb, which ensures compatibility with non-supporting nodes. Per [RFC2205], nodes not supporting this extension will ignore the new flag defined in this document but forward it without modification. - The S2L_SUB_LSP_MARKER_BEGIN and S2L_SUB_LSP_MARKER_END Objects have - been defined with class numbers in the form 11bbbbbb, which ensures - compatibility with non-supporting nodes. Per [RFC2205], nodes not - supporting new S2L_SUB_LSP_MARKER_BEGIN and S2L_SUB_LSP_MARKER_END - Objects will ignore them but forward it without modification. + The S2L_SUB_LSP_FRAG Object has been defined with class numbers in + the form 11bbbbbb, which ensures compatibility with non-supporting + nodes. Per [RFC2205], nodes not supporting new S2L_SUB_LSP_FRAG + Object will ignore them but forward it without modification. 6. IANA Considerations IANA is requested to administer assignment of new values for namespace defined in this document and summarized in this section. 6.1. P2MP-TE Tree Re-evaluation Request Flag IANA maintains a name space for RSVP-TE TE parameters "Resource Reservation Protocol-Traffic Engineering (RSVP-TE) Parameters" (see @@ -516,62 +521,60 @@ o Preferable P2MP-TE Tree Exists sub-code: +----------+--------------------+---------+---------+-----------+ | Sub-code | Sub-code | PathErr | PathErr | Reference | | value | Description | Code | Name | | +----------+--------------------+---------+---------+-----------+ | TBA by | Preferable P2MP-TE | 25 | Notify | This | | IANA | Tree Exists | | Error | document | +----------+--------------------+---------+---------+-----------+ -6.3. BEGIN and END Markers For S2L sub-LSP Descriptor +6.3. Fragment Identifier For S2L sub-LSP Descriptor IANA maintains a name space for RSVP protocol parameters "Resource Reservation Protocol (RSVP) Parameters" (see http://www.iana.org/assignments/rsvp-parameters). From the sub-registry "Class Types or C-Types 50 S2L_SUB_LSP" in registry "Class Names, Class Numbers, and Class Types", allocation of new C-Types is requested (Section 4.3). As defined in [RFC4875], S2L_SUB_LSP Object is defined with Class-Number 50 to identify a particular S2L sub-LSP belonging to the - P2MP-TE LSP. This document adds two new object types for this object + P2MP-TE LSP. This document adds one new object type for this object as follows: - o S2L_SUB_LSP_MARKER_BEGIN and S2L_SUB_LSP_MARKER_END Object types: + o S2L_SUB_LSP_FRAG Object type: - +---------------+---------------------------+-----------------+ + +-----------------+---------------------------+-----------------+ | C-Type value | Description | Reference | - +---------------+---------------------------+-----------------+ - | TBA by IANA | S2L_SUB_LSP_MARKER_BEGIN | This document | - +---------------+---------------------------+-----------------+ - | TBA by IANA | S2L_SUB_LSP_MARKER_END | This document | - +---------------+---------------------------+-----------------+ + +-----------------+---------------------------+-----------------+ + | TBA by IANA | S2L_SUB_LSP_FRAG | This document | + +-----------------+---------------------------+-----------------+ 7. Security Considerations This document defines RSVP-TE signaling extensions to allow an ingress node of a P2MP-TE LSP to request the re-evaluation of the entire LSP tree, and for a mid-point LSR to notify the ingress node of the existence of a preferable tree by sending a PathErr. As per [RFC4736], in the case of a P2MP-TE LSP S2L sub-LSP spanning multiple domains, it may be desirable for a mid-point LSR to modify the RSVP PathErr message defined in this document to preserve confidentiality across domains. Furthermore, an ingress node may decide to ignore this PathErr message coming from a mid-point LSR residing in another domain. Similarly, a mid-point LSR may decide to ignore the P2MP-TE tree re-evaluation request originating from another ingress domain. - This document also defines markers to indicate beginning and end of - an S2L sub-LSP descriptor list when combining large number of S2L - sub-LSPs in an RSVP message and the message needs to be fragmented. - The introduction of these markers, by themselves, introduce no + This document also defines fragment identifier for the S2L sub-LSP + descriptor list when combining large number of S2L sub-LSPs in an + RSVP message and the message needs to be fragmented. The + introduction of the fragment identifier, by itself, introduce no additional information to signaling. For a general discussions on MPLS and GMPLS related security issues, see the MPLS/GMPLS security framework [RFC5920]. 8. References 8.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. @@ -604,23 +607,23 @@ [RFC5440] Vasseur, JP., Ed., and JL. Le Roux, Ed., "Path Computation Element (PCE) Communication Protocol (PCEP)", RFC 5440, March 2009. [RFC5920] Fang, L., "Security Framework for MPLS and GMPLS Networks", RFC 5920, July 2010. Acknowledgments The authors would like to thank Loa Andersson, Sriganesh Kini, Curtis - Villamizar, Dimitri Papadimitriou and Nobo Akiya for reviewing this - document. The authors would also like to thank Ling Zeng for - implementing mechanisms defined in this document. + Villamizar, Dimitri Papadimitriou, Nobo Akiya and Vishnu Pavan Beeram + for reviewing this document. The authors would also like to thank + Ling Zeng for implementing mechanisms defined in this document. Author's Addresses Tarek Saad (editor) Cisco Systems EMail: tsaad@cisco.com Rakesh Gandhi (editor) Cisco Systems