Multiprotocol Interconnect over Frame Relay (RFC2427)
Original Publication Date: 1998-Sep-01
Included in the Prior Art Database: 2000-Sep-13
Internet Society Requests For Comment (RFCs)
C. Brown: 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.
Network Working Group C. Brown
Request for Comments: 2427 Consultant
STD: 55 A. Malis
Obsoletes: 1490, 1294 Ascend Communications, Inc.
Category: Standards Track September 1998
Multiprotocol Interconnect over Frame Relay
Status of this Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright (C) The Internet Society (1998). All Rights Reserved.
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 the encapsulation method
described in this document, 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.
This document could not have been completed without the support of
Terry Bradley of Avici Systems, Inc.. Comments and contributions
from many sources, especially those from Ray Samora of Proteon, Ken
Rehbehn of Visual Networks, Fred Baker and Charles Carvalho of Cisco
Systems, 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 (though
it was deleted in the final version) and Floyd Backes and Laura
Bridge of 3Com for their contributions to the bridging descriptions.
This document could not have been completed without the expertise of
the IP over Large Public Data Networks and the IP over NBMA working
groups of the IETF.
1. Conventions and Acronyms
The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this
document, are to be interpreted as described in .
All drawings in this document are drawn with the left-most bit as the
high order bit for transmission. For example, the drawings might be
0 1 2 3 4 5 6 7 bits
| flag (7E hexadecimal) |
| Q.922 Address* |