RFC 3034 (rfc3034) - Page 2 of 24
Use of Label Switching on Frame Relay Networks Specification
Alternative Format: Original Text Document
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