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

Versions: 00 01

Network Working Group                                        Bruce Davie
Internet Draft                                           Jeremy Lawrence
Expiration Date: January 1999                           Keith McCloghrie
                                                           Yakov Rekhter
                                                              Eric Rosen
                                                          George Swallow
                                                     Cisco Systems, Inc.

                                                             Paul Doolan
                                                 Ennovate Networks, Inc.

                                                               July 1998


                    Use of Label Switching With ATM


                      draft-davie-mpls-atm-01.txt

Status of this Memo

   This document is an Internet-Draft.  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."

   To view the entire list of current Internet-Drafts, please check the
   "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
   Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern
   Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific
   Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast).


Abstract


   The MPLS Architecture [1] 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. No
   ATM-specific routing or addressing is needed.  ATM switches used in
   this way are known as ATM-LSRs.




Davie, et al.                                                   [Page 1]


Internet Draft        draft-davie-mpls-atm-01.txt              July 1998


   This document extends and clarifies the relevant portions of [1] and
   [2] by specifying in more detail the procedures which to be used when
   distributing labels to or from ATM-LSRs, when those labels represent
   Forwarding Equivalence Classes (FECs, see [1]) for which the routes
   are determined on a hop-by-hop basis by network layer routing
   algorithms.

   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 [3].



Contents

    1      Introduction  ...........................................   2
    2      Definitions  ............................................   3
    3      Special Characteristics of ATM Switches  ................   4
    4      Label Switching Control Component for ATM  ..............   5
    5      Hybrid Switches (Ships in the Night)  ...................   5
    6      Use of  VPI/VCIs  .......................................   6
    6.1    Direct Connections  .....................................   6
    6.2    Connections via an ATM VP  ..............................   7
    6.3    Connections via an ATM SVC  .............................   7
    7      Label Distribution and Maintenance Procedures  ..........   8
    7.1    Edge LSR Behavior  ......................................   8
    7.2    Conventional ATM Switches (non-VC-merge)  ...............   9
    7.3    VC-merge-capable ATM Switches  ..........................  11
    8      Encapsulation  ..........................................  12
    9      TTL Manipulation  .......................................  14
   10      Security Considerations  ................................  15
   11      Intellectual Property Considerations  ...................  15
   12      References  .............................................  15
   13      Acknowledgments  ........................................  15
   14      Authors' Addresses  .....................................  16




1. Introduction

   The MPLS Architecture [1] discusses the 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. No
   ATM-specific routing or addressing is needed.  ATM switches used in
   this way are known as ATM-LSRs.




Davie, et al.                                                   [Page 2]


Internet Draft        draft-davie-mpls-atm-01.txt              July 1998


   This document extends and clarifies the relevant portions of [1] and
   [2] by specifying in more detail the procedures which are to be used
   for distributing labels to or from ATM-LSRs, when those labels
   represent Forwarding Equivalence Classes (FECs, see [1]) for which
   the routes are determined on a hop-by-hop basis by network layer
   routing algorithms.  The label distribution technique described here
   is referred to in [1] as "downstream-on-demand".  This label
   distribution technique is mandatory for ATM-LSRs that are not capable
   of "VC merge" (defined in section 2), and is optional for ATM-LSRs
   that are capable of VC merge.

   Label distribution techniques used when the routes are explicitly
   chosen, or when the FECs consist of multicast packets, are not
   considered in this document, and further statements made in this
   document about ATM-LSR label distribution do not necessarily apply in
   those cases.

   The label distribution procedures specified herein are required for
   use when the ATM-LSRs are not capable of "VC merge", and may also be
   used if the ATM-LSRs are capable of VC merge.  Label distribution
   procedures for the case of "VP merge" are not considered in this
   document.

   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 [3].  The specified encapsulation is to be used
   for multicast or explicitly routed labeled packets as well.

   This document uses terminology from [1].


2. Definitions

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

   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 VPI field, the contents of the VCI field, or the
   combined contents of the VPI and VCI fields.  Any two LDP peers which
   are connected via an LC-ATM interface will use LDP negotiations to
   determine which of these three cases is applicable to that interface.

   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 and/or
   VPI field.



Davie, et al.                                                   [Page 3]


Internet Draft        draft-davie-mpls-atm-01.txt              July 1998


   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.

   In general, an LC-ATM interface will be used either to connect two
   ATM-LSRs, or to connect an ATM-LSR to a frame-based LSR.

   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.


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







Davie, et al.                                                   [Page 4]


Internet Draft        draft-davie-mpls-atm-01.txt              July 1998


4. 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 is communicated by several mechanisms, notably the Label
   Distribution Protocol (LDP) [2].  This document imposes certain
   requirements on the LDP.

   This document considers only the case where the label switching
   control component uses information learned directly from network
   layer routing protocols.  It is presupposed that the switch
   participates as a peer in these protocols (e.g., OSPF, IS-IS).

   In some cases, LSRs make use of other protocols (e.g. RSVP, 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.



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













Davie, et al.                                                   [Page 5]


Internet Draft        draft-davie-mpls-atm-01.txt              July 1998


6. Use of  VPI/VCIs

   Label switching is accomplished by associating labels with Forwarding
   Equivalence Classes, and using the label value to forward packets,
   including determining the value of any replacement label.  See [1]
   for further details. In an ATM-LSR, the label is carried in the VPI
   and/or VCI field. Just as in conventional ATM, for a cell arriving at
   an interface, the VPI/VCI is looked up, replaced, and the cell is
   switched.

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

   LDP may be used to advertise additional VPI/VCIs to carry control
   information or non-labelled packets. These may use either the null
   encapsulation, as defined in Section 5.1 of RFC1483, or the LLC/SNAP
   encapsulation, as defined in Section 4.1 of RFC1483.


6.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 entire VPI/VCI field to
   encode a single label.  Alternatively, they may agree to use the VPI
   field to encode the top label in the stack, and the VCI field to
   encode the second label in the stack.  However, the latter
   alternative is only allowed when the top label represents a FEC for
   which the Label Switched Path (LSP, see [1]) consists entirely of
   LSRs, directly connected via LC-ATM interfaces, which have agreed to
   encode the top label in the VPI field and the second label in the VCI
   field.

   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.

   It is prohibited to encode any label as a VPI/VCI value whose VCI
   part is in the range 0-32 inclusive.



Davie, et al.                                                   [Page 6]


Internet Draft        draft-davie-mpls-atm-01.txt              July 1998


   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 ranges of VCIs are communicated through LDP.


6.2. Connections via an ATM VP

   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.

   It is prohibited to encode any label as a VPI/VCI value whose VCI
   part is in the range 0-32 inclusive.

   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 ranges of VPI/VCIs are communicated through LDP.  If
   more than one VPI is used for label switching, the allowable range of
   VCIs may be different for each VPI, and each range is communicated
   through LDP.


6.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, the procedures described in [4] must be used
   to assign a VCID to each such VC, and LDP is used to bind a VCID to a
   FEC.  The top label of a received packet is then inferred (via a
   one-to-one mapping) from the virtual circuit on which the packet
   arrived.

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






Davie, et al.                                                   [Page 7]


Internet Draft        draft-davie-mpls-atm-01.txt              July 1998


7. Label Distribution and Maintenance Procedures

   This document discusses the use of "downstream-on-demand" label
   distribution (see [1]) by ATM-LSRs.  These label distribution
   procedures are mandatory for ATM-LSRs that do not support VC-merge,
   and may also be used by ATM-LSRs that do support VC-merge.  The
   procedures differ somewhat in the two cases, however. We therefore
   describe the two scenarios in turn. We begin by describing the
   behavior of members of the Edge Set of an ATM-LSR domain; these "Edge
   LSRs" are not themselves ATM-LSRs, and their behavior is the same
   whether the domain contains VC-merge capable LSRs or not.


7.1. Edge LSR Behavior

   Consider a member of the Edge Set of an ATM-LSR domain. Assume that,
   as a result of its routing calculations, it selects an ATM-LSR as the
   next hop of a certain FEC, and that the next hop is reachable via a
   LC-ATM interface. The Edge LSR uses LDP to request a label binding
   for that FEC from the next hop.  The hop count field in the request
   is set to 1.  Once the Edge LSR receives the label binding
   information, it may use MPLS forwarding procedures to transmit
   packets in the specified FEC, using the specified label as an
   outgoing label. (Or using the VPI/VCI that corresponds to the
   specified VCID as the outgoing label, if VCIDs are being used.)

   The binding received by the edge LSR may contain a hop count, which
   represents the number of hops a packet will take to cross the ATM-LSR
   domain when using this label. If there is a hop count associated with
   the binding, the ATM-LSR should adjust the packet's TTL by this
   amount before transmitting the packet.  The procedures for doing so
   are specified in section 9.  The procedures for encapsulating the
   packets, are specified in section 8.

   When a member of the Edge Set of the ATM-LSR domain receives a label
   binding request from an ATM-LSR, it allocates a label, and returns
   (via LDP) a binding containing the allocated label back to the peer
   that originated the request.  It sets the hop count in the binding to
   1.

   When a routing calculation causes an Edge LSR to change the next hop
   for a particular FEC, and the former next hop was in the ATM-LSR
   domain, the Edge LSR should notify the former next hop (via LDP) that
   the label binding associated with the FEC is no longer needed.







Davie, et al.                                                   [Page 8]


Internet Draft        draft-davie-mpls-atm-01.txt              July 1998


7.2. Conventional ATM Switches (non-VC-merge)

   When an ATM-LSR receives (via LDP) a label binding request for a
   certain FEC from a peer connected to the ATM-LSR over a LC-ATM
   interface, the ATM-LSR takes the following actions:

     - it allocates a label,

     - it requests (via LDP) a label binding from the next hop for that
       FEC;

     - it returns (via LDP) a binding containing the allocated incoming
       label back to the peer that originated the request.

   The hop count field in the request that the ATM-LSR sends (to the
   next hop LSR) is set to the hop count field in the request that it
   received from the upstream LSR plus one.  If the resulting hop count
   exceeds a configured maximum value, the request is not sent to the
   next hop, and the ATM-LSR notifies the upstream neighbor that its
   binding request cannot be satisfied.

   Otherwise, once the ATM-LSR receives the binding from the next hop,
   it places the label from the binding into the outgoing label
   component of the LIB entry.

   The ATM-LSR may choose to wait for the request to be satisfied from
   downstream before returning the binding upstream.  This is a form of
   "ordered control" (as defined in [1] and [2]), in particular
   "ingress-initiated ordered control".  In this case, the ATM-LSR
   increments the hop count it received from downstream and uses this
   value in the binding it returns upstream.  However, if the hop count
   exceeds a configured maximum value, a label binding is not passed
   upstream.  Rather, the upstream LDP peer is informed that the
   requested label binding cannot be satisfied.

   Alternatively, the ATM-LSR may return the binding upstream without
   waiting for a binding from downstream ("independent" control, as
   defined in [1] and [2]). In this case, it uses a reserved value for
   hop count in the binding, indicating that the true hop count is
   unknown. The correct value for hop count will be returned later, as
   described below.

   Note that an ATM-LSR, or a member of the edge set of an ATM-LSR
   domain, may receive multiple binding requests for the same FEC from
   the same ATM-LSR. It must generate a new binding for each request
   (assuming adequate resources to do so), and retain any existing
   binding(s). For each request received, an ATM-LSR should also
   generate a new binding request toward the next hop for the FEC.



Davie, et al.                                                   [Page 9]


Internet Draft        draft-davie-mpls-atm-01.txt              July 1998


   When a routing calculation causes an ATM-LSR to change the next hop
   for a FEC, the ATM-LSR should notify the former next hop (via LDP)
   that the label binding associated with the FEC is no longer needed.

   When a LSR receives a notification that a particular label binding is
   no longer needed, the LSR may deallocate the label associated with
   the binding, and destroy the binding. In the case where an ATM-LSR
   receives such notification and destroys the binding, it should notify
   the next hop for the FEC that the label binding is no longer needed.
   If a LSR does not destroy the binding, it may re-use the binding only
   if it receives a request for the same FEC with the same hop count as
   the request that originally caused the binding to be created.

   When a route changes, the label bindings are re-established from the
   point where the route diverges from the previous route.  LSRs
   upstream of that point are (with one exception, noted below)
   oblivious to the change.

   Whenever a LSR changes its next hop for a particular FEC, if the new
   next hop is reachable via an LC-ATM interface, then for each label
   that it has bound to that FEC, and distributed upstream, it must
   request a new label binding from the new next hop.

   When an ATM-LSR receives a label binding for a particular FEC from a
   downstream neighbor, it may already have provided a corresponding
   label binding for this FEC to an upstream neighbor, either because it
   is using independent control, or because the new binding from
   downstream is the result of a routing change. In this case, it should
   extract the hop count from the new binding and increment it by one.
   If the new hop count is different from that which was previously
   conveyed to the upstream neighbor (including the case where the
   upstream neighbor was given the value `unknown') the ATM-LSR must
   notify the upstream neighbor of the change. Each ATM-LSR in turn
   increments the hop count and passes it upstream until it reaches the
   ingress Edge LSR. If at any point the value of the hop count equals a
   configured maximum hop count value, the ATM-LSR should withdraw the
   binding from the upstream neighbor.

   Whenever an ATM-LSR originates a label binding request to its next
   hop LSR as a result of receiving a label binding request from another
   (upstream) LSR, and the request to the next hop LSR is not satisfied,
   the ATM-LSR should destroy the binding created in response to the
   received request, and notify the requester (via LDP).

   If an ATM-LSR receives a binding request containing a hop count that
   exceeds a configurable maximum, no binding should be established and
   an error message should be returned to the requester.




Davie, et al.                                                  [Page 10]


Internet Draft        draft-davie-mpls-atm-01.txt              July 1998


   When a LSR determines that it has lost its LDP session with another
   LSR, the following actions are taken.  Any binding information
   learned via this connection must be discarded.  For any label
   bindings that were created as a result of receiving label binding
   requests from the peer, the LSR may destroy these bindings (and
   deallocate labels associated with these binding).

   An ATM-LSR should use `split-horizon' when it satisfies binding
   requests from its neighbors. That is, if it receives a request for a
   binding to a particular FEC and the LSR making that request is,
   according to this ATM-LSR, the next hop for that FEC, it should not
   return a binding for that route.

   Note that if ordered control is used, it is not possible to create
   looping paths consisting entirely of non-VC-merging ATM-LSRs.  LDP
   messages might be sent in a loop until the hop count reaches the
   configured maximum, but data would not loop.

   Note that non-merging ATM-LSRs must use "conservative label retention
   mode" [1].


7.3. VC-merge-capable ATM Switches

   Relatively minor changes are needed to accommodate ATM-LSRs which
   support VC-merge. The primary difference is that a VC-merge-capable
   ATM-LSR needs only one outgoing label per FEC, even if multiple
   requests for label bindings to that FEC are received from upstream
   neighbors.

   When a VC-merge-capable ATM-LSR receives a binding request from an
   upstream LSR for a certain FEC, and it does not already have an
   outgoing label binding for that FEC (or an outstanding request for
   such a label binding), it issues a bind request to its next hop just
   as it would do if it were not merge-capable. If, however, it already
   has an outgoing label binding for that FEC, it does not need to issue
   a downstream binding request. Instead, it allocates an incoming
   label, and returns that label in a binding to the upstream requester.
   When packets with that label as top label are received from the
   requester, the top label value will be replaced with the existing
   outgoing label value that corresponds to the same FEC.

   If the ATM-LSR does not have an outgoing label binding for the FEC,
   but does have an outstanding request for one, it does not issue
   another request.

   When sending a label binding upstream, the hop count associated with
   the corresponding binding from downstream is incremented by 1, and



Davie, et al.                                                  [Page 11]


Internet Draft        draft-davie-mpls-atm-01.txt              July 1998


   the result transmitted upstream as the hop count associated with the
   new binding.

   Note that, just like conventional ATM-LSRs and members of the edge
   set of the ATM-LSR domain, a VC-merge-capable ATM-LSR must issue a
   new binding every time it receives a request from upstream, since
   there may be switches upstream which do not support VC-merge.
   However, it only needs to issue a corresponding binding request
   downstream if it does not already have a label binding for the
   appropriate route.

   When a change in the routing table of a VC-merge-capable ATM-LSR
   causes it to select a new next hop for one of its FECs, it may
   optionally release the binding for that route from the former next
   hop.  If it doesn't already have a corresponding binding for the new
   next hop, it must request one.  (The choice between conservative and
   liberal label retention mode is an implementation option.)

   If a new binding is obtained, which contains a hop count that differs
   from that which was received in the old binding, then the ATM-LSR
   must take the new hop count, increment it by one, and notify any
   upstream neighbors who have label bindings for this FEC of the new
   value. Just as with conventional ATM-LSRs, this enables the new hop
   count to propagate back towards the ingress of the ATM-LSR domain. If
   at any point the hop count exceeds the configurable maximum value,
   then the label bindings for this route must be withdrawn from all
   upstream neighbors to whom a binding was previously provided. This
   ensures that any loops caused by routing transients will be detected
   and broken.

   Complete prevention of transient looping paths can be achieved by
   means of the techniques described in [5], which work with any mix of
   merging and non-merging ATM-LSRs.  Note that the loop prevention
   technique described in [1] and [2] cannot be used along with
   downstream-on-demand label distribution.


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.

   In general, when a labeled packet is transmitted on an LC-ATM
   interface, where the VPI/VCI (or VCID) is interpreted as the top one
   or two labels in the label stack, it is also necessary for the packet
   to be encapsulated as specified in [3], and for the resulting packet
   to be placed directly into the AAL5 frame.



Davie, et al.                                                  [Page 12]


Internet Draft        draft-davie-mpls-atm-01.txt              July 1998


   Let n be the depth of a packet's label stack, and let c be the number
   of labels (1 or 2) which are represented by the VPI/VCI or VCID.

   If n == c, the packet should be encapsulated as specified in [3],
   with at least one, but no more than n, label stack entries.  The
   label value of the bottom label stack entry should be set to the
   distinguished "Explicit NULL" value for the network layer protocol of
   the packet.  The label value of any other label in the stack should
   be set to the "IPv4 Explicit NULL" value as defined in [3].

   Essentially, this creates at least four bytes of overhead whose
   meaning is "n == c".  The only ways to eliminate this overhead are:

     - through apriori knowledge that n == c;

     - by using two VCs per FEC, one for those packets where n == c, and
       one for those packets where n > c.

   While either of these techniques is permitted, it is doubtful that
   they have any practical utility.

   If n > c, the packet should be encapsulated as specified in [3].  The
   number of label stack entries contained in that encapsulation, e,
   must be between n and n - c inclusive.  If more than n - c label
   stack entries are encoded, the top e - n labels must have their label
   values set to the distinguished value "IPv4 Explicit NULL", as
   defined in [3].

   Note that if n > c for some packet, it is an implementation choice as
   to whether the generic encapsulation should contains n or n - c
   entries.  Using the smaller number of entries in the encapsulation
   saves communications bandwidth, but may complicate the logic of the
   transmit and/or received forwarding paths of the Edge LSRs.

   In any case, the packet's outgoing TTL, and its CoS, are carried in
   the TTL and CoS fields respectively of the top stack entry in the
   generic encapsulation.   If the generic encapsulation is not present,
   the outgoing TTL is carried in the TTL field of the network layer
   header.












Davie, et al.                                                  [Page 13]


Internet Draft        draft-davie-mpls-atm-01.txt              July 1998


9. 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 [3], 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 8.

   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 [3].

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



Davie, et al.                                                  [Page 14]


Internet Draft        draft-davie-mpls-atm-01.txt              July 1998


   packets.



10. Security Considerations

   Security considerations are not addressed in this document.


11. Intellectual Property Considerations

   Cisco Systems may seek patent or other intellectual property
   protection for some or all of the technologies disclosed in this
   document. If any standards arising from this document are or become
   protected by one or more patents assigned to Cisco Systems, Cisco
   intends to disclose those patents and license them under openly
   specified and non-discriminatory terms, for no fee.


12. References

   [1] Rosen, Viswanathan, Callon, "Multi-Protocol Label Switching
   Architecture", Internet Draft, draft-ietf-mpls-arch-02.txt, July,
   1998

   [2] Andersson, Doolan, Feldman, Fredette, Thomas, "Label Distribution
   Protocol", Internet Draft, draft-ietf-mpls-ldp-00.txt, March, 1998.

   [3] Rosen, et al. "Label Switching: Label Stack Encodings", Internet
   Draft, draft-ietf-mpls-label-encaps-02.txt, July, 1998.

   [4] Nagami, Demizu, Esaki, Doolan, "VCID Notification over ATM link",
   Internet Draft, draft-ietf-mpls-vcid-atm-00.txt.

   [5] Ohba, Katsube, Rosen, Doolan, "MPLS Loop Prevention Technique
   Using LSP-id and Hop Count", Internet Draft, draft-ohba-mpls-loop-
   prevention-01.txt.


13. Acknowledgments

   Significant contributions to this work have been made by Anthony
   Alles, Fred Baker, Dino Farinacci, Guy Fedorkow, Arthur Lin, Morgan
   Littlewood and Dan Tappan.







Davie, et al.                                                  [Page 15]


Internet Draft        draft-davie-mpls-atm-01.txt              July 1998


14. Authors' Addresses


   Bruce Davie
   Cisco Systems, Inc.
   250 Apollo Drive
   Chelmsford, MA, 01824

   E-mail: bsd@cisco.com


   Paul Doolan
   Ennovate Networks Inc.
   330 Codman Hill Rd
   Boxborough, MA 01719

   E-mail: pdoolan@ennovatenetworks.com


   Jeremy Lawrence
   Cisco Systems, Inc.
   1400 Parkmoor Ave.
   San Jose, CA, 95126

   E-mail: jlawrenc@cisco.com


   Keith McCloghrie
   Cisco Systems, Inc.
   170 Tasman Drive
   San Jose, CA, 95134

   E-mail: kzm@cisco.com


   Yakov Rekhter
   Cisco Systems, Inc.
   170 Tasman Drive
   San Jose, CA, 95134

   E-mail: yakov@cisco.com










Davie, et al.                                                  [Page 16]


Internet Draft        draft-davie-mpls-atm-01.txt              July 1998



   Eric Rosen
   Cisco Systems, Inc.
   250 Apollo Drive
   Chelmsford, MA, 01824

   E-mail: erosen@cisco.com


   George Swallow
   Cisco Systems, Inc.
   250 Apollo Drive
   Chelmsford, MA, 01824

   E-mail: swallow@cisco.com




































Davie, et al.                                                  [Page 17]


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