[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00 01 02 03 04 05 06 07

Network Working Group                                    Atsushi Iwata
Internet Draft                                         Norihito Fujita
<draft-iwata-mpls-crankback-00.txt>                     NEC Corporation
Expiration Date: May 2001
                                                         Gerald R. Ash
                                                                  AT&T

                                                         Adrian Farrel
                                                  Data Connection Ltd.

                                                         November 2000


            Crankback Routing Extensions for MPLS Signaling

                   <draft-iwata-mpls-crankback-00.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.















Iwata, et al.       draft-ietf-mpls-crankback-00.txt            [Page 1]


Internet Draft                                             November 2000


Abstract

   This draft proposes crankback routing extensions for CR-LDP signaling
   and for RSVP-TE signaling. 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 CR-LDP and RSVP-TE so that the label
   request can be retried on an alternate path that detours around the
   blocked link or node upon a setup failure. Furthermore, the 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.

Table of Contents

                                                                Page
   1. Introduction                                              3
   2. Explicit versus implicit rerouting indications            4
   3. Crankback routing behaviors due to LSP setup blockage     6
   4. New status codes for rerouting                            8
   5. Location Identifiers of Blocked Links or Nodes            8
   6. Indication of Rerouting Behavior                          9
   7. Additional TLVs                                          10
     7.1. Rerouting TLV                                        10
     7.2. Link TLV                                             11
     7.3. Node TLV                                             14
   8. Routing protocol interactions                            16
   9. RSVP-TE considerations                                   16
     9.1 Indication of Rerouting Behavior                      18
     9.2 Rerouting Object                                      19
     9.3 Link-Rerouting Subobject                              20
     9.4 Node-Rerouting Subobject                              23
     9.5 Error Values                                          25
     9.6 ResvErr Usage                                         25
     9.7 Notify Message Usage                                  25
     9.8 Backward Compatibility                                26
   10. LSP restoration considerations                          27
   11. Security Considerations                                 28
   12. Acknowledgments                                         28
   13. References                                              28





Iwata, et al.       draft-ietf-mpls-crankback-00.txt            [Page 2]


Internet Draft                                             November 2000


1. Introduction

   CR-LDP (Constraint-based Routing Label Distribution Protocol) [CR-
   LDP] and RSVP-TE (RSVP Extensionf for LSP Tunnel) [RSVP-TE] can be
   used for establishing explicitly routed LSPs (CR-LSPs) in an MPLS
   network. Using CR-LDP and 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].
   Explicit paths can be designated based on the distributed information
   at the LSR initiating a LSP and, if necessary, intermediate 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 the current CR-LDP specification, when an LSP setup
   failure occurs, a Notification message is returned to the setup
   initiator (ingress LSR), which terminates this message and gives up
   the LSP establishment. 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] 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".

   If the ingress 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, ASH2]. We propose
   the use of crankback routing in CR-LDP and RSVP-TE. Crankback routing
   requires notifying an upstream LSR of the location of the blocked
   link or node.

   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. The 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



Iwata, et al.       draft-ietf-mpls-crankback-00.txt            [Page 3]


Internet Draft                                             November 2000


   the real-time network state becomes much greater than in normal LSP
   setups. The LSP restoration must therefore be performed with
   inaccurate information, which is likely to cause setup blocking.
   Crankback routing would also improve failure recovery in these
   situations.

   Recently, Multi-Protocol Lambda Switching has also been discussed
   [AWDUCHE2]. 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 [CHAUDHURI]. This
   implies that crankback routing would also be useful in an MPLambdaS
   network. This draft proposes a crankback routing system that is an
   extension of CR-LDP and RSVP-TE and discusses the identification of
   blocked links or nodes in an MPLS network.

   For the sake of clarity, the general discussions in the following
   sections are restricted to the use of CR-LDP as the label
   distribution technique. A similar discussion can be applied to TE-
   RSVP [TE-RSVP] as discussed in Sec.9.

2. 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.  In the feedback case [ASHW],
   or in the current error sub-codes of the Notification message [CR-
   LDP], one can infer a situation where rerouting can be done, but it
   also can lead to other problems, which have been experienced in
   practice, as illustrated below.

    *--------------------*  *-----------------*
    |                    |  |                 |
    |  N2 ----------- N3-|--|----- AT--- EO2  |
    |  |              | x|--|--x x |          |
    |  |              |  |  |   x  |          |
    |  |              | x|--|--x x |          |
    |  N1 ----------- N4-|--|----- EO1        |
    |                    |  |                 |
    *--------------------*  *-----------------*
             AS-1                 AS-2

        Figure 1.  Example of network topology

   Experiences of using release messages in TDM-based networks for
   analogous purposes provide some guidance.  One can use a release



Iwata, et al.       draft-ietf-mpls-crankback-00.txt            [Page 4]


Internet Draft                                             November 2000


   message with a cause value (CV) indicating "link congestion" (a CV
   already standardized in ISUP, for example) to try to then do
   rerouting at the originating node.  However, this sometimes leads to
   other problems.  Figure 1 is used to illustrate five examples based
   on actual service-provider experiences with respect to crankback
   (i.e., explicit indication) versus release/CV, or "no bandwidth
   available" (NBA) (i.e., implicit indication) processing. 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).

   (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.  With crankback, however, this could be
   resolved, since crankback also indicates where the blocking occurred,
   and in this scenario a crankback should not be returned.  Rather, a
   CV34 should be returned and should result in blocking the connection
   request at N2 (the proper response to CV34).

   (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



Iwata, et al.       draft-ietf-mpls-crankback-00.txt            [Page 5]


Internet Draft                                             November 2000


   trying the alternate route.

   (5) Granted that with topology exchange, such as OSPF, the ingress
   LSR could infer the rerouting condition.  However, 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.  The draft [ASH2] 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 large AS size.

   Therefore, the alternate routing should be indicated based on an
   explicit indication (as in examples 2 and 5), and it is best to know
   the following information separately:

     a) where blockage/congestion occurred (as in examples 2-3), and

     b) whether alternate routing "should" be attempted even if there is
     no "blockage" (as in example 4).

3. Crankback routing behaviors due to LSP setup blockage

   Crankback routing is performed when an LSP setup request is blocked
   along the path, as described in the following procedures.

   When a Label Request message is blocked due to unavailable resources,
   a Notification message with the location identifier of the blockage,
   should be returned to the LSR initiating the Label Request (ingress
   LSR) or the area border LSR. This location identifier of the blockage
   is described in the Rerouting TLV specified in the Section 7. The
   existence of the Rerouting TLV in the Notification message implies
   the explicit indication of the alternate rerouting, as discussed in
   the previous section.

   This message may optionally include the feedback TLV, as specified in
   [ASW], to piggy-back the current available bandwidth information on
   the blocked link. This fed-back information carried by the feedback
   TLV can be incorporated into subsequent route computations at the
   ingress LSR or the area border LSR, which greatly helps to reduce the
   LSP blocking probability and improves the accuracy of the routing by
   this learning behavior.

   In a flat network without segmentation, when the ingress LSR receives
   the Notification 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 Label Request message is sent over



Iwata, et al.       draft-ietf-mpls-crankback-00.txt            [Page 6]


Internet Draft                                             November 2000


   this path.

   On the other hand, in a network segmented into areas such as with
   hierarchical OSPF, the following procedures are used. As explained in
   Section 6, the crankback routing behavior is indicated in the
   "Routing Behavior Flag" (RtgFlg) of the LSPID TLV in the Label
   Request message.  If the "Routing Behavior Flag" is set to end-to-end
   rerouting, the Notification message with the Rerouting TLV is
   returned all the way back to the ingress LSR, which may then issue a
   new Label Request message along another path, which is the same as
   the case of the flat network above. If the "Routing Behavior Flag" is
   set as segment-based rerouting (hierarchical rerouting), the area
   border LSR must terminate the Notification message with the Rerouting
   TLV and then perform alternate routing within the area, where the
   area border LSR is located at the ingress side of the area, instead
   of the ingress LSR of the entire network.

   The ingress LSR or the intermediate area border LSR that computed the
   alternate path should store the location identifiers of the blockages
   indicated in the Rerouting TLV in the Notification message, until it
   receives a corresponding Label Mapping message. Since the crankback
   routing may happen more than once for establishing an 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. Thus, until the LSP is established completely, it should
   be better to maintain the history table of the location identifiers
   of the blockages notified in each Notify message received at the LSR.
   Therefore, while the crankback routing is being processed for the
   LSP, if another Notification message with a Rerouting TLV is received
   again at the ingress LSR or the intermediate area border LSR for this
   LSP to trigger another crankback routing, the path computation should
   be done by the ingress LSR or the intermediate area border LSR, based
   on the previous blocked links or nodes in the history table as well
   as the current ones in the received Notification message. This
   history table may be used for the following LSP setups to compute an
   accurate path computation during some period or may also be cleared
   each time an LSP is established.

   For establishing an LSP, the maximum number of crankback rerouting
   attempts allowed may be limited. 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 improve the performance. When
   either an ingress LSR or an area border LSR receives more than the
   maximum number of Notification messages with the Rerouting TLV, it
   processes this Notification message as an ordinary (non-crankback)
   Notification message and does not issue any more Label Request
   messages. When an area border LSR experiences this situation, it



Iwata, et al.       draft-ietf-mpls-crankback-00.txt            [Page 7]


Internet Draft                                             November 2000


   sends back to the ingress LSR in the previous area and specifies the
   error code "Maximum number of reroutings aborted" in the Status TLV
   within the Notification message. The ingress LSR, upon receiving this
   message, is allowed to find another area border LSR by pruning this
   area border LSR in order to try to find another alternative path.

4. New status codes for rerouting

   The Status TLV included in the Notification message [CR-LDP]
   indicates the cause of the problem, such as "Resource unavailable"
   and "Traffic Parameters Unavailable".

   For rerouting behaviors, additional status codes are defined for the
   Status TLV in the Notification message. When an ingress LSR and
   intermediate area border LSR receiving this Status TLV does not
   support the rerouting functions explained above, this TLV is allowed
   to be silently ignored.

   The code "Alternate rerouting should be attempted" is used for an
   explicit crankback rerouting indication, such as policy related
   rerouting, and is specified by an intermediate LSR. The code "Maximum
   number of reroutings aborted" is used by an intermediate area border
   LSR to indicate when the number of crankback reroutings goes beyond
   the predetermined threshold. When the ingress LSR or the intermediate
   area border LSR receives this code, it tries to find another area
   border LSR through which it might be able to find another alternative
   path. Other codes could be added in the future for other possible
   rerouting behaviors (to be determined).


    Status Code                                       Type
    --------------------------------------         ----------
    Alternate rerouting should be attempted        0x44000016
    Maximum number of reroutings aborted           0x44000017

5. 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. We specify both protocol-independent and protocol-
   dependent identifiers. Although a general identifier that is
   independent of other protocols is preferable, there are a couple of
   restrictions on its use.

   In a CR-LDP label request, an explicit route can be represented as a
   list of ER-Hop TLVs in the ER-TLV. The first ER-Hop TLV is removed
   when the label request is sent to the next abstract node. Therefore,



Iwata, et al.       draft-ietf-mpls-crankback-00.txt            [Page 8]


Internet Draft                                             November 2000


   we propose that the blockage location be represented using the top
   ER-Hop TLVs upon a blockage. In the case of a node blockage, the
   first ER-Hop TLV is returned in the Rerouting TLV in the Notification
   message. Upon a link blockage, the first and second ER-Hop TLVs are
   returned, which means that the blockage location is the link between
   the two nodes indicated by these TLVs. If the abstract node described
   by the ER-Hop TLV is represented by a strict hop with a prefix length
   of 32, this indicates one IP address of a single IPv4 node. If this
   condition is met, the indication of the blockage location by the ER-
   Hop TLVs allows an ingress or intermediate area border LSR to compute
   an alternate path to detour just the link/node. If not, the link or
   node where a setup failure occurred probably will not be identified.
   Furthermore, if an initial label request is traversed with hop-by-hop
   routing, the label request message does not have an ER-TLV.  These
   examples imply that ER-Hop TLVs cannot always be used as the location
   identifier of a blockage. An alternate indicator of such blocked
   links or nodes is required.

   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. We also propose 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 Behavior Flag of
   LSPID TLV carried in the Label Request message must be set 0010,
   which implies segment-based rerouting (hierarchical rerouting). In
   this draft, we specify identifications for OSPFv2 for IPv4, IS-IS for
   IPv4, OSPF for IPv6, and IS-IS for IPv6.

6. Indication of Rerouting Behavior

   The LSPID TLV is specified in [CR-LDP] and is a mandatory TLV in the
   Label Request message. The "Routing Behavior Flag" (RtgFlg) is newly
   specified within the reserved field of [CR-LDP], as shown below. It
   is used for indicating the behavior of the crankback rerouting for
   the Label Request message.

   Note that "Action Indicator Flag" [CR-LDP][ASH3] in the LSPID TLV may
   be used for this purpose. The current definition of this ActFlg flag
   is to indicate the action that should be taken if the LSP already
   exists on the LSR receiving the message. If the spec [CR-LDP] allows
   this ActFlg flag to be extended to support an LSP under being
   established, the specified RtgFlg flag can be merged into the ActFlg
   flag.



Iwata, et al.       draft-ietf-mpls-crankback-00.txt            [Page 9]


Internet Draft                                             November 2000


    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|0|      LSPID-TLV  (0x0821)  |      Length                   |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |     Reserved  |RtgFlg |ActFlg |      Local CR-LSP ID          |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                       Ingress LSR Router ID                   |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      RtgFlg
        Routing Behavior Flag: A 4-bit field that indicates explicitly
        the behavior of rerouting, or crankback routing for an LSP
        under establishment. This RtgFlg can also be used for specifying
        the behavior of LSP restoration for established LSPs.
        A set of code points is specified as follows:

        0000: indicates no rerouting
        0001: indicates end-to-end rerouting
        0010: indicates segment-based rerouting (hierarchical rerouting)

7. Additional TLVs

   In this section, we define additional TLVs included in the
   Notification message for indicating the location of blocked links or
   blocked nodes. The defined TLVs can also be used for LSP restoration,
   where these TLVs are carried in Label Withdraw messages for
   triggering LSP restoration to the ingress LSR.

7.1. Rerouting TLV

   When resource allocation for a Label Request message is not allowed,
   a Notification message is returned. In a network where crankback
   routing is supported, the Rerouting TLV is included in the
   Notification message. This message must carry the LSPID TLV of the
   corresponding CR-LSP. The Status TLV included in the Notification
   message indicates the cause of the problem. Additional status codes
   are added to the current defined ones, as described in Sec.4.

   If LSP restoration is supported, the Rerouting TLV may be included in
   Label Withdraw messages caused by network failures. In this case, the
   message must also carry the LSPID TLV of the corresponding CR-LSP,
   and its Status TLV indicates the cause of the problem.








Iwata, et al.       draft-ietf-mpls-crankback-00.txt           [Page 10]


Internet Draft                                             November 2000


    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|0|     Rerouting (0x850)     |          Length               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               Location Identifier Components                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Location Identifier Components
     One or more TLVs of the following are included.

       Link TLV:  See below for the format.
       Node TLV:  See below for the format.

7.2. Link TLV

   In case of crankback routing, the Link TLV is used to identify a link
   where a setup blockage is detected. In case of LSP restoration, the
   Link TLV is included to identify a link where a fault is detected.

    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|0|       Link (0x851)        |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          Reserved             | Protocol Type |     Num       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 Link Identifier Components 1                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ~                         ............                          ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 Link Identifier Components N                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Protocol Type
     A one-octet unsigned integer containing the unique identifier of a
     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. If a type other than 1
     is used, or the routing-protocol-specific link identifiers are
     used, the Routing Behavior Flag of the LSPID TLV carried in the
     Label Request message must be set 0010, which implies that segment-
     based rerouting (hierarchical rerouting) is used.

             1:  CR-LDP (ER-Hop TLVs)
             2:  OSPFv2 for IPv4 [OSPF]
             3:  Integrated IS-IS (or IS-IS) for IPv4 [ISIS]



Iwata, et al.       draft-ietf-mpls-crankback-00.txt           [Page 11]


Internet Draft                                             November 2000


             4:  OSPF for IPv6 [OSPF6]
             5:  Integrated IS-IS (or IS-IS) for IPv6 [ISIS6]
       128-255:  Reserved for private and experimental use.

   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 CR-LDP (1), the following format is used. The
     first and second ER-Hop TLVs upon setup blockage are included.

    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                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     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.












Iwata, et al.       draft-ietf-mpls-crankback-00.txt           [Page 12]


Internet Draft                                             November 2000


     When the protocol type is OSPF for IPv6 (4), 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                             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       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).














Iwata, et al.       draft-ietf-mpls-crankback-00.txt           [Page 13]


Internet Draft                                             November 2000


     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).

     IP Interface Address
       The IP address assigned to the interface advertised in IS-IS for
       IPv6 (5).

7.3. 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.

   The Node TLV is used to identify a node where a setup blockage or a
   fault is detected.

    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|0|       Node (0x852)        |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          Reserved             | Protocol Type |     Num       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 Node Identifier Components 1                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ~                         ............                          ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 Node Identifier Components N                  |



Iwata, et al.       draft-ietf-mpls-crankback-00.txt           [Page 14]


Internet Draft                                             November 2000


   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Protocol Type
     A one-octet unsigned integer containing the unique identifier of
     the protocol used for QoS routing. The same value as defined in the
     Link TLV is 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 CR-LDP (1), the following format is used. The
     first ER-Hop TLV upon setup blockage is included.

    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                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     When the protocol type is OSPFv2 for IPv4 (2) or OSPF for IPv6 (4),
     the following 4-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                             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     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           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+




Iwata, et al.       draft-ietf-mpls-crankback-00.txt           [Page 15]


Internet Draft                                             November 2000


     System ID
       The same value as the System ID used in IS-IS for IPv4 (3) or in
       IS-IS for IPv6 (5).

8. Routing protocol interactions

   If the routing-protocol-specific link or node identifiers are used in
   the Link TLV and Node TLV defined above, CR-LDP 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 Notification message
   with the Rerouting TLV toward an ingress LSR, the CR-LDP 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 TLV. The ingress LSR, upon
   receiving this Notification 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.

9. RSVP-TE considerations

   Nothing precludes the use of crankback routing mechanism and LSP
   restoration mechanism with appropriate TLV structures in the RSVP-TE
   messages.

   We illustrate a simple case of setting up an LSP on an explicit route
   from router-A to router-B, in which certain Tspec and Flowspec
   requirements must be met on each link in the LSP.  The steps are as
   follows [RSVP][RSVP-TE]:

   (1) router-A (ingress LSR) sends an RSVP Path message to router-B
   (egress LSR) with

      a) a TSPEC object that specifies the traffic characteristics of
   the data flow that the route-A will generate on the LSP

      b) an EXPLICIT_ROUTE object (ERO) that specifies the explicit
   route of the LSP

   (2) along the way accumulate Adspec to describe the network resources
   available

   (3) at the router-B (the egress LSR) map these to an Rspec to build a
   FLOWSPEC object which includes a service class and the TSPEC object



Iwata, et al.       draft-ietf-mpls-crankback-00.txt           [Page 16]


Internet Draft                                             November 2000


   and the RSPEC object.

   (4) router-B sends the FLOWSPEC object back in a Resv message along
   the specified explicit route, hop-by-hop in reverse order and
   reserves the resources link by link

   Resource allocation failure may occur at two points.

   (a) On the reverse path, as the Resv is processed, resources are
   reserved and, if they are not available on the required link or at a
   specific node, a ResvErr message is returned to the egress node
   (router-B) indicating "Admission Control failure" [RSVP].  Router-B
   is allowed to change the Rspec and try again, but in the event that
   this is not practical or not supported, router-B 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.

   (b) It is also possible to make resource reservations on the forward
   path as the Path message is processed. This choice is made in many
   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".





















Iwata, et al.       draft-ietf-mpls-crankback-00.txt           [Page 17]


Internet Draft                                             November 2000


9.1 Indication of Rerouting Behavior

   The behavior specified by the RtgFlg described in Section 6 is
   achieved in RSVP-TE by a change to the LSP_TUNNEL Session Attribute
   Object.  A new RtgFlg field is added in what was previously a
   reserved area in the object.

   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)      //
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   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



Iwata, et al.       draft-ietf-mpls-crankback-00.txt           [Page 18]


Internet Draft                                             November 2000


       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  Segment-based rerouting (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.


9.2 Rerouting Object

   We define a new object, the "rerouting Object", analagous to the
   "Rerouting TLV" defined in Section 7.1, to explicitly indicate that
   crankback rerouting is allowed at router-A. The new object is added
   to the definition of the PathErr message specifying it as optional.

   When a PathErr message carrying the Rerouting object is received at
   router-A, router-A MAY attempt crankback rerouting. It can choose
   from the following actions.

   - Send PathTear to give up

   - Do nothing to give up (soft state times out)

   - Pick a new route and send a new Path

   - Change the resource requirements and send a new Path message


   The PathErr message is defined as follows:




Iwata, et al.       draft-ietf-mpls-crankback-00.txt           [Page 19]


Internet Draft                                             November 2000


      <PathErr message> ::= <Common Header> [ <INTEGRITY> ]
                            <SESSION> <ERROR_SPEC>
                            [ <REROUTING> ]
                            [ <POLICY_DATA> ...]
                            [ <sender descriptor> ]

   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:  See below for the format.
      Node Rerouting Subobject:  See below for the format.


9.3 Link-Rerouting Subobject

   This subobject is analogous to the Link TLV in Sec.7.2. It may be
   carried in the Rerouting object in a PathErr message.

    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    | Protocol Type |     Num       |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                 Link Identifier Components 1                  |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    ~                         ............                          ~
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                 Link Identifier Components N                  |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type
     The Type indicates the type of contents of the subobject.
     1   Link-Rerouting subobject

   Length
     The length in bytes of the subobject



Iwata, et al.       draft-ietf-mpls-crankback-00.txt           [Page 20]


Internet Draft                                             November 2000


   Protocol Type
     A one-octet unsigned integer containing the unique identifier of a
     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 the ERO, independent of protocols. If a type other than 1 is
     used, or the routing-protocol-specific link identifiers are used,
     the Flag of the SESSION_ATTRIBUTE in the LSP_TUNNEL_IPv4 Session
     Object carried in the Path message must be set 0x10, which implies
     that segment-based rerouting (hierarchical rerouting) is used.

             1:  RSVP-TE for IPv4 (EXPLICIT ROUTE Object)
             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.

   Num: Number of Link Identifier Components
     A one-octet unsigned integer specifying the number of Link
     Identifier Components included in the object.

   One or more Link Identifier Components
     A variable length field containing link identifiers for relevant
     protocol types.

     When the type is RSVP-TE for IPv4 (1), the following format is
     used. The first and second ERO hop upon setup blockage are
     included.

    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 ERO hop                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Second ERO hop                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     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                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



Iwata, et al.       draft-ietf-mpls-crankback-00.txt           [Page 21]


Internet Draft                                             November 2000


     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.

    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.



Iwata, et al.       draft-ietf-mpls-crankback-00.txt           [Page 22]


Internet Draft                                             November 2000


    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).

     IP Interface Address
       The IP address assigned to the interface advertised in IS-IS for
       IPv6 (5).

9.4 Node-Rerouting Subobject

   This subobject is analogous to the Node TLV in Sec.7.3. It may be
   carried in the Rerouting object in a PathErr message.

   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    | Protocol Type |     Num       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 Node Identifier Components 1                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ~                         ............                          ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 Node Identifier Components N                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     Type
       The Type indicates the type of contents of the subobject.
       2   Node-Rerouting subobject

     Length
       The length in bytes of the subobject

   Protocol Type



Iwata, et al.       draft-ietf-mpls-crankback-00.txt           [Page 23]


Internet Draft                                             November 2000


     A one-octet unsigned integer containing the unique identifier of
     the protocol used for QoS routing. The same value as defined in the
     Link-Rerouting subbject is used.

   Num: Number of Node Identifier Components
     A one-octet unsigned integer specifying the number of Node
     Identifier Components included in the object.

   One or mode Node Identifier Components
     A variable length field containing the node identifier for relevant
     protocol types.


     When the type is RSVP-TE for IPv4 (1), the following format is
     used. The first ERO Hop upon setup blockage is included.

    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 ERO Hop                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     When the protocol type is OSPFv2 for IPv4 (2) or OSPF for IPv6 (4),
     the following 4-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                             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     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



Iwata, et al.       draft-ietf-mpls-crankback-00.txt           [Page 24]


Internet Draft                                             November 2000


       IS-IS for IPv6 (5).


9.5 Error Values

   Error values for the Error Code "Admission Control Failure" are
   defined in [RSVP]. It may be appropriate to define new additional
   subcodes to provide additional action information.

   This area is for future study.

9.6 ResvErr Usage

   As described above, the resource allocation failure for RSVP-TE may
   occur when 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.

   This can be achieved by specifying additions to the ResvErr message
   as follows.

      <ResvErr Message> ::= <Common Header> [ <INTEGRITY> ]
                            <SESSION>  <RSVP_HOP>
                            <ERROR_SPEC>
                            [ <SCOPE> ]
                            [ <REROUTING> ]
                            [ <POLICY_DATA> ...]
                            <STYLE> [ <error flow descriptor> ]

   The Rerouting object carried on the ResvErr is exactly as described
   above.

   When a ResvErr carrying a Rerouting object 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, it SHOULD generate a
   PathErr message and send it to the ingress LSR.

   Such a PathErr should contain

      - an Error_Spec object that shows the egress LSR as the Error Node

      - the Rerouting object unchanged from the ResvErr.

9.7 Notify Message Usage

   [GMPLS] defines a new message, the Notify message, to supplement
   error reporting in RSVP-TE networks.  The Notify message is sent to



Iwata, et al.       draft-ietf-mpls-crankback-00.txt           [Page 25]


Internet Draft                                             November 2000


   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 that an LSR that supports [GMPLS] and the crankback
   extensions defined in this draft, it MAY choose to send a Notify
   message in the event of resource allocation failure.  This would
   ensure a speedier report of the error to the ingress/egress LSRs and
   might make LSP restoration faster (see Section 10).

   To facilitate crankback after a Notify message, the Notify message is
   extended to optionally carry the Rerouting object as follows.

      <Notify message> ::= <Common Header> [<INTEGRITY>] <MESSAGE_ID>
                           <ERROR_SPEC>
                           [<REROUTING>]
                           <notify session list>

      <notify session list> :== [<notify session list>] <notify session>

      <notify session> :== <SESSION> [<POLICY_DATA>...]
                           <sender descriptor>

9.8 Backward Compatibility

   It is recognized that not all nodes in an RSVP-TE network will
   necessarily 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.

      o  Class-Num = 11bbbbbb

         The node should ignore the object but forward it,
         unexamined and unmodified, in all messages resulting
         from this message.



Iwata, et al.       draft-ietf-mpls-crankback-00.txt           [Page 26]


Internet Draft                                             November 2000


10. LSP restoration considerations

   LSP restoration is performed to recover the failure of 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 an 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. The detailed procedure for LSP restoration will be described
   in a separate document.

   When an LSR detects a fault on an adjacent downstream link or node, a
   Label Withdraw message is sent upstream over a CR-LSP configured on
   the LSR. Each LSR receiving the message then releases the
   corresponding LSP. If the failed LSP is expected to be restored at an
   upstream LSR, the Rerouting TLV with the location information of the
   failed link or node is included in a Label Withdraw message. The
   ingress or intermediate area border LSR receiving the message can
   terminate these messages and then perform alternate routing.

   On the downstream side of the failure, an LSR detecting the failure
   sends a Label Release message over the CR-LSP configured on the LSR.
   The egress or intermediate area border LSR receiving the message can
   terminate this message and wait until the new Label Request message
   for the LSP restoration is received.

   In a flat network without segmentation, when the ingress LSR receives
   the Label Withdraw 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 Label Request message is sent over
   this path toward the egress LSR. On the other hand, when the egress
   LSR receives the Label release message with the LSPID TLV, whose
   "Routing Behavior Flag" indicates the end-to-end rerouting mode, it
   must wait until the new Label Request message is received.

   In a network segmented into areas such as with hierarchical OSPF, the
   following procedures can be used. As explained in the Section 6, the
   LSP restoration behavior is indicated in the "Routing Behavior Flag"
   (RtgFlg) of the LSPID TLV in the Label Request message. If the
   "Routing Behavior Flag" is set to end-to-end rerouting, the Label
   Withdraw message with the Rerouting TLV is returned all the way back
   to the ingress LSR, which may then issue a new Label Request message
   along another path, which is the same procedure as in the flat



Iwata, et al.       draft-ietf-mpls-crankback-00.txt           [Page 27]


Internet Draft                                             November 2000


   network case above. If the "Routing Behavior Flag" is set to segment-
   based rerouting (hierarchical rerouting), the ingress area border LSR
   must terminate the Label Withdraw message with the Rerouting TLV and
   then perform alternate routing within the area, where the area border
   LSR is located on the ingress side of the area, instead of the
   ingress LSR of the entire network. On the other hand, when the egress
   area border LSR receives the Label release message with the LSPID
   TLV, whose "Routing Behavior Flag" indicates segment-based rerouting
   (hierarchical rerouting), it must wait until the new Label Request
   message is received.

11. Security Considerations

   Both the crankback routing extensions and LSP restoration extensions
   for CR-LDP inherit the same security mechanisms described in Section
   6 of [LDP] and [CR-LDP] to protect against spoofing attacks of an LDP
   session, the privacy of LDP signaling messages, and the denial of
   service (DoS) attacks to well known UDP/TCP ports for LDP sessions.

12. Acknowledgments

   We would like to thank Juha Heinanen and Srinivas Makam for their
   review and comments.

13. References

   [ASH1] G. Ash, "Routing Guidelines for Efficient Routing Methods,"
   work in progress <draft-ash-itu-sg2-routing-guidelines-00.txt>,
   October 1999.

   [ASH2] G. Ash, "Traffic Engineering & QoS methods for IP-, ATM-, &
   TDM-Based Multiservice Networks," work in progress <draft-ash-te-qos-
   routing-01.txt>, July 2000.

   [ASH3] G. Ash, et al., "LSP Modification Using CR-LDP", work in
   progress <draft-ietf-mpls-crlsp-modify-02.txt>, October 2000.

   [ASHW] P. Ashwood-Smith, et al., "Improving Topology Data Base
   Accuracy with LSP Feedback," work in progress <draft-ietf-mpls-te-
   feed-01.txt>, July 2000.

   [AWDUCHE1] D. Awduche, et al., "Requirements for Traffic Engineering
   Over MPLS," RFC2702, September 1999.

   [AWDUCHE2] D. Awduche, et al., "Multi-Protocol Lambda Switching:
    Combining MPLS Traffic Engineering Control With Optical
   Crossconnects", work in progress <draft-awduche-mpls-te-
   optical-02.txt>, July 2000.



Iwata, et al.       draft-ietf-mpls-crankback-00.txt           [Page 28]


Internet Draft                                             November 2000


   [CHAUDHURI] S. Chaudhuri, et al., "Control of Lightpaths in an
   Optical Network," work in progress <draft-chaudhuri-ip-olxc-
   control-00.txt>, February 2000.

   [CR-LDP] B. Jamoussi, et al., "Constraint-Based LSP Setup using LDP,"
   work in progress <draft-ietf-mpls-cr-ldp-04.txt>, July 2000.

   [GMPLS] P. Ashwood-Smith and L. Berger, et al., "Generalized MPLS -
   Signaling Functional Description," work in progress, <draft-ietf-
   mpls- generalized-signaling-00.txt>, October 2000.

   [INTER-AREA-MPLS1] S. Venkatachalam, "OSPF, IS-IS, RSVP, CR-LDP
   extensions to support inter-area traffic engineering using MPLS TE,"
   work in progress, <draft-dharanikota-interarea-mpls-te-ext-01.txt>,
   November 2000.

   [INTER-AREA-MPLS2] S. Venkatachalam, "A Framework for the LSP Setup
   Across IGP Areas for MPLS Traffic Engineering," work in progress,
   <draft-venkatachalam-interarea-mpls-te-01.txt>, November 2000.

   [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," work in progress
   <draft-ietf-isis-ipv6-01.txt>, July 2000.

   [LDP] L. Andersson, et al., "LDP Specification," work in progress
   <draft-ietf-mpls-ldp-11.txt>, August 2000.

   [MAKAM] S. Makam, et al., "Framework for MPLS-based Recovery," work
   in progress <draft-makam-mpls-recovery-frmwrk-01.txt>, July 2000.

   [OSPF] J. Moy, "OSPF Version 2," RFC2328, April 1998.

   [OSPF6] R. Coltun, et al., "OSPF for IPv6," RFC2740, December 1999.

   [PNNI] ATM Forum, "Private Network-Network Interface Specification
   Version 1.0 (PNNI 1.0)," <af-pnni-0055.000>, May 1996.

   [RSVP] R. Braden, et al., "Resource ReSerVation Protocol (RSVP) --
   Version 1 Functional Specification, RFC2205, September 1997.

   [RSVP-TE] D. Awduche, et al., "Extensions to RSVP for LSP Tunnels,"
   work in progress <draft-ietf-mpls-rsvp-lsp-tunnel-07.txt>, March
   2000.

   [SHARMA] V. Sharma, et al., "An Assessment of QoS and Protection in
   MPLS," MPLS'99 Conference, June 1999.



Iwata, et al.       draft-ietf-mpls-crankback-00.txt           [Page 29]


Internet Draft                                             November 2000


14. Authors' Addresses

   Atsushi Iwata
   NEC Corporation
   Computer & Communication Media Research
   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

   Norihito Fujita
   NEC Corporation
   Computer & Communication Media Research
   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

   Adrian Farrel
   Network Convergence Group
   Data Connection Ltd.
   Windsor House
   Pepper Street
   Chester, UK

   Phone: +44-(0)-1244-313440
   Fax:   +44-(0)-1244-312422
   Email: af@dataconnection.com









Iwata, et al.       draft-ietf-mpls-crankback-00.txt           [Page 30]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/