INTERNET-DRAFT M. Liebsch G. Renker R. Schmitz NEC Network Laboratories Europe Expires March 2002 September 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, Schmitz [Page 1] INTERNET-DRAFT Paging Concept for IP based Networks September 2001 Table of Contents 1 INTRODUCTION 4 1.1 General Overview . . . . . . . . . . . . . . . . . . . . . . 4 1.1.1 General Scheme of a Paging Process . . . . . . . . . . 5 1.1.2 Mobility Background . . . . . . . . . . . . . . . . . . 5 1.1.3 Concept Summary . . . . . . . . . . . . . . . . . . . . 5 1.1.4 Role of the Paging Strategy . . . . . . . . . . . . . . 5 1.2 Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 1.3 Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . 6 2 TERMS 7 2.1 Key Words . . . . . . . . . . . . . . . . . . . . . . . . . . 7 2.2 Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7 3 BASIC MECHANISM 9 3.1 Paging Principle . . . . . . . . . . . . . . . . . . . . . . 9 3.2 Classification of Access Media . . . . . . . . . . . . . . . 10 3.3 Paging Strategies . . . . . . . . . . . . . . . . . . . . . . 10 3.3.1 Blanket Polling . . . . . . . . . . . . . . . . . . . . 10 3.3.2 Shortest-Distance-First . . . . . . . . . . . . . . . . 10 3.3.3 Sequential (Group) Paging . . . . . . . . . . . . . . . 11 3.3.4 Adaptive Individual Paging . . . . . . . . . . . . . . 11 3.3.5 Other Paging Strategies . . . . . . . . . . . . . . . . 11 3.3.6 Optimization. . . . . . . . . . . . . . . . . . . . . . 11 3.4 Network Model . . . . . . . . . . . . . . . . . . . . . . . . 11 3.4.1 Entities. . . . . . . . . . . . . . . . . . . . . . . . 11 3.4.2 Mapping Functions . . . . . . . . . . . . . . . . . . . 12 4 PAGING AGENT SPECIFICATION 12 4.1 Core Tasks of the Paging Agent. . . . . . . . . . . . . . . . 13 4.2 Additional Functionality. . . . . . . . . . . . . . . . . . . 14 4.3 Paging Agent Redundancy . . . . . . . . . . . . . . . . . . . 14 4.4 Internal Realization of Paging Strategies . . . . . . . . . . 14 5 STATE REGISTRATION AND MAINTENANCE 15 5.1 Conditions to Enter Idle State. . . . . . . . . . . . . . . . 15 5.1.1 General Consideration . . . . . . . . . . . . . . . . . 15 5.1.2 Problems Regarding On-Link Neighbors. . . . . . . . . . 16 5.2 Idle State Registration at the Paging Agent . . . . . . . . . 17 5.2.1 Mobile IP - specific part of the registration . . . . . 18 5.2.2 Implicit Idle State Registration. . . . . . . . . . . . 18 5.2.3 Idle State Registration using MIPv6 Messages. . . . . . 20 5.2.4 Explicit Idle State Registration. . . . . . . . . . . . 21 5.2.5 Permanent Registration. . . . . . . . . . . . . . . . . 22 5.3 Idle State De-Registration. . . . . . . . . . . . . . . . . . 22 5.3.1 General State Machine . . . . . . . . . . . . . . . . . 23 5.4 Idle State Registration at Correspondent Nodes. . . . . . . . 23 5.5 Messages for Idle State Registration. . . . . . . . . . . . . 24 5.5.1 Idle State Request Message. . . . . . . . . . . . . . . 24 5.5.2 Idle State Reply Message. . . . . . . . . . . . . . . . 25 Liebsch, Renker, Schmitz [Page 2] INTERNET-DRAFT Paging Concept for IP based Networks September 2001 6 PAGING DORMANT MOBILE NODES 25 6.1 Paging Algorithm of the Paging Agent . . . . . . . . . . . . . 26 6.2 Paging Request Message . . . . . . . . . . . . . . . . . . . . 27 6.2.1 General Message Format . . . . . . . . . . . . . . . . . 27 6.2.2 Sub-Options contained in the Paging Request. . . . . . . 27 6.3 Paging Reply Specification . . . . . . . . . . . . . . . . . . 28 6.4 Mobile Node Paging Address . . . . . . . . . . . . . . . . . . 29 6.4.1 Group Paging Multicast Address . . . . . . . . . . . . . 29 6.4.2 Paging individual mobile nodes . . . . . . . . . . . . . 29 6.5 Distribution Mechanism of Paging Requests. . . . . . . . . . . 30 6.5.1 Tunneling Mode . . . . . . . . . . . . . . . . . . . . . 30 6.5.2 Direct Mode. . . . . . . . . . . . . . . . . . . . . . . 31 7 SERVICE DISCOVERY 31 7.1 Discovery of Paging Capabilities . . . . . . . . . . . . . . . 32 7.1.1 Variant 1: Advertisements in the visited network . . . . 33 7.1.2 Variant 2: Static mobile node configuration. . . . . . . 33 7.1.3 Variant 3: Dynamic Paging Agent Address Discovery. . . . 33 7.2 Message Formats. . . . . . . . . . . . . . . . . . . . . . . . 34 7.2.1 Multiple Discovery Strategies. . . . . . . . . . . . . . 34 8 SOLUTIONS TO REDUCE NETWORK LOAD 34 8.1 Group Paging . . . . . . . . . . . . . . . . . . . . . . . . . 35 8.2 Paging Agent Hierarchies . . . . . . . . . . . . . . . . . . . 35 8.3 Message Support for Sequential Paging. . . . . . . . . . . . . 36 9 ENHANCEMENTS FOR STATIC PAGING AREAS 37 9.1 Rules for Paging Area Deployment . . . . . . . . . . . . . . . 37 9.2 Roaming In Static Paging Areas . . . . . . . . . . . . . . . . 37 9.2.1 Movement Detection in Static Paging Areas. . . . . . . . 37 9.2.2 Paging Area Configuration. . . . . . . . . . . . . . . . 38 9.3 Support for Overlapping Paging Areas . . . . . . . . . . . . . 38 9.3.1 Non-Overlapping static Paging Areas. . . . . . . . . . . 38 9.3.2 Overlapping static Paging Areas. . . . . . . . . . . . . 38 9.4 Deployment of Multicasting . . . . . . . . . . . . . . . . . . 40 9.5 Flexible Remote Configuration of Access Routers. . . . . . . . 41 10 SECURITY CONSIDERATIONS 42 10.1 Mobile Node Aspects . . . . . . . . . . . . . . . . . . . . . 42 10.2 Paging Agent Aspects. . . . . . . . . . . . . . . . . . . . . 43 10.3 Foreign Network Aspects . . . . . . . . . . . . . . . . . . . 43 10.4 General Paging Architecture Aspects . . . . . . . . . . . . . 43 11 IANA CONSIDERATIONS 11.1 Message Formats . . . . . . . . . . . . . . . . . . . . . . . 45 11.2 Addresses Used. . . . . . . . . . . . . . . . . . . . . . . . 45 12 PROTOCOL CONSTANTS 46 13 OPEN ISSUES 46 Liebsch, Renker, Schmitz [Page 3] INTERNET-DRAFT Paging Concept for IP based Networks September 2001 A REFERENCES 47 B AUTHOR'S ADDRESSES 50 C MAPPING OF THE FUNCIONAL ARCHITECTURE WITH RFC 3154 50 C.1 Composite Architecture of the Paging Agent . . . . . . . . . . 50 D CONFORMANCE CHECK with RFC 3154 52 D.1 Impact on Power Consumption. . . . . . . . . . . . . . . . . . 52 D.2 Scalability. . . . . . . . . . . . . . . . . . . . . . . . . . 52 D.3 Control of Broadcast/Multicast/Anycast . . . . . . . . . . . . 52 D.4 Efficient Signaling for Inactive Mode. . . . . . . . . . . . . 53 D.5 No Routers . . . . . . . . . . . . . . . . . . . . . . . . . . 53 D.6 Multiple Dormant Modes . . . . . . . . . . . . . . . . . . . . 53 D.7 Independence of Mobility Protocol. . . . . . . . . . . . . . . 54 D.8 Support for Existing Mobility Protocols. . . . . . . . . . . . 54 D.9 Dormant Mode Termination . . . . . . . . . . . . . . . . . . . 54 D.10 Network Updates . . . . . . . . . . . . . . . . . . . . . . . 54 D.11 Efficient Utilization of L2 . . . . . . . . . . . . . . . . . 55 D.12 Orthogonality of Paging Area and Subnets. . . . . . . . . . . 55 D.13 Future L3 Paging Support. . . . . . . . . . . . . . . . . . . 55 D.14 Robustness Against Failure of Network Elements. . . . . . . . 55 D.15 Reliability of Packet Delivery. . . . . . . . . . . . . . . . 56 D.16 Robustness Against Message Loss . . . . . . . . . . . . . . . 56 D.17 Flexibility of Administration . . . . . . . . . . . . . . . . 56 D.18 Flexibility of Paging Agent Design. . . . . . . . . . . . . . 57 D.19 Availability of Security Support. . . . . . . . . . . . . . . 57 D.20 Authentication of Paging Location Registration. . . . . . . . 57 D.21 Authentication of Paging Area Information . . . . . . . . . . 57 D.22 Authentication of Paging Messages . . . . . . . . . . . . . . 57 D.23 Paging Volume . . . . . . . . . . . . . . . . . . . . . . . . 58 D.24 Parsimonious Security Messaging . . . . . . . . . . . . . . . 58 D.25 Noninterference with Host's Security Policy . . . . . . . . . 58 D.26 Noninterference with End-to-end Security. . . . . . . . . . . 58 D.27 Detection of Bogus Correspondent Nodes. . . . . . . . . . . . 58 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. Liebsch, Renker, Schmitz [Page 4] INTERNET-DRAFT Paging Concept for IP based Networks September 2001 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. Nevertheless, the concept is independent of the mobility management protocol and integrates modularly into existing systems making use of registration mechanisms provided by respective mobility management protocols in order to receive initial user data packets destined to as idle registered mobile nodes. The concept conforms to [Sea-Req] in this context. In Mobile IPv6, 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 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. Since the Access Router can make use of L2-specifics in order to support paging a mobile node, respective mechanisms can be applied on the access link for different dormant modes. 1.1.4 Role of the Paging Strategy As the performance of a paging implementation depends on the specific Liebsch, Renker, Schmitz [Page 5] INTERNET-DRAFT Paging Concept for IP based Networks September 2001 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 and other mobility management protocols * 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 Liebsch, Renker, Schmitz [Page 6] INTERNET-DRAFT Paging Concept for IP based Networks September 2001 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. This is to be taken into account for any mobility management system in order to support a long-time idle state registration. 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 Black Hole packet loss without any control of the system COA Care-Of Address Liebsch, Renker, Schmitz [Page 7] INTERNET-DRAFT Paging Concept for IP based Networks September 2001 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) MN mobile node MSL Maximum Segment Lifetime (RFC 793) Liebsch, Renker, Schmitz [Page 8] INTERNET-DRAFT Paging Concept for IP based Networks September 2001 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 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 Liebsch, Renker, Schmitz [Page 9] INTERNET-DRAFT Paging Concept for IP based Networks September 2001 [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. 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. Liebsch, Renker, Schmitz [Page 10] INTERNET-DRAFT Paging Concept for IP based Networks September 2001 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 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 Liebsch, Renker, Schmitz [Page 11] INTERNET-DRAFT Paging Concept for IP based Networks September 2001 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 MUST cause re- entering active state followed by the establishment of a routable L3 link. 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. With respect to the functional architecture for paging described in [Sea- Req], the Paging Agent described in this concept covers the three related functional entities (FE), i.e. the Tracking Agent FE, the Dormant Monitoring Agent FE as well as the Paging Agent FE. In order to avoid confusing the described 'composite Paging Agent' with the 'Paging Agent FE' of [Sea-Req], the composite Paging Agent node is named as 'Paging Agent' in the remaining sections of this concept. The respective functional entity specified in [Sea-Req] is named as 'Paging Agent FE'. Annex C illustrates and explains the assignment of the functional entities of [Sea-Req] to the Paging Agent described in this document. Liebsch, Renker, Schmitz [Page 12] INTERNET-DRAFT Paging Concept for IP based Networks September 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, Schmitz [Page 13] INTERNET-DRAFT Paging Concept for IP based Networks September 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. Furthermore, the Paging Agent SHOULD check, whether or not the received packet is of a type which is allowed to initiate paging of the respective idle mobile terminal. 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. For IPv6 based systems, the realization employs IPv6 Anycasting, both original and mirroring Paging Agent Liebsch, Renker, Schmitz [Page 14] INTERNET-DRAFT Paging Concept for IP based Networks September 2001 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 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 Liebsch, Renker, Schmitz [Page 15] INTERNET-DRAFT Paging Concept for IP based Networks September 2001 that it monitors a set of parameters as the state of ongoing communications, number of handovers, average rate of incoming connections etc. 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 ). Liebsch, Renker, Schmitz [Page 16] INTERNET-DRAFT Paging Concept for IP based Networks September 2001 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). +-----+ (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. For any mobility management system, this common part is the Liebsch, Renker, Schmitz [Page 17] INTERNET-DRAFT Paging Concept for IP based Networks September 2001 registration of a respective Paging Agent with the mobility agent which allows the Paging Agent to receive and buffer initial packets destined to the as idle registered mobile node. 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 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]. Liebsch, Renker, Schmitz [Page 18] INTERNET-DRAFT Paging Concept for IP based Networks September 2001 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. 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). Liebsch, Renker, Schmitz [Page 19] INTERNET-DRAFT Paging Concept for IP based Networks September 2001 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, Schmitz [Page 20] INTERNET-DRAFT Paging Concept for IP based Networks September 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. Furthermore, explicit idle state registration is required in case of an application of this concept with any mobility management system. This keeps the Paging architecture and protocol independent of the mobility management system it is integrated with. In the general case, the Paging Agent registration with the respective mobility agent of the system replaces the MIPv6 Binding Update, as it is illustrated in the figure below, appropriately. Liebsch, Renker, Schmitz [Page 21] INTERNET-DRAFT Paging Concept for IP based Networks September 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]. This is done by updating the exact location of the mobile terminal with its mobility agent, allowing to establish a routable L3 link. 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 Liebsch, Renker, Schmitz [Page 22] INTERNET-DRAFT Paging Concept for IP based Networks September 2001 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 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 * | * * +-> ************ The registration of the PA with the Home Agent is considered in case of having Mobile IPv6 or Mobile IPv4 as mobility management system. For any mobility management system, the Paging Agent address has to be notified to the respective mobility management entity in order to enable reception of initial user data packets, destined to a respective idle mobile node, at the Paging Agent. The respective mobility management entity might also be a local agent (hierarchical approaches). 5.4 Idle State Registration at Correspondent Nodes When entering idle state, the question how correspondent nodes should be informed has to be concerned. This is to be considered when Route Optimization is made use of in a Mobile IPv6 system where correspondent nodes maintain a Binding Cache. 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 Liebsch, Renker, Schmitz [Page 23] INTERNET-DRAFT Paging Concept for IP based Networks September 2001 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 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 For IPv6 based networks, the format of the Idle State Request message is a Destination Options Header [RFC 2460, sec. 4.6]. Since the actual signaling message carried by the IPv6 Destination Options Header is TLV-encoded, the generic format of the options can be conveyed over UDP transport as well. This is in order to keep the related signaling transport transparent to the actual IP version and supports migration scenarios. 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. Further fields COULD be added for further control as TLV-encoded Liebsch, Renker, Schmitz [Page 24] INTERNET-DRAFT Paging Concept for IP based Networks September 2001 options: * a field to allow a mobile node to set filters on which packets, destined to the idle mobile terminal and buffered at the Paging Agent, are allowed to initiate paging the idle mobile node. This option enables a mobile node to configure a set of Multicast/Anycast addresses which are allowed to trigger paging the respective node. For this purpose a list of appropriate IP addresses is to be sent with this filter configuration option message. Acceptance of Broadcast packets can be enabled or disabled with this message. * a field for additional unique identifiers. * a field for specifying an individual paging area (e.g. list of Access Routers). 5.5.2 Idle State Reply Message The counterpart to the Idle State Request is also a Destination Options Header for IPv6 or, alternatively, a message header and body of the same format (TLV-encoded) to be conveyed over UDP transport. 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. * a random value field for identification of Paging Request messages. Once a security strategy has been applied to the paging scheme, both messages COULD be extended to integrate key negotiation. 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, Liebsch, Renker, Schmitz [Page 25] INTERNET-DRAFT Paging Concept for IP based Networks September 2001 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 which are allowed to wake up the respective mobile node. 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 or the packet does not pass the predefined filtering function of packets, which are allowed to wake up a mobile terminal, packets MUST be discarded; the Paging Agent SHOULD send an ICMP error message. After message validation, the Home Address (or an appropriate identifier for respective systems) 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 Paging Reply as specified below arrives before the timeout, this timer is stopped and the Paging Agent validates the Paging Reply Liebsch, Renker, Schmitz [Page 26] INTERNET-DRAFT Paging Concept for IP based Networks September 2001 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. For IPv4 based systems, appropriate protocol tunneling is to be used. 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. For IPv4 based systems or when the signaling transport is to be kept independent of IPv6 specific mechanisms, the TLV-encoded message is to be conveyed in a UDP/IP packet. 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 Liebsch, Renker, Schmitz [Page 27] INTERNET-DRAFT Paging Concept for IP based Networks September 2001 The sub-options have the same TLV-format as the Paging Request message and are defined in [JoPe00b, sec. 5.5]. Specifically defined 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 | +-----+--------+------------------------------+ | 5 | 4 | IPv4 Home Address | +-----+--------+------------------------------+ | 6 | 4 | Random Value | +-----+--------+------------------------------+ If the Home Address of the mobile node is an IPv4 address and the mobile node is IPv6 capable, 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). If the system supports IPv4 only, the type number 5 MUST be used to identify the Home Address of the respective idle mobile node. 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. Liebsch, Renker, Schmitz [Page 28] INTERNET-DRAFT Paging Concept for IP based Networks September 2001 * 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 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 for IPv6. Appropriate addressing is to be applied for IPv4. 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 Liebsch, Renker, Schmitz [Page 29] INTERNET-DRAFT Paging Concept for IP based Networks September 2001 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 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 Liebsch, Renker, Schmitz [Page 30] INTERNET-DRAFT Paging Concept for IP based Networks September 2001 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 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 Liebsch, Renker, Schmitz [Page 31] INTERNET-DRAFT Paging Concept for IP based Networks September 2001 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]. An appropriate control mechanism for IPv4-only systems is to be done. 7.1 Discovery of Paging Capabilities 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. Liebsch, Renker, Schmitz [Page 32] INTERNET-DRAFT Paging Concept for IP based Networks September 2001 Otherwise, it MUST be set to zero. The same approach can be applied for IPv4 networks and makes use of an extension for ICMP Router Advertisement. In this case, the IP address of the related Paging Agent is advertised. 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 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 Liebsch, Renker, Schmitz [Page 33] INTERNET-DRAFT Paging Concept for IP based Networks September 2001 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 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 Liebsch, Renker, Schmitz [Page 34] INTERNET-DRAFT Paging Concept for IP based Networks September 2001 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 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. Liebsch, Renker, Schmitz [Page 35] INTERNET-DRAFT Paging Concept for IP based Networks September 2001 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]. 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 Liebsch, Renker, Schmitz [Page 36] INTERNET-DRAFT Paging Concept for IP based Networks September 2001 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 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 Liebsch, Renker, Schmitz [Page 37] INTERNET-DRAFT Paging Concept for IP based Networks September 2001 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 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, Schmitz [Page 38] INTERNET-DRAFT Paging Concept for IP based Networks September 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 unstable 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, Schmitz [Page 39] INTERNET-DRAFT Paging Concept for IP based Networks September 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, Schmitz [Page 40] INTERNET-DRAFT Paging Concept for IP based Networks September 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, Schmitz [Page 41] INTERNET-DRAFT Paging Concept for IP based Networks September 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 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. General security aspects are addressed in (section 10.4) and in (Appendix D). 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 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 advertisements or Dynamic Paging Agent Address Discovery (sec. 7.1.3), there is no given proof of trustworthiness. Liebsch, Renker, Schmitz [Page 42] INTERNET-DRAFT Paging Concept for IP based Networks September 2001 * 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 share encryption keys, confidentiality of possibly valuable user data can be provided. * The paging messages might also be in plain text and duplicated several times. These contain the Home Address or another value that can be used 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. 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 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. 10.4 General Paging Architecture Aspects The security architecture for IP based networks we refer to is as follows: Security management of a specific domain (possibly an administrative Liebsch, Renker, Schmitz [Page 43] INTERNET-DRAFT Paging Concept for IP based Networks September 2001 domain) is done having a distributed control architecture consisting of an AAA.f (Foreign Network AAA-Server) which has control of multiple Access Routers, each has an Attendant for AAA implemented. Mobile nodes authenticate with a foreign network through the Attendant- Agent of the respective Access Router it is connected through to the network. Attendants always contact their related AAA.f, which authenticates mobile nodes at the respective AAA.h (Home Network AAA-Server) and maintains a data base entry for these authentications, valid for the respective domain. This refers to [RFC 2977]. In general, the concept refers to standard IPSec structures for authentication and encryption. Having an architecture as described in this document for Paging integrated modularly to an existing IP based system, beside the general security related aspects the following three scenarios were identified to be analyzed: (1) A mobile node wants to enter idle state in a specific domain and wants to discover a trustworthy Paging Agent (Paging Agent service authentication). (2) When the mobile node wants to register idle state with the selected Paging Agent, the mobile node has to proof its identity to the Paging Agent (MN authentication). (3) When the Paging Agent initiates paging a registered idle mobile node, the mobile node has to check integrity of the incoming Paging Request message in order to ensure, that paging has been initiated by a trustworthy Paging Agent (Paging Agent process authentication). For (1), when a mobile node has been authenticated with the administrative domain it is roaming in, it should trust the respective Access Router he has authenticated through. When a Paging Agent address is advertised, the Paging Agent can be considered as trustworthy. For Paging Agents which are outside a respective administrative domain (e.g. for inter-domain paging), an appropriate mechanism is relied on for establishment of a security association. This might be a static security association when the Paging Agent is located in the mobile nodes home domain. For (2), when the mobile node wants to register with a Paging Agent, it has already authenticated with the respective domain. In this case, the Paging Agent has an implicit security association with the mobile node and might request appropriate keys from the local AAA.f. Other approaches for the establishment of a security association might be considered, especially, when the Paging Agent is located outside the administrative domain where the mobile node is roaming in AND the respective Paging Agent is NOT located in the mobile nodes home domain (see case (1) above). For (3), when a Paging Agent sends Paging Request messages to mobile nodes which are registered as idle, the Paging Request message has to Liebsch, Renker, Schmitz [Page 44] INTERNET-DRAFT Paging Concept for IP based Networks September 2001 be authenticated in order to ensure, that the mobile node is able to check the identity of its Paging Agent with the received message. Additionally, we propose to have an individual random value for the actual paging process as a shared secret, which is given to the mobile node during the explicit Idle Mode Request/Reply signaling between the mobile node and the Paging Agent. The Paging Agent sends back a random value to the mobile node in the Idle Mode Reply message. In this case, the reply message is to be encrypted. This identifier is to be kept by both entities, the mobile node and the Paging Agent. The random value is valid until the mobile node registers as active next time (initiated either actively or passively). 11 IANA CONSIDERATIONS The following addresses and message formats have to be registered with IANA. 11.1 Message Formats +------------------------------+-------------------+----------------+ | 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 Liebsch, Renker, Schmitz [Page 45] INTERNET-DRAFT Paging Concept for IP based Networks September 2001 * 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. 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 Liebsch, Renker, Schmitz [Page 46] INTERNET-DRAFT Paging Concept for IP based Networks September 2001 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]. * 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, Liebsch, Renker, Schmitz [Page 47] INTERNET-DRAFT Paging Concept for IP based Networks September 2001 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., 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, RFC 3132, June 2001 [Sea-Req] J. Kempf et al., Requirements and Functional Architecture for an IP Host Alerting Protocol, RFC 3154, August 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, Liebsch, Renker, Schmitz [Page 48] INTERNET-DRAFT Paging Concept for IP based Networks September 2001 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, Schmitz [Page 49] INTERNET-DRAFT Paging Concept for IP based Networks September 2001 B AUTHOR'S ADDRESSES Marco Liebsch, Gerrit Renker, Ralf Schmitz 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 Ralf.Schmitz@ccrle.nec.de C MAPPING OF THE FUNCIONAL ARCHITECTURE WITH RFC 3154 This section gives a comparison on how the functional entities of the functional architecture of RFC 3154 are assigned to the Paging concept described in this document. C.1 Composite Architecture of the Paging Agent The Paging Agent concept as it is described in this document may cover the Dormant Monitoring Agent functional entity (FE), the Tracking Agent FE as well as the Paging Agent FE in one physical machine (composite Paging Agent). A distributed architecture is possible. The following illustration shows the assignment of the individual functional entities covered by the composite Paging Agent node to the related communication peer. Liebsch, Renker, Schmitz [Page 50] INTERNET-DRAFT Paging Concept for IP based Networks September 2001 update & Composite Paging Agent idle/active +-------------------------------------+ registration | +--------+ +----+ | +- - - - - - - - -|- - - - - ->|Tracking|<>|Data| | | | |Agent FE| |Base| | | | +--------+ +----+ +----------+ +------+ +------+ +--------+ | | Dormant | |Mobile|<|Access|<-+| Paging | +--------------|Monitoring| | Node |<|Router| ||Agent FE|-------------------------| Agent FE | +------+ +------+ |+--------+ +----------+ | | | | +-------------------------------------+ +------+ | <|Access|<-+ <|Router| +------+ | | | | |<-------|<----------| --------------- // -------------- |<--- L2/L3 L3 incoming Paging Paging user data packet In order to avoid performance degradation and decreased scalability at the composite Paging Agent architecture, the Dormant Monitoring Agent is logically the functional entity which is registered with the respective mobility management entity. Intentionally, this entity receives only user data packets, which are destined for mobile nodes registered as idle with the respective composite Paging Agent. This avoids scanning and processing other packets than packets, which are destined to registered idle mobile nodes. During a mobile nodes idle registration process with the composite Paging Agent as well as for updating Paging Area information, the mobile node addresses logically the Tracking Agent functional entity, which maintains an appropriate data base. When a user data packet comes in and has been validated to be allowed to trigger paging the respective idle mobile node (addressing a registered idle mobile node and passing a configurable filtering function), the Paging Agent distributes the L3 Paging Request messages according to the selected paging strategy to all Access Routers assigned to the respective Paging Area (see section 4.). The paging protocol does not make any assumption about the technology used for access provision. Individual Access Routers receiving the L3 Paging Request can make use of L2 specifics of the respective access technology in order to support the paging process and technology specific dormant modes (see section 3.4.2). Liebsch, Renker, Schmitz [Page 51] INTERNET-DRAFT Paging Concept for IP based Networks September 2001 D CONFORMANCE CHECK WITH RFC 3154 D.1 Impact on Power Consumption The paging concept described in this document for IP based Networks allows and supports a registered idle state of a mobile node. In this state the power consumption of the mobile is minimized (possibly with hardware supported power saving mode), because no battery exhausting IP address configuration and sending of Binding Updates is necessary, even if the mobile terminal is roaming. Beyond that, the scope of the new entity, called Paging Agent, may extend several administrative domains. This 'inter-domain paging' in combination with advanced paging strategies (section 3.3) reduces the frequency of signaling and therefore the reduction of power consumption even more. Therefore, this paging concept conforms with the required Impact on Power Consumption. D.2 Scalability One of the main design goals of the Paging Concept for IP based Networks is the 'KISS' principle: Keep It Simple and Scalable (section 1.2), by the deployment of modular construction, i.e., the paging concept integrates modularly into the mobility environment and is therefore open for possible future extensions. The concept allows static paging areas as well as dynamically assignment of paging areas and considers mirroring of Paging Agents, introducing a service redundancy to avoid single point of failures in the network. Furthermore, a hierarchy of Paging Agents is considered in the document. All this scalability features provide the framework for a load sharing between the agents: Paging Agents are distributed over the network (e.g., one or more Paging Agents per administrative domain) and therefore one Paging Agent only serves a limited number of mobile hosts, providing scalability for millions of hosts, as required in [Sea-Req]. In case a single Paging Agent reaches the limit of its serving power, the concept is extendable to relay the service requesting mobile node to another Paging Agent serving the specific area (e.g., relaying the request or modifying the advertisement), in order to scale even for this scenario, which is unlikely, because the paging area is restricted. D.3 Control of Broadcast/Multicast/Anycast When a mobile node intends to enter a power saving dormant mode, it sends an appropriate Idle State Request message to its serving Paging Agent (see section 5.5.1). Beside mandatory information elements, a message option can be sent with the Idle State Request to change default filter settings for Broadcast, Multicast and Anycast addresses individually. In case of allowing a set of Multicast addresses to trigger paging the respective mobile node, a list of Multicast addresses or/and Anycast addresses is to be sent with the Idle State Request message from the mobile node to the Paging Agent. Liebsch, Renker, Schmitz [Page 52] INTERNET-DRAFT Paging Concept for IP based Networks September 2001 The filtering function is to be integrated with the Dormant Monitoring Agent functional entity. Since the Idle State Request message is processed by the Tracking Agent functional entity, individual settings on this filter are stored in the data base the Tracking Agent functional entity is maintaining and be requested by the Dormant Monitoring Agent functional entity in case of an incoming packet. D.4 Efficient Signaling for Inactive Mode The Tracking Agent is considered as functional part of the Paging Agent. After reception and validation of incoming data at the Paging Agent, the identifier of the message (i.e., the home address in case of the referenced Mobile IPv6 architecture) is used to look up the entry for the mobile node in internal database 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. Therefore, efficient signaling, as required in [Sea- Req], is provided, because paging will not be initiated without a valid entry in the database tables. Assuming that a mobile node going to Inactive Mode deregisters with the Paging Agent, there is no need for maintaining a dedicated Inactive Mode in the database tables for standard, error-free scenarios. Nevertheless, there may occur error cases, like sudden connection break down, in which additional mechanisms have to protect the system of flooding the Paging Area permanently with Paging Request messages. This is realized having a binary exponential backoff mechanism for retransmission of Paging Request messages. Additionaly, after a configurable amount of retransmissions, sending of Paging Request messages are inhibited by locking the data entries of the mobile node, for a configurable time of LOCK_TIME (section 6.1). D.5 No Routers The Paging Concept described in this document does not consider mobile routers, as stated in [Sea-Req], but is open to be extended if the need arises. D.6 Multiple Dormant Modes The IP paging proposal provided in this document is independent of the underlying layer-2 medium. The mapping to layer-2 specific signaling takes place at the Access Router, the only host, which has to consider layer-2 specifics (section 1.1.3). Assuming layer-2 mapping and specifics at the Access Router, the proposed paging protocol is able to cope with technology dependent dormant modes, as required in [Sea-Req]. If multiple modes within a technology have to be considered and to be made configurable by the mobile node, the mobile node must notify the Paging Agent of the desired mode for the respective technologies, which has to be considered in the Paging Request distribution and to be mapped to the individual technologies Liebsch, Renker, Schmitz [Page 53] INTERNET-DRAFT Paging Concept for IP based Networks September 2001 at the Access Routers. D.7 Independence of Mobility Protocol The modular construction of this proposal specifies a paging concept for IP based networks, independent of the underlying layer-2 medium, the deployed paging strategy and is especially kept separate and independent from a specific mobility protocol, as required in [Sea- Req]. The concept provides support for the existing mobility protocols, which is shown by the use of Mobile IPv6 [JoPe00b] as reference/example mobility protocol, but is not restricted to this protocol. The separate entity ´Paging Agent´ integrates modularly to systems and provides the paging functionality. In order to keep the registration with a Paging Agent independent of the mobility protocol, (section 5.2.4) introduces explicit signaling for Idle Mode Request/Reply. The concept is in line with [Sea-Req] with this regard. D.8 Support for Existing Mobility Protocols The proposed paging concept for IP based networks uses Mobile IPv6 [JoPe00b] as reference mobility protocol and provides a solution deploying IPv6 and Mobile IPv6 specific features (e.g., make use of the alternate care-of address sub-option [JoPe00b, sec. 5.5]). Nevertheless, the concept is also suitable to support Mobile IPv4, because the concept is independent of the mobility protocol (e.g., message transport in IPv6 Destination Option is to be replaced by standard UDP transport). Therefore, the concept is in line with the requirement for support of existing mobility protocols. D.9 Dormant Mode Termination The paging concept for IP based networks is independent of the paging strategy and the underlying layer-2 medium. The Paging Agent initiates a page by using solely IP as signaling layer. The mapping to layer-2 specific signaling takes place at the recent Access Routers, which are the only nodes taking layer-2 specifics into account. If paging is already supported on layer-2, this fact SHOULD be taken into account by the specific mapping function on the recent Access Routers. The paged mobile node MUST re-enter active state and re-establish a routable L3 link with the network upon the reception of either a layer-2 paging signal or an IP paging request packet. This is in conformance with the paging requirements [Sea-Req - sec. 4.9]. D.10 Network Updates The concept considers different approaches for Paging Area identification when a mobile node is registered idle. The approaches are different for static and dynamically configurable Paging Areas. In case of having static Paging Areas, a Paging Area Identifier is Liebsch, Renker, Schmitz [Page 54] INTERNET-DRAFT Paging Concept for IP based Networks September 2001 broadcasted in the respective Paging Area, which are assigned a specific set of Access Routers. In order to avoid flooding the network side of a Paging Area with periodic advertisements (Paging Area ID), the concept proposes to include appropriate Paging Area identifies in Access Router Advertisements. This requires administrative configuration of Access Routers. When individual configuration of Paging Areas are considered, the assignment of a single Paging Agent per Paging Area is not suitable. This feature is supported by the concept described in this document (section 4.4). In this case, individual Paging Areas are identified by a list of Access Router identifies (e.g. IP address) known by the respective mobile node and its Paging Agent. D.11 Efficient Utilization of L2 The paging concept for IP based networks considers the efficient utilization of layer-2 paging (section 3.4.2) by making use of recent mapping functions at the Access Routers. Therefore, paging on layer-2 SHOULD be taken into account by the specific mapping function, in case it is available, providing the required efficient utilization of L2, as defined in [Sea-Req - sec. 4.11]. D.12 Orthogonality of Paging Area and Subnets The paging concept for IP based networks allows an arbitrary mapping between subnets and Paging Areas, as required in RFC 3154 - sec. 4.12, by the deployment of the Paging Agent as separate entity, which manages paging related functionality. The scope of the Paging Agent may extend several administrative domains, a feature called inter- domain paging, even expanding the required orthogonality of Paging Areas and Subnets. Since the Paging Agent sees one or more Access Routers assigned to a Paging Area, from the Paging Agents point of view a Paging Area is constructed out of one or more subnets. Regarding L2 Paging Areas, the reader is referred to (section 9.1). D.13 Future L3 Paging Support The modular construction of the paging concept for IP based networks makes it easy to adapt the concept to a possible future IP mobility protocol. The concept provides an IP paging solution independent of the deployed paging strategy and the underlying layer-2 medium. A specific layer-2 paging functionality is used by recent mapping functions at the Access Routers, but it is not required for the paging concept, since this is solely IP based. The draft supports initiation of active state re-establishment of a mobile node by the reception of either a layer-2 paging signal or an IP paging packet, which shows the flexibility and the support of different schemes and paging strategies, which is open for future extensions, as required in [Sea-Req -sec. 4.13]. D.14 Robustness Against Failure of Network Elements Liebsch, Renker, Schmitz [Page 55] INTERNET-DRAFT Paging Concept for IP based Networks September 2001 In order to provide robustness against failure of network elements, Paging Agent redundancy is proposed in (section 4.3) of this concept. One centralized, single Paging Agent introduces a single point of failure. Therefore, mirroring of Paging Agents is proposed in (section 4.3), e.g. by deployment of an IPv6 anycast address. In case of failure of a Paging Agent, redundant Paging Agents will still be reachable under the same common address and provide the required robustness of [Sea-Req]. D.15 Reliability of Packet Delivery The paging concept for IP based networks is independent of the transport protocol, i.e., it supports unreliable UDP connections as well as reliable TCP connections and therefore, packet delivery is as reliable as the underlying transport protocol or the application itself. The Paging Agent is involved in routing and packet delivery only if data for an idle registered mobile node, which has to be paged, arrives. To ensure robust delivery of this data (i.e., packet delivery is reliable to a high degree of probability), the buffer size of the message queue, which is allocated to buffer incoming packets while the mobile terminal is in the process of being paged, has to be big enough to store all packets without buffer overflow. This involves the deployed paging strategy, because depending on the paging strategy the paging timeout is set, in order to decide when a mobile node is considered to be unreachable. These considerations are made in (section 6.1) and therefore the requirement for reliability of packet delivery is fulfilled. Furthermore, the reliability is enhanced by the deployment of redundancy of Paging Agents (section 4.3), as described above. D.16 Robustness Against Message Loss The registration process (e.g., idle registration or active registration) is based on an acknowledgement mechanism (section 5) and the with the Paging Request a timer is started, in order to invoke retransmission if there is no Paging Reply after the timeout occurs (section 6.1). Therefore, the Paging Concept for IP based Networks conforms to RFC 3154 in this item. However, the reliability of a page is highly depending of the deployed Paging Strategy, whereas this concept supports any kind of Paging strategy [RENK01 - sec. 3.3]. D.17 Flexibility of Administration Administrative configuration of Paging Agents can be kept flexible, since mobile node specific settings like individual Paging Area assignment is either configured by mobile nodes in the registration process before entering the idle mode or might be supported by Paging Agent extensions as described in (section 4.2). Additional mechanisms are proposed to remotely configure Access Routers, which support the paging process (section 9.5). Liebsch, Renker, Schmitz [Page 56] INTERNET-DRAFT Paging Concept for IP based Networks September 2001 D.18 Flexibility of Paging Area Design The paging concept for IP based networks provides high flexibility of paging area design by supporting static and dynamic paging area concepts (section 4.4). If static paging areas are used, only the bindings - Home Address ==> Paging Area - Paging Area ==> {[AR_1], [AR_2], ... [AR_N]} are stored in the system of tables which maintain the paging state information. If Adaptive Individual Paging [Cast99] is used, the mobile terminal can communicate a list of Access Routers it considers as its best possible paging area to the Paging Agent. This list is dynamic and therefore supports dynamic paging area design. With the modular construction, the scope of the Paging Agent may extend several administrative domains and therefore supports inter-domain paging. This increases the flexibility of dynamic paging areas even more, because dynamic paging areas may even extend several administrative domains (Note: to enable this feature, security aspects are to be comprised). The administrative scope of a Paging Agent and the paging area topology remain configurable, e.g., the required topology of one Paging Agent per domain is also possible. D.19 Availability of Security Support Currently, the concept relies on message extensions for authentication and encryption covered by IPSec for IPv6 and IPv4. An analysis of security aspects and how the current paging concept integrates into IP based systems from security point of view is covered in (section 10). D.20 Authentication of Paging Location Registration The current concept relies on the aspects for authentication of a mobile node with an administrative domain as described in (section 10). This addresses the integration of the Paging Agent into an architecture which has a security framework as referred to in (section 10.4). D.21 Authentication of Paging Area Information Distribution of Paging Area information is performed by Access Routers. Since these Access Routers belong to a specific domain and advertisement of Paging Area information is not distributed from a node located beyond the scope of an individual Access Router, broadcast information is ensured to to be originated on the local link. This means, no packets coming from outside have to be authenticated. D.22 Authentication of Paging Messages Paging Request messages can be authenticated by having a pre- established security association between the mobile node and the Liebsch, Renker, Schmitz [Page 57] INTERNET-DRAFT Paging Concept for IP based Networks September 2001 Paging Agent. Additionally, a shared secret is exchanged between the mobile node and the Paging Agent during the Idle Mode Registration process before a mobile node enters the dormant mode. The Idle Mode Reply message sent back from the Paging Agent to the mobile node is to be encrypted appropriately. This shared secret is a random number determined by the Paging Agent and identifies the following Paging Request message (section 10.4). D.23 Paging Volume The Paging Agent is able to scale for a large number of paging requests, since the processing and system table maintenance is kept simple. Redundancy of Paging Agents (section 4.3) or hierarchical Paging Agent approaches (section 8.2), which are considered in the proposal, could also be used to share the load in the unlikely case that a single Paging Agent gets overloaded. D.24 Parsimonious Security Messaging The protocol allows to have an additional shared secret between the Paging Agent and the mobile node for identification of the Paging Agent during the paging process. This allows to have a pre- identification of incoming Paging Request messages. Getting individual identifiers does not imply additional signaling, since the exchange of the random value is part of the Idle Mode Registration. Hence, no superfluous power is consumed on additional signaling. D.25 Noninterference with Host's Security Policy Having an independent explicit signaling for Idle State Registration and for the Paging Process as well as a system, which integrates modularly to any IP based platform, the security policy of the paging concept does not interfere with a host's security policy. D.26 Noninterference with End-to-end Security Paging is integrated modularly to any system and is kept transparent to end-to-end communication. End-to-end security is not broken since user data packets sent to idle mobile nodes are buffered and forwarded to the mobile hosts without any modifications after the respective mobile node has been paged and has established a routable link to its current location. D.27 Detection of Bogus Correspondent Nodes Having an option to set filters within the Paging Agent on addresses for Multicast/Anycast, which are not allowed to trigger paging a mobile node, provides a method to at least use a similar filter setting function at the Paging Agent to specify individual 'Source Addresses', which are not allowed to trigger paging. This is not a real feature and might be automated by a higher layer bogus Liebsch, Renker, Schmitz [Page 58] INTERNET-DRAFT Paging Concept for IP based Networks September 2001 correspondent node detection mechanism. An advanced mechanism is not specified within the framework of this version of the protocol proposal. Liebsch, Renker, Schmitz [Page 59]