draft-ietf-ccamp-crankback-04.txt   draft-ietf-ccamp-crankback-05.txt 
Network Working Group Adrian Farrel (editor) Network Working Group Adrian Farrel (editor)
Internet Draft Old Dog Consulting Internet Draft Old Dog Consulting
Category: Standards Track Category: Standards Track
Expires: August 2005 Arun Satyanarayana Expires: November 2005 Arun Satyanarayana
Cisco Systems, Inc.
Atsushi Iwata Atsushi Iwata
Norihito Fujita Norihito Fujita
NEC Corporation NEC Corporation
Gerald R. Ash Gerald R. Ash
AT&T AT&T
February 2005 May 2005
Crankback Signaling Extensions for MPLS and GMPLS Signaling Crankback Signaling Extensions for MPLS and GMPLS RSVP-TE
<draft-ietf-ccamp-crankback-04.txt>
<draft-ietf-ccamp-crankback-05.txt>
Status of this Memo Status of this Memo
This document is an Internet-Draft and is subject to all provisions By submitting this Internet-Draft, each author represents that any
of Section 3 of RFC 3667. By submitting this Internet-Draft, each applicable patent or other IPR claims of which he or she is aware
author represents that any applicable patent or other IPR claims of have been or will be disclosed, and any of which he or she becomes
which he or she is aware have been or will be disclosed, and any of aware will be disclosed, in accordance with Section 6 of BCP 79.
which he or she become aware will be disclosed, in accordance with
RFC 3668.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts. groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
skipping to change at line 52 skipping to change at line 53
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 is
returned from the point of failure to allow new setup attempts to be returned from the point of failure to allow new setup attempts to be
made avoiding the blocked resources. Crankback can also be applied to made avoiding the blocked resources. Crankback can also be applied to
LSP restoration to indicate the location of the failed link or node. LSP 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", RFC3473. These extensions mean that the LSP
setup request can be retried on an alternate path that detours around setup request can be retried on an alternate path that detours around
blocked links or nodes. This offers significant improvements in the blocked links or nodes. This offers significant improvements in the
successful setup and recovery ratios for LSPs, especially in 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......................................................4 1. Terminology......................................................3
1.1. Control Plane and Data Plane Separation........................4 1.1. Control Plane and Data Plane Separation........................3
2. Introduction and Framework.......................................5 2. Introduction and Framework.......................................4
2.1. Background.....................................................5 2.1. Background.....................................................4
2.2. Repair and Restoration.........................................6 2.2. Repair and Recovery............................................5
2.3. Interaction with TE Flooding Mechanisms .......................6 2.3. Interaction with TE Flooding Mechanisms .......................6
3. Discussion: Explicit Versus Implicit Re-routing Indications......7 3. Discussion: Explicit Versus Implicit Re-routing Indications......6
4. Required Operation...............................................8 4. Required Operation...............................................7
4.1. Resource Failure or Unavailability.............................8 4.1. Resource Failure or Unavailability.............................7
4.2. Computation of an Alternate Path...............................8 4.2. Computation of an Alternate Path...............................7
4.2.1 Information Required for Re-routing...........................9 4.2.1 Information Required for Re-routing...........................8
4.2.2 Signaling a New Route.........................................9 4.2.2 Signaling a New Route.........................................8
4.3. Persistence of Error Information...............................9 4.3. Persistence of Error Information...............................9
4.4. Handling Re-route Failure.....................................10 4.4. Handling Re-route Failure......................................9
4.5. Limiting Re-routing Attempts..................................10 4.5. Limiting Re-routing Attempts..................................10
5. Existing Protocol Support for Crankback Re-routing..............11 5. Existing Protocol Support for Crankback Re-routing..............10
5.1. RSVP-TE ......................................................12 5.1. RSVP-TE ......................................................11
5.2. GMPLS-RSVP-TE ................................................12 5.2. GMPLS-RSVP-TE ................................................11
Section B : Solution Section B : Solution
6. Control of Crankback Operation..................................12 6. Control of Crankback Operation..................................12
6.1. Requesting Crankback and Controlling In-Network Re-routing....12 6.1. Requesting Crankback and Controlling In-Network Re-routing....12
6.2. Action on Detecting a Failure.................................13 6.2. Action on Detecting a Failure.................................13
6.3. Limiting Re-routing Attempts..................................14 6.3. Limiting Re-routing Attempts..................................13
6.3.1 New Status Codes for Re-routing..............................14 6.3.1 New Status Codes for Re-routing..............................13
6.4. Protocol Control of Re-routing Behavior.......................14 6.4. Protocol Control of Re-routing Behavior.......................13
7. Reporting Crankback Information.................................15 7. Reporting Crankback Information.................................14
7.1. Required Information..........................................15 7.1. Required Information..........................................14
7.2. Protocol Extensions...........................................15 7.2. Protocol Extensions...........................................14
7.3 Guidance for Use of IF_ID Error Spec TLVs......................19 7.3 Guidance for Use of IF_ID Error Spec TLVs......................18
7.3.1 General Principles...........................................19 7.3.1 General Principles...........................................18
7.3.2 Error Report TLVs............................................20 7.3.2 Error Report TLVs............................................19
7.3.3 Fundamental Crankback TLVs...................................20 7.3.3 Fundamental Crankback TLVs...................................19
7.3.4 Additional Crankback TLVs....................................20 7.3.4 Additional Crankback TLVs....................................20
7.3.5 Grouping TLVs by Failure Location............................22 7.3.5 Grouping TLVs by Failure Location............................21
7.3.6 Alternate Path identification................................23 7.3.6 Alternate Path identification................................22
7.4. Action on Receiving Crankback Information.....................23 7.4. Action on Receiving Crankback Information.....................22
7.4.1 Re-route Attempts............................................23 7.4.1 Re-route Attempts............................................22
7.4.2 Location Identifiers of Blocked Links or Nodes...............23 7.4.2 Location Identifiers of Blocked Links or Nodes...............22
7.4.3 Locating Errors within Loose or Abstract Nodes...............24 7.4.3 Locating Errors within Loose or Abstract Nodes...............23
7.4.4 When Re-routing Fails........................................24 7.4.4 When Re-routing Fails........................................23
7.4.5 Aggregation of Crankback Information.........................24 7.4.5 Aggregation of Crankback Information.........................23
7.5. Notification of Errors........................................25 7.5. Notification of Errors........................................24
7.5.1 ResvErr Processing...........................................25 7.5.1 ResvErr Processing...........................................24
7.5.2 Notify Message Processing....................................25 7.5.2 Notify Message Processing....................................24
7.6. Error Values..................................................26 7.6. Error Values..................................................25
7.7. Backward Compatibility........................................26 7.7. Backward Compatibility........................................25
8. Routing Protocol Interactions...................................26 8. LSP Recovery Considerations.....................................25
9. LSP Restoration Considerations..................................26 8.1. Upstream of the Fault.........................................26
9.1. Upstream of the Fault.........................................27 8.2. Downstream of the Fault.......................................26
9.2. Downstream of the Fault.......................................27 9. IANA Considerations.............................................27
10. IANA Considerations............................................28 9.1. Error Codes...................................................27
10.1. Error Codes..................................................28 9.2. IF_ID_ERROR_SPEC TLVs.........................................27
10.2. IF_ID_ERROR_SPEC TLVs........................................28 9.3. LSP_ATTRIBUTES Object.........................................27
10.3. LSP_ATTRIBUTES Object........................................28 10. Security Considerations........................................27
11. Security Considerations........................................28 11. Acknowledgments................................................28
12. Acknowledgments................................................29 12. Intellectual Property Considerations...........................28
13. Intellectual Property Considerations...........................29 13. Normative References...........................................28
14. Normative References...........................................29 14. Informational References.......................................29
15. Informational References.......................................30 15. Authors' Addresses.............................................30
16. Authors' Addresses.............................................31 16. Disclaimer of Validity.........................................30
17. Disclaimer of Validity.........................................32 17. Full Copyright Statement.......................................31
18. Full Copyright Statement.......................................32 A. Experience of Crankback in TDM-based Networks..................32
A. Experience of Crankback in TDM-based Networks..................33
Section A : Problem Statement Section A : Problem Statement
0. Changes
(This section to be removed before publication as an RFC.)
0.1 Changes from 03 to 04 Version
- Content of NODE_ID TLV changes from Router ID to TE Router ID.
- Clarification that the MPLS LSPs referenced are TE LSPs.
- More open inclusion of GMPLS alongside MPLS.
- Note that bundling draft changes obsoletes the use of component ID
TLVs. Remove unnumbered component interface id TLVs and renumber
other TLVs.
- New section explaining control plane and data plane separation.
- New section on the interaction with TE flooding mechanisms.
- Clarify the use of the history table.
- Clarify the way that the retry counting is used.
- Typos.
0.2 Changes from 01 to 02, and 02 to 03 Versions
- Update IPR and copyright
- Update references
0.3 Changes from 00 to 01 Versions
- Removal of background descriptive material pertaining to TDM
network experience from section 3 to an Appendix.
- Removal of definition of Error Spec TLVs for unnumbered bundled
links from section 7.2 to a separate document.
- More detailed guidance on which Error Spec TLVs to use when.
- Change LSP_ATTRIBUTE flags from hex values to bit numbers.
- Typographic errors fixed.
- Update references.
1. Terminology 1. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
1.1. Control Plane and Data Plane Separation 1.1. Control Plane and Data Plane Separation
Throughout this document the processes and techniques are described Throughout this document the processes and techniques are described
as though the control plane and data plane elements that comprose a as though the control plane and data plane elements that comprise a
Label Switching Router (LSR) are coresident and related in a Label Switching Router (LSR) are coresident and related in a
one-to-one manner. This is a convenience of documentaiton only. one-to-one manner. This is a convenience of documentation only.
It should be noted that GMPLS LSRs may be decomposed such that the It should be noted that GMPLS LSRs may be decomposed such that the
control plane components are not physically collocated. Further, one control plane components are not physically collocated. Further, one
presence in the control plane may control more than one LSR in the presence in the control plane may control more than one LSR in the
data plane. These points have several consequences with respect to data plane. These points have several consequences with respect to
this document: this document:
o The nodes, links and resources that are reported as in error, are o The nodes, links and resources that are reported as in error, are
data plane entities. data plane entities.
o The nodes, areas and ASs that report that they have attempted o The nodes, areas and ASs that report that they have attempted
re-routing, are control plane entities. re-routing, are control plane entities.
o Where a single control plane entity is responsible for more than o Where a single control plane entity is responsible for more than
one data plane LSR, crankback signaling may be implicit in just one data plane LSR, crankback signaling may be implicit in just
the same way as LSP establishment signaling may be. the same way as LSP establishment signaling may be.
The above points may be considered self-evident, but are stated The above points may be considered self-evident, but are stated
here for absolute clarity. here for absolute clarity.
The stylistic convenience of refering to both the control plane The stylistic convenience of referring to both the control plane
element responsible for a single LSR and the data plane component of 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 that LSR simply as "the LSR", should not be taken to mean that this
document is applicable only to a colocated one-to-one relationship. document is applicable only to a collocated one-to-one relationship.
Further, in the majority case the control plane and data plane Further, in the majority case the control plane and data plane
components are related in a 1:1 ratio and are usually collocated. components are related in a 1:1 ratio and are usually collocated.
2. Introduction and Framework 2. Introduction and Framework
2.1. Background 2.1. Background
RSVP-TE (RSVP Extensions for LSP Tunnels) [RFC3209] can be 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-TE, resources can also be reserved along a path to guarantee RSVP-TE, resources can also be reserved along a path to guarantee
or control QoS for traffic carried on the LSP. To designate an and/or control QoS for traffic carried on the LSP. To designate an
explicit path that satisfies QoS constraints, it is necessary to explicit path that satisfies QoS guarantees, it is necessary to
discern the resources available to each link or node in the network. discern the resources available to each link or node in the network.
For the collection of such resource information, routing protocols, For the collection of such resource information, routing protocols,
such as OSPF and IS-IS , can be extended to distribute additional such as OSPF and 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 initiating an LSP and signaled as Explicit Routes during at the LSR (ingress) initiating an LSP and signaled as Explicit
LSP establishment. Explicit Routes may contain 'loose hops' and Routes during LSP establishment. Explicit Routes may contain 'loose
'abstract nodes' that convey routing through any of a collection of hops' and 'abstract nodes' that convey routing through a collection
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 initiator, or a ResvErr sent to the terminator (egress LSR). to the ingress, or a ResvErr sent to the egress (terminator).
These messages may result in the LSP setup being abandoned. In These messages may result in the LSP setup being abandoned. In
Generalized MPLS [RC3473] the Notify message may additionally be Generalized MPLS [RC3473] the Notify message may additionally be
used to expedite notification of LSP failures to ingress and egress used to expedite notification of failures of existing LSPs to ingress
LSRs, or to a specific "repair point". and egress LSRs, or to a specific "repair point" - an LSR responsible
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-Connect on an end-to-end explicit path. This makes crankback Cross-Connect on an end-to-end explicit path. This makes crankback
routing all the more important in certain GMPLS networks. routing all the more important in certain GMPLS networks.
2.2. Repair and Restoration 2.2. 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 restoration schemes for link or node On the other hand, various recovery schemes for link or node
failures have been proposed in [RFC3469] and include fast failures have been proposed in [RFC3469] and include fast
restoration. These schemes rely on the existence of a backup LSP to re-routing. These schemes rely on the existence of a protecting LSP
protect the primary, but if both the primary and backup paths fail it to protect the working LSP, but if both the working and protecting
is necessary to re-establish the LSP on an end-to-end basis avoiding paths fail it is necessary to re-establish the LSP on an end-to-end
the known failures. Similarly, fast restoration by establishing a basis avoiding the known failures. Similarly, fast re-routing by
restoration path on demand after failure requires computation of a establishing a recovery path on demand after failure requires
new LSP that avoids the known failures. End-to-end restoration for computation of a new LSP that avoids the known failures. End-to-end
alternate routing requires the location of the failed link or node. recovery for alternate routing requires the location of the failed
Crankback routing schemes could be used to notify the upstream LSRs link or node. Crankback routing schemes could be used to notify the
of the location of the failure. upstream LSRs 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 restoration 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
restoration is the only way to recover LSP failures. This makes recovery may be the only way to recover from LSP failures. This is
crankback rerouting particularly useful in a GMPLS network, in because segment protection may be much harder to achieve in networks
particular in dynamic LSP re-routing cases (no backup LSP of photonic cross-connects where a particular lambda may already be
pre-establishment). 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
protection.
This requirement makes crankback re-routing particularly useful in a
GMPLS network, in particular in dynamic LSP re-routing cases (no
protecting LSP pre-establishment).
2.3. Interaction with TE Flooding Mechanisms 2.3. Interaction with TE Flooding Mechanisms
GMPLS uses IGPs (OSPF and IS-IS) to flood traffic engineering (TE) GMPLS uses IGPs (OSPF and IS-IS) to flood traffic engineering (TE)
information that is used to construct a traffic engineering database information that is used to construct a traffic engineering database
(TED) which acts as a data source for path computation. (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
skipping to change at line 318 skipping to change at line 290
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 scope of this document.
3. Discussion: Explicit Versus Implicit Re-routing Indications 3. Discussion: Explicit Versus Implicit Re-routing Indications
There have been problems in service provider networks 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. that explicitly authorizes re-routing, and contrasts it with the
inferred or implicit re-routing indication that has previously
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-routing can be done. This allows for recovery from network errors re-routing can be performed. This allows for recovery from network
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. This
background information is given in Appendix A. background information is given in Appendix A.
It is certainly the case that with topology exchange, such as OSPF, It is certainly the case that with topology information distribution
the ingress LSR could infer the re-routing condition. However, as performed with routing protocols such as OSPF, the ingress LSR
convergence of routing information is typically slower than the could infer the re-routing condition. However, convergence of
expected LSP setup times. One of the reasons for crankback is to topology information using routing protocols is typically slower than
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. at 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 alternate routing should be indicated 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 4. Required Operation
Section 2 identifies some of the circumstances under which crankback Section 2 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
skipping to change at line 375 skipping to change at line 350
the area border LSR, the AS border LSR, or to some other repair the area border LSR, the AS border LSR, or to 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 4.2.1 and 7.
4.2. Computation of an Alternate Path 4.2. Computation of an Alternate Path
In a flat network without partitioning, when the ingress LSR receives In a flat network without partitioning of the routing topology, when
the error message it computes an alternate path around the blocked the ingress LSR receives the error message it computes an alternate
link or node to satisfy QoS constraints using link state information path around the blocked link or node to satisfy QoS guarantees using
about the network. If an alternate path is found, a new LSP setup link state information about the network. If an alternate path is
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
hierarchical OSPF, the area border LSR may intercept and terminate OSPF, the area border LSR may intercept and terminate the error
the error response, and perform alternate (re-)routing within the response, and perform alternate (re-)routing within the downstream
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 as an area border LSR as
described above. It can intercept and terminate the error response, described above. It can intercept and terminate the error response,
and perform alternate routing. This may be particularly useful where and perform alternate routing. This may be particularly useful where
domains of computation are applied within the network, however if domains of computation are applied within the (partitioned) network,
all nodes in the network perform re-routing it is possible to spend where such domains are not coincident on the routing partition
excessive network and CPU resources on re-routing attempts that would boundaries. However if, all nodes in the network perform re-routing
be better made only at designated re-routing nodes. This scenario is it is possible to spend excessive network and CPU resources on
somewhat like 'MPLS fast re-route' [FASTRR], in which any node in the re-routing attempts that would be better made only at designated
MPLS domain can establish 'local repair' LSPs after failure re-routing nodes. This scenario is somewhat like 'MPLS fast re-route'
notification. [FASTRR], in which any node in the MPLS domain can establish 'local
repair' LSPs upon failure notification.
4.2.1 Information Required for Re-routing 4.2.1 Information Required for Re-routing
In order to correctly compute a route that avoids the 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.
However, this information may not be enough to help with The reason for the failure may provide an important discriminator to
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
path computation excluding the reporting LSR, but the reason
"Temporary Control Plane Congestion" might lead to a simple retry
after a suitable pause.
However, even this information may not be enough to help with
re-computation. Consider for instance an explicit route that contains re-computation. Consider for instance an explicit route that contains
a non-explicit abstract node or a loose hop. In this case, the failed a 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 is 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 information
needs to provide the context into the explicit route. needs to indicate where, within the explicit route, the problem has
occurred.
4.2.2 Signaling a New Route 4.2.2 Signaling a New Route
If the crankback information can be used to compute a new route If the crankback information can be used to compute a new route
avoiding the blocking problem, the route can be signaled as an avoiding the failed/blocking network resource, the route can be
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] [EXCLUDE] may be particularly helpful. To achieve this, [EXCLUDE]
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 4.3. Persistence of Error Information
skipping to change at line 431 skipping to change at line 415
[EXCLUDE] may be particularly helpful. To achieve this, [EXCLUDE] [EXCLUDE] may be particularly helpful. To achieve this, [EXCLUDE]
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 4.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) to perform an accurate path the state of this information) so that the resulting path
computation to 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
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 it is questionable what value this provides since a
future retry as a result of crankback rerouting should not attempt to future retry as a result of crankback re-routing should not attempt
route through A (such is the nature of crankback). If the history to route through A. If the history information is retained for a
information is retained for a longer period it SHOULD be discarded longer period it SHOULD be discarded after a local timeout has
after a local timeout has expired, and that timer MUST be shorter expired. This timer is required so that the repair point does not
than the timer used by the ingress to re-attempt a failed service apply the history table to an attempt by the ingress to re-establish
(note that re-attempting a failed service is not the same as making a a failed LSP, but to allow the history table to be available for use
re-route attempt after failure). in re-routing attempts before the ingress declares the LSP as failed.
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
ingress LSR. The correlation of the timers between the ingress and
repair point LSRs is typically by manual configuration of timers
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 It is not intended that the information in the history table be used
to supplement the TED for the computation of paths of other LSPs. to supplement the TED for the computation of paths of other LSPs.
4.4. Handling Re-route Failure 4.4. Handling Re-route Failure
Multiple blockages (for the same LSP) may occur, and successive 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 the that avoids all of the blockages. In this case, it must pass an
error indication upstream. It is most useful to the upstream nodes error indication message upstream. It is most useful to the upstream
(and in particular the ingress LSR) that may, themselves, attempt new nodes (and in particular to the ingress LSR) that may as repair
routes for the LSP setup, if the error indication in this case points for the LSP setup, if the error indication message identifies
identifies all of the downstream blockages and also the node that has all of the downstream blockages and also the repair point that was
been unable to compute an alternate path. unable to compute an alternate path.
4.5. Limiting Re-routing Attempts 4.5. Limiting Re-routing Attempts
It is important to prevent an endless repetition of LSP setup It is important to prevent endless repetition of LSP setup attempts
attempts using crankback routing information after error conditions using crankback routing information after error conditions are
are signaled, or during periods of high congestion. It may also be signaled, or during periods of high congestion. It may also be useful
useful to reduce the number of retries, since failed retries will to reduce the number of retries, since failed retries will increase
increase setup latency and degrade performance. setup latency and degrade performance by increasing the 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 allowed may be
limited in a variety of ways. This document allows an LSR to limit limited in a variety of ways. This document allows an LSR to limit
the retries per LSP, and assumes that such a limit will be applied the retries per LSP, and assumes that such a limit will be applied
either as a per node configuration for those LSRs that are capable either as a per node configuration for those LSRs that are capable
of rerouting, or as a network-wide configuration value. 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 upstream to the next node where further reports the failure in an upstream direction until it reaches the
re-routing attempts may be attempted. It is important that the next repair point where further re-routing attempts may be attempted,
crankback information provided indicates that routing back through or reaches the ingress which may act as a repair point or declare the
this node will not succeed - this situation is similar to that in LSP as faioled. It is important that the crankback information
section 4.4. provided indicates that routing back through this node will not
succeed - this situation is similar to that in section 4.4.
5. Existing Protocol Support for Crankback Re-routing 5. Existing Protocol Support for Crankback Re-routing
Crankback re-routing is appropriate for use with RSVP-TE. Crankback re-routing is appropriate for use with RSVP-TE.
1) LSP establishment may fail because of an inability to 1) LSP establishment may fail because of an inability to route,
route, perhaps because links are down. In this case a perhaps because links are down. In this case a PathErr message is
PathErr message is returned to the initiator. returned to the ingress.
2) LSP establishment may fail because resources are 2) LSP establishment may fail because resources are unavailable.
unavailable. This is particularly relevant in GMPLS where This is particularly relevant in GMPLS where explicit label
explicit label control may be in use. Again, a PathErr control may be in use. Again, a PathErr message is returned to the
message is returned to the initiator. ingress.
3) Resource reservation may fail during LSP establishment, 3) Resource reservation may fail during LSP establishment, as the
as the Resv is processed. If resources are not available on Resv is processed. If resources are not available on the required
the required link or at a specific node, a ResvErr message is link or at a specific node, a ResvErr message is returned to the
returned to the egress node indicating "Admission Control egress node indicating "Admission Control failure" [RFC2205]. The
failure" [RFC2205]. The egress is allowed to change the egress is allowed to change the FLOWSPEC and try again, but in the
FLOWSPEC and try again, but in the event that this is not event that this is not practical or not supported (particularly in
practical or not supported (particularly in the GMPLS context), the non-PSC context), the egress LSR may choose to take any one of
the egress LSR may choose to take any one of the following the following actions.
actions.
- Ignore the situation and allow recovery to happen through - Ignore the situation and allow recovery to happen through
Path refresh message and refresh timeout [RFC2205]. Path refresh message and refresh timeout [RFC2205].
- Send a PathErr message towards the initiator indicating
- Send a PathErr message towards the ingress indicating
"Admission Control failure". "Admission Control failure".
- Send a ResvTear message towards the initiator to abort
the LSP setup.
Note that in multi-area/AS networks, the ResvErr might be Note that in multi-area/AS networks, the ResvErr might be
intercepted and acted on at an area/AS border router. intercepted and acted on at an area/AS border router.
4) It is also possible to make resource reservations on the forward 4) It is also possible to make resource reservations on the forward
path as the Path message is processed. This choice is compatible path as the Path message is processed. This choice is compatible
with LSP setup in GMPLS networks [RFC3471]. In this case if with LSP setup in GMPLS networks [RFC3471], [RFC4373]. In this
resources are not available, a PathErr message is returned to case if resources are not available, a PathErr message is returned
initiator indicating "Admission Control failure". 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 5.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
skipping to change at line 571 skipping to change at line 562
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 LSP failures direct to a selected node. This message carries report LSP failures direct to a selected node. This message carries
the same error reporting facilities as described above. The Notify the same error reporting facilities as described above. The Notify
message may be used to expedite the propagation of error message may be used to expedite the propagation of error
notifications, but in a network that offers crankback routing at notifications, but in a network that offers crankback routing at
multiple nodes there would need to be some agreement between LSRs multiple nodes there would need to be some agreement between LSRs
as to whether PathErr or Notify provides the stimulus for crankback as to whether PathErr or Notify provides the stimulus for crankback
operation. Otherwise, multiple nodes might attempt to repair the LSP operation. This agreement is constrained by the re-routing behavior
at the same time, because selection (as listed in section 6.4). Otherwise, multiple nodes 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 the ingress LSR, and reaching 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 LSR. ingress LSR.
Section B : Solution Section B : Solution
6. Control of Crankback Operation 6. Control of Crankback Operation
skipping to change at line 618 skipping to change at line 610
Routers or AS Border Routers. The boundary Routers or AS Border Routers. The boundary
(ABR/ASBR) can either decide to forward the (ABR/ASBR) can either decide to forward the
error message upstream to the ingress error message upstream to the ingress
LSR or try to select another egress boundary LSR or try to select another egress boundary
LSR. Other intermediate nodes SHOULD NOT LSR. Other intermediate nodes SHOULD NOT
attempt re-routing. Nodes detecting failures attempt re-routing. Nodes detecting failures
MUST report an error and SHOULD supply MUST report an error and SHOULD supply
crankback information. crankback information.
Segment-based Re-routing Segment-based Re-routing
Any node MAY attempt rerouting after it Any node MAY attempt re-routing after it
receives an error report and before it passes receives an error report and before it passes
the error report further upstream. Nodes 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 full crankback information.
6.2. Action on Detecting a Failure 6.2. Action on Detecting a Failure
A node that detects the failure to setup an LSP or the failure of an A node that detects the failure to setup an LSP or the failure of an
established LSP SHOULD act according to the Re-routing Flag passed on established LSP SHOULD act according to the Re-routing Flag passed on
the LSP setup request. the LSP setup request.
If Segment-based Re-routing is allowed, or if Boundary Re-routing is If Segment-based Re-routing is allowed, or if Boundary Re-routing is
allowed and the detecting node is an ABR or ASBR, the detecting node allowed and the detecting node is an ABR or ASBR, the detecting node
MAY immediately attempt to re-route. MAY immediately attempt to re-route.
skipping to change at line 660 skipping to change at line 651
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/TBD) is used to identify that a node has abandoned crankback
re-routing because it has reached a threshold for retry attempts. re-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 6.4. Protocol Control of Re-routing Behavior
The Session Attributes Object in RSVP-TE is used on Path messages to The LSP_ATTRIBUTES object defined in [LSP-ATTRIB] is used on Path
indicate the capabilities and attributes of the session. This object messages to convey the Re-Routing Flag described in section 5.1.
contains an 8-bit flag field which is used to signal individual Three bits are defined for inclusion in the LSP Attributes TLV as
Boolean capabilities or attributes. The Re-Routing Flag described in follows. The bit numbers below are suggested and actual values are
section 5.1 would fit naturally into this field, but there is a TBD by IETF consensus.
scarcity of bits, so use is made of the new LSP_ATTRIBUTES object
defined in [LSP-ATTRIB]. Three bits are defined for inclusion in the
LSP Attributes TLV as follows. The bit numbers below are suggested
and actual values are TBD by IETF consensus.
Bit Name and Usage Bit Name and Usage
Number Number
1 End-to-end re-routing desired. 1 End-to-end re-routing desired.
This flag indicates the end-to-end re-routing behavior This flag indicates the end-to-end re-routing behavior for an
for an LSP under establishment. This MAY also be used LSP under establishment. This MAY also be used for specifying
for specifying the behavior of end-to-end LSP restoration the behavior of end-to-end LSP recovery for established LSPs.
for established LSPs.
2 Boundary re-routing desired. 2 Boundary re-routing desired.
This flag indicates the boundary re-routing This flag indicates the boundary re-routing behavior for an
behavior for an LSP under establishment. LSP under establishment. This MAY also be used for specifying
This MAY also be used for specifying the the segment-based LSP recovery through nested crankback for
segment-based (hierarchical) LSP restoration established LSPs. The boundary ABR/ASBR can either decide to
for established LSPs. The boundary ABR/ASBR forward the PathErr message upstream to an upstream boundary
can either decide to forward the PathErr ABR/ASBR or to the ingress LSR. Alternatively, it can try to
message upstream to the Head-end LSR or try select another egress boundary LSR.
to select another egress boundary LSR.
3 Segment-based re-routing desired. 3 Segment-based re-routing desired.
This flag indicates the segment-based This flag indicates the segment-based re-routing behavior for
re-routing behavior for an LSP under an LSP under establishment. This MAY also be used to specify
establishment. This MAY also be used the segment-based LSP recovery for established LSPs.
for specifying the segment-based LSP
restoration for established LSPs.
7. Reporting Crankback Information 7. Reporting Crankback Information
7.1. Required Information 7.1. Required Information
As described above, full crankback information SHOULD 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
address that was distributed by the routing protocols (OSPF and ISIS)
in their TE link state advertisements. However, some additional
information such as component link identifiers is additional to this.
7.2. Protocol Extensions 7.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 scope for carrying TLVs that identify
the link associated with the error. 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 PHOP listed below. They are used to identify links in the IF_ID RSVP_HOP
Object and in the IF_ID ERROR_SPEC object to identify the failed Object, and in the IF_ID ERROR_SPEC object to identify the failed
resource which is usually the downstream resource from the reporting resource which is usually 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)
skipping to change at line 805 skipping to change at line 793
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. In the case of The 4-octet area identifier for the node. This identifies the
ABRs, 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 | ISIS Area Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ISIS Area Identifier (continued) ~ ~ ISIS Area Identifier (continued) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at line 875 skipping to change at line 863
| | | |
~ 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. current LSP setup attempt. Note that an interface identifier
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 type 3 that indicate A sequence of TLVs as defined here of the same format as type
incoming interfaces at downstream nodes that have already 1, 2 or 3 TLVs that indicate incoming interfaces at downstream
participated in crankback attempts and have been declared nodes that have already participated in crankback attempts and
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 7.3 Guidance for Use of IF_ID ERROR_SPEC TLVs
7.3.1 General Principles 7.3.1 General Principles
If crankback is not being used but an IF-ID ERROR_SPEC object is If crankback is not being used, inclusion of an IF-ID ERROR_SPEC
included in a PathErr, ResvErr or Notify message, the sender SHOULD object in PathErr, ResvErr and Notify messages follows the processing
include one of the TLVs of type 1 through 3 as described in rules defined in [RFC3473] and [BUNDLE]. A sender MAY include
[RFC3473]. TLVs of type 4 or 5 SHOULD NOT be used as described in additional TLVs of types 6 through 27 to report crankback information
[BUNDLE] and component links should be identified using the for informational/monitoring purposes.
principles described in that document.
A sender MAY include additional TLVs from the range 6 through 27
to report crankback information, although this information will at
most only be used for logging.
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], [BUNDLE], and previous paragraph. Additional TLVs SHOULD [RFC3473], [BUNDLE], and the previous paragraph. Additional TLVs
also be included to report further information. The following section SHOULD also be included to report further information. The following
gives advice on which TLVs should be used under different section gives advice on which TLVs should be used under different
circumstances, and which TLVs must be supported by LSRs. circumstances, and which TLVs must be supported by LSRs.
Note that all such TLVs are optional and MAY be omitted. Inclusion of Note that all such additional TLVs are optional and MAY be omitted.
the optional TLVs SHOULD be performed where doing so helps to Inclusion of the optional TLVs SHOULD be performed where doing so
facilitate error reporting and crankback. The TLVs fall into three helps to facilitate error reporting and crankback. The TLVs fall into
categories: those that are essential to report the error, those that three categories: those that are essential to report the error, those
provide additional information that is or may be fundamental to the that provide additional information that is or may be fundamental to
utility of crankback, and those that provide additional information the utility of crankback, and those that provide additional
that may be useful for crankback in some circumstances. 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 [BUNDLE]. There is, however, no [RFC3473] and obsoleted by [BUNDLE]. There is, however, no
requirement for an LSR to actively process any but the error report requirement for an LSR to actively process any but the TLVs defined
TLVs. An LSR that proposes to perform crankback re-routing SHOULD in [RFC3473]. An LSR that proposes to perform crankback re-routing
support receipt and processing of all of the fundamental crankback SHOULD support receipt and processing of all of the fundamental
TLVs, and is RECOMMENDED to support the receipt and processing of crankback TLVs, and is RECOMMENDED to support the receipt and
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 7.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 obsoleted TLVs 4 and 5 may be considered in this category, but the obsoleted TLVs 4 and 5 may be considered in this category, but
SHOULD NOT be used.) SHOULD 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 device that does not support IPv6 will not need the ability to create
create a TLV of type 2. Note, however, that such a device MUST still a TLV of type 2. Note, however, that such a device MUST still be
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 7.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. available. (Note that some of these TLVs MUST be included as
described in the previous two sections.)
The use of TLVs of type 8, 9, 10 and 11 MAY, however, be omitted The TLVs of type 8, 9, 10 and 11 MAY, however, be omitted according
according to local policy and relevance of the information. to local policy and relevance of the information.
7.3.4 Additional Crankback TLVs 7.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-specific abstract node) and deduce that its upstream neighbor may non-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 node further 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
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.
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
skipping to change at line 1010 skipping to change at line 999
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 by ABRs relaying the error. Note that the Reporting Node ID added by ABRs relaying the error. Note that the Reporting Node ID
(TLV 21) need not be included if the IP address of the reporting (TLV 21) need not be included if the IP address of the reporting
node as indicated in the ERROR_SPEC itself, is sufficient to fully node as indicated in the ERROR_SPEC itself, is sufficient to fully
identify the node. identify 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 some node forwarding
the error) MAY supply suggestions about the ERO that could have been the error) MAY make suggestions about how the error could have been
used to avoid the error. As the error propagates back upstream and as avoided, for example by supplying a partial ERO that would cause the
crankback routing is attempted and fails, it is beneficial to collect LSP to be successfully set up if it were used. As the error
lists of failed nodes and links so that they will not be included in propagates back upstream and as crankback routing is attempted and
further computations performed at upstream nodes. Theses lists may fails, it is beneficial to collect lists of failed nodes and links so
also be factored into route exclusions [EXCLUDE]. that they will not be included in further computations performed at
upstream nodes. These lists may also be factored into route
exclusions [EXCLUDE].
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.
It is left as an implementation detail precisely when to include each The decision of precisely which TLV types a reporting node includes
of the TLVs according to the capabilities of the system reporting the is dependent on the specific capabilities of the node, and is
error. outside the scope of this document.
7.3.5 Grouping TLVs by Failure Location 7.3.5 Grouping TLVs by Failure Location
Further guidance as to the inclusion of crankback TLVs can be given Further guidance as to the inclusion of crankback TLVs can be given
by grouping the TLVs according to the location of the failure and 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.
Although discussion of aggregation of crankback information is out of
the scope of this document, it should be noted that this topic is
closely aligned to the information presented here.
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
skipping to change at line 1070 skipping to change at line 1057
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
the scope of this document, it should be noted that this topic is
closely aligned to the information presented here. Aggregation is
discussed further in section 7.4.5.
7.3.6 Alternate Path Identification 7.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 7.4. Action on Receiving Crankback Information
7.4.1 Re-route Attempts 7.4.1 Re-route Attempts
As described in section 3, a node receiving crankback information in As described in section 3, 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
SESSION_ATTRIBUTE object during LSP setup request. LSP_ATTRIBUTES object during 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. This allows the combination of crankback information from LSP. On the next crankback re-routing path computation attempt, the
multiple failures when computing an alternate path. LSR should exclude all the failed nodes and links and resources
reported 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 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 7.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
skipping to change at line 1127 skipping to change at line 1120
of a TE Router ID and the Link ID. If the topology and resource of 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 for IPv4, IS-IS for IPv4, OSPF for IPv6, and identifiers for OSPFv2, OSPFv3, and IS-IS for IPv4 and IPv6. These
IS-IS for IPv6. These identifiers may only be used if segment-based identifiers may only be used if segment-based re-routing is
re-routing is supported, as indicated by the Routing Behavior flag on supported, as indicated by the Routing Behavior flag on the LSP setup
the LSP setup request. request.
7.4.3 Locating Errors within Loose or Abstract Nodes 7.4.3 Locating Errors within Loose or Abstract Nodes
The explicit route on the original LSP setup request may 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
skipping to change at line 1165 skipping to change at line 1158
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 7.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 some node upstream may choose to attempt crankback re-routing. If
that node's attempts at re-routing fail the node will accumulate a that node's attempts at re-routing fail the node will accumulate a
set of failure information. When the node gives up it must propagate set of failure information. When the node gives up it MUST propagate
the failure message further upstream and include crankback the failure message further upstream and include crankback
information when it does so. information when it does so.
There is not scope in the protocol extensions described in this Including a full list of all failures that have occurred due to
document to supply a full list of all of the failures that have multiple crankback failures by multiple repair point LSRs downstream
occurred. Such a list would be indefinitely long and would include could lead to too much information signaled using the protocol
more detail than is required. However, TLVs 26 and 27 allow lists of extensions described in this document. A compression mechanism for
unusable links and nodes to be accumulated as the failure is passed such information is available using TLVs 26 and 27. These TLVs allow
back upstream. for a more concise accumulation of failure information as crankback
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, or flagging an ABR as unusable when by flagging the node as unusable, flagging an ABR as unusable when
there is no downstream path available, and so on. The precise details there is no downstream path available, or including a TLV of type 9
of how aggregation of crankback information is performed are beyond which results in the exclusion of the entire area, and so on. The
the scope of this document. precise details of how aggregation of crankback information is
performed are beyond the scope of this document.
7.5. Notification of Errors 7.5. Notification of Errors
7.5.1 ResvErr Processing 7.5.1 ResvErr Processing
As described above, the resource allocation failure for 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 receives
the ResvErr message, per [RFC2205] it still has the option of the ResvErr message, per [RFC2205] it still has the option of
skipping to change at line 1245 skipping to change at line 1240
the predetermined threshold at an individual LSR. the predetermined threshold at an individual LSR.
7.7. Backward Compatibility 7.7. Backward Compatibility
It is recognized that not all nodes in an RSVP-TE network 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).
8. Routing Protocol Interactions This document introduces no backward compatibility issues provided
that existing implementations conform to the TLV processing rules
If the routing-protocol-specific link or node identifiers are used in defined in [RFC3471] and [RFC3473].
the Link and Node IF_ID ERROR_SPEC TLVs defined above, the signaling
has to interact with the OSPF/IS-IS routing protocol.
For example, when an intermediate LSR issues a PathErr message, the
signaling module of the intermediate LSR should interact with the
routing logic to determine the routing-protocol-specific link or node
ID where the blockage or fault occurred and carry this information
onto the Link TLV and Node TLV inside the IF_ID ERROR_SPEC object.
The ingress LSR, upon receiving the error message, should interact
with the routing logic to compute an alternate path by pruning the
specified link ID or node ID in the routing database.
Procedures concerning these protocol interactions are out of scope of
this document.
9. LSP Restoration Considerations 8. LSP Recovery Considerations
LSP restoration 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 restoration, 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 restoration. The goal of this example is the above extensions to LSP recovery. The goal of this example is
to give a general overview of how this might work, and not to give a to give a general overview of how this might work, and not to give a
detailed procedure for LSP restoration. detailed procedure for LSP recovery.
Although there are several techniques for LSP restoration, this Although there are several techniques for LSP recovery, this
section explains the case of on-demand LSP restoration, which section explains the case of on-demand LSP recovery, which
attempts to set up a new LSP on demand after detecting an LSP attempts to set up a new LSP on demand after detecting an LSP
failure. failure.
9.1. Upstream of the Fault 8.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 PathErr message is sent upstream. In GMPLS, the ERROR_SPEC object a 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 the
message then releases the corresponding LSP. (Note that if the state message then releases the corresponding LSP. (Note that if the state
removal indication is not present on the PathErr message, the ingress removal indication is not present on the PathErr message, the ingress
node must issue a PathTear message to cause the resources to be node MUST issue a PathTear message to cause the resources to be
released.) If the failed LSP has to be restored at an upstream LSR, released.) If the failed LSP has to be recovered at an upstream LSR,
the IF_ID ERROR SPEC that includes the location information of the the IF_ID ERROR SPEC that includes the location information of the
failed link or node is included in the PathErr message. The ingress, failed link or node is included in the PathErr message. The ingress,
intermediate area border LSR, or indeed any repair point permitted by intermediate area border LSR, or indeed any repair point permitted by
the Re-routing Flags, that receives the PathErr message can terminate the Re-routing Flags, that receives the PathErr message can terminate
the message and then perform alternate routing. the message and then perform alternate routing.
In a flat network, when the ingress LSR receives the 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 constraints. 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 8.2, the LSP restoration behavior is used. As explained in Section 6.4, the LSP recovery behavior is
indicated in the Flags field of the SESSION_ATTRIBUTE object of the indicated in the Flags field of the LSP_ATTRIBUTES object of the
Path message. If the Flags indicate "End-to-end re-routing", the Path message. If the Flags indicate "End-to-end re-routing", the
PathErr message is returned all the way back to the ingress LSR, PathErr message is returned all the way back to the ingress LSR,
which may then issue a new Path message along another path, which is which may then issue a new Path message along another path, which is
the same procedure as in the flat network case above. the same 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.
9.2. Downstream of the Fault 8.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 PathErr or Notify message containing an IF_ID ERROR SPEC that a 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 the
downstream LSP state in place and facilitates make-before-break 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 the
detecting node does not send a PathTear immediately then unused sate detecting node does not send a PathTear immediately then unused sate
will timeout according to the normal rules of [RFC2205]. 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 not
skipping to change at line 1340 skipping to change at line 1322
detecting node does not send a PathTear immediately then unused sate detecting node does not send a PathTear immediately then unused sate
will timeout according to the normal rules of [RFC2205]. 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 not
propagated further downstream for an LSP that has SE reservation propagated further downstream for an LSP that has SE reservation
style. Note, however, that this is a divergence from the protocol and style. Note, however, that this is a divergence from the protocol and
might severely impact normal tear-down of LSPs. might severely impact normal tear-down of LSPs.
10. IANA Considerations 9. IANA Considerations
10.1 Error Codes 9.1 Error Codes
A new error value is defined for the RSVP-TE "Routing Problem" error A new error value is defined for the RSVP-TE "Routing Problem" error
code that is defined in [RFC3209]. code that is defined in [RFC3209].
TBD Re-routing limit exceeded. TBD Re-routing limit exceeded.
10.2 IF_ID_ERROR_SPEC TLVs 9.2 IF_ID_ERROR_SPEC TLVs
Note that the IF_ID_ERROR_SPEC TLV type values defined in [RFC3471] Note that the IF_ID_ERROR_SPEC TLV type values defined in [RFC3471]
are not currently tracked by IANA. IANA is requested to form a are not currently tracked by IANA. IANA is requested to form a
registry of these values. The new values proposed by this document registry of these values. The new values proposed by this document
are found in section 7.2. are found in section 7.2.
10.3 LSP_ATTRIBUTES Object 9.3 LSP_ATTRIBUTES Object
Three bits are defined for inclusion in the LSP Attributes TLV of Three bits are defined for inclusion in the LSP Attributes TLV of
the LSP_ATTRIBUTES object in section 6.4. Suggested values are the LSP_ATTRIBUTES object in section 6.4. Suggested values are
supplied. IANA is requested to assign those bits. supplied. IANA is requested to assign those bits.
11. Security Considerations 10. Security Considerations
It should be noted that while the extensions in this document It should be noted that while the extensions in this document
introduce no new security holes in the protocols, should a malicious introduce no new security holes in the protocols, should a malicious
user gain protocol access to the network, the crankback information user gain protocol access to the network, the crankback information
might be used to prevent establishment of valid LSPs. might be used to prevent establishment of valid LSPs.
The implementation of re-routing attempt thresholds are particularly The implementation of re-routing attempt thresholds are particularly
important in this context. important in this context.
The crankback routing extensions and procedures for LSP restoration The crankback routing extensions and procedures for LSP recovery
as applied to RSVP-TE introduce no further new security as applied to RSVP-TE introduce no further new security
considerations. Refer to [RFC2205], [RFC3209] and [RFC3473] for a considerations. Refer to [RFC2205], [RFC3209] and [RFC3473] for a
description of applicable security considerations. description of applicable security considerations.
12. Acknowledgments 11. 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 liaison process. ITU-T liaison process.
Simon Marshall-Unitt made contributions to this draft. Simon Marshall-Unitt made contributions to this draft.
13. Intellectual Property Considerations 12. Intellectual Property Considerations
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
skipping to change at line 1414 skipping to change at line 1396
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf- this standard. Please address the information to the IETF at ietf-
ipr@ietf.org. ipr@ietf.org.
14. Normative References 13. 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] R. Braden, et al., "Resource ReSerVation Protocol (RSVP)
Version 1 Functional Specification", RFC2205, September Version 1 Functional Specification", RFC2205, September
1997. 1997.
[RFC3209] D. Awduche, et al., "RSVP-TE: Extensions to RSVP for LSP [RFC3209] D. Awduche, et al., "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC3209, December 2001. Tunnels", RFC3209, December 2001.
skipping to change at line 1436 skipping to change at line 1418
[RFC3471] P. Ashwood-Smith and L. Berger, et al., "Generalized [RFC3471] P. Ashwood-Smith and L. Berger, et al., "Generalized
MPLS - Signaling Functional Description", RFC 3471, MPLS - Signaling Functional Description", RFC 3471,
January 2003. January 2003.
[RFC3473] L. Berger, et al., "Generalized MPLS Signaling - RSVP-TE [RFC3473] L. Berger, et al., "Generalized MPLS Signaling - RSVP-TE
Extensions", RFC 3473, January 2003. Extensions", RFC 3473, January 2003.
[LSP-ATTRIB] A. Farrel, D. Papadimitriou, JP. Vasseur, "Encoding of [LSP-ATTRIB] A. Farrel, D. Papadimitriou, JP. Vasseur, "Encoding of
Attributes for Multiprotocol Label Switching (MPLS) Attributes for Multiprotocol Label Switching (MPLS)
Label Switched Path (LSP) Establishment Using RSVP-TE", Label Switched Path (LSP) Establishment Using RSVP-TE",
draft-ietf-mpls-rsvpte-attributes-04.txt, July 2004, draft-ietf-mpls-rsvpte-attributes, work in progress.
work in progress.
[ASON-REQ] D. Papadimitriou, J. Drake, J. Ash, A. Farrel, L. Ong,
"Requirements for Generalized MPLS (GMPLS) Signaling
Usage and Extensions for Automatically Switched Optical
Network (ASON)", daft-ietf-ccamp-gmpls-ason-reqts-07.txt
October 2004, work in progress.
[BUNDLE] Kompella, K., Rekhter, Y., and Berger, L., "Link
Bundling in MPLS Traffic Engineering",
draft-ietf-mpls-bundle, work in progress.
15. Informational References 14. Informational References
[ASH1] G. Ash, ITU-T Recommendations E.360.1 --> E.360.7, "QoS [ASH1] G. Ash, ITU-T Recommendations E.360.1 --> E.360.7, "QoS
Routing & Related Traffic Engineering Methods for IP-, Routing & Related Traffic Engineering Methods for IP-,
ATM-, & TDM-Based Multiservice Networks", May, 2002. ATM-, & TDM-Based Multiservice Networks", May, 2002.
[BUNDLE] Kompella, K., Rekhter, Y., and Berger, L., "Link
Bundling in MPLS Traffic Engineering",
draft-ietf-mpls-bundle, work in progress.
[FASTRR] Ping Pan, et al., "Fast Reroute Extensions to RSVP-TE [FASTRR] Ping Pan, et al., "Fast Reroute Extensions to RSVP-TE
for LSP Tunnels", for LSP Tunnels", draft-ietf-mpls-rsvp-lsp-fastreroute,
draft-ietf-mpls-rsvp-lsp-fastreroute-06.txt, May 2004 work in progress.
(work in progress).
[G8080] ITU-T Recommendation G.808/Y.1304, Architecture for the [G8080] ITU-T Recommendation G.808/Y.1304, Architecture for the
Automatically Switched Optical Network (ASON), November Automatically Switched Optical Network (ASON), November
2001. For information on the availability of this 2001. For information on the availability of this
document, please see http://www.itu.int. document, please see http://www.itu.int.
[EXCLUDE] C-Y. Lee, A. Farrel and S De Cnodder, "Exclude Routes - [EXCLUDE] C-Y. Lee, A. Farrel and S De Cnodder, "Exclude Routes -
Extension to RSVP-TE", Extension to RSVP-TE",
draft-ietf-ccamp-rsvp-te-exclude-route-02.txt, July 2004 draft-ietf-ccamp-rsvp-te-exclude-route, work in
(work in progress). 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>, May 1996. <af-pnni-0055.000>, May 1996.
[RFC2702] D. Awduche, et al., "Requirements for Traffic [RFC2702] D. Awduche, et al., "Requirements for Traffic
Engineering Over MPLS", RFC2702, September 1999. Engineering Over MPLS", RFC2702, September 1999.
[RFC3469] V. Sharma, et al., "Framework for MPLS-based Recovery", [RFC3469] V. Sharma, et al., "Framework for MPLS-based Recovery",
RFC 3469, February 2003. RFC 3469, February 2003.
16. Authors' Addresses 15. Authors' Addresses
Adrian Farrel (editor) Adrian Farrel (editor)
Old Dog Consulting Old Dog Consulting
Phone: +44 (0) 1978 860944 Phone: +44 (0) 1978 860944
EMail: adrian@olddog.co.uk EMail: adrian@olddog.co.uk
Arun Satyanarayana Arun Satyanarayana
EMail: kuvempu@yahoo.com Cisco Systems, Inc.
170 West Tasman Dr.
San Jose, CA 95134
Phone: +1 408 853-3206
Email: asatyana@cisco.com
Atsushi Iwata Atsushi Iwata
NEC Corporation NEC Corporation
Networking Research Laboratories System Platforms Research Laboratories
1-1, Miyazaki, 4-Chome, Miyamae-ku, 1753 Shimonumabe Nakahara-ku,
Kawasaki, Kanagawa, 216-8555, JAPAN Kawasaki, Kanagawa, 211-8666, JAPAN
Phone: +81-(44)-856-2123 Phone: +81-(44)-396-2744
Fax: +81-(44)-856-2230 Fax: +81-(44)-431-7612
EMail: a-iwata@ah.jp.nec.com E-Mail: a-iwata@ah.jp.nec.com
Norihito Fujita Norihito Fujita
NEC Corporation NEC Corporation
Networking Research Laboratories System Platforms Research Laboratories
1-1, Miyazaki, 4-Chome, Miyamae-ku, 1753 Shimonumabe Nakahara-ku,
Kawasaki, Kanagawa, 216-8555, JAPAN Kawasaki, Kanagawa, 211-8666, JAPAN
Phone: +81-(44)-856-2123 Phone: +81-(44)-396-2091
Fax: +81-(44)-856-2230 Fax: +81-(44)-431-7644
EMail: n-fujita@bk.jp.nec.com E-Mail: n-fujita@bk.jp.nec.com
Gerald R. Ash Gerald R. Ash
AT&T AT&T
Room MT D5-2A01 Room MT D5-2A01
200 Laurel Avenue 200 Laurel Avenue
Middletown, NJ 07748, USA Middletown, NJ 07748, USA
Phone: (+1) 732-420-4578 Phone: (+1) 732-420-4578
Fax: (+1) 732-368-8659 Fax: (+1) 732-368-8659
EMail: gash@att.com EMail: gash@att.com
17. Disclaimer of Validity 16. Disclaimer of Validity
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
18. Full Copyright Statement 17. Full Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights. except as set forth therein, the authors retain all their rights.
Appendix A. Experience of Crankback in TDM-based Networks Appendix A. Experience of Crankback in TDM-based Networks
Experience of using release messages in TDM-based networks for Experience of using release messages in TDM-based networks for
analogous repair and re-routing purposes provides some guidance. analogous repair and re-routing purposes provides some guidance.
 End of changes. 

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