Network Working Group Archan Misra INTERNET-DRAFT Subir Das InternetEngineering Task Force Anthony Mcauley draft-misra-mobileip-idmp-00.txt Ashutosh Dutta Date: July 14, 2000 Telcordia Technologies Expires: January 14, 2001 Sajal K. Das University of Texas at Arlington IDMP: An Intra-Domain Mobility Management Protocol using Mobility Agents Status of this memo This document is an Internet-Draft and is in full conformance with all provisions of sections 10 of RFC 2026. 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. Abstract This document introduces IDMP, a mobility protocol that supports routing of datagrams to a mobile node inside a mobility domain. A mobility domain essentially identifies a collection of IP subnets and networks that are aggregated together based on factors such as geographic proximity or administrative control. In addition to supporting basic redirection of packets to mobile nodes, IDMP also provides fast handoff support, with minimal packet losses due to mobility-related transients, and paging support to reduce the signaling burden on mobile nodes. IDMP uses two care-of addresses to manage mobility. The global care-of address identifies the mobile's current domain and remains unchanged as long as the mobile does not change domains. The local care-of address identifies the mobile's current point of attachment and changes every time a mobile node changes subnets. IDMP specifies two types of agents, Subnet Agents and Mobility Agents, to support this two-layer mobility hierarchy. By using two care-of addresses , IDMP removes the need for host-specific routing inside the domain and allows the use of multiple alternative protocols for supporting global mobility. Expires January 2001 [Page 1] Internet Draft IDMP July 2000 Contents 1 Introduction -----------------------------------------------------2 1.1 Hierarchical Approach to Mobility Management--------------3 1.2 Requirements Terminology----------------------------------4 2 Requirements and Motivation for IDMP------------------------------4 2.1 Protocol Functional Requirements--------------------------5 2.2 Motivation for a Separate Protocol------------------------6 3 Functional Overview of IDMP---------------------------------------7 3.1 Basic Packet Redirection and Mobility Support-------------9 3.2 Paging Support in IDMP-----------------------------------11 3.3 Fast Handoff Support in IDMP-----------------------------13 3.4 Distributed Agents and the TeleMIP architecture----------15 3.5 Key Differences with Alternative Protocols---------------16 4 IDMP Addressing Modes and Impact on Other Protocols--------------18 4.1 Choices in Global Care-of Addresses----------------------18 4.2 Choices in Local Care-of Addresses-----------------------19 4.3 Enhancements Needed in Other Protocols-------------------20 5 IDMP Packet Formats and Processing Rules-------------------------21 5.1 Router Advertisement and Solicitations-------------------21 5.2 Local (subnet) Registration------------------------------23 5.3 Intra-Domain (MN-MA) Location Update --------------------26 6 Security Considerations------------------------------------------29 7 Acknowledgements-------------------------------------------------29 8 Intellectual Property Considerations-----------------------------29 9 References-------------------------------------------------------29 1 Introduction This draft introduces the Intra-Domain Mobility Management Protocol (IDMP) proposed for supporting macro-mobility (mobility within a domain). IDMP provides an effective way to manage macro-mobility by using Mobility Agents that provide the mobile with a globally valid care-of address, which can be used for global registration. Packet routing from the Mobility Agent to the mobile's current location is achieved by using a separate locally scoped care-of address. In Expires January 2001 [Page 2] Internet Draft IDMP July 2000 addition to supporting basic packet redirection inside the domain, IDMP also provides support for very fast handoffs (with minimal packet losses due to transients associated with mobility) and paging of registered hosts (significantly decreasing the power drain due to signaling in mobile nodes). By specifying a separate intra-domain mobility management protocol, IDMP enables a clear delineation of intra-domain mobility support from global (inter-domain) mobility management. By making IDMP distinct from Mobile IP [4], IDMP allows the use of multiple alternative global mobility management protocols and architectures without functional changes in the individual domains. We show how IDMP's use of separate local and global care-of addresses can be used to design a two-layered hierarchical IP mobility architecture. We present one such hierarchical architecture called TeleMIP (Telecommunications-enhanced Mobile IP), which essentially uses IDMP for managing intra-domain mobility and Mobile IP for supporting global mobility. Several alternative proposals [1] [2] [3] [15] exist for extending and augmenting the basic Mobile IP [4] protocol to provide faster intra-domain registration by essentially using a hierarchical mobility management framework. These proposals are largely motivated by the desire to extend Mobile IP for supporting real-time traffic (including voice) in IP-based cellular networks. The key goals of these proposals are to reduce the latency of the registration process (thereby enabling fast handoff support) and to support cellular specific features (such as paging) via IP-layer mechanisms. IDMP supports these desirable intra-domain mobility features without employing host-specific routing and without over-extending Mobile IP. 1.1 Hierarchical Approach to Mobility Management Proposals for reducing the latency associated with Mobile IP registration messages usually introduce a mobility management hierarchy to localize the scope of most location update messages. The basic Mobile IP protocol employs a flat management hierarchy, whereby every change in connectivity in the foreign network must be communicated back to the home network. In contrast, proposals such as Cellular IP [1], HAWAII [2], Mobile IP with Regional Tunnel Management [3] and TeleMIP [5] use a two-layer hierarchical framework to manage mobility. These proposals group subnets by mobility domains to localize the scope of location updates. A mobility domain essentially consists of a collection of subnets, typically under the control of a single provider. Global signaling traffic, which informs appropriate external nodes about the mobile's new domain of attachment, are generated only when the mobile changes domains. Movement across subnets within the same domain is managed through signaling within the domain, with nodes external to the domain remaining unaware of the mobile's precise location within the domain. By appropriately sizing domains, operators can significantly reduce the latency of the intra-domain registration process and also decrease the global signaling load. Since Mobile IP employs a flat mobility management architecture, only one care-of address (an address that provides information about the mobile's current point of attachment) is adequate to ensure proper packet redirection. Proposals such as Cellular IP and HAWAII also Expires January 2001 [Page 3] Internet Draft IDMP July 2000 use a single care-of address; to support the management hierarchy, they establish and maintain host-specific routes within the domain. Like IDMP, the Regional Tunnel Management proposal [3] uses two different care-of address to manage intra-domain mobility without requiring host-specific routes, but is based on extensions to the Mobile IP protocol. We shall shortly argue that intra-domain mobility protocols need to support that are not relevant to a global mobility management protocol. Intra-domain mobility management is best embedded in a protocol distinct from Mobile IP. While the concept of mobility domains is an inherent part of all other proposed hierarchical schemes, IDMP differs from other proposals in two key aspects: * By explicitly using a second (local) care-of address to manage intra-domain mobility, IDMP obviates the need in [1][2] for host-based intra-domain routing. * IDMP exists as a stand-alone protocol, providing support for features that are best supported by agents in the currently visited domain. Divorcing the intra-domain mobility management from global mobility schemes, such as Mobile IP [4] or SIP-based mobility [8][9], also provides a cleaner security and authentication framework. The TeleMIP architecture, which uses IDMP for intra-domain mobility Management, is presented in [5][6]. In the TeleMIP architecture, the global care-of address resolves the location of the mobile up to the granularity of an individual domain; IDMP's local care-of addressing is used for handling routing inside the domain. Since the local care-of address has no global significance, private addressing can be used within the domain, thereby providing significant address space relief in IPv4 architectures. TeleMIP also envisages the use of multiple Mobility Agents (each running IDMP) in a domain to achieve greater robustness and dynamic load balancing for QoS support. A comparison of IDMP with alternative intra-domain protocols will be presented later, after the protocol has been functionally specified. While IDMP was initially designed to support the mobility needs of cellular networks, IDMP's flexible design allows it to be used as an intra-domain registration protocol in alternative access technologies, including wireline and wireless LANs. 1.2 Requirements Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [13]. 2. Requirements and Motivation for IDMP In this section, we first present the functionality expected from any well designed intra-domain mobility management protocol and argue why distinguishing such a protocol from Mobile IP provides a modular architectural framework. Expires January 2001 [Page 4] Internet Draft IDMP July 2000 2.1 Protocol Functional Requirements As IP-based mobility management emerges as a viable alternative in various communication network scenarios, Internet protocols need to be enhanced to support several additional performance objectives. Based on a survey of the requirements for supporting mobility in cellular networks, we can identify the following minimum set of features desired of any intra-domain mobility management solution: * Support for fast handoffs The mobility management architecture should be able to seamlessly redirect packets to the mobile's new point of attachment with very small latency. To support real-time IP applications, including Voice-over-IP, the latency typically associated with the registration process must be decreased and bounded. Reducing and bounding the registration delay to O(10) msecs should be a primary goal of any next generation IP mobility solution. * Reducing packet loss during movement One of the chief design goals for Mobile IP was ensuring transparent mobility for TCP applications. Applications that use TCP-based transport and are relatively less delay-sensitive can reliably recover from losses during mobility by using TCP's retransmission mechanism. New applications are however emerging, especially for cellular networks, that use non-reliable transport protocols (such as RTP [7]) for packet transport. Bounds on the acceptable packet transfer delay can preclude the use of end-to-end retransmission-based schemes in such scenarios. The intra-domain mobility management protocol should ensure minimal loss of in-flight packets due to transients in the registration process. * Provide paging support Paging is important in power-conscious environments since it enables a mobile node to significantly reduce its mobility-related signaling traffic. Next generation cellular networks are likely to see a proliferation of miniature devices and appliances, where battery consumption will remain an important constraint. Any intra-domain mobility management protocol should have the option to provide paging support; such support leaves the location of the mobile unresolved until new session traffic is initiated and the exact point of attachment of the mobile needs to be explicitly determined. * Provide support for multi-path distribution techniques Mobile IP inherently provides support for multiple distribution paths by allowing a mobile node to register multiple care-of addresses with its Home Agent. This process can, however, incur considerable latency since the registration request must be propagated all the way to the home network. Since the multiple traffic paths (typically used for providing redundancy and greater transmission reliability) usually originate in the foreign domain itself, support for such paths should be a feature of the intra-domain mobility protocol (rather than the global mobility management scheme). By enhancing the intra-domain IP mobility Expires January 2001 [Page 5] Internet Draft IDMP July 2000 protocol to support such emerging technologies (e.g., soft-handoffs), if necessary, modifications to protocol specifications with evolving technologies can be localized to the relevant domains. This support must be optional and configurable only when the link and physical layer technologies permit; at this point, it is not clear whether such support is necessary for currently emerging access technologies. We do not consider this issue any further in this version of the IDMP draft. 2.2 Motivation for a Separate Protocol While Mobile IP is the ubiquitous standard for IP-based mobility, a separate protocol specification for supporting intra-domain mobility becomes necessary once we analyze the shortcomings of Mobile IP in achieving the functional goals enumerated above. Mobile IP was primarily designed to provide seamless roaming, by providing a mobile node (MN) a topologically correct care-of address in the visited foreign) network. Mobile IP was developed for the "computer/PC-based Internet access" model where node mobility is restricted to only a small fraction of the total number of IP hosts. In such predominantly static environments, the frequency and volume of global registration messages generated by mobile nodes is not a major concern. When Mobile IP was designed, the primary objective was to ensure transparency to TCP connections by preserving the fixed home address of the MN and performing packet redirection (using tunneling) at the network layer. In the absence of a set of viable real-time or delay sensitive applications, the latency involved in updating the remote HA or CN on every subnet change was also not a topic of practical concern. Also, Mobile IP assumes that the rate of subnet change by an MN is not too rapid; the specifications state that Mobile IP is intended for situations where the MN does not change subnets more than once every second. Finally, since Mobile IP was initially deployed on portable/desktop computers, conserving the power expended by the MN in registrations was not given high priority; hence, Mobile IP has support for lazy location updates and paging. Mobility support for real-time applications, especially in a cellular environment, must address each of these shortcomings of basic Mobile IP. In the cellular environment, the concept of a well-defined home network where the MN spends the majority of its time is less applicable. Also, since every active node is likely to exhibit significant mobility, signaling overheads can become very large. In practical cellular networks, topology considerations and frequency and address space limitations may also cause an IP subnet to span a fairly limited geographical area. Thus, a mobile may change subnets fairly frequently (especially if the trend towards pico-cellular networks in urban areas continues). Thus, Mobile IP's assumption that an MN will not change subnets more than once every second can become a constraint in emerging IP-based cellular architectures. Since voice and other real-time multimedia applications will be critical applications for cellular network, Mobile IP's flat management structure must also be modified to introduce a hierarchical structure and thereby reduce the latencies and packet losses currently involved in the registration (location update) Expires January 2001 [Page 6] Internet Draft IDMP July 2000 process. Finally, unlike wireless LANS, power consumption is likely to remain a major issue in cellular networks and support for mechanisms such as paging will be vital for the successful adoption of IP technology in such environments. While Mobile IP can certainly be augmented to address each of these shortcomings, there appears little motivation to do so. Firstly, unlike the conventional Internet, where backward compatibility is a major concern, cellular networks have no "IP legacy" issues. A separate intra-domain protocol fosters a more modular network architecture; the architecture should allow static Internet hosts to communicate with mobile nodes without any changes. Since the intra-domain mobility protocol is separate from the global mobility solution, this goal is easy to achieve. For example, IDMP's design allows it to seamlessly operate with Mobile IP, by specifying the global care-of address as the Mobile IP care-of address to the Home Agent (HA). Secondly, an inspection of the intra-domain mobility objectives shows an uneasy fit with the global mobility management objectives of Mobile IP. Mobile IP is best equipped to provide the basic packet redirection mechanism from a CN to the current location (in some approximate sense) of the MN. Extending Mobile IP for intra-domain mobility support complicates an elegant and well-defined protocol and could lead to functionality being defined at inappropriate elements. For example, a Home Agent is clearly a poor choice as an originator of paging requests, since such requests must traverse the entire network between the home network and the current foreign network. Furthermore, proposals such as Regional Tunnel Management [3] that seek to extend Mobile IP in a hierarchical manner tend to combine the intra-domain and global authentication and security mechanisms. In practice, global and intra-domain authentication can have different objectives and security levels. For example, in military environments, where an MN moves into an untrusted cellular domain, it may wish to separate the security association between the MN and its HA from any association within the cellular domain. Specifying intra-domain mobility management independent of the global mobility scheme promotes the ubiquitous support of MNs belonging to "home networks" of varying security consciousness. Finally, as stated earlier, standardizing a separate intra-domain mobility protocol allows more flexibility in the choice of the global registration protocol. While Mobile IP is certainly the currently preferred technique for global IP registration, alternative techniques such as SIP-based mobility [9] and Mobile IP-LR [10] do exist. Standardizing IDMP independently of Mobile IP permits Mobile Nodes (MN) using different global update mechanisms to be supported off the same cellular domain mobility infrastructure. The next section presents the functional overview of the Intra-Domain Mobility Management Protocol, which uses two different care-of addresses to support a two-level mobility management architecture. Large pieces of IDMP are similar to Mobile IP; to minimize the implementation costs associated with IDMP, IDMP reuses Mobile IP standard message formats as much as possible. However, IDMP offers substantially different functional support to warrant definition as a separate protocol. 3 Functional Overview of IDMP Expires January 2001 [Page 7] Internet Draft IDMP July 2000 This section presents a high level overview of the operation of IDMP. In particular, we outline how packets are re-directed to the MN by the two-layer addressing mechanism, how IDMP agents coordinate to ensure faster handoffs and minimize packet losses during transients associated with intra-domain mobility and how IDMP supports paging for registered MNs. We shall later see that, similar to Mobile IP, IDMP also supports two modes for obtaining a local care-of address (LCOA): a Subnet Agent (SA) mode, whereby the MN obtains the local care-of address from Subnet Agents (SA) present on each individual subnet, and a Co-located (CO) mode, whereby the MN uses additional subnet-specific configuration mechanisms, such as DHCP [10] or DRCP [11] to obtain a co-located local care-of address. IDMP has two analogous modes for the global care-of address as well: the Mobility Agent (MA) mode whereby all MNs associated with an MA use the same global care-of address, and the Global Co-located (GC) mode, where each MN has its unique global care-of address. Both modes however require packet interception and redirection by the Mobility Agent. For purposes of illustration, we assume the SA mode for local care-of addressing and the MA mode for global care-of addressing. ---------------------+-------------------------- | DOMAIN | | +--+--+ | | |BR | +--+--+ | | +---+ -- | | +-----+R |---+ |MA | | | | +---+ -- | | +-------------------+---------------------+-- | | | +- -- -+- | | | | | | |R | |R | | R | -+ +- -+- | | | | | | +-+--+ +-+--+ +-+--+ | | | | | | |SA1 | |SA2 | | SA3| +-+--+ +-+--+ +--+-+ | | | | | | |subnet1 |subnet2 |subnet3 | | +--+ | | +----+MN| | +--+ Expires January 2001 [Page 8] Internet Draft IDMP July 2000 Figure 1 Two-level IDMP Functional Architecture (BR: Border Router, R: Interior Router) IDMP functionality is best described using the layout shown in Figure 1. We see that, similar to Mobile IP, we have Subnet Agents (SA) at each subnet; these agents provide the MN with a topologically correct local care-of address in the foreign domain. While the functionality of a SA is very similar to that of Mobile IP Foreign Agents in Mobile IP; we use a different nomenclature to emphasize the IDMP-specific nature of these nodes. IDMP also introduces a new functional node, called the Mobility Agent (MA), which sits at a higher level in the network hierarchy than the SA and which provides a topologically correct, globally reachable care-of address to the MN. The MN thus has two addresses associated with it: * A global care-of address (the MA's publicly reachable address) that enables packets to be globally routed to the MA. * A local care-of address (in this case the address associated with SA1, SA2 or SA3) that identifies the subnet where the MN is currently attached. 3.1 Basic Packet Redirection and Mobility Support When the MN first moves into a domain, it first obtains a local care-of address (in this case, SA2's address) by performing a subnet-specific mobility registration using IDMP. IDMP also requires SA2 to assign the MN a Mobility Agent (MA) during this subnet-specific registration process. The MN then performs an intra-domain location update by communicating its current local care-of address to the designated MA. The MA includes either its address or a separate global care-of address in the intra-domain location update reply. Subsequently, the mobile node is responsible for generating a global location update (registration) to the necessary remote nodes (e.g., Home Agent if Mobile IP is used for global mobility management); this is however independent of the IDMP specifications. The IDMP call flow when the MN first moves into a new domain is illustrated in figure 2. MN FA MA | Route Advertisement | | <<--------------------+ | | | | |Subnet Registration Req. | +-------------------->> | | | | | | | | | | | Request Reply (MA) | | <<--------------------+ | | | | Expires January 2001 [Page 9] Internet Draft IDMP July 2000 | | | |Intra-domain Location update | +---------------------+---------------->> | | | | Intra-domain Location Reply | <<--------------------+-----------------+ | | | +---------------------+-----------------+----------->> | Global Update (beyond IDMP) | | | | | | | Figure 2 IDMP Call Flow during the Initial Intra-Domain Location Update After the initial intra-domain registration process, IDMP now allows the MN to retain its global care-of address as long is stays within the same domain. Whenever the MN changes subnets within this same domain, it performs a new subnet-specific registration with the new SA. Since the MN indicates that it has an existing valid registration within the domain, the SA does not allocate it a new MA address in this case. The MN then performs a new intra-domain location update and informs its MA of its new local care-of address. No global messages are generated in this case, since the global care-of address remains unchanged. As with other hierarchical mobility management schemes, the localization of intra-domain mobility significantly reduces the latency of handoffs across subnets within the same domain and also dramatically decreases the frequency of global signaling traffic. Figure 3 describes the IDMP call flow during subsequent intra-domain movement. MN FA MA | Route Advertisement | | <<--------------------+ | | | | |Subnet Registration Req. | +-------------------->> | | | | | | | | | | | Request Reply | | <<--------------------+ | | | | | | | |Intra-domain Location Update | +---------------------+---------------->> | | | | Intra-domain Location Reply | <<--------------------+-----------------+ | | | | | | | | | Expires January 2001 [Page 10] Internet Draft IDMP July 2000 | | | | | | Figure 3 IDMP Call Flow during Subsequent Intra-Domain Movement It is now fairly simple to construct the delivery mechanism for packets destined to the MN. We describe this mechanism assuming the use of basic Mobile IP as the global mobility management mechanism. A Packet transmitted to the MN's home address is intercepted by the home agent and then tunneled to the Mobility Agent using the MN's global care-of address. The MA is responsible for decapsulating this packet and then using the inner (permanent home address) destination address to determine the target MN for this packet. The MA then looks up its internal table to determine the current local care-of address for this MN, re-encapsulates the packet (with this local care-of address as the outer destination header) and then forwards it to the MN using conventional IP routing within the domain. The SA receives this message, decapsulates the outer header and then forwards the packet to the MN using layer-2 mechanisms (similar to Mobile IP). For the reverse path (for packets from the MN to a CN), the MN has two different options. If the network nodes perform no ingress/egress filtering, then the MN can simply forward packets direclty towards the CN. However, in more security foreign domains, reverse tunneling (within the domain) may be necessary. While the global reverse tunneling support is outside TeleMIP's scope, reverse tunneling within the domain mobility domain can be achieved by routing outbound packets to the MA. The MA will then encapsulate these packets (using the topologically correct global care-of address as the source address field in the outer header) and then forward it toward the CN. If commercial providers desire to account for outbound packets as well, then reverse tunneling within the domain may be mandatory; the MA then serves as an accounting node as well. 3.2 Paging Support in IDMP The paging architecture of IDMP is very similar to that currently employed in cellular networks. Paging in IDMP requires the definition and configuration of Paging Areas (PA). A PA is a collection of subnets (Subnet Agents) within which the MN's exact location needs to be resolved. Paging support is only activated when the MN indicates to the network that it is switching to a registered but Idle state; this will typically occur after a period of inactivity at the mobile. As long as the MN stays in an idle state and does not move to a new Paging Area, it does not perform any local or intra-domain registrations. Each PA is identified by a unique 16 bit identifier, called a Paging Area Identifier (PAI); IDMP allows operators to define overlapping Paging Areas (to reduce boundary effects) of arbitrary sizes. A single Subnet Agent can be a member of multiple Paging Areas; the SA MUST broadcast its set of PAIs in its Router Advertisement beacons. An MN can use this set of PAIs to determine when it has crossed from one Paging Area to Expires January 2001 [Page 11] Internet Draft IDMP July 2000 another. +-----+ +----------+ +-----+ | | | | | | | CN |-----------| INTERNET |-----------| HA | | | | | | | +-----+ +----+-----+ +-----+ | | | +----+-----+ | | +-------------+-------| ROUTER |--------+-------------+ | | | | | | | | +----+-----+ | | | | | | | | | | | | Subnet A | Subnet| B +---+----+ Subnet| C Subnet| D ----+---- -------+- | MA | ----+---- ----+---- | | +---+----+ | | | | | | | | +-+---------+------------+-+-----------+ | | | | | | | | +--+--+ +v-+--+ +v-+--+ +v-+--+ | SA1 | | SA2 | | SA3 | | SA4 | +-----+ +-----+ +-----+ +-----+ +-----------------------------------+ / +----------------\----------------------------+ / +---------+ +--/--------+ +---\-------------+ +---------+\ / / \ / / \ / \ \ / \\ / / \ / \ / \ / \\ | | | | | \ | +----+ | | || | | | | | | | <--|---| MN |--|-|--> || | \ \ / | \ / | +----+ \ / / \ \ \ \ / / \ // \ \ / \ \ / \ / / \ // \ +--------+ +--\---------+ +-----/------------+ +---------+/ \ +-----------------/---------------------------+ +-------------------------------------+ Figure 4 IDMP Paging Architecture The selective location update and paging operation of IDMP is visually illustrated in figure 4. In this model of operation, SA2, SA3 and SA4 belong to the same PA (PA1), while SA1 and SA2 are part of a different PA (PA2). We assume that the MN switches to Idle state in subnet C. As long as it moves between subnets B, C or D, the MN may lose contact with its previous SA but will hear at least one beacon (from SA2, SA3 or SA4) that includes PA1 in its list of PAs. Consequently, not only will the MN not inform its MA about its current local care-of address, it will not even bother to obtain a new local care-of address. However, when the MN moves to subnet A and realizes that it has moved beyond the domain of PA1, it performs a local registration with SA1 and then sends a Registration Update Expires January 2001 [Page 12] Internet Draft IDMP July 2000 to the MA, indicating the new PA (PA2). Note that it is possible for the MN to have a choice of PAIs for its new PA (if multiple PAs overlap); we currently assume that the MN will randomly choose one from the available set of Paging Areas. When the MA receives packets for an MN which is currently registered, but in an Idle state, it `multicasts' a PageSolicitation packet to all the subnets associated with the MN's current PA (to SA2, SA3 and SA4). It also buffers incoming packets until the MN has successfully answered the paging request. When the MN responds to this solicitation and re-registers with the MA, buffered packets are forwarded to the MN. Temporary buffering is acceptable as the intra-domain location update process is assumed to have reasonably low latency, which is assumed to lie within the acceptable bounds for initial session establishment. The mechanism by which the MA distributes transmits the PageSolicitation packet to multiple subnets (SAs) is not specified as part of IDMP. Standard IP multicasting techniques, if available, SHOULD be used to enable the distribution of the paging soliciation. When the MN receives this PageSolicitation, it MUST re-register with its MA, indicating its exact current location and thereby switching back to an Active state. Once the MA completes this intra-domain registration, the packet redirection process is revived and all buffered packets are transmitted (via encapsulation) to the MN. 3.3 Fast Handoff Support in IDMP While localizing the scope for intra-domain registration messages (up to the Mobility Agent) certainly bounds the delay involved in the registration process, packets can still get lost due to transients in IDMP's intra-domain location update process. Whenever an MN changes subnets, it must obtain a new local care-of address (either from the new SA or via subnet configuration protocols) and then register this new address with its Mobility Agent. In-flight packets will be redirected to the old location of the MN (previous SA) during this transient phase and will thus be lost. It is thus easy to see that moderate handoff latency under the basic TeleMIP intra-domain mobility management mechanism can arise if there are significant delays in either obtaining a new local care-of address or in communicating this to the Mobility Agent. To further reduce the latency (and minimize the packet losses)in the local update process, IDMP supports fast handoff by multicasting packets during the handoff period. While IP multicasting MAY be used, IDMP does not mandate or specify a specific mechanism for distributing copies of the packets to multiple destinations. Fast handoff support in IDMP does not require recipients to join and leave multicast groups dynamically and consequently imposes no group formation latency. IDMP's fast handoff support is based on the assumption that the MN is aware of an impending handoff (or change in subnets) and is thus able to alert its MA of an imminent movement. In most current cellular environments, for example, a mobile is transferred from one BS (or BSC) to an adjacent BS (or BSC) based on various layer-2 constraints (such as signal strength). During this transition, there is often a period of time during which the mobile `hears' two different BSCs and is on the threshold of switching from one BS to another. Thus, in an IP environment, a Expires January 2001 [Page 13] Internet Draft IDMP July 2000 mobile node should be able to determine when it is likely to lose contact with the old subnet (for example, if it has trouble hearing beacons from its current SA). To minimize packet loss during the handoff period, the MN initiates a request to the MA to `multicast' its packets for a limited period of time. If the multicast recipients are chosen such that these packets are available at the new location of the MN, the MN can receive these packets immediately after it obtains a new local care-of address (subnet registration), even though the full intra-domain registration process has not been completed. IDMP's fast handoff mechanism has similarities with the mechanisms proposed in [14] and [16]. +-----+ +----------+ +-----+ | | | | | | | CN |-----------| INTERNET |-----------| HA | | | | | | | +-----+ +----+-----+ +-----+ | | | +----+-----+ | | +-------------+-------| ROUTER |--------+-------------+ | | | | | | | | +----+-----+ | | | | | | | | | | | | Subnet A | Subnet| B +---+----+ Subnet| C Subnet| D ----+---- ----+---- | MA | ----+---- ----+---- | | +---+----+ | | | | | | | | +---------+-+------------+------------+-| | | | | | | | | +--+-v+ +v-+--+ +v-+--+ +--+--+ | SA1 | | SA2 | | SA3 | | SA4 | +-----+ +-----+ +-----+ +-----+ +---------+ +-----------+ +-----------------+ +-----------+ / \ / \ / \ / \ / \ \ / / \ | | | +------+ \ | | | | <-|-|--| MN |----|-|--> | | | \ \ / +------+ \ / \ / / \ \ / \ / \ / \ / \ / \ / +--------+ +------------+ +------------------+ +---------+ Figure 5 IDMP Fast Handoff Mechanism We describe the multicast forwarding mechanism using IDMP's SA mode in Figure 5. When the MN decides that it is going to change SAs, corresponding to a move from subnet B to subnet C, it sends a MovementImminent message to its MA (via SA2). Note that this message can be very short; we assume that in most instances, the mobile will be able to transmit this message before it loses Expires January 2001 [Page 14] Internet Draft IDMP July 2000 connectivity with the old SA/subnet. On reception of this message, the MA consults its tables and determines the multicast group that identifies the neighbors of SA 2. It begins to forward any subsequently arriving packets for the MN to this cluster of "neighboring SAs" (SA1, SA2 and SA3). Each member of the group then buffers a limited number of these packets (on a per-MN queue). When, for example, the MN registers with SA3, SA3 can immediately forward any buffered packets to the MN even before the intra-domain location update process (up to the MA) has completed. 3.4 Distributed Agents and the TeleMIP's Architecture The TeleMIP architecture presented in [5][6] uses IDMP as the intra-domain mobility management mechanism to provide fast handoffs and paging support in a scalable manner. A key element of the TeleMIP architecture is the explicit use of multiple IDMP Mobility Agents inside a single domain to provide a robust mobility management architecture. A logical organization of the TeleMIP hierarchy is shown in figure 6. Unlike other hierarchical schemes, such as [1][2], where the intra-domain mobility is managed by a single border router at the ingress edge of the domain, IDMP Mobility Agents can be placed in arbitrary locations and hierarchies within the domain. Of course, this flexibility comes at the expense of possibly sub-optimal routing ("triangular routes") inside the domain. Also, unlike the approaches using host-specific routing in [1][2] which either assume or impose a tree-like hierarchy on the domain topology, IDMP works in domains with arbitrary topologies. IDMP does not use an implicit path reversal technique to route location updates towards the border router of the domain; intra-domain location updates from the MN are explicitly directed to a specific MA. The multi-MA TeleMIP architecture does not need any additional management in multi-peered domains, where multiple border routers promote redundancy as well as load sharing. The TeleMIP architecture enables distributed mobility support and eliminates single points of failure. Different sets of MNs within the same domain can be assigned to different MAs. The placement of multiple Mobility Agents allows the administrator of the domain to implement load-balancing algorithms that distribute the traffic across multiple mobility agents. TeleMIP also provides operators the ability to dynamically add new MAs as the traffic load increases. ---------------------+-------------------------- | DOMAIN | | +--+--+ | | |BR | +--+--+ | +------------------------+ +---+ -- | -+ +---+ +- +---+ | +-----+R |---+------|R +-----| | |R +---+ | |MA | | | | | + |MA | | | |MA | +*--<<---+ -- | -- +-*-+ -- +---+ Expires January 2001 [Page 15] Internet Draft IDMP July 2000 /+\------+-. | /|\ +-----------+-.-----+-----------------+--+--- | . . | . | +- . . -- . /-\ | | . . | | . | | |R | . . |R | . |R | -+ . . +- . \+/ | . . | . | ...... .. | . . | . | MA-MN +-+--+ . . +-+--+ . +-+--+ Association | | . . | | . | | |SA1 | . . |SA2 | . | SA3| +-+--+ . . +-+--+ . +--+-+ | . . | . | | . . | . | |subnet1 . . |subnet2 . |subnet3 | +---+..+ . | +---+ . | +---+ +---+ | . +----| | . +----| | |MN1| +..........+MN2| +.........+MN3| +---+ +---+ +---+ Figure 6 TeleMIP Architecture with multiple Mobility Agents The TeleMIP approach is logically equivalent to running Mobile IP at two different hierarchies. When Mobile IP is used for global mobility in an IDMP-enabled domain, the HA provides an MN a globally stable point for packet redirection: packets addressed to the MN's permanent home address will be intercepted and forwarded to the MN's current domain. The IDMP Mobility Agent similarly provides a domain-wide stable point for packet redirection: packets arriving at the MN and addressed to the MNs GCOA are redirected to the MN's current subnet of attachment. Thus, a Mobility Agent can be considered to provide functionality similar to that of a Dynamic Home Agent, wherein the MN dynamically obtains a home address that is valid for that domain. 3.5 Key Differences between Alternative Protocols and IDMP Several other schemes, including Cellular IP, HAWAII and Mobile IP Regional Tunnel Management have been proposed for managing intra-domain mobility in IP networks. This section describes the key differences between these alternative proposals and IDMP. IDMP differs from other suggested intra-domain protocols such as Cellular IP, HAWAII or EMA [12] by using a second care-of address (the LCOA) to eliminate the necessity of host-specific route establishment (either domain-wide or localized) inside the domain. This elmination of host-based routing us achieved by specifying the Mobility Agent as an anchor point does, however, carry the penalty of routing sub-optimality inside the IDMP domain. In contrast, Cellular IP and HAWAII use path reversal to set up the most optimal intra-domain route. Since the local care-of address (LCOA) has meaning only inside the domain, it is easy to see that the local care-of addresses can be private or locally scoped. The ability to use private addresses for managing intra-domain mobility is an Expires January 2001 [Page 16] Internet Draft IDMP July 2000 important benefit in IPv4 environments, where public address pools may not always be abundantly available. IDMP assumes the use of conventional IP routing protocols inside the domain and hence does not lead to any additional scalability issues. IDMP only requires modifications to nodes designated as either Mobility Agents or Subnet Agents. In an IDMP-enabled domain, future protocol upgrades are also restricted to these specific nodes. In contrast, approaches using host-based routing support mobility management in a completely distributed fashion and require upgrades/support at all nodes in the cellular domain. Host-specific routing is typically geared towards tree-shaped networks that have a natural hierarchy with a single ingress router for the domain. In such networks, movement from one leaf node to another merely requires reestablishment of the downstream path from the least common ancestor (LCA) of the current and previous nodes. To support such schemes in arbitrary multi-peered networks, additional address and route management is necessary to ensure that updates from a specific MN always travel towards a unique ingress router. In contrast, the IDMP Mobility Agent is fundamentally a generalized proxy and works in any arbitrary configured network configuration. Host-specific routing approaches also provide greater challenges in the establishment of arbitrarily shaped paging areas. IDMP permits operators to define arbitrarily sized and overlapping paging areas. A paging area In IDMP is simply a set of Subnet Agents (subnets) that subscribe to the same multicast group; the size and membership of a PA can be changed by simply altering the subscription of SAs/subnets to well-known multicast groups. In contrast, both HAWAII and Cellular IP use a tree-like network hierarchy to propagate paging updates towards the root and modify forwarding state at a LCA. Furthermore, in Cellular IP, the extent of a PA is implicitly determined by the location of the Paging Caches. Given a node with a Paging Cache, a Paging Area is defined by the set of nodes for which this node is the Least Common Ancestor with a Paging Cache. Such a placement-based PA definition makes it harder to define overlapping PAs of arbitrary size; changing the size and membership of a Paging Area also requires explicit manipulation of paging cache locations inside the cellular domain. IDMP's use of two care-of addresses and the specification of a Mobility Agent as a stable care-of address with domain-wide validity is similar to the proposal for Mobile IP with regional Tunnel Management [3] and the Hierarchical Mobile IPv6 proposal in [15]. The IDMP Mobility Agent is similar in concept to the Gateway Foreign Agent proposed in [3]), albeit with some differences. * IDMP is a separate mobility protocol that does not mandate the use of Mobile IP for global location management. A mobility architecture using IDMP has two distinct location update phases: one using IDMP for intra-domain mobility, and a separate one for global mobility. Unlike [3], where Mobile IP is the implicit global mobility protocol, users in IDMP domains can not only use Mobile IP, but a variety of other protocols, such as SIP, as well. Expires January 2001 [Page 17] Internet Draft IDMP July 2000 * By making the two registration procedures distinct, IDMP permits a cleaner security and authentication framework. The MA or SA is not expected to be used as intermediate relays for the global registration process; all global location updates are transacted directly between the MN and the remote destination (e.g., HA in Mobile IP). For example, the TeleMIP architecture does not require the sharing of the MN-HA security association with the MA; the intra-domain and extra-domain security associations are independent and unrelated. This separation comes at the expense of higher registration latency during an inter-domain (global) update, sinceusers in an IDMP domain must perform global resgitratio separately from the intra-domain location updates. * In IDMP, the assignment of an MA to a mobile is controlled by the network. Unlike solutions based on Mobile IP, where the agent hierarchy was explicitly specified in the Agent Advertisement messages, IDMP does not advertise the list of candidate MAs in its initial advertisement message. Rather, the MA is assigned to the MN by the network (SA), presumably using additional service-specific requirements that are specified by the MN during the initial registration process. Thus, IDMP allows the network to easily and dynamically balance mobility support over multiple MAs. 4 IDMP Addressing Modes and Impact on Other Protocols IDMP uses two care-of addresses, one for providing global connectivity and another for handling intra-domain mobility. IDMP allows each of these addresses to be assigned to a mobile node in an agent-based approach (where multiple mobiles share the same care-of address) or in a co-located approach (where each mobile has its own unique care-of address). Implementers and operators MAY choose to use only one specific mode of addressing for both the local and global care-of addresses. However, implementations SHOULD provide mobile nodes the ability to choose either mode of addressing, for both the local and global care-of addresses. As we shall see, specifying both modes allows IDMP to be used in a wide variety of mobility management architectures. Choosing the co-located addressing mode however, will require additional enhancements to existing protocols. 4.1 Choices in Global Care-of Addresses The global care-of address (GCOA) in IDMP is valid as long as the MN stays within the same IDMP domain. IDMP supports two different modes for assigning the GCOA: a) In the Mobility Agent (MA) mode, the MN uses its Mobility Agent's publicly reachable address as its care-of address. Multiple mobile nodes allocated to the same MA thus share their global care-of address. In this case, packets from external nodes (for example, from Mobile IP Home Agents) MUST be tunneled to this global care-of address, with the MN's permanent home address present in the destination field of the inner header. Tunneling is required since the MA needs the internal destination address Expires January 2001 [Page 18] Internet Draft IDMP July 2000 field to demultiplex packets addressed to different mobiles. After decapsulating the packet, the MA uses this internal address (which needs to globally scoped as well) to determine the identity of the MN and then retireves its current local care-of address using its internal tables. While the agent-based approach allows conservation of address space (since multiple MNs share the same global care-of address), it has two limitations that may occasionally prove significant. Firstly, this approach assumes that the MN always possesses a permanent home address. In certain mobility architectures, for example, in SIP-based mobility [9], users are identified by alternative identifiers; the notion of a permanently assigned home address for each device may not apply in such scenarios. Furthermore, it is possible that devices may have IP stacks on them, but not necessarily a permanent IP address. Secondly, using the MA modes tunneling mandatory from the remote source (either HA or CN) to the MA . In certain situations, operators may wish to avoid this tunneled mode of transport, possibly due to security and QoS-related considerations. b) In the Global Co-located (GC) mode, each registered MN is assigned a unique globally valid care-of address. Note that each mobile is also separately assigned a local care-of address. This approach assumes that each MA has a pool of publicly available IP addresses associated with it. Mobiles using a specific MA are assigned a global care-of address from this pool; packets addressed to any member of this pool will be routed via regular IP routing to this MA. This approach alleviates both the shortcomings of the MA mode of global care-of addressing. There is no mandatory need for the remote node to tunnel packets for an MN to the MA. Assuming that the remote node has the ability to bind the MN's GCOA and use it in the destination address field in the IP header, it can simply send regular packets using this GCOA. The MA (acting as a proxy for the MN) intercepts such packets; the MA can then use this unique GCOA as an index to determine the LCOA of the corresponding mobile node. This approach also removes the need for a separate and permanent home address to be associated with every MN. Such an address is not needed either by the MA (which uses the temporary GCOA as its index into the forwarding table) or by the SA (which can send packets to the MN using it's layer-2 address). This mode makes IDMP useful as an intra-domain protocol in architectures where there is no permanent IP address associated with the MN (or the user). This mode however requires every domain (and its constituent MAs) to have a sufficiently large public address pool to allocate a separate global address to each and every registered MN. Address pool exhaustion could become an issue in IPv4 networks; this requirement is not an issue in IPv6 domains. 4.2 Choices in Local Care-of Addresses The second care-of address associated with an MN is its local care-of address (LCOA); this identifies the subnet to which the MN is currently attached. Expires January 2001 [Page 19] Internet Draft IDMP July 2000 4.2.1 Subnet Agent (SA) mode In the subnet mode, this LCOA is assigned to the MN using Agent Advertisements (similar to Mobile IP's Foreign Agent mode. The local care-of address is usually the SA's interface address itself. The SA is then responsible for demultiplexing all packets tunneled to this care-of address and then forwarding it to the individual mobiles using layer-2 mechanisms. In this mode, nodes detect change in their subnet based on Agent Advertisements that are periodically broadcast by the Subnet Agents. 4.2.2 Co-located (CO) mode In this mode, the MN uses additional subnet configuration protocols, such as DHCP or DRCP, to obtain an address, independent of IDMP. This mode is identical to the co-located mode of Mobile IP. In this mode, the MN is responsible for decapsulating packets directed to it. Additional layer-2 triggering support will be needed in this case to provide an MN the notification of mobility and change of subnets; specification of such mechanisms is beyond the scope of IDMP. 4.3 Impact on Associated Protocols Nodes In the SA mode of local care-of addressing, IDMP is essentially self-contained and operates as a stand-alone intra-domain protocol. In this mode, functionality required to support various mobility features, including the allocation of local care-of addresses, is confined to the IDMP-specific agents. For example, to support paging, the Subnet Agent must now actively subscribe to multicast groups that identify the paging areas to which it belongs. The SA is also responsible for joining appropriate neighborhood clusters and for buffering any packets multicast to the MN during the intra-domain registration transient. In the CO mode for local addressing, support for certain IDMP-specific features requires modifications of and enhancements to additional protocols and network nodes. In the CO mode, in the absence of SAs, the MN MUST obtain configuration information such as the identity of its Mobility Agent and the Domain Identifier associated with the current subnet, from some other configuration protocol. If DHCP, for example, is used as the subnet address configuration protocol, it must be augmented to provide an MN with the address of its MA in addition to a subnet-specific local care-of address. Furthermore, additional fields such as Domain Identifier and Paging Area Identifiers need to be a part of the DHCP OFFER message to enable the MN to determine when it has switched domains or paging areas and consequently needs to re-initiate intra-domain or global registration respectively. Such information is expected to be carried in DHCP messages uses Extension Headers. To support functions such as paging and fast Handoffs in the CO mode, the subnet router functionality must also be augmented. For example, a subnet router must now be able to cache multicast packets Expires January 2001 [Page 20] Internet Draft IDMP July 2000 for a limited duration, subscribe to multicast groups and forward paging requests multicast to its subnet by an MA. Of course, another architectural option for an MN is to use protocols such as DHCP to merely obtain a co-located care-of address and use an IDMP-specific SA for all other IDMP-specific support functions. Further specification of the necessary modifications and upgrades to subnet-specific protocols and nodes is deferred to a later draft 5 IDMP Packet Formats and Processing Rules Since IDMP can be considered to be an enhanced version of Mobile IP, with additional intra-domain specific features, significant portions of the message formats and processing rules are derived from the Mobile IP [4] specifications. In this draft, we specify the packet formats and processing actions in fairly generic terms and refer readers to the Mobile IP specifications for details on the packet formats and the processing rules. More detailed and self-contained specification of IDMP will be provided in a more mature version of the current draft. Broadly speaking, IDMP processing can be divided into three separate activities: a) Transmission and Processing of Router Advertisements to detect subnet changes (SA mode) b) Registration Request and Reply Processing to register and obtain a local care-of address (SA mode). c) Registration Request and Reply Processing to perform an intra-domain registration with the Mobility Agent. We now consider each of these different activities individually. 5.1 Router Advertisement and Solicitations Like Mobile IP. IDMP uses ICMP router advertisements and solicitations as the principal mechanism to detect subnet (and domain) changes and to obtain the identity of candidate Subnet Agents. IDMP Subnet Agents use ICMP Agent advertisement messages to broadcast subnet information to the mobile nodes. To maintain compatibility with the Mobility Advertisement extensions of Mobile IP, IDMP reuses the Mobile IP packet format as far as possible. To indicate the presence of IDMP, and to indicate the support of various optional IDMP features, the unused bits in Mobile IP's specification of Mobility Advertisements are used. The following figure describes the current structure of IDMP's Mobility Advertisement extensions in ICMP's Agent Advertisement messages. 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|T|E|O|P reserved| |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| | Local Care-of Address | Expires January 2001 [Page 21] Internet Draft IDMP July 2000 |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| | Domain Identifier | |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| | Paging Area Identifier # 1 | Paging Area Identifier #2 | | . . . . . . . . . . | . . . . . . . . . . | | ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 7 IDMP Router Advertisement Message Format Most of the values are derived from Mobile IP's specification and hence, are not discussed further here. The major changes include the specification of the following 3 bits: * E: An IDMP bit indicating that this subnet is part of a domain that supports the IDMP protocol. * O: A FastHandoff capability bit indicating that this SA is capable of participating in the fast handoff procedure. * P: A PagingCapability bit indicating that this SA is capable of participating in the Paging mechanism. The Domain Identifier field is 32 bits long and is used to specify the scope of a single IDMP domain. This field is used by an MN to determine when is has moved away from its present domain and hence, needs to perform a fresh global registration. Another key difference with Mobile IP's Mobility Advertisement syntax is that IDMP advertises only one care-of address (the local care-of address) in a single agent advertisement (for reasons of size). Thus, each SA is responsible for generating its own advertisements. Also, the Paging Identifiers are broadcast as part of the Agent Advertisement message. Each paging area identifier (PAI) is 16 bits in length; a Subnet Agent MUST broadcast PAIs in pairs to ensure that the Agent Advertisement aligns on a word boundary. The Paging Area Identifier 0x0000 is reserved for padding and alignment and MUST be ignored by the MN. Thus, each domain can have a maximum of 255 unique Paging Areas. As in Mobile IP, an MN must perform Router Solicitations if it wishes to register in the SA mode and does not hear advertisements from the Subnet Agents. The structure of these Solicitation requests is very similar to that specified in Mobile IP and is not discussed further in this draft. 5.1.1 Mobile Node Considerations If the TeleMIP bit is NOT set, then the MN must assume that this particular subnet or SA is not part of an IDMP domain. In such a case, a node implementing Mobile IP MUST go back to its basic Mobile IP registration procedure as documented in [4]. In particular, it MUST reset current paging and fast handoff information and initiate a new registration with the Home Agent using the new SA's (actually FA's) care-of address as the current care-of address. Expires January 2001 [Page 22] Internet Draft IDMP July 2000 As stated earlier, the FastHandoff (O) and PagingCapability (P) bits indicate whether the SA is capable and willing to support the corresponding capabilities. In case one of those bits is not set in an Agent Advertisement from the SA with which the MN is currently registered, the MN MUST stop assuming the corresponding support from the TeleMIP domain. Similarly, if these bits are not set in an Agent Advertisement from an SA with which the MN is performing a new subnet-specific registration, the MN MUST stop assuming support for the corresponding IDMP feature. For example, if the MN currently in an idle state moves and hears advertisements only from a new SA which does not have the PagingCapability bit set, the MN must immediately revert back to the active state and indicate discontinuation of paging support to the MA during its intra-domain registration process. If the bits are however set, the MN is then free to specify its request for corresponding support to the MA. The MN MAY choose not to avail of one or more of the currently advertised services. However, nodes in a cellular environment that require both low latency handoffs and power conservation SHOULD utilize the corresponding services, if they are advertised in the Router Advertisement messages. 5.2 Local (Subnet) Registration Whenever the MN moves into a different subnet, the MN must first obtain a new valid care-of address before it can update its MA with this address. In the SA mode, obtaining a new care-of address requires completing a successful registration with the new SA. During this registration process, the SA creates an entry binding the MN's permanent home address(or any other unique identifier, in case the MN does not have a permanent home address, as discussed earlier) to the MN's layer-2 address. Packets tunneled to the SA are decapsulated and then forwarded to the MN using this cache. The IDMP message formats and processing rules for subnet registration in the SA mode are very similar to the registration process in Mobile IP, except that the MN must now explicitly register with the SA. 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 |S|B|D|M|V|O|P|N| Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Unique Permanent ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Local Care-of Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Global Care-of Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Identification + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Extensions ... +-+-+-+-+-+-+-+- Expires January 2001 [Page 23] Internet Draft IDMP July 2000 Figure 8 IDMP Subnet Registration Request Packet Format The above figure illustrates the format of the Registration Request message sent from the MN to the SA. IDMP consciously uses semantics and packet formats similar to the Mobile IP registration process. In addition to the standard Mobile IP fields and bits, IDMP also adds the following additional bits and fields. * P: Paging Request bit indicates that the MN is registering in an idle mode. * N: NewRegistration bit: Setting this bit to 1 indicates that the MN is requesting a complete Intra-Domain registration process. The MN typically sets this bit to 1 only for its first registration in the new domain. * O: FastHandoff bit: This bit replaces the GRE encapsulation bit in Mobile IP's registration request message. Since IDMP does not involve registration with the Home Agent, we reuse this bit to indicate that the MN is requesting fast handoff support from the Subnet Agent. Since IDMP is designed for operation with global mobility architectures where the MN may not have a permanent home address, it does not specify a separate field for the Permanent Home Address. On the contrary, it re-designates this field as a Unique Permanent ID; when operating in conjunction with Mobile IP, this field will indeed be the permanent home address. Also, since IDMP does not explicitly assume Mobile IP as the global mobility management protocol (and also because the SA does not require the MN's Home Agent address), the Home Agent Address field in Mobile IP's Registration Message field has been deleted. The exact security and authentication framework for the various registration phases are being deferred to a subsequent draft. We do expect additional security related fields to be a part of the Extensions field. In Mobile IP, the Identification field is used for replay protection between the HA and the MN. In IDMP, there are three distinct and registration processes. Each process uses its own Identification field to maintain sequencing between the respective nodes and avoid replay protection. For example, in the subnet-specific registration process, an Identification field is defined between the MN and the SA. Both the other registration processes (the intra-domain and global registrations) will have their own independent Identification field. 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 |P|N|O| Code | Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Unique Permanent ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Local Care-of Address | Expires January 2001 [Page 24] Internet Draft IDMP July 2000 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Global Care-of Address (MA) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Identification + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Extensions ... +-+-+-+-+-+-+-+- Figure 9 IDMP Subnet Registration Reply Packet Format The packet format for registration replies is shown in figure 9 and is borrowed from the Registration reply format for Mobile IP. The reply specifies the local care-of address and the global care-of address. This global care-of address is really the MA address; to obtain a unique GCOA (GC mode of IDMP), the MN MUST separately request a global address from the MA. Since the IDMP SA MUST indicate its support for requested services in its registration reply, the Code field has been reduced to 5 bits. The P bit indicates support for paging, the N bit indicates that this reply is in response to a new intra-domain registration request (requesting a new MA) and the O bit indicates support for fast handoffs. As with the Registration Request message, additional security-related extensions are expected to be defined in subsequent drafts. 5.2.1 Mobile Node Considerations When the MN hears agent advertisements from an SA and chooses to register with it, it sends the Registration Request to the SA. If the MN realizes that it is in a new domain or mustre-initiate registration in that domain, it MUST set the N bit. The foreign agent processes the Registration Request and then responds to the MN. Since IDMP distinguishes the subnet-specific registration mechanism from the intra-domain registration mechanism, the MN must maintain separate 64 bit Identification for matching registration replies from the Subnet Agent and the Mobility agent. The use of this 64 bit Identification field is exactly similar to that envisaged in the basic Mobile IP operation. If the MN has set the N bit to 1 in the Registration Request, it MUST use the global care-of address field specified in a successfully accepted Registration Reply as its new care-of address. If the MN had not set this bit to 1, the MN should ignore this field and SHOULD NOT replace its current care-of address with this new address. The MN MUST use the P and O bits to determine whether its requests for paging and fast handoff support have been accepted. If any of these requested featuers have been rejected by the SA, the MA MUST not specify such support in its subsequent intra-domain registration with the Mobility Agent. 5.2.2 Subnet Agent Considerations Expires January 2001 [Page 25] Internet Draft IDMP July 2000 In general, IDMP's Subnet Agents process Registration Requests from MNs in the same manner as Mobile IP's Foreign Agents. The key difference is that the SA is now also responsible for distinguishing between requests from MN's that enter this domain for the first time and other mobile nodes that have already been assigned an MA in this domain. This is achieved through the use of the N (NewRegistrationBit) in the Registration Request message. If this bit is set to 1, the SA MUST verify that the global care-of address field is set to 0 and then return an appropriate global care-of address in the corresponding Registration Reply. The SA must also set the P and O bits appropriately in its registration reply. If the P bit is set to 1 in the Registration Reply, then the SA MUST be willing to provide paging support by becoming a member of the appropriate Paging Area. The SA MUST NOT set the P bit to 1 if the MN has set it to 0 in the corresponding Registration Request message. Identical rules apply for the O bit as well. During operation with fast handoff support, the SA may need to buffer packets for an MN. These packets are multicast to it by the MA during the change of subnets by the MN. In this case, upon successful completion of the subnet-registration phase, the SA must check its source-specific buffers to determine if there are any packets addressed to the current MN (using its permanent home address as the indexing field). If such packets are found, the SA MUST transmit such packets immediately after sending out a RegistrationReply that acknowledges a successful registration request. The paging functionality does not impose any additional processing on the Subnet Agents. Consequently, all SAs SHOULD support paging i.e., have the ability to receive multicast PageSolicitation packets and broadcast them on the appropriate interface(s) that it manages. Furthermore, receipt of a Registration request that indicates request for paging MUST not be used as a sole reason for denying an otherwise valid subnet-specific Registration Request. 5.3 Intra-Domain (MN-MA) Location Update After obtaining a local care-of address, the MN must perform a location update with its designated MA. Since the essentials of the MN-MA location update are very similar to an MN-SA subnet-specific registration, the packet formats and processing rules are very similar. The MA, however, has to perform significant additional functionality to provide support for various IDMP features. The MA is the nodal point responsible for providing fast handoff and paging support and consequently retains greater control over the responses to new registration requests. 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 |S|D|*|G|I|O|P|N| Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Expires January 2001 [Page 26] Internet Draft IDMP July 2000 | Unique Permanent ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Local Care-of Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Global Care-of Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Remote Agent Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Identification + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Extensions ... +-+-+-+-+-+-+-+- Figure 10 IDMP Intra-Domain Location Update Packet Format The format for Location Update packets transmitted by the MN to the MA is shown in figure 10. While largely similar to Mobile IP, the bits for Minimal and GRE encapsulation and for BroadcastDatagrams have been replaced, since such operations are best performed either by the HA or by the subnet-specific SA respectively. Those bits have been replaced by two additional bits: * O: FastHandoff bit is set to 1 by the MN to indicate that it requests Fast Handoff support from its MA. * P: PagingRequest bit is set to 1 by the MN to request Paging support from the MA. * N: NewRegistration bit is set to 1 by the MN to indicate that this is a completely new Intra-Domain registration. * I: IdleState bit is set to 1 by the MN to indicate that it is currently in an Idle State. If both this bit and the PagingRequest (P) bit are set to 1, then the MA MUST interpret this to indicate a request for paging support and should then buffer incoming packets and broadcast a PageSolicitation for the MN. * G: GlobalAddress bit is set to 1 by the MN indicate a request for the Glocal Co-located (GC) addressing mode of IDMP. One bit is presently unused and could be specified for additional IDMP-based mobility support in subsequent drafts. Additionally, the MA-MN location update also specifies a separate field, the Remote Agent Address field. This field can be used to inform the MA about a prospective target for the global registration message. For example, a mobile using Mobile IP as the global registration protocol should set this field to the address of its Home Agent. Specifying this address also provides the flexibility for the MA to perform appropriate authentication and authorization functions with this remote agent. If the MN does not wish to provide a valid Remote Address field, it MUST set this address field Expires January 2001 [Page 27] Internet Draft IDMP July 2000 to 0. 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 |P|N|O|G|I| Code | Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Unique Permanent ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Local Care-of Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Global Care-of Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Remote Agent Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Identification + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Extensions ... +-+-+-+-+-+-+-+- Figure 11 IDMP Intra-Domain (MA-MN) Update Response Packet Format Figure 11 shows the packet format for the intra-domain update response sent by the MA to an MN in response to a location update request. The P, N, O, G and I bits are necessary to indicate the MA's response to the corresponding request by the mobile node. For example, if the G bit is set, the MN MUST assume that it is operating in the GC mode and that it has its unique global care-of address. To provide space for these additional bits in the same packet format, the Code field in the registration response packet has been reduced to 6 bits. Also, in contrast to the subnet-specific registration response packet, the intra-domain update response packet contains the address of the remote agent specified in the update request as well. 5.3.1 Mobility Agent Considerations When the N (New Registration) bit is set, the MA MUST interpret this as a request for registration by an MN that has newly entered the domain. The MA MUST verify that the global care-of address field is set to 0 in all such new requests and must generate a new global care-of address (either in MA or GC mode, depending on the G bit), for the MN in its corresponding Registration Reply. In case of a new registration, the MA MUST not use any previous Identification field values used in any previous association with the MN, but MUST generate a new 64 bit number for sequencing. Whenever a new registration is requested, we expect the MA to perform additional authentication and authorization function as part of the security framework. Details of such functions are largely outside the scope of IDMP. However, we do expect that additional security extensions, for example, based on public-key exchange algorithms, will be specified as Extensions to the basic location update packet format in future IDMP drafts. When the MA Expires January 2001 [Page 28] Internet Draft IDMP July 2000 responds to a Location Update Request, IT MUST NOT set to 1 any of the G, P, I or O bits, unless it provides support for the corresponding function. Detailed processing rules for each of the registration and location update phases will be provided in the next draft. 6. Security Considerations IDMP borrows the ideas of replay protection and security associations from Mobile IP. It currently appears that IDMP has the same security considerations as Mobile IP. More detailed security considerations are expected to be specified in future versions of this draft. Since IDMP is an intra-domain protocol, practical use of this protocol will require use of an additional global mobility management mechanism as well. For example, it is anticipated that the Mobility Agent will perform additional authentication and authorization functions when a Mobile Node first registers in that domain. While such functions are not part of IDMP, they may very well require support in the form of additional fields in IDMP messages. Such fields SHOULD be specified as Extensions to the basic IDMP format. 7. Acknowledgements Part of the work on IDMP specification and the TeleMIP architecture for mobility management was funded by the U.S. Army Research Laboratory (ARL) under the Advanced Telecommunications and Information Distribution Research Program (ATIRP) Consortium. The authors also acknowledge the contribution of Kaushik Chakraborty in implementing the initial version of IDMP. Ashutosh Dutta wishes to acknowledge Henning Schulzrinne of Columbia University for many helpful discussions regarding the use of IP multicasting in mobility management. 8. Intellectual Property Considerations Telcordia may seek patent or other intelectual property protection for some of the technologies specified in this document. If any standards arising from this discolsure are or become protected by one or more patents assigned to Telcordia Technologies, Telcordia intends to disclose those technologies and license them on reasonable and non-discriminatory terms. Future revisions of this draft may contain additional information on intellectual property protection sought or received. References 1. A. Campbell, J. Gomez, C-Y. Wan, S. Kim, Z. Turanyi and A. Valko, "Cellular IP", Internet draft, , January 2000, Work in progress. 2. R. Ramjee, T. La Porta, S. Thuel and K. Varadhan: "IP micro- mobility support using HAWAII", Expires January 2001 [Page 29] Internet Draft IDMP July 2000 , June 1999, Work in progress. 3. E. Gustafsson, A. Jonsson and C. Perkins, ``Mobile IP regional tunnel management', , IETF, March 2000, Work in Progress. 4. Perkins, C., Editor: "IP Mobility Support", RFC 2002, October 1996. 5. S. Das, A. Misra, P. Agrawal, and S.K. Das, ``TeleMIP: Telecommunication enhanced mobile IP architecture for fast intra-domain mobility,'' To be published in IEEE Personal Communications, August, 2000. 6. A. Misra, S. Das, A. Dutta, and S. K. Das, "Supporting fast intra-domain handoffs and paging with TeleMIP in next-generation cellular networks", Communicated to INFOCOM 2001, to be held in April 2001. 7. H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson, ``RTP: A Transport Protocol for Real-time Applications'', RFC 1889, January, 1996. 8. M. Handley, H. Schulzrinne, E. Schooler, J. Rosenberg, "SIP: Session Initiation Protocol," RFC 2543, March 1999 9. E. Wedlund and H. Schulzrinne, "Mobility Support using SIP", Proc. of second ACM International Workshop on Wireless Mobile Multimedia (WOWMOM'99), August, 1999, pp 76-82. 10. R. Droms, `` Dynamic Host Configuration Protocol,'' Request for Comments 2131, Mar 1997. 11. A. Mcauley, S. Das, S. Baba abd Y. Shobatake, ``Dynamic Registration and Configuration Protocol (DRCP)'', , July 2000, Work in progress. 12. A. O'Neill, G. Tsirtsis, and S. Corson, ``Edge mobility architecture'', , IETF, Mrach 2000, 2000, Work in progress. 13. Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels," RFC-2119, March 1997. 14. K. El Malki and H. Soliman, 'Hierarchical Mobile IPv4/v6 and Fast Handoffs', , IETF, March 2000, Work in Progress. 15. C. Castelluccia, ``HMIPv6: A Hierarchical Mobile IPv6 Proposal'', ACM Computing and Communication Review (MC2R), April 2000. 16. J. Kempf, P. Calhoun and C. Pairla, ``Foreign Agent assisted hand-off'', , June 2000, Work in progress. Expires January 2001 [Page 30]