draft-ietf-ccamp-lsp-diversity-01.txt   draft-ietf-ccamp-lsp-diversity-02.txt 
CCAMP Working Group Zafar Ali CCAMP Working Group Zafar Ali
Internet Draft George Swallow Internet Draft George Swallow
Intended status: Standard Track Clarence Filsfils Intended status: Standard Track Clarence Filsfils
Expires: August 17, 2013 Matt Hartley Expires: January 14, 2014 Matt Hartley
Ori Gerstel Ori Gerstel
Gabriele Maria Galimberti Gabriele Maria Galimberti
Cisco Systems Cisco Systems
Kenji Kumaki Kenji Kumaki
KDDI Corporation KDDI Corporation
Ruediger Kunze Ruediger Kunze
Deutsche Telekom AG Deutsche Telekom AG
Julien Meuric Julien Meuric
France Telecom Orange France Telecom Orange
February 18, 2013 July 15, 2013
Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Path Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Path
Diversity using Exclude Routes Diversity using Exclude Routes
draft-ietf-ccamp-lsp-diversity-01.txt draft-ietf-ccamp-lsp-diversity-02.txt
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six Internet-Drafts are draft documents valid for a maximum of six months
months and may be updated, replaced, or obsoleted by other documents and may be updated, replaced, or obsoleted by other documents at any
at any time. It is inappropriate to use Internet-Drafts as time. It is inappropriate to use Internet-Drafts as reference
reference material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 17, 2013. This Internet-Draft will expire on January 13, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with carefully, as they describe your rights and restrictions with respect
respect to this document. Code Components extracted from this to this document. Code Components extracted from this document must
document must include Simplified BSD License text as described in include Simplified BSD License text as described in Section 4.e of
Section 4.e of the Trust Legal Provisions and are provided without the Trust Legal Provisions and are provided without warranty as
warranty as described in the Simplified BSD License. described in the Simplified BSD License.
This document may contain material from IETF Documents or IETF Internet Draft draft-ietf-ccamp-lsp-diversity-02.txt
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
Abstract Abstract
RFC 4874 specifies methods by which route exclusions may be RFC 4874 specifies methods by which route exclusions may 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 signaling for additional route exclusions based document specifies signaling for additional route exclusions based
on Paths currently existing or expected to exist within the network. on Paths currently existing or expected to exist within the network.
Conventions used in this document Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
Table of Contents Table of Contents
1. Introduction ..................................................3 1. Introduction..................................................2
2. RSVP-TE signaling extensions ..................................5 2. RSVP-TE signaling extensions..................................4
2.1. Terminology .................................................5 2.1. Terminology...........................................5
2.2. Path XRO Subobjects .........................................5 2.2. Path XRO Subobjects...................................5
2.2.1. IPv4 Point-to-Point Path subobject ....................... 5 2.2.1. IPv4 Point-to-Point Path subobject....................... 5
2.2.2. IPv6 Point-to-Point Path subobject ....................... 9 2.2.2. IPv6 Point-to-Point Path subobject....................... 8
2.3. Processing rules for the Path XRO subobjects ..............10 2.3. Processing rules for the Path XRO subobjects..........9
2.4. Path EXRS Subobject ........................................13 2.4. Path EXRS Subobject..................................12
2.4.1. Processing Rules for the EXRS with Path subobject ....... 14 3. Security Considerations......................................13
3. Security Considerations .....................................14 4. IANA Considerations..........................................13
4. IANA Considerations .........................................14 4.1. New XRO subobject types..............................13
4.1. New XRO subobject types ....................................14 4.2. New EXRS subobject types.............................14
4.2. New EXRS subobject types ...................................15 4.3. New RSVP error sub-codes.............................14
4.3. New RSVP error sub-codes....................................15 5. Acknowledgements.............................................14
6. References...................................................14
Internet Draft draft-ietf-ccamp-lsp-diversity-01.txt 6.1. Normative References.................................14
6.2. Informative References...............................15
5. Acknowledgements .............................................15
6. References ...................................................15
6.1. Normative References .................................15
6.2. Informative References ...............................16
1. Introduction 1. Introduction
Path diversity is a well-known requirement from Service Providers. Path diversity is a well-known requirement from Service Providers.
Such diversity is required to ensure Label-Switched Path (LSPs) Such diversity is required to ensure Label-Switched Paths (LSPs)
may be established without sharing resources, thus greatly may be established without sharing resources, thus greatly
reducing the probability of simultaneous connection failures. reducing the probability of simultaneous connection failures.
Internet Draft draft-ietf-ccamp-lsp-diversity-02.txt
When route computation for paths that need to be diverse is When route computation for paths that need to be diverse is
performed at the LSP's source node, this requirement can be met by performed at the LSP's source node, this requirement can be met by
a local decision at that node. However, there are scenarios when a local decision at that node. However, there are scenarios when
route computations are performed by remote nodes, there is a need route computations are performed by remote nodes, thus there is a
for relevant diversity requirements to be communicated to those need for relevant diversity requirements to be communicated to
nodes. These include (but are not limited to): those nodes. These include (but are not limited to):
. LSPs with loose hops in the Explicit Route Object (ERO), e.g. . LSPs with loose hops in the Explicit Route Object (ERO), e.g.
inter-domain LSPs. inter-domain LSPs;
. Generalized Multi-Protocol Label Switching (GMPLS) User- . Generalized Multi-Protocol Label Switching (GMPLS) User-Network
Network Interface (UNI) where route computation may be Interface (UNI) where route computation may be performed by the
performed by the (server layer) core node [RFC4208]; (server layer) core node [RFC4208].
[RFC4874] introduced a means of specifying nodes and resources to [RFC4874] introduced a means of specifying nodes and resources to
be excluded from a route, using the eXclude Route Object (XRO) and be excluded from a route, using the eXclude Route Object (XRO) and
Explicit Exclusion Route Subobject (EXRS). Explicit Exclusion Route Subobject (EXRS).
[RFC4874] facilitates the calculation of diverse routes for LSPs [RFC4874] facilitates the calculation of diverse routes for LSPs
based on known properties of those paths including addresses of based on known properties of those paths including addresses of
links and nodes traversed, and Shared Risk Link Groups (SRLGs) of links and nodes traversed, and Shared Risk Link Groups (SRLGs) of
traversed links. This requires that these properties of the traversed links. This requires that these properties of the
path(s) from which diversity is required be known to the source path(s) from which diversity is required be known to the source
node which initiates signaling. However, there are circumstances node which initiates signaling. However, there are circumstances
under which this may not be possible or desirable, including (but under which this may not be possible or desirable, including (but
not limited to): not limited to):
. Exclusion of a path which does not originate, terminate or . Exclusion of a path which does not originate, terminate or
traverse the source node signaling the diverse LSP, in which traverse the source node signaling the diverse LSP, in which
case the addresses and SRLGs of the path from which diversity case the addresses and SRLGs of the path from which diversity
is required are unknown to the source node. is required are unknown to the source node.
. Exclusion of a path which, while known at the source node of . Exclusion of a path which, while known at the source node of
the diverse LSP, has incomplete or unavailable route the diverse LSP, has incomplete or unavailable route
information, e.g. due to confidentiality of the path information, e.g. due to confidentiality of the path
Internet Draft draft-ietf-ccamp-lsp-diversity-01.txt
attributes. In other words, the scenario in which the reference attributes. In other words, the scenario in which the reference
path is hosted by the source / requesting node but the path is hosted by the source / requesting node but the
properties required to construct an XRO object are not known to properties required to construct an XRO object are not known to
source / requesting node. Inter-domain and GMPLS overlay source / requesting node. Inter-domain and GMPLS overlay
networks may present such restrictions. networks may present such restrictions.
. If the source node knows the route of the reference path from . If the source node knows the route of the reference path from
which diversity is required, it can use this information to which diversity is required, it can use this information to
construct an XRO and send it in the path message during the construct an XRO and send it in the path message during the
signaling of a diverse LSP. However, if the route of the signaling of a diverse LSP. However, if the route of the
excluded path changes (e.g. due to re-optimization or failure excluded path changes (e.g. due to re-optimization or failure
in the network), the source node would need to change the in the network), the source node would need to change the
Internet Draft draft-ietf-ccamp-lsp-diversity-02.txt
diverse path to ensure that it remains diverse from the diverse path to ensure that it remains diverse from the
excluded path. It is preferable to have this decision made by excluded path. It is preferable to have this decision made by
the node that performed the path-calculation for the diverse the node that performed the path-calculation for the diverse
path. For example, in the case of GMPLS-UNI, it is better to path. For example, in the case of GMPLS-UNI, it is better to
have such responsibility at the server layer as opposed to at have such responsibility at the server layer as opposed to at
the client layer so that the diversity requirements are the client layer so that the diversity requirements are
transparent to the client layer. Furthermore, in all networking transparent to the client layer. Furthermore, in all networking
scenarios, if the node performing the route computation/ scenarios, if the node performing the route computation/
expansion is aware of the diversity requirements of the two expansion is aware of the diversity requirements of the two
paths, it may consider joint re-optimization of the diverse paths, it may consider joint re-optimization of the diverse
skipping to change at page 5, line 5 skipping to change at page 4, line 43
This document addresses only the exclusion of point-to-point This document addresses only the exclusion of point-to-point
paths; point-to-multipoint paths will be addressed in a future paths; point-to-multipoint paths will be addressed in a future
version. version.
If mutually diverse routes are desired for two LSPs belonging to If mutually diverse routes are desired for two LSPs belonging to
different tunnels, it is recommended that they be signaled with different tunnels, it is recommended that they be signaled with
XRO LSP subobjects referencing each other. The processing rules XRO LSP subobjects referencing each other. The processing rules
specified in this document cover this case. specified in this document cover this case.
Internet Draft draft-ietf-ccamp-lsp-diversity-01.txt
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. Specifically, this address the aforementioned requirements. Specifically, this
document defines a new LSP subobject to be signaled in the document defines a new LSP subobject to be signaled in the
EXCLUDE_ROUTE object (XRO) and/ or Explicit Exclusion Route EXCLUDE_ROUTE object (XRO) and/ or Explicit Exclusion Route
Subobject (EXRS) defined in [RFC4874]. Inclusion of the LSP Subobject (EXRS) defined in [RFC4874]. Inclusion of the LSP
subobject in any other RSVP object is not defined. subobject in any other RSVP object is not defined.
Internet Draft draft-ietf-ccamp-lsp-diversity-02.txt
2.1. Terminology 2.1. Terminology
In this document, the following terminology is adopted: In this document, the following terminology is adopted:
Excluded path: the path from which diversity is required. Excluded path: the path from which diversity is required.
Diverse LSP: the LSP being signaled with XRO/ EXRS containing the Diverse LSP: the LSP being signaled with XRO/ EXRS containing the
path subobject referencing the excluded path(s). path subobject referencing the excluded path(s).
Processing node: the node performing a path-calculation involving Processing node: the node performing a path-calculation involving
skipping to change at page 6, line 4 skipping to change at page 5, line 42
defined by this document as follows. defined by this document as follows.
2.2.1. IPv4 Point-to-Point Path subobject 2.2.1. IPv4 Point-to-Point Path 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| Type | Length |Attribute Flags|Exclusion Flags| |L| Type | Length |Attribute Flags|Exclusion Flags|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 tunnel end point address | | IPv4 tunnel end point address |
Internet Draft draft-ietf-ccamp-lsp-diversity-01.txt
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Must Be Zero | Tunnel ID | | Must Be Zero | Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extended Tunnel ID | | Extended Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 tunnel sender address | | IPv4 tunnel sender address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Must Be Zero | LSP ID | | Must Be Zero | LSP ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Internet Draft draft-ietf-ccamp-lsp-diversity-02.txt
L L
The L-flag is used as for the other XRO subobjects defined The L-flag is used as for the other XRO subobjects defined
in [RFC4874]. in [RFC4874].
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 1 indicates that the attribute specified SHOULD be
avoided. avoided.
Type Type
skipping to change at page 7, line 4 skipping to change at page 6, line 39
The Attribute Flags are used to communicate desirable The Attribute Flags are used to communicate desirable
attributes of the LSP being signaled. The following flags attributes of the LSP being signaled. The following flags
are defined. None, all or multiple attribute flags MAY be are defined. None, all or multiple attribute flags MAY be
set within the same subobject. set within the same subobject.
0x01 = LSP ID to be ignored 0x01 = LSP ID to be ignored
This flag is used to indicate tunnel level exclusion. This flag is used to indicate tunnel level exclusion.
Specifically, this flag is used to indicate that the Specifically, this flag is used to indicate that the
lsp-id field of the subobject is to be ignored and the lsp-id field of the subobject is to be ignored and the
Internet Draft draft-ietf-ccamp-lsp-diversity-01.txt
exclusion applies to any LSP matching the rest of the exclusion applies to any LSP matching the rest of the
supplied FEC. supplied FEC.
0x02 = Destination node exception 0x02 = Destination node exception
This flag is used to indicate that the destination node This flag is used to indicate that the destination node
of the LSP being signaled MAY be shared with the of the LSP being signaled MAY be shared with the
excluded path even when this violates the exclusion excluded path even when this violates the exclusion
flags. flags.
Internet Draft draft-ietf-ccamp-lsp-diversity-02.txt
0x04 = Processing node exception 0x04 = Processing node exception
This flag is used to indicate that the processing node This flag is used to indicate that the processing node
MAY be shared with the excluded path even when this MAY be shared with the excluded path even when this
violates the exclusion flags. violates the exclusion flags.
0x08 = Penultimate node exception 0x08 = Penultimate node exception
This flag is used to indicate that the penultimate node This flag is used to indicate that the penultimate node
of the LSP being signaled MAY be shared with the of the LSP being signaled MAY be shared with the
skipping to change at page 8, line 5 skipping to change at page 7, line 42
0x02 = Node exclusion 0x02 = Node exclusion
This flag is used to indicate that the route of the This flag is used to indicate that the route of the
LSP being signaled is requested to be node diverse LSP being signaled is requested to be node diverse
from the excluded path specified by the LSP from the excluded path specified by the LSP
subobject. subobject.
(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.)
Internet Draft draft-ietf-ccamp-lsp-diversity-01.txt
0x04 = Link exclusion 0x04 = Link exclusion
This flag is used to indicate that the route of the This flag is used to indicate that the route of the
LSP being signaled is requested to be link diverse LSP being signaled is requested to be link diverse
from the path specified by the LSP subobject. from the path specified by the LSP subobject.
The remaining fields are as defined in [RFC3209]. The remaining fields are as defined in [RFC3209].
Internet Draft draft-ietf-ccamp-lsp-diversity-02.txt
2.2.2. IPv6 Point-to-Point Path subobject 2.2.2. IPv6 Point-to-Point Path 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| Type | Length |Attribute Flags|Exclusion Flags| |L| Type | Length |Attribute Flags|Exclusion Flags|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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 10, line 5 skipping to change at page 9, line 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Must Be Zero | LSP ID | | Must Be Zero | LSP ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
L L
The L-flag is used as for the other XRO subobjects defined The L-flag is used as for the other XRO subobjects defined
in [RFC4874]. in [RFC4874].
0 indicates that the attribute specified MUST be excluded. 0 indicates that the attribute specified MUST be excluded.
Internet Draft draft-ietf-ccamp-lsp-diversity-02.txt
1 indicates that the attribute specified SHOULD be 1 indicates that the attribute specified SHOULD be
avoided. avoided.
Type Type
IPv6 Point-to-Point Path subobject IPv6 Point-to-Point Path subobject
(to be assigned by IANA; suggested value: 37). (to be assigned by IANA; suggested value: 37).
Length Length
skipping to change at page 10, line 34 skipping to change at page 9, line 36
2.3. Processing rules for the Path XRO subobjects 2.3. Processing rules for the Path XRO subobjects
XRO processing as described in [RFC4874] is unchanged. XRO processing as described in [RFC4874] is unchanged.
If the processing node is the destination for the LSP being If the processing node is the destination for the LSP being
signaled, it SHOULD NOT process a Path XRO subobject. signaled, it SHOULD NOT process a Path XRO subobject.
If the L-flag is not set, the processing node follows the If the L-flag is not set, the processing node follows the
following procedure: following procedure:
- The processing node MUST ensure that any route calculated for - The processing node MUST ensure that any route calculated for
the signaled LSP respects the requested exclusion flags with the signaled LSP respects the requested exclusion flags with
respect to the excluded path referenced by the subobject, respect to the excluded path referenced by the subobject,
including local resources. including local resources.
- If the processing node fails to find a route that meets the - If the processing node fails to find a route 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 excluded path referenced in the LSP subobject is - If the excluded path referenced in the LSP subobject is unknown
unknown to the processing node, the processing node SHOULD to the processing node, the processing node SHOULD ignore the
ignore the LSP subobject in the XRO and SHOULD proceed with the LSP subobject in the XRO and SHOULD proceed with the signaling
signaling request. After sending the Resv for the signaled LSP, request. After sending the Resv for the signaled LSP, the
the processing node SHOULD return a PathErr with the error code
Internet Draft draft-ietf-ccamp-lsp-diversity-02.txt
processing node SHOULD return a PathErr with the error code
"Notify Error" (25) and error sub-code "Route of XRO path "Notify Error" (25) and error sub-code "Route of XRO path
unknown" (value to be assigned by IANA, suggested value: 13) unknown" (value to be assigned by IANA, suggested value: 13)
for the signaled LSP. for the signaled LSP.
If the L-flag is set, the processing node follows the following If the L-flag is set, the processing node follows the following
procedure: procedure:
- The processing node SHOULD respect the requested exclusion - The processing node SHOULD respect the requested exclusion
flags with respect to the excluded path as far as possible. flags with respect to the excluded path as far as possible.
- If the processing node fails to find a route that meets the - If the processing node fails to find a route that meets the
requested constraint, it SHOULD proceed with signaling using a requested constraint, it SHOULD proceed with signaling using a
suitable route that meets the constraint as far as possible. suitable route 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, suggest value: 14) to the source node.
- If the excluded path referenced in the LSP subobject is - If the excluded path referenced in the LSP subobject is unknown
unknown to the processing node, the processing node SHOULD to the processing node, the processing node SHOULD ignore the
ignore the LSP subobject in the XRO and SHOULD proceed with the LSP subobject in the XRO and SHOULD proceed with the signaling
signaling request. After sending the Resv for signaled LSP, the request. After sending the Resv for signaled LSP, the
processing node SHOULD return a PathErr message with the error processing node SHOULD return a PathErr message with the error
code "Notify Error" (25) and error sub-code "Route of XRO path code "Notify Error" (25) and error sub-code "Route of XRO path
unknown" for the signaled LSP. unknown" for the signaled LSP.
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 diverse LSP's XRO - an excluded path referenced in the diverse LSP's XRO subobject
subobject becomes known to the processing node (e.g. when the becomes known to the processing node (e.g. when the excluded
excluded path is signaled), or path is signaled), or
- A change in the excluded path becomes known to the processing - A change in the excluded path becomes known to the processing
node, node,
the processing node SHOULD re-evaluate the exclusion and the processing node SHOULD re-evaluate the exclusion and
diversity constraints requested by the diverse LSP to determine diversity constraints requested by the diverse LSP to determine
whether they are still satisfied. whether they are still satisfied.
- If the requested exclusion constraints for the diverse LSP - If the requested exclusion constraints for the diverse LSP are
are no longer satisfied and an alternative route for the no longer satisfied and an alternative route for the diverse
diverse LSP that can satisfy those constraints exists, the LSP that can satisfy those constraints exists, the processing
processing node SHOULD send a PathErr message for the diverse node SHOULD send a PathErr message for the diverse LSP with the
LSP with the error code "Notify Error" (25) and error sub-code error code "Notify Error" (25) and error sub-code "Preferable
"Preferable path exists" (6). A source node receiving a PathErr path exists" (6). A source node receiving a PathErr message
message with this error code and sub-code combination MAY try
to reoptimize the diverse tunnel to the new compliant path.
- If the requested exclusion constraints for the diverse LSP Internet Draft draft-ietf-ccamp-lsp-diversity-02.txt
are no longer satisfied and no alternative path for the diverse
LSP that can satisfy those constraints exists, then:
o If the L-flag was not set in the original exclusion, the with this error code and sub-code combination MAY try to
reoptimize the diverse tunnel to the new compliant path.
- If the requested exclusion constraints for the diverse LSP are
no longer satisfied and no alternative path for the diverse LSP
that can satisfy those constraints exists, then:
o If the L-flag was not set in the original exclusion, the
processing node MUST send a PathErr message for the 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. PSR flag SHOULD NOT 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). (value: to be assigned by IANA, suggest value: 14).
The following rules apply whether or not the L-flag is set: The following rules apply whether or not the L-flag is set:
- An XRO object MAY contain multiple path subobjects. - An XRO object MAY contain multiple path subobjects.
- As specified in [RFC4874], a node receiving a Path message - As specified in [RFC4874], a node receiving a Path message
carrying an XRO MAY reject the message if the XRO is too large carrying an XRO MAY reject the message if the XRO is too large
or complicated for the local implementation or the rules of or complicated for the local implementation or the rules of
local policy. In this case, the node MUST send a PathErr local policy. In this case, the node MUST send a PathErr
message with the error code "Routing Error" (24) and error sub- message with the error code "Routing Error" (24) and error sub-
code "XRO Too Complex" (68). A source node receiving this code "XRO Too Complex" (68). A source node receiving this
error code/sub-code combination MAY reduce the complexity of error code/sub-code combination MAY reduce the complexity of
the XRO or route around the node that rejected the XRO. the XRO or route around the node that rejected the XRO.
- 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 path "Notify Error" (25) and error sub-codes "Route of XRO path
unknown" or "Failed to respect Exclude Route" MAY take no unknown" or "Failed to respect Exclude Route" MAY take no
action. action.
- The attribute-flags affect the processing of the XRO subobject - The attribute-flags affect the processing of the XRO subobject
as follows: as follows:
o When the "LSP ID to be ignored" flag is set, the o When the "LSP ID to be ignored" flag is set, the
processing node MUST calculate a route based on exclusions processing node MUST calculate a route based on exclusions
from the routes of all known LSPs matching the tunnel-id, from the routes of all known LSPs matching the tunnel-id,
source, destination and extended tunnel-id specified in source, destination and extended tunnel-id specified in
the subobject. When this flag is not set, the lsp-id is the subobject. When this flag is not set, the lsp-id is
not ignored and the exclusion applies only to the not ignored and the exclusion applies only to the
specified LSP (i.e., LSP level exclusion). specified LSP (i.e., LSP level exclusion).
Internet Draft draft-ietf-ccamp-lsp-diversity-02.txt
o When the "destination node exception" flag is not set, the o When the "destination node exception" flag is not set, the
exclusion flags SHOULD also be respected for the exclusion flags SHOULD also be respected for the
destination node. destination node.
o When the "processing node exception" flag is not set, the o When the "processing node exception" flag is not set, the
exclusion flags SHOULD also be respected for the exclusion flags SHOULD also be respected for the
processing node. processing node.
o When the "penultimate node exception" flag is not set, the o When the "penultimate node exception" flag is not set, the
exclusion flags SHOULD also be respected for the exclusion flags SHOULD also be respected for the
skipping to change at page 13, line 47 skipping to change at page 12, line 49
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Must Be Zero | Tunnel ID | | Must Be Zero | Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extended Tunnel ID | | Extended Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 tunnel sender address | | IPv4 tunnel sender address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Must Be Zero | LSP ID | | Must Be Zero | LSP ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The meaning of respective fields in EXRS header is as defined in The meaning of respective fields in EXRS header are as defined in
[RFC4874]. The meaning of respective fields in IPv4 P2P Path [RFC4874]. The meaning of respective fields in IPv4 P2P Path
subobject is as defined earlier in this document. This is with subobject is as defined earlier in this document.
the exceptions that:
- The processing node exception applies to the node processing
the ERO.
- If the L bit in the ERO header is not set (ERO.L = 0), the
IPv4 P2P Path subobject is processed against the path(s) for
which the processing node is a source, destination or transit
node.
- The penultimate node exception applies to the penultimate node
of the loose hop. This flag is only processed if the ERO.L bit
is set, i.e. in the loose ERO hop case.
- The destination node exception applies to the last explicit
node to which the loose hop is expanded. This flag is only
processed if ERO.L bit is set, i.e., in the loose ERO hop case.
2.4.1. Processing Rules for the EXRS with Path subobject Internet Draft draft-ietf-ccamp-lsp-diversity-02.txt
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 Path subobject(s), [RFC4874]. When the EXRS contains one or more Path subobject(s),
the processing rules specified in Section 2.3 apply to the node the processing rules specified in Section 2.3 apply to the node
processing the ERO with the EXRS subobject. processing the ERO with the EXRS subobject.
The EXRS scope is limited to the loose hop in which the EXRS If a loose-hop expansion results in the creation of another
appears. If loose-hop expansion results in the creation of loose-hop in the outgoing ERO, the processing node MAY include
another loose-hop in the outgoing ERO, the processing node MAY the EXRS in the newly-created loose hop for further processing by
include the EXRS in the newly-created loose hop for further downstream nodes.
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
4.1. New XRO subobject types 4.1. New XRO subobject types
skipping to change at page 15, line 4 skipping to change at page 13, line 44
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
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 introduces two new subobjects for the EXCLUDE_ROUTE
object [RFC4874], C-Type 1. object [RFC4874], C-Type 1.
Subobject Type Subobject Description Subobject Type Subobject Description
-------------- --------------------- -------------- ---------------------
To be assigned by IANA IPv4 P2P Path subobject To be assigned by IANA IPv4 P2P Path subobject
(suggested value: 36) (suggested value: 36)
Internet Draft draft-ietf-ccamp-lsp-diversity-02.txt
To be assigned by IANA IPv6 P2P Path subobject To be assigned by IANA IPv6 P2P Path subobject
(suggested value: 37) (suggested value: 37)
4.2. New EXRS subobject types 4.2. New EXRS subobject types
The IPv4 and IPv6 P2P Path subobjects are also defined as new The IPv4 and IPv6 P2P Path subobjects are also defined as new
EXRS subobjects. EXRS subobjects.
4.3. New RSVP error sub-codes 4.3. New RSVP error sub-codes
skipping to change at page 16, line 9 skipping to change at page 15, line 5
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.
Internet Draft draft-ietf-ccamp-lsp-diversity-02.txt
[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, April 2007. Traffic Engineering (RSVP-TE)", RFC 4874, April 2007.
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.
[RFC2209] Braden, R. and L. Zhang, "Resource ReSerVation Protocol [RFC2205] Braden, R. (Ed.), Zhang, L., Berson, S., Herzog, S. and
(RSVP) -- Version 1 Message Processing Rules", RFC S. Jamin, "Resource ReserVation Protocol -- Version 1
2209, September 1997. Functional Specification", RFC 2205, September 1997.
[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.
Authors' Addresses Authors' Addresses
Zafar Ali Zafar Ali
Cisco Systems. Cisco Systems.
Email: zali@cisco.com Email: zali@cisco.com
George Swallow George Swallow
Cisco Systems Cisco Systems
swallow@cisco.com swallow@cisco.com
Clarence Filsfils Clarence Filsfils
Cisco Systems, Inc. Cisco Systems, Inc.
cfilsfil@cisco.com cfilsfil@cisco.com
Internet Draft draft-ietf-ccamp-lsp-diversity-02.txt
Matt Hartley Matt Hartley
Cisco Systems Cisco Systems
Email: mhartley@cisco.com Email: mhartley@cisco.com
Ori Gerstel Ori Gerstel
Cisco Systems Cisco Systems
ogerstel@cisco.com ogerstel@cisco.com
Gabriele Maria Galimberti Gabriele Maria Galimberti
Cisco Systems Cisco Systems
 End of changes. 55 change blocks. 
133 lines changed or deleted 136 lines changed or added

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