draft-ietf-ccamp-crankback-00.txt   draft-ietf-ccamp-crankback-01.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: June 2004 Arun Satyanarayana Expires: July 2004 Arun Satyanarayana
Movaz Networks, Inc. Movaz Networks, Inc.
Atsushi Iwata Atsushi Iwata
Norihito Fujita Norihito Fujita
NEC Corporation NEC Corporation
Gerald R. Ash Gerald R. Ash
AT&T AT&T
Simon Marshall-Unitt Simon Marshall-Unitt
Data Connection Ltd. Data Connection Ltd.
December 2003 January 2004
Crankback Signaling Extensions for MPLS Signaling Crankback Signaling Extensions for MPLS Signaling
<draft-ietf-ccamp-crankback-00.txt> <draft-ietf-ccamp-crankback-01.txt>
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full This document is an Internet-Draft and is in full
conformance with all provisions of Section 10 of RFC2026. conformance with all provisions of Section 10 of RFC2026.
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.
skipping to change at line 66 skipping to change at line 66
RSVP for LSP Tunnels", RFC3209, so that the LSP setup request can be RSVP for LSP Tunnels", RFC3209, so that the LSP setup request can be
retried on an alternate path that detours around blocked links or retried on an alternate path that detours around blocked links or
nodes. This offers significant improvements in the successful setup nodes. This offers significant improvements in the successful setup
and recovery ratios for LSPs, especially in situations where a large and recovery ratios for LSPs, especially in situations where a large
number of setup requests are triggered at the same time. number of setup requests are triggered at the same time.
Table of Contents Table of Contents
Section A : Problem Statement Section A : Problem Statement
1. Summary for Sub-IP Area..........................................3 1. Terminology......................................................3
1.1. Summary........................................................3 2. Introduction and Framework.......................................3
1.2. Related documents..............................................3 2.1. Background.....................................................3
1.3. Where does it fit in the Picture of the Sub-IP Work............3
1.4. Why is it Targeted at this WG..................................3
1.5. Justification..................................................3
2. Introduction and Framework.......................................4
2.1. Background.....................................................4
2.2. Repair and Restoration.........................................4 2.2. Repair and Restoration.........................................4
3. Discussion: Explicit Versus Implicit Re-routing Indications......5 3. Discussion: Explicit Versus Implicit Re-routing Indications......5
4. Required Operation...............................................7 4. Required Operation...............................................6
4.1. Resource Failure or Unavailability.............................8 4.1. Resource Failure or Unavailability.............................6
4.2. Computation of an Alternate Path...............................8 4.2. Computation of an Alternate Path...............................6
4.2.1 Information Required for Re-routing...........................8 4.2.1 Information Required for Re-routing...........................6
4.2.2 Signaling a New Route.........................................9 4.2.2 Signaling a New Route.........................................7
4.3. Persistence of Error Information...............................9 4.3. Persistence of Error Information...............................7
4.4. Handling Re-route Failure......................................9 4.4. Handling Re-route Failure......................................7
4.5. Limiting Re-routing Attempts..................................10 4.5. Limiting Re-routing Attempts...................................8
5. Existing Protocol Support for Crankback Re-routing..............10 5. Existing Protocol Support for Crankback Re-routing...............8
5.1. RSVP-TE [RFC 3209]............................................11 5.1. RSVP-TE [RFC 3209].............................................9
5.2. GMPLS-RSVP-TE [RFC 3473]......................................11 5.2. GMPLS-RSVP-TE [RFC 3473].......................................9
Section B : Solution Section B : Solution
6. Control of Crankback Operation..................................12 6. Control of Crankback Operation..................................10
6.1. Requesting Crankback and Controlling In-Network Re-routing....12 6.1. Requesting Crankback and Controlling In-Network Re-routing....10
6.2. Action on Detecting a Failure.................................12 6.2. Action on Detecting a Failure.................................10
6.3. Limiting Re-routing Attempts..................................13 6.3. Limiting Re-routing Attempts..................................11
6.3.1 New Status Codes for Re-routing..............................13 6.3.1 New Status Codes for Re-routing..............................11
6.4. Protocol Control of Re-routing Behavior.......................13 6.4. Protocol Control of Re-routing Behavior.......................11
7. Reporting Crankback Information.................................14 7. Reporting Crankback Information.................................12
7.1. Required Information..........................................14 7.1. Required Information..........................................12
7.2. Protocol Extensions...........................................14 7.2. Protocol Extensions...........................................12
7.2.1 Guidance for Use of IF_ID Error Spec TLVs....................18 7.3 Guidance for Use of IF_ID Error Spec TLVs......................16
7.2.2 Alternate Path identification................................20 7.3.1 General Principles...........................................16
7.3. Action on Receiving Crankback Information.....................20 7.3.2 Error Report TLVs............................................16
7.3.1 Re-route Attempts............................................20 7.3.3 Fundamental Crankback TLVs...................................17
7.3.2 Location Identifiers of Blocked Links or Nodes...............21 7.3.4 Additional Crankback TLVs....................................17
7.3.3 Locating Errors within Loose or Abstract Nodes...............21 7.3.5 Grouping TLVs by Failure Location............................18
7.3.4 When Re-routing Fails........................................21 7.3.6 Alternate Path identification................................19
7.3.5 Aggregation of Crankback Information.........................22 7.4. Action on Receiving Crankback Information.....................19
7.4. Notification of Errors........................................22 7.4.1 Re-route Attempts............................................19
7.4.1 ResvErr Processing...........................................22 7.4.2 Location Identifiers of Blocked Links or Nodes...............20
7.4.2 Notify Message Processing....................................23 7.4.3 Locating Errors within Loose or Abstract Nodes...............20
7.5. Error Values..................................................23 7.4.4 When Re-routing Fails........................................20
7.6. Backward Compatibility........................................23 7.4.5 Aggregation of Crankback Information.........................21
8. Routing Protocol Interactions...................................23 7.5. Notification of Errors........................................21
9. LSP Restoration Considerations..................................24 7.5.1 ResvErr Processing...........................................21
9.1. Upstream of the Fault.........................................24 7.5.2 Notify Message Processing....................................22
9.2. Downstream of the Fault.......................................25 7.6. Error Values..................................................22
10. IANA Considerations............................................25 7.7. Backward Compatibility........................................22
10.1. Error Codes..................................................25 8. Routing Protocol Interactions...................................22
10.2. IF_ID_ERROR_SPEC TLVs........................................25 9. LSP Restoration Considerations..................................23
10.3. LSP_ATTRIBUTES Object........................................25 9.1. Upstream of the Fault.........................................23
11. Security Considerations........................................26 9.2. Downstream of the Fault.......................................24
12. Acknowledgments................................................26 10. IANA Considerations............................................24
13. Intellectual Property Considerations...........................26 10.1. Error Codes..................................................24
14. Normative References...........................................26 10.2. IF_ID_ERROR_SPEC TLVs........................................24
15. Informational References.......................................27 10.3. LSP_ATTRIBUTES Object........................................24
11. Security Considerations........................................25
12. Acknowledgments................................................25
13. Intellectual Property Considerations...........................25
14. Normative References...........................................25
15. Informational References.......................................26
16. Authors' Addresses.............................................27 16. Authors' Addresses.............................................27
17. Full Copyright Statement.......................................28 A. Experience of Crankback in TDM-based Networks .................28
Full Copyright Statement.......................................29
Section A : Problem Statement Section A : Problem Statement
1. Summary for Sub-IP Area 0. Changes
1.1. Summary
This document describes requirements, procedures and
protocol extensions for Crankback Routing in MPLS and
GMPLS networks. These extensions address some of the
requirements laid out by the ITU-T for the Automatically
Switched Optical Network (ASON). This is recognized in
[ASON-REQ].
1.2. Related documents
See the References Sections.
1.3. Where does it fit in the Picture of the Sub-IP Work
This work is applicable to MPLS and GMPLS signaling protocols.
1.4. Why is it Targeted at this WG
MPLS is a product of the MPLS WG, GMPLS is worked on by
the CCAMP WG. This document provides common extensions
for use in MPLS and GMPLS and so is appropriate for
consideration by the CCAMP WG.
The CCAMP charter now contains the work item: (This section to be removed before publication as an RFC.
- Define signaling and routing mechanisms to make possible the 0.1 Changes from 00 to 01 Versions
creation of paths that span multiple IGP areas, multiple ASes,
and multiple providers, including techniques for crankback.
1.5. Justification - 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.
Crankback Signaling is a requirement in large and multi- 1. Terminology
area networks, in networks with rapidly changing
topologies or resource usage, or in networks where setup
latency may be high.
The requirement for Crankback Routing in the Automatically The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
Switched Optical Network (ASON) has been identified by the "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
ITU-T [G8080] and recognized by the IETF in [ASON-REQ]. document are to be interpreted as described in [RFC2119].
2. Introduction and Framework 2. Introduction and Framework
2.1. Background 2.1. Background
RSVP-TE (RSVP Extensions for LSP Tunnel) [RFC3209] can be RSVP-TE (RSVP Extensions for LSP Tunnels) [RFC3209] can be
used for establishing explicitly routed LSPs in an MPLS used for establishing explicitly routed LSPs in an MPLS
network. Using RSVP-TE, resources can also be reserved network. Using RSVP-TE, resources can also be reserved
along a path to guarantee or control QoS for traffic along a path to guarantee or control QoS for traffic
carried on the LSP. To designate an explicit path that carried on the LSP. To designate an explicit path that
satisfies QoS constraints, it is necessary to discern the satisfies QoS constraints, it is necessary to discern the
resources available to each link or node in the network. resources available to each link or node in the network.
For the collection of such resource information, routing For the collection of such resource information, routing
protocols, such as OSPF and IS-IS , can be extended to protocols, such as OSPF and IS-IS , can be extended to
distribute additional state information [RFC2702]. distribute additional state information [RFC2702].
Explicit paths can be computed based on the distributed Explicit paths can be computed based on the distributed
information at the LSR initiating a LSP and signaled as information at the LSR initiating an LSP and signaled as
Explicit Routes during LSP establishment. Explicit Routes Explicit Routes during LSP establishment. Explicit Routes
may contain 'loose hops' and 'abstract nodes' that convey may contain 'loose hops' and 'abstract nodes' that convey
routing through any of a collection of nodes. This routing through any of a collection of nodes. This
mechanism may be used to devolve parts of the path mechanism may be used to devolve parts of the path
computation to intermediate nodes such as area border LSRs. computation to intermediate nodes such as area border LSRs.
In a distributed routing environment, however, the In a distributed routing environment, however, the
resource information used to compute a constraint-based resource information used to compute a constraint-based
path may be out of date. This means that a setup request path may be out of date. This means that a setup request
may be blocked, for example, because a link or node along may be blocked, for example, because a link or node along
the selected path has insufficient resources. the selected path has insufficient resources.
In RSVP-TE, a blocked LSP setup may result in a PathErr In RSVP-TE, a blocked LSP setup may result in a PathErr
message sent to the initiator or a ResvErr sent to the message sent to the initiator, or a ResvErr sent to the
terminator (egress LSR). These messages may result in the terminator (egress LSR). These messages may result in the
LSP setup being abandoned. In Generalized MPLS [RC3473] LSP setup being abandoned. In Generalized MPLS [RC3473]
the Notify message may additionally be used to expedite the Notify message may additionally be used to expedite
notification of LSP failures to ingress and egress LSRs, notification of LSP failures to ingress and egress LSRs,
or to a specific "repair point". or to a specific "repair point".
These existing mechanisms provide a certain amount of These existing mechanisms provide a certain amount of
information about the path of the failed LSP. information about the path of the failed LSP.
2.2. Repair and Restoration 2.2. Repair and Restoration
skipping to change at line 228 skipping to change at line 207
request. Determination of the identity of the blocked request. Determination of the identity of the blocked
link or node can be achieved by the mechanism known as link or node can be achieved by the mechanism known as
crankback routing [PNNI, ASH1]. In RSVP-TE, crankback crankback routing [PNNI, ASH1]. In RSVP-TE, crankback
signaling requires notifying an upstream LSR of the signaling requires notifying an upstream LSR of the
location of the blocked link or node. In some cases this location of the blocked link or node. In some cases this
requires more information than is currently available in requires more information than is currently available in
the signaling protocols. the signaling protocols.
On the other hand, various restoration schemes for link On the other hand, various restoration schemes for link
or node failures have been proposed in [RFC3469] and or node failures have been proposed in [RFC3469] and
others including fast restoration. These schemes rely on include fast restoration. These schemes rely on
the existence of a backup LSP to protect the primary, but the existence of a backup LSP to protect the primary, but
if both the primary and backup paths fail it is necessary if both the primary and backup paths fail it is necessary
to reestablish the LSP on an end-to-end basis avoiding to re-establish the LSP on an end-to-end basis avoiding
the known failures. Similarly, fast restoration by the known failures. Similarly, fast restoration by
establishing a restoration path on demand after failure establishing a restoration path on demand after failure
requires computation of a new LSP that avoids the known requires computation of a new LSP that avoids the known
failures. End-to-end restoration for alternate routing failures. End-to-end restoration for alternate routing
requires the location of the failed link or node. requires the location of the failed link or node.
Crankback routing schemes could also be used to notify Crankback routing schemes could be used to notify
upstream LSRs of the location of the failure. upstream LSRs of the location of the failure.
Furthermore, in situations where many link or node Furthermore, in situations where many link or node
failures occur at the same time, the difference between failures occur at the same time, the difference between
the distributed routing information and the real-time the distributed routing information and the real-time
network state becomes much greater than in normal LSP network state becomes much greater than in normal LSP
setups. LSP restoration might, therefore, be performed setups. LSP restoration might, therefore, be performed
with inaccurate information, which is likely to cause with inaccurate information, which is likely to cause
setup blocking. Crankback routing could improve failure setup blocking. Crankback routing could improve failure
recovery in these situations. recovery in these situations.
skipping to change at line 276 skipping to change at line 255
explicit re-routing indication that explicitly authorizes explicit re-routing indication that explicitly authorizes
re-routing. re-routing.
Various existing protocol options and exchanges including Various existing protocol options and exchanges including
the error values of PathErr message [RFC2205, RFC3209] the error values of PathErr message [RFC2205, RFC3209]
and the Notify message [RFC3473] allow an implementation and the Notify message [RFC3473] allow an implementation
to infer a situation where re-routing can be done. This to infer a situation where re-routing can be done. This
allows for recovery from network errors or resource allows for recovery from network errors or resource
contention. contention.
However, such inference of recovery signaling is not However, such inference of recovery signaling is not always
always desirable since it may be doomed to failure. desirable since it may be doomed to failure. For example,
Experience of using release messages in TDM-based experience of using release messages in TDM-based networks for
networks for analogous purposes provides some guidance. analogous implicit and explicit re-routing indications purposes
One can use the receipt of a release message with a cause provides some guidance. This background information is given in
value (CV) indicating "link congestion" to trigger a re- Appendix A."
routing attempt at the originating node. However, this
sometimes leads to problems.
*--------------------* *-----------------*
| | | |
| N2 ----------- N3-|--|----- AT--- EO2 |
| | | \| | / | |
| | | |--|- / | |
| | | | | \/ | |
| | | | | /\ | |
| | | |--|- \ | |
| | | /| | \ | |
| N1 ----------- N4-|--|----- EO1 |
| | | |
*--------------------* *-----------------*
A-1 A-2
Figure 1. Example of network topology
Figure 1 illustrates four examples based on service-
provider experiences with respect to crankback (i.e.,
explicit indication) versus implicit indication through a
release with CV. In this example, N1, N2,N3, and N4 are
located in one area (A-1), and AT, EO1, and EO2 are in
another area (A-2).
Note that two distinct areas are used in this example to
expose the issues clearly. In fact, the issues are not
limited to multi-area networks, but arise whenever path
computation is distributed throughout the network. For
example where loose routes, AS routes or path computation
domains are used.
1. A connection request from node N1 to EO1 may route to N4
and then find "all circuits busy". N4 returns a release
message to N1 with CV34 indicating all circuits busy.
Normally, a node such as N1 is programmed to block a
connection request when receiving CV34, although there is
good reason to try to alternate route the connection request
via N2 and N3.
Some service providers have implemented a technique called
route advance (RA), where if a node that is RA capable
receives a release message with CV34, it will use this as an
implicit re-route indication and try to find an alternate
route for the connection request if possible. In this
example, alternate route N1-N2-N3-EO1 can be tried and may
well succeed.
2. Suppose a connection request goes from N2 to N3 to AT
trying to reach EO2 and is blocked at link AT-EO2. Node AT
returns a CV34 and with RA, N2 may try to re-route N2-N1-N4-
AT-EO2, but of course this fails again. The problem is that
N2 does not realize where this blocking occurred based on
the CV34, and in this case there is no point in further
alternate routing.
3. However, in another case of a connection request from N2
to E02, suppose that link N3-AT is blocked. In this case N3
should return crankback information (and not CV34) so that
N2 can alternate route to N1-N4-AT-EO2, which may well be
successful.
4. In a final example, for a connection request from EO1 to
N2, EO1 first tries to route the connection request directly
to N3. However, node N3 may reject the connection request
even if there is bandwidth available on link N3-EO1 (perhaps
for priority routing considerations, e.g., reserving
bandwidth for high priority connection requests). However,
when N3 returns CV34 in the release message, EO1 blocks the
connection request (a normal response to CV34 especially if
E01-N4 is already known blocked) rather than trying to
alternate route through AT-N3-N2, which might be successful.
If N3 returns crankback information, EO1 could respond by
trying the alternate route.
It is certainly the case that with topology exchange, It is certainly the case that with topology exchange,
such as OSPF, the ingress LSR could infer the re-routing such as OSPF, the ingress LSR could infer the re-routing
condition. However, convergence of routing information is condition. However, convergence of routing information is
typically slower than the expected LSP setup times. One typically slower than the expected LSP setup times. One of
of the reasons for crankback is to avoid the overhead of the reasons for crankback is to avoid the overhead of
available-link-bandwidth flooding, and to more efficiently available-link-bandwidth flooding, and to more efficiently
use local state information to direct alternate routing at use local state information to direct alternate routing
the ingress-LSR. at the ingress-LSR.
[ASH1] shows how event-dependent-routing can just use crankback, [ASH1] shows how event-dependent-routing can just use crankback,
and not available-link-bandwidth flooding, to decide on the re- and not available-link-bandwidth flooding, to decide on the re-
route path in the network through "learning models". Reducing route path in the network through "learning models". Reducing
this flooding reduces overhead and can lead to the ability to this flooding reduces overhead and can lead to the ability to
support much larger AS sizes. support much larger AS sizes.
Therefore, the alternate routing should be indicated based on Therefore, the alternate routing should be indicated based on
an explicit indication (as in examples 3 and 4), and it is best an explicit indication, and it is best to know the following
to know the following information separately: information separately:
a) where blockage/congestion occurred (as in examples 1-2),
and
b) whether alternate routing "should" be attempted even if - where blockage/congestion occurred
there is no "blockage" (as in example 4). - whether alternate routing "should" be attempted.
4. Required Operation 4. Required Operation
Section 2 identifies some of the circumstances under which Section 2 identifies some of the circumstances under which
crankback may be useful. Crankback routing is performed as crankback may be useful. Crankback routing is performed as
described in the following procedures, when an LSP setup described in the following procedures, when an LSP setup
request is blocked along the path or when an existing LSP fails. request is blocked along the path, or when an existing LSP fails.
4.1. Resource Failure or Unavailability 4.1. Resource Failure or Unavailability
When an LSP setup request is blocked due to unavailable When an LSP setup request is blocked due to unavailable
resources, an error message response with the location resources, an error message response with the location
identifier of the blockage should be returned to the LSR identifier of the blockage should be returned to the LSR
initiating the LSP setup (ingress LSR), the area border initiating the LSP setup (ingress LSR), the area border
LSR, the AS border LSR, or to some other repair point. LSR, the AS border LSR, or to some other repair point.
This error message carries an error specification This error message carries an error specification
according to [RFC3209] - this indicates the cause of the according to [RFC3209] - this indicates the cause of the
error and the node/link on which the error occurred. error and the node/link on which the error occurred.
Crankback operation may require further information as Crankback operation may require further information as
detailed in section 6. detailed in sections 4.2.1 and 7.
4.2. Computation of an Alternate Path 4.2. Computation of an Alternate Path
In a flat network without partitioning, when the ingress In a flat network without partitioning, when the ingress
LSR receives the error message it computes an alternate LSR receives the error message it computes an alternate
path around the blocked link or node to satisfy QoS path around the blocked link or node to satisfy QoS
constraints using link state information about the area. constraints using link state information about the network.
If an alternate path is found, a new LSP setup request is If an alternate path is found, a new LSP setup request is
sent over this path. sent over this path.
On the other hand, in a network partitioned into areas On the other hand, in a network partitioned into areas
such as with hierarchical OSPF, an area border LSR may such as with hierarchical OSPF, an area border LSR may
intercept and terminate the error response, and perform intercept and terminate the error response, and perform
alternate (re-)routing within the downstream area. alternate (re-)routing within the downstream area.
In a third scenario, any node within an area may act as a In a third scenario, any node within an area may act as a
repair point. In this case, the LSR behaves much as an repair point. In this case, each LSR behaves much as an
area border LSR as described above. It can intercept and area border LSR as described above. It can intercept and
terminate the error response, and perform alternate terminate the error response, and perform alternate
routing. This may be particularly useful where domains of routing. This may be particularly useful where domains of
computation are applied within the network, however if computation are applied within the network, however if
all nodes in the network perform re-routing it is all nodes in the network perform re-routing it is
possible to spend excessive network and CPU resources on possible to spend excessive network and CPU resources on
re-routing attempts that would be better made only at re-routing attempts that would be better made only at
designated re-routing nodes. This scenario is somewhat designated re-routing nodes. This scenario is somewhat
like 'MPLS fast re-route' [FASTRR], in which any node in like 'MPLS fast re-route' [FASTRR], in which any node in
the MPLS domain can establish 'local repair' LSPs after the MPLS domain can establish 'local repair' LSPs after
skipping to change at line 484 skipping to change at line 384
path computation to detour all blockages. path computation to detour all blockages.
If a second error response is received by a repair point If a second error response is received by a repair point
(while it is performing crankback re-routing) it should (while it is performing crankback re-routing) it should
update the history table that lists all experienced update the history table that lists all experienced
blockages, and use the entire gathered information when blockages, and use the entire gathered information when
making a further re-routing attempt. making a further re-routing attempt.
4.4. Handling Re-route Failure 4.4. Handling Re-route Failure
Multiple blockages (for the same LSP) may occur, and Multiple blockages (for the same LSP) may occur, and successive
successive setup retry attempts may fail. Retaining error setup retry attempts may fail. Retaining error information from
information from previous attempts ensures that there is previous attempts ensures that there is no thrashing of setup
no thrashing of setup attempts, and knowledge of the attempts, and knowledge of the blockages increases with each
blockages increases with each attempt. attempt.
It may be that after several retries, a given repair It may be that after several retries, a given repair point is
point is unable to compute a path to the destination unable to compute a path to the destination (that is, the egress
(that is, the egress of the LSP) that avoids all of the of the LSP) that avoids all of the blockages. In this case, it
blockages. In this case, it must pass the error must pass the error indication upstream. It is most useful to the
indication upstream. It is most useful to the upstream upstream nodes (and in particular the ingress LSR) that may,
nodes (and in particular the ingress LSR) that may, themselves, attempt new routes for the LSP setup, if the error
themselves, attempt new routes for the LSP setup if the indication in this case identifies all of the downstream blockages
error indication in this case identifies all of the and also the node that has been unable to compute an alternate path.
downstream blockages and also the node that has been
unable to compute an alternate path.
4.5. Limiting Re-routing Attempts 4.5. Limiting Re-routing Attempts
It is important to prevent an endless repetition of LSP It is important to prevent an endless repetition of LSP
setup attempts using crankback routing information after setup attempts using crankback routing information after
error conditions are signaled, or during periods of high error conditions are signaled, or during periods of high
congestion. It may also be useful to reduce the number of congestion. It may also be useful to reduce the number of
retries, since failed retries will increase setup latency retries, since failed retries will increase setup latency
and degrade performance. and degrade performance.
skipping to change at line 544 skipping to change at line 442
setup according to local policy and might choose to re- setup according to local policy and might choose to re-
use its original path or seek to compute a path that use its original path or seek to compute a path that
avoids the blocked resources. In the latter case, it may avoids the blocked resources. In the latter case, it may
be useful to indicate the blocked resource in this error be useful to indicate the blocked resource in this error
message. message.
5. Existing Protocol Support for Crankback Re-routing 5. Existing Protocol Support for Crankback Re-routing
Crankback re-routing is appropriate for use with RSVP-TE. Crankback re-routing is appropriate for use with RSVP-TE.
1) Path establishment may fail because of an inability to 1) LSP establishment may fail because of an inability to
route, perhaps because links are down. In this case a route, perhaps because links are down. In this case a
PathErr message is returned to the initiator. PathErr message is returned to the initiator.
2) Path establishment may fail because resources are 2) LSP establishment may fail because resources are
unavailable. This is particularly relevant in GMPLS where unavailable. This is particularly relevant in GMPLS where
explicit label control may be in use. Again, a PathErr explicit label control may be in use. Again, a PathErr
message is returned to the initiator. message is returned to the initiator.
3) Resource reservation may fail in the upstream direction, 3) Resource reservation may fail during LSP establishment,
as the Resv is processed, and resources are reserved. If as the Resv is processed. If
resources are not available on the required link or at a resources are not available on the required link or at a
specific node, a ResvErr message is returned to the egress specific node, a ResvErr message is returned to the egress
node indicating "Admission Control failure" [RFC2205]. The node indicating "Admission Control failure" [RFC2205]. The
egress is allowed to change the FLOWSPEC and try again, but egress is allowed to change the FLOWSPEC and try again, but
in the event that this is not practical or not supported in the event that this is not practical or not supported
(particularly in the GMPLS context), the egress LSR may (particularly in the GMPLS context), the egress LSR may
choose to take any one of the following actions. choose to take any one of the following actions.
- Ignore the situation and allow recovery to happen through - Ignore the situation and allow recovery to happen through
Path refresh message and refresh timeout [RFC2205]. Path refresh message and refresh timeout [RFC2205].
- Send a PathErr message towards the initiator indicating - Send a PathErr message towards the initiator indicating
"Admission Control failure". "Admission Control failure".
- Send a ResvTear message towards the initiator to abort - Send a ResvTear message towards the initiator to abort
the LSP setup. the LSP setup.
Note that in multi-area networks, the ResvErr might be Note that in multi-area/AS networks, the ResvErr might be
intercepted and acted on at an area border router. intercepted and acted on at an area/AS border router.
4) It is also possible to make resource reservations on the 4) It is also possible to make resource reservations on the forward
forward path as the Path message is processed. This choice path as the Path message is processed. This choice is compatible
is compatible with LSP setup in GMPLS networks [RFC3471]. In with LSP setup in GMPLS networks [RFC3471]. In this case if
this case if resources are not available, a PathErr message resources are not available, a PathErr message is returned to
is returned to initiator indicating "Admission Control initiator indicating "Admission Control failure".
failure".
Crankback information would be useful to an upstream node Crankback information would be useful to an upstream node (such as
(such as the ingress) if it is supplied on a PathErr or a the ingress) if it is supplied on a PathErr or a Notify message that
Notify message that is sent upstream. is sent upstream.
5.1. RSVP-TE [RFC 3209] 5.1. RSVP-TE [RFC 3209]
In RSVP-TE a failed LSP setup attempt results in a PathErr In RSVP-TE a failed LSP setup attempt results in a PathErr
message returned upstream. The PathErr message carries an message returned upstream. The PathErr message carries an
ERROR_SPEC object, which indicates the node or interface ERROR_SPEC object, which indicates the node or interface
reporting the error and the reason for the failure. reporting the error and the reason for the failure.
Crankback re-routing can be performed explicitly avoiding Crankback re-routing can be performed explicitly avoiding
the node or interface reported. the node or interface reported.
5.2. GMPLS-RSVP-TE [RFC 3473] 5.2. GMPLS-RSVP-TE [RFC 3473]
GMPLS extends the error reporting described above by GMPLS extends the error reporting described above by
allowing LSRs to report the interface that is in error in allowing LSRs to report the interface that is in error in
addition to the identity of the node reporting the error. addition to the identity of the node reporting the error.
This further enhances the ability of a re-computing node This further enhances the ability of a re-computing node
to route around the error. to route around the error.
GMPLS introduces a targeted Notify message that may be GMPLS introduces a targeted Notify message that may be used to
used to report LSP failures direct to a selected node. report LSP failures direct to a selected node. This message carries
This message carries the same error reporting facilities the same error reporting facilities as described above. The Notify
as described above. The Notify message may be used to message may be used to expedite the propagation of error
expedite the propagation of error notifications, but in a notifications, but in a network that offers crankback routing at
network that offers crankback routing at multiple nodes multiple nodes there would need to be some agreement between LSRs
there would need to be some agreement between LSRs as to as to whether PathErr or Notify provides the stimulus for crankback
whether PathErr or Notify provides the stimulus for operation. Otherwise, multiple nodes might attempt to repair the LSP
crankback operation. Otherwise, multiple nodes might at the same time, because
attempt to repair the LSP at the same time, in particular
because 1) these messages can flow through different 1) these messages can flow through different paths before
paths before reaching the ingress LSR and 2) the destination reaching the ingress LSR, and
of the Notify message might not be the ingress LSR. 2) the destination of the Notify message might not be the
ingress LSR.
Section B : Solution Section B : Solution
6. Control of Crankback Operation 6. Control of Crankback Operation
6.1. Requesting Crankback and Controlling In-Network Re-routing 6.1. Requesting Crankback and Controlling In-Network Re-routing
When a request is made to set up an LSP tunnel, the ingress When a request is made to set up an LSP tunnel, the ingress LSR
LSR should specify whether it wants crankback information to should specify whether it wants crankback information to be collected
be collected in the event of a failure and whether it requests in the event of a failure, and whether it requests re-routing
re-routing attempts by any or specific intermediate nodes. For attempts by any or specific intermediate nodes. For this purpose, a
this purpose, a Re-routing Flag field is added to the protocol Re-routing Flag field is added to the protocol setup request
setup request messages. The corresponding values are mutually messages. The corresponding values are mutually exclusive.
exclusive.
No Re-routing Intermediate nodes SHOULD NOT attempt No Re-routing The ingress node MAY attempt re-routing after
failure. Intermediate nodes SHOULD NOT attempt
re-routing after failure. Nodes detecting re-routing after failure. Nodes detecting
failures MUST report an error and MAY supply failures MUST report an error and MAY supply
crankback information. This is the default crankback information. This is the default
and backwards compatible option. and backwards compatible option.
End-to-end Re-routing Intermediate nodes SHOULD NOT attempt End-to-end Re-routing The ingress node MAY attempt re-routing after
failure. Intermediate nodes SHOULD NOT attempt
re-routing after failure. Nodes detecting re-routing after failure. Nodes detecting
failures MUST report an error and SHOULD failures MUST report an error and SHOULD
supply crankback information. supply crankback information.
Boundary Re-routing Intermediate nodes MAY attempt re-routing Boundary Re-routing Intermediate nodes MAY attempt re-routing
after failure only if they are Area Border after failure only if they are Area Border
Routers or AS Border Routers. The boundary Routers or AS Border Routers. The boundary
ABR/ASBR can either decide to forward the (ABR/ASBR) can either decide to forward the
Path Error message upstream to the Head-end error message upstream to the ingress
LSR or try to select another egress boundary LSR or try to select another egress boundary
LSR. Other nodes SHOULD NOT attempt re- LSR. Other intermediate nodes SHOULD NOT
routing. Nodes detecting failures MUST attempt re-routing. Nodes detecting failures
report an error and SHOULD supply crankback MUST report an error and SHOULD supply
information. crankback information.
Segment-based Re-routing Segment-based Re-routing
All intermediate nodes MAY attempt re- All nodes MAY attempt re-routing after
routing after failure. Nodes detecting failure. Nodes detecting failures MUST report
failures MUST report an error and SHOULD an error and SHOULD supply full crankback
supply full crankback information. 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 A node that detects the failure to setup an LSP or the failure of an
failure of an established LSP SHOULD act according to the established LSP SHOULD act according to the Re-routing Flag passed on
Re-routing Flag passed on the LSP setup request. the LSP setup request.
If Segment-based Re-routing is allowed or if Boundary Re- If Segment-based Re-routing is allowed, or if Boundary Re-routing is
routing is allowed and the detecting node is an ABR or ASBR, allowed and the detecting node is an ABR or ASBR, the detecting node
the detecting node MAY immediately attempt to re-route. MAY immediately attempt to re-route.
If End-to-end Re-routing is indicated, or if Segment-based or If End-to-end Re-routing is indicated, or if Segment-based or
Boundary Re-routing is allowed and the detecting node chooses Boundary Re-routing is allowed and the detecting node chooses
not to make re-routing attempts (or has exhausted all possible not to make re-routing attempts (or has exhausted all possible
re-routing attempts), the detecting node returns a protocol re-routing attempts), the detecting node MUST return a protocol
error indication and SHOULD include full crankback information. error indication and SHOULD include full crankback information.
6.3. Limiting Re-routing Attempts 6.3. Limiting Re-routing Attempts
Each repair point should apply a locally configurable Each repair point SHOULD apply a locally configurable
limit to the number of attempts it makes to re-route an limit to the number of attempts it makes to re-route an
LSP. This helps to prevent excessive network usage in the LSP. This helps to prevent excessive network usage in the
event of significant faults and allows back-off to other event of significant faults, and allows back-off to other
repair points which may have a better chance of routing repair points which may have a better chance of routing
around the problem. around the problem.
6.3.1 New Status Codes for Re-routing 6.3.1 New Status Codes for Re-routing
An error code/value of "Routing Problem"/"Re-routing An error code/value of "Routing Problem"/"Re-routing
limit exceeded" (24/TBD) is used to identify that a node limit exceeded" (24/TBD) is used to identify that a node
has abandoned crankback re-routing because it has reached has abandoned crankback re-routing because it has reached
a threshold for retry attempts. a threshold for retry attempts.
skipping to change at line 704 skipping to change at line 603
6.4. Protocol Control of Re-routing Behavior 6.4. Protocol Control of Re-routing Behavior
The Session Attributes Object in RSVP-TE is used on Path The Session Attributes Object in RSVP-TE is used on Path
messages to indicate the capabilities and attributes of the messages to indicate the capabilities and attributes of the
session. This object contains an 8-bit flag field which is session. This object contains an 8-bit flag field which is
used to signal individual Boolean capabilities or attributes. used to signal individual Boolean capabilities or attributes.
The Re-Routing Flag described in section 5.1 would fit The Re-Routing Flag described in section 5.1 would fit
naturally into this field, but there is a scarcity of bits, so naturally into this field, but there is a scarcity of bits, so
use is made of the new LSP_ATTRIBUTES object defined in use is made of the new LSP_ATTRIBUTES object defined in
[LSP-ATTRIB]. Three bits are defined for inclusion in the LSP [LSP-ATTRIB]. Three bits are defined for inclusion in the LSP
Attributes TLV as follows. The values below are suggested and Attributes TLV as follows. The bit numbers below are suggested
actual values are TBD by IETF consensus. and actual values are TBD by IETF consensus.
0x01 End-to-end re-routing desired Bit Name and Usage
This flag indicates the end-to-end re- Number
routing behavior for an LSP under
establishment. This MAY also be used
for specifying the behavior of end-to-
end LSP restoration for established LSPs.
0x02 Boundary re-routing desired. 1 End-to-end re-routing desired.
This flag indicates the end-to-end re-routing behavior
for an LSP under establishment. This MAY also be used
for specifying the behavior of end-to-end LSP restoration
for established LSPs.
2 Boundary re-routing desired.
This flag indicates the boundary re-routing This flag indicates the boundary re-routing
behavior for an LSP under establishment. behavior for an LSP under establishment.
This MAY also be used for specifying the This MAY also be used for specifying the
segment-based (hierarchical) LSP restoration segment-based (hierarchical) LSP restoration
for established LSPs. The boundary ABR/ASBR for established LSPs. The boundary ABR/ASBR
can either decide to forward the PathErr can either decide to forward the PathErr
message upstream to the Head-end LSR or try message upstream to the Head-end LSR or try
to select another egress boundary LSR. to select another egress boundary LSR.
0x04 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 an LSP under re-routing behavior for an LSP under
establishment. This MAY also be used establishment. This MAY also be used
for specifying the segment-based LSP for specifying the segment-based LSP
restoration for established LSPs. restoration for established LSPs.
7. Reporting Crankback Information 7. Reporting Crankback Information
7.1. Required Information 7.1. Required Information
As described above, full crankback information should As described above, full crankback information SHOULD
indicate the node, link and other resources, which have indicate the node, link and other resources, which have
been attempted but have failed because of allocation been attempted but have failed because of allocation
issues or network failure. issues or network failure.
The default crankback information SHOULD include the The default crankback information SHOULD include the
interface and the node address. interface and the node address.
7.2. Protocol Extensions 7.2. Protocol Extensions
[RFC3473] defines an IF_ID ERROR_SPEC Object that can be [RFC3473] defines an IF_ID ERROR_SPEC object that can be
used on PathErr, ResvErr and Notify messages to convey used on PathErr, ResvErr and Notify messages to convey
the information carried in the Error Spec Object defined the information carried in the Error Spec Object defined
in [RFC 3209]. Additionally, it has scope for carrying in [RFC 3209]. Additionally, the IF_ID ERROR_SPEC Object
TLVs that help identify the identity of the link has scope for carrying TLVs that identify the link
associated with the error. associated with the error.
The TLVs for use with this object are defined in The TLVs for use with this object are defined in [RFC3471], and
[RFC3471], and are as follows. They are used to identify are listed below. They are used to identify links in the IF_ID
links in the IF_ID PHOP Object and in the IF_ID PHOP Object and in the IF_ID ERROR_SPEC object to identify the
ERROR_SPEC Object to identify the failed resource which failed resource which is usually the downstream resource from
is usually the downstream resource from the reporting the reporting node.
node.
Type Length Format Description Type Length Format Description
-------------------------------------------------------------------- --------------------------------------------------------------------
1 8 IPv4 Addr. IPv4 (Interface address) 1 8 IPv4 Addr. IPv4 (Interface address)
2 20 IPv6 Addr. IPv6 (Interface address) 2 20 IPv6 Addr. IPv6 (Interface address)
3 12 Compound IF_INDEX (Interface index) 3 12 Compound IF_INDEX (Interface index)
4 12 Compound COMPONENT_IF_DOWNSTREAM (Component interface) 4 12 Compound COMPONENT_IF_DOWNSTREAM (Component interface)
5 12 Compound COMPONENT_IF_UPSTREAM (Component interface) 5 12 Compound COMPONENT_IF_UPSTREAM (Component interface)
Two new TLVs are defined for use in the IF_ID PHOP Object Two further TLVs are defined in [IFID_UNNUM] for use in the IF_ID
and in the IF_ID Error Spec Object. Note that the Type PHOP Object and in the IF_ID ERROR_SPEC object to identify component
values shown here are only suggested values - final links of unnumbered interfaces. Note that the Type values shown here
values are TBD and to be determined by IETF consensus. are only suggested values in [IFID_UNNUM] - final values are TBD and
to be determined by IETF consensus.
Type Length Format Description Type Length Format Description
-------------------------------------------------------------------- --------------------------------------------------------------------
6 16 See below UNUM_COMPONENT_IF_DOWN (Component interface) 6 16 Compound UNUM_COMPONENT_IF_DOWN (Component interface)
7 16 See below UNUM_COMPONENT_IF_UP (Component interface) 7 16 Compound UNUM_COMPONENT_IF_UP (Component interface)
In order to facilitate reporting of crankback In order to facilitate reporting of crankback information, the
information, the following additional TLVs are defined. following additional TLVs are defined. Note that the Type values
Note that the Type values shown here are only suggested shown here are only suggested values - final values are TBD and to be
values - final values are TBD and to be determined by determined by IETF consensus.
IETF consensus.
Type Length Format Description Type Length Format Description
-------------------------------------------------------------------- --------------------------------------------------------------------
8 var See below DOWNSTREAM_LABEL (GMPLS label) 8 var See below DOWNSTREAM_LABEL (GMPLS label)
9 var See below UPSTREAM_LABEL (GMPLS label) 9 var See below UPSTREAM_LABEL (GMPLS label)
10 8 See below NODE_ID (Router Id) 10 8 See below NODE_ID (Router Id)
11 x See below OSPF_AREA (Area Id) 11 x See below OSPF_AREA (Area Id)
12 x See below ISIS_AREA (Area Id) 12 x See below ISIS_AREA (Area Id)
13 8 See below AUTONOMOUS_SYSTEM (Autonomous system) 13 8 See below AUTONOMOUS_SYSTEM (Autonomous system)
14 var See below ERO_CONTEXT (ERO subobject) 14 var See below ERO_CONTEXT (ERO subobject)
skipping to change at line 815 skipping to change at line 715
28 x See below REPORTING_OSPF_AREA (Area Id) 28 x See below REPORTING_OSPF_AREA (Area Id)
29 x See below REPORTING_ISIS_AREA (Area Id) 29 x See below REPORTING_ISIS_AREA (Area Id)
30 8 See below REPORTING_AS (Autonomous system) 30 8 See below REPORTING_AS (Autonomous system)
31 var See below PROPOSED_ERO (ERO subobjects) 31 var See below PROPOSED_ERO (ERO subobjects)
32 var See below NODE_EXCLUSIONS (List of nodes) 32 var See below NODE_EXCLUSIONS (List of nodes)
33 var See below LINK_EXCLUSIONS (List of interfaces) 33 var See below LINK_EXCLUSIONS (List of interfaces)
For types 1, 2, 3, 4 and 5, the format of the Value field For types 1, 2, 3, 4 and 5, the format of the Value field
is already defined in [RFC3471]. is already defined in [RFC3471].
For types 6 and 7 the format of the Value field is already
defined in [IFID_UNNUM].
For types 16 and 18, they format of the Value field is For types 16 and 18, they format of the Value field is
the same as for type 1. the same as for type 1.
For types 17 and 19, the format of the Value field is the For types 17 and 19, the format of the Value field is the
same as for type 2. same as for type 2.
For types 20, 21 and 22, the formats of the Value fields For types 20, 21 and 22, the formats of the Value fields
are the same as for types 3, 4 and 5 respectively. are the same as for types 3, 4 and 5 respectively.
For types 6, 7, 23 and 24 the Value field has the format: For types 23 and 24 the Value field is the same as for
types 6 and 7 respectively.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Component ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IP Address: 32 bits
The IP address field may carry either an IP
address associated with the router, where
associated address is the value carried in
a router address TLV of routing.
Interface ID: 32 bits
The Interface ID identifier of the
unnumbered link.
Component ID: 32 bits
A bundled component link. The special value
0xFFFFFFFF can be used to indicate the same
label is to be valid across all component
links.
For types 8, 9, 25 and 26 the length field is variable For types 8, 9, 25 and 26 the length field is variable
and the Value field is a label as defined in [RFC3471]. and the Value field is a label as defined in [RFC3471].
As with all uses of labels, it is assumed that any node As with all uses of labels, it is assumed that any node
that can process the label information knows the syntax that can process the label information knows the syntax
and semantics of the label from the context. Note that and semantics of the label from the context. Note that
all TLVs are zero-padded to a multiple four octets so all TLVs are zero-padded to a multiple four octets so
that if a label is not itself a multiple of four octets that if a label is not itself a multiple of four octets
it must be disambiguated from the trailing zero pads by it must be disambiguated from the trailing zero pads by
knowledge derived from the context. knowledge derived from the context.
skipping to change at line 886 skipping to change at line 762
For types 11 and 28 the Value field has the format: For types 11 and 28 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 the node is part of. In the case of The 4-octet area identifier for the node. In the case of
ABRs, this identifies the area where the failure has occurred. ABRs, this identifies the area where the failure has occurred.
For types 12 and 29 the Value field has the format: For types 12 and 29 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 975 skipping to change at line 850
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Link Identifiers: Link Identifiers:
A sequence of TLVs as defined here of types 3, 4, 5, 6 or 7 A sequence of TLVs as defined here of types 3, 4, 5, 6 or 7
that indicates incoming interfaces at downstream nodes that that indicates incoming interfaces at downstream nodes that
have already participated in crankback attempts and have have already participated in crankback attempts and have
been declared unusable for the current LSP setup attempt. been declared unusable for the current LSP setup attempt.
7.2.1 Guidance for Use of IF_ID Error Spec TLVs 7.3 Guidance for Use of IF_ID ERROR_SPEC TLVs
If Crankback is not being used but an IF-ID Error_Spec 7.3.1 General Principles
Object is included in a PathErr, ResvErr or Notify
If crankback is not being used but an IF-ID ERROR_SPEC
object is included in a PathErr, ResvErr or Notify
message, the sender SHOULD include one of the TLVs of message, the sender SHOULD include one of the TLVs of
type 1 through 5 as described in [RFC3473]. A sender that type 1 through 5 as described in [RFC3473]. A sender that
wishes to report an error with a component link of an wishes to report an error with a component link of an
unnumbered bundle SHOULD use the new TLVs of type 6 or 7 unnumbered bundle SHOULD use the new TLVs of type 6 or 7
as defined in this document. A sender MAY include as defined in this document. A sender MAY include
additional TLVs from the range 8 through 33 to report additional TLVs from the range 8 through 33 to report
crankback information, although this information will at crankback information, although this information will at
most only be used for logging. most only be used for logging.
If Cranback is being used, the sender of a PathErr, If crankback is being used, the sender of a PathErr,
ResvErr or Notify message MUST use the IF_ID Error_Spec ResvErr or Notify message MUST use the IF_ID ERROR_SPEC
Object and MUST include at least one of the TLVs in the object and MUST include at least one of the TLVs in the
range 1 through 7 as described in [RFC3473] and the range 1 through 7 as described in [RFC3473] and the
previous paragraph. Additional TLVs SHOULD also be previous paragraph. Additional TLVs SHOULD also be
included to report further information. Note that all included to report further information. The following
such TLVs are optional and MAY be omitted. Inclusion of section gives advice on which TLVs should be used under
the optional TLVs SHOULD be performed where doing so different circumstances, and which TLVs must be supported
helps to facilitate error reporting and crankback. The by LSRs.
TLVs fall into three categories: those that are essential
to report the error, those that provide additional Note that all such TLVs are optional and MAY be omitted.
information that is or may be fundamental to the utility Inclusion of the optional TLVs SHOULD be performed where
of cranback, and those that provide additional doing so helps to facilitate error reporting and crankback.
information that may be useful for crankback in some The TLVs fall into three categories: those that are essential
circumstances. to report the error, those that provide additional information
that is or may be fundamental to the utility of crankback, and
those that provide additional information that may be useful for
crankback in some circumstances.
Note that all LSRs MUST be prepared to receive and forward any
TLV as per [RFC3473]. There is, however, no requirement for an
LSR to actively process any but the error report TLVs. An LSR
that proposes to perform crankback re-routing SHOULD support
receipt and processing of all of the fundamental crankback TLVs,
and is RECOMMENDED to support the receipt and processing of
the additional crankback TLVs.
It should be noted, however, that some assumptions about the
TLVs 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 need to support the receipt and processing
of TLV types 28 and 29. 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.
7.3.2 Error Report TLVs
Error Report TLVs are those in the range 1 through 7.
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 used, at least one of the TLVs in
the range 1 through 7 MUST be present. The choice of which
TLV to use will be dependent on the circumstance of the error
and device capabilities. For example, a device that does not
support IPv6 will not need the ability to create a TLV of type
2. Note, however, that such a device MUST still be prepared
to receive and process all error report TLVs.
7.3.3 Fundamental Crankback TLVs
Many of the TLVs report the specific resource that has Many of the TLVs report the specific resource that has
failed. For example, TLV type 1 can be used to report that failed. For example, TLV type 1 can be used to report that
the setup attempt was blocked by some form of resource the setup attempt was blocked by some form of resource
failure on a specific interface identified by the IP failure on a specific interface identified by the IP
address supplied. TLVs in this category are 1 through 13. address supplied. TLVs in this category are 1 through 13.
These TLVs SHOULD be supplied whenever the node detecting These TLVs SHOULD be supplied whenever the node detecting
and reporting the failure with crankback information has and reporting the failure with crankback information has
the information available. The use of TLVs of type 10, 11, the information available.
12 and 13, MAY, however, be omitted according to local
policy and relevance of the information. The use of TLVs of type 10, 11, 12 and 13, MAY, however, be
omitted according to local policy and relevance of the
information.
7.3.4 Additional Crankback TLVs
Some TLVs help to locate the fault within the context of
the path of the LSP that was being set up. TLVs of types
14, 15, 16 and 17 help 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
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 non-specific abstract node) and
deduce that its upstream neighbor may have selected the
path using next hop routing. In this case, providing the
ERO context will be useful to the node further that
performs re-routing.
Reporting nodes SHOULD also supply TLVs from the range 14 Reporting nodes SHOULD also supply TLVs from the range 14
through 26 as appropriate for reporting the error. The through 26 as appropriate for reporting the error. The
reporting nodes MAY also supply TLVs from the range 27 reporting nodes MAY also supply TLVs from the range 27
through 33. through 33.
Note that in deciding whether a TLV in the range 14 Note that in deciding whether a TLV in the range 14
through 26 "is appropriate", the reporting node should through 26 "is appropriate", the reporting node should
consider amongst other things, whether the information is consider amongst other things, whether the information is
pertinent to the cause of the failure. For example, when pertinent to the cause of the failure. For example, when
a cross-connection fails it may be that the outgoing a cross-connection fails it may be that the outgoing
interface is faulted, in which case only the interface interface is faulted, in which case only the interface
(for example, TLV type 1) needs to be reported, but if (for example, TLV type 1) needs to be reported, but if
the problem is that the incoming interface cannot be the problem is that the incoming interface cannot be
connected to the outgoing interface because of temporary connected to the outgoing interface because of temporary
or permanent cross-connect limitations, the node should or permanent cross-connect limitations, the node should
also include reference to the incoming interface (for also include reference to the incoming interface (for
example, TLV type 18). example, TLV type 18).
Some TLVs help to locate the fault within the context of
the path of the LSP that was being set up. TLVs of types
14, 15, 16 and 17 help 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
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 non-specific abstract node) and
deduce that its upstream neighbor may have selected the
path using next hop routing. In this case, providing the
ERO context will be useful to the node further that
performs re-routing.
Four TLVs (27, 28, 29 and 30) allow the location of the Four TLVs (27, 28, 29 and 30) allow the location of the
reporting node to be expanded upon. These TLVs would not reporting node to be expanded upon. These TLVs would not
be included if the information is not of use within the be included if the information is not of use within the
local system, but might be added by ABRs relaying the local system, but might be added by ABRs relaying the
error. Note that the Reporting Node Id (TLV 27) need not error. Note that the Reporting Node Id (TLV 27) need not
be included if the IP address of the reporting node as be included if the IP address of the reporting node as
indicated in the Error Spec itself, is sufficient to indicated in the ERROR_SPEC itself, is sufficient to
fully identify the node. fully identify the node.
The last three TLVs (31, 32, and 33) provide additional The last three TLVs (31, 32, and 33) provide additional
information for recomputation points. The reporting node information for recomputation points. The reporting node
(or some node forwarding the error) may supply (or some node forwarding the error) may supply
suggestions about the ERO that could have been used to suggestions about the ERO that could have been used to
avoid the error. As the error propagates back upstream avoid the error. As the error propagates back upstream
and as crankback routing is attempted and fails, it is and as crankback routing is attempted and fails, it is
beneficial to collect lists of failed nodes and links so beneficial to collect lists of failed nodes and links so
that they will not be included in further computations that they will not be included in further computations
skipping to change at line 1075 skipping to change at line 992
Note that there is no ordering requirement on any of the Note that there is no ordering requirement on any of the
TLVs within the IF_ID Error Spec, and no implication TLVs within the IF_ID Error Spec, and no implication
should be drawn from the ordering of the TLVs in a should be drawn from the ordering of the TLVs in a
received IF_ID Error Spec. received IF_ID Error Spec.
It is left as an implementation detail precisely when to It is left as an implementation detail precisely when to
include each of the TLVs according to the capabilities of include each of the TLVs according to the capabilities of
the system reporting the error. the system reporting the error.
7.2.2 Alternate Path identification 7.3.5 Grouping TLVs by Failure Location
No new object is used to distinguish between Path/Resv Further guidance as to the inclusion of crankback TLVs can be given
messages for an alternate LSP. Thus, the alternate LSP by grouping the TLVs according to the location of the failure and
uses the same SESSION and SENDER_TEMPLATE/FILTER_SPEC the context within which it is reported. For example, a TLV that
objects as the ones used for the initial LSP under re- reports an area identifier would only need to be included as the
routing. crankback error report transits an area boundary.
7.3. Action on Receiving Crankback Information 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.
7.3.1 Re-route Attempts Resource Failure
8 DOWNSTREAM_LABEL
9 UPSTREAM_LABEL
Interface failures
1 IPv4
2 IPv6
3 IF_INDEX
4 COMPONENT_IF_DOWNSTREAM
5 COMPONENT_IF_UPSTREAM
6 UNUM_COMPONENT_IF_DOWN
7 UNUM_COMPONENT_IF_UP
14 ERO_CONTEXT
15 ERO_NEXT_CONTEXT
16 PREVIOUS_HOP_IPv4
17 PREVIOUS_HOP_IPv6
18 INCOMING_IPv4
19 INCOMING_IPv6
20 INCOMING_IF_INDEX
21 INCOMING_COMP_IF_DOWN
22 INCOMING_COMP_IF_UP
23 INCOMING_UNUM_COMP_DOWN
24 INCOMING_UNUM_COMP_UP
25 INCOMING_DOWN_LABEL
26 INCOMING_UP_LABEL
Node failures
10 NODE_ID
27 REPORTING_NODE_ID
Area failures
11 OSPF_AREA
12 ISIS_AREA
28 REPORTING_OSPF_AREA
29 REPORTING_ISIS_AREA
31 PROPOSED_ERO
32 NODE_EXCLUSIONS
33 LINK_EXCLUSIONS
AS failures
13 AUTONOMOUS_SYSTEM
30 REPORTING_AS
As described in section 3, a node receiving crankback 7.3.6 Alternate Path identification
information in a PathErr must first check to see whether
it is allowed to perform re-routing. This is indicated by No new object is used to distinguish between Path/Resv messages
the Re-routing Flags in the SESSION_ATTRIBUTE object for an alternate LSP. Thus, the alternate LSP uses the same
during LSP setup request. SESSION and SENDER_TEMPLATE/FILTER_SPEC objects as the ones used
for the initial LSP under re-routing.
7.4. Action on Receiving Crankback Information
7.4.1 Re-route Attempts
As described in section 3, a node receiving crankback information
in 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 SESSION_ATTRIBUTE object during LSP setup request.
If a node is not allowed to perform re-routing it should If a node is not allowed to perform re-routing it should
forward the PathErr message, or if it is the ingress forward the PathErr message, or if it is the ingress
report the LSP as having failed. report the LSP as having failed.
If re-routing is allowed, the node should attempt to If re-routing is allowed, the node should attempt to compute a path
compute a path to the destination using the original to the destination using the original (received) explicit path and
(received) explicit path and excluding the failed/blocked excluding the failed/blocked node/link. The new path should be added
node/link. The new path should be added to an LSP setup to an LSP setup request as an explicit route and signaled.
request as an explicit route and signaled.
LSRs performing crankback re-routing should store all received LSRs performing crankback re-routing should store all received
crankback information for an LSP until the LSP is successfully crankback information for an LSP until the LSP is successfully
established or until the node abandons its attempts to re-route established or until the node abandons its attempts to re-route
the LSP. This allows the combination of crankback information the LSP. This allows the combination of crankback information
from multiple failures when computing an alternate path. from multiple failures when computing an alternate path.
It is an implementation decision whether the crankback It is an implementation decision whether the crankback
information is discarded immediately upon successful LSP information is discarded immediately upon successful LSP
establishment or retained for a period in case the LSP fails. establishment or retained for a period in case the LSP fails.
7.3.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- In order to compute an alternate path by crankback re-
routing, it is necessary to identify the blocked links or routing, it is necessary to identify the blocked links or
nodes and their locations. The common identifier of each nodes and their locations. The common identifier of each
link or node in an MPLS network should be specified. Both link or node in an MPLS network should be specified. Both
protocol-independent and protocol- dependent identifiers protocol-independent and protocol- dependent identifiers
may be specified. Although a general identifier that is may be specified. Although a general identifier that is
independent of other protocols is preferable, there are a independent of other protocols is preferable, there are a
couple of restrictions on its use as described in the couple of restrictions on its use as described in the
following subsection. following subsection.
skipping to change at line 1145 skipping to change at line 1110
setup request must have been set to show support for setup request must have been set to show support for
boundary or segment-based re-routing. boundary or segment-based re-routing.
In this document, we specify routing protocol specific In this document, we specify routing protocol specific
link and node identifiers for OSPFv2 for IPv4, IS-IS for link and node identifiers for OSPFv2 for IPv4, IS-IS for
IPv4, OSPF for IPv6, and IS-IS for IPv6. These IPv4, OSPF for IPv6, and IS-IS for IPv6. These
identifiers may only be used if segment-based re-routing identifiers may only be used if segment-based re-routing
is supported, as indicated by the Routing Behavior flag is supported, as indicated by the Routing Behavior flag
on the LSP setup request. on the LSP setup request.
7.3.3 Locating Errors within Loose or Abstract Nodes 7.4.3 Locating Errors within Loose or Abstract Nodes
The explicit route on the original LSP setup request may The explicit route on the original LSP setup request may
contain a loose or an Abstract Node. In these cases, the contain a loose or an Abstract Node. In these cases, the
crankback information may refer to links or nodes that crankback information may refer to links or nodes that
were not in the original explicit route. were not in the original explicit route.
In order to compute a new path, the repair point may need In order to compute a new path, the repair point may need
to identify the pair of hops (or nodes) in the explicit to identify the pair of hops (or nodes) in the explicit
route between which the error/blockage occurred. route between which the error/blockage occurred.
To assist this, the crankback information reports the top To assist this, the crankback information reports the top
two hops of the explicit route as received at the two hops of the explicit route as received at the
reporting node. The first hop will likely identify the reporting node. The first hop will likely identify the
node or the link, the second hop will identify a 'next' node or the link, the second hop will identify a 'next'
hop from the original explicit route. hop from the original explicit route.
7.3.4 When Re-routing Fails 7.4.4 When Re-routing Fails
When a node cannot or chooses not to perform crankback re- When a node cannot or chooses not to perform crankback re-
routing it must forward the PathErr message further upstream. routing it must forward the PathErr message further upstream.
However, when a node was responsible for expanding or However, when a node was responsible for expanding or
replacing the explicit route as the LSP setup was replacing the explicit route as the LSP setup was
processed it MUST update the crankback information with processed it MUST update the crankback information with
regard to the explicit route that it received. Only if regard to the explicit route that it received. Only if
this is done will the upstream nodes stand a chance of this is done will the upstream nodes stand a chance of
successfully routing around the problem. successfully routing around the problem.
7.3.5 Aggregation of Crankback Information 7.4.5 Aggregation of Crankback Information
When a setup blocking error or an error in an established When a setup blocking error or an error in an established
LSP occurs and cranback information is sent in an error LSP occurs and crankback information is sent in an error
notification message, some node upstream may choose to notification message, some node upstream may choose to
attempt crankback re-routing. If that node's attempts at attempt crankback re-routing. If that node's attempts at
re-routing fail the node will accumulate a set of failure re-routing fail the node will accumulate a set of failure
information. When the node gives up it must propagate the information. When the node gives up it must propagate the
failure message further upstream and include crankback failure message further upstream and include crankback
information when it does so. information when it does so.
There is not scope in the protocol extensions described There is not scope in the protocol extensions described
in this document to supply a full list of all of the in this document to supply a full list of all of the
failures that have occurred. Such a list would be failures that have occurred. Such a list would be
skipping to change at line 1200 skipping to change at line 1165
links and nodes to be accumulated as the failure is links and nodes to be accumulated as the failure is
passed back upstream. passed back upstream.
Aggregation may involve reporting all links from a node Aggregation may involve reporting all links from a node
as unusable by flagging the node as unusable, or flagging as unusable by flagging the node as unusable, or flagging
an ABR as unusable when there is no downstream path an ABR as unusable when there is no downstream path
available, and so on. The precise details of how available, and so on. The precise details of how
aggregation of crankback information is performed are aggregation of crankback information is performed are
beyond the scope of this document. beyond the scope of this document.
7.4. Notification of Errors 7.5. Notification of Errors
7.4.1 ResvErr Processing 7.5.1 ResvErr Processing
As described above, the resource allocation failure for As described above, the resource allocation failure for
RSVP-TE may occur on the reverse path when the Resv RSVP-TE may occur on the reverse path when the Resv
message is being processed. In this case, it is still message is being processed. In this case, it is still
useful to return the received crankback information to useful to return the received crankback information to
the ingress LSR. However, when the egress LSR receives the ingress LSR. However, when the egress LSR receives
the ResvErr message, per RFC 2205 it still has the option the ResvErr message, per RFC 2205 it still has the option
of re-issuing the Resv with different resource of re-issuing the Resv with different resource
requirements (although not on an alternate path). requirements (although not on an alternate path).
skipping to change at line 1228 skipping to change at line 1193
have failed, it SHOULD generate a PathErr message carrying have failed, it SHOULD generate a PathErr message carrying
the crankback information and send it to the ingress LSR. the crankback information and send it to the ingress LSR.
If a ResvErr reports on more than one FILTER_SPEC If a ResvErr reports on more than one FILTER_SPEC
(because the Resv carried more than one FILTER_SPEC) then (because the Resv carried more than one FILTER_SPEC) then
only one set of crankback information should be present only one set of crankback information should be present
in the ResvErr and it should apply to all FILTER_SPEC in the ResvErr and it should apply to all FILTER_SPEC
carried. In this case, it may be necessary per [RFC 2205] carried. In this case, it may be necessary per [RFC 2205]
to generate more than one PathErr. to generate more than one PathErr.
7.4.2 Notify Message Processing 7.5.2 Notify Message Processing
[RFC3473] defines the Notify message to enhance error [RFC3473] defines the Notify message to enhance error
reporting in RSVP-TE networks. This message is not reporting in RSVP-TE networks. This message is not
intended to replace the PathErr and ResvErr messages. The intended to replace the PathErr and ResvErr messages. The
Notify message is sent to addresses requested on the Path Notify message is sent to addresses requested on the Path
and Resv messages. These addresses could (but need not) and Resv messages. These addresses could (but need not)
identify the ingress and egress LSRs respectively. identify the ingress and egress LSRs respectively.
When a network error occurs, such as the failure of link When a network error occurs, such as the failure of link
hardware, the LSRs that detect the error MAY send Notify hardware, the LSRs that detect the error MAY send Notify
messages to the requested addresses. The type of error messages to the requested addresses. The type of error
that causes a Notify message to be sent is an that causes a Notify message to be sent is an
implementation detail. implementation detail.
In the event of a failure, an LSR that supports [RFC3473] In the event of a failure, an LSR that supports [RFC3473]
and the crankback extensions defined in this document MAY and the crankback extensions defined in this document MAY
choose to send a Notify message carrying crankback choose to send a Notify message carrying crankback
information. This would ensure a speedier report of the information. This would ensure a speedier report of the
error to the ingress/egress LSRs. error to the ingress/egress LSRs.
7.5. Error Values 7.6. Error Values
Error values for the Error Code "Admission Control Error values for the Error Code "Admission Control
Failure" are defined in [RFC2205]. Error values for the Failure" are defined in [RFC2205]. Error values for the
error code "Routing Problem" are defined in [RFC 3209] error code "Routing Problem" are defined in [RFC 3209]
and [RFC 3473]. and [RFC 3473].
A new error value is defined for the error code "Routing A new error value is defined for the error code "Routing
Problem". "Re-routing limit exceeded" indicates that re- Problem". "Re-routing limit exceeded" indicates that re-
routing has failed because the number of crankback re- routing has failed because the number of crankback re-
routing attempts has gone beyond the predetermined routing attempts has gone beyond the predetermined
threshold at an individual LSR. threshold at an individual LSR.
7.6. Backward Compatibility 7.7. Backward Compatibility
It is recognized that not all nodes in an RSVP-TE network It is recognized that not all nodes in an RSVP-TE network
will support the extensions defined in this document. It will support the extensions defined in this document. It
is important that an LSR that does not support these is important that an LSR that does not support these
extensions can continue to process a PathErr, ResvErr or extensions can continue to process a PathErr, ResvErr or
Notify message even if it carries the newly defined IF_ID Notify message even if it carries the newly defined IF_ID
ERROR_SPEC information (TLVs). ERROR_SPEC information (TLVs).
8. Routing Protocol Interactions 8. Routing Protocol Interactions
skipping to change at line 1348 skipping to change at line 1313
message is returned all the way back to the ingress LSR, message is returned all the way back to the ingress LSR,
which may then issue a new Path message along another which may then issue a new Path message along another
path, which is the same procedure as in the flat network path, which is the same procedure as in the flat network
case above. case above.
If the Flags field indicates Boundary re-routing, the If the Flags field indicates Boundary re-routing, the
ingress area border LSR MAY terminate the PathErr message ingress area border LSR MAY terminate the PathErr message
and then perform alternate routing within the area for and then perform alternate routing within the area for
which the area border LSR is the ingress LSR. which the area border LSR is the ingress LSR.
If the Flags field indicates segment-based re-routing, If the Flags field indicates segment-based re-routing, any node
any node MAY apply the procedures described above for MAY apply the procedures described above for Boundary re-routing.
Boundary re-routing.
9.2. Downstream of the Fault 9.2. Downstream of the Fault
This section only applies to errors that occur after an This section only applies to errors that occur after an
LSP has been established. Note that an LSR that generates LSP has been established. Note that an LSR that generates
a PathErr with Path_State_Remove Flag SHOULD also send a a PathErr with Path_State_Remove Flag SHOULD also send a
PathTear downstream to clean up the LSP. PathTear downstream to clean up the LSP.
A node that detects a fault and is downstream of the A node that detects a fault and is downstream of the
fault MAY send a PathErr or Notify message containing an fault MAY send a PathErr or Notify message containing an
skipping to change at line 1393 skipping to change at line 1357
A new error value is defined for the RSVP-TE "Routing A new error value is defined for the RSVP-TE "Routing
Problem" error code that is defined in [RFC3209]. Problem" error code that is defined in [RFC3209].
TBD Re-routing limit exceeded. TBD Re-routing limit exceeded.
10.2 IF_ID_ERROR_SPEC TLVs 10.2 IF_ID_ERROR_SPEC TLVs
Note that the IF_ID_ERROR_SPEC TLV type values are not Note that the IF_ID_ERROR_SPEC TLV type values are not
currently tracked by IANA. This might be a good currently tracked by IANA. This might be a good
opportunity to move them under IANA control. opportunity to move them under IANA control. The values
proposed by this document are found in section 7.2.
10.3 LSP_ATTRIBUTES Object 10.3 LSP_ATTRIBUTES Object
Three bits are defined for inclusion in the LSP Three bits are defined for inclusion in the LSP Attributes TLV of
Attributes TLV of the LSP_ATTRIBUTES object. IANA is the LSP_ATTRIBUTES object in section 6.4. Suggested values are
requested to assign those bits. supplied. IANA is requested to assign those bits.
11. Security Considerations 11. Security Considerations
It should be noted that while the extensions in this It should be noted that while the extensions in this document
document introduce no new security holes in the introduce no new security holes in the protocols, should a malicious
protocols, should a malicious user gain protocol access user gain protocol access to the network, the crankback information
to the network, the crankback information might be used might be used to prevent establishment of valid LSPs.
to prevent establishment of valid LSPs.
The implementation of re-routing attempt thresholds are The implementation of re-routing attempt thresholds are
particularly important in this context. particularly important in this context.
The crankback routing extensions and procedures for LSP The crankback routing extensions and procedures for LSP restoration
restoration as applied to RSVP-TE introduce no further as applied to RSVP-TE introduce no further new security
new security considerations. Refer to [RFC2205], considerations. Refer to [RFC2205], [RFC3209] and [RFC3473] for a
[RFC3209] and [RFC3473] for a description of applicable description of applicable security considerations.
security considerations.
12. Acknowledgments 12. Acknowledgments
We would like to thank Juha Heinanen and Srinivas Makam We would like to thank Juha Heinanen and Srinivas Makam
for their review and comments, and Zhi-Wei Lin for his for their review and comments, and Zhi-Wei Lin for his
considered opinions. Thanks, too, to John Drake for considered opinions. Thanks, too, to John Drake for
encouraging us to resurrect this document and consider encouraging us to resurrect this document and consider
the use of the IF-ID ERROR SPEC object. Thanks for a the use of the IF-ID ERROR SPEC object. Thanks for a
welcome and very thorough review by Dimitri Papadimitriou. welcome and very thorough review by Dimitri Papadimitriou.
skipping to change at line 1451 skipping to change at line 1414
be obtained from the IETF Secretariat. be obtained from the IETF Secretariat.
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 which may cover technology that may be required to practice rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive this standard. Please address the information to the IETF Executive
Director. Director.
14. Normative References 14. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
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.
[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.
skipping to change at line 1474 skipping to change at line 1440
[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-00.txt, December 2003, draft-ietf-mpls-rsvpte-attributes-00.txt, December 2003,
work in progress. work in progress.
[ASON-REQ] D. Papadimitriou, J. Drake, J. Ash, A. Farrel, L. Ong, [ASON-REQ] D. Papadimitriou, J. Drake, J. Ash, A. Farrel, L. Ong,
"Requirements for Generalized MPLS (GMPLS) Signaling "Requirements for Generalized MPLS (GMPLS) Signaling
Usage and Extensions for Automatically Switched Optical Usage and Extensions for Automatically Switched Optical
Network (ASON)", daft-ietf-ccamp-gmpls-ason-reqts-03.txt Network (ASON)", daft-ietf-ccamp-gmpls-ason-reqts-05.txt
October 2003, work in progress. November 2003, work in progress.
15. Informational References 15. Informational References
[ASH1] G. Ash, ITU-T Recommendations E.360.1 --> E.360.7, "QoS [ASH1] G. Ash, ITU-T Recommendations E.360.1 --> E.360.7, "QoS
Routing & Related Traffic Engineering Methods for IP-, Routing & Related Traffic Engineering Methods for IP-,
ATM-, & TDM-Based Multiservice Networks", May, 2002. ATM-, & TDM-Based Multiservice Networks", May, 2002.
[FASTRR] Ping Pan, et al., "Fast Reroute Extensions to RSVP-TE [FASTRR] Ping Pan, et al., "Fast Reroute Extensions to RSVP-TE
for LSP Tunnels", draft-ietf-mpls-rsvp-lsp-fastreroute- for LSP Tunnels", draft-ietf-mpls-rsvp-lsp-fastreroute-
03.txt, July 2003 (work in progress). 03.txt, July 2003 (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. 2001.
[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", draft-ietf-ccamp-rsvp-te-exclude- Extension to RSVP-TE", draft-ietf-ccamp-rsvp-te-exclude-
route-00.txt, June 2003 (work in progress). route-01.txt, December 2003 (work in progress).
[PNNI] ATM Forum, "Private Network-Network Interface [PNNI] ATM Forum, "Private Network-Network Interface
Specification Version 1.0 (PNNI 1.0)", <af-pnni- Specification Version 1.0 (PNNI 1.0)", <af-pnni-
0055.000>, May 1996. 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.
[INTER-AS] JP. Vasseur, and R. Zhang, "Inter-AS MPLS Traffic [INTER-AS] JP. Vasseur and R. Zhang, "Inter-AS MPLS Traffic
Engineering", draft-vasseur-inter-as-te-01.txt, June Engineering", draft-vasseur-inter-as-te-01.txt, June
2003, work in progress. 2003, work in progress.
[IFID_UNNUM] A. Farrel and A. Satyanarayana, "Identification of
Component Links of Unnumbered Interfaces", draft-farrel-
ccamp-ifid-unnum-00.txt, January 2004, work in progress.
16. Authors' Addresses 16. Authors' Addresses
Adrian Farrel (editor) Adrian Farrel (editor)
Old Dog Consulting Old Dog Consulting
Phone: +44 (0) 1978 860944 Phone: +44 (0) 1978 860944
EMail: adrian@olddog.co.uk EMail: adrian@olddog.co.uk
Arun Satyanarayana Arun Satyanarayana
Movaz Networks, Inc. Movaz Networks, Inc.
7926 Jones Branch Drive, Suite 615 7926 Jones Branch Drive, Suite 615
McLean, VA 22102 McLean, VA 22102
Phone: (+1) 703-847-1785 Phone: (+1) 703-847-1785
EMail: aruns@movaz.com EMail: aruns@movaz.com
Atsushi Iwata Atsushi Iwata
NEC Corporation NEC Corporation
Networking Research Laboratories Networking Research Laboratories
skipping to change at line 1552 skipping to change at line 1523
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
Simon Marshall-Unitt Simon Marshall-Unitt
Data Connection Ltd. Data Connection Ltd.
100 Church Street 100 Church Street
Enfield, Middlesex Enfield, Middlesex, EN2 6BQ, UK
EN2 6BQ, UK
Phone: (+44) (0)-208-366-1177 Phone: (+44) (0)-208-366-1177
EMail: smu@dataconnection.com EMail: smu@dataconnection.com
17. Full Copyright Statement Appendix A. Experience of Crankback in TDM-based Networks
Copyright (c) The Internet Society (2003). All Rights Experience of using release messages in TDM-based networks for
analogous repair and re-routing purposes provides some guidance.
One can use the receipt of a release message with a cause value (CV)
indicating "link congestion" to trigger a re-routing attempt at the
originating node. However, this sometimes leads to problems.
*--------------------* *-----------------*
| | | |
| N2 ----------- N3-|--|----- AT--- EO2 |
| | | \| | / | |
| | | |--|- / | |
| | | | | \/ | |
| | | | | /\ | |
| | | |--|- \ | |
| | | /| | \ | |
| N1 ----------- N4-|--|----- EO1 |
| | | |
*--------------------* *-----------------*
A-1 A-2
Figure 1. Example of network topology
Figure 1 illustrates four examples based on service-provider
experiences with respect to crankback (i.e., explicit indication)
versus implicit indication through a release with CV. In this
example, N1, N2,N3, and N4 are located in one area (A-1), and AT,
EO1, and EO2 are in another area (A-2).
Note that two distinct areas are used in this example to expose the
issues clearly. In fact, the issues are not limited to multi-area
networks, but arise whenever path computation is distributed
throughout the network. For example where loose routes, AS routes or
path computation domains are used.
1. A connection request from node N1 to EO1 may route to N4 and then
find "all circuits busy". N4 returns a release message to N1 with
CV34 indicating all circuits busy. Normally, a node such as N1 is
programmed to block a connection request when receiving CV34,
although there is good reason to try to alternate route the
connection request via N2 and N3.
Some service providers have implemented a technique called route
advance (RA), where if a node that is RA capable receives a
release message with CV34, it will use this as an implicit
re-route indication and try to find an alternate route for the
connection request if possible. In this example, alternate route
N1-N2-N3-EO1 can be tried and may well succeed.
2. Suppose a connection request goes from N2 to N3 to AT trying to
reach EO2 and is blocked at link AT-EO2. Node AT returns a CV34
and with RA, N2 may try to re-route N2-N1-N4-AT-EO2, but of
course this fails again. The problem is that N2 does not realize
where this blocking occurred based on the CV34, and in this case
there is no point in further alternate routing.
3. However, in another case of a connection request from N2 to E02,
suppose that link N3-AT is blocked. In this case N3 should return
crankback information (and not CV34) so that N2 can alternate
route to N1-N4-AT-EO2, which may well be successful.
4. In a final example, for a connection request from EO1 to N2, EO1
first tries to route the connection request directly to N3.
However, node N3 may reject the connection request even if there
is bandwidth available on link N3-EO1 (perhaps for priority
routing considerations, e.g., reserving bandwidth for high
priority connection requests). However, when N3 returns CV34 in
the release message, EO1 blocks the connection request (a normal
response to CV34 especially if E01-N4 is already known blocked)
rather than trying to alternate route through AT-N3-N2, which
might be successful. If N3 returns crankback information, EO1
could respond by trying the alternate route.
It is certainly the case that with topology exchange, such as OSPF,
the ingress LSR could infer the re-routing condition. However,
convergence of routing information 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
efficiently use local state information to direct alternate routing
at the ingress-LSR.
[ASH1] shows how event-dependent-routing can just use crankback,
and not available-link-bandwidth flooding, to decide on the re-
route path in the network through "learning models". Reducing
this flooding reduces overhead and can lead to the ability to
support much larger AS sizes.
Therefore, the alternate routing should be indicated based on
an explicit indication (as in examples 3 and 4), and it is best
to know the following information separately:
a) where blockage/congestion occurred (as in examples 1-2),
and
b) whether alternate routing "should" be attempted even if
there is no "blockage" (as in example 4).
Full Copyright Statement
Copyright (c) The Internet Society (2004). All Rights
Reserved. This document and translations of it may be Reserved. This document and translations of it may be
copied and furnished to others, and derivative works that copied and furnished to others, and derivative works that
comment on or otherwise explain it or assist in its comment on or otherwise explain it or assist in its
implementation may be prepared, copied, published and implementation may be prepared, copied, published and
distributed, in whole or in part, without restriction of distributed, in whole or in part, without restriction of
any kind, provided that the above copyright notice and any kind, provided that the above copyright notice and
this paragraph are included on all such copies and this paragraph are included on all such copies and
derivative works. However, this document itself may not derivative works. However, this document itself may not
be modified in any way, such as by removing the copyright be modified in any way, such as by removing the copyright
notice or references to the Internet Society or other notice or references to the Internet Society or other
 End of changes. 

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