doc: Add RFC documents

1 files changed, 1347 insertions, 0 deletions

diff --git a/doc/rfc/rfc3034.txt b/doc/rfc/rfc3034.txt
new file mode 100644
index 0000000..0846812
--- /dev/null
+++ b/doc/rfc/rfc3034.txt
@@ -0,0 +1,1347 @@
+
+
+
+
+
+
+Network Working Group                                           A. Conta
+Request for Comments: 3034                        Transwitch Corporation
+Category: Standards Track                                      P. Doolan
+                                                                Ennovate
+                                                                A. Malis
+                                                   Vivace Networks, Inc.
+                                                            January 2001
+
+
+             Use of Label Switching on Frame Relay Networks
+                             Specification
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2001).  All Rights Reserved.
+
+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 (LDP) described in [LDP] relative to Frame Relay Networks.
+   MPLS enables the use of Frame Relay Switches as Label Switching
+   Routers (LSRs).
+
+Table of Contents
+
+   1. Introduction................................................2
+   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...7
+   5.4.1   FR-LSRs Loop Control - MPLS TTL Processing.............7
+   5.4.2   Performing MPLS TTL calculations.......................8
+   5.5  Label Processing by Ingress FR-LSRs......................12
+
+
+
+Conta, et al.               Standards Track                     [Page 1]
+
+RFC 3034            Label Switching with Frame Relay        January 2001
+
+
+   5.6  Label Processing by Core FR-LSRs.........................12
+   5.7  Label Processing by Egress FR-LSRs.......................13
+   6.  Label Switching Control Component for Frame Relay.........13
+   6.1  Hybrid Switches (Ships in the Night)  ...................14
+   7.  Label Allocation and Maintenance Procedures ..............15
+   7.1  Edge LSR Behavior........................................15
+   7.2  Efficient use of label space-Merging FR-LSRs.............18
+   7.3  LDP message fields specific to Frame Relay...............19
+   8.  Security Considerations  .................................21
+   9.  Acknowledgments  .........................................21
+   10. References  ..............................................22
+   11. Authors' Addresses  ......................................23
+   12. Full Copyright Statement  ................................24
+
+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 top
+   (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 top (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 Frame Relay Label
+   Switching Routers, 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.
+
+   This document is a companion document to [STACK] and [ATM].
+
+
+
+
+
+
+
+
+Conta, et al.               Standards Track                     [Page 2]
+
+RFC 3034            Label Switching with Frame Relay        January 2001
+
+
+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
+      forwards frames between two such interfaces using labels carried
+      in the DLCI field.
+
+   FR-LSR domain
+
+      A FR-LSR domain is a set of FR-LSRs, which are mutually
+      interconnected by LC-FR interfaces.
+
+   Edge Set
+
+      The Edge Set of an FR-LSR domain is the set of LSRs, which are
+      connected to the domain by LC-FR interfaces.
+
+   Forwarding Encapsulation
+
+      The Forwarding Encapsulation is the type of MPLS encapsulation
+      (Frame Relay, ATM, Generic) of a packet that determines the
+      packet's MPLS forwarding, or the network layer encapsulation if
+      that packet is forwarded based on the network layer (IP,
+      etc...)header.
+
+   Input Encapsulation
+
+      The Input Encapsulation is the type of MPLS encapsulation (Frame
+      Relay, ATM, Generic) of a packet when that packet is received on
+      an LSR's interface, or the network layer (IP, etc...)encapsulation
+      if that packet has no MPLS encapsulation.
+
+
+
+
+
+
+Conta, et al.               Standards Track                     [Page 3]
+
+RFC 3034            Label Switching with Frame Relay        January 2001
+
+
+   Output Encapsulation
+
+      The Output Encapsulation is the type of MPLS encapsulation (Frame
+      Relay, ATM, Generic) of a packet when that packet is transmitted
+      on an LSR's interface, or the network layer (IP,
+      etc...)encapsulation if that packet has no MPLS encapsulation.
+
+   Input TTL
+
+      The Input TTL is the MPLS TTL of the top of the stack when a
+      labeled packet is received on an LSR interface, or the network
+      layer (IP) TTL if the packet is not labeled.
+
+   Output TTL
+
+      The Output TTL is the MPLS TTL of the top of the stack when a
+      labeled packet is transmitted on an LSR interface, or the network
+      layer (IP) TTL if the packet is not labeled.
+
+   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) 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.
+
+
+
+
+Conta, et al.               Standards Track                     [Page 4]
+
+RFC 3034            Label Switching with Frame Relay        January 2001
+
+
+   -  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.
+
+   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:
+
+               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, et al.               Standards Track                     [Page 5]
+
+RFC 3034            Label Switching with Frame Relay        January 2001
+
+
+            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 use of the frame relay null encapsulation implies that labels
+   implicitly encode the network protocol type.
+
+   Rules regarding the construction of the label stack, and error
+   messages returned to the frame source are also described in [STACK].
+
+   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 top (current) 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.
+
+
+
+
+
+
+Conta, et al.               Standards Track                     [Page 6]
+
+RFC 3034            Label Switching with Frame Relay        January 2001
+
+
+   The allowable ranges of DLCIs, the size of DLCIs, and the support for
+   VC merging MUST be communicated through LDP messages.  Note that the
+   range of DLCIs used for labels depends on the size of the DLCI field.
+
+5.2  Homogeneous LSPs
+
+   If <LSR1, LSR2, LSR3> 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 <LSR1, LSR2, LSR3> 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 Generic (MPLS shim
+   header), or ATM encapsulation.  In such networks there may be some
+   LSRs, which have Frame Relay interfaces as well as MPLS Generic
+   ("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 a Generic MPLS
+   (MPLS shim) header on the outgoing interface.
+
+5.4  Frame Relay Label Switching Loop Prevention and Control
+
+   FR-LSRs SHOULD operate on loop free FR-LSPs or LSP Frame Relay
+   segments.  Therefore, FR-LSRs SHOULD use loop detection and MAY use
+   loop prevention mechanisms as 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.
+
+
+
+Conta, et al.               Standards Track                     [Page 7]
+
+RFC 3034            Label Switching with Frame Relay        January 2001
+
+
+   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 Frame Relay 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:
+
+      -  it treats the packet as an expired packet and return an ICMP
+         message to its source.
+
+      -  it forwards the packet, as an unlabeled packet, with a TTL that
+         reflects the IP (network layer) forwarding.
+
+   If the incoming TTL is 1, only the first option applies.
+
+   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.
+
+5.4.2  Performing MPLS TTL calculations
+
+   The calculation applied to the "input TTL" that yields the "output
+   TTL" depends on (i)the "input encapsulation", (ii)the "forwarding
+   encapsulation", and (iii)the "output encapsulation".  The
+   relationship among (i),(ii), and (iii), can be defined as a function
+
+
+
+
+Conta, et al.               Standards Track                     [Page 8]
+
+RFC 3034            Label Switching with Frame Relay        January 2001
+
+
+   "D" of "input encapsulation" (ie), "forwarding encapsulation" (fe),
+   and "output encapsulation" (oe).  Subsequently the calculation
+   applied to the "input TTL" to yield the "output TTL" can be described
+   as:
+
+     output TTL = input TTL - D(ie, fe, oe)
+
+   or in a brief notation:
+
+     output TTL = input TTL - d
+
+   where "d" has three possible values: "0","1", or "the number of hops
+   of the LSP segment":
+
+   For unicast transmission:
+
++================+=================+=================+=================+
+|                |     Type of     |     Type of     |     Type of     |
+|       d        |      Input      |    Forwarding   |     Output      |
+|                |  Encapsulation  |  Encapsulation  |  Encapsulation  |
++================+=================+=================+=================+
+|       0        |   Frame Relay   |   Frame Relay   |   Frame Relay   |
++----------------+-----------------+-----------------+-----------------+
+|       1        |       any       |  Generic MPLS   |  Generic MPLS   |
++----------------+-----------------+-----------------+-----------------+
+| number of hops |                 |  Generic MPLS   |                 |
+|      of        |       any       |      or         |   Frame Relay   |
+|  LSP segment   |                 |IP(network layer)|                 |
++================+=================+=================+=================+
+
+   The "number of hops of the LSP segment" is the value of the "hop
+   count" that is attached with the label used when the packet is
+   forwarded, if LDP [LDP] has provided such a "hop count" value when it
+   distributed the label for the LSP, that is the LDP message had a "hop
+   count object".  If LDP didn't provide a "hop count", or it provided
+   an "unknown" value, the default value of the "number of hops of the
+   segment" is 1.
+
+   When sending a label binding upstream, the "hop count" associated
+   with the corresponding binding from downstream, if different than the
+   "unknown" value, MUST be incremented by 1, and the result transmitted
+   upstream as the hop count associated with the new binding (the
+   "unknown" value is transmitted unchanged).  If the new "hop count"
+   value exceeds the "maximum" value, the FR-LSR MUST NOT pass the
+   binding upstream, but instead MUST send an error upstream
+   [LDP][ARCH].
+
+
+
+
+
+Conta, et al.               Standards Track                     [Page 9]
+
+RFC 3034            Label Switching with Frame Relay        January 2001
+
+
+   For multicast transmission:
+
++================+=================+=================+=================+
+|                |     Type of     |     Type of     |     Type of     |
+|       d        |      Input      |    Forwarding   |     Output      |
+|                |  Encapsulation  |  Encapsulation  |  Encapsulation  |
++================+=================+=================+=================+
+|       0        |   Frame Relay   |   Frame Relay   |   Frame Relay   |
++----------------+-----------------+-----------------+-----------------+
+|                |                 |  Generic MPLS   |                 |
+|       1        |       any       |      or         |   Frame Relay   |
+|                |                 |IP(network layer)|                 |
++----------------+-----------------+-----------------+-----------------+
+| number of hops |                 |  Generic MPLS   |                 |
+|      of        |  Frame Relay    |      or         |       any       |
+|  LSP segment   |                 |IP(network layer)|                 |
++================+=================+=================+=================+
+
+   Referring to the "forwarding encapsulation" with the abbreviation "I"
+   for IP (network layer), "G" for Generic MPLS, and "F" for Frame Relay
+   MPLS, referring to an LSR interface with the abbreviation "i" if the
+   input or output encapsulation is IP and no MPLS encapsulation, "g"
+   when the input or output MPLS encapsulation is Generic MPLS, "f" when
+   it is Frame Relay, "a" when it is ATM, and furthermore considering
+   the symbols "iIf", "gGf", "fFf", etc... as LSRs with input,
+   forwarding and output encapsulations as referred above, the following
+   describes examples of TTL calculations for the Homogeneous and
+   Heterogeneous LSPs discussed in previous sections:
+
+                         Homogeneous LSP
+                         ---------------
+        IP_ttl = n                             IP_ttl=mpls_ttl-1 = n-6
+        --------->iIf                      fIi--------->
+                    | mpls_ttl = n-5       ^
+                    |                      |
+number of hops     1|     Frame Relay      |5
+                    |                      |
+                    V   2      3      4    |
+                    fFf--->fFf--->fFf--->fFf
+
+ "iIf" is "ingress LSR" in Frame Relay LSP and
+        calculates: mpls_ttl = IP_TTL - number of hops = n-5
+ "fIi" is "egress LSR" from Frame Relay LSP, and
+        calculates: IP_ttl = mpls_ttl-1 = n-6
+
+
+
+
+
+
+
+Conta, et al.               Standards Track                    [Page 10]
+
+RFC 3034            Label Switching with Frame Relay        January 2001
+
+
+                          Heterogeneous LSP
+                          -----------------
+ingress LSR                                                  egress LSR
+IP_ttl = n                                               IP_ttl = n - 15
+links   LAN   PPP        FR          ATM    PPP    FR     LAN
+ --->iIg-->gGg-->gGf            fGa       aGg-->gGf       fGg-->gIi--->
+hops     1     2   |     6      | |   9   |  10   |  13   ^  14    15
+                   |1          4| |1     3|       |1     3|
+                   V  2     3   | V   2   |       V   2   |
+                  fFf-->fFf-->fFf aAa-->aAa       fFf-->fFf
+mpls_ttl
+       n-1   n-2  (n-2)-4=n-6  (n-6)-3=n-9  n-10  n-13     n-14
+
+
+"iIg" is "ingress LSR" in LSP; it calculates: mpls_ttl=n-1
+"gGf" is "egress LSR" from Generic MPLS segment, and
+      "ingress LSR" in Frame Relay segment and calculates: mpls_ttl=n-6
+"fGa" "egress LSR" from Frame Relay segment, and
+      "ingress LSR" in ATM segment and calculates: mpls_ttl=n-9
+"gGf" is "egress LSR" from Generic MPLS segment, and
+      "ingress LSR" in Frame Relay segment and calculates: mpls_ttl=n-13
+"fGg" is "egress LSR" from Frame Relay segment, and
+      ingress LSR" in Generic MPLS segment and calculates: mpls_ttl=n-14
+"gIi" is "egress LSR" from  LSP and calculates: IP_ttl=n-15
+
+
+      And further examples:
+
+                Frame Relay Unicast -- TTL calculated at ingress
+
+   (ingress LSR)  1     2        3      4
+            x--->---+--->---+--->>--+-->>---x (egress LSR)
+      o.ttl=i.ttl-4         |     2      3
+                            ^
+    hops                   1|
+                            |
+                            x (ingress LSR)
+                              o.ttl=i.ttl-3
+
+
+          Frame Relay Multicast -- TTL calculated at egress
+
+                (egress LSR)x  o.ttl=i.ttl-3
+    hops                    |
+                            ^3
+     (ingress LSR)          |            o.ttl=i.ttl-4
+            x--->---+--->---+--->---+--->---x (egress LSR)
+                1       2       3       4
+
+
+
+Conta, et al.               Standards Track                    [Page 11]
+
+RFC 3034            Label Switching with Frame Relay        January 2001
+
+
+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.
+
+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).
+
+
+
+
+
+
+
+Conta, et al.               Standards Track                    [Page 12]
+
+RFC 3034            Label Switching with Frame Relay        January 2001
+
+
+   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".
+
+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].
+
+
+
+
+
+
+Conta, et al.               Standards Track                    [Page 13]
+
+RFC 3034            Label Switching with Frame Relay        January 2001
+
+
+   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.
+
+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.
+
+
+
+
+
+
+Conta, et al.               Standards Track                    [Page 14]
+
+RFC 3034            Label Switching with Frame Relay        January 2001
+
+
+   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].  The "downstream-on-demand" label
+   allocation and maintenance mechanism discussed in this section MUST
+   be used by FR-LSRs that do not support VC merging, and it MAY also be
+   used by FR-LSRs that do support VC merging (note that this mechanism
+   applies to hop-by-hop routed traffic):
+
+7.1   Edge LSR Behavior
+
+   Consider a member of the Edge Set of a FR-LSR domain.  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
+   domain 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 domain 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
+   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 domain, 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.
+
+
+
+
+
+
+Conta, et al.               Standards Track                    [Page 15]
+
+RFC 3034            Label Switching with Frame Relay        January 2001
+
+
+   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 domain,
+   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
+   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
+
+
+
+Conta, et al.               Standards Track                    [Page 16]
+
+RFC 3034            Label Switching with Frame Relay        January 2001
+
+
+   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).
+
+   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).
+
+
+
+
+Conta, et al.               Standards Track                    [Page 17]
+
+RFC 3034            Label Switching with Frame Relay        January 2001
+
+
+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 domain. 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 (VC merging) 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 (VC merging) can be performed.
+
+   When label conservation is used, when a FR-LSR receives a binding
+   request from an upstream LSR for a certain FEC, and it does already
+   have an outgoing label binding for that FEC, it does not need to
+   issue a downstream binding request.  Instead, it may allocate an
+   incoming label, and return that label in a binding to the upstream
+   requester.  Packets received from the requester, with that label as
+   top label, will be forwarded after replacing the label with the
+   existing outgoing label for that FEC.  If the FR-LSR does not have an
+   outgoing label binding for that FEC, but does have an outstanding
+   request for one, it need not issue another request.  This means that
+   in a label conservation case, a FR-LSR must respond with a new
+   binding for every upstream request, but it may need to send one
+   binding request downstream.
+
+   In case of label conservation, if a change in the routing table
+   causes FR-LSR to select a new next hop for one of its FECs, it MAY
+   release the binding for that route from the former next hop.  If it
+   doesn't already have a corresponding binding for the new next hop, it
+   must request one (note that the choice depends on the label retention
+   mode [ARCH]).
+
+   If a new binding is obtained, which contain a hop count that differs
+   from that of the old binding, the FR-LSR must process the new hop
+   count: increment by 1, if different than "unknown", and notify the
+   upstream neighbors who have label bindings for this FEC of the new
+   value.  To ensure that loops will be detected, if the new hop count
+   exceeds the "maximum" value, the label values for this FEC must be
+   withdrawn from all upstream neighbors to whom a binding was
+   previously sent.
+
+
+
+Conta, et al.               Standards Track                    [Page 18]
+
+RFC 3034            Label Switching with Frame Relay        January 2001
+
+
+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:
+
+   "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
+          2     23
+
+      Len values 1 and 3 are reserved for future use.
+
+   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.
+
+
+
+
+
+Conta, et al.               Standards Track                    [Page 19]
+
+RFC 3034            Label Switching with Frame Relay        January 2001
+
+
+   "Frame Relay Merge":
+
+          0 1 2 3 4 5 6 7
+         +-+-+-+-+-+-+-+-+
+         | Reserved    |M|
+         +-+-+-+-+-+-+-+-+
+
+      with the following fields:
+
+   Merge
+      One bit field that specifies the merge capabilities of the FR-LSR:
+
+      Value                  Meaning
+
+        0                    Merge NOT supported
+        1                    Merge supported
+
+      A FR-LSR that supports VC merging MUST ensure that fragmented
+      frames from distinct incoming DLCIs are not interleaved on the
+      outgoing DLCI.
+
+   Reserved
+      This field is reserved.  It must be set to zero on transmission
+      and must be ignored on receipt.
+
+   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:
+
+   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
+          2     23
+
+
+
+
+Conta, et al.               Standards Track                    [Page 20]
+
+RFC 3034            Label Switching with Frame Relay        January 2001
+
+
+      Len values 1 and 3 are reserved for future use.
+
+   DLCI
+      The binary value of the Frame Relay Label.  The significant number
+      of bits (10 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].
+
+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,
+   Eric Rosen.  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.
+
+
+
+
+
+
+Conta, et al.               Standards Track                    [Page 21]
+
+RFC 3034            Label Switching with Frame Relay        January 2001
+
+
+10.  References
+
+   [MIFR]  Bradley, T., Brown, C. and A. Malis, "Multiprotocol
+           Interconnect over Frame Relay", RFC 2427, September 1998.
+
+   [ARCH]  Rosen, E., Callon, R. and A. Vishwanathan, "Multi-Protocol
+           Label Switching Architecture", RFC 3031, January 2001.
+
+   [LDP]   Andersson, L., Doolan, P., Feldman, N., Fredette, A. and R.
+           Thomas, "Label Distribution Protocol", RFC 3036, January
+           2001.
+
+   [STACK] Rosen, E., Rehter, Y., Tappan, D., Farinacci, D., Fedorkow,
+           G., Li, T. and A. Conta, "MPLS Label Stack Encoding", RFC
+           3032, January 2001.
+
+   [ATM]   Davie, B., Lawrence, J., McCloghrie, M., Rosen, E., Swallow,
+           G., Rekhter, Y., and P. Doolan, "Use of Label Switching with
+           ATM", RFC 3035, January 2001.
+
+   [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, et al.               Standards Track                    [Page 22]
+
+RFC 3034            Label Switching with Frame Relay        January 2001
+
+
+11.  Authors' Addresses
+
+   Alex Conta
+   Transwitch Corporation
+   3 Enterprise Drive
+   Shelton, CT 06484
+
+   Phone: 1-203-929-8810
+   EMail: aconta@txc.com
+
+
+   Paul Doolan
+   Ennovate Networks
+   60 Codman Hill Rd
+   Boxborough MA 01719
+
+   Phone: 1-978-263-2002
+   EMail: pdoolan@ennovatenetworks.com
+
+
+   Andrew G. Malis
+   Vivace Networks, Inc.
+   2730 Orchard Parkway
+   San Jose, CA 95134
+   USA
+
+   Phone: 1-408-383-7223
+   Fax:   1-408-904-4748
+   EMail: Andy.Malis@vivacenetworks.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Conta, et al.               Standards Track                    [Page 23]
+
+RFC 3034            Label Switching with Frame Relay        January 2001
+
+
+12.  Full Copyright Statement
+
+   Copyright (C) The Internet Society (2001).  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assigns.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Conta, et al.               Standards Track                    [Page 24]
+