draft-ietf-teas-lsp-diversity-09.txt   draft-ietf-teas-lsp-diversity-10.txt 
TEAS Working Group Zafar Ali, Ed. TEAS Working Group Zafar Ali, Ed.
Internet Draft George Swallow, Ed. Internet Draft George Swallow, Ed.
Intended status: Standard Track Cisco Systems Intended status: Standard Track Cisco Systems
Updates RFC4874 F. Zhang, Ed. Updates RFC4874 F. Zhang, Ed.
Expires: May 17, 2018 Huawei Expires: September 03, 2018 Huawei
D. Beller, Ed. D. Beller, Ed.
Nokia Nokia
November 13, 2017 March 02, 2018
Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Path Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Path
Diversity using Exclude Route Diversity using Exclude Route
draft-ietf-teas-lsp-diversity-09.txt draft-ietf-teas-lsp-diversity-10.txt
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in progress." reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 28, 2017. This Internet-Draft will expire on September 03, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 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 (http://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 to this document. Code Components extracted from this respect to this document. Code Components extracted from this
document must include Simplified BSD License text as described in document must include Simplified BSD License text as described in
Section 4.e of the Trust Legal Provisions and are provided without Section 4.e of the Trust Legal Provisions and are provided without
warranty as described in the Simplified BSD License. warranty as described in the Simplified BSD License.
Abstract Abstract
Resource ReSerVation Protocol-Traffic Engineering provides support Resource ReSerVation Protocol-Traffic Engineering provides support
for the communication of exclusion information during label switched for the communication of exclusion information during label switched
path (LSP) setup. This document specifies two new diversity path (LSP) setup. A typical LSP diversity use case is for
subobjects for the RSVP eXclude Route Object (XRO) and the Explicit protection, where two LSPs should follow different paths through the
Exclusion Route Subobject (EXRS). Three different mechanisms are network in order to avoid single points of failure, thus greatly
defined to accomplish LSP diversity in the provider or core network: improving service availability. This document specifies an approach
the signaled diversity type indicates whether diversity is based on which can be used for network scenarios where full knowledge of the
client, path computation engine (PCE), or network assigned path(s) is not necessarily known by use of an abstract identifier
identifiers. for the path. Three types of abstract identifiers are specified:
The solution described in this document is based on the assumption client-based, Path Computation Engine (PCE)-based, network-based.
that LSPs are requested sequentially, i.e., the time period between This document specifies two new diversity subobjects for the RSVP
the LSP setup requests for the two LSPs may be relatively long (in eXclude Route Object (XRO) and the Explicit Exclusion Route
the order of days, weeks, months). Re-routing the LSP that was Subobject (EXRS).
established first and may have existed for some time is not
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. considered.
Conventions used in this document Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
Table of Contents Table of Contents
Terms and Abbreviations..........................................3
1. Introduction..................................................3 1. Introduction..................................................3
1.1. Client-Initiated Identifier..............................5 1.1. Client-Initiated Identifier..............................6
1.2. PCE-allocated Identifier.................................6 1.2. PCE-allocated Identifier.................................7
1.3. Network-Assigned Identifier..............................7 1.3. Network-Assigned Identifier..............................8
2. RSVP-TE signaling extensions..................................9 2. RSVP-TE signaling extensions.................................10
2.1. Diversity XRO Subobject..................................9 2.1. Diversity XRO Subobject.................................10
2.2. Diversity EXRS Subobject................................16 2.2. Diversity EXRS Subobject................................17
2.3. Processing rules for the Diversity XRO and EXRS 2.3. Processing rules for the Diversity XRO and EXRS
subobjects..............................................16 subobjects..............................................17
3. Security Considerations......................................20 3. Security Considerations......................................21
4. IANA Considerations..........................................20 4. IANA Considerations..........................................22
4.1. New XRO subobject types.................................20 4.1. New XRO subobject types.................................22
4.2. New EXRS subobject types................................21 4.2. New EXRS subobject types................................22
4.3. New RSVP error sub-codes................................21 4.3. New RSVP error sub-codes................................22
5. Acknowledgements.............................................22
6. References...................................................22 5. Acknowledgements.............................................23
6.1. Normative References....................................22 6. References...................................................23
6.2. Informative 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
LSP, to which the path of a diverse LSP shall be diverse.
XRO: eXclude Route Object as defined in [RFC4874]
1. Introduction 1. Introduction
Path diversity for multiple connections is a well-known Service Path diversity for multiple connections is a well-known
Provider requirement. Diversity constraints ensure that Label- operational requirement. Diversity constraints ensure that Label-
Switched Paths (LSPs) can be established without sharing network Switched Paths (LSPs) can be established without sharing network
resources, thus greatly reducing the probability of simultaneous resources, thus 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 knowledge of the network topology and is permitted to signal full knowledge of the network topology and is permitted to signal
an Explicit Route Object. However, there are scenarios where an 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 need for relevant diversity constraints to be signaled to those a 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 (ERO), e.g. . LSPs with loose hops in the Explicit Route Object, e.g. inter-
inter-domain LSPs. domain LSPs.
. Generalized Multi-Protocol Label Switching (GMPLS) User- . Generalized Multi-Protocol Label Switching (GMPLS) User-
Network Interface (UNI), where the core node may perform path Network Interface (UNI), where the core node may perform path
computation [RFC4208]. computation [RFC4208].
[RFC4874] introduced a means of specifying nodes and resources to [RFC4874] introduced a means of specifying nodes and resources to
be excluded from a route, using the eXclude Route Object (XRO) and be 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
skipping to change at page 4, line 5 skipping to change at page 4, line 31
. Exclusion of a path which is known to the source node of the . Exclusion of a path which 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 diversity from the reference path is not fully known. guarantee diversity from the reference path is not fully known.
Inter-domain and GMPLS overlay networks can impose such Inter-domain and GMPLS overlay networks can impose such
restrictions. restrictions.
This is exemplified in the Figure 1, where the overlay reference This is illustrated in the Figure 1, where the overlay reference
model from [RFC4208] is shown. model 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+- |
| | | | +--+--+ | | | | | | +---+-| | | | | | | +--+--+ | | | | | | +---+-| | |
| +----+ | | | +--+--+ +--+--+ +--+--+ | | | +----+ | | +----+ | | | +--+--+ +--+--+ +--+--+ | | | +----+ |
skipping to change at page 4, line 35 skipping to change at page 5, line 32
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 multi-homed
connectivity.). Single-homed EN devices are connected to a single connectivity). Single-homed EN devices are connected to a single
CN device via a single UNI link. This single UNI link may CN device via a single UNI link. This single UNI link may
constitute a single point of failure. UNI connection between EN1 constitute a single point of failure. UNI connection between EN1
and CN1 is an example of singled-homed UNI connectivity. and CN1 is an example of singled-homed UNI connectivity.
A single point of failure caused by a single-homed UNI can be Such a single point of failure can be avoided when the EN device
avoided when the EN device is connected to two different CN is connected to two different CN devices, as depicted for EN2 in
devices, as depicted for EN2 in Figure 1. For the dual-homing Figure 1. For the dual-homing case, it is possible to establish
case, it is possible to establish two different UNI connections two different UNI connections from the same source EN device to
from the same source EN device to the same destination EN device. the same destination EN device. For example, two connections from
For example, two connections from EN2 to EN3 may use the two UNI EN2 to EN3 may use the two UNI links EN2-CN1 and EN2-CN4. To
links EN2-CN1 and EN2-CN4. To avoid single points of failure avoid single points of failure within the provider network, it is
within the provider network, it is necessary to also ensure path necessary to also ensure path (LSP) diversity within the core
(LSP) diversity within the core network. network.
In a UNI network such as that shown in Figure 1, the CNs In a network providing a set of UNI interfaces between ENs and
typically perform path computation. Information sharing across CNs such as that shown in Figure 1, the CNs typically perform
the UNI boundary is restricted based on the policy rules imposed path computation. Information sharing across the UNI boundary is
by the core network. Typically, the core network topology restricted based on the policy rules imposed by the core network.
information is not exposed to the ENs. In the network shown in Typically, the core network topology information as well as LSP
Figure 1, consider a use case where an LSP from EN2 to EN4 needs path information is not exposed to the ENs. In the network shown
to be SRLG diverse from an LSP from EN1 to EN3. In this case, EN2 in Figure 1, consider a use case where an LSP from EN2 to EN4
may not know SRLG attributes of the EN1- EN3 LSP and hence cannot needs to be SRLG diverse from an LSP from EN1 to EN3. In this
construct an XRO to exclude these SRLGs. In this example EN2 case, EN2 may not know SRLG attributes of the EN1- EN3 LSP and
cannot use the procedures described in [RFC4874]. Similarly, an hence cannot construct an XRO to exclude these SRLGs. In this
LSP from EN2 to EN3 traversing CN1 needs to be diverse from an example EN2 cannot use the procedures described in [RFC4874].
LSP from EN2 to EN3 going via CN4. Again in this case, exclusions Similarly, an LSP from EN2 to EN3 traversing CN1 needs to be
based on [RFC4874] cannot be used. diverse from an LSP from EN2 to EN3 going via CN4. Again, in this
case, exclusions based on [RFC4874] cannot be used.
This document addresses these diversity requirements by This document addresses these diversity requirements by
introducing the notion of excluding the path taken by particular introducing an approach of excluding the path taken by these
LSP(s). The reference LSP(s) or route(s) from which diversity is particular LSP(s). The reference LSP(s) or route(s) from which
required is/are identified by an "identifier". The type of diversity is required is/are identified by an abstract
identifier to use is highly dependent on the networking "identifier". The type of identifier to use is highly dependent
deployment scenario; it could be client-initiated, allocated by on the core network operator's networking deployment scenario; it
the (core) network or managed by a PCE. This document defines could be client-initiated (provided by the EN), provided by a PCE
three different types of identifiers corresponding to these three or allocated by the (core) network. This document defines three
cases: a client initiated identifier, a PCE allocated Identifier different types of identifiers corresponding to these three
and CN ingress node (UNI-N) allocated Identifier. cases: a client-initiated identifier, a PCE allocated identifier
and CN ingress node (UNI-N) allocated identifier (= network-
assigned identifier).
1.1. Client-Initiated Identifier 1.1. Client-Initiated Identifier
The following fields MUST be used to represent the client- The following fields MUST be used to represent the client-
controlled identifier: IPv4/IPv6 tunnel sender address, initiated identifier: IPv4/IPv6 tunnel sender address,
IPv4/IPv6 tunnel endpoint address, Tunnel ID, and Extended IPv4/IPv6 tunnel endpoint address, Tunnel ID, and Extended
Tunnel ID. The client MAY also include LSP ID to identify a Tunnel ID. Based on local policy, the client MAY also include
specific LSP within the tunnel. These fields are defined in the LSP ID to identify a specific LSP within the tunnel. These
[RFC3209], sections 4.6.1.1 and 4.6.2.1. 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 The usage of the client-initiated identifier is illustrated by
Figure 1. Suppose a LSP from EN2 to EN4 needs to be diverse with 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- 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 EN3 LSP is LSP-IDENTIFIER1, where LSP-IDENTIFIER1 is defined by
the tuple (tunnel-id = T1, LSP ID = L1, source address = the tuple (tunnel-id = T1, LSP ID = L1, source address = EN1.RID
EN1.ROUTE Identifier (RID), destination address = EN3.RID, (ROUTE Identifier), destination address = EN3.RID, extended
extended tunnel-id = EN1.RID). Similarly, LSP identifier of the tunnel-id = EN1.RID). Similarly, LSP identifier of the EN2-EN4
EN2-EN3 LSP is LSP-IDENTIFIER2, where LSP-IDENTIFIER12 is defined LSP is LSP-IDENTIFIER2, where LSP-IDENTIFIER2 is defined by the
by the tuple (tunnel-id = T2, LSP IS = L1, source address = tuple (tunnel-id = T2, LSP ID = L2, source address = EN2.RID,
EN2.RID, destination address = EN4.RID, extended tunnel-id = destination address = EN4.RID, extended tunnel-id = EN2.RID). The
EN2.RID). The EN1-EN3 LSP is signaled with an exclusion EN1-EN3 LSP is signaled with an exclusion requirement from LSP-
requirement from LSP-IDENTIFIER2, and the EN2-EN3 LSP is signaled IDENTIFIER2, and the EN2-EN4 LSP is signaled with an exclusion
with an exclusion requirement from LSP-IDENTIFIER1. In order to requirement from LSP-IDENTIFIER1. In order to maintain diversity
maintain diversity between these two connections within the core between these two connections within the core network, the core
network, the core network SHOULD implement Crankback Signaling network SHOULD implement Crankback Signaling Extensions as
[RFC4920]. Note that crankback signaling is known to lead to defined in [RFC4920]. Note that crankback signaling is known to
slower setup times and sub-optimal paths under some circumstances lead to slower setup times and sub-optimal paths under some
as described by [RFC4920]. circumstances as described by [RFC4920].
1.2. PCE-allocated Identifier 1.2. PCE-allocated Identifier
In scenarios where a PCE is deployed and used to perform path In scenarios where a PCE is deployed and used to perform path
computation, the core edge node (e.g., node CN1 in Figure 1) computation, the core edge node (e.g., node CN1 in Figure 1)
could consult a PCE to allocate identifiers, which are used to could consult a PCE to allocate identifiers, which are used to
signal path diversity constraints. In other scenarios, a PCE is signal path diversity constraints. In other deployment scenarios,
deployed at network node(s) or a PCE is part of a Network a PCE is deployed at a network node(s) or a PCE is part of a
Management System (NMS). In all these cases, the Path Key as Network Management System (NMS). In all these cases, the PCE is
defined in [RFC5520] can be used in RSVP signaling as the consulted and the Path-Key as defined in [RFC5520] can be used in
identifier to ensure diversity. RSVP signaling as the identifier to ensure diversity.
An example of specifying LSP diversity using a Path Key is shown 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 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 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 in Domain 1 to the destination in Domain 2, but the domains keep
strict confidentiality about all path and topology information. strict confidentiality about all path and topology information.
The first LSP is signaled by the source with ERO {A, B, loose Dst} 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, and is set up with the path {Src, A, B, U, V, W, Dst}. However,
when sending the RRO out of Domain 2, node U would normally strip when sending the Record Route Object (RRO) out of Domain 2, node
the path and replace it with a loose hop to the destination. With U would normally strip the path and replace it with a loose hop
this limited information, the source is unable to include enough to the destination. With this limited information, the source is
detail in the ERO of the second LSP to avoid it taking, for unable to include enough detail in the ERO of the second LSP to
example, the path {Src, C, D, X, V, W, Dst} for path-disjointness. 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 improve the situation, node U performs the PCE In order to support LSP diversity, node U consults the PCE and
function and replaces the path segment {U, V, W} in the RRO with replaces the path segment {U, V, W} in the RRO with a Path Key
a Path Key subobject. The Path Key subobject assigns an subobject. The PCE function assigns an "identifier" and puts it
"identifier" to the key. The PCE ID in the message indicates that into the Path Key field of the Path Key subobject. The PCE ID in
it was node U that made the replacement. the message indicates that this replacement operation was
performed by node U.
With this additional information, the source is able to signal With this additional information, the source node is able to
the subsequent LSPs with the ERO set to {C, D, exclude Path signal the subsequent LSPs with the ERO set to {C, D, exclude
Key(EXRS), loose Dst}. When the signaling message reaches node X, Path Key(EXRS), loose Dst}. When the signaling message reaches
it can consult node U to expand the Path Key and know how to node X, it can consult the PCE function associated with node U to
avoid the path of the first LSP. Alternatively, the source could expand the Path Key in order to calculate a path that is diverse
use an ERO of {C, D, loose Dst} and include an XRO containing the with respect to the first LSP. Alternatively, the source node
Path Key. could use an ERO of {C, D, loose Dst} and include an XRO
containing the Path Key.
This mechanism can work with all the Path-Key resolution This mechanism can work with all the Path Key resolution
mechanisms, as detailed in [RFC5553] section 3.1. A PCE, co- mechanisms, as detailed in [RFC5553] section 3.1. A PCE, co-
located or not, may be used to resolve the Path-Key, but the node located or not, may be used to resolve the Path Key, but the node
(i.e., a Label Switching Router (LSR)) can also use the Path Key (i.e., a Label Switching Router (LSR)) can also use the Path Key
information to index a Path Segment previously supplied to it by information to index a Path Segment previously supplied to it by
the entity that originated the Path-Key, for example the LSR that the entity that originated the Path Key, for example the LSR that
inserted the Path-Key in the RRO or a management system. inserted the Path Key in the RRO or a management system.
1.3. Network-Assigned Identifier 1.3. Network-Assigned Identifier
There are scenarios in which the network provides diversity- There are scenarios in which the network provides diversity-
related information for a service that allows the client device related information for a service that allows the client device
to include this information in the signaling message. If the to include this information in the signaling message. If the
Shared Resource Link Group (SRLG) identifier information is both Shared Resource Link Group (SRLG) identifier information is both
available and shareable (by policy) with the ENs, the procedure available and shareable (by policy) with the ENs, the procedure
defined in [RFC8001] can be used to collect SRLG identifiers defined in [RFC8001] can be used to collect SRLG identifiers
associated with an LSP (LSP1). When a second LSP (LSP2) needs to associated with an LSP (LSP1). When a second LSP (LSP2) needs to
skipping to change at page 8, line 31 skipping to change at page 9, line 33
abstract SRLG identifier associated with a given path rather than abstract SRLG identifier associated with a given path rather than
a detailed SRLG list. The PAS is a single identifier that can be a detailed SRLG list. The PAS is a single identifier that can be
used to request diversity and associate diversity. The means by used to request diversity and associate diversity. The means by
which the processing node determines the path corresponding to which the processing node determines the path corresponding to
the PAS is beyond the scope of this document. the PAS is beyond the scope 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 information (or equivalent) that has been allocated by LSPs SRLG 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 identifier "123", the CN would use exists for the LSP with the PAS identifier "123", the CN would
local knowledge of the core network SRLGs associated with the use local knowledge of the core network SRLGs associated with the
"123" LSPs and use those SRLGs as constraints for path LSPs tagged with PAS attribute "123" and use those SRLGs as
computation. If a PAS identifier is included for exclusion in the constraints for path computation. If a PAS identifier is used as
connection request, the CN (UNI-N) in the core network is assumed an exclusion identifier in the connection request, the CN (UNI-N)
to be able to determine the existing core network SRLG in the core network is assumed to be able to determine the
information and calculate a path that meets the determined existing core network SRLG information and calculate a path that
diversity constraints. meets the determined diversity constraints.
When a CN satisfies a connection setup for a (SRLG) diverse When a CN satisfies a connection setup for a (SRLG) diverse
signaled path, the CN may optionally record the core network SRLG signaled path, the CN may optionally record the core network SRLG
information for that connection in terms of CN based parameters information for that connection in terms of CN based parameters
and associates that with the EN addresses in the Path message. and associates that with the EN addresses in the Path message.
Specifically, for Layer-1 Virtual Private Networks (L1VPNs), Port Specifically, for Layer 1 Virtual Private Networks (L1VPNs), Port
Information Tables (PIT) [RFC5251] can be leveraged to translate Information Tables (PIT) [RFC5251] can be leveraged to translate
between client (EN) addresses and core network addresses. between client (EN) 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 is beyond the scope of this document. For example, the network is beyond the scope of this document. For example, the
PAS and the associated SRLG information can be distributed within PAS and the associated SRLG information can be distributed within
the core network by an Interior Gateway Protocol (IGP) or by the core network by an Interior Gateway Protocol (IGP) or by
other means such as configuration. Regardless of means used to other means such as configuration. Regardless of means used to
distribute the PAS information, the information is kept inside distribute the PAS information, the information is kept inside
core network and is not shared with the overlay network (see the core network and is 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 the aforementioned requirements and use cases. address 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
skipping to change at page 10, line 26 skipping to change at page 11, line 26
| 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 as for the XRO subobjects defined in The L-flag is used in the same way as for the XRO
[RFC4874], i.e., subobjects defined in [RFC4874], i.e.,
0 indicates that the attribute specified MUST be excluded. 0 indicates that the diversity constraints MUST be
satisfied.
1 indicates that the attribute specified SHOULD be avoided. 1 indicates that the diversity constraints SHOULD be
satisfied.
XRO Type XRO Type
The value is set to TBA1 for the IPv4 diversity XRO The value is set to TBA1 for the IPv4 Diversity XRO
subobject (value to be assigned by IANA). Similarly, the subobject (value to be assigned by IANA). The value is set
value is set to TBA2 for the IPv6 diversity XRO subobject to TBA2 for the IPv6 Diversity XRO subobject (value to be
(value to be assigned by IANA). assigned by IANA).
Length Length
Per [RFC4874], the Length contains the total length of the Per [RFC4874], the Length contains the total length of the
IPv4/IPv6 subobject in bytes, including the Type and IPv4/IPv6 subobject in bytes, including the XRO Type and
Length fields. The Length is variable, depending on the Length fields. The Length is variable, depending on the
diversity identifier value. diversity identifier value.
Diversity Identifier Type (DI Type) Diversity Identifier Type (DI Type)
Diversity Identifier Type (DI Type) indicates the way the Diversity Identifier Type (DI Type) indicates the way the
reference LSP(s) or route(s) with which diversity is reference LSP(s) or route(s) with which diversity is
required is identified in the IPv4/IPv6 Diversity required is identified in the IPv4/IPv6 Diversity
subobjects. The following three DI type values are defined subobjects. The following three DI type values are defined
in this document: in this document:
skipping to change at page 11, line 25 skipping to change at page 12, line 27
DI Type value Definition DI Type value Definition
------------- -------------------------------- ------------- --------------------------------
1 Client Initiated Identifier 1 Client Initiated Identifier
2 PCE Allocated Identifier 2 PCE Allocated Identifier
3 Network Assigned Identifier 3 Network Assigned Identifier
Attribute Flags (A-Flags): Attribute Flags (A-Flags):
The Attribute Flags (A-Flags) are used to communicate The Attribute Flags (A-Flags) are used to communicate
desirable attributes of the LSP being signaled in the IPv4/ desirable attributes of the LSP being signaled in the IPv4/
IPv6 Diversity subobjects. The following flags are defined. IPv6 Diversity subobjects. Each flag acts independently.
Each flag acts independently. Any combination of flags is Any combination of flags is permitted.
permitted.
0x01 = Destination node exception 0x01 = Destination node exception
Indicates that the exclusion does not apply to the Indicates that the exclusion does not apply to the
destination node of the LSP being signaled. destination node of the LSP being signaled.
0x02 = Processing node exception 0x02 = Processing node exception
Indicates that the exclusion does not apply to the Indicates that the exclusion does not apply to the
node(s) performing ERO expansion for the LSP being node(s) performing ERO expansion for the LSP being
signaled. An ingress UNI-N node is an example of such a signaled. An ingress UNI-N node is an example of such a
node. node.
0x04 = Penultimate node exception 0x04 = Penultimate node exception
Indicates that the penultimate node of the LSP being Indicates that the penultimate node of the LSP being
signaled MAY be shared with the excluded path even when signaled MAY be shared with the excluded path even when
this violates the exclusion flags. 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 The penultimate node exception flag is typically set
when the destination node is single homed (e.g. EN1 or when the destination node is single homed (e.g. EN1 or
EN4 in Figure 1). In such a case, LSP diversity can only EN4 in Figure 1). In such a case, LSP diversity can only
be accomplished inside the core network up to the egress be accomplished inside the core network up to the egress
node and the penultimate hop must be the same for the node and the penultimate hop must be the same for the
LSPs. LSPs.
0x08 = LSP ID to be ignored 0x08 = LSP ID to be ignored
This flag is used to indicate tunnel level exclusion. This flag is used to indicate tunnel level exclusion.
Specifically, this flag is used to indicate that if Specifically, this flag is used to indicate that if
diversity identifier contains lsp-id field, the lsp-id diversity identifier contains LSP ID field, the LSP ID
is to be ignored and the exclusion applies to any LSP is to be ignored and the exclusion applies to any LSP
matching the rest of the diversity identifier. matching the rest of the diversity identifier.
Exclusion Flags (E-Flags): Exclusion Flags (E-Flags):
The Exclusion-Flags are used to communicate the desired The Exclusion Flags are used to communicate the desired
type(s) of exclusion requested in the IPv4/IPv6 diversity type(s) of exclusion requested in the IPv4/IPv6 diversity
subobjects. The following flags are defined. Any subobjects. The following flags are defined. Any
combination of these flags is permitted. Please note that combination of these flags is permitted. Please note that
the exclusion specified by these flags may be modified by the exclusion specified by these flags may be modified by
the value of the Attribute-flags. For example, node the value of the Attribute-flags. For example, node
exclusion flag is ignored for the "Penultimate node" if exclusion flag is ignored for the "Penultimate node" if
the "Penultimate node exception" flag of the Attribute- the "Penultimate node exception" flag of the Attribute-
flags is set. flags is set.
0x01 = SRLG exclusion 0x01 = SRLG exclusion
Indicates that the path of the LSP being signaled is Indicates that the path of the LSP being signaled is
requested to be SRLG-diverse from the excluded path requested to be SRLG disjoint with respect to the
specified by the IPv4/IPv6 Diversity XRO subobject. excluded path specified by the IPv4/IPv6 Diversity
XRO subobject.
0x02 = Node exclusion 0x02 = Node exclusion
Indicates that the path of the LSP being signaled is Indicates that the path of the LSP being signaled is
requested to be node-diverse from the excluded path requested to be node-diverse from the excluded path
specified by the IPv4/IPv6 Diversity XRO subobject. specified by the IPv4/IPv6 Diversity XRO subobject.
0x04 = Link exclusion 0x04 = Link exclusion
Indicates that the path of the LSP being signaled is Indicates that the path of the LSP being signaled is
requested to be link-diverse from the path specified requested to be link-diverse from the path specified
by the IPv4/IPv6 Diversity XRO subobject. by the IPv4/IPv6 Diversity XRO subobject.
0x08 = reserved 0x08 = reserved
This flag is reserved. It MUST be set to zero on This flag is reserved. It MUST be set to zero on
transmission, and MUST be ignored on receipt for both transmission, and MUST be ignored on receipt for both
IPv4/IPv6 Diversity XRO subobjects. IPv4/IPv6 Diversity XRO subobjects.
skipping to change at page 13, line 37 skipping to change at page 14, line 40
IPv4/IPv6 tunnel sender address of the reference LSP IPv4/IPv6 tunnel sender address of the reference LSP
against which diversity is desired. IPv4/IPv6 tunnel against which diversity is desired. IPv4/IPv6 tunnel
sender address is as defined in [RFC3209]. sender address is as defined in [RFC3209].
o When the diversity identifier type is set to "IPv4/IPv6 o When the diversity identifier type is set to "IPv4/IPv6
PCE Allocated Identifier", the value MUST be set to the PCE Allocated Identifier", the value MUST be set to the
IPv4/IPv6 address of the node that assigned the Path Key IPv4/IPv6 address of the node that assigned the Path Key
identifier and that can return an expansion of the Path identifier and that can return an expansion of the Path
Key or use the Path Key as exclusion in a path Key or use the Path Key as exclusion in a path
computation. The Path Key is defined in [RFC5553]. The computation. The Path Key is defined in [RFC5553]. The
PCE-ID is carried in the Identifier Source Address field PCE-ID is carried in the Diversity Identifier Source
of the subobject. Address field of the subobject.
o When the diversity identifier type is set to "IPv4/IPv6 o When the diversity identifier type is set to "IPv4/IPv6
Network Assigned Identifier", the value MUST be set to the Network Assigned Identifier", the value MUST be set to the
IPv4/IPv6 address of the node allocating the Path Affinity IPv4/IPv6 address of the node allocating the Path Affinity
Set (PAS). Set (PAS).
Diversity Identifier Value: Diversity Identifier Value:
Encoding for this field depends on the diversity identifier Encoding for this field depends on the diversity identifier
type, as defined in the following. type, as defined in the following.
skipping to change at page 16, line 13 skipping to change at page 17, line 16
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 used on the path between two inclusive abstract nodes or be used on the path between two inclusive abstract nodes or
resources in the explicit route. An EXRS contains one or more resources in the explicit route. An EXRS contains one or more
subobjects of its own, called EXRS subobjects [RFC4874]. subobjects of its own, called EXRS subobjects [RFC4874].
An EXRS MAY include 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 SHALL be used. document. The same type values TBA1 and TBA2 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 not changed by this document. The processing rules for EXRS is not changed by this document. The processing rules for
the Diversity XRO and EXRS subobjects are similar unless the the Diversity XRO and EXRS subobjects are similar unless the
differences are explicitly described. Similarly, IPv4 and IPv6 differences are explicitly described. Similarly, IPv4 and IPv6
Diversity XRO subobjects and IPv4 and IPv6 Diversity EXRS Diversity XRO subobjects and IPv4 and IPv6 Diversity EXRS
subobjects follow the same processing rules. subobjects follow the 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 [RFC4874]. in [RFC4874].
An XRO/ EXRS object MAY contain multiple Diversity subobjects of An XRO/EXRS object MAY contain multiple Diversity subobjects of
the same DI Type. E.g., in order to exclude multiple Path Keys, a the same DI Type. E.g., 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 by multiple LSPs, a node MAY include multiple Diversity taken by multiple LSPs, a node MAY include multiple Diversity
XRO/ EXRS subobjects each with a different LSP identifier. XRO/EXRS subobjects each with a different LSP identifier.
Likewise, to exclude multiple PAS identifiers, a node MAY include Likewise, to exclude multiple PAS identifiers, a node MAY include
multiple Diversity XRO/ EXRS subobjects each with a different PAS multiple Diversity XRO/EXRS subobjects each with a different PAS
identifier. However, all Diversity subobjects in an XRO/ EXRS identifier. However, all Diversity subobjects in an XRO/EXRS MUST
MUST contain the same Diversity Identifier Type. If a Path contain the same Diversity Identifier Type. If a Path message
message contains an XRO/ EXRS with multiple Diversity subobjects contains an XRO/EXRS with multiple Diversity subobjects of
of different DI Types, the processing node MUST return a PathErr different DI Types, 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
"XRO/ EXRS Too Complex" (68/ 69). "XRO/EXRS Too Complex" (68/69).
If the processing node recognize the Diversity XRO/ EXRS If the processing node recognizes the Diversity XRO/EXRS
subobject but does not support the DI type, it MUST return a subobject but does not support the DI type, it MUST return a
PathErr with the error code "Routing Problem" (24) and error sub- PathErr with the error code "Routing Problem" (24) and error sub-
code "Unsupported Diversity Identifier Type" (TBA3). code "Unsupported Diversity Identifier Type" (TBA3).
In case of DI type "Client Initiated Identifier", all nodes along In 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 constraint is satisfied. If a diversity violation is diversity constraint is satisfied. If a diversity violation is
detected, crankback signaling MAY be initiated. detected, crankback signaling MAY be initiated.
In case of DI type "PCE Allocated Identifier" and "Network In 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 XRO/ EXRS Diversity subobjects. Typically, the ingress node the XRO/EXRS Diversity subobjects as follows. In the PCE case,
of a domain sends a path computation request from ingress node to the ingress node of a domain sends a path computation request for
egress node including diversity constraints to a PCE or the a path from ingress node to egress node including diversity
ingress node is capable to calculate the path for a new LSP from constraints to a PCE. Or,in the PAS case, the ingress node is
ingress node to the egress node taking the diversity constraints capable to calculate the path for the new LSP from ingress node
into account. The calculated path is then carried in the explicit to the egress node taking the diversity constraints into account.
route object (ERO). Hence, the transit nodes in a domain and the The calculated path is then carried in the explicit route object
domain egress node SHOULD NOT process the signaled diversity (ERO). Hence, the transit nodes in a domain and the domain egress
information unless path computation is performed. node SHOULD NOT process the signaled diversity information unless
path computation is performed.
While processing EXRS object, if a loose-hop expansion results in While processing 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 node MAY include the EXRS in the newly created loose processing node MAY include the EXRS in the newly created loose
hop for further processing by downstream nodes. hop for further processing by downstream nodes.
The attribute-flags affect the processing of the Diversity XRO/ The Attribute-flags affect the processing of the Diversity
EXRS subobject as follows: XRO/EXRS subobject as follows:
o When the "processing node exception" flag is set, the o When the "Processing node exception" flag is set, the
exclusion MUST be ignored for the node processing the XRO exclusion 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 MUST be ignored for the destination node in exclusion MUST be ignored for the destination node in
processing the XRO subobject. The destination node processing the XRO subobject. The destination node
exception for the EXRS subobject applies to the explicit exception for the EXRS subobject applies to the explicit
node identified by the ERO subobject that identifies the node identified by the ERO subobject that identifies the
next abstract node. When the "destination node exception" next abstract node. When the "destination node exception"
flag is set in the EXRS subobject, exclusion MUST be flag is set in the EXRS subobject, exclusion MUST be
ignored for the 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 subobject, the exclusion MUST be ignored for the XRO subobject, the exclusion MUST be ignored for the
penultimate node on the path of the LSP being established. penultimate node 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 the node before the explicit node identified by applies to the node before the explicit node identified by
the ERO subobject that identifies the next abstract node. the ERO subobject that identifies the next abstract node.
When the "penultimate node exception" flag is set in the When the "penultimate node exception" flag is set in the
EXRS subobject, the exclusion MUST be ignored for the said EXRS subobject, the exclusion MUST be ignored for the said
node (i.e., the node before the next abstract node). node (i.e., the node before the next 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 "IPv4/IPv6 Client - If the Diversity Identifier Type is set to "Client Initiated
Initiated Identifiers", the processing node MUST ensure that Identifier", the processing node MUST ensure that the path
the path calculated/ expended for the signaled LSP is diverse calculated/expanded for the signaled LSP is diverse from the
from the route taken by the LSP identified in the Diversity route taken by the LSP identified in the Diversity Identifier
Identifier Value field. Value field.
- If the Diversity Identifier Type is set to "IPv4/IPv6 PCE - If the Diversity Identifier Type is set to "PCE Allocated
Allocated Identifiers", the processing node MUST ensure that Identifier", the processing node MUST ensure that any path
any path calculated for the signaled LSP is diverse from the calculated for the signaled LSP is diverse from the route
route identified by the Path-Key. The processing node MAY use identified by the Path Key. The processing node MAY use the PCE
the PCE identified by the IPv4/IPv6 Diversity Identifier Source identified by the Diversity Identifier Source Address in the
Address in the subobject for route computation. The processing subobject for route computation. The processing node MAY use
node MAY use the Path-Key resolution mechanisms described in the Path Key resolution mechanisms described in [RFC5553].
[RFC5553].
- If the Diversity Identifier Type is set to "IPv4/IPv6 Network - If the Diversity Identifier Type is set to "Network Assigned
Assigned Identifiers", the processing node MUST ensure that the Identifier", the processing node MUST ensure that the path
path calculated for the signaled LSP is diverse with respect to calculated for the signaled LSP is diverse with respect to the
the values associated with the PAS identifier and Diversity values associated with the PAS identifier and Diversity
Identifier source address fields. Identifier source address fields.
- Regardless of whether the path computation is performed - Regardless of whether the path computation is performed
locally or at a remote node (e.g., PCE), the processing node locally or at a remote node (e.g., PCE), the processing node
MUST ensure that any path calculated for the signaled LSP is MUST ensure that any path calculated for the signaled LSP is
diverse from the requested Exclusion Flags. diverse from the requested Exclusion Flags.
- If the excluded path referenced in the XRO subobject is - If the excluded path referenced in the XRO subobject is
unknown to the processing node, the processing node SHOULD unknown to the processing node, the processing node SHOULD
ignore the diversity XRO subobject and SHOULD proceed with the ignore the Diversity XRO subobject and SHOULD proceed with the
signaling request. After sending the Resv for the signaled LSP, signaling request. After sending the Resv for the signaled LSP,
the processing node MUST return a PathErr with the error code the processing node MUST return a PathErr with the error code
"Notify Error" (25) and error sub-code TBA4 "Route of XRO LSP "Notify Error" (25) and error sub-code TBA4 "Route of XRO LSP
identifier unknown" (value to be assigned by IANA) for the identifier unknown" (value to be assigned by IANA) for the
signaled LSP. signaled LSP.
- If the processing node fails to find a path that meets the - 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 XRO diversity subobject or EXRS diversity 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 "IPv4/IPv6 Client - If the Diversity Identifier Type is set to " Client Initiated
Initiated Identifiers", the processing node SHOULD ensure that Identifiers", the processing node SHOULD ensure that the path
the path calculated/ expended for the signaled LSP is diverse calculated/ expended for the signaled LSP is diverse from the
from the route taken by the LSP identified in the Diversity route taken by the LSP identified in the Diversity Identifier
Identifier Value field. Value field.
- If the Diversity Identifier Type is set to "IPv4/IPv6 PCE - If the Diversity Identifier Type is set to " PCE Allocated
Allocated Identifiers", the processing node SHOULD ensure that Identifiers", the processing node SHOULD ensure that the path
the path calculated for the signaled LSP is diverse from the calculated for the signaled LSP is diverse from the route
route identified by the Path-Key. identified by the Path Key.
- If the Diversity Identifier Type is set to "IPv4/IPv6 Network - If the Diversity Identifier Type is set to "IPv4/IPv6 Network
Assigned Identifiers", the processing node SHOULD ensure that Assigned Identifiers", the processing node SHOULD ensure that
the path calculated for the signaled LSP is diverse with the path calculated for the signaled LSP is diverse with
respect to the values associated with the PAS identifier and respect to the values associated with the PAS identifier and
Diversity Identifier source address fields. Diversity Identifier source address fields.
- If the processing node fails to find a path that meets the - 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.
skipping to change at page 20, line 28 skipping to change at page 21, line 34
PathErr message for the diverse LSP with the error code "Notify PathErr message for the diverse LSP with the error code "Notify
Error" (25) and a new error sub- code TBA6 "Compliant path Error" (25) and a new error sub- code TBA6 "Compliant path
exists" (value: to be assigned by IANA). The PSR flag MUST NOT exists" (value: to be assigned by IANA). The PSR flag MUST NOT
be set. A source node receiving a PathErr message with this be set. A source node receiving a PathErr message with this
error code and sub-code combination MAY move the diverse LSP to error code and sub-code combination MAY move the diverse LSP to
a new path that meets the original constraints. 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
above those identified in [RFC5920], [RFC2205], [RFC3209], in addition to those identified in [RFC5920], [RFC2205],
[RFC3473] and [RFC4874]. [RFC3209], [RFC3473], [RFC2747], [RFC4874], [RFC5520], and
[RFC5553].
The diversity mechanism defined in this document, relies on the The diversity mechanisms defined in this document, rely on the
new diversity subobject that is carried in the XRO or EXRS, new diversity subobject that is carried in the XRO or EXRS,
respectively. In section 7 of [RFC4874], it is stated that the respectively. In section 7 of [RFC4874], it is noted some
XRO could be considered for removal from the Path message due to administrative boundaries may remove the XRO due to security
security concerns for example at administrative boundaries. In concerns on explicit route information exchange. However, when
this case, the diversity subobject would also be removed. Hence, the diversity subobjects specified in this document are used,
the diversity subobject MUST be kept while other subobjects may removing at the administrative boundary an XRO containing these
be removed. diversity subobjects would result in the request for diversity
being dropped at the boundary, and path computation would be
unlikely to produce the requested diverse path. As such,
diversity subobjects MUST be retained in an XRO crossing an
administrative boundary, even if other subobjects are removed.
This retention would be based on operator policy. The use of
diversity subobjects are based on mutual agreement. This avoids
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 is requested to administer the assignment of new values
defined in this document and summarized in this section. defined in this document and summarized in this section.
4.1. New XRO subobject types 4.1. New XRO subobject types
IANA registry: RSVP PARAMETERS IANA registry: RSVP PARAMETERS
Subsection: Class Names, Class Numbers, and Class Types Subsection: Class Names, Class Numbers, and Class Types
skipping to change at page 21, line 4 skipping to change at page 22, line 19
4. IANA Considerations 4. IANA Considerations
IANA is requested to administer the assignment of new values IANA is requested to administer the assignment of new values
defined in this document and summarized in this section. defined in this document and summarized in this section.
4.1. New XRO subobject types 4.1. New XRO subobject types
IANA registry: RSVP PARAMETERS IANA registry: RSVP PARAMETERS
Subsection: Class Names, Class Numbers, and Class Types Subsection: Class Names, Class Numbers, and Class Types
This document defines two new subobjects for the EXCLUDE_ROUTE This document defines two new subobjects for the EXCLUDE_ROUTE
object [RFC4874], C-Type 1. (see: object [RFC4874], C-Type 1. (see:
http://www.iana.org/assignments/rsvp-parameters/rsvp- http://www.iana.org/assignments/rsvp-parameters/rsvp-
parameters.xhtml#rsvp-parameters-94) parameters.xhtml#rsvp-parameters-94)
Subobject Description Subobject Type +--------------------------+----------------+
------------------------ -------------- | Subobject Description | Subobject Type |
IPv4 Diversity subobject TBA1 +--------------------------+----------------+
IPv6 Diversity subobject TBA2 | IPv4 Diversity subobject | TBA1 |
| IPv6 Diversity subobject | TBA2 |
+--------------------------+----------------+
4.2. New EXRS subobject types 4.2. New EXRS subobject types
The diversity XRO subobjects are also defined as new EXRS The Diversity XRO subobjects are also defined as new EXRS
subobjects. (EXPLICIT_ROUTE see: subobjects. (EXPLICIT_ROUTE see:
http://www.iana.org/assignments/rsvp-parameters/rsvp- http://www.iana.org/assignments/rsvp-parameters/rsvp-
parameters.xhtml#rsvp-parameters-24). The same numeric subobject parameters.xhtml#rsvp-parameters-24). The same numeric subobject
type values TBA1 and TBA2 are being requested for the two new type values TBA1 and TBA2 are being requested for the two new
EXRS subobjects. EXRS subobjects.
4.3. New RSVP error sub-codes 4.3. New RSVP error sub-codes
IANA registry: RSVP PARAMETERS IANA registry: RSVP PARAMETERS
Subsection: Error Codes and Globally Defined Error Value Sub- Subsection: Error Codes and Globally Defined Error Value Sub-
skipping to change at page 22, line 32 skipping to change at page 24, line 5
The authors also would like to thank Luyuan Fang and Walid Wakim The authors also would like to thank Luyuan Fang and Walid Wakim
for their review comments. for their review comments.
6. References 6. References
6.1. Normative References 6.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2205] Braden, R. (Ed.), Zhang, L., Berson, S., Herzog, S. and
S. Jamin, "Resource ReserVation Protocol -- Version 1
Functional Specification", RFC 2205, September 1997.
[RFC2747] Baker, F., Lindell, B. and M. Talwar, "RSVP
Cryptographic Authentication", RFC 2747, January 2000.
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan,
V., and G. Swallow, "RSVP-TE: Extensions to RSVP for V., and G. Swallow, "RSVP-TE: Extensions to RSVP for
LSP Tunnels", RFC 3209, December 2001. LSP Tunnels", RFC 3209, December 2001.
[RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching
(GMPLS) Signaling Resource ReserVation Protocol-Traffic (GMPLS) Signaling Resource ReserVation Protocol-Traffic
Engineering (RSVP-TE) Extensions", RFC 3473, January Engineering (RSVP-TE) Extensions", RFC 3473, January
2003. 2003.
[RFC4202] Kompella, Ed., K, Rekhter, Y, Ed., "Routing Extensions
in Support of Generalized Multi-Protocol Label
Switching (GMPLS)", RFC 4202, October 2005.
[RFC4874] Lee, CY., Farrel, A., and S. De Cnodder, "Exclude [RFC4874] Lee, CY., Farrel, A., and S. De Cnodder, "Exclude
Routes - Extension to Resource ReserVation Protocol- Routes - Extension to Resource ReserVation Protocol-
Traffic Engineering (RSVP-TE)", RFC 4874, April 2007. Traffic Engineering (RSVP-TE)", RFC 4874, April 2007.
[RFC4920] Farrel, A., Ed., Satyanarayana, A., Iwata, A., Fujita, [RFC4920] Farrel, A., Ed., Satyanarayana, A., Iwata, A., Fujita,
N., and G. Ash, "Crankback Signaling Extensions for N., and G. Ash, "Crankback Signaling Extensions for
MPLS and GMPLS RSVP-TE", RFC 4920, July 2007. MPLS and GMPLS RSVP-TE", RFC 4920, July 2007.
[RFC5553] Farrel, A., Ed., Bradford, R., and JP. Vasseur, [RFC5553] Farrel, A., Ed., Bradford, R., and JP. Vasseur,
"Resource Reservation Protocol (RSVP) Extensions for "Resource Reservation Protocol (RSVP) Extensions for
 End of changes. 75 change blocks. 
219 lines changed or deleted 277 lines changed or added

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