Dismiss
InnovationQ/InnovationQ Plus content will be updated on Sunday, June 25, 10am ET, with new patent and non-patent literature collections. Click here to learn more.
Browse Prior Art Database

Classical IP and ARP over ATM (RFC1577)

IP.com Disclosure Number: IPCOM000002411D
Original Publication Date: 1994-Jan-01
Included in the Prior Art Database: 2000-Sep-12
Document File: 15 page(s) / 39K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

M. Laubach: AUTHOR

Abstract

This memo defines an initial application of classical IP and ARP in an Asynchronous Transfer Mode (ATM) network environment configured as a Logical IP Subnetwork (LIS) as described in Section 3. This memo does not preclude the subsequent development of ATM technology into areas other than a LIS; specifically, as single ATM networks grow to replace many ethernet local LAN segments and as these networks become globally connected, the application of IP and ARP will be treated differently. This memo considers only the application of ATM as a direct replacement for the "wires" and local LAN segments connecting IP end-stations ("members") and routers operating in the "classical" LAN-based paradigm. Issues raised by MAC level bridging and LAN emulation are beyond the scope of this paper.

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

Network Working Group M. Laubach

Request for Comments: 1577 Hewlett-Packard Laboratories

Category: Standards Track January 1994

Classical IP and ARP over ATM

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.

Abstract

This memo defines an initial application of classical IP and ARP in

an Asynchronous Transfer Mode (ATM) network environment configured as

a Logical IP Subnetwork (LIS) as described in Section 3. This memo

does not preclude the subsequent development of ATM technology into

areas other than a LIS; specifically, as single ATM networks grow to

replace many ethernet local LAN segments and as these networks become

globally connected, the application of IP and ARP will be treated

differently. This memo considers only the application of ATM as a

direct replacement for the "wires" and local LAN segments connecting

IP end-stations ("members") and routers operating in the "classical"

LAN-based paradigm. Issues raised by MAC level bridging and LAN

emulation are beyond the scope of this paper.

This memo introduces general ATM technology and nomenclature.

Readers are encouraged to review the ATM Forum and ITU-TS (formerly

CCITT) references for more detailed information about ATM

implementation agreements and standards.

Acknowledgments

This memo could not have come into being without the critical review

from Jim Forster of Cisco Systems, Drew Perkins of FORE Systems, and

Bryan Lyles, Steve Deering, and Berry Kercheval of XEROX PARC. The

concepts and models presented in [1], written by Dave Piscitello and

Joseph Lawrence, laid the structural groundwork for this work. ARP

[3] written by Dave Plummer and Inverse ARP [12] written by Terry

Bradley and Caralyn Brown are the foundation of ATMARP presented in

this memo. This document could have not been completed without the

expertise of the IP over ATM Working Group of the IETF and the ad hoc

PVC committee at the Amsterdam IETF meeting.

1. 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 RECOMMEND -- this item should generally be followed for

all but exceptional circumstances.

o MAY or OPTIONAL -- the item is truly optional and may be followed

or ignored according to the needs of the implementor.

2. Introduction

The goal of this specification is to allow compatible and

interoperable implementations for transmitting IP datagrams and ATM

Address...