draft-ietf-ccamp-lsp-diversity-02.txt   draft-ietf-ccamp-lsp-diversity-03.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: January 14, 2014 Matt Hartley Expires: August 2, 2014 Matt Hartley
Ori Gerstel
Gabriele Maria Galimberti Gabriele Maria Galimberti
Cisco Systems Cisco Systems
Ori Gerstel
SDN Solutions Ltd.
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
July 15, 2013 February 3, 2014
Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Path Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Path
Diversity using Exclude Routes Diversity using Exclude Route
draft-ietf-ccamp-lsp-diversity-02.txt draft-ietf-ccamp-lsp-diversity-03.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 months Internet-Drafts are draft documents valid for a maximum of six
and may be updated, replaced, or obsoleted by other documents at any months and may be updated, replaced, or obsoleted by other documents
time. It is inappropriate to use Internet-Drafts as reference at any time. It is inappropriate to use Internet-Drafts as
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 January 13, 2014. This Internet-Draft will expire on August 2, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2014 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)
publication of this document. Please review these documents in effect on the date of publication of this document. Please
carefully, as they describe your rights and restrictions with respect review these documents carefully, as they describe your rights
to this document. Code Components extracted from this document must and restrictions with respect to this document. Code Components
include Simplified BSD License text as described in Section 4.e of extracted from this document must include Simplified BSD License
the Trust Legal Provisions and are provided without warranty as text as described in Section 4.e of the Trust Legal Provisions
described in the Simplified BSD License. and are provided without warranty as described in the Simplified
BSD License.
Internet Draft draft-ietf-ccamp-lsp-diversity-02.txt Internet Draft draft-ietf-ccamp-lsp-diversity-03.txt
Abstract Abstract
RFC 4874 specifies methods by which route exclusions may be RFC 4874 specifies methods by which path 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 exclusion
on Paths currently existing or expected to exist within the network. subobjects based 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..................................................2 1. Introduction ................................................2
2. RSVP-TE signaling extensions..................................4 2. RSVP-TE signaling extensions.................................4
2.1. Terminology...........................................5 2.1. Terminology..........................................4
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....................... 8 2.2.2. IPv6 Point-to-Point Path subobject...................... 8
2.3. Processing rules for the Path XRO subobjects..........9 2.3. Processing rules for the Path XRO subobjects.........9
2.4. Path EXRS Subobject..................................12 2.4. Path EXRS Subobject.................................12
3. Security Considerations......................................13 3. Security Considerations.....................................13
4. IANA Considerations..........................................13 4. IANA Considerations.........................................13
4.1. New XRO subobject types..............................13 4.1. New XRO subobject types.............................13
4.2. New EXRS subobject types.............................14 4.2. New EXRS subobject types............................14
4.3. New RSVP error sub-codes.............................14 4.3. New RSVP error sub-codes............................14
5. Acknowledgements.............................................14 5. Acknowledgements............................................14
6. References...................................................14 6. References..................................................14
6.1. Normative References.................................14 6.1. Normative Reference.................................14
6.2. Informative References...............................15 6.2. Informative References..............................15
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 Paths (LSPs) Such diversity ensures Label-Switched Paths (LSPs) may be
may be established without sharing resources, thus greatly established without sharing resources, thus greatly reducing the
reducing the probability of simultaneous connection failures. probability of simultaneous connection failures.
Internet Draft draft-ietf-ccamp-lsp-diversity-02.txt Internet Draft draft-ietf-ccamp-lsp-diversity-03.txt
When route computation for paths that need to be diverse is When a source node has full topological knowledge and is permitted
performed at the LSP's source node, this requirement can be met by to signal an Explicit Route Object, diverse paths can be computed
a local decision at that node. However, there are scenarios when locally. However, there are scenarios when path computations are
route computations are performed by remote nodes, thus there is a performed by remote nodes, thus there is a need for relevant
need for relevant diversity requirements to be communicated to diversity requirements to be communicated to those nodes. These
those nodes. These include (but are not limited to): 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-Network . Generalized Multi-Protocol Label Switching (GMPLS) User-
Interface (UNI) where route computation may be performed by the Network Interface (UNI) where path computation may be performed
(server layer) core node [RFC4208]. by the (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 paths 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. Employing these mechanisms requires that the
path(s) from which diversity is required be known to the source source node that initiates signaling knows the relevant properties
node which initiates signaling. However, there are circumstances of the path(s) from which diversity is desired. However, there are
under which this may not be possible or desirable, including (but circumstances under which this may not be possible or desirable,
not limited to): including (but 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 is known to the source node of the
the diverse LSP, has incomplete or unavailable route diverse LSP, however the node has incomplete or no path
information, e.g. due to confidentiality of the path information, e.g. due to policy. In other words, the scenario
attributes. In other words, the scenario in which the reference in which the reference path is known by the source / requesting
path is hosted by the source / requesting node but the node but the properties required to construct an XRO object are
properties required to construct an XRO object are not known to not fully known. Inter-domain and GMPLS overlay networks can
source / requesting node. Inter-domain and GMPLS overlay present such restrictions.
networks may present such restrictions.
. If the source node knows the route of the reference path from
which diversity is required, it can use this information to
construct an XRO and send it in the path message during the
signaling of a diverse LSP. However, if the route of the
excluded path changes (e.g. due to re-optimization or failure
in the network), the source node would need to change the
Internet Draft draft-ietf-ccamp-lsp-diversity-02.txt This document defines procedures that may be used to exclude the
path taken by a particular LSP, or the paths taken by all LSPs
belonging to a single tunnel. The diversity requirements
considered in this document do not require that the paths in
question belong to the same tunnel or share the same source or
destination node.
diverse path to ensure that it remains diverse from the Internet Draft draft-ietf-ccamp-lsp-diversity-03.txt
excluded path. It is preferable to have this decision made by
the node that performed the path-calculation for the diverse
path. For example, in the case of GMPLS-UNI, it is better to
have such responsibility at the server layer as opposed to at
the client layer so that the diversity requirements are
transparent to the client layer. Furthermore, in all networking
scenarios, if the node performing the route computation/
expansion is aware of the diversity requirements of the two
paths, it may consider joint re-optimization of the diverse
paths.
This document addresses such scenarios and defines procedures If mutually diverse paths are desired for two LSPs belonging to
that may be used to exclude the route taken by a particular LSP, different tunnels, it is recommended that they be signaled with
or the routes taken by all LSPs belonging to a single tunnel. XRO LSP subobjects referencing each other. The processing rules
Note that this diversity requirement is different from the specified in this document cover this case.
diversity requirements of path protection where both the
reference and diverse LSPs belong to the same tunnel. The
diversity requirements considered in this document do not require
that the paths in question belonging to the same tunnel or share
the same source or destination node.
The means by which the node calculating or expanding the route of The means by which the node calculating or expanding the route of
the signaled LSP discovers the route of the path(s) from which the signaled LSP discovers the route of the path(s) from which
the signaled LSP requires diversity are beyond the scope of this the signaled LSP requires diversity are beyond the scope of this
document. document.
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. Exclusion of point-to-multipoint paths is beyond the scope
version. of this document.
If mutually diverse routes are desired for two LSPs belonging to
different tunnels, it is recommended that they be signaled with
XRO LSP subobjects referencing each other. The processing rules
specified in this document cover this case.
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
an exclusion specified in an XRO or EXRS. exclusion specified in an XRO or EXRS.
Destination node: in the context of an XRO, this is the Destination node: in the context of an XRO, this is the
destination of the LSP being signaled. In the context of an EXRS, destination of the LSP being signaled. In the context of an EXRS,
the destination node is the last explicit node to which the loose the destination node is the last explicit node to which the loose
hop is expanded. hop is expanded.
Penultimate node: in the context of an XRO, this is the Penultimate node: in the context of an XRO, this is the
penultimate hop of the LSP being signaled. In the context of an penultimate hop of the LSP being signaled. In the context of an
EXRS, the penultimate node is the penultimate node of the loose EXRS, the penultimate node is the penultimate node of the loose
hop undergoing expansion. hop undergoing expansion.
Internet Draft draft-ietf-ccamp-lsp-diversity-03.txt
2.2. Path XRO Subobjects 2.2. Path XRO Subobjects
New IPv4 and IPv6 Point-to-Point (P2P) Path XRO subobjects are New IPv4 and IPv6 Point-to-Point (P2P) Path XRO subobjects are
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 6, line 5 skipping to change at page 5, line 30
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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:
IPv4 Point-to-Point Path subobject IPv4 Point-to-Point Path subobject (to be assigned by IANA;
(to be assigned by IANA; suggested value: 36). suggested value: 36).
Length Length:
Internet Draft draft-ietf-ccamp-lsp-diversity-03.txt
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
always 24. always 24.
Attribute Flags Attribute Flags:
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. Each flag acts independently. Any combination
set within the same subobject. of flags is permitted.
0x01 = LSP ID to be ignored 0x01 = LSP ID to be ignored
This flag is used to indicate tunnel level exclusion. Indicates tunnel level exclusion. Specifically, this
Specifically, this flag is used to indicate that the flag is used to indicate that the lsp-id field of the
lsp-id field of the subobject is to be ignored and the subobject is to be ignored and the exclusion applies to
exclusion applies to any LSP matching the rest of the 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 Indicates that exclusion does not apply to the
of the LSP being signaled MAY be shared with the destination node of the LSP being signaled.
excluded path even when this violates the exclusion
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 Indicates that exclusion does not apply to the ERO
MAY be shared with the excluded path even when this processing node of the LSP being signaled.
violates the exclusion flags.
0x08 = Penultimate node exception 0x08 = Penultimate node exception
This flag is used to indicate that the penultimate node Indicates that the penultimate node of the LSP being
of the LSP being signaled MAY be shared with the signaled MAY be shared with the excluded path even when
excluded path even when this violates the exclusion this violates the exclusion flags.
flags.
Indicates that exclusion does not apply to the
penultimate node of the LSP being signaled.
Exclusion Flags Exclusion Flags
The Exclusion-Flags are used to communicate desirable The Exclusion-Flags are used to communicate the desired
types of exclusion. The following flags are defined. type(s) of exclusion. The following flags are defined.
0x01 = SRLG exclusion 0x01 = SRLG exclusion
This flag is used to indicate that the route of the Internet Draft draft-ietf-ccamp-lsp-diversity-03.txt
LSP being signaled is requested to be SRLG diverse
from the excluded path specified by the LSP Indicates that the path of the LSP being signaled is
subobject. requested to be SRLG diverse from the excluded path
specified by the LSP subobject.
0x02 = Node exclusion 0x02 = Node exclusion
This flag is used to indicate that the route of the Indicates that the path of the LSP being signaled is
LSP being signaled is requested to be node diverse requested to be node diverse from the excluded path
from the excluded path specified by the LSP 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.)
0x04 = Link exclusion 0x04 = Link exclusion
This flag is used to indicate that the route of the Indicates that the path of the LSP being signaled is
LSP being signaled is requested to be link diverse requested to be link diverse from the path specified
from the path specified by the LSP subobject. 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 Internet Draft draft-ietf-ccamp-lsp-diversity-03.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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 9, 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 Internet Draft draft-ietf-ccamp-lsp-diversity-03.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 9, line 36 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 path 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 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 excluded path referenced in the LSP subobject is unknown - If the excluded path referenced in the LSP subobject is
to the processing node, the processing node SHOULD ignore the unknown to the processing node, the processing node SHOULD
LSP subobject in the XRO and SHOULD proceed with the signaling ignore the LSP subobject in the XRO and SHOULD proceed with the
request. After sending the Resv for the signaled LSP, the
Internet Draft draft-ietf-ccamp-lsp-diversity-02.txt Internet Draft draft-ietf-ccamp-lsp-diversity-03.txt
processing node SHOULD return a PathErr with the error code signaling request. After sending the Resv for the signaled LSP,
the 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 procedure
procedure: below:
- 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 to the extent possible.
- If the processing node fails to find a route 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 route 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, suggest value: 14) to the source node.
- If the excluded path referenced in the LSP subobject is unknown - If the excluded path referenced in the LSP subobject is
to the processing node, the processing node SHOULD ignore the unknown to the processing node, the processing node SHOULD
LSP subobject in the XRO and SHOULD proceed with the signaling ignore the LSP subobject in the XRO and SHOULD proceed with the
request. After sending the Resv for signaled LSP, the signaling 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 subobject - an excluded path referenced in the diverse LSP's XRO
becomes known to the processing node (e.g. when the excluded subobject becomes known to the processing node (e.g. when the
path is signaled), or excluded 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 are - If the requested exclusion constraints for the diverse LSP
no longer satisfied and an alternative route for the diverse are no longer satisfied and an alternative path for the diverse
LSP that can satisfy those constraints exists, the processing LSP that can satisfy those constraints exists, the processing
node SHOULD send a PathErr message for the diverse LSP with the node SHOULD send a PathErr message for the diverse LSP with the
error code "Notify Error" (25) and error sub-code "Preferable error code "Notify Error" (25) and a new error sub-code
path exists" (6). A source node receiving a PathErr message "compliant path exists" (value: to be assigned by IANA, suggest
Internet Draft draft-ietf-ccamp-lsp-diversity-02.txt Internet Draft draft-ietf-ccamp-lsp-diversity-03.txt
with this error code and sub-code combination MAY try to value: 15). A source node receiving a PathErr message with this
reoptimize the diverse tunnel to the new compliant path. 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 - If the requested exclusion constraints for the diverse LSP
no longer satisfied and no alternative path for the diverse LSP are no longer satisfied and no alternative path for the diverse
that can satisfy those constraints exists, then: LSP 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 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
carrying an XRO MAY reject the message if the XRO is too large
or complicated for the local implementation or the rules of
local policy. In this case, the node MUST send a PathErr
message with the error code "Routing Error" (24) and error sub-
code "XRO Too Complex" (68). A source node receiving this
error code/sub-code combination MAY reduce the complexity of
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 path based on exclusions
from the routes of all known LSPs matching the tunnel-id, from the paths 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 (i.e., tunnel level exclusion). When this
not ignored and the exclusion applies only to the flag is not set, the lsp-id is not ignored and the
specified LSP (i.e., LSP level exclusion). exclusion applies only to the 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.
Internet Draft draft-ietf-ccamp-lsp-diversity-03.txt
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
penultimate node. penultimate node.
2.4. Path EXRS Subobject 2.4. Path EXRS Subobject
skipping to change at page 12, line 49 skipping to change at page 12, line 45
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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 are as defined in The meanings of respective fields in EXRS header are as defined
[RFC4874]. The meaning of respective fields in IPv4 P2P Path in [RFC4874]. The meanings of respective fields in IPv4 P2P Path
subobject is as defined earlier in this document. subobject are as defined earlier in this document.
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),
Internet Draft draft-ietf-ccamp-lsp-diversity-03.txt
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.
If a loose-hop expansion results in the creation of another If a loose-hop expansion results in the creation of another
loose-hop in the outgoing ERO, the processing node MAY include loose-hop in the outgoing ERO, the processing node MAY include
the EXRS in the newly-created loose hop for further processing by the EXRS in the newly-created loose hop for further processing by
downstream nodes. downstream nodes.
The processing node exception for the EXRS subobject applies to The processing node exception for the EXRS subobject applies to
the node processing the ERO. the node processing the ERO.
skipping to change at page 14, line 4 skipping to change at page 13, line 50
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)
Internet Draft draft-ietf-ccamp-lsp-diversity-03.txt
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
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
skipping to change at page 14, line 33 skipping to change at page 14, line 30
Sub-code Value Sub-code Value
-------- ----- -------- -----
Route of XRO path unknown To be assigned by IANA. Route of XRO path unknown To be assigned by IANA.
Suggested Value: 13. Suggested Value: 13.
Failed to respect Exclude Route To be assigned by IANA. Failed to respect Exclude Route To be assigned by IANA.
Suggested Value: 14. Suggested Value: 14.
Compliant path exists To be assigned by IANA.
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.
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.
Internet Draft draft-ietf-ccamp-lsp-diversity-02.txt Internet Draft draft-ietf-ccamp-lsp-diversity-03.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.
skipping to change at page 15, line 37 skipping to change at page 15, line 37
[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
Cisco Systems
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 Internet Draft draft-ietf-ccamp-lsp-diversity-03.txt
Matt Hartley Gabriele Maria Galimberti
Cisco Systems Cisco Systems
Email: mhartley@cisco.com ggalimbe@cisco.com
Ori Gerstel Ori Gerstel
Cisco Systems SDN Solutions Ltd.
ogerstel@cisco.com origerstel@gmail.com
Gabriele Maria Galimberti Matt Hartley
Cisco Systems Cisco Systems
ggalimbe@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 Rudiger Kunze
Deutsche Telekom AG Deutsche Telekom AG
Ruediger.Kunze@telekom.de Ruediger.Kunze@telekom.de
Julien Meuric Julien Meuric
France Telecom Orange France Telecom Orange
Email: julien.meuric@orange.com Email: julien.meuric@orange.com
George Swallow
Cisco Systems
swallow@cisco.com
 End of changes. 84 change blocks. 
222 lines changed or deleted 190 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/