Internet Draft






MPLS Working  Group                               A. Conta (Lucent)
INTERNET-DRAFT                                    P. Doolan (Ennovate)
                                                  A. Malis (Ascend)
                                                  22 October 1998


             Use of Label Switching on Frame Relay Networks

                             Specification

                       draft-ietf-mpls-fr-02.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 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

   This  document  defines  the  model  and   generic   mechanisms   for
   Multiprotocol  Label  Switching on Frame Relay networks. Furthermore,
   it  extends  and  clarifies  portions  of  the  Multiprotocol   Label
   Switching Architecture described in [ARCH] and the Label Distribution
   Protocol described in [LDP] relative to Frame  Relay  Networks.  MPLS
   enables  the  use  of Frame Relay Switches as Label Switching Routers
   (LSRs).










(Conta & Doolan & Malis)    Draft expires in six months  [Page 1]




INTERNET-DRAFT      Label Switching with Frame Relay    October 22, 1998


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 Encapsulation.........................................5
5. Frame Relay Label Switching Processing......................6
5.1  Use of DLCIs..............................................6
5.2  Homogeneous LSPs..........................................7
5.3  Heterogeneous LSPs........................................7
5.4  Frame Relay Label Switching Loop Prevention and Control...8
5.4.1   FR-LSRs Loop Control - MPLS TTL Processing.............8
5.4.2   Performing MPLS TTL calculations.......................9
5.5  Label Processing by Ingress FR-LSRs......................11
5.6  Label Processing by Core FR-LSRs.........................12
5.7  Label Processing by Egress FR-LSRs.......................12
6  Label Switching Control Component for Frame Relay..........13
6.1  Hybrid Switches (Ships in the Night)  ...................14
7  Label Allocation and Maintenance Procedures ...............14
7.1  Edge LSR Behavior........................................14
7.2  Efficient use of label space-Merging FR-LSRs.............17
7.3  LDP message fields specific to Frame Relay...............17
8  Security Considerations  ..................................19
9  Acknowledgments  ..........................................20
10 References  ...............................................20
11 Authors' Addresses  .......................................21






















(Conta & Doolan & Malis)    Draft expires in six months  [Page 2]




INTERNET-DRAFT      Label Switching with Frame Relay    October 22, 1998


1. Introduction

   The  Multiprotocol  Label  Switching  Architecture  is  described  in
   [ARCH]. 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

        A FR-LSR is an LSR with  one  or  more  LC-FR  interfaces  which



(Conta & Doolan & Malis)    Draft expires in six months  [Page 3]




INTERNET-DRAFT      Label Switching with Frame Relay    October 22, 1998


        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.


Additionally, this document uses terminology from [ARCH].


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  [FRF],  etc.... Because of these constraints, some special
   procedures are required for FR-LSRs.

   Some of the key features of Frame Relay switches  that  affect  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 four bytes in the header.

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

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



(Conta & Doolan & Malis)    Draft expires in six months  [Page 4]




INTERNET-DRAFT      Label Switching with Frame Relay    October 22, 1998


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


4. 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 [ITU] 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:


            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








(Conta & Doolan & Malis)    Draft expires in six months  [Page 5]




INTERNET-DRAFT      Label Switching with Frame Relay    October 22, 1998


            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"  [STACK],  where  the top stack entry carries significant values for
the EXP, S , and TTL fields [STACK] but not  for  the  label,  which  is
rather  carried  in  the  DLCI field of the Frame Relay data link header
encoded in Q.922 [ITU] address format.


5. Frame Relay Label Switching Processing


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



(Conta & Doolan & Malis)    Draft expires in six months  [Page 6]




INTERNET-DRAFT      Label Switching with Frame Relay    October 22, 1998


   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.


5.2  Homogeneous LSPs

   If  is an LSP, it is possible that LSR1, LSR2,  and
   LSR3  will use the same encoding of the label stack when transmitting
   packet P from LSR1, to LSR2,  and  then  to  LSR3.  Such  an  LSP  is
   homogeneous.


5.3  Heterogeneous 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 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 other MPLS encapsulations, such as the 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
   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.






(Conta & Doolan & Malis)    Draft expires in six months  [Page 7]




INTERNET-DRAFT      Label Switching with Frame Relay    October 22, 1998


5.4  Frame Relay Label Switching Loop Prevention and Control

   FR-LSRs MUST use a mechanism that insures loop free FR- LSPs  or  LSP
   FR segments. Such mechanisms are described in [ARCH], and [LDP].


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

   In the multicast case, a meaningful LSP length or LSP segment  length
   is  propagated  to  the  FR-LSR  egress node, enabling  the egress to
   decrement the TTL value before forwarding packets out of the  non-TTL
   LSP segment.





(Conta & Doolan & Malis)    Draft expires in six months  [Page 8]




INTERNET-DRAFT      Label Switching with Frame Relay    October 22, 1998


5.4.2  Performing MPLS TTL calculations

   Considering the "incoming TTL" the MPLS TTL of the top of  the  stack
   when  a labeled packet is received, and the "output TTL" the MPLS TTL
   of the top of the stack when a packet leaves a node, the relationship
   between  the  two  is defined as a function of the type of the output
   interface, and the type of transmit  operation  done  on  the  output
   interface (unicast or multicast):

output TTL = function (input TTL, output interface type, type of transmit)=

           = input TTL - funct (output interface type, type of transmit)

   Considering the symbol "I" for an IP interface, the symbol "G" for  a
   generic  MPLS  encapsulating interface, the symbol "A" for a MPLS ATM
   encapsulating
    interface, the symbol "F" for a MPLS FR encapsulating interface, and
   "G_G",  "F_G", etc... LSRs with specific input and output interfaces,
   and also the symbols "O.TTL" and "I.TTL" for the "output" and "input"
   TTL, the following describes the possible combinations:

input,output          Unicast

  ->G_G->      O.TTL = I.TTL - 1

  ->F_G->      O.TTL = I.TTL - nr. of hops of starting segment  (ingress F)
  ->G_F->      O.TTL = I.TTL - 1                                (egress F)

  ->A_F->      O.TTL = I.TTL - nr. of hops of starting segment  (ingress F)
  ->F_A->      O.TTL = I.TTL - 1                                (egress F)

  ->F_F->  similar to ->A A->    no TTL processing

input,output         Multicast

  ->G_G->      O.TTL = I.TTL - 1

  ->G_F->      O.TTL = I.TTL - 1                                (ingress F)
  ->F_G->      O.TTL = I.TTL - nr. of hops of ending segment    (egress F)

  ->A_F->      O.TTL = I.TTL - 1                                (ingress F)
  ->F_A->      O.TTL = I.TTL - nr. of hops of ending segment    (egress F)

  ->F_F->  similar to ->A A->    no TTL processing







(Conta & Doolan & Malis)    Draft expires in six months  [Page 9]




INTERNET-DRAFT      Label Switching with Frame Relay    October 22, 1998


                          Homogeneous LSP

               --->I_F      Frame Relay     F_I--->
hops = 5             |                      |
                     F_F--->F_F--->F_F--->F_F
                             loop free
ip_ttl = n                                    ip_ttl=n-6
    mpls_ttl = n-5                           n-5


                          Heterogeneous LSP


   LSP                                                           LSP
   ingress                                                       egress

        LAN   PPP        FR          ATM    PPP    FR     LAN

 --->I_G-->G_G-->G_F             F_A      A_G-->G_F      F_G-->G_I--->
                   |            /  |      |       |      |
hops     1    1    |     4     /   |  3   |   1   |  3   |   1     1
                   F_F--F_F--F_F   A_A--A_A       F_F--F_F

                     loop free     loop free     loop free
ip_ttl
      n                                                          n-15
mpls_ttl
       n-1   n-2   n-6               n-9      n-10   n-13     n-14



       Unicast -- TTL calculated at ingress

             1       2        3      4
         o-------o-------o-------o-------o
       ttl=n-4          /     2      3
                       /
 hops                1/
                     /
                    o ttl=n-3











(Conta & Doolan & Malis)    Draft expires in six months [Page 10]




INTERNET-DRAFT      Label Switching with Frame Relay    October 22, 1998


       Multicast -- TTL calculated at egress

                             o ttl=n-3
         hops               /
                          3/
                          /            ttl=n-4
         o-------o-------o-------o-------o
             1       2       3       4



5.5  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 homogeneous -- Frame Relay only -- and the  FR-LSR  is
   the ingress.

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

   For unicast packets, the MPLS TTL  SHOULD  be  decremented  with  the
   number  of  hops of the Frame Relay LSP (homogeneous), or Frame Relay
   segment of the LSP  (heterogeneous).  An  LDP  constructing  the  LSP
   SHOULD  pass  meaningful  information to the ingress FR-LSR regarding
   the number of hops of the "non-TTL segment".

   For multicast packets, the MPLS TTL SHOULD be decremented by  1.   An
   LDP  constructing  the  LSP SHOULD pass meaningful information to the
   egress 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.





(Conta & Doolan & Malis)    Draft expires in six months [Page 11]




INTERNET-DRAFT      Label Switching with Frame Relay    October 22, 1998


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


5.7  Label Processing by Egress FR-LSRs

   When reaching the end of a Frame Relay LSP, the FR-LSR pops the label
   stack  [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  top  level
   MPLS TTL is propagated to the new top 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 the
   appropriate value depending the type of the output interface and  the
   type  of  transmit  operation  (see  section  6.3). Further, the MPLS
   packet is forwarded according to  the  MPLS  specifications  for  the
   particular link of the next segment of the LSP.

   For unicast packets, the MPLS TTL SHOULD be decremented by one if the
   output  interface is a generic one, or with the number of hops of the
   next ATM segment of the LSP (heterogeneous), if the output  interface
   is an ATM (non-TTL)  interface.

   For multicast packets, the MPLS TTL  SHOULD  be  decremented  by  the
   number  of  hops of the FR segment being exited.  An LDP constructing
   the LSP SHOULD pass  meaningful  information  to  the  egress  FR-LSR
   regarding the number of hops of the FR "non-TTL segment".



(Conta & Doolan & Malis)    Draft expires in six months [Page 12]




INTERNET-DRAFT      Label Switching with Frame Relay    October 22, 1998


6.  Label Switching Control Component for Frame Relay


   To support label switching a Frame Relay Switch  MUST  implement  the
   control  component  of  label  switching, which 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]  (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
   discussed in the next section.






(Conta & Doolan & Malis)    Draft expires in six months [Page 13]




INTERNET-DRAFT      Label Switching with Frame Relay    October 22, 1998


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


7.  Label Allocation and Maintenance Procedures


   The mechanisms and message formats of a Label  Distribution  Protocol
   are  documented  in  [ARCH]  and  [LDP].  A possible scenario for the
   label allocation  and  maintenance  for  FR-LSRs  is  "downstream-on-
   demand"  as  it  follows (note that this applies to hop-by-hop routed
   traffic):


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 (FEC), and that the next hop is reachable  via
   a  LC-Frame  Relay  interface.  Assume that the next-hop FR-LSR is an
   "LDP-peer" [ARCH][LDP]. The Edge LSR sends an LDP  "request"  message
   for  a label binding from the next hop, downstream LSR. When the Edge
   LSR receives in response from the downstream LSR  the  label  binding
   information  in  an LDP "mapping" message, the label is stored in the
   Label Information Base (LIB) as an outgoing label for that  FEC.  The
   "mapping"   message   may  contain  the  "hop  count"  object,  which
   represents the number of hops a packet will take to cross the  FR-LSR
   cloud  to  the  Egress FR-LSR when using this label. This information
   may be stored for TTL calculation. Once this is done, the LSR may use
   MPLS forwarding to transmit packets in that FEC.

   When a member of the Edge Set of the FR-LSR  cloud  receives  an  LDP
   "request"  message  from  a  FR-LSR  for  a  FEC,  it means it is the
   Egress-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  "mapping"  message



(Conta & Doolan & Malis)    Draft expires in six months [Page 14]




INTERNET-DRAFT      Label Switching with Frame Relay    October 22, 1998


   containing  the  allocated  label  back upstream to the LDP peer that
   originated the request.  The  "mapping"  message  contains  the  "hop
   count" object value set 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  an  LDP  "release"
   message)  that  the  label  binding  associated  with the route is no
   longer needed.

   When a Frame Relay-LSR  receives  an  LDP  "request"  message  for  a
   certain  route  (FEC) from an LDP 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 propagates the "request",  by  sending  an  LDP  "request"
           message to the next hop LSR, downstream for that route (FEC);


   In the "ordered control" mode [ARCH], the FR-LSR will  wait  for  its
   "request"  to  be  responded from downstream with a "mapping" message
   before returning the "mapping" upstream in response  to  a  "request"
   ("ordered  control"  approach  [ARCH]).  In  this  case,  the  FR-LSR
   increments the hop count it received from downstream  and  uses  this
   value in the "mapping" it returns upstream.

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

   Since both the "ordered" and "independent" control has advantages and
   disadvantages,  this  is  left as an implementation, or configuration
   choice.

   Once the FR-LSR receives in response the  label  binding  in  an  LDP
   "mapping"  message  from  the  next hop, it places the label into the
   outgoing label component of the LIB entry.

   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 (FEC) from
   the same FR-LSR. It must generate a new "mapping" for each  "request"
   (assuming  adequate  resources  to  do  so),  and retain any existing
   mapping(s).  For  each  "request"  received,  a  FR-LSR  should  also



(Conta & Doolan & Malis)    Draft expires in six months [Page 15]




INTERNET-DRAFT      Label Switching with Frame Relay    October 22, 1998


   generate  a  new  binding "request" toward the next hop for the route
   (FEC).

   When a routing calculation causes a FR-LSR to change the next hop for
   a  route  (FEC), the FR-LSR should notify the former next hop (via an
   LDP "release" message) 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. This mode is the  "conservative
   label  retention  mode"  [ARCH].  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  (the  FR-LSR  is  configured  in
   "liberal  label  retention  mode"  [ARCH]), 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   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  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  an  LDP  "withdraw"
   message).




(Conta & Doolan & Malis)    Draft expires in six months [Page 16]




INTERNET-DRAFT      Label Switching with Frame Relay    October 22, 1998


   When an LSR determines that it has lost its LDP session with  another
   LSR, the following actions are taken:

        -    MUST discard  any  binding  information  learned  via  this
             connection;

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



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.


7.3   LDP messages specific to Frame Relay

   The Label Distribution Protocol [LDP] messages exchanged between  two
   Frame   Relay  "LDP-peer"  LSRs  may  contain  Frame  Relay  specific
   information such as:









(Conta & Doolan & Malis)    Draft expires in six months [Page 17]




INTERNET-DRAFT      Label Switching with Frame Relay    October 22, 1998


   "Frame Relay Label Range":

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Reserved    |Len|               Minimum DLCI                  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Reserved        |               Maximum DLCI                  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   with the following fields:

   Reserved
     This fields are reserved. They must be set to zero on  transmission
     and must be ignored on receipt.

   Len
     This field specifies the number of bits of the DLCI. The  following
     values are supported:

          Len  DLCI bits

          0     10
          1     17
          2     23

   Minimum DLCI
     This 23 bit field is the binary value of the lower bound of a block
     of  Data  Link  Connection Identifiers (DLCIs) that is supported by
     the originating FR-LSR. The Minimum DLCI should be right  justified
     in this field and the preceding bits should be set to 0.

   Maximum DLCI
     This 23 bit field is the binary value of the upper bound of a block
     of  Data  Link  Connection Identifiers (DLCIs) that is supported by
     the originating FR-LSR. The Maximum DLCI should be right  justified
     in this field and the preceding bits should be set to 0.

   and "Frame Relay Label":

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Reserved    |Len|                       DLCI                  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   with the following fields:




(Conta & Doolan & Malis)    Draft expires in six months [Page 18]




INTERNET-DRAFT      Label Switching with Frame Relay    October 22, 1998


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

   Len
     This field specifies the number of bits of the DLCI. The  following
     values are supported:

          Len  DLCI bits

          0     10
          1     17
          2     23

   DLCI
     The binary value of the Frame Relay Label. The  significant  number
     of  bits  (10, 17, or 23) of the label value are to be encoded into
     the Data Link Connection Identifier (DLCI) field when part  of  the
     Frame Relay data link header (see Section 4.).


8.  Security Considerations


   This section looks at the security aspects of:

         (a) frame traffic

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





(Conta & Doolan & Malis)    Draft expires in six months [Page 19]




INTERNET-DRAFT      Label Switching with Frame Relay    October 22, 1998


9.  Acknowledgments

   The initial version of this  document  was  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  George  Swallow  for  the  suggestion  to  use  null
   encapsulation, and to Eric Gray for his reviewing.

   Also thanks to Nancy Feldman and Bob Thomas for  their  collaboration
   in including the LDP messages specific to Frame Relay LSRs

10. References

   [MIFR] T. Bradley, C. Brown,  A.  Malis  "Multiprotocol  Interconnect
   over Frame Relay" RFC 2427, September 1998.


   [ARCH] E. Rosen, R. Callon, A.  Vishwanathan,  "Multi-Protocol  Label
   Switching Architecture", Work in Progress, July 1998.


   [LDP] L. Anderson, P. Doolan, N. Feldman,  A.  Fredette,  R.  Thomas,
   "Label Distribution Protocol", Work in Progress, August 1998.


   [STACK] E. Rosen et al, "Label  Switching:  Label  Stack  Encodings",
   Work in Progress, September 1998


   [ATM] B. Davie et al. "Use of Label  Switching  with  ATM",  Work  in
   Progress, July 1998.


   [ITU] International Telecommunications Union, "ISDN Data  Link  Layer
   Specification  for  Frame Mode Bearer Services", ITU-T Recommendation
   Q.922, 1992.


   [FRF] Frame Relay  Forum,  User-to-Network  Implementation  Agreement
   (UNI), FRF 1.1, January 19, 1996









(Conta & Doolan & Malis)    Draft expires in six months [Page 20]




INTERNET-DRAFT      Label Switching with Frame Relay    October 22, 1998


11.Authors' Addresses

   Alex Conta
   Lucent Technologies Inc.
   300 Baker Ave, Suite 100
   Concord, MA 01742
   +1-978-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)    Draft expires in six months [Page 21]