Internet DRAFT - draft-fujita-mpls-crldp-crankback

draft-fujita-mpls-crldp-crankback









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

                                                            July 2000


                Crankback Routing Extensions for CR-LDP

               <draft-fujita-mpls-crldp-crankback-01.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

   This draft proposes crankback routing extensions for CR-LDP
   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 label requests may be blocked by links or nodes without
   sufficient resources. This draft specifies crankback routing
   extensions for CR-LDP 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 proposed crankback routing schemes
   can be also applied to end-to-end LSP restoration by indicating the



Iwata & Fujita  draft-fujita-mpls-crldp-crankback-01.txt        [Page 1]

Internet Draft                                                 July 2000


   location of the failure link or node. This would significantly
   improve the recovery ratio for failed LSPs, especially in situations
   where a large number of setup requests are triggered at the same
   time.

1. Introduction

   CR-LDP (Constraint-based Routing Label Distribution Protocol) is
   defined in [CR-LDP] for establishing explicitly routed LSPs (CR-LSPs)
   in an MPLS network. Using CR-LDP, resources can also be reserved
   along a path to guarantee or control QoS for traffic carried on the
   CR-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], can be extended to distribute
   additional state information [LI]. Explicit paths can be designated
   based on the distributed information at the LSR initiating a CR-LSP
   and, if necessary, intermediate gateway 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. When a setup failure occurs, a notification is returned to
   the setup initiator (ingress LSR). In the current CR-LDP, the ingress
   LSR receiving the notification has to terminate the message and give
   up the LSP establishment.

   If the ingress or intermediate gateway 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, ASH]. We propose the use
   of crankback routing in CR-LDP. 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 [SWALLOW, 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 repair the LSP on an end-to-end basis.
   End-to-end restoration for alternate routing requires the location of
   the failed link or node. A proposed 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. The LSP restoration must therefore be performed
   with inaccurate information, which is likely to cause setup blocking.



Iwata & Fujita  draft-fujita-mpls-crldp-crankback-01.txt        [Page 2]

Internet Draft                                                 July 2000


   Crankback routing would also improve failure recovery in these
   situations.

   Recently, Multi-Protocol Lambda Switching has also been discussed. 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 discusses
   the identification of blocked links or nodes in an MPLS network.

   Although we address CR-LDP as the label distribution technique in the
   following, a similar discussion can be applied to TE-RSVP [TE-RSVP].

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 notification error messages [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
   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



Iwata & Fujita  draft-fujita-mpls-crldp-crankback-01.txt        [Page 3]

Internet Draft                                                 July 2000


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



Iwata & Fujita  draft-fujita-mpls-crldp-crankback-01.txt        [Page 4]

Internet Draft                                                 July 2000


   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

   Crankback routing can be performed in the following situation.

     a. A setup request is blocked.

     b. An established LSP fails.

   Although crankback routing can be done on a hop-by-hop basis, which
   may be useful for fast restoration, we address source-route based
   crankback routing in this draft.

3.1. Crankback Routing due to Setup Request Blockage

   When a label request is blocked due to unavailable resources, a
   notification message with a Rerouting TLV with the location
   identifier of the blockage, is returned to the LSR initiating the
   label request (ingress LSR). The notification message is called a
   "crankback notification". It may include information such as
   bandwidth availability, as described in [ASHW]. This issue is left
   for further study.

   In a flat network without segmentation, the ingress LSR receives the
   message and 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 is sent
   over this path. In a network segmented into areas such as
   hierarchical OSPF, the area border node may terminate the crankback
   notification and then perform alternate routing instead of the
   ingress LSR.

   The LSR that computed the alternate path stores the location



Iwata & Fujita  draft-fujita-mpls-crldp-crankback-01.txt        [Page 5]

Internet Draft                                                 July 2000


   identifiers of the blockages indicated in a crankback notification
   until it receives a corresponding label mapping message. Upon
   receiving a crankback notification again after retrying a label
   request, another alternate path is computed based on the previous
   blocked links or nodes in the stored information as well as the
   current ones in the received notification message.

   Optionally, the maximum number of crankback routing allowed for
   establishing an LSP may be limited. This is useful to prevent a
   endless repetition of crankback routing in certain error conditions.
   It is also useful for reducing the number of unnecessary retries,
   which do not improve performance. When crankback notifications exceed
   the threshold, the message that exceeded the threshold is processed
   as an ordinary (non-crankback) notification and no more label
   requests are issued. Other mechanisms for controlling crankback
   routing can also be used.

3.2. Crankback Routing due to LSP Failures

   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
   fault link or node is included in a label withdraw message. The
   ingress or intermediate gateway LSR receiving the message can
   terminate this messages and then perform alternate routing.

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

   Other behaviors are the same as those of performing crankback routing
   upon setup request blockage.

4. Explicit indication code of rerouting

   Crankback rerouting action is indicated in the Status TLV in the
   Notification message [CR-LDP]. Following is a new status code for the
   Status TLV. The exact value of YY will be defined. When an ingress
   LSR receiving this Status TLV does not support the rerouting
   functions explained above, this TLV is allowed to be silently
   ignored.

    Status Code                                       Type
    --------------------------------------         ----------



Iwata & Fujita  draft-fujita-mpls-crldp-crankback-01.txt        [Page 6]

Internet Draft                                                 July 2000


    Alternate rerouting should be attempted        0x440000YY


5. Location Identifiers of Blocked Links or Nodes

   In order to compute an alternate path by crankback routing, 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 propose 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,
   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 a crankback notification. Upon a link
   blockage, the first and second ER-Hop TLVs is 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 gateway 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 and IS-IS, 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 protocol-specific link or node
   identifiers that can be used for multiple routing protocols. In this
   draft, we specify identifications for OSPF and IS-IS. Extension for
   other routing protocols, such as BGP, etc., can be easily applied but
   is left for further study.

   Although a general link/node identifier in a network is preferable,
   it is difficult to specify it because MPLS signaling protocols are



Iwata & Fujita  draft-fujita-mpls-crldp-crankback-01.txt        [Page 7]

Internet Draft                                                 July 2000


   independent of routing protocols. This issue is left for further
   study.


6. Additional TLVs

   In this section, we define additional TLVs included in notification
   and label withdraw messages for indicating the location of blocked
   links or blocked nodes.

6.1. Rerouting TLV

   When resource allocation for a label request 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
   can be added to the current defined ones to give more detail about
   the blockage such as "Reserved" and "Heavily Loaded" [ASH].

   If LSP restoration is supported, the Rerouting TLV is included in
   label withdraw messages caused by network failures. The message must
   also carry the LSPID TLV of the corresponding CR-LSP. The Status TLV
   can be also included to indicate the cause of the problem.

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

6.2. Link TLV

   The Link TLV is used to identify a link 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



Iwata & Fujita  draft-fujita-mpls-crldp-crankback-01.txt        [Page 8]

Internet Draft                                                 July 2000


   |0|0|       Link (TBD)          |            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.

             1:  CR-LDP (ER-Hop TLVs)
             2:  OSPF
             3:  IS-IS
       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 OSPF (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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



Iwata & Fujita  draft-fujita-mpls-crldp-crankback-01.txt        [Page 9]

Internet Draft                                                 July 2000


   |                         Router ID                             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          Link ID                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     Router ID
       The same value as the Router ID used in OSPF.

     Link ID
       The same value as the Link ID used in OSPF.

     When the protocol type is IS-IS (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.

     IP Interface Address
       The IP address assigned to the interface advertised in IS-IS.

6.3. Node TLV

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



Iwata & Fujita  draft-fujita-mpls-crldp-crankback-01.txt        [Page 10]

Internet Draft                                                 July 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 OSPF (2), 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 OSPF.

     When the protocol type is IS-IS (3), 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.




Iwata & Fujita  draft-fujita-mpls-crldp-crankback-01.txt        [Page 11]

Internet Draft                                                 July 2000


7. Security Considerations

   Security considerations are not addressed in this version of the
   draft.

8. Acknowledgments

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

9. References

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

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

   [LI] T. Li, G. Swallow, D. Awduche, "IGP Requirements for Traffic
   Engineering with MPLS", <draft-li-mpls-igp-te-00.txt>, February 1999.

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

   [ASH] G. Ash, B. Jamoussi, Y. Lee, O. Aboul-Magd, "QoS Resource
   Management in MPLS-Based Networks", <draft-ash-qos-routing-00.txt>,
   February 1999.

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

   [SWALLOW] R. Goguen, G. Swallow, "RSVP Label Allocation for Backup
   Tunnels", <draft-swallow-rsvp-bypass-label-00.txt>, October 1999.

   [MAKAM] S. Makam, V. Sharma, K. Owens, C. Huang,
   "Protection/Restoration of MPLS Networks", <draft-makam-mpls-
   protection-00.txt>, October 1999.

   [SHARMA] V. Sharma, C. Huang, S. Makam, K. Owens, "An Assessment of
   QoS and Protection in MPLS", MPLS'99 Conference, June 1999.

   [CHAUDHURI] S. Chaudhuri, G. Hjalmtysson, J. Yates, "Control of
   Lightpaths in an Optical Network", <draft-chaudhuri-ip-olxc-
   control-00.txt>, February 2000.

   [TE-RSVP] D. Awduche, L. Berger, D. Gan, T. Li, G. Swallow, V.
   Srinvasan, "Extensions to RSVP for LSP Tunnels", <draft-ietf-mpls-
   rsvp-lsp-tunnel-06.txt>, July 2000.



Iwata & Fujita  draft-fujita-mpls-crldp-crankback-01.txt        [Page 12]

Internet Draft                                                 July 2000


   [ASHW] P. Ashwood-Smith, B. Jamoussi, D. Fedyk, D. Skalecki,
   "IMPROVING TOPOLOGY DATA BASE ACCURACY WITH LSP FEEDBACK VIA CR-LDP",
   <draft-ietf-mpls-te-feed-00.txt>, February 2000.

9. 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: iwata@ccm.cl.nec.co.jp

   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@ccm.cl.nec.co.jp

   Gerald R. Ash
   AT&T
   Room MT E3-3C37
   200 Laurel Avenue
   Middletown, NJ 07748, USA

   Phone: +1 732 420-4578
   Fax:   +1 732 440-6687
   Email: gash@att.com
















Iwata & Fujita  draft-fujita-mpls-crldp-crankback-01.txt        [Page 13]