Internet Draft






MPLS Working  Group                               A. Conta (Lucent)
INTERNET-DRAFT                                    P. Doolan (Innovative)
                                                  A. Malis (Ascend)
                                                  November 1997


             Use of Label Switching on Frame Relay Networks

                             Specification

                       draft-conta-mpls-fr-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.  Internet-Drafts  may  be  updated, replaced, or obsoleted by
   other documents at any time.  It is not appropriate to use  Internet-
   Drafts as reference material or to cite them other than as a "working
   draft" or "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).

   Distribution of this memo is unlimited.

Abstract

   This  document  defines  the  model  and   generic   mechanisms   for
   Multiprotocol   Label   Switching   on   Frame   Relay   networks.  A
   Multiprotocol Label Switching Architecture is  described  in  [ARCH].
   MPLS  enables  the  use  of  Frame  Relay Switches as Label Switching
   Routers (LSRs).










Conta & Doolan & Malis       Expires in six months  [Page 1]




INTERNET-DRAFT  Use of Label Switching With Frame RelayNovember 17, 1997


Table of Contents


   Status of this Memo.........................................1
   Table of Contents...........................................2
1. Introduction................................................3
2. Terminology.................................................3
3. Special Characteristics of Frame Relay Switches.............4
4  Label Switching Control Component for Frame Relay...........5
4.1  Hybrid Switches (Ships in the Night)  ....................6
5  Label Encapsulation.........................................6
6  Frame Relay Label Swithcing Processing......................8
6.1  Use of DLCIs..............................................8
6.2  Hybrid LSPs...............................................8
6.3  Frame Relay Label Switching Loop Prevention and Control...9
6.3.1   FR-LSRs Loop Control - MPLS TTL Processing.............9
6.4  Label Processing by Ingress FR-LSRs......................10
6.5  Label Processing by Core FR-LSRs.........................10
6.6  Label Processing by Egress FR-LSRs.......................11
7  Label Allocation and Maintenance Procedures ...............11
7.1  Edge LSR Behavior........................................11
7.2  Efficient use of label space-Merging FR-LSRs.............14
8  Security Considerations  ..................................14
9  Acknowledgments  ..........................................15
10 References  ...............................................15
11 Authors' Addresses  .......................................16

























Conta & Doolan & Malis       Expires in six months  [Page 2]




INTERNET-DRAFT  Use of Label Switching With Frame RelayNovember 17, 1997


1. Introduction

   A Multiprotocol Label Switching Architecture is described in  [ARCH].
   The   framework   for  Multiprotocol  Label  Switching  protocols  is
   described in [FRAMEW]. It is possible to use Frame Relay switches  as
   Label Switching Routers.  Such Frame Relay 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 specific
   Frame Relay routing is needed.

   When a Frame Relay switch is used for label  switching,  the  current
   label,  on  which  forwarding  decisions are based, is carried in the
   DLCI field of the Frame Relay data link  layer  header  of  a  frame.
   Additional  information carried along with the current label, but not
   processed by Frame Relay switching, along with other labels,  if  the
   packet   is  multiply  labeled,  are  carried  in  the  generic  MPLS
   encapsulation defined in [STACK].

   Frame Relay permanent virtual circuits (PVCs) could be configured  to
   carry  label switching based traffic. The DLCIs would be used as MPLS
   Labels and the Frame Relay switches would become MPLS switches  while
   the   MPLS   traffic   would   be   encapsulated  according  to  this
   specification, and would be forwarded based on network layer  routing
   information.

   The keywords MUST, MUST NOT, MAY, OPTIONAL,   REQUIRED,  RECOMMENDED,
   SHALL,  SHALL  NOT,  SHOULD,  SHOULD  NOT   are  to be interpreted as
   defined in RFC 2119.


2. Terminology


   LSR

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

   LC-FR

        A label switching controlled Frame Relay (LC-FR) interface is  a
        Frame  Relay interface controlled by the label switching control
        component. Packets traversing such an interface carry labels  in
        the DLCI field.

   FR-LSR




Conta & Doolan & Malis       Expires in six months  [Page 3]




INTERNET-DRAFT  Use of Label Switching With Frame RelayNovember 17, 1997


        A FR-LSR is an LSR with  a  number  of  LC-FR  interfaces  which
        forwards  frames  onto  these interfaces using labels carried in
        the DLCI field.

   FR-LSR cloud

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

   Edge Set

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



3. Special characteristics of Frame Relay Switches

   While  the  label   switching   architecture   permits   considerable
   flexibility  in  LSR  implementation,  a FR-LSR is constrained by the
   capabilities  of  the  (possibly  pre-existing)  hardware   and   the
   restrictions   on  such  matters  as  frame  format  imposed  by  the
   Multiprotocol Interconnect over Frame Relay [MIFR],  or  Frame  Relay
   standards  (Q.922,  etc).  Because of these constraints, some special
   procedures are required for FR-LSRs.

   Some of the key features of Frame Relay switches that  affects  their
   behavior as LSRs are:

   -    the label swapping function is performed on fields (DLCI) in the
        frame's Frame Relay data link header; this dictates the size and
        placement of the label(s) in a packet.  The  size  of  the  DLCI
        field  can be 10 (default), 17, or 23 bits, and it can span two,
        or respectively four bytes in the header.

   -    congestion control is performed by each node based on parameters
        that  are passed at circuit creation. Flags in the frame headers
        may be set as a consequence  of  congestion,  or  exceeding  the
        contractual parameters of the circuit.

   -    although in a standard switch it may be  possible  to  configure
        multiple   input  DLCIs  to  one  output  DLCI  resulting  in  a
        multipoint-to-point circuit,  multipoint-to-multipoint  VCs  are
        generally not fully supported.


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



Conta & Doolan & Malis       Expires in six months  [Page 4]




INTERNET-DRAFT  Use of Label Switching With Frame RelayNovember 17, 1997


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


4.  Label Switching Control Component for Frame Relay


   To support label switching a Frame Relay Switch  MUST  implement  the
   control  component  of  label  switching.  This consists primarily of
   label  allocation   and   maintenance   procedures.   Label   binding
   information  MAY  be communicated by several mechanisms, one of which
   is the Label Distribution Protocol (LDP) [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 may use other protocols (e.g. RSVP, PIM, BGP)  to
   distribute  label  bindings. In these cases, a Frame Relay LSR should
   participate in these protocols.

   In the case where Frame Relay circuits are established  via  LDP,  or
   RSVP,  or  others,  with  no involvement from traditional Frame Relay
   mechanisms, it  is  assumed  that  circuit  establishing  contractual
   information    such    as    input/output    maximum    frame   size,
   incoming/outgoing  requested/agreed   throughput,   incoming/outgoing
   acceptable      throughput,     incoming/outgoing     burst     size,
   incoming/outgoing frame rate, used in  transmitting,  and  congestion
   control  MAY  be  passed  to  the  FR-LSRs  through  RSVP,  or can be
   statically configured. It is also assumed that congestion control and
   frame  header  flagging as a consequence of congestion, would be done
   by the FR-LSRs in a similar fashion as for  traditional  Frame  Relay
   circuits. With the goal of emulating a best-effort router as default,
   the default VC parameters, in the absence  of  LDP,  RSVP,  or  other
   mechanisms  participation  to setting such parameters, should be zero
   CIR, so that input policing will set the DE bit in  incoming  frames,
   but no frames are dropped..

   Control and state information for the circuits based on MPLS  MAY  be
   communicated through LDP.

   Support  of  label  switching  on  a  Frame  Relay  switch   requires
   conformance  only  to  FRF  1.1 (framing, bit-stuffing, headers, FCS)
   except for section 2.3 (PVC control signaling procedures,  aka  LMI).
   Q.933  signaling for PVCs and/or SVCs is not required. PVC and/or SVC
   signaling may be used for non-MPLS (standard Frame Relay) PVCs and/or
   SVCs  when  both  are  running  on  the  same  interface  as MPLS, as



Conta & Doolan & Malis       Expires in six months  [Page 5]




INTERNET-DRAFT  Use of Label Switching With Frame RelayNovember 17, 1997


   discussed in a next section.


4.1  Hybrid Switches (Ships in the Night)


   The existence of the label switching control  component  on  a  Frame
   Relay switch does not preclude the ability to support the Frame Relay
   control component defined by the ITU and Frame  Relay  Forum  on  the
   same   switch  and  the  same  interfaces  (NICs).  The  two  control
   components, label switching and  those  defined  by  ITU/Frame  Relay
   Forum, 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 DLCI space which are available to each component.


5. Label Encapsulation

   By default, all  labeled  packets  should  be  transmitted  with  the
   generic  label  encapsulation  as defined in [STACK], using the frame
   relay null encapsulation mechanism. The labels implicitly encode  the
   network protocol type, consequently those particular labels cannot be
   used with other network protocols. Rules regarding  the  construction
   of  the  label stack, and error messages returned to the frame source
   are also described in [STACK].

            0                       1                       (Octets)
           +-----------------------+-----------------------+
(Octets)0  |                                               |
           /                 Q.922 Address                 /
           /             (length 'n' equals 2 or 4)        /
           |                                               |
           +-----------------------+-----------------------+
        n  |                       .                       |
           /                       .                       /
           /                  MPLS packet                  /
           |                       .                       |
           +-----------------------+-----------------------+

       "n" is the length of the Q.922  Address  which  can  be  2  or  4
       octets.

       The Q.922 representation of a DLCI  (in  canonical  order  -  the
       first  bit  is  stored in the least significant, i.e., the right-
       most bit of a byte in memory) [CANON]is the following:



Conta & Doolan & Malis       Expires in six months  [Page 6]




INTERNET-DRAFT  Use of Label Switching With Frame RelayNovember 17, 1997


            7     6     5     4     3     2     1     0      (bit order)
           +-----+-----+-----+-----+-----+-----+-----+-----+
(octet) 0  |            DLCI(high order)       |  0  |  0  |
           +-----+-----+-----+-----+-----+-----+-----+-----+
        1  |  DLCI(low order)      |  0  |  0  |  0  |  1  |
           +-----+-----+-----+-----+-----+-----+-----+-----+

              10 bits DLCI

            7     6     5     4     3     2     1     0      (bit order)
           +-----+-----+-----+-----+-----+-----+-----+-----+
(octet) 0  |            DLCI(high order)       |  0  |  0  |
           +-----+-----+-----+-----+-----+-----+-----+-----+
        1  |  DLCI                 |  0  |  0  |  0  |  0  |
           +-----+-----+-----+-----+-----+-----+-----+-----+
        2  |             DLCI(low order)             |  0  |
           +-----+-----+-----+-----+-----+-----+-----+-----+
        3  |       unused (set to 0)           |  1  |  1  |
           +-----+-----+-----+-----+-----+-----+-----+-----+

              17 bits DLCI

            7     6     5     4     3     2     1     0      (bit order)
           +-----+-----+-----+-----+-----+-----+-----+-----00
(octet) 0  |            DLCI(high order)       |  0  |  0  |
           +-----+-----+-----+-----+-----+-----+-----+-----
        1  |  DLCI                 |  0  |  0  |  0  |  0  |
           +-----+-----+-----+-----+-----+-----+-----+-----+
        2  |             DLCI                        |  0  |
           +-----+-----+-----+-----+-----+-----+-----+-----+
        3  |       DLCI (low order)            |  0  |  1  |
           +-----+-----+-----+-----+-----+-----+-----+-----+

              23 bits DLCI

The generic encapsulation contains n labels for a label stack  of  depth
n,  where  the  top  stack  entry  carries  significant  values with the
exception of the label which is carried in the DLCI field of  the  Frame
Relay data link header encoded in Q.922 address format.












Conta & Doolan & Malis       Expires in six months  [Page 7]




INTERNET-DRAFT  Use of Label Switching With Frame RelayNovember 17, 1997


6. Frame Relay Label Switching Processing


6.1  Use of DLCIs

   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 [ARCH] for further details. In a
   FR-LSR,  the current (top) MPLS label is carried in the DLCI field of
   the Frame Relay data link layer header of the frame.  The  top  label
   carries implicitly information about the network protocol type.

   For two connected FR-LSRs, a full-duplex connection must be available
   for  LDP.   The  DLCI  for  the  LDP VC is assigned a value by way of
   configuration, similar to configuring the DLCI used to run IP routing
   protocols between the switches.

   With the exception of this configured value, the DLCI values used for
   MPLS in the two directions of the link may be treated as belonging to
   two independent spaces, i.e. VCs may be half-duplex,  each  direction
   with   its  own  DLCI.  In  case  of  DLCI  aggregation  (DLCI  space
   conservation), half-duplex (unidirectional) VCs are desired, since  a
   "many  to  few"  aggregation  is possible in one direction but not in
   reverse.

   The allowable ranges of DLCIs are always  communicated  through  LDP.
   Note  that  the range of DLCIs used for labels depends on the size of
   the DLCI field.


6.2  Hybrid LSPs

   If  is an LSP, it is possible that  LSR1  will  use
   one  encoding  of the label stack when transmitting packet P to LSR2,
   but LSR2 will use a different encoding when transmitting a  packet  P
   to  LSR3.   In  general,  the  MPLS  architecture  supports LSPs with
   different label stack  encodings  used  on  different  hops.  When  a
   labeled  packet  is received, the LSR must decode it to determine the
   current value of the label stack, then  must  operate  on  the  label
   stack  to determine the new label value of the stack, and then encode
   the new value appropriately before transmitting the labeled packet to
   its next hop.

   Naturally there will be MPLS networks which contain a combination  of
   Frame  Relay switches operating as LSRs, and other LSRs which operate
   using an other MPLS encapsulations, such as MPLS shim header, or  ATM
   encapsulation.  In  such  networks  there may be some LSRs which have
   Frame Relay interfaces as well as "MPLS Shim" interfaces. This is one



Conta & Doolan & Malis       Expires in six months  [Page 8]




INTERNET-DRAFT  Use of Label Switching With Frame RelayNovember 17, 1997


   example  of  an LSR with different label stack encodings on different
   hops of the same LSP. Such an LSR may swap off a Frame Relay  encoded
   label  on  an  incoming interface and replace it with a label encoded
   into an MPLS shim header on the outgoing interface.


6.3  Frame Relay Label Switching Loop Prevention and Control

   FR-LSRs SHOULD use diffusion computation for loop prevention [ARCH].


6.3.1  FR-LSRs Loop Control - MPLS TTL processing

   The MPLS TTL encoded in the MPLS label stack is a mechanism used to:

   (a) suppress loops;

   (b) limit the scope of a packet.

   When a packet travels along an LSP, it should emerge  with  the  same
   TTL  value  that  it  would  have  had  if  it had traversed the same
   sequence of routers without  having  been  label  switched.   If  the
   packet  travels  along  a hierarchy of LSPs, the total number of LSR-
   hops traversed should be reflected in its TTL value when  it  emerges
   from the hierarchy of LSPs [ARCH].

   The initial value of the MPLS TTL is loaded into a newly pushed label
   stack  entry  from  the  previous TTL value, whether that is from the
   network layer header when no previous label stack existed, or from  a
   pre-existent lower level label stack entry.

   A FR-LSR switching same level labeled packets does not decrement  the
   MPLS TTL. A sequence of such FR-LSR is a "non-TTL segment".

   When a packet emerges from a "non-TTL LSP segment", it should however
   reflect  in  the  TTL  the  number  of  LSR-hops it traversed. In the
   unicast case, this can be achieved by propagating  a  meaningful  LSP
   length  or  LSP  segment length to the FR-LSR ingress nodes, enabling
   the ingress to decrement the TTL value before forwarding packets into
   a non-TTL LSP segment [ARCH].

   When an ingress FR-LSR determines upon decrementing the MPLS TTL that
   a  particular  packet's TTL will expire before the packet reaches the
   egress of the "non-TTL LSP segment", the FR-LSR MUST not label switch
   the  packet,  but  rather  follow the specifications in [STACK] in an
   attempt to return an error message to the packet's source.





Conta & Doolan & Malis       Expires in six months  [Page 9]




INTERNET-DRAFT  Use of Label Switching With Frame RelayNovember 17, 1997


6.4  Label Processing by Ingress FR-LSRs

   When a packet first enters an MPLS domain, the packet is forwarded by
   normal  network  layer  forwarding operations with the exception that
   the outgoing encapsulation will include an MPLS label  stack  [STACK]
   with  at  least  one  entry.  The frame relay null encapsulation will
   carry information about the network layer protocol implicitly in  the
   label,  which MUST be associated only with that network protocol. The
   TTL field in the top label stack entry is  filled  with  the  network
   layer  TTL  (or  hop  limit)  resulted after network layer forwarding
   [STACK]. The further FR-LSR processing is similar  in  both  possible
   cases:

   (a) the LSP is Frame Relay only, and the FR-LSR is the ingress.

   (b) the LSP is hybrid -- Frame  Relay,  PPP,  Ethernet,  ATM,  etc...
   segments  form  the LSP -- and the FR-LSR is the ingress into a Frame
   Relay segment.

   The MPLS TTL SHOULD be decremented with the number  of  hops  of  the
   Frame Relay LSP, or Frame Relay segment of the LSP, minus one. An LDP
   constructing the  LSP  SHOULD  pass  meaningful  information  to  the
   ingress FR-LSR regarding the number of hops of the "non-TTL segment".
   Next, the MPLS encapsulated packet is passed down to the Frame  Relay
   data  link  driver with the top label as output DLCI. The Frame Relay
   frame carrying the MPLS encapsulated packet  is  forwarded  onto  the
   Frame Relay VC to the next LSR.


6.5  Label Processing by Core FR-LSRs

   In a FR-LSR, the current (top) MPLS label  is  carried  in  the  DLCI
   field of the Frame Relay data link layer header of the frame. Just as
   in conventional Frame Relay, for a frame arriving  at  an  interface,
   the  DLCI carried by the Frame Relay data link header is looked up in
   the DLCI Information Base, replaced  with  the  correspondent  output
   DLCI,  and  transmitted  on  the outgoing interface (forwarded to the
   next hop node).

   The current label information is also carried in the top of the label
   stack.   In  the  top  level  entry,  all  fields  except  the  label
   information, which is carried and switched in the Frame  Relay  frame
   data link-layer header, are of current significance.

   Two successive FR-LSR MUST  encode  the  labels  in  the  same  Q.922
   address format (the DLCI length MUST be the same).





Conta & Doolan & Malis       Expires in six months [Page 10]




INTERNET-DRAFT  Use of Label Switching With Frame RelayNovember 17, 1997


6.6  Label Processing by Egress FR-LSRs

   When reaching the end of a Frame Relay LSP, the FR-LSR pops the label
   stack  [FRAMEW],[ARCH].  If the label popped is the last label, it is
   necessary to determine the particular network layer protocol which is
   being  carried.  The  label  stack carries no explicit information to
   identify the network layer protocol. This must be inferred  from  the
   value of the label which is popped from the stack.

   If the label popped is not the last label, the previous current  MPLS
   TTL is propagated to the new current label stack entry.

   If the FR-LSR is the egress switch of a  Frame  Relay  segment  of  a
   hybrid  LSP, and the end of the Frame Relay segment is not the end of
   the LSP, the MPLS packet will be processed for  forwarding  onto  the
   next segment of the LSP based on the information held in the Next Hop
   Label Forwarding Entry (NHLFE) [ARCH]. The output label is set to the
   value  from  the NHLFE, and the MPLS TTL is decremented by 1 [STACK].
   Further,  the  MPLS  packet  is  forwarded  according  to  the   MPLS
   specifications  for  the  particular  link of the next segment of the
   LSP.


7.  Label Allocation and Maintenance Procedures


   A possible scenario for the label allocation and maintenance for  FR-
   LSRs is the following:


7.1   Edge LSR Behavior

   Consider a member of the Edge Set of a FR-LSR cloud. Assume that,  as
   a result of its routing calculations, it selects a FR-LSR as the next
   hop of a certain route, and that the next hop is reachable via a  LC-
   Frame Relay interface. The Edge LSR uses a specific LDP request for 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 FR-LSR cloud  when
   using this label. The edge LSR should 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



Conta & Doolan & Malis       Expires in six months [Page 11]




INTERNET-DRAFT  Use of Label Switching With Frame RelayNovember 17, 1997


           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 FR-LSR cloud  receives  a  label
   binding  request  from  a FR-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 FR-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.

   When a Frame Relay-LSR receives (via LDP) a label binding request for
   a  certain  route  from  a  peer connected to the FR-LSR over a LC-FR
   interface, the FR-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 FR-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  FR-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 FR-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 FR-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  FR-LSR  should  notify  the  upstream neighbor that it could not
   satisfy the binding request.




Conta & Doolan & Malis       Expires in six months [Page 12]




INTERNET-DRAFT  Use of Label Switching With Frame RelayNovember 17, 1997


   Alternatively, the FR-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   approach   has
   advantages  and  disadvantages,  this  is  left  as an implementation
   choice.

   Note that a FR-LSR, or a member of the edge set of  a  FR-LSR  cloud,
   may  receive  multiple  binding  requests for the same route from the
   same FR-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, a FR-LSR should also  generate
   a new binding request toward the next hop for the route.

   When a routing calculation causes a FR-LSR to change the next hop for
   a  route, the FR-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  a  FR-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 a FR-LSR or a member of  the
   edge  set reachable via a LC-FR 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 a FR-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



Conta & Doolan & Malis       Expires in six months [Page 13]




INTERNET-DRAFT  Use of Label Switching With Frame RelayNovember 17, 1997


   given the value  `unknown')  the  FR-LSR  must  notify  the  upstream
   neighbor  of the change. Each FR-LSR in turn increments the hop count
   and passes it upstream until it reaches the ingress Edge LSR.

   Whenever a FR-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  FR-LSR  should  destroy  the  binding created in response to the
   received request, and notify the requester (via LDP).

   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  must  destroy  these  bindings  (and
   deallocate labels associated with these binding).


7.2   Efficient use of label space - Merging FR-LSRs

   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 FR-
   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 [ARCH]) provides a mechanism to conserve the
   number of labels.

   Note that conserving label space may be restricted in case the  frame
   traffic  requires  Frame Relay fragmentation. The issue is that Frame
   Relay fragments must be transmitted in sequence,  i.e.  fragments  of
   distinct  frames  must  not be interleaved. If the fragmenting FR-LSR
   ensures the transmission in sequence of all  fragments  of  a  frame,
   without  interleaving  with  fragments  of  other  frames, then label
   conservation (aggregation) can be performed.

   In the case where the label space is to be conserved, it is desirable
   to  use  half-duplex  (unidirectional)  VCs,  since  a  "many to few"
   aggregation is possible in one direction but not in reverse.


8.  Security Considerations


   This section looks at the security aspects of:

         (a) frame traffic



Conta & Doolan & Malis       Expires in six months [Page 14]




INTERNET-DRAFT  Use of Label Switching With Frame RelayNovember 17, 1997


         (b) label distribution.

   MPLS encapsulation  has  no  effect  on  authenticated  or  encrypted
   network  layer  packets, that is IP packets that are authenticated or
   encrypted will incur no change.

   The MPLS protocol has no mechanisms of its  own  to  protect  against
   misdirection of packets or the impersonation of an LSR by accident or
   malicious intent.

   Altering by accident or forgery an existent label in the  DLCI  field
   of  the  Frame Relay data link layer header of a frame or one or more
   fields in a potentially following label stack affects the  forwarding
   of that frame.

   The label distribution  mechanism can  be  secured  by  applying  the
   appropriate  level  of  security  to the underlying protocol carrying
   label information - authentication or encryption -  see [LDP].


9.  Acknowledgments

   This document is derived from the Label Switching over  ATM  document
   [ATM].

   Thanks for the extensive reviewing and constructive comments from (in
   alphabetical  order)  Dan  Harrington,  Milan Merhar, Martin Mueller.
   Also thanks to E. Gray for his reviewing. More [TBD]

10. References

   [MIFR] T. Bradley, C. Brown,  A.  Malis  "Multiprotocol  Interconnect
   over Frame Relay" <draft-ietf-ion-fr-update-03.txt>


   [FRAMEW]"A Framework for Multiprotocol Label Switching"  R.Callon  et
   al. <draft-ietf-mpls-framework-01.txt>


   [ARCH] "Proposed Architecture for MPLS" in  "draft-rosen-mpls-00.txt"
   by E. Rosen, R. Callon, R. Vishwanathan.


   [LDP] Label Distribution Protocol - work in progress.


   [STACK] "Label Switching: Label Stack  Encodings"  "draft-mpls-label-
   encaps-00.txt" by Rosen et al.



Conta & Doolan & Malis       Expires in six months [Page 15]




INTERNET-DRAFT  Use of Label Switching With Frame RelayNovember 17, 1997


   [ATM] "draft-davie-tag-switching-atm-01.txt" by Davie et al.




10.Authors' Addresses

   Alex Conta
   Lucent Technologies Inc.
   300 Baker Ave, Suite 100
   Concord, MA 01742
   +1-508-287-2842
   E-mail: aconta@lucent.com

   Paul Doolan
   Ennovate Networks
   330 Codman Hill Rd
   Boxborough MA 01719
   +1-978-263-2002
   E-mail: pdoolan@ennovatenetworks.com

   Andrew Malis
   Ascend Communications, Inc
   1 Robbins Rd
   Westford, MA 01886
   +1-978-952-7414
   E-mail: malis@ascend.com
























Conta & Doolan & Malis       Expires in six months [Page 16]