Dismiss
InnovationQ will be updated on Sunday, Oct. 22, from 10am ET - noon. You may experience brief service interruptions during that time.
Browse Prior Art Database

Multiprotocol Interconnect over Frame Relay (RFC2427)

IP.com Disclosure Number: IPCOM000003004D
Original Publication Date: 1998-Sep-01
Included in the Prior Art Database: 2000-Sep-13
Document File: 26 page(s) / 69K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

C. Brown: AUTHOR [+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.

This text was extracted from a ASCII document.
This is the abbreviated version, containing approximately 4% of the total text.

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 Notice

Copyright (C) The Internet Society (1998). All Rights Reserved.

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 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.

Acknowledgments

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 [16].

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

labeled as:

0 1 2 3 4 5 6 7 bits

+---+---+---+---+---+---+---+

...