One document matched: draft-conta-mpls-fr-00.txt
MPLS Working Group A. Conta (Lucent)
INTERNET-DRAFT P. Doolan (Cisco)
September 1997
Use of Label Switching With Frame Relay
Specification
draft-conta-mpls-fr-00.txt
Status of this Memo
This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its Areas,
and its Working Groups. Note that other groups may also distribute
working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months. Internet-Drafts may be updated, replaced, or obsoleted by
other documents at any time. It is not appropriate to use Internet-
Drafts as reference material or to cite them other than as a "working
draft" or "work in progress."
To learn the current status of any Internet-Draft, please check the
"1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
ftp.isi.edu (US West Coast).
Distribution of this memo is unlimited.
Abstract
This document defines the model and generic mechanisms for
Multiprotocol Label Switching on Frame Relay networks. A
Multiprotocol Label Switching Architecture is described in [ARCH].
MPLS enables the use of Frame Relay Switches as Label Switching
Routers (LSRs). The Frame Relay Switches run network layer routing
algorithms (such as OSPF, IS-IS, etc.), and their data forwarding is
based on the results of these routing algorithms. No Frame Relay-
specific routing is needed.
Conta Expires in six months [Page 1]
INTERNET-DRAFT Use of Label Switching With Frame Relay September 15, 1997
Table of Contents
Status of this Memo.........................................1
Table of Contents...........................................2
1. Introduction................................................3
2. Terminology.................................................3
3. Special Characteristics of Frame Relay Switches.............4
4 Label Switching Control Component for Frame Relay...........4
5 Hybrid Switches (Ships in the Night) ......................5
6 Use of DLCIs ..............................................6
7 Label Allocation and Maintenance Procedures ................7
7.1 Edge LSR Behavior......................................7
7.2 Efficient use of label space.. ......................10
8 Label Encapsulation ......................................10
9 Security Considerations ..................................11
10 Acknowledgments ..........................................11
11 References ...............................................11
12 Authors' Addresses .......................................12
Conta Expires in six months [Page 2]
INTERNET-DRAFT Use of Label Switching With Frame Relay September 15, 1997
1. Introduction
A 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.
Frame Relay permanent virtual circuits (PVCs) could be configured to
carry label switching based traffic. The traffic through the PVCs
would be forwarded based on network layer routing information.
When a Frame Relay switch is used for label switching, the label on
which forwarding decisions are based is carried in the DLCI field of
the Frame Relay data link layer header of a frame. In this case
other labels, if the packet is multiply labeled, are carried in the
generic MPLS encapsulation defined in [STACK].
Although we deal here with the use of DLCIs as MPLS Labels and the
transformation thereby of FR Switches into MPLS switches we note that
MPLS traffic could be carried over FR PVCs using the techniques of
RFC1490.
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 a number of LC-FR interfaces which
forwards frames between these interfaces using labels carried in
Conta Expires in six months [Page 3]
INTERNET-DRAFT Use of Label Switching With Frame Relay September 15, 1997
the DLCI field.
FR-LSR cloud
A FR-LSR cloud is a set of FR-LSRs which are mutually
interconnected by LC-FR interfaces.
Edge Set
The Edge Set of an FR-LSR cloud is the set of LSRs which are
connected to the cloud by LC-FR interfaces.
3. Special characteristics of Frame Relay Switches
While the label switching architecture permits considerable
flexibility in LSR implementation, a FR-LSR is constrained by the
capabilities of the (possibly pre-existing) hardware and the
restrictions on such matters as frame format imposed by RFC 1490, or
Frame Relay standards (Q.922, etc). Because of these constraints,
some special procedures are required for FR-LSRs.
Some of the key features of Frame Relay switches that affects their
behavior as LSRs are:
- the label swapping function is performed on fields (DLCI) in the
frame's Frame Relay data link header; this dictates the size and
placement of the label(s) in a packet. The size of the DLCI
field can be 10 (default), 17, or 24 bits, and it can span two,
three, or respectively four bytes in the header.
- congestion control is performed by each node based on parameters
that are passed at circuit creation. Flags in the frame headers
may be set as a consequence of congestion, or exceeding the
contractual parameters of the circuit.
- multipoint-to-point and multipoint-to-multipoint VCs are
generally not supported.
- there is generally no capability to perform a `TTL-decrement'
function as is performed on IP headers in routers.
This document describes ways of applying label switching to Frame
Relay switches which work within these constraints.
Conta Expires in six months [Page 4]
INTERNET-DRAFT Use of Label Switching With Frame Relay September 15, 1997
4. Label Switching Control Component for Frame Relay
To support label switching a Frame Relay Switch must implement the
control component of label switching. This consists primarily of
label allocation and maintenance procedures. Label binding
information may be communicated by several mechanisms, one of which
is the Label Distribution Protocol (LDP) [LDP].
Since the label switching control component uses information learned
directly from network layer routing protocols, this implies that the
switch must participate as a peer in these protocols (e.g., OSPF,
IS-IS).
In some cases, LSRs make use of other protocols (e.g. RSVP, PIM, BGP)
to distribute label bindings. In these cases, a Frame Relay LSR would
need to participate in these protocols.
Frame Relay permanent virtual circuits (PVCs) can be used to carry
MPLS traffic using the encapsulation techniques described in RFC1490.
In such a case the DLCIs allocated for the PVCs will be distributed
as MPLS labels by LDP.
In the case where Frame Relay circuits are established via LDP, or
RSVP, 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 could be passed to the FR-LSRs
through RSVP. 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.
Control and state information for the circuits based on MPLS could be
communicated through LDP.
Support of label switching on a Frame Relay switch does not require
the switch to support the Frame Relay control component defined by
the ITU (I.451, Q.922) and Frame Relay Forum (e.g., UNI, NNI). A FR-
LSR may optionally support and respond to LMI commands.
5. Hybrid Switches (Ships in the Night)
The existence of the label switching control component on a Frame
Conta Expires in six months [Page 5]
INTERNET-DRAFT Use of Label Switching With Frame Relay September 15, 1997
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. The two control components,
label switching and the ITU/Frame Relay Forum defined, 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.
6. 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. 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 Label Information Base, replaced with the correspondent output
DLCI, and transmitted on the outgoing interface (forwarded to the
next hop node).
Note that the current label information is also carried in the top of
the label stack. In the top level entry, only the TTL field is truely
significant.
For two connected FR-LSRs, a full-duplex connection must be available
for LDP. By default, the DLCI for the LDP VC is assigned a value of
[TBD].
With the exception of this reserved value, the DLCI values used 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, which can be 10 (default), 17, or 24 bits.
Conta Expires in six months [Page 6]
INTERNET-DRAFT Use of Label Switching With Frame Relay September 15, 1997
7 Label Allocation and Maintenance Procedures
FR-LSRs use the downstream-on-demand allocation mechanism described
in [ARCH].
7.1 Edge LSR Behavior
Consider a member of the Edge Set of a FR-LSR cloud. Assume that, as
a result of its routing calculations, it selects a FR-LSR as the next
hop of a certain route, and that the next hop is reachable via a LC-
Frame Relay interface. The Edge LSR uses LDP's BIND_REQUEST to
request a label binding from the next hop. The hop count field in
the request is set to 1. Once the Edge LSR receives the label
binding information, the label is used as an outgoing label. The
binding received by the edge LSR may contain a hop count, which
represents the number of hops a packet will take to cross the FR-LSR
cloud when using this label. The edge LSR may either
- use this hop count to decrement the TTL of packets before
transmitting them over the cloud
- decrement the TTL of packets by one before transmitting them
over the cloud.
The choice between these two options should be made based on local
configuration.
When a member of the Edge Set of the FR-LSR cloud receives a label
binding request from a FR-LSR, it allocates a label, creates a new
entry in its Label Information Base (LIB), places that label in the
incoming label component of the entry, and returns (via LDP) a
binding containing the allocated label back to the peer that
originated the request. It sets the hop count in the binding to 1.
When a routing calculation causes an Edge LSR to change the next hop
for a route, and the former next hop was in the FR-LSR cloud, the
Edge LSR should notify the former next hop (via LDP) that the label
binding associated with the route is no longer needed.
When a Frame Relay-LSR receives (via LDP) a label binding request for
a certain route from a peer connected to the FR-LSR over a LC-FR
interface, the FR-LSR takes the following actions:
- it allocates a label, creates a new entry in its Label
Conta Expires in six months [Page 7]
INTERNET-DRAFT Use of Label Switching With Frame Relay September 15, 1997
Information Base (LIB), and places that label in the
incoming label component of the entry;
- it requests (via LDP) a label binding from the next hop for
that route;
- it returns (via LDP) a binding containing the allocated
incoming label back to the peer that originated the
request.
The hop count field in the request that the FR-LSR sends (to the next
hop LSR) is set to the hop count field in the request that it
received from the upstream LSR plus one. Once the FR-LSR receives
the binding from the next hop, it places the label from the binding
into the outgoing label component of the LIB entry.
The FR-LSR may choose to wait for the request to be satisfied from
downstream before returning the binding upstream (a "conservative"
approach). In this case, the FR-LSR increments the hop count it
received from downstream and uses this value in the binding it
returns upstream. If the value of the hop count equals MAX_HOP_COUNT
the FR-LSR should notify the upstream neighbor that it could not
satisfy the binding request.
Alternatively, the FR-LSR may return the binding upstream without
waiting for a binding from downstream (an "optimistic" approach). In
this case, it uses a reserved value for hop count in the binding,
indicating that it is unknown. The correct value for hop count will
be returned later, as described below.
Since both the conservative and the optimistic approach has
advantages and disadvantages, this is left as an implementation
choice.
Note that a FR-LSR, or a member of the edge set of a FR-LSR cloud,
may receive multiple binding requests for the same route from the
same FR-LSR. It must generate a new binding for each request
(assuming adequate resources to do so), and retain any existing
binding(s). For each request received, a FR-LSR should also generate
a new binding request toward the next hop for the route.
When a routing calculation causes a FR-LSR to change the next hop for
a route, the FR-LSR should notify the former next hop (via LDP) that
the label binding associated with the route is no longer needed.
When a LSR receives a notification that a particular label binding is
no longer needed, the LSR may deallocate the label associated with
Conta Expires in six months [Page 8]
INTERNET-DRAFT Use of Label Switching With Frame Relay September 15, 1997
the binding, and destroy the binding. In the case where a FR-LSR
receives such notification and destroys the binding, it should notify
the next hop for the route that the label binding is no longer
needed. If a LSR does not destroy the binding, it may re-use the
binding only if it receives a request for the same route with the
same hop count as the request that originally caused the binding to
be created.
When a route changes, the label bindings are re-established from the
point where the route diverges from the previous route. LSRs
upstream of that point are (with one exception, noted below)
oblivious to the change. Whenever a LSR changes its next hop for a
particular route, if the new next hop is a FR-LSR or a member of the
edge set reachable via a LC-FR interface, then for each entry in its
LIB associated with the route the LSR should request (via LDP) a
binding from the new next hop.
When a FR-LSR receives a label binding from a downstream neighbor, it
may already have provided a corresponding label binding for this
route to an upstream neighbor, either because it is operating
optimistically or because the new binding from downstream is the
result of a routing change. In this case, it should extract the hop
count from the new binding and increment it by one. If the new hop
count is different from that which was previously conveyed to the
upstream neighbor (including the case where the upstream neighbor was
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. If at
any point the value of the hop count equals MAX_HOP_COUNT, the FR-
LSR should withdraw the binding from the upstream neighbor.
Whenever a FR-LSR originates a label binding request to its next hop
LSR as a result of receiving a label binding request from another
(upstream) LSR, and the request to the next hop LSR is not satisfied,
the FR-LSR should destroy the binding created in response to the
received request, and notify the requester (via LDP).
If a FR-LSR receives a binding request containing a hop count that
equals MAX_HOP_COUNT, no binding should be established and an error
message should be returned to the requester.
When a LSR determines that it has lost its LDP session with another
LSR, the following actions are taken. Any binding information
learned via this connection must be discarded. For any label
bindings that were created as a result of receiving label binding
requests from the peer, the LSR may destroy these bindings (and
deallocate labels associated with these binding).
Conta Expires in six months [Page 9]
INTERNET-DRAFT Use of Label Switching With Frame Relay September 15, 1997
7.2 Efficient use of label space
The above discussion assumes that an edge LSR will request one label
for each prefix in its routing table that has a next hop in the FR-
LSR cloud. In fact, it is possible to significantly reduce the number
of labels needed by having the edge LSR request instead one label for
several routes. Use of many-to-one mappings between routes (address
prefixes) and labels using the notion of Forwarding Equivalence
Classes (as described in [ARCH]) provides a mechanism to conserve the
number of labels.
Note that conserving label space may be restricted in case the frame
traffic requires Frame Relay fragmentation. The issue is that Frame
Relay fragments must be transmitted in sequence, i.e. fragments of
distinct frames must not be interleaved. If the fragmenting FR-LSR
ensures the transmission in sequence of all fragments of a frame,
without interleaving with fragments of other frames, then label
conservation (aggregation) can be performed.
In the case where the label space is to be conserved, it is desirable
to use half-duplex (unidirectional) VCs, since a "many to few"
aggregation is possible in one direction but not in reverse.
8. Label Encapsulation
By default, all labeled packets should be transmitted with the
generic label encapsulation as defined in [STACK], using the frame
relay encapsulation mechanisms described in RFC 1490, and protocol
types defined in [STACK]. Rules regarding the construction of the
label stack, and error messages returned to the frame source are also
described in [STACK].
Since the value at the top of the label stack is determined from the
DLCI field, the information carried in the label stack for the
current label is significant only for the TTL field. The generic
encapsulation contains n labels for a label stack of depth n, where
the only significant field in the current label stack entry is TTL.
This means that for one level of labels the generic encapsulation
consists of a label carrying a TTL only.
Conta Expires in six months [Page 10]
INTERNET-DRAFT Use of Label Switching With Frame Relay September 15, 1997
9. Security Considerations
This section looks at the security aspects of:
- frame traffic
- label distribution.
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].
10. Acknowledgments
This document is derived from the Label Switching over ATM document
[ATM].
Thanks for the extensive reviewing and constructive comments from (in
alphabetical order) Dan Harrington, Milan Merhar, Martin Mueller.
11. References
[RFC-1490] T. Bradley, C. Brown, A. Malis "Multiprotocol Interconnect
over Frame Relay"
[ARCH] "Proposed Architecture for MPLS" in "draft-rosen-mpls-00.txt"
by Rosen, Callon, Vishwanathan.
[LDP] Label Distribution Protocol - work in progress.
[STACK] "Label Switching: Label Stack Encodings" "draft-rosen-tag-
stack-02.txt" by Rosen et al.
[ATM] "draft-davie-tag-switchingatm-01.txt" by Davie et al.
Conta Expires in six months [Page 11]
INTERNET-DRAFT Use of Label Switching With Frame Relay September 15, 1997
Authors' Addresses:
Alex Conta Paul Doolan
Lucent Technologies Inc. Cisco Systems, Inc
300 Baker Ave, Suite 100 250 Apollo Drive
Concord, MA 01742 Chelmsford, MA, 01824
+1-508-287-2842 +1-508-244-8917
E-mail: aconta@lucent.com E-mail: pdoolan@cisco.com
Conta Expires in six months [Page 12]
| PAFTECH AB 2003-2026 | 2026-04-24 01:55:53 |