rfc1577.txt

<VC++网络游戏建摸与实现>源代码

                InARP_REQUEST = 8
                InARP_REPLY   = 9
                ARP_NAK       = 10

     ar$spln -  length in octets of the source protocol address. For
                IP ar$spln is 4.

     ar$tpln -  length in octets of the target protocol address. For
                IP ar$tpln is 4.

     ar$sha  -  source ATM number (E.164 or ATM Forum NSAPA)

     ar$ssa  -  source ATM subaddress (ATM Forum NSAPA)

     ar$spa  -  source protocol address

     ar$tha  -  target ATM number (E.164 or ATM Forum NSAPA)

     ar$tsa  -  target ATM subaddress (ATM Forum NSAPA)

     ar$tpa  -  target protocol address














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


   The encoding of the 8-bit type and length value for ar$shtl,
   ar$sstl, ar$thtl, and ar$tstl is as follows:

     MSB   8     7     6     5     4     3     2     1   LSB
        +-----+-----+-----+-----+-----+-----+-----+-----+
        |  0  | 1/0 |   Octet length of address         |
        +-----+-----+-----+-----+-----+-----+-----+-----+

   Where:

     bit.8   (reserved) = 0  (for future use)

     bit.7   (type)     = 0  ATM Forum NSAPA format
                        = 1  E.164 format

     bit.6-1 (length)   = 6 bit unsigned octet length of address
                          (MSB = bit.6, LSB = bit.1)

   ATM addresses in Q.93B (as defined by the ATM Forum UNI 3.0
   signalling specification [9]) include a "Calling Party Number
   Information Element" and a "Calling Party Subaddress Information
   Element".  These Information Elements (IEs) SHOULD map to
   ATMARP/InATMARP source ATM number and source ATM subaddress
   respectively.  Furthermore, ATM Forum defines a "Called Party Number
   Information Element" and a "Called Party Subaddress Information
   Element". These IEs map to ATMARP/InATMARP target ATM number and
   target ATM subaddress respectively.

   The ATM Forum defines three structures for the combined use of number
   and subaddress [9]:

                        ATM Number      ATM Subaddress
                      --------------    --------------
        Structure 1   ATM Forum NSAPA        null
        Structure 2       E.164              null
        Structure 3       E.164         ATM Forum NSAPA

   IP members MUST register their ATM endpoint address with their ATMARP
   server using the ATM address structure appropriate for their ATM
   network connection: i.e., LISs implemented over ATM LANs following
   ATM Forum UNI 3.0 should register using Structure 1; LISs implemented
   over an E.164 "public" ATM network should register using Structure 2.
   A LIS implemented over a combination of ATM LANs and public ATM
   networks may need to register using Structure 3.  Implementations
   based on this memo MUST support all three ATM address structures.

   ATMARP and InATMARP requests and replies for ATM address structures 1
   and 2 MUST indicate a null ATM subaddress; i.e., ar$sstl.type = 1 and



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


   ar$sstl.length = 0 and ar$tstl.type = 1 and ar$tstl.length = 0.  When
   ar$sstl.length and ar$tstl.length =0, the ar$tsa and ar$ssa fields
   are not present.

   Note: the ATMARP packet format presented in this memo is general in
   nature in that the ATM number and ATM subaddress fields SHOULD map
   directly to the corresponding Q.93B fields used for ATM
   call/connection setup signalling messages.  The IP over ATM Working
   Group expects ATM Forum NSAPA numbers (Structure 1) to predominate
   over E.164 numbers (Structure 2) as ATM endpoint identifiers within
   ATM LANs.  The ATM Forum's VC Routing specification is not complete
   at this time and therefore its impact on the operational use of ATM
   Address Structure 3 is undefined. The ATM Forum will be defining this
   relationship in the future.  It is for this reason that IP members
   need to support all three ATM address structures.

6.7 ATMARP/InATMARP Packet Encapsulation

   ATMARP and InATMARP packets are to be encoded in AAL5 PDUs using
   LLC/SNAP encapsulation. The format of the AAL5 CPCS-SDU payload field
   for ATMARP/InATMARP PDUs is:

               Payload Format for ATMARP/InATMARP PDUs:
               +------------------------------+
               |        LLC 0xAA-AA-03        |
               +------------------------------+
               |        OUI 0x00-00-00        |
               +------------------------------+
               |     Ethertype 0x08-06        |
               +------------------------------+
               |                              |
               |   ATMARP/InATMARP Packet     |
               |                              |
               +------------------------------+

   The LLC value of 0xAA-AA-03 (3 octets) indicates the presence of a
   SNAP header.

   The OUI value of 0x00-00-00 (3 octets) indicates that the following
   two-bytes is an ethertype.

   The Ethertype value of 0x08-06 (2 octets) indicates ARP [4].

   The total size of the LLC/SNAP header is fixed at 8-octets. This
   aligns the start of the ATMARP packet on a 64-bit boundary relative
   to the start of the AAL5 CPCS-SDU.





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


   The LLC/SNAP encapsulation for ATMARP/InATMARP presented here is
   consistent with the treatment of multiprotocol encapsulation of IP
   over ATM AAL5 as specified in [2] and in the format of ATMARP over
   IEEE 802 networks as specified in [5].

   Traditionally, address resolution requests are broadcast to all
   directly connected IP members within a LIS. It is conceivable in the
   future that larger scaled ATM networks may handle ATMARP requests to
   destinations outside the originating LIS, perhaps even globally;
   issues raised by ATMARP'ing outside the LIS or by a global ATMARP
   mechanism are beyond the scope of this memo.

7.  IP Broadcast Address

   ATM does not support broadcast addressing, therefore there are no
   mappings available from IP broadcast addresses to ATM broadcast
   services. Note: this lack of mapping does not restrict members from
   transmitting or receiving IP datagrams specifying any of the four
   standard IP broadcast address forms as described in [8].  Members,
   upon receiving an IP broadcast or IP subnet broadcast for their LIS,
   MUST process the packet as if addressed to that station.

8.  IP Multicast Address

   ATM does not support multicast address services, therefore there are
   no mappings available from IP multicast addresses to ATM multicast
   services.  Current IP multicast implementations (i.e., MBONE and IP
   tunneling, see [10]) will continue to operate over ATM based logical
   IP subnets if operated in the WAN configuration.

   This memo recognizes the future development of ATM multicast service
   addressing by the ATM Forum. When available and widely implemented,
   the roll-over from the current IP multicast architecture to this new
   ATM architecture will be straightforward.

9.  Security

   Not all of the security issues relating to IP over ATM are clearly
   understood at this time, due to the fluid state of ATM
   specifications, newness of the technology, and other factors.

   It is believed that ATM and IP facilities for authenticated call
   management, authenticated end-to-end communications, and data
   encryption will be needed in globally connected ATM networks.  Such
   future security facilities and their use by IP networks are beyond
   the scope of this memo.





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


   There are known security issues relating to host impersonation via
   the address resolution protocols used in the Internet [13].  No
   special security mechanisms have been added to the address resolution
   mechanism defined here for use with networks using IP over ATM.

10.  Open Issues

   o   Interim Local Management Interface (ILMI) services will not be
       generally implemented initially by some providers and vendors and
       will not be used to obtain the ATM address network prefix from
       the network [9].  Meta-signalling does provide some of this
       functionality and in the future we need to document the options.

   o   Well known ATM address(es) for ATMARP servers?  It would be very
       handy if a mechanism were available for determining the "well
       known" ATM address(es) for the client's ATMARP server in the LIS.

   o   There are many VC management issues which have not yet been
       addressed by this specification and which await the unwary
       implementor.  For example, one problem that has not yet been
       resolved is how two IP members decide which of duplicate VCs can
       be released without causing VC thrashing.  If two IP stations
       simultaneously established VCs to each other, it is tempting to
       allow only one of these VCs to be established, or to release one
       of these VCs immediately after it is established.  If both IP
       stations simultaneously decide to release opposite VCs, a
       thrashing effect can be created where VCs are repeatedly
       established and immediately released.  For the time being, the
       safest strategy is to allow duplicate VCs to be established and
       simply age them like any other VCs.

References

   [1] Piscitello, D., and J. Lawrence, "IP and ARP over the SMDS
       Service", RFC 1209, Bell Communications Research, March 1991.

   [2] Heinanen, J., "Multiprotocol Encapsulation over ATM Adaptation
       Layer 5", RFC 1483, Telecom Finland, July 1993.

   [3] Plummer, D., "An Ethernet Address Resolution Protocol - or -
       Converting Network Addresses to 48.bit Ethernet Address for
       Transmission on Ethernet Hardware", STD 37, RFC 826, MIT,
       November 1982.

   [4] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1340,
       USC/Information Sciences Institute, July 1992.





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


   [5] Postel, J., and J. Reynolds, "A Standard for the Transmission of
       IP Datagrams over IEEE 802 Networks", STD 43, RFC 1042,
       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", STD 3, RFC 1122, USC/Information Sciences Institute,
       October 1989.

   [9] ATM Forum, "ATM User-Network Interface Specification Version
       3.0.", ATM Forum, 480 San Antonio Road, Suite 100, Mountain View,
       CA 94040, June 1993.

  [10] Deering, S., "Host Extensions for IP Multicasting", STD 5, RFC
       1112, Stanford University, August 1989.

  [11] Colella, R., and Gardner, E., and R. Callon, "Guidelines for OSI
       NSAP Allocation in the Internet", RFC 1237, NIST, Mitre, DEC,
       July 1991.

  [12] Bradely, T., and C. Brown, "Inverse Address Resolution Protocol",
       RFC 1293, Wellfleet Communications, Inc., January 1992.

  [13] Bellovin, S., "Security Problems in the TCP/IP Protocol Suite",
       ACM Computer Communications Review, Vol. 19, Issue 2, pp. 32-48,
       1989.

Security Considerations

   Security issues are discussed in Section 9.

Author's Address

   Mark Laubach
   Hewlett-Packard Laboratories
   1501 Page Mill Road
   Palo Alto, CA 94304

   Phone: [phone]
   Fax:   [phone]
   EMail: [e-mail]





Laubach                                                        [Page 17]