Re: ATMARP Client Autoconfiguration

[Hiroshi Suzuki <[e-mail]>]

Joel,  Fong and IP-ATMers.

We (  NEC and CiTR  ) posted the following draft  for ROLC  last week,
which  is related  to   Autoconfiguration of  NHRP clients.  Since the
usage of Anycast for autoconfiguratin of  ATMARP is discussed  in this
ip-atm list, and  our draft is closely related  to this  issue, let us
make some comments.

Though the title of our draft is  on Mobile NHRP,  the basic target of
the  proposed scheme is  auto-configuration  of NHRP clients to access
its NHRP Server over large ATM network.

We assume that the NORMAL-Anycast capability be  used for NHRP clients
( NHC ) to  access the NHRP  server (  NHS   ).  AS Joel  pointed out,
Anycast address is OK only when the target  end system  is  within the
domain / site, since anycast address gives  us a connection to the end
service system which is closest in terms of PNNI  distance in a scope.
So if all NHSes register his service  capability with ANYCAST address,
NHCs which may be distributed anyway, and independent on  the position
of his NHS,( because of Logical subnet topology can be  independent on
the Physical network topology ) a NHC of a LIS may access another NHRP
server to register his IP-ATM address, which  is however configured to
support other LISes.  This results in registration error.

I agree somewhat that the idea of LIS-specific anycast address by Fong
and Carl  may help to  avoid the above NHRP autoconfiguration problem,
though the original  scheme is proposed for IPoverATM.   However, with
LIS  specific  Anycast,  since  PNNI  needs to advertize  LIS specific
information over   large  ATM  networks,  which  cause  an aggregation
problem, I rather agree what Joel wrote,

>However, if one extends this to usage of LIS technology over extended
>ATM networks, the scaling is very dangerous.  We have an anycast address
>being propagated for any IP subnet with LIS membership allowed anywhere
>in the extended ATM net.  Clearly, this is not all nets.  But such
>addresses are not aggregateable.  So, one ends up with a lot of
>advertisements.

So   what  we proposed  for  NHRP   (  not rfc1577)   is "registration
forwarding", as follows.

"A NHC  may accesses  "ANY" NHS with anycast  address  to register his
ATM-IP address.  If the  NHS is NOT  the server which supports the LIS
that the   NHC  belongs to,  then the   NHS is going  to FORWARD  such
register packet to the HOME NHRP server, using NHRP Server  table that
is originally  used for forwarding  NHRP request packets.   Note  that
such forwarding is  newly added  only for registration ( with security
extention ), other  procedures  are  the same,  meaning that  the NHRP
request can be sent ANY NHRP server,  since request forwarding  to the
appropriate NHS is already there."

Note that  these behaviors  are similar to what Mobile  IP does.  This
scheme is scalable and allows us to have a wider area  spread LIS over
big ATM network, and we can have more mobility of terminals.  e.g. You
can move  anywhere in  the  same  NBMA ( even  in the  world if it  is
connected  to ) with  your ATM-PC with  the same IP address.  You will
get different ATM address  from the  switch you plug  in but you  will
still register your  new ATM address to your  home NHS.  Each NHC  can
move to anywhere  as long  as he can access  any NHS which can forward
his packet to the home NHS.

(We also considered the usage of Config server to get his NHS address.
But if the registration forwarding  is  not supported,  this does  not
scale as well if we use anycast address to access configuration server
again.  This is because NHC may  access different configuration server
which does not have the right information of the NHS information.)

I personally  presume that NHRP  servers will  be  deployed eventually
everywhere instead of RFC1577 server existing for a  longer time.  And
also we expect this forward capability can be extended to support MARS
registration   forwarding  based   on NHRP  infrastructure.   Even for
RFC1577 legacy  clients,  NHRP servers  acting  as  RFC1577 server, as
discussed in this list, could forward such ATMARP  packet to the right
Server.

I hope this is helpful for this list as well.

Best Regards

Hiroshi SUZUKI
NEC


----- cut here -----




Routing over Large Clouds Working Group                  Koichi Horikawa
INTERNET-DRAFT                                         (NEC Corporation)
                                                          Hiroshi Suzuki
                                                       (NEC Corporation)
                                                           Atsushi Iwata
                                                       (NEC Corporation)
                                                            David Horton
                                                                  (CiTR)
                                                           November 1995


            Support for Mobile NHRP Devices in ATM Networks
                  <draft-horikawa-mobile-nhrp-00.txt>


Status of this Memo

   This document is an Internet Draft.  Internet Drafts are working
   documents of the Internet Engineering Task Force (IETF), its Areas,
   and its Working Groups.  Note that other groups may also distribute
   working documents as Internet Drafts.

   Internet Drafts are draft documents valid for a maximum of six
   months.  Internet Drafts may be updated, replaced, or obsoleted by
   other documents at any time.  It is not appropriate to use Internet
   Drafts as reference material or to cite them other than as a "working
   draft" or "work in progress."

   Please check the 1id-abstracts.txt listing contained in the
   internet-drafts Shadow Directories on nic.ddn.mil, nnsc.nsf.net,
   nic.nordu.net, ftp.nisc.sri.com, or munnari.oz.au to learn the
   current status of any Internet Draft.


Abstract

   This document describes support for mobile devices using NHRP [1] for
   address resolution in ATM networks.

   This document proposes some methods for a mobile terminal to access
   its NHS correctly even if it does not know the ATM address of the
   NHS. These proposals involve using "ATM anycast capability" specified
   in [2] and modification of NHRP to support "NHRP Register
   forwarding".

   The methods described in this document are also applicable to non-
   mobile devices.




Mobile NHRP                                                     [Page 1]

Expiration Date May 1995                                   November 1995


1. Problem Statement

   The aim of the proposal is to support ATM terminals which move from
   one switch to another across several sites and remain there for long
   periods of time. Their ATM addresses change but the IP addresses do
   not. The aim is to support wire/fiber connection technologies but not
   to support "true mobile" communications with radio links etc.

   An NHS manages the IP-ATM address pair of each ATM terminal which it
   serves. Each ATM terminal sends NHRP Register packets to the NHS. In
   the case of static configuration,  each ATM terminal needs to know
   the ATM address of the NHS. So the system administrator must
   configure the NHS's ATM addresses in each ATM terminal. The current
   NHRP specification would work if the NHS's ATM addresses are
   configured correctly in each ATM terminal, even if an ATM terminal
   moves.  (Because the NHC will establish an SVC across the ATM network
   to the home NHS).

   However it would be very complicated to maintain these NHS's ATM
   addresses for the large number of ATM terminals in the ATM network.
   Therefore, it is desirable that each ATM terminal does not need to
   know actual ATM address of its NHS, but uses an alternative way to
   access its NHS.

   One of the possible solutions might be that each ATM terminal
   accesses its NHS through the use of the ATM anycast capability [2]
   (or by the use of well-known PVC to access its NHS; such a PVC would
   be configured at each ATM switch in the ATM network).

   However, due to the mobility of ATM terminals, this approach is not
   sufficient.  If the ATM terminal moves to another domain, the NHS
   accessed via ATM anycast capability (anycast address) might be
   different from one which serves the ATM terminal.  This is because
   the path is routed by PNNI procedures so that it takes minimum switch
   hops to the entity specified by the anycast address [3]. In this
   case, the NHS will reject NHRP Register packets from the ATM terminal
   as described in [1].

   For example, suppose there is a big ATM campus network as shown in
   Figure 1, which consists of an ATM cloud in the west coast campus
   (the logical IP Subnet: LIS-A ) and another cloud in the east coast
   campus (LIS-C). These clouds are directly interconnected by ATM.
   Suppose your home campus is in the west coast and your PC belongs to
   the LIS-A. So, the PC's IP-ATM address pair is registered at the
   NHS-1, which is configured to serve the LIS-A. You may fly from the
   west coast to the east coast for business trip with your PC, and may
   plug in the ATM network in the east coast campus, without changing
   the IP address. If you usually access NHS-1 with ATM anycast



Mobile NHRP                                                     [Page 2]

Expiration Date May 1995                                   November 1995


   capability, then the NHRP registration with the anycast address would
   get to the NHS-3 when you are in the east coast campus, since the
   anycast address leads you the nearest entity in terms of PNNI routing
   distance. Based on the current NHRP draft-06 [1], such a registration
   would be rejected, since the NHS-3 is configured to serve LIS-C.

           (Home NHS)                                 (Foreign NHS)
          Serving LIS-A         Serving LIS-B         Serving LIS-C
            +-------+             +-------+             +-------+
            | NHS-1 |             | NHS-2 |    "Reject!"| NHS-3 |
            +---+---+             +---+---+             +---+---+
                |                     |                     |   ^
         +------+---------------------+---------------------+-- | -+
         | (The west coast)   :               :(The east coast) |  |
         |      LIS-A         :     LIS-B     :      LIS-C      |  |
         |                    :               :                 |  |
         |                    :               :   NHRP Register |  |
         |                    :               :     (anycast)   |  |
         +--------------------------------------------------+-- | -+
               |                 ATM network                |   |
          +----+----+                                  +----+----+
          |Terminal |  ============================>>  |Terminal |
          +---------+              (move)              +---------+
                                                          (NHC)
          [IP : A.1]                                   [IP : A.1]
          [ATM: X.1]                                   [ATM: Y.1]

                                                      Mobile device


         Figure 1:  Problem when access to an NHS by anycast address



2. Proposal

2.1 Termininology

   This this document uses the same terminology as [1]. In addition, we
   use following terms.

   ATM network:      a logical ATM subnetwork, corresponding to "logical
                     NBMA subnetwork" described in [1].

   Mobile devices:   ATM terminals (hosts, routers etc.) which move from
                     one switch to another across several sites and
                     remain there for long periods of time. Their ATM
                     addresses will change but the IP addresses will



Mobile NHRP                                                     [Page 3]

Expiration Date May 1995                                   November 1995


                     not.

   NHC:              an NHRP client itself or an ATM terminal where the
                     NHRP client runs. (The mobile device)

   Home NHS:         the NHS to which the NHC normally sends NHRP
                     packets.  This home NHS holds authoritative IP-ATM
                     address pair of the NHC.

   Foreign NHS:      other NHS than the home NHS. The IP address prefix
                     of the foreign NHS may be different from that of
                     the NHC.

   The relationships between these is shown also in Figure 1.

2.2 Overview

   In this section, we present a proposal to support mobile devices and
   also to avoid (or reduce) manual configuration of each mobile device.
   Although a diversity of solutions could be considered, we present a
   proposal where no modification of the NHRP packet types is needed. A
   manual configuration may also be used to override this automatic
   configuration.

   Following is the proposal:


   . An NHC sends an NHRP Register packet to an NHS (home or foreign)
     via anycast address of NHS service. The NHS which received this
     NHRP Register packet forwards it towards this NHC's home NHS if
     necessary. The next-hop NHS choice would be the same as for an
     authoritative request for this NHC's address.

   Basically, this proposal depends on "ATM anycast capability"
   specified in [2]. An anycast address is a "functional address" which
   is assigned to a certain service such as LAN Emulation Configuration
   Server (LECS) [4]. Even if there are multiple servers providing the
   service in an ATM network, each ATM terminal does not have to know
   the number of servers nor where the servers are located. When an ATM
   terminal wants to access the server, it sends a SETUP message which
   contains the anycast address of the service. The ATM network, upon
   receiving this SETUP message, will establish a single point-to-point
   connection to the nearest server in term of PNNI routing distance
   (See [2] and [3] for further details).

   This proposal allows an NHRP deployment to avoid (a) configuring NHCs
   with specific (unicast) ATM addresses of their NHSs, and (b) imposing
   requirements on relative placement of NHCs and their NHSs within an



Mobile NHRP                                                     [Page 4]

Expiration Date May 1995                                   November 1995


   ATM network.  So it is also applicable to a non-mobile NHC so that
   the NHC can register its IP-ATM address pair with the appropriate NHS
   regardless of the relative positions of the NHC and the NHS on the
   ATM network.  This is useful to reduce manual configuration for
   constructing a virtual LAN, for example.


2.3 Description

   This section gives a more detailed description of the proposal.

   This proposal consists of the following two items.

   . An NHC accesses the home NHS or foreign NHS via ATM anycast
     capability.

   . An NHS forwards the NHRP Register packet towards the NHC's home NHS
     if this packet is not originated by an NHC which this NHS serves.
     This forwarding procedure for the NHRP Register packet is carried
     out based on the NHRP Server Table which is used for forwarding the
     NHRP Request packets.

   The protocol proceeds as follows (See Figure 2).

           Home NHS                                   Foreign NHS
           +-------+             +-------+             +-------+
           | NHS-1 | <---------  | NHS-2 | <---------  | NHS-3 |
           +---+---+   forward   +---+---+   forward   +---+---+
               |                     |                     |  ^
         +-----+---------------------+---------------------+- | -+
         |                 :                   :              |  |
         |     LIS-A       :       LIS-B       :     LIS-C    |  |
         |                 :                   :              |  |
         |                 :                   : NHRP Register|  |
         |                 :                   :   (anycast)  |  |
         +-------------------------------------------------+- | -+
               |                ATM network                |  |
           +---+---+                                   +---+---+
           |  NHC  |  =============================>>  |  NHC  |
           +-------+              (move)               +-------+
                                                      Mobile device


                            Figure 2  Proposal

   Each NHC is configured with the anycast address of NHS service
   (anycast-NHS: this value is [To Be Done]). Each NHC uses this
   anycast-NHS to establish an SVC to send any NHRP packet to an NHS.



Mobile NHRP                                                     [Page 5]

Expiration Date May 1995                                   November 1995


   This means each NHC does not have to know actual ATM address of its
   NHS. Furthermore, anycast address has as same format as ordinary ATM
   addresses (20-octet address), so each NHC need not to know whether
   the address is an anycast or an ordinary ATM address.

   An NHS accessed via anycast-NHS is the nearest one from an NHC, as
   mentioned above. So, if this NHC has moved to another switch, the NHS
   which the NHC could access by anycast-NHS might be different from the
   one serving this NHC. In this case, when the NHC establishes an SVC
   and sends NHRP Register packet to the NHS, non-home NHS would receive
   this packet. If this packet is discarded as described in [1], this
   mobile NHC could not participate in NHRP.

   So "forwarding NHRP Register packet towards the home NHS" capability
   is introduced here. When an NHS receives an NHRP Register packet from
   an NHC or other NHS, the NHS checks if the NHC which originated this
   packet is served by the NHS. If the NHC is served by the NHS, normal
   action is taken as described in [1]. Otherwise, the NHS forwards the
   NHRP Register packet towards the home NHS in the same way as if the
   NHC made a request for ATM address of itself. The NHS determines the
   next hop NHS based on the Source IP address field in the NHRP
   Register packet to be forwarded. This forwarding behaviour is
   proposed instead of sending an NHRP Error Indication packet (Can't
   Serve This Address) back to the NHC.


   Other NHRP actions are done as described in [1]. For example, NHRP
   request packets for this roaming NHC's ATM address (based on its IP
   address), will be forwarded to the home NHS by normal NHRP
   forwarding. NHRP request packets by the roaming NHC will be made to
   the foreign NHS via anycast-NHS. [Note: This roaming NHC does not
   have to know whether this NHS's address is an anycast one or an
   ordinary one.]

   [Note: The transit NHSs may cache the information included in the
   NHRP Register packet to be forwarded. If the transit NHSs do that,
   then performance of NHRP would improve. However, there would be some
   security and cache coherency problems. Therefore this proposal
   recommends caching no information from the NHRP Register packet to be
   forwarded. This issue is for further study.]

   For security reasons, new NHRP Extension "NHRP End-End Authentication
   Extension" should be supported at least in NHRP Register packet. This
   extension should be checked when NHRP Register packets are forwarded.
   Authentication of each NHC is done by only the home NHS. This means
   that a transit NHS which receives NHRP Register packets from NHCs or
   other NHSs should forward the same contents of the NHRP Register
   packet towards the home NHS (See section 4, Security Considerations).



Mobile NHRP                                                     [Page 6]

Expiration Date May 1995                                   November 1995


3. Discussion

   What we propose

   (a) removes the need for individual configuration of NHCs

   (b) leverages NHRP Register forwarding from the NHRP Request
       forwarding configuration in the NHS.

   There could be other solutions than the method proposed in this
   document. For example (See Figure 3.),

   . A kind of configuration server may be placed per a certain
     administrative domain, which hold ATM addresses of all NHSs and
     also which LIS(s) the NHSs serve within the domain.

   . An NHC accesses one of these configuration servers via the anycast
     address of the configuration service. Then this configuration
     server tells the NHC an ATM address of the NHC's home NHS. This
     procedure is similar to that of LAN Emulation Configuration Server
     (LECS) [4]. If this configuration server does not know the home
     NHS, it tells the NHC an ATM address of the nearest NHS towards the
     home NHS. The NHC then establishes an SVC to the NHS by the
     obtained ATM address and sends NHRP Register packet to the NHS
     (NHRP Request packet as well).

   . An NHS, upon receiving the NHRP Register packet, forwards it
     towards the NHC's home NHS if this packet is not originated by an
     NHC which this NHS serves.






















Mobile NHRP                                                     [Page 7]

Expiration Date May 1995                                   November 1995


               +-------------+                   +-------------+
               |Configuration|                   |Configuration|
               |  Server-1   |for LIS-A/B        |  Server-2   |for LIS-C/D
               +------+------+                   +------+------+
                                                          ^
          Home NHS                       Foreign NHS    | |
          +-------+       +-------+       +-------+     | |  +-------+
          | NHS-1 | <---- | NHS-2 | <---- | NHS-3 |     | |  | NHS-4 |
          +---+---+       +---+---+       +---+---+     | |  +---+---+
              |               |               |  ^      | |      |
      +-------+---------------+---------------+- | ---- | | -----+----+
      |               :               :          \    : | |           |
      |     LIS-A     :     LIS-B     :   LIS-C   \   : | |   LIS-D   |
      |               :               :            \  : | |           |
      |               :               :             \ : | |  Query    |
      |               :               :              \  | |(anycast)  |
      +---------------------------------------------- \ v | -+--------+
              |       ATM network        NHRP Register \     |
          +---+---+                                    +-----+-+
          |  NHC  |  =============================>>   |  NHC  |
          +-------+              (move)                +-------+


                         Figure 3  Another solution

   This solution also needs "NHRP Register forwarding capability" when
   there are multiple configuration servers supporting large ATM
   networks. Therefore the essential part of the mobility support in
   NHRP is to have the NHRP Register forwarding procedure. This
   registration behavior is consistent with the registration behavior of
   the mobile node in "IP Mobility Support" [5].

4. Security Considerations

   To avoid security problems, it is recommended to use the new NHRP
   Extension "NHRP End-End Authentication Extension" described in
   section 2.

   The NHRP Authentication Extension as described in [1] is hop-by-hop.
   For this proposal we introduce end-end authentication, i.e.
   authentication between the roaming NHC and the NHS that will serve
   its IP-ATM address. The NHRP End-End Authentication Extension should
   not be recalculated at transit NHSs. The format for the NHRP End-End
   Authentication Extension is for further study. It is expected to
   follow similar lines to the hop-by-hop NHRP Authentication Extension.






Mobile NHRP                                                     [Page 8]

Expiration Date May 1995                                   November 1995


References


   [1] "NBMA Next Hop Resolution Protocol (NHRP)", Dave Katz, David
       Piscitello, Bruce Cole, draft-ietf-rolc-nhrp-06.txt

   [2] "Draft of UNI Signaling 4.0", ATM Forum 94-1018R6

   [3] "PNNI Draft Specification", ATM Forum 94-0471R14

   [4] "LAN Emulation over ATM Specification, Version 1.0", The ATM
       Forum

   [5] "IP Mobility Support", Charles Perkins, draft-ietf-mobileip-
       protocol-12.txt

Acknowledgment

   The authors would like to thank Yakov Rekhter (cicso Systems) for his
   comments.

Author's Address:

      Koichi Horikawa                     Hiroshi Suzuki
      C&C Research Laboratories,          C&C  Research Laboratories,
      NEC Corporation                     NEC Corporation
      4-1-1 Miyazaki, Miyamae-ku,         4-1-1 Miyazaki, Miyamae-ku,
      Kawasaki, Kanagawa 216 Japan        Kawasaki, Kanagawa 216 Japan
      phone : [phone]             phone : [phone]
      e-mail: [e-mail]   e-mail: [e-mail]

      Atsushi Iwata                       David Horton
      C&C  Research Laboratories,         Centre for Information Technology
      NEC Corporation                     Research,
      4-1-1 Miyazaki, Miyamae-ku,         University of Queensland
      Kawasaki, Kanagawa 216 Japan        Qld 4072 Australia
      phone : [phone]             phone : [phone]
      e-mail: [e-mail]      e-mail: [e-mail]













Mobile NHRP                                                     [Page 9]