ATM Forum Technical Committee ATM Forum/96-1699/WATM ------------------------------------------------------------------------------ Title: Tunnelled Signalling for the Support of Mobile ATM ------------------------------------------------------------------------------ Source: John Porter, Damian Gilmurray Olivetti Research Limited 24a Trumpington Street Cambridge CB2 1QA United Kingdom Phone: +44 1223 343000 Fax: +44 1223 313542 Email: {jporter, dgilmurray}@orl.co.uk ------------------------------------------------------------------------------ Date: December 2-6, 1996 Vancouver, B.C., Canada ------------------------------------------------------------------------------ Distribution: WATM ------------------------------------------------------------------------------ Notice: This contribution has been prepared to assist the ATM Forum. It is offered for discussion and is not a binding proposal on Olivetti Research Limited. Specifically Olivetti Research Limited reserves the right to add, amend or withdraw any or all statements contained herein. ------------------------------------------------------------------------------ Abstract: This contribution proposes a solution to the problem of supporting mobile ATM devices and is in response to the request for technical proposals made in [1]. The solution described uses tunnelled signalling in combination with a location service to perform location management for mobile ATM devices. ------------------------------------------------------------------------------ 1 Introduction A number of contributions have proposed solutions to the problem of location management for mobile ATM devices [2-4]. These solutions may generally be categorised into either mobile PNNI schemes where the routing mechanisms of PNNI are extended to cope with mobility or location register schemes where location management is performed outside PNNI. The solution proposed here falls into the latter category. The solution to location management for mobile ATM has a number of requirements. . It should be scaleable The solution should scale to support large numbers of mobiles where there is possibly rapid mobility between access points. It should work over an arbitrarily large internetwork which involves both private and public ATM networks. . It should support hosts and networks with no mobility enhancements Unmodified hosts and networks should operate transparently with those with mobility enhancements. Furthermore the modifications to existing signalling and routing protocols should be minimised. . There should be efficient routing of virtual connections Virtual connections to mobile ATM devices must be routed on a reasonably optimal path. This is especially true in the wide area where connections traversing the public ATM network will be subject to billing. However it is more important for the system to function adequately with legacy networks and hosts than for the routing to be optimal. . Management overhead should be minimised The mobility of a large number of mobiles should not overload the ATM network with management messaging. The effect of small-scale mobility of mobiles in the local area should be isolated from the wide area[5]. Furthermore, where there are protocol exchanges involving mobile entities, intermediate switches should be involved in the processing of these messages. The solution described here proposes the use of tunnelled signalling in combination with a location service to manage the mobility of ATM devices. The scheme is applicable to both a scenario in which the wireless link is to a mobile terminal and one in which the link is to a mobile. Most importantly it can operate with no changes to signalling protocols and therefore work with existing and future systems. 2 Architecture 2.1 Addressing In order to make use of existing PNNI routing protocols this scheme proposes the use of a Mobile Home Address (MHA) and a Mobile Foreign Address (MFA) to track and locate mobile ATM devices as in [2][3]. A mobile is assumed to originate from a particular network termed its Home Network. Services within this network have administrative responsibility for the mobile and maintain information such as the current location of the mobile and security details for authentication services. When a mobile registers in a network other than its Home Network this network is termed its Foreign Network. Services within the Foreign Network are responsible for managing the small scale mobility of the mobile within this network and for registering the current location of the mobile. An MHA, specifying the Home Network, is allocated to the mobile which stores it in non volatile memory. A possible mechanism for allocating this address is to derive it from the network prefix of the Home Network and the MAC address of the mobile. The MAC address of a mobile is a 48-bit globally unique IEEE MAC address as is suggested for use as the End System Identifier (ESI) in UNI 4.0 [6]. Endpoints which wish to establish a connection with a mobile device use the MHA of the mobile for the called party number in the SETUP request. Similarly mobile endpoints which wish to establish a connection use their MHA for the calling party number in the SETUP request. It must be possible for a mobile-enabled switch to determine whether a called party number in a SETUP request refers to a mobile. There are two possible approaches: either the address is specified in a table of mobile addresses or the address space is explicitly partitioned. A table-based approach is considered to have a serious performance penalty and therefore a partitioning of the address space is considered necessary. When a mobile registers in a foreign network it is allocated an MFA by a service in that network. This address may either indicate a switch or an access point in the network or may be derived from the network prefix of the Foreign Network and the MAC address of the mobile. The dynamic binding of MFA to MHA means that a relatively static binding between ATM endpoints and ATM addresses can be assumed for ATM name server functionality [8]. The view taken by PNNI that the ATM address hierarchy reflects the network topology can also be extended to mobile endpoints. 2.2 Location Service As has been proposed in other contributions, a Location Service manages the mapping between MHAs and MFAs. The implementation of this Location Service will logically consist of a hierarchy of location registers. The functionality of the Location Service will include services provided in both the Home Network and the Foreign Network of the mobile. These services are supported by location registers respectively termed the Home Location Register (HLR) and the Visitor Location Register (VLR). The Location Service protocol should be independent of PNNI and UNI in order to satisfy the scaleability requirement. It can then run efficiently over any ATM network regardless of the underlying protocols and imposes no mobility requirements on those protocols. The HLR for a mobile is the service at the mobile's Home Network which is the authoritative and fallback location for the mapping from the MHA to its MFA. The HLR can also be used to authenticate the mobile when it is registered in Foreign Networks. Further value-added services such as paging may also be provided by the HLR. When a mobile registers at an access point in a foreign network using its MHA, the access point contacts the Location Service. The Visitor Location Register (VLR) allocates an MFA to the mobile and caches the mapping from the MHA to this MFA. The Location Service then communicates this mapping through the Location Service hierarchy back to the HLR for the mobile. 2.3 Tunnelling Tunnelling is a term used to describe the encapsulation of an endpoint address in a message routed via an intermediate address, the tunnel address. In the IP Mobility Support RFC [7] tunnelling is used to route datagrams to the current location of mobile IP devices. In this contribution, tunnelling is used for SETUP requests. SETUP requests for the endpoint address are routed via the intermediate tunnel address after which the signalling message reverts to the use of the original endpoint address. A simple example of tunnelling is illustrated in Figure 1. We propose that this mechanism be used to support routing SETUP requests for mobile endpoints and networks. Figure 1: Example of simple tunnelling 2.4 Tunnelling Implementation The implementation of tunnelling, as described, requires functionality which enables the encapsulation of the destination address in the connection SETUP request and the reconstruction of the original connection SETUP request at the tunnel exit. This can either be by explicit encapsulation of the destination address within the tunnelled request, or by implicit recovery of the address based on the addresses in the request. 2.4.1 MHA Encapsulation A mechanism to support explicit tunnelling is already specified in UNI3.0/3.1/4.0 to route connections between private ATM endpoints identified by NSAP-format ATM addresses across a public network supporting E.164 ATM addresses. At the ingress UNI to the public network the private ATM addresses are encapsulated in the Called Party Subaddress and Calling Party Subaddress information elements of a SETUP request. The E.164 gateway addresses of the two private networks are substituted as the new Calling Party Number and Called Party Number information elements. At the egress UNI from the public network, the private ATM calling and called party addresses are extracted from the Subaddress information elements and are used to forward the SETUP request with the original called and calling party private ATM addresses. In UNI4.0 and PNNI1.0 multiple called party subaddress information elements can be included in a SETUP request. A subaddress information element can therefore be used to transport the MHA in a tunnelled SETUP request where the called party number is the MFA. This is the preferred approach to encapsulation as it is consistent with the current function for this Information Element. The Generic Identifier Transport in UNI 4.0 / PNNI 1.0 is an end-to-end information element. As has been suggested in [3], this could be used to carry the MHA in a tunnelled SETUP request where the called party number is the MFA. If neither of these approaches are applicable (neither are possible in UNI 3.0/3.1) then a fallback solution is to use Implicit Tunnelling. This can only apply where there is a one-to-one mapping between MHA and MFA. If this is the case then MHA can be recovered at the exit of a tunnel with a reverse mapping based on the MFA. 2.4.2 MHA to MFA Translation A tunnel is entered at the first mobile-enabled switch encountered by the SETUP request as it is forwarded from the calling party towards the MHA. For optimal routing the mobile-enabled switch should be as near to the calling party as possible. A practical solution is to have mobility functionality in the gateway switch between the public and private network. The worst-case scenario is one in which there are no mobile-enabled switches en route to the mobileÆs Home Network. In this situation a mobile-enabled switch in the Home Network would perform the tunnelling of the SETUP request to the mobileÆs Foreign Network. This architecture allows for a limited initial deployment of mobility enhancements at the cost of sub-optimal routing with the option of progressive improvement. 2.4.3 MFA to MHA Translation A tunnel is exited either at a mobile-enabled switch or the access point for the mobile. The precise location of the exit of a tunnel is dependent on the handoff model. There are two main proposals for managing the handoff of connections as a mobile moves between access points. The first model, commonly referred to as the Path Rerouting Model, involves rerouting a mobileÆs connections from one access point to another via a crossover or anchor switch. In practice the switch may either be a true ATM switch or an access point. The second model, the Path Extension Model, involves extending the connections on handoff from one access point to the next. In the path rerouting model the MFA is associated with an anchor switch where the tunnel terminates. Connections are then routed to the appropriate access point using tunnelled SETUP requests where the called party number is the address of this access point. In the path extension model, the MFA is associated with an access point. On handoff, the MFA will either migrate or be reassigned from the old access point to the new access point. Existing connections at the old access point are extended to the new access point using tunnelled SETUP requests where the called party number is the address of this new access point. Until the MFA address migration or reassignment has taken effect, new SETUP requests will continue to arrive at the old access point. These SETUP requests will then be tunnelled through the access points in the path until they arrive at the mobileÆs current access point. The migration or reassignment of the MFA places no requirements on the speed of PNNI routing updates as tunnelling bypasses this routing. Rebinding MFA to MHA requires that the location service be updated frequently. Migration of MFA between access points requires the localised routing to be modified to reflect the new topology. Selection of one or other scheme depends on the tradeoff between Location Service updates and PNNI routing updates. 2.5 Tunnelling to Support Mobile Terminals 2.5.1 Fixed Terminal(FT) to Mobile Terminal(MT) In this example, a connection is originated by FT1 with ATM endpoint address A.1.10 for mobile MT2 with MHA C.2.11. The source network is mobile-enabled and the mobile is supported by an anchor switch in its Foreign Network. When the mobile was initially registered at AP2 the VLR allocated MFA B.3.3 as the anchor switch for the mobile. . FT1 generates a SETUP request specifying A.1.10 as the calling party number and MHA C.2.11 as the called party number. . The SETUP request is routed via a mobile-enabled switch in the source network. The mobile- enabled switch recognises that the called party number is that of a mobile and performs a location request on that address. . The Location Service returns the MFA B.3.3 for the mobile which in this case is the endpoint address of the anchor switch. . The called party number of the SETUP request is now replaced with the MFA and the MHA is encapsulated. . The SETUP request is routed to the anchor switch in the Foreign Network using standard routing protocols based on the MFA. . At the anchor switch the original called party number is recovered and the SETUP request is tunnelled to the appropriate access point endpoint address. . The access point receives the tunnelled message and forwards the original SETUP request to the mobile. 2.5.1 MT to MT In this example a connection is originated from calling mobile MT1 and destined for mobile MT2. The mobiles themselves only use their respective MHAs, MHA1 D.1.12 and MHA2 C.2.11. Access points are assumed to have Location Service functionality and in this case no mobile-enabled switches are necessary. There are no changes to the signalling protocols. . Mobile MT1 originates a SETUP request specifying MHA1 as the calling party number and MHA2 as the called party number. . The source Access Point AP1 detects that MHA2 is a mobile address and makes a location request to the Location Service. (For illustrative purposes the VLR is shown forwarding the request to the HLR although in practice the Location Service is likely to have the MHA-to-MFA mapping cached.) The Location Service returns MFA2 which in this case corresponds to the destination access point B.3.3. . AP1 replaces the called party number in the SETUP request with MFA2 and encapsulates the MHA2. . The SETUP request is now routed based on MFA2 to the destination access point. . AP2 now regenerates the original SETUP request by replacing the called party number with MHA2. . The VC is completed when the CONNECT message returns along the prototype VC. 2.6 Tunnelling to Support Mobile Networks The discussion so far has been focused on the mobile endpoints scenario. Tunnelled signalling is most effective for the location management of mobile or moving ATM networks where the wireless link is supporting multiple ATM endpoints. In a mobile ATM network, such as a mobile multi-user platform, many ATM devices including switches and endpoints are collectively mobile. To avoid the management overhead of registering a separate MHA-to-MFA mapping for each ATM device in the mobile network, all the devices in the mobile network share an MHA prefix. When the wireless access point of a mobile network registers at a network, the VLR of the network allocates a single MFA address to the mobile network. The Location Service maintains a mapping from the mobile networkÆs MHA prefix to this MFA. This Network prefix is then used as a mask by which any address within the mobile network can be tunnelled via the same MFA. 2.6.1 FT to FT in mobile network In this example a mobile network is supported. There are assumed to be terminals which are fixed with respect to the mobile network. In this case the Location Service can manage the mobile network as a whole. All endpoints within the mobile network have the same network prefix D which identifies them as mobile. Non mobile-enabled switches will by default route connections to the æHome NetworkÆ of D which is C. The mobile access point AP1 registers the mobile network using its network prefix D. The Location Service now æwild cardsÆ any addresses with that prefix and assumes that they are all contacted via the same MFA. The Location Service and any VLRs only need a single entry for all endpoints within the mobile network The tunnelling procedure is now identical to that for a single mobile endpoint. The only difference is that the Location Service only needs to match the network prefix for the mobile network. 2.6.1 FT to MT in mobile network This case is similar to that of a mobile ATM network. In this case the mobile network itself has access points and supports the registration of mobiles. The registration process is hierarchical. Mobile MT2 registers with the access point AP2 which itself is part of the mobile network E. AP2 registers mobile MT2 with the Location Service in its own network. This determines the MHA-to- MFA translation specific to the mobile network. The mobile location service then registers MT2 with the wired location service and the mobile is registered in the usual way in the wired network. When a connection is made to the mobile there are now two translations of MHA-to-MFA; first by the mobile-enabled switch in the wired network and the second by the mobile-enabled switch (AP3) in the mobile ATM network. 2.7 Tunnelling through public network 2.7.1 FT to MT via Home Network This example demonstrates tunnelling between a fixed host and a mobile endpoint across the public network. In this case the source network of the fixed host is not mobile-enabled. The mobile is supported by an anchor switch which decouples the movement of the mobile between access points from the Location Service. The protocol falls back to the rerouting approach to location management where the connection is routed via the Home Network of the mobile. . The call is originated by FT1 with the MHA as the called party number. There are no mobile- enabled switches in the originating network so the SETUP request is routed to the mobile Home Network by default. The SETUP request traverses the public network using E.164 address encapsulation in order to route to the mobile Home Network. . In the mobile Home Network the originating NSAP addresses are recovered at the public-to- private UNI and the SETUP request is routed to a mobile-enabled switch. . This mobile-enabled switch contacts the Location Service (in this case the VLR and HLR may be co-located). . The MFA B.4.4, the address of the anchor switch, is retrieved from the Location Service. . The called party number in the SETUP request is replaced with the MFA and the MHA is encapsulated. . The SETUP request is then routed back through the public network to the anchor switch. In this case the private-to-public UNI must again encapsulate the NSAP addresses using E.164 addresses to identify the appropriate public-to-private network gateway. . The tunnelled NSAP addresses are recovered at the destination public-to-private UNI and the SETUP request is forwarded to the anchor switch. . At the anchor switch the tunnelled SETUP request is again recovered and in this case is tunnelled once more to the appropriate access point. . The access point then forwards the SETUP request containing the original ATM endpoint addresses to the mobile. . The signalling process completes with either a RELEASE or CONNECT, which follows the reverse path using the prototype VC established by the SETUP request. In this case the wide area routing is non-optimal due to the lack of mobile support in the source network. The public network is not modified to support mobility and hierarchical tunnelling, i.e. tunnelling for mobility encapsulation and E.164 address encapsulation, is used. 2.8 Implicit Tunnelling 2.8.1 FT to MT In this example it is assumed that the intervening network cannot support explicit tunnelling. This would be the case for UNI 3.0 / 3.1 networks which have no mechanism for encapsulation of the MHA. Implicit tunnelling requires the MHA and MFA to have a one-to-one mapping. This can be achieved by including the ESI of the MHA in the MFA with the assumption that the mobile ESI is unique. The MFA is not associated directly with any endpoint in the network. In a SETUP request with the MFA as the called party number, the HO-DSP is used to route the request the appropriate anchor switch. The anchor switch then performs a reverse lookup on the MFA based on the ESI and recovers the appropriate MHA. In this example the SETUP request is again implicitly tunnelled to the access point although it is likely that the anchor switch to access point link will support encapsulation. 3 Summary The solution described here proposes the use of tunnelled signalling in combination with a location service to manage the mobility of ATM devices. The scheme is applicable to both a scenario in which the wireless link is to a mobile terminal and one in which the link is to a mobile. Most importantly it can operate with no changes to signalling protocols and therefore work with existing and future systems. Advantages of the tunnelling approach: . Compatible with UNI/PNNI/BICI . No management load for intermediate switches . Routing efficient with mobile enabled networks . Network functional with no mobile enhancements . Reduces dynamic routing problem in local area . Can reduce binding overhead especially for mobile networks Disadvantages: . Address partition required between mobile and fixed addresses . Location Service required 4 References [1] Lou Dellaverson et al., "Proposed Charter, Work Plan and Schedule for a Wireless ATM Working Group", ATM Forum/96-0721/PLEN, June 10-14, 1996. [2] A. Acharya, J. Li, and D. Raychaudhuri, "Mapping of contribution 96-1121 ('Primitives for Location Management and Handoff in Mobile ATM Networks') to WATM baseline text", ATM Forum/96-1417/WATM, August 1996. [3] Arun Ayyagari, Jeff Harrang, Sankar Ray, "Call Establishment/Termination in Wireless PNNI", ATM Forum/96-1410/WATM, October 1996 [4] M. Veeraraghavan, G. Dommety, "Location Management in Wireless ATM Networks", ATM Forum/96-1500/WATM, October 1996 [5] John Porter et al., "The ORL Radio ATM System, Architecture and Implementation", Olivetti Research Technical Report 96.5, January, 1996. [6] The ATM Forum Technical Committee, "ATM User-Network Interface (UNI) Signalling Specification Version 4.0", af-sig-0061.000, June 1996. [7] C. Perkins (editor), "IP Mobility Support", RFC 2002, October 1996. [8] The ATM Forum Technical Committee, "ATM Name System Specification Version 1.0", af-saa-0069.000, September 1996. ATM Forum Technical Committee ATM Forum/96-1699/WATM 1