Internet DRAFT - draft-ietf-atm-classical
draft-ietf-atm-classical
Network Working Group Mark Laubach
Request for Comments: DRAFT Hewlett-Packard Laboratories
Expires December 7, 1993 June 7, 1993
Classical IP and ARP over ATM
Positioning note for Readers
[This section to be removed after draft is reviewed a few times.]
This document is the deliverable from an action item made at the
Columbus IETF IP-over-ATM working group meeting on 3/28-3/30, 1993.
In that meeting, the group enthusiastically (with applause) agreed to
segment activities into two areas of focus: one is the treatment as
ATM as a "wire replacement" for connecting IP host and routers,
maintaining the current IP, ARP, and subnet architecture. This was
dubbed the "classical" approach. The other focus area is the world
where ATM subnets and peernets are widely deployed and globally
connected, where the architecture of IP and ARP will need to change
to take advantage of the features provided to it by this fully
deployed ATM.
It was felt that writing down the "Classical IP over ATM"
specifications would be straightforward. This memo is a direct result
of that action item and hopes to be the "starting block" for the
efforts to come. Future memos will be forthcoming from the working
group that update or obsolete this one as ATM becomes better defined
and more fully deployed.
The main differences between "classical" and "subnet/peernet" models
are:
Classical
o One default maximum MTU size for the interface, consistent with
current implementations.
o Default LLC/SNAP encapsulation, with administrator allowed re-
configuration.
o IP destinations map to VC's via ARP and route lookups, consistent
with current model.
o ARP's stay within the LIS, current ARP architecture stays the
same.
Laubach [Page 1]
DRAFT Classical IP and ARP over ATM May 1993
o One IP subnet used for many hosts/routers. A separate VC is used
for each host/router pair, one subnet is used for all these VC's.
o PVC's dominate, we're stuck with them for awhile.
o Standard ATM signalling is non-existent.
Subnet/Peernet:
o MTU size negotiated per VC via ATM signalling, requires MTU size
be separated from interface in protocol stack.
o Encapsulation negotiated per VC via ATM signalling, requires
common signalling to be implemented and globally available.
o Any applications map to VC's, requires changes to TCP/UDP/IP to
allow ports to map directly on to VC's
o ARP's can go global, ARP architecture needs to change to support
a robust global client/server model.
o Differing QOS's will exist on a per application basis.
The deployment of ATM into the internet community is beginning and
will take several years to implement. During this period, we expect
deployment to follow logical ("classical") IP subnet boundaries for
the following reasons:
o Administrators and managers of IP subnetworks will tend to
initially follow the same models as they currently have deployed.
The mindset of the community will change slowly over time as ATM
increases its coverage and builds its credibility.
o Policy administration practices rely on the security, access,
routing, and filtering capability of IP Internet gateways: i.e.
firewalls. ATM will not be allowed to "back-door" these
mechanisms until ATM provides better management capability than
the existing services and practices.
The need for standardization for the "classical" approach is wide-
spread and urgently needed. It is the intent of this position note to
make the point that this memo should be moved quickly through the
working group and into the draft standards process.
Status of this Memo
This document is an internet draft. Internet Drafts are working
documents of the Internet Engineering Task Force (IETF), its Areas,
Laubach [Page 2]
DRAFT Classical IP and ARP over ATM May 1993
and its Working Groups. Note that other groups may also distribute
working documents as Internet Drafts.
Internet Drafts are draft documents valid for a maximum of six
months. Internet Drafts may be updated, replaced, or obsoleted by
other documents at any time. It is not appropriate to use Internet
Drafts as reference material or to cite them other than as a "working
draft" or "work in progress". Please check the lid-abstracts.txt
listing contained in the internet-drafts shadow directories on
nic.ddn.mil, nnsc.nsf.net, nic.nordu.net, ftp.nisc.src.com, or
munnari.oz.au to learn the current status of any Internet Draft.
1. Abstract
This memo describes an initial application of classical IP and ARP in
an ATM network environment configured as a logical IP subnetwork, or
"LIS" as described below and in [1]. This memo does not preclude the
subsequent development of ATM technology into areas other than an
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 document considers only the application of ATM a as a direct
replacement for the "wires" and local LAN segments connecting IP
end-stations and routers. Issues raised by MAC level bridging are
beyond the scope of this paper.
3. Acknowledgment
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 and Steve Deering of XEROX PARC. The concepts and models
presented in [1], written by Dave Piscitello and Joseph Lawrence,
laid the structural groundwork for this work. This document could
have not been completed without the expertise of the IP over ATM
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 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
Laubach [Page 3]
DRAFT Classical IP and ARP over ATM May 1993
or ignored according to the needs of the implementor.
5. Introduction
The goal of this specification is to allow compatible and
interoperable implementations for transmitting IP datagrams and ARP
requests and replies over ATM Adaptation Layer 5 (AAL5)[6].
Currently, ATM standards are being defined in the ATM-FORUM, the
ITU-TSS (formally CCITT), and ANSI. ITU-TSS and ANSI are defining
standards for public ATM networks, ATM-FORUM defines public and local
aspects of ATM standardization. It is the intent of this document to
follow ATM-FORUM standards for the use of Classical IP within local
(non-public) networks.
Initial deployment of ATM provides a LAN segment replacement for
ethernet networks and as wire-replacement for dedicated public
telecommunication lines between IP routers. In the former model,
local IP routers with one or more ATM interfaces will connect islands
of local ATM networks. ATM-FORUM compliant addressing will be used
within these local ATM networks. In the latter model, public ATM
networks will be used to connect IP routers, which in turn may or may
not connect to local ATM networks. Public networks will use ITU-TSS
and ANSI standards for addressing in ATM. ATM-FORUM compliant
addressing cannot be guaranteed in public ATM networks.
The characteristics and features of ATM networks are different than
those found in LAN's:
o ATM provides a virtual circuit switched environment. VC setup may
be done on either a permanent (PVC) or dynamic (SVC) basis. SVC
call management signalling is performed via Q.93B implementations
[7].
o Data to be passed by a VC is segmented into 53 octet quantities
called cells (5 octets of ATM header and 48 octets of data). ATM
networks provide very low latency switching, high throughput, and
the ability to multiplex VCs of differing quality of service.
o Each VC carries a type which identifies a specific format for the
exchange of protocol data units (PDU's). These formats are called
ATM Adaptation Layers (AAL's) and are typed from 1 through 5.
AAL5 specifies a packet format with a maximum size of 65K user
data octets. Cells for an AAL5 PDU are transmitted first to last,
the last cell indicating end of PDU. ATM standards guarantee that
on a given VC AAL5 PDU's are not intermixed and that cell
ordering is preserved end-to-end.
o Multicast is not yet a conformance requirement of the ATM-FORUM.
Laubach [Page 4]
DRAFT Classical IP and ARP over ATM May 1993
o ATM hardware addresses are based on NSAP's.
This memo describes the initial deployment of ATM within "classical"
IP networks as a direct replacement for local area networks
(ethernets) and for IP links which interconnect routers, either
within or between administrative domains. "Classical" here refers to
the treatment of the ATM host adapter as a networking interface to
the IP protocol stack. This memo does not preclude the subsequent
evolution of ATM networks as they become more globally deployed and
interconnected and the evolution of TCP and IP to take advantage of
these changes - these will be the subject of future documents. This
memo does not address issues related to transparent data link layer
interoperability.
6. IP Subnetwork Configuration
This section describes the scenario for an ATM network that is
configured with one or more logical IP subnetworks, LIS's. The
scenario considers only directly connected IP hosts or routers.
In the LIS scenario, each separate administrative entity configures
its hosts and routers within a closed logical IP subnetwork. Each LIS
operates and communicates independently of other LIS's over the same
ATM network. Hosts connected to ATM communicate directly to other
hosts within the same LIS. Communication to hosts outside of the
local LIS is provided via an IP router. This router would be a
station attached to the ATM network that may have been configured as
a member of two or more LIS's. This configuration results in a number
of disjoint LIS's operating over the same ATM network. Hosts of
differing IP subnets would communicate via an intermediate router
even though a direct virtual circuit between the two hosts may be
available over the ATM network.
The requirements for IP member stations (hosts, routers) operating in
an ATM LIS configuration are:
o All members have the same IP network/subnet number.
o All stations within an LIS are accessed directly over the ATM
network.
o All stations outside of the LIS are accessed via a router.
o All members of an LIS must have a mechanism for resolving IP
addresses to ATM addresses via ARP [4].
o All members within a LIS MUST be able to communicate with all
Laubach [Page 5]
DRAFT Classical IP and ARP over ATM May 1993
other members in the same LIS; i.e., the topology is fully
meshed. There should be no administrative restrictions at the ATM
level that prevent VC's from operating between all pair of
stations.
o If the ATM switching fabric supports hardware multicast addressing,
then a group address MUST be configured whose membership is the
set of all IP stations within the LIS. Furthermore, one VC SHALL
be configured on each member station using this group address and
dedicated for ARP queries/replies, and one VC SHALL be configured
on each member station using this group address for encapsulated
IP traffic (see section under Packet Format).
The following list identifies a set of ATM specific parameters that
MUST be implemented in each IP station which would connect to the ATM
network. The parameter values MUST be user configurable:
o ATM Hardware Address (atm$ha). The ATM individual address of the
IP station. Each host must be configured to accept datagrams
destined for this address
o ATM ARP Request Address (atm$arp-req). The ATM hardware address
(unicast or multicast) to which ARP requests are to be sent.
Three cases are supported:
1. atm$arp-req is atm$ha, the local machine ATM hardware address.
The local host may either consult its static ARP translation
table directly, or support ARP queries by loopback internally
or exter- nally via the ATM network. In the case of an
external loopback, a VC is dedicated specifically for ARP
queries and replies.
2. atm$arp-req is the ATM hardware unicast address of an
individual ARP server located within the LIS. That server must
have authorita- tive responsibility for resolving ARP requests
all IP stations within the LIS. The VC's connecting IP
stations to this ARP server are dedicated specifically for ARP
queries and replies.
3. atm$arp-req is an ATM hardware group address. If the ATM
switching fabric supports ATM hardware multicast, then a well
known VC using the ATM group address local to the LIS is
dedicated specifically for broadcast ARP queries and replies.
The ARP query/reply service on all IP stations within the LIS
MUST be reachable via this address.
ATM hardware addresses are formatted as ATM-FORUM compliant NSAP's.
[ref?]
Laubach [Page 6]
DRAFT Classical IP and ARP over ATM May 1993
ARP request and reply formats are discussed in the section on Address
Resolution.
It is RECOMMENDED that routers providing LIS functionality over the
ATM network also support the ability to interconnect differing LIS's.
Routers that wish to provide interconnection of differing LIS's MUST
be able to support multiple sets of these parameters (one set for
each connected LIS) and be able to associate each set of parameters
with a specific IP network/ subnet number. In addition, it is
RECOMMENDED that a router be able to provide this multiple LIS
support with a single physical ATM interface that may have one or
more individual ATM addresses.
7. Packet Format
The default packet format for IP datagrams SHALL be the IEEE 802.2
LLC/SNAP format as described in [2].
This memo recognizes the future development of end-to-end signalling
within ATM that will allow negotiation of encapsulation method on a
per-VC basis. Signalling negotiations are beyond the scope of this
document.
8. MTU Size
The default MTU size for IP stations operating over the ATM network
SHALL be 9180 octets. The LLC/SNAP header is 8 octets, therefore the
maximum ATM AAL5 protocol service unit size will be 9188 octets.
The minimum IP MTU size is 576 octets [8]. The LLC/SNAP header is 8
octets, therefore the minimum ATM AAL5 protocol data unit size will
be 584 octets.
This memo recognizes the future development of end-to-end signalling
within ATM that will allow negotiation of MTU on a per-VC basis.
End-to-end negotiations are beyond the scope of this document.
9. Address Resolution
The dynamic mapping of 32-bit Internet addresses to ATM addresses
SHALL be done via the dynamic discovery procedure of the Address
Resolution Protocol (ARP) [3].
Internet addresses are assigned independent of ATM addresses. Each
host implementation MUST know its own internet address and ATM
address and respond to Address Resolution requests appropriately.
Hosts MUST also use ARP (either dynamically or via static table
lookup) to map Internet addresses to ATM addresses when needed.
Laubach [Page 7]
DRAFT Classical IP and ARP over ATM May 1993
The ARP protocol has several fields that have the following format
and values:
Data:
ar$hrd 16 bits Hardware type
ar$pro 16 bits Protocol type
ar$hln 8 bits Octet length of hardware address (n)
ar$pln 8 bits Octet length of protocol address (m)
ar$op 16 bits Operation code (request or reply)
ar$sha noctets source hardware address
ar$spa moctets source protocol address
ar$tha noctets target hardware address
ar$tpa moctets target protocol address
Where:
ar$hrd - assigned to NSAP address family and is nn decimal
(0x00nn) [4].
ar$pro - see Assigned Numbers for protocol type number for
the protocol using ARP. (IP is 0x0800).
ar$hln - length of the larger of the source or target
hardware NSAP address length.
ar$pln - length in bytes of the protocol address field. For
IP ar$pln is 4.
ar$op - 1 for request and 2 for reply
ar$sha - source NSAP address.
ar$tha - target NSAP address.
The ATM hardware addresses in ARP packets (ar$sha, ar$tha) SHALL be
ATM-FORUM specified NSAP addresses.[ref?]
The same NSAP encoding SHALL be used within an LIS and replies will
use the same encoding as queries. For example, NSAP's may encode IEEE
48-bit MAC addresses or may encode E.164 addresses. Within the LIS
either IEEE MAC or E.164 hardware addresses may be used but not both.
ARP packets are to be encoded in AAL5 PDU's using LLC/SNAP
encapsulation. The format of the AAL5 CPCS-SDU payload field for
routed non-ISO PDU's is:
Laubach [Page 8]
DRAFT Classical IP and ARP over ATM May 1993
Payload Format for Routed non-ISO PDU's
+------------------------------+
| LLC 0xAA-AA-03 |
+------------------------------+
| OUI 0x00-00-00 |
+------------------------------+
| Ethertype 0x08-06 |
+------------------------------+
| |
| ARP Packet |
| |
+------------------------------+
The LLC value of 0xAA-AA-03 (3 bytes) indicates the presence of a
SNAP header.
The OUI value of 0x00-00-00 (3 bytes) indicates that the following
two-bytes is an ethertype.
The Ethertype value of 0x08-06 (2 bytes) indicates ARP [4].
The total size of the LLC/SNAP header is 8-bytes fixed length. This
aligns the start of the ARP packet on a 64-bit boundary relative to
the start of the AAL5 SDU.
The LLC/SNAP encapsulation for ARP presented here is consistent with
the treatment of multiprotocol encapsulation of IP over ATM AAL5 as
specified in [2] and in the format of ARP over IEEE 802 networks as
specified in [5].
Traditionally, ARP requests are broadcast to all directly connected
IP stations within a LIS. It is conceivable in the future that larger
scaled ATM networks may "broadcast" ARP requests to destinations
outside the originating LIS, perhaps even globally; issues raised by
broadcasting outside the LIS or by a global ARP mechanism are beyond
the scope of this document.
10. IP Broadcast Address
ATM hardware multicast is not yet a conformance requirement of the
ATM-FORUM. As such, there is no consistent facility in ATM switches
for hardware multicast addressing. The following scenarios apply to
the multicast and non-multicast situations:
1. ATM multicast available: if the switch fabric connecting the host
ATM interface supports multicast, then the Internet broadcast
address (the address on that network with a host part of all
binary ones) MUST map to an ATM group address that includes all
Laubach [Page 9]
DRAFT Classical IP and ARP over ATM May 1993
IP stations within the LIS.
2. No ATM multicast support: the Internet broadcast address MUST map
to atm$arp-req, and atm$arp-req MUST either map to the local IP
host ATM hardware address or the ATM hardware address of an ARP
server located within the LIS.
In either case, encapsulated IP packets sent to the IP broadcast
address may be received on the ARP query VC. This requires that IP
packets sent to the IP broadcast address use LLC/SNAP encoding and
that all stations examine the value of ethertype in the LLC/SNAP
header and process IP versus ARP accordingly on all packets received
on this VC.
11. IP Multicast Address
IP multicast address mapping to ATM group addresses are not discussed
in this memo.
12. Security
Security issues are not discussed in this memo.
This memo recognizes the future development of ATM and IP facilities
for authenticated call setup, authenticated end-to-end application
knowledge, and data encryption as being required services for
globally connected ATM networks. These future security facilities and
their use by IP networks are beyond the scope of this document.
13. Open Issues
[This section to be removed after draft is reviewed a few times.]
There are some open issues:
o A proposal was put before the Internet Assigned Numbers Authority
to approve a request to create an ARP hardware type of "NSAP
family address". IANA has not responded as of this date. My
hopes are that we can get an ARP type created now that will cover
NSAPs for all time.
o Well known ATM hardware address(es) for ARP servers? It would be
very handy if we came up with a set of well known ATM addresses
for ARP services. We should probably have well-known PVC numbers
for a non-SVC environment also.
o Should this require that Interim Local Management Interface
(ILMI) be used to obtain the ATM address network prefix from the
Laubach [Page 10]
DRAFT Classical IP and ARP over ATM May 1993
network?
o We need to be able to reference ATM-FORUM documents within this
memo, are these publicly released? If yes, what are the
references?
REFERENCES
[1] Piscitello, D., and Lawrence, J., "IP and ARP over the SMDS
Service", RFC1209, USC/Information Sciences Institute, March
1991.
[2] Heinanen, Juha, "Multiprotocol Encapsulation over ATM Adaptation
Layer 5", work in progress, IETF IP over ATM Working Group,
February 1993.
[3] Plummer, D., "An Ethernet Address Resolution Protocol - or -
Converting Network Addresses to 48.bit Ethernet Address for
Transmission on Ethernet Hardware", RFC 826, MIT, November 1982.
[4] Reynolds, J., and Postel, J., "Assigned Numbers", RFC1340, USC/
Information Sciences Institute, July 1992.
[5] Postel, J., and Reynolds, J., "A Standard for the Transmission of
IP Datagrams over IEEE 802 Networks", RFC1042, USC/Information
Sciences Institute, February 1988.
[6] CCITT, "Draft Recommendation I.363", CCITT Study Group XVIII,
Geneva, 19-29 January 1993.
[7] CCITT, "Draft text for Q.93B", CCITT Study Group XI, 23 September
- 2 October 1992.
[8] Braden, R., "Requirements for Internet Hosts -- Communication
Layers", RFC1122, USC/Information Sciences Institute, October
1989.
[Need ATM-FORUM references.]
Authors' Addresses
Mark Laubach
Hewlett-Packard Laboratories
1501 Page Mill Road
Palo Alto, CA 94304
Phone: 415.857.3513 FAX: 415.857.8526
EMail: laubach@hpl.hp.com
Laubach [Page 11]
