draft-ietf-teas-lsp-diversity-07.txt   draft-ietf-teas-lsp-diversity-08.txt 
TEAS Working Group Zafar Ali, Ed. TEAS Working Group Zafar Ali, Ed.
Internet Draft George Swallow, Ed. Internet Draft George Swallow, Ed.
Intended status: Standard Track Cisco Systems Intended status: Standard Track Cisco Systems
Updates RFC4874 F. Zhang, Ed. Updates RFC4874 F. Zhang, Ed.
Expires: September 28, 2017 Huawei Expires: January 3, 2018 Huawei
D. Beller, Ed. D. Beller, Ed.
Nokia Nokia
March 27, 2017 July 2, 2017
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-07.txt draft-ietf-teas-lsp-diversity-08.txt
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
skipping to change at page 2, line 8 skipping to change at page 2, line 8
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with carefully, as they describe your rights and restrictions with
respect to this document. Code Components extracted from this respect to this document. Code Components extracted from this
document must include Simplified BSD License text as described in document must include Simplified BSD License text as described in
Section 4.e of the Trust Legal Provisions and are provided without Section 4.e of the Trust Legal Provisions and are provided without
warranty as described in the Simplified BSD License. warranty as described in the Simplified BSD License.
Abstract Abstract
Resource ReserVation Protocol-Traffic Engineering provides support Resource ReserVation Protocol-Traffic Engineering provides support
for the communication of exclusion information during labeled switch for the communication of exclusion information during label switched
path setup. This document specifies three new route exclusion types. path (LSP) setup. This document specifies two new diversity
The new types include exclusions based on LSP, PCE, and network subobjects for the RSVP XRO and EXRS subobjects. Three different
assigned identifiers. mechanisms are supported how LSP diversity can be accomplished in
the provider or core network: the signaled diversity type, indicates
whether diversity is based on client, path computation engine (PCE),
or network assigned identifiers.
The solution described in this document is based on the assumption
that LSPs are requested sequentially, i.e., the time period between
the LSP setup requests for the two LSPs may be longer (days, weeks,
months). Re-routing the first LSP that may have existed for a longer
period of time is not considered.
Conventions used in this document Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
Table of Contents Table of Contents
1. Introduction..................................................2 1. Introduction..................................................3
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.2. Diversity EXRS Subobject................................15 2.2. Diversity EXRS Subobject................................15
2.3. Processing rules for the Diversity XRO and EXRS 2.3. Processing rules for the Diversity XRO and EXRS
subobjects..............................................16 subobjects..............................................16
3. Security Considerations......................................20 3. Security Considerations......................................20
4. IANA Considerations..........................................20 4. IANA Considerations..........................................20
skipping to change at page 5, line 32 skipping to change at page 5, line 35
required is/are identified by an "identifier". The type of required is/are identified by an "identifier". The type of
identifier to use is highly dependent on the networking identifier to use is highly dependent on the networking
deployment scenario; it could be client-initiated, allocated by deployment scenario; it could be client-initiated, allocated by
the (core) network or managed by a PCE. This document defines the (core) network or managed by a PCE. This document defines
three different types of identifiers corresponding to these three three different types of identifiers corresponding to these three
cases: a client initiated identifier, a PCE allocated Identifier cases: a client initiated identifier, a PCE allocated Identifier
and CN ingress node (UNI-N) allocated Identifier. and CN ingress node (UNI-N) allocated Identifier.
1.1. Client-Initiated Identifier 1.1. Client-Initiated Identifier
There are scenarios in which the ENs have the following The following fields MUST be used to represent the client-
requirements for the diversity identifier: controlled identifier: IPv4/IPv6 tunnel sender address,
IPv4/IPv6 tunnel endpoint address, Tunnel ID, and Extended
- The identifier is controlled by the client side and is Tunnel ID. The client MAY also include LSP ID to identify a
specified as part of the service request. specific LSP within the tunnel. These fields are defined in
[RFC3209], sections 4.6.1.1 and 4.6.2.1.
- Both client and server understand the identifier.
- It is necessary to be able to reference the identifier even if
the LSP referenced by it is not yet signaled.
- The identifier is to be stable for a long period of time.
- The identifier is to be stable even when the referenced LSP is
rerouted.
These requirements are met by using the LSP identifier. The LSP
identifier uniquely identifies an LSP in the network and
comprises of the following fields: IPv4/IPv6 tunnel sender
address, IPv4/IPv6 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.
The usage of the client-initiated identifier is illustrated by The usage of the client-initiated identifier is illustrated by
Figure 1. Suppose a LSP from EN2 to EN4 needs to be diverse with Figure 1. Suppose a LSP from EN2 to EN4 needs to be diverse with
respect to a LSP from EN1 to EN3. The LSP identifier of the EN1- respect to a LSP from EN1 to EN3. The LSP identifier of the EN1-
EN3 LSP is LSP-IDENTIFIER1, where LSP-IDENTIFIER1 is defined by EN3 LSP is LSP-IDENTIFIER1, where LSP-IDENTIFIER1 is defined by
the tuple (tunnel-id = T1, LSP ID = L1, source address = the tuple (tunnel-id = T1, LSP ID = L1, source address =
EN1.ROUTE Identifier (RID), destination address = EN3.RID, EN1.ROUTE Identifier (RID), destination address = EN3.RID,
extended tunnel-id = EN1.RID). Similarly, LSP identifier of the extended tunnel-id = EN1.RID). Similarly, LSP identifier of the
EN2-EN3 LSP is LSP-IDENTIFIER2, where LSP-IDENTIFIER12 is defined EN2-EN3 LSP is LSP-IDENTIFIER2, where LSP-IDENTIFIER12 is defined
by the tuple (tunnel-id = T2, LSP IS = L1, source address = by the tuple (tunnel-id = T2, LSP IS = L1, source address =
EN2.RID, destination address = EN4.RID, extended tunnel-id = EN2.RID, destination address = EN4.RID, extended tunnel-id =
EN2.RID). The EN1-EN3 LSP is signaled with an exclusion EN2.RID). The EN1-EN3 LSP is signaled with an exclusion
requirement from LSP-IDENTIFIER2, and the EN2-EN3 LSP is signaled requirement from LSP-IDENTIFIER2, and the EN2-EN3 LSP is signaled
with an exclusion requirement from LSP-IDENTIFIER1. In order to with an exclusion requirement from LSP-IDENTIFIER1. In order to
maintain diversity between these two connections within the core maintain diversity between these two connections within the core
network, it is assumed that the core network implements Crankback network, the core network SHOULD implement Crankback Signaling
Signaling [RFC4920]. Note that crankback signaling is known to [RFC4920]. Note that crankback signaling is known to lead to
lead to slower setup times and sub-optimal paths under some slower setup times and sub-optimal paths under some circumstances
circumstances as described by [RFC4920]. 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 at network node(s) 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
skipping to change at page 13, line 36 skipping to change at page 13, line 36
PCE Allocated Identifier", the value MUST be set to the PCE Allocated Identifier", the value MUST be set to the
IPv4/ IPv6 address of the node that assigned the Path Key IPv4/ IPv6 address of the node that assigned the Path Key
identifier and that can return an expansion of the Path identifier and that can return an expansion of the Path
Key or use the Path Key as exclusion in a path Key or use the Path Key as exclusion in a path
computation. The Path Key is defined in [RFC5553]. The computation. The Path Key is defined in [RFC5553]. The
PCE-ID is carried in the Identifier Source Address field PCE-ID is carried in the Identifier Source Address field
of the subobject. of the subobject.
o When the diversity identifier type is set to "IPv4/ IPv6 o When the diversity identifier type is set to "IPv4/ IPv6
Network Assigned Identifier", the value MUST be set to the Network Assigned Identifier", the value MUST be set to the
IPv4/ IPv6 address of the node publishing the Path IPv4/ IPv6 address of the node allocating the Path
Affinity Set (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 "Client When the diversity identifier type is set to "Client
Initiated Identifier" in IPv4 Diversity XRO subobject, the Initiated Identifier" in IPv4 Diversity XRO subobject, the
diversity identifier value MUST be encoded as follows: diversity identifier value MUST be encoded as follows:
skipping to change at page 16, line 38 skipping to change at page 16, line 38
multiple Diversity XRO/ EXRS subobjects each with a different PAS multiple Diversity XRO/ EXRS subobjects each with a different PAS
identifier. However, all Diversity subobjects in an XRO/ EXRS identifier. However, all Diversity subobjects in an XRO/ EXRS
MUST contain the same Diversity Identifier Type. If a Path MUST contain the same Diversity Identifier Type. If a Path
message contains an XRO/ EXRS with multiple Diversity subobjects message contains an XRO/ EXRS with multiple Diversity subobjects
of different DI Types, the processing node MUST return a PathErr of different DI Types, the processing node MUST return a PathErr
with the error code "Routing Problem" (24) and error sub-code with the error code "Routing Problem" (24) and error sub-code
"XRO/ EXRS Too Complex" (68/ 69). "XRO/ EXRS Too Complex" (68/ 69).
If the processing node recognize the Diversity XRO/ EXRS If the processing node recognize the Diversity XRO/ EXRS
subobject but does not support the DI type, it MUST return a subobject but does not support the DI type, it MUST return a
PathErr with the error code TBA3 "Routing Problem" and error PathErr with the error code "Routing Problem" (24) and error sub-
value of "Unsupported Diversity Identifier Type". code "Unsupported Diversity Identifier Type" (TBA3).
The nodes in the domain that perform path computation SHOULD In case of DI type "Client Initiated Identifier", all nodes along
process the diversity information signaled in the XRO/ EXRS the path SHOULD process the diversity information signaled in the
Diversity subobjects. The transit nodes in a domain and the XRO/ EXRS Diversity subobjects to verify that the signaled
diversity constraint is satisfied. If a diversity violation is
detected, crankback signaling MAY be initiated.
In case of DI type "PCE Allocated Identifier" and "Network
Assigned Identifier", the nodes in the domain that perform path
computation SHOULD process the diversity information signaled in
the XRO/ EXRS Diversity subobjects. Typically, the ingress node
of a domain sends a path computation request from ingress node to
egress node including diversity constraints to a PCE or the
ingress node is capable to calculate the path for a new LSP from
ingress node to the egress node taking the diversity constraints
into account. The calculated path is then carried in the explicit
route object (ERO). Hence, the transit nodes in a domain and the
domain egress node SHOULD NOT process the signaled diversity domain egress node SHOULD NOT process the signaled diversity
information. While processing EXRS object, if a loose-hop information unless path computation is performed.
expansion results in the creation of another loose-hop in the
outgoing ERO, the processing node MAY include the EXRS in the While processing EXRS object, if a loose-hop expansion results in
newly created loose hop for further processing by downstream the creation of another loose-hop in the outgoing ERO, the
nodes. 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/ The attribute-flags affect the processing of the Diversity XRO/
EXRS subobject as follows: EXRS subobject as follows:
o When the "processing node exception" flag is set, the o When the "processing node exception" flag is set, the
exclusion MUST be ignored for the node processing the XRO exclusion MUST be ignored for the node processing the XRO
or EXRS subobject. or EXRS subobject.
o When the "destination node exception" flag is set, the o When the "destination node exception" flag is set, the
exclusion MUST be ignored for the destination node in exclusion MUST be ignored for the destination node in
skipping to change at page 20, line 19 skipping to change at page 20, line 31
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].
The diversity mechanism defined in this document, relies on the The diversity mechanism defined in this document, relies on the
new diversity subobject that is carried in the XRO or EXRS, new diversity subobject that is carried in the XRO or EXRS,
respectively. In section 7 of [RFC4874], it is stated that the respectively. In section 7 of [RFC4874], it is stated that the
XRO could be considered for removal from the Path message due to XRO could be considered for removal from the Path message due to
security concerns for example at administrative boundaries. In security concerns for example at administrative boundaries. In
this case, the diversity subobject would also be removed. Hence, this case, the diversity subobject would also be removed. Hence,
the diversity subobject must be kept while other subobjects may the diversity subobject MUST be kept while other subobjects may
be removed. be removed.
4. IANA Considerations 4. IANA Considerations
IANA is requested to administer the assignment of new values IANA is requested to administer the assignment of new values
defined in this document and summarized in this section. defined in this document and summarized in this section.
4.1. New XRO subobject types 4.1. New XRO subobject types
IANA registry: RSVP PARAMETERS IANA registry: RSVP PARAMETERS
 End of changes. 12 change blocks. 
46 lines changed or deleted 52 lines changed or added

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