One document matched: draft-iwata-mpls-crankback-05.txt
Differences from draft-iwata-mpls-crankback-04.txt
MPLS Working Group Adrian Farrel (editor)
Internet Draft Movaz Networks, Inc.
Document: draft-iwata-mpls-crankback-05.txt
Expiration Date: September 2003 Atsushi Iwata
Norihito Fujita
NEC Corporation
Gerald R. Ash
AT&T
Simon Marshall-Unitt
Data Connection Ltd.
March 2003
Crankback Routing Extensions for MPLS Signaling
<draft-iwata-mpls-crankback-05.txt>
Status of this Memo
This document is an Internet-Draft and is in full
conformance with all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet
Engineering Task Force (IETF), its areas, and its working
groups. Note that other groups may also distribute
working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum
of six months and may be updated, replaced, or obsoleted
by other documents at any time. It is inappropriate to
use Internet-Drafts as reference material or to cite them
other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be
accessed at http://www.ietf.org/shadow.html.
Abstract
Recently, several routing protocol extensions for
advertising resource information in addition to topology
information have been proposed for use in distributed
constraint-based routing. In such a distributed routing
environment, however, the information used to compute a
constraint-based path may be out of date. This means
that LSP setup requests may be blocked by links or nodes
without sufficient resources.
This draft specifies crankback routing extensions for use
in Multi-Protocol Label Switching (MPLS) signaling using
RSVP-TE as defined in "RSVP-TE: Extensions to RSVP for
LSP Tunnels", RFC3209, so that the LSP setup request can
be retried on an alternate path that detours around the
blocked link or node upon a setup failure.
Iwata, et al. draft-iwata-mpls-crankback-05.txt [Page 1]
Internet Draft March 2003
Furthermore, crankback routing schemes can also be
applied to LSP restoration by indicating the location of
the failure link or node. This would significantly
improve the successful recovery ratio for failed LSPs,
especially in situations where a large number of setup
requests are triggered at the same time.
Crankback has been identified by the ITU-T as requirement
for the Automatically Switched Optical Network (ASON) and
should be added to the GMPLS signaling protocols to meet
this requirement.
Table of Contents
1. Summary for Sub-IP Area 3
1.1. Summary 3
1.2. Related documents 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. Changes and Further Work 4
2.1. Changes from the Previous Version 4
2.2. Future Work 4
3. Introduction 4
4. Explicit Versus Implicit Rerouting Indications 6
5. Overview of Crankback Function 8
6. Existing Support for Crankback Rerouting 10
6.1. RSVP-TE 10
6.2. GMPLS 10
6.3. Information Required for Rerouting 10
6.4. Signaling a New Route 11
7. MPLS Signaling Protocol Independent Information and Procedures 11
7.1. Requesting Crankback and Controlling In-Network Rerouting 11
7.2. Action on Detecting a Failure 12
7.3. Required Information 12
7.3.1 Link TLV 13
7.3.2 Node TLV 16
7.4. Action on Receiving Crankback Information 17
7.4.1 Reroute Attempts 17
7.4.2 Location Identifiers of Blocked Links or Nodes 18
7.4.3 Locating Errors within Loose or Abstract Nodes 18
7.4.4 When Rerouting Fails 19
7.5. Limiting Rerouting Attempts 19
7.5.1 New Status Codes for Rerouting 19
8. RSVP-TE Extensions for Crankback 19
8.1. Overview 19
8.1.1 ResvErr Processing 20
8.1.2 Notify Message Processing 21
8.2. Indication of Rerouting Behavior 21
8.3. Rerouting Object 23
8.4. Error Values 24
8.5. Backward Compatibility 24
9. Routing Protocol Interactions 25
10. LSP Restoration Considerations 25
10.1. Upstream of the Fault 25
10.2. Downstream of the Fault 26
Iwata, et al. draft-iwata-mpls-crankback-05.txt [Page 2]
Internet Draft March 2003
11. Security Considerations 27
11.1. RSVP-TE 27
12. Acknowledgments 27
13. Normative References 27
14. Informational References 28
15. Authors' Addresses 28
16. Full Copyright Statement 29
1. Summary for Sub-IP Area
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).
1.2. Related documents
See the Reference Section
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. This draft extends the
MPLS signaling protocols. At past IETF gatherings it has
been suggested that this draft might equally be handled
by the CCAMP WG. We await further direction from the WG
chairs and the ADs.
1.5. Justification
Crankback Routing is a requirement in large and multi-
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 Switched Optical Network (ASON) has been
identified by the ITU-T. It is therefore appropriate to
consider if and how GMPLS can be extended to provide the
function.
Iwata, et al. draft-iwata-mpls-crankback-05.txt [Page 3]
Internet Draft March 2003
2. Changes and Further Work
This section to be removed before the draft progresses to
RFC.
2.1. Changes from the Previous Version
The main changes are:
- minor typographical
- retirement of all references to CR-LDP
- additional work items to consider changing signaling
mechanisms to utilize the IF-ID ErrorSpec present in
[GMPLS-RSVP]
- update references.
2.2. Future Work
The following work items have been identified.
- Extend crankback information to allow it to report on
individual links from bundles, labels and specific
resources.
- Provide a mechanism to limit the number of rerouting
attempts that should be made in total, within an area and at
an individual node.
- Add and explain methods for controlling which nodes in a
network and on an LSP may make rerouting attempts.
- The final versions of [GMPLS-RSVP] introduced the IF-ID
ErrorSpec where failure information beyond the basic failure
reason and reporting node id can be included in TLVs within
the ErrorSpec object in a PathErr, ResvErr or notify
message. This mechanism is ideal for the propagation of
crankback failure information. It is likely that this
document will be updated to use that mechanism rather than
the one currently described.
3. Introduction
RSVP-TE (RSVP Extensions for LSP Tunnel) [RSVP-TE] can be
used for establishing explicitly routed LSPs in an MPLS
network. Using RSVP-TE, resources can also be reserved
along a path to guarantee or control QoS for traffic
carried on the LSP. To designate an explicit path that
satisfies QoS constraints, it is necessary to discern the
resources available to each link or node in the network.
For the collection of such resource information, routing
protocols, such as OSPF [OSPF] and IS-IS [ISIS], can be
extended to distribute additional state information
[AWDUCHE1].
Iwata, et al. draft-iwata-mpls-crankback-05.txt [Page 4]
Internet Draft March 2003
Explicit paths can be computed based on the distributed
information at the LSR initiating a LSP and signaled as
Explicit Routes during LSP establishment. Explicit
Routes may contain 'loose hops' and 'abstract nodes' that
convey routing through any of a collection of nodes.
This mechanism may be used to devolve parts of the path
computation to intermediate nodes such as area border
LSRs.
In a distributed routing environment, however, the
resource information used to compute a constraint-based
path may be out of date. This means that a setup request
may be blocked, for example, because a link or node along
the selected path has insufficient resources.
In RSVP-TE, a blocked LSP setup may result in a PathErr
message sent to the initiator or a ResvErr sent to the
terminator (egress LSR). These messages may result in
the LSP setup being abandoned. In Generalized MPLS
[GMPLS-RSVP] the Notify message can be used in RSVP-TE
networks to expedite notification of LSP failures to
ingress and egress LSRs, or to a specific "repair point".
These existing mechanisms provide a certain amount of
information about the path of the failed LSP.
If the ingress LSR or intermediate area border LSR knows
the location of the blocked link or node, the LSR can
designate an alternate path and then reissue the setup
request, which can be achieved by the mechanism known as
crankback routing [PNNI, ASH1]. We propose the use of
crankback routing in RSVP-TE. Crankback routing requires
notifying an upstream LSR of the location of the blocked
link or node. In some cases this requires more
information than is currently available in the signaling
protocols.
On the other hand, various restoration schemes for link
or node failures have been proposed in [MAKAM, SHARMA]
and others. Fast restoration by pre-establishing a
backup LSP is useful for failures on a primary LSP. If
both the primary and backup paths fail, however, it is
necessary to reestablish the LSP on an end-to-end basis.
End-to-end restoration for alternate routing requires the
location of the failed link or node. Crankback routing
schemes could also be used to notify upstream LSRs of the
location of the failure.
Furthermore, in situations where many link or node
failures occur at the same time, the difference between
the distributed routing information and the real-time
network state becomes much greater than in normal LSP
setups. LSP restoration must therefore be performed with
inaccurate information, which is likely to cause setup
blocking. Crankback routing would improve failure
recovery in these situations.
Iwata, et al. draft-iwata-mpls-crankback-05.txt [Page 5]
Internet Draft March 2003
Generalized MPLS [GMPLS] extends MPLS into networks that
manage TDM and lambda resources. In a network without
wavelength converters, setup requests are likely to be
blocked more often than in a conventional MPLS
environment because the same wavelength must be allocated
at each OXC on an end-to-end explicit path. Furthermore,
end-to-end restoration is the only way to recover LSP
failures. This implies that crankback routing would also
be useful in an GMPLS network.
Crankback has been identified by the ITU-T as requirement
for the Automatically Switched Optical Network (ASON)
[G8080] and should be added to the GMPLS signaling
protocols to meet this requirement.
Once crankback information has been supplied to the
repair point, it may compute a new path to route around
the problem. It may be, however, that the repair point
does not have sufficient topology information to compute
an Explicit Route that is guaranteed to avoid the failed
link or node. In this case, Route Exclusions [LEE] may
be particularly helpful. That is, when computing a path
loose hops and abstract nodes may be used, and [LEE]
offers the opportunity to use route exclusions to force
avoidance of the failed node, link or resource.
This draft proposes a crankback routing system that is an
extension of RSVP-TE and discusses the identification of
blocked links or nodes in an MPLS network.
4. Explicit Versus Implicit Rerouting Indications
There have been problems in service provider networks
when "inferring" from indirect information that rerouting
is allowed. In the case of using an explicit rerouting
indication, rerouting is explicitly authorized and not
inferred.
Various protocol options and exchanges including the
error values of PathErr message [RSVP, RSVP-TE] and the
Notify message [GMPLS-RSVP] allow an implementation to
infer a situation where rerouting can be done. This
allows for recovery from network errors or resource
contention.
However, such inference of recovery signaling is not
always desirable since it may be doomed to failure.
Experience of using release messages in TDM-based
networks for analogous purposes provides some guidance.
One can use the receipt of a release message with a cause
value (CV) indicating "link congestion" (a CV already
standardized in ISUP, for example) to trigger a rerouting
attempt at the originating node. However, this sometimes
leads to problems.
Iwata, et al. draft-iwata-mpls-crankback-05.txt [Page 6]
Internet Draft March 2003
*--------------------* *-----------------*
| | | |
| N2 ----------- N3-|--|----- AT--- EO2 |
| | | \| | / | |
| | | |--|- / | |
| | | | | \/ | |
| | | | | /\ | |
| | | |--|- \ | |
| | | /| | \ | |
| N1 ----------- N4-|--|----- EO1 |
| | | |
*--------------------* *-----------------*
AS-1 AS-2
Figure 1. Example of network topology
Figure 1 is illustrates five examples based on service-
provider experiences with respect to crankback (i.e.,
explicit indication) versus implicit indication through
release/CV, or "no bandwidth available" (NBA). In this
example, N1, N2,N3, and N4 are located in one area (AS-
1), and AT, EO1, and EO2 are in another area (AS-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" (equivalent to NBA). N4
returns a release message to N1 with cause value (CV) 34
(indicates all circuits busy/NBA). 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 then it will 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. Now 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, however N2 will not realize where this
blocking occurred based on the CV34, and in this case there
is no point in further alternate routing. However with RA
it may try to route N2-N1-N4-AT-EO2, but of course this
fails again.
In this scenario, CV34 should be used and correctly
interpreted to indicate that the LSP should be blocked and
not re-signaled. If RA was required, it would be indicated
by the use of crankback.
Iwata, et al. draft-iwata-mpls-crankback-05.txt [Page 7]
Internet Draft March 2003
3. However in another case of a connection request from N2
to E02, suppose that link N3-AT is blocked, then in this
case N3 should return a crankback (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, given that
E01-N4 is already known blocked due to NBA) rather than
trying to alternate route through AT-N3-N2, which may well
be successful. Had N3 returned a crankback, the 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 rerouting
condition. However, convergence of routing information
is typically slow with respect to desired LSP setup
times. One of the reasons for crankback is to avoid the
overhead or available-link-bandwidth (ALB) flooding to
more efficiently use local state information to direct
alternate routing at the ingress-LSR.
[ASH1] shows how event-dependent-routing (EDR) can just
use crankback, and not ALB flooding as required by state-
dependent-routing (SDR), to decide on the path in the
network through "learning models". Reducing the ALB
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).
5. Overview of Crankback Function
Crankback routing is performed when an LSP setup request
is blocked along the path, as described in the following
procedures.
Iwata, et al. draft-iwata-mpls-crankback-05.txt [Page 8]
Internet Draft March 2003
When an LSP setup request is blocked due to unavailable
resources, an error response with the location identifier
of the blockage, should be returned to the LSR initiating
the LSP setup (ingress LSR), the area border LSR, or some
other repair point.
This error response carries an error specification as
standard - this indicates the cause of the error and the
node/link on which the error occurred.
In a flat network without segmentation, when the ingress
LSR receives the error response it designates an
alternate path around the blocked link or node to satisfy
QoS constraints using link state information about the
area. If an alternate path is found, a new LSP setup
request is sent over this path.
On the other hand, in a network segmented into areas such
as with hierarchical OSPF, the following procedures can
be used. The error response is generated as described,
but the area border LSR may terminate the error response
and perform alternate routing within the area for which
the LSR is an ingress.
In a third scenario, any node within an area may act as a
repair point. In this case, the LSR behaves much as an
area border LSR described above. It can terminate the
error response and perform alternate routing. This may
be particularly useful where domains of computation are
applied within the network, but care must be taken to
prevent all nodes in the network behaving in this way or
rerouting thrash may occur. This scenario is somewhat
like `MPLS fast reroute', in which any node in the MPLS
domain can establish `local repair' LSPs after failure
notification.
The repair point LSR that computes the alternate path
should store the location identifiers of the blockages
indicated in the error indication until the LSP is
successfully established or until the LSR abandons
rerouting attempts. Since the crankback routing may
happen more than once while establishing a specific LSP,
the history table of all experienced blockages for this
LSP should be maintained to perform an accurate path
computation to detour the blockages.
If a second error response is received by a repair point
while it is performing crankback rerouting, it should
update the history table and use the entire gathered
information when making a further rerouting attempt.
The maximum number of crankback rerouting attempts
allowed may be limited for any one LSP at any single
node. This is useful to prevent an endless repetition of
crankback routing in certain error conditions or during
periods of high congestion. It is also useful for
reducing the number of unnecessary retries, which do not
Iwata, et al. draft-iwata-mpls-crankback-05.txt [Page 9]
Internet Draft March 2003
improve the performance. When a repair point receives
more than the maximum number of error responses, it
processes the last error response as an ordinary (non-
crankback) error response, does not attempt further
rerouting and forwards the error upstream if it is not
the ingress. When a non-ingress LSR experiences this
situation, it sends an error response to the ingress LSR
and specifies the error "Maximum number of reroutings
aborted". The ingress LSR, upon receiving this message,
may attempt to find a wholly disjoint route (perhaps
through another area) or reports the LSP as failed.
6. Existing Support for Crankback Rerouting
As already described, RSVP-TE includes error
notifications from which a rerouting requirement can be
inferred. These notifications also contain information
about the failed steps in the path.
This section outlines what information is carried and
shows how in some circumstances this may not be enough to
properly facilitate crankback rerouting.
6.1. RSVP-TE
In RSVP-TE a failed LSP setup attempt results in a
PathErr message returned upstream. The PathErr carries
an ErrSpec Object which indicates the node or interface
reporting the error and the reason for the failure.
Crankback rerouting can now be performed explicitly
avoiding the node or interface reported.
6.2. GMPLS
GMPLS extends the error reporting described above by
allowing LSRs to report the errored interface in addition
to the identity of the node reporting the error. This
information would typically only be used in response to
an LSP request that included the IF_ID (PHOP 3) object to
identify the data link to which the signaling applies.
This further enhances the ability of a recomputing node
to route around the error.
6.3. Information Required for Rerouting
In order to correctly compute a route that avoids the
blocking problem in the network, a repair point LSR must
gain as much crankback information as possible. Ideally,
the repair node will be given the node, link and reason
for the failure.
Iwata, et al. draft-iwata-mpls-crankback-05.txt [Page 10]
Internet Draft March 2003
However, this information may not be enough to help with
recomputation. Consider an explicit route that contains
an abstract node or a loose hop. In this case, the
failed node and link is not necessarily enough to tell
the repair point which hop in the explicit route has
failed. The crankback information needs to provide
context into the explicit route.
6.4. Signaling a New Route
If a new route can be computed it can be signaled as an
explicit route that will avoid the blocking issues.
Sometimes, however, the repair point may not always be
able to compute a route. For example, it may not have
sufficient topology information about the part of the
network where the failure occurred.
In this case, the repair point may still attempt to re-
signal the LSP using the route exclusion procedures
described in [LEE].
7. MPLS Signaling Protocol Independent Information and Procedures
7.1. Requesting Crankback and Controlling In-Network Rerouting
When a request is made to setup an LSP tunnel, the
ingress LSR should specify whether it wants crankback
information to be collected in the event of a failure and
whether it requests rerouting attempts by the
intermediate nodes. A Rerouting Flag field is added to
the protocol setup request messages. Three values for
the Rerouting Flag are defined. These values are
mutually exclusive.
No Rerouting Intermediate nodes SHOULD NOT attempt
rerouting after failure. Nodes
detecting failures are not requested to
supply crankback information.
End-to-end Rerouting Intermediate nodes SHOULD NOT attempt
rerouting after failure. Nodes detecting
failures SHOULD supply full crankback
information.
ARB Rerouting Intermediate nodes MAY attempt rerouting
after failure only if they are Area Border
Routers. Nodes detecting failures SHOULD
supply full crankback information.
Segment-based Rerouting Intermediate nodes MAY attempt rerouting
after failure. Nodes detecting failures
SHOULD supply full crankback information.
Iwata, et al. draft-iwata-mpls-crankback-05.txt [Page 11]
Internet Draft March 2003
7.2. Action on Detecting a Failure
A node that detects the failure to setup an LSP or the
failure of an established LSP SHOULD act according to the
Rerouting Flag passed on the LSP setup request.
If Segment-based Rerouting is allowed, the detecting node
MAY immediately attempt to reroute.
If End-to-end Rerouting is indicated, or if Segment-based
Rerouting is allowed and the detecting node chooses not
to make rerouting attempts (or has exhausted all possible
rerouting attempts), the detecting node returns a
protocol error indication and SHOULD include full
crankback information.
7.3. Required Information
As described above, full crankback information should
indicate the node, link and other resources which have
been attempted but have failed because of allocation
issues or network failure. These details are reported in
the Rerouting Information.
The following information is carried in Routing
Information:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ TLVs ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Where each TLV has the following format:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Value ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 16 bits
Indicates type of interface being
identified. Defined values are:
Type Meaning Description
---------------------------------------------------
1 Link TLV The Value describes a Link
2 Node TLV The Value describes a Node
Iwata, et al. draft-iwata-mpls-crankback-05.txt [Page 12]
Internet Draft March 2003
Length: 16 bits
Indicates the total length of the TLV,
i.e., 4 + the length of the value field in
octets. A value field whose length is not
a multiple of four MUST be zero-padded so
that the TLV is four-octet aligned.
7.3.1 Link TLV
When the TLV type is 1 (one) indicating a link TLV, the
value has the following format.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Protocol Type | Num | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link Identifier Components 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ............ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link Identifier Components N |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Protocol Type
A one-octet unsigned integer containing the
unique identifier of the protocol used for
QoS routing. The following type numbers
are defined.
If a constraint-based route is to be
calculated with no routing protocols, type
1 should be used. A location is identified
using ER-Hop TLVs, independent of
protocols.
A type value other than 1 is only permitted
if the Rerouting Flag in the LSP setup
request indicated support for ABR or
segment-based rerouting.
1: ER-Hop
2: OSPFv2 for IPv4 [OSPF]
3: Integrated IS-IS (or IS-IS) for IPv4 [ISIS]
4: OSPF for IPv6 [OSPF6]
5: Integrated IS-IS (or IS-IS) for IPv6 [ISIS6]
128-255: Reserved for private and experimental use.
Note that if adjacent Areas use different
routing protocols, the ABR is responsible
for mapping the rerouting information. In
general, the correct procedure is to
convert to ER-Hop (1) when transitioning
such Areas.
Iwata, et al. draft-iwata-mpls-crankback-05.txt [Page 13]
Internet Draft March 2003
Num: Number of Link Identifier Components
A one-octet unsigned integer specifying the
number of Link Identifier Components
included in the TLV.
One or more Link Identifier Components
A variable length field containing link
identifiers for relevant protocol types.
When the type is ER-Hop (1), the following format is used.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| First ER-Hop TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Second ER-Hop TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
First ER-Hop TLV
The first hop in the explicit route received by the
reporting LSR.
Second ER-Hop TLV
The second hop in the explicit route
received by the reporting LSR. Together
with the First ER-Hop, this assists the
repair point to locate the error within the
context of the explicit route that it sent
out.
When the protocol type is OSPFv2 for IPv4 (2), the
following 8-octet format is used.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Router ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Router ID
The same value as the Router ID used in OSPFv2 for IPv4.
Link ID
The same value as the Link ID used in OSPFv2 for IPv4.
When the protocol type is OSPF for IPv6 (4), the
following 8-octet format is used.
Iwata, et al. draft-iwata-mpls-crankback-05.txt [Page 14]
Internet Draft March 2003
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Router ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Router ID
The same value as the Router ID used in OSPF for IPv6.
Interface ID
The same value as the Interface ID used in OSPF for IPv6.
When the protocol type is IS-IS for IPv4 (3), the
following 12-octet format is used.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ System ID +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP Interface Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
System ID
The same value as System ID used in IS-IS
for IPv4 (3).
IP Interface Address
The IP address assigned to the interface
advertised in IS-IS for IPv4 (3).
When the protocol type is IS-IS for IPv6 (5), the
following 24-octet format is used.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ System ID +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ IP Interface Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
System ID
The same value as System ID used in IS-IS for IPv6 (5).
Iwata, et al. draft-iwata-mpls-crankback-05.txt [Page 15]
Internet Draft March 2003
IP Interface Address
The IP address assigned to the interface advertised in IS-IS
for IPv6 (5).
7.3.2 Node TLV
In case of crankback rerouting, the Node TLV is used to
identify a node or an abstract node where a setup
blockage is detected. In the case of LSP restoration,
the Node TLV is included to identify a node or an
abstract node where a fault is detected.
When the TLV type is 2 indicating a node TLV, the value
has the following format.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Protocol Type | Num | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Node Identifier Components 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ............ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Node Identifier Components N |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Protocol Type
A one-octet unsigned integer containing the
unique identifier of the protocol used for
QoS routing. The same values as defined
for the Link TLV are used.
Num: Number of Node Identifier Components
A one-octet unsigned integer specifying the
number of Node Identifier Components
included in the TLV.
One or mode Node Identifier Components
A variable length field containing the node
identifier for relevant protocol types.
When the type is ER-Hop (1), the following format is
used.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| First ER-Hop TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
First ER-Hop
The first hop in the explicit route
received by the reporting node.
When the protocol type is OSPFv2 for IPv4 (2) or OSPF for
IPv6 (4), the following 4-octet format is used.
Iwata, et al. draft-iwata-mpls-crankback-05.txt [Page 16]
Internet Draft March 2003
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Router ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Router ID
The same value as the Router ID used in
OSPFv2 for IPv4 or in OSPF for IPv6.
When the protocol type is IS-IS for IPv4 (3) or IS-IS for
IPv6 (5), the following 8-octet format is used.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ System ID +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
System ID
The same value as the System ID used in IS-
IS for IPv4 (3) or in IS-IS for IPv6 (5).
7.4. Action on Receiving Crankback Information
7.4.1 Reroute Attempts
As described in section 3, a node receiving crankback
information in an error response must first check to see
whether it is allowed to perform rerouting. This is
indicated by the Rerouting Flags in the LSP setup
request.
If a node is not allowed to perform rerouting it should
forward the error upstream, or if it is the ingress
report the LSP as having failed.
If rerouting is allowed, the node should attempt to
compute a path to the destination using the constraints
of the original (received) explicit path excluding the
failed/blocked node/link. The new path should be added
to an LSP setup request as an explicit route and
signaled.
LSRs performing crankback rerouting should store all
received crankback information for an LSP until the LSP
is successfully established or until the node abandons
its attempts to reroute the LSP. This allows it to
combine crankback information from multiple failures when
computing a new path.
Iwata, et al. draft-iwata-mpls-crankback-05.txt [Page 17]
Internet Draft March 2003
7.4.2 Location Identifiers of Blocked Links or Nodes
In order to compute an alternate path by crankback
rerouting, it is necessary to identify where blocked
links or nodes are. The common identifier of each link
or node in an MPLS network should be specified. Both
protocol-independent and protocol- dependent identifiers
may be specified. Although a general identifier that is
independent of other protocols is preferable, there are a
couple of restrictions on its use as described in the
following subsection.
In link state protocols such as OSPF [OSPF] and IS-IS
[ISIS], each link and node in a network can be uniquely
identified. For example, the OSPF protocol uses Router
ID as the node identifier and the combination of Router
ID and Link ID as the link identifier. If the topology
and resource information obtained by OSPF advertisements
is used to compute a constraint-based path, the location
of a blockage can be represented by such identifiers.
Routing-protocol-specific link or node identifiers that
can be used for multiple routing protocols.
Note that, when the routing-protocol-specific link
identifiers are used, the Routing Flag on the LSP setup
request must have been set to 0010 or 0100 (or both),
which implies support for ABR or segment-based rerouting
(hierarchical rerouting).
In this draft, we specify routing protocol specific link
and node identifiers for OSPFv2 for IPv4, IS-IS for IPv4,
OSPF for IPv6, and IS-IS for IPv6. These identifiers may
only be used if segment-based rerouting (hierarchical
rerouting) is supported, as indicated by the Routing
Behavior flag on the LSP setup request.
If the link blockage occurs in the upstream direction
because the downstream node has no resources available on
that link, the downstream node can use the LSP setup
request message-sender's IP address to generate an ER-TLV
for the upstream node (it can use this generated ER-Hop
TLV with the first ER-Hop TLV to identify the link).
7.4.3 Locating Errors within Loose or Abstract Nodes
The explicit route on the original LSP setup request may
contain a loose hop or an Abstract Node. In these cases,
the crankback information may refer to links or nodes
that were not in the original explicit route.
In order to compute a new path, the repair point may need
to identify the pair of hops (or nodes) in the explicit
route between which the error/blockage occurred.
Iwata, et al. draft-iwata-mpls-crankback-05.txt [Page 18]
Internet Draft March 2003
To assist this, the crankback information reports the top
two hops of the explicit route as received at the
reporting node. The first hop will likely identify the
node or the link, the second hop will identify a 'next'
hop from the original explicit route.
7.4.4 When Rerouting Fails
When a node cannot or chooses not to perform crankback
rerouting it must forward the error response further
upstream.
However, when a node was responsible for expanding or
replacing the explicit route as the LSP setup was
processed it MUST update the crankback information with
regard to the explicit route that it received. Only if
this is done will the upstream nodes stand a chance of
successfully routing around the problem.
7.5. Limiting Rerouting Attempts
Each repair point should apply a locally configurable
limit to the number of attempts it makes to reroute an
LSP. This helps to prevent excessive network usage in
the event of significant faults and allows back-off to
other repair points which may have a better chance of
routing around the problem.
7.5.1 New Status Codes for Rerouting
A new status/error code is used to identify that a node
has abandoned crankback rerouting because a it has
reached a threshold for retry attempts.
A node receiving an error response with this status code
MAY also attempt crankback rerouting, but it is
RECOMMENDED that such attempts be limited to the ingress
LSR.
8. RSVP-TE Extensions for Crankback
8.1. Overview
Crankback rerouting is appropriate for use with RSVP-TE.
1) Path establishment may fail because of an inability to
route, perhaps because links are down. In this case a
PathErr is returned to the initiator.
2) Path establishment may fail because resources are
unavailable. This is particularly relevant in GMPLS where
explicit label control may be in use. Again, a PathErr is
returned to the initiator.
Iwata, et al. draft-iwata-mpls-crankback-05.txt [Page 19]
Internet Draft March 2003
3) Resource reservation may fail on the reverse path, as the
Resv is processed, and resources are reserved. If resources
are not available on the required link or at a specific
node, a ResvErr message is returned to the egress node
indicating "Admission Control failure" [RSVP]. The egress
is allowed to change the Rspec and try again, but in the
event that this is not practical or not supported, the
egress may choose to take any one of the following actions.
- Ignore the situation and allow recovery to happen through
Path refresh and refresh timeout [RSVP].
- Send a PathErr towards router-A indicating "Admission
Control failure".
- Send ResvTear towards router-A to abort the LSP setup.
Note that in multi-area networks, the ResvErr might be
intercepted and acted on at an area border router.
4) It is also possible to make resource reservations on the
forward path as the Path message is processed. This choice
is made in any RSVP-TE implementations and is compatible
with LSP setup in optical networks [GMPLS]. In this case if
resources are not available, a PathErr message is returned
to router-A indicating "Admission Control failure".
Crankback information would be useful to an upstream node
(such as the ingress) if it is supplied on a PathErr or a
Notify message that is sent upstream.
8.1.1 ResvErr Processing
As described above, the resource allocation failure for
RSVP-TE may occur on the reverse path when the Resv
message is being processed. In this case, it is still
useful to collect the crankback information and return it
to the ingress LSR. However, it is the intention of RSVP
is that such errors are propagated to the egress using a
ResvErr message to allow the egress the option of re-
issuing the Resv with different resource requirements
(although not on an alternate path). This means that a
PathErr with crankback information must not be issued as
soon as the error is detected at a transit node, but that
the crankback information must be encoded in the ResvErr
and passed back to the egress for action.
When a ResvErr carrying crankback information is received
at an egress LSR, the egress LSR MAY ignore this object
and perform the same actions as for any other ResvErr.
However, if the egress LSR supports the crankback
extensions defined in this draft, and after all local
recovery procedures have failed, it SHOULD generate a
PathErr message carrying the crankback information and
send it to the ingress LSR.
Iwata, et al. draft-iwata-mpls-crankback-05.txt [Page 20]
Internet Draft March 2003
If a ResvErr reports on more than one filter spec
(because the Resv carried more than one filter spec) then
only one set of crankback information should be present
in the ResvErr and it should apply to all filter specs
carried. In this case it may be necessary to generate
more than one PathErr according to the normal rules of
RSVP.
8.1.2 Notify Message Processing
[GMPLS-RSVP] defines a new message, the Notify message,
to enhance error reporting in RSVP-TE networks. The
Notify message is sent to addresses requested on the Path
and Resv messages. These addresses could (but need not)
identify the ingress and egress LSRs respectively.
When a network error occurs, such as the failure of link
hardware, the LSRs that detect the error MAY send Notify
messages to the requested addresses. The type of error
that causes a Notify message to be sent is an
implementation detail.
The Notify message is not intended to replace the PathErr
and ResvErr messages.
In the event of a failure an LSR that supports [GMPLS-
RSVP] and the crankback extensions defined in this draft
MAY choose to send a Notify message carrying crankback
information. This would ensure a speedier report of the
error to the ingress/egress LSRs and might make LSP
restoration faster.
8.2. Indication of Rerouting Behavior
The behavior specified by the Routing Flag of section 7.1
is achieved in RSVP-TE by a change to the LSP_TUNNEL
Session Attribute Object. New values for the Flags field
are defined.
The object is now specified as follows.
class = SESSION_ATTRIBUTE, LSP_TUNNEL C-Type = 7
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Setup Prio | Holding Prio | Flags | Name Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// Session Name (NULL padded display string) //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Iwata, et al. draft-iwata-mpls-crankback-05.txt [Page 21]
Internet Draft March 2003
Setup Priority
The priority of the session with respect to
taking resources, in the range of 0 to 7.
The value 0 is the highest priority. The
Setup Priority is used in deciding whether
this session can preempt another session.
Holding Priority
The priority of the session with respect to
holding resources, in the range of 0 to
7. The value 0 is the highest priority.
Holding Priority is used in deciding
whether this session can be preempted by
another session.
Flags
0x01 Local protection desired
This flag permits transit routers to
use a local repair mechanism which may
result in violation of the explicit
route object. When a fault is detected
on an adjacent downstream link or node,
a transit router can reroute traffic
for fast service restoration.
0x02 Label recording desired
This flag indicates that label
information should be included when
doing a route record.
0x04 SE Style desired
This flag indicates that the tunnel
ingress node may choose to reroute this
tunnel without tearing it down. A
tunnel egress node SHOULD use the SE
Style when responding with a Resv
message.
0x08 End-to-end rerouting desired
This flag indicates the end-to-end
rerouting behavior for an LSP under
establishment. This can also be used
for specifying the behavior of end-to-
end LSP restoration for established
LSPs.
0x10 ABR (hierarchical) rerouting desired.
This flag indicates the Area Border
Router rerouting (hierarchical
rerouting) behavior for an LSP under
establishment. This can also be used
for specifying the segment-based
(hierarchical) LSP restoration for
established LSPs.
Iwata, et al. draft-iwata-mpls-crankback-05.txt [Page 22]
Internet Draft March 2003
0x20 Segment-based (hierarchical) rerouting desired.
This flag indicates the segment-based
rerouting (hierarchical rerouting)
behavior for an LSP under
establishment. This can also be used
for specifying the segment-based
(hierarchical) LSP restoration for
established LSPs.
Name Length
The length of the display string before
padding, in bytes.
Session Name
A null padded string of characters.
8.3. Rerouting Object
We define a new object, the "Rerouting Object" (analogous
to the "Rerouting TLV" defined for CR-LDP), to carry
crankback information. The new object is added to the
definition of the PathErr, ResvErr and Notify messages,
specifying it as optional.
The altered messages are defined as follows. Note that
the forms used are from [GMPLS-RSVP] - the inclusion of
[ <REROUTING> ] is equally applicable to standard RSVP-TE
[RSVP-TE].
<PathErr message> ::= <Common Header> [ <INTEGRITY> ]
[ [<MESSAGE_ID_ACK> | <MESSAGE_ID_NACK>] ... ]
[ <MESSAGE_ID> ]
<SESSION> <ERROR_SPEC>
[ <ACCEPTABLE_LABEL_SET> ... ]
[ <REROUTING> ]
[ <POLICY_DATA> ...]
[ <sender descriptor> ]
<ResvErr Message> ::= <Common Header> [ <INTEGRITY> ]
[ [<MESSAGE_ID_ACK> | <MESSAGE_ID_NACK>] ... ]
[ <MESSAGE_ID> ]
<SESSION> <RSVP_HOP>
<ERROR_SPEC> [ <SCOPE> ]
[ <ACCEPTABLE_LABEL_SET> ... ]
[ <REROUTING> ]
[ <POLICY_DATA> ...]
<STYLE> [ <error flow descriptor> ]
<Notify message> ::= <Common Header> [ <INTEGRITY> ]
[ [<MESSAGE_ID_ACK> | <MESSAGE_ID_NACK>] ... ]
[ <MESSAGE_ID> ]
<ERROR_SPEC>
[ <REROUTING> ]
<notify session list>
Iwata, et al. draft-iwata-mpls-crankback-05.txt [Page 23]
Internet Draft March 2003
<notify session list> := [<notify session list>]
<upstream notify session> |
<downstream notify session>
<upstream notify session> ::= <SESSION> [<ADMIN_STATUS> ]
[ <POLICY_DATA>...]
<sender descriptor>
<downstream notify session> ::= <SESSION> [<POLICY_DATA>...]
<flow descriptor list>
The Rerouting Object is defined as follows:
IPv4 REROUTING object: Class = TBD, C-Type = 1
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// (Subobjects) //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Rerouting object may contain one or more subobjects
of the following types:
Link Rerouting Subobject
Node Rerouting Subobject
These subobjects conform to the TLV formats described in
section 5.3.
8.4. Error Values
Error values for the Error Code "Admission Control
Failure" are defined in [RSVP].
A new error value is defined for the error code "Routing
Problem". "Rerouting limit exceeded indicates that
rerouting has failed because the number of crankback
rerouting attempts has gone beyond the predetermined
threshold at an individual LSR.
8.5. Backward Compatibility
It is recognized that not all nodes in an RSVP-TE network
will support the extensions defined in this draft. It is
important that an LSR that does not support these
extensions can continue to process a PathErr, ResvErr or
Notify message even if it carries the new Rerouting
Object.
This is achieved by using the rules set out in Section
3.10 of [RSVP] to define the value of the Class of the
new Rerouting Object. The value shall be selected from
the set of values as follows.
Class-Num = 11bbbbbb
Iwata, et al. draft-iwata-mpls-crankback-05.txt [Page 24]
Internet Draft March 2003
The node should ignore the object but forward it,
unexamined and unmodified, in all messages resulting from
this message.
9. Routing Protocol Interactions
If the routing-protocol-specific link or node identifiers
are used in the Link TLV and Node TLV defined above, the
signaling software has to have an interface to interact
with the routing protocol, OSPFv2 for IPv4, IS-IS for
IPv4, OSPF for IPv6, or IS-IS for IPv6.
For example, when an intermediate LSR issues a PathErr
message with the Rerouting Object towards an ingress LSR,
the signaling module of the intermediate LSR should
interact with the routing logic to determine the routing-
protocol-specific link or node ID where the blockage or
fault occurred and carry this information onto the Link
TLV and Node TLV inside the Rerouting Object. The
ingress LSR, upon receiving this message, should interact
with the routing logic to compute an alternative path by
pruning the specified link ID or node ID in the routing
database.
Although such protocol interactions are required, the
procedure of this interaction is out of scope in this
document.
10. LSP Restoration Considerations
LSP restoration is performed to recover an established
LSP when a failure occurs along the path. In the case of
LSP restoration, the extensions for crankback rerouting
explained above can be applied for improving performance.
This section gives an example of applying the above
extensions to LSP restoration. The goal of this example
is to give a general overview of how this might work, and
not to give a detailed procedure for LSP restoration.
Although there are several techniques for LSP
restoration, this section explains the case of on-demand
LSP restoration, which attempts to set up a new LSP on
demand after detecting an LSP failure.
10.1. Upstream of the Fault
When an LSR detects a fault on an adjacent downstream
link or node, a PathErr message is sent upstream. In
GMPLS this message may carry a state removal indication.
Each LSR receiving the message then releases the
corresponding LSP. (Note that if the state removal
indication is not present on the PathErr message it is
necessary for the ingress node to issue a PathTear
message to cause the resources to be released.) If the
failed LSP is expected to be restored at an upstream LSR,
Iwata, et al. draft-iwata-mpls-crankback-05.txt [Page 25]
Internet Draft March 2003
the Rerouting Object with the location information of the
failed link or node is included in the PathErr message.
The ingress, intermediate area border LSR, or indeed any
repair point permitted by the Rerouting Flags, that
receives the PathErr message can terminate the message
and then perform alternate routing.
In a flat network without segmentation, when the ingress
LSR receives the PathErr message with the Rerouting TLV,
it designates an alternate path around the blocked link
or node to satisfy QoS constraints using link state
information about the area. If an alternate path is
found, a new Path message is sent over this path toward
the egress LSR.
In a network segmented into areas such as with
hierarchical OSPF, the following procedures can be used.
As explained in Section 8.2, the LSP restoration behavior
is indicated in the Flags field of the Session Attributes
object of the Path message. If the Flags indicate end-to-
end rerouting, the PathErr message with the Rerouting
object is returned all the way back to the ingress LSR,
which may then issue a new Path message along another
path, which is the same procedure as in the flat network
case above.
If the Flags field indicates ABR rerouting (hierarchical
rerouting), the ingress area border LSR MAY terminate the
PathErr message carrying the Rerouting object and then
perform alternate routing within the area for which the
area border LSR is the ingress LSR.
If the Flags field indicates segment-based rerouting
(hierarchical rerouting), any node MAY apply the
procedures described above for ABR rerouting.
10.2. Downstream of the Fault
On the downstream side of the failure, an LSR detecting
the failure sends a PathTear for the LSP..
When a PathTear message is received at the egress of the
LSP, it performs the normal processing. That is, it
releases the LSP.
An intermediate area border LSR receiving the PathTear
message for an LSP that was setup with Flags field
indicating ABR rerouting (hierarchical rerouting) can
terminate the PathTear and wait until the new Path
message for the LSP restoration is received. There is an
inherent danger in this step, however, since it is
possible that the LSP restoration will take a path that
avoids this LSR, or even that the LSP restoration will
not take place. If a node decides to absorb the PathTear
in this way it is RECOMMENDED that the LSR run a local
timer to tidy up and forward the PathTear in the event
that it does not see the LSP restoration.
Iwata, et al. draft-iwata-mpls-crankback-05.txt [Page 26]
Internet Draft March 2003
If segment-based rerouting is indicated, any node
receiving a PathTear MAY act as described for ABRs above.
Otherwise, a node receiving a PathTear SHOULD release the
resources associated with the LSP and forward the message
downstream.
11. Security Considerations
It should be noted that while the extensions in this
draft introduce no new security holes in the protocols,
should a malicious user gain protocol access to the
network, the crankback information might be used to
prevent establishment of valid LSPs.
The implementation of rerouting attempt thresholds are
particularly important in this context.
11.1. RSVP-TE
The crankback routing extensions and procedures for LSP
restoration as applied to RSVP-TE introduce no further
new security considerations. Refer to [RSVP], [RSVP-TE]
and [GMPLS-RSVP] for a description of applicable security
considerations.
12. Acknowledgments
We would like to thank Juha Heinanen and Srinivas Makam
for their review and comments, and Zhi-Wei Lin for his
considered opinions. Thanks, too, to John Drake for
encouraging us to resurrect this draft and consider the
use of the IF-ID ErrorSpec.
13. Normative References
[RSVP] R. Braden, et al., "Resource ReSerVation Protocol (RSVP)
- Version 1 Functional Specification", RFC2205,
September 1997.
[RSVP-TE] D. Awduche, et al., "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC3209, December 2001.
[GMPLS] P. Ashwood-Smith and L. Berger, et al., "Generalized
MPLS - Signaling Functional Description", RFC 3471,
January 2003.
[GMPLS-RSVP] L. Berger, et al., "Generalized MPLS Signaling - RSVP-TE
Extensions", RFC 3473, January 2003.
[OSPF] J. Moy, "OSPF Version 2", RFC2328, April 1998.
[OSPF6] R. Coltun, et al., "OSPF for IPv6", RFC2740, December
1999.
Iwata, et al. draft-iwata-mpls-crankback-05.txt [Page 27]
Internet Draft March 2003
[ISIS] R. Callon, "Use of OSI IS-IS for Routing in TCP/IP and
Dual Environments", RFC1195, December 1990.
[ISIS6] C. E. Hopps, "Routing IPv6 with IS-IS", draft-ietf-isis-
ipv6-02.txt, April 2001 (work in progress).
14. Informational References
[ASH1] G. Ash, "Traffic Engineering & QoS methods for IP-,
ATM-, & TDM-Based Multiservice Networks", draft-ietf-
tewg-qos-routing-04.txt, October 2001 (work in
progress).
[AWDUCHE1] D. Awduche, et al., "Requirements for Traffic
Engineering Over MPLS", RFC2702, September 1999.
[G8080] ITU-T Recommendation G.808/Y.1304, Architecture for the
Automatically Switched Optical Network (ASON), November
2001.
[LEE] C-Y. Lee, A. Farrel and S De Cnodder, "Exclude Routes -
Extension to RSVP-TE", draft-lee-ccamp-rsvp-te-exclude-
route-02.txt, March 2003 (work in progress).
[MAKAM] V. Sharma, et al., "Framework for MPLS-based Recovery",
RFC 3469, February 2003.
[PNNI] ATM Forum, "Private Network-Network Interface
Specification Version 1.0 (PNNI 1.0)", <af-pnni-
0055.000>, May 1996.
[SHARMA] V. Sharma, et al., "An Assessment of QoS and Protection
in MPLS", MPLS'99 Conference, June 1999.
15. Authors' Addresses
Adrian Farrel (editor)
Movaz Networks, Inc.
7926 Jones Branch Drive, Suite 615
McLean, VA 22102
Phone: +1-(703)-847-1867
Email: afarrel@movaz.com
Atsushi Iwata
NEC Corporation
Networking Research Laboratories
1-1, Miyazaki, 4-Chome, Miyamae-ku,
Kawasaki, Kanagawa, 216-8555, JAPAN
Phone: +81-(44)-856-2123
Fax: +81-(44)-856-2230
Email: a-iwata@ah.jp.nec.com
Iwata, et al. draft-iwata-mpls-crankback-05.txt [Page 28]
Internet Draft March 2003
Norihito Fujita
NEC Corporation
Networking Research Laboratories
1-1, Miyazaki, 4-Chome, Miyamae-ku,
Kawasaki, Kanagawa, 216-8555, JAPAN
Phone: +81-(44)-856-2123
Fax: +81-(44)-856-2230
Email: n-fujita@bk.jp.nec.com
Gerald R. Ash
AT&T
Room MT D5-2A01
200 Laurel Avenue
Middletown, NJ 07748, USA
Phone: +1-(732)-420-4578
Fax: +1-(732)-368-8659
Email: gash@att.com
Simon Marshall-Unitt
Data Connection Ltd.
100 Church Street
Enfield, Middlesex
EN2 6BQ, UK
Phone: +44-(20)-8366-1177
Email: smu@dataconnection.com
16. Full Copyright Statement
Copyright (c) The Internet Society (2003). All Rights
Reserved. This document and translations of it may be
copied and furnished to others, and derivative works that
comment on or otherwise explain it or assist in its
implementation may be prepared, copied, published and
distributed, in whole or in part, without restriction of
any kind, provided that the above copyright notice and
this paragraph are included on all such copies and
derivative works. However, this document itself may not
be modified in any way, such as by removing the copyright
notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose
of developing Internet standards in which case the
procedures for copyrights defined in the Internet
Standards process must be followed, or as required to
translate it into languages other than English.
The limited permissions granted above are perpetual and
will not be revoked by the Internet Society or its
successors or assigns.
This document and the information contained herein is
provided on an "AS IS" basis and THE INTERNET SOCIETY AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL
WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED
TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN
WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Iwata, et al. draft-iwata-mpls-crankback-05.txt [Page 29]
| PAFTECH AB 2003-2026 | 2026-04-23 10:35:59 |