summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc8390.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc8390.txt')
-rw-r--r--doc/rfc/rfc8390.txt1459
1 files changed, 1459 insertions, 0 deletions
diff --git a/doc/rfc/rfc8390.txt b/doc/rfc/rfc8390.txt
new file mode 100644
index 0000000..81d4c02
--- /dev/null
+++ b/doc/rfc/rfc8390.txt
@@ -0,0 +1,1459 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF) Z. Ali, Ed.
+Request for Comments: 8390 Cisco Systems
+Updates: 4874 G. Swallow, Ed.
+Category: Standards Track SETC
+ISSN: 2070-1721 F. Zhang, Ed.
+ Huawei
+ D. Beller, Ed.
+ Nokia
+ July 2018
+
+
+ RSVP-TE Path Diversity Using Exclude Route
+
+Abstract
+
+ RSVP-TE provides support for the communication of exclusion
+ information during Label Switched Path (LSP) setup. A typical LSP
+ diversity use case is for protection, where two LSPs should follow
+ different paths through the network in order to avoid single points
+ of failure, thus greatly improving service availability. This
+ document specifies an approach that can be used for network scenarios
+ where the full path(s) is not necessarily known by use of an abstract
+ identifier for the path. Three types of abstract identifiers are
+ specified: client based, Path Computation Element (PCE) based, and
+ network based. This document specifies two new diversity subobjects
+ for the RSVP eXclude Route Object (XRO) and the Explicit Exclusion
+ Route Subobject (EXRS).
+
+ For the protection use case, LSPs are typically created at a slow
+ rate and exist for a long time so that it is reasonable to assume
+ that a given (reference) path currently existing (with a well-known
+ identifier) will continue to exist and can be used as a reference
+ when creating the new diverse path. Re-routing of the existing
+ (reference) LSP, before the new path is established, is not
+ considered.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Ali, et al. Standards Track [Page 1]
+
+RFC 8390 RVSP-TE Path Diversity July 2018
+
+
+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
+ https://www.rfc-editor.org/info/rfc8390.
+
+Copyright Notice
+
+ Copyright (c) 2018 IETF Trust and the persons identified as the
+ document authors. All rights reserved.
+
+ This document is subject to BCP 78 and the IETF Trust's Legal
+ Provisions Relating to IETF Documents
+ (https://trustee.ietf.org/license-info) in effect on the date of
+ publication of this document. Please review these documents
+ carefully, as they describe your rights and restrictions with respect
+ to this document. Code Components extracted from this document must
+ include Simplified BSD License text as described in Section 4.e of
+ the Trust Legal Provisions and are provided without warranty as
+ described in the Simplified BSD License.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Ali, et al. Standards Track [Page 2]
+
+RFC 8390 RVSP-TE Path Diversity July 2018
+
+
+Table of Contents
+
+ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
+ 1.1. Conventions Used in This Document . . . . . . . . . . . . 6
+ 1.2. Terms and Abbreviations . . . . . . . . . . . . . . . . . 6
+ 1.3. Client-Initiated Identifier . . . . . . . . . . . . . . . 7
+ 1.4. PCE-Allocated Identifier . . . . . . . . . . . . . . . . 7
+ 1.5. Network-Assigned Identifier . . . . . . . . . . . . . . . 9
+ 2. RSVP-TE Signaling Extensions . . . . . . . . . . . . . . . . 10
+ 2.1. Diversity XRO Subobject . . . . . . . . . . . . . . . . . 10
+ 2.2. Diversity EXRS Subobject . . . . . . . . . . . . . . . . 16
+ 2.3. Processing Rules for the Diversity XRO and EXRS
+ Subobjects . . . . . . . . . . . . . . . . . . . . . . . 16
+ 3. Security Considerations . . . . . . . . . . . . . . . . . . . 20
+ 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
+ 4.1. New XRO Subobject Types . . . . . . . . . . . . . . . . . 21
+ 4.2. New EXRS Subobject Types . . . . . . . . . . . . . . . . 21
+ 4.3. New RSVP Error Sub-codes . . . . . . . . . . . . . . . . 22
+ 5. References . . . . . . . . . . . . . . . . . . . . . . . . . 22
+ 5.1. Normative References . . . . . . . . . . . . . . . . . . 22
+ 5.2. Informative References . . . . . . . . . . . . . . . . . 23
+ Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 24
+ Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 24
+ Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26
+
+1. Introduction
+
+ Path diversity for multiple connections is a well-known operational
+ requirement. Diversity constraints ensure that Label Switched Paths
+ (LSPs) can be established without sharing network resources, thus
+ greatly reducing the probability of simultaneous connection failures.
+
+ The source node can compute diverse paths for LSPs when it has full
+ knowledge of the network topology and is permitted to signal an
+ Explicit Route Object (ERO). However, there are scenarios where
+ different nodes perform path computations, and therefore there is a
+ need for relevant diversity constraints to be signaled to those
+ nodes. These include (but are not limited to):
+
+ o LSPs with loose hops in the Explicit Route Object, e.g., inter-
+ domain LSPs; and
+
+ o Generalized Multiprotocol Label Switching (GMPLS) User-Network
+ Interface (UNI), where the core node may perform path computation
+ [RFC4208].
+
+
+
+
+
+
+Ali, et al. Standards Track [Page 3]
+
+RFC 8390 RVSP-TE Path Diversity July 2018
+
+
+ [RFC4874] introduced a means of specifying nodes and resources to be
+ excluded from a route using the eXclude Route Object (XRO) and
+ Explicit Exclusion Route Subobject (EXRS). It facilitates the
+ calculation of diverse paths for LSPs based on known properties of
+ those paths including addresses of links and nodes traversed and
+ Shared Risk Link Groups (SRLGs) of traversed links. Employing these
+ mechanisms requires that the source node that initiates signaling
+ knows the relevant properties of the path(s) from which diversity is
+ desired. However, there are circumstances under which this may not
+ be possible or desirable, including (but not limited to):
+
+ o Exclusion of a path that does not originate, terminate, or
+ traverse the source node of the diverse LSP, in which case the
+ addresses of links and SRLGs of the path from which diversity is
+ required are unknown to the source node.
+
+ o Exclusion of a path that is known to the source node of the
+ diverse LSP for which the node has incomplete or no path
+ information, e.g., due to operator policy. In this case, the
+ source node is aware of the existence of the reference path, but
+ the information required to construct an XRO object to guarantee
+ diversity from the reference path is not fully known. Inter-
+ domain and GMPLS overlay networks can impose such restrictions.
+
+ This is illustrated in Figure 1, where the overlay reference model
+ from [RFC4208] is shown.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Ali, et al. Standards Track [Page 4]
+
+RFC 8390 RVSP-TE Path Diversity July 2018
+
+
+ Overlay Overlay
+ Network +----------------------------------+ Network
+ +---------+ | | +---------+
+ | +----+ | | +-----+ +-----+ +-----+ | | +----+ |
+ | | | | UNI | | | | | | | | UNI | | | |
+ | -+ EN1+-+-----+--+ CN1 +----+ CN2 +----+ CN3 +---+-----+-+ EN3+- |
+ | | | | +--+--+ | | | | | | +---+-| | |
+ | +----+ | | | +--+--+ +--+--+ +--+--+ | | | +----+ |
+ +---------+ | | | | | | | +---------+
+ | | | | | | |
+ +---------+ | | +--+--+ | +--+--+ | | +---------+
+ | +----+ | | | | | +-------+ +-----+ | +----+ |
+ | | +-+--+ | | CN4 +---------------+ CN5 | | | | | |
+ | -+ EN2+-+-----+--+ | | +---+-----+-+ EN4+- |
+ | | | | UNI | +-----+ +-----+ | UNI | | | |
+ | +----+ | | | | +----+ |
+ +---------+ +----------------------------------+ +---------+
+ Overlay Core Network Overlay
+ Network Network
+ Legend: EN - Edge Node
+ CN - Core Node
+
+ Figure 1: Overlay Reference Model [RFC4208]
+
+ Figure 1 depicts two types of UNI connectivity: single-homed and
+ dual-homed ENs (which also applies to higher-order multihomed
+ connectivity). Single-homed EN devices are connected to a single CN
+ device via a single UNI link. This single UNI link may constitute a
+ single point of failure. UNI connection between EN1 and CN1 is an
+ example of singled-homed UNI connectivity.
+
+ Such a single point of failure can be avoided when the EN device is
+ connected to two different CN devices, as depicted for EN2 in
+ Figure 1. For the dual-homing case, it is possible to establish two
+ different UNI connections from the same source EN device to the same
+ destination EN device. For example, two connections from EN2 to EN3
+ may use the two UNI links EN2-CN1 and EN2-CN4. To avoid single
+ points of failure within the provider network, it is necessary to
+ also ensure path (LSP) diversity within the core network.
+
+ In a network providing a set of UNI interfaces between ENs and CNs
+ such as that shown in Figure 1, the CNs typically perform path
+ computation. Information sharing across the UNI boundary is
+ restricted based on the policy rules imposed by the core network.
+ Typically, the core network topology information as well as LSP path
+ information is not exposed to the ENs. In the network shown in
+ Figure 1, consider a use case where an LSP from EN2 to EN4 needs to
+ be SRLG diverse from an LSP from EN1 to EN3. In this case, EN2 may
+
+
+
+Ali, et al. Standards Track [Page 5]
+
+RFC 8390 RVSP-TE Path Diversity July 2018
+
+
+ not know SRLG attributes of the EN1-EN3 LSP and hence cannot
+ construct an XRO to exclude these SRLGs. In this example, EN2 cannot
+ use the procedures described in [RFC4874]. Similarly, an LSP from
+ EN2 to EN3 traversing CN1 needs to be diverse from an LSP from EN2 to
+ EN3 going via CN4. Again, in this case, exclusions based on
+ [RFC4874] cannot be used.
+
+ This document addresses these diversity requirements by introducing
+ an approach of excluding the path taken by these particular LSP(s).
+ Each reference LSP or route from which diversity is required is
+ identified by an abstract "identifier". The type of identifier to
+ use is highly dependent on the core network operator's networking
+ deployment scenario; it could be client initiated (provided by the
+ EN), provided by a PCE, or allocated by the (core) network. This
+ document defines three different types of identifiers corresponding
+ to these three cases: a client-initiated identifier, a PCE-allocated
+ identifier, and an identifier allocated by the CN ingress node
+ (UNI-N), i.e., a network-assigned identifier.
+
+1.1. Conventions Used in This Document
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
+ "OPTIONAL" in this document are to be interpreted as described in
+ BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
+ capitals, as shown here.
+
+1.2. Terms and Abbreviations
+
+ Diverse LSP: A diverse Label Switched Path (LSP) is an LSP that has
+ a path that does not have any link or SRLG in common with the path
+ of a given LSP. Diverse LSPs are meaningful in the context of
+ protection or restoration.
+
+ ERO: Explicit Route Object as defined in [RFC3209].
+
+ EXRS: Explicit Exclusion Route Subobject as defined in [RFC4874].
+
+ SRLG: Shared Risk Link Group as defined in [RFC4202].
+
+ Reference Path: The reference path is the path of an existing LSP to
+ which the path of a diverse LSP shall be diverse.
+
+ XRO: eXclude Route Object as defined in [RFC4874].
+
+
+
+
+
+
+
+Ali, et al. Standards Track [Page 6]
+
+RFC 8390 RVSP-TE Path Diversity July 2018
+
+
+1.3. Client-Initiated Identifier
+
+ The following fields MUST be used to represent the client-initiated
+ identifier: IPv4/IPv6 tunnel sender address, IPv4/IPv6 tunnel
+ endpoint address, Tunnel ID, and Extended Tunnel ID. Based on local
+ policy, the client MAY also include the LSP ID to identify a specific
+ LSP within the tunnel. These fields are defined in Sections 4.6.1.1
+ and 4.6.2.1 of [RFC3209].
+
+ The usage of the client-initiated identifier is illustrated by
+ Figure 1. Suppose an LSP from EN2 to EN4 needs to be diverse with
+ respect to an LSP from EN1 to EN3.
+
+ The LSP identifier of the EN1-EN3 LSP is LSP-IDENTIFIER1, where LSP-
+ IDENTIFIER1 is defined by the tuple
+
+ (tunnel-id = T1,
+ LSP ID = L1,
+ source address = EN1.RID (Route Identifier),
+ destination address = EN3.RID,
+ extended tunnel-id = EN1.RID).
+
+ Similarly, the LSP identifier of the EN2-EN4 LSP is LSP-IDENTIFIER2,
+ where LSP-IDENTIFIER2 is defined by the tuple
+
+ (tunnel-id = T2,
+ LSP ID = L2,
+ source address = EN2.RID,
+ destination address = EN4.RID,
+ extended tunnel-id = EN2.RID).
+
+ The EN1-EN3 LSP is signaled with an exclusion requirement from LSP-
+ IDENTIFIER2, and the EN2-EN4 LSP is signaled with an exclusion
+ requirement from LSP-IDENTIFIER1. In order to maintain diversity
+ between these two connections within the core network, the core
+ network SHOULD implement crankback signaling extensions as defined in
+ [RFC4920]. Note that crankback signaling is known to lead to slower
+ setup times and suboptimal paths under some circumstances as
+ described by [RFC4920].
+
+1.4. PCE-Allocated Identifier
+
+ In scenarios where a PCE is deployed and used to perform path
+ computation, typically the ingress node of the core network (e.g.,
+ node CN1 in Figure 1) could consult a PCE to allocate identifiers,
+ which are used to signal path diversity constraints. In other
+ deployment scenarios, a PCE is deployed at a network node(s) or it is
+
+
+
+
+Ali, et al. Standards Track [Page 7]
+
+RFC 8390 RVSP-TE Path Diversity July 2018
+
+
+ part of a Network Management System (NMS). In all these cases, the
+ PCE is consulted and the Path Key, as defined in [RFC5520], can be
+ used in RSVP signaling as the identifier to ensure diversity.
+
+ An example of specifying LSP diversity using a Path Key is shown in
+ Figure 2, where a simple network with two domains is shown. It is
+ desired to set up a pair of path-disjoint LSPs from the source in
+ Domain 1 to the destination in Domain 2, but the domains keep strict
+ confidentiality about all path and topology information.
+
+ The first LSP is signaled by the source with ERO {A, B, loose Dst}
+ and is set up with the path {Src, A, B, U, V, W, Dst}. However, when
+ sending the Record Route Object (RRO) out of Domain 2, node U would
+ normally strip the path and replace it with a loose hop to the
+ destination. With this limited information, the source is unable to
+ include enough detail in the ERO of the second LSP to avoid it
+ taking, for example, the path {Src, C, D, X, V, W, Dst} for path-
+ disjointness.
+
+ --------------------- -----------------------------
+ | Domain 1 | | Domain 2 |
+ | | | |
+ | --- --- | | --- --- --- |
+ | | A |--| B |--+--+--| U |--| V |---| W | |
+ | / --- --- | | --- --- --- \ |
+ | ---/ | | / / \--- |
+ | |Src| | | / / |Dst| |
+ | ---\ | | / / /--- |
+ | \ --- --- | | --- / --- / --- / |
+ | | C |--| D |--+--+--| X |---| Y |--| Z | |
+ | --- --- | | --- --- --- |
+ | | | |
+ --------------------- -----------------------------
+
+ Figure 2: A Simple Multi-domain Network
+
+ In order to support LSP diversity, node U consults the PCE and
+ replaces the path segment {U, V, W} in the RRO with a Path Key
+ subobject. The PCE function assigns an "identifier" and puts it into
+ the Path Key field of the Path Key subobject. The PCE ID in the
+ message indicates that this replacement operation was performed by
+ node U.
+
+ With this additional information, the source node is able to signal
+ the subsequent LSPs with the ERO set to {C, D, exclude Path Key
+ (signaled in the EXRS RSVP subobject), loose Dst}. When the
+ signaling message reaches node X, it can consult the PCE function
+ associated with node U to expand the Path Key in order to calculate a
+
+
+
+Ali, et al. Standards Track [Page 8]
+
+RFC 8390 RVSP-TE Path Diversity July 2018
+
+
+ path that is diverse with respect to the first LSP. Alternatively,
+ the source node could use an ERO of {C, D, loose Dst} and include an
+ XRO containing the Path Key.
+
+ This mechanism can work with all the Path Key resolution mechanisms,
+ as detailed in Section 3.1 of [RFC5553]. A PCE, co-located or not,
+ may be used to resolve the Path Key, but the node (i.e., a Label
+ Switching Router (LSR)) can also use the Path Key information to
+ index a path segment previously supplied to it by the entity that
+ originated the Path Key (for example, the LSR that inserted the Path
+ Key in the RRO or a management system).
+
+1.5. Network-Assigned Identifier
+
+ There are scenarios in which the network provides diversity-related
+ information for a service that allows the client device to include
+ this information in the signaling message. If the Shared Risk Link
+ Group (SRLG) identifier information is both available and shareable
+ (by policy) with the ENs, the procedure defined in [RFC8001] can be
+ used to collect SRLG identifiers associated with an LSP (LSP1). When
+ a second LSP (LSP2) needs to be diverse with respect to LSP1, the EN
+ constructing the RSVP signaling message for setting up LSP2 can
+ insert the SRLG identifiers associated with LSP1 as diversity
+ constraints into the XRO using the procedure described in [RFC4874].
+ However, if the core network SRLG identifiers are either not
+ available or not shareable with the ENs based on policies enforced by
+ the core network, existing mechanisms cannot be used.
+
+ In this document, a signaling mechanism is defined where information
+ signaled to the CN via the UNI does not require shared knowledge of
+ core network SRLG information. For this purpose, the concept of a
+ Path Affinity Set (PAS) is defined for abstracting SRLG information.
+ The motive behind the introduction of the PAS is to minimize the
+ exchange of diversity information between the core network (CNs) and
+ the client devices (ENs). The PAS contains an abstract SRLG
+ identifier associated with a given path rather than a detailed SRLG
+ list. The PAS is a single identifier that can be used to request
+ diversity and associate diversity. The means by which the processing
+ node determines the path corresponding to the PAS is beyond the scope
+ of this document.
+
+ A CN on the core network boundary interprets the specific PAS
+ identifier (e.g., "123") as meaning to exclude the core network SRLG
+ information (or equivalent) that has been allocated by LSPs
+ associated with this PAS identifier value. For example, if a path
+ exists for the LSP with the PAS identifier "123", the CN would use
+ local knowledge of the core network SRLGs associated with the LSPs
+ tagged with PAS attribute "123" and use those SRLGs as constraints
+
+
+
+Ali, et al. Standards Track [Page 9]
+
+RFC 8390 RVSP-TE Path Diversity July 2018
+
+
+ for path computation. If a PAS identifier is used as an exclusion
+ identifier in the connection request, the CN (UNI-N) in the core
+ network is assumed to be able to determine the existing core network
+ SRLG information and calculate a path that meets the determined
+ diversity constraints.
+
+ When a CN satisfies a connection setup for an SRLG-diverse signaled
+ path, the CN may optionally record the core network SRLG information
+ for that connection in terms of CN-based parameters and associate
+ that with the EN addresses in the Path message. Specifically, for
+ Layer 1 Virtual Private Networks (L1VPNs), Port Information Tables
+ (PITs) [RFC5251] can be leveraged to translate between client (EN)
+ addresses and core network addresses.
+
+ The means to distribute the PAS information within the core network
+ is beyond the scope of this document. For example, the PAS and the
+ associated SRLG information can be distributed within the core
+ network by an Interior Gateway Protocol (IGP) or by other means such
+ as configuration. Regardless of means used to distribute the PAS
+ information, the information is kept inside the core network and is
+ not shared with the overlay network (see Figure 1).
+
+2. RSVP-TE Signaling Extensions
+
+ This section describes the signaling extensions required to address
+ the aforementioned requirements and use cases.
+
+2.1. Diversity XRO Subobject
+
+ New Diversity XRO subobjects are defined below for the IPv4 and IPv6
+ address families. Most of the fields in the IPv4 and IPv6 Diversity
+ XRO subobjects are common and are described following the definition
+ of the two subobjects.
+
+ The IPv4 Diversity XRO subobject is defined as follows:
+
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ |L| XRO Type | Length |DI Type|A-Flags|E-Flags| Resvd |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | IPv4 Diversity Identifier Source Address |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Diversity Identifier Value |
+ // ... //
+ | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+
+
+Ali, et al. Standards Track [Page 10]
+
+RFC 8390 RVSP-TE Path Diversity July 2018
+
+
+ Similarly, the IPv6 Diversity XRO subobject is defined as follows:
+
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ |L| XRO Type | Length |DI Type|A-Flags|E-Flags| Resvd |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | IPv6 Diversity Identifier Source Address |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | IPv6 Diversity Identifier Source Address (cont.) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | IPv6 Diversity Identifier Source Address (cont.) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | IPv6 Diversity Identifier Source Address (cont.) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Diversity Identifier Value |
+ // ... //
+ | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ L:
+ The L flag is used in the same way as for the XRO subobjects
+ defined in [RFC4874], that is:
+
+ 0 indicates that the diversity constraints MUST be satisfied, and
+
+ 1 indicates that the diversity constraints SHOULD be satisfied.
+
+ XRO Type:
+ The value is set to 38 for the IPv4 Diversity XRO subobject. The
+ value is set to 39 for the IPv6 Diversity XRO subobject.
+
+ Length:
+ Per [RFC4874], the Length contains the total length of the
+ IPv4/IPv6 subobject in bytes, including the XRO Type and Length
+ fields. The Length is variable, depending on the Diversity
+ Identifier Value.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Ali, et al. Standards Track [Page 11]
+
+RFC 8390 RVSP-TE Path Diversity July 2018
+
+
+ Diversity Identifier Type (DI Type):
+ Diversity Identifier Type (DI Type) indicates the way the
+ reference LSP(s) or route(s) with which diversity is required is
+ identified in the IPv4/IPv6 Diversity subobjects. The following
+ three DI Type values are defined in this document:
+
+ DI Type value Definition
+ ------------- --------------------------------
+ 1 Client-Initiated Identifier
+ 2 PCE-Allocated Identifier
+ 3 Network-Assigned Identifier
+
+ Attribute Flags (A-Flags):
+ The Attribute Flags (A-Flags) are used to communicate desirable
+ attributes of the LSP being signaled in the IPv4/IPv6 Diversity
+ subobjects. Each flag acts independently. Any combination of
+ flags is permitted.
+
+ 0x01 = Destination node exception
+ Indicates that the exclusion does not apply to the destination
+ node of the LSP being signaled.
+
+ 0x02 = Processing node exception
+ Indicates that the exclusion does not apply to the node(s)
+ performing ERO expansion for the LSP being signaled. An
+ ingress UNI-N node is an example of such a node.
+
+ 0x04 = Penultimate node exception
+ Indicates that the penultimate node of the LSP being signaled
+ MAY be shared with the excluded path even when this violates
+ the exclusion flags. This flag is useful, for example, when an
+ EN is not dual homed (like EN4 in Figure 1, where all LSPs have
+ to go through CN5).
+
+ The "Penultimate node exception" flag is typically set when the
+ destination node is single homed (e.g., EN1 or EN4 in
+ Figure 2). In such a case, LSP diversity can only be
+ accomplished inside the core network up to the egress node and
+ the penultimate hop must be the same for the LSPs.
+
+ 0x08 = LSP ID to be ignored
+ This flag is used to indicate tunnel-level exclusion.
+ Specifically, this flag is used to indicate that if the
+ diversity identifier contains an LSP ID field, then the LSP ID
+ is to be ignored, and the exclusion applies to any LSP matching
+ the rest of the diversity identifier.
+
+
+
+
+
+Ali, et al. Standards Track [Page 12]
+
+RFC 8390 RVSP-TE Path Diversity July 2018
+
+
+ Exclusion Flags (E-Flags):
+ The Exclusion Flags are used to communicate the desired type(s) of
+ exclusion requested in the IPv4/IPv6 Diversity subobjects. The
+ following flags are defined. Any combination of these flags is
+ permitted. Please note that the exclusion specified by these
+ flags may be modified by the value of the A-Flags. For example,
+ the node exclusion flag is ignored for the penultimate node if the
+ "Penultimate node exception" flag of the A-Flags is set.
+
+ 0x01 = SRLG exclusion
+ Indicates that the path of the LSP being signaled is requested
+ to be SRLG disjoint with respect to the excluded path specified
+ by the IPv4/IPv6 Diversity XRO subobject.
+
+ 0x02 = Node exclusion
+ Indicates that the path of the LSP being signaled is requested
+ to be "node diverse" from the excluded path specified by the
+ IPv4/IPv6 Diversity XRO subobject.
+
+ 0x04 = Link exclusion
+ Indicates that the path of the LSP being signaled is requested
+ to be "link diverse" from the path specified by the IPv4/IPv6
+ Diversity XRO subobject.
+
+ 0x08 = Reserved
+ This flag is reserved. It MUST be set to zero on transmission
+ and MUST be ignored on receipt for both IPv4/IPv6 Diversity XRO
+ subobjects.
+
+ Resvd:
+ This field is reserved. It MUST be set to zero on transmission
+ and MUST be ignored on receipt for both IPv4/IPv6 Diversity XRO
+ subobjects.
+
+ IPv4/IPv6 Diversity Identifier Source Address:
+ This field MUST be set to the IPv4/IPv6 address of the node that
+ assigns the diversity identifier. Depending on the Diversity
+ Identifier Type, the diversity identifier source may be a client
+ node, PCE entity, or network node. Specifically:
+
+ * When the Diversity Identifier Type is set to the "Client-
+ Initiated Identifier", the value MUST be set to IPv4/IPv6
+ tunnel sender address of the reference LSP against which
+ diversity is desired. The IPv4/IPv6 tunnel sender address is
+ as defined in [RFC3209].
+
+
+
+
+
+
+Ali, et al. Standards Track [Page 13]
+
+RFC 8390 RVSP-TE Path Diversity July 2018
+
+
+ * When the Diversity Identifier Type is set to "PCE-Allocated
+ Identifier", the value MUST be set to the IPv4/IPv6 address of
+ the node that assigned the Path Key identifier and that can
+ return an expansion of the Path Key or use the Path Key as
+ exclusion in a path computation. The Path Key is defined in
+ [RFC5553]. The PCE ID is carried in the Diversity Identifier
+ Source Address field of the subobject.
+
+ * When the Diversity Identifier Type is set to "Network-Assigned
+ Identifier", the value MUST be set to the IPv4/IPv6 address of
+ the node allocating the Path Affinity Set (PAS).
+
+ Diversity Identifier Value: Encoding for this field depends on the
+ Diversity Identifier Type, as defined in the following.
+
+ When the Diversity Identifier Type is set to "Client-Initiated
+ Identifier" in the IPv4 Diversity XRO subobject, the Diversity
+ Identifier Value MUST be encoded as follows:
+
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | IPv4 Tunnel Endpoint Address |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Must Be Zero | Tunnel ID |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Extended Tunnel ID |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Must Be Zero | LSP ID |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ The IPv4 Tunnel Endpoint Address, Tunnel ID, Extended Tunnel ID,
+ and LSP ID are as defined in [RFC3209].
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Ali, et al. Standards Track [Page 14]
+
+RFC 8390 RVSP-TE Path Diversity July 2018
+
+
+ When the Diversity Identifier Type is set to "Client-Initiated
+ Identifier" in the IPv6 Diversity XRO subobject, the Diversity
+ Identifier Value MUST be encoded as follows:
+
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | IPv6 Tunnel Endpoint Address |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | IPv6 Tunnel Endpoint Address (cont.) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | IPv6 Tunnel Endpoint Address (cont.) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | IPv6 Tunnel Endpoint Address (cont.) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Must Be Zero | Tunnel ID |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Extended Tunnel ID |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Extended Tunnel ID (cont.) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Extended Tunnel ID (cont.) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Extended Tunnel ID (cont.) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Must Be Zero | LSP ID |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ The IPv6 Tunnel Endpoint Address, Tunnel ID, IPv6 Extended Tunnel
+ ID, and LSP ID are as defined in [RFC3209].
+
+ When the Diversity Identifier Type is set to "PCE-Allocated
+ Identifier" in the IPv4 or IPv6 Diversity XRO subobject, the
+ Diversity Identifier Value MUST be encoded as follows:
+
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Must Be Zero | Path Key |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ The Path Key is defined in [RFC5553].
+
+
+
+
+
+
+
+
+
+Ali, et al. Standards Track [Page 15]
+
+RFC 8390 RVSP-TE Path Diversity July 2018
+
+
+ When the Diversity Identifier Type is set to "Network-Assigned
+ Identifier" in the IPv4 or IPv6 Diversity XRO subobject, the
+ Diversity Identifier Value MUST be encoded as follows:
+
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Path Affinity Set (PAS) Identifier |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ The Path Affinity Set (PAS) Identifier field is a 32-bit value
+ that is scoped by (i.e., is only meaningful when used in
+ combination with) the Diversity Identifier Source Address field.
+ There are no restrictions on how a node selects a PAS identifier
+ value. Section 1.3 defines the PAS term and provides context on
+ how values may be selected.
+
+2.2. Diversity EXRS Subobject
+
+ [RFC4874] defines the EXRS ERO subobject. An EXRS is used to
+ identify abstract nodes or resources that must not or should not be
+ used on the path between two inclusive abstract nodes or resources in
+ the explicit route. An EXRS contains one or more subobjects of its
+ own, called EXRS subobjects [RFC4874].
+
+ An EXRS MAY include a Diversity subobject as specified in this
+ document. The same type values 38 and 39 MUST be used.
+
+2.3. Processing Rules for the Diversity XRO and EXRS Subobjects
+
+ The procedure defined in [RFC4874] for processing the XRO and EXRS is
+ not changed by this document. The processing rules for the Diversity
+ XRO and EXRS subobjects are similar unless the differences are
+ explicitly described. Similarly, IPv4 and IPv6 Diversity XRO
+ subobjects and IPv4 and IPv6 Diversity EXRS subobjects follow the
+ same processing rules.
+
+ If the processing node cannot recognize the Diversity XRO/EXRS
+ subobject, the node is expected to follow the procedure defined in
+ [RFC4874].
+
+ An XRO/EXRS object MAY contain multiple Diversity subobjects of the
+ same DI Type. For example, in order to exclude multiple Path Keys, a
+ node MAY include multiple Diversity XRO subobjects, each with a
+ different Path Key. Similarly, in order to exclude the routes taken
+ by multiple LSPs, a node MAY include multiple Diversity XRO/EXRS
+ subobjects, each with a different LSP identifier. Likewise, to
+ exclude multiple PAS identifiers, a node MAY include multiple
+
+
+
+Ali, et al. Standards Track [Page 16]
+
+RFC 8390 RVSP-TE Path Diversity July 2018
+
+
+ Diversity XRO/EXRS subobjects, each with a different PAS identifier.
+ However, all Diversity subobjects in an XRO/EXRS MUST contain the
+ same Diversity Identifier Type. If a Path message contains an XRO/
+ EXRS with multiple Diversity subobjects of different DI Types, the
+ processing node MUST return a PathErr with the error code "Routing
+ Problem" (24) and error sub-code "XRO/EXRS Too Complex" (68/69).
+
+ If the processing node recognizes the Diversity XRO/EXRS subobject
+ but does not support the DI Type, it MUST return a PathErr with the
+ error code "Routing Problem" (24) and error sub-code "Unsupported
+ Diversity Identifier Type" (36).
+
+ In the case of DI Type "Client-Initiated Identifier", all nodes along
+ the path SHOULD process the diversity information signaled in the
+ XRO/EXRS Diversity subobjects to verify that the signaled diversity
+ constraint is satisfied. If a diversity violation is detected,
+ crankback signaling MAY be initiated.
+
+ In the case of DI Type "PCE-Allocated Identifier" and "Network-
+ Assigned Identifier", the nodes in the domain that perform path
+ computation SHOULD process the diversity information signaled in the
+ XRO/EXRS Diversity subobjects as follows. In the PCE case, the
+ ingress node of a domain sends a path computation request for a path
+ from ingress node to egress node, including diversity constraints to
+ a PCE. Or, in the PAS case, the ingress node is capable of
+ calculating the path for the new LSP from ingress node to the egress
+ node, taking the diversity constraints into account. The calculated
+ path is then carried in the Explicit Route Object (ERO). Hence, the
+ transit nodes in a domain and the domain egress node SHOULD NOT
+ process the signaled diversity information unless path computation is
+ performed.
+
+ While processing the EXRS object, if a loose hop expansion results in
+ the creation of another loose hop in the outgoing ERO, the processing
+ node MAY include the EXRS in the newly created loose hop for further
+ processing by downstream nodes.
+
+ The A-Flags affect the processing of the Diversity XRO/EXRS subobject
+ as follows:
+
+ o When the "Processing node exception" flag is set, the exclusion
+ MUST be ignored for the node processing the XRO or EXRS subobject.
+
+ o When the "Destination node exception" flag is set, the exclusion
+ MUST be ignored for the destination node in processing the XRO
+ subobject. The destination node exception for the EXRS subobject
+ applies to the explicit node identified by the ERO subobject that
+
+
+
+
+Ali, et al. Standards Track [Page 17]
+
+RFC 8390 RVSP-TE Path Diversity July 2018
+
+
+ identifies the next abstract node. When the "Destination node
+ exception" flag is set in the EXRS subobject, exclusion MUST be
+ ignored for said node (i.e., the next abstract node).
+
+ o When the "Penultimate node exception" flag is set in the XRO
+ subobject, the exclusion MUST be ignored for the penultimate node
+ on the path of the LSP being established.
+
+ The penultimate node exception for the EXRS subobject applies to
+ the node before the explicit node identified by the ERO subobject
+ that identifies the next abstract node. When the "Penultimate
+ node exception" flag is set in the EXRS subobject, the exclusion
+ MUST be ignored for said node (i.e., the node before the next
+ abstract node).
+
+ If the L-flag of the Diversity XRO subobject or Diversity EXRS
+ subobject is not set, the processing node proceeds as follows.
+
+ o If the Diversity Identifier Type is set to "Client-Initiated
+ Identifier", the processing node MUST ensure that the path
+ calculated/expanded for the signaled LSP is diverse from the route
+ taken by the LSP identified in the Diversity Identifier Value
+ field.
+
+ o If the Diversity Identifier Type is set to "PCE-Allocated
+ Identifier", the processing node MUST ensure that any path
+ calculated for the signaled LSP is diverse from the route
+ identified by the Path Key. The processing node MAY use the PCE
+ identified by the Diversity Identifier Source Address in the
+ subobject for route computation. The processing node MAY use the
+ Path Key resolution mechanisms described in [RFC5553].
+
+ o If the Diversity Identifier Type is set to "Network-Assigned
+ Identifier", the processing node MUST ensure that the path
+ calculated for the signaled LSP is diverse with respect to the
+ values associated with the PAS Identifier and Diversity Identifier
+ Source Address fields.
+
+ o Regardless of whether the path computation is performed locally or
+ at a remote node (e.g., PCE), the processing node MUST ensure that
+ any path calculated for the signaled LSP is diverse from the
+ requested Exclusion Flags.
+
+ o If the excluded path referenced in the XRO subobject is unknown to
+ the processing node, the processing node SHOULD ignore the
+ Diversity XRO subobject and SHOULD proceed with the signaling
+ request. After sending the Resv for the signaled LSP, the
+
+
+
+
+Ali, et al. Standards Track [Page 18]
+
+RFC 8390 RVSP-TE Path Diversity July 2018
+
+
+ processing node MUST return a PathErr with the error code "Notify
+ Error" (25) and error sub-code "Route of XRO LSP identifier
+ unknown" (14) for the signaled LSP.
+
+ o If the processing node fails to find a path that meets the
+ requested constraint, the processing node MUST return a PathErr
+ with the error code "Routing Problem" (24) and error sub-code
+ "Route blocked by Exclude Route" (67).
+
+ If the L-flag of the Diversity XRO subobject or Diversity EXRS
+ subobject is set, the processing node proceeds as follows:
+
+ o If the Diversity Identifier Type is set to "Client-Initiated
+ Identifier", the processing node SHOULD ensure that the path
+ calculated/expended for the signaled LSP is diverse from the route
+ taken by the LSP identified in the Diversity Identifier Value
+ field.
+
+ o If the Diversity Identifier Type is set to "PCE-Allocated
+ Identifier", the processing node SHOULD ensure that the path
+ calculated for the signaled LSP is diverse from the route
+ identified by the Path Key.
+
+ o If the Diversity Identifier Type is set to "Network-Assigned
+ Identifier", the processing node SHOULD ensure that the path
+ calculated for the signaled LSP is diverse with respect to the
+ values associated with the PAS Identifier and Diversity Identifier
+ Source Address fields.
+
+ o If the processing node fails to find a path that meets the
+ requested constraint, it SHOULD proceed with signaling using a
+ suitable path that meets the constraint as far as possible. After
+ sending the Resv for the signaled LSP, it MUST return a PathErr
+ message with error code "Notify Error" (25) and error sub-code
+ "Failed to satisfy Exclude Route" (15) to the source node.
+
+ If, subsequent to the initial signaling of a diverse LSP, an excluded
+ path referenced in the XRO subobject becomes known to the processing
+ node or a change in the excluded path becomes known to the processing
+ node, the processing node MUST re-evaluate the exclusion and
+ diversity constraints requested by the diverse LSP to determine
+ whether they are still satisfied.
+
+ o In the case where the L-flag was not set in the initial setup
+ message, the exclusion and diversity constraints were satisfied at
+ the time of the initial setup. If the processing node re-
+ evaluating the exclusion and diversity constraints for a diverse
+ LSP detects that the exclusion and diversity constraints are no
+
+
+
+Ali, et al. Standards Track [Page 19]
+
+RFC 8390 RVSP-TE Path Diversity July 2018
+
+
+ longer met, it MUST send a PathErr message for the diverse LSP
+ with the error code "Routing Problem" (24) and error sub-code
+ "Route blocked by Exclude Route" (67). The Path_State_Removed
+ (PSR) flag [RFC3473] MUST NOT be set. A source node receiving a
+ PathErr message with this error code and sub-code combination
+ SHOULD take appropriate actions and move the diverse LSP to a new
+ path that meets the original constraints.
+
+ o In the case where the L-flag was set in the initial setup message,
+ the exclusion and diversity constraints may or may not be
+ satisfied at any given time. If the exclusion constraints for a
+ diverse LSP were satisfied before, and if the processing node re-
+ evaluating the exclusion and diversity constraints for a diverse
+ LSP detects that exclusion and diversity constraints are no longer
+ met, it MUST send a PathErr message for the diverse LSP with the
+ error code "Notify Error" (25) and error sub-code "Failed to
+ satisfy Exclude Route" (15). The PSR flag MUST NOT be set. The
+ source node MAY take no consequent action and keep the LSP along
+ the path that does not meet the original constraints. Similarly,
+ if the exclusion constraints for a diverse LSP were not satisfied
+ before, and if the processing node re-evaluating the exclusion and
+ diversity constraints for a diverse LSP detects that the exclusion
+ constraints are met, it MUST send a PathErr message for the
+ diverse LSP with the error code "Notify Error" (25) and a new
+ error sub-code "Compliant path exists" (16). The PSR flag MUST
+ NOT be set. A source node receiving a PathErr message with this
+ error code and sub-code combination MAY move the diverse LSP to a
+ new path that meets the original constraints.
+
+3. Security Considerations
+
+ This document does not introduce any additional security issues in
+ addition to those identified in [RFC5920], [RFC2205], [RFC3209],
+ [RFC3473], [RFC2747], [RFC4874], [RFC5520], and [RFC5553].
+
+ The diversity mechanisms defined in this document rely on the new
+ diversity subobject that is carried in the XRO or EXRS, respectively.
+ In Section 7 of [RFC4874], it is noted that some administrative
+ boundaries may remove the XRO due to security concerns on explicit
+ route information exchange. However, when the diversity subobjects
+ specified in this document are used, removing at the administrative
+ boundary an XRO containing these diversity subobjects would result in
+ the request for diversity being dropped at the boundary, and path
+ computation would be unlikely to produce the requested diverse path.
+ As such, diversity subobjects MUST be retained in an XRO crossing an
+ administrative boundary, even if other subobjects are removed. This
+
+
+
+
+
+Ali, et al. Standards Track [Page 20]
+
+RFC 8390 RVSP-TE Path Diversity July 2018
+
+
+ retention would be based on operator policy. The use of diversity
+ subobjects is based on mutual agreement. This avoids the need to
+ share the identity of network resources when supporting diversity.
+
+4. IANA Considerations
+
+ IANA has assigned new values defined in this document and summarized
+ in this section.
+
+4.1. New XRO Subobject Types
+
+ In the IANA registry for RSVP parameters, under "Class Names, Class
+ Numbers, and Class Types", this document defines two new subobjects
+ for the EXCLUDE_ROUTE object [RFC4874], C-Type 1 (see "Class Types or
+ C-Types - 232 EXCLUDE_ROUTE" on <https://www.iana.org/assignments/
+ rsvp-parameters>).
+
+ +----------------+-------+
+ | Description | Value |
+ +----------------+-------+
+ | IPv4 Diversity | 38 |
+ | IPv6 Diversity | 39 |
+ +----------------+-------+
+
+4.2. New EXRS Subobject Types
+
+ The Diversity XRO subobjects are also defined as new EXRS subobjects
+ (see "Class Types or C-Types - 20 EXPLICIT_ROUTE" on
+ <https://www.iana.org/assignments/rsvp-parameters>). The same
+ numeric values have been assigned:
+
+ +----------------+-------+
+ | Description | Value |
+ +----------------+-------+
+ | IPv4 Diversity | 38 |
+ | IPv6 Diversity | 39 |
+ +----------------+-------+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Ali, et al. Standards Track [Page 21]
+
+RFC 8390 RVSP-TE Path Diversity July 2018
+
+
+4.3. New RSVP Error Sub-codes
+
+ In the IANA registry for RSVP parameters, under "Error Codes and
+ Globally Defined Error Value Sub-Codes", for Error Code "Routing
+ Problem" (24) (see [RFC3209]), the following sub-codes are defined
+ (see "Sub-Codes - 24 Routing Problem" on
+ <https://www.iana.org/assignments/rsvp-parameters>).
+
+ +-------+---------------------------------------+-----------+
+ | Value | Description | Reference |
+ +-------+---------------------------------------+-----------+
+ | 36 | Unsupported Diversity Identifier Type | RFC 8390 |
+ +-------+---------------------------------------+-----------+
+
+ For Error Code "Notify Error" (25) (see [RFC3209]), the following
+ sub-codes are defined (see "Sub-Codes - 25 Notify Error" on
+ <https://www.iana.org/assignments/rsvp-parameters>).
+
+ +-------+-------------------------------------+-----------+
+ | Value | Description | Reference |
+ +-------+-------------------------------------+-----------+
+ | 14 | Route of XRO LSP identifier unknown | RFC 8390 |
+ | 15 | Failed to satisfy Exclude Route | RFC 8390 |
+ | 16 | Compliant path exists | RFC 8390 |
+ +-------+-------------------------------------+-----------+
+
+5. References
+
+5.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,
+ <https://www.rfc-editor.org/info/rfc2119>.
+
+ [RFC2747] Baker, F., Lindell, B., and M. Talwar, "RSVP Cryptographic
+ Authentication", RFC 2747, DOI 10.17487/RFC2747, January
+ 2000, <https://www.rfc-editor.org/info/rfc2747>.
+
+ [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,
+ <https://www.rfc-editor.org/info/rfc3209>.
+
+
+
+
+
+
+
+
+Ali, et al. Standards Track [Page 22]
+
+RFC 8390 RVSP-TE Path Diversity July 2018
+
+
+ [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,
+ <https://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,
+ <https://www.rfc-editor.org/info/rfc4202>.
+
+ [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, <https://www.rfc-editor.org/info/rfc4874>.
+
+ [RFC4920] Farrel, A., Ed., Satyanarayana, A., Iwata, A., Fujita, N.,
+ and G. Ash, "Crankback Signaling Extensions for MPLS and
+ GMPLS RSVP-TE", RFC 4920, DOI 10.17487/RFC4920, July 2007,
+ <https://www.rfc-editor.org/info/rfc4920>.
+
+ [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,
+ <https://www.rfc-editor.org/info/rfc5553>.
+
+ [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
+ 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
+ May 2017, <https://www.rfc-editor.org/info/rfc8174>.
+
+5.2. Informative References
+
+ [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, <https://www.rfc-editor.org/info/rfc2205>.
+
+ [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,
+ <https://www.rfc-editor.org/info/rfc4208>.
+
+ [RFC5251] Fedyk, D., Ed., Rekhter, Y., Ed., Papadimitriou, D.,
+ Rabbat, R., and L. Berger, "Layer 1 VPN Basic Mode",
+ RFC 5251, DOI 10.17487/RFC5251, July 2008,
+ <https://www.rfc-editor.org/info/rfc5251>.
+
+
+
+Ali, et al. Standards Track [Page 23]
+
+RFC 8390 RVSP-TE Path Diversity July 2018
+
+
+ [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,
+ <https://www.rfc-editor.org/info/rfc5520>.
+
+ [RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS
+ Networks", RFC 5920, DOI 10.17487/RFC5920, July 2010,
+ <https://www.rfc-editor.org/info/rfc5920>.
+
+ [RFC8001] Zhang, F., Ed., Gonzalez de Dios, O., Ed., Margaria, C.,
+ Hartley, M., and Z. Ali, "RSVP-TE Extensions for
+ Collecting Shared Risk Link Group (SRLG) Information",
+ RFC 8001, DOI 10.17487/RFC8001, January 2017,
+ <https://www.rfc-editor.org/info/rfc8001>.
+
+Acknowledgements
+
+ The authors would like to thank Xihua Fu for his contributions. The
+ authors also would like to thank Luyuan Fang and Walid Wakim for
+ their review and comments.
+
+Contributors
+
+ Igor Bryskin
+ Huawei Technologies
+ Email: Igor.Bryskin@huawei.com
+
+ Daniele Ceccarelli
+ Ericsson
+ Email: Daniele.Ceccarelli@ericsson.com
+
+ Dhruv Dhody
+ Huawei Technologies
+ Email: dhruv.ietf@gmail.com
+
+ Don Fedyk
+ Hewlett-Packard Enterprise
+ Email: don.fedyk@hpe.com
+
+ Clarence Filsfils
+ Cisco Systems, Inc.
+ Email: cfilsfil@cisco.com
+
+ Gabriele Maria Galimberti
+ Cisco Systems
+ Email: ggalimbe@cisco.com
+
+
+
+
+Ali, et al. Standards Track [Page 24]
+
+RFC 8390 RVSP-TE Path Diversity July 2018
+
+
+ Ori Gerstel
+ SDN Solutions Ltd.
+ Email: origerstel@gmail.com
+
+ Oscar Gonzalez de Dios
+ Telefonica I+D
+ Email: ogondio@tid.es
+
+ Matt Hartley
+ Cisco Systems
+ Email: mhartley@cisco.com
+
+ Kenji Kumaki
+ KDDI Corporation
+ Email: ke-kumaki@kddi.com
+
+ Ruediger Kunze
+ Deutsche Telekom AG
+ Email: Ruediger.Kunze@telekom.de
+
+ Lieven Levrau
+ Nokia
+ Email: Lieven.Levrau@nokia.com
+
+ Cyril Margaria
+ Email: cyril.margaria@gmail.com
+
+ Julien Meuric
+ France Telecom Orange
+ Email: julien.meuric@orange.com
+
+ Yuji Tochio
+ Fujitsu
+ Email: tochio@jp.fujitsu.com
+
+ Xian Zhang
+ Huawei Technologies
+ Email: zhang.xian@huawei.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+Ali, et al. Standards Track [Page 25]
+
+RFC 8390 RVSP-TE Path Diversity July 2018
+
+
+Authors' Addresses
+
+ Zafar Ali (editor)
+ Cisco Systems.
+
+ Email: zali@cisco.com
+
+
+ George Swallow (editor)
+ Southend Technical Center
+
+ Email: swallow.ietf@gmail.com
+
+
+ Fatai Zhang (editor)
+ Huawei Technologies
+
+ Email: zhangfatai@huawei.com
+
+
+ Dieter Beller (editor)
+ Nokia
+
+ Email: Dieter.Beller@nokia.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Ali, et al. Standards Track [Page 26]
+