rfc2225.txt

来自「著名的RFC文档,其中有一些文档是已经翻译成中文的的.」· 文本 代码 · 共 1,543 行 · 第 1/5 页

   information prior to any attempt to re-establish communication to an
   IP member after a non-normal communications problem has previously
   occurred on a VC to that IP member.

8.5.3 Use of ATMARP In Mobile-IP Scenarios

   When an ATM LIS is used as the home network in a mobile-IP scenario,
   it is RECOMMENDED that the home agent NOT maintain long term
   connections with the ATMARP service.  The absence of this VC will
   permit a mobile node's registration, upon its return to the home
   network, to immediately preempt the home agent's previous gratuitous
   registration.

8.6 Address Resolution Server Selection

   If the client supports PVCs only, the ATMARP server list is empty and
   the client MUST not generate any address resolution requests other
   than the InATMARP requests on a PVC needed to validate that PVC.

   If the client supports SVCs, then the client MUST have a non-NULL
   atm$arp-req-list pointing to the ATMARP server(s) which provides
   ATMARP service for the LIS.




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


   The client MUST register with a server from atm$arp-req-list.

   The client SHALL attempt to communicate with any of the servers until
   a successful registration is accomplished.  The order in which client
   selects servers to attempt registration, is a local matter, as are
   the number of retries and timeouts for such attempts.

8.6.1 PVCs to ATMARP Servers

   In a mixed PVC and SVC LIS environment, an ATMARP client MAY have a
   PVC to an ATMARP server.  In this case, this PVC is used for ATMARP
   requests and responses as if it were an established SVC.  NOTE: if
   this PVC is to be used for IP traffic, then the ATMARP server MUST be
   prepared to accept and respond appropriately to InATMARP traffic.

8.7 ATMARP Packet Formats

   Internet addresses are assigned independently of ATM addresses.  Each
   host implementation MUST know its own IP and ATM address(es) and MUST
   respond to address resolution requests appropriately.  IP members
   MUST also use ATMARP and InATMARP to resolve IP addresses to ATM
   addresses when needed.

   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 UNI 3.1 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.

8.7.1 ATMARP/InATMARP Request and Reply Packet Formats

   The ATMARP and InATMARP request and reply protocols use the same
   hardware type (ar$hrd), protocol type (ar$pro), and operation code
   (ar$op) data formats as the ARP and InARP protocols [3,12].  The
   location of these three fields within the ATMARP packet are in the
   same byte position as those in ARP and InARP packets.  A unique
   hardware type value has been assigned for ATMARP.  In addition,
   ATMARP makes use of an additional operation code for ARP_NAK.  The
   remainder of the ATMARP/InATMARP packet format is different than the
   ARP/InARP packet format.





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


   The ATMARP and InATMARP protocols have several fields that have the
   following format and values:

   Data:
     ar$hrd   16 bits  Hardware type
     ar$pro   16 bits  Protocol type
     ar$shtl   8 bits  Type & length (TL) of source ATM number (q)
     ar$sstl   8 bits  Type & length (TL) of source ATM subaddress (r)
     ar$op    16 bits  Operation code (request, reply, or NAK)
     ar$spln   8 bits  Length of source protocol address (s)
     ar$thtl   8 bits  Type & length (TL) of target ATM number (x)
     ar$tstl   8 bits  Type & length (TL) of target ATM subaddress (y)
     ar$tpln   8 bits  Length of target protocol address (z)
     ar$sha   qoctets of source ATM number
     ar$ssa   roctets of source ATM subaddress
     ar$spa   soctets of source protocol address
     ar$tha   xoctets of target ATM number
     ar$tsa   yoctets of target ATM subaddress
     ar$tpa   zoctets of target protocol address

   Where:
     ar$hrd  -  assigned to ATM Forum address family and is
                19 decimal (0x0013) [4].

     ar$pro  -  see Assigned Numbers for protocol type number for
                the protocol using ATMARP. (IP is 0x0800).

     ar$shtl -  Type and length of source ATM number.  See
                Section 8.7.4 for TL encoding details.

     ar$sstl -  Type and length of source ATM subaddress.  See
                Section 8.7.4 for TL encoding details.

     ar$op   -  The operation type value (decimal):

                ATMARP_Request   = ARP_REQUEST   = 1
                ATMARP_Reply     = ARP_REPLY     = 2
                InATMARP_Request = InARP_REQUEST = 8
                InATMARP_Reply   = InARP_REPLY   = 9
                ATMARP_NAK       = ARP_NAK       = 10

     ar$spln -  length in octets of the source protocol address. Value
                range is 0 or 4 (decimal).  For IPv4 ar$spln is 4.

     ar$thtl -  Type and length of target ATM number.  See
                Section 8.7.4 for TL encoding details.





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


     ar$tstl -  Type and length of target ATM subaddress.  See
                Section 8.7.4 for TL encoding details.

     ar$tpln -  length in octets of the target protocol address. Value
                range is 0 or 4 (decimal).  For IPv4 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

8.7.2 Receiving Unknown ATMARP packets

   If an ATMARP client receives an ATMARP message with an operation code
   (ar$op) for which it is not coded to support, it MUST gracefully
   discard the message and continue normal operation.  An ATMARP client
   is NOT REQUIRED to return any message to the sender of the
   unsupported message.

8.7.3 TL, ATM Number, and ATM Subaddress Encoding

   The encoding of the 8-bit TL (type and length) fields in ATMARP and
   In_ATMARP packets 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)  Value
                          range is from 0 to 20 (decimal).






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


   ATM addresses, as defined by the ATM Forum UNI 3.1 signaling
   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

   ATMARP and InATMARP requests and replies for ATM address structures 1
   and 2 MUST indicate a null or unknown ATM subaddress by setting the
   appropriate subaddress length to zero; i.e., ar$sstl.length = 0 or
   ar$tstl.length = 0, the corresponding type field (ar$sstl.type or
   ar$tstl.type) MUST be ignored and the physical space for the ATM
   subaddress buffer MUST not be allocated in the ATMARP packet.  For
   example, if ar$sstl.length=0, the storage for the source ATM
   subaddress is not allocated and the first byte of the source protocol
   address ar$spa follows immediately after the last byte of the source
   hardware address ar$sha in the packet.

   Null or unknown ATM addresses MUST be indicated by setting the
   appropriate address length to zero; i.e., ar$shtl.length and
   ar$thtl.length is zero and the corresponding type field (ar$sstl.type
   or ar$tstl.type) MUST be ignored and the physical space for the ATM
   address or ATM subaddress buffer MUST not be allocated in the ATMARP
   packet.

8.7.4 ATMARP_NAK Packet Format

   The ATMARP_NAK packet format is the same as the received
   ATMARP_Request packet format with the operation code set to ARP_NAK,
   i.e., the ATMARP_Request packet data is exactly copied (e.g., using
   bcopy) for transmission with the ATMARP_Request operation code
   changed to ARP_NAK value.

8.7.5 Variable Length Requirements for ATMARP Packets

   ATMARP and InATMARP packets are variable in length.



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


   A null or unknown source or target protocol address is indicated by
   the corresponding length set to zero: e.g., when ar$spln or ar$tpln
   is zero the physical space for the corresponding address structure
   MUST not be allocated in the packet.

   For backward compatibility with previous implementations, a null IPv4
   protocol address may be received with length = 4 and an allocated
   address in storage set to the value 0.0.0.0.  Receiving stations MUST
   be liberal in accepting this format of a null IPv4 address.  However,
   on transmitting an ATMARP or InATMARP packet, a null IPv4 address
   MUST only be indicated by the length set to zero and MUST have no
   storage allocated.

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

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



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