Classical IP and ARP over ATM to NHRP Transition
RFC 2336

• Status
• IESG evaluation record
• IESG writeups
• Email expansions
• History

• Versions
• 03

Network Working Group                                         J. Luciani
Request for Comments: 2336                                  Bay Networks
Category: Informational                                        July 1998

            Classical IP and ARP over ATM to NHRP Transition

Status of this Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

Copyright Notice

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

Abstract

   This document describes methods and procedures for the graceful
   transition from an ATMARP LIS[1] to an NHRP LIS[2] network model over
   ATM.

1. Introduction

   The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
   SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this
   document, are to be interpreted as described in [6].

   ATMARP defines an initial application of classical IP and ARP in an
   ATM network environment configured as a LIS[1].  ATMARP only
   considers application of ATM as a direct replacement for the "wires"
   and local LAN segments connecting IP end-stations and routers
   operating in the "classical" LAN-based paradigm.

   The NBMA Next Hop Resolution Protocol (NHRP) allows a source station
   (a host or router), wishing to communicate over a Non-Broadcast,
   Multi-Access (NBMA) subnetwork, to determine the internetworking
   layer addresses and NBMA addresses of suitable "NBMA next hops"
   toward a destination station. If the destination is connected to the
   NBMA subnetwork and direct communication is administratively allowed,
   then the NBMA next hop is the destination station itself.  Otherwise,
   the NBMA next hop is the egress router from the NBMA subnetwork that
   is "nearest" to the destination station.  For the purposes of this
   document, the NBMA network is of type ATM.

Luciani                      Informational                      [Page 1]
RFC 2336         Classical IP and ARP over ATM to NHRP         July 1998

   It is reasonable to expect that ATMARP Clients and NHRP Clients will
   initially coexist within a LIS.  Thus, it is necessary to define a
   graceful transition, including a period of coexistance, from the use
   of ATMARP to the use of NHRP for address resolution in the LIS
   [1][2]. In short, NHSs will be required to respond to ATMARP Client
   queries in a fashion which will permit continued use of the ATMARP
   Client within the LIS during the ATMARP to NHRP transition period.
   Note that this document places no protocol requirements upon
   ATMARP[1] servers.

   For the following, it will be assumed that the reader is familiar
   with the terminology as described in [1][2][3].

2. Service Requirements

   If NHRP is to be used in a LIS then only NHSs will be used in the
   LIS; that is, there will not be a mixture of NHSs and ATMARP servers
   within the same LIS.  Since ATMARP servers will not be able to
   understand NHCs and since, as described below, NHSs will respond to
   ATMARP Clients, this is a reasonable simplifying restriction.

   This document will only address SVC based environments and will not
   address PVC environments.  This document will refer only to ATM AAL5
   as the NBMA and IP as the protocol layer since ATMARP only addresses
   these protocols.

2.1 NHRP Server Requirements

   If NHRP Servers (NHS) are to be deployed in a LIS which contains both
   ATMARP Clients and NHRP Clients then NHSs MUST respond to
   ATMARP_Requests sent by ATMARP Clients in the same fashion that an
   ATMARP Server would respond as described in [1].  To do this, the NHS
   MUST first recognize the LLC/SNAP ATMARP code point with LLC=0xAA-
   AA-03, OUI=0x00-00-00, and ethertype=0x08-06.  Further, the NHS MUST
   recognize the packet formats described in Section 8.7 of [1].
   However, since this document does not extend to PVC environments,

   NHSs MUST only receive/respond to values of ar$op of 1,2,10
   (Decimal).  If an NHS receives an ATMARP message with ar$op values
   other than those previously noted then the NHS MUST discard the
   packet and MUST NOT take any further action.

   When an NHS receives a valid (as defined in the previous paragraph)
   ATMARP_Request packet, the NHS MUST follow the rules described in
   Section 8.4 of [1] with the following additional processing:

Luciani                      Informational                      [Page 2]
RFC 2336         Classical IP and ARP over ATM to NHRP         July 1998

     1) When an ATMARP_Request causes a new table entry in the NHS for
        an ATMARP Client, that table entry MUST be marked as being of
        type "ATMARP" so that it can be differentiated from an NHRP
        sourced entry.

     2) An ATMARP_Request MUST NOT cause an ATMARP_Reply to be sent if
        that ATMARP_Request contains an off-LIS protocol address.  This
        should never happen because the IP stack on the requesting