rfc3034.txt

最新的RFC

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]