draft-ietf-teas-lsp-diversity-03.txt   draft-ietf-teas-lsp-diversity-04.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: July 8, 2016 F. Zhang, Ed. Expires: September 22, 2016 F. Zhang, Ed.
Huawei Huawei
D. Beller, Ed. D. Beller, Ed.
Alcatel-Lucent Nokia
January 5, 2016 March 21, 2016
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-03.txt draft-ietf-teas-lsp-diversity-04.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 July 8, 2016. This Internet-Draft will expire on September 22, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 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
skipping to change at page 2, line 23 skipping to change at page 2, line 28
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...........................7 1.3. Network-Assigned Identifier...........................7
2. RSVP-TE signaling extensions..................................9 2. RSVP-TE signaling extensions..................................9
2.1. Diversity XRO Subobject...............................9 2.1. Diversity XRO Subobject...............................9
2.1.1. IPv4 Diversity XRO Subobject................. 9 2.2. Diversity EXRS Subobject.............................15
2.1.2. IPv6 Diversity XRO Subobject................ 13 2.3. Processing rules for the Diversity XRO and EXRS
2.2. Processing rules for the Diversity XRO subobject.....17 subobjects...........................................16
2.3. Diversity EXRS Subobject.............................20 3. Security Considerations......................................20
3. Security Considerations......................................22 4. IANA Considerations..........................................21
4. IANA Considerations..........................................22 4.1. New XRO subobject types..............................21
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
5. Acknowledgements.............................................23 6. References...................................................22
6. References...................................................23 6.1. Normative References.................................22
6.1. Normative References.................................23 6.2. Informative References...............................23
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 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
skipping to change at page 4, line 28 skipping to change at page 4, line 28
| -+ 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.
A single point of failure caused by a single-homed UNI can be A single point of failure caused by a single-homed UNI can be
avoided when the EN device is connected to two different CN avoided when the EN device is connected to two different CN
skipping to change at page 6, line 32 skipping to change at page 6, line 32
Signaling [RFC4920]. Note that crankback signaling is known to Signaling [RFC4920]. Note that crankback signaling is known to
lead to slower setup times and sub-optimal paths under some lead to slower setup times and sub-optimal paths under some
circumstances 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 at network node(s) 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
identifier to ensure diversity. 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.
skipping to change at page 9, line 17 skipping to change at page 9, line 17
PAS information, the information is kept inside core network and PAS information, the information is kept inside core network and
is not shared with the overlay network (see Figure 1). is not shared with the overlay network (see 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 by this document as New Diversity XRO subobjects are defined below for the IPv4 and
follows. IPv6 address families. Most of the fields in the IPv4 and IPv6
Diversity XRO subobjects are common and are described following
the definition of the two subobjects.
2.1.1. IPv4 Diversity XRO Subobject IPv4 Diversity XRO Subobject is defined as follows:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|L| XRO Type | Length |DI Type|A-Flags|E-Flags| Resvd | |L| XRO Type | Length |DI Type|A-Flags|E-Flags| Resvd |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Diversity Identifier Source Address | | IPv4 Diversity Identifier Source Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Diversity Identifier Value | | Diversity Identifier Value |
// ... // // ... //
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Similarly, the IPv6 Diversity XRO Subobject is defined as
follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|L| XRO Type | Length |DI Type|A-Flags|E-Flags| Resvd |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 Diversity Identifier source address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 Diversity Identifier source address (cont.) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 Diversity Identifier source address (cont.) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 Diversity Identifier source address (cont.) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Diversity Identifier Value |
// ... //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
L: 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.,
0 indicates that the attribute specified MUST be excluded. 0 indicates that the attribute specified MUST be excluded.
1 indicates that the attribute specified SHOULD be avoided. 1 indicates that the attribute specified SHOULD be avoided.
XRO Type XRO Type
Type for IPv4 diversity XRO subobject (to be assigned by
IANA). The value is set to for IPv4 diversity XRO subobject
(value to be assigned by IANA). Similarly, The value is
set to for IPv6 diversity XRO Subobject (value to be
assigned by IANA).
Length Length
The Length contains the total length of the subobject in The Length contains the total length of the IPv4/ IPv6
bytes, including the Type and Length fields. The Length is subobject in bytes, including the Type and Length fields.
variable, depending on the diversity identifier value. The Length is variable, depending on the 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. The following three DI type values required is identified in the IPv4/ IPv6 Diversity
are defined in this document: subobjects. The following three DI type values are defined
in this document:
DI Type value Definition DI Type value Definition
------------- -------------------------------- ------------- --------------------------------
1 IPv4 Client Initiated Identifier 1 Client Initiated Identifier
2 IPv4 PCE Allocated Identifier 2 PCE Allocated Identifier
3 IPv4 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. The desirable attributes of the LSP being signaled in the IPv4/
following flags are defined. Each flag acts independently. IPv6 Diversity subobjects. The following flags are defined.
Any combination of flags is permitted. Each flag acts independently. Any combination of flags is
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
border node(s) performing ERO expansion for the LSP node(s) performing ERO expansion for the LSP being
being signaled. An ingress UNI-N node is an example of signaled. An ingress UNI-N node is an example of such a
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.
0x08 = LSP ID to be ignored
This flag is used to indicate tunnel level exclusion.
Specifically, this flag is used to indicate that if
diversity identifier contains lsp-id field, the lsp-id
is to be ignored and the exclusion applies to any LSP
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. The following flags are defined. Any type(s) of exclusion requested in the IPv4/ IPv6 diversity
combination of these flags is permitted. subobjects. The following flags are defined. Any
combination of these flags is permitted. Please note that
the exclusion specified by these flags may be modified by
the value of the Attribute-flags. For example, node
exclusion flag is ignored for the "Penultimate node" if the
"Penultimate node exception" flag of the Attribute-flags is
set.
0x01 = SRLG exclusion 0x01 = 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
specified by the Diversity XRO subobject. 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 Diversity XRO subobject. specified by the IPv4/ IPv6 Diversity XRO subobject.
(Note: the meaning of this flag may be modified by
the value of the Attribute-flags.)
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 Diversity XRO subobject. by the IPv4/ IPv6 Diversity XRO subobject.
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 for both
IPv4/ IPv6 Diversity XRO subobjects.
IPv4 Diversity Identifier source address: IPv4 / IPv6 Diversity Identifier source address:
This field is set to the IPv4 address of the node that This field is set to the IPv4/ IPv6 address of the node
assigns the diversity identifier. Depending on the that assigns the diversity identifier. Depending on the
diversity identifier type, the diversity identifier source diversity identifier type, the diversity identifier source
may be a client node, PCE entity or network node. may be a client node, PCE entity or network node.
Specifically: Specifically:
o When the diversity identifier type is set to "IPv4 Client o When the diversity identifier type is set to "IPv4/ IPv6
Initiated Identifier", the value is set to IPv4 tunnel Client Initiated Identifier", the value is set to IPv4/
sender address of the reference LSP against which IPv6 tunnel sender address of the reference LSP against
diversity is desired. IPv4 tunnel sender address is as which diversity is desired. IPv4/ IPv6 tunnel sender
defined in [RFC3209]. address is as defined in [RFC3209].
o When the diversity identifier type is set to "IPv4 PCE o When the diversity identifier type is set to "IPv4/ IPv6
Allocated Identifier", the value indicates the IPv4 PCE Allocated Identifier", the value indicates the IPv4/
address of the node that assigned the Path Key identifier IPv6 address of the node that assigned the Path Key
and that can return an expansion of the Path Key or use identifier and that can return an expansion of the Path
the Path Key as exclusion in a path computation. The Path Key or use the Path Key as exclusion in a path
Key is defined in [RFC5553]. computation. The Path Key is defined in [RFC5553].
o When the diversity identifier type is set to "IPv4 o When the diversity identifier type is set to "IPv4/ IPv6
Network Assigned Identifier", the value indicates the IPv4 Network Assigned Identifier", the value indicates the
address of the node publishing the Path Affinity Set IPv4/ IPv6 address of the node publishing the Path
(PAS). Affinity 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.
When the diversity identifier type is set to "IPv4 Client When the diversity identifier type is set to "Client
Initiated Identifier", the diversity identifier value MUST Initiated Identifier" in IPv4 Diversity XRO subobject, the
be encoded as follows: diversity identifier value MUST be encoded as follows:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 13, line 4 skipping to change at page 14, line 5
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
Allocated Identifier", the diversity identifier value MUST
be encoded as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Must Be Zero | Path Key |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Path Key is defined in [RFC5553].
When the diversity identifier type is set to "IPv4 Network
Assigned Identifier", the diversity identifier value MUST
be encoded as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Path Affinity Set (PAS) identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Path affinity Set (PAS) identifier is a single number
that represents a summarized SRLG for the reference path
against which diversity is desired. The PAS identifier is
defined in this document.
2.1.2. IPv6 Diversity XRO Subobject
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|L| XRO Type | Length |DI Type|A-Flags|E-Flags| Resvd |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 Diversity Identifier source address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 Diversity Identifier source address (cont.) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 Diversity Identifier source address (cont.) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 Diversity Identifier source address (cont.) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Diversity Identifier Value |
// ... //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
L:
The L-flag is used as for the XRO subobjects defined in
[RFC4874], i.e.,
0 indicates that the attribute specified MUST be excluded.
1 indicates that the attribute specified SHOULD be avoided.
XRO Type
Type for IPv6 diversity XRO subobject (to be assigned by
IANA).
Length
The Length contains the total length of the subobject in
bytes, including the Type and Length fields. The Length is
variable, depending on the diversity identifier value.
Attribute Flags (A-Flags):
As defined in Section 2.1.1 for the IPv4 counterpart.
Exclusion Flags (E-Flags):
As defined in Section 2.1.1 for the IPv4 counterpart.
Resvd
This field is reserved. It SHOULD be set to zero on
transmission, and MUST be ignored on receipt.
Diversity Identifier Type (DI Type)
This field is defined in the same fashion as its IPv4
counter part described in Section 2.1.1.
The three DI Types associated with IPv6 addresses are
defined as follows:
DI Type value Definition
------------- --------------------------------
4 IPv6 Client Initiated Identifier
5 IPv6 PCE Allocated Identifier
6 IPv6 Network Assigned Identifier
These idenifier are assigned and used as defined in
Section 2.1.1.
IPv4 Diversity Identifier source address:
This field is set to IPv6 address of the node that assigns
the diversity identifier. How identity of node for various
diversity types is determined is as described in Section
2.1.1 for the IPv4 counterpart.
Diversity Identifier Value:
Encoding for this field depends on the diversity identifier
type, as defined in the following.
When the diversity identifier type is set to "IPv6 Client When the diversity identifier type is set to "IPv6 Client
Initiated Identifier", the diversity identifier value MUST Initiated Identifier" in IPv6 Diversity XRO subobject, the
be encoded as follows: diversity identifier value MUST be encoded as follows:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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 16, line 20 skipping to change at page 14, line 40
| Extended Tunnel ID (cont.) | | Extended Tunnel ID (cont.) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extended Tunnel ID (cont.) | | Extended Tunnel ID (cont.) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Must Be Zero | LSP ID | | Must Be Zero | LSP ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The IPv6 tunnel end point address, Tunnel ID, IPv6 Extended The IPv6 tunnel 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 "PCE Allocated
Allocated Identifier", the diversity identifier value MUST Identifier" in IPv4 or IPv6 Diversity XRO subobject, the
be encoded as follows: diversity identifier value MUST be encoded as follows:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Must Be Zero | Path Key | | Must Be Zero | Path Key |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Path Key is defined in [RFC5553]. The Path Key is defined in [RFC5553].
When the diversity identifier type is set to "IPv6 Network When the diversity identifier type is set to "Network
Assigned Identifier", the diversity identifier value MUST Assigned Identifier" in IPv4 or IPv6 Diversity XRO
be encoded as follows: subobject, the diversity identifier value MUST be encoded
as follows:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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 field is a 32-bit
Section 2.1.1. value that is scoped by, i.e., is only meaningful when
used in combination with, the Diversity Identifier source
address field. There are no restrictions on how a node
selects a PAS identifier value. Section 1.3. defines the
PAS term and provides context on how values may be
selected.
2.2. Processing rules for the Diversity XRO subobject 2.2. Diversity EXRS Subobject
The procedure defined in [RFC4874] for processing XRO and EXRS is [RFC4874] defines the EXRS ERO subobject. An EXRS is used to
not changed by this document. If the processing node cannot identify abstract nodes or resources that must not or should not
recognize the IPv4/IPv6 Diversity XRO subobject, the node is be used on the path between two inclusive abstract nodes or
expected to follow the procedure defined in [RFC4874]. resources in the explicit route. An EXRS contains one or more
subobjects of its own, called EXRS subobjects [RFC4874].
An XRO object MAY contain multiple Diversity subobjects. E.g., in An EXRS MAY include Diversity subobject as specified in this
order to exclude multiple Path Keys, an EN may include multiple document. In this case, the IPv4 EXRS format is as follows:
Diversity XRO subobjects each with a different Path Key.
Similarly, in order to exclude the routes taken by multiple LSPs,
an EN may include multiple Diversity XRO subobjects each with a
different LSP identifier. Likewise, to exclude multiple PAS
identifiers, an EN may include multiple Diversity XRO subobjects
each with a different PAS identifier. However, all Diversity
subobjects in an XRO MUST contain the same Diversity Identifier
Type. If a Path message contains an XRO with multiple Diversity
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).
Please note that only those nodes in the domain that perform path 0 1 2 3
computation (typically the domain ingress node), shall process 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
the diversity information signaled in the Diversity subobjects. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The transit nodes in a domain and the domain egress node |L| Type | Length | Reserved |
typically do not need to process it. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|L| XRO Type | Length |DI Type|A-Flags|E-Flags| Resvd |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Diversity Identifier source address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Diversity Identifier Value |
// ... //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The attribute-flags affect the processing of the Diversity XRO Similarly, the IPv6 EXRS format is as follows:
subobject as follows:
o When the "destination node exception" flag is set, the 0 1 2 3
exclusion MUST be ignored for the destination node. 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| Type | Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|L| XRO Type | Length |DI Type|A-Flags|E-Flags| Resvd |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 Diversity Identifier source address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 Diversity Identifier source address (cont.) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 Diversity Identifier source address (cont.) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 Diversity Identifier source address (cont.) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Diversity Identifier Value |
// ... //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The meanings of respective fields in EXRS header are as defined
in [RFC4874]. The meanings of respective fields in the Diversity
subobject are as defined earlier in this document for the XRO
Diversity subobject.
2.3. Processing rules for the Diversity XRO and EXRS subobjects
The procedure defined in [RFC4874] for processing the XRO and
EXRS is not changed by this document. The processing rules for
the Diversity XRO and EXRS subobjects are similar unless the
differences are explicitly described. Similarly, IPv4 and IPv6
Diversity XRO subobjects and IPv4 and IPv6 Diversity EXRS
subobjects follow the same processing rules.
If the processing node cannot recognize the Diversity XRO/ EXRS
subobject, the node is expected to follow the procedure defined
in [RFC4874].
An XRO/ EXRS object MAY contain multiple Diversity subobjects of
the same DI Type. E.g., in order to exclude multiple Path Keys, a
node may include multiple Diversity XRO subobjects each with a
different Path Key. Similarly, in order to exclude the routes
taken by multiple LSPs, a node may include multiple Diversity
XRO/ EXRS subobjects each with a different LSP identifier.
Likewise, to exclude multiple PAS identifiers, a node may include
multiple Diversity XRO/ EXRS subobjects each with a different PAS
identifier. However, all Diversity subobjects in an XRO/ EXRS
MUST contain the same Diversity Identifier Type. If a Path
message contains an XRO/ EXRS with multiple Diversity subobjects
of different DI Types, the processing node MUST return a PathErr
with the error code "Routing Problem" (24) and error sub-code
"XRO/ EXRS Too Complex" (68/ 69).
If the processing node recognize the Diversity XRO/ EXRS
subobject but does not support the DI type, it MUST return a
PathErr with the error code "Routing Problem" and error value of
"Unsupported Diversity Identifier Type".
The nodes in the domain that perform path computation SHOULD
process the diversity information signaled in the XRO/ EXRS
Diversity subobjects. The transit nodes in a domain and the
domain egress node MAY ignore it. While processing EXRS object,
if a loose-hop expansion results in the creation of another
loose-hop in the outgoing ERO, the processing node MAY include
the EXRS in the newly created loose hop for further processing by
downstream nodes.
The attribute-flags affect the processing of the Diversity 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 processing node. The exclusion MUST be ignored for the node processing the XRO
processing node is the node performing path calculation. or EXRS subobject.
o When the "penultimate node exception" flag is set, the o When the "destination node exception" flag is set, the
exclusion MUST be ignored for the penultimate node on the exclusion MUST be ignored for the destination node in
path of the LSP being established. processing the XRO subobject. The destination node
exception for the EXRS subobject applies to the explicit
node identified by the ERO subobject that identifies the
next abstract node. This flag is only processed if the L
bit is set in the ERO subobject that identifies the next
abstract node.
If the L-flag of the diversity XRO subobject is not set, the o When the "penultimate node exception" flag is set in the
processing node proceeds as follows. XRO subobject, the exclusion MUST be ignored for the
penultimate node on the path of the LSP being established.
The penultimate node exception for the EXRS subobject
applies to the node before the explicit node identified by
the ERO subobject that identifies the next abstract node.
This flag is only processed if the L bit is set in the ERO
subobject that identifies the next abstract node.
If the L-flag of the diversity XRO subobject or diversity EXRS
subobject is not set, the processing node proceeds as follows.
- If the Diversity Identifier Type is set to "IPv4/IPv6 Client - If the Diversity Identifier Type is set to "IPv4/IPv6 Client
Initiated Identifiers", the processing node MUST ensure that Initiated Identifiers", the processing node MUST ensure that
the path calculated/ expended for the signaled LSP is diverse the path calculated/ expended for the signaled LSP is diverse
from the route taken by the LSP identified in the Diversity from the route taken by the LSP identified in the Diversity
Identifier Value field. Identifier Value field.
- If the Diversity Identifier Type is set to "IPv4/IPv6 PCE - If the Diversity Identifier Type is set to "IPv4/IPv6 PCE
Allocated Identifiers", the processing node MUST ensure that Allocated Identifiers", the processing node MUST ensure that
any path calculated for the signaled LSP is diverse from the any path calculated for the signaled LSP is diverse from the
route identified by the Path-Key. The processing node MAY use route identified by the Path-Key. The processing node MAY use
the PCE identified by the IPv4/IPv6 Diversity Identifier Source the PCE identified by the IPv4/IPv6 Diversity Identifier Source
Address in the subobject for route computation. The processing Address in the subobject for route computation. The processing
node MAY use the Path-Key resolution mechanisms described in node MAY use 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 "IPv4/IPv6 Network
Assigned Identifiers", the processing node MUST ensure that the Assigned Identifiers", the processing node MUST ensure that the
path calculated for the signaled LSP respects the requested PAS path calculated for the signaled LSP is diverse with respect to
exclusion. the values associated with the PAS identifier and Diversity
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 MUST ensure that any path calculated for the signaled LSP is
respects 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 "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 XRO diversity subobject or EXRS diversity
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 "IPv4/IPv6 Client
Initiated Identifiers", the processing node SHOULD ensure that Initiated Identifiers", the processing node SHOULD ensure that
the path calculated/ expended for the signaled LSP is diverse the path calculated/ expended for the signaled LSP is diverse
from the route taken by the LSP identified in the Diversity from the route taken by the LSP identified in the Diversity
Identifier Value field. Identifier Value field.
- If the Diversity Identifier Type is set to "IPv4/IPv6 PCE - If the Diversity Identifier Type is set to "IPv4/IPv6 PCE
Allocated Identifiers", the processing node SHOULD ensure that Allocated Identifiers", the processing node SHOULD ensure that
the path calculated for the signaled LSP is diverse from the the path calculated for the signaled LSP is diverse from the
route identified by the Path-Key.If the Diversity Identifier route identified by the Path-Key.
Type is set to "IPv4/IPv6 Network Assigned Identifiers", the
processing node SHOULD ensure that the path calculated for the
signaled LSP respects the requested PAS exclusion.
- The processing node SHOULD respect the requested exclusion - If the Diversity Identifier Type is set to "IPv4/IPv6 Network
flags to the extent possible. Assigned Identifiers", the processing node SHOULD ensure that
the path calculated for the signaled LSP is diverse with
respect to the values associated with the PAS identifier and
Diversity Identifier source address fields.
- 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 MUST 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 satisfy 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, an If, subsequent to the initial signaling of a diverse LSP, an
excluded path referenced in the XRO subobject becomes known to excluded path referenced in the XRO subobject becomes known to
the processing node, or a change in the excluded path becomes the processing node, or a change in the excluded path becomes
known to the processing node, the processing node MUST re- known to the processing node, the processing node MUST re-
evaluate the exclusion and diversity constraints requested by the evaluate the exclusion and diversity constraints requested by the
diverse LSP to determine whether they are still satisfied. diverse LSP to determine whether they are still satisfied.
If, subsequent to the initial signaling of a diverse LSP, the If, subsequent to the initial signaling of a diverse LSP, the
requested exclusion constraints for the diverse LSP are no longer requested exclusion constraints for the diverse LSP are no longer
satisfied and an alternative path for the diverse LSP that can satisfied and an alternative path for the diverse LSP that can
satisfy those constraints exists, then: satisfy those constraints exists, then:
- If the L-flag was not set in the original exclusion, the - If the L-flag was not set in the original exclusion, the
processing node MUST send a PathErr message for the diverse LSP processing node MUST send a PathErr message for the diverse LSP
with the error code "Routing Problem" (24) and error sub-code with the error code "Routing Problem" (24) and error sub-code
"Route blocked by Exclude Route" (67). The PSR flag MUST NOT be "Route blocked by Exclude Route" (67). The Path_State_Removed
set. A source node receiving a PathErr message with this error flag (PSR) [RFC3473] MUST NOT be set. A source node receiving a
code and sub-code combination SHOULD take appropriate actions PathErr message with this error code and sub-code combination
to migrate to a compliant path. SHOULD take appropriate actions to migrate to a compliant path.
- If the L-flag was 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 diverse LSP processing node MUST send a PathErr message for the diverse LSP
with the error code "Notify Error" (25) and a new error sub- with the error code "Notify Error" (25) and a new error sub-
code "compliant path exists" (value: to be assigned by IANA). code "compliant path exists" (value: to be assigned by IANA).
The PSR flag MUST NOT be set. A source node receiving a PathErr The PSR flag MUST NOT be set. A source node receiving a PathErr
message with this error code and sub-code combination MAY message with this error code and sub-code combination MAY
signal a new LSP to migrate the compliant path. signal a new LSP to migrate the compliant path.
If, subsequent to the initial signaling of a diverse LSP, the If, subsequent to the initial signaling of a diverse LSP, the
skipping to change at page 20, line 16 skipping to change at page 20, line 35
- If the L-flag was not set in the original exclusion, the - If the L-flag was not set in the original exclusion, the
processing node MUST send a PathErr message for the diverse LSP processing node MUST send a PathErr message for the diverse LSP
with the error code "Routing Problem" (24) and error sub-code with the error code "Routing Problem" (24) and error sub-code
"Route blocked by Exclude Route" (67). The PSR flag MUST be "Route blocked by Exclude Route" (67). The PSR flag MUST be
set. set.
- If the L-flag was 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 diverse LSP processing node MUST send a PathErr message for the diverse LSP
with the error code error code "Notify Error" (25) and error with the error code error code "Notify Error" (25) and error
sub-code "Failed to respect Exclude Route" (value: to be sub-code "Failed to satisfy Exclude Route" (value: to be
assigned by IANA). The PSR flag MUST NOT be set. The source assigned by IANA). The PSR flag MUST NOT be set. The source
node MAY take no action and keep the LSP along the non- node MAY take no action and keep the LSP along the non-
compliant path. compliant path.
2.3. Diversity EXRS Subobject
[RFC4874] defines the EXRS ERO subobject. An EXRS is used to
identify abstract nodes or resources that must not or should not
be used on the path between two inclusive abstract nodes or
resources in the explicit route. An EXRS contains one or more
subobjects of its own, called EXRS subobjects [RFC4874].
An EXRS MAY include Diversity subobject as specified in this
document. In this case, the IPv4 EXRS format is as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|L| Type | Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|L| XRO Type | Length |DI Type|A-Flags|E-Flags| Resvd |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Diversity Identifier source address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Diversity Identifier Value |
// ... //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Similarly, the IPv6 EXRS format is as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|L| Type | Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|L| XRO Type | Length |DI Type|A-Flags|E-Flags| Resvd |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 Diversity Identifier source address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 Diversity Identifier source address (cont.) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 Diversity Identifier source address (cont.) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 Diversity Identifier source address (cont.) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Diversity Identifier Value |
// ... //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The meanings of respective fields in EXRS header are as defined
in [RFC4874]. The meanings of respective fields in the Diversity
subobject are as defined earlier in this document for the XRO
Diversity subobject.
The processing rules for the EXRS object are unchanged from
[RFC4874]. When the EXRS contains one or more Diversity
subobject(s), the processing rules specified in Section 2.2 apply
to the node processing the ERO with the EXRS subobject.
If a loose-hop expansion results in the creation of another
loose-hop in the outgoing ERO, the processing node MAY include
the EXRS in the newly created loose hop for further processing by
downstream nodes.
The processing node exception for the EXRS subobject applies to
the node processing the ERO.
The destination node exception for the EXRS subobject applies to
the explicit node identified by the ERO subobject that identifies
the next abstract node. This flag is only processed if the L bit
is set in the ERO subobject that identifies the next abstract
node.
The penultimate node exception for the EXRS subobject applies to
the node before the explicit node identified by the ERO subobject
that identifies the next abstract node. This flag is only
processed if the L bit is set in the ERO subobject that
identifies the next abstract node.
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], above those identified in [RFC5920], [RFC2205], [RFC3209],
[RFC3473] and [RFC4874]. [RFC3473] and [RFC4874].
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.
skipping to change at page 23, line 5 skipping to change at page 21, line 35
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. (see: http://www.iana.org/assignments/rsvp- subobjects. (see: http://www.iana.org/assignments/rsvp-
parameters/rsvp-parameters.xhtml#rsvp-parameters-24) parameters/rsvp-parameters.xhtml#rsvp-parameters-24)
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 "Routing Problem" (24) (see [RFC3209]) the
following sub-codes are defined. (see:
http://www.iana.org/assignments/rsvp-parameters/rsvp-
parameters.xhtml#rsvp-parameters-105)
+-------------+----------------------------+---------------+
| Error Value | Description | Reference |
| Sub-codes | | |
+-------------+----------------------------+---------------+
| TBA3 | Unsupported Diversity | This document |
| | Identifier Type | |
+-------------+----------------------------+---------------+
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 LSP | This document | | TBA4 | Route of XRO LSP | This document |
| | identifier unknown | | | | identifier unknown | |
| TBA4 | Failed to respect | This document | | TBA5 | Failed to satisfy | This document |
| | Exclude Route | | | | Exclude Route | |
| TBA5 | Compliant path exists | This document | | TBA6 | 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.
6. References 6. References
6.1. Normative References 6.1. Normative References
skipping to change at page 24, line 28 skipping to change at page 23, line 37
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-02, Information", draft-ietf-teas-rsvp-te-srlg-collect-04,
in expert review. in expert review.
[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 [RFC5251] D. Fedyk, Ed., Y. Rekhter, Ed., D. Papadimitriou,
Virtual Private Network (VPN) Terminology", RFC 4026, R. Rabbat, L. Berger, "Layer 1 VPN Basic Mode",
March 2005. RFC 5251, July 2008.
[RFC5253] Takeda, T., Ed., "Applicability Statement for Layer 1
Virtual Private Network (L1VPN) Basic Mode", RFC 5253,
July 2008.
[RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS [RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS
Networks", RFC 5920, July 2010. Networks", RFC 5920, July 2010.
Contributors' Addresses Contributors' Addresses
Igor Bryskin Igor Bryskin
ADVA Optical Networking ADVA Optical Networking
Email: ibryskin@advaoptical.com Email: ibryskin@advaoptical.com
skipping to change at page 26, line 4 skipping to change at page 25, line 19
SDN Solutions Ltd. SDN Solutions Ltd.
Email: origerstel@gmail.com Email: origerstel@gmail.com
Matt Hartley Matt Hartley
Cisco Systems Cisco Systems
Email: mhartley@cisco.com Email: mhartley@cisco.com
Kenji Kumaki Kenji Kumaki
KDDI Corporation KDDI Corporation
Email: ke-kumaki@kddi.com Email: ke-kumaki@kddi.com
Ruediger Kunze Ruediger Kunze
Deutsche Telekom AG Deutsche Telekom AG
Email: Ruediger.Kunze@telekom.de Email: Ruediger.Kunze@telekom.de
Lieven Levrau Lieven Levrau
Alcatel-Lucent Nokia
Email: Lieven.Levrau@alcatel-lucent.com Email: Lieven.Levrau@nokia.com
Cyril Margaria Cyril Margaria
cyril.margaria@gmail.com cyril.margaria@gmail.com
Julien Meuric Julien Meuric
France Telecom Orange France Telecom Orange
Email: julien.meuric@orange.com Email: julien.meuric@orange.com
Yuji Tochio Yuji Tochio
Fujitsu Fujitsu
skipping to change at page 26, line 34 skipping to change at page 26, line 12
Huawei Technologies Huawei Technologies
Email: zhang.xian@huawei.com Email: zhang.xian@huawei.com
Authors' Addresses Authors' Addresses
Zafar Ali Zafar Ali
Cisco Systems. Cisco Systems.
Email: zali@cisco.com Email: zali@cisco.com
Dieter Beller Dieter Beller
Alcatel-Lucent Nokia
Email: Dieter.Beller@alcatel-lucent.com Email: Dieter.Beller@nokia.com
George Swallow George Swallow
Cisco Systems Cisco Systems
Email: swallow@cisco.com Email: swallow@cisco.com
Fatai Zhang Fatai Zhang
Huawei Technologies Huawei Technologies
Email: zhangfatai@huawei.com Email: zhangfatai@huawei.com
 End of changes. 64 change blocks. 
332 lines changed or deleted 283 lines changed or added

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