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.
Laubach [Page 1]
RFC 1577 Classical IP and ARP over ATM January 1993
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 Resolution Protocol (ATMARP) requests and replies over ATM
Adaptation Layer 5 (AAL5)[2,6].
Note: this memo defines only the operation of IP and address
resolution over ATM, and is not meant to describe the operation of
ATM networks. Any reference to virtual connections, permanent virtual
connections, or switched virtual connections applies only to virtual
channel connections used to support IP and address resolution over
ATM, and thus are assumed to be using AAL5. This memo places no
restrictions or requirements on virtual connections used for other
purposes.
Initial deployment of ATM provides a LAN segment replacement for:
1) Local area networks (e.g., Ethernets, Token Rings and FDDI).
2) Local-area backbones between existing (non-ATM) LANs.
3) Dedicated circuits or frame relay PVCs between IP routers.
Note: In 1), local IP routers with one or more ATM interfaces will be
able to connect islands of ATM networks. In 3), public or private
ATM Wide Area networks will be used to connect IP routers, which in
turn may or may not connect to local ATM networks. ATM WANs and LANs
may be interconnected.
Private ATM networks (local or wide area) will use the private ATM
address structure specified in the ATM Forum UNI specification [9].
This structure is modeled after the format of an OSI Network Service
Access Point Address. A private ATM address uniquely identifies an
Laubach [Page 2]