Multiprotocol Interconnect over Frame Relay
RFC 1294

Document Type RFC - Proposed Standard (January 1992; No errata)
Obsoleted by RFC 2427, RFC 1490
Authors Terry Bradley  , Caralyn Brown  , Andy Malis 
Last updated 2013-03-02
Stream IETF
Formats plain text html pdf htmlized bibtex
Stream WG state (None)
Document shepherd No shepherd assigned
IESG IESG state RFC 1294 (Proposed Standard)
Consensus Boilerplate Unknown
Telechat date
Responsible AD (None)
Send notices to (None)
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.

2.  Abstract

   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.

3.  Acknowledgements

   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.

4.  Conventions

   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

5.  Introduction

   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.

   The specifications in this document are intended to apply to both
   switched and permanent virtual circuits.

6.  Frame Format

   All protocols must encapsulate their packets within a Q.922 Annex A
   frame [1,2].  Additionally, frames shall contain information
   necessary to identify the protocol carried within the Protocol Data
   Unit (PDU), thus allowing the receiver to properly process the
   incoming packet.  The format shall be as follows:

Bradley, Brown, Malis                                           [Page 2]
RFC 1294             Multiprotocol over Frame Relay         January 1992

         |    flag (7E hexadecimal)    |
         |       Q.922 Address*        |
         +--                         --+
         |                             |
         | Control (UI = 0x03)         |
         | Optional Pad(s)   (0x00)    |
         | NLPID                       |
         |             .               |
         |             .               |
         |             .               |
         |           Data              |
         |             .               |
         |             .               |
         |   Frame Check Sequence      |
Show full document text