draft-ietf-ccamp-lsp-diversity-00.txt   draft-ietf-ccamp-lsp-diversity-01.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: August 11, 2013 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 12, 2013 February 18, 2013
Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) LSP Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Path
Route Diversity using Exclude Routes Diversity using Exclude Routes
draft-ietf-ccamp-lsp-diversity-00.txt draft-ietf-ccamp-lsp-diversity-01.txt
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in progress." reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 11, 2013. This Internet-Draft will expire on August 17, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions This document is subject to BCP 78 and the IETF Trust's Legal
Relating to IETF Documents (http://trustee.ietf.org/license-info) Provisions Relating to IETF Documents
in effect on the date of publication of this document. Please (http://trustee.ietf.org/license-info) in effect on the date of
review these documents carefully, as they describe your rights and publication of this document. Please review these documents
restrictions with respect to this document. Code Components carefully, as they describe your rights and restrictions with
extracted from this document must include Simplified BSD License respect to this document. Code Components extracted from this
text as described in Section 4.e of the Trust Legal Provisions and document must include Simplified BSD License text as described in
are provided without warranty as described in the Simplified BSD Section 4.e of the Trust Legal Provisions and are provided without
License. warranty as described in the Simplified BSD License.
Internet Draft draft-ietf-ccamp-lsp-diversity-00.txt
This document may contain material from IETF Documents or IETF This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this 10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process. modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
than English. than English.
Abstract Abstract
[RFC4874] 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 ingress 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 LSPs 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 ..................................................3
1.1. Requirements Notation .................................5 2. RSVP-TE signaling extensions ..................................5
2. RSVP-TE signaling extensions ...............................5 2.1. Terminology .................................................5
2.1. Terminology ...........................................5 2.2. Path XRO Subobjects .........................................5
2.2. LSP Subobject .........................................5 2.2.1. IPv4 Point-to-Point Path subobject ....................... 5
2.3. Processing rules for the LSP subobject ...............10 2.2.2. IPv6 Point-to-Point Path subobject ....................... 9
2.4. LSP Subobject in Explicit Exclusion Route Subobject ..11 2.3. Processing rules for the Path XRO subobjects ..............10
2.4.1. Processing Rules for the EXRS with LSP subobject.12 2.4. Path EXRS Subobject ........................................13
4. IANA Considerations .......................................12 2.4.1. Processing Rules for the EXRS with Path subobject ....... 14
4.1. New XRO subobject type ...............................12 3. Security Considerations .....................................14
4.2. New EXRS subobject type ..............................12 4. IANA Considerations .........................................14
4.3. New RSVP error sub-code ..............................12 4.1. New XRO subobject types ....................................14
5. Acknowledgement ...........................................13 4.2. New EXRS subobject types ...................................15
6. References ................................................13 4.3. New RSVP error sub-codes....................................15
6.1. Normative References .................................13
6.2. Informative References ...............................13
1. Introduction ...............................................3
1.1. Requirements Notation .................................5
2. RSVP-TE signaling extensions ...............................5
2.1. Terminology ...........................................5
2.2. LSP Subobjects ........................................5
2.2.1. IPv4 Point-to-Point LSP subobject ............... 5
2.2.2. IPv6 Point-to-Point LSP subobject ............... 9
2.3. Processing rules for the LSP subobject ...............10
2.4. LSP Subobject in Explicit Exclusion Route Subobject
(EXRS) ....................................................13
2.4.1. Processing Rules for the EXRS with LSP subobject 14
3. Security Considerations ...................................14
4. IANA Considerations .......................................14
4.1. New XRO subobject type ...............................14
Internet Draft draft-ietf-ccamp-lsp-diversity-00.txt Internet Draft draft-ietf-ccamp-lsp-diversity-01.txt
4.2. New EXRS subobject type ..............................14 5. Acknowledgements .............................................15
4.3. New RSVP error sub-code ..............................14 6. References ...................................................15
5. Acknowledgement ...........................................15
6. References ................................................15
6.1. Normative References .................................15 6.1. Normative References .................................15
6.2. Informative References ...............................15 6.2. Informative References ...............................16
1. Introduction 1. Introduction
Label-Switched Path (LSP) diversity is required to ensure LSPs may Path diversity is a well-known requirement from Service Providers.
be established without sharing resources, thus greatly reducing Such diversity is required to ensure Label-Switched Path (LSPs)
the probability of simultaneous connection failures. may be established without sharing resources, thus greatly
reducing the probability of simultaneous connection failures.
LSP diversity is a well-known requirement from Service Providers. When route computation for paths that need to be diverse is
When route computation for LSPs that need to be diverse is performed at the LSP's source node, this requirement can be met by
performed at ingress node, this requirement can be met by a local a local decision at that node. However, there are scenarios when
decision at that node. However, there are scenarios when route route computations are performed by remote nodes, there is a need
computations are performed by remote nodes, in which case there is for relevant diversity requirements to be communicated to those
a 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 Interface (UNI) where route computation may be Network Interface (UNI) where route computation may be
performed by the (sever layer) core node [RFC4208]; performed by the (server layer) core node [RFC4208];
The eXclude Route Object (XRO) and Explicit Exclusion Route [RFC4874] introduced a means of specifying nodes and resources to
Subobject (EXRS) specification [RFC4874] introduces a means of be excluded from a route, using the eXclude Route Object (XRO) and
specifying nodes and resources to be excluded from routes, using Explicit Exclusion Route Subobject (EXRS).
the XRO and/ or 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 LSPs 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 LSP(s) traversed links. This requires that these properties of the
from which diversity is required be known to the ingress node path(s) from which diversity is required be known to the source
which initiates signaling. However, there are circumstances under node which initiates signaling. However, there are circumstances
which this may not be possible or desirable, including (but not under which this may not be possible or desirable, including (but
limited to): not limited to):
. Exclusion of the route of a LSP which does not originate, . Exclusion of a path which does not originate, terminate or
terminate or traverse the ingress node signaling the diverse traverse the source node signaling the diverse LSP, in which
LSP, in which case the addresses and SRLGs of the LSP from case the addresses and SRLGs of the path from which diversity
which diversity is required are unknown to the ingress node. is required are unknown to the source node.
Internet Draft draft-ietf-ccamp-lsp-diversity-00.txt . Exclusion of a path which, while known at the source node of
the diverse LSP, has incomplete or unavailable route
information, e.g. due to confidentiality of the path
Internet Draft draft-ietf-ccamp-lsp-diversity-01.txt
. Exclusion of the route of a LSP which, while known at the
ingress node of the diverse LSP, has incomplete or unavailable
route information, e.g. due to confidentiality of the LSP route
attributes. In other words, the scenario in which the reference attributes. In other words, the scenario in which the reference
LSP is hosted by the ingress/ 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
ingress/ 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 route of the reference LSP from which diversity is . If the source node knows the route of the reference path from
required (e.g. LSP1) is known to the ingress node, that node which diversity is required, it can use this information to
can use this information to construct an XRO and send it in the construct an XRO and send it in the path message during the
path message during the signaling of a diverse LSP (LSP2). signaling of a diverse LSP. However, if the route of the
However, if the route of LSP1 changes (e.g. due to re- excluded path changes (e.g. due to re-optimization or failure
optimization or failure in the network), the ingress node would in the network), the source node would need to change the
need to change path of LSP2 to ensure that it remains diverse diverse path to ensure that it remains diverse from the
from LSP1. It is preferable to have this decision made by the excluded path. It is preferable to have this decision made by
node that calculated the path for LSP2. For example, in the the node that performed the path-calculation for the diverse
case of GMPLS-UNI, it is better to have such responsibility at path. For example, in the case of GMPLS-UNI, it is better to
the server layer as opposed to at the client layer so that the have such responsibility at the server layer as opposed to at
diversity requirements are transparent to the client layer. the client layer so that the diversity requirements are
Furthermore, in all networking scenarios, if the node transparent to the client layer. Furthermore, in all networking
performing the route computation/ expansion is aware of the scenarios, if the node performing the route computation/
diversity requirements of LSP1 and LSP2, it may consider joint expansion is aware of the diversity requirements of the two
re-optimization of the diverse LSPs. paths, it may consider joint re-optimization of the diverse
paths.
This document addresses such scenarios and defines procedures This document addresses such scenarios and defines procedures
that may be used to exclude the route taken by a particular LSP, that may be used to exclude the route taken by a particular LSP,
or the route taken by all LSPs belonging to a single tunnel. Note or the routes taken by all LSPs belonging to a single tunnel.
that this diversity requirement is different from the diversity Note that this diversity requirement is different from the
requirements of path protection where both the reference and diversity requirements of path protection where both the
diverse LSPs belong to the same tunnel. The diversity reference and diverse LSPs belong to the same tunnel. The
requirements considered in this document do not require that the diversity requirements considered in this document do not require
LSPs in question belonging to the same tunnel or share an ingress that the paths in question belonging to the same tunnel or share
node. 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 LSPs from which the the signaled LSP discovers the route of the path(s) from which
signaled LSP requires diversity is beyond the scope of this the signaled LSP requires diversity are beyond the scope of this
document. However, in most cases the LSPs with route diversity document.
requirements may transit the node expanding the route.
This document addresses only the exclusion of point-to-point This document addresses only the exclusion of point-to-point
tunnels; point-to-multipoint tunnels will be addressed in a paths; point-to-multipoint paths will be addressed in a future
future version. Similarly, at present only IPv4 addresses are
considered; support for IPv6 addresses will be added in a future
version. version.
Internet Draft draft-ietf-ccamp-lsp-diversity-00.txt If mutually diverse routes are desired for two LSPs belonging to
different tunnels, it is recommended that they be signaled with
1.1. Requirements Notation XRO LSP subobjects referencing each other. The processing rules
specified in this document cover this case.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL Internet Draft draft-ietf-ccamp-lsp-diversity-01.txt
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
[RFC2119].
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.
2.1. Terminology 2.1. Terminology
In this document, the following terminology is adopted: In this document, the following terminology is adopted:
LSP1/TUNNEL1: LSP1/TUNNEL1 is the LSP/tunnel from which diversity Excluded path: the path from which diversity is required.
is required.
LSP2/TUNNEL2: The term LSP2/TUNNEL2 is used to refer the LSP Diverse LSP: the LSP being signaled with XRO/ EXRS containing the
being signaled with XRO/ EXRS containing the LSP subobject path subobject referencing the excluded path(s).
referencing LSP1/TUNNEL1.
CircuitID: The term CircuitID refers to the LSP Forwarding Processing node: the node performing a path-calculation involving
Equivalence Class (FEC) (LSP ID field of the FEC may be ignored an exclusion specified in an XRO or EXRS.
depending on the context the CircuitID term is used).
CircuitIDx: The term CicuitIDx refers to CircuitID of Destination node: in the context of an XRO, this is the
LSPx/TUNNELx. destination of the LSP being signaled. In the context of an EXRS,
the destination node is the last explicit node to which the loose
hop is expanded.
2.2. LSP Subobjects Penultimate node: in the context of an XRO, this is the
penultimate hop of the LSP being signaled. In the context of an
EXRS, the penultimate node is the penultimate node of the loose
hop undergoing expansion.
New IPv4 and IPv6 Point-to-Point (P2P) LSP subobject are defined 2.2. Path XRO Subobjects
by this document as follows.
2.2.1. IPv4 Point-to-Point LSP subobject New IPv4 and IPv6 Point-to-Point (P2P) Path XRO subobjects are
defined by this document as follows.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Internet Draft draft-ietf-ccamp-lsp-diversity-00.txt
|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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 6, line 23 skipping to change at page 6, line 20
| Extended Tunnel ID | | Extended Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 tunnel sender address | | IPv4 tunnel sender address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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.
1 indicates that the attribute specified SHOULD be 1 indicates that the attribute specified SHOULD be
avoided. avoided.
Type Type
IPv4 Point-to-Point LSP subobject IPv4 Point-to-Point Path subobject
(to be assigned by IANA suggested value: 36). (to be assigned by IANA; suggested value: 36).
Length Length
The length contains the total length of the subobject in The length contains the total length of the subobject in
bytes, including the type and length fields. The length is bytes, including the type and length fields. The length is
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 (In the following, the attributes of the LSP being signaled. The following flags
term LSP2 is used to reference the LSP being signaled; are defined. None, all or multiple attribute flags MAY be
please refer to Section 2.1 for definition of LSP2). The set within the same subobject.
following flags are defined. None, all or multiple
attribute flags MAY be set within the same subobject.
0x01 = LSP ID to be ignored 0x01 = LSP ID to be ignored
Internet Draft draft-ietf-ccamp-lsp-diversity-00.txt
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
exclusion applies to any LSP matching the rest of the
supplied FEC. In other words, if this flag is set, the
processing node MUST calculate a route based on
exclusions from the routes of all known LSPs matching
the tunnel-id, source, destination and extended tunnel-
id specified in the subobject.
When this flag is not set, the lsp-id is not ignored and Internet Draft draft-ietf-ccamp-lsp-diversity-01.txt
the exclusion applies only to the specified LSP (i.e.,
LSP level exclusion). In other words, when this flag is exclusion applies to any LSP matching the rest of the
not set, route exclusions MUST respect the specified LSP supplied FEC.
(i.e. the lsp-id, the tunnel-id, source, destination and
extended tunnel-id specified needs to be respected
during exclusion).
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
may be shared even when sharing of the said node of the LSP being signaled MAY be shared with the
violates the exclusion flags. When this flag is not set, excluded path even when this violates the exclusion
the exclusion flags SHOULD also be respected for the flags.
destination node.
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 even when sharing of the said node MAY be shared with the excluded path even when this
violates the exclusion flags. When this flag is not set, violates the exclusion flags.
the exclusion flags SHOULD also be respected for the
processing node.
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
may be shared even when sharing of the said node of the LSP being signaled MAY be shared with the
violates the exclusion flags. When this flag is not set, excluded path even when this violates the exclusion
the exclusion flags SHOULD also be respected for the flags.
penultimate node.
Exclusion Flags Exclusion Flags
The Exclusion-Flags are used to communicate desirable The Exclusion-Flags are used to communicate desirable
types of exclusion. The following flags are defined. types of exclusion. The following flags are defined.
Internet Draft draft-ietf-ccamp-lsp-diversity-00.txt
0x01 = SRLG exclusion 0x01 = SRLG 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 SRLG diverse LSP being signaled is requested to be SRLG diverse
from the route of the LSP or tunnel specified by the from the excluded path specified by the LSP
LSP subobject. subobject.
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 route of the LSP or tunnel specified by the from the excluded path specified by the LSP
LSP subobject. The node exclusion is subobject to the subobject.
setting of the "Processing node exception", the
"Penultimate node exception" and the "Destination (Note: the meaning of this flag may be modified by
node exception" 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 route of the LSP or tunnel specified by the from the path specified by the LSP subobject.
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-00.txt 2.2.2. IPv6 Point-to-Point Path subobject
2.2.2. IPv6 Point-to-Point LSP 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 9, line 46 skipping to change at page 9, line 44
| IPv4 tunnel sender address (cont.) | | IPv4 tunnel sender address (cont.) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 tunnel sender address (cont.) | | IPv4 tunnel sender address (cont.) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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.
Internet Draft draft-ietf-ccamp-lsp-diversity-00.txt 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
IPv6 Point-to-Point LSP subobject IPv6 Point-to-Point Path subobject
(to be assigned by IANA suggested value: 36). (to be assigned by IANA; suggested value: 37).
Length Length
The length contains the total length of the subobject in The length contains the total length of the subobject in
bytes, including the type and length fields. The length is bytes, including the type and length fields. The length is
always 48. always 48.
The Attribute Flags and Exclusion Flags are as defined for the The Attribute Flags and Exclusion Flags are as defined for the
IPv4 Point-to-Point LSP subobject. IPv4 Point-to-Point LSP XRO subobject.
The remaining fields are as defined in [RFC3209]. The remaining fields are as defined in [RFC3209].
2.3. Processing rules for the LSP subobject 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 node is the destination for the LSP being signaled, it If the processing node is the destination for the LSP being
SHOULD NOT process a LSP 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 (LSP2) respects the requested exclusion flags the signaled LSP respects the requested exclusion flags with
with respect to the route traversed by the LSP(s) referenced by respect to the excluded path referenced by the subobject,
the LSP subobject (LSP1/TUNNEL1), 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 SHOULD return a requested constraint, the processing node MUST return a PathErr
PathErr with the error code "Routing Problem (24)" and error with the error code "Routing Problem" (24) and error sub-code
value "Route blocked by Exclude Route (67)". "Route blocked by Exclude Route" (67).
- If the route of the LSP or tunnel (LSP1/TUNNEL1) referenced in
the LSP subobject is unknown to the processing node, the
processing node SHOULD ignore the LSP subobject in the XRO and
SHOULD proceed with the signaling request (for LSP2). However,
Internet Draft draft-ietf-ccamp-lsp-diversity-00.txt
in this case, after sending Resv for LSP2, the processing node
SHOULD return a PathErr with the error code "Notify Error (25)"
and error value "Route of XRO LSP unknown (value: to be
assigned by IANA, suggest value: 13)" for LSP2.
- If latter, the route of the LSP or tunnel (LSP1/TUNNEL1)
referenced in the LSP subobject becomes known (e.g. when LSP1
is signaled) or the TUNNEL1 is re-optimized to a different
route, such that the requested exclusion/ diversity constraints
are no longer satisfied and a path that can satisfy the
requested constraints exists, the node calculating or expanding
the path SHOULD send a PathErr message for LSP2 with the error
code "Notify Error (25)" and error value "Preferable path
exists (6)". An ingress node receiving this error code/value
combination MAY try to reoptimize the LSP2 to the new preferred
path.
- Route computation for the LSP or tunnel (LSP1/ TUNNEL1) - If the excluded path referenced in the LSP subobject is
referenced in the LSP subobject for new setup or for re- unknown to the processing node, the processing node SHOULD
optimization LSP SHOULD be performed to avoid situation where ignore the LSP subobject in the XRO and SHOULD proceed with the
the requested exclusion/ diversity constraints are no longer signaling request. After sending the Resv for the signaled LSP,
satisfied and a path that can satisfy the requested constraints the processing node SHOULD return a PathErr with the error code
does not exist. However, if such situation arises the node that "Notify Error" (25) and error sub-code "Route of XRO path
computed or expanded the route for LSP2 SHOULD send a PathErr unknown" (value to be assigned by IANA, suggested value: 13)
message for LSP2 with the error code "Routing Problem (24)" and for the signaled LSP.
error value "Route blocked by Exclude Route (67)".
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 route traversed by the referenced flags with respect to the excluded path as far as possible.
LSP(s) (LSP1/TUNNEL1) 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 proceeds with a suitable route requested constraint, it SHOULD proceed with signaling using a
that best meets the constraint, but after completion of suitable route that meets the constraint as far as possible.
signaling setup, it SHOULD return a PathErr code "Notify Error After sending the Resv for the signaled LSP, it SHOULD return a
(25)" and error value "Failed to respect Exclude Route (value: PathErr message with error code "Notify Error" (25) and error
to be assigned by IANA, suggest value: 14)" to the ingress sub-code "Failed to respect Exclude Route" (value: to be
node. assigned by IANA, suggest value: 14) to the source node.
- If the route of the LSP or tunnel (LSP1/TUNNEL1) referenced in - If the excluded path referenced in the LSP subobject is
the LSP subobject is unknown to the processing node, the unknown to the processing node, the processing node SHOULD
processing node SHOULD ignore the LSP subobject in XRO and ignore the LSP subobject in the XRO and SHOULD proceed with the
SHOULD proceed with the signaling request (for LSP2). However, signaling request. After sending the Resv for signaled LSP, the
in this case, after sending Resv for LSP2, the processing node processing node SHOULD return a PathErr message with the error
code "Notify Error" (25) and error sub-code "Route of XRO path
unknown" for the signaled LSP.
Internet Draft draft-ietf-ccamp-lsp-diversity-00.txt If, subsequent to the initial signaling of a diverse LSP:
SHOULD return a PathErr with the error code "Notify Error" and - an excluded path referenced in the diverse LSP's XRO
error value "Route to XRO LSP unknown" for LSP2. subobject becomes known to the processing node (e.g. when the
excluded path is signaled), or
- If latter, the route of the LSP or tunnel (LSP1/TUNNEL1) - A change in the excluded path becomes known to the processing
referenced in the LSP subobject becomes known (e.g. when LSP1 node,
is signaled) or the TUNNEL1 is re-optimized to a different
route, such that the requested exclusion/ diversity constraints
are no longer satisfied and a path that can satisfy the
requested constraints exists, the node calculating or expanding
the path SHOULD send a PathErr message for LSP2 with the error
code "Notify Error (25)" and error value "Preferable path
exists". An ingress node receiving this error code/value
combination MAY try to reoptimize the LSP2 to the new preferred
path.
- Route computation for the LSP or tunnel (LSP1/ TUNNEL1) the processing node SHOULD re-evaluate the exclusion and
referenced in the LSP subobject for new setup or for re- diversity constraints requested by the diverse LSP to determine
optimization LSP SHOULD be performed to avoid situation where whether they are still satisfied.
the requested exclusion/ diversity constraints are no longer
satisfied and a path that can satisfy the requested constraints
does not exist. However, if such situation arises the node that
computed or expanded the route for LSP2 SHOULD send a PathErr
message for LSP2 with the error code "Notify Error" and error
value "Failed to respect Exclude Route".
The following rules apply equally to L = 0 and L = 1 case: - If the requested exclusion constraints for the diverse LSP
are no longer satisfied and an alternative route for the
diverse LSP that can satisfy those constraints exists, the
processing node SHOULD send a PathErr message for the diverse
LSP with the error code "Notify Error" (25) and error sub-code
"Preferable path exists" (6). A source node receiving a PathErr
message with this error code and sub-code combination MAY try
to reoptimize the diverse tunnel to the new compliant path.
- XRO object MAY contain multiple LSP subobjects. In this case, - If the requested exclusion constraints for the diverse LSP
the processing node A node receiving a Path message carrying an are no longer satisfied and no alternative path for the diverse
XRO MAY reject the message if the XRO is too large or LSP that can satisfy those constraints exists, then:
complicated for the local implementation or the rules of local
policy, as per the roles of XRO defined in [RFC4874]. In this
case, the node MUST send a PathErr message with the error
code "Routing Error" and error value "XRO Too Complex". An
ingress node receiving this error code/value combination MAY
reduce the complexity of the XRO or route around the node that
rejected the XRO.
- An ingress node receiving PathErr with the error code "Notify o If the L-flag was not set in the original exclusion, the
Error" and error values "Route to XRO LSP unknown" or "Failed processing node MUST send a PathErr message for the
to respect Exclude Route" MAY take no action other than simply diverse LSP with the error code "Routing Problem" (24) and
logging these notifications. error sub-code "Route blocked by Exclude Route" (67). The
PSR flag SHOULD NOT be set.
Note that LSP1 may be signaled with an XRO LSP subobject o If the L-flag was set in the original exclusion, the
referencing CircuitID2 (LSP2 FEC) and LSP2 may be signaled with processing node SHOULD send a PathErr message for the
an XRO LSP subobject referencing CircuitID1 (LSP1 FEC). The diverse LSP with the error code error code "Notify Error"
above-mentioned processing rules cover this case. In fact, if (25) and error sub-code "Failed to respect Exclude Route"
(value: to be assigned by IANA, suggest value: 14).
Internet Draft draft-ietf-ccamp-lsp-diversity-00.txt The following rules apply whether or not the L-flag is set:
"LSP ID to be ignored" attribute flag is set when LSP1 is - An XRO object MAY contain multiple path subobjects.
signaled with an XRO LSP subobject referencing CircuitID2, it is
RECOMMENDED that LSP2 is signaled with an XRO LSP subobject
referencing CircuitID1.
2.4. LSP Subobject in Explicit Exclusion Route Subobject (EXRS) - 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.
[RFC4874] defines an ERO subobject called Explicit Exclusion - A source node receiving a PathErr message with the error code
Route Subobject (EXRS). An EXRS is used to identify abstract "Notify Error" (25) and error sub-codes "Route of XRO path
nodes or resources that must not or should not be used on the unknown" or "Failed to respect Exclude Route" MAY take no
path between two inclusive abstract nodes or resources in the action.
explicit route. An EXRS contains one or more subobjects of its
own, called EXRS subobjects [RFC4874].
An EXRS MAY include an IPv4 Point-to-Point (P2P) LSP subobject. - The attribute-flags affect the processing of the XRO subobject
In this case, EXRS would look as follows: as follows:
o When the "LSP ID to be ignored" flag is set, the
processing node MUST calculate a route based on exclusions
from the routes of all known LSPs matching the tunnel-id,
source, destination and extended tunnel-id specified in
the subobject. When this flag is not set, the lsp-id is
not ignored and the exclusion applies only to the
specified LSP (i.e., LSP level exclusion).
o When the "destination node exception" flag is not set, the
exclusion flags SHOULD also be respected for the
destination node.
o When the "processing node exception" flag is not set, the
exclusion flags SHOULD also be respected for the
processing node.
o When the "penultimate node exception" flag is not set, the
exclusion flags SHOULD also be respected for the
penultimate node.
2.4. Path EXRS Subobject
[RFC4874] defines the EXRS ERO subobject. An EXRS is used to
identify abstract nodes or resources that must not or should not
be used on the path between two inclusive abstract nodes or
resources in the explicit route. An EXRS contains one or more
subobjects of its own, called EXRS subobjects [RFC4874].
An EXRS MAY include an IPv4 Point-to-Point (P2P) Path subobject
as specified in section 2.2.1. In this case, the EXRS format
would be as follows:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|L| Type | Length | Reserved | |L| Type | Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|L| Type | Length |Attribute Flags|Exclusion Flags| |L| Type | Length |Attribute Flags|Exclusion Flags|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 tunnel end point address | | IPv4 tunnel end point address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Must Be Zero | Tunnel ID | | Must Be Zero | Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extended Tunnel ID | | Extended Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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 is as defined in
[RFC4874]. Similarly, the meaning of respective fields in IPv4 [RFC4874]. The meaning of respective fields in IPv4 P2P Path
P2P LSP subobject is as defined earlier in this document. This is subobject is as defined earlier in this document. This is with
with the exceptions that: the exceptions that:
- Processing node exception applies to the node processing the - The processing node exception applies to the node processing
ERO. the ERO.
Internet Draft draft-ietf-ccamp-lsp-diversity-00.txt - 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.
- If L bit in the ERO header is not set (ERO.L = 0), the IPv4 - The penultimate node exception applies to the penultimate node
P2P LSP subobject is processed against the LSPs for which the of the loose hop. This flag is only processed if the ERO.L bit
processing node is ingress, egress or a transit node. is set, i.e. in the loose ERO hop case.
- Penultimate node exception applies to the penultimate node of - The destination node exception applies to the last explicit
the loose hop. This flag is only processed if EXRS.L bit is node to which the loose hop is expanded. This flag is only
set, i.e., in the loose ERO hop case. processed if ERO.L bit is set, i.e., in the loose ERO hop case.
- Destination node exception applies to the abstract node to 2.4.1. Processing Rules for the EXRS with Path subobject
which the route is expanded. This flag is only processed if
EXRS.L bit is set, i.e., in the loose ERO hop case.
2.4.1. Processing Rules for the EXRS with LSP subobject The processing rules for the EXRS object are unchanged from
[RFC4874]. When the EXRS contains one or more Path subobject(s),
the processing rules specified in Section 2.3 apply to the node
processing the ERO with the EXRS subobject.
Processing rules for the EXRS object are same as processing rules The EXRS scope is limited to the loose hop in which the EXRS
as described in [RFC4874]. When the EXRS contains one or more LSP appears. If loose-hop expansion results in the creation of
subobject(s), processing rule specified in Section 2.3 applies to another loose-hop in the outgoing ERO, the processing node MAY
the node processing the ERO with EXRS subobject. include the EXRS in the newly-created loose hop for further
processing by downstream nodes.
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], and above those identified in [RFC5920], [RFC2205], [RFC3209],
[RFC3473] and [RFC4874]. [RFC3473] and [RFC4874].
4. IANA Considerations 4. IANA Considerations
4.1. New XRO subobject type 4.1. New XRO subobject types
This document introduces a new subobject for the EXCLUDE_ROUTE IANA registry: RSVP PARAMETERS
Subsection: Class Names, Class Numbers, and Class Types
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 (suggest value: 36) IPv4 P2P LSP subobject To be assigned by IANA IPv4 P2P Path subobject
(suggested value: 36)
To be assigned by IANA IPv6 P2P Path subobject
(suggested value: 37)
4.2. New EXRS subobject type 4.2. New EXRS subobject types
IPv4 P2P LSP subobject is also defined as a new EXRS subobject. The IPv4 and IPv6 P2P Path subobjects are also defined as new
EXRS subobjects.
4.3. New RSVP error sub-code 4.3. New RSVP error sub-codes
For Error Code = 25 "Notify Error" (see [RFC3209]) the following IANA registry: RSVP PARAMETERS
sub-code is defined. Subsection: Error Codes and Globally-Defined Error Value Sub-
Codes
Internet Draft draft-ietf-ccamp-lsp-diversity-00.txt For Error Code "Notify Error" (25) (see [RFC3209]) the following
sub-codes are defined.
Sub-code Value Sub-code Value
-------- ----- -------- -----
Route of XRO LSP 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.
5. Acknowledgement 5. Acknowledgements
Authors would like to thanks 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,
skipping to change at page 16, line 5 skipping to change at page 16, line 30
[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 [RFC2209] Braden, R. and L. Zhang, "Resource ReSerVation Protocol
(RSVP) -- Version 1 Message Processing Rules", RFC (RSVP) -- Version 1 Message Processing Rules", RFC
2209, September 1997. 2209, September 1997.
Internet Draft draft-ietf-ccamp-lsp-diversity-00.txt
[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
 End of changes. 101 change blocks. 
348 lines changed or deleted 316 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/