[Search] [txt|pdf|bibtex] [Tracker] [Email] [Nits]

Versions: 00 01                                                         
Network Working Group                                        Bruce Davie
Internet Draft                                           Jeremy Lawrence
Expiration Date: May  1998                              Keith McCloghrie
                                                           Yakov Rekhter
                                                              Eric Rosen
                                                          George Swallow
                                                     Cisco Systems, Inc.

                                                             Paul Doolan
                                                 Ennovate Networks, Inc.

                                                           November 1997



                    Use of Label Switching With ATM


                      draft-davie-mpls-atm-00.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 learn the current status of any Internet-Draft, please check the
   "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
   Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
   munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
   ftp.isi.edu (US West Coast).


Abstract




Davie, et al.                                                   [Page 1]


Internet Draft        draft-davie-mpls-atm-00.txt           October 1997


   A Multi Protocol Label Switching architecture is described in [1].
   Label Switching enables the use of ATM Switches 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.

   This document describes how the label switching architecture is
   applied to ATM switches.




Contents

    1      Introduction  ...........................................   2
    2      Definitions  ............................................   3
    3      Special Characteristics of ATM Switches  ................   3
    4      Label Switching Control Component for ATM  ..............   4
    5      Hybrid Switches (Ships in the Night)  ...................   5
    6      Use of  VPI/VCIs  .......................................   5
    7      Label Allocation and Maintenance Procedures  ............   6
    7.1    Edge LSR Behavior  ......................................   6
    7.2    Conventional ATM Switches (non-VC-merge)  ...............   7
    7.3    VC-merge-capable ATM Switches  ..........................   9
    7.4    Efficient use of label space  ...........................  11
    8      Encapsulation  ..........................................  11
    9      Security Considerations  ................................  12
   10      Intellectual Property Considerations  ...................  12
   11      References  .............................................  12
   12      Acknowledgments  ........................................  12
   13      Authors' Addresses  .....................................  12




1. Introduction

   A label switching architecture is described in [1]. It is possible to
   use ATM switches as label switching routers. Such ATM switches run
   network layer routing algorithms (such as OSPF, IS-IS, etc.), and
   their forwarding is based on the results of these routing algorithms.
   No ATM-specific routing or addressing is needed.

   When an ATM switch is used for label switching, the label on which
   forwarding decisions are based is carried in the VCI and/or VPI
   fields. (It is possible to carry multiple labels in the VCI and/or
   VPI fields, but the scope of this document is restricted to the case



Davie, et al.                                                   [Page 2]


Internet Draft        draft-davie-mpls-atm-00.txt           October 1997


   of a single label.)

   The characteristics of ATM switches require some specialized
   procedures and conventions to support label switching. This document
   describes those aspects of label switching which are specific to ATM.


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.
   Packets traversing such an interface carry labels in the VCI and/or
   VPI field.

   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.

   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.

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

   The Edge Set of an ATM-LSR cloud is the set of frame-based LSRs which
   are connected to the cloud by LC-ATM interfaces.

   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 label switching 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 affects their behavior
   as LSRs are:




Davie, et al.                                                   [Page 3]


Internet Draft        draft-davie-mpls-atm-00.txt           October 1997


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


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 and maintenance procedures. Label binding information is
   communicated by several mechanisms, notably the Label Distribution
   Protocol (LDP). Candidate protocols being considered by the LDP
   design team are described in [2, 4]. This document imposes certain
   requirements on the LDP.

   Since the label switching control component uses information learned
   directly from network layer routing protocols, this implies that the
   switch must participate 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.

   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.












Davie, et al.                                                   [Page 4]


Internet Draft        draft-davie-mpls-atm-00.txt           October 1997


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.


6. Use of  VPI/VCIs

   Label switching is accomplished by associating labels with routes 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.

   ATM-LSRs may be connected by ATM virtual paths to enable
   interconnection of ATM-LSRs over a cloud of conventional ATM
   switches. In this case, the label is carried in the VCI field.

   For two connected ATM-LSRs, a connection must be available for LDP.
   The default is for this connection to be on VPI 0, VCI 32. For ATM-
   LSRs connected by a VPI of value x, the default for the LDP
   connection is VPI x, VCI 32. Additionally, for all VPI values, VCIs 0
   - 32 are not used as labels.

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










Davie, et al.                                                   [Page 5]


Internet Draft        draft-davie-mpls-atm-00.txt           October 1997


7. Label Allocation and Maintenance Procedures

   ATM-LSRs use the downstream-on-demand allocation mechanism described
   in [1]. The procedures for label allocation depend on whether the
   switches support VC-merge or not. We therefore describe the two
   scenarios in turn. We begin by describing the behavior of members of
   the Edge Set of an ATM-LSR cloud; these edge LSRs are not themselves
   ATM-LSRs, and their behavior is the same whether the cloud contains
   VC-merge capable LSRs or not.


7.1. Edge LSR Behavior

   Consider a member of the Edge Set of an ATM-LSR cloud. Assume that,
   as a result of its routing calculations, it selects an ATM-LSR as the
   next hop of a certain route, and that the next hop is reachable via a
   LC-ATM interface. The Edge LSR uses LDP's binding request message to
   request a label binding from the next hop.  The hop count field in
   the request is set to 1.  Once the Edge LSR receives the label
   binding information, the label is used as an outgoing label. 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
   cloud when using this label. The edge LSR may either


       - use this hop count to decrement the TTL of packets before
      transmitting them over the cloud

       - decrement the TTL of packets by one before transmitting them
      over the cloud.


   The choice between these two options should be made based on local
   configuration.

   When a member of the Edge Set of the ATM-LSR cloud receives a label
   binding request from an ATM-LSR, it allocates a label, creates a new
   entry in its Label Information Base (LIB), places that label in the
   incoming label component of the entry, 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 route, and the former next hop was in the ATM-LSR cloud, the
   Edge LSR should notify the former next hop (via LDP) that the label
   binding associated with the route is no longer needed.




Davie, et al.                                                   [Page 6]


Internet Draft        draft-davie-mpls-atm-00.txt           October 1997


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

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


       - it allocates a label, creates a new entry in its Label
      Information Base (LIB), and places that label in the incoming
      label component of the entry;

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

       - 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.  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 (a "conservative"
   approach).  In this case, the ATM-LSR increments the hop count it
   received from downstream and uses this value in the binding it
   returns upstream. If the value of the hop count equals MAX_HOP_COUNT
   the ATM-LSR should notify the upstream neighbor that it could not
   satisfy the binding request.

   Alternatively, the ATM-LSR may return the binding upstream without
   waiting for a binding from downstream (an "optimistic" approach). In
   this case, it uses a reserved value for hop count in the binding,
   indicating that it is unknown. The correct value for hop count will
   be returned later, as described below.

   Since both the conservative and the optimistic approaches have
   advantages and disadvantages, this is left as an implementation
   choice.

   Note that an ATM-LSR, or a member of the edge set of an ATM-LSR
   cloud, may receive multiple binding requests for the same route 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 route.



Davie, et al.                                                   [Page 7]


Internet Draft        draft-davie-mpls-atm-00.txt           October 1997


   When a routing calculation causes an ATM-LSR to change the next hop
   for a route, the ATM-LSR should notify the former next hop (via LDP)
   that the label binding associated with the route 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 route 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 route 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 route, if the new next hop is an ATM-LSR or a member of
   the edge set reachable via a LC-ATM interface, then for each entry in
   its LIB associated with the route the LSR should request (via LDP) a
   binding from the new next hop.

   When an ATM-LSR receives a label binding from a downstream neighbor,
   it may already have provided a corresponding label binding for this
   route to an upstream neighbor, either because it is operating
   optimistically 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 MAX_HOP_COUNT, 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
   equals MAX_HOP_COUNT, no binding should be established and an error
   message should be returned to the requester.




Davie, et al.                                                   [Page 8]


Internet Draft        draft-davie-mpls-atm-00.txt           October 1997


   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 route and the LSR making that request is,
   according to this ATM-LSR, the next hop for that route, it should not
   return a binding for that route.

   Note that it is not possible for complete label-switched looping
   paths to be established when VC merge is not supported. The worst
   case behavior (possible only if optimistic mode is used) is that
   binding request messages could travel in a loop, setting up a label
   switched spiral, which would then be torn down when the hop count in
   the binding request reached MAX_HOP_COUNT. In conservative mode, no
   label switched path can be set up unless the path exits the ATM-LSR
   cloud.


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 route, even if multiple
   requests for label bindings to that route are received from upstream
   neighbors.

   When a VC-merge-capable ATM-LSR receives a binding request from an
   upstream LSR for a certain route, and it does not already have an
   outgoing label binding for that route, it issues a bind request to
   its next hop just as before. If, however, it already has an outgoing
   label binding for that route, it does not need to issue a downstream
   binding request. Instead, it creates a new LIB entry, allocates an
   incoming label for that entry and returns that label in a binding to
   the upstream requester, and uses the existing outgoing label for the
   outgoing label entry in the LIB. It also takes the hop count that was
   provided with the label binding it received from downstream,
   increments it by one, and uses this value in the binding that it
   sends to the upstream requester.

   Note that, just like conventional ATM-LSRs and members of the edge
   set of the ATM-LSR cloud, 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



Davie, et al.                                                   [Page 9]


Internet Draft        draft-davie-mpls-atm-00.txt           October 1997


   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 routes, it releases
   the binding for that route from the former next hop and requests a
   new binding from the new next hop. If the new binding 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
   route 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 cloud. If at any point the hop count reaches
   MAX_HOP_COUNT, 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.

   While the choice between "conservative" and "optimistic" binding
   remains for VC-merge capable LSRs, the advantages of the conservative
   approach are greater in this case. This is because:


       - the optimistic mode permits the formation of a looping switched
      path which will not be removed until routing changes to remove the
      loop;

       - the conservative mode does not have the same drawbacks when VC
      merge is supported, since it will often be possible to obtain a
      binding by merging into an existing path, without waiting for
      binding requests and responses to propagate across the entire
      ATM-LSR cloud.


   The use of conservative mode along with hop counts in the binding
   requests and responses ensures that stable looping paths cannot be
   set up.  Implementations may choose to support the diffusion
   algorithm described in [1] for stronger protection against transient
   loops.












Davie, et al.                                                  [Page 10]


Internet Draft        draft-davie-mpls-atm-00.txt           October 1997


7.4. Efficient use of label space

   The above discussion assumes that an edge LSR will request one label
   for each prefix in its routing table that has a next hop in the ATM-
   LSR cloud. In fact, it is possible to significantly reduce the number
   of labels needed by having the edge LSR request instead one label for
   several routes. Use of many-to-one mappings between routes (address
   prefixes) and labels using the notion of Forwarding Equivalence
   Classes (as described in [1]) provides a mechanism to conserve the
   number of labels.



8. Encapsulation

   By default, all labelled packets should be transmitted with the
   generic label encapsulation, as defined in [3]. A packet thus
   encapsulated is then directly encapsulated within an AAL5 frame.
   Since the value at the top of the label stack is determined from the
   VCI and/or VPI fields, the top label in the label encapsulation is
   ignored. Other fields in the top stack entry, such as TTL and COS,
   may be used by LSRs at the edges of the ATM-LSR cloud that are able
   to examine that entry.

   For systems which are using only one level of labelling, it is
   theoretically possible to use a null encapsulation. In this case, IP
   packets are carried directly inside AAL5 frames, as in the null
   encapsulation of RFC 1483. However, all ATM-LSRs in a cloud must be
   configured to use this encapsulation to avoid reassembly and re-
   encapsulation in the middle of the cloud.

   The initial LDP connection, described in Section 5, uses the LLC/SNAP
   encapsulation, as defined in Section 4.1 of RFC1483. This same VCI
   (with the LLC/SNAP encapsulation) may be used to exchange Network
   Layer routing information as well.

   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.











Davie, et al.                                                  [Page 11]


Internet Draft        draft-davie-mpls-atm-00.txt           October 1997


9. Security Considerations

   Security considerations are not addressed in this document.


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


11. References

   [1] Rosen, E. et al. A Proposed Architecture for MPLS,  Internet
   Draft, draft-ietf-mpls-arch-00.txt, August, 1997

   [2] Doolan, P. et al. Tag Distribution Protocol, Internet Draft,
   draft-doolan-tdp-spec-01.txt, May, 1997.

   [3] Rosen, E. et al. Label Switching: Label Stack Encodings, Internet
   Draft, draft-rosen-tag-stack-03.txt, July, 1997.

   [4] Feldman, N., and Viswanathan, A.  ARIS Specification, Internet
   Draft, draft-feldman-aris-spec-00.txt, March, 1997.


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


13. Authors' Addresses


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

   E-mail: bsd@cisco.com





Davie, et al.                                                  [Page 12]


Internet Draft        draft-davie-mpls-atm-00.txt           October 1997



   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


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