draft-ietf-ccamp-crankback-06.txt   rfc4920.txt 
Network Working Group A. Farrel (Editor)
Internet Draft Old Dog Consulting
Category: Standards Track
Expires: July 2007 A. Satyanarayana
Cisco Systems, Inc.
Network Working Group A. Farrel, Ed.
Request for Comments: 4920 Old Dog Consulting
Category: Standards Track A. Satyanarayana
Cisco Systems, Inc.
A. Iwata A. Iwata
N. Fujita N. Fujita
NEC Corporation NEC Corporation
G. Ash G. Ash
AT&T AT&T
January 2007
Crankback Signaling Extensions for MPLS and GMPLS RSVP-TE Crankback Signaling Extensions for MPLS and GMPLS RSVP-TE
<draft-ietf-ccamp-crankback-06.txt>
Status of this Memo Status of This Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months This document specifies an Internet standards track protocol for the
and may be updated, replaced, or obsoleted by other documents at any Internet community, and requests discussion and suggestions for
time. It is inappropriate to use Internet-Drafts as reference improvements. Please refer to the current edition of the "Internet
material or to cite them other than as "work in progress." Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
The list of current Internet-Drafts can be accessed at Copyright Notice
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at Copyright (C) The IETF Trust (2007).
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) and Generalized MPLS that Multiprotocol Label Switching (MPLS) and Generalized MPLS
(GMPLS) Traffic Engineered (TE) Label Switched Path (LSP) setup (GMPLS) Traffic Engineered (TE) Label Switched Path (LSP) setup
requests may be blocked by links or nodes without sufficient 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
returned from the point of failure to allow new setup attempts to be is returned from the point of failure to allow new setup attempts to
made avoiding the blocked resources. Crankback can also be applied to be made avoiding the blocked resources. Crankback can also be
LSP recovery to indicate the location of the failed link or node. applied to LSP recovery 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, and GMPLS signaling as defined in RSVP for LSP Tunnels", RFC3209, and GMPLS signaling as defined in
"Generalized Multi-Protocol Label Switching (GMPLS) Signaling "Generalized Multi-Protocol Label Switching (GMPLS) Signaling
Functional Description", RFC3473. These extensions mean that the LSP Functional Description", RFC 3473. These extensions mean that the
setup request can be retried on an alternate path that detours around LSP setup request can be retried on an alternate path that detours
blocked links or nodes. This offers significant improvements in the around blocked links or nodes. This offers significant improvements
successful setup and recovery ratios for LSPs, especially in in the successful setup and recovery ratios for LSPs, especially in
situations where a large number of setup requests are triggered at situations where a large number of setup requests are triggered at
the same time. the same time.
Table of Contents Table of Contents
Section A : Problem Statement Section A : Problem Statement
1. Terminology......................................................3 1. Introduction and Framework ......................................4
1.1. Control Plane and Data Plane Separation........................3 1.1. Background .................................................4
2. Introduction and Framework.......................................4 1.2. Control Plane and Data Plane Separation ....................5
2.1. Background.....................................................4 1.3. Repair and Recovery ........................................5
2.2. Repair and Recovery............................................5 1.4. Interaction with TE Flooding Mechanisms ....................6
2.3. Interaction with TE Flooding Mechanisms .......................6 1.5. Terminology ................................................7
3. Discussion: Explicit Versus Implicit Re-routing Indications......6 2. Discussion: Explicit versus Implicit Re-Routing Indications .....7
4. Required Operation...............................................7 3. Required Operation ..............................................8
4.1. Resource Failure or Unavailability.............................7 3.1. Resource Failure or Unavailability .........................8
4.2. Computation of an Alternate Path...............................8 3.2. Computation of an Alternate Path ...........................8
4.2.1 Information Required for Re-routing...........................8 3.2.1. Information Required for Re-Routing .................9
4.2.2 Signaling a New Route.........................................9 3.2.2. Signaling a New Route ...............................9
4.3. Persistence of Error Information...............................9 3.3. Persistence of Error Information ..........................10
4.4. Handling Re-route Failure.....................................10 3.4. Handling Re-Route Failure .................................11
4.5. Limiting Re-routing Attempts..................................10 3.5. Limiting Re-Routing Attempts ..............................11
5. Existing Protocol Support for Crankback Re-routing..............11 4. Existing Protocol Support for Crankback Re-Routing .............11
5.1. RSVP-TE ......................................................11 4.1. RSVP-TE ...................................................12
5.2. GMPLS-RSVP-TE ................................................12 4.2. GMPLS-RSVP-TE .............................................13
Section B : Solution Section B : Solution
6. Control of Crankback Operation..................................12 5. Control of Crankback Operation .................................13
6.1. Requesting Crankback and Controlling In-Network Re-routing....12 5.1. Requesting Crankback and Controlling In-Network
6.2. Action on Detecting a Failure.................................13 Re-Routing ................................................13
6.3. Limiting Re-routing Attempts..................................13 5.2. Action on Detecting a Failure .............................14
6.3.1 New Status Codes for Re-routing..............................13 5.3. Limiting Re-Routing Attempts ..............................14
6.4. Protocol Control of Re-routing Behavior.......................14 5.3.1. New Status Codes for Re-Routing ....................15
7. Reporting Crankback Information.................................14 5.4. Protocol Control of Re-Routing Behavior ...................15
7.1. Required Information..........................................14 6. Reporting Crankback Information ................................15
7.2. Protocol Extensions...........................................14 6.1. Required Information ......................................15
7.3 Guidance for Use of IF_ID Error Spec TLVs......................18 6.2. Protocol Extensions .......................................16
7.3.1 General Principles...........................................18 6.3. Guidance for Use of IF_ID ERROR_SPEC TLVs .................20
7.3.2 Error Report TLVs............................................19 6.3.1. General Principles .................................20
7.3.3 Fundamental Crankback TLVs...................................19 6.3.2. Error Report TLVs ..................................21
7.3.4 Additional Crankback TLVs....................................20 6.3.3. Fundamental Crankback TLVs .........................21
7.3.5 Grouping TLVs by Failure Location............................21 6.3.4. Additional Crankback TLVs ..........................22
7.3.6 Alternate Path identification................................22 6.3.5. Grouping TLVs by Failure Location ..................23
7.4. Action on Receiving Crankback Information.....................22 6.3.6. Alternate Path Identification ......................24
7.4.1 Re-route Attempts............................................22 6.4. Action on Receiving Crankback Information .................25
7.4.2 Location Identifiers of Blocked Links or Nodes...............23 6.4.1. Re-Route Attempts ..................................25
7.4.3 Locating Errors within Loose or Abstract Nodes...............23 6.4.2. Location Identifiers of Blocked Links or Nodes .....25
7.4.4 When Re-routing Fails........................................23 6.4.3. Locating Errors within Loose or Abstract Nodes .....26
7.4.5 Aggregation of Crankback Information.........................24 6.4.4. When Re-Routing Fails ..............................26
7.5. Notification of Errors........................................24 6.4.5. Aggregation of Crankback Information ...............26
7.5.1 ResvErr Processing...........................................24 6.5. Notification of Errors ....................................27
7.5.2 Notify Message Processing....................................25 6.5.1. ResvErr Processing .................................27
7.6. Error Values..................................................25 6.5.2. Notify Message Processing ..........................28
7.7. Backward Compatibility........................................25 6.6. Error Values ..............................................28
8. LSP Recovery Considerations.....................................26 6.7. Backward Compatibility ....................................28
8.1. Upstream of the Fault.........................................26 7. LSP Recovery Considerations ....................................29
8.2. Downstream of the Fault.......................................27 7.1. Upstream of the Fault .....................................29
9. IANA Considerations.............................................27 7.2. Downstream of the Fault ...................................30
9.1. Error Codes...................................................27 8. IANA Considerations ............................................30
9.2. IF_ID_ERROR_SPEC TLVs.........................................27 8.1. Error Codes ...............................................30
9.3. LSP_ATTRIBUTES Object.........................................28 8.2. IF_ID_ERROR_SPEC TLVs .....................................31
10. Security Considerations........................................28 8.3. LSP_ATTRIBUTES Object .....................................31
11. Acknowledgments................................................29 9. Security Considerations ........................................31
12. Normative References...........................................30 10. Acknowledgments ...............................................32
13. Informational References.......................................30 11. References ....................................................33
14. Authors' Addresses.............................................31 11.1. Normative References .....................................33
A. Experience of Crankback in TDM-based Networks..................34 11.2. Informative References ...................................33
Appendix A.........................................................35
Section A : Problem Statement Section A : Problem Statement
1. Terminology 1. Introduction and Framework
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
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 comprise a
Label Switching Router (LSR) are coresident and related in a
one-to-one manner. This is a convenience of documentation 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 referring 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 collocated 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.1. Background 1.1. Background
RSVP-TE (RSVP Extensions for LSP Tunnels) [RFC3209] can be used for RSVP-TE (RSVP Extensions for LSP Tunnels) [RFC3209] can be used for
establishing explicitly routed LSPs in an MPLS network. Using establishing explicitly routed LSPs in an MPLS network. Using RSVP-
RSVP-TE, resources can also be reserved along a path to guarantee TE, resources can also be reserved along a path to guarantee and/or
and/or control QoS for traffic carried on the LSP. To designate an control QoS for traffic carried on the LSP. To designate an explicit
explicit path that satisfies QoS guarantees, it is necessary to path that satisfies Quality of Service (QoS) guarantees, it is
discern the resources available to each link or node in the network. necessary to discern the resources available to each link or node in
For the collection of such resource information, routing protocols, the network. For the collection of such resource information,
such as OSPF and IS-IS , can be extended to distribute additional routing protocols, such as OSPF and Intermediate System to
Intermediate System (IS-IS), can be extended to distribute additional
state information [RFC2702]. state information [RFC2702].
Explicit paths can be computed based on the distributed information Explicit paths can be computed based on the distributed information
at the LSR (ingress) initiating an LSP and signaled as Explicit at the LSR (ingress) initiating an LSP and signaled as Explicit
Routes during LSP establishment. Explicit Routes may contain 'loose Routes during LSP establishment. Explicit Routes may contain 'loose
hops' and 'abstract nodes' that convey routing through a collection hops' and 'abstract nodes' that convey routing through a collection
of nodes. This mechanism may be used to devolve parts of the path of nodes. This 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 resource In a distributed routing environment, however, the resource
information used to compute a constraint-based path may be out of information used to compute a constraint-based path may be out of
date. This means that a setup request may be blocked, for example, date. This means that a setup request may be blocked, for example,
because a link or node along the selected path has insufficient because a link or node along the selected path has insufficient
resources. resources.
In RSVP-TE, a blocked LSP setup may result in a PathErr message sent In RSVP-TE, a blocked LSP setup may result in a PathErr message sent
to the ingress, or a ResvErr sent to the egress (terminator). to the ingress, or a ResvErr sent to the egress (terminator). These
These messages may result in the LSP setup being abandoned. In messages may result in the LSP setup being abandoned. In Generalized
Generalized MPLS [RC3473] the Notify message may additionally be MPLS [RFC3473] the Notify message may additionally be used to
used to expedite notification of failures of existing LSPs to ingress expedite notification of failures of existing LSPs to ingress and
and egress LSRs, or to a specific "repair point" - an LSR responsible egress LSRs, or to a specific "repair point" -- an LSR responsible
for performing protection or restoration. for performing protection or restoration.
These existing mechanisms provide a certain amount of information These existing mechanisms provide a certain amount of information
about the path of the failed LSP. about the path of the failed LSP.
Generalized MPLS [RFC3471] and [RFC3473] extends MPLS into networks Generalized MPLS [RFC3471] and [RFC3473] extends MPLS into networks
that manage Layer 2, TDM and lambda resources as well as packet that manage Layer 2, TDM and lambda resources as well as packet
resources. Thus, crankback routing is also useful in GMPLS networks. resources. Thus, crankback routing is also useful in GMPLS networks.
In a network without wavelength converters, setup requests are likely In a network without wavelength converters, setup requests are likely
to be blocked more often than in a conventional MPLS environment to be blocked more often than in a conventional MPLS environment
because the same wavelength must be allocated at each Optical because the same wavelength must be allocated at each Optical Cross-
Cross-Connect on an end-to-end explicit path. This makes crankback Connect on an end-to-end explicit path. This makes crankback routing
routing all the more important in certain GMPLS networks. all the more important in certain GMPLS networks.
2.2. Repair and Recovery 1.2. 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 comprise a
Label Switching Router (LSR) coreside and are related in a one-to-one
manner. This is for the convenience of documentation only.
It should be noted that GMPLS LSRs may be decomposed such that the
control plane components are not physically collocated. Furthermore,
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 errors, are
data plane entities.
o The nodes, areas, and Autonomous Systems (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 referring 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 collocated one-to-one relationship.
Furthermore, in the majority of cases, the control plane and data
plane components are related in a 1:1 ratio and are usually
collocated.
1.3. Repair and Recovery
If the ingress LSR or intermediate area border LSR knows the location If the ingress LSR or intermediate area border LSR knows the location
of the blocked link or node, it can designate an alternate path and of the blocked link or node, it can designate an alternate path and
then reissue the setup request. Determination of the identity of the then reissue the setup request. Determination of the identity of the
blocked link or node can be achieved by the mechanism known as blocked 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 signaling
requires notifying the upstream LSR of the location of the blocked requires notifying the upstream LSR of the location of the blocked
link or node. In some cases this requires more information than is link or node. In some cases, this requires more information than is
currently available in the signaling protocols. currently available in the signaling protocols.
On the other hand, various recovery schemes for link or node On the other hand, various recovery schemes for link or node failures
failures have been proposed in [RFC3469] and include fast have been proposed in [RFC3469] and include fast re-routing. These
re-routing. These schemes rely on the existence of a protecting LSP schemes rely on the existence of a protecting LSP to protect the
to protect the working LSP, but if both the working and protecting working LSP, but if both the working and protecting paths fail, it is
paths fail it is necessary to re-establish the LSP on an end-to-end necessary to re-establish the LSP on an end-to-end basis, avoiding
basis avoiding the known failures. Similarly, fast re-routing by the known failures. Similarly, fast re-routing by establishing a
establishing a recovery path on demand after failure requires recovery path on demand after failure requires computation of a new
computation of a new LSP that avoids the known failures. End-to-end LSP that avoids the known failures. End-to-end recovery for
recovery for alternate routing requires the location of the failed alternate routing requires the location of the failed link or node.
link or node. Crankback routing schemes could be used to notify the Crankback routing schemes could be used to notify the upstream LSRs
upstream LSRs of the location of the failure. of the location of the failure.
Furthermore, in situations where many link or node failures occur at Furthermore, in situations where many link or node failures occur at
the same time, the difference between the distributed routing the same time, the difference between the distributed routing
information and the real-time network state becomes much greater than information and the real-time network state becomes much greater than
in normal LSP setups. LSP recovery might, therefore, be performed in normal LSP setups. LSP recovery might, therefore, be performed
with inaccurate information, which is likely to cause setup blocking. with inaccurate information, which is likely to cause setup blocking.
Crankback routing could improve failure recovery in these situations. Crankback routing could improve failure recovery in these situations.
The requirement for end-to-end allocation of lambda resources in The requirement for end-to-end allocation of lambda resources in
GMPLS networks without wavelength converters means that end-to-end GMPLS networks without wavelength converters means that end-to-end
recovery may be the only way to recover from LSP failures. This is recovery may be the only way to recover from LSP failures. This is
because segment protection may be much harder to achieve in networks because segment protection may be much harder to achieve in networks
of photonic cross-connects where a particular lambda may already be of photonic cross-connects where a particular lambda may already be
in use on other links: End-to-end protection offers the choice of use in use on other links: End-to-end protection offers the choice of use
of another lambda, but this choice is not available in segment of another lambda, but this choice is not available in segment
protection. protection.
This requirement makes crankback re-routing particularly useful in a This requirement makes crankback re-routing particularly useful in a
GMPLS network, in particular in dynamic LSP re-routing cases (no GMPLS network, particularly in dynamic LSP re-routing cases (i.e.,
protecting LSP pre-establishment). when there is no pre-establishment of the protecting LSP).
2.3. Interaction with TE Flooding Mechanisms 1.4. Interaction with TE Flooding Mechanisms
GMPLS uses IGPs (OSPF and IS-IS) to flood traffic engineering (TE) GMPLS uses Interior Gateway Protocols (IGPs) (OSPF and IS-IS) to
information that is used to construct a traffic engineering database flood traffic engineering (TE) information that is used to construct
(TED) which acts as a data source for path computation. a traffic engineering database (TED) which acts as a data source for
path computation.
Crankback signaling is not intended to supplement or replace the Crankback signaling is not intended to supplement or replace the
normal operation of the TE flooding mechanism, since these mechanisms normal operation of the TE flooding mechanism, since these mechanisms
are independent of each other. That is, information gathered from are independent of each other. That is, information gathered from
crankback signaling may be applied to compute an alternate path for crankback signaling may be applied to compute an alternate path for
the LSP for which the information was signaled, but the information the LSP for which the information was signaled, but the information
is not intended to be used to influence the computation of the paths is not intended to be used to influence the computation of the paths
of other LSPs. of other LSPs.
Any requirement to rapidly flood updates about resource availability Any requirement to rapidly flood updates about resource availability
so that they may be applied as deltas to the TED and utilized in so that they may be applied as deltas to the TED and utilized in
future path computations are out of scope of this document. future path computations are out of the scope of this document.
3. Discussion: Explicit Versus Implicit Re-routing Indications 1.5. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
2. Discussion: Explicit versus Implicit Re-Routing Indications
There have been problems in service provider networks when There have been problems in service provider networks when
"inferring" from indirect information that re-routing is allowed. "inferring" from indirect information that re-routing is allowed.
This document proposes the use of an explicit re-routing indication This document proposes the use of an explicit re-routing indication
that explicitly authorizes re-routing, and contrasts it with the that authorizes re-routing, and contrasts it with the inferred or
inferred or implicit re-routing indication that has previously implicit re-routing indication that has previously been used.
been used.
Various existing protocol options and exchanges including the error Various existing protocol options and exchanges, including the error
values of PathErr message [RFC2205, RFC3209] and the Notify message values of PathErr message [RFC2205, RFC3209] and the Notify message
[RFC3473] allow an implementation to infer a situation where [RFC3473], allow an implementation to infer a situation where re-
re-routing can be performed. This allows for recovery from network routing can be performed. This allows for recovery from network
errors or resource contention. errors or resource contention.
However, such inference of recovery signaling is not always desirable However, such inference of recovery signaling is not always desirable
since it may be doomed to failure. For example, experience of using since it may be doomed to failure. For example, experience of using
release messages in TDM-based networks for analogous implicit and release messages in TDM-based networks, for analogous implicit and
explicit re-routing indications purposes provides some guidance. This explicit re-routing indications purposes provides some guidance.
background information is given in Appendix A. This background information is given in Appendix A.
It is certainly the case that with topology information distribution It is certainly the case that with topology information distribution,
as performed with routing protocols such as OSPF, the ingress LSR as performed with routing protocols such as OSPF, the ingress LSR
could infer the re-routing condition. However, convergence of could infer the re-routing condition. However, convergence of
topology information using routing protocols is typically slower than topology information using routing protocols is typically slower than
the expected LSP setup times. One of the reasons for crankback is to the expected LSP setup times. One of the reasons for crankback is to
avoid the overhead of available-link-bandwidth flooding, and to more avoid the overhead of available-link-bandwidth flooding, and to more
efficiently use local state information to direct alternate routing efficiently use local state information to direct alternate routing
at the path computation point. to the path computation point.
[ASH1] shows how event-dependent-routing can just use crankback, and [ASH1] shows how event-dependent-routing can just use crankback, and
not available-link-bandwidth flooding, to decide on the re-route path not available-link-bandwidth flooding, to decide on the re-route path
in the network through "learning models". Reducing this flooding in the network through "learning models". Reducing this flooding
reduces overhead and can lead to the ability to support much larger reduces overhead and can lead to the ability to support much larger
AS sizes. AS sizes.
Therefore, the use of alternate routing should be based on an Therefore, the use of alternate routing should be based on an
explicit indication, and it is best to know the following information explicit indication, and it is best to know the following 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 3. Required Operation
Section 2 identifies some of the circumstances under which crankback Section 1 identifies some of the circumstances under which crankback
may be useful. Crankback routing is performed as described in the may be useful. Crankback routing is performed as described in the
following procedures, when an LSP setup request is blocked along the following procedures, when an LSP setup 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 3.1. Resource Failure or Unavailability
When an LSP setup request is blocked due to unavailable resources, an When an LSP setup request is blocked due to unavailable resources, an
error message response with the location identifier of the blockage error message response with the location identifier of the blockage
should be returned to the LSR initiating the LSP setup (ingress LSR), should be returned to the LSR initiating the LSP setup (ingress LSR),
the area border LSR, the AS border LSR, or to some other repair the area border LSR, the AS border LSR, or some other repair point.
point.
This error message carries an error specification according to This error message carries an error specification according to
[RFC3209] - this indicates the cause of the error and the node/link [RFC3209] -- this indicates the cause of the error and the node/link
on which the error occurred. Crankback operation may require further on which the error occurred. Crankback operation may require further
information as detailed in sections 4.2.1 and 7. information as detailed in Sections 3.2.1 and 6.
A repair point (for example, an ingress LSR) that receives crankback A repair point (for example, an ingress LSR) that receives crankback
information resulting from the failure of an established LSP may information resulting from the failure of an established LSP may
apply local policy to govern how it attempts repair of the LSP. For apply local policy to govern how it attempts repair of the LSP. For
example, it may prioritise repair attempts between multiple LSPs that example, it may prioritize repair attempts between multiple LSPs that
have failed, and it may consider LSPs that have been locally repaired have failed, and it may consider LSPs that have been locally repaired
([RFC4090]) to be less urgent candidates for end-to-end repair. ([RFC4090]) to be less urgent candidates for end-to-end repair.
Further, there is a likelihood that other LSRs are also attempting Furthermore, there is a likelihood that other LSRs are also
LSP repair for LSPs affected by the same fault which may give rise to attempting LSP repair for LSPs affected by the same fault which may
resource contention within the network, so an LSR may stagger its give rise to resource contention within the network, so an LSR may
repair attempts in order to reduce the chance of resource contention. stagger its repair attempts in order to reduce the chance of resource
contention.
4.2. Computation of an Alternate Path 3.2. Computation of an Alternate Path
In a flat network without partitioning of the routing topology, when In a flat network without partitioning of the routing topology, when
the ingress LSR receives the error message it computes an alternate the ingress LSR receives the error message, it computes an alternate
path around the blocked link or node to satisfy QoS guarantees using path around the blocked link or node to satisfy QoS guarantees using
link state information about the network. If an alternate path is link state information about the network. If an alternate path is
found, a new LSP setup request is sent over this path. found, a new LSP setup request is sent over this path.
On the other hand, in a network partitioned into areas such as with On the other hand, in a network partitioned into areas such as with
OSPF, the area border LSR may intercept and terminate the error OSPF, the area border LSR may intercept and terminate the error
response, and perform alternate (re-)routing within the downstream response, and perform alternate (re-)routing within the downstream
area. area.
In a third scenario, any node within an area may act as a repair In a third scenario, any node within an area may act as a repair
point. In this case, each LSR behaves much as an area border LSR as point. In this case, each LSR behaves much like an area border LSR
described above. It can intercept and terminate the error response, as described above. It can intercept and terminate the error
and perform alternate routing. This may be particularly useful where response and perform alternate routing. This may be particularly
domains of computation are applied within the (partitioned) network, useful where domains of computation are applied within the
where such domains are not coincident on the routing partition (partitioned) network, where such domains are not coincident on the
boundaries. However if, all nodes in the network perform re-routing routing partition boundaries. However if, all nodes in the network
it is possible to spend excessive network and CPU resources on perform re-routing it is possible to spend excessive network and CPU
re-routing attempts that would be better made only at designated resources on re-routing attempts that would be better made only at
re-routing nodes. This scenario is somewhat like 'MPLS fast re-route' designated re-routing nodes. This scenario is somewhat like 'MPLS
[RFC4090], in which any node in the MPLS domain can establish 'local fast re-route' [RFC4090], in which any node in the MPLS domain can
repair' LSPs upon failure notification. establish 'local repair' LSPs upon failure notification.
4.2.1 Information Required for Re-routing 3.2.1. Information Required for Re-Routing
In order to correctly compute a route that avoids the blocking In order to correctly compute a route that avoids the blocking
problem, a repair point LSR must gather as much crankback information problem, a repair point LSR must gather as much crankback information
as possible. Ideally, the repair node will be given the node, link as possible. Ideally, the repair node will be given the node, link,
and reason for the failure. and reason for the failure.
The reason for the failure may provide an important discriminator to The reason for the failure may provide an important discriminator to
help decide what action should be taken. For example, a failure that help decide what action should be taken. For example, a failure that
indicates "No Route to Destination" is likely to give rise to a new indicates "No Route to Destination" is likely to give rise to a new
path computation excluding the reporting LSR, but the reason path computation excluding the reporting LSR, but the reason
"Temporary Control Plane Congestion" might lead to a simple retry "Temporary Control Plane Congestion" might lead to a simple retry
after a suitable pause. after a suitable pause.
However, even this information may not be enough to help with However, even this information may not be enough to help with re-
re-computation. Consider for instance an explicit route that contains computation. Consider for instance an explicit route that contains a
a non-explicit abstract node or a loose hop. In this case, the failed non-explicit abstract node or a loose hop. In this case, the failed
node and link is not necessarily enough to tell the repair point node and link are not necessarily enough to tell the repair point
which hop in the explicit route has failed. The crankback information which hop in the explicit route has failed. The crankback
needs to indicate where, within the explicit route, the problem has information needs to indicate where, within the explicit route, the
occurred. problem has occurred.
4.2.2 Signaling a New Route 3.2.2. Signaling a New Route
If the crankback information can be used to compute a new route If the crankback information can be used to compute a new route
avoiding the failed/blocking network resource, the route can be avoiding the failed/blocking network resource, the route can be
signaled as an Explicit Route. signaled as an Explicit Route.
However, it may be that the repair point does not have sufficient However, it may be that the repair point does not have sufficient
topology information to compute an Explicit Route that is guaranteed topology information to compute an Explicit Route that is guaranteed
to avoid the failed link or node. In this case, Route Exclusions to avoid the failed link or node. In this case, Route Exclusions
[EXCLUDE] may be particularly helpful. To achieve this, [EXCLUDE] [RFC4874] may be particularly helpful. To achieve this, [RFC4874]
allows the crankback information to be presented as route exclusions allows 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 3.3. Persistence of Error Information
The repair point LSR that computes the alternate path should store The repair point LSR that computes the alternate path should store
the location identifiers of the blockages indicated in the error the location identifiers of the blockages indicated in the error
message until the LSP is successfully established by downstream LSRs message until the LSP is successfully established by downstream LSRs
or until the repair point LSR abandons re-routing attempts. Since or until the repair point LSR abandons re-routing attempts. Since
crankback signaling information may be returned to the same repair crankback signaling information may be returned to the same repair
point LSR more than once while establishing a specific LSP, the point LSR more than once while establishing a specific LSP, the
repair point LSR SHOULD maintain a history table of all experienced repair point LSR SHOULD maintain a history table of all experienced
blockages for this LSP (at least until the routing protocol updates blockages for this LSP (at least until the routing protocol updates
the state of this information) so that the resulting path the state of this information) so that the resulting path
computation(s) can detour all blockages. computation(s) can detour all blockages.
If a second error response is received by a repair point (while it is If a second error response is received by a repair point (while it is
performing crankback re-routing) it should update the history table performing crankback re-routing) it should update the history table
that lists all experienced blockages, and use the entire gathered that lists all experienced blockages, and use the entire gathered
skipping to change at line 440 skipping to change at page 10, line 28
If a second error response is received by a repair point (while it is If a second error response is received by a repair point (while it is
performing crankback re-routing) it should update the history table performing crankback re-routing) it should update the history table
that lists all experienced blockages, and use the entire gathered that lists all experienced blockages, and use the 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 Note that the purpose of this history table is to correlate
information when repeated retry attempts are made by the same LSR. information when repeated retry attempts are made by the same LSR.
For example, suppose that an attempt is made to route from A through 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 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 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 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 route from A through B, and this may be achieved by use of the
history table. history table.
The history table can be discarded by the signaling controller for A The history table can be discarded by the signaling controller for A
if the LSP is successfully established through A. The history table if the LSP is successfully established through A. The history table
MAY be retained after the signaling controller for A sends an error MAY be retained after the signaling controller for A sends an error
upstream, however it is questionable what value this provides since a upstream, however the value this provides is questionable since a
future retry as a result of crankback re-routing should not attempt future retry as a result of crankback re-routing should not attempt
to route through A. If the history information is retained for a to route through A. If the history information is retained for a
longer period it SHOULD be discarded after a local timeout has longer period it SHOULD be discarded after a local timeout has
expired. This timer is required so that the repair point does not expired. This timer is required so that the repair point does not
apply the history table to an attempt by the ingress to re-establish apply the history table to an attempt by the ingress to re-establish
a failed LSP, but to allow the history table to be available for use a failed LSP, but to allow the history table to be available for use
in re-routing attempts before the ingress declares the LSP as failed. in re-routing attempts before the ingress declares the LSP as failed.
It is RECOMMENDED that the repair point LSR discard the history table It is RECOMMENDED that the repair point LSR discard the history table
using a timer no larger than the LSP retry timer configured on the using a timer no larger than the LSP retry timer configured on the
ingress LSR. The correlation of the timers between the ingress and ingress LSR. The correlation of the timers between the ingress and
repair point LSRs is typically by manual configuration of timers repair point LSRs is typically by manual configuration of timers
local to each LSR, and is outside the scope of this document. local to each LSR, and is outside the scope of this document.
It is not intended that the information in the history table be used The information in the history table is not intended to supplement
to supplement the TED for the computation of paths of other LSPs. the TED for the computation of paths of other LSPs.
4.4. Handling Re-route Failure 3.4. Handling Re-Route Failure
Multiple blockages (for the same LSP) may occur, and successive setup Multiple blockages (for the same LSP) may occur, and successive setup
retry attempts may fail. Retaining error information from previous retry attempts may fail. Retaining error information from previous
attempts ensures that there is no thrashing of setup attempts, and attempts ensures that there is no thrashing of setup attempts, and
knowledge of the blockages increases with each attempt. knowledge of the blockages increases with each attempt.
It may be that after several retries, a given repair point is unable It may be that after several retries, a given repair point is unable
to compute a path to the destination (that is, the egress of the LSP) to compute a path to the destination (that is, the egress of the LSP)
that avoids all of the blockages. In this case, it must pass an that avoids all of the blockages. In this case, it must pass an
error indication message upstream. It is most useful to the upstream error indication message upstream. It is most useful to the upstream
nodes (and in particular to the ingress LSR) that may as repair nodes (and in particular to the ingress LSR) that may repair points
points for the LSP setup, if the error indication message identifies for the LSP setup, if the error indication message identifies all of
all of the downstream blockages and also the repair point that was the downstream blockages and also the repair point that was unable to
unable to compute an alternate path. compute an alternate path.
4.5. Limiting Re-routing Attempts 3.5. Limiting Re-Routing Attempts
It is important to prevent endless repetition of LSP setup attempts It is important to prevent endless repetition of LSP setup attempts
using crankback routing information after error conditions are using crankback routing information after error conditions are
signaled, or during periods of high congestion. It may also be useful signaled, or during periods of high congestion. It may also be
to reduce the number of retries, since failed retries will increase useful to reduce the number of retries, since failed retries will
setup latency and degrade performance by increasing the amount of increase setup latency and degrade performance by increasing the
signaling processing and message exchanges within the network. amount of signaling processing and message exchanges within the
network.
The maximum number of crankback re-routing attempts allowed may be The maximum number of crankback re-routing attempts that are allowed
limited in a variety of ways. This document allows an LSR to limit may be limited in a variety of ways. This document allows an LSR to
the retries per LSP, and assumes that such a limit will be applied limit the retries per LSP, and assumes that such a limit will be
either as a per node configuration for those LSRs that are capable applied either as a per-node configuration for those LSRs that are
of re-routing, or as a network-wide configuration value. capable of re-routing, or as a network-wide configuration value.
When the number of retries at a particular LSR is exceeded, the LSR When the number of retries at a particular LSR is exceeded, the LSR
reports the failure in an upstream direction until it reaches the will report the failure in an upstream direction until it reaches the
next repair point where further re-routing attempts may be attempted, next repair point where further re-routing attempts may be attempted,
or reaches the ingress which may act as a repair point or declare the or it reaches the ingress which may act as a repair point or declare
LSP as faioled. It is important that the crankback information the LSP as failed. It is important that the crankback information
provided indicates that routing back through this node will not this is provided indicates that routing back through this node will
succeed - this situation is similar to that in section 4.4. not succeed; this situation is similar to that in Section 3.4.
5. Existing Protocol Support for Crankback Re-routing 4. 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 route, 1) LSP establishment may fail because of an inability to route,
perhaps because links are down. In this case a PathErr message is perhaps because links are down. In this case a PathErr message is
returned to the ingress. returned to the ingress.
2) LSP establishment may fail because resources are unavailable. 2) LSP establishment may fail because resources are unavailable.
This is particularly relevant in GMPLS where explicit label This is particularly relevant in GMPLS where explicit label
control may be in use. Again, a PathErr message is returned to the control may be in use. Again, a PathErr message is returned to
ingress. the ingress.
3) Resource reservation may fail during LSP establishment, as the 3) Resource reservation may fail during LSP establishment, as the
Resv is processed. If resources are not available on the required Resv is processed. If resources are not available on the required
link or at a specific node, a ResvErr message is returned to the link or at a specific node, a ResvErr message is returned to the
egress node indicating "Admission Control failure" [RFC2205]. The egress node indicating "Admission Control failure" [RFC2205]. The
egress is allowed to change the FLOWSPEC and try again, but in the egress is allowed to change the FLOWSPEC and try again, but in the
event that this is not practical or not supported (particularly in event that this is not practical or not supported (particularly in
the non-PSC context), the egress LSR may choose to take any one of the non-PSC context), the egress LSR may choose to take any one of
the following actions. the following actions.
- Ignore the situation and allow recovery to happen through - Ignore the situation and allow recovery to happen through Path
Path refresh message and refresh timeout [RFC2205]. refresh message and refresh timeout [RFC2205].
- Send a PathErr message towards the ingress indicating - Send a PathErr message towards the ingress indicating "Admission
"Admission Control failure". Control failure".
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.
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], [RFC4373]. In this with LSP setup in GMPLS networks [RFC3471], [RFC3473]. In this
case if resources are not available, a PathErr message is returned case, if resources are not available, a PathErr message is
to ingress indicating "Admission Control failure". returned to ingress 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 4.1. RSVP-TE
In RSVP-TE a failed LSP setup attempt results in a PathErr message In RSVP-TE, a failed LSP setup attempt results in a PathErr message
returned upstream. The PathErr message carries an ERROR_SPEC object, returned upstream. The PathErr message carries an ERROR_SPEC object,
which indicates the node or interface reporting the error and the which indicates the node or interface reporting the error and the
reason for the failure. reason for the failure.
Crankback re-routing can be performed explicitly avoiding the node Crankback re-routing can be performed explicitly avoiding the node or
or interface reported. interface reported.
5.2. GMPLS-RSVP-TE 4.2. GMPLS-RSVP-TE
GMPLS extends the error reporting described above by allowing LSRs to GMPLS extends the error reporting described above by allowing LSRs to
report the interface that is in error in addition to the identity of report the interface that is in error in addition to the identity of
the node reporting the error. This further enhances the ability of a the node reporting the error. This further enhances the ability of a
re-computing node to route around the error. re-computing node 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
report LSP failures direct to a selected node. This message carries LSP failures direct to a selected node. This message carries the
the same error reporting facilities as described above. The Notify 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
as to whether PathErr or Notify provides the stimulus for crankback to whether PathErr or Notify provides the stimulus for crankback
operation. This agreement is constrained by the re-routing behavior operation. This agreement is constrained by the re-routing behavior
selection (as listed in section 6.4). Otherwise, multiple nodes might selection (as listed in Section 5.4). Otherwise, multiple nodes
attempt to repair the LSP at the same time, because: might attempt to repair the LSP at the same time, because:
1) these messages can flow through different paths before 1) these messages can flow through different paths before reaching
reaching the ingress LSR, and the ingress LSR, and
2) the destination of the Notify message might not be the 2) the destination of the Notify message might not be the ingress
ingress LSR. LSR.
Section B : Solution Section B : Solution
6. Control of Crankback Operation 5. Control of Crankback Operation
6.1. Requesting Crankback and Controlling In-Network Re-routing 5.1. Requesting Crankback and Controlling In-Network Re-Routing
When a request is made to set up an LSP tunnel, the ingress LSR When a request is made to set up an LSP tunnel, the ingress LSR
should specify whether it wants crankback information to be collected should specify whether it wants crankback information to be collected
in the event of a failure, and whether it requests re-routing in the event of a failure, and whether it requests re-routing
attempts by any or specific intermediate nodes. For this purpose, a attempts by any or specific intermediate nodes. For this purpose, a
Re-routing Flag field is added to the protocol setup request Re-routing Flag field is added to the protocol setup request
messages. The corresponding values are mutually exclusive. messages. The corresponding values are mutually exclusive.
No Re-routing The ingress node MAY attempt re-routing after No Re-routing The ingress node MAY attempt re-routing
failure. Intermediate nodes SHOULD NOT attempt after failure. Intermediate nodes SHOULD
re-routing after failure. Nodes detecting NOT attempt re-routing after failure.
failures MUST report an error and MAY supply Nodes detecting failures MUST report an
crankback information. This is the default error and MAY supply crankback information.
and backwards compatible option. This is the default and backwards
compatible option.
End-to-end Re-routing The ingress node MAY attempt re-routing after End-to-end Re-routing The ingress node MAY attempt re-routing
failure. Intermediate nodes SHOULD NOT attempt after failure. Intermediate nodes SHOULD
re-routing after failure. Nodes detecting NOT attempt re-routing after failure.
failures MUST report an error and SHOULD
supply crankback information. Nodes detecting failures MUST report an
error and SHOULD supply crankback
information.
Boundary Re-routing Intermediate nodes MAY attempt re-routing Boundary Re-routing Intermediate nodes MAY attempt re-routing
after failure only if they are Area Border after failure only if they are Area Border
Routers or AS Border Routers. The boundary Routers or AS Border Routers (ABRs/ASBRs).
(ABR/ASBR) can either decide to forward the The boundary (ABR/ASBR) can either decide
error message upstream to the ingress to forward the error message upstream to
LSR or try to select another egress boundary the ingress LSR or try to select another
LSR. Other intermediate nodes SHOULD NOT egress boundary LSR. Other intermediate
attempt re-routing. Nodes detecting failures nodes SHOULD NOT attempt re-routing. Nodes
MUST report an error and SHOULD supply
crankback information.
Segment-based Re-routing
Any node MAY attempt re-routing after it
receives an error report and before it passes
the error report further upstream. Nodes
detecting failures MUST report an error and detecting failures MUST report an error and
SHOULD supply full crankback information. SHOULD supply crankback information.
6.2. Action on Detecting a Failure
Segment-based Re-routing Any node MAY attempt re-routing after it
receives an error report and before it
passes the error report further upstream.
Nodes detecting failures MUST report an
error and SHOULD supply full crankback
information.
5.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
not to make re-routing attempts (or has exhausted all possible make re-routing attempts (or has exhausted all possible re-routing
re-routing attempts), the detecting node MUST return a protocol attempts), the detecting node MUST return a protocol error indication
error indication and SHOULD include full crankback information. and SHOULD include full crankback information.
6.3. Limiting Re-routing Attempts 5.3. Limiting Re-Routing Attempts
Each repair point SHOULD apply a locally configurable limit to the Each repair point SHOULD apply a locally configurable limit to the
number of attempts it makes to re-route an LSP. This helps to prevent number of attempts it makes to re-route an LSP. This helps to
excessive network usage in the event of significant faults, and prevent excessive network usage in the event of significant faults,
allows back-off to other repair points which may have a better chance and allows back-off to other repair points which may have a better
of routing around the problem. chance of routing around the problem.
6.3.1 New Status Codes for Re-routing 5.3.1. New Status Codes for Re-Routing
An error code/value of "Routing Problem"/"Re-routing limit exceeded" An error code/value of "Routing Problem"/"Re-routing limit exceeded"
(24/TBD) is used to identify that a node has abandoned crankback (24/22) is used to identify that a node has abandoned crankback re-
re-routing because it has reached a threshold for retry attempts. routing because it has reached a threshold for retry attempts.
A node receiving an error response with this status code MAY also A node receiving an error response with this status code MAY also
attempt crankback re-routing, but it is RECOMMENDED that such attempt crankback re-routing, but it is RECOMMENDED that such
attempts be limited to the ingress LSR. attempts be limited to the ingress LSR.
6.4. Protocol Control of Re-routing Behavior 5.4. Protocol Control of Re-Routing Behavior
The LSP_ATTRIBUTES object defined in [RFC4420] is used on Path The LSP_ATTRIBUTES object defined in [RFC4420] is used on Path
messages to convey the Re-Routing Flag described in section 5.1. messages to convey the Re-Routing Flag described in Section 4.1.
Three bits are defined for inclusion in the LSP Attributes TLV as Three bits are defined for inclusion in the LSP Attributes TLV as
follows. The bit numbers below are suggested and actual values are follows. The bit numbers below have been assigned by IANA.
to be assigned by IANA.
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 for an This flag indicates the end-to-end re-routing behavior for an
LSP under establishment. This MAY also be used for specifying LSP under establishment. This MAY also be used for
the behavior of end-to-end LSP recovery for established LSPs. specifying the behavior of end-to-end LSP recovery for
established LSPs.
2 Boundary re-routing desired. 2 Boundary re-routing desired.
This flag indicates the boundary re-routing behavior for an This flag indicates the boundary re-routing behavior for an
LSP under establishment. This MAY also be used for specifying LSP under establishment. This MAY also be used for
the segment-based LSP recovery through nested crankback for specifying the segment-based LSP recovery through nested
established LSPs. The boundary ABR/ASBR can either decide to crankback for established LSPs. The boundary ABR/ASBR can
forward the PathErr message upstream to an upstream boundary either decide to forward the PathErr message upstream to an
ABR/ASBR or to the ingress LSR. Alternatively, it can try to upstream boundary ABR/ASBR or to the ingress LSR.
select another egress boundary LSR. Alternatively, it can try to select another egress boundary
LSR.
3 Segment-based re-routing desired. 3 Segment-based re-routing desired.
This flag indicates the segment-based re-routing behavior for This flag indicates the segment-based re-routing behavior for
an LSP under establishment. This MAY also be used to specify an LSP under establishment. This MAY also be used to specify
the segment-based LSP recovery for established LSPs. the segment-based LSP recovery for established LSPs.
7. Reporting Crankback Information 6. Reporting Crankback Information
7.1. Required Information 6.1. Required Information
As described above, full crankback information SHOULD indicate the As described above, full crankback information SHOULD indicate the
node, link and other resources, which have been attempted but have node, link, and other resources, which have been attempted but have
failed because of allocation issues or network failure. failed because of allocation issues or network failure.
The default crankback information SHOULD include the interface and The default crankback information SHOULD include the interface and
the node address. the node address.
Any address reported in such crankback information SHOULD be an Any address reported in such crankback information SHOULD be an
address that was distributed by the routing protocols (OSPF and ISIS) address that was distributed by the routing protocols (OSPF and IS-
in their TE link state advertisements. However, some additional IS) in their TE link state advertisements. However, some additional
information such as component link identifiers is additional to this. information such as component link identifiers is additional to this.
7.2. Protocol Extensions 6.2. Protocol Extensions
[RFC3473] defines an IF_ID ERROR_SPEC object that can be used on [RFC3473] defines an IF_ID ERROR_SPEC object that can be used on
PathErr, ResvErr and Notify messages to convey the information PathErr, ResvErr and Notify messages to convey the information
carried in the Error Spec Object defined in [RFC3209]. Additionally, carried in the Error Spec Object defined in [RFC3209]. Additionally,
the IF_ID ERROR_SPEC Object has scope for carrying TLVs that identify the IF_ID ERROR_SPEC Object has the scope for carrying TLVs that
the link associated with the error. identify the link associated with the error.
The TLVs for use with this object are defined in [RFC3471], and are The TLVs for use with this object are defined in [RFC3471], and are
listed below. They are used to identify links in the IF_ID RSVP_HOP listed below. They are used in two places. In the IF_ID RSVP_HOP
object they are used to identify links. In the IF_ID ERROR_SPEC
Object, and in the IF_ID ERROR_SPEC object to identify the failed object they are used to identify the failed resource which is usually
resource which is usually the downstream resource from the reporting the downstream resource from 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)
Note that TLVs 4 and 5 are obsoleted by [RFC4201] and SHOULD NOT be Note that TLVs 4 and 5 are obsoleted by [RFC4201] and SHOULD NOT be
used to identify component interfaces in IF_ID ERROR_SPEC objects. used to identify component interfaces in IF_ID ERROR_SPEC objects.
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.
shown here are only suggested values - final values are TBD and to be
determined by IETF consensus.
Type Length Format Description Type Length Format Description
-------------------------------------------------------------------- --------------------------------------------------------------------
6 var See below DOWNSTREAM_LABEL (GMPLS label) 6 var See below DOWNSTREAM_LABEL (GMPLS label)
7 var See below UPSTREAM_LABEL (GMPLS label) 7 var See below UPSTREAM_LABEL (GMPLS label)
8 8 See below NODE_ID (TE Router ID) 8 8 See below NODE_ID (TE Router ID)
9 x See below OSPF_AREA (Area ID) 9 x See below OSPF_AREA (Area ID)
10 x See below ISIS_AREA (Area ID) 10 x See below ISIS_AREA (Area ID)
11 8 See below AUTONOMOUS_SYSTEM (Autonomous system) 11 8 See below AUTONOMOUS_SYSTEM (Autonomous system)
12 var See below ERO_CONTEXT (ERO subobject) 12 var See below ERO_CONTEXT (ERO subobject)
skipping to change at line 758 skipping to change at page 17, line 30
19 var See below INCOMING_DOWN_LABEL (GMPLS label) 19 var See below INCOMING_DOWN_LABEL (GMPLS label)
20 var See below INCOMING_UP_LABEL (GMPLS label) 20 var See below INCOMING_UP_LABEL (GMPLS label)
21 8 See below REPORTING_NODE_ID (Router ID) 21 8 See below REPORTING_NODE_ID (Router ID)
22 x See below REPORTING_OSPF_AREA (Area ID) 22 x See below REPORTING_OSPF_AREA (Area ID)
23 x See below REPORTING_ISIS_AREA (Area ID) 23 x See below REPORTING_ISIS_AREA (Area ID)
24 8 See below REPORTING_AS (Autonomous system) 24 8 See below REPORTING_AS (Autonomous system)
25 var See below PROPOSED_ERO (ERO subobjects) 25 var See below PROPOSED_ERO (ERO subobjects)
26 var See below NODE_EXCLUSIONS (List of nodes) 26 var See below NODE_EXCLUSIONS (List of nodes)
27 var See below LINK_EXCLUSIONS (List of interfaces) 27 var See below LINK_EXCLUSIONS (List of interfaces)
For types 1, 2 and 3 the format of the Value field is already defined For types 1, 2, and 3 the format of the Value field is already
in [RFC3471]. defined in [RFC3471].
For types 14 and 16, they format of the Value field is the same as For types 14 and 16, the format of the Value field is the same as for
for type 1. type 1.
For types 15 and 17, the format of the Value field is the same as for For types 15 and 17, the format of the Value field is the same as for
type 2. type 2.
For type 18 the format of the Value field is the same as for type 3. For type 18, the format of the Value field is the same as for type 3.
For types 6, 7, 19 and 20 the length field is variable and the Value For types 6, 7, 19, and 20, the length field is variable and the
field is a label as defined in [RFC3471]. As with all uses of labels, Value field is a label as defined in [RFC3471]. As with all uses of
it is assumed that any node that can process the label information labels, it is assumed that any node that can process the label
knows the syntax and semantics of the label from the context. Note information knows the syntax and semantics of the label from the
that all TLVs are zero-padded to a multiple four octets so that if a context. Note that all TLVs are zero-padded to a multiple of four
label is not itself a multiple of four octets it must be octets so that if a label is not itself a multiple of four octets, it
disambiguated from the trailing zero pads by knowledge derived from must be disambiguated from the trailing zero pads by knowledge
the context. derived from the context.
For types 8 and 21 the Value field has the format: For types 8 and 21, 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 TE Router ID (TLV type 8) or the Router ID (TLV type 21) The TE Router ID (TLV type 8) or the Router ID (TLV type 21)
used to identify the node within the IGP. used to identify the node within the IGP.
For types 9 and 22 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. This identifies the The 4-octet area identifier for the node. This identifies the
area where the failure has occurred. area where the failure has occurred.
For types 10 and 23 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 | IS-IS Area Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ISIS Area Identifier (continued) ~ ~ IS-IS Area Identifier (continued) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Length Length
Length of the actual (non-padded) IS-IS Area Identifier in Length of the actual (non-padded) IS-IS Area Identifier in
octets. Valid values are from 2 to 11 inclusive. octets. Valid values are from 2 to 11 inclusive.
ISIS Area Identifier IS-IS Area Identifier
The variable-length IS-IS 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 11 and 24 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 that The AS Number of the associated Autonomous System. Note that
if 16-bit AS numbers are in use, the low order bits (16 if 16-bit AS numbers are in use, the low order bits (16
through 31) should be used and the high order bits (0 through through 31) should be used and the high order bits (0 through
15) should be set to zero. 15) should be set to zero.
For types 12, 13 and 25 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 allowed A sequence of Explicit Route Object (ERO) subobjects. Any ERO
whether defined in [RFC3209], [RFC3473] or other documents. subobjects are allowed whether defined in [RFC3209],
Note that ERO subobjects contain their own types and lengths. [RFC3473], or other documents. Note that ERO subobjects
contain their own types and lengths.
For type 26 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 8 that A sequence of TLVs as defined here of types 1, 2, or 8 that
indicates downstream nodes that have already participated in indicates downstream nodes that have already participated in
crankback attempts and have been declared unusable for the crankback attempts and have been declared unusable for the
current LSP setup attempt. Note that an interface identifier current LSP setup attempt. Note that an interface identifier
may be used to identify a node. may be used to identify a node.
For type 27 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 the same format as type A sequence of TLVs as defined here of the same format as type
1, 2 or 3 TLVs that indicate incoming interfaces at downstream 1, 2 or 3 TLVs that indicate incoming interfaces at downstream
nodes that have already participated in crankback attempts and nodes that have already participated in crankback attempts and
have been declared unusable for the current LSP setup attempt. have been declared unusable for the current LSP setup attempt.
7.3 Guidance for Use of IF_ID ERROR_SPEC TLVs 6.3. Guidance for Use of IF_ID ERROR_SPEC TLVs
7.3.1 General Principles 6.3.1. General Principles
If crankback is not being used, inclusion of an IF-ID ERROR_SPEC If crankback is not being used, inclusion of an IF_ID ERROR_SPEC
object in PathErr, ResvErr and Notify messages follows the processing object in PathErr, ResvErr, and Notify messages follows the
rules defined in [RFC3473] and [RFC4201]. A sender MAY include processing rules defined in [RFC3473] and [RFC4201]. A sender MAY
additional TLVs of types 6 through 27 to report crankback information include additional TLVs of types 6 through 27 to report crankback
for informational/monitoring purposes. information for informational/monitoring purposes.
If crankback is being used, the sender of a PathErr, ResvErr or If crankback is being used, the sender of a PathErr, ResvErr, or
Notify message MUST use the IF_ID ERROR_SPEC object and MUST include Notify message MUST use the IF_ID ERROR_SPEC object and MUST include
at least one of the TLVs in the range 1 through 3 as described in at least one of the TLVs in the range 1 through 3 as described in
[RFC3473], [RFC4201], and the previous paragraph. Additional TLVs [RFC3473], [RFC4201], and the previous paragraph. Additional TLVs
SHOULD also be included to report further information. The following SHOULD also be included to report further information. The following
section gives advice on which TLVs should be used under different section gives advice on which TLVs should be used under different
circumstances, and which TLVs must be supported by LSRs. circumstances, and which TLVs must be supported by LSRs.
Note that all such additional TLVs are optional and MAY be omitted. Note that all such additional TLVs are optional and MAY be omitted.
Inclusion of the optional TLVs SHOULD be performed where doing so Inclusion of the optional TLVs SHOULD be performed where doing so
helps to facilitate error reporting and crankback. The TLVs fall into helps to facilitate error reporting and crankback. The TLVs fall
three categories: those that are essential to report the error, those into three categories: those that are essential to report the error,
that provide additional information that is or may be fundamental to those that provide additional information that is or may be
the utility of crankback, and those that provide additional fundamental to the utility of crankback, and those that provide
information that may be useful for crankback in some circumstances. additional information that may be useful for crankback in some
circumstances.
Note that all LSRs MUST be prepared to receive and forward any TLV as Note that all LSRs MUST be prepared to receive and forward any TLV as
per [RFC3473]. This includes TLVs of type 4 or 5 as defined in per [RFC3473]. This includes TLVs of type 4 or 5 as defined in
[RFC3473] and obsoleted by [RFC4201]. There is, however, no [RFC3473] and obsoleted by [RFC4201]. There is, however, no
requirement for an LSR to actively process any but the TLVs defined requirement for an LSR to actively process any but the TLVs defined
in [RFC3473]. An LSR that proposes to perform crankback re-routing in [RFC3473]. An LSR that proposes to perform crankback re-routing
SHOULD support receipt and processing of all of the fundamental SHOULD support receipt and processing of all of the fundamental
crankback TLVs, and is RECOMMENDED to support the receipt and crankback TLVs, and is RECOMMENDED to support the receipt and
processing of the additional crankback TLVs. processing of the additional crankback TLVs.
It should be noted, however, that some assumptions about the TLVs It should be noted, however, that some assumptions about the TLVs
that will be used MAY be made based on the deployment scenarios. For that will be used MAY be made based on the deployment scenarios. For
example, a router that is deployed in a single-area network does not example, a router that is deployed in a single-area network does not
need to support the receipt and processing of TLV types 22 and 23. need to support the receipt and processing of TLV types 22 and 23.
Those TLVs might be inserted in an IF_ID ERROR_SPEC object, but would Those TLVs might be inserted in an IF_ID ERROR_SPEC object, but would
not need to be processed by the receiver of a PathErr message. not need to be processed by the receiver of a PathErr message.
7.3.2 Error Report TLVs 6.3.2. Error Report TLVs
Error Report TLVs are those in the range 1 through 3. (Note that Error Report TLVs are those in the range 1 through 3. (Note that the
the obsoleted TLVs 4 and 5 may be considered in this category, but obsoleted TLVs 4 and 5 may be considered in this category, but SHOULD
SHOULD NOT be used.) NOT be used.)
As stated above, when crankback information is reported, the IF_ID As stated above, when crankback information is reported, the IF_ID
ERROR_SPEC object MUST be used. When the IF_ID ERROR_SPEC object is ERROR_SPEC object MUST be used. When the IF_ID ERROR_SPEC object is
used, at least one of the TLVs in the range 1 through 3 MUST be used, at least one of the TLVs in the range 1 through 3 MUST be
present. The choice of which TLV to use will be dependent on the present. The choice of which TLV to use will be dependent on the
circumstance of the error and device capabilities. For example, a circumstance of the error and device capabilities. For example, a
device that does not support IPv6 will not need the ability to create device that does not support IPv6 will not need the ability to create
a TLV of type 2. Note, however, that such a device MUST still be a TLV of type 2. Note, however, that such a device MUST still be
prepared to receive and process all error report TLVs. prepared to receive and process all error report TLVs.
7.3.3 Fundamental Crankback TLVs 6.3.3. Fundamental Crankback TLVs
Many of the TLVs report the specific resource that has failed. For Many of the TLVs report the specific resource that has failed. For
example, TLV type 1 can be used to report that the setup attempt was example, TLV type 1 can be used to report that the setup attempt was
blocked by some form of resource failure on a specific interface blocked by some form of resource failure on a specific interface
identified by the IP address supplied. TLVs in this category are 1 identified by the IP address supplied. TLVs in this category are 1
through 11, although TLVs 4 and 5 may be considered to be excluded through 11, although TLVs 4 and 5 may be considered to be excluded
from this category by dint of having been obsoleted. from this category by dint of having been obsoleted.
These TLVs SHOULD be supplied whenever the node detecting and These TLVs SHOULD be supplied whenever the node detecting and
reporting the failure with crankback information has the information reporting the failure with crankback information has the information
available. (Note that some of these TLVs MUST be included as available. (Note that some of these TLVs MUST be included as
described in the previous two sections.) described in the previous two sections.)
The TLVs of type 8, 9, 10, and 11 MAY, however, be omitted according
The TLVs of type 8, 9, 10 and 11 MAY, however, be omitted according
to local policy and relevance of the information. to local policy and relevance of the information.
7.3.4 Additional Crankback TLVs 6.3.4. Additional Crankback TLVs
Some TLVs help to locate the fault within the context of the path of Some TLVs help to locate the fault within the context of the path of
the LSP that was being set up. TLVs of types 12, 13, 14 and 15 help the LSP that was being set up. TLVs of types 12, 13, 14, and 15 help
to set the context of the error within the scope of an explicit path to set the context of the error within the scope of an explicit path
that has loose hops or non-precise abstract nodes. The ERO context that has loose hops 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 notice that
it is a member of the next hop in the ERO (such as a loose or it is a member of the next hop in the ERO (such as a loose or non-
non-specific abstract node) and deduce that its upstream neighbor may specific abstract node) and deduce that its upstream neighbor may
have selected the path using next hop routing. In this case, have selected the path using next hop routing. In this case,
providing the ERO context will be useful to the upstream node that providing the ERO context will be useful to the upstream node that
performs re-routing. performs re-routing.
Note the distinction between TLVs 12 and 13 is the distinction Note the distinction between TLVs 12 and 13 is the distinction
between "this is the hop I was trying to satisfy when I failed" and between "this is the hop I was trying to satisfy when I failed" and
"this is the next hop I was trying to reach when I failed. "this is the next hop I was trying to reach when I failed".
Reporting nodes SHOULD also supply TLVs from the range 12 through 20 Reporting nodes SHOULD also supply TLVs from the range 12 through 20
as appropriate for reporting the error. The reporting nodes MAY also as appropriate for reporting the error. The reporting nodes MAY also
supply TLVs from the range 21 through 27. supply TLVs from the range 21 through 27.
Note that in deciding whether a TLV in the range 12 through 20 "is Note that in deciding whether a TLV in the range 12 through 20 "is
appropriate", the reporting node should consider amongst other appropriate", the reporting node should consider amongst other
things, whether the information is pertinent to the cause of the things, whether the information is pertinent to the cause of the
failure. For example, when a cross-connection fails it may be that failure. For example, when a cross-connection fails, it may be that
the outgoing interface is faulted, in which case only the interface the outgoing 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 the problem is
that the incoming interface cannot be connected to the outgoing that the incoming interface cannot be connected to the outgoing
interface because of temporary or permanent cross-connect interface because of temporary or permanent cross-connect
limitations, the node should also include reference to the incoming limitations, the node should also include reference to the incoming
interface (for example, TLV type 16). interface (for example, TLV type 16).
Four TLVs (21, 22, 23 and 24) allow the location of the reporting Four TLVs (21, 22, 23, and 24) allow the location of the reporting
node to be expanded upon. These TLVs would not be included if the node to be expanded upon. These TLVs would not be included if the
information is not of use within the local system, but might be information is not of use within the local system, but might be added
added by ABRs relaying the error. Note that the Reporting Node ID by ABRs relaying the error. Note that the Reporting Node ID (TLV 21)
(TLV 21) need not be included if the IP address of the reporting need not 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 fully identify
identify the node. the node.
The last three TLVs (25, 26, and 27) provide additional information The last three TLVs (25, 26, and 27) provide additional information
for recomputation points. The reporting node (or some node forwarding for recomputation points. The reporting node (or a node forwarding
the error) MAY make suggestions about how the error could have been the error) MAY make suggestions about how the error could have been
avoided, for example by supplying a partial ERO that would cause the avoided, for example, by supplying a partial ERO that would cause the
LSP to be successfully set up if it were used. As the error LSP to be successfully set up if it were used. As the error
propagates back upstream and as crankback routing is attempted and propagates back upstream and as crankback routing is attempted and
fails, it is beneficial to collect lists of failed nodes and links so fails, it is beneficial to collect lists of failed nodes and links so
that they will not be included in further computations performed at that they will not be included in further computations performed at
upstream nodes. These lists may also be factored into route upstream nodes. These lists may also be factored into route
exclusions [EXCLUDE]. exclusions [RFC4874].
Note that there is no ordering requirement on any of the TLVs within Note that there is no ordering requirement on any of the TLVs within
the IF_ID Error Spec, and no implication should be drawn from the the IF_ID Error Spec, and no implication should be drawn from the
ordering of the TLVs in a received IF_ID Error Spec. ordering of the TLVs in a received IF_ID Error Spec.
The decision of precisely which TLV types a reporting node includes The decision of precisely which TLV types a reporting node includes
is dependent on the specific capabilities of the node, and is is dependent on the specific capabilities of the node, and is outside
outside the scope of this document. the scope of this document.
7.3.5 Grouping TLVs by Failure Location 6.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 the by grouping the TLVs according to the location of the failure and the
context within which it is reported. For example, a TLV that reports context within which it is reported. For example, a TLV that reports
an area identifier would only need to be included as the crankback an area identifier would only need to be included as the crankback
error report transits an area boundary. error report transits an area boundary.
Resource Failure Resource Failure
6 DOWNSTREAM_LABEL 6 DOWNSTREAM_LABEL
7 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 (obsoleted) 4 COMPONENT_IF_DOWNSTREAM (obsoleted)
5 COMPONENT_IF_UPSTREAM (obsoleted) 5 COMPONENT_IF_UPSTREAM (obsoleted)
12 ERO_CONTEXT 12 ERO_CONTEXT
13 ERO_NEXT_CONTEXT 13 ERO_NEXT_CONTEXT
14 PREVIOUS_HOP_IPv4 14 PREVIOUS_HOP_IPv4
15 PREVIOUS_HOP_IPv6 15 PREVIOUS_HOP_IPv6
16 INCOMING_IPv4 16 INCOMING_IPv4
17 INCOMING_IPv6 17 INCOMING_IPv6
18 INCOMING_IF_INDEX 18 INCOMING_IF_INDEX
19 INCOMING_DOWN_LABEL 19 INCOMING_DOWN_LABEL
20 INCOMING_UP_LABEL 20 INCOMING_UP_LABEL
Node failures Node Failures
8 NODE_ID 8 NODE_ID
21 REPORTING_NODE_ID 21 REPORTING_NODE_ID
Area failures Area Failures
9 OSPF_AREA 9 OSPF_AREA
10 ISIS_AREA 10 ISIS_AREA
22 REPORTING_OSPF_AREA 22 REPORTING_OSPF_AREA
23 REPORTING_ISIS_AREA 23 REPORTING_ISIS_AREA
25 PROPOSED_ERO 25 PROPOSED_ERO
26 NODE_EXCLUSIONS 26 NODE_EXCLUSIONS
27 LINK_EXCLUSIONS 27 LINK_EXCLUSIONS
AS failures AS Failures
11 AUTONOMOUS_SYSTEM 11 AUTONOMOUS_SYSTEM
24 REPORTING_AS 24 REPORTING_AS
Although discussion of aggregation of crankback information is out of Although discussion of aggregation of crankback information is out 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. Aggregation is closely aligned to the information presented here. Aggregation is
discussed further in section 7.4.5. discussed further in Section 6.4.5.
7.3.6 Alternate Path Identification 6.3.6. Alternate Path Identification
No new object is used to distinguish between Path/Resv messages for No new object is used to distinguish between Path/Resv messages for
an alternate LSP. Thus, the alternate LSP uses the same SESSION and an alternate LSP. Thus, the alternate LSP uses the same SESSION and
SENDER_TEMPLATE/FILTER_SPEC objects as the ones used for the initial SENDER_TEMPLATE/FILTER_SPEC objects as the ones used for the initial
LSP under re-routing. LSP under re-routing.
7.4. Action on Receiving Crankback Information 6.4. Action on Receiving Crankback Information
7.4.1 Re-route Attempts 6.4.1. Re-Route Attempts
As described in section 3, a node receiving crankback information in As described in Section 2, a node receiving crankback information in
a PathErr must first check to see whether it is allowed to perform a PathErr must first check to see whether it is allowed to perform
re-routing. This is indicated by the Re-routing Flags in the re-routing. This is indicated by the Re-routing Flags in the
LSP_ATTRIBUTES object during LSP setup request. LSP_ATTRIBUTES object during an LSP setup request.
If a node is not allowed to perform re-routing it should forward the If a node is not allowed to perform re-routing it should forward the
PathErr message, or if it is the ingress report the LSP as having PathErr message, or if it is the ingress 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 the established or until the node abandons its attempts to re-route the
LSP. On the next crankback re-routing path computation attempt, the LSP. On the next crankback re-routing path computation attempt, the
LSR should exclude all the failed nodes and links and resources LSR should exclude all the failed nodes, links and resources reported
reported from previous attempts. from previous attempts.
It is an implementation decision whether the crankback information is It is an implementation decision whether the crankback information is
discarded immediately upon successful LSP establishment or retained discarded immediately upon a successful LSP 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 6.4.2. Location Identifiers of Blocked Links or Nodes
In order to compute an alternate path by crankback re-routing, it is In order to compute an alternate path by crankback re-routing, it is
necessary to identify the blocked links or nodes and their locations. necessary to identify the blocked links or nodes and their locations.
The common identifier of each link or node in an MPLS network should The common identifier of each link or node in an MPLS network should
be specified. Both protocol-independent and protocol-dependent be specified. Both protocol-independent and protocol-dependent
identifiers may be specified. Although a general identifier that is identifiers 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 couple of
restrictions on its use as described in the following subsection. restrictions on its use as described in the following subsection.
In link state protocols such as OSPF and IS-IS, each link and node In link state protocols such as OSPF and IS-IS, each link and node in
in a network can be uniquely identified. For example, by the context a network can be uniquely identified, for example, by the context of
of a TE Router ID and the Link ID. If the topology and resource a TE Router ID and the Link ID. If the topology and resource
information obtained by OSPF advertisements is used to compute a information obtained by OSPF advertisements is used to compute a
constraint-based path, the location of a blockage can be represented constraint-based path, the location of a blockage can be represented
by such identifiers. by such identifiers.
Note that, when the routing-protocol-specific link identifiers are Note that when the routing-protocol-specific link identifiers are
used, the Re-routing Flag on the LSP setup request must have been set used, the Re-routing Flag on the LSP setup request must have been set
to show support for boundary or segment-based re-routing. to show support for boundary or segment-based re-routing.
In this document, we specify routing protocol specific link and node In this document, we specify routing protocol specific link and node
identifiers for OSPFv2, OSPFv3, and IS-IS for IPv4 and IPv6. These identifiers for OSPFv2, OSPFv3, and IS-IS for IPv4 and IPv6. These
identifiers may only be used if segment-based re-routing is identifiers may only be used if segment-based re-routing is
supported, as indicated by the Routing Behavior flag on the LSP setup supported, as indicated by the Routing Behavior flag on the LSP setup
request. request.
7.4.3 Locating Errors within Loose or Abstract Nodes 6.4.3. Locating Errors within Loose or Abstract Nodes
The explicit route on the original LSP setup request may contain a The explicit route on the original LSP setup request may contain a
loose or an Abstract Node. In these cases, the crankback information loose or an Abstract Node. In these cases, the crankback information
may refer to links or nodes that were not in the original explicit may refer to links or nodes that were not in the original explicit
route. route.
In order to compute a new path, the repair point may need to identify In order to compute a new path, the repair point may need to identify
the pair of hops (or nodes) in the explicit route between which the the pair of hops (or nodes) in the explicit route between which the
error/blockage occurred. error/blockage occurred.
To assist this, the crankback information reports the top two hops of To assist this, the crankback information reports the top two hops of
the explicit route as received at the reporting node. The first hop the explicit route as received at the reporting node. The first hop
will likely identify the node or the link, the second hop will will likely identify the node or the link, the second hop will
identify a 'next' hop from the original explicit route. identify a 'next' hop from the original explicit route.
7.4.4 When Re-routing Fails 6.4.4. When Re-Routing Fails
When a node cannot or chooses not to perform crankback re-routing it When a node cannot or chooses not to perform crankback 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 replacing the However, when a node was responsible for expanding or replacing the
explicit route as the LSP setup was processed it MUST update the explicit route as the LSP setup was processed, it MUST update the
crankback information with regard to the explicit route that it crankback information with regard to the explicit route that it
received. Only if this is done will the upstream nodes stand a received. Only if this is done will the upstream nodes stand a
chance of successfully routing around the problem. chance of successfully routing around the problem.
7.4.5 Aggregation of Crankback Information 6.4.5. Aggregation of Crankback Information
When a setup blocking error or an error in an established LSP occurs When a setup blocking error or an error in an established LSP occurs
and crankback information is sent in an error notification message, and crankback information is sent in an error notification message,
some node upstream may choose to attempt crankback re-routing. If an upstream node may choose to attempt crankback re-routing. If that
that node's attempts at re-routing fail the node will accumulate a node's attempts at re-routing fail, the node will accumulate a set of
set of failure information. When the node gives up it MUST propagate failure 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
information when it does so. when it does so.
Including a full list of all failures that have occurred due to Including a full list of all failures that have occurred due to
multiple crankback failures by multiple repair point LSRs downstream multiple crankback failures by multiple repair point LSRs downstream
could lead to too much information signaled using the protocol could lead to too much signaled information using the protocol
extensions described in this document. A compression mechanism for extensions described in this document. A compression mechanism for
such information is available using TLVs 26 and 27. These TLVs allow such information is available using TLVs 26 and 27. These TLVs allow
for a more concise accumulation of failure information as crankback for a more concise accumulation of failure information as crankback
failures are propagated upstream. failures are propagated upstream.
Aggregation may involve reporting all links from a node as unusable Aggregation may involve reporting all links from a node as unusable
by flagging the node as unusable, flagging an ABR as unusable when by flagging the node as unusable, flagging an ABR as unusable when
there is no downstream path available, or including a TLV of type 9 there is no downstream path available, or including a TLV of type 9
which results in the exclusion of the entire area, and so on. The which results in the exclusion of the entire area, and so on. The
precise details of how aggregation of crankback information is precise details of how aggregation of crankback information is
performed are beyond the scope of this document. performed are beyond the scope of this document.
7.5. Notification of Errors 6.5. Notification of Errors
7.5.1 ResvErr Processing 6.5.1. ResvErr Processing
As described above, the resource allocation failure for RSVP-TE may As described above, the resource allocation failure for RSVP-TE may
occur on the reverse path when the Resv message is being processed. occur on the reverse path when the Resv message is being processed.
In this case, it is still useful to return the received crankback In this case, it is still useful to return the received crankback
information to the ingress LSR. However, when the egress LSR receives information to the ingress LSR. However, when the egress LSR
the ResvErr message, per [RFC2205] it still has the option of receives the ResvErr message, per [RFC2205] it still has the option
re-issuing the Resv with different resource requirements (although of re-issuing the Resv with different resource requirements (although
not on an alternate path). not on an alternate path).
When a ResvErr carrying crankback information is received at an When a ResvErr carrying crankback information is received at an
egress LSR, the egress LSR MAY ignore this object and perform the egress LSR, the egress LSR MAY ignore this object and perform the
same actions as for any other ResvErr. However, if the egress LSR same actions that it would perform for any other ResvErr. However,
supports the crankback extensions defined in this document, and after if the egress LSR supports the crankback extensions defined in this
all local recovery procedures have failed, it SHOULD generate a document, and after all local recovery procedures have failed, it
PathErr message carrying the crankback information and send it to the SHOULD generate a PathErr message carrying the crankback information
ingress LSR. and send it to the ingress LSR.
If a ResvErr reports on more than one FILTER_SPEC (because the Resv If a ResvErr reports on more than one FILTER_SPEC (because the Resv
carried more than one FILTER_SPEC) then only one set of crankback carried more than one FILTER_SPEC) then only one set of crankback
information should be present in the ResvErr and it should apply to information should be present in the ResvErr and it should apply to
all FILTER_SPEC carried. In this case, it may be necessary per all FILTER_SPEC carried. In this case, it may be necessary per
[RFC2205] to generate more than one PathErr. [RFC2205] to generate more than one PathErr.
7.5.2 Notify Message Processing 6.5.2. Notify Message Processing
[RFC3473] defines the Notify message to enhance error reporting in [RFC3473] defines the Notify message to enhance error reporting in
RSVP-TE networks. This message is not intended to replace the PathErr RSVP-TE networks. This message is not intended to replace the
and ResvErr messages. The Notify message is sent to addresses PathErr and ResvErr messages. The Notify message is sent to
requested on the Path and Resv messages. These addresses could (but addresses requested on the Path and Resv messages. These addresses
need not) identify the ingress and egress LSRs respectively. could (but need not) identify the ingress and egress LSRs,
respectively.
When a network error occurs, such as the failure of link hardware, When a network error occurs, such as the failure of link hardware,
the LSRs that detect the error MAY send Notify messages to the the LSRs that detect the error MAY send Notify messages to the
requested addresses. The type of error that causes a Notify message requested addresses. The type of error that causes a Notify message
to be sent is an implementation detail. to be sent is an implementation detail.
In the event of a failure, an LSR that supports [RFC3473] and the In the event of a failure, an LSR that supports [RFC3473] and the
crankback extensions defined in this document MAY choose to send a crankback extensions defined in this document MAY choose to send a
Notify message carrying crankback information. This would ensure a Notify message carrying crankback information. This would ensure a
speedier report of the error to the ingress/egress LSRs. speedier report of the error to the ingress and/or egress LSRs.
7.6. Error Values 6.6. Error Values
Error values for the Error Code "Admission Control Failure" are Error values for the Error Code "Admission Control Failure" are
defined in [RFC2205]. Error values for the error code "Routing defined in [RFC2205]. Error values for the error code "Routing
Problem" are defined in [RFC3209] and [RFC3473]. Problem" are defined in [RFC3209] and [RFC3473].
A new error value is defined for the error code "Routing Problem". A new error value is defined for the error code "Routing Problem".
"Re-routing limit exceeded" indicates that re-routing has failed "Re-routing limit exceeded" indicates that re-routing has failed
because the number of crankback re-routing attempts has gone beyond because the number of crankback re-routing attempts has gone beyond
the predetermined threshold at an individual LSR. the predetermined threshold at an individual LSR.
7.7. Backward Compatibility 6.7. Backward Compatibility
It is recognized that not all nodes in an RSVP-TE network will It is recognized that not all nodes in an RSVP-TE network will
support the extensions defined in this document. It is important support the extensions defined in this document. It is important
that an LSR that does not support these extensions can continue to that an LSR that does not support these extensions can continue to
process a PathErr, ResvErr or Notify message even if it carries the process a PathErr, ResvErr, or Notify message even if it carries the
newly defined IF_ID ERROR_SPEC information (TLVs). newly defined IF_ID ERROR_SPEC information (TLVs).
This document introduces no backward compatibility issues provided This document does not introduce any backward compatibility issues
that existing implementations conform to the TLV processing rules provided that existing implementations conform to the TLV processing
defined in [RFC3471] and [RFC3473]. rules defined in [RFC3471] and [RFC3473].
8. LSP Recovery Considerations 7. LSP Recovery Considerations
LSP recovery is performed to recover an established LSP when a LSP recovery is performed to recover an established LSP when a
failure occurs along the path. In the case of LSP recovery, the failure occurs along the path. In the case of LSP recovery, the
extensions for crankback re-routing explained above can be applied extensions for crankback re-routing explained above can be applied
for improving performance. This section gives an example of applying for improving performance. This section gives an example of applying
the above extensions to LSP recovery. The goal of this example is the above extensions to LSP recovery. The goal of this example is to
to give a general overview of how this might work, and not to give a give a general overview of how this might work, and not to give a
detailed procedure for LSP recovery. detailed procedure for LSP recovery.
Although there are several techniques for LSP recovery, this Although there are several techniques for LSP recovery, this section
section explains the case of on-demand LSP recovery, which explains the case of on-demand LSP recovery, which attempts to set up
attempts to set up a new LSP on demand after detecting an LSP a new LSP on demand after detecting an LSP failure.
failure.
8.1. Upstream of the Fault 7.1. Upstream of the Fault
When an LSR detects a fault on an adjacent downstream link or node, When an LSR detects a fault on an adjacent downstream link or node, a
a PathErr message is sent upstream. In GMPLS, the ERROR_SPEC object PathErr message is sent upstream. In GMPLS, the ERROR_SPEC object
may carry a Path_State_Remove_Flag indication. Each LSR receiving the may carry a Path_State_Remove_Flag indication. Each LSR receiving
message then releases the corresponding LSP. (Note that if the state the message then releases the corresponding LSP. (Note that if the
removal indication is not present on the PathErr message, the ingress state removal indication is not present on the PathErr message, the
node MUST issue a PathTear message to cause the resources to be ingress node MUST issue a PathTear message to cause the resources to
released.) If the failed LSP has to be recovered at an upstream LSR, be released.) If the failed LSP has to be recovered at an upstream
the IF_ID ERROR SPEC that includes the location information of the LSR, the IF_ID ERROR SPEC that includes the location information of
failed link or node is included in the PathErr message. The ingress, the failed link or node is included in the PathErr message. The
intermediate area border LSR, or indeed any repair point permitted by ingress, intermediate area border LSR, or indeed any repair point
the Re-routing Flags, that receives the PathErr message can terminate permitted by the Re-routing Flags, that receives the PathErr message
the message and then perform alternate routing. can terminate the message and then perform alternate routing.
In a flat network, when the ingress LSR receives the PathErr message In a flat network, when the ingress LSR receives the PathErr message
with the IF_ID ERROR_SPEC TLVs, it computes an alternate path around with the IF_ID ERROR_SPEC TLVs, it computes an alternate path around
the blocked link or node satisfying the QoS guarantees. If an the blocked link or node satisfying the QoS guarantees. If an
alternate path is found, a new Path message is sent over this path alternate 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 procedures can be In a network segmented into areas, the following procedures can be
used. As explained in Section 6.4, the LSP recovery behavior is used. As explained in Section 5.4, the LSP recovery behavior is
indicated in the Flags field of the LSP_ATTRIBUTES object of the indicated in the Flags field of the LSP_ATTRIBUTES object of the Path
Path message. If the Flags indicate "End-to-end re-routing", the message. If 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
which may then issue a new Path message along another path, which is then issue a new Path message along another path, which is the same
the same procedure as in the flat network case above. procedure as in the flat network case above.
If the Flags field indicates Boundary re-routing, the ingress area If the Flags field indicates Boundary re-routing, the ingress area
border LSR MAY terminate the PathErr message and then perform border LSR MAY terminate the PathErr message and then perform
alternate routing within the area for which the area border LSR is alternate routing within the area for which the area border LSR is
the ingress LSR. the ingress LSR.
If the Flags field indicates segment-based re-routing, any node MAY If the Flags field indicates segment-based re-routing, any node MAY
apply the procedures described above for Boundary re-routing. apply the procedures described above for Boundary re-routing.
8.2. Downstream of the Fault 7.2. Downstream of the Fault
This section only applies to errors that occur after an LSP has been This section only applies to errors that occur after an LSP has been
established. Note that an LSR that generates a PathErr with established. Note that an LSR that generates a PathErr with
Path_State_Remove Flag SHOULD also send a PathTear downstream to Path_State_Remove Flag SHOULD also send a PathTear downstream to
clean up the LSP. clean up the LSP.
A node that detects a fault and is downstream of the fault MAY send A node that detects a fault and is downstream of the fault MAY send a
a PathErr and/or Notify message containing an IF_ID ERROR SPEC that PathErr and/or Notify message containing an IF_ID ERROR SPEC that
includes the location information of the failed link or node, and MAY includes the location information of the failed link or node, and MAY
send a PathTear to clean up the LSP at all other downstream nodes. send a PathTear to clean up the LSP at all other downstream nodes.
However, if the reservation style for the LSP is Shared Explicit (SE) However, 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 leaves
downstream LSP state in place and facilitates make-before-break the downstream LSP state in place and facilitates make-before-break
repair of the LSP re-utilizing downstream resources. Note that if the repair of the LSP re-utilizing downstream resources. Note that if
detecting node does not send a PathTear immediately then unused sate the detecting node does not send a PathTear immediately, then the
will timeout according to the normal rules of [RFC2205]. unused state will timeout according to the normal rules of [RFC2205].
At a well-known merge point, an ABR or an ASBR, a similar decision At a well-known merge point, an ABR or an ASBR, a similar decision
might also be made so as to better facilitate make-before-break might also be made so as to better facilitate make-before-break
repair. In this case a received PathTear might be 'absorbed' and not repair. In this case, a received PathTear might be 'absorbed' and
propagated further downstream for an LSP that has SE reservation not propagated further downstream for an LSP that has an SE
style. Note, however, that this is a divergence from the protocol and reservation style. Note, however, that this is a divergence from the
might severely impact normal tear-down of LSPs. protocol and might severely impact normal tear-down of LSPs.
9. IANA Considerations 8. IANA Considerations
9.1 Error Codes 8.1. Error Codes
IANA maintains a registry called "RSVP Parameters" with a subregistry IANA maintains a registry called "RSVP Parameters" with a subregistry
called "Error Codes and Globally-Defined Error Value Sub-Codes". This called "Error Codes and Globally-Defined Error Value Sub-Codes".
subregistry includes the RSVP-TE "Routing Problem" error code that is This subregistry includes the RSVP-TE "Routing Problem" error code
defined in [RFC3209]. that is defined in [RFC3209].
IANA is requested to assign a new error value for the "Routing
Problem" error code as follows:
17 Re-routing limit exceeded.
The value of 17 is suggested and is for confirmation by IANA. IANA has assigned a new error value for the "Routing Problem" error
code as follows:
9.2 IF_ID_ERROR_SPEC TLVs 22 Re-routing limit exceeded.
The IF_ID_ERROR_SPEC TLV type values defined in [RFC3471] 8.2. IF_ID_ERROR_SPEC TLVs
are maintained by IANA in the "Interface_ID Types" sub-registry of
the "GMPLS Signaling Parameters" registry.
IANA is requested to make new assignments from this subregistry for The IF_ID_ERROR_SPEC TLV type values defined in [RFC3471] are
the new TLV types defined in Section 7.2 of this document. maintained by IANA in the "Interface_ID Types" subregistry of the
"GMPLS Signaling Parameters" registry.
The text 'see below' may be replaced by 'see RFC' within the IANA has made new assignments from this subregistry for the new TLV
subregistry to give a clear reference to the location of the types defined in Section 6.2 of this document.
definition of the TLV format.
9.3 LSP_ATTRIBUTES Object 8.3. LSP_ATTRIBUTES Object
IANA maintains an "RSVP TE Parameters" registry with an "Attributes IANA maintains an "RSVP TE Parameters" registry with an "Attributes
Flags" subregistry. IANA is requested to make three new allocations Flags" subregistry. IANA has made three new allocations from this
from this registry as listed in Section 6.4. registry as listed in Section 5.4.
These bits are defined for inclusion in the LSP Attributes TLV of These bits are defined for inclusion in the LSP Attributes TLV of the
the LSP_ATTRIBUTES. The values shown are suggested and are for LSP_ATTRIBUTES. The values shown have been assigned by IANA.
confirmation by IANA.
10. Security Considerations 9. Security Considerations
The RSVP-TE trust model assumes that RSVP-TE neighbors and peers The RSVP-TE trust model assumes that RSVP-TE neighbors and peers
trust each other to exchange ligitimate and non-malicious messages. trust each other to exchange legitimate and non-malicious messages.
This assumption is necessary in order that the signaling protocol can This assumption is necessary in order that the signaling protocol can
function. function.
Note that this trust model is assumed to cascade. That is, if an LSR Note that this trust model is assumed to cascade. That is, if an LSR
trusts its neighbors, it extends this trust to all LSRs that its trusts its neighbors, it extends this trust to all LSRs that its
neighbor trusts. This means that the trust model is usually applied neighbor trusts. This means that the trust model is usually applied
across the whole network to create a trust domain. across the whole network to create a trust domain.
Authentication of neighbor identity is already a standard provision Authentication of neighbor identity is already a standard provision
of RSVP-TE, as is the protection of messages against tampering and of RSVP-TE, as is the protection of messages against tampering and
spoofing. Refer to [RFC2205], [RFC3209], and [RFC3473] for a spoofing. Refer to [RFC2205], [RFC3209], and [RFC3473] for a
description of applicable security considerations. These description of applicable security considerations. These
considerations and mechanisms are applicable to hop-by-hop message considerations and mechanisms are applicable to hop-by-hop message
exchanges (such as used for crankback propagation on PathErr exchanges (such as used for crankback propagation on PathErr
messages) and directed message exchanges (such as used for crankback messages) and directed message exchanges (such as used for crankback
skipping to change at line 1391 skipping to change at page 31, line 45
Authentication of neighbor identity is already a standard provision Authentication of neighbor identity is already a standard provision
of RSVP-TE, as is the protection of messages against tampering and of RSVP-TE, as is the protection of messages against tampering and
spoofing. Refer to [RFC2205], [RFC3209], and [RFC3473] for a spoofing. Refer to [RFC2205], [RFC3209], and [RFC3473] for a
description of applicable security considerations. These description of applicable security considerations. These
considerations and mechanisms are applicable to hop-by-hop message considerations and mechanisms are applicable to hop-by-hop message
exchanges (such as used for crankback propagation on PathErr exchanges (such as used for crankback propagation on PathErr
messages) and directed message exchanges (such as used for crankback messages) and directed message exchanges (such as used for crankback
propagation on Notify messages). propagation on Notify messages).
Key management may also be used with RSVP-TE to help to protect Key management may also be used with RSVP-TE to help to protect
against impersonation and also against message content falsification. against impersonation and message content falsification. This
This requires the maintenance, exchange, and configuration of keys on requires the maintenance, exchange, and configuration of keys on each
each LSR. Note that such maintenance may be especially onerous to LSR. Note that such maintenance may be especially onerous to
operators, hence it is important to limit the number of keys while operators, hence it is important to limit the number of keys while
ensuring the required level of security. ensuring the required level of security.
This document does not introduce any protocol elements or message This document does not introduce any protocol elements or message
exchanges that change the operation of RSVP-TE security. exchanges that change the operation of RSVP-TE security.
However, it should be noted that crankback is envisaged as an However, it should be noted that crankback is envisaged as an inter-
inter-domain mechanism, and as such it is likely that crankback domain mechanism, and as such it is likely that crankback information
information is exchanged over trust domain borders. In these cases is exchanged over trust domain borders. In these cases, it is
it is expected that the information from within a neighboring expected that the information from within a neighboring domain would
domain would be of little or no value to the node performing be of little or no value to the node performing crankback re-routing
crankback re-routing and would be ignored. In any case, it is highly and would be ignored. In any case, it is highly likely that the
likely that the reporting domain will have applied some form of reporting domain will have applied some form of information
information aggregation in order to preserve the confirentiality of aggregation in order to preserve the confidentiality of its network
its network topology. topology.
The issue of a direct attack by one domain upon another domain is The issue of a direct attack by one domain upon another domain is
possible and domain administrators should apply policies to protect possible and domain administrators should apply policies to protect
their domains against the results of another domain attempting to their domains against the results of another domain attempting to
thrash LSPs by allowing them to set up before reporting them as thrash LSPs by allowing them to set up before reporting them as
failed. On the whole, it is expected that commercial contracts failed. On the whole, it is expected that commercial contracts
between trust domains will provide a degree of protection. between trust domains will provide a degree of protection.
A more serious threat might arise if a domain reports that neither it A more serious threat might arise if a domain reports that neither it
nor its downstream neighbor can provide a path to the destination. nor its downstream neighbor can provide a path to the destination.
Such a report could be bogus in that the reporting domain might not Such a report could be bogus in that the reporting domain might not
have allowed the downstream domain the chance to attempt to provide a have allowed the downstream domain the chance to attempt to provide a
path. (Note that the same problem does not arise for nodes within a path. Note that the same problem does not arise for nodes within a
domain because of the trust model.) This type of malicious behavior domain because of the trust model. This type of malicious behavior
is hard to overcome, but may be detected by use of indirect path is hard to overcome, but may be detected by use of indirect path
computation requests send direct to the falsely reported domain using computation requests sent direct to the falsely reported domain using
mechanisms such as the Path Computation Element [RFC4655]. mechanisms such as the Path Computation Element [RFC4655].
Note that a separate document describing inter-domain MPLS and GMPLS Note that a separate document describing inter-domain MPLS and GMPLS
security considerations will be produced. security considerations will be produced.
Finally, it should be noted that while the extensions in this Finally, it should be noted that while the extensions in this
document introduce no new security holes in the protocols, should a document introduce no new security holes in the protocols, should a
malicious user gain protocol access to the network, the crankback malicious user gain protocol access to the network, the crankback
information might be used to prevent establishment of valid LSPs. information might be used to prevent establishment of valid LSPs.
Thus, the existing security features available in RSVP-TE should be Thus, the existing security features available in RSVP-TE should be
carefully considered by all deployers and SHOULD be made available by carefully considered by all deployers and SHOULD be made available by
all implementations that offer cranback. Note that the implementation all implementations that offer crankback. Note that the
of re-routing attempt thresholds are also particularly useful in this implementation of re-routing attempt thresholds are also particularly
context. useful in this context.
11. Acknowledgments 10. Acknowledgments
We would like to thank Juha Heinanen and Srinivas Makam for their We would like to thank Juha Heinanen and Srinivas Makam for their
review and comments, and Zhi-Wei Lin for his considered opinions. review and comments, and Zhi-Wei Lin for his considered opinions.
Thanks, too, to John Drake for encouraging us to resurrect this Thanks, too, to John Drake for encouraging us to resurrect this
document and consider the use of the IF_ID ERROR SPEC object. Thanks document and consider the use of the IF_ID ERROR SPEC object. Thanks
for a welcome and very thorough review by Dimitri Papadimitriou. for a welcome and very thorough review by Dimitri Papadimitriou.
Stephen Shew made useful comments for clarification through the Stephen Shew made useful comments for clarification through the ITU-T
ITU-T liaison process. liaison process.
Simon Marshall-Unitt made contributions to this draft. Simon Marshall-Unitt made contributions to this document.
SecDir review was provided by Tero Kivinen. Thanks to Ross Callon for SecDir review was provided by Tero Kivinen. Thanks to Ross Callon
useful discussions of prioritization of crankback re-routing for useful discussions of prioritization of crankback re-routing
attempts. attempts.
12. Normative References 11. References
11.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2205] R. Braden, et al., "Resource ReSerVation Protocol (RSVP) [RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S.
Version 1 Functional Specification", RFC2205, September Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1
1997. Functional Specification", RFC 2205, September 1997.
[RFC3209] D. Awduche, et al., "RSVP-TE: Extensions to RSVP for LSP [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC3209, December 2001. Tunnels", RFC3209, December 2001.
[RFC3471] P. Ashwood-Smith and L. Berger, et al., "Generalized [RFC3471] Berger, L., Ed., "Generalized Multi-Protocol Label
MPLS - Signaling Functional Description", RFC 3471, Switching (GMPLS) Signaling Functional Description", RFC
January 2003. 3471, January 2003.
[RFC3473] L. Berger, et al., "Generalized MPLS Signaling - RSVP-TE [RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label
Extensions", RFC 3473, January 2003. Switching (GMPLS) Signaling Resource ReserVation
Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC
3473, January 2003.
[RFC4420] Farrel, A., et al, "Encoding of Attributes for [RFC4420] Farrel, A., Ed., Papadimitriou, D., Vasseur, J.-P., and A.
Multiprotocol Label Switching (MPLS) Label Switched Path Ayyangar, "Encoding of Attributes for Multiprotocol Label
(LSP) Establishment Using RSVP-TE", RFC 4420, February Switching (MPLS) Label Switched Path (LSP) Establishment
2006. Using Resource ReserVation Protocol-Traffic Engineering
(RSVP-TE)", RFC 4420, February 2006.
13. Informational References 11.2. Informative 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.
[RFC2702] D. Awduche, et al., "Requirements for Traffic [RFC2702] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M., and J.
Engineering Over MPLS", RFC2702, September 1999. McManus, "Requirements for Traffic Engineering Over MPLS",
RFC 2702, September 1999.
[RFC3469] V. Sharma, et al., "Framework for MPLS-based Recovery", [RFC3469] Sharma, V., Ed., and F. Hellstrand, Ed., "Framework for
RFC 3469, February 2003. Multi-Protocol Label Switching (MPLS)-based Recovery", RFC
3469, February 2003.
[RFC4090] Ping Pan, et al, "Fast Reroute Extensions to RSVP-TE [RFC4090] Pan, P., Ed., Swallow, G., Ed., and A. Atlas, Ed., "Fast
for LSP Tunnels", RFC 4090, May 2005. Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090,
May 2005.
[RFC4201] Kompella, K., Rekhter, Y., and L. Berger, "Link Bundling
in MPLS Traffic Engineering (TE)", RFC 4201, October 2005.
[RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path [RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path
Computation Element (PCE)-Based Architecture", RFC 4655, Computation Element (PCE)-Based Architecture", RFC 4655,
August 2006. August 2006.
[G8080] ITU-T Recommendation G.808/Y.1304, Architecture for the [RFC4874] Lee, CY., Farrel, A., and S. De Cnodder, "Exclude Routes -
Automatically Switched Optical Network (ASON), November Extension to Resource ReserVation Protocol-Traffic
2001. For information on the availability of this Engineering (RSVP-TE)", RFC 4874, April 2007.
document, please see http://www.itu.int.
[EXCLUDE] C-Y. Lee, A. Farrel and S. De Cnodder, "Exclude Routes -
Extension to RSVP-TE",
draft-ietf-ccamp-rsvp-te-exclude-route, work in
progress.
[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>,
<af-pnni-0055.000>, May 1996. May 1996.
14. Authors' Addresses
Adrian Farrel (Editor)
Old Dog Consulting
Phone: +44 (0) 1978 860944
EMail: adrian@olddog.co.uk
Arun Satyanarayana
Cisco Systems, Inc.
170 West Tasman Dr.
San Jose, CA 95134
Phone: +1 408 853-3206
Email: asatyana@cisco.com
Atsushi Iwata
NEC Corporation
System Platforms Research Laboratories
1753 Shimonumabe Nakahara-ku,
Kawasaki, Kanagawa, 211-8666, JAPAN
Phone: +81-(44)-396-2744
Fax: +81-(44)-431-7612
E-Mail: a-iwata@ah.jp.nec.com
Norihito Fujita
NEC Corporation
System Platforms Research Laboratories
1753 Shimonumabe Nakahara-ku,
Kawasaki, Kanagawa, 211-8666, JAPAN
Phone: +81-(44)-396-2091
Fax: +81-(44)-431-7644
E-Mail: n-fujita@bk.jp.nec.com
Gerald R. Ash
AT&T
Room MT D5-2A01
200 Laurel Avenue
Middletown, NJ 07748, USA
Phone: (+1) 732-420-4578
Fax: (+1) 732-368-8659
EMail: gash@att.com
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
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
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and 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
originating node. However, this sometimes leads to problems. originating node. However, this sometimes leads to problems.
*--------------------* *-----------------* *--------------------* *-----------------*
| | | | | | | |
| N2 ----------- N3-|--|----- AT--- EO2 | | N2 ----------- N3-|--|----- AT--- EO2 |
| | | \| | / | | | | | \| | / | |
| | | |--|- / | | | | | |--|- / | |
| | | | | \/ | | | | | | | \/ | |
| | | | | /\ | | | | | | | /\ | |
skipping to change at line 1628 skipping to change at page 35, line 36
A-1 A-2 A-1 A-2
Figure 1. Example of network topology Figure 1. Example of network topology
Figure 1 illustrates four examples based on service-provider Figure 1 illustrates four examples based on service-provider
experiences with respect to crankback (i.e., explicit indication) experiences with respect to crankback (i.e., explicit indication)
versus implicit indication through a release with CV. In this versus implicit indication through a release with CV. In this
example, N1, N2,N3, and N4 are located in one area (A-1), and AT, example, N1, N2,N3, and N4 are located in one area (A-1), and AT,
EO1, and EO2 are in another area (A-2). EO1, and EO2 are in another area (A-2).
Note that two distinct areas are used in this example to expose the Note that two distinct areas are used in this example to clearly
issues clearly. In fact, the issues are not limited to multi-area expose the issues. In fact, the issues are not limited to multi-area
networks, but arise whenever path computation is distributed networks, but arise whenever path computation is distributed
throughout the network. For example where loose routes, AS routes or throughout the network, for example, where loose routes, AS routes,
path computation domains are used. or path computation domains are used.
1. A connection request from node N1 to EO1 may route to N4 and then 1. A connection request from node N1 to EO1 may route to N4 and then
find "all circuits busy". N4 returns a release message to N1 with find "all circuits busy". N4 returns a release message to N1 with
CV34 indicating all circuits busy. Normally, a node such as N1 is CV34 indicating all circuits busy. Normally, a node such as N1 is
programmed to block a connection request when receiving CV34, programmed to block a connection request when receiving CV34,
although there is good reason to try to alternate route the although there is good reason to try to alternately route the
connection request via N2 and N3. connection request via N2 and N3.
Some service providers have implemented a technique called route Some service providers have implemented a technique called Route
advance (RA), where if a node that is RA capable receives a Advance (RA), where if a node that is RA capable receives a
release message with CV34, it will use this as an implicit release message with CV34, it will use this as an implicit re-
re-route indication and try to find an alternate route for the route indication and try to find an alternate route for the
connection request if possible. In this example, alternate route connection request if possible. In this example, alternate route
N1-N2-N3-EO1 can be tried and may well succeed. N1-N2-N3-EO1 can be tried and may well succeed.
2. Suppose a connection request goes from N2 to N3 to AT trying to 2. Suppose a connection request goes from N2 to N3 to AT while trying
reach EO2 and is blocked at link AT-EO2. Node AT returns a CV34 to reach EO2 and is blocked at link AT-EO2. Node AT returns a
and with RA, N2 may try to re-route N2-N1-N4-AT-EO2, but of CV34 and with RA, N2 may try to re-route N2-N1-N4-AT-EO2, but of
course this fails again. The problem is that N2 does not realize course this fails again. The problem is that N2 does not realize
where this blocking occurred based on the CV34, and in this case where this blocking occurred based on the CV34, and in this case
there is no point in further alternate routing. there is no point in further alternate routing.
3. However, in another case of a connection request from N2 to E02, 3. However, in another case of a connection request from N2 to E02,
suppose that link N3-AT is blocked. In this case N3 should return suppose that link N3-AT is blocked. In this case N3 should return
crankback information (and not CV34) so that N2 can alternate crankback information (and not CV34) so that N2 can alternate
route to N1-N4-AT-EO2, which may well be successful. route to N1-N4-AT-EO2, which may well be successful.
4. In a final example, for a connection request from EO1 to N2, EO1 4. In a final example, for a connection request from EO1 to N2, EO1
first tries to route the connection request directly to N3. first tries to route the connection request directly to N3.
However, node N3 may reject the connection request even if there However, node N3 may reject the connection request even if there
is bandwidth available on link N3-EO1 (perhaps for priority is bandwidth available on link N3-EO1 (perhaps for priority
routing considerations, e.g., reserving bandwidth for high routing considerations, e.g., reserving bandwidth for high
priority connection requests). However, when N3 returns CV34 in priority connection requests). However, when N3 returns CV34 in
the release message, EO1 blocks the connection request (a normal the release message, EO1 blocks the connection request (a normal
response to CV34 especially if E01-N4 is already known blocked) response to CV34 especially if E01-N4 is already known to be
rather than trying to alternate route through AT-N3-N2, which blocked) rather than trying to alternate route through AT-N3-N2,
might be successful. If N3 returns crankback information, EO1 which might be successful. If N3 returns crankback information,
could respond by trying the alternate route. EO1 could respond by trying the alternate route.
It is certainly the case that with topology exchange, such as OSPF, It is certainly the case that with topology exchange, such as
the ingress LSR could infer the re-routing condition. However, OSPF, the ingress LSR could infer the re-routing condition.
convergence of routing information is typically slower than the However, convergence of routing information is typically slower
expected LSP setup times. One of the reasons for crankback is to than the expected LSP setup times. One of the reasons for
avoid the overhead of available-link-bandwidth flooding, and to more crankback is to avoid the overhead of available-link-bandwidth
efficiently use local state information to direct alternate routing flooding, and to more efficiently use local state information to
at the ingress-LSR. direct alternate routing 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 (as in examples 3 and 4), and it is best explicit indication (as in examples 3 and 4), and it is best to know
to know the following information separately: the following information separately:
a) where blockage/congestion occurred (as in examples 1-2), a) where blockage/congestion occurred (as in examples 1-2)
and and
b) whether alternate routing "should" be attempted even if b) whether alternate routing "should" be attempted even if there
there is no "blockage" (as in example 4). is no "blockage" (as in example 4).
Authors' Addresses
Adrian Farrel (Editor)
Old Dog Consulting
Phone: +44 (0) 1978 860944
EMail: adrian@olddog.co.uk
Arun Satyanarayana
Cisco Systems, Inc.
170 West Tasman Dr.
San Jose, CA 95134
Phone: +1 408 853-3206
EMail: asatyana@cisco.com
Atsushi Iwata
NEC Corporation
System Platforms Research Laboratories
1753 Shimonumabe Nakahara-ku,
Kawasaki, Kanagawa, 211-8666, JAPAN
Phone: +81-(44)-396-2744
Fax: +81-(44)-431-7612
EMail: a-iwata@ah.jp.nec.com
Norihito Fujita
NEC Corporation
System Platforms Research Laboratories
1753 Shimonumabe Nakahara-ku,
Kawasaki, Kanagawa, 211-8666, JAPAN
Phone: +81-(44)-396-2091
Fax: +81-(44)-431-7644
EMail: n-fujita@bk.jp.nec.com
Gerald R. Ash
AT&T
EMail: gash5107@yahoo.com
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
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
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
 End of changes. 230 change blocks. 
699 lines changed or deleted 604 lines changed or added

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