draft-ietf-teas-lsp-diversity-00.txt   draft-ietf-teas-lsp-diversity-01.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: June 10, 2015 F. Zhang, Ed. Expires: September 10, 2015 F. Zhang, Ed.
Huawei Huawei
D. Beller, Ed. D. Beller, Ed.
Alcatel-Lucent Alcatel-Lucent
December 11, 2014 March 9, 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-00.txt draft-ietf-teas-lsp-diversity-01.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 June 10, 2015. This Internet-Draft will expire on September 10, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2015 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 Provisions This document is subject to BCP 78 and the IETF Trust's Legal
Relating to IETF Documents (http://trustee.ietf.org/license-info) Provisions Relating to IETF Documents
in effect on the date of publication of this document. Please (http://trustee.ietf.org/license-info) in effect on the date of
review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. Code Components carefully, as they describe your rights and restrictions with
extracted from this document must include Simplified BSD License respect to this document. Code Components extracted from this
text as described in Section 4.e of the Trust Legal Provisions document must include Simplified BSD License text as described in
and are provided without warranty as described in the Simplified Section 4.e of the Trust Legal Provisions and are provided without
BSD License. warranty as described in the Simplified BSD License.
Internet Draft draft-ietf-teas-lsp-diversity-00.txt
Abstract Abstract
RFC 4874 specifies methods by which path exclusions can be RFC 4874 specifies methods by which path exclusions can be
communicated during RSVP-TE signaling in networks where precise communicated during RSVP-TE signaling in networks where precise
explicit paths are not computed by the LSP source node. This explicit paths are not computed by the LSP source node. This
document specifies procedures for additional route exclusion document specifies procedures for additional route exclusion
subobject based on Paths currently existing or expected to exist subobject based on Paths currently existing or expected to exist
within the network. within the network.
skipping to change at page 2, line 27 skipping to change at page 2, line 20
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 ...........................7 1.3. Network-Assigned Identifier ...........................8
2. RSVP-TE signaling extensions ..................................9 2. RSVP-TE signaling extensions .................................10
2.1. Diversity XRO Subobject ...............................9 2.1. Diversity XRO Subobject ..............................10
2.1.1. IPv4 Diversity XRO Subobject ....................9 2.1.1. IPv4 Diversity XRO Subobject ...................10
2.1.2. IPv6 Diversity XRO Subobject ...................14 2.1.2. IPv6 Diversity XRO Subobject ...................15
2.2. Processing rules for the Diversity XRO subobject .....17 2.2. Processing rules for the Diversity XRO subobject .....18
2.3. Diversity EXRS Subobject .............................20 2.3. Diversity EXRS Subobject .............................22
3. Security Considerations ......................................22 3. Security Considerations ......................................23
4. IANA Considerations ..........................................22 4. IANA Considerations ..........................................24
4.1. New XRO subobject types ..............................22 4.1. New XRO subobject types ..............................24
4.2. New EXRS subobject types .............................23 4.2. New EXRS subobject types .............................24
4.3. New RSVP error sub-codes .............................23 4.3. New RSVP error sub-codes .............................24
5. Acknowledgements .............................................23 5. Acknowledgements .............................................25
6. References ...................................................24 6. References ...................................................25
6.1. Normative References .................................24 6.1. Normative References .................................25
6.2. Informative References ...............................24 6.2. Informative References ...............................26
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
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 When a source node has full topological knowledge and is permitted
to signal an Explicit Route Object, diverse paths for LSPs can be to signal an Explicit Route Object, diverse paths for LSPs can be
computed by this source node. However, there are scenarios when computed by this source node. However, there are scenarios when
Internet Draft draft-ietf-teas-lsp-diversity-00.txt
path computations are performed by different nodes, and there is path computations are performed by different nodes, and there is
therefore a need for relevant diversity constraints to be therefore a need for relevant diversity constraints to be
communicated to those nodes. These include (but are not limited communicated to those 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 path computation may be
skipping to change at page 4, line 5 skipping to change at page 4, line 5
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 existence of the reference path is known to the source node 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 present such
restrictions. restrictions.
This is exemplified in the Figure 1, where overlay reference This is exemplified in the Figure 1, where overlay reference
model from [RFC4208] is shown. model from [RFC4208] is shown.
Internet Draft draft-ietf-teas-lsp-diversity-00.txt Overlay Overlay
Network +----------------------------------+ Network
Overlay Overlay +---------+ | | +---------+
Network +----------------------------------+ Network | +----+ | | +-----+ +-----+ +-----+ | | +----+ |
+---------+ | | +---------+ | | | | UNI | | | | | | | | UNI | | | |
| +----+ | | +-----+ +-----+ +-----+ | | +----+ | | -+ EN1+-+-----+--+ CN1 +----+ CN2 +----+ CN3 +---+-----+-+ EN3+- |
| | | | UNI | | | | | | | | UNI | | | | | | | | +--+--+ | | | | | | +---+-| | |
| -+ EN1+-+-----+--+ CN1 +----+ CN2 +----+ CN3 +---+-----+-+ EN3+- | | +----+ | | | +--+--+ +--+--+ +--+--+ | | | +----+ |
| | | | +--+--+ | | | | | | +---+-| | | +---------+ | | | | | | | +---------+
| +----+ | | | +--+--+ +--+--+ +--+--+ | | | +----+ | | | | | | | |
+---------+ | | | | | | | +---------+ +---------+ | | +--+--+ | +--+--+ | | +---------+
| | | | | | | | +----+ | | | | | +-------+ +-----+ | +----+ |
+---------+ | | +--+--+ | +--+--+ | | +---------+ | | +-+--+ | | CN4 +---------------+ CN5 | | | | | |
| +----+ | | | | | +-------+ +-----+ | +----+ | | -+ EN2+-+-----+--+ | | +---+-----+-+ EN4+- |
| | +-+--+ | | CN4 +---------------+ CN5 | | | | | | | | | | UNI | +-----+ +-----+ | UNI | | | |
| -+ EN2+-+-----+--+ | | +---+-----+-+ EN4+- | | +----+ | | | | +----+ |
| | | | UNI | +-----+ +-----+ | UNI | | | | +---------+ +----------------------------------+ +---------+
| +----+ | | | | +----+ | Overlay Core Network Overlay
+---------+ +----------------------------------+ +---------+ Network Network
Overlay Core Network Overlay
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
skipping to change at page 5, line 4 skipping to change at page 5, line 4
devices, as depicted for EN2 in Figure 1. For the dual-homing devices, as depicted for EN2 in Figure 1. For the dual-homing
case, it is possible to establish two different UNI connections case, it is possible to establish two different UNI connections
from the same source EN device to the same destination EN device. from the same source EN device to the same destination EN device.
For example, two connections from EN2 to EN3 may use the two UNI For example, two connections from EN2 to EN3 may use the two UNI
links EN2-CN1 and EN2-CN4. To avoid single points of failure links EN2-CN1 and EN2-CN4. To avoid single points of failure
within the provider network, it is necessary to also ensure path within the provider network, it is necessary to also ensure path
(LSP) diversity within the core network. (LSP) diversity within the core network.
In a UNI network such as that shown in Figure 1, the CNs In a UNI network such as that shown in Figure 1, the CNs
typically perform path computation. Information sharing across typically perform path computation. Information sharing across
Internet Draft draft-ietf-teas-lsp-diversity-00.txt
the UNI boundary is restricted based on the policy rules imposed the UNI boundary is restricted based on the policy rules imposed
by the core network. Typically, the core network topology by the core network. Typically, the core network topology
information is not exposed to the ENs. In the network shown in information is not exposed to the ENs. In the network shown in
Figure 1, consider a use case where an LSP from EN2 to EN4 needs Figure 1, consider a use case where an LSP from EN2 to EN4 needs
to be SRLG diverse from an LSP from EN1 to EN3. In this case, EN2 to be SRLG diverse from an LSP from EN1 to EN3. In this case, EN2
may not know SRLG attributes of the EN1- EN3 LSP and hence cannot may not know SRLG attributes of the EN1- EN3 LSP and hence cannot
construct an XRO to exclude these SRLGs. In this example EN2 construct an XRO to exclude these SRLGs. In this example EN2
cannot use the procedures described in [RFC4874]. Similarly, an cannot use the procedures described in [RFC4874]. Similarly, an
LSP from EN2 to EN3 traversing CN1 needs to be diverse from an LSP from EN2 to EN3 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
skipping to change at page 5, line 52 skipping to change at page 5, line 49
- 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 tunnel
is rerouted. is 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 Resource ReserVation
Protocol (RSVP) tunnel/ LSP Forwarding Equivalence Class (FEC) as Protocol (RSVP) tunnel/ LSP Forwarding Equivalence Class (FEC) as
the identifier. the identifier. LSP FEC uniquely identifies an LSP in the network
and comprises of the following fields: IPv4 tunnel sender
Internet Draft draft-ietf-teas-lsp-diversity-00.txt address, IPv4 tunnel end point address, Tunnel ID, LSP ID, and
Extended Tunnel ID. These fields are defined in [RFC3209],
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 using Figure 1. Suppose a tunnel from EN2 to EN4 needs to be
diverse with respect to a tunnel from EN1 to EN3. The tunnel FEC diverse with respect to a tunnel from EN1 to EN3. The tunnel FEC
of the EN1-EN3 tunnel is FEC1, where FEC1 is defined by the tuple of the EN1-EN3 tunnel is FEC1, where FEC1 is defined by the tuple
(tunnel-id = T1, source address = EN1.ROUTE Identifier (RID), (tunnel-id = T1, source address = EN1.ROUTE Identifier (RID),
destination address = EN3.RID, extended tunnel-id = EN1.RID). destination address = EN3.RID, extended tunnel-id = EN1.RID).
Similarly, tunnel FEC of the EN2-EN3 tunnel is FEC2, where FEC2 Similarly, tunnel FEC of the EN2-EN3 tunnel is FEC2, where FEC2
is defined by the tuple (tunnel-id = T2, source address = is defined by the tuple (tunnel-id = T2, source address =
EN2.RID, destination address = EN4.RID, extended tunnel-id = EN2.RID, destination address = EN4.RID, extended tunnel-id =
skipping to change at page 7, line 5 skipping to change at page 8, line 5
strict confidentiality about all path and topology information. strict confidentiality about all path and topology information.
The first LSP is signaled by the source with ERO {A, B, loose Dst} The first LSP is signaled by the source with ERO {A, B, loose Dst}
and is set up with the path {Src, A, B, U, V, W, Dst}. However, and is set up with the path {Src, A, B, U, V, W, Dst}. However,
when sending the RRO out of Domain 2, node U would normally strip when sending the RRO out of Domain 2, node U would normally strip
the path and replace it with a loose hop to the destination. With the path and replace it with a loose hop to the destination. With
this limited information, the source is unable to include enough this limited information, the source is unable to include enough
detail in the ERO of the second LSP to avoid it taking, for detail in the ERO of the second LSP to avoid it taking, for
example, the path {Src, C, D, X, V, W, Dst} for path-disjointness. example, the path {Src, C, D, X, V, W, Dst} for path-disjointness.
Internet Draft draft-ietf-teas-lsp-diversity-00.txt
--------------------- ----------------------------- --------------------- -----------------------------
| Domain 1 | | Domain 2 | | Domain 1 | | Domain 2 |
| | | | | | | |
| --- --- | | --- --- --- | | --- --- | | --- --- --- |
| | A |--| B |--+--+--| U |--| V |---| W | | | | A |--| B |--+--+--| U |--| V |---| W | |
| / --- --- | | --- --- --- \ | | / --- --- | | --- --- --- \ |
| ---/ | | / / \--- | | ---/ | | / / \--- |
| |Src| | | / / |Dst| | | |Src| | | / / |Dst| |
| ---\ | | / / /--- | | ---\ | | / / /--- |
| \ --- --- | | --- / --- / --- / | | \ --- --- | | --- / --- / --- / |
skipping to change at page 8, line 4 skipping to change at page 9, line 4
the entity that originated the Path-Key, for example the LSR that the entity that originated the Path-Key, for example the LSR that
inserted the Path-Key in the RRO or a management system. inserted the Path-Key in the RRO or a management system.
1.3. Network-Assigned Identifier 1.3. Network-Assigned Identifier
There are scenarios in which the network provides diversity- There are scenarios in which the network provides diversity-
related information for a service that allows the client device related information for a service that allows the client device
to include this information in the signaling message. If the to include this information in the signaling message. If the
Shared Resource Link Group (SRLG) identifier information is both Shared Resource Link Group (SRLG) identifier information is both
available and shareable (by policy) with the ENs, the procedure available and shareable (by policy) with the ENs, the procedure
Internet Draft draft-ietf-teas-lsp-diversity-00.txt
defined in [DRAFT-SRLG-RECORDING] can be used to collect SRLG defined in [DRAFT-SRLG-RECORDING] can be used to collect SRLG
identifiers associated with an LSP (LSP1). When a second LSP identifiers associated with an LSP (LSP1). When a second LSP
(LSP2) needs to be diverse with respect to LSP1, the EN (LSP2) needs to be diverse with respect to LSP1, the EN
constructing the RSVP signaling message for setting up LSP2 can constructing the RSVP signaling message for setting up LSP2 can
insert the SRLG identifiers associated with LSP1 as diversity insert the SRLG identifiers associated with LSP1 as diversity
constraints into the XRO using the procedure described in constraints into the XRO using the procedure described in
[RFC4874]. However, if the core network SRLG identifiers are [RFC4874]. However, if the core network SRLG identifiers are
either not available or not shareable with the ENs based on either not available or not shareable with the ENs based on
policies enforced by core network, existing mechanisms cannot be policies enforced by core network, existing mechanisms cannot be
used. used.
skipping to change at page 9, line 4 skipping to change at page 10, line 4
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 PAS and the associated SRLG information can be distributed
within the core network by an Interior Gateway Protocol (IGP) or within the core network by an Interior Gateway Protocol (IGP) or
Internet Draft draft-ietf-teas-lsp-diversity-00.txt
by other means such as configuration. They can then be utilized by other means such as configuration. They can then be utilized
by other CNs when other ENs are requesting paths to be setup that by other CNs when other ENs are requesting paths to be setup that
would require path/connection diversity. In the VPN case, this would require path/connection diversity. In the VPN case, this
information is distributed on a VPN basis and contains a PAS information is distributed on a VPN basis and contains a PAS
identifier, CN addresses and SRLG information. In this way, on a identifier, CN addresses and SRLG information. In this way, on a
VPN basis, the core network can have additional opaque records VPN basis, the core network can have additional opaque records
for the PAS values for various Paths along with the SRLG list for the PAS values for various Paths along with the SRLG list
associated with the Path. This information is internal to the associated with the Path. This information is internal to the
core network and is known only to the core network. core network and is known only to the core network.
skipping to change at page 10, line 5 skipping to change at page 11, line 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
Internet Draft draft-ietf-teas-lsp-diversity-00.txt
XRO Type XRO Type
Type for IPv4 diversity XRO subobject (to be assigned by Type for IPv4 diversity XRO subobject (to be assigned by
IANA; suggested value: 37). IANA).
Length Length
The Length contains the total length of the subobject in The Length contains the total length of the subobject in
bytes, including the Type and Length fields. The Length is bytes, including the Type and Length fields. The Length is
variable, depending on the diversity identifier value. 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. Three values are defined in this required is identified. The following three DI type values
document: are defined in this document:
IPv4 Client Initiated Identifier 1 (to be assigned by DI Type value Definition
IANA) ------------- --------------------------------
IPv4 PCE Allocated Identifier 2 (to be assigned by 1 IPv4 Client Initiated Identifier
IANA) 2 IPv4 PCE Allocated Identifier
IPv4 Network Assigned Identifier 3 (to be assigned by 3 IPv4 Network Assigned Identifier 3
IANA)
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
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 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.
Internet Draft draft-ietf-teas-lsp-diversity-00.txt
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 0x08 = LSP ID to be ignored
This flag is only applicable when the diversity is This flag is only applicable when the diversity is
specified using the client-initiated identifier, the specified using the client-initiated identifier, the
skipping to change at page 12, line 4 skipping to change at page 13, line 4
(Note: the meaning of this flag may be modified by (Note: the meaning of this flag may be modified by
the value of the Attribute-flags.) 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 Diversity XRO subobject.
Resvd Resvd
Internet Draft draft-ietf-teas-lsp-diversity-00.txt
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.
IPv4 Diversity Identifier source address: IPv4 Diversity Identifier source address:
This field is set to the IPv4 address of the node that This field is set to the IPv4 address of the node that
assigns the diversity identifier. Depending on the 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:
skipping to change at page 13, line 5 skipping to change at page 13, line 42
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 is
encoded as follows: encoded as follows:
Internet Draft draft-ietf-teas-lsp-diversity-00.txt 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 14, line 5 skipping to change at page 15, line 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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 node identified by
the "IPv4 Diversity Identifier source address" field of the "IPv4 Diversity Identifier source address" field of
the diversity XRO subobject assigns the PAS value. the diversity XRO subobject assigns the PAS value.
Internet Draft draft-ietf-teas-lsp-diversity-00.txt
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 Diversity Identifier source address (cont.) | | IPv6 Diversity Identifier source address (cont.) |
skipping to change at page 14, line 38 skipping to change at page 15, line 36
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 IPv6 diversity XRO subobject (to be assigned by Type for IPv6 diversity XRO subobject (to be assigned by
IANA; suggested value: 38). IANA).
Length Length
The Length contains the total length of the subobject in The Length contains the total length of the subobject in
bytes, including the Type and Length fields. The Length is bytes, including the Type and Length fields. The Length is
variable, depending on the diversity identifier value. variable, depending on the diversity identifier value.
Attribute Flags (A-Flags): Attribute Flags (A-Flags):
As defined in Section 2.1.1 for the IPv4 counterpart. As defined in Section 2.1.1 for the IPv4 counterpart.
Internet Draft draft-ietf-teas-lsp-diversity-00.txt
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 DI Types associated with IPv6 addresses are defined, The three DI Types associated with IPv6 addresses are
defined,
as follows: as follows:
IPv6 Client Initiated Identifier 4 (to be assigned by DI Type value Definition
IANA) ------------- --------------------------------
IPv6 PCE Allocated Identifier 5 (to be assigned by 4 IPv6 Client Initiated Identifier
IANA) 5 IPv6 PCE Allocated Identifier
IPv6 Network Assigned Identifier 6 (to be assigned by 6 IPv6 Network Assigned Identifier
IANA)
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.
IPv4 Diversity Identifier source address: IPv4 Diversity Identifier source address:
This field is set to IPv6 address of the node that assigns This field is set to IPv6 address of the node that assigns
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.
Internet Draft draft-ietf-teas-lsp-diversity-00.txt
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 is
encoded as follows: 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.) |
skipping to change at page 17, line 5 skipping to change at page 18, line 5
encoded as follows: 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].
Internet Draft draft-ietf-teas-lsp-diversity-00.txt
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 is
encoded as follows: 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 multiple PAS identifiers, an EN
may include multiple Diversity XRO subobjects each with a may include multiple Diversity XRO subobjects each with a
different PAS identifier. However, all Diversity subobjects in an different PAS identifier. However, all Diversity subobjects in an
XRO SHOULD contain the same Diversity Identifier Type. If a Path XRO SHOULD contain the same Diversity Identifier Type. If a Path
message contains an XRO with Diversity subobjects with multiple message contains an XRO with Diversity subobjects with multiple
Diversity Identifier Types, the processing node SHOULD return a Diversity Identifier Types, the processing node SHOULD return a
PathErr with the error code "Routing Problem" (24) and error sub- PathErr with the error code "Routing Problem" (24) and error sub-
code "XRO Too Complex" (68). code "XRO Too Complex" (68).
It shall be noted that only those nodes in the domain that
perform path computation (typically the domain ingress node),
shall process the diversity information signaled in the Diversity
subobjects. The transit nodes in a domain and the domain egress
node 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 SHOULD 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 SHOULD be ignored for the processing node. The
processing node is the node performing path calculation. processing node is the node performing path calculation.
Internet Draft draft-ietf-teas-lsp-diversity-00.txt
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 SHOULD be ignored for the penultimate node on
the path of the LSP being established. the path of the LSP being established.
o The "LSP ID to be ignored" flag is only defined for the o The "LSP ID to be ignored" flag is only defined for the
"IPv4/ IPv6 Client Initiated Identifier" diversity types. "IPv4/ IPv6 Client Initiated Identifier" diversity types.
When the Diversity Identifier Type is set to any other When the Diversity Identifier Type is set to any other
value, this flag SHOULD NOT be set on transmission and value, this flag SHOULD NOT be set on transmission and
MUST be ignored in processing. When this flag is not set, MUST be ignored in processing. When this flag is not set,
the lsp-id is not ignored and the exclusion applies only the lsp-id is not ignored and the exclusion applies only
skipping to change at page 18, line 30 skipping to change at page 19, line 32
processing node proceeds as follows. processing node proceeds as follows.
- "IPv4/ IPv6 Client Initiated Identifiers" Diversity Type: the - "IPv4/ IPv6 Client Initiated Identifiers" Diversity Type: the
processing node MUST ensure that any path calculated for the processing node MUST ensure that any path calculated for the
signaled LSP is diverse from the RSVP TE FEC identified by the signaled LSP is diverse from the RSVP TE FEC identified by the
client in the XRO subobject. client in the XRO subobject.
- "IPv4/ IPv6 PCE Allocated Identifiers" Diversity Type: the - "IPv4/ IPv6 PCE Allocated Identifiers" Diversity Type: the
processing node MUST ensure that any path calculated for the processing node MUST ensure that any path calculated for the
signaled LSP is diverse from the route identified by the Path- signaled LSP is diverse from the route identified by the Path-
Key. The processing node MAY use the PCE identified by the IPv4 Key. The processing node MAY use the PCE identified by the
Diversity Identifier source address in the subobject for route IPv4/ IPv6 Diversity Identifier source address in the subobject
computation. The processing node MAY use the Path-Key for route computation. The processing node MAY use the Path-Key
resolution mechanisms described in [RFC5553]. resolution mechanisms described in [RFC5553].
- "IPv4/ IPv6 Network Assigned Identifiers" Diversity Type: the - "IPv4/ IPv6 Network Assigned Identifiers" Diversity Type: the
processing node MUST ensure that the path calculated for the processing node MUST ensure that the path calculated for the
signaled LSP respects the requested PAS exclusion. . 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 with respect to the
excluded path referenced by the subobject, including local excluded path referenced by the subobject, including local
resources. 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 SHOULD 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, suggested value: 13) for the signaled LSP. IANA) for the signaled LSP.
Internet Draft draft-ietf-teas-lsp-diversity-00.txt
- 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 - "IPv4/ IPv6 Client Initiated Identifiers" Diversity Type: the
skipping to change at page 19, line 40 skipping to change at page 20, line 42
- 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 with respect to the excluded path 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 SHOULD 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, suggest value: 14) 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 - An excluded path referenced in the XRO subobject becomes
known to the processing node, or a change in the excluded path known to the processing node, or a change in the excluded path
becomes known to the processing node, the processing node becomes known to the processing node, the processing node
SHOULD re-evaluate the exclusion and diversity constraints SHOULD re-evaluate the exclusion and diversity constraints
requested by the diverse LSP to determine whether they are requested by the diverse LSP to determine whether they are
still satisfied. still satisfied.
- If the requested exclusion constraints for the diverse LSP are - If the requested exclusion constraints for the diverse LSP are
no longer satisfied and an alternative path for the diverse LSP no longer satisfied and an alternative path for the diverse LSP
that can satisfy those constraints exists, then: that can satisfy those constraints exists, then:
Internet Draft draft-ietf-teas-lsp-diversity-00.txt
o If the L-flag was not set in the original exclusion, the o If the L-flag was not 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 with the error code "Routing Problem" (24) and diverse LSP with the error code "Routing Problem" (24) and
error sub-code "Route blocked by Exclude Route" (67). The error sub-code "Route blocked by Exclude Route" (67). The
PSR flag SHOULD NOT be set. A source node receiving a PSR flag SHOULD NOT be set. A source node receiving a
PathErr message with this error code and sub-code PathErr message with this error code and sub-code
combination SHOULD take appropriate actions to migrate the combination SHOULD take appropriate actions to migrate the
compliant path. compliant path.
o If the L-flag was set in the original exclusion, the o If the L-flag was set in the original exclusion, the
processing node SHOULD send a PathErr message for the processing node SHOULD send a PathErr message for the
diverse LSP with the error code "Notify Error" (25) and a diverse LSP with the error code "Notify Error" (25) and a
new error sub-code "compliant path exists" (value: to be new error sub-code "compliant path exists" (value: to be
assigned by IANA, suggest value: 15). The PSR flag SHOULD assigned by IANA). The PSR flag SHOULD NOT be set. A
NOT be set. A source node receiving a PathErr message with source node receiving a PathErr message with this error
this error code and sub-code combination MAY signal a new code and sub-code combination MAY signal a new LSP to
LSP to migrate the compliant path. migrate the compliant path.
- If the requested exclusion constraints for the diverse LSP are - If the requested exclusion constraints for the diverse LSP are
no longer satisfied and no alternative path for the diverse LSP no longer satisfied and no alternative path for the diverse LSP
that can satisfy those constraints exists, then: that can satisfy those constraints exists, then:
o If the L-flag was not set in the original exclusion, the o If the L-flag was not 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 with the error code "Routing Problem" (24) and diverse LSP with the error code "Routing Problem" (24) and
error sub-code "Route blocked by Exclude Route" (67). The error sub-code "Route blocked by Exclude Route" (67). The
PSR flag SHOULD be set. PSR flag SHOULD be set.
o If the L-flag was set in the original exclusion, the o If the L-flag was set in the original exclusion, the
processing node SHOULD send a PathErr message for the processing node SHOULD send a PathErr message for the
diverse LSP with the error code error code "Notify Error" diverse LSP with the error code error code "Notify Error"
(25) and error sub-code "Failed to respect Exclude Route" (25) and error sub-code "Failed to respect Exclude Route"
(value: to be assigned by IANA, suggest value: 14). The (value: to be assigned by IANA). The PSR flag SHOULD NOT
PSR flag SHOULD NOT be set. be set.
The following rules apply whether or not the L-flag is set: The following rules apply whether or not the L-flag is set:
- A source node receiving a PathErr message with the error code - A source node receiving a PathErr message with the error code
"Notify Error" (25) and error sub-codes "Route of XRO tunnel "Notify Error" (25) and error sub-codes "Route of XRO tunnel
identifier unknown" or "Failed to respect Exclude Route" MAY identifier unknown" or "Failed to respect Exclude Route" MAY
take no action. take no action.
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
Internet Draft draft-ietf-teas-lsp-diversity-00.txt
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
document. In this case, the IPv4 EXRS format is as follows: document. In this case, the IPv4 EXRS format is 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| Type | Length | Reserved | |L| Type | Length | Reserved |
skipping to change at page 22, line 5 skipping to change at page 23, line 11
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 Diversity Identifier source address (cont.) | | IPv6 Diversity Identifier source address (cont.) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 Diversity Identifier source address (cont.) | | IPv6 Diversity Identifier source address (cont.) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Diversity Identifier Value | | Diversity Identifier Value |
// ... // // ... //
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Internet Draft draft-ietf-teas-lsp-diversity-00.txt
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. 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.
skipping to change at page 22, line 45 skipping to change at page 24, line 7
identifies the next abstract node. 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
defined in this document and summarized in this section.
4.1. New XRO subobject types 4.1. New XRO subobject types
IANA registry: RSVP PARAMETERS IANA registry: RSVP PARAMETERS
Subsection: Class Names, Class Numbers, and Class Types Subsection: Class Names, Class Numbers, and Class Types
This document introduces two new subobjects for the EXCLUDE_ROUTE This document defines two new subobjects for the EXCLUDE_ROUTE
object [RFC4874], C-Type 1. object [RFC4874], C-Type 1. (see:
http://www.iana.org/assignments/rsvp-parameters/rsvp-
Internet Draft draft-ietf-teas-lsp-diversity-00.txt parameters.xhtml#rsvp-parameters-94)
Subobject Description Subobject Type Subobject Description Subobject Type
-------------- ------------------------ --------------
--------------------- IPv4 Diversity subobject TBA1
IPv4 Diversity subobject To be assigned by IANA IPv6 Diversity subobject TBA2
(suggested value: 37)
IPv6 Diversity subobject To be assigned by IANA
(suggested value: 38)
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. subobjects. (see: http://www.iana.org/assignments/rsvp-
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 "Notify Error" (25) (see [RFC3209]) the following For Error Code "Notify Error" (25) (see [RFC3209]) the following
sub-codes are defined. sub-codes are defined. (see:
http://www.iana.org/assignments/rsvp-parameters/rsvp-
Sub-code Value parameters.xhtml#rsvp-parameters-105)
-------- ----- +-------------+----------------------------+---------------+
| Error Value | Description | Reference |
Route of XRO To be assigned by IANA. | Sub-codes | | |
tunnel identifier unknown Suggested Value: 13. +-------------+----------------------------+---------------+
| TBA3 | Route of XRO tunnel | This document |
Failed to respect Exclude Route To be assigned by IANA. | | identifier unknown | |
Suggested Value: 14. | TBA4 | Failed to respect | This document |
| | Exclude Route | |
Compliant path exists To be assigned by IANA. | TBA5 | Compliant path exists | This document |
Suggested Value: 15. +-------------+----------------------------+---------------+
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.
Internet Draft draft-ietf-teas-lsp-diversity-00.txt
6. References 6. References
6.1. Normative References 6.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan,
V., and G. Swallow, "RSVP-TE: Extensions to RSVP for V., and G. Swallow, "RSVP-TE: Extensions to RSVP for
LSP Tunnels", RFC 3209, December 2001. LSP Tunnels", RFC 3209, December 2001.
[RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching
(GMPLS) Signaling Resource ReserVation Protocol-Traffic (GMPLS) Signaling Resource ReserVation Protocol-Traffic
Engineering (RSVP-TE) Extensions", RFC 3473, January Engineering (RSVP-TE) Extensions", RFC 3473, January
2003. 2003.
[RFC4874] Lee, CY., Farrel, A., and S. De Cnodder, "Exclude [RFC4874] Lee, CY., Farrel, A., and S. De Cnodder, "Exclude
Routes - Extension to Resource ReserVation Protocol- Routes - Extension to Resource ReserVation Protocol-
Traffic Engineering (RSVP-TE)", RFC 4874, June 2007. Traffic Engineering (RSVP-TE)", RFC 4874, April 2007.
[RFC5553] Farrel, A., Ed., Bradford, R., and JP. Vasseur, [RFC5553] Farrel, A., Ed., Bradford, R., and JP. Vasseur,
"Resource Reservation Protocol (RSVP) Extensions for Path Key "Resource Reservation Protocol (RSVP) Extensions for Path Key
Support", RFC 5553, May 2009. Support", RFC 5553, May 2009.
6.2. Informative References 6.2. Informative References
[RFC4208] Swallow, G., Drake, J., Ishimatsu, H., and Y. Rekhter, [RFC4208] Swallow, G., Drake, J., Ishimatsu, H., and Y. Rekhter,
"Generalized Multiprotocol Label Switching (GMPLS) "Generalized Multiprotocol Label Switching (GMPLS)
User-Network Interface (UNI): Resource ReserVation User-Network Interface (UNI): Resource ReserVation
Protocol-Traffic Engineering (RSVP-TE) Support for the Protocol-Traffic Engineering (RSVP-TE) Support for the
Overlay Model", RFC 4208, October 2005. Overlay Model", RFC 4208, October 2005.
[RFC4920] Farrel, A., Ed., Satyanarayana, A., Iwata, A., Fujita, [RFC4920] Farrel, A., Ed., Satyanarayana, A., Iwata, A., Fujita,
N., and G. Ash, "Crankback Signaling Extensions for N., and G. Ash, "Crankback Signaling Extensions for
MPLS and GMPLS RSVP-TE", RFC 4920, July 2007. MPLS and GMPLS RSVP-TE", RFC 4920, July 2007.
[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, June 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-ccamp-rsvp-te-srlg-collect.txt, Information", draft-ietf-teas-rsvp-te-srlg-collect-00,
work in progress. work in progress.
Internet Draft draft-ietf-teas-lsp-diversity-00.txt
[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.
[RFC5253] Takeda, T., Ed., "Applicability Statement for Layer 1 [RFC5253] Takeda, T., Ed., "Applicability Statement for Layer 1
Virtual Private Network (L1VPN) Basic Mode", RFC 5253, Virtual Private Network (L1VPN) Basic Mode", RFC 5253,
skipping to change at page 26, line 4 skipping to change at page 27, line 26
Don Fedyk Don Fedyk
Hewlett-Packard Hewlett-Packard
Email: don.fedyk@hp.com Email: don.fedyk@hp.com
Clarence Filsfils Clarence Filsfils
Cisco Systems, Inc. Cisco Systems, Inc.
Email: cfilsfil@cisco.com Email: cfilsfil@cisco.com
Xihua Fu Xihua Fu
ZTE ZTE
Internet Draft draft-ietf-teas-lsp-diversity-00.txt
Email: fu.xihua@zte.com.cn Email: fu.xihua@zte.com.cn
Gabriele Maria Galimberti Gabriele Maria Galimberti
Cisco Systems Cisco Systems
Email: ggalimbe@cisco.com Email: ggalimbe@cisco.com
Ori Gerstel Ori Gerstel
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
Rudiger 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 Alcatel-Lucent
Email: Lieven.Levrau@alcatel-lucent.com Email: Lieven.Levrau@alcatel-lucent.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
skipping to change at page 27, line 4 skipping to change at page 28, line 24
Yuji Tochio Yuji Tochio
Fujitsu Fujitsu
Email: tochio@jp.fujitsu.com Email: tochio@jp.fujitsu.com
Xian Zhang Xian Zhang
Huawei Technologies Huawei Technologies
Email: zhang.xian@huawei.com Email: zhang.xian@huawei.com
Authors' Addresses Authors' Addresses
Internet Draft draft-ietf-teas-lsp-diversity-00.txt
Zafar Ali Zafar Ali
Cisco Systems. Cisco Systems.
Email: zali@cisco.com Email: zali@cisco.com
Dieter Beller Dieter Beller
Alcatel-Lucent Alcatel-Lucent
Email: Dieter.Beller@alcatel-lucent.com Email: Dieter.Beller@alcatel-lucent.com
George Swallow George Swallow
 End of changes. 56 change blocks. 
169 lines changed or deleted 127 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/