INTERNET-DRAFT M. Liebsch
G. Renker
R. Schmitz
NEC Network Laboratories Europe
Expires March 2002 September 2001
Paging Concept for IP based Networks
<draft-renker-paging-ipv6-01.txt>
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]