rfc2225.txt
来自「<VC++网络游戏建摸与实现>源代码」· 文本 代码 · 共 1,543 行 · 第 1/5 页
TXT
1,543 行
Network Working Group M. LaubachRequest for Comments: 2225 Com21, Inc.Category: Standards Track J. HalpernObsoletes: 1626, 1577 Newbridge Networks, Inc. April 1998 Classical IP and ARP over ATMStatus 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 . . . . . . . . . . . . . . . . . . . 18Laubach & 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 . . . . . . . . . . . . . . . . . . . . 281. 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 19983. 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. 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.5. IP SUBNETWORK CONFIGURATION⌨️ 快捷键说明
复制代码Ctrl + C
搜索代码Ctrl + F
全屏模式F11
增大字号Ctrl + =
减小字号Ctrl + -
显示快捷键?