diff options
Diffstat (limited to 'doc/rfc/rfc8149.txt')
| -rw-r--r-- | doc/rfc/rfc8149.txt | 955 |
1 files changed, 955 insertions, 0 deletions
diff --git a/doc/rfc/rfc8149.txt b/doc/rfc/rfc8149.txt new file mode 100644 index 0000000..20a789b --- /dev/null +++ b/doc/rfc/rfc8149.txt @@ -0,0 +1,955 @@ + + + + + + +Internet Engineering Task Force (IETF) T. Saad, Ed. +Request for Comments: 8149 R. Gandhi, Ed. +Category: Standards Track Z. Ali +ISSN: 2070-1721 Cisco Systems, Inc. + R. Venator + Defense Information Systems Agency + Y. Kamite + NTT Communications Corporation + April 2017 + + + RSVP Extensions for Reoptimization of Loosely Routed + Point-to-Multipoint Traffic Engineering Label Switched Paths (LSPs) + +Abstract + + The reoptimization of a Point-to-Multipoint (P2MP) Traffic + Engineering (TE) Label Switched Path (LSP) may be triggered based on + the need to reoptimize an individual source-to-leaf (S2L) sub-LSP or + a set of S2L sub-LSPs, both using the Sub-Group-based reoptimization + method, or the entire P2MP-TE LSP tree using the Make-Before-Break + (MBB) method. This document discusses the application of the + existing mechanisms for path reoptimization of loosely routed Point- + to-Point (P2P) TE LSPs to the P2MP-TE LSPs, identifies issues in + doing so, and defines procedures to address them. When reoptimizing + a large number of S2L sub-LSPs in a tree using the Sub-Group-based + reoptimization method, the S2L sub-LSP descriptor list may need to be + semantically fragmented. This document defines the notion of a + fragment identifier to help recipient nodes unambiguously reconstruct + the fragmented S2L sub-LSP descriptor list. + +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 7841. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc8149. + + + + + + + +Saad, et al. Standards Track [Page 1] + +RFC 8149 P2MP-TE Loosely Routed LSPs April 2017 + + +Copyright Notice + + Copyright (c) 2017 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 + described in the Simplified BSD License. + +Table of Contents + + 1. Introduction ....................................................3 + 2. Conventions Used in This Document ...............................4 + 2.1. Key Word Definitions .......................................4 + 2.2. Abbreviations ..............................................4 + 2.3. Terminology ................................................4 + 3. Overview ........................................................5 + 3.1. Loosely Routed Inter-domain P2MP-TE LSP Tree ...............5 + 3.2. Existing Mechanism for Tree-Based P2MP-TE LSP + Reoptimization .............................................6 + 3.3. Existing Mechanism for Sub-Group-Based P2MP-TE LSP + Reoptimization .............................................7 + 4. Signaling Extensions for Loosely Routed P2MP-TE LSP + Reoptimization ..................................................8 + 4.1. Tree-Based Reoptimization ..................................8 + 4.2. Sub-Group-Based Reoptimization Using Fragment Identifier ...9 + 5. Message and Object Definitions .................................11 + 5.1. "P2MP-TE Tree Re-evaluation Request" Flag .................11 + 5.2. "Preferable P2MP-TE Tree Exists" Path Error Sub-code ......11 + 5.3. Fragment Identifier for S2L Sub-LSP Descriptor ............11 + 6. Compatibility ..................................................12 + 7. IANA Considerations ............................................13 + 7.1. "P2MP-TE Tree Re-evaluation Request" Flag .................13 + 7.2. "Preferable P2MP-TE Tree Exists" Path Error Sub-code ......13 + 7.3. Fragment Identifier for S2L Sub-LSP Descriptor ............14 + 8. Security Considerations ........................................14 + 9. References .....................................................15 + 9.1. Normative References ......................................15 + 9.2. Informative References ....................................16 + Acknowledgments ...................................................16 + Authors' Addresses ................................................17 + + + + +Saad, et al. Standards Track [Page 2] + +RFC 8149 P2MP-TE Loosely Routed LSPs April 2017 + + +1. Introduction + + This document defines Resource Reservation Protocol - Traffic + Engineering (RSVP-TE) [RFC2205] [RFC3209] signaling extensions for + reoptimizing loosely routed Point-to-Multipoint (P2MP) Traffic + Engineering (TE) Label Switched Paths (LSPs) [RFC4875] in a + Multiprotocol Label Switching (MPLS) or Generalized MPLS (GMPLS) + [RFC3473] network. + + A P2MP-TE LSP is comprised of one or more source-to-leaf (S2L) + sub-LSPs. A loosely routed P2MP-TE S2L sub-LSP is defined as one + whose path does not contain the full explicit route identifying each + node along the path to the egress node at the time of its signaling + by the ingress node. Such an S2L sub-LSP is signaled with no + Explicit Route Object (ERO) [RFC3209], with an ERO that contains at + least one "loose next hop", or with an ERO that contains an abstract + node that identifies more than one node. This is often the case with + inter-domain P2MP-TE LSPs where a Path Computation Element (PCE) is + not used [RFC5440]. + + As per [RFC4875], an ingress node may reoptimize the entire P2MP-TE + LSP tree by re-signaling all its S2L sub-LSPs using the + Make-Before-Break (MBB) method, or it may reoptimize an individual + S2L sub-LSP or a set of S2L sub-LSPs, i.e., an individual destination + or a set of destinations, both using the Sub-Group-based + reoptimization method. + + [RFC4736] defines an RSVP signaling procedure for reoptimizing the + path(s) of loosely routed Point-to-Point (P2P) TE LSP(s). The + mechanisms listed in [RFC4736] include a method for the ingress node + to trigger a new path re-evaluation request and a method for the + midpoint node to send a notification regarding the availability of a + preferred path. This document discusses the application of those + mechanisms to the reoptimization of loosely routed P2MP-TE LSPs, + identifies issues in doing so, and defines procedures to address + them. + + For reoptimizing a group of S2L sub-LSPs in a tree using the + Sub-Group-based reoptimization method, an S2L sub-LSP descriptor list + can be used to signal one or more S2L sub-LSPs in an RSVP message. + This RSVP message may need to be semantically fragmented when a large + number of S2L sub-LSPs are added to the descriptor list. This + document defines the notion of a fragment identifier to help + recipient nodes unambiguously reconstruct the fragmented S2L sub-LSP + descriptor list. + + + + + + +Saad, et al. Standards Track [Page 3] + +RFC 8149 P2MP-TE Loosely Routed LSPs April 2017 + + +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 + + ABR: Area Border Router. + + ERO: Explicit Route Object. + + LSP: Label Switched Path. + + LSR: Label Switching Router. + + RRO: Record Route Object. + + S2L sub-LSP: Source-to-leaf sub-LSP. + + TE LSP: Traffic Engineering LSP. + +2.3. Terminology + + This document defines the following terms: + + o Ingress node: Head-end / source node of the TE LSP. + + o Egress node: Tail-end / destination node of the TE LSP. + + It is assumed that the reader is also familiar with the terminology + in [RFC4736] and [RFC4875]. + + + + + + + + + + + + + + + + + +Saad, et al. Standards Track [Page 4] + +RFC 8149 P2MP-TE Loosely Routed LSPs April 2017 + + +3. Overview + + [RFC4736] defines RSVP signaling extensions for reoptimizing loosely + routed P2P TE LSPs as follows: + + o A midpoint LSR that expands loose next hop(s) sends a solicited or + unsolicited PathErr with Notify error code 25 (as defined in + [RFC3209]), with sub-code 6 to indicate "Preferable Path Exists" + to the ingress node. + + o An ingress node triggers a path re-evaluation request at all + midpoint LSRs that expand loose next hop(s) by setting the "Path + Re-evaluation Request" flag (0x20) in the SESSION_ATTRIBUTES + object in the Path message. + + o The ingress node, upon receiving this PathErr with the Notify + error code (either solicited or unsolicited), initiates the + reoptimization of the LSP, using the MBB method with a different + LSP-ID. + + The following sections discuss the issues that may arise when + applying the mechanisms defined in [RFC4736] for reoptimizing loosely + routed P2MP-TE LSPs. + +3.1. Loosely Routed Inter-domain P2MP-TE LSP Tree + + An example of a loosely routed inter-domain P2MP-TE LSP tree is shown + in Figure 1. In this example, the P2MP-TE LSP tree consists of three + S2L sub-LSPs, to destinations (i.e., leafs) R10, R11, and R12 from + the ingress node (i.e., source) R1. Nodes R2 and R5 are branch + nodes, and nodes ABR3, ABR4, ABR7, ABR8, and ABR9 are ABRs. For the + S2L sub-LSP to destination R10, nodes ABR3, ABR7, and R10 are defined + as loose next hops. For the S2L sub-LSP to destination R11, nodes + ABR3, ABR8, and R11 are defined as loose next hops. For the S2L + sub-LSP to destination R12, nodes ABR4, ABR9, and R12 are defined as + loose next hops. + + + + + + + + + + + + + + + +Saad, et al. Standards Track [Page 5] + +RFC 8149 P2MP-TE Loosely Routed LSPs April 2017 + + + <--area1--><--area0--><-area2-> + + ABR7---R10 + / + / + ABR3---R5 + / \ + / \ + R1---R2 ABR8---R11 + \ + \ + ABR4---R6 + \ + \ + ABR9---R12 + + Figure 1: Example of Loosely Routed Inter-domain P2MP-TE LSP Tree + +3.2. Existing Mechanism for Tree-Based P2MP-TE LSP Reoptimization + + The mechanisms defined in [RFC4736] can be easily applied to trigger + the reoptimization of an individual S2L sub-LSP or a group of S2L + sub-LSPs. However, to apply those mechanisms for triggering the + reoptimization of a P2MP-TE LSP tree, an ingress node needs to send + path re-evaluation requests on all (typically hundreds) of the + S2L sub-LSPs, and the midpoint LSR needs to send PathErrs with the + Notify error code for all S2L sub-LSPs. Such mechanisms may lead to + the following issues: + + o A midpoint LSR that expands loose next hop(s) may have to + accumulate the received path re-evaluation request(s) for all S2L + sub-LSPs (e.g., by using a wait timer) and interpret them as a + reoptimization request for the whole P2MP-TE LSP tree. Otherwise, + a midpoint LSR may prematurely send a "Preferable Path Exists" + notification for one S2L sub-LSP or a subset of S2L sub-LSPs. + + o Similarly, the ingress node may have to heuristically determine + when to perform P2MP-TE LSP tree reoptimization and when to + perform S2L sub-LSP reoptimization. For example, an + implementation may choose to delay reoptimization long enough to + allow all PathErrs to be received. Such timer-based procedures + may produce undesired results. + + o The ingress node that receives (un)solicited PathErr(s) with the + Notify error code for one or more individual S2L sub-LSPs may + prematurely start reoptimizing the subset of S2L sub-LSPs. + However, as mentioned in [RFC4875], Section 14.2, such a + Sub-Group-based reoptimization procedure may result in data + + + +Saad, et al. Standards Track [Page 6] + +RFC 8149 P2MP-TE Loosely Routed LSPs April 2017 + + + duplication that can be avoided if the entire P2MP-TE LSP tree is + reoptimized using the MBB method with a different LSP-ID, + especially if the ingress node eventually receives PathErrs with + the Notify error code for all S2L sub-LSPs of the P2MP-TE + LSP tree. + + In order to address the above-mentioned issues and to align the + reoptimization of P2MP-TE LSPs with P2P LSPs [RFC4736], a mechanism + is needed to trigger the reoptimization of the LSP tree by + re-signaling all S2L sub-LSPs with a different LSP-ID. To meet this + requirement, this document defines RSVP-TE signaling extensions for + the ingress node to trigger the re-evaluation of the P2MP LSP tree on + every hop that has a next hop defined as a loose or abstract hop for + one or more S2L sub-LSP paths, and a midpoint LSR to signal to the + ingress node that a preferable LSP tree exists (compared to the + current path) or that the whole P2MP-TE LSP must be reoptimized + (because of maintenance required on the TE LSP path) (see + Section 4.1). + +3.3. Existing Mechanism for Sub-Group-Based P2MP-TE LSP Reoptimization + + Applying the procedures discussed in [RFC4736] in conjunction with + the Sub-Group-based reoptimization procedures ([RFC4875], + Section 14.2), an ingress node MAY trigger path re-evaluation + requests for a set of S2L sub-LSPs in a single Path message using an + S2L sub-LSP descriptor list. Similarly, a midpoint LSR may send a + PathErr with Notify error code 25 and 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. + This method can be used for reoptimizing a sub-group of S2L sub-LSPs + within an LSP tree using the same LSP-ID. This method can alleviate + the scaling issue associated with sending RSVP messages for + individual S2L sub-LSPs. However, this procedure can lead to the + following issues when used to reoptimize the LSP tree: + + o A Path message that is intended to carry the path re-evaluation + request as defined in [RFC4736] with a full list of S2L sub-LSPs + in an S2L sub-LSP descriptor list will be decomposed at branching + LSRs, and only a subset of the S2L sub-LSPs that are routed over + the same next hop will be added in the descriptor list of the Path + message propagated to downstream midpoint LSRs. Consequently, + when a preferable path exists at such midpoint LSRs, the PathErr + with the Notify error code can only include the subset of S2L + sub-LSPs traversing the LSR. In this case, at the ingress node + there is no way to distinguish which mode of reoptimization to + invoke, i.e., Sub-Group-based reoptimization using the same LSP-ID + or tree-based reoptimization using a different LSP-ID. + + + + +Saad, et al. Standards Track [Page 7] + +RFC 8149 P2MP-TE Loosely Routed LSPs April 2017 + + + o An LSR may semantically 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 + subsets of S2L sub-LSPs in each (due to either the combined Path + message getting fragmented or the combined PathErr message getting + fragmented) and would require additional logic to determine how to + reoptimize the LSP tree (for example, waiting for some time to + aggregate all possible PathErr 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 issues caused by semantic + fragmentation of an RSVP message, this document defines a new + fragment identifier object for the S2L sub-LSP descriptor list when + combining a large number of S2L sub-LSPs in an RSVP message (see + Section 4.2). + +4. Signaling Extensions for Loosely Routed P2MP-TE LSP Reoptimization + +4.1. Tree-Based Reoptimization + + To evaluate a P2MP-TE LSP tree on midpoint LSRs that expand loose + next hop(s), an ingress node MAY send a Path message with the + "P2MP-TE Tree Re-evaluation Request" flag set (bit number 14 in the + Attribute Flags TLV) as defined in this document. The ingress node + selects one of the S2L sub-LSPs of the P2MP-TE LSP tree transiting a + midpoint LSR to trigger the re-evaluation request. The ingress node + MAY send a re-evaluation request to each border LSR on the path of + the LSP tree. + + A midpoint LSR that expands loose next hop(s) for one or more S2L + sub-LSP paths does the following upon receiving a Path message with + the "P2MP-TE Tree Re-evaluation Request" flag set: + + o The midpoint LSR MUST check for a preferable P2MP-TE LSP tree by + re-evaluating all S2L sub-LSPs that are expanded paths of the + loose next hops of the P2MP-TE LSP. + + o If a preferable P2MP-TE LSP tree is found, the midpoint LSR MUST + send to the ingress node an RSVP PathErr with Notify error code 25 + [RFC3209] and sub-code 13 ("Preferable P2MP-TE Tree Exists)" as + defined in this document. The midpoint LSR, in turn, SHOULD NOT + propagate the "P2MP-TE Tree Re-evaluation Request" flag in the + subsequent RSVP Path messages sent downstream for the re-evaluated + P2MP-TE LSP. + + + + + +Saad, et al. Standards Track [Page 8] + +RFC 8149 P2MP-TE Loosely Routed LSPs April 2017 + + + o If no preferable tree for P2MP-TE LSPs can be found, the midpoint + LSR that expands loose next hop(s) for one or more S2L sub-LSP + paths MUST propagate the request downstream by setting the + "P2MP-TE Tree Re-evaluation Request" flag in the LSP_ATTRIBUTES + object of the RSVP Path message. + + A midpoint LSR MAY send an unsolicited PathErr with the Notify error + code and the "Preferable P2MP-TE Tree Exists" sub-code to the ingress + node to notify the ingress node of a preferred P2MP-TE LSP tree when + it determines that it exists. In this case, the midpoint LSR that + expands loose next hop(s) for one or more S2L sub-LSP paths selects + one of the S2L sub-LSPs of the P2MP-TE LSP tree to send this PathErr + message to the ingress node. The midpoint LSR SHOULD consider how + frequently it chooses to send such a PathErr, considering that both + (1) a PathErr may be lost during its transit to the ingress node and + (2) the ingress node may choose not to reoptimize the LSP when such a + PathErr is received. + + The sending of an RSVP PathErr with the Notify error code and the + "Preferable P2MP-TE Tree Exists" sub-code to the ingress node + notifies the ingress node of the existence of a preferable P2MP-TE + LSP tree, and upon receiving this PathErr, the ingress node SHOULD + trigger the reoptimization of the LSP, using the MBB method with a + different LSP-ID. + +4.2. Sub-Group-Based Reoptimization Using Fragment Identifier + + It might be preferable, as per [RFC4875], to reoptimize the entire + P2MP-TE LSP by re-signaling all of its S2L sub-LSPs (Section 14.1 + ("Make-before-Break") in [RFC4875]) or to reoptimize an individual + S2L sub-LSP or a group of S2L sub-LSPs, i.e., an individual + destination or a group of destinations (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 reoptimize one or + more S2L sub-LSPs of the P2MP-TE LSP. + + An ingress node may trigger path re-evaluation requests using the + procedures defined in [RFC4736] for a set of S2L sub-LSPs by + combining multiple Path messages using an S2L sub-LSP descriptor list + [RFC4875]. An S2L sub-LSP descriptor list is created using a series + of S2L_SUB_LSP objects as defined in [RFC4875]. Similarly, a + midpoint LSR may send a PathErr with Notify error code 25 and + 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. + + + + + +Saad, et al. Standards Track [Page 9] + +RFC 8149 P2MP-TE Loosely Routed LSPs April 2017 + + + The S2L_SUB_LSP_FRAG object defined in this document is optional, + with the following exceptions: + + o 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 + semantically fragment the message. In this case, the LSR MUST add + the S2L_SUB_LSP_FRAG object defined in this document for each + fragment in the S2L sub-LSP descriptor to be able to rebuild the + list from the received fragments that may arrive out of order. + + o In any other situation where an RSVP message needs to be + fragmented, an LSR MUST add the S2L_SUB_LSP_FRAG object for each + fragment in the S2L sub-LSP descriptor. + + A midpoint LSR SHOULD wait to accumulate all S2L sub-LSPs before + attempting to re-evaluate a preferable path when a Path message for + "Path Re-evaluation Request" is received with the S2L_SUB_LSP_FRAG + object. If a midpoint LSR does not receive all fragments of the Path + message (for example, when fragments are lost) within a configurable + time interval, it SHOULD trigger the re-evaluation of all S2L + sub-LSPs of the P2MP-TE LSP transiting on the node. A midpoint LSR + MUST receive at least one fragment of the Path message to trigger + this behavior. + + An ingress node SHOULD wait to accumulate all S2L sub-LSPs before + attempting to trigger reoptimization when a PathErr with the Notify + error code and the "Preferable Path Exists" sub-code is received with + an S2L_SUB_LSP_FRAG object. If an ingress node does not receive all + fragments of the PathErr message (for example, when fragments are + lost) within a configurable time interval, it SHOULD trigger the + reoptimization of all S2L sub-LSPs of the P2MP-TE LSP transiting on + the midpoint node that had sent the PathErr message. An ingress node + MUST receive at least one fragment of the PathErr message to trigger + this behavior. + + The S2L_SUB_LSP_FRAG object defined in this document has a wider + applicability in addition to the P2MP-TE LSP reoptimization. It can + also be used (in Path and Resv messages) to set up a new P2MP-TE LSP + and to send other PathErr messages as well as Path Tear and Resv Tear + messages for a set of S2L sub-LSPs. This is outside the scope of + this document. + + + + + + + + + +Saad, et al. Standards Track [Page 10] + +RFC 8149 P2MP-TE Loosely Routed LSPs April 2017 + + +5. Message and Object Definitions + +5.1. "P2MP-TE Tree Re-evaluation Request" Flag + + In order to trigger a tree re-evaluation request, a new flag in the + Attribute Flags TLV of the LSP_ATTRIBUTES object [RFC5420] is defined + by this document: + + Bit Number 14: "P2MP-TE Tree Re-evaluation Request" flag + + The "P2MP-TE Tree Re-evaluation Request" flag is meaningful in a Path + message of a P2MP-TE S2L sub-LSP and is inserted by the ingress node + using the message format defined in [RFC6510]. + +5.2. "Preferable P2MP-TE Tree Exists" Path Error Sub-code + + In order to indicate to an ingress node that a preferable P2MP-TE LSP + tree exists, the following new sub-code for PathErr messages with + Notify error code 25 [RFC3209] is defined by this document: + + Sub-code 13: "Preferable P2MP-TE Tree Exists" sub-code + + When a preferable path for a P2MP-TE LSP tree exists, the midpoint + LSR sends a solicited or unsolicited "Preferable P2MP-TE Tree Exists" + sub-code with a PathErr message with Notify error code 25 to the + ingress node of the P2MP-TE LSP. + +5.3. Fragment Identifier for S2L Sub-LSP Descriptor + + The 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]. The RSVP message may need to be semantically fragmented + [RFC4875] due to a large number of S2L sub-LSPs added in the + descriptor list, and such fragments may be received out of order. To + be able to rebuild the fragmented S2L sub-LSP descriptor list + correctly, the following object is defined to identify the fragments: + + S2L_SUB_LSP_FRAG: Class Number 204 + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Length (8 bytes) | Class Num 204 | C-Type 1 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Fragment ID | Fragments Tot.| Fragment Num. | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + + +Saad, et al. Standards Track [Page 11] + +RFC 8149 P2MP-TE Loosely Routed LSPs April 2017 + + + 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 semantically fragmented. The fragment ID is reset to 1 when it + reaches the maximum value of 65535. The scope of the fragment ID + is limited to the RSVP message type (e.g., Path) carrying the + fragment. In other words, fragment IDs do not have any + correlation between different RSVP message types (e.g., Path and + PathErr). The receiver does not check to ensure that the + consecutive new RSVP messages (e.g., Path messages) are received + with fragment IDs incremented by 1. + + Fragments Total: 8-bit integer in the range of 1 to 255. + + This value indicates the number of fragments sent for the given + RSVP message. This value MUST be the same in all fragmented RSVP + messages with a common fragment ID. + + Fragment Number: 8-bit integer in the range of 1 to 255. + + This value indicates the position of this fragment in the given + RSVP message. + + The format of an S2L sub-LSP descriptor message is as follows: + + <S2L sub-LSP descriptor> ::= + [ <S2L_SUB_LSP_FRAG> ] + <S2L_SUB_LSP> + [ <P2MP SECONDARY_EXPLICIT_ROUTE> ] + + The S2L_SUB_LSP_FRAG object is added before adding the S2L_SUB_LSP + object in the semantically fragmented RSVP message. + +6. Compatibility + + The LSP_ATTRIBUTES object has been defined in [RFC5420] and its + message formats in [RFC6510] 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 for this object in this document and will 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 this object will ignore + the object and will forward it without modification. + + + + + +Saad, et al. Standards Track [Page 12] + +RFC 8149 P2MP-TE Loosely Routed LSPs April 2017 + + +7. IANA Considerations + + IANA has performed the actions described below. + +7.1. "P2MP-TE Tree Re-evaluation Request" Flag + + IANA maintains the "Resource Reservation Protocol-Traffic Engineering + (RSVP-TE) Parameters" registry (see + <http://www.iana.org/assignments/rsvp-te-parameters>). Per + Section 5.1 of this document, IANA has registered a new flag in the + "Attribute Flags" registry. This new flag is defined for the + Attribute Flags TLV in the LSP_ATTRIBUTES object [RFC5420]. + + +-----+---------------+----------+----------+-----+-----+-----------+ + | Bit | Name | Attribute| Attribute| RRO | ERO | Reference | + | No | | Flags | Flags | | | | + | | | Path | Resv | | | | + +-----+---------------+----------+----------+-----+-----+-----------+ + | | P2MP-TE Tree | Yes | No | No | No | This | + | 14 | Re-evaluation | | | | | document | + | | Request | | | | | | + +-----+---------------+----------+----------+-----+-----+-----------+ + +7.2. "Preferable P2MP-TE Tree Exists" Path Error Sub-code + + IANA maintains the "Resource Reservation Protocol (RSVP) Parameters" + registry (see <http://www.iana.org/assignments/rsvp-parameters>). + Per Section 5.2 of this document, IANA has registered a new error + code in the "Sub-Codes - 25 Notify Error" sub-registry of the "Error + Codes and Globally-Defined Error Value Sub-Codes" registry. + + + + + + + + + + + + + + + + + + + + + +Saad, et al. Standards Track [Page 13] + +RFC 8149 P2MP-TE Loosely Routed LSPs April 2017 + + + As defined in [RFC3209], error code 25 in the ERROR_SPEC object + corresponds to a PathErr with the Notify error. This document adds a + new "Preferable P2MP-TE Tree Exists" sub-code for this PathErr as + follows: + + +----------+--------------------+---------+---------+-----------+ + | Value | Description | PathErr | PathErr | Reference | + | | | Code | Name | | + +----------+--------------------+---------+---------+-----------+ + | 13 | Preferable P2MP-TE | 25 | Notify | This | + | | Tree Exists | | Error | document | + +----------+--------------------+---------+---------+-----------+ + +7.3. Fragment Identifier for S2L Sub-LSP Descriptor + + IANA maintains the "Resource Reservation Protocol (RSVP) Parameters" + registry (see <http://www.iana.org/assignments/rsvp-parameters>). + Per Section 5.3 of this document, IANA has registered a new class + number in the "Class Names, Class Numbers, and Class Types" registry. + + +-----------------+---------------------------+-----------------+ + | Class Number | Class Name | Reference | + +-----------------+---------------------------+-----------------+ + | 204 | S2L_SUB_LSP_FRAG | This document | + +-----------------+---------------------------+-----------------+ + + IANA has also created the "Class Types or C-Types - 204 + S2L_SUB_LSP_FRAG" registry and populated it as follows: + + +-----------------+---------------------------+-----------------+ + | Value | Description | Reference | + +-----------------+---------------------------+-----------------+ + | 1 | S2L_SUB_LSP_FRAG | This document | + +-----------------+---------------------------+-----------------+ + +8. 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 LSP + tree downstream of a node and to allow a midpoint LSR to notify the + ingress node of the existence of a preferable tree by sending a + PathErr message. As per [RFC4736], in the case of a P2MP-TE LSP S2L + sub-LSP spanning multiple domains, it may be desirable for a midpoint + LSR to modify the RSVP PathErr message to preserve confidentiality + across domains. + + + + + + +Saad, et al. Standards Track [Page 14] + +RFC 8149 P2MP-TE Loosely Routed LSPs April 2017 + + + This document also defines a fragment identifier for the S2L sub-LSP + descriptor when combining a large number of S2L sub-LSPs in an RSVP + message and the message needs to be semantically fragmented. The + introduction of the fragment identifier, by itself, introduces no + additional information to signaling. For a general discussion on + security issues related to MPLS and GMPLS, see the MPLS/GMPLS + security framework [RFC5920]. + +9. References + +9.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, + DOI 10.17487/RFC2119, March 1997, + <http://www.rfc-editor.org/info/rfc2119>. + + [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, + September 1997, <http://www.rfc-editor.org/info/rfc2205>. + + [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., + and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP + Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, + <http://www.rfc-editor.org/info/rfc3209>. + + [RFC4736] Vasseur, JP., Ed., Ikejiri, Y., and R. Zhang, + "Reoptimization of Multiprotocol Label Switching (MPLS) + Traffic Engineering (TE) Loosely Routed Label Switched + Path (LSP)", RFC 4736, DOI 10.17487/RFC4736, + November 2006, <http://www.rfc-editor.org/info/rfc4736>. + + [RFC4875] Aggarwal, R., Ed., Papadimitriou, D., Ed., and S. + Yasukawa, Ed., "Extensions to Resource Reservation + Protocol - Traffic Engineering (RSVP-TE) for + Point-to-Multipoint TE Label Switched Paths (LSPs)", + RFC 4875, DOI 10.17487/RFC4875, May 2007, + <http://www.rfc-editor.org/info/rfc4875>. + + [RFC5420] Farrel, A., Ed., Papadimitriou, D., Vasseur, JP., and A. + Ayyangarps, "Encoding of Attributes for MPLS LSP + Establishment Using Resource Reservation Protocol Traffic + Engineering (RSVP-TE)", RFC 5420, DOI 10.17487/RFC5420, + February 2009, <http://www.rfc-editor.org/info/rfc5420>. + + + + + + +Saad, et al. Standards Track [Page 15] + +RFC 8149 P2MP-TE Loosely Routed LSPs April 2017 + + +9.2. Informative References + + [RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label + Switching (GMPLS) Signaling Resource ReserVation + Protocol-Traffic Engineering (RSVP-TE) Extensions", + RFC 3473, DOI 10.17487/RFC3473, January 2003, + <http://www.rfc-editor.org/info/rfc3473>. + + [RFC5440] Vasseur, JP., Ed., and JL. Le Roux, Ed., "Path Computation + Element (PCE) Communication Protocol (PCEP)", RFC 5440, + DOI 10.17487/RFC5440, March 2009, + <http://www.rfc-editor.org/info/rfc5440>. + + [RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS + Networks", RFC 5920, DOI 10.17487/RFC5920, July 2010, + <http://www.rfc-editor.org/info/rfc5920>. + + [RFC6510] Berger, L. and G. Swallow, "Resource Reservation Protocol + (RSVP) Message Formats for Label Switched Path (LSP) + Attributes Objects", RFC 6510, DOI 10.17487/RFC6510, + February 2012, <http://www.rfc-editor.org/info/rfc6510>. + +Acknowledgments + + The authors would like to thank Loa Andersson, Sriganesh Kini, Curtis + Villamizar, Dimitri Papadimitriou, Nobo Akiya, Vishnu Pavan Beeram, + and Joel M. Halpern for reviewing this document and providing many + useful comments and suggestions. The authors would also like to + thank Ling Zeng with Cisco Systems for implementing the mechanisms + defined in this document. A special thanks to Adrian Farrel for his + thorough review of this document. + + + + + + + + + + + + + + + + + + + + +Saad, et al. Standards Track [Page 16] + +RFC 8149 P2MP-TE Loosely Routed LSPs April 2017 + + +Authors' Addresses + + Tarek Saad (editor) + Cisco Systems, Inc. + + Email: tsaad@cisco.com + + + Rakesh Gandhi (editor) + Cisco Systems, Inc. + + Email: rgandhi@cisco.com + + + Zafar Ali + Cisco Systems, Inc. + + Email: zali@cisco.com + + + Robert H. Venator + Defense Information Systems Agency + + Email: robert.h.venator.civ@mail.mil + + + Yuji Kamite + NTT Communications Corporation + + Email: y.kamite@ntt.com + + + + + + + + + + + + + + + + + + + + + +Saad, et al. Standards Track [Page 17] + |