Mobile IP Working Group John Z. Wang Almon Tang Internet Draft Motorola Document: draft-wang-mobileip-umip-00.txt March 2000 Category: Internet Draft Universal Mobile IP (UMIP) Location Management Status of this Memo This document is a submission by the mobile-ip Working Group of the Internet Engineering Task Force (IETF). Comments should be submitted to the MOBILE-IP@STANDARDS.NOTELNETWORKS.COM mailing list. Distribution of this memo is unlimited. This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [1]. 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 and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. 1. Abstract Global roaming is one of the design objectives for next generation (3G) cellular networks. To efficiently support real-time applications for mobile users in these networks, signaling and payload traffic delays must be minimal. It has been identified that one of the sources causing long delays is triangle routing. That is, for example, in the registration process the registration requests have to be transmitted from a foreign agent in the visited network all the way to the home network every time the mobile node initiates a call or when the mobile node roams into a different visiting network [2]. Universal Mobile IP (UMIP) proposes to eliminate triangle routing in both signaling and payload traffic through a distributed hierarchical architecture in both the mobile's visiting domain and its home domain. In this document focuses are on the issues Wang, Tang Internet Draft-Expires August 2000 1 UMIP March 2000 associated with the registration process. Other UMIP issues such as call connection will be addressed in a separate contribution. In UMIP, a set of location registration (LR) nodes are designed to handle mobile registration locally. When the mobile node registers with the home network from a foreign network, a location chain is established through these nodes. The information needed for the mobile node to access the network such as user profile, security data and billing information, is distributed to these nodes from the home network. When the mobile node roams into a different visiting network or returns to its home network, the nearby location registration nodes then process the mobile registration and update the location chain accordingly. UMIP is backward compatible with Mobile IP RFC2002. The Regional Tunnel Management with a hierarchical Foreign Agent architecture [1] is a special case of UMIP. 2. Conventions used in this document Bluetooth Bluetooth is the codename for a technology specification for small form factor, low-cost, short range radio links between mobile PCs,mobile phones and other portable devices. The Bluetooth Special Interest Group is an industry group consisting of leaders in the telecommunications and computing industries that are driving development of the technology and bringing it to market. BRAN Broadband Radio Access Network BTS Base Transceiver Station CN Core IP-based Network Current ID The ID (NAI) of an LR to which the mobile node has successfully registered DECT Digital European Cordless Telephone DNS Domain Name Server FA Foreign Agent Wang, Tang September, 2000 2 UMIP March 2000 Foreign Domain The coverage area that is outside the Home Domain from which the mobile node subscribes network services HA Home Agent Home ID The ID (NAI) of the mobile node assigned by its home LR from which the MN subscribes network services. Home Network The coverage area of the home LR from which an MN subscribes network services Home Domain The entire area covered by the top layer LR that includes the home sub-tree where the mobile node subscribes network services IrDA Infrared Data Association Location Chain A sequence of location pointers at LRs forming a routing path between MN's current LR and its home LR Location Pointer IP address of an LR to which outbound packets are forwarded for a mobile user LR Location Registration or Location Register, a network entity in the IP network to handle mobility management MIN Mobile Node Identification Number MN Mobile Node NAI Network Access Identifier NE Network Entity including LR, RNN. New ID The ID (NAI) of the LR which a mobile user newly discovered and to which Universal Registration Request messages are sent PDSN Packet Data Service Node Wang, Tang September, 2000 3 UMIP March 2000 RAN Radio Access Network RNN Radio Network Node for voice / data applications RNS Radio Network Subsystem UMIP Universal Mobile IP VHE Virtual Home Environment 3. Introduction The proposed Universal Mobile IP (UMIP) technology is designed for next generation (3G) cellular networks. It is intended to offer integrated mobility services, with global coverage, to multiple heterogeneous Radio Access Networks for real-time and non-real time applications. The proposed technology adds features to, and is backward compatible with, the Mobile IP standard specified in RFC2002 [2]. The Regional Tunnel Management [1] is a special case of UMIP. In a Mobile IP network as specified in RFC2002, a home agent serves as both a centralized location registry and as a tunneling endpoint, such that all packets destined to a mobile node must be routed to its home agent and then encapsulated and forwarded to the corresponding foreign agent. This scenario is commonly called triangle routing (tromboning) which does not make efficient use of network resources and is one of the sources causing registration delays. The Regional Tunnel Management introduced a hierarchical Foreign Agent architecture to the IP network to remove triangle routing for the registration signaling. There are several issues when adopting Regional Tunnel Management to the 3G cellular networks. They are: Inhomogeneous system architectures in Home and Foreign domains. Triangle routing in call connection. Unable to support personal (compared with device) mobility. Undefined de-registration process for mobility management. Requiring heavy involvement of MN in the registration process. The proposed UMIP technology is to distribute location registry in a homogeneous hierarchical architecture. The goal is to reduce the time required for call setup and payload routing by replacing the triangle routing bottleneck with a homogeneous hierarchical system architecture. The optimization of payload routing will be addressed Wang, Tang September, 2000 4 UMIP March 2000 in a separate document. In this draft, only the UMIP registration process is discussed. 3.1 Major characteristics of the UMIP technology Major characteristics of the proposed UMIP technology compared with the existing IP solutions are as follows. The proposed solution 1. Offers a fully distributed mobility management solution to establish connectivity for both signaling and traffic without triangle routing (tromboning). 2. Is specially designed to enable 3G real-time applications with global coverage. 3. Offers a potential solution for personal (compared with device) mobility management by implementing Mobile User Identifier (e.g., Network Access Identifier (NAI) [17]) as the personal identity and use it as the key index in the tracing process. 4. Offers a fully distributed solution for mapping from logical name (NAI) to routable IP address. Compared with DNS (Domain Name Service) solution, it incurs no triangle routing (tromboning) in obtaining the mapping. 5. Offers an integrated solution for heterogeneous access technologies to provide seamless mobility services. 6. Pushes down the mobility management NNI (Network-Network Interface) to the CN-RAN (Core Network-Radio Access Network) interface that maximizes CN re-use and information sharing. This is a solution whereby a single IP Core Network is capable of supporting any access technologies. 7. Features a homogeneous system architecture in which the hierarchical structure can be adopted in both Foreign and Home domains. In this regard, the Regional Tunnel Management [1] is a special case of UMIP where the Home domain is reduced to a single node. 8. Offers a Core Network (CN) Architecture that is transparent to the mobile node. In this case, the mobile node (MN) is no longer bothered by CN architecture details in its registration process such as to distinguish between regional registration and registration with the home network. The benefits include more efficient use of the radio spectrum, lower complexity, less power consumption and reduced cost of the MN. 9. Is software configurable. The LRs (Location Registers) above layer one in Figure 2 share the identical interface and state machine in signaling processing and therefore, the same hardware could be placed anywhere in the hierarchy with software configuration. Only software changes are required when the logical hierarchical structure (number of layers, number of children nodes, etc.) needs to be re-configured. 10. Is consistent with the concepts of VHE (Virtual Home Environment), Dynamic DNS, Dynamic Home Agent assignment, Regional Tunnel Management, micro mobility management, and route optimization. Wang, Tang September, 2000 5 UMIP March 2000 The proposed UMIP is based on IPv4. IPv6 version will be addressed in the future. 4. System Architecture A simplified 3G wireless network architecture is shown in Figure1[15][16]. There are two separate network segments in the architecture. The first segment is the Radio Access Network (RAN) that includes the Radio Network Node (RNN), which is associated with a coverage area such as zone, paging area or routing area. The second segment of the system is the Core Network (CN) which offers an integrated mobility solution among other functions to all the underlying heterogeneous RANs. | Radio Access Network(RAN) -- > | < -- Core Network(CN) | MN ------------- RNN --------------|---------PDSN ----- MN ------------- RNS --------------|---------SGSN ----- | | Figure 1. 3G wireless network architecture. Figure 2 shows a UMIP system architecture with four layers of Location Registers (LRs). The RNN is the lowest layer LR (i.e., L1 L4 LR ------------------------ LR / \ / \ L3 LR LR LR LR / \ / \ / \ / \ / \ / \ / \ / \ L2 LR LR LR LR CN LR LR LR LR /___\_ _ /__\ / \ M-interface / \ L1 LR RAN LR /_ / _ - - / / MN MN Figure 2. The UMIP hierarchical system architecture LR) in the hierarchy. The layer of the LR in the hierarchy is identified by either a unique NAI or an IP address. Different Wang, Tang September, 2000 6 UMIP March 2000 wireless systems may have their own network entities that are equivalent to the RNN. For example, the Radio Network Subsystem (RNS) is an equivalent entity in a GPRS network [16]. The RNN is responsible for both voice and / or data applications. Each RNN is identified by a single location ID and is shared by multiple Base Transceiver Stations (BTSs) under its control. It is assumed that the RNN has a link layer connection (e.g., common control channels or the equivalent) with the Mobile Node (MN). The RAN is responsible for all the radio access and micro mobility management (if any) issues. The core network MAY support multiple radio access technologies such as WCDMA, CDMA2000, GSM, IS-95, DECT, BRAN (Broadband Radio Access Network), BLUETOOTH, IrDA, and other future technologies. For example, a CDMA customer may want to talk directly to a GSM cellular user by simply dialing the called party ID. The proposed solution is able to locate the called party with the help of the distributed LR database and make an appropriate connection to the called party. As a by-product of UMIP, the Network-Network Interface (NNI) is pushed down to the RAN-CN interface that should maximize CN reuse and system integration for mobility management. The RAN-CN interface for mobility management is marked as "M-interface" in Figure 2. No matter what technology is implemented for the RAN, the RAN-CN interface MUST be IP based. The mobility management is implemented in LRs (Location Registers). In addition to serving as foreign agent and replying to registration requests for home agent, they maintain and update the mobility database. The LRs are organized in a multiple-layered architecture (The maximum layer I equals 4 in Figure 2.). The layer index is assigned in an increasing order from bottom to top of the architecture. The number of layers in different sub-trees (domains) MAY not necessarily be identical. Each LR may have zero or multiple child LRs in the next lower layer. Each LR may have zero (called root LR) or one immediate parent LR. All the root LRs are assumed to be able to communicate with each other to form a location chain cross multiple domains. Each LR is associated with a logical coverage area. The total coverage area of a lower layer LR MUST be a proper sub-set of that of its parent LR. In other words, the logical boundary of a higher layer LR MUST not cross any boundaries of its offspring LRs. The behavior of each LR may be different depending on the layer at which it is located. Only those LRs that have a direct (wired or wireless) interface to a MN need to advertise their presence to MNs. It should be noted that an LR at a given layer can have subtending child LRs and an interface to MNs. The root LR in a hierarchy can interface with the root nodes in other hierarchies. 4.1 Identifiers for Location Registration Wang, Tang September, 2000 7 UMIP March 2000 In addition to their IP addresses, all the functional entities, LRs and MNs, are identified by their globally unique identifiers. NAI (Network Access Identifier) [5] is a potential candidate for such an identifier. Without losing generality, we will use NAI as our selected identifier in this draft. To have an efficient system solution, the assignment of NAIs MUST follow the following rules: The mobile user is identified by his / her NAI. This offers an opportunity to support Personal Mobility in UMIP. The NAIs, rather than the IP addresses, of the bottom layer LRs are used as the Current, New, or Home location identifiers for the mobile nodes. The NAIs of the LRs SHOULD be assigned in a way that by comparing the mobile user's Current, New, or Home identifiers, the LR at any layer should be able to make routing decisions. Complete specification of the NAI assignment is outside the scope of this document. One way of doing this is to assign a shorter NAI for a higher layer entity and the assigned NAI is a postfix of the NAI assigned to its child entity of a lower layer. For example, a Layer 1 LR may have an NAI as "123.Arlington_Heights.Chicago.Il_US@abc." A Layer 2 LR may have an NAI as "Arlington_Heights.Chicago.IL_US@abc.". A Layer 3 LR may have an NAI as "Chicago.IL_US@abc.". A Layer 4 LR may have an NAI as "IL_US@abc.". And a mobile user registered with the Layer 1 LR may have an NAI as "4567.123.Arlington_Heights.Chicago.IL_US@abc.". It should be noted that the NAI [5] is defined in such a flexible way that an all-numeric numbering (such as a telephone number) is a legal NAI. For example, 18471234567 is a legal NAI. As a matter of fact, all existing IP, IMSI, and MIN addressing schemes could also be treated as a legitimate NAI. The NAIs of all the network entities, including LRs and mobile users, are re-assignable for scalability considerations. The proposed solution also works for mobile users with a permanently assigned NAI. The efficiency in assigning NAI is an issue of implementation. UMIP supports both pre-assigned and re-assigned NAIs. 4.2 Location Registration Table In each of the LR, there is an LR table to store MN location information for mobility management, as shown in Figure 3. Under the following conditions, there MUST be an entry created and maintained in the LR table for a mobile user: The mobile user is outside its registered home network and The LR is on the location chain. The location chain begins at the mobile user's bottom layer LR in its Home Domain and ends at the bottom layer LR in its visited Foreign Domain. Wang, Tang September, 2000 8 UMIP March 2000 Note that there is no entry for mobile nodes which are power on and at home network. In UMIP, when no entry is found in the LR table, the mobile node is assumed to be at its home network. There MUST be at least five entities in the LR table. They are keyed index, pointer, status of pointer, lifetime, and replay protection. Each of them is described in the following. Keyed Index The first column of the LR table is the keyed index, which is the mobile user's home NAI. It is used by the LR to look up mobile information to process registration and location updates. There must be a mechanism in the proposed solution to map from a mobile user's identification (NAI) to a routable IP address. The mapping function is performed at LR. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Key Index | Pointer | Status | Lifetime | Replay Protection | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3. The LR Table Location Pointer The second column is a location pointer of the mobile user. A location pointer for a mobile user is an IP address of an LR to which the LR will forward outbound packets for that mobile user. Location Pointer Status The third column is the status of the location pointer for the mobile user. There are possibly three types of status. They are pending, active and forwarding. An entry for a mobile user is marked as "pending" after an LR receiving a Universal Registration Request initiated by the mobile user and before receiving a positive Reply (authenticated). An entry is marked by the LR as "active" after a positive Universal Registration Reply associated with the mobile user has been received. An entry is marked by the LR as "forwarding" after a validated de-registration message with a forwarding address is received before the associated forwarding lifetime is expired. Lifetime The fourth column of the LR table is lifetime. All three types of pointer status in the LR table MUST be associated with lifetime Wang, Tang September, 2000 9 UMIP March 2000 (time in seconds). The lifetime assigned to an entry with "forwarding" status SHOULD be reasonably small to prevent a large amount of entries accumulated in the LR table. UMIP MUST implement LifeTime Update to request extending the lifetime of the MN's binding information. The LifeTime Update Request process may be initiated by a MN or any LR on the MN's location chainon mobile user's behalf. To support lifetime update before the lifetime expires, LifeTime Update Request message generated by an MN or LR MUST be directed on the path leading to the Home network of the mobile user. An LR MUST NOT make any decision based on expired location information. Replay Protection The fifth column is the style of replay protection in use. If a received Universal Registration Request contains a Replay Protection extension requiring a style of replay protection not supported by the LR, the LR MUST reject the Universal Registration Request and send a Universal Registration Reply with the value in the Code field set to UNSUPPORTED_REPLAY_PROTECTION. The replay protection for the regular Mobile IP registration and Regional Registrations is described in [2] and will be implemented in the Universal Mobile IP (UMIP). Since the MN may perform Universal Registrations in parallel with regular registrations at its home network, the MN MUST keep one replay protection mechanism and sequence for the LR and a separate mechanism and sequence for the HA. When using nonces for replay protection, the identification field in the Universal Registration Request / Reply messages is used. The sender of the message is required to set the high-order 32 bits of the identification field to the value of the nonces that will be used by the LR in the next Universal Registration Request / Reply message sent to this LR node. The low-order 32 bits of the identification field are required to be set to the value of the nonces being used for this message. Thus, in each message, the LR communicates to the target LR the value of the nonces that will be used next time. If no messages are lost in the network, the LR and the target LR can remain synchronized with respect to the nonces being used. If, however, the target LR receives a message with what it believes to be an incorrect nonce, it may resynchronize with the LR by using a Universal Registration Request. Example L4 LR1 ----------------------- LR2 / \ / \ L3 LR11 LR12 LR21 LR22 Wang, Tang September, 2000 10 UMIP March 2000 / \ / \ / \ / \ / \ / \ / \ / \ L2 LR111 LR112 LR121 LR122 CN LR211 LR212 LR221 LR222 / \ / \ / \ / \ L1 LR1111 LR1121 (H) RAN LR2121 LR2122 (C) /_ /_ - - / / MN MN Figure 4. An example of the location chain For example, as shown in Figure 4, if the current location of MN is LR 2122 there may be a location chain setup from LR1121 (Home network) to LR112, then to LR11, LR1, LR2, LR21, LR212 and finally to LR2122. A Layer i LR MUST maintain location information for at least the following three types of mobile users. (1) Visitor: a mobile user who subscribes its service outside the coverage area of the LR and is roaming within the coverage area of the questioned LR. (2) Native Local Roamer: a mobile user who subscribes its service within the coverage area of the LR but is currently located within a different Layer i-1 coverage area than that where it subscribes its service. (3) Native Traveler: a mobile user that subscribes its service inside the coverage area and roaming outside the coverage area of the questioned Layer i LR. As indicated in Figure 4, suppose a mobile user subscribes its service with LR1121, it is a Visitor for LR2122, LR212, LR21 and LR2 if it registers with LR2122. It is a Native local roamer for LR11 if it registers with LR1111. It is a Native Traveler for LR 1121, LR112, LR11 and LR1 if it registers with any LR with a root other than LR1. There exists an efficient solution [13] on this minimal amount of mobile user location information. As specified in [13], as long as a mobile user stays within its Layer i-1 home domain, there is no location information needed in the Layer i home domain LR for that mobile user. Considering the localized mobility behavior of the mobile users, the memory size, searching delay, and accordingly the complexity and cost of the LR is thus greatly reduced. 4.3 Agent Advertisement To support heterogeneous RAN technologies in the proposed solution, Agent Advertisement MUST be able to be implemented on multiple access technology and multiple layers of the hierarchical structure. For example, a cellular routing area may be associated with a Layer Wang, Tang September, 2000 11 UMIP March 2000 1 network entities and a satellite cell may be associated with a Layer 2 LR. Etc. The Layer i (e.g. i = 1) network entity MUST announce its presence via an Agent Advertisement message for application J (e.g. cellular) mobile users where the lowest coverage area of application J is associated with the Layer i coverage area. There MUST be an "RT" flag in the Agent Advertisement message to distinguish whether the Regional Tunnel management is supported by the local system. The flag is inserted in one of the reserved fields, after the flags defined in [2] if IP protocol is used over the air. Another Flag is "IR" indicating whether the Intelligent Routing [8] is supported. The Global Challenge MUST be included regularly in the Agent Advertisement message for security considerations if it is implemented by the system. The Layer i LR IP address (care-of address) and its NAI is advertised in the Agent Advertisement message. If IP is used over the air, the LR NAI extension MUST appear in the Agent Advertisement message after any of the advertisement extensions defined in [2]. By comparing the domain parts of the LR NAI the mobile node can determine whether it is in a location region different from what it has registered. Different coverage regions of different layers can also be determined in a similar way. There MAY be multiple care-of addresses and NAIs in the Agent Advertisement message. The first care-of address and NAI MUST be those for the Layer i LR. 4.3.1 The Mobility Management Agent Advertisement Extension The Mobility Agent Advertisement Extension follows the ICMP Router Advertisement fields. It is used to indicate that an ICMP Router Advertisement message is also an Agent Advertisement being sent by a Location Register. The Mobility Agent Advertisement Extension is defined as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Registration Lifetime |R|B|H|F|M|G|V|RT|IR| reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | zero or more Care-of Addresses | | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Extensions | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Wang, Tang September, 2000 12 UMIP March 2000 Figure 5. The Mobility Management Advertisement Extension Type TBD Length (6 + 4*N), where N is the number of care-of addresses advertised. Sequence Number The count of Agent Advertisement messages sent since the agent was initialized. Registration Lifetime The longest lifetime (measured in seconds) that this agent is willing to accept in any Registration Request. A value of 0xffff indicates infinity. This field has no relation to the "Lifetime" field within the ICMP Router Advertisement portion of the Agent Advertisement. R Registration required. Registration with this foreign agent (or another foreign agent on this link) is required even when using a co-located care-of address. Always be set to "1" if RT is set. B Busy. The foreign agent will not accept registrations from additional mobile nodes. H Home agent. This agent offers service as a home agent on the link on which this Agent Advertisement message is sent. Always be set to "1" when RT is set. F Foreign agent. This agent offers service as a foreign agent on the link on which this Agent Advertisement message is sent. Always be set to "1" when RT is set. M Minimal encapsulation. This agent implements receiving tunneled datagrams that use minimal encapsulation [12]. G GRE encapsulation. This agent implements receiving tunneled datagrams that use GRE encapsulation [10]. V Van Jacobson header compression. This agent supports use of Van Jacobson header compression [11] over the link with any registered mobile node. Wang, Tang September, 2000 13 UMIP March 2000 RT The flag is set when the system supports Regional Tunnel Management. IR The flag is set when the system supports Intelligent Routing. Reserved Reserved seven bits. Sent as zero; ignored on reception. Care-of Address(es) The advertised network entity care-of address(es) provided by this network entity. An Agent Advertisement MUST include at least one care-of address if the 'F' bit is set. The number of care-of addresses present is determined by the N fi e l d in the 4 Extension. Extensions The following extensions MAY be included: Authentication challenge extension: This extension MAY consist of one or more random numbers generated locally. Other extensions The bottom layer LR must continue to send Agent Advertisements, so that any mobile nodes already registered with it will know that they have not moved out of range of the region and that the network entity has not failed. A network entity may indicate that it is "too busy" to allow new mobile nodes to register with it, by setting the 'B' bit in its Agent Advertisements. An Agent Advertisement message MUST NOT have the 'B' bit set if the 'F' bit is not also set, and at least one of the 'F' bit and the 'H' bit MUST be set in any Agent Advertisement message sent. 4.3.2 LR NAI Extension The LR NAI extension is defined as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Subtype | LR NAI | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 6: Location Register NAI Extension Type TBD Sub-type New ID, Current ID, Hierarchical LR Wang, Tang September, 2000 14 UMIP March 2000 Length The length in bytes of the LR NAI field LR NAI A string in the NAI format defined in [5]. The advertising network entity MUST include its NAI in the Agent Advertisement Message to support UMIP. If present, the network entity NAI extension MUST appear in the Agent Advertisement message after any of the advertisement extensions defined in [2]. By comparing the domain part of the network entity's NAI with the domain part of its own NAI, the mobile node can determine whether it is in its home domain or in a visited domain, and whether it has changed domain since it last registered. 4.4 Registration The process and the messages that are required for implementing UMIP technology are described in this section. 4.4.1 Universal Registration Request Message The format of the Universal Registration Request messages is similar to that of the Regional Registration Request defined in MIP Regional Tunnel Management [1] and that of the Binding Update Message in Route Optimization in MIP [6]. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type |A|I|M|G|RT|Rs1 | Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Mobile Node Home Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Care-of Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Identification + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sub-type | Rs2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Extensions ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 7. Universal Registration Request message The format of the Universal Registration Request message is illustrated above, and contains the following fields: Wang, Tang September, 2000 15 UMIP March 2000 Type TBD A The 'A' (acknowledge) bit is set by the node sending the Binding Update message to request a Binding Acknowledge message be returned. I The 'I' (identification present) bit is set by the node sending the Binding Update message if the identification field is present in the message. M If the 'M' (minimal encapsulation) bit is set, datagrams may be tunneled to the mobile node using the minimal encapsulation protocol [12]. G If the 'G' (Generic Record Encapsulation, or GRE) bit is set, datagrams may be tunneled to the mobile node using GRE [10]. Wang, Tang September, 2000 16 UMIP March 2000 Lifetime The number of seconds remaining before the binding cache entry must be considered expired. A value of all ones indicates infinity. A value of zero indicates that no binding cache entry for the mobile node should be created and that any existing binding cache for the mobile node should be deleted. The lifetime is typically equal to the remaining lifetime of the mobile node's registration. Mobile Node Home Address The home IP address of the mobile node to which the Universal Registration message refers. Care-of Address The IP address of the newly discovered bottom layer LR. Identification If present, a 64-bit number, assigned by the node sending the Binding Request message, used to assist in matching requests with replies, and in protecting against replay attacks. Sub-type Eight-bit field for registration, de-registration, etc. RT 'RT' (Regional Tunnel) bit is set for Regional Tunneling Registration Request / Reply messages. Rs1 Reserved 3 bits. Sent as 0; ignored on reception. Rs2 Reserved 24 bits. Sent as 0; ignored on reception. Extensions The following extensions MUST be included in the Universal Registration Request messages: * ID and address extensions: Home ID (NAI), Current ID (NAI), IP address of Current ID. The following extensions MAY be included in the Universal Registration Request messages: * An MN-Foreign Authentication extension. * An Authentication Response extension: This extension MAY be the response to the Authentication Challenge received from the Agent Advertisement. * An Authentication Challenge extension: This extension MAY be the challenge of MN or LR(s). It MAY include one or more random numbers. Wang, Tang September, 2000 17 UMIP March 2000 * Other extensions: For details, please see p. 9 & 11 in [6]. As soon as a valid Universal Registration message is received at a Layer i LR at the bottom and above layer of the associated application, additional extensions will be added to the message. They are, not inclusive, NEW ADDRESS (NAI) is added at the bottom layer of the application. Hierarchical LR extensions (Layer i (above the bottom layer of the application) LR NAI and its IP address) MAY also be appended in the message for routing improvement considerations. The initial stored Layer i LR NAI (serves as Current ID) of an MN when its power on MUST be its own MN NAI. The MN may register a care-of address or any other local index adopted by the associated RAN with the LR. It is noted that the newly discovered Layer i LR may be its own Home LR (HA). Multiple IP addresses could be assigned to a mobile user, each for a different application. Extensions SHOULD be defined to carry the active application IP addresses in the combined Universal Registration Request message. Receiving a Multiple IP address extension from a Universal Registration Request the LR SHOULD store that information as part of the mobile user profile associated with the mobile node. The information SHOULD be accessible from the LR table of the LR. 4.4.2 IP Address Extension The IP Address extension is defined as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Subtype | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IP Addresses | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 8: IP Address Extension Type TBD Sub-type New ID, Current ID, Hierarchical LR address, Application IP address etc. Wang, Tang September, 2000 18 UMIP March 2000 Length 1+4n. n is the number of IP addresses in the extension. Reserved Reserved 8 bits, sent as zero, ignored on reception 4.4.3 Universal Registration Reply message The Universal Registration Reply message fields are shown as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Code | Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Home Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Identification | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Extensions ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 9. Universal Registration Reply message Type TBD Code A value indicating the result of the Universal Registration Request. See below for a list of currently defined Code values. Lifetime If the Code field indicates that the registration was accepted, the Lifetime field is set to the number of seconds remaining before the registration is considered expired. A value of zero indicates that the mobile node has been de-registered. A value of 0xffff indicates infinity. If the Code field indicates that the registration was denied, the contents of the Lifetime field are unspecified and MUST be ignored on reception. Home Address The IP address of the mobile node. Identification Wang, Tang September, 2000 19 UMIP March 2000 A 64-bit number used for matching Registration Requests with Registration Replies, and for protecting against replay attacks of registration messages. The value is based on the Identification field from the Registration Request message from the mobile node, and on the style of replay protection used in the security context. Wang, Tang September, 2000 20 UMIP March 2000 Extensions The following extensions MUST be included in Universal Registration Reply message: * Home NAI extension * Mobile-Home Authentication extension. The following extension MAY be included in Universal Registration Reply message: * User Profile extension * Authentication challenge extension: This extension MAY include one or more random numbers to be forwarded to either MN or LR(s) * Authentication response extension: This extension MAY include home response(s) to MN or LR(s) challenge(s) received from Universal Registration Request message. This extension MAY also include security parameters for use in subsequent access processing. * Billing information extension (TBD) * Other extensions. The following values are defined for use within the Code field [2]. Registration successful: 0 registration accepted 1 registration accepted, but simultaneous mobility bindings unsupported Registration denied by LR in the foreign domain: 64 reason unspecified 65 administratively prohibited 66 insufficient resources 67 mobile node failed authentication 68 home agent failed authentication 69 requested Lifetime too long 70 poorly formed Request 71 poorly formed Reply 72 requested encapsulation unavailable 73 requested Van Jacobson compression unavailable 74 invalid care-of address 75 registration timeout 80 home network unreachable (ICMP error received) 81 home agent host unreachable (ICMP error received) Wang, Tang September, 2000 21 UMIP March 2000 82 home agent port unreachable (ICMP error received) 88 home agent unreachable (other ICMP error received) Registration denied by LR in the home domain: 128 reason unspecified 129 administratively prohibited 130 insufficient resources 131 mobile node failed authentication 132 foreign agent failed authentication 133 registration Identification mismatch 134 poorly formed Request 135 too many simultaneous mobility bindings 136 unknown home agent address In addition, the following values are defined for UMIP Universal Registration: Registration denied by LR: TBD: requested replay protection unavailable TBD: unknown LR TBD: LR unreachable (ICMP error received) TBD: LR host unreachable (ICMP error received) TBD: LR port unreachable (ICMP error received) TBD: LR unreachable (other ICMP error received) 4.4.4 Registration Process MN Movement Detection The RAN can implement any MN movement detection mechanism adopted by the RAN system (e.g. as described in [2]). One preferred MN movement detection mechanism is described as follows. In UMIP, the MN needs no knowledge of the core network architecture and therefore, there is no need for this type of information to be transmitted regularly over the band limited wireless channels. All an MN is concerned about, from the registration perspective, is to monitor the NAI of the bottom layer LR's common control channel associated with an application. The movement detection uses the NAI of the LR that is sent on the common control channels or in the Agent Advertisement messages if IP is used over the air. The MN should lock to the identified LR , the details of the LR identification process is outside of the scope of this document, and keep track of LR NAI extensions from all the Advertisements received. If the received NAI should change, the mobile node MUST assume that it has moved. Suppose the MN of application J for a mobile user receives an Agent Advertisement from a Layer i (the lowest layer for application J) LR and discovers that it is in a new Layer i LR coverage area (paging area, routing area, and zone, etc.). The MN MUST initiate the registration process by sending a Universal Registration Request to the newly discovered Wang, Tang September, 2000 22 UMIP March 2000 Layer i LR if the Agent Advertisement indicates that it supports Universal Registration. To support user authentication with Global Challenge, a reply to the Global Challenge MUST be included as part of the Universal Registration Request message. Upon receipt of a validated Universal Registration Request, an LR MUST register the IP address of the network entity from which the Universal Registration Request was sent. Associated information MUST also be stored and indexed by the mobile user's NAI. This includes the mobile user's NAI, Status and Lifetime. The status is marked "pending." If the LR does not have the authentication information, it will relay the Universal Registration Request to the next LR, and may eventually reach the home LR, for authentication. The LR will authenticate the request if it contains all the security information. After successful authentication, the Status will be marked "active". A Registration Reply message may also be generated and sent along the location chain toward the mobile node. The Registration Reply message MAY also include other information such as user profile (to support VHE), security information (to support mobile user authentication) and billing information. Upon receipt of a Registration Reply message, the LR needs to validate the message and check if there is already an entry "pending". If the Reply indicates that the registration request is accepted, the Status of the mobile user will be marked "active". The LR MUST then forward the Reply message to the next LR following the existing location pointer. If the LR does not support UMIP, upon receipt of a Universal Registration Request message, it MUST deny the request. 4.4.5 Hierarchical LR Extension On the Registration update path, each LR, other than the bottom layer LR, MAY add a Hierarchical LR extension to the Registration message. This information may be used for the downstream LRs (according to the location update chain) to update their LR tables. It could also be used for further routing improvements. One or more Hierarchical LR Extensions MAY be present in a Universal Registration Request in the Core Network. When these extensions are added to a registration request by an LR, the receiving LR sets up a pending registration record for the mobile user, using the IP address of the LR from which the Universal Registration Request is received as the location pointer for the mobile user. Furthermore, a new extension is created and the extension MUST be appended at the end of all the extensions that had been included by its upstream LRs as part of its registration message. If multiple Hierarchical LR Extension is not implemented, a receiving LR will replace the Hierarchical LR extension with one carrying its own information. Wang, Tang September, 2000 23 UMIP March 2000 The Hierarchical LR Extension SHOULD only be added on its upward update path (from layer i to layer i+1). The extension of a higher layer SHOULD be appended after that of a lower layer if multiple Hierarchical LR Extension is implemented. The Hierarchical LR Extension is defined as that specified in [1] with following modifications. The Hierarchical LR Extension fields are shown as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Layer Index | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LR IP Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LR NAI | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 10. Hierarchical LR Extension Type TBD Length Specifies the length including NAI field Layer index The layer number of the LR LR IP Address The IP address of the LR relaying the Universal Registration Request LR NAI The NAI of the LR relaying the Universal Registration Request Collectively, the LR network MUST be able to set up a location chain for any of the mobile users that are outside their registered networks (HA). The location chain MUST begin at the bottom layer Home LR and end at the current location of the mobile user. All the pointers of the location chain are routable IP addresses. Each link of the location chain MAY point to its next higher layer, a next lower layer LR (or another network entity) of the same domain (sub- tree) or point to a root LR of a different domain if the LR is a root LR itself. A pointer MAY also point to any other LR (or network entity) for efficiency considerations. A timer is set whenever a Universal Registration Request message is sent. A retry or a Registration Failure (after N>=0 failed retries) Wang, Tang September, 2000 24 UMIP March 2000 message is sent to the appropriate party only when the timer expires. A fully distributed implementation It is highly desirable to have a fully distributed location update process in such a system dealing with global mobility management and real time applications. As soon as a Location Register receives a Universal Registration Request it will make a decision on whether it is the last hop of the journey. If it is not it will decide the next hop for the Universal Registration message. All mobility management message routing decisions SHOULD be made based on the identities (NAI) of the mobile user, previous LR and current LR. One fully distributed solution that meets the specifications described in this document can be found in [13]. In the reference a hierarchical and fully distributed system architecture is presented. The detailed state machine for individual LR to support UMIP is specified. 4.4.6 De-registration There SHOULD be no direct involvement of a mobile node in the de- registration process. The de-registration process SHOULD be part of the location update process that is mobile user initiated and is carried out by the collective efforts of the LR network. All the LRs that were on the location chain associated with the MN's current location of a mobile user and are no longer on the location chain associated with the mobile node's new location SHOULD be informed by a Location Cancellation message and the database be updated accordingly. After validating the received Location Cancellation message, any LR MAY update its associated data entry indicating the new location (IP address) of the mobile user with a status "forwarding". The forwarding pointer may help, for instance, to forward the undelivered packets of the roaming mobile user to its new location. The forwarding pointer is valid before its Lifetime expires. After Lifetime has expired, the associated entry will be removed from the LR's database. At this point, all the information of the mobile user such as the user secret data, user profile, etc. SHOULD also be removed from the LR's database. Suppose that a mobile subscriber has been assigned to LR 1121 as its registered Home address (NAI), as shown in Figure 4. If the mobile node remains within the coverage of LR 1121, there will be no location information in the LR hierarchy since by default the mobile user is assumed at home if there is no location information is available at any LR. Wang, Tang September, 2000 25 UMIP March 2000 Next suppose that a mobile node attempts to register within the coverage area of LR2122. A location chain will be set up beginning from its home LR and ending at LR2122. There are several potential ways to set up the location chain. One possible way is as follows. A pointer contains the IP address of next upper layer LR in each of the LRs (except the top layer) in the mobile user's Home domain. For example, a pointer exists in LR 1121 pointing to LR112, etc. At the top layer LR of the mobile user's home domain there is a pointer pointing to the root node of the visiting domain (LR 2). In each of the LRs of the mobile user's Foreign domain, a location pointer exists pointing to the next lower layer LR where the mobile user is located. For example, a pointer at LR 2 indicates that LR 21 is the next hop of the associated location chain. The LR 21 has a pointer pointing to LR 212. The LR 212 has a pointer pointing to LR 2122 and the latter has a link layer connection (e.g. on common control channel or the equivalent) to the MN. Another approach is to bypass some of the LRs in the hierarchy. For example, the pointers of the associated LRs on the MN's home branch (e.g. LR 112, LR 11 and LR 1) can be the IP address of the root node LR 2 of the Foreign domain to reduce the hop count. Now when an MN moves to a different location area after it has registered successfully, for example, its has registered with LR 2122 and now moves to the coverage area of LR 2121. The registration message doesn't have to go all the way back to LR 1121, practically it may be half world away. The only change needed is update the associated pointer in LR 212, LR 2122 and setup a new pointer in LR 2121. All these updates are performed locally. Since the location information is locally available in the LRs of both the Home and Foreign domain of a mobile user and statistically, most of the traffic (both inbound and outbound) is generated in these domains, the time delay and the associated time jitter is thus greatly reduced. For example, a call to an MN, with Home LR 1121 and currently registered at LR 2122, is generated in the coverage area of LR 2121 will find the called party's location by accessing LR 2121, LR 212 and LR 2122 locally. 4.5 Location Update Acknowledgement and Security considerations 4.5.1 Assumptions It is possible that the communication system is owned by multiple entities. There are possibly two categories of neighboring LRs. The first type of LRs are those that share the same operational authority. In this case, they MAY share the same secret data. Wang, Tang September, 2000 26 UMIP March 2000 The second type of LRs are those that are under a different operational authority. There must be a way of security key management to support setting up security association among these LRs. It is assumed that security associations have been setup and be able to work properly between domains (collection) of LRs from different operators. It is assumed that the security associations already set up between the LRs. It is also assumed that the LRs from different domains must be compatible, that is, they MUST support at least one common type of encapsulation, compression mechanisms, etc.. It should be noted that the security association is setup on an operator to operator basis rather than on a call to call basis. 4.5.2 Process An MN-HA Authentication extension MUST be included as part of a Universal Registration Request when an MN performs a Universal Registration. Receiving a Universal Registration Request, an LR will confirm the validity of the MN if there is a local copy of MN associated security data. It will update its location database accordingly and acknowledge the location update to its upstream (according to the location update chain) network entity if the mobile user is locally authenticated. Otherwise, it will reject the request (by ignoring the request or sending a NACK) if there is a local copy of the MN associated security data and the authentication fails. If there is no such security data locally available the LR will relay the registration message to the next hop along the path to the mobile user's Home network asking for authentication. In the mean time the newly updated location pointer will be marked as in a pending stage with a limited lifetime until a positive reply is received from the downstream (according to the location update chain) LR. If the associated lifetime expires or a negative reply is received for the pending information for the mobile user the associated registration request is rejected and the associated data discarded. If a positive reply is received before the associated lifetime expires, the associated location information will be upgraded from "pending" to "active" state and an acknowledgement message MUST be sent to its upstream (according to the location update chain) network entity. The authentication among LRs are implemented with the help of Authentication extensions. It shares the same format and default algorithm support requirements as the three authentication extensions defined for base Mobile IP [2], but is distinguished by its type. The authenticator value is computed, as defined in [2], from the stream of bytes including the shared secret, the UDP payload (that is, the Universal Registration Request or Reply message), all prior extensions in their entirety, and the type and length of this extension, but not including the authenticator field itself nor the UDP header. This extension is required to be used in any Universal Registration Request and Reply messages. Wang, Tang September, 2000 27 UMIP March 2000 The LR that processes the location update successfully generates a Universal Registration Reply only in two conditions. The first condition is when the LR is the ending point of a forward location update process. One such example is when it is the bottom layer LR in the Home domain of the mobile user. Another example is when it is the LR that is knowledgeable of the security data of the mobile user and there is no need to further propagate the location update message in the system. The second condition to generate a Universal Registration Reply is when an LR receives a Universal Registration Reply for a pending mobile user from its downstream LR. The Universal Registration Reply will be relayed to the upstream (according to the location update chain) network entity. Generating a Universal Registration Reply message, a downstream (according to the mobile user's location updating chain) LR MUST direct the message to the next upstream LR IP address that is available from the Hierarchical LR extension or the New Address extension of the previously received Universal Registration Request message and was recorded as a pending location pointer in the LR table. The LR that initiates Universal Registration Reply distributes appropriate security data (e.g. registration key or Challenge-Reply vectors) to the associated LRs. For instance the LR may use a Mobile User Key Reply extension (similar to the Home-Mobile key Reply extension and Foreign Agent Key Reply Extension [6]), added to the Universal Registration Reply message, or it may use other AAA functions [7]. User profile extension (TBD) and Billing information extension (TBD) MAY also be included as part of the Universal Registration Reply message. Distribution of security data and user profile information makes it locally available to the visited network which in turn reduces the time delay and the associated time jitter incurred by triangle routing (tromboning) in the process of authentication,service provisioning and other system management functions. In case that the Mobile-Foreign LR Authentication extension is present in a Universal Registration Request message, the LR in the foreign domain will perform the authentication. Similarly, if a Foreign-Home Authentication extension is present in a Universal Registration Request message, the authentication is performed between the LRs of the visited and home domains. If everything works fine, all the network entities that sent out a Universal Registration Request message MUST receive one and only one Universal Registration Reply. When an LR generates or receives a Universal Registration Reply, it performs a memory look up function to determine where to relay this message. The bottom layer LR in the visited network MUST send a Universal Registration Reply to the associated MN when a successful Wang, Tang September, 2000 28 UMIP March 2000 Universal Registration Reply is received from its downstream (according to the associated location chain) LR. It is noted that the Universal Registration Request / Reply messages may need to be re-coded on some of the legs on the location update chain due to encryption and security considerations. If, for instance, the Mobile User Key Reply extension is present, the LR that receives the Universal Registration Reply decrypts the security data. It MAY (when necessary) then add, for instance, a new Mobile User Key Reply extension to the Universal Registration Reply message, before relaying it to the next LR. The new Mobile User Key Reply extension contains the security data, encrypted with a secret shared between the LR and the next hop LR in the hierarchy. This Universal Registration Reply relaying process is repeated in every participating LR in the hierarchy, until the message reaches the bottom layer LR where the mobile user is located. When the bottom layer LR receives the Universal Registration Reply, it performs a memory look up function, as described in [2], and relays the reply to the mobile node. The existing IP encryption technologies are proposed to carry the security data. The existing IP authentication technologies (AAA and security extensions) are proposed to support the LR authentication processes. The security extensions are part of Universal Registration Request and Universal Registration Reply messages. For example, when an LR receives a Universal Registration Request from another LR it is required to verify the authentication extension in the message, using the mobility security association it shares with the sending LR. The authentication extension is required for Universal Registration messages. If the authentication succeeds, then the location database is updated accordingly. Otherwise, an authentication exception should be raised. Each mobile user location update triggered by a Universal Registration Request is associated with a maximum lifetime. When sending the Universal Registration Request message, the associated LRs should set this lifetime to the remaining registration lifetime. Each following location update for the same mobile user SHOULD refresh the lifetime. Since there is an effective de-registration process, the Lifetime parameter SHOULD be set to a reasonably big value for network bandwidth efficiency considerations. Further details on the lifetime management are outside the scope of this document. 4.6 UMIP Billing Billing functionality is usually partitioned between usage creation (tier 1), usage aggregation (tier 2), and invoicing (tier 3). In UMIP, usage creation and aggregation are combined in the UMIP system. The combined function is distributed in the LRs in layer i (i=1 for the RAN, corresponds to L1 in Fig. 4, or i=2 in the CN, Wang, Tang September, 2000 29 UMIP March 2000 corresponds to L2 in Fig. 4). The network operator can decide whether this combined billing functionality is in the RAN or the CN. In addition to basic subscriber and services information, each LR on the location chain of layer i will contain subscriber billing information that is usually kept in a billing invoicing system (tier 3). For example, the LR will contain information about allowed time of day access, different level of service to be provided and credit/prepaid status. Since the bearer paths flow through the LRs, the LR records the traffic generated associated with a subscriber. Subscriber traffic information, in addition to the subscriber billing information kept in the LR, will allow the LR to create the CDRs (Call Detail Records) and forward these to the billing invoicing system that generates the user invoices. The billing invoicing system contains information that is needed to generate the invoice, e.g., name, address, credit card number, billing address and phone number. When a subscriber is in a visited network, the visited billing invoicing system will collect the subscriber's CDRs and forward these to the subscriber's home billing invoicing system. This distributed billing scheme does not require centralized billing mediation devices that collect usage information from all network elements, since usage will be determined at the source LR (e.g., LR1121 or LR 112 in Fig. 4). In addition, a network operator will not have to deploy separate 'prepaid servers' since the prepayment status information is also available at the source LR. Fewer communication resources will be spent on sending subscriber usage data in the network, and the result will be that more bandwidth is available for user traffic. Billing data updates The subscriber billing information in a visited LR is distributed to the LR together with the Registration Reply message. Conversely, if subscriber billing data is updated in the home network's LR (e.g., a change in the levels of service provided), it will be forwarded to the current LR where the subscriber is registered. Real-time billing information access The subscriber can access his billing information stored in the local LR where he is currently registered. The information available includes levels of service allowed, and prepaid status. This local access allows the subscriber to check in real-time his billing status. A description of this extension will be provided in a later version of this draft. Wang, Tang September, 2000 30 UMIP March 2000 5. Future Work The mobile user service profile specifies the service type and level to which the mobile user has subscribed. Similar to the call barring service the proposed solution is able to offer the mobile user a selective mobility tracing service that defines the regions that the mobile user is willing to be reached (traced). The selective mobility tracing service can be supported in the UMIP Mobility Management and will be supported by a later version of the draft. Other improvements such as a shortcut of the hierarchical location chain, the power-down and out-of-coverage de-registration and power- on and re-enter-coverage-area registration, details of the LifeTime Update Request process, and extending UMIP to IPv6 will be discussed in the future. 6. Acknowledgment Thanks to many colleagues at Motorola who have contributed to this draft. 7. References [1] E. Gustafsson, A Jonsson, and C. Perkins, "Mobile IP Regional Tunnel Management", draft-ietf-mobileip-reg-tunnel-01.txt, August 1999. [2] C. Perkins, Editor, "IP Mobility Support for IPv4, revised", draft-ietf-mobileip-rfc2002-bis-01.txt, January 2000. [3] ITU-T Rec. Q.1711, "Network functional Model for IMT-2000", March 1999. [4] P. Calhoun and C. Perkins, "DIAMETER Mobility IP Extensions", draft-calhoun-diameter-mobileip-02.txt, August 1999 [5] B. Aboba and M. Beadles, "The Network Access Identifier", RFC 2486, January 1999 [6] C. Perkins and D. Johnson, "Route Optimization in Mobile-IP", draft-ietf-mobileip-optim-08.txt, February 1999 [7] C. Perkins and P. Calhoun, "AAA Registration Keys for Mobile IP", draft-ietf-mobileip-aaa-key-00.txt, June 1999 [8] J. Wang, "Intelligent Routing in Universal Mobile IP", work in process. [9] H. Lrawczyk, et. al., "HMAC: Keyed-Hashing for Message Authentication", RFC 2104,. February 1997. Wang, Tang September, 2000 31 UMIP March 2000 [10] Stan Hanks, Tony Li, Dino Farinacci, and Paul Traina, "Generic Routing Encapsulation (GRE)", RFC 1701, October 1994. [11] Van Jacobson, "Compressing TCP/IP Headers for Low-Speed Serial Links", RFC 1144, February 1990. [12] C. Perkins, "Minimal Encapsulation within IP", RFC 2004, May 1996. [13] J. Wang et. al., "UMIP Intelligent Routing", work in progress. [14] S. Bradner, "The Internet Standards Process -- Revision 3, BCP 9", RFC 2026, October 1996. [15] T. Hiller, "Wireless IP Network Architecture based on IETF Protocols", TIA TR 45.6/TSG-P, June 1999. [16] ETSI TS 123 060 V 3.2.1, "General packet Radio Service (GPRS), Service Description", January 2000. The following syntax specification uses the augmented Backus-Naur Form (BNF) as described in RFC-2234 [2]. 8. Security Considerations The security concerns have been addressed in the section of location update acknowledgment and security considerations. 9. Author's Addresses John Wang Motorola Inc. 1501 W. Shure Dr. Phone: (847) 435-2710 Email: ezw001@email.mot.com Almon Tang Motorola Inc. 1501 W. Shure Dr. Phone: (847) 435-2715 Email: aat008@email.mot.com Wang, Tang September, 2000 32 UMIP March 2000 Full Copyright Statement "Copyright (C) The Internet Society (date). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implmentation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into Wang, Tang September, 2000 33 UMIP March 2000 1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. 2 Crocker, D. and Overell, P.(Editors), "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, Internet Mail Consortium and Demon Internet Ltd., November 1997 Wang, Tang September, 2000 34