Internet DRAFT - draft-wimer-mpls-atm-rsvp

draft-wimer-mpls-atm-rsvp



HTTP/1.1 200 OK
Date: Tue, 09 Apr 2002 12:12:21 GMT
Server: Apache/1.3.20 (Unix)
Last-Modified: Fri, 28 May 1999 11:36:42 GMT
ETag: "2e6b4e-9450-374e7fca"
Accept-Ranges: bytes
Content-Length: 37968
Connection: close
Content-Type: text/plain

Internet Draft                                                  W. Wimer
Expires: December 31, 1999                            FORE Systems, Inc.
<draft-wimer-mpls-atm-rsvp-00.txt>                             June 1999

                  MPLS Using RSVP and ATM VC Switching

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

   The MPLS Architecture [MPLS-ARCH] discusses a way in which ATM
   switches may be used as Label Switching Routers.  The ATM switches
   run network layer routing algorithms (such as OSPF, IS-IS, etc.), and
   their data forwarding is based on the results of these routing
   algorithms.  Additional ATM-specific routing and addressing is
   optional but not required.  ATM switches used in this way are known
   as ATM-LSRs.

   This document extends and clarifies the relevant portions of [MPLS-
   ARCH] and [LSP-TUNNEL] by specifying in more detail the procedures to
   be used for distributing labels to or from ATM-LSRs, when those
   labels represent LSP tunnels setup via the RSVP protocol with MPLS
   extensions [LSP-TUNNEL].

   This document also specifies the MPLS encapsulation to be used when
   sending labeled packets to or from ATM-LSRs, and in that respect is a
   companion document to [MPLS-ENCAPS].

Wimer                  Expires December 31, 1999                [Page 1]

Internet Draft      draft-wimer-mpls-atm-rsvp-00.txt           June 1999

Contents

           Acknowledgements  .......................................   2
    1      Introduction  ...........................................   2
    2      Specification of Requirements  ..........................   3
    3      Definitions  ............................................   3
    4      Special Characteristics of ATM Switches  ................   4
    5      Label Switching Control Component for ATM  ..............   5
    6      Hybrid Switches (Ships in the Night)  ...................   5
    7      Use of  VPI/VCIs  .......................................   5
    7.1    Direct Connections  .....................................   6
    7.2    Connections via an ATM Virtual Path  ....................   7
    7.3    Connections via an ATM SVC  .............................   8
    8      Encapsulation  ..........................................  12
    9      RSVP Hop Count Object  ..................................  14
   10      TTL Manipulation  .......................................  16
   11      Security Considerations  ................................  17
   12      References  .............................................  17
   13      Author's Address  .......................................  18

Acknowledgments

   Several portions of this document have been adapted from "MPLS using
   LDP and ATM VC Switching" <draft-ietf-mpls-atm-02.txt> by Bruce
   Davie, Jeremy Lawrence, Keith McCloghrie, Yakov Rekhter, Eric Rosen,
   George Swallow, and Paul Doolan.  Other contributors to that document
   include Anthony Alles, Fred Baker, Dino Farinacci, Guy Fedorkow,
   Arthur Lin, Morgan Littlewood, and Dan Tappan.  These efforts are
   gratefully acknowledged.

1. Introduction

   The MPLS Architecture [MPLS-ARCH] discusses a way in which ATM
   switches may be used as Label Switching Routers.  The ATM switches
   run network layer routing algorithms (such as OSPF, IS-IS, etc.), and
   their data forwarding is based on the results of these routing
   algorithms.  Additional ATM-specific routing and addressing is
   optional but not required.  ATM switches used in this way are known
   as ATM-LSRs.

   This document extends and clarifies the relevant portions of [MPLS-
   ARCH] and [LSP-TUNNEL] by specifying in more detail the procedures to
   be used for distributing labels to or from ATM-LSRs, when those
   labels represent LSP tunnels setup via the RSVP protocol with MPLS
   extensions [LSP-TUNNEL].  The label distribution technique described
   here is referred to in [MPLS-ARCH] as "downstream-on-demand".

Wimer                  Expires December 31, 1999                [Page 2]

Internet Draft      draft-wimer-mpls-atm-rsvp-00.txt           June 1999

   This document does NOT specify the label distribution techniques to
   be used in the following cases:

     - the routes are chosen on a hop-by-hop basis as label distribution
       proceeds, rather than being explicitly chosen before label
       distribution begins,

     - the labels represent FECs that consist of multicast packets,

     - the LSRs use "VP merge".

   Further statements made in this document about ATM-LSR label
   distribution do not necessarily apply in these cases.

   This document also specifies the MPLS encapsulation to be used when
   sending labeled packets to or from ATM-LSRs, and in that respect is a
   companion document to [MPLS-ENCAPS].  The specified encapsulation is
   the same as that used for multicast or hop-by-hop routed labeled
   packets.  [MPLS-LDP-ATM]

   This document uses terminology from [MPLS-ARCH].

2. Specification of Requirements

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [REQUIRE].

3. Definitions

   A Label Switching Router (LSR) is a device which implements the label
   switching control and forwarding components described in [MPLS-ARCH].

   A label switching controlled ATM (LC-ATM) interface is an ATM
   interface controlled by the label switching control component.  When
   a packet traversing such an interface is received, it is treated as a
   labeled packet.  The packet's top label is inferred either from the
   contents of the VCI field or the combined contents of the VPI and VCI
   fields.  Local configuration parameters control which particular
   discipline is used between a given pair of LSRs interconnected by
   LC-ATM interfaces.

   An ATM-LSR is a LSR with a number of LC-ATM interfaces which forwards
   cells between these interfaces using labels carried in the VCI or
   VPI/VCI field.

Wimer                  Expires December 31, 1999                [Page 3]

Internet Draft      draft-wimer-mpls-atm-rsvp-00.txt           June 1999

   A frame-based LSR is a LSR which forwards complete frames between its
   interfaces.  Note that such a LSR may have zero, one or more LC-ATM
   interfaces.

   Sometimes a single box may behave as an ATM-LSR with respect to
   certain pairs of interfaces, but may behave as a frame-based LSR with
   respect to other pairs.  For example, an ATM switch with an ethernet
   interface may function as an ATM-LSR when forwarding cells between
   its LC-ATM interfaces, but may function as a frame-based LSR when
   forwarding frames from its ethernet to one of its LC-ATM interfaces.
   In such cases, one can consider the two functions (ATM-LSR and
   frame-based LSR) as being coresident in a single box.

   It is intended that an LC-ATM interface be used to connect two ATM-
   LSRs, or to connect an ATM-LSR to a frame-based LSR.  The use of an
   LC-ATM interface to connect two frame-based LSRs is not considered in
   this document.

   An ATM-LSR domain is a set of ATM-LSRs which are mutually
   interconnected by LC-ATM interfaces.

   The Edge Set of an ATM-LSR domain is the set of frame-based LSRs
   which are connected to members of the domain by LC-ATM interfaces.  A
   frame-based LSR which is a member of an Edge Set of an ATM-LSR domain
   may be called an Edge LSR.

   VC-merge is the process by which a switch receives cells on several
   incoming VCIs and transmits them on a single outgoing VCI without
   causing the cells of different AAL5 PDUs to become interleaved.

4. Special Characteristics of ATM Switches

   While the MPLS architecture permits considerable flexibility in LSR
   implementation, an ATM-LSR is constrained by the capabilities of the
   (possibly pre-existing) hardware and the restrictions on such matters
   as cell format imposed by ATM standards. Because of these
   constraints, some special procedures are required for ATM-LSRs.

   Some of the key features of ATM switches that affect their behavior
   as LSRs are:

     - the label swapping function is performed on fields (the VCI
       and/or VPI) in the cell header; this dictates the size and
       placement of the label(s) in a packet.

     - multipoint-to-point and multipoint-to-multipoint VCs are
       generally not supported. This means that most switches cannot

Wimer                  Expires December 31, 1999                [Page 4]

Internet Draft      draft-wimer-mpls-atm-rsvp-00.txt           June 1999

       support 'VC-merge' as defined above.

     - there is generally no capability to perform a 'TTL-decrement'
       function as is performed on IP headers in routers.

   This document describes ways of applying label switching to ATM
   switches which work within these constraints.

5. Label Switching Control Component for ATM

   To support label switching, an ATM switch MUST implement the control
   component of label switching.  This consists primarily of label
   allocation, distribution, and maintenance procedures.  Label binding
   information may be communicated by several mechanisms.  This document
   is concerned with the application of the RSVP protocol (with LSP
   tunnel extensions) to ATM-LSRs.

   In some cases, LSRs make use of other protocols (e.g. LDP, PIM, BGP)
   to distribute label bindings.  In these cases, an ATM-LSR would need
   to participate in these protocols.  However, these are not explicitly
   considered in this document.

   Support of label switching on an ATM switch does NOT require the
   switch to support the ATM control component defined by the ITU and
   ATM Forum (e.g., UNI, PNNI).  An ATM-LSR may OPTIONALLY respond to
   OAM cells.

6. Hybrid Switches (Ships in the Night)

   The existence of the label switching control component on an ATM
   switch does not preclude the ability to support the ATM control
   component defined by the ITU and ATM Forum on the same switch and the
   same interfaces.  The two control components, label switching and the
   ITU/ATM Forum defined, would operate independently.

   Definition of how such a device operates is beyond the scope of this
   document.  However, only a small amount of information needs to be
   consistent between the two control components, such as the portions
   of the VPI/VCI space which are available to each component.

7. Use of VPI/VCIs

   Label switching is accomplished by associating labels with LSP
   tunnels, and using the label value to forward packets, including
   determining the value of any replacement label.  See [MPLS-ARCH] and
   [LSP-TUNNEL] for further details.  In an ATM-LSR, the label is

Wimer                  Expires December 31, 1999                [Page 5]

Internet Draft      draft-wimer-mpls-atm-rsvp-00.txt           June 1999

   carried in the VPI/VCI field, or, when two ATM-LSRs are connected via
   an ATM "Virtual Path", in the VCI field.

   Labeled packets MUST be transmitted using the null encapsulation, as
   defined in Section 5.1 of RFC 1483 [RFC1483].

   In addition, if two peer LSRs are connected via an LC-ATM interface,
   a non-MPLS connection, capable of carrying unlabelled IP packets,
   MUST be available.  This non-MPLS connection is used to carry RSVP
   packets between the two peers, and MAY also be used (but is not
   required to be used) for other unlabeled packets (such as OSPF
   packets, etc.).  The LLC/SNAP encapsulation of RFC 1483 [RFC1483]
   MUST be used on the non-MPLS connection.

   It SHOULD be possible to configure an LC-ATM interface with
   additional VPI/VCIs that are used to carry control information or
   non-labelled packets.  In that case, the VCI values MUST be in the
   0-32 range.  These may use either the null encapsulation, as defined
   in Section 5.1 of RFC 1483 [RFC1483], or the LLC/SNAP encapsulation,
   as defined in Section 4.1 of RFC 1483 [RFC1483].

7.1. Direct Connections

   We say that two LSRs are "directly connected" over an LC-ATM
   interface if all cells transmitted out that interface by one LSR will
   reach the other, and there are no ATM switches between the two LSRs.

   When two LSRs are directly connected via an LC-ATM interface, they
   jointly control the allocation of VPIs/VCIs on the interface
   connecting them.  They may agree to use the VPI/VCI field to encode a
   single label.

   The default VPI/VCI value for the non-MPLS connection is VPI 0, VCI
   32.  Other values can be configured, as long as both parties are
   aware of the configured value.

   A VPI/VCI value whose VCI part is in the range 0-32 inclusive MUST
   NOT be used as the encoding of a label.

   With the exception of these reserved values, the VPI/VCI values used
   in the two directions of the link MAY be treated as independent
   spaces.

   The allowable range of VPI/VCIs is communicated through RSVP using
   the "Label Request with ATM Label Range" object.

   When signaling LSP setup between a pair of LSRs directly connected

Wimer                  Expires December 31, 1999                [Page 6]

Internet Draft      draft-wimer-mpls-atm-rsvp-00.txt           June 1999

   via LC-ATM interfaces, the VPI and VCI values are encoded as the top
   label within the RSVP Label Object as shown below.  (Note that [LSP-
   TUNNEL] encodes the label stack object such that the top label
   appears in the rightmost 4 octets of the label object.)  The field
   marked "MBZ" is reserved for future use; it must be zero when
   transmitted and must be ignored upon receipt.

      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     //          (Object contents: remainder of label stack)         //
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  MBZ  |         VPI           |              VCI              |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

7.2. Connections via an ATM Virtual Path

   Sometimes it can be useful to treat two LSRs as adjacent (in some
   LSP) across an LC-ATM interface, even though the connection between
   them is made through an ATM "cloud" via an ATM Virtual Path.  In this
   case, the VPI field is not available to MPLS, and the label MUST be
   encoded entirely within the VCI field.

   In this case, the default VCI value of the non-MPLS connection
   between the LSRs is 32.  The VPI is set to whatever is required to
   make use of the Virtual Path.

   A VPI/VCI value whose VCI part is in the range 0-32 inclusive MUST
   NOT be used as the encoding of a label.

   With the exception of these reserved values, the VPI/VCI values used
   in the two directions of the link MAY be treated as independent
   spaces.

   The allowable range of VPI/VCIs is communicated through RSVP.  If
   more than one VPI is used for label switching, the allowable range of
   VCIs may be different for each VPI.  For each independent RSVP
   session, a suitable range is communicated using the "Label Request
   with ATM Label Range" object.

   When signaling LSP setup between a pair of LSRs connected via an ATM
   Virtual Path, the VPI and VCI values are encoded as the top label
   within the RSVP Label Object as shown below.  (Note that [LSP-TUNNEL]
   encodes the label stack object such that the top label appears in the
   rightmost 4 octets of the label object.)  The field marked "MBZ" is

Wimer                  Expires December 31, 1999                [Page 7]

Internet Draft      draft-wimer-mpls-atm-rsvp-00.txt           June 1999

   reserved for future use; it must be zero when transmitted and must be
   ignored upon receipt.

      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     //          (Object contents: remainder of label stack)         //
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  MBZ  |         VPI           |              VCI              |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

7.3. Connections via an ATM SVC

   Sometimes it may be useful to treat two LSRs as adjacent (in some
   LSP) across an LC-ATM interface, even though the connection between
   them is made through an ATM "cloud" via a set of ATM Switched Virtual
   Circuits.

   In this case, there is no default VPI or VCI value for the non-MPLS
   connection.

   In general, an ATM SVC will not have the same VPI/VCI values at each
   of its endpoints.  [VCID] discusses a procedure for exchanging an
   end-to-end identifier called a VCID.  The VCID is communicated
   through RSVP as if it were the label value.  [GIT] offers a mechanism
   for communicating the VCID within ATM signaling messages, thus
   providing a mapping between the VCID and the SVC being established.
   The top label of a received MPLS data packet is then inferred (via a
   one-to-one mapping) from the virtual circuit on which the packet
   arrived:

         SVC's Local VPI/VCI <---> VCID <---> NHLFE / RSVP state

   This document recommends a particular combination of the above
   techniques and details the interactions involved.

   [VCID] proposes a model in which an upstream LSR chooses a VCID value
   and then communicates that VCID value to the downstream LSR either
   during ATM SVC establishment or shortly thereafter.  The downstream
   LSR must then return that particular VCID value in subsequent label
   mapping messages.  Note that the downstream LSR thus has no choice in
   label assignment.  In contrast, this document recommends a model more
   consistent with downstream label assignment.  In particular, the
   downstream LSR chooses the VCID and passes it to the upstream LSR in
   RSVP Resv messages, before any ATM signaling is performed.  When the

Wimer                  Expires December 31, 1999                [Page 8]

Internet Draft      draft-wimer-mpls-atm-rsvp-00.txt           June 1999

   upstream LSR receives the Resv message, it then initiates an ATM
   Setup message toward the downstream LSR and includes the VCID within
   the Generic Identifier Information Element within the ATM Setup
   message.

   [GIT] suggests a number of techniques for carrying IP-related
   information within ATM signaling messages.  Included is an approach
   for encapsulating RSVP messages entirely within ATM signaling
   messages using the User-to-User Signaling Information Element.
   However, this document recommends against the use of this particular
   approach for two reasons.  First, complex RSVP messages may exceed
   the information element's 133-octet length restriction.  Second,
   certain RSVP messages (state refreshes, errors, etc.) need to be sent
   at times other than initial connection-establishment time.  Thus a
   separate non-ATM-signaling mechanism would be needed for these
   messages anyway.  The use of a single transport mechanism (the non-
   MPLS connection) for all RSVP messages seems preferable to the use of
   two separate mechanisms.

   This document recommends sending RSVP messages over the normal
   unlabeled VC and recommends a downstream label-assignment discipline.

   The RSVP exchange proceeds as follows:

                          |-----ATM SVC Cloud----|

                        LSR u                  LSR d
                          |                      |
     ...----Path--------->|                      |
                          |--------Path--------->|
                          |                      |--------Path----->...
                          |                      |
                          |                      |<---Resv w/label--...
                          |<--Resv w/label=VCID--|
                          |                      |
                          |---ATM Setup w/VCID-->|
                          |                      |
                          |<-ATM Connect w/VCID--|
     ...<--Resv w/label---|                      |
                          |                      |

Wimer                  Expires December 31, 1999                [Page 9]

Internet Draft      draft-wimer-mpls-atm-rsvp-00.txt           June 1999

   The full procedure is:

       1.  In general, LSRs u and d receive and forward RSVP Path
           messages according to [LSP-TUNNEL].  When LSR u forwards a
           Path message to LSR d, LSR u uses its non-MPLS connection to
           LSR d.  The "Label Request without Label Range" object
           (C_Type = 1) is used in the Path message (not the "Label
           Request with ATM Label Range" (C_Type = 2)).

       2.  Eventually, LSR d receives an RSVP Resv message from its
           downstream LSR (or LSR d is the end of the LSP tunnel).

       3.  LSR d allocates a label=VCID in the range 16 to 1048575 and
           records the label in the appropriate state block for this LSP
           tunnel.

       4.  Using its non-MPLS connection to LSR u, LSR d forwards the
           Resv message to LSR u containing the label=VCID in the Label
           Object.

       5.  LSR u receives the RSVP Resv message from LSR d and records
           it in its appropriate state block for this LSP tunnel.

       6.  LSR u initiates an ATM Setup message (with appropriate QoS
           parameters) toward LSR d.  It includes the VCID value in the
           Setup message, encoded in the Generic Identifier Information
           Element [GIT].  The "standard/application" field is coded as
           0x06 (MPLS) and the "identifier type" field is coded as 0x02
           (Resource).  Only the first such Generic Identifier is
           considered significant; additional MPLS+Resource entries MUST
           be ignored.  See below and [GIT] for the format of the
           Generic Identifier information element.

       7.  LSR d receives the incoming ATM Setup message and uses the
           included VCID value to locate the corresponding state block.
           This allows LSR d to associate the VPI/VCI of the new
           incoming SVC with the appropriate state block and Next Hop
           Label Forwarding Entry (NHLFE).

       8.  LSR d responds with an ATM Connect message and "echos" back
           the Generic Identifier information element containing the
           received VCID value.  This serves as a confirmation to LSR u
           that the VCID has been successfully received.

Wimer                  Expires December 31, 1999               [Page 10]

Internet Draft      draft-wimer-mpls-atm-rsvp-00.txt           June 1999

   The encoding of the VCID within the Generic Identifier Information
   Element is:

                                 Bits
              8     7     6     5     4     3     2     1    Octets
           +-----+-----+-----+-----+-----+-----+-----+-----+
           |        Information element identifier         |
           |    = Generic identifier transport IE (0x7F)   |  1
           +-----+-----+-----+-----+-----+-----+-----+-----+
           |  1  |   Coding  |    IE instruction field     |
           | Ext |  standard |Flag |Res. |  IE action ind. |  2
           +-----+-----+-----+-----+-----+-----+-----+-----+
           |   Length of contents of information element   |  3-4
           +-----+-----+-----+-----+-----+-----+-----+-----+
           |    Identifier related standard/application    |
           |               = MPLS (0x06)                   |  5
           +-----+-----+-----+-----+-----+-----+-----+-----+
           |                Identifier type                |
           |               = Resource (0x02)               |  6
           +-----+-----+-----+-----+-----+-----+-----+-----+
           |               Identifier length               |
           |               = 4 octets (0x04)               |  7
           +-----+-----+-----+-----+-----+-----+-----+-----+
           |                                               |  8
           |              MPLS VCID (4 octets)             |  9
           |                                               | 10
           |                                               | 11
           +-----+-----+-----+-----+-----+-----+-----+-----+

            The Identifier type field is Resource (0x02).

            The Identifier length is 4 octets.

            The MPLS VCID [12] is assigned to the Identifier value field.

Wimer                  Expires December 31, 1999               [Page 11]

Internet Draft      draft-wimer-mpls-atm-rsvp-00.txt           June 1999

   When signaling LSP setup between a pair of LSRs connected via ATM
   SVCs, the VPI and VCI values are encoded as the top label within the
   RSVP Label Object as shown below.  (Note that [LSP-TUNNEL] encodes
   the label stack object such that the top label appears in the
   rightmost 4 octets of the label object.)  The field marked "MBZ" is
   reserved for future use; it must be zero when transmitted and must be
   ignored upon receipt.

   NOTE: This is the same as the normal label encoding in [LSP-TUNNEL].

      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     //          (Object contents: remainder of label stack)         //
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |       MBZ     |                     VCID                      |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

8. Encapsulation

   The procedures described in this section affect only the Edge LSRs of
   the ATM-LSR domain.  The ATM-LSRs themselves do not modify the
   encapsulation in any way.

   Labeled packets MUST be transmitted using the null encapsulation of
   Section 5.1 of RFC 1483 [RFC1483].

   Except in certain circumstances specified below, when a labeled
   packet is transmitted on an LC-ATM interface, where the VPI/VCI (or
   VCID) is interpreted as the top label in the label stack, the packet
   MUST also contain a "shim header" [MPLS-ENCAPS].

   If the packet has a label stack with n entries, it MUST carry a shim
   with n entries.  The actual value of the top label is encoded in the
   VPI/VCI field.  The label value of the top entry in the shim (which
   is just a "placeholder" entry) MUST be set to 0 upon transmission,
   and MUST be ignored upon reception.  The packet's outgoing TTL, and
   its CoS, are carried in the TTL and CoS fields respectively of the
   top stack entry in the shim.

   Note that if a packet has a label stack with only one entry, this
   requires it to have a single-entry shim (4 bytes), even though the
   actual label value is encoded into the VPI/VCI field.  This is done
   to ensure that the packet always has a shim.  Otherwise, there would
   be no way to determine whether it had one or not, i.e., no way to

Wimer                  Expires December 31, 1999               [Page 12]

Internet Draft      draft-wimer-mpls-atm-rsvp-00.txt           June 1999

   determine whether there are additional label stack entries.

   The only ways to eliminate this extra overhead are:

     - through apriori knowledge that packets have only a single label
       (e.g., perhaps the network only supports one level of label)

     - by using two VCs per FEC, one for those packets which have only a
       single label, and one for those packets which have more than one
       label

   The second technique would require that there be some way of
   signalling via RSVP that the VC is carrying only packets with a
   single label, and is not carrying a shim.  When supporting VC merge,
   one would also have to take care not to merge a VC on which the shim
   is not used into a VC on which it is used, or vice versa.

   Note that if the shim header is not present, the outgoing TTL is
   carried in the TTL field of the network layer header.

Wimer                  Expires December 31, 1999               [Page 13]

Internet Draft      draft-wimer-mpls-atm-rsvp-00.txt           June 1999

9. RSVP Hop Count Object

   The Resv message is augmented with a <HOP_COUNT> object for use
   across ATM-LSR domains.

   The format of the Resv message is as follows:

   <Resv Message> ::= <Common Header> [ <INTEGRITY> ]
                      <SESSION>  <RSVP_HOP>
                      <TIME_VALUES>
                      [ <RESV_CONFIRM> ]  [ <SCOPE> ]
                      [ <POLICY_DATA> ... ]
                      <STYLE> <flow descriptor list>

   <flow descriptor list> ::= <FF flow descriptor list>
                            | <SE filter spec list>

   <FF flow descriptor list> ::= <FF flow descriptor>
                               | <FF flow descriptor list> <FF flow descriptor>

   <FF flow descriptor> ::= [ <FLOWSPEC> ] <FILTER_SPEC> <LABEL>
                            [ <RECORD_ROUTE> ]  [ <HOP_COUNT> ]

   <SE flow descriptor> ::= <FLOWSPEC> <SE filter spec list>

   <SE filter spec list> ::= <SE filter spec>
                           | <SE filter spec list> <SE filter spec>

   <SE filter spec> ::= <FILTER_SPEC> <LABEL> [ <RECORD_ROUTE> ]
                        [ <HOP_COUNT> ]

   Note:  LABEL, RECORD_ROUTE (if present), and HOP_COUNT (if present)
          are bound to the preceding FILTER_SPEC.  No more than one
          occurrence of each of LABEL, RECORD_ROUTE, and HOP_COUNT
          may follow each FILTER_SPEC.

   The HOP_COUNT object format is shown below.

   class = 20, C_Type = 1  (need to get an official class num from
                            the IANA)

      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                    Reserved                   |   Hop Count   |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Wimer                  Expires December 31, 1999               [Page 14]

Internet Draft      draft-wimer-mpls-atm-rsvp-00.txt           June 1999

         Reserved

            This field is reserved.  It must be set to zero on
            transmission and must be ignored on receipt.

         Hop Count

            1 octet unsigned integer hop count value.

   The HOP_COUNT object is carried in Resv messages.

   When an LSR forwards a Resv message with a Label object from a
   frame-based interface to an LC-ATM interface, the LSR adds a
   HOP_COUNT object to the Resv message and initializes its value to 1.
   Similarly, if the LSR is the termination point of an LSP tunnel, is
   generating a Resv message in response to a Path message, and is
   transmitting the Resv message out an LC-ATM interface, the LSR adds a
   HOP_COUNT object to the Resv message and initializes its value to 1.

   When an LSR receives a Resv message with a HOP_COUNT object on an
   LC-ATM interface and forwards the message out an LC-ATM interface,
   the LSR MUST increment the value of the hop count within the
   HOP_COUNT object.

   When an LSR forwards a Resv message with a HOP_COUNT object from an
   LC-ATM interface to a frame-based interface, the LSR removes the
   HOP_COUNT object from the Resv message and records its value in the
   appropriate state block.  Similarly, if the LSR is the origination
   point of an LSP tunnel, is receiving a Resv message in response to a
   Path message, and is receiving the Resv message on an LC-ATM
   interface, the LSR records the value of the HOP_COUNT object in the
   appropriate state block.

   The following table summarizes this behavior:

     Incoming   Outgoing
     interface  interface  Action
     --------------------------------------------------------------------
      --        LC-ATM     Add HOP_COUNT=1 object
     Frame      LC-ATM     Add HOP_COUNT=1 object
     LC-ATM     LC-ATM     Increment HOP_COUNT object
     LC-ATM     Frame      Remove HOP_COUNT object, record in state block
     LC-ATM      --        Record in state block

Wimer                  Expires December 31, 1999               [Page 15]

Internet Draft      draft-wimer-mpls-atm-rsvp-00.txt           June 1999

10. TTL Manipulation

   The procedures described in this section affect only the Edge LSRs of
   the ATM-LSR domain.  The ATM-LSRs themselves do not modify the TTL in
   any way.

   The details of the TTL adjustment procedure are as follows.  If a
   packet was received by the Edge LSR as an unlabeled packet, the
   "incoming TTL" comes from the IP header.  (Procedures for other
   network layer protocols are for further study.) If a packet was
   received by the Edge LSR as a labeled packet, using the encapsulation
   specified in [MPLS-ENCAPS], the "incoming TTL" comes from the entry
   at the top of the label stack.

   If a hop count has been associated with the label binding that is
   used when the packet is forwarded, the "outgoing TTL" is set to the
   larger of (a) 0 or (b) the difference between the incoming TTL and
   the hop count.  If a hop count has not been associated with the label
   binding that is used when the packet is forwarded, the "outgoing TTL"
   is set to the larger of (a) 0 or (b) one less than the incoming TTL.

   If this causes the outgoing TTL to become zero, the packet MUST NOT
   be transmitted as a labeled packet using the specified label.  The
   packet can be treated in one of two ways:

     - it may be treated as having expired; this may cause an ICMP
       message to be transmitted;

     - the packet may be forwarded, as an unlabeled packet, with a TTL
       that is 1 less than the incoming TTL; such forwarding would need
       to be done over a non-MPLS connection.

   Of course, if the incoming TTL is 1, only the first of these two
   options is applicable.

   If the packet is forwarded as a labeled packet, the outgoing TTL is
   carried as specified in section 9.

   When an Edge LSR receives a labeled packet over an LC-ATM interface,
   it obtains the incoming TTL from the top label stack entry of the
   generic encapsulation, or, if that encapsulation is not present, from
   the IP header.

   If the packet's next hop is an ATM-LSR, the outgoing TTL is formed
   using the procedures described in this section.  Otherwise the
   outgoing TTL is formed using the procedures described in [MPLS-
   ENCAPS].

Wimer                  Expires December 31, 1999               [Page 16]

Internet Draft      draft-wimer-mpls-atm-rsvp-00.txt           June 1999

   The procedures in this section are intended to apply only to unicast
   packets.

11.  Security Considerations

   The use of the procedures and encapsulations specified in this
   document does not have any security impact other than that which may
   generally be present in the use of any MPLS procedures or
   encapsulations.

13.  References

   [GIT] Suzuki, M., "The Assignment of the Information Field and
       Protocol Identifier in the Q.2941 Generic Identifier and Q.2957
       User-to-user Signaling for the Internet Protocol", Work in
       Progress, December 1998.

   [LSP-TUNNEL] Awduche, D., Berger, L., Gan, D., Li, T., Swallow, G.,
       Srinivasan, V., "Extensions to RSVP for LSP Tunnels", Work in
       Progress, March 1999.

   [MPLS-ARCH] Rosen E., Viswanathan, A., Callon R., "Multi-Protocol
       Label Switching Architecture", Work in Progress, April 1999.

   [MPLS-ENCAPS] Rosen, E., Rekhter, Y., Tappan, D., Farinacci, D.,
       Fedorkow, G., Li, T., Conta, A., "MPLS Label Stack Encoding",
       Work in Progress, April 1999.

   [REQUIRE] Bradner, S., RFC 2119 "Key words for use in RFCs to
       Indicate Requirement Levels."  March 1997.  (Also BCP0014)
       (Status: BEST CURRENT PRACTICE)

   [RFC1483] Heinanen, J., "Multiprotocol Encapsulation over ATM
       Adaptation Layer 5", RFC 1483, July 1993

   [VCID] Nagami, K., Demizu N., Esaki H., Doolan P., "VCID Notification
       over ATM link", Work in Progress, April 1999.

Wimer                  Expires December 31, 1999               [Page 17]

Internet Draft      draft-wimer-mpls-atm-rsvp-00.txt           June 1999

13.  Author's Address

   Walt Wimer
   FORE Systems, Inc.
   1000 FORE Drive
   Warrendale, PA  15086-7502

   Phone:  724-742-7324
   EMail:  wwimer@fore.com

Wimer                  Expires December 31, 1999               [Page 18]