rfc1577.txt

RFC 的详细文档！

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]

RFC 1577             Classical IP and ARP over ATM          January 1993


   ATM endpoint.  Public networks will use either the address structure
   specified in ITU-TS recommendation E.164 or the private network ATM
   address structure.  An E.164 address uniquely identifies an interface
   to a public network.

   The characteristics and features of ATM networks are different than
   those found in LANs:

   o   ATM provides a Virtual Connection (VC) switched environment. VC
       setup may be done on either a Permanent Virtual Connection (PVC)
       or dynamic Switched Virtual Connection (SVC) basis. SVC call
       management signalling is performed via implementations of the
       Q.93B protocol [7,9].

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

   o   The function of mapping user Protocol Data Units (PDUs) into the
       information field of the ATM cell and vice versa is performed in
       the ATM Adaptation Layer (AAL).  When a VC is created a specific
       AAL type is associated with the VC.  There are four different AAL
       types, which are referred to individually as "AAL1", "AAL2",
       "AAL3/4", and "AAL5".  (Note: this memo concerns itself with the
       mapping of IP and ATMARP over AAL5 only.  The other AAL types are
       mentioned for introductory purposes only.)  The AAL type is known
       by the VC end points via the call setup mechanism and is not
       carried in the ATM cell header.  For PVCs the AAL type is
       administratively configured at the end points when the Connection
       (circuit) is set up.  For SVCs, the AAL type is communicated
       along the VC path via Q.93B as part of call setup establishment
       and the end points use the signaled information for
       configuration.  ATM switches generally do not care about the AAL
       type of VCs.  The AAL5 format specifies a packet format with a
       maximum size of (64K - 1) octets of user data. Cells for an AAL5
       PDU are transmitted first to last, the last cell indicating the
       end of the PDU.  ATM standards guarantee that on a given VC, cell
       ordering is preserved end-to-end.  NOTE: AAL5 provides a non-
       assured data transfer service - it is up to higher-level
       protocols to provide retransmission.

   o   ATM Forum signalling defines point-to-point and point-to-
       multipoint Connection setup [9].  Multipoint-to-multipoint VCs
       are not yet specified by ITU-TS or ATM Forum.

   o   An ATM Forum ATM endpoint address is either encoded as an NSAP
       Address (NSAPA) or is an E.164 Public-UNI address [9].  In some
       cases, both an ATM endpoint address and an E.164 Public UNI
       address are needed by an ATMARP client to reach another host or



Laubach                                                         [Page 3]

RFC 1577             Classical IP and ARP over ATM          January 1993


       router.  Since the use of ATM endpoint addresses and E.164 public
       UNI addresses by ATMARP are analogous to the use of Ethernet
       addresses, the notion of "hardware address" is extended to
       encompass ATM addresses in the context of ATMARP, even though ATM
       addresses need not have hardware significance.  ATM Forum NSAPAs
       use the same basic format as U.S. GOSIP NSAPAs [11].  Note: ATM
       Forum addresses should not be construed as being U.S. GOSIP
       NSAPAs.  They are not, the administration is different, which
       fields get filled out are different, etc.

   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. The "classical" model here
   refers to the treatment of the ATM host adapter as a networking
   interface to the IP protocol stack operating in a LAN-based paradigm.

   Characteristics of the classical model are:

    o  The same maximum transmission unit (MTU) size is used for all VCs
       in a LIS [2].  (Refer to Section 5.)

    o  Default LLC/SNAP encapsulation of IP packets.

    o  End-to-end IP routing architecture stays the same.

    o  IP addresses are resolved to ATM addresses by use of an ATMARP
       service within the LIS - ATMARPs stay within the LIS.  From a
       client's perspective, the ATMARP architecture stays faithful to
       the basic ARP model presented in [3].

    o  One IP subnet is used for many hosts and routers. Each VC
       directly connects two IP members within the same LIS.

   Future memos will describe the operation of IP over ATM when ATM
   networks become globally deployed and interconnected.

   The deployment of ATM into the Internet community is just beginning
   and will take many years to complete. During the early part of this
   period, we expect deployment to follow traditional 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.





Laubach                                                         [Page 4]

RFC 1577             Classical IP and ARP over ATM          January 1993


    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" around these
       mechanisms until ATM provides better management capability than
       the existing services and practices.

    o  Standards for global IP over ATM will take some time to complete
       and deploy.

   This memo details the treatment of the classical model of IP and
   ATMARP over ATM. This memo does not preclude the subsequent treatment
   of ATM networks within the IP framework as ATM becomes globally
   deployed and interconnected; this will be the subject of future
   documents. This memo does not address issues related to transparent
   data link layer interoperability.

3.  IP Subnetwork Configuration

   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 LISs on 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 is an ATM
   Endpoint attached to the ATM network that is configured as a member
   of one or more LISs.  This configuration may result in a number of
   disjoint LISs operating over the same ATM network. Hosts of differing
   IP subnets MUST communicate via an intermediate IP router even though
   it may be possible to open a direct VC between the two IP members
   over the ATM network.

   The requirements for IP members  (hosts, routers) operating in an ATM
   LIS configuration are:

   o   All members have the same IP network/subnet number and address
       mask [8].

   o   All members within a LIS are directly connected to the ATM
       network.

   o   All members outside of the LIS are accessed via a router.

   o   All members of a LIS MUST have a mechanism for resolving IP
       addresses to ATM addresses via ATMARP (based on [3]) and vice
       versa via InATMARP (based on [12]) when using SVCs.  Refer to
       Section 6 "Address Resolution" in this memo.





Laubach                                                         [Page 5]

RFC 1577             Classical IP and ARP over ATM          January 1993


   o   All members of a LIS MUST have a mechanism for resolving VCs to
       IP addresses via InATMARP (based on [12]) when using PVCs.  Refer
       to Section 6 "Address Resolution" in this memo.

   o   All members within a LIS MUST be able to communicate via ATM with
       all other members in the same LIS; i.e., the virtual Connection
       topology underlying the intercommunication among the members is
       fully meshed.

   The following list identifies a set of ATM specific parameters that
   MUST be implemented in each IP station connected to the ATM network:

   o   ATM Hardware Address (atm$ha). The ATM address of the individual
       IP station.

   o   ATMARP Request Address (atm$arp-req). atm$arp-req is the ATM
       address of an individual ATMARP server located within the LIS.
       In an SVC environment, ATMARP requests are sent to this address
       for the resolution of target protocol addresses to target ATM
       addresses.  That server MUST have authoritative responsibility
       for resolving ATMARP requests of all IP members within the LIS.
       Note: if the LIS is operating with PVCs only, then this parameter
       may be set to null and the IP station is not required to send
       ATMARP requests to the ATMARP server.

   It is RECOMMENDED that routers providing LIS functionality over the
   ATM network also support the ability to interconnect multiple LISs.
   Routers that wish to provide interconnection of differing LISs 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
   to 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