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