diff options
Diffstat (limited to 'doc/rfc/rfc8001.txt')
| -rw-r--r-- | doc/rfc/rfc8001.txt | 899 |
1 files changed, 899 insertions, 0 deletions
diff --git a/doc/rfc/rfc8001.txt b/doc/rfc/rfc8001.txt new file mode 100644 index 0000000..e48499b --- /dev/null +++ b/doc/rfc/rfc8001.txt @@ -0,0 +1,899 @@ + + + + + + +Internet Engineering Task Force (IETF) F. Zhang, Ed. +Request for Comments: 8001 Huawei +Category: Standards Track O. Gonzalez de Dios, Ed. +ISSN: 2070-1721 Telefonica Global CTO + C. Margaria + Juniper + M. Hartley + Z. Ali + Cisco + January 2017 + + + RSVP-TE Extensions for Collecting + Shared Risk Link Group (SRLG) Information + +Abstract + + This document provides extensions for Resource Reservation Protocol - + Traffic Engineering (RSVP-TE), including GMPLS, to support automatic + collection of Shared Risk Link Group (SRLG) information for the TE + link formed by a Label Switched Path (LSP). + +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/rfc8001. + + + + + + + + + + + + + + + + +Zhang, et al. Standards Track [Page 1] + +RFC 8001 RSVP-TE Ext for Collecting SRLG January 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 + 1.1. Applicability Example: Dual-Homing . . . . . . . . . . . . 3 + 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 5 + 3. RSVP-TE Requirements . . . . . . . . . . . . . . . . . . . . . 5 + 3.1. SRLG Collection Indication . . . . . . . . . . . . . . . . 5 + 3.2. SRLG Collection . . . . . . . . . . . . . . . . . . . . . 6 + 3.3. SRLG Update . . . . . . . . . . . . . . . . . . . . . . . 6 + 3.4. SRLG ID Definition . . . . . . . . . . . . . . . . . . . . 6 + 4. Encodings . . . . . . . . . . . . . . . . . . . . . . . . . . 6 + 4.1. SRLG Collection Flag . . . . . . . . . . . . . . . . . . . 6 + 4.2. RRO SRLG Subobject . . . . . . . . . . . . . . . . . . . 7 + 5. Signaling Procedures . . . . . . . . . . . . . . . . . . . . . 8 + 5.1. SRLG Collection . . . . . . . . . . . . . . . . . . . . . 8 + 5.2. SRLG Update . . . . . . . . . . . . . . . . . . . . . . . 10 + 5.3 Domain Boundaries . . . . . . . . . . . . . . . . . . . . . 10 + 5.4. Compatibility . . . . . . . . . . . . . . . . . . . . . . 11 + 6. Manageability Considerations . . . . . . . . . . . . . . . . . 11 + 6.1. Policy Configuration . . . . . . . . . . . . . . . . . . . 11 + 6.2. Coherent SRLG IDs . . . . . . . . . . . . . . . . . . . . 11 + 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 + 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 + 8.1. RSVP Attribute Bit Flags . . . . . . . . . . . . . . . . . 12 + 8.2. ROUTE_RECORD Object . . . . . . . . . . . . . . . . . . . 12 + 8.3. Policy Control Failure Error Subcodes . . . . . . . . . . 13 + 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 + 9.1. Normative References . . . . . . . . . . . . . . . . . . . 13 + 9.2. Informative References . . . . . . . . . . . . . . . . . . 14 + Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . . 15 + Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 + + + + +Zhang, et al. Standards Track [Page 2] + +RFC 8001 RSVP-TE Ext for Collecting SRLG January 2017 + + +1. Introduction + + It is important to understand which Traffic Engineering (TE) links in + a given network might be at risk from the same failures. In this + sense, a set of links can constitute a Shared Risk Link Group (SRLG) + if they share a resource whose failure can affect all links in the + set [RFC4202]. + + On the other hand, as described in [RFC4206] and [RFC6107], a + Hierarchical LSP (H-LSP) or stitched LSP (S-LSP) can be used for + carrying one or more other LSPs. Both the H-LSP and S-LSP can be + formed as a TE link. In such cases, it is important to know the SRLG + information of the LSPs that will be used to carry further LSPs. + + This document provides a signaling mechanism that collects the SRLGs + that are used by an LSP and can then be advertised as properties of + the TE link formed by that LSP. + +1.1. Applicability Example: Dual-Homing + + An interesting use case for the SRLG collection procedures defined in + this document is achieving LSP diversity in a dual-homing scenario. + The use case is illustrated in Figure 1, when the overlay model is + applied as defined in [RFC4208]. In this example, the exchange of + routing information over the User-Network Interface (UNI) is + prohibited by operator policy. + + +---+ +---+ + | P |....| P | + +---+ +---+ + / \ + +-----+ +-----+ + +---+ | PE1 | | PE3 | +---+ + |CE1|----| | | |----|CE2| + +---+\ +-----+ +-----+ /+---+ + \ | | / + \ +-----+ +-----+ / + \| PE2 | | PE4 |/ + | | | | + +-----+ +-----+ + \ / + +---+ +---+ + | P |....| P | + +---+ +---+ + + Figure 1: Dual-Homing Configuration + + + + + +Zhang, et al. Standards Track [Page 3] + +RFC 8001 RSVP-TE Ext for Collecting SRLG January 2017 + + + Single-homed customer edge (CE) devices are connected to a single + provider edge (PE) device via a single UNI link (which could be a + bundle of parallel links, typically using the same fiber cable). + This single UNI link can constitute a single point of failure. Such + a single point of failure can be avoided if the CE device is + connected to two PE devices via two UNI interfaces for CE1 and CE2, + respectively, as depicted in Figure 1. + + For the dual-homing case, it is possible to establish two connections + (LSPs) from the source CE device to the same destination CE device + where one connection is using one UNI link to PE1, for example, and + the other connection is using the UNI link to PE2. In order to avoid + single points of failure within the provider network, it is necessary + to also ensure path (LSP) diversity within the provider network to + achieve end-to-end diversity for the two LSPs between the two CE + devices CE1 and CE2. This use case describes how it is possible to + achieve path diversity within the provider network based on collected + SRLG information. As the two connections (LSPs) enter the provider + network at different PE devices, the PE device that receives the + connection request for the second connection needs to know the + additional path computation constraints such that the path of the + second LSP is disjoint with respect to the already established first + connection. + + As SRLG information is normally not shared between the provider + network and the client network, i.e., between PE and CE devices, the + challenge is how to solve the diversity problem when a CE is dual- + homed. The RSVP extensions for collecting SRLG information defined + in this document make it possible to retrieve SRLG information for an + LSP and hence solve the dual-homing LSP diversity problem. For + example, CE1 in Figure 1 may have requested an LSP1 to CE2 via PE1 + that is routed via PE3 to CE2. CE1 can then subsequently request an + LSP2 to CE2 via PE2 with the constraint that it needs to be maximally + SRLG disjoint with respect to LSP1. PE2, however, does not have any + SRLG information associated with LSP1, and this is needed as input + for its constraint-based path computation function. If CE1 is + capable of retrieving the SRLG information associated with LSP1 from + PE1, it can pass this discovered information to PE2 as part of the + LSP2 setup request (RSVP PATH message) in an EXCLUDE_ROUTE Object + (XRO) or Explicit Exclusion Route Subobject (EXRS) as described in + [RFC4874], and PE2 can now calculate a path for LSP2 that is SRLG + disjoint with respect to LSP1. The SRLG information associated with + LSP1 can be retrieved when LSP1 is established or at any time before + LSP2 is set up. + + When CE1 sends the setup request for LSP2 to PE2, it can also request + the collection of SRLG information for LSP2 and send that information + to PE1 by re-signaling LSP1 with SRLG-exclusion based on LSP2's + + + +Zhang, et al. Standards Track [Page 4] + +RFC 8001 RSVP-TE Ext for Collecting SRLG January 2017 + + + discovered SRLGs. This will ensure that the two paths for the two + LSPs remain mutually diverse; this is important when the provider + network is capable of restoring connections that failed due to a + network failure (fiber cut) in the provider network. + + Note that the knowledge of SRLG information even for multiple LSPs + does not allow a CE device to derive the provider network topology + based on the collected SRLG information. It would, however, be + possible for an entity controlling multiple CE devices to derive some + information related to the topology. This document therefore allows + PE devices to control the communication of SRLGs outside the provider + network if desired. + +2. 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]. + +3. RSVP-TE Requirements + + The SRLG collection process takes place in three stages: + + o The LSP's ingress node requests that SRLG collection take place; + + o SRLG data is added to the Path and Resv ROUTE_RECORD Objects + (RROs) by all nodes during signaling; + + o Changes to previously signaled SRLG data are made by sending + updated Path and Resv messages as required. + +3.1. SRLG Collection Indication + + The ingress node of the LSP needs be capable of indicating whether + the SRLG information of the LSP is to be collected during the + signaling procedure of setting up an LSP. There is no need for SRLG + information to be collected without an explicit request by the + ingress node. + + It may be preferable for the SRLG collection request to be understood + by all nodes along the LSP's path, or it may be more important for + the LSP to be established successfully even if it traverses nodes + that cannot supply SRLG information or have not implemented the + procedures specified in this document. It is desirable for the + ingress node to make the SRLG collection request in a manner that + best suits its own policy. + + + + + +Zhang, et al. Standards Track [Page 5] + +RFC 8001 RSVP-TE Ext for Collecting SRLG January 2017 + + +3.2. SRLG Collection + + If requested, the SRLG information is collected during the setup of + an LSP. SRLG information is added by each hop to the Path RRO during + Path message processing. The same information is also added to the + Resv RRO during Resv processing at each hop. + +3.3. SRLG Update + + When the SRLG information of an existing LSP for which SRLG + information was collected during signaling changes, the relevant + nodes of the LSP need to be capable of updating the SRLG information + of the LSP. This means that the signaling procedure needs to be + capable of updating the new SRLG information. + +3.4. SRLG ID Definition + + The identifier of an SRLG (SRLG ID) is defined as a 32-bit quantity + in [RFC4202]. This definition is used in this document. + +4. Encodings + +4.1. SRLG Collection Flag + + In order to indicate to nodes that SRLG collection is desired, this + document defines a new flag in the Attribute Flags TLV (see + [RFC5420]). This document defines a new SRLG Collection Flag in the + Attribute Flags TLV. A node that wishes to indicate that SRLG + collection is desired MUST set this flag in an Attribute Flags TLV in + an LSP_REQUIRED_ATTRIBUTES object (if collection is to be mandatory) + or an LSP_ATTRIBUTES object (if collection is desired but not + mandatory). + + o Bit Number (specified in Section 8.1): SRLG Collection Flag + + The SRLG Collection Flag is meaningful on a Path message. If the + SRLG Collection Flag is set to 1, it means that the SRLG information + SHOULD be reported to the ingress and egress node along the setup of + the LSP. + + The rules for the processing of the Attribute Flags TLV are not + changed. + + + + + + + + + +Zhang, et al. Standards Track [Page 6] + +RFC 8001 RSVP-TE Ext for Collecting SRLG January 2017 + + +4.2. RRO SRLG Subobject + + This document defines a new RRO subobject (ROUTE_RECORD subobject) to + record the SRLG information of the LSP. Its format is modeled on the + RRO subobjects defined in [RFC3209]. + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type | Length |D| Reserved | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | SRLG ID 1 (4 octets) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + ~ ...... ~ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | SRLG ID n (4 octets) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Type (8 bits) + + The type of the subobject. The value is specified in Section 8.2. + + Length (8 bits) + + The Length field contains the total length of the subobject in + octets, including the Type and Length fields. The Length depends on + the number of SRLG IDs. + + Direction bit (D-bit) (1 bit) + + If not set, the SRLGs contained in this subobject apply to the + downstream direction. If set, they apply to the upstream direction. + + Reserved (15 bits) + + This 15-bit field is reserved. It SHOULD be set to zero on + transmission and MUST be ignored on receipt. + + SRLG ID (4 octets) + + This field contains one SRLG ID. There is one SRLG ID field per SRLG + collected. There MAY be multiple SRLG ID fields in an SRLG + subobject. + + A node MUST NOT push an SRLG subobject in the ROUTE_RECORD without + also pushing either an IPv4 subobject, an IPv6 subobject, an + Unnumbered Interface ID subobject, or a Path Key Subobject (PKS). + + + +Zhang, et al. Standards Track [Page 7] + +RFC 8001 RSVP-TE Ext for Collecting SRLG January 2017 + + + As described in [RFC3209], the ROUTE_RECORD object is managed as a + stack. The SRLG subobject MUST be pushed by the node before the node + IP address or link identifier. The SRLG subobject SHOULD be pushed + after the Attribute subobject, if present, and after the LABEL + subobject, if requested. It MUST be pushed within the hop to which + it applies. + + [RFC5553] describes mechanisms to carry a PKS in the RRO so as to + facilitate confidentiality in the signaling of inter-domain TE LSPs. + RFC 5553 allows the path segment that needs to be hidden (that is, a + Confidential Path Segment (CPS)) to be replaced in the RRO with a + PKS. If the CPS contains SRLG subobjects, these MAY be retained in + the RRO by adding them again after the PKS in the RRO. The CPS is + defined in [RFC5520]. + + The rules for the processing of the LSP_REQUIRED_ATTRIBUTES, + LSP_ATTRIBUTES, and ROUTE_RECORD objects are not changed. + +5. Signaling Procedures + + The ingress node of the LSP MUST be capable of indicating whether the + SRLG information of the LSP is to be collected during the signaling + procedure of setting up an LSP. + +5.1. SRLG Collection + + Per [RFC3209], an ingress node initiates the recording of the route + information of an LSP by adding an RRO to a Path message. If an + ingress node also desires SRLG recording, it MUST set the SRLG + Collection Flag in the Attribute Flags TLV, which MAY be carried in + either an LSP_REQUIRED_ATTRIBUTES object (when the collection is + mandatory) or an LSP_ATTRIBUTES object (when the collection is + desired, but not mandatory). + + A node MUST NOT add SRLG information without an explicit request by + the ingress node in the Path message. + + When a node receives a Path message that carries an + LSP_REQUIRED_ATTRIBUTES object with the SRLG Collection Flag set, if + local policy determines that the SRLG information is not to be + provided to the endpoints, it MUST return a PathErr message with + + o Error Code 2 (policy) and + + o Error subcode "SRLG Recording Rejected" (see Section 8.3 for + value) + + to reject the Path message. + + + +Zhang, et al. Standards Track [Page 8] + +RFC 8001 RSVP-TE Ext for Collecting SRLG January 2017 + + + When a node receives a Path message that carries an LSP_ATTRIBUTES + object with the SRLG Collection Flag set, if local policy determines + that the SRLG information is not to be provided to the endpoints, the + Path message MUST NOT be rejected due to the SRLG recording + restriction, and the Path message MUST be forwarded without any SRLG + subobject(s) added to the RRO of the corresponding outgoing Path + message. + + If local policy permits the recording of the SRLG information, the + processing node SHOULD add local SRLG information, as defined below, + to the RRO of the corresponding outgoing Path message. The + processing node MAY add multiple SRLG subobjects to the RRO if + necessary. It then forwards the Path message to the next node in the + downstream direction. The processing node MUST retain a record of + the SRLG recording request for reference during Resv processing + described below. + + If the addition of SRLG information to the RRO would result in the + RRO exceeding its maximum possible size or becoming too large for the + Path message to contain it, the requested SRLGs MUST NOT be added. + If the SRLG collection request was contained in an + LSP_REQUIRED_ATTRIBUTES object, the processing node MUST behave as + specified by [RFC3209] and drop the RRO from the Path message + entirely. If the SRLG collection request was contained in an + LSP_ATTRIBUTES object, the processing node MAY omit some or all of + the requested SRLGs from the RRO; otherwise, it MUST behave as + specified by [RFC3209] and drop the RRO from the Path message + entirely. Subsequent processing of the LSP proceeds as further + specified in [RFC3209]. + + Following the steps described above, the intermediate nodes of the + LSP can collect the SRLG information in the RRO during the processing + of the Path message hop by hop. When the Path message arrives at the + egress node, the egress node receives SRLG information in the RRO. + + Per [RFC3209], when issuing a Resv message for a Path message that + contains an RRO, an egress node initiates the RRO process by adding + an RRO to the outgoing Resv message. The processing for RROs + contained in Resv messages then mirrors that of the Path messages. + + When a node receives a Resv message for an LSP for which SRLG + Collection was specified in the corresponding Path message, then when + local policy allows recording SRLG information, the node MUST add + SRLG information to the RRO of the corresponding outgoing Resv + message as specified below. When the Resv message arrives at the + ingress node, the ingress node can extract the SRLG information from + the RRO in the same way as the egress node. + + + + +Zhang, et al. Standards Track [Page 9] + +RFC 8001 RSVP-TE Ext for Collecting SRLG January 2017 + + + Note that a link's SRLG information for the upstream direction cannot + be assumed to be the same as that for the downstream direction. + + o For Path and Resv messages for a unidirectional LSP, a node SHOULD + include SRLG subobjects in the RRO for the downstream data link + only. + + o For Path and Resv messages for a bidirectional LSP, a node SHOULD + include SRLG subobjects in the RRO for both the upstream data link + and the downstream data link from the local node. In this case, + the node MUST include the information in the same order for both + Path messages and Resv messages. That is, the SRLG subobject for + the upstream link is added to the RRO before the SRLG subobject + for the downstream link. + + If SRLG data is added for both the upstream and downstream links, + the two sets of SRLG data MUST be added in separate SRLG + subobjects. A single SRLG subobject MUST NOT contain a mixture of + upstream and downstream SRLGs. When adding a SRLG subobject to an + RRO, the D-bit MUST be set appropriately to indicate the direction + of the SRLGs. If an SRLG ID applies in both directions, it SHOULD + be added to both the upstream and downstream SRLG subobjects. + + Based on the above procedure, the endpoints can get the SRLG + information automatically. Then, for instance, the endpoints can + advertise it as a TE link to the routing instance based on the + procedure described in [RFC6107] and configure the SRLG information + of the Forwarding Adjacency (FA) automatically. + +5.2. SRLG Update + + When the SRLG information of a link is changed, the endpoints of LSPs + using that link need to be made aware of the changes. When a change + to the set of SRLGs associated with a link occurs, the procedures + defined in Section 4.4.3 of [RFC3209] MUST be used to refresh the + SRLG information for each affected LSP if the local node's policy + dictates that the SRLG change be communicated to other nodes. + +5.3 Domain Boundaries + + If mandated by local policy as specified by the network operator, a + node MAY remove SRLG information from any RRO in a Path or Resv + message being processed. It MAY add a summary of the removed SRLGs + or map them to other SRLG values. However, this SHOULD NOT be done + unless explicitly mandated by local policy. + + + + + + +Zhang, et al. Standards Track [Page 10] + +RFC 8001 RSVP-TE Ext for Collecting SRLG January 2017 + + +5.4. Compatibility + + A node that does not recognize the SRLG Collection Flag in the + Attribute Flags TLV is expected to proceed as specified in [RFC5420]. + It is expected to pass the TLV on unaltered if it appears in an + LSP_ATTRIBUTES object or to reject the Path message with the + appropriate Error Code and Value if it appears in a + LSP_REQUIRED_ATTRIBUTES object. + + A node that does not recognize the SRLG RRO subobject is expected to + behave as specified in [RFC3209]: unrecognized subobjects are to be + ignored and passed on unchanged. + +6. Manageability Considerations + +6.1. Policy Configuration + + In a border node of an inter-domain or inter-layer network, the + following SRLG processing policy MUST be capable of being configured: + + o Whether the node is allowed to participate in SRLG collection and + notify changes to collected SRLG information to endpoint nodes as + described in Section 5.2. + + o Whether the SRLG IDs of the domain or specific layer network can + be exposed to the nodes outside the domain or layer network, or + whether they SHOULD be summarized, mapped to values that are + comprehensible to nodes outside the domain or layer network, or + removed entirely as described in Section 5.3. + + A node using [RFC5553] and PKS MAY apply the same policy. + +6.2. Coherent SRLG IDs + + In a multi-layer, multi-domain scenario, SRLG IDs can be configured + by different management entities in each layer or domain. In such + scenarios, maintaining a coherent set of SRLG IDs is a key + requirement in order to be able to use the SRLG information properly. + Thus, SRLG IDs SHOULD be unique. Note that current procedures are + targeted towards a scenario where the different layers and domains + belong to the same operator or to several coordinated administrative + groups. Ensuring the aforementioned coherence of SRLG IDs is beyond + the scope of this document. + + Further scenarios, where coherence in the SRLG IDs cannot be + guaranteed, are out of the scope of the present document and are left + for further study. + + + + +Zhang, et al. Standards Track [Page 11] + +RFC 8001 RSVP-TE Ext for Collecting SRLG January 2017 + + +7. Security Considerations + + This document builds on the mechanisms defined in [RFC3473], which + also discusses related security measures. In addition, [RFC5920] + provides an overview of security vulnerabilities and protection + mechanisms for the GMPLS control plane. The procedures defined in + this document permit the transfer of SRLG data between layers or + domains during the signaling of LSPs, subject to policy at the layer + or domain boundary. As described in Sections 5.3 and 6.1, local + policy as specified by the network operator will explicitly mandate + the processing of information at domain or layer boundaries. + +8. IANA Considerations + +8.1. RSVP Attribute Bit Flags + + IANA has created a registry and manages the space of the Attribute + bit flags of the Attribute Flags TLV, as described in Section 11.3 of + [RFC5420], in the "Attribute Flags" subregistry of the "Resource + Reservation Protocol-Traffic Engineering (RSVP-TE) Parameters" + registry located at + <http://www.iana.org/assignments/rsvp-te-parameters>. + + This document introduces a new Attribute bit flag: + + Bit No Name Attribute Attribute RRO ERO Reference + Flags Path Flags Resv + --------- ---------- ---------- ----------- --- --- --------- + 12 SRLG Yes No Yes No RFC 8001, + Collection [RFC7570] + Flag + +8.2. ROUTE_RECORD Object + + IANA manages the "Resource Reservation Protocol (RSVP) Parameters" + registry located at + <http://www.iana.org/assignments/rsvp-parameters>. This document + introduces a new RRO subobject under the "Sub-object type - 21 + ROUTE_RECORD - Type 1 Route Record" subregistry: + + Value Description Reference + ----- ------------------- --------- + 34 SRLG subobject RFC 8001 + + + + + + + + +Zhang, et al. Standards Track [Page 12] + +RFC 8001 RSVP-TE Ext for Collecting SRLG January 2017 + + +8.3. Policy Control Failure Error Subcodes + + IANA manages the assignments in the "Error Codes and Globally-Defined + Error Value Sub-Codes" section of the "Resource Reservation Protocol + (RSVP) Parameters" registry located at + <http://www.iana.org/assignments/rsvp-parameters>. + + This document introduces a new value under "Sub-Codes - 2 Policy + Control Failure": + + Value Description Reference + ----- ----------------------- --------- + 21 SRLG Recording Rejected RFC 8001 + +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>. + + [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>. + + [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>. + + [RFC4202] Kompella, K., Ed., and Y. Rekhter, Ed., "Routing + Extensions in Support of Generalized Multi-Protocol Label + Switching (GMPLS)", RFC 4202, DOI 10.17487/RFC4202, + October 2005, <http://www.rfc-editor.org/info/rfc4202>. + + [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>. + + + + + + + +Zhang, et al. Standards Track [Page 13] + +RFC 8001 RSVP-TE Ext for Collecting SRLG January 2017 + + + [RFC5520] Bradford, R., Ed., Vasseur, JP., and A. Farrel, + "Preserving Topology Confidentiality in Inter-Domain Path + Computation Using a Path-Key-Based Mechanism", RFC 5520, + DOI 10.17487/RFC5520, April 2009, + <http://www.rfc-editor.org/info/rfc5520>. + + [RFC5553] Farrel, A., Ed., Bradford, R., and JP. Vasseur, "Resource + Reservation Protocol (RSVP) Extensions for Path Key + Support", RFC 5553, DOI 10.17487/RFC5553, May 2009, + <http://www.rfc-editor.org/info/rfc5553>. + +9.2. Informative References + + [RFC4206] Kompella, K. and Y. Rekhter, "Label Switched Paths (LSP) + Hierarchy with Generalized Multi-Protocol Label Switching + (GMPLS) Traffic Engineering (TE)", RFC 4206, + DOI 10.17487/RFC4206, October 2005, + <http://www.rfc-editor.org/info/rfc4206>. + + [RFC4208] Swallow, G., Drake, J., Ishimatsu, H., and Y. Rekhter, + "Generalized Multiprotocol Label Switching (GMPLS) User- + Network Interface (UNI): Resource ReserVation Protocol- + Traffic Engineering (RSVP-TE) Support for the Overlay + Model", RFC 4208, DOI 10.17487/RFC4208, October 2005, + <http://www.rfc-editor.org/info/rfc4208>. + + [RFC4874] Lee, CY., Farrel, A., and S. De Cnodder, "Exclude Routes - + Extension to Resource ReserVation Protocol-Traffic + Engineering (RSVP-TE)", RFC 4874, DOI 10.17487/RFC4874, + April 2007, <http://www.rfc-editor.org/info/rfc4874>. + + [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>. + + [RFC6107] Shiomoto, K., Ed., and A. Farrel, Ed., "Procedures for + Dynamically Signaled Hierarchical Label Switched Paths", + RFC 6107, DOI 10.17487/RFC6107, February 2011, + <http://www.rfc-editor.org/info/rfc6107>. + + [RFC7570] Margaria, C., Ed., Martinelli, G., Balls, S., and B. + Wright, "Label Switched Path (LSP) Attribute in the + Explicit Route Object (ERO)", RFC 7570, + DOI 10.17487/RFC7570, July 2015, + <http://www.rfc-editor.org/info/rfc7570>. + + + + + + +Zhang, et al. Standards Track [Page 14] + +RFC 8001 RSVP-TE Ext for Collecting SRLG January 2017 + + +Acknowledgements + + The authors would like to thank Dieter Beller, Vishnu Pavan Beeram, + Lou Berger, Deborah Brungard, Igor Bryskin, Ramon Casellas, Niclas + Comstedt, Alan Davey, Elwyn Davies, Dhruv Dhody, Himanshu Shah, and + Xian Zhang for their useful comments and improvements to this + document. + +Contributors + + Dan Li + Huawei + F3-5-B RD Center + Bantian, Longgang District, Shenzhen 518129 + China + + Email: danli@huawei.com + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Zhang, et al. Standards Track [Page 15] + +RFC 8001 RSVP-TE Ext for Collecting SRLG January 2017 + + +Authors' Addresses + + Fatai Zhang (editor) + Huawei + F3-5-B RD Center + Bantian, Longgang District, Shenzhen 518129 + China + + Email: zhangfatai@huawei.com + + + Oscar Gonzalez de Dios (editor) + Telefonica Global CTO + Distrito Telefonica, edificio sur, Ronda de la Comunicacion 28045 + Madrid 28050 + Spain + Phone: +34 913129647 + + Email: oscar.gonzalezdedios@telefonica.com + + + Cyril Margaria + Juniper + 200 Somerset Corporate Blvd., Suite 4001 + Bridgewater, NJ 08807 + United States of America + + Email: cmargaria@juniper.net + + + Matt Hartley + Cisco + + Email: mhartley@cisco.com + + + Zafar Ali + Cisco + + Email: zali@cisco.com + + + + + + + + + + + +Zhang, et al. Standards Track [Page 16] + |