rfc3034.txt

最新的RFC


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]