rfc2225.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 1,499 行 · 第 1/5 页

Network Working Group                                        M. Laubach
Request for Comments: 2225                                  Com21, Inc.
Category: Standards Track                                    J. Halpern
Obsoletes: 1626, 1577                          Newbridge Networks, Inc.
                                                             April 1998


                     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.

Copyright Notice

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

Table of Contents

   1. ABSTRACT  . . . . . . . . . . . . . . . . . . . . . . . . . .  2
   2. ACKNOWLEDGMENT  . . . . . . . . . . . . . . . . . . . . . . .  2
   3. CONVENTIONS . . . . . . . . . . . . . . . . . . . . . . . . .  3
   4. INTRODUCTION  . . . . . . . . . . . . . . . . . . . . . . . .  3
   5. IP SUBNETWORK CONFIGURATION . . . . . . . . . . . . . . . . .  6
   5.1  Background  . . . . . . . . . . . . . . . . . . . . . . . .  6
   5.2  LIS Configuration Requirements  . . . . . . . . . . . . . .  7
   5.3  LIS Router Additional Configuration . . . . . . . . . . . .  8
   6. IP PACKET FORMAT  . . . . . . . . . . . . . . . . . . . . . .  8
   7. DEFAULT VALUE FOR IP MTU OVER ATM AAL5  . . . . . . . . . . .  9
   7.1  Permanent Virtual Circuits  . . . . . . . . . . . . . . . .  9
   7.2  Switched Virtual Circuits . . . . . . . . . . . . . . . . .  9
   7.3  Path MTU Discovery Required . . . . . . . . . . . . . . . . 11
   8. LIS ADDRESS RESOLUTION SERVICES . . . . . . . . . . . . . . . 11
   8.1  ATM-based ARP and InARP Equivalent Services . . . . . . . . 11
   8.2  Permanent Virtual Connections . . . . . . . . . . . . . . . 12
   8.3  Switched Virtual Connections  . . . . . . . . . . . . . . . 12
   8.4  ATMARP Single Server Operational Requirements . . . . . . . 13
   8.5  ATMARP Client Operational Requirements  . . . . . . . . . . 14
   8.5.1  Client ATMARP Table Aging . . . . . . . . . . . . . . . . 16
   8.5.2  Non-Normal VC Operations  . . . . . . . . . . . . . . . . 17
   8.5.3  Use of ATM ARP in Mobile-IP Scenarios . . . . . . . . . . 17
   8.6  Address Resolution Server Selection . . . . . . . . . . . . 17
   8.6.1  PVCs to ATMARP Servers  . . . . . . . . . . . . . . . . . 18
   8.7  ATMARP Packet Formats . . . . . . . . . . . . . . . . . . . 18



Laubach & Halpern           Standards Track                     [Page 1]

RFC 2225                  IP and ARP over ATM                 April 1998


   8.7.1  ATMARP/InATMARP Request and Reply Packet Formats  . . . . 18
   8.7.2  Receiving Unknown ATMARP packets  . . . . . . . . . . . . 20
   8.7.3  TL, ATM Number, and ATM Subaddress Encoding . . . . . . . 20
   8.7.4  ATMARP_NAK Packet Format  . . . . . . . . . . . . . . . . 21
   8.7.5  Variable Length Requirements for ATMARP Packets . . . . . 21
   8.8  ATMARP/InATMARP Packet Encapsulation  . . . . . . . . . . . 22
   9. IP BROADCAST ADDRESS  . . . . . . . . . . . . . . . . . . . . 23
   10. IP MULTICAST ADDRESS . . . . . . . . . . . . . . . . . . . . 23
   11. SECURITY CONSIDERATIONS  . . . . . . . . . . . . . . . . . . 23
   12. MIB SPECIFICATION  . . . . . . . . . . . . . . . . . . . . . 24
   13. OPEN ISSUES  . . . . . . . . . . . . . . . . . . . . . . . . 24
   14. REFERENCES . . . . . . . . . . . . . . . . . . . . . . . . . 24
   15. AUTHORS' ADDRESSES . . . . . . . . . . . . . . . . . . . . . 26
   APPENDIX A - Update Information  . . . . . . . . . . . . . . . . 27
   FULL COPYRIGHT STATEMENT . . . . . . . . . . . . . . . . . . . . 28

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

2.  ACKNOWLEDGMENT

   The authors would like to thank the efforts of the IP over ATM
   Working Group of the IETF.  Without their substantial, and sometimes
   contentious support, of the Classical IP over ATM model, this updated
   memo would not have been possible.  Section 7, on Default MTU, has
   been incorporated directly from Ran Atkinson's RFC 1626, with his
   permission.  Thanks to Andy Malis for an early review and comments
   for rolc and ion related issues.






Laubach & Halpern           Standards Track                     [Page 2]

RFC 2225                  IP and ARP over ATM                 April 1998


3.  CONVENTIONS

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [20].

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

   This memo specifies the stable foundation baseline operational model
   which will always be available in IP and ARP over ATM
   implementations.  Subsequent memos will build upon and refine this
   model.  However, in the absence or failure of those extensions,
   operations will default to the specifications contained in this memo.
   Consequently, this memo will not reference these other extensions.

   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 3.1 specification
   [9] or as in the ATM Forum UNI 4.0 specification [19].  This
   structure is modeled after the format of an OSI Network Service
   Access Point Address (NSAPA).  A private ATM address uniquely
   identifies an ATM endpoint.



Laubach & Halpern           Standards Track                     [Page 3]

RFC 2225                  IP and ARP over ATM                 April 1998


   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 UNI
       3.1 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 UNI 3.1 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 signaling defines point-to-point and point-to-
       point Connection setup [9, 19.]  Multipoint-to-multipoint not yet
       specified by ITU-TS or ATM Forum.

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



Laubach & Halpern           Standards Track                     [Page 4]

RFC 2225                  IP and ARP over ATM                 April 1998


       Since the use of AESAs 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 NSAP format addresses (AESA)
       use the same basic format as U.S. GOSIP OSI 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.  However, in this
       document, these will be referred to as NSAPAs.

   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 the default for
       all VCs in a LIS.  However, on a VC-by-VC point-to-point basis,
       the MTU size may be negotiated during connection setup using Path
       MTU Discovery to better suit the needs of the cooperating pair of
       IP members or the attributes of the communications path.  (Refer
       to Section 7.3)

   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:





Laubach & Halpern           Standards Track                     [Page 5]

RFC 2225                  IP and ARP over ATM                 April 1998


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