INTERNET-DRAFT M. Liebsch G. Renker NEC Network Laboratories Europe Expires December 2001 June 2001 Paging Concept for IP based Networks Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 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/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Abstract This document defines an IP paging concept that supports a registered idle state of a mobile node and coordinates paging independent of the underlying layer-2 medium. The concept specifies a generic protocol that allows to abstract away from layer-2 paging capabilities up to the Access Routers, providing wired or wireless network access to idle mobile terminals. A new entity, called Paging Agent, is introduced. This Paging Agent supports employment of several different paging strategies. The reference mobility architecture of this specification is Mobile IPv6. Avoiding modifications of Mobile IPv6 entities, the paging concept integrates modularly into the mobility environment. Liebsch, Renker [Page 1] INTERNET-DRAFT Paging Concept for IP based Networks June 2001 Table of Contents 1 INTRODUCTION 4 1.1 General Overview . . . . . . . . . . . . . . . . . . . . . . 4 1.1.1 General Scheme of a Paging Process . . . . . . . . . . 4 1.1.2 Mobility Background . . . . . . . . . . . . . . . . . . 4 1.1.3 Concept Summary . . . . . . . . . . . . . . . . . . . . 4 1.1.4 Role of the Paging Strategy . . . . . . . . . . . . . . 5 1.2 Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 1.3 Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . 6 2 TERMS 6 2.1 Key Words . . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.2 Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 3 BASIC MECHANISM 8 3.1 Paging Principle . . . . . . . . . . . . . . . . . . . . . . 8 3.2 Classification of Access Media . . . . . . . . . . . . . . . 9 3.3 Paging Strategies . . . . . . . . . . . . . . . . . . . . . . 9 3.3.1 Blanket Polling . . . . . . . . . . . . . . . . . . . . 9 3.3.2 Shortest-Distance-First . . . . . . . . . . . . . . . . 10 3.3.3 Sequential (Group) Paging . . . . . . . . . . . . . . . 10 3.3.4 Adaptive Individual Paging . . . . . . . . . . . . . . 10 3.3.5 Other Paging Strategies . . . . . . . . . . . . . . . . 10 3.3.6 Optimization. . . . . . . . . . . . . . . . . . . . . . 10 3.4 Network Model . . . . . . . . . . . . . . . . . . . . . . . . 10 3.4.1 Entities. . . . . . . . . . . . . . . . . . . . . . . . 10 3.4.2 Mapping Functions . . . . . . . . . . . . . . . . . . . 11 4 PAGING AGENT SPECIFICATION 11 4.1 Core Tasks of the Paging Agent. . . . . . . . . . . . . . . . 12 4.2 Additional Functionality. . . . . . . . . . . . . . . . . . . 13 4.3 Paging Agent Redundancy . . . . . . . . . . . . . . . . . . . 13 4.4 Internal Realization of Paging Strategies . . . . . . . . . . 14 5 STATE REGISTRATION AND MAINTENANCE 14 5.1 Conditions to Enter Idle State. . . . . . . . . . . . . . . . 14 5.1.1 General Consideration . . . . . . . . . . . . . . . . . 14 5.1.2 Problems Regarding On-Link Neighbors. . . . . . . . . . 15 5.2 Idle State Registration at the Paging Agent . . . . . . . . . 15 5.2.1 Mobile IP - specific part of the registration . . . . . 16 5.2.2 Implicit Idle State Registration. . . . . . . . . . . . 17 5.2.3 Idle State Registration using MIPv6 Messages. . . . . . 18 5.2.4 Explicit Idle State Registration. . . . . . . . . . . . 19 5.2.5 Permanent Registration. . . . . . . . . . . . . . . . . 20 5.3 Idle State De-Registration. . . . . . . . . . . . . . . . . . 20 5.3.1 General State Machine . . . . . . . . . . . . . . . . . 21 5.4 Idle State Registration at Correspondent Nodes. . . . . . . . 21 5.5 Messages for Idle State Registration. . . . . . . . . . . . . 22 5.5.1 Idle State Request Message. . . . . . . . . . . . . . . 22 5.5.2 Idle State Reply Message. . . . . . . . . . . . . . . . 22 Liebsch, Renker [Page 2] INTERNET-DRAFT Paging Concept for IP based Networks June 2001 6 PAGING DORMANT MOBILE NODES 23 6.1 Paging Algorithm of the Paging Agent . . . . . . . . . . . . . 23 6.2 Paging Request Message . . . . . . . . . . . . . . . . . . . . 24 6.2.1 General Message Format . . . . . . . . . . . . . . . . . 24 6.2.2 Sub-Options contained in the Paging Request. . . . . . . 24 6.3 Paging Reply Specification . . . . . . . . . . . . . . . . . . 25 6.4 Mobile Node Paging Address . . . . . . . . . . . . . . . . . . 26 6.4.1 Group Paging Multicast Address . . . . . . . . . . . . . 26 6.4.2 Paging individual mobile nodes . . . . . . . . . . . . . 26 6.5 Distribution Mechanism of Paging Requests. . . . . . . . . . . 27 6.5.1 Tunneling Mode . . . . . . . . . . . . . . . . . . . . . 27 6.5.2 Direct Mode. . . . . . . . . . . . . . . . . . . . . . . 28 7 SERVICE DISCOVERY 28 7.1 Discovery of Paging Capabilities . . . . . . . . . . . . . . . 28 7.1.1 Variant 1: Advertisements in the visited network . . . . 29 7.1.2 Variant 2: Static mobile node configuration. . . . . . . 29 7.1.3 Variant 3: Dynamic Paging Agent Address Discovery. . . . 30 7.2 Message Formats. . . . . . . . . . . . . . . . . . . . . . . . 31 7.2.1 Multiple Discovery Strategies. . . . . . . . . . . . . . 31 8 SOLUTIONS TO REDUCE NETWORK LOAD 31 8.1 Group Paging . . . . . . . . . . . . . . . . . . . . . . . . . 31 8.2 Paging Agent Hierarchies . . . . . . . . . . . . . . . . . . . 32 8.3 Message Support for Sequential Paging. . . . . . . . . . . . . 33 9 ENHANCEMENTS FOR STATIC PAGING AREAS 33 9.1 Rules for Paging Area Deployment . . . . . . . . . . . . . . . 34 9.2 Roaming In Static Paging Areas . . . . . . . . . . . . . . . . 34 9.2.1 Movement Detection in Static Paging Areas. . . . . . . . 34 9.2.2 Paging Area Configuration. . . . . . . . . . . . . . . . 34 9.3 Support for Overlapping Paging Areas . . . . . . . . . . . . . 35 9.3.1 Non-Overlapping static Paging Areas. . . . . . . . . . . 35 9.3.2 Overlapping static Paging Areas. . . . . . . . . . . . . 35 9.4 Deployment of Multicasting . . . . . . . . . . . . . . . . . . 37 9.5 Flexible Remote Configuration of Access Routers. . . . . . . . 38 10 SECURITY CONSIDERATIONS 39 10.1 Mobile Node Aspects . . . . . . . . . . . . . . . . . . . . . 39 10.2 Paging Agent Aspects. . . . . . . . . . . . . . . . . . . . . 40 10.3 Foreign Network Aspects . . . . . . . . . . . . . . . . . . . 41 11 IANA CONSIDERATIONS 11.1 Message Formats . . . . . . . . . . . . . . . . . . . . . . . 41 11.2 Addresses Used. . . . . . . . . . . . . . . . . . . . . . . . 42 12 PROTOCOL CONSTANTS 42 13 OPEN ISSUES 43 A REFERENCES 44 Liebsch, Renker [Page 3] INTERNET-DRAFT Paging Concept for IP based Networks June 2001 B AUTHOR'S ADDRESSES 46 1 INTRODUCTION 1.1 General Overview Following the reasoning in favor of IP paging in [Sea-Prob], this document specifies an IP paging solution that allows to coordinate paging independent of the underlying layer-2 medium. A new entity called Paging Agent manages paging-related functionality, its scope may extend several administrative domains. This feature is called inter-domain paging. To allow an optimized operation, the specification of Paging Agent and the paging strategy it deploys is kept separately. The paging strategy is seen as module deployed by the Paging Agent and can be selected according to individual needs and paging policy. 1.1.1 General Scheme of a Paging Process A paging process is typically initiated by incoming data for an idle mobile node. A set of one or more locations (Paging Area) is determined, with a given probability that the user can be found in this Paging Area. In each search iteration or polling cycle request messages are sent to all of the locations that make up the Paging Area. Idle mobile nodes are capable of receiving these paging request messages, only the target mobile node sends a response message to the paging initiator. If several polling cycles are used, there is a timeout between each iteration. The paging process terminates if the target mobile node responds within the timeout. Otherwise, a new Paging Area is chosen for the next polling cycle. The maximum search time to page a mobile node is limited by system resources (maximum available buffer space for incoming data) and by communication parameters as e. g. the timeout values of a TCP connection initiation [RFC 793]. Therefore, a delay constraint exists and the search must be finished within a given time limit. 1.1.2 Mobility Background This concept uses Mobile IPv6 [JoPe00b] as reference mobility protocol. Mobile nodes autoconfigure co-located care-of addresses on foreign networks and register these with their Home Agents. Correspondent nodes send packets to the Home Address of a mobile node, on its Home Network. The Home Agent on the Home Network of the mobile node intercepts these packets, which are then tunneled to the visited network of the mobile node. Alternatively, Route Optimization [JoPe00b, sec. 2] can be used. 1.1.3 Concept Summary Paging is initiated by a separate Paging Agent. This agent uses Liebsch, Renker [Page 4] INTERNET-DRAFT Paging Concept for IP based Networks June 2001 solely IP as signaling layer. The mapping of protocol signaling to layer-2 specific signaling takes place at the Access Router, it is the only node where the specifics of a L2 medium are taken into account. This mapping, if needed at all, is provided by a medium- specific mapping function. 1.1.4 Role of the Paging Strategy As the performance of a paging implementation depends on the specific strategy it deploys, emphasis is placed on how to make paging more efficient. A good paging strategy should therefore comply with the following objectives: * minimize paging signaling load, i.e. the total number of locations that are polled * perform successfully under given delay constraints * minimize paging delay, i.e. the number of polling cycles * reduce activity of an idle mobile node related to updating location information Another aspect is multiuser performance, investigated inter alia in [Ro97]. 1.2 Goals This is a list of design goals for the design process of the paging service: * a simple solution which will possibly cooperate with different environments * not that kind of simplicity that forbids future extensions / scalability * KISS: Keep It Simple, Scalable * make no assumptions about the underlying network structure to support as many scenarios as possible (as in [Clark88]) * if additional intelligence is required, put it in the endpoints, e. g. delivery of statistical user information is handled by the mobile node * as little change to MIPv6 as possible, if e. g. communication is relayed through the Paging Agent, route optimization should still be possible * modular construction, i. e. keep paging separate from MIPv6 Liebsch, Renker [Page 5] INTERNET-DRAFT Paging Concept for IP based Networks June 2001 * be prepared for inter-domain paging (this is a problem not addressed by existing Internet proposals) * keep possible extensions in mind (e. g. user profiles, individual adaptive paging, centralized management) 1.3 Assumptions The paging concept requires modifications or extensions of Access Routers, to what extent is discussed below. No changes are however intended to correspondent nodes and Home Agent, i. e. only the mobile node and the paging service are aware of the idle mobile node state. Regarding binding lifetimes, the Lifetime field of the Binding Update [JoPe00b, p. 21] is 32 bit long. If the Home Agent puts no limitation on the maximum binding lifetime, a long-time idle state is enabled at the Paging Agent during which there is no need for a refresh of the Home Agent binding. Otherwise, more frequent refreshes of the Home Agent binding will become necessary during the idle state of the mobile node. 2 TERMS 2.1 Key Words 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. 2.2 Terminology For terms specifically related to Mobile IP, please see [JoPe00b, sec. 3]. In terms of paging, this document tries to be as close to the paging problem statement [Sea-Prob] and the list of Seamoby terms [Sea-Term] as possible. To resolve ambiguities, however, the following terms are defined for the context of this document. Access Router a router that provides access to a (potential) L2 connection to the mobile node Active State mobile node state, mainly characterized by the following characteristics: 1. an established L2 connection 2. the communication peer of mobile node knows the currently configured IP address of the MN 3. the L2 connection is used to carry L3 data traffic Liebsch, Renker [Page 6] INTERNET-DRAFT Paging Concept for IP based Networks June 2001 Black Hole packet loss without any control of the system COA Care-Of Address COCOA Co-located COA Connection established L2 connectivity, providing transport service for L3 traffic L2 layer 2 L3 layer 3 Idle State mobile node state, mainly characterized by: 1. less frequent location updates 2. network-maintained location information is less accurate than in Active State 3. the MN is not currently involved in an ongoing L3 communication IMSI International Mobile Subscriber Identity Inter-Domain Paging paging across multiple administrative domains Inter-System Paging paging over several different (L2) technologies Inter-Technology Paging see Inter-System Paging Intra-Domain Paging paging confined to a single administrative domain IPSec Security Architecture for the Internet Protocol (RFC 2401) Location smallest indivisible unit at which a mobile node can be located (e.g. a single base station) Liebsch, Renker [Page 7] INTERNET-DRAFT Paging Concept for IP based Networks June 2001 MN mobile node MSL Maximum Segment Lifetime (RFC 793) Paging Area in this context used as general term to describe a set of 2 or more locations likely to be polled in the paging process; see also Predefined Paging Area Paging Strategy the order and mode of how a set of Locations is polled to locate an idle mobile node PAI Paging Area Identifier, used to identify a Static Paging Area Polling Cycle single step of a paging search phase Predefined Paging Area statically grouped set of locations, manually configured by an operator for paging purposes Static Paging Area see Predefined Paging Area Unreachable Mobile Node MN, whose location can not be resolved for the purpose of routing L3 data traffic to it 3 BASIC MECHANISM 3.1 Paging Principle To make protocol operation independent of the specific architecture, a separate Paging Agent entity is used, rather than a modified Mobile IPv4 Foreign Agent [RFC 2002]. The principle of the paging process is in this context: 1. a mobile node registers idle state with the separate Paging Agent. 2. the Paging Agent is responsible for localizing a registered idle mobile node once data starts to arrive for this mobile node. 3. the paging process terminates once the mobile node re-enters active state by restoring exact routing information, gets ready Liebsch, Renker [Page 8] INTERNET-DRAFT Paging Concept for IP based Networks June 2001 for incoming data and indicates this readiness to the Paging Agent. This concept uses explicit paging, i.e. exchange of a Paging Request and a Paging Response message to page dormant mobile nodes. Implicit paging utilizes user data to page mobile nodes, only Cellular IP [CIPv6, sec. 2.1] is known to employ this kind of paging. 3.2 Classification of Access Media For further clarification we refer to use the categories of layer-2 media according to available L2 support for idle state and paging. These classifications relate to the differentiation of layer-2 media in [Sea-Prob, sec. 3.1 and 3.2], augmented by a L2 medium class without support for paging and idle state. This is summarized in the table below. +------+-------------------------------------+-------------+ |class | characteristics | example | +------+-------------------------------------+-------------+ +------+-------------------------------------+-------------+ | 1 | no support for idle state or paging | Ethernet | +------+-------------------------------------+-------------+ | 2 | support for idle state only | IEEE 802.11 | +------+-------------------------------------+-------------+ | 3 | support for idle state AND paging | UMTS, GSM | +------+-------------------------------------+-------------+ The three abstract classes discussed here are used as starting point to develop the basic entities. To support different layer-2 media, mapping functions are introduced as described in section 3.4.2. 3.3 Paging Strategies Most paging proposals only support one single paging strategy, classified below as Blanket Polling. A cost analysis of this strategy shows that it is only sub-optimal [Ro97]. We argue that it is important to support different paging strategies, which are listed below. The list is extensible, several other strategies are discussed in [Wong00]. 3.3.1 Blanket Polling This strategy uses predefined Paging Areas (see section 2.2), made up by the radio coverage area of one or more Access Routers. The network knows only the current Paging Area of the MN, possibly using Paging Area Identifiers (PAI). When paging idle mobile nodes, all cells of a Paging Area are polled simultaneously. For example, regarding the media classes described above, broadcast (multicast) could be used in a class 1 medium or a Paging Channel in a class 3 medium. Liebsch, Renker [Page 9] INTERNET-DRAFT Paging Concept for IP based Networks June 2001 3.3.2 Shortest-Distance-First [Wong00] This requires cartographic information at the Paging Agent. Paging starts in the cell that was last registered by the mobile node, then all neighboring cells of this cell are polled, after that the neighboring cells of the neighboring cells are polled and so on. 3.3.3 Sequential (Group) Paging [Ro95] A list of user location probabilities is used, sorted in decreasing order of probability. The list elements, pointing to Paging Areas or single access routers, are polled sequentially, hence the name. The analysis in [Ro95] has proven that Sequential Paging minimizes the signaling cost over all choices of a set of locations. Sequential Group Paging is an optimization that reduces the paging delay, still resulting in signaling cost reductions of at least 50%, even under delay constraints. 3.3.4 Adaptive Individual Paging [Cast99] The mobile node dynamically generates a working set of access routers it considers as the best possible current Paging Area. The mobile node communicates the members of this individual Paging Area to its Paging Agent. This dynamic Paging Area will be used to page an idle mobile node. 3.3.5 Other Paging Strategies An idea not fully specified is paging based on global coordinates determined by GPS (Global Positioning System), an idea is mentioned in [RFC 2009]. Several other different paging strategies are discussed in [Wong00]. 3.3.6 Optimization Group Paging (or 'Ensemble Polling[Ro97]') can be used as an optimization, whereby several idle mobile nodes are paged simultaneously. This allows a better multiuser performance and load control. Also, paging delay can be reduced. Group paging has successfully been employed by GSM. 3.4 Network Model 3.4.1 Entities +----+ +----+ +----+ | PA |------------>| AR |----------->| MN | +----+ +----+ +----+ PA = Paging Agent, AR = Access Router Liebsch, Renker [Page 10] INTERNET-DRAFT Paging Concept for IP based Networks June 2001 Although no assumptions are made about the general network topology, this concept focuses mainly on two nodes: 1. the separate Paging Agent which controls the L3 paging functionality. 2. the router that provides access to a (potential) L2 connection with the mobile node, called Access Router in this context To page a mobile node on layer-3, a layer-2 connection will be necessary. If the (prospective) L2 connection to the mobile node is IP-addressable via an interface of the Access Router, then this interface address will have the same subnet prefix as the (prospective) care-of address of the mobile node. Furthermore, in some paging strategies such as Adaptive Individual Paging [Cast99] mobile nodes report IP-addresses of access routers to the Paging Agent. A mobile node can only collect the information directly available on its link. The recorded interface IP address will at the same time point to a potential endpoint of a layer-2 connection with the mobile node. Consequently, the Paging Agent of this specification addresses for paging purposes precisely the one interface of a Access Router at which a (prospective) layer-2 connection to the mobile node terminates. 3.4.2 Mapping Functions The Paging Agent uses IP for paging purposes. To page a mobile node, a mapping of layer-3 signaling to layer-2 might be necessary to take L2-specific details into account. This is provided by a mapping function in the Access Router. The simplest possible mapping function is that of a Neighbor Cache entry [RFC 2461, sec. 5.1], mapping IP addresses to link-layer addresses. If paging is already supported on layer-2, this fact SHOULD be taken into account by the specific mapping function. The paged mobile node receives either a layer-2 paging signal or an IP paging request packet, both SHOULD cause re- entering active state. 4 PAGING AGENT SPECIFICATION The Paging Agent is implemented as separate entity, its service can be confined to a single network or across multiple networks. Liebsch, Renker [Page 11] INTERNET-DRAFT Paging Concept for IP based Networks June 2001 +----+ +----+ | CN |----------->| HA | +----+ +----+ | | | Tunnel to Paging Agent | registered as alternate COA v +----+ | PA | +----+ | | | Paging Request +---------+---+----+---------+ | | | | +---- | ------- | ------ | ------- | ----+ | v v v v | | +----+ +----+ +----+ +----+ | | | AR | | AR | | AR | | AR | | | +----+ +----+ +----+ +----+ | | /|\ /|\ /|\ /|\ | | | | +----+ | | |idle| | | | MN | | | +----+ | | Paging Area | +----------------------------------------+ 4.1 Core Tasks of the Paging Agent To provide paging service for idle mobile nodes, the Paging Agent SHALL implement the following core tasks: 1. it has to maintain the idle state of the mobile node. This information about the mobile node SHOULD be stored: the Home Address, address of the Home Agent, last COA, current mobile node state, remaining binding lifetime and possibly a Paging Area ID. The list is extensible. 2. depending on the paging strategy, specific information about the network in which the mobile node has to be localized SHALL be stored (see discussion about paging strategies in section 3.3). 3. the paging process is initiated by the Paging Agent. In general, this requires to poll a set of several access routers with a message that is able to uniquely identify the mobile node, either by including its Home Address or a similarly unique identifier. The search algorithm, number and sequence of Liebsch, Renker [Page 12] INTERNET-DRAFT Paging Concept for IP based Networks June 2001 polled access routers depend on the specific paging strategy. 4. queuing of incoming data for idle mobile nodes up to a configurable limit MUST be enabled. The Paging Agent SHOULD first check, if incoming data is addressed to a mobile node that is registered with it. If not, it SHOULD send an ICMP Destination Unreachable message. 5. once the paged mobile node indicates that it has re-entered active state, the Paging Agent MUST update information about the mobile node and forward any buffered data. 4.2 Additional Functionality Over and above the core tasks, additional functionality can be provided by an extensible Paging Agent: 1. database facilities to store daily usage and movement statistics for individual user profiles. 2. automated functions to evaluate statistical data necessary to generate individual user profiles. 3. a user-interface to allow users to modify their individual user profiles, possibly via a web browser. 4. storage of long-term cryptographic keys for certified and registered users, providing enhanced security. 5. a management subsystem that allows configuration of the current policy, i. e. paging strategy, user authentication etc. 6. if predefined, static Paging Areas are used, provision of a centralized management system for remote configuration of access routers. All functionality MAY be implemented in a distributed or centralized manner. Tasks can also be split up between several entities, the core functions e. g. could be provided by the Paging Agent, while enhanced and management functions could be placed on a separate, OPTIONAL Paging Server, possibly serving several Paging Agents at a time. 4.3 Paging Agent Redundancy One centralized Paging Agent introduces a single point of failure. Therefore, mirroring of Paging Agents is considered, introducing a redundancy of at least one. The realization employs IPv6 Anycasting, both original and mirroring Paging Agent have the same anycast address [RFC 2373, sec. 2.6]. If one of the Paging Agents fails, the other will still be reachable under the same common address. In the simplest case of mirroring the configuration data is simply copied Liebsch, Renker [Page 13] INTERNET-DRAFT Paging Concept for IP based Networks June 2001 from one server to another. To automate this process, agents could be arranged like primary and secondary DNS servers [RFC 1034]; one 'authoritative' Paging Agent would periodically update information in the other, similar to the zone transfer protocol of the DNS. This is future work. 4.4 Internal Realization of Paging Strategies Paging state information for mobile nodes is stored in a system of tables at the Paging Agent. Depending on how data tables are interrelated with another, several possibilities of paging service are possible: * if static Paging Areas are used, only the bindings - Home Address ==> Paging Area - Paging Area ==> {[AR_1], [AR_2], ... [AR_N]} are stored. AR_1 ... AR_N are the access routers belonging to the current Paging Area of the mobile node. * alternatively, if Adaptive Individual Paging [Cast99] is to be used, the mobile node could communicate a list of Access Routers it considers as its best possible paging area to the Paging Agent. The only internal difference between regular and adaptive paging is that the Paging Agent uses dynamic lists instead of static lists. A special extension of the Idle State Request message (section 5.5.1) SHOULD be used to indicate this paging mode to the Paging Agent and to accommodate the list of Access Routers. Thus, a Paging Agent can offer both static and dynamic paging service variants. * the sequence of locations in Sequential Paging (sec. 3.3) can be determined by simply sorting the internal list of locations. * the administrative scope of a Paging Agent and the Paging Area topology remain configurable, e. g. one Paging Agent per domain. 5 STATE REGISTRATION AND MAINTENANCE 5.1 Conditions to Enter Idle State 5.1.1 General Consideration Entering idle state is mobile-initiated, that is, the mobile node has to decide by itself when it wants to enter idle state. This requires that it monitors a set of parameters as the state of ongoing communications, number of handovers, average rate of incoming connections etc. Liebsch, Renker [Page 14] INTERNET-DRAFT Paging Concept for IP based Networks June 2001 The first requirement for the transition from active to idle state is that the mobile node has discovered the Paging Agent address according to section 7.1. The second requirement is the absence of ongoing communications. Because of possible packet delays, idle state SHOULD only be entered if for a configurable time T_INACTIVE no traffic from or to the mobile node has occurred. To reuse a tried and tested principle, the mobile node SHOULD set T_INACTIVE to the value of twice the Maximum Segment Lifetime (MSL) of its TCP unit [RFC 793]. Extra attention should be paid to the possibility that Neighbor Caches of on-link neighbors may still have valid entries. 5.1.2 Problems Regarding On-Link Neighbors The mobile node should analyze the state of its communications with great care, as the following consideration about Neighbor Cache entries shows. Generally, the decision if an on-link neighbor is reachable or not is based on state value entries in the Neighbor Cache (NC) and on Neighbor Unreachability Detection, which itself also relies on the NC. The dangerous case occurs if a router or a node on the link still has entries in its Neighbor Cache that indicate reachability of the mobile node, while the latter has already moved on to another link. This case becomes even worse if meanwhile the mobile node has entered idle state and performs no further location updates. A Neighbor Cache entry can be in one of five states [RFC 2461, sec. 7.3.2], but only in the INCOMPLETE and PROBE states an active verification of the cached link-layer address is performed via Neighbor Solicitations. Packets destined to an IP address for which the NC entry reveals REACHABLE state are passed on to the associated link-layer address without any check. This means, if the mobile node leaves a subnet while its default router still has NC entries in the REACHABLE state, all incoming IP packets for the mobile node will be lost until the entry state changes ("black hole"). Entries remain in REACHABLE state for ReachableTime milliseconds after the last confirmation of a neighbor's presence [RFC 2461, sec. 7.3.3]. Concluding, to provide minimal black hole protection, the mobile node SHOULD wait at least ReachableTime milliseconds after its last communication before it enters idle state. This value is contained in the Reachable Time field in local Router Advertisements [RFC 2461, sec. 4.2] or can be calculated on a worst-case basis according to [RFC 2461, sec. 6.3.2]. Accordingly, the time T_INACTIVE SHOULD be set to MAX( ReachableTime, 2 * MSL ). 5.2 Idle State Registration at the Paging Agent The figure below shows the setup for idle state registration, it can be done via the Paging Agent (1) or parallelly (2). Liebsch, Renker [Page 15] INTERNET-DRAFT Paging Concept for IP based Networks June 2001 +-----+ (1) |Home |<----------+ |Agent| | +-----+ | ^ COA | | +------+ | |Paging| | |Agent | | +------+ | ^ ^ (2)| | | | (2)| |(1) | | | | | | | | | | | | +------------------------------+ | | | +--+ +--+ +--+ +--+ | | |AR| |AR| |AR| |AR| | | +--+ +--+ +--+ +--+ | | COCOA | | +--+ | | |MN| | | +--+ Paging Area| +------------------------------+ Idle state registration in the context of correspondent nodes is concerned in section 5.4. Regarding idle state registration with Home Agent and Paging Agent, this document introduces a flexible scheme that can be adapted to a number of different situations. As long as the mobile node is in the idle state, it registers the IP address of the Paging Agent instead of an autoconfigured care-of address with the Home Agent. This makes in fact two registrations necessary before the idle state can be entered. First, the Paging Agent needs a registration of all information that is necessary to page the mobile node, based on the current paging strategy and the set of potential locations in foreign networks where it possibly will be paged. Second, the mobile node needs to register the IP-address of the Paging Agent with its Home Agent. The separation makes it easy to adapt the paging concept to a possible future IP mobility protocol. Therefore the common part of the variant idle state registrations is a regular MIPv6 Binding Update sent from the mobile node to its Home Agent. 5.2.1 Mobile IP - specific part of the registration The source address of this Binding Update is set to the COCOA configured on the current subnet of the mobile node, its Home Address Liebsch, Renker [Page 16] INTERNET-DRAFT Paging Concept for IP based Networks June 2001 is contained in the Home Address Option. To register the IP address of the Paging Agent, which is possibly located on a different subnet, the alternate care-of address sub-option [JoPe00b, sec. 5.5] MUST be used. It is REQUIRED to authenticate the whole packet by mandatory IPSec [JoPe00b, sec. 4.4]. The Home Agent sends back a Binding Acknowledgment containing the registration status (acceptance or rejection), the granted binding lifetime and recommended binding refresh rate. Four possibilities exist to register idle state, the differences lay in the communication with the Paging Agent. 5.2.2 Implicit Idle State Registration This variant enables registration at the lowest cost in terms of messages, while not affecting or modifying authenticated data sent between mobile node and Home Agent. The process is illustrated in the two subfigures below. The mobile node prepares the Binding Update to the Home Agent as it would usually do and inserts a Routing Header, whose first hop is set to the address of the Paging Agent, the final destination is the address of the Home Agent. The authentication sum is generated over the whole (plain text) IP packet, as required by IPSec [RFC 2401]. Positive case: -------------- +------+ +------+ +-----+ |Mobile| |Paging| |Home | | Node | |Agent | |Agent| +------+ +------+ +-----+ | | | | MIPv6 Binding Update (COCOA) | | +----------------------------->| | | Hop 1 of Routing Header | | | | Binding Update (PA COA) | | +-------------------------->| | | Hop 2 of Routing Header | | | | | | MIPv6 Binding Acknowledge | |<---------------------------------------------------------+ | | Upon reception of this packet, the Paging Agent reads the plain text contents, detects the presence of its own address in the Binding Update, retrieves the mobile node Home Address from the packet and updates the information about the mobile node in its internal tables. Afterwards, it passes the packet back to its routing module, which routes it to its final destination. Liebsch, Renker [Page 17] INTERNET-DRAFT Paging Concept for IP based Networks June 2001 The Home Agent receives the packet, authenticates the contents (which have not been modified in transit), creates the binding as appropriate and acknowledges the transaction with the mandatory Binding Acknowledgment. If the status field of a negative Binding Acknowledgment [JoPe00b, p. 25] indicates that a second try could be successful, the mobile node SHOULD try a new registration. Otherwise, it MUST stay in active state and register its current COCOA with the Home Agent and send an Idle State De-Registration message (section 5.3) to the Paging Agent. If the binding was accepted by the Home Agent, idle state MAY be entered. As usual in MIPv6, the granted lifetime for the idle state registration is contained in the Lifetime field of the Binding Acknowledgment (BAck). Negative case: -------------- +------+ +------+ +-----+ |Mobile| |Paging| |Home | | Node | |Agent | |Agent| +------+ +------+ +-----+ | | | | MIPv6 Binding Update (COCOA) | | +----------------------------->| | | Hop 1 of Routing Header | | | | | | | | | Negative Acknowledgment | | |<-----------------------------+ | | (Idle State Reply) | | | | | | | | The second figure above shows rejection by the Paging Agent, which in this case does not forward the Binding Update, but sends an negative acknowledgment in form of the Idle State Reply (sec. 5.5.2) with a negative status code. The mobile node MUST then behave in the same way as described above for the rejection by the Home Agent. 5.2.3 Idle State Registration using MIPv6 Messages This mode is comparable to the first one, messages are sent separately this time. It is suitable for cases where the mobile node can not send plain text Binding Updates or no common security association can be established between the parties mobile node, Paging Agent and Home Agent. Liebsch, Renker [Page 18] INTERNET-DRAFT Paging Concept for IP based Networks June 2001 +------+ +------+ +-----+ |Mobile| |Paging| |Home | | Node | |Agent | |Agent| +------+ +------+ +-----+ | | | | MIPv6 Binding Update (COCOA) | | +----------------------------->|-- |----- | | | T1 | ^ | MIPv6 Binding Acknowledge | | | | |<-----------------------------+-- | | | | | | | | T_reg | MIPv6 Binding Update (PA COA Registration) | | +--------------------------------------------------------->|-- | | ||T2 | | MIPv6 Binding Acknowledgment || v |<---------------------------------------------------------+----- | | The Binding Update (BU) to the Paging Agent contains no alternate COA sub-option, which is however present in the BU to the Home Agent. As the registration affects the reachability of the mobile node, each BU MUST be acknowledged. The mobile node can suggest different idle state timeout values in the BUs it sends to Home and Paging Agent. If the status of both the received Binding Acknowledgments indicates acceptance, idle state can be entered. Otherwise, the mobile node MUST stay in active state and register its current COCOA with its Home Agent. The Binding Updates can be sent almost parallelly, so that T_reg is less than the sum of T1 and T2. 5.2.4 Explicit Idle State Registration This mode uses two new message formats described below, it is required if parameters between Paging Agent and mobile node have to be exchanged. Liebsch, Renker [Page 19] INTERNET-DRAFT Paging Concept for IP based Networks June 2001 +------+ +------+ +-----+ |Mobile| |Paging| |Home | | Node | |Agent | |Agent| +------+ +------+ +-----+ | | | | Idle Mode Request | | +----------------------------->| | | | | | Idle Mode Reply | | |<-----------------------------+ | | | | | | | MIPv6 Binding Update (PA-COA Registration) | +--------------------------------------------------------->| | | | MIPv6 Binding Update Acknowledgment | |<---------------------------------------------------------+ | | As in the cases before, if not both message exchanges acknowledge success, the mobile node MUST stay in active state and register its current COCOA with the Home Agent. 5.2.5 Permanent Registration In this mode, the mobile node only registers the IP address of the Paging Agent with its Home Agent when it decides to enter idle state. This mode is only applicable for certain scenarios. A first prerequisite is that the mobile node has a static configuration for the Paging Agent. The second requirement is that the mobile node MUST NOT enter idle state in networks that do not support paging. A possible case could be if the mobile node stays for a long time in a certain area, where paging is supported by all involved networks. 5.3 Idle State De-Registration Generally, a mobile node re-enters active state by restoring exact routing information [Sea-Prob]. Specifically, in Mobile IPv6 this is achieved by registering the current COCOA with Paging Agent, Home Agent and correspondent nodes, respectively. Two different messages MAY be accepted as Idle State De-Registration message: 1. a MIPv6 Binding Update with zero lifetime (to both Paging Agent and Home Agent) 2. an Idle State Request with zero lifetime, as described in section 5.5.1 (Paging Agent only) These messages can be piggybacked on data the mobile node wants to send [JoPe00b]. De-registration at the Paging Agent helps to reduce Liebsch, Renker [Page 20] INTERNET-DRAFT Paging Concept for IP based Networks June 2001 signaling load caused by outdated state information or possibly bogus correspondent nodes. De-Registration at the Paging Agent is however OPTIONAL, stale entries at the Paging Agent MAY also be removed after a timeout. If the mobile node de-registers at both Home Agent and Paging Agent, it SHOULD de-register at the Home Agent first. 5.3.1 General State Machine The model of the mobile node state machine is: +-- ************ Refresh | * * Binding | * ACTIVE * | * * +-> ************ V ^ | | Register Idle State at PA | | De-Register Idle State at PA Register PAgt-COA with HA | | Binding Update (COCOA) to HA | | V ^ +-- ************ Refresh | * * Binding | * IDLE * | * * +-> ************ 5.4 Idle State Registration at Correspondent Nodes When entering idle state, the question how correspondent nodes should be informed has to be concerned. At the time a mobile node enters idle state, there might still be entries referring to its last COA in Binding Caches of correspondent nodes. The same entries appear in the Binding Update List of the mobile node. Correspondent nodes delete entries once the associated lifetime expires [JoPe00b, sec. 8.3]. As long as such an entry has not yet expired, the mobile node MUST be prepared to receive Binding Requests from correspondent nodes [JoPe00b, sec. 8.6]. Three possibilities exist: 1. idle state is only entered if a communication pause of T_INACTIVE seconds occurs and if the last entry in the Binding Update List [JoPe00b, p. 16] of the mobile node has timed out. 2. the mobile node de-registers each binding at correspondent nodes before entering idle state, i. e. it sends a BU with a zero lifetime to each CN for which it has an entry in its Binding Update List. 3. the mobile node could send Binding Updates with the Paging-Agent-COA also to correspondent nodes. This would complicate idle state management, permitting the mobile node to Liebsch, Renker [Page 21] INTERNET-DRAFT Paging Concept for IP based Networks June 2001 enter idle state while entries in the BU List are still active. All three possibilities SHOULD be configurable. Choices (1) and (2) allow to enter a definite idle state, whereas (3) has the advantage that the overhead of tunneling via the Home Agent is avoided for correspondent nodes initiating a communication. 5.5 Messages for Idle State Registration 5.5.1 Idle State Request Message The format of the Idle State Request message is a Destination Options Header [RFC 2460, sec. 4.6]. Minimally, the following fields MUST be present: * a field for Paging Area IDs if static Paging Areas are part of the current paging strategy. * a container field for a unique identifier, at least one for the International Mobile Subscriber Identity (IMSI) number. * a sequence number field to match requests with replies. * a field to contain the interface ID of the mobile node (minimally 3 bytes, see sec. 6.4.2). * an idle lifetime field, allowing the mobile node to suggest the duration of its idle state registration. 5.5.2 Idle State Reply Message The counterpart to the Idle State Request is also a Destination Options Header. The following fields MUST be present: * a status code field to indicate acceptance or rejection of the registration and to allow a simple error code. * a sequence number field to match replies to requests. * a parameter field to indicate the employed paging strategy via numbers. * a group paging field to contain a group paging multicast address (see 6.4). * a granted idle lifetime field to set a timeout for the idle state registration. Once a security strategy has been applied to the paging scheme, both messages SHOULD be extended to integrate key negotiation. Liebsch, Renker [Page 22] INTERNET-DRAFT Paging Concept for IP based Networks June 2001 6 PAGING DORMANT MOBILE NODES An idle mobile node that wants to send data re-enters active state by performing the procedure described in 5.3. An idle mobile node for which data is coming in at the Paging Agent needs to be paged in order to re-enter active state. Independent of the paging strategy, paging is initiated by the Paging Agent, which generates a Paging Request message that uniquely identifies the mobile node. This message is distributed to (several) Access Routers and in the successful case finally reaches the mobile node. The paging process terminates after the mobile node has re-entered active state and has indicated this transition to the Paging Agent, or if the idle mobile node could not be located after one or more timeouts and retransmissions of the Paging Request. This section specifies the paging algorithm, messages used to page a mobile node, the distribution mechanism of the Paging Request from one Paging Agent to multiple Access Routers and the internal mapping functions of the Access Routers. 6.1 Paging Algorithm of the Paging Agent The paging procedure at the Paging Agent is entered when packets for a mobile node arrive. These can be in one of two formats: * packets sent via the Home Agent will be tunneled, the destination address of the inner packet is the Home Address of the mobile node * route optimized packets from correspondent nodes or packets sent by the Home Agent itself [JoPe00b, sec. 9.8.3] contain a Routing Header, whose last destination is the Home Address of the mobile node The Paging Agent first checks the message format. If an error occurs, packets MUST be discarded; the Paging Agent SHOULD send an ICMP error message. After message validation, the Home Address contained in the packet is retrieved and used to look up the entry for the mobile node in internal data tables. If no valid entry exists, the Paging Agent MUST discard the packet and send an ICMP Destination Unreachable message [RFC 2463, sec. 3.1] to the originator. In the successful case, a message queue is allocated to buffer incoming packets while the mobile node is in the process of being paged. The maximum buffer size for incoming data is configured by the parameter MAX_BUFFER, an error function has to be provided for the overflow case (see also [Sea-Req, sec. 3.2]). The Paging Agent generates the Paging Request message (section 6.2) and, depending on the paging strategy, distributes the request to the Access Routers. The distribution mechanism is specified in section 6.5. A timer is then set to the configurable value PAGING_TIMEOUT. If a Liebsch, Renker [Page 23] INTERNET-DRAFT Paging Concept for IP based Networks June 2001 Paging Reply as specified below arrives before the timeout, this timer is stopped and the Paging Agent validates the Paging Reply message. If the validation fails, the Paging Agent MUST send back an ICMP error message and restart the timer. If the validation succeeds, the mobile node state is updated in the internal data tables and the buffered packets are forwarded to the mobile node. The Paging Agent uses IPv6-in-IPv6 encapsulation [RFC 2473] to forward buffered packets, as the mobile node needs the original packet headers to determine the original sender of the message. After the timeout for the Paging Reply occurred, the Paging Request is retransmitted and the timer restarted. Because retransmissions of Paging Requests, each time distributed to a number of Access Routers, can accumulate a high bandwidth consumption, a binary exponential backoff mechanism is applied to the timer value. The Paging Agent discards buffered data after MAX_PRQ_RETRY retransmissions, issues an ICMP Destination Unreachable message to the originator and inhibits new paging processes. New paging processes are inhibited by locking the data entries of the mobile node, for a configurable time of LOCK_TIME seconds. During this time, a new paging process for the mobile node SHALL NOT be started. 6.2 Paging Request Message 6.2.1 General Message Format The purpose of this message is to identify an idle mobile node. A generic format is used and several different identifiers are supported. The generic message format of a Paging Request is a Destination Option Header [RFC 2460, sec. 4.6], which MAY contain one or more sub-options to accommodate specific identifiers. The Paging Request is laid out according to the TLV - format [RFC 2460, sec. 4.2]: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - - | Option Type | Option Length | Option Data +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - - Option Type: a number, to be assigned by IANA. Option Length: length of the option, in octets, excluding the Option Type and Option Length fields. This field MUST be set to the total length of all sub-options present, including their Sub-Option Type and Sub-Option Length fields. Option Data: container field for one or more sub-options. 6.2.2 Sub-Options contained in the Paging Request The sub-options have the same TLV-format as the Paging Request message and are defined in [JoPe00b, sec. 5.5]. Specifically defined Liebsch, Renker [Page 24] INTERNET-DRAFT Paging Concept for IP based Networks June 2001 are sub-options to contain an IPv6 Home Address, a Network Access Identifier (NAI) [RFC 2794] or an International Mobile Subscriber Identity (IMSI) number for cellular networks. The table below shows values for the sub-option fields. The Length value for the NAI is taken from [RFC 2486, sec. 2.4]. +-----+--------+------------------------------+ |Type | Length | Value | +-----+--------+------------------------------+ +-----+--------+------------------------------+ | 1 | 16 | IPv6 Home Address | +-----+--------+------------------------------+ | 2 | 72 | Network Access Identifier | +-----+--------+------------------------------+ | 3 | tbd | IMSI | +-----+--------+------------------------------+ | 4 | 16 | IPv6 Multicast Group Address | +-----+--------+------------------------------+ If the Home Address of the mobile node is an IPv4 address, either the corresponding IPv4-compatible or IPv4-mapped IPv6 address [RFC 2373, sec. 2.5.4] MUST be used. The group paging address is assigned at Idle State Registration (section 5.2). Several identifiers may be present at a time, if e. g. the mobile node has several Home Addresses. 6.3 Paging Reply Specification This message serves to acknowledge that the mobile node has successfully re-entered active state. However, no new message formats have to be defined. Instead, three possibilities of existing messages meet the requirements of a Paging Reply: * Mobile IPv6 Registration a regular MIPv6 Binding Update is capable of indicating the mobile node active state. * Idle State De-Registration any of the De-Registration messages specified in 5.3 serves as valid Paging Reply. * Idle State Registration this is a special case, it allows that a mobile node re-enters idle state directly after having received its data traffic. The registration messages defined in 5.2 at the same time serve as valid Paging Reply. If however the paging rate exceeds a certain configurable limit of MAX_IDLE_RATE, another idle state Liebsch, Renker [Page 25] INTERNET-DRAFT Paging Concept for IP based Networks June 2001 registration SHOULD be rejected to conserve bandwidth. 6.4 Mobile Node Paging Address Depending on the type of distribution mechanism that will be implemented, either the Home Address or a link-local multicast address will be used to page a mobile node on a foreign subnetwork. This subsection specifies the addresses used for paging single mobile nodes and collective group paging. 6.4.1 Group Paging Multicast Address If the optional group paging is used, the Paging Agent assigns a special group paging address and includes it in the Idle State Reply. The address consists of a fixed part plus a group identifier and has to be assigned at the [IANA], the general format can be: +--------------------+--------------------+ | FF02:000A:0000:0000:XXXX:XXXX:XXXX:XXXX | +--------------------+--------------------+ |<----- Prefix ----->|<---- Group ID ---->| +--------------------+--------------------+ This is a conceivable format picked from unallocated address space described in [RFC 2375] but demonstrates the desired purpose: the flags (`0') indicate `well-known' permanent use, the scope identifier (`2') is set to link-local [RFC 2373]. 6.4.2 Paging individual mobile nodes Either the Home Address is used or one out of two multicast addresses. The first choice is the Solicited Node Multicast Address [RFC 2373, sec. 2.7.1], as shown in the figure below. +----------------------------------+--------------+ | 104 bits | 24 bits | +----------------------------------+--------------+ | FF02:0000:0000:0000:0000:0001:FF | Interface ID | +----------------------------------+--------------+ A prerequisite is that the Paging Agent knows the last 3 bytes of the mobile node interface identifier. If the mobile node is aware of using a subnet prefix longer than 104 bits, it MUST perform explicit idle state registration (section 5.2.4) and include the 24 low-order bits of its interface address. The second multicast address alternative is derived from the basic group paging address format of section 6.4.1 and will include an individual identifier instead of a group identifier. The individual identifier can also be taken from the interface ID of the mobile node. Using a fixed multicast address to page individual mobile nodes Liebsch, Renker [Page 26] INTERNET-DRAFT Paging Concept for IP based Networks June 2001 is not well scalable, it would also wake up unaffected mobile nodes at each paging event. This is at the same time the advantage of the Solicited Node Multicast Address: apart from the eased deployment of a well-known address, only the set of nodes whose last 3 interface ID bytes are identical are affected. The probability that more than one node is addressed by this address at a time is considerably low. 6.5 Distribution Mechanism of Paging Requests Distribution of paging requests requires some additional support of the Access Routers. Two modes are offered and specified below. 6.5.1 Tunneling Mode The Paging Agent encapsulates the Paging Request, using IPv6-in-IPv6 encapsulation [RFC 2473]. The destination address of the outer IPv6 header is set to the address of the Access Router, the destination address of the inner IP header is the well-known multicast paging address specified in 6.4.2. This mode poses comparatively little requirements on the mapping functions of Access Routers associated with medium classes one and two (see section 3.2). The first requirement is that the Access Routers are able to decapsulate IPv6-in-IPv6 encapsulated packets. The second requirement is a special routing table entry that causes the inner packet, destined to the well-known multicast address (sec. 6.4.2), to leave the same interface on which the tunneled Paging Request has been received. The attribute ´special´ refers to the fact that in this case the routing decision needs to take the interface into account on which a packet destined to this multicast address has been received. This needs to be in addition to the routing table entry for the multicast address. If the router has more than two interfaces, the destination route for the multicast address can otherwise not be set without ambiguity. Assuming that implementations will allow such a configuration, the inner packet of the tunneled Paging Request will be routed to the prospective subnet of the mobile node. If the mobile node, listening to one of the multicast addresses described in section 6.4, is located on that link, it will re-enter active state and send a Paging Reply. If the mobile node can not be located on the link, no ICMPv6 error message is generated due to the fact that the destination address is a multicast address [RFC 2463, sec. 2.4, e.2 / e.3]. The Solicited Node Multicast Address (sec. 6.4.2) SHOULD NOT be used in this paging mode, the Access Router itself does also listen to such an address and a routing table entry would corrupt its own traffic. Regarding the class 3 medium (section 3.2), a mapping function can be realized in two ways: 1. Access Routers of a class 3 medium use packet filtering and are able to detect tunneled Paging Requests. It is assumed that a class 3 medium Access Router has access to information that allows to relate the mobile node Home Address to whatever Liebsch, Renker [Page 27] INTERNET-DRAFT Paging Concept for IP based Networks June 2001 identifier is internally used to address the mobile node on layer-2. Otherwise, a specific identifier has to be present in the Paging Request, e. g. as IMSI sub-option (sec. 6.2). As soon as the internal identifier is retrieved, the mapping function locates the mobile node and initiates layer-2 paging if necessary. Once the mobile node is localized, it re-enters active state as described in 5.3, and sends a Paging Reply. 2. The second alternative for the class 3 mapping function is the definition of a virtual interface, comparable to the common ´loopback´ interface of IP nodes. The Access Router would then decapsulate the tunneled Paging Request and route the inner packet, destined to the multicast address, to its virtual interface, where the mapping function would collect it for further processing. Employment of a virtual interface is described in [Solom96, pp. 90-94]. 6.5.2 Direct Mode This mode is less transparent than the first one, it works without tunneling. Here, the Paging Request is directly sent to the Access Router. For medium classes one and two the Home Address identifier sub-option (sec. 6.2) is present. The Access Routers of these medium classes generate another Paging Request on the link on which the tunneled Paging Request has been received and set the destination address of the Paging Request to the Home Address of the mobile node. This behavior is very similar to the way Mobile IPv4 Foreign Agents address mobile nodes on their link [RFC 2002, sec. 1.7]. If the multicast group address sub-option (sec. 6.4) is also present in the Paging Request, the IP destination address of the generated Paging Request is set to the group multicast address contained therein. The Access Router of a class 3 medium receives the same Paging Request as for the other two media, retrieves the unique identifier sub-option(s) and localizes the mobile node in the same way as described for tunneling mode. An optimization for the class 3 medium Access Router is not to deliver the IP Paging Request to the mobile node if L2 paging is involved. Instead, the fact that the mobile node is paged via layer-2 triggers state transition from idle to active and the mobile node sends the Paging Reply ´as if´ it would have received the IP Paging Request. 7 SERVICE DISCOVERY A single Paging Agent is a single point of failure. Therefore, mirroring of Paging Agents is considered further on in this document (see section 4.3). To enable redundancy of Paging Agents under a single, well-known address, the IPv6 address of the Paging Agent is set to the new IPv6 Anycast format [RFC 2473]. 7.1 Discovery of Paging Capabilities Liebsch, Renker [Page 28] INTERNET-DRAFT Paging Concept for IP based Networks June 2001 A roaming mobile node visiting a foreign network needs several facts to request service from a Paging Agent: 1. the IP-address of the Paging Agent. 2. an information if paging is supported by the visited network. 3. if static Paging Areas (section 2.2) are used, the mobile node needs to determine in which Paging Area it is. Three different solutions are presented below. All are optional, one needs to be present and the mobile node MUST be able to handle each one. 7.1.1 Variant 1: Advertisements in the visited network Within an administrative domain, paging support can be indicated by sending periodic advertisement messages. Although the messaging is not restricted to a specific format, this concept proposes to use a new extension to ICMPv6 Router Advertisements [RFC 2461]. The advantage of such an extension is that Router Advertisements are already being used to advertise subnet prefixes and that an extension requires less modifications to the IP stack than a dedicated message. The extension uses the generic Type-Length-Value format (TLV) [RFC 2461, sec. 4.2], the VALUE area SHALL provide two data fields, one for the IPv6 anycast address of an advertised Paging Agent and the other Paging Area IDs in the case that a visited network employs static Paging Areas. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - - | TYPE | LENGTH | VALUE +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - - The TYPE identifier is a well-known number, is assigned to this proposed message format and will have to be registered at the [IANA]. The LENGTH field indicates the length of the VALUE area in bytes. The mere presence of this extension serves to indicate network support for paging. If static Paging Areas are being used in the visited network, the Paging Area ID field has to be set to a nonzero value. Otherwise, it MUST be set to zero. It is pointed out that two paging implementations, namely MIRP [HaMa00] and HMIPv6 Regional Paging [Sari00], further extend the usage of Router Advertisements to page idle mobile nodes and offer time-slotted IP paging. Because this extends the requirements placed on foreign networks, it is left as an optional possibility. 7.1.2 Variant 2: Static mobile node configuration Liebsch, Renker [Page 29] INTERNET-DRAFT Paging Concept for IP based Networks June 2001 The IPv6 anycast addresses of one or more Paging Agents are manually configured, e. g. in a control file of the mobile node. The paging capabilities of a visited network are discovered via the Paging Agent. If paging is not supported by a network, a negative acknowledgment is sent back to the mobile node when it registers idle state. This mode alone is not suitable for paging strategies that rely on Paging Area IDs. 7.1.3 Variant 3: Dynamic Paging Agent Address Discovery This solution is similar to the second one, but without previous knowledge of the Paging Agent anycast address. It is based on the definition of a well-known IPv6 anycast address and the exchange of two messages with an entity on the visited subnet. The well-known anycast address is taken from the reserved anycast address space specified in [RFC 2526]. It is constructed as follows: +------------------+---------------------+-------------------+ | N bits | (128 - 7 - N) bits | 7 bits | +------------------+---------------------+-------------------+ |subnet identifier | specific [RFC 2526] | Anycast ID [IANA] | +------------------+---------------------+-------------------+ The subnet identifier is the same used on the current subnet of the mobile node, the last 7 bits contain the Anycast ID, a unique identifier. Up to now only one of the 128 possible anycast identifiers has been assigned [RFC 2526]. The remaining bits depend on the interface identifier and the subnet prefix length being used, this can unambiguously be derived from the specification in [RFC 2526, sec. 2]. This anycast address is termed 'all Paging-Agents on this link' address for reference within this specification, the Anycast ID will also have to be registered with IANA. The next requirement is that the visited network either provides a Paging Agent that listens to this address or a relay agent that will transparently relay messages to a Paging Agent on another network (cf. relay agents in DHCP [RFC 2131]). Possibly, relay agents could be substituted by a routing table entry for the well known Paging Agent anycast address, pointing to the address of the Paging Agent on a different subnet. Paging Agent Address Discovery involves this message exchange: 1. the mobile node sends a Paging Agent Address Request message to the ´all Paging-Agents on this link´ anycast address. 2. if relay agents are used on the visited subnet, the request is forwarded to the anycast address of a Paging Agent in charge. 3. one Paging Agent (of possibly many) unicasts a Paging Agent Address Reply message back to the mobile node, containing its Liebsch, Renker [Page 30] INTERNET-DRAFT Paging Concept for IP based Networks June 2001 own address as source address and optionally other parameters as e. g. an ID for the paging strategy. 7.2 Message Formats Both messages can be realized as ICMPv6 messages. Apart from the generic Type-Code-Checksum format [RFC 2463, sec. 2.1], an identifier field is REQUIRED for both 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 | Code | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + body of Paging Agent Address Request / Reply + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Paging Agent Address Reply message has one field to encode the paging strategy that is used in the network where the mobile node registers. A reserved space is RECOMMENDED for both messages to provide space for possible other parameters in future. 7.2.1 Multiple Discovery Strategies A rule of precedence is defined, if more than one alternative is employed at a time. Network operators MAY enforce certain Paging Agents to be used by advertising the IP address of a local Paging Agent in the Router Advertisement extension. A mobile node without a manually configured Paging Agent MUST perform Dynamic Paging Agent Address Discovery (sec. 7.1.3) in the absence of Paging Area Router Advertisements (sec. 7.1.1). 8 SOLUTIONS TO REDUCE NETWORK LOAD A costly aspect of the paging service is the bandwidth consumed in paging cycles to poll sets of Access Routers. The extent of bandwidth consumption is minimal if Paging Agent and Access Routers are located close to another, possibly within the same domain. This may not always be the case, especially if paging is provided by a party other than a regional network operator. As a result, paging cycles will also cause network load in the core network, which is not desired. Therefore, three solutions are presented in this section to reduce bandwidth consumed by polling cycles. 8.1 Group Paging To reduce signaling load, several mobile nodes can be paged simultaneously. Group paging is optional and is indicated by the presence of a group paging multicast address in the group paging Liebsch, Renker [Page 31] INTERNET-DRAFT Paging Concept for IP based Networks June 2001 field of the Idle State Reply message (sec. 5.5.2). If this field is non-zero, the mobile node MUST configure its interface(s) for this address. Otherwise, if only one mobile node is paged at a time, the group paging field MUST be set to zero. Group Paging is independent of the registration mode, i. e. the Idle State Reply message with the group paging address serves as valid reply to each of the four registration modes described in section 5.2. 8.2 Paging Agent Hierarchies A Paging Agent hierarchy (figure below) allows users to keep their preferred Paging Agent while the distribution of Paging Requests is handled locally. The requirements are that the local Paging Agents can decode their own Paging Request messages. | | --- A | v +------+ | PAgt | +------+ / \ / \ B --- --- B / \ / \ +------+ +------+ | PAgt | | PAgt | +------+ +------+ | | To avoid different implementations for each hierarchical level, interfaces A (addressed by Home Agents and correspondent nodes) and B (addressed by higher-level Paging Agent) SHOULD be compatible or uniform. Minor modifications are necessary regarding the organization of paging information at the higher-level Paging Agent, it MUST be able to differentiate regular Access Routers and lower-level Paging Agents as receivers of Paging Requests. This SHOULD be achieved by using type identifiers for the addresses that the Paging Agent manages in its internal structures. Information related to the local network topology can remain at the lower-level Paging Agents. This kind of arrangement is especially suitable for paging strategies that rely on topological information about foreign networks. By employing a local Paging Agent, a network operator can keep the details of the network topography confidential. A possible example is the Shortest-Distance-First strategy [Wong00]. Liebsch, Renker [Page 32] INTERNET-DRAFT Paging Concept for IP based Networks June 2001 When paging a mobile node, the higher-level Paging Agent sends only one single Paging Request to the lower-level Paging Agent, containing the last care-of address of the mobile node that was recorded. The lower-level Paging Agent takes control of paging, determines the direct neighbors to this address and distributes the bandwidth- consuming Paging Requests locally. Another positive aspect of local Paging Agents is the enhanced flexibility of service and policy. If a network operator decides not to trust external paging service and related communication anymore, the local agents can be re-configured to do standalone service. 8.3 Message Support for Sequential Paging The solution presented in this subsection is suitable for paging strategies with moderate delay constraint and no need for simultaneous polling. Sequential Paging is such a strategy, the principle is to poll one Access Router first, wait for a certain time, go on by polling the next router, wait a certain time and so on, until the last router of the sequence has been polled. To reduce bandwidth, the sequence of addresses to be polled is included in the Paging Request and interpreted by the Access Routers in a manner similar to a Routing Header. This works only in Direct Mode (section 6.5.2). The Paging Agent copies the list of Access Routers in the order they have to appear into a sub-option and sends the Paging Request to the first address of the list. The associated Access Router locally pages the mobile node, possibly waits a preconfigured time and passes the Paging Request on to the next address of the list. The node belonging to that address acts in the same way, pages locally, possibly waits and forwards the Paging Request on to the next address of the list. This pattern repeats until the last address of the list has been reached. The specific message format is the TLV- layout, specified in [JoPe00b, p. 34], the field values are set to: Type: 5 Length: (number of addresses) * 16 Value: ordered list of IPv6 addresses The maximum length of the value field in a sub-option is 255 bytes. Thus, if more than 15 stations have to appear in the list, a second or third sub-option MAY be employed. If necessary, an alternative message format MAY be used, containing individual timeout values for each station of the list. 9 ENHANCEMENTS FOR STATIC PAGING AREAS This section describes optional alternatives for the specific case that Predefined, Static Paging Areas (sec. 2.2) are used. Static Paging Areas are mostly associated with the Blanket Polling paging Liebsch, Renker [Page 33] INTERNET-DRAFT Paging Concept for IP based Networks June 2001 strategy (sec. 3.3), that is localization of an idle mobile node within a Paging Area is realized by simultaneously polling all Access Routers of the area. 9.1 Rules for Paging Area Deployment While roaming in a domain that is divided into Predefined Paging Areas, an idle mobile node updates location information whenever it enters a new Paging Area. A clear distinction between layer-2 Paging Areas and layer-3 Paging Areas is essential. A general rule of this paging concept is that if Paging Areas have to be defined as part of a certain paging strategy, all definition takes place on layer-3, i. e. on the level of IP addresses. As a consequence, layer-2 Paging Areas remain transparent to layer-3 signaling. Accordingly, if a layer-2 medium supports layer-2 Paging Areas as part of its paging strategy, all these Paging Areas MUST be subordinate to the same IP subnet. The reverse case (a layer-2 Paging Areas comprises several IP subnets) is ambiguous and requires specific treatment. An idle mobile node could be paged on a subnet other than the one that is currently registered, which will lead to packet loss. This case is special, if it occurs more frequently in practice, it will then be worth to provide a specific function to coordinate layer-2 Paging Areas and IP subnet areas. A simple solution is the introduction of a smooth handoff ([JoPe00a], [JoPe00b, sec. 10.9]) scheme. 9.2 Roaming In Static Paging Areas 9.2.1 Movement Detection in Static Paging Areas If static, predefined Paging Areas are used, the mobile node has to update location information at the Paging Agent each time it enters a new Paging Area. To this avail, the Idle State Request message is used to carry the Paging Area ID (PAI) of the current Paging Area around the mobile node. The Paging Agent SHOULD acknowledge this update. 9.2.2 Paging Area Configuration The challenge of static Paging Area configuration is apart from minimizing overall processing costs the best possible tradeoff between network load caused by polling cycles and location updates. Two extremes exist: * Extremely small Paging Areas result in minimal network load due to Paging Requests. On the other hand, the smaller the Paging Areas, the higher the Liebsch, Renker [Page 34] INTERNET-DRAFT Paging Concept for IP based Networks June 2001 frequency of location updates. Additional management overhead due to an increased Paging Area density is also incurred. * Extremely wide Paging Areas result in a low location update frequency of roaming idle mobile nodes. The paging network load is however proportional to the area size of the Paging Area. Thus, paging in a large Paging Area incurs a very high network load. It is the task of the network operator to configure the best possible tradeoff between these two extremes. Note that in this inter-domain paging concept a Paging Area MAY comprise multiple domains. Implementing the Paging Area ID extension (sec. 7.1.1), Router Advertisements contain an additional Paging Area Identifier (PAI). The mobile node in idle state needs to adapt its movement detection algorithm to detect if it has entered a new Paging Area. A load problem occurs for access routers at the borders of a Paging Area, nearly all registrations will be done there and only a few at other access routers more towards the center of the Paging Area. Therefore it is better also to support overlapping paging areas. 9.3 Support for Overlapping Paging Areas 9.3.1 Non-Overlapping Static Paging Areas This is the default mode, the mobile node has to check one PAI at a time. Receiving different advertisements with different PAIs from neighboring access routers can anticipate an imminent change of the Paging Area. 9.3.2 Overlapping Static Paging Areas This mode is enabled by extending the Router Advertisements. Those access routers, which belong to more than one Paging Area, advertise the identifiers of all Paging Areas they are member of. The mobile node will detect the border of a Paging Area by the presence of more than one PAI in a single advertisement message: Liebsch, Renker [Page 35] INTERNET-DRAFT Paging Concept for IP based Networks June 2001 Paging Area 1 ....------------------------+ +------------- | ---------------.... +--+ +--+ +--+|+--+ +--+ +--+|+--+ +--+ +--+ |AR| |AR| |AR|||AR| |AR| |AR|||AR| |AR| |AR| +--+ +--+ +--+|+--+ +--+ +--+|+--+ +--+ +--+ PA1 PA1 PA1| PA1 PA1 PA1| | PA2 PA2 PA2| PA2 PA2 PA2 | | ....------------------------+ +-------------------------------.... Paging Area 2 Considering a mobile node moving from Paging Area 1 to Paging Area 2, it detects a new Paging Area (PA2) in the border area. The mobile node MAY remain registered in PA1, as long as it hears Paging ID Advertisements containing the PA1 - Identifier. The mobile node SHOULD randomize the registration within border areas. The two advantages of this arrangement are: 1. Reduced signaling and processing load of routers at the Paging Area borders. If a clever random registration algorithm is used, a balanced load distribution can be achieved for all access routers. 2. The movement detection of the idle mobile node is now more robust. Whereas in disjoint paging areas the mobile node can only hope to receive a neighboring Router Advertisement early enough, this scheme provides explicit information to the mobile node that it is currently in a border area. This is especially important in wireless environments with instable link quality (reflections, multi-path propagation etc.). If more than two Paging Area IDs are present, ambiguities occur regarding which Paging Area is being entered. To resolve these ambiguities, the mobile node SHOULD perform a random selection. Neighbor Discovery Options [RFC 2461] use a one-byte Length field, so the maximum data length is 255 bytes. This restricts the number of PAIs in the message, which are finite anyway. Regarding the maximum number of PAIs in such an extension, we consider the 'cellular' hexagon: Setting the worst case to a maximum of 6 Paging Areas overlapping in a center area leaves still enough space in the extension for other possible information. For example, if 32 byte Paging Area identifiers are used, there would still be space for the IPv6 addresses of two Paging Agents in the Router Advertisement extension described in section 7.1.1. Liebsch, Renker [Page 36] INTERNET-DRAFT Paging Concept for IP based Networks June 2001 9.4 Deployment of Multicasting Using multicast as a distribution system for Paging Requests is not a new idea, it already appeared in the MIRP [HaMa00], Hierarchical Mobile IPv6 [Sari00] and HAWAII [Rapo00b] paging proposals. The basic idea is employment of a multicast routing tree for the distribution of Paging Requests to the Access Routers, which join a dedicated Paging Area multicast group for this purpose. For operations within a domain, multicast group addresses with link-local or site-local scope [RFC 2373, p. 14] are sufficient. Setting up a multicast tree involves two parts. First, a router has to declare that it wants to join a multicast group. This is typically done by protocols like IGMP [RFC 1112] or Multicast Listener Discovery [RFC 2710] in IPv6. The second part is done by a special multicast routing protocol that collects this information from several routers and builds up a routing tree. The time between the subscription of a multicast address by a router and the instant that the route is fully set up is called join latency. It is beyond scope of this document to devise efficient ways to reduce multicast join latencies but it is stated that such latencies may impose an upper time limit if group memberships change fast and dynamically. This can be the case with Adaptive Individual Paging [Cast99]. An empirical examination in the MBone resulted in join latency values measured in the range of 700 milliseconds for a route of 16 hops [Garg99]. In any way, multicasting can ease the deployment of static Paging Areas, used e. g. by Blanket Polling. The multicast distribution tree in this case is statically set up, therefore the effective join latency is zero. Instead of storing Paging Area IDs, the Paging Agent can store the multicast addresses associated with the current Paging Area of the mobile node, this could be supported by routers advertising multicast group addresses instead of Paging Area IDs. Apart from the multicast address that belongs to a certain Paging Area, the Paging Agent needs to address the root of the multicast routing tree, called distribution point in this context. Two alternatives exist. * the root is located on the network of the Paging Agent. This can be arranged if local Paging Agents are used or if the multicast routing tree may extend the borders of the foreign network. To page a mobile node in a specific Paging Area, the Paging Request is sent to the associated multicast address (stored internally at the Paging Agent) via the local distribution point. * the multicast routing tree is set up locally and the Paging Agent resides on a distant subnetwork. In this case, the Paging Liebsch, Renker [Page 37] INTERNET-DRAFT Paging Concept for IP based Networks June 2001 Agent will have to tunnel the Paging Request, the outer IP header destination address is set to the address of the distribution point, while the destination address of the inner IP header points to the target multicast group address. The Paging Request arrives at the distribution point, the inner packet is decapsulated and routed according to the destination multicast address. The identification of which method is precisely used SHOULD be stored in the internal tables of the Paging Agent. 9.5 Flexible Remote Configuration of Access Routers Paging area detection is realized through the advertisement of Paging Area IDs (PAI), as described in 7.1.1. Accordingly, a possibly large number of Access Routers have to be configured with PAI numbers that have to be advertised in Router Advertisements, an active and a passive solution exist: 1. Passive: manual configuration Each Access Router is individually configured to advertise a statically assigned Paging Area ID. This is tedious to configure and not well scalable (every change requires manual intervention), but is easier to implement. 2. Active: remote configuration These possibilities require more modifications in Access Routers but are more flexible, scalable (support for re-configuration) and comfortable (centralized management). Access Routers receive configuration information from a Paging Server, the topology of the network is known at the Paging Server. These are topics to keep in mind for possible future extension: (a) Configuration via SNMP This requires the implementation of a Management Information Base (MIB) [RFC 1441] for remote management of Access Routers. The MIB contains control variables for configuration and data variables to store statistics. Using SNMP, one or more Paging Areas can be centrally configured and daily user statistics be saved in data variables, evaluated periodically. (b) Deploy Router Renumbering This idea is used in [SoCa00b, sec. 8.2] to induce access routers to advertise information about Mobility Anchor Point service in the domain. The proposed idea is an extension to Router Renumbering [RFC 2894], which defines a set of Liebsch, Renker [Page 38] INTERNET-DRAFT Paging Concept for IP based Networks June 2001 messages that can be used to renumber certain interfaces on a router without manual intervention. The information that has to be advertised is sent from a central point to all Access Routers via special Router Renumbering messages. (c) Other Means This requires to write an explicit protocol. For example, the advertisement information can be sent to access routers using a special IPv6 header Destination Option, the access routers will have to send an acknowledgment in turn [SoCa00b, p. 16]. Also, the access routers could periodically poll the information. 10 SECURITY CONSIDERATIONS An important aspect that could not be covered by this paper is protection of the protocol with an appropriate security framework. Further and thorough investigation is necessary to evaluate if existing (IPSec) security structures provide sufficient security for scenarios related to this protocol. A swift answer is not possible. Rather, this section analyzes the security requirements and the potentially vulnerable aspects of the protocol. For further security aspects, see also [Sea-Req]. 10.1 Mobile Node Aspects In general, mobile nodes using a paging service are most likely to attach via a wireless link to a network. Wireless links are especially vulnerable to passive eavesdropping, active replay attacks and other active attacks [Perk98, p. 84]. This is also one of the reasons why every registration in Mobile IP has to be authenticated ([RFC 2002, sec. 3.2], [JoPe00b, sec. 4.4]), mobile node and Home Agent share a security association. The security features of Mobile IP however do not suffice to cover the interactions with the Paging Agent, as the following considerations show. By registering the address of the Paging Agent instead of its own care-of address, the mobile node grants authority to a remote entity, it admits that the Paging Agent collects its traffic and is confident that the Paging Agent will redistribute collected traffic accurately. Both aspects introduce vulnerabilities: * The mobile node needs assurance that the Paging Agent is trustworthy. Authentication or better certification is a mandatory requirement, if no stronger security measures can be provided. Otherwise, an abuse of the (possibly well-known) Paging Agent address to redirect mobile node traffic would be a trivial operation for potential attackers. The need for authentication is even higher when dynamically changing Paging Agents are used. A manually configured Paging Agent might be regarded as trustworthy, if otherwise Paging Agents are determined by Liebsch, Renker [Page 39] INTERNET-DRAFT Paging Concept for IP based Networks June 2001 advertisements or Dynamic Paging Agent Address Discovery (sec. 7.1.3), there is no given proof of trustworthiness. * The second aspect affects the distribution of collected, private data over a public Internet. The paging service in principle offers no confidentiality, packets sent from the Paging Agent to the mobile node are sent as plain text. If mobile node and Paging Agent have encryption keys, confidentiality of possibly valuable user data can be provided. * Also in plain text and duplicated several times are the paging messages. These contain the Home Address or another number to uniquely identify the mobile node. This allows third parties to deduce information about the mobile node's location, its migration pattern, location preferences and possibly more. The paging concept introduced in [Fede97] uses implicit addresses to hide the location of the paged mobile node. If an established security association exists between mobile node and Paging Agent, identifiers could also be encrypted. In this draft, Explicit Idle State Registration (section 5.2.4) has been devised with the thought in mind to have a pair of messages ready to potentially accommodate a key exchange between a mobile node and a Paging Agent. The degree of the security that a candidate key exchange protocol provides will have to be examined first. To conclude the list of mobile node vulnerabilities with a positive aspect, a strong security framework can enable an improved protocol operation. That is, the maximum time a mobile node MAY possibly be idle is dictated by the values for binding Lifetime and registration Refresh interval in the Binding Acknowledgment [JoPe00b, sec. 5.2]. If the Paging Agent can be integrated into the Mobile IP environment with sufficient security, it could possibly send the Binding Updates merely serving to refresh the binding at the Home Agent on behalf of the mobile node. As a result, idle state duration could be extended by far, leading to even further reduced signaling and higher mobile node power savings. It has to be investigated if this arrangement causes problems with Mobile IP implementations, as the Mobile IPv6 specification states that "No other IPv6 nodes are authorized to send Binding Updates on behalf of a mobile node." [JoPe00b, p. 89]. Should it be possible to send Binding Updates on behalf of the mobile node, a security framework MUST be provided. 10.2 Paging Agent Aspects The most obvious security need is a protection against denial-of- service attacks. A single Paging Agent can easily be compromised by submitting a large number of Idle State Requests simultaneously. Authentication of mobile nodes to the Paging Agent provides some mitigation, forged Idle State Requests could thus be rejected. Also, a load control SHOULD be implemented, to split large workloads among Liebsch, Renker [Page 40] INTERNET-DRAFT Paging Concept for IP based Networks June 2001 several Paging Agents. 10.3 Foreign Network Aspects To page each mobile node, a Paging Agent creates network load in a possibly foreign network. There is a need to protect networks against abuse of this facility to potentially flood a network. A simple remedy is to restrict the scope of Paging Agents to local domains only, which however nullifies a big advantage of this concept. Another possibility is the introduction of authentication between the Paging Agent and each foreign network for which it is offering paging service. This inventory covers only the most obvious aspects. A security scheme that protects the mentioned (and possibly other) weak points of the protocol will result in increased efficiency and make the proposed scheme more attractive for commercial environments. 11 IANA CONSIDERATIONS The following addresses and message formats have to be registered with IANA. 11.1 Message Formats Liebsch, Renker [Page 41] INTERNET-DRAFT Paging Concept for IP based Networks June 2001 +------------------------------+-------------------+----------------+ | Message | Format | Section | +------------------------------+-------------------+----------------+ +------------------------------+-------------------+----------------+ | Paging Agent Address Request | ICMPv6 | 7.1.3 | +------------------------------+-------------------+----------------+ | Paging Agent Address Reply | ICMPv6 | 7.1.3 | +------------------------------+-------------------+----------------+ +------------------------------+-------------------+----------------+ | Idle State Request | Dest. Header Opt. | 5.5.1 | +------------------------------+-------------------+----------------+ | Idle State Reply | Dest. Header Opt. | 5.5.2 | +------------------------------+-------------------+----------------+ +------------------------------+-------------------+----------------+ | Paging Request | Dest. Header Opt. | 6.2 | +------------------------------+-------------------+----------------+ | Home Address - ID | Sub-Option | 6.2 | +------------------------------+-------------------+----------------+ | NAI - ID | Sub-Option | 6.2 | +------------------------------+-------------------+----------------+ | IMSI - ID | Sub-Option | 6.2 | +------------------------------+-------------------+----------------+ | Multicast Group Address - ID | Sub-Option | 6.2 | +------------------------------+-------------------+----------------+ +------------------------------+-------------------+----------------+ | Paging Area ID extension | TLV extension | 7.1.1 | +------------------------------+-------------------+----------------+ | Sequential Polling Extension | Sub-Option | 8.3 | +------------------------------+-------------------+----------------+ 11.2 Addresses Used * the 'all Paging-Agents on this link' anycast address (section 7.1.3) * the group multicast address (section 6.4.1) 12 PROTOCOL CONSTANTS Several constants have been named to ease description and discussion. The constants are: MAX_REGISTER: the maximum time that a mobile node is considered idle (MAY be set to infinity for statically registered mobile nodes). PAGING_TIMEOUT: initial timeout value for the paging process (exponential backoff). MAX_PRQ_RETRY: maximum number of Paging Request retransmissions. Liebsch, Renker [Page 42] INTERNET-DRAFT Paging Concept for IP based Networks June 2001 MAX_BUFFER: maximum amount of data buffered per mobile node at the Paging Agent. LOCK_TIME: inhibit time, during which no new paging process is initiated after a mobile node could not be localized. MAX_IDLE_RATE: maximum allowed number of paging incidents per unit of time if a mobile node may continuously be registered idle. ReachableTime: as defined in [RFC 2461, sec. 6.3.2]. T_INACTIVE: waiting time prior to entering idle state after the last packet has been sent or received by the mobile node. It is set to MAX( ReachableTime, 2*MSL) (section 5.1.2). 13 OPEN ISSUES This section concludes the draft with a 'to-do' list, these ideas can further enhance the basic paging protocol. At first, a practical implementation should be considered, confrontation with realization issues can further mature the foundation laid out by this document. Apart from possible extensions already mentioned in the text, the future work items are: * the question of paging in ad-hoc networks needs study. * a number index to encode different paging strategies. * allow communication with micro-mobility protocols, such as CIP, HAWAII, HMIPv6 or IDMP to allow inter-domain paging also for these proposals. * extend mobile node functionality to the periodic delivery of location data to a centralized server, e. g. once per day. This is meant to generate location probabilities used for user-profile based paging. * provide a user-interface to allow editing of user profiles, a user could type in all the locations he is likely to be at. * automate sharing of configuration data among mirroring Paging Agents, using a kind of zone transfer protocol (section 4). * an examination, how useful GPS can be to locate a user [RFC 2009]. * make this paging service well-known to other network services, i. e. provide an interface for DHCP advertisements and to the Service Location Protocol [RFC 2165]. Liebsch, Renker [Page 43] INTERNET-DRAFT Paging Concept for IP based Networks June 2001 * build an enterprise Management Information Base [RFC 1213] to allow remote configuration via SNMP network management tools. A REFERENCES [Cast99] C. Castelluccia, Extending Mobile IP with Adaptive Individual Paging: A Performance Analysis, INRIA TR-0236, November 1999; available at http://www.inrialpes.fr/planete/people/ccastel/rt99.ps (last visited 27-2-01) [CIPv6] Z. D. Shelby et al, Cellular IPv6, draft-shelby-seamoby-cellularipv6-00.txt, work in progress, November 2000 [Clark88] David D. Clark, The Design Philosophy of the DARPA Internet Protocols, Proc. SIGCOMM '88, ACM Computer Communication Review Vol. 18, No. 4, August 1988, pp. 106-114 [Fede97] H. Federrath et al., Minimizing the Average Cost of Paging on the Air Interface - An Approach Considering Privacy, IEEE Document Nr. 0-7803-4075-2/97, 1997 [Garg99] A. Garg et al., Measurement of Join Latency on the Mbone, August 1999; available at: ftp://ftp.cs.umass.edu/pub/techrept/techreport/1999/ UM-CS-1999-047.ps (last visited 29-3-01) [HaMa00] H. Haverinen / J. Malinen, Mobile IP Regional Paging, draft-haverinen-mobileip-reg-paging-00.txt, work in progress, June 2000 [IANA] The Internet Assigned Numbers Authority, http:// www.iana.org/numbers.html [JoPe00a] D.B. Johnson / C. Perkins, Route Optimization in Mobile IP, draft-ietf-mobileip-optim-10.txt, work in progress, November 2000 [JoPe00b] D.B. Johnson / C. Perkins, Mobility Support in IPv6, draft-ietf-mobileip-ipv6-13.txt, work in progress, November 2000 [Perk98] Charles E. Perkins, Mobile IP - Design Principles and Practices, Addison-Wesley, 1998 [RaPo00b] R. Ramjee / T. La Porta et al., Liebsch, Renker [Page 44] INTERNET-DRAFT Paging Concept for IP based Networks June 2001 Paging support for IP mobility, draft-ietf-mobileip-paging-hawaii-01.txt, work in progress, July 2000 [Ro95] C. Rose / R. Yates, Minimizing the Average Cost of Paging Under Delay Constraints, ACM Journal of Wireless Networks, vol. 1, no. 2, pp.211--219, 1995 [Ro97] C. Rose / R. Yates, Ensemble Polling Strategies for Increased Paging Capacity in Mobile Communication Networks, ACM Journal of Wireless Networks, vol. 3, no. 2, pp.159--167, 1997 [Sari00] B. Sarikaya et al., Mobile IPv6 Regional Paging, draft-sarikaya-mobileip-hmipv6rp-00.txt, work in progress, November 2000 [Sea-Prob] J. Kempf, Dormant Mode Host Alerting Problem Statement, draft-ietf-seamoby-paging-problem-statement-03.txt, work in progress, May 2001 [Sea-Req] J. Kempf et al., Requirements for an IP Mobile Node Alerting Protocol, draft-ietf-seamoby-paging-requirements-01.txt, work in progress, May 2001 [Sea-Term] J. Manner et al, Mobility Related Terminology, draft-manner-seamoby-terms-01.txt, work in progress, March 2001 [SoCa00b] H. Soliman / C. Castelluccia et al., Hierarchical MIPv6 mobility management, draft-ietf-mobileip-hmipv6-01.txt, work in progress, November 2000 [Solom96] James D. Solomon, Mobile IP - The Internet unplugged, Prentice-Hall, 1996 [Wong00] W.-S. Wong / V.M. Leung, Location Management for Next-Generation Personal Communication Networks, IEEE Network, Sept. 2000 Liebsch, Renker [Page 45] INTERNET-DRAFT Paging Concept for IP based Networks June 2001 B AUTHOR'S ADDRESSES Marco Liebsch, Gerrit Renker NEC Network Laboratories Europe Adenauerplatz 6, 69115 Heidelberg Germany Phone: +49 (0)6221 13708 - 11 Fax: +49 (0)6221 13708 - 28 email: Marco.Liebsch@ccrle.nec.de Gerrit.Renker@ccrle.nec.de Liebsch, Renker [Page 46]