rfc2225.txt

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


RFC 2225                  IP and ARP over ATM                 April 1998


8.2 Permanent Virtual Connections

   An IP station MUST have a mechanism (e.g., manual configuration) for
   determining what PVCs it has, and in particular which PVCs are being
   used with LLC/SNAP encapsulation.  The details of the mechanism are
   beyond the scope of this memo.

   All IP members supporting PVCs are required to use the Inverse ATM
   Address Resolution Protocol (InATMARP) (refer to [12]) on those VCs
   using LLC/SNAP encapsulation.  In a strict PVC environment, the
   receiver SHALL infer the relevant VC from the VC on which the
   InATMARP_Request or response InATMARP_Reply was received.  When the
   ATM source and/or target address is unknown, the corresponding ATM
   address length in the InATMARP packet MUST be set to zero (0)
   indicating a null length, and no storage be allocated in the InATMARP
   packet, otherwise the appropriate address field should be filled in
   and the corresponding length set appropriately.  InATMARP packet
   format details are presented later in this memo.

   Directly from [12]: "When the requesting station receives the
   In[ATM]ARP_Reply, it may complete the [ATM]ARP table entry and use
   the provided address information.  NOTE: as with [ATM]ARP,
   information learned via In[ATM]ARP may be aged or invalidated under
   certain circumstances." IP stations supporting PVCs MUST re-validate
   ATMARP table entries as part of the table aging process.  See the
   Section 8.5.1 "Client ATMARP Table Aging".

   If a client has more than one IP address within the LIS and if using
   PVCs, when an InATMARP_Request is received an InATMARP_Reply MUST be
   generated for each such address.

8.3 Switched Virtual Connections

   SVCs require support from address resolution services for resolving
   target IP addresses to target ATM endpoint addresses.  All members in
   the LIS MUST use the same service.  This service MUST have
   authoritative responsibility for resolving the ATMARP requests of all
   IP members within the LIS.

   ATMARP servers do not actively establish connections.  They depend on
   the clients in the LIS to initiate connections for the ATMARP
   registration procedure and for transmitting ATMARP requests.  An
   individual client connects to the ATMARP server using a point-to-
   point LLC/SNAP VC.  The client sends normal ATMARP request packets to
   the server.  The ATMARP server examines each ATMARP_Request packet
   for





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


   the source protocol and source hardware address information of the
   sending client and uses this information to build its ATMARP table
   cache.  This information is used to generate replies to any ATMARP
   requests it receives.

   InATMARP_Request packets MUST specify valid address information for
   ATM source number, ATM target number, and source protocol address;
   i.e., these fields MUST be non-null in InATMARP_Request packets.

   This memo defines the address resolution service in the LIS and
   constrains it to consist of a single ATMARP server.  Client-server
   interaction is defined by using a single server approach as a
   reference model.

   This memo recognizes the future development of standards and
   implementations of multiple-ATMARP-server models that will extend the
   operations as defined in this memo to provide a highly reliable
   address resolution service.

8.4 ATMARP Single Server Operational Requirements

   A single ATMARP server accepts ATM calls/connections from other ATM
   end points.  After receiving any ATMARP_Request, the server will
   examine the source and target address information in the packet and
   make note of the VC on which the ATMARP_Request arrived.  It will use
   this information as necessary to build and update its ATMARP table
   entries.

   For each ATMARP_Request, then:

   1.  If the source IP protocol address is the same as the target IP
       protocol address and a table entry exists for that IP address and
       if the source ATM hardware address does not match the table entry
       ATM address and there is an open VC associated with that table
       entry that is not the same as the VC associated with the
       ATMARP_Request, the server MUST return the table entry
       information in the ATMARP_Reply, and MUST raise a "duplicate IP
       address detected" condition to the server's management.  The
       table entry is not updated.

   2.  Otherwise, if the source IP protocol address is the same as the
       target IP protocol address, and either there is no table entry
       for that IP address, or a table entry exists for that IP address
       and there is no open VC associated with that table entry, or if
       the VC associated with that entry is the same as the VC for the
       ATMARP_Request, the server MUST either create a new entry or
       update the old entry as appropriate and return that table entry
       information in the ATMARP Reply.



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


   3.  Otherwise, when the source IP protocol address does not match the
       target IP protocol address, the ATMARP server will generate the
       corresponding ATMARP_Reply if it has an entry for the target
       information in its ATMARP table.  Otherwise, it will generate a
       negative ATMARP reply (ATMARP_NAK).

   4.  Additionally, when the source IP protocol address does not match
       the target IP protocol address and when the server receives an
       ATMARP_Request over a VC, where the source IP and ATM address do
       not have a corresponding table entry, the ATMARP server MUST
       create a new table entry for the source information.
       Explanation: this allows old RFC 1577 clients to register with
       this ATMARP service by just issuing requests to it.

   5.  Additionally, when the source IP protocol address does not match
       the target IP protocol address and where the source IP and ATM
       addresses match the association already in the ATMARP table and
       the ATM address matches that associated with the VC, the server
       MUST update the table timeout on the source ATMARP table entry
       but only if it has been more than 10 minutes since the last
       update.  Explanation: if the client is sending ATMARP requests to
       the server over the same VC that it used to register its ATMARP
       entry, the server should examine the ATMARP request and note that
       the client is still "alive" by updating the timeout on the
       client's ATMARP table entry.

   6.  Additionally, when the source IP protocol address does not match
       the target IP protocol address and where the source IP and ATM
       addresses do not match the association already in the ATMARP
       table, the server MUST NOT update the ATMARP table entry.

   An ATMARP server MUST have knowledge of any open VCs it has and their
   association with an ATMARP table entry, and in particular, which VCs
   support LLC/SNAP encapsulation.  In normal operation, active ATMARP
   clients will revalidate their entries prior to the server aging
   process taking effect.

   Server ATMARP table entries are valid for 20 minutes.  If an entry
   ages beyond 20 minutes without being updated (refreshed) by the
   client, that entry is deleted from the table regardless of the state
   of any VCs that may be associated with that entry.

8.5 ATMARP Client Operational Requirements

   The ATMARP client is responsible for contacting the ATMARP service to
   both initially register and subsequently refresh its own ATMARP
   information.




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


   The client is also responsible for using the ATMARP service to gain
   and revalidate ATMARP information about other IP members in the LIS
   (server selection overview is discussed in Section 8.6).  As noted in
   Section 5.2, ATMARP clients MUST be configured with the ATM address
   of the appropriate server prior to client ATMARP operation.

   IP clients 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.1 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.
   See Section 8.7.1 for more details regarding the ATMARP Request
   packet format.

   To handle the case when a client has more than one IP address within
   a LIS, when using an ATMARP server, the client MUST register each
   such address.

   For initial registration and subsequent refreshing of its own
   information with the ATMARP service, clients MUST:

   1.  Establish an LLC/SNAP VC connection to a server in the ATMARP
       service for the purposes of transmitting and receiving ATMARP
       packets.

       NOTE: in the case of refreshing its own information with the
       ATMARP service, a client MAY reuse an existing established
       connection to the ATMARP service provided that the connection was
       previously used either to initially register its information with
       the ATMARP service or to refresh its information with the ATMARP
       service.

   2.  After establishing a successful connection to the ATMARP service,
       the client MUST transmit an ATMARP_Request packet, requesting a
       target ATM address for its own IP address as the target IP
       protocol address.  The client checks the ATMARP_Reply and if the
       source hardware and protocol addresses match the respective
       target hardware and protocol addresses, the client is registered
       with the ATMARP service.  If the addresses do not match, the
       client MAY take action, raise alarms, etc.; however, these
       actions are beyond the scope of this memo.  In the case of a
       client having more than one IP address in the list, this step
       MUST be repeated for each IP address.





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


   3.  Clients MUST respond to ATMARP_Request and InATMARP_Request
       packets received on any VC appropriately.  (Refer to Section 7,
       "Protocol Operation" in RFC 1293 [12].)

       NOTE: for reasons of robustness, clients MUST respond to
       ATMARP_Requests.

   4.  Generate and transmit address resolution request packets to the
       address resolution service.  Respond to address resolution reply
       packets appropriately to build/refresh its own client ATMARP
       table entries.

   5.  Generate and transmit InATMARP_Request packets as needed and
       process InATMARP_Reply packets appropriately.  InATMARP_Reply
       packets should be used to build/refresh its own client ATMARP
       table entries.  (Refer to Section 7, "Protocol Operation" in
       [12].)  If a client has more than one IP address within the LIS
       when an InATMARP_Request is received an InATMARP_Reply MUST be
       generated for each such address.

   The client MUST refresh its ATMARP information with the server at
   least once every 15 minutes.  This is done by repeating steps 1 and
   2.

   An ATMARP client MUST have knowledge of any open VCs it has
   (permanent or switched), their association with an ATMARP table
   entry, and in particular, which VCs support LLC/SNAP encapsulation.

8.5.1 Client ATMARP Table Aging

   Client ATMARP table entries are valid for a maximum time of 15
   minutes.

   When an ATMARP table entry ages, an ATMARP client MUST invalidate the
   table entry.  If there is no open VC server associated with the
   invalidated entry, that entry is deleted.  In the case of an
   invalidated entry and an open VC, the client MUST revalidate the
   entry prior to transmitting any non address resolution traffic on
   that VC; this requirement applies to both PVCs and SVCs.  NOTE: the
   client is permitted to revalidate an ATMARP table entry before it
   ages, thus restarting the aging time when the table entry is
   successfully revalidated.  The client MAY continue to use the open
   VC, as long as the table entry has not aged, while revalidation is in
   progress.

   In the case of an open PVC, the client revalidates the entry by
   transmitting an InATMARP_Request and updating the entry on receipt of
   an InATMARP_Reply.



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


   In the case of an open SVC, the client revalidates the entry by
   querying the address resolution service.  If a valid reply is
   received (e.g., ATMARP_Reply), the entry is updated.  If the address
   resolution service cannot resolve the entry (i.e., "host not found"),
   the SVC should be closed and the associated table entry removed.  If
   the address resolution service is not available (i.e., "server
   failure") and if the SVC is LLC/SNAP encapsulated, the client MUST
   attempt to revalidate the entry by transmitting an InATMARP_Request
   on that VC and updating the entry on receipt of an InATMARP_Reply.
   If the InATMARP_Request attempt fails to return an InATMARP_Reply,
   the SVC should be closed and the associated table entry removed.

   If a VC with an associated invalidated ATMARP table entry is closed,
   that table entry is removed.

8.5.2 Non-Normal VC Operations

   The specific details on client procedures for detecting non-normal VC
   connection establishment or closures, or failed communications on an
   established VC are beyond the scope of this memo.  It is REQUIRED
   however, that the client MUST remove the associated ATMARP entry for
   a VC that fails to operate properly, as defined by the client, when
   the client closes that VC, when it releases its resources for a VC,
   or prior to any attempt to reopen that VC.  This behavior
   specifically REQUIRES that the client MUST refresh its ATMARP table