Multiprotocol Interconnect over Frame Relay (RFC1294)
Original Publication Date: 1992-Jan-01
Included in the Prior Art Database: 2019-Feb-11
Internet Society Requests For Comment (RFCs)
T. Bradley: AUTHOR [+2]
This memo describes an encapsulation method for carrying network interconnect traffic over a Frame Relay backbone. It covers aspects of both Bridging and Routing. [STANDARDS-TRACK]
Network Working Group T. Bradley Request for Comments: 1294 C. Brown Wellfleet Communications, Inc. A. Malis BBN Communications January 1992
Multiprotocol Interconnect over Frame Relay
1. Status of this Memo
This RFC specifies an IAB standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "IAB Official Protocol Standards" for the standardization state and status of this protocol. Distribution of this memo is unlimited.
This memo describes an encapsulation method for carrying network interconnect traffic over a Frame Relay backbone. It covers aspects of both Bridging and Routing. Systems with the ability to transfer both this encapsulation method, and others must have a priori knowledge of which virtual circuits will carry which encapsulation method and this encapsulation must only be used over virtual circuits that have been explicitly configured for its use.
Comments and contributions from many sources, especially those from Ray Samora of Proteon, Ken Rehbehn of Netrix Corporation, Fred Baker and Charles Carvalho of Advanced Computer Communications and Mostafa Sherif of AT&T have been incorporated into this document. Special thanks to Dory Leifer of University of Michigan for his contributions to the resolution of fragmentation issues. This document could not have been completed without the expertise of the IP over Large Public Data Networks working group of the IETF.
The following language conventions are used in the items of specification in this document:
o Must, Shall or Mandatory -- the item is an absolute requirement of the specification.
o Should or Recommended -- the item should generally be followed for all but exceptional circumstances.
Bradley, Brown, Malis [Page 1]
RFC 1294 Multiprotocol over Frame Relay January 1992
o May or Optional -- the item is truly optional and may be followed or ignored according to the needs of the implementor.
The following discussion applies to those devices which serve as end stations (DTEs) on a public or private Frame Relay network (for example, provided by a common carrier or PTT). It will not discuss the behavior of those stations that are considered a part of the Frame Relay network (DCEs) other than to explain situations in which the DTE must react.
The Frame Relay network provides a number of virtual circuits that form the basis for connections between stations attached to the same Frame Relay network. The resulting set of interconnected devices forms a private Frame Relay group which may be either fully interconnected with a complete "mesh" of virtual circuits, or only partially interconnected. In either case, each virtual circuit is uniquely identified at each Frame Relay interface by a Data Link Connection Identifier (DLCI). In most circumstances DLCIs have strictly local significance at each Frame Relay interface.