draft-ietf-ccamp-crankback-03.txt   draft-ietf-ccamp-crankback-04.txt 
Network Working Group Adrian Farrel (editor) Network Working Group Adrian Farrel (editor)
Internet Draft Old Dog Consulting Internet Draft Old Dog Consulting
Category: Standards Track Category: Standards Track
Expires: April 2005 Arun Satyanarayana Expires: August 2005 Arun Satyanarayana
Movaz Networks, Inc.
Atsushi Iwata Atsushi Iwata
Norihito Fujita Norihito Fujita
NEC Corporation NEC Corporation
Gerald R. Ash (AT&T) Gerald R. Ash
AT&T
October 2004 February 2005
Crankback Signaling Extensions for MPLS Signaling Crankback Signaling Extensions for MPLS and GMPLS Signaling
<draft-ietf-ccamp-crankback-03.txt> <draft-ietf-ccamp-crankback-04.txt>
Status of this Memo Status of this Memo
By submitting this Internet-Draft, I certify that any applicable This document is an Internet-Draft and is subject to all provisions
patent or other IPR claims of which I am aware have been disclosed, of Section 3 of RFC 3667. By submitting this Internet-Draft, each
or will be disclosed, and any of which I become aware will be author represents that any applicable patent or other IPR claims of
disclosed, in accordance with RFC 3668. which he or she is aware have been or will be disclosed, and any of
which he or she become aware will be disclosed, in accordance with
RFC 3668.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts. groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be The list of Internet-Draft Shadow Directories can be
accessed at http://www.ietf.org/shadow.html. accessed at http://www.ietf.org/shadow.html.
Abstract Abstract
In a distributed, constraint-based routing environment, the In a distributed, constraint-based routing environment, the
information used to compute a path may be out of date. This means information used to compute a path may be out of date. This means
that Multiprotocol Label Switching (MPLS) label switched path (LSP) that Multiprotocol Label Switching (MPLS) and Generalized MPLS
setup requests may be blocked by links or nodes without sufficient (GMPLS) Traffic Engineered (TE) Label Switched Path (LSP) setup
requests may be blocked by links or nodes without sufficient
resources. Crankback is a scheme whereby setup failure information is resources. Crankback is a scheme whereby setup failure information is
returned from the point of failure to allow new setup attempts to be returned from the point of failure to allow new setup attempts to be
made avoiding the blocked resources. Crankback can also be applied to made avoiding the blocked resources. Crankback can also be applied to
LSP restoration to indicate the location of the failed link or node. LSP restoration to indicate the location of the failed link or node.
This document specifies crankback signaling extensions for use in This document specifies crankback signaling extensions for use in
MPLS signaling using RSVP-TE as defined in "RSVP-TE: Extensions to MPLS signaling using RSVP-TE as defined in "RSVP-TE: Extensions to
RSVP for LSP Tunnels", RFC3209, so that the LSP setup request can be RSVP for LSP Tunnels", RFC3209, and GMPLS signaling as defined in
retried on an alternate path that detours around blocked links or "Generalized Multi-Protocol Label Switching (GMPLS) Signaling
nodes. This offers significant improvements in the successful setup Functional Description", RFC3473. These extensions mean that the LSP
and recovery ratios for LSPs, especially in situations where a large setup request can be retried on an alternate path that detours around
number of setup requests are triggered at the same time. blocked links or nodes. This offers significant improvements in the
successful setup and recovery ratios for LSPs, especially in
situations where a large number of setup requests are triggered at
the same time.
Table of Contents Table of Contents
Section A : Problem Statement Section A : Problem Statement
1. Terminology......................................................3 1. Terminology......................................................4
2. Introduction and Framework.......................................3 1.1. Control Plane and Data Plane Separation........................4
2.1. Background.....................................................3 2. Introduction and Framework.......................................5
2.2. Repair and Restoration.........................................4 2.1. Background.....................................................5
3. Discussion: Explicit Versus Implicit Re-routing Indications......5 2.2. Repair and Restoration.........................................6
4. Required Operation...............................................6 2.3. Interaction with TE Flooding Mechanisms .......................6
4.1. Resource Failure or Unavailability.............................6 3. Discussion: Explicit Versus Implicit Re-routing Indications......7
4.2. Computation of an Alternate Path...............................6 4. Required Operation...............................................8
4.2.1 Information Required for Re-routing...........................7 4.1. Resource Failure or Unavailability.............................8
4.2.2 Signaling a New Route.........................................7 4.2. Computation of an Alternate Path...............................8
4.3. Persistence of Error Information...............................7 4.2.1 Information Required for Re-routing...........................9
4.4. Handling Re-route Failure......................................7 4.2.2 Signaling a New Route.........................................9
4.5. Limiting Re-routing Attempts...................................8 4.3. Persistence of Error Information...............................9
5. Existing Protocol Support for Crankback Re-routing...............8 4.4. Handling Re-route Failure.....................................10
5.1. RSVP-TE [RFC 3209].............................................9 4.5. Limiting Re-routing Attempts..................................10
5.2. GMPLS-RSVP-TE [RFC 3473].......................................9 5. Existing Protocol Support for Crankback Re-routing..............11
5.1. RSVP-TE ......................................................12
5.2. GMPLS-RSVP-TE ................................................12
Section B : Solution Section B : Solution
6. Control of Crankback Operation..................................10 6. Control of Crankback Operation..................................12
6.1. Requesting Crankback and Controlling In-Network Re-routing....10 6.1. Requesting Crankback and Controlling In-Network Re-routing....12
6.2. Action on Detecting a Failure.................................11 6.2. Action on Detecting a Failure.................................13
6.3. Limiting Re-routing Attempts..................................11 6.3. Limiting Re-routing Attempts..................................14
6.3.1 New Status Codes for Re-routing..............................11 6.3.1 New Status Codes for Re-routing..............................14
6.4. Protocol Control of Re-routing Behavior.......................11 6.4. Protocol Control of Re-routing Behavior.......................14
7. Reporting Crankback Information.................................12 7. Reporting Crankback Information.................................15
7.1. Required Information..........................................12 7.1. Required Information..........................................15
7.2. Protocol Extensions...........................................12 7.2. Protocol Extensions...........................................15
7.3 Guidance for Use of IF_ID Error Spec TLVs......................16 7.3 Guidance for Use of IF_ID Error Spec TLVs......................19
7.3.1 General Principles...........................................16 7.3.1 General Principles...........................................19
7.3.2 Error Report TLVs............................................17 7.3.2 Error Report TLVs............................................20
7.3.3 Fundamental Crankback TLVs...................................17 7.3.3 Fundamental Crankback TLVs...................................20
7.3.4 Additional Crankback TLVs....................................18 7.3.4 Additional Crankback TLVs....................................20
7.3.5 Grouping TLVs by Failure Location............................19 7.3.5 Grouping TLVs by Failure Location............................22
7.3.6 Alternate Path identification................................20 7.3.6 Alternate Path identification................................23
7.4. Action on Receiving Crankback Information.....................20 7.4. Action on Receiving Crankback Information.....................23
7.4.1 Re-route Attempts............................................20 7.4.1 Re-route Attempts............................................23
7.4.2 Location Identifiers of Blocked Links or Nodes...............20 7.4.2 Location Identifiers of Blocked Links or Nodes...............23
7.4.3 Locating Errors within Loose or Abstract Nodes...............21 7.4.3 Locating Errors within Loose or Abstract Nodes...............24
7.4.4 When Re-routing Fails........................................21 7.4.4 When Re-routing Fails........................................24
7.4.5 Aggregation of Crankback Information.........................21 7.4.5 Aggregation of Crankback Information.........................24
7.5. Notification of Errors........................................22 7.5. Notification of Errors........................................25
7.5.1 ResvErr Processing...........................................22 7.5.1 ResvErr Processing...........................................25
7.5.2 Notify Message Processing....................................22 7.5.2 Notify Message Processing....................................25
7.6. Error Values..................................................23 7.6. Error Values..................................................26
7.7. Backward Compatibility........................................23 7.7. Backward Compatibility........................................26
8. Routing Protocol Interactions...................................23 8. Routing Protocol Interactions...................................26
9. LSP Restoration Considerations..................................24 9. LSP Restoration Considerations..................................26
9.1. Upstream of the Fault.........................................24 9.1. Upstream of the Fault.........................................27
9.2. Downstream of the Fault.......................................25 9.2. Downstream of the Fault.......................................27
10. IANA Considerations............................................25 10. IANA Considerations............................................28
10.1. Error Codes..................................................25 10.1. Error Codes..................................................28
10.2. IF_ID_ERROR_SPEC TLVs........................................25 10.2. IF_ID_ERROR_SPEC TLVs........................................28
10.3. LSP_ATTRIBUTES Object........................................25 10.3. LSP_ATTRIBUTES Object........................................28
11. Security Considerations........................................26 11. Security Considerations........................................28
12. Acknowledgments................................................26 12. Acknowledgments................................................29
13. Intellectual Property Considerations...........................26 13. Intellectual Property Considerations...........................29
14. Normative References...........................................26 14. Normative References...........................................29
15. Informational References.......................................27 15. Informational References.......................................30
16. Authors' Addresses.............................................28 16. Authors' Addresses.............................................31
17. Disclaimer of Validity.........................................29 17. Disclaimer of Validity.........................................32
18. Full Copyright Statement.......................................29 18. Full Copyright Statement.......................................32
A. Experience of Crankback in TDM-based Networks..................30 A. Experience of Crankback in TDM-based Networks..................33
Section A : Problem Statement Section A : Problem Statement
0. Changes 0. Changes
(This section to be removed before publication as an RFC.) (This section to be removed before publication as an RFC.)
0.1 Changes from 01 to 02, and 02 to 03 Versions 0.1 Changes from 03 to 04 Version
- Content of NODE_ID TLV changes from Router ID to TE Router ID.
- Clarification that the MPLS LSPs referenced are TE LSPs.
- More open inclusion of GMPLS alongside MPLS.
- Note that bundling draft changes obsoletes the use of component ID
TLVs. Remove unnumbered component interface id TLVs and renumber
other TLVs.
- New section explaining control plane and data plane separation.
- New section on the interaction with TE flooding mechanisms.
- Clarify the use of the history table.
- Clarify the way that the retry counting is used.
- Typos.
0.2 Changes from 01 to 02, and 02 to 03 Versions
- Update IPR and copyright - Update IPR and copyright
- Update references - Update references
0.2 Changes from 00 to 01 Versions 0.3 Changes from 00 to 01 Versions
- Removal of background descriptive material pertaining to TDM - Removal of background descriptive material pertaining to TDM
network experience from section 3 to an Appendix. network experience from section 3 to an Appendix.
- Removal of definition of Error Spec TLVs for unnumbered bundled - Removal of definition of Error Spec TLVs for unnumbered bundled
links from section 7.2 to a separate document. links from section 7.2 to a separate document.
- More detailed guidance on which Error Spec TLVs to use when. - More detailed guidance on which Error Spec TLVs to use when.
- Change LSP_ATTRIBUTE flags from hex values to bit numbers. - Change LSP_ATTRIBUTE flags from hex values to bit numbers.
- Typographic errors fixed. - Typographic errors fixed.
- Update references. - Update references.
1. Terminology 1. Terminology
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 [RFC2119]. document are to be interpreted as described in [RFC2119].
1.1. Control Plane and Data Plane Separation
Throughout this document the processes and techniques are described
as though the control plane and data plane elements that comprose a
Label Switching Router (LSR) are coresident and related in a
one-to-one manner. This is a convenience of documentaiton only.
It should be noted that GMPLS LSRs may be decomposed such that the
control plane components are not physically collocated. Further, one
presence in the control plane may control more than one LSR in the
data plane. These points have several consequences with respect to
this document:
o The nodes, links and resources that are reported as in error, are
data plane entities.
o The nodes, areas and ASs that report that they have attempted
re-routing, are control plane entities.
o Where a single control plane entity is responsible for more than
one data plane LSR, crankback signaling may be implicit in just
the same way as LSP establishment signaling may be.
The above points may be considered self-evident, but are stated
here for absolute clarity.
The stylistic convenience of refering to both the control plane
element responsible for a single LSR and the data plane component of
that LSR simply as "the LSR", should not be taken to mean that this
document is applicable only to a colocated one-to-one relationship.
Further, in the majority case the control plane and data plane
components are related in a 1:1 ratio and are usually collocated.
2. Introduction and Framework 2. Introduction and Framework
2.1. Background 2.1. Background
RSVP-TE (RSVP Extensions for LSP Tunnels) [RFC3209] can be RSVP-TE (RSVP Extensions for LSP Tunnels) [RFC3209] can be used for
used for establishing explicitly routed LSPs in an MPLS establishing explicitly routed LSPs in an MPLS network. Using
network. Using RSVP-TE, resources can also be reserved RSVP-TE, resources can also be reserved along a path to guarantee
along a path to guarantee or control QoS for traffic or control QoS for traffic carried on the LSP. To designate an
carried on the LSP. To designate an explicit path that explicit path that satisfies QoS constraints, it is necessary to
satisfies QoS constraints, it is necessary to discern the discern the resources available to each link or node in the network.
resources available to each link or node in the network. For the collection of such resource information, routing protocols,
For the collection of such resource information, routing such as OSPF and IS-IS , can be extended to distribute additional
protocols, such as OSPF and IS-IS , can be extended to state information [RFC2702].
distribute additional state information [RFC2702].
Explicit paths can be computed based on the distributed Explicit paths can be computed based on the distributed information
information at the LSR initiating an LSP and signaled as at the LSR initiating an LSP and signaled as Explicit Routes during
Explicit Routes during LSP establishment. Explicit Routes LSP establishment. Explicit Routes may contain 'loose hops' and
may contain 'loose hops' and 'abstract nodes' that convey 'abstract nodes' that convey routing through any of a collection of
routing through any of a collection of nodes. This nodes. This mechanism may be used to devolve parts of the path
mechanism may be used to devolve parts of the path
computation to intermediate nodes such as area border LSRs. computation to intermediate nodes such as area border LSRs.
In a distributed routing environment, however, the In a distributed routing environment, however, the resource
resource information used to compute a constraint-based information used to compute a constraint-based path may be out of
path may be out of date. This means that a setup request date. This means that a setup request may be blocked, for example,
may be blocked, for example, because a link or node along because a link or node along the selected path has insufficient
the selected path has insufficient resources. resources.
In RSVP-TE, a blocked LSP setup may result in a PathErr In RSVP-TE, a blocked LSP setup may result in a PathErr message sent
message sent to the initiator, or a ResvErr sent to the to the initiator, or a ResvErr sent to the terminator (egress LSR).
terminator (egress LSR). These messages may result in the These messages may result in the LSP setup being abandoned. In
LSP setup being abandoned. In Generalized MPLS [RC3473] Generalized MPLS [RC3473] the Notify message may additionally be
the Notify message may additionally be used to expedite used to expedite notification of LSP failures to ingress and egress
notification of LSP failures to ingress and egress LSRs, LSRs, or to a specific "repair point".
or to a specific "repair point".
These existing mechanisms provide a certain amount of These existing mechanisms provide a certain amount of information
information about the path of the failed LSP. about the path of the failed LSP.
Generalized MPLS [RFC3471] and [RFC3473] extends MPLS into networks
that manage Layer 2, TDM and lambda resources as well as packet
resources. Thus, crankback routing is also useful in GMPLS networks.
In a network without wavelength converters, setup requests are likely
to be blocked more often than in a conventional MPLS environment
because the same wavelength must be allocated at each Optical
Cross-Connect on an end-to-end explicit path. This makes crankback
routing all the more important in certain GMPLS networks.
2.2. Repair and Restoration 2.2. Repair and Restoration
If the ingress LSR or intermediate area border LSR knows If the ingress LSR or intermediate area border LSR knows the location
the location of the blocked link or node, the LSR can of the blocked link or node, it can designate an alternate path and
designate an alternate path and then reissue the setup then reissue the setup request. Determination of the identity of the
request. Determination of the identity of the blocked blocked link or node can be achieved by the mechanism known as
link or node can be achieved by the mechanism known as crankback routing [PNNI, ASH1]. In RSVP-TE, crankback signaling
crankback routing [PNNI, ASH1]. In RSVP-TE, crankback requires notifying the upstream LSR of the location of the blocked
signaling requires notifying an upstream LSR of the link or node. In some cases this requires more information than is
location of the blocked link or node. In some cases this currently available in the signaling protocols.
requires more information than is currently available in
the signaling protocols.
On the other hand, various restoration schemes for link On the other hand, various restoration schemes for link or node
or node failures have been proposed in [RFC3469] and failures have been proposed in [RFC3469] and include fast
include fast restoration. These schemes rely on restoration. These schemes rely on the existence of a backup LSP to
the existence of a backup LSP to protect the primary, but protect the primary, but if both the primary and backup paths fail it
if both the primary and backup paths fail it is necessary is necessary to re-establish the LSP on an end-to-end basis avoiding
to re-establish the LSP on an end-to-end basis avoiding the known failures. Similarly, fast restoration by establishing a
the known failures. Similarly, fast restoration by restoration path on demand after failure requires computation of a
establishing a restoration path on demand after failure new LSP that avoids the known failures. End-to-end restoration for
requires computation of a new LSP that avoids the known alternate routing requires the location of the failed link or node.
failures. End-to-end restoration for alternate routing Crankback routing schemes could be used to notify the upstream LSRs
requires the location of the failed link or node. of the location of the failure.
Crankback routing schemes could be used to notify
upstream LSRs of the location of the failure.
Furthermore, in situations where many link or node Furthermore, in situations where many link or node failures occur at
failures occur at the same time, the difference between the same time, the difference between the distributed routing
the distributed routing information and the real-time information and the real-time network state becomes much greater than
network state becomes much greater than in normal LSP in normal LSP setups. LSP restoration might, therefore, be performed
setups. LSP restoration might, therefore, be performed
with inaccurate information, which is likely to cause
setup blocking. Crankback routing could improve failure
recovery in these situations.
Generalized MPLS [RFC3471] extends MPLS into networks with inaccurate information, which is likely to cause setup blocking.
that manage Layer 2, TDM and lambda resources. In a Crankback routing could improve failure recovery in these situations.
network without wavelength converters, setup requests are
likely to be blocked more often than in a conventional The requirement for end-to-end allocation of lambda resources in
MPLS environment because the same wavelength must be GMPLS networks without wavelength converters means that end-to-end
allocated at each Optical Cross-Connect on an end-to-end restoration is the only way to recover LSP failures. This makes
explicit path. Furthermore, end-to-end restoration is the crankback rerouting particularly useful in a GMPLS network, in
only way to recover LSP failures. This implies that particular in dynamic LSP re-routing cases (no backup LSP
crankback routing would also be useful in a GMPLS pre-establishment).
network, in particular in dynamic LSP re-routing cases
(no backup LSP pre-establishment). 2.3. Interaction with TE Flooding Mechanisms
GMPLS uses IGPs (OSPF and IS-IS) to flood traffic engineering (TE)
information that is used to construct a traffic engineering database
(TED) which acts as a data source for path computation.
Crankback signaling is not intended to supplement or replace the
normal operation of the TE flooding mechanism, since these mechanisms
are independent of each other. That is, information gathered from
crankback signaling may be applied to compute an alternate path for
the LSP for which the information was signaled, but the information
is not intended to be used to influence the computation of the paths
of other LSPs.
Any requirement to rapidly flood updates about resource availability
so that they may be applied as deltas to the TED and utilized in
future path computations are out of scope of this document.
3. Discussion: Explicit Versus Implicit Re-routing Indications 3. Discussion: Explicit Versus Implicit Re-routing Indications
There have been problems in service provider networks There have been problems in service provider networks when
when "inferring" from indirect information that re-routing "inferring" from indirect information that re-routing is allowed.
is allowed. This document proposes the use of an explicit This document proposes the use of an explicit re-routing indication
re-routing indication that explicitly authorizes re-routing. that explicitly authorizes re-routing.
Various existing protocol options and exchanges including Various existing protocol options and exchanges including the error
the error values of PathErr message [RFC2205, RFC3209] values of PathErr message [RFC2205, RFC3209] and the Notify message
and the Notify message [RFC3473] allow an implementation [RFC3473] allow an implementation to infer a situation where
to infer a situation where re-routing can be done. This re-routing can be done. This allows for recovery from network errors
allows for recovery from network errors or resource or resource contention.
contention.
However, such inference of recovery signaling is not always However, such inference of recovery signaling is not always desirable
desirable since it may be doomed to failure. For example, since it may be doomed to failure. For example, experience of using
experience of using release messages in TDM-based networks for release messages in TDM-based networks for analogous implicit and
analogous implicit and explicit re-routing indications purposes explicit re-routing indications purposes provides some guidance. This
provides some guidance. This background information is given in background information is given in Appendix A.
Appendix A."
It is certainly the case that with topology exchange, It is certainly the case that with topology exchange, such as OSPF,
such as OSPF, the ingress LSR could infer the re-routing the ingress LSR could infer the re-routing condition. However,
condition. However, convergence of routing information is convergence of routing information is typically slower than the
typically slower than the expected LSP setup times. One of expected LSP setup times. One of the reasons for crankback is to
the reasons for crankback is to avoid the overhead of avoid the overhead of available-link-bandwidth flooding, and to more
available-link-bandwidth flooding, and to more efficiently efficiently use local state information to direct alternate routing
use local state information to direct alternate routing at the path computation point.
at the ingress-LSR.
[ASH1] shows how event-dependent-routing can just use crankback, [ASH1] shows how event-dependent-routing can just use crankback, and
and not available-link-bandwidth flooding, to decide on the not available-link-bandwidth flooding, to decide on the re-route path
re-route path in the network through "learning models". Reducing in the network through "learning models". Reducing this flooding
this flooding reduces overhead and can lead to the ability to reduces overhead and can lead to the ability to support much larger
support much larger AS sizes. AS sizes.
Therefore, the alternate routing should be indicated based on Therefore, the alternate routing should be indicated based on an
an explicit indication, and it is best to know the following explicit indication, and it is best to know the following information
information separately: separately:
- where blockage/congestion occurred - where blockage/congestion occurred
- whether alternate routing "should" be attempted. - whether alternate routing "should" be attempted.
4. Required Operation 4. Required Operation
Section 2 identifies some of the circumstances under which Section 2 identifies some of the circumstances under which crankback
crankback may be useful. Crankback routing is performed as may be useful. Crankback routing is performed as described in the
described in the following procedures, when an LSP setup following procedures, when an LSP setup request is blocked along the
request is blocked along the path, or when an existing LSP fails. path, or when an existing LSP fails.
4.1. Resource Failure or Unavailability 4.1. Resource Failure or Unavailability
When an LSP setup request is blocked due to unavailable When an LSP setup request is blocked due to unavailable resources, an
resources, an error message response with the location error message response with the location identifier of the blockage
identifier of the blockage should be returned to the LSR should be returned to the LSR initiating the LSP setup (ingress LSR),
initiating the LSP setup (ingress LSR), the area border the area border LSR, the AS border LSR, or to some other repair
LSR, the AS border LSR, or to some other repair point. point.
This error message carries an error specification This error message carries an error specification according to
according to [RFC3209] - this indicates the cause of the [RFC3209] - this indicates the cause of the error and the node/link
error and the node/link on which the error occurred. on which the error occurred. Crankback operation may require further
Crankback operation may require further information as information as detailed in sections 4.2.1 and 7.
detailed in sections 4.2.1 and 7.
4.2. Computation of an Alternate Path 4.2. Computation of an Alternate Path
In a flat network without partitioning, when the ingress In a flat network without partitioning, when the ingress LSR receives
LSR receives the error message it computes an alternate the error message it computes an alternate path around the blocked
path around the blocked link or node to satisfy QoS link or node to satisfy QoS constraints using link state information
constraints using link state information about the network. about the network. If an alternate path is found, a new LSP setup
If an alternate path is found, a new LSP setup request is request is sent over this path.
sent over this path.
On the other hand, in a network partitioned into areas On the other hand, in a network partitioned into areas such as with
such as with hierarchical OSPF, an area border LSR may hierarchical OSPF, the area border LSR may intercept and terminate
intercept and terminate the error response, and perform the error response, and perform alternate (re-)routing within the
alternate (re-)routing within the downstream area. downstream area.
In a third scenario, any node within an area may act as a In a third scenario, any node within an area may act as a repair
repair point. In this case, each LSR behaves much as an point. In this case, each LSR behaves much as an area border LSR as
area border LSR as described above. It can intercept and described above. It can intercept and terminate the error response,
terminate the error response, and perform alternate and perform alternate routing. This may be particularly useful where
routing. This may be particularly useful where domains of domains of computation are applied within the network, however if
computation are applied within the network, however if all nodes in the network perform re-routing it is possible to spend
all nodes in the network perform re-routing it is excessive network and CPU resources on re-routing attempts that would
possible to spend excessive network and CPU resources on be better made only at designated re-routing nodes. This scenario is
re-routing attempts that would be better made only at somewhat like 'MPLS fast re-route' [FASTRR], in which any node in the
designated re-routing nodes. This scenario is somewhat MPLS domain can establish 'local repair' LSPs after failure
like 'MPLS fast re-route' [FASTRR], in which any node in notification.
the MPLS domain can establish 'local repair' LSPs after
failure notification.
4.2.1 Information Required for Re-routing 4.2.1 Information Required for Re-routing
In order to correctly compute a route that avoids the In order to correctly compute a route that avoids the blocking
blocking problem, a repair point LSR must gather as much problem, a repair point LSR must gather as much crankback information
crankback information as possible. Ideally, the repair as possible. Ideally, the repair node will be given the node, link
node will be given the node, link and reason for the and reason for the failure.
failure.
However, this information may not be enough to help with However, this information may not be enough to help with
re-computation. Consider for instance an explicit route re-computation. Consider for instance an explicit route that contains
that contains a non-explicit abstract node or a loose a non-explicit abstract node or a loose hop. In this case, the failed
hop. In this case, the failed node and link is not node and link is not necessarily enough to tell the repair point
necessarily enough to tell the repair point which hop in which hop in the explicit route has failed. The crankback information
the explicit route has failed. The crankback information
needs to provide the context into the explicit route. needs to provide the context into the explicit route.
4.2.2 Signaling a New Route 4.2.2 Signaling a New Route
If the crankback information can be used to compute a new If the crankback information can be used to compute a new route
route avoiding the blocking problem, the route can be avoiding the blocking problem, the route can be signaled as an
signaled as an Explicit Route. Explicit Route.
However, it may be that the repair point does not have However, it may be that the repair point does not have sufficient
sufficient topology information to compute an Explicit topology information to compute an Explicit Route that is guaranteed
Route that is guaranteed to avoid the failed link or to avoid the failed link or node. In this case, Route Exclusions
node. In this case, Route Exclusions [EXCLUDE] may be [EXCLUDE] may be particularly helpful. To achieve this, [EXCLUDE]
particularly helpful. To achieve this, [EXCLUDE] allows allows the crankback information to be presented as route exclusions
the crankback information to be presented as route exclusions
to force avoidance of the failed node, link or resource. to force avoidance of the failed node, link or resource.
4.3. Persistence of Error Information 4.3. Persistence of Error Information
The repair point LSR that computes the alternate path The repair point LSR that computes the alternate path should store
should store the location identifiers of the blockages the location identifiers of the blockages indicated in the error
indicated in the error message until the LSP is message until the LSP is successfully established by downstream LSRs
successfully established or until the LSR abandons re-routing or until the repair point LSR abandons re-routing attempts. Since
attempts. Since crankback routing may happen more than once crankback signaling information may be returned to the same repair
while establishing a specific LSP, a history table of all point LSR more than once while establishing a specific LSP, the
experienced blockages for this LSP SHOULD be maintained (at repair point LSR SHOULD maintain a history table of all experienced
least until the routing protocol updates the state of this blockages for this LSP (at least until the routing protocol updates
information) to perform an accurate path computation to the state of this information) to perform an accurate path
detour all blockages. computation to detour all blockages.
If a second error response is received by a repair point (while If a second error response is received by a repair point (while it is
it is performing crankback re-routing) it should update the performing crankback re-routing) it should update the history table
history table that lists all experienced blockages, and use the that lists all experienced blockages, and use the entire gathered
entire gathered information when making a further re-routing attempt. information when making a further re-routing attempt.
Note that the purpose of this history table is to correlate
information when repeated retry attempts are made by the same LSR.
For example, suppose that an attempt is made to route from A through
B, and B returns a failure with crankback information, an attempt may
be made to route from A through C, and this may also fail with the
return of crankback information - the next attempt SHOULD NOT be to
route from A through B, and this may be achieved by use of the
history table.
The history table can be discarded by the signaling controller for A
if the LSP is successfully established through A. The history table
MAY be retained after the signaling controller for A sends an error
upstream, however it is questionable what value this provides since a
future retry as a result of crankback rerouting should not attempt to
route through A (such is the nature of crankback). If the history
information is retained for a longer period it SHOULD be discarded
after a local timeout has expired, and that timer MUST be shorter
than the timer used by the ingress to re-attempt a failed service
(note that re-attempting a failed service is not the same as making a
re-route attempt after failure).
It is not intended that the information in the history table be used
to supplement the TED for the computation of paths of other LSPs.
4.4. Handling Re-route Failure 4.4. Handling Re-route Failure
Multiple blockages (for the same LSP) may occur, and successive Multiple blockages (for the same LSP) may occur, and successive setup
setup retry attempts may fail. Retaining error information from retry attempts may fail. Retaining error information from previous
previous attempts ensures that there is no thrashing of setup attempts ensures that there is no thrashing of setup attempts, and
attempts, and knowledge of the blockages increases with each knowledge of the blockages increases with each attempt.
attempt.
It may be that after several retries, a given repair point is It may be that after several retries, a given repair point is unable
unable to compute a path to the destination (that is, the egress to compute a path to the destination (that is, the egress of the LSP)
of the LSP) that avoids all of the blockages. In this case, it that avoids all of the blockages. In this case, it must pass the
must pass the error indication upstream. It is most useful to the error indication upstream. It is most useful to the upstream nodes
upstream nodes (and in particular the ingress LSR) that may, (and in particular the ingress LSR) that may, themselves, attempt new
themselves, attempt new routes for the LSP setup, if the error routes for the LSP setup, if the error indication in this case
indication in this case identifies all of the downstream blockages identifies all of the downstream blockages and also the node that has
and also the node that has been unable to compute an alternate path. been unable to compute an alternate path.
4.5. Limiting Re-routing Attempts 4.5. Limiting Re-routing Attempts
It is important to prevent an endless repetition of LSP It is important to prevent an endless repetition of LSP setup
setup attempts using crankback routing information after attempts using crankback routing information after error conditions
error conditions are signaled, or during periods of high are signaled, or during periods of high congestion. It may also be
congestion. It may also be useful to reduce the number of useful to reduce the number of retries, since failed retries will
retries, since failed retries will increase setup latency increase setup latency and degrade performance.
and degrade performance.
The maximum number of crankback re-routing attempts
allowed may be limited in a variety of ways. The number
may be limited by LSP, by node, by area or by AS. Control
of the limit may be applied as a configuration item per
LSP, per node, per area or per AS.
When the number of retries at a particular node, area or The maximum number of crankback re-routing attempts allowed may be
AS is exceeded, the LSR handling the current failure limited in a variety of ways. This document allows an LSR to limit
reports the failure upstream to the next node, area or AS the retries per LSP, and assumes that such a limit will be applied
where further re-routing attempts may be attempted. It is either as a per node configuration for those LSRs that are capable
important that the crankback information provided of rerouting, or as a network-wide configuration value.
indicates that routing back through this node, area or AS
will not succeed - this situation is similar to that in
section 4.4. Note that in some circumstances, such a
report will also mean that no further re-routing attempts
can possibly succeed - for example, when the egress node
is within the failed area.
When the maximum number of retries for a specific LSP has When the number of retries at a particular LSR is exceeded, the LSR
been exceeded, the LSR handling the current failure reports the failure upstream to the next node where further
should send an error message upstream indicating "Maximum re-routing attempts may be attempted. It is important that the
number of re-routings exceeded". This error will be crankback information provided indicates that routing back through
passed back to the ingress LSR with no further re-routing this node will not succeed - this situation is similar to that in
attempts. The ingress LSR may choose to retry the LSP section 4.4.
setup according to local policy and might choose to re-use
its original path or seek to compute a path that avoids
the blocked resources. In the latter case, it may be
useful to indicate the blocked resource in this error
message.
5. Existing Protocol Support for Crankback Re-routing 5. Existing Protocol Support for Crankback Re-routing
Crankback re-routing is appropriate for use with RSVP-TE. Crankback re-routing is appropriate for use with RSVP-TE.
1) LSP establishment may fail because of an inability to 1) LSP establishment may fail because of an inability to
route, perhaps because links are down. In this case a route, perhaps because links are down. In this case a
PathErr message is returned to the initiator. PathErr message is returned to the initiator.
2) LSP establishment may fail because resources are 2) LSP establishment may fail because resources are
unavailable. This is particularly relevant in GMPLS where unavailable. This is particularly relevant in GMPLS where
explicit label control may be in use. Again, a PathErr explicit label control may be in use. Again, a PathErr
message is returned to the initiator. message is returned to the initiator.
3) Resource reservation may fail during LSP establishment, 3) Resource reservation may fail during LSP establishment,
as the Resv is processed. If as the Resv is processed. If resources are not available on
resources are not available on the required link or at a the required link or at a specific node, a ResvErr message is
specific node, a ResvErr message is returned to the egress returned to the egress node indicating "Admission Control
node indicating "Admission Control failure" [RFC2205]. The failure" [RFC2205]. The egress is allowed to change the
egress is allowed to change the FLOWSPEC and try again, but FLOWSPEC and try again, but in the event that this is not
in the event that this is not practical or not supported practical or not supported (particularly in the GMPLS context),
(particularly in the GMPLS context), the egress LSR may the egress LSR may choose to take any one of the following
choose to take any one of the following actions. actions.
- Ignore the situation and allow recovery to happen through - Ignore the situation and allow recovery to happen through
Path refresh message and refresh timeout [RFC2205]. Path refresh message and refresh timeout [RFC2205].
- Send a PathErr message towards the initiator indicating - Send a PathErr message towards the initiator indicating
"Admission Control failure". "Admission Control failure".
- Send a ResvTear message towards the initiator to abort - Send a ResvTear message towards the initiator to abort
the LSP setup. the LSP setup.
Note that in multi-area/AS networks, the ResvErr might be Note that in multi-area/AS networks, the ResvErr might be
intercepted and acted on at an area/AS border router. intercepted and acted on at an area/AS border router.
skipping to change at line 483 skipping to change at line 547
4) It is also possible to make resource reservations on the forward 4) It is also possible to make resource reservations on the forward
path as the Path message is processed. This choice is compatible path as the Path message is processed. This choice is compatible
with LSP setup in GMPLS networks [RFC3471]. In this case if with LSP setup in GMPLS networks [RFC3471]. In this case if
resources are not available, a PathErr message is returned to resources are not available, a PathErr message is returned to
initiator indicating "Admission Control failure". initiator indicating "Admission Control failure".
Crankback information would be useful to an upstream node (such as Crankback information would be useful to an upstream node (such as
the ingress) if it is supplied on a PathErr or a Notify message that the ingress) if it is supplied on a PathErr or a Notify message that
is sent upstream. is sent upstream.
5.1. RSVP-TE [RFC 3209] 5.1. RSVP-TE
In RSVP-TE a failed LSP setup attempt results in a PathErr In RSVP-TE a failed LSP setup attempt results in a PathErr message
message returned upstream. The PathErr message carries an returned upstream. The PathErr message carries an ERROR_SPEC object,
ERROR_SPEC object, which indicates the node or interface which indicates the node or interface reporting the error and the
reporting the error and the reason for the failure. reason for the failure.
Crankback re-routing can be performed explicitly avoiding Crankback re-routing can be performed explicitly avoiding the node
the node or interface reported. or interface reported.
5.2. GMPLS-RSVP-TE [RFC 3473] 5.2. GMPLS-RSVP-TE
GMPLS extends the error reporting described above by GMPLS extends the error reporting described above by allowing LSRs to
allowing LSRs to report the interface that is in error in report the interface that is in error in addition to the identity of
addition to the identity of the node reporting the error. the node reporting the error. This further enhances the ability of a
This further enhances the ability of a re-computing node re-computing node to route around the error.
to route around the error.
GMPLS introduces a targeted Notify message that may be used to GMPLS introduces a targeted Notify message that may be used to
report LSP failures direct to a selected node. This message carries report LSP failures direct to a selected node. This message carries
the same error reporting facilities as described above. The Notify the same error reporting facilities as described above. The Notify
message may be used to expedite the propagation of error message may be used to expedite the propagation of error
notifications, but in a network that offers crankback routing at notifications, but in a network that offers crankback routing at
multiple nodes there would need to be some agreement between LSRs multiple nodes there would need to be some agreement between LSRs
as to whether PathErr or Notify provides the stimulus for crankback as to whether PathErr or Notify provides the stimulus for crankback
operation. Otherwise, multiple nodes might attempt to repair the LSP operation. Otherwise, multiple nodes might attempt to repair the LSP
at the same time, because at the same time, because
skipping to change at line 554 skipping to change at line 618
Routers or AS Border Routers. The boundary Routers or AS Border Routers. The boundary
(ABR/ASBR) can either decide to forward the (ABR/ASBR) can either decide to forward the
error message upstream to the ingress error message upstream to the ingress
LSR or try to select another egress boundary LSR or try to select another egress boundary
LSR. Other intermediate nodes SHOULD NOT LSR. Other intermediate nodes SHOULD NOT
attempt re-routing. Nodes detecting failures attempt re-routing. Nodes detecting failures
MUST report an error and SHOULD supply MUST report an error and SHOULD supply
crankback information. crankback information.
Segment-based Re-routing Segment-based Re-routing
All nodes MAY attempt re-routing after Any node MAY attempt rerouting after it
failure. Nodes detecting failures MUST report receives an error report and before it passes
an error and SHOULD supply full crankback the error report further upstream. Nodes
information. detecting failures MUST report an error and
SHOULD supply full crankback information.
6.2. Action on Detecting a Failure 6.2. Action on Detecting a Failure
A node that detects the failure to setup an LSP or the failure of an A node that detects the failure to setup an LSP or the failure of an
established LSP SHOULD act according to the Re-routing Flag passed on established LSP SHOULD act according to the Re-routing Flag passed on
the LSP setup request. the LSP setup request.
If Segment-based Re-routing is allowed, or if Boundary Re-routing is If Segment-based Re-routing is allowed, or if Boundary Re-routing is
allowed and the detecting node is an ABR or ASBR, the detecting node allowed and the detecting node is an ABR or ASBR, the detecting node
MAY immediately attempt to re-route. MAY immediately attempt to re-route.
If End-to-end Re-routing is indicated, or if Segment-based or If End-to-end Re-routing is indicated, or if Segment-based or
Boundary Re-routing is allowed and the detecting node chooses Boundary Re-routing is allowed and the detecting node chooses
not to make re-routing attempts (or has exhausted all possible not to make re-routing attempts (or has exhausted all possible
re-routing attempts), the detecting node MUST return a protocol re-routing attempts), the detecting node MUST return a protocol
error indication and SHOULD include full crankback information. error indication and SHOULD include full crankback information.
6.3. Limiting Re-routing Attempts 6.3. Limiting Re-routing Attempts
Each repair point SHOULD apply a locally configurable Each repair point SHOULD apply a locally configurable limit to the
limit to the number of attempts it makes to re-route an number of attempts it makes to re-route an LSP. This helps to prevent
LSP. This helps to prevent excessive network usage in the excessive network usage in the event of significant faults, and
event of significant faults, and allows back-off to other allows back-off to other repair points which may have a better chance
repair points which may have a better chance of routing of routing around the problem.
around the problem.
6.3.1 New Status Codes for Re-routing 6.3.1 New Status Codes for Re-routing
An error code/value of "Routing Problem"/"Re-routing An error code/value of "Routing Problem"/"Re-routing limit exceeded"
limit exceeded" (24/TBD) is used to identify that a node (24/TBD) is used to identify that a node has abandoned crankback
has abandoned crankback re-routing because it has reached re-routing because it has reached a threshold for retry attempts.
a threshold for retry attempts.
A node receiving an error response with this status code A node receiving an error response with this status code MAY also
MAY also attempt crankback re-routing, but it is RECOMMENDED attempt crankback re-routing, but it is RECOMMENDED that such
that such attempts be limited to the ingress LSR. attempts be limited to the ingress LSR.
6.4. Protocol Control of Re-routing Behavior 6.4. Protocol Control of Re-routing Behavior
The Session Attributes Object in RSVP-TE is used on Path The Session Attributes Object in RSVP-TE is used on Path messages to
messages to indicate the capabilities and attributes of the indicate the capabilities and attributes of the session. This object
session. This object contains an 8-bit flag field which is contains an 8-bit flag field which is used to signal individual
used to signal individual Boolean capabilities or attributes. Boolean capabilities or attributes. The Re-Routing Flag described in
The Re-Routing Flag described in section 5.1 would fit section 5.1 would fit naturally into this field, but there is a
naturally into this field, but there is a scarcity of bits, so scarcity of bits, so use is made of the new LSP_ATTRIBUTES object
use is made of the new LSP_ATTRIBUTES object defined in defined in [LSP-ATTRIB]. Three bits are defined for inclusion in the
[LSP-ATTRIB]. Three bits are defined for inclusion in the LSP LSP Attributes TLV as follows. The bit numbers below are suggested
Attributes TLV as follows. The bit numbers below are suggested
and actual values are TBD by IETF consensus. and actual values are TBD by IETF consensus.
Bit Name and Usage Bit Name and Usage
Number Number
1 End-to-end re-routing desired. 1 End-to-end re-routing desired.
This flag indicates the end-to-end re-routing behavior This flag indicates the end-to-end re-routing behavior
for an LSP under establishment. This MAY also be used for an LSP under establishment. This MAY also be used
for specifying the behavior of end-to-end LSP restoration for specifying the behavior of end-to-end LSP restoration
for established LSPs. for established LSPs.
skipping to change at line 638 skipping to change at line 700
This flag indicates the segment-based This flag indicates the segment-based
re-routing behavior for an LSP under re-routing behavior for an LSP under
establishment. This MAY also be used establishment. This MAY also be used
for specifying the segment-based LSP for specifying the segment-based LSP
restoration for established LSPs. restoration for established LSPs.
7. Reporting Crankback Information 7. Reporting Crankback Information
7.1. Required Information 7.1. Required Information
As described above, full crankback information SHOULD As described above, full crankback information SHOULD indicate the
indicate the node, link and other resources, which have node, link and other resources, which have been attempted but have
been attempted but have failed because of allocation failed because of allocation issues or network failure.
issues or network failure.
The default crankback information SHOULD include the The default crankback information SHOULD include the interface and
interface and the node address. the node address.
7.2. Protocol Extensions 7.2. Protocol Extensions
[RFC3473] defines an IF_ID ERROR_SPEC object that can be [RFC3473] defines an IF_ID ERROR_SPEC object that can be used on
used on PathErr, ResvErr and Notify messages to convey PathErr, ResvErr and Notify messages to convey the information
the information carried in the Error Spec Object defined carried in the Error Spec Object defined in [RFC3209]. Additionally,
in [RFC 3209]. Additionally, the IF_ID ERROR_SPEC Object the IF_ID ERROR_SPEC Object has scope for carrying TLVs that identify
has scope for carrying TLVs that identify the link the link associated with the error.
associated with the error.
The TLVs for use with this object are defined in [RFC3471], and The TLVs for use with this object are defined in [RFC3471], and are
are listed below. They are used to identify links in the IF_ID listed below. They are used to identify links in the IF_ID PHOP
PHOP Object and in the IF_ID ERROR_SPEC object to identify the Object and in the IF_ID ERROR_SPEC object to identify the failed
failed resource which is usually the downstream resource from resource which is usually the downstream resource from the reporting
the reporting node. node.
Type Length Format Description Type Length Format Description
-------------------------------------------------------------------- --------------------------------------------------------------------
1 8 IPv4 Addr. IPv4 (Interface address) 1 8 IPv4 Addr. IPv4 (Interface address)
2 20 IPv6 Addr. IPv6 (Interface address) 2 20 IPv6 Addr. IPv6 (Interface address)
3 12 Compound IF_INDEX (Interface index) 3 12 Compound IF_INDEX (Interface index)
4 12 Compound COMPONENT_IF_DOWNSTREAM (Component interface) 4 12 Compound COMPONENT_IF_DOWNSTREAM (Component interface)
5 12 Compound COMPONENT_IF_UPSTREAM (Component interface) 5 12 Compound COMPONENT_IF_UPSTREAM (Component interface)
Two further TLVs are defined in [TE-BUNDLE] for use in the IF_ID Note that TLVs 4 and 5 are obsoleted by [BUNDLE] and SHOULD NOT be
PHOP Object and in the IF_ID ERROR_SPEC object to identify component used to identify component interfaces in IF_ID ERROR_SPEC objects.
links of unnumbered interfaces. Note that the Type values shown here
are only suggested values in [TE-BUNDLE] - final values are TBD and
to be determined by IETF consensus.
Type Length Format Description
--------------------------------------------------------------------
6 16 Compound UNUM_COMPONENT_IF_DOWN (Component interface)
7 16 Compound UNUM_COMPONENT_IF_UP (Component interface)
In order to facilitate reporting of crankback information, the In order to facilitate reporting of crankback information, the
following additional TLVs are defined. Note that the Type values following additional TLVs are defined. Note that the Type values
shown here are only suggested values - final values are TBD and to be shown here are only suggested values - final values are TBD and to be
determined by IETF consensus. determined by IETF consensus.
Type Length Format Description Type Length Format Description
-------------------------------------------------------------------- --------------------------------------------------------------------
8 var See below DOWNSTREAM_LABEL (GMPLS label) 6 var See below DOWNSTREAM_LABEL (GMPLS label)
9 var See below UPSTREAM_LABEL (GMPLS label) 7 var See below UPSTREAM_LABEL (GMPLS label)
10 8 See below NODE_ID (Router Id) 8 8 See below NODE_ID (TE Router ID)
11 x See below OSPF_AREA (Area Id) 9 x See below OSPF_AREA (Area ID)
12 x See below ISIS_AREA (Area Id) 10 x See below ISIS_AREA (Area ID)
13 8 See below AUTONOMOUS_SYSTEM (Autonomous system) 11 8 See below AUTONOMOUS_SYSTEM (Autonomous system)
14 var See below ERO_CONTEXT (ERO subobject) 12 var See below ERO_CONTEXT (ERO subobject)
15 var See below ERO_NEXT_CONTEXT (ERO subobjects) 13 var See below ERO_NEXT_CONTEXT (ERO subobjects)
16 8 IPv4 Addr. PREVIOUS_HOP_IPv4 (Node address) 14 8 IPv4 Addr. PREVIOUS_HOP_IPv4 (Node address)
17 20 IPv6 Addr. PREVIOUS_HOP_IPv6 (Node address) 15 20 IPv6 Addr. PREVIOUS_HOP_IPv6 (Node address)
18 8 IPv4 Addr. INCOMING_IPv4 (Interface address) 16 8 IPv4 Addr. INCOMING_IPv4 (Interface address)
19 20 IPv6 Addr. INCOMING_IPv6 (Interface address) 17 20 IPv6 Addr. INCOMING_IPv6 (Interface address)
20 12 Compound INCOMING_IF_INDEX (Interface index) 18 12 Compound INCOMING_IF_INDEX (Interface index)
21 12 Compound INCOMING_COMP_IF_DOWN (Component interface) 19 var See below INCOMING_DOWN_LABEL (GMPLS label)
22 12 Compound INCOMING_COMP_IF_UP (Component interface) 20 var See below INCOMING_UP_LABEL (GMPLS label)
23 16 See below INCOMING_UNUM_COMP_DOWN (Component interface) 21 8 See below REPORTING_NODE_ID (Router ID)
24 16 See below INCOMING_UNUM_COMP_UP (Component interface) 22 x See below REPORTING_OSPF_AREA (Area ID)
25 var See below INCOMING_DOWN_LABEL (GMPLS label) 23 x See below REPORTING_ISIS_AREA (Area ID)
26 var See below INCOMING_UP_LABEL (GMPLS label) 24 8 See below REPORTING_AS (Autonomous system)
27 8 See below REPORTING_NODE_ID (Router Id) 25 var See below PROPOSED_ERO (ERO subobjects)
28 x See below REPORTING_OSPF_AREA (Area Id) 26 var See below NODE_EXCLUSIONS (List of nodes)
29 x See below REPORTING_ISIS_AREA (Area Id) 27 var See below LINK_EXCLUSIONS (List of interfaces)
30 8 See below REPORTING_AS (Autonomous system)
31 var See below PROPOSED_ERO (ERO subobjects)
32 var See below NODE_EXCLUSIONS (List of nodes)
33 var See below LINK_EXCLUSIONS (List of interfaces)
For types 1, 2, 3, 4 and 5, the format of the Value field
is already defined in [RFC3471].
For types 6 and 7 the format of the Value field is already For types 1, 2 and 3 the format of the Value field is already defined
defined in [TE-BUNDLE]. in [RFC3471].
For types 16 and 18, they format of the Value field is For types 14 and 16, they format of the Value field is the same as
the same as for type 1. for type 1.
For types 17 and 19, the format of the Value field is the For types 15 and 17, the format of the Value field is the same as for
same as for type 2. type 2.
For types 20, 21 and 22, the formats of the Value fields For type 18 the format of the Value field is the same as for type 3.
are the same as for types 3, 4 and 5 respectively.
For types 23 and 24 the Value field is the same as for For types 6, 7, 19 and 20 the length field is variable and the Value
types 6 and 7 respectively. field is a label as defined in [RFC3471]. As with all uses of labels,
it is assumed that any node that can process the label information
knows the syntax and semantics of the label from the context. Note
that all TLVs are zero-padded to a multiple four octets so that if a
label is not itself a multiple of four octets it must be
disambiguated from the trailing zero pads by knowledge derived from
the context.
For types 8, 9, 25 and 26 the length field is variable For types 8 and 21 the Value field has the format:
and the Value field is a label as defined in [RFC3471].
As with all uses of labels, it is assumed that any node
that can process the label information knows the syntax
and semantics of the label from the context. Note that
all TLVs are zero-padded to a multiple four octets so
that if a label is not itself a multiple of four octets
it must be disambiguated from the trailing zero pads by
knowledge derived from the context.
For types 10 and 27 the Value field has the format:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Router Id | | Router ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Router Id: 32 bits Router ID: 32 bits
The Router Id used to identify the node within the IGP. The TE Router ID (TLV type 8) or the Router ID (TLV type 21)
used to identify the node within the IGP.
For types 11 and 28 the Value field has the format: For types 9 and 22 the Value field has the format:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OSPF Area Identifier | | OSPF Area Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
OSPF Area Identifier OSPF Area Identifier
The 4-octet area identifier for the node. In the case of The 4-octet area identifier for the node. In the case of
ABRs, this identifies the area where the failure has occurred. ABRs, this identifies the area where the failure has occurred.
For types 12 and 29 the Value field has the format: For types 10 and 23 the Value field has the format:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | ISIS Area Identifier | | Length | ISIS Area Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ISIS Area Identifier (continued) ~ ~ ISIS Area Identifier (continued) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Length Length
Length of the actual (non-padded) ISIS Area Identifier Length of the actual (non-padded) IS-IS Area Identifier in
in octets. Valid values are from 2 to 11 inclusive. octets. Valid values are from 2 to 11 inclusive.
ISIS Area Identifier ISIS Area Identifier
The variable-length ISIS area identifier. Padded with The variable-length IS-IS area identifier. Padded with
trailing zeroes to a four-octet boundary. trailing zeroes to a four-octet boundary.
For types 13 and 30 the Value field has the format: For types 11 and 24 the Value field has the format:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Autonomous System Number | | Autonomous System Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Autonomous System Number: 32 bits Autonomous System Number: 32 bits
The AS Number of the associated Autonomous System. Note The AS Number of the associated Autonomous System. Note that
that if 16-bit AS numbers are in use, the low order bits if 16-bit AS numbers are in use, the low order bits (16
(16 through 31) should be used and the high order bits through 31) should be used and the high order bits (0 through
(0 through 15) should be set to zero. 15) should be set to zero.
For types 14, 15 and 31 the Value field has the format: For types 12, 13 and 25 the Value field has the format:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
~ ERO Subobjects ~ ~ ERO Subobjects ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
ERO Subobjects: ERO Subobjects:
A sequence of ERO subobjects. Any ERO subobjects are A sequence of ERO subobjects. Any ERO subobjects are allowed
allowed whether defined in [RFC3209], [RFC3473] or other whether defined in [RFC3209], [RFC3473] or other documents.
documents. Note that ERO subobjects contain their own Note that ERO subobjects contain their own type and length
type and length fields. fields.
For type 32 the Value field has the format: For type 26 the Value field has the format:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
~ Node Identifiers ~ ~ Node Identifiers ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Node Identifiers: Node Identifiers:
A sequence of TLVs as defined here of types 1, 2 or 10 A sequence of TLVs as defined here of types 1, 2 or 8 that
that indicates downstream nodes that have already indicates downstream nodes that have already participated in
participated in crankback attempts and have been declared crankback attempts and have been declared unusable for the
unusable for the current LSP setup attempt. current LSP setup attempt.
For type 33 the Value field has the format: For type 27 the Value field has the format:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
~ Link Identifiers ~ ~ Link Identifiers ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Link Identifiers: Link Identifiers:
A sequence of TLVs as defined here of types 3, 4, 5, 6 or 7 A sequence of TLVs as defined here of type 3 that indicate
that indicates incoming interfaces at downstream nodes that incoming interfaces at downstream nodes that have already
have already participated in crankback attempts and have participated in crankback attempts and have been declared
been declared unusable for the current LSP setup attempt. unusable for the current LSP setup attempt.
7.3 Guidance for Use of IF_ID ERROR_SPEC TLVs 7.3 Guidance for Use of IF_ID ERROR_SPEC TLVs
7.3.1 General Principles 7.3.1 General Principles
If crankback is not being used but an IF-ID ERROR_SPEC If crankback is not being used but an IF-ID ERROR_SPEC object is
object is included in a PathErr, ResvErr or Notify included in a PathErr, ResvErr or Notify message, the sender SHOULD
message, the sender SHOULD include one of the TLVs of include one of the TLVs of type 1 through 3 as described in
type 1 through 5 as described in [RFC3473]. A sender that [RFC3473]. TLVs of type 4 or 5 SHOULD NOT be used as described in
wishes to report an error with a component link of an [BUNDLE] and component links should be identified using the
unnumbered bundle SHOULD use the new TLVs of type 6 or 7 principles described in that document.
as defined in this document. A sender MAY include
additional TLVs from the range 8 through 33 to report A sender MAY include additional TLVs from the range 6 through 27
crankback information, although this information will at to report crankback information, although this information will at
most only be used for logging. most only be used for logging.
If crankback is being used, the sender of a PathErr, If crankback is being used, the sender of a PathErr, ResvErr or
ResvErr or Notify message MUST use the IF_ID ERROR_SPEC Notify message MUST use the IF_ID ERROR_SPEC object and MUST include
object and MUST include at least one of the TLVs in the at least one of the TLVs in the range 1 through 3 as described in
range 1 through 7 as described in [RFC3473] and the [RFC3473], [BUNDLE], and previous paragraph. Additional TLVs SHOULD
previous paragraph. Additional TLVs SHOULD also be also be included to report further information. The following section
included to report further information. The following gives advice on which TLVs should be used under different
section gives advice on which TLVs should be used under circumstances, and which TLVs must be supported by LSRs.
different circumstances, and which TLVs must be supported
by LSRs.
Note that all such TLVs are optional and MAY be omitted. Note that all such TLVs are optional and MAY be omitted. Inclusion of
Inclusion of the optional TLVs SHOULD be performed where the optional TLVs SHOULD be performed where doing so helps to
doing so helps to facilitate error reporting and crankback. facilitate error reporting and crankback. The TLVs fall into three
The TLVs fall into three categories: those that are essential categories: those that are essential to report the error, those that
to report the error, those that provide additional information provide additional information that is or may be fundamental to the
that is or may be fundamental to the utility of crankback, and utility of crankback, and those that provide additional information
those that provide additional information that may be useful for that may be useful for crankback in some circumstances.
crankback in some circumstances.
Note that all LSRs MUST be prepared to receive and forward any Note that all LSRs MUST be prepared to receive and forward any TLV as
TLV as per [RFC3473]. There is, however, no requirement for an per [RFC3473]. This includes TLVs of type 4 or 5 as defined in
LSR to actively process any but the error report TLVs. An LSR [RFC3473] and obsoleted by [BUNDLE]. There is, however, no
that proposes to perform crankback re-routing SHOULD support requirement for an LSR to actively process any but the error report
receipt and processing of all of the fundamental crankback TLVs, TLVs. An LSR that proposes to perform crankback re-routing SHOULD
and is RECOMMENDED to support the receipt and processing of support receipt and processing of all of the fundamental crankback
TLVs, and is RECOMMENDED to support the receipt and processing of
the additional crankback TLVs. the additional crankback TLVs.
It should be noted, however, that some assumptions about the It should be noted, however, that some assumptions about the TLVs
TLVs that will be used MAY be made based on the deployment that will be used MAY be made based on the deployment scenarios. For
scenarios. For example, a router that is deployed in a example, a router that is deployed in a single-area network does not
single-area network does not need to support the receipt and need to support the receipt and processing of TLV types 22 and 23.
processing of TLV types 28 and 29. Those TLVs might be inserted Those TLVs might be inserted in an IF_ID ERROR_SPEC object, but would
in an IF_ID ERROR_SPEC object, but would not need to be processed not need to be processed by the receiver of a PathErr message.
by the receiver of a PathErr message.
7.3.2 Error Report TLVs 7.3.2 Error Report TLVs
Error Report TLVs are those in the range 1 through 7. Error Report TLVs are those in the range 1 through 3. (Note that
the obsoleted TLVs 4 and 5 may be considered in this category, but
SHOULD NOT be used.)
As stated above, when crankback information is reported, As stated above, when crankback information is reported, the IF_ID
the IF_ID ERROR_SPEC object MUST be used. When the IF_ID ERROR_SPEC object MUST be used. When the IF_ID ERROR_SPEC object is
ERROR_SPEC object is used, at least one of the TLVs in used, at least one of the TLVs in the range 1 through 3 MUST be
the range 1 through 7 MUST be present. The choice of which present. The choice of which TLV to use will be dependent on the
TLV to use will be dependent on the circumstance of the error circumstance of the error and device capabilities. For example, a
and device capabilities. For example, a device that does not device that does not support IPv6 will not need the ability to
support IPv6 will not need the ability to create a TLV of type create a TLV of type 2. Note, however, that such a device MUST still
2. Note, however, that such a device MUST still be prepared be prepared to receive and process all error report TLVs.
to receive and process all error report TLVs.
7.3.3 Fundamental Crankback TLVs 7.3.3 Fundamental Crankback TLVs
Many of the TLVs report the specific resource that has Many of the TLVs report the specific resource that has failed. For
failed. For example, TLV type 1 can be used to report that example, TLV type 1 can be used to report that the setup attempt was
the setup attempt was blocked by some form of resource blocked by some form of resource failure on a specific interface
failure on a specific interface identified by the IP identified by the IP address supplied. TLVs in this category are 1
address supplied. TLVs in this category are 1 through 13. through 11, although TLVs 4 and 5 may be considered to be excluded
from this category by dint of having been obsoleted.
These TLVs SHOULD be supplied whenever the node detecting These TLVs SHOULD be supplied whenever the node detecting and
and reporting the failure with crankback information has reporting the failure with crankback information has the information
the information available. available.
The use of TLVs of type 10, 11, 12 and 13, MAY, however, be The use of TLVs of type 8, 9, 10 and 11 MAY, however, be omitted
omitted according to local policy and relevance of the according to local policy and relevance of the information.
information.
7.3.4 Additional Crankback TLVs 7.3.4 Additional Crankback TLVs
Some TLVs help to locate the fault within the context of Some TLVs help to locate the fault within the context of the path of
the path of the LSP that was being set up. TLVs of types the LSP that was being set up. TLVs of types 12, 13, 14 and 15 help
14, 15, 16 and 17 help to set the context of the error to set the context of the error within the scope of an explicit path
within the scope of an explicit path that has loose hops that has loose hops or non-precise abstract nodes. The ERO context
or non-precise abstract nodes. The ERO context information is not always a requirement, but a node may notice that
information is not always a requirement, but a node may it is a member of the next hop in the ERO (such as a loose or
notice that it is a member of the next hop in the ERO non-specific abstract node) and deduce that its upstream neighbor may
(such as a loose or non-specific abstract node) and have selected the path using next hop routing. In this case,
deduce that its upstream neighbor may have selected the providing the ERO context will be useful to the node further that
path using next hop routing. In this case, providing the
ERO context will be useful to the node further that
performs re-routing. performs re-routing.
Reporting nodes SHOULD also supply TLVs from the range 14 Reporting nodes SHOULD also supply TLVs from the range 12 through 20
through 26 as appropriate for reporting the error. The as appropriate for reporting the error. The reporting nodes MAY also
reporting nodes MAY also supply TLVs from the range 27 supply TLVs from the range 21 through 27.
through 33.
Note that in deciding whether a TLV in the range 14 Note that in deciding whether a TLV in the range 12 through 20 "is
through 26 "is appropriate", the reporting node should appropriate", the reporting node should consider amongst other
consider amongst other things, whether the information is things, whether the information is pertinent to the cause of the
pertinent to the cause of the failure. For example, when failure. For example, when a cross-connection fails it may be that
a cross-connection fails it may be that the outgoing the outgoing interface is faulted, in which case only the interface
interface is faulted, in which case only the interface (for example, TLV type 1) needs to be reported, but if the problem is
(for example, TLV type 1) needs to be reported, but if that the incoming interface cannot be connected to the outgoing
the problem is that the incoming interface cannot be interface because of temporary or permanent cross-connect
connected to the outgoing interface because of temporary limitations, the node should also include reference to the incoming
or permanent cross-connect limitations, the node should interface (for example, TLV type 16).
also include reference to the incoming interface (for
example, TLV type 18).
Four TLVs (27, 28, 29 and 30) allow the location of the Four TLVs (21, 22, 23 and 24) allow the location of the reporting
reporting node to be expanded upon. These TLVs would not node to be expanded upon. These TLVs would not be included if the
be included if the information is not of use within the information is not of use within the local system, but might be
local system, but might be added by ABRs relaying the added by ABRs relaying the error. Note that the Reporting Node ID
error. Note that the Reporting Node Id (TLV 27) need not (TLV 21) need not be included if the IP address of the reporting
be included if the IP address of the reporting node as node as indicated in the ERROR_SPEC itself, is sufficient to fully
indicated in the ERROR_SPEC itself, is sufficient to identify the node.
fully identify the node.
The last three TLVs (31, 32, and 33) provide additional The last three TLVs (25, 26, and 27) provide additional information
information for recomputation points. The reporting node for recomputation points. The reporting node (or some node forwarding
(or some node forwarding the error) may supply the error) MAY supply suggestions about the ERO that could have been
suggestions about the ERO that could have been used to used to avoid the error. As the error propagates back upstream and as
avoid the error. As the error propagates back upstream crankback routing is attempted and fails, it is beneficial to collect
and as crankback routing is attempted and fails, it is lists of failed nodes and links so that they will not be included in
beneficial to collect lists of failed nodes and links so further computations performed at upstream nodes. Theses lists may
that they will not be included in further computations also be factored into route exclusions [EXCLUDE].
performed at upstream nodes. Theses lists may also be
factored into route exclusions [EXCLUDE].
Note that there is no ordering requirement on any of the Note that there is no ordering requirement on any of the TLVs within
TLVs within the IF_ID Error Spec, and no implication the IF_ID Error Spec, and no implication should be drawn from the
should be drawn from the ordering of the TLVs in a ordering of the TLVs in a received IF_ID Error Spec.
received IF_ID Error Spec.
It is left as an implementation detail precisely when to It is left as an implementation detail precisely when to include each
include each of the TLVs according to the capabilities of of the TLVs according to the capabilities of the system reporting the
the system reporting the error. error.
7.3.5 Grouping TLVs by Failure Location 7.3.5 Grouping TLVs by Failure Location
Further guidance as to the inclusion of crankback TLVs can be given Further guidance as to the inclusion of crankback TLVs can be given
by grouping the TLVs according to the location of the failure and by grouping the TLVs according to the location of the failure and the
the context within which it is reported. For example, a TLV that context within which it is reported. For example, a TLV that reports
reports an area identifier would only need to be included as the an area identifier would only need to be included as the crankback
crankback error report transits an area boundary. error report transits an area boundary.
Although discussion of aggregation of crankback information is out Although discussion of aggregation of crankback information is out of
of the scope of this document, it should be noted that this topic is the scope of this document, it should be noted that this topic is
closely aligned to the information presented here. closely aligned to the information presented here.
Resource Failure Resource Failure
8 DOWNSTREAM_LABEL 6 DOWNSTREAM_LABEL
9 UPSTREAM_LABEL 7 UPSTREAM_LABEL
Interface failures Interface failures
1 IPv4 1 IPv4
2 IPv6 2 IPv6
3 IF_INDEX 3 IF_INDEX
4 COMPONENT_IF_DOWNSTREAM 4 COMPONENT_IF_DOWNSTREAM (obsoleted)
5 COMPONENT_IF_UPSTREAM 5 COMPONENT_IF_UPSTREAM (obsoleted)
6 UNUM_COMPONENT_IF_DOWN 12 ERO_CONTEXT
7 UNUM_COMPONENT_IF_UP 13 ERO_NEXT_CONTEXT
14 ERO_CONTEXT 14 PREVIOUS_HOP_IPv4
15 ERO_NEXT_CONTEXT 15 PREVIOUS_HOP_IPv6
16 PREVIOUS_HOP_IPv4 16 INCOMING_IPv4
17 PREVIOUS_HOP_IPv6 17 INCOMING_IPv6
18 INCOMING_IPv4 18 INCOMING_IF_INDEX
19 INCOMING_IPv6 19 INCOMING_DOWN_LABEL
20 INCOMING_IF_INDEX 20 INCOMING_UP_LABEL
21 INCOMING_COMP_IF_DOWN
22 INCOMING_COMP_IF_UP
23 INCOMING_UNUM_COMP_DOWN
24 INCOMING_UNUM_COMP_UP
25 INCOMING_DOWN_LABEL
26 INCOMING_UP_LABEL
Node failures Node failures
10 NODE_ID 8 NODE_ID
27 REPORTING_NODE_ID 21 REPORTING_NODE_ID
Area failures Area failures
11 OSPF_AREA 9 OSPF_AREA
12 ISIS_AREA 10 ISIS_AREA
28 REPORTING_OSPF_AREA 22 REPORTING_OSPF_AREA
29 REPORTING_ISIS_AREA 23 REPORTING_ISIS_AREA
31 PROPOSED_ERO 25 PROPOSED_ERO
32 NODE_EXCLUSIONS 26 NODE_EXCLUSIONS
33 LINK_EXCLUSIONS 27 LINK_EXCLUSIONS
AS failures AS failures
13 AUTONOMOUS_SYSTEM 11 AUTONOMOUS_SYSTEM
30 REPORTING_AS 24 REPORTING_AS
7.3.6 Alternate Path identification 7.3.6 Alternate Path Identification
No new object is used to distinguish between Path/Resv messages No new object is used to distinguish between Path/Resv messages for
for an alternate LSP. Thus, the alternate LSP uses the same an alternate LSP. Thus, the alternate LSP uses the same SESSION and
SESSION and SENDER_TEMPLATE/FILTER_SPEC objects as the ones used SENDER_TEMPLATE/FILTER_SPEC objects as the ones used for the initial
for the initial LSP under re-routing. LSP under re-routing.
7.4. Action on Receiving Crankback Information 7.4. Action on Receiving Crankback Information
7.4.1 Re-route Attempts 7.4.1 Re-route Attempts
As described in section 3, a node receiving crankback information As described in section 3, a node receiving crankback information in
in a PathErr must first check to see whether it is allowed to a PathErr must first check to see whether it is allowed to perform
perform re-routing. This is indicated by the Re-routing Flags in re-routing. This is indicated by the Re-routing Flags in the
the SESSION_ATTRIBUTE object during LSP setup request. SESSION_ATTRIBUTE object during LSP setup request.
If a node is not allowed to perform re-routing it should If a node is not allowed to perform re-routing it should forward the
forward the PathErr message, or if it is the ingress PathErr message, or if it is the ingress report the LSP as having
report the LSP as having failed. failed.
If re-routing is allowed, the node should attempt to compute a path If re-routing is allowed, the node should attempt to compute a path
to the destination using the original (received) explicit path and to the destination using the original (received) explicit path and
excluding the failed/blocked node/link. The new path should be added excluding the failed/blocked node/link. The new path should be added
to an LSP setup request as an explicit route and signaled. to an LSP setup request as an explicit route and signaled.
LSRs performing crankback re-routing should store all received LSRs performing crankback re-routing should store all received
crankback information for an LSP until the LSP is successfully crankback information for an LSP until the LSP is successfully
established or until the node abandons its attempts to re-route established or until the node abandons its attempts to re-route the
the LSP. This allows the combination of crankback information LSP. This allows the combination of crankback information from
from multiple failures when computing an alternate path. multiple failures when computing an alternate path.
It is an implementation decision whether the crankback It is an implementation decision whether the crankback information is
information is discarded immediately upon successful LSP discarded immediately upon successful LSP establishment or retained
establishment or retained for a period in case the LSP fails. for a period in case the LSP fails.
7.4.2 Location Identifiers of Blocked Links or Nodes 7.4.2 Location Identifiers of Blocked Links or Nodes
In order to compute an alternate path by crankback re-routing, In order to compute an alternate path by crankback re-routing, it is
it is necessary to identify the blocked links or nodes and necessary to identify the blocked links or nodes and their locations.
their locations. The common identifier of each link or node The common identifier of each link or node in an MPLS network should
in an MPLS network should be specified. Both be specified. Both protocol-independent and protocol- dependent
protocol-independent and protocol- dependent identifiers identifiers may be specified. Although a general identifier that is
may be specified. Although a general identifier that is independent of other protocols is preferable, there are a couple of
independent of other protocols is preferable, there are a restrictions on its use as described in the following subsection.
couple of restrictions on its use as described in the
following subsection.
In link state protocols such as OSPF and IS-IS , each In link state protocols such as OSPF and IS-IS , each link and node
link and node in a network can be uniquely identified. in a network can be uniquely identified. For example, by the context
For example, by the context of a Router ID and the Link of a TE Router ID and the Link ID. If the topology and resource
ID. If the topology and resource information obtained by information obtained by OSPF advertisements is used to compute a
OSPF advertisements is used to compute a constraint-based constraint-based path, the location of a blockage can be represented
path, the location of a blockage can be represented by by such identifiers.
such identifiers.
Note that, when the routing-protocol-specific link Note that, when the routing-protocol-specific link identifiers are
identifiers are used, the Re-routing Flag on the LSP used, the Re-routing Flag on the LSP setup request must have been set
setup request must have been set to show support for to show support for boundary or segment-based re-routing.
boundary or segment-based re-routing.
In this document, we specify routing protocol specific In this document, we specify routing protocol specific link and node
link and node identifiers for OSPFv2 for IPv4, IS-IS for identifiers for OSPFv2 for IPv4, IS-IS for IPv4, OSPF for IPv6, and
IPv4, OSPF for IPv6, and IS-IS for IPv6. These IS-IS for IPv6. These identifiers may only be used if segment-based
identifiers may only be used if segment-based re-routing re-routing is supported, as indicated by the Routing Behavior flag on
is supported, as indicated by the Routing Behavior flag the LSP setup request.
on the LSP setup request.
7.4.3 Locating Errors within Loose or Abstract Nodes 7.4.3 Locating Errors within Loose or Abstract Nodes
The explicit route on the original LSP setup request may The explicit route on the original LSP setup request may contain a
contain a loose or an Abstract Node. In these cases, the loose or an Abstract Node. In these cases, the crankback information
crankback information may refer to links or nodes that may refer to links or nodes that were not in the original explicit
were not in the original explicit route. route.
In order to compute a new path, the repair point may need In order to compute a new path, the repair point may need to identify
to identify the pair of hops (or nodes) in the explicit the pair of hops (or nodes) in the explicit route between which the
route between which the error/blockage occurred. error/blockage occurred.
To assist this, the crankback information reports the top To assist this, the crankback information reports the top two hops of
two hops of the explicit route as received at the the explicit route as received at the reporting node. The first hop
reporting node. The first hop will likely identify the will likely identify the node or the link, the second hop will
node or the link, the second hop will identify a 'next' identify a 'next' hop from the original explicit route.
hop from the original explicit route.
7.4.4 When Re-routing Fails 7.4.4 When Re-routing Fails
When a node cannot or chooses not to perform crankback When a node cannot or chooses not to perform crankback re-routing it
re-routing it must forward the PathErr message further upstream. must forward the PathErr message further upstream.
However, when a node was responsible for expanding or However, when a node was responsible for expanding or replacing the
replacing the explicit route as the LSP setup was explicit route as the LSP setup was processed it MUST update the
processed it MUST update the crankback information with crankback information with regard to the explicit route that it
regard to the explicit route that it received. Only if received. Only if this is done will the upstream nodes stand a
this is done will the upstream nodes stand a chance of chance of successfully routing around the problem.
successfully routing around the problem.
7.4.5 Aggregation of Crankback Information 7.4.5 Aggregation of Crankback Information
When a setup blocking error or an error in an established When a setup blocking error or an error in an established LSP occurs
LSP occurs and crankback information is sent in an error and crankback information is sent in an error notification message,
notification message, some node upstream may choose to some node upstream may choose to attempt crankback re-routing. If
attempt crankback re-routing. If that node's attempts at that node's attempts at re-routing fail the node will accumulate a
re-routing fail the node will accumulate a set of failure set of failure information. When the node gives up it must propagate
information. When the node gives up it must propagate the the failure message further upstream and include crankback
failure message further upstream and include crankback
information when it does so. information when it does so.
There is not scope in the protocol extensions described There is not scope in the protocol extensions described in this
in this document to supply a full list of all of the document to supply a full list of all of the failures that have
failures that have occurred. Such a list would be occurred. Such a list would be indefinitely long and would include
indefinitely long and would include more detail than is more detail than is required. However, TLVs 26 and 27 allow lists of
required. However, TLVs 32 and 33 allow lists of unusable unusable links and nodes to be accumulated as the failure is passed
links and nodes to be accumulated as the failure is back upstream.
passed back upstream.
Aggregation may involve reporting all links from a node Aggregation may involve reporting all links from a node as unusable
as unusable by flagging the node as unusable, or flagging by flagging the node as unusable, or flagging an ABR as unusable when
an ABR as unusable when there is no downstream path there is no downstream path available, and so on. The precise details
available, and so on. The precise details of how of how aggregation of crankback information is performed are beyond
aggregation of crankback information is performed are the scope of this document.
beyond the scope of this document.
7.5. Notification of Errors 7.5. Notification of Errors
7.5.1 ResvErr Processing 7.5.1 ResvErr Processing
As described above, the resource allocation failure for As described above, the resource allocation failure for RSVP-TE may
RSVP-TE may occur on the reverse path when the Resv occur on the reverse path when the Resv message is being processed.
message is being processed. In this case, it is still In this case, it is still useful to return the received crankback
useful to return the received crankback information to information to the ingress LSR. However, when the egress LSR receives
the ingress LSR. However, when the egress LSR receives the ResvErr message, per [RFC2205] it still has the option of
the ResvErr message, per RFC 2205 it still has the option re-issuing the Resv with different resource requirements (although
of re-issuing the Resv with different resource not on an alternate path).
requirements (although not on an alternate path).
When a ResvErr carrying crankback information is received at When a ResvErr carrying crankback information is received at an
an egress LSR, the egress LSR MAY ignore this object and egress LSR, the egress LSR MAY ignore this object and perform the
perform the same actions as for any other ResvErr. However, same actions as for any other ResvErr. However, if the egress LSR
if the egress LSR supports the crankback extensions defined supports the crankback extensions defined in this document, and after
in this document, and after all local recovery procedures all local recovery procedures have failed, it SHOULD generate a
have failed, it SHOULD generate a PathErr message carrying PathErr message carrying the crankback information and send it to the
the crankback information and send it to the ingress LSR. ingress LSR.
If a ResvErr reports on more than one FILTER_SPEC If a ResvErr reports on more than one FILTER_SPEC (because the Resv
(because the Resv carried more than one FILTER_SPEC) then carried more than one FILTER_SPEC) then only one set of crankback
only one set of crankback information should be present information should be present in the ResvErr and it should apply to
in the ResvErr and it should apply to all FILTER_SPEC all FILTER_SPEC carried. In this case, it may be necessary per
carried. In this case, it may be necessary per [RFC 2205] [RFC2205] to generate more than one PathErr.
to generate more than one PathErr.
7.5.2 Notify Message Processing 7.5.2 Notify Message Processing
[RFC3473] defines the Notify message to enhance error [RFC3473] defines the Notify message to enhance error reporting in
reporting in RSVP-TE networks. This message is not RSVP-TE networks. This message is not intended to replace the PathErr
intended to replace the PathErr and ResvErr messages. The and ResvErr messages. The Notify message is sent to addresses
Notify message is sent to addresses requested on the Path requested on the Path and Resv messages. These addresses could (but
and Resv messages. These addresses could (but need not) need not) identify the ingress and egress LSRs respectively.
identify the ingress and egress LSRs respectively.
When a network error occurs, such as the failure of link When a network error occurs, such as the failure of link hardware,
hardware, the LSRs that detect the error MAY send Notify the LSRs that detect the error MAY send Notify messages to the
messages to the requested addresses. The type of error requested addresses. The type of error that causes a Notify message
that causes a Notify message to be sent is an to be sent is an implementation detail.
implementation detail.
In the event of a failure, an LSR that supports [RFC3473] In the event of a failure, an LSR that supports [RFC3473] and the
and the crankback extensions defined in this document MAY crankback extensions defined in this document MAY choose to send a
choose to send a Notify message carrying crankback Notify message carrying crankback information. This would ensure a
information. This would ensure a speedier report of the speedier report of the error to the ingress/egress LSRs.
error to the ingress/egress LSRs.
7.6. Error Values 7.6. Error Values
Error values for the Error Code "Admission Control Error values for the Error Code "Admission Control Failure" are
Failure" are defined in [RFC2205]. Error values for the defined in [RFC2205]. Error values for the error code "Routing
error code "Routing Problem" are defined in [RFC 3209] Problem" are defined in [RFC3209] and [RFC3473].
and [RFC 3473].
A new error value is defined for the error code "Routing A new error value is defined for the error code "Routing Problem".
Problem". "Re-routing limit exceeded" indicates that re-routing "Re-routing limit exceeded" indicates that re-routing has failed
has failed because the number of crankback re-routing attempts because the number of crankback re-routing attempts has gone beyond
has gone beyond the predetermined threshold at an individual LSR. the predetermined threshold at an individual LSR.
7.7. Backward Compatibility 7.7. Backward Compatibility
It is recognized that not all nodes in an RSVP-TE network It is recognized that not all nodes in an RSVP-TE network will
will support the extensions defined in this document. It support the extensions defined in this document. It is important
is important that an LSR that does not support these that an LSR that does not support these extensions can continue to
extensions can continue to process a PathErr, ResvErr or process a PathErr, ResvErr or Notify message even if it carries the
Notify message even if it carries the newly defined IF_ID newly defined IF_ID ERROR_SPEC information (TLVs).
ERROR_SPEC information (TLVs).
8. Routing Protocol Interactions 8. Routing Protocol Interactions
If the routing-protocol-specific link or node identifiers If the routing-protocol-specific link or node identifiers are used in
are used in the Link and Node IF_ID ERROR_SPEC TLVs the Link and Node IF_ID ERROR_SPEC TLVs defined above, the signaling
defined above, the signaling has to interact with the has to interact with the OSPF/IS-IS routing protocol.
OSPF/IS-IS routing protocol.
For example, when an intermediate LSR issues a PathErr For example, when an intermediate LSR issues a PathErr message, the
message, the signaling module of the intermediate LSR signaling module of the intermediate LSR should interact with the
should interact with the routing logic to determine the routing logic to determine the routing-protocol-specific link or node
routing-protocol-specific link or node ID where the ID where the blockage or fault occurred and carry this information
blockage or fault occurred and carry this information onto the Link TLV and Node TLV inside the IF_ID ERROR_SPEC object.
onto the Link TLV and Node TLV inside the IF_ID The ingress LSR, upon receiving the error message, should interact
ERROR_SPEC object. The ingress LSR, upon receiving the with the routing logic to compute an alternate path by pruning the
error message, should interact with the routing logic to specified link ID or node ID in the routing database.
compute an alternate path by pruning the specified link
ID or node ID in the routing database.
Procedures concerning these protocol interactions are out Procedures concerning these protocol interactions are out of scope of
of scope of this document. this document.
9. LSP Restoration Considerations 9. LSP Restoration Considerations
LSP restoration is performed to recover an established LSP restoration is performed to recover an established LSP when a
LSP when a failure occurs along the path. In the case of failure occurs along the path. In the case of LSP restoration, the
LSP restoration, the extensions for crankback re-routing extensions for crankback re-routing explained above can be applied
explained above can be applied for improving performance. for improving performance. This section gives an example of applying
This section gives an example of applying the above the above extensions to LSP restoration. The goal of this example is
extensions to LSP restoration. The goal of this example to give a general overview of how this might work, and not to give a
is to give a general overview of how this might work, and detailed procedure for LSP restoration.
not to give a detailed procedure for LSP restoration.
Although there are several techniques for LSP Although there are several techniques for LSP restoration, this
restoration, this section explains the case of on-demand section explains the case of on-demand LSP restoration, which
LSP restoration, which attempts to set up a new LSP on attempts to set up a new LSP on demand after detecting an LSP
demand after detecting an LSP failure. failure.
9.1. Upstream of the Fault 9.1. Upstream of the Fault
When an LSR detects a fault on an adjacent downstream When an LSR detects a fault on an adjacent downstream link or node,
link or node, a PathErr message is sent upstream. In a PathErr message is sent upstream. In GMPLS, the ERROR_SPEC object
GMPLS, the ERROR_SPEC object may carry a may carry a Path_State_Remove_Flag indication. Each LSR receiving the
Path_State_Remove_Flag indication. Each LSR receiving the message then releases the corresponding LSP. (Note that if the state
message then releases the corresponding LSP. (Note that removal indication is not present on the PathErr message, the ingress
if the state removal indication is not present on the node must issue a PathTear message to cause the resources to be
PathErr message, the ingress node must issue a PathTear released.) If the failed LSP has to be restored at an upstream LSR,
message to cause the resources to be released.) If the the IF_ID ERROR SPEC that includes the location information of the
failed LSP has to be restored at an upstream LSR, the failed link or node is included in the PathErr message. The ingress,
IF_ID ERROR SPEC that includes the location information intermediate area border LSR, or indeed any repair point permitted by
of the failed link or node is included in the PathErr the Re-routing Flags, that receives the PathErr message can terminate
message. The ingress, intermediate area border LSR, or
indeed any repair point permitted by the Re-routing
Flags, that receives the PathErr message can terminate
the message and then perform alternate routing. the message and then perform alternate routing.
In a flat network, when the ingress LSR receives the In a flat network, when the ingress LSR receives the PathErr message
PathErr message with the IF_ID ERROR_SPEC TLVs, it with the IF_ID ERROR_SPEC TLVs, it computes an alternate path around
computes an alternate path around the blocked link or the blocked link or node satisfying the QoS constraints. If an
node satisfying the QoS constraints. If an alternate path alternate path is found, a new Path message is sent over this path
is found, a new Path message is sent over this path
toward the egress LSR. toward the egress LSR.
In a network segmented into areas, the following In a network segmented into areas, the following procedures can be
procedures can be used. As explained in Section 8.2, the used. As explained in Section 8.2, the LSP restoration behavior is
LSP restoration behavior is indicated in the Flags field indicated in the Flags field of the SESSION_ATTRIBUTE object of the
of the SESSION_ATTRIBUTE object of the Path message. If Path message. If the Flags indicate "End-to-end re-routing", the
the Flags indicate "End-to-end re-routing", the PathErr PathErr message is returned all the way back to the ingress LSR,
message is returned all the way back to the ingress LSR, which may then issue a new Path message along another path, which is
which may then issue a new Path message along another the same procedure as in the flat network case above.
path, which is the same procedure as in the flat network
case above.
If the Flags field indicates Boundary re-routing, the If the Flags field indicates Boundary re-routing, the ingress area
ingress area border LSR MAY terminate the PathErr message border LSR MAY terminate the PathErr message and then perform
and then perform alternate routing within the area for alternate routing within the area for which the area border LSR is
which the area border LSR is the ingress LSR. the ingress LSR.
If the Flags field indicates segment-based re-routing, any node If the Flags field indicates segment-based re-routing, any node MAY
MAY apply the procedures described above for Boundary re-routing. apply the procedures described above for Boundary re-routing.
9.2. Downstream of the Fault 9.2. Downstream of the Fault
This section only applies to errors that occur after an This section only applies to errors that occur after an LSP has been
LSP has been established. Note that an LSR that generates established. Note that an LSR that generates a PathErr with
a PathErr with Path_State_Remove Flag SHOULD also send a Path_State_Remove Flag SHOULD also send a PathTear downstream to
PathTear downstream to clean up the LSP. clean up the LSP.
A node that detects a fault and is downstream of the A node that detects a fault and is downstream of the fault MAY send
fault MAY send a PathErr or Notify message containing an a PathErr or Notify message containing an IF_ID ERROR SPEC that
IF_ID ERROR SPEC that includes the location information includes the location information of the failed link or node, and MAY
of the failed link or node, and MAY send a PathTear to send a PathTear to clean up the LSP at all other downstream nodes.
clean up the LSP at all other downstream nodes. However, However, if the reservation style for the LSP is Shared Explicit (SE)
if the reservation style for the LSP is Shared Explicit (SE) the detecting LSR MAY choose not to send a PathTear - this leaves the
the detecting LSR MAY choose not to send a PathTear - this downstream LSP state in place and facilitates make-before-break
leaves the downstream LSP state in place and facilitates repair of the LSP re-utilizing downstream resources. Note that if the
make-before-break repair of the LSP re-utilizing downstream detecting node does not send a PathTear immediately then unused sate
resources. Note that if the detecting node does not send a will timeout according to the normal rules of [RFC2205].
PathTear immediately then unused sate will timeout according
to the normal rules of [RFC2205].
At a well-known merge point, an ABR or an ASBR, a similar At a well-known merge point, an ABR or an ASBR, a similar decision
decision might also be made so as to better facilitate might also be made so as to better facilitate make-before-break
make-before-break repair. In this case a received repair. In this case a received PathTear might be 'absorbed' and not
PathTear might be 'absorbed' and not propagated further propagated further downstream for an LSP that has SE reservation
downstream for an LSP that has SE reservation style. style. Note, however, that this is a divergence from the protocol and
Note, however, that this is a divergence from the protocol might severely impact normal tear-down of LSPs.
and might severely impact normal tear-down of LSPs.
10. IANA Considerations 10. IANA Considerations
10.1 Error Codes 10.1 Error Codes
A new error value is defined for the RSVP-TE "Routing A new error value is defined for the RSVP-TE "Routing Problem" error
Problem" error code that is defined in [RFC3209]. code that is defined in [RFC3209].
TBD Re-routing limit exceeded. TBD Re-routing limit exceeded.
10.2 IF_ID_ERROR_SPEC TLVs 10.2 IF_ID_ERROR_SPEC TLVs
Note that the IF_ID_ERROR_SPEC TLV type values are not Note that the IF_ID_ERROR_SPEC TLV type values defined in [RFC3471]
currently tracked by IANA. This might be a good are not currently tracked by IANA. IANA is requested to form a
opportunity to move them under IANA control. The values registry of these values. The new values proposed by this document
proposed by this document are found in section 7.2. are found in section 7.2.
10.3 LSP_ATTRIBUTES Object 10.3 LSP_ATTRIBUTES Object
Three bits are defined for inclusion in the LSP Attributes TLV of Three bits are defined for inclusion in the LSP Attributes TLV of
the LSP_ATTRIBUTES object in section 6.4. Suggested values are the LSP_ATTRIBUTES object in section 6.4. Suggested values are
supplied. IANA is requested to assign those bits. supplied. IANA is requested to assign those bits.
11. Security Considerations 11. Security Considerations
It should be noted that while the extensions in this document It should be noted that while the extensions in this document
introduce no new security holes in the protocols, should a malicious introduce no new security holes in the protocols, should a malicious
user gain protocol access to the network, the crankback information user gain protocol access to the network, the crankback information
might be used to prevent establishment of valid LSPs. might be used to prevent establishment of valid LSPs.
The implementation of re-routing attempt thresholds are The implementation of re-routing attempt thresholds are particularly
particularly important in this context. important in this context.
The crankback routing extensions and procedures for LSP restoration The crankback routing extensions and procedures for LSP restoration
as applied to RSVP-TE introduce no further new security as applied to RSVP-TE introduce no further new security
considerations. Refer to [RFC2205], [RFC3209] and [RFC3473] for a considerations. Refer to [RFC2205], [RFC3209] and [RFC3473] for a
description of applicable security considerations. description of applicable security considerations.
12. Acknowledgments 12. Acknowledgments
We would like to thank Juha Heinanen and Srinivas Makam We would like to thank Juha Heinanen and Srinivas Makam for their
for their review and comments, and Zhi-Wei Lin for his review and comments, and Zhi-Wei Lin for his considered opinions.
considered opinions. Thanks, too, to John Drake for Thanks, too, to John Drake for encouraging us to resurrect this
encouraging us to resurrect this document and consider document and consider the use of the IF_ID ERROR SPEC object. Thanks
the use of the IF-ID ERROR SPEC object. Thanks for a for a welcome and very thorough review by Dimitri Papadimitriou.
welcome and very thorough review by Dimitri Papadimitriou.
Stephen Shew made useful comments for clarification through the
ITU-T liaison process.
Simon Marshall-Unitt made contributions to this draft. Simon Marshall-Unitt made contributions to this draft.
13. Intellectual Property Considerations 13. Intellectual Property Considerations
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has might or might not be available; nor does it represent that it has
skipping to change at line 1447 skipping to change at line 1445
Label Switched Path (LSP) Establishment Using RSVP-TE", Label Switched Path (LSP) Establishment Using RSVP-TE",
draft-ietf-mpls-rsvpte-attributes-04.txt, July 2004, draft-ietf-mpls-rsvpte-attributes-04.txt, July 2004,
work in progress. work in progress.
[ASON-REQ] D. Papadimitriou, J. Drake, J. Ash, A. Farrel, L. Ong, [ASON-REQ] D. Papadimitriou, J. Drake, J. Ash, A. Farrel, L. Ong,
"Requirements for Generalized MPLS (GMPLS) Signaling "Requirements for Generalized MPLS (GMPLS) Signaling
Usage and Extensions for Automatically Switched Optical Usage and Extensions for Automatically Switched Optical
Network (ASON)", daft-ietf-ccamp-gmpls-ason-reqts-07.txt Network (ASON)", daft-ietf-ccamp-gmpls-ason-reqts-07.txt
October 2004, work in progress. October 2004, work in progress.
[BUNDLE] Kompella, K., Rekhter, Y., and Berger, L., "Link
Bundling in MPLS Traffic Engineering",
draft-ietf-mpls-bundle, work in progress.
15. Informational References 15. Informational References
[ASH1] G. Ash, ITU-T Recommendations E.360.1 --> E.360.7, "QoS [ASH1] G. Ash, ITU-T Recommendations E.360.1 --> E.360.7, "QoS
Routing & Related Traffic Engineering Methods for IP-, Routing & Related Traffic Engineering Methods for IP-,
ATM-, & TDM-Based Multiservice Networks", May, 2002. ATM-, & TDM-Based Multiservice Networks", May, 2002.
[FASTRR] Ping Pan, et al., "Fast Reroute Extensions to RSVP-TE [FASTRR] Ping Pan, et al., "Fast Reroute Extensions to RSVP-TE
for LSP Tunnels", for LSP Tunnels",
draft-ietf-mpls-rsvp-lsp-fastreroute-06.txt, May 2004 draft-ietf-mpls-rsvp-lsp-fastreroute-06.txt, May 2004
(work in progress). (work in progress).
skipping to change at line 1478 skipping to change at line 1480
[PNNI] ATM Forum, "Private Network-Network Interface [PNNI] ATM Forum, "Private Network-Network Interface
Specification Version 1.0 (PNNI 1.0)", Specification Version 1.0 (PNNI 1.0)",
<af-pnni-0055.000>, May 1996. <af-pnni-0055.000>, May 1996.
[RFC2702] D. Awduche, et al., "Requirements for Traffic [RFC2702] D. Awduche, et al., "Requirements for Traffic
Engineering Over MPLS", RFC2702, September 1999. Engineering Over MPLS", RFC2702, September 1999.
[RFC3469] V. Sharma, et al., "Framework for MPLS-based Recovery", [RFC3469] V. Sharma, et al., "Framework for MPLS-based Recovery",
RFC 3469, February 2003. RFC 3469, February 2003.
[TE-BUNDLE] Z. Ali, A. Farrel, D. Papadimitriou, A. Satyanarayana,
and A. Zamfir, "Generalized Multi-Protocol Label
Switching (GMPLS) RSVP-TE signaling using Bundled
Traffic Engineering (TE) Links",
draft-dimitri-ccamp-gmpls-rsvp-te-bundled-links-00.txt,
May 2004, work in progress.
16. Authors' Addresses 16. Authors' Addresses
Adrian Farrel (editor) Adrian Farrel (editor)
Old Dog Consulting Old Dog Consulting
Phone: +44 (0) 1978 860944 Phone: +44 (0) 1978 860944
EMail: adrian@olddog.co.uk EMail: adrian@olddog.co.uk
Arun Satyanarayana Arun Satyanarayana
Movaz Networks, Inc. EMail: kuvempu@yahoo.com
7926 Jones Branch Drive, Suite 615
McLean, VA 22102
Phone: (+1) 703-847-1785
EMail: aruns@movaz.com
Atsushi Iwata Atsushi Iwata
NEC Corporation NEC Corporation
Networking Research Laboratories Networking Research Laboratories
1-1, Miyazaki, 4-Chome, Miyamae-ku, 1-1, Miyazaki, 4-Chome, Miyamae-ku,
Kawasaki, Kanagawa, 216-8555, JAPAN Kawasaki, Kanagawa, 216-8555, JAPAN
Phone: +81-(44)-856-2123 Phone: +81-(44)-856-2123
Fax: +81-(44)-856-2230 Fax: +81-(44)-856-2230
EMail: a-iwata@ah.jp.nec.com EMail: a-iwata@ah.jp.nec.com
skipping to change at line 1538 skipping to change at line 1529
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
18. Full Copyright Statement 18. Full Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights. except as set forth therein, the authors retain all their rights.
Appendix A. Experience of Crankback in TDM-based Networks Appendix A. Experience of Crankback in TDM-based Networks
Experience of using release messages in TDM-based networks for Experience of using release messages in TDM-based networks for
analogous repair and re-routing purposes provides some guidance. analogous repair and re-routing purposes provides some guidance.
One can use the receipt of a release message with a cause value (CV) One can use the receipt of a release message with a cause value (CV)
indicating "link congestion" to trigger a re-routing attempt at the indicating "link congestion" to trigger a re-routing attempt at the
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/