Mobility support for NHRP
Koichi Horikawa <horikawa@nwk.cl.nec.co.jp> Wed, 22 November 1995 09:03 UTC
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07309; 22 Nov 95 4:03 EST
Received: from guelah.nexen.com by IETF.CNRI.Reston.VA.US id aa07305; 22 Nov 95 4:02 EST
Received: from maelstrom.nexen.com (maelstrom.nexen.com [204.249.97.5]) by guelah.nexen.com (8.6.12/8.6.12) with ESMTP id DAA18789; Wed, 22 Nov 1995 03:26:43 -0500
Received: (from root@localhost) by maelstrom.nexen.com (8.6.12/8.6.12) id DAA02336 for rolc-out; Wed, 22 Nov 1995 03:32:40 -0500
Received: from nexen.nexen.com (nexen.nexen.com [204.249.96.18]) by maelstrom.nexen.com (8.6.12/8.6.12) with ESMTP id DAA02327 for <rolc@nexen.com>; Wed, 22 Nov 1995 03:32:33 -0500
Received: from research.gate.nec.co.jp (research.gate.nec.co.jp [202.32.8.49]) by nexen.nexen.com (8.6.12/8.6.12) with ESMTP id DAA13269 for <rolc@nexen.com>; Wed, 22 Nov 1995 03:32:14 -0500
Received: from tomato.nwk.cl.nec.co.jp by research.gate.nec.co.jp (8.6.12+2.5Wb4/950912) with SMTP id RAA16812; Wed, 22 Nov 1995 17:30:47 +0900
Received: by nwk.cl.nec.co.jp (5.65c/6.4JAIN-nwk-gw+2.1) id AA08350; Wed, 22 Nov 1995 17:30:46 +0900
Received: by lettuce.nwk.cl.nec.co.jp (8.6.12+2.4W/NWK-950509) id RAA25417; Wed, 22 Nov 1995 17:32:09 +0900
Date: Wed, 22 Nov 1995 17:32:09 +0900
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Koichi Horikawa <horikawa@nwk.cl.nec.co.jp>
Message-Id: <199511220832.RAA25417@lettuce.nwk.cl.nec.co.jp>
To: rolc@nexen.com
Subject: Mobility support for NHRP
X-Orig-Sender: owner-rolc@nexen.com
Precedence: bulk
X-Info: Submissions to rolc@nexen.com
X-Info: [Un]Subscribe requests to rolc-request@nexen.com
X-Info: Archives for rolc via ftp://ietf.cnri.reston.va.us/ietf-mail-archive/rolc/
Hi, folks,
Following is the Internet-Draft to be submitted to ROLC group for the
support of mobile NHRP devices in ATM networks.
The proposed methods provide the capability for mobile terminals to
access its NHS correctly even if it does not know the ATM address of
the NHS. These proposals involve using "ATM anycast capability" and
modification of NHRP to support "NHRP Register forwarding".
Although the document's title has the term "Mobile", it is also
applicable to a non-mobile ( normal ) NHC. Becuase the NHC can
register its IP-ATM address pair with the appropriate NHS without
configuration of the each NHS's ATM address, 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.
We'd appreciate your comments/suggestions.
Best Regards,
Koichi
----------------------------------------------------------------------
Koichi Horikawa
Network Research Laboratory,
C&C Research Laboratories, NEC Corp.
FAX: +81-44-856-2230 TEL: +81-44-856-2123
--- 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 : +81-44-856-2123 phone : +81-44-856-2123
e-mail: horikawa@nwk.CL.nec.co.jp e-mail: hiroshi@nwk.CL.nec.co.jp
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 : +81-44-856-2123 phone : +61-7-33654321
e-mail: iwata@nwk.CL.nec.co.jp e-mail: horton@citr.uq.oz.au
Mobile NHRP [Page 9]
- Mobility support for NHRP Koichi Horikawa