draft-ietf-teas-lsp-diversity-01.txt   draft-ietf-teas-lsp-diversity-02.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
Expires: September 10, 2015 F. Zhang, Ed. Expires: January 7, 2016 F. Zhang, Ed.
Huawei Huawei
D. Beller, Ed. D. Beller, Ed.
Alcatel-Lucent Alcatel-Lucent
March 9, 2015 July 6, 2015
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-01.txt draft-ietf-teas-lsp-diversity-02.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/.
skipping to change at page 2, line 17 skipping to change at page 2, line 17
within the network. within the network.
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
1. Introduction ..................................................2 1. Introduction..................................................2
1.1. Client-Initiated Identifier ...........................5 1.1. Client-Initiated Identifier...........................5
1.2. PCE-allocated Identifier ..............................6 1.2. PCE-allocated Identifier..............................6
1.3. Network-Assigned Identifier ...........................8 1.3. Network-Assigned Identifier...........................7
2. RSVP-TE signaling extensions .................................10 2. RSVP-TE signaling extensions..................................9
2.1. Diversity XRO Subobject ..............................10 2.1. Diversity XRO Subobject...............................9
2.1.1. IPv4 Diversity XRO Subobject ...................10 2.1.1. IPv4 Diversity XRO Subobject............................. 9
2.1.2. IPv6 Diversity XRO Subobject ...................15 2.1.2. IPv6 Diversity XRO Subobject............................ 13
2.2. Processing rules for the Diversity XRO subobject .....18 2.2. Processing rules for the Diversity XRO subobject.....17
2.3. Diversity EXRS Subobject .............................22 2.3. Diversity EXRS Subobject.............................20
3. Security Considerations ......................................23 3. Security Considerations......................................22
4. IANA Considerations ..........................................24 4. IANA Considerations..........................................22
4.1. New XRO subobject types ..............................24 4.1. New XRO subobject types..............................22
4.2. New EXRS subobject types .............................24 4.2. New EXRS subobject types.............................22
4.3. New RSVP error sub-codes .............................24 4.3. New RSVP error sub-codes.............................22
5. Acknowledgements .............................................25 5. Acknowledgements.............................................23
6. References ...................................................25 6. References...................................................23
6.1. Normative References .................................25 6.1. Normative References.................................23
6.2. Informative References ...............................26 6.2. Informative References...............................24
1. Introduction 1. Introduction
Path diversity for multiple connections is a well-known Service Path diversity for multiple connections is a well-known Service
Provider requirement. Diversity constraints ensure that Label- Provider requirement. Diversity constraints ensure that Label-
Switched Paths (LSPs) can be established without sharing 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.
When a source node has full topological knowledge and is permitted The source node can compute diverse paths for LSPs when it has
to signal an Explicit Route Object, diverse paths for LSPs can be full knowledge of the network topology and is permitted to signal
computed by this source node. However, there are scenarios when an Explicit Route Object. However, there are scenarios where
path computations are performed by different nodes, and there is different nodes perform path computations, and therefore there is
therefore a need for relevant diversity constraints to be a need for relevant diversity constraints to be signaled to those
communicated to those nodes. These include (but are not limited nodes. These include (but are not limited to):
to):
. LSPs with loose hops in the Explicit Route Object (ERO), e.g. . LSPs with loose hops in the Explicit Route Object (ERO), e.g.
inter-domain LSPs; inter-domain LSPs.
. Generalized Multi-Protocol Label Switching (GMPLS) User- . Generalized Multi-Protocol Label Switching (GMPLS) User-
Network Interface (UNI), where path computation may be Network Interface (UNI), where the core node may perform path
performed by the core node [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
Shared Risk Link Groups (SRLGs) of traversed links. Employing Shared Risk Link Groups (SRLGs) of traversed links. Employing
these mechanisms requires that the source node that initiates these mechanisms requires that the source node that initiates
signaling knows the relevant properties of the path(s) from which signaling knows the relevant properties of the path(s) from which
diversity is desired. However, there are circumstances under which diversity is desired. However, there are circumstances under which
skipping to change at page 3, line 34 skipping to change at page 3, line 34
to): to):
. Exclusion of a path which does not originate, terminate or . Exclusion of a path which 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 required are unknown to the source node. is required are unknown to the source node.
. 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
existence of the reference path is known to the source node 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 present such Inter-domain and GMPLS overlay networks can impose such
restrictions. restrictions.
This is exemplified in the Figure 1, where overlay reference This is exemplified 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 25 skipping to change at page 4, line 25
+---------+ | | +--+--+ | +--+--+ | | +---------+ +---------+ | | +--+--+ | +--+--+ | | +---------+
| +----+ | | | | | +-------+ +-----+ | +----+ | | +----+ | | | | | +-------+ +-----+ | +----+ |
| | +-+--+ | | 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 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.
skipping to change at page 5, line 22 skipping to change at page 5, line 22
LSP from EN2 to EN3 traversing CN1 needs to be diverse from an LSP from EN2 to EN3 traversing CN1 needs to be diverse from an
LSP from EN2 to EN3 going via CN4. Again in this case, exclusions LSP from EN2 to EN3 going via CN4. Again in this case, exclusions
based on [RFC4874] cannot be used. 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 the notion of excluding the path taken by particular
LSP(s). The reference LSP(s) or route(s) from which diversity is LSP(s). The reference LSP(s) or route(s) from which diversity is
required is/are identified by an "identifier". The type of required is/are identified by an "identifier". The type of
identifier to use is highly dependent on the networking identifier to use is highly dependent on the networking
deployment scenario; it could be client-initiated, allocated by deployment scenario; it could be client-initiated, allocated by
the (core) network or managed by a PCE. This document defines the (core) network or managed by a PCE . This document defines
three different types of identifiers corresponding to these three three different types of identifiers corresponding to these three
cases: a client initiated identifier, a PCE allocated Identifier cases: a client initiated identifier, a PCE allocated Identifier
and CN ingress node (UNI-N) allocated Identifier. and CN ingress node (UNI-N) allocated Identifier.
1.1. Client-Initiated Identifier 1.1. Client-Initiated Identifier
There are scenarios in which the ENs have the following There are scenarios in which the ENs have the following
requirements for the diversity identifier: requirements for the diversity identifier:
- The identifier is controlled by the client side and is - The identifier is controlled by the client side and is
specified as part of the service request. specified as part of the service request.
- Both client and server understand the identifier. - Both client and server understand the identifier.
- It is necessary to be able to reference the identifier even if - It is necessary to be able to reference the identifier even if
the LSP referenced by it is not yet signaled. the LSP referenced by it is not yet signaled.
- The identifier is to be stable for a long period of time. - The identifier is to be stable for a long period of time.
- The identifier is to be stable even when the referenced tunnel - The identifier is to be stable even when the referenced LSP is
is rerouted. rerouted.
- The identifier is to be human-readable. - The identifier is to be human-readable.
These requirements are met by using the Resource ReserVation These requirements are met by using the LSP identifier. The LSP
Protocol (RSVP) tunnel/ LSP Forwarding Equivalence Class (FEC) as identifier uniquely identifies an LSP in the network and
the identifier. LSP FEC uniquely identifies an LSP in the network comprises of the following fields: IPv4/IPv6 tunnel sender
and comprises of the following fields: IPv4 tunnel sender address, IPv4/IPv6 tunnel end point address, Tunnel ID, LSP ID,
address, IPv4 tunnel end point address, Tunnel ID, LSP ID, and and Extended Tunnel ID. These fields are defined in [RFC3209],
Extended Tunnel ID. These fields are defined in [RFC3209], sections 4.6.1.1 and 4.6.2.1.
sections 4.6.1.1 and 4.6.2.1. Similarly, tunnel FEC uniquely
identifies a tunnel in the network and comprises of the following
fields: IPv4 tunnel sender address, IPv4 tunnel end point
address, Tunnel ID, and Extended Tunnel ID. These 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
using Figure 1. Suppose a tunnel from EN2 to EN4 needs to be Figure 1. Suppose a LSP from EN2 to EN4 needs to be diverse with
diverse with respect to a tunnel from EN1 to EN3. The tunnel FEC respect to a LSP from EN1 to EN3. The LSP identifier of the EN1-
of the EN1-EN3 tunnel is FEC1, where FEC1 is defined by the tuple EN3 LSP is LSP-IDENTIFIER1, where LSP-IDENTIFIER1 is defined by
(tunnel-id = T1, source address = EN1.ROUTE Identifier (RID), the tuple (tunnel-id = T1, LSP ID = L1, source address =
destination address = EN3.RID, extended tunnel-id = EN1.RID). EN1.ROUTE Identifier (RID), destination address = EN3.RID,
Similarly, tunnel FEC of the EN2-EN3 tunnel is FEC2, where FEC2 extended tunnel-id = EN1.RID). Similarly, LSP identifier of the
is defined by the tuple (tunnel-id = T2, source address = EN2-EN3 LSP is LSP-IDENTIFIER2, where LSP-IDENTIFIER12 is defined
by the tuple (tunnel-id = T2, LSP IS = L1, source address =
EN2.RID, destination address = EN4.RID, extended tunnel-id = EN2.RID, destination address = EN4.RID, extended tunnel-id =
EN2.RID). The EN1-EN3 tunnel is signaled with an exclusion EN2.RID). The EN1-EN3 LSP is signaled with an exclusion
requirement from FEC2, and the EN2-EN3 tunnel is signaled with an requirement from LSP-IDENTIFIER2, and the EN2-EN3 LSP is signaled
exclusion requirement from FEC1. In order to maintain diversity with an exclusion requirement from LSP-IDENTIFIER1. In order to
between these two connections within the core network, it is maintain diversity between these two connections within the core
assumed that the core network implements Crankback Signaling network, it is assumed that the core network implements Crankback
[RFC4920]. Note that crankback signaling is known to lead to Signaling [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 scenarios a PCE is
deployed in each border node or a PCE is part of a Network deployed in each border node or a PCE is part of a Network
Management System (NMS). In all these cases, the Path Key as Management System (NMS). In all these cases, the Path Key as
defined in [RFC5520] can be used in RSVP signaling as the defined in [RFC5520] can be used in RSVP signaling as the
skipping to change at page 8, line 20 skipping to change at page 7, line 20
| / --- --- | | --- --- --- \ | | / --- --- | | --- --- --- \ |
| ---/ | | / / \--- | | ---/ | | / / \--- |
| |Src| | | / / |Dst| | | |Src| | | / / |Dst| |
| ---\ | | / / /--- | | ---\ | | / / /--- |
| \ --- --- | | --- / --- / --- / | | \ --- --- | | --- / --- / --- / |
| | C |--| D |--+--+--| X |---| Y |--| Z | | | | C |--| D |--+--+--| X |---| Y |--| Z | |
| --- --- | | --- --- --- | | --- --- | | --- --- --- |
| | | | | | | |
--------------------- ----------------------------- --------------------- -----------------------------
Figure 1: 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 improve the situation, node U performs the PCE
function and replaces the path segment {U, V, W} in the RRO with function and replaces the path segment {U, V, W} in the RRO with
a Path Key Subobject. The Path Key Subobject assigns an a Path Key Subobject. The Path Key Subobject assigns an
"identifier" to the key. The PCE ID in the message indicates that "identifier" to the key. The PCE ID in the message indicates that
it was node U that made the replacement. it was node U that made the replacement.
With this additional information, the source is able to signal With this additional information, the source is able to signal
the subsequent LSPs with the ERO set to {C, D, exclude Path the subsequent LSPs with the ERO set to {C, D, exclude Path
Key(EXRS), loose Dst}. When the signaling message reaches node X, Key(EXRS), loose Dst}. When the signaling message reaches node X,
skipping to change at page 9, line 49 skipping to change at page 8, line 49
diversity constraints. 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 PAS and the associated SRLG information can be distributed The means to distribute the PAS information within the core
within the core network by an Interior Gateway Protocol (IGP) or network is beyond the scope of this document. The PAS and the
by other means such as configuration. They can then be utilized associated SRLG information can be distributed within the core
by other CNs when other ENs are requesting paths to be setup that network by an Interior Gateway Protocol (IGP) or by other means
would require path/connection diversity. In the VPN case, this such as configuration. Regardless of means used to distribute the
information is distributed on a VPN basis and contains a PAS PAS information, the information is kept inside core network and
identifier, CN addresses and SRLG information. In this way, on a is not shared with the overlay network (see Figure 1).
VPN basis, the core network can have additional opaque records
for the PAS values for various Paths along with the SRLG list
associated with the Path. This information is internal to the
core network and is known only to the core network.
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 by this document as New Diversity XRO subobjects are defined by this document as
follows. follows.
2.1.1. IPv4 Diversity XRO Subobject 2.1.1. IPv4 Diversity XRO Subobject
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 |
// ... // // ... //
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
L: L:
The L-flag is used as for the XRO subobjects defined in The L-flag is used as for the XRO subobjects defined in
[RFC4874], i.e., [RFC4874], i.e.,
skipping to change at page 11, line 27 skipping to change at page 10, line 24
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. The following three DI type values required is identified. The following three DI type values
are defined in this document: are defined in this document:
DI Type value Definition DI Type value Definition
------------- -------------------------------- ------------- --------------------------------
1 IPv4 Client Initiated Identifier 1 IPv4 Client Initiated Identifier
2 IPv4 PCE Allocated Identifier 2 IPv4 PCE Allocated Identifier
3 IPv4 Network Assigned Identifier 3 3 IPv4 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. The desirable attributes of the LSP being signaled. The
following flags are defined. Each flag acts independently. following flags are defined. Each flag acts independently.
Any combination of flags is permitted. Any combination of flags is permitted.
0x01 = Destination node exception 0x01 = Destination node exception
skipping to change at page 12, line 6 skipping to change at page 11, line 4
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
border node(s) performing ERO expansion for the LSP border node(s) performing ERO expansion for the LSP
being signaled. An ingress UNI-N node is an example of being signaled. An ingress UNI-N node is an example of
such a node. such a 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.
0x08 = LSP ID to be ignored
This flag is only applicable when the diversity is
specified using the client-initiated identifier, the
flag indicates tunnel level exclusion, as detailed in
section 2.2.
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. The following flags are defined. Any type(s) of exclusion. The following flags are defined. Any
combination of these flags is permitted. combination of these flags is permitted.
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-diverse from the excluded path
skipping to change at page 13, line 39 skipping to change at page 12, line 31
Network Assigned Identifier", the value indicates the IPv4 Network Assigned Identifier", the value indicates the IPv4
address of the node publishing the Path Affinity Set address of the node publishing the Path Affinity Set
(PAS). (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.
When the diversity identifier type is set to "IPv4 Client When the diversity identifier type is set to "IPv4 Client
Initiated Identifier", the diversity identifier value is Initiated Identifier", the diversity identifier value MUST
encoded as follows: 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 end point 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 end point address, Tunnel ID, Extended
Tunnel ID and LSP ID are as defined in [RFC3209]. Tunnel ID and LSP ID are as defined in [RFC3209].
When the diversity identifier type is set to "IPv4 PCE When the diversity identifier type is set to "IPv4 PCE
Allocated Identifier", the diversity identifier value is Allocated Identifier", the diversity identifier value MUST
encoded as follows: 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 "IPv4 Network When the diversity identifier type is set to "IPv4 Network
Assigned Identifier", the diversity identifier value is Assigned Identifier", the diversity identifier value MUST
encoded as follows: 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Path Affinity Set (PAS) identifier | | Path Affinity Set (PAS) identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Path affinity Set (PAS) identifier is a single number The Path affinity Set (PAS) identifier is a single number
that represents a summarized SRLG for the reference path that represents a summarized SRLG for the reference path
against which diversity is desired. The node identified by against which diversity is desired. The PAS identifier is
the "IPv4 Diversity Identifier source address" field of defined in this document.
the diversity XRO subobject assigns the PAS value.
2.1.2. IPv6 Diversity XRO Subobject 2.1.2. IPv6 Diversity XRO Subobject
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 16, line 15 skipping to change at page 15, line 4
Exclusion Flags (E-Flags): Exclusion Flags (E-Flags):
As defined in Section 2.1.1 for the IPv4 counterpart. As defined in Section 2.1.1 for the IPv4 counterpart.
Resvd Resvd
This field is reserved. It SHOULD be set to zero on This field is reserved. It SHOULD be set to zero on
transmission, and MUST be ignored on receipt. transmission, and MUST be ignored on receipt.
Diversity Identifier Type (DI Type) Diversity Identifier Type (DI Type)
This field is defined in the same fashion as its IPv4 This field is defined in the same fashion as its IPv4
counter part described in Section 2.1.1. counter part described in Section 2.1.1.
The three DI Types associated with IPv6 addresses are The three DI Types associated with IPv6 addresses are
defined, defined as follows:
as follows:
DI Type value Definition DI Type value Definition
------------- -------------------------------- ------------- --------------------------------
4 IPv6 Client Initiated Identifier 4 IPv6 Client Initiated Identifier
5 IPv6 PCE Allocated Identifier 5 IPv6 PCE Allocated Identifier
6 IPv6 Network Assigned Identifier 6 IPv6 Network Assigned Identifier
These idenifier are assigned and used as defined in These idenifier are assigned and used as defined in
Section 2.1.1. Section 2.1.1.
skipping to change at page 17, line 6 skipping to change at page 15, line 31
the diversity identifier. How identity of node for various the diversity identifier. How identity of node for various
diversity types is determined is as described in Section diversity types is determined is as described in Section
2.1.1 for the IPv4 counterpart. 2.1.1 for the IPv4 counterpart.
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.
When the diversity identifier type is set to "IPv6 Client When the diversity identifier type is set to "IPv6 Client
Initiated Identifier", the diversity identifier value is Initiated Identifier", the diversity identifier value MUST
encoded as follows: 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 end point address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 tunnel end point address (cont.) | | IPv6 tunnel end point address (cont.) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 tunnel end point address (cont.) | | IPv6 tunnel end point address (cont.) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 17, line 37 skipping to change at page 16, line 21
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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 end point address, Tunnel ID, IPv6 Extended
Tunnel ID and LSP ID are as defined in [RFC3209]. Tunnel ID and LSP ID are as defined in [RFC3209].
When the diversity identifier type is set to "IPv6 PCE When the diversity identifier type is set to "IPv6 PCE
Allocated Identifier", the diversity identifier value is Allocated Identifier", the diversity identifier value MUST
encoded as follows: 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 "IPv6 Network When the diversity identifier type is set to "IPv6 Network
Assigned Identifier", the diversity identifier value is Assigned Identifier", the diversity identifier value MUST
encoded as follows: 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Path Affinity Set (PAS) identifier | | Path Affinity Set (PAS) identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Path affinity Set (PAS) identifier is as defined in The Path affinity Set (PAS) identifier is as defined in
Section 2.1.1. Section 2.1.1.
2.2. Processing rules for the Diversity XRO subobject 2.2. Processing rules for the Diversity XRO subobject
The procedure defined in [RFC4874] for processing XRO and EXRS is The procedure defined in [RFC4874] for processing XRO and EXRS is
not changed by this document. If the processing node cannot not changed by this document. If the processing node cannot
recognize the IPv4/ IPv6 Diversity XRO subobject, the node is recognize the IPv4/IPv6 Diversity XRO subobject, the node is
expected to follow the procedure defined in [RFC4874]. expected to follow the procedure defined in [RFC4874].
An XRO object MAY contain multiple Diversity subobjects. E.g., in An XRO object MAY contain multiple Diversity subobjects. E.g., in
order to exclude multiple Path Keys, an EN may include multiple order to exclude multiple Path Keys, an EN may include multiple
Diversity XRO subobjects each with a different Path Key. Diversity XRO subobjects each with a different Path Key.
Similarly, in order to exclude multiple PAS identifiers, an EN Similarly, in order to exclude the routes taken by multiple LSPs,
may include multiple Diversity XRO subobjects each with a an EN may include multiple Diversity XRO subobjects each with a
different PAS identifier. However, all Diversity subobjects in an different LSP identifier. Likewise, to exclude multiple PAS
XRO SHOULD contain the same Diversity Identifier Type. If a Path identifiers, an EN may include multiple Diversity XRO subobjects
message contains an XRO with Diversity subobjects with multiple each with a different PAS identifier. However, all Diversity
Diversity Identifier Types, the processing node SHOULD return a subobjects in an XRO MUST contain the same Diversity Identifier
PathErr with the error code "Routing Problem" (24) and error sub- Type. If a Path message contains an XRO with multiple Diversity
code "XRO Too Complex" (68). subobjects of different Diversity Identifier Types, the
processing node MUST return a PathErr with the error code
"Routing Problem" (24) and error sub-code "XRO Too Complex" (68).
It shall be noted that only those nodes in the domain that Please note that only those nodes in the domain that perform path
perform path computation (typically the domain ingress node), computation (typically the domain ingress node), shall process
shall process the diversity information signaled in the Diversity the diversity information signaled in the Diversity subobjects.
subobjects. The transit nodes in a domain and the domain egress The transit nodes in a domain and the domain egress node
node typically do not need to process it. typically do not need to process it.
The attribute-flags affect the processing of the Diversity XRO The attribute-flags affect the processing of the Diversity XRO
subobject as follows: subobject as follows:
o When the "destination node exception" flag is set, the o When the "destination node exception" flag is set, the
exclusion SHOULD be ignored for the destination node. exclusion MUST be ignored for the destination node.
o When the "processing node exception" flag is set, the o When the "processing node exception" flag is set, the
exclusion SHOULD be ignored for the processing node. The exclusion MUST be ignored for the processing node. The
processing node is the node performing path calculation. processing node is the node performing path calculation.
o When the "penultimate node exception" flag is set, the o When the "penultimate node exception" flag is set, the
exclusion SHOULD be ignored for the penultimate node on exclusion MUST be ignored for the penultimate node on the
the path of the LSP being established. path of the LSP being established.
o The "LSP ID to be ignored" flag is only defined for the
"IPv4/ IPv6 Client Initiated Identifier" diversity types.
When the Diversity Identifier Type is set to any other
value, this flag SHOULD NOT be set on transmission and
MUST be ignored in processing. When this flag is not set,
the lsp-id is not ignored and the exclusion applies only
to the specified LSP (i.e., LSP level exclusion).
If the L-flag of the diversity XRO subobject is not set, the If the L-flag of the diversity XRO subobject is not set, the
processing node proceeds as follows. processing node proceeds as follows.
- "IPv4/ IPv6 Client Initiated Identifiers" Diversity Type: the - If the Diversity Identifier Type is set to "IPv4/IPv6 Client
processing node MUST ensure that any path calculated for the Initiated Identifiers", the processing node MUST ensure that
signaled LSP is diverse from the RSVP TE FEC identified by the the path calculated/ expended for the signaled LSP is diverse
client in the XRO subobject. from the route taken by the LSP identified in the Diversity
Identifier Value field.
- "IPv4/ IPv6 PCE Allocated Identifiers" Diversity Type: the - If the Diversity Identifier Type is set to "IPv4/IPv6 PCE
processing node MUST ensure that any path calculated for the Allocated Identifiers", the processing node MUST ensure that
signaled LSP is diverse from the route identified by the Path- any path calculated for the signaled LSP is diverse from the
Key. The processing node MAY use the PCE identified by the route identified by the Path-Key. The processing node MAY use
IPv4/ IPv6 Diversity Identifier source address in the subobject the PCE identified by the IPv4/IPv6 Diversity Identifier Source
for route computation. The processing node MAY use the Path-Key Address in the subobject for route computation. The processing
resolution mechanisms described in [RFC5553]. node MAY use the Path-Key resolution mechanisms described in
[RFC5553].
- "IPv4/ IPv6 Network Assigned Identifiers" Diversity Type: the - If the Diversity Identifier Type is set to "IPv4/IPv6 Network
processing node MUST ensure that the path calculated for the Assigned Identifiers", the processing node MUST ensure that the
signaled LSP respects the requested PAS exclusion. . path calculated for the signaled LSP respects the requested PAS
exclusion.
- 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 MUST ensure that any path calculated for the signaled LSP
respects the requested exclusion flags with respect to the respects the requested Exclusion Flags.
excluded path referenced by the subobject, including local
resources.
- 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 SHOULD 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 "Route reference in "Notify Error" (25) and error sub-code "Route reference in
diversity XRO identifier unknown" (value to be assigned by diversity XRO identifier unknown" (value to be assigned by
IANA) for the signaled LSP. IANA) for the 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 diversity XRO subobject is set, the If the L-flag of the diversity XRO subobject is set, the
processing node proceeds as follows: processing node proceeds as follows:
- "IPv4/ IPv6 Client Initiated Identifiers" Diversity Type: the - If the Diversity Identifier Type is set to "IPv4/IPv6 Client
processing node SHOULD ensure that the path calculated for the Initiated Identifiers", the processing node SHOULD ensure that
signaled LSP is diverse from the RSVP TE FEC identified by the the path calculated/ expended for the signaled LSP is diverse
client in the XRO subobject. from the route taken by the LSP identified in the Diversity
Identifier Value field.
- "IPv4/ IPv6 PCE Allocated Identifiers" Diversity Type: the
processing node SHOULD ensure that the path calculated for the
signaled LSP is diverse from the route identified by the Path-
Key.
"IPv4/ IPv6 Network Assigned Identifiers" Diversity Type: the - If the Diversity Identifier Type is set to "IPv4/IPv6 PCE
Allocated Identifiers", the processing node SHOULD ensure that
the path calculated for the signaled LSP is diverse from the
route identified by the Path-Key.If the Diversity Identifier
Type is set to "IPv4/IPv6 Network Assigned Identifiers", the
processing node SHOULD ensure that the path calculated for the processing node SHOULD ensure that the path calculated for the
signaled LSP respects the requested PAS exclusion. The means by signaled LSP respects the requested PAS exclusion.
which the processing node determines the path corresponding to
the PAS is beyond the scope of this document.
- The processing node SHOULD respect the requested exclusion - The processing node SHOULD respect the requested exclusion
flags with respect to the excluded path to the extent possible. flags to the extent possible.
- 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.
After sending the Resv for the signaled LSP, it SHOULD return a After sending the Resv for the signaled LSP, it MUST return a
PathErr message with error code "Notify Error" (25) and error PathErr message with error code "Notify Error" (25) and error
sub-code "Failed to respect Exclude Route" (value: to be sub-code "Failed to respect Exclude Route" (value: to be
assigned by IANA) to the source node. assigned by IANA) to the source node.
If, subsequent to the initial signaling of a diverse LSP: If, subsequent to the initial signaling of a diverse LSP, an
excluded path referenced in the XRO subobject becomes known to
- An excluded path referenced in the XRO subobject becomes the processing node, or a change in the excluded path becomes
known to the processing node, or a change in the excluded path known to the processing node, the processing node MUST re-
becomes known to the processing node, the processing node evaluate the exclusion and diversity constraints requested by the
SHOULD re-evaluate the exclusion and diversity constraints diverse LSP to determine whether they are still satisfied.
requested by the diverse LSP to determine whether they are
still satisfied.
- If the requested exclusion constraints for the diverse LSP are
no longer satisfied and an alternative path for the diverse LSP
that can satisfy those constraints exists, then:
o If the L-flag was not set in the original exclusion, the
processing node MUST send a PathErr message for the
diverse LSP with the error code "Routing Problem" (24) and
error sub-code "Route blocked by Exclude Route" (67). The
PSR flag SHOULD NOT be set. A source node receiving a
PathErr message with this error code and sub-code
combination SHOULD take appropriate actions to migrate the
compliant path.
o If the L-flag was set in the original exclusion, the If, subsequent to the initial signaling of a diverse LSP, the
processing node SHOULD send a PathErr message for the requested exclusion constraints for the diverse LSP are no longer
diverse LSP with the error code "Notify Error" (25) and a satisfied and an alternative path for the diverse LSP that can
new error sub-code "compliant path exists" (value: to be satisfy those constraints exists, then:
assigned by IANA). The PSR flag SHOULD NOT be set. A
source node receiving a PathErr message with this error
code and sub-code combination MAY signal a new LSP to
migrate the compliant path.
- If the requested exclusion constraints for the diverse LSP are - If the L-flag was not set in the original exclusion, the
no longer satisfied and no alternative path for the diverse LSP processing node MUST send a PathErr message for the diverse LSP
that can satisfy those constraints exists, then: with the error code "Routing Problem" (24) and error sub-code
"Route blocked by Exclude Route" (67). The PSR flag MUST NOT be
set. A source node receiving a PathErr message with this error
code and sub-code combination SHOULD take appropriate actions
to migrate to a compliant path.
o If the L-flag was not set in the original exclusion, the - If the L-flag was set in the original exclusion, the
processing node MUST send a PathErr message for the processing node MUST send a PathErr message for the diverse LSP
diverse LSP with the error code "Routing Problem" (24) and with the error code "Notify Error" (25) and a new error sub-
error sub-code "Route blocked by Exclude Route" (67). The code "compliant path exists" (value: to be assigned by IANA).
PSR flag SHOULD be set. The PSR flag MUST NOT be set. A source node receiving a PathErr
message with this error code and sub-code combination MAY
signal a new LSP to migrate the compliant path.
o If the L-flag was set in the original exclusion, the If, subsequent to the initial signaling of a diverse LSP, the
processing node SHOULD send a PathErr message for the requested exclusion constraints for the diverse LSP are no longer
diverse LSP with the error code error code "Notify Error" satisfied and no alternative path for the diverse LSP that can
(25) and error sub-code "Failed to respect Exclude Route" satisfy those constraints exists, then:
(value: to be assigned by IANA). The PSR flag SHOULD NOT
be set.
The following rules apply whether or not the L-flag is set: - If the L-flag was not set in the original exclusion, the
processing node MUST send a PathErr message for the diverse LSP
with the error code "Routing Problem" (24) and error sub-code
"Route blocked by Exclude Route" (67). The PSR flag MUST be
set.
- A source node receiving a PathErr message with the error code - If the L-flag was set in the original exclusion, the
"Notify Error" (25) and error sub-codes "Route of XRO tunnel processing node MUST send a PathErr message for the diverse LSP
identifier unknown" or "Failed to respect Exclude Route" MAY with the error code error code "Notify Error" (25) and error
take no action. sub-code "Failed to respect Exclude Route" (value: to be
assigned by IANA). The PSR flag MUST NOT be set. The source
node MAY take no action and keep the LSP along the non-
compliant path.
2.3. Diversity EXRS Subobject 2.3. 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 Diversity subobject as specified in this
skipping to change at page 23, line 14 skipping to change at page 21, line 28
| IPv6 Diversity Identifier source address (cont.) | | IPv6 Diversity Identifier source address (cont.) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Diversity Identifier Value | | Diversity Identifier Value |
// ... // // ... //
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The meanings of respective fields in EXRS header are as defined The meanings of respective fields in EXRS header are as defined
in [RFC4874]. The meanings of respective fields in the Diversity in [RFC4874]. The meanings of respective fields in the Diversity
subobject are as defined earlier in this document for the XRO subobject are as defined earlier in this document for the XRO
subobject. Diversity subobject.
The processing rules for the EXRS object are unchanged from The processing rules for the EXRS object are unchanged from
[RFC4874]. When the EXRS contains one or more Diversity [RFC4874]. When the EXRS contains one or more Diversity
subobject(s), the processing rules specified in Section 2.2 apply subobject(s), the processing rules specified in Section 2.2 apply
to the node processing the ERO with the EXRS subobject. to the node processing the ERO with the EXRS subobject.
If a loose-hop expansion results in the creation of another If a loose-hop expansion results in the creation of another
loose-hop in the outgoing ERO, the processing node MAY include loose-hop in the outgoing ERO, the processing node MAY include
the EXRS in the newly created loose hop for further processing by the EXRS in the newly created loose hop for further processing by
downstream nodes. downstream nodes.
skipping to change at page 25, line 4 skipping to change at page 23, line 11
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-
Codes Codes
For Error Code "Notify Error" (25) (see [RFC3209]) the following For Error Code "Notify Error" (25) (see [RFC3209]) the following
sub-codes are defined. (see: sub-codes are defined. (see:
http://www.iana.org/assignments/rsvp-parameters/rsvp- http://www.iana.org/assignments/rsvp-parameters/rsvp-
parameters.xhtml#rsvp-parameters-105) parameters.xhtml#rsvp-parameters-105)
+-------------+----------------------------+---------------+ +-------------+----------------------------+---------------+
| Error Value | Description | Reference | | Error Value | Description | Reference |
| Sub-codes | | | | Sub-codes | | |
+-------------+----------------------------+---------------+ +-------------+----------------------------+---------------+
| TBA3 | Route of XRO tunnel | This document | | TBA3 | Route of XRO LSP | This document |
| | identifier unknown | | | | identifier unknown | |
| TBA4 | Failed to respect | This document | | TBA4 | Failed to respect | This document |
| | Exclude Route | | | | Exclude Route | |
| TBA5 | Compliant path exists | This document | | TBA5 | Compliant path exists | This document |
+-------------+----------------------------+---------------+ +-------------+----------------------------+---------------+
5. Acknowledgements 5. Acknowledgements
The authors would like to thank Luyuan Fang and Walid Wakim for The authors would like to thank Luyuan Fang and Walid Wakim for
their review comments. their review comments.
skipping to change at page 26, line 24 skipping to change at page 24, line 28
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.
[RFC5520] Bradford, R., Ed., Vasseur, JP., and A. Farrel, [RFC5520] Bradford, R., Ed., Vasseur, JP., and A. Farrel,
"Preserving Topology Confidentiality in Inter-Domain "Preserving Topology Confidentiality in Inter-Domain
Path Computation Using a Path-Key-Based Mechanism", RFC Path Computation Using a Path-Key-Based Mechanism", RFC
5520, April 2009. 5520, April 2009.
[DRAFT-SRLG-RECORDING] F. Zhang, D. Li, O. Gonzalez de Dios, C. [DRAFT-SRLG-RECORDING] F. Zhang, D. Li, O. Gonzalez de Dios, C.
Margaria, "RSVP-TE Extensions for Collecting SRLG Margaria, "RSVP-TE Extensions for Collecting SRLG
Information", draft-ietf-teas-rsvp-te-srlg-collect-00, Information", draft-ietf-teas-rsvp-te-srlg-collect-02,
work in progress. work in progress.
[RFC2205] Braden, R. (Ed.), Zhang, L., Berson, S., Herzog, S. and [RFC2205] Braden, R. (Ed.), Zhang, L., Berson, S., Herzog, S. and
S. Jamin, "Resource ReserVation Protocol -- Version 1 S. Jamin, "Resource ReserVation Protocol -- Version 1
Functional Specification", RFC 2205, September 1997. Functional Specification", RFC 2205, September 1997.
[RFC4026] Andersson, L. and T. Madsen, "Provider Provisioned [RFC4026] Andersson, L. and T. Madsen, "Provider Provisioned
Virtual Private Network (VPN) Terminology", RFC 4026, Virtual Private Network (VPN) Terminology", RFC 4026,
March 2005. March 2005.
 End of changes. 61 change blocks. 
219 lines changed or deleted 184 lines changed or added

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