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

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/