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