INTERNET-DRAFT Marco Liebsch
Expires March 2003 Yoshihiro Ohba
[Editors]
Tao Zhang
September 2002
Architecture and Protocol framework for Dormant Mode Host Alerting
<draft-liebsch-dmha-framework-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 discusses and describes an architecture and protocol
framework for the design and specification of a generic IP based
architecture and protocol for Dormant Mode Host Alerting, aka IP
paging. It focuses on the location and operation related interworking
of the different functional entities as required to allow for a
flexible and scalable deployment of the protocol. Furthermore,
protocol transport and security mechanisms are evaluated and proposed
to meet respective requirements on a DMHA protocol. This document
intends to be a comprehensive guideline for the design of a generic
IP paging architecture and protocol.
Liebsch, Ohba, Zhang [Page 1]
INTERNET-DRAFT A framework for Dormant Mode Host Alerting September 2002
Table of Contents
1. Introduction ............................................ 2
1.1 Background information .................................. 2
1.2 General Overview ........................................ 3
2. Terms ................................................... 4
3. Dormant mode supporting nodes ........................... 6
4. Paging area design ...................................... 6
5. The role of the paging strategy ......................... 8
6. Dormant mode location management ....................... 10
6.1 General description .................................... 10
6.2 Proposal evaluation .................................... 10
6.2.1 Mobility proprietary solutions ......................... 10
6.2.2 Mobility independent solutions ......................... 10
6.2.3 Hybrid solutions ....................................... 11
6.2.4 Last-hop solutions ..................................... 12
6.3 3GPP considerations .................................... 12
7. DMA function ........................................... 13
7.1 DMA location and modes ................................. 13
7.1.1 Paging trigger packet reception ........................ 13
7.1.2 Paging trigger packet capturing ........................ 14
7.2 Filtering for DMHA ..................................... 15
8. PA function ............................................ 15
8.1 Functional split of the PA function .................... 15
8.2 Addressing of core components .......................... 16
8.3 Addressing of last-hop components ...................... 17
9. Signaling transport .................................... 17
10. Security support ....................................... 18
10.1 Security threat categories ............................. 18
10.2 Consideration for Category 1 attacks ................... 19
10.2.1 Candidate security mechanisms for DMHA ................. 19
10.2.2 Establishing an SA ..................................... 20
10.3 Consideration for Category 2 attacks ................... 21
11. Availability ........................................... 22
11.1 Related nodes .......................................... 22
11.2 Evaluated mechanisms ................................... 23
11.3 Proposed solution ...................................... 23
A References ............................................. 23
B Author's addresses ..................................... 25
C Overview on access technologies ........................ 26
C.1 802.11 Power Management ................................ 26
1. Introduction
1.1 Background information
This document describes an architecture and protocol framework
evaluation for the design and specification of a generic IP based
Liebsch, Ohba, Zhang [Page 2]
INTERNET-DRAFT A framework for Dormant Mode Host Alerting September 2002
architecture and protocol on Dormant Mode Host Alerting (DMHA), aka
IP paging. This framework document is related to various candidate
solutions for the issues addressed in [1] and focuses on the location
and operation of the different functional entities as identified in
[2], required for flexible and scalable deployment of the protocol.
Furthermore, protocol transport and security mechanisms are evaluated
and proposed to meet the requirements of a generic IP paging
protocol, as described in [2].
Various proposals with different characteristics are addressed,
discussed and evaluated with respect to meeting the requirements as
identified in [2]. Since the generic protocol for IP paging should be
independent of the access technology, but deployment of access
technology and interface specific support for dormant mode as well as
paging should be allowed, the framework has to take appropriate
functions into account to allow for mapping the generic IP paging
protocol to technology specifics. In case of not getting support on
dormant mode and paging from layers below the IP layer on the access
link and respective interfaces, the framework should allow
integration of appropriate features on IP level, supporting dormant
mode and the paging process in an efficient way.
1.2 General Overview
A generic IP paging architecture and protocol targets at an access
technology independent solution for finding and re-activating dormant
mobile terminals. The generic nature aims at the integration into
various IP mobility managed platforms to support heterogeneous
access. Since paging on a mobile terminal's access interface is in
most cases optimized taking technology specific functions for dormant
mode support and the paging procedure into account, the architecture
and protocol to be specified for a generic IP paging solution MUST
allow for the mapping of the common IP paging protocol to access
technology specific functions.
Evaluation of requirements and the attempt to integrate a set of
candidate protocols for IP paging into various IP mobility management
schemes has shown, that demand on the architecture and the protocol
for IP paging varies. Therefore, aiming at a generic solution while
meeting requirements on flexibility and scalability demands thorough
analysis of different proposals on how to design the architecture for
IP paging. In particular the placement and distribution or co-
location of individual paging related functional entities, as
indicated in [2], is to be evaluated for individual mobility schemes
and network characteristics.
The challenge is to find a compromise between complexity and
flexibility, taking the placement of different paging functional
entities and interworking between them into consideration. Further
issues to be evaluated are demands with respect to availability. In
Liebsch, Ohba, Zhang [Page 3]
INTERNET-DRAFT A framework for Dormant Mode Host Alerting September 2002
this regard, the IP paging architecture has to allow approaches for
the introduction of redundancy and efficient deployment of fail-over
handling mechanisms. A further demand is to allow providers a high
degree of flexibility in paging area design, taking co-existence of
L2 and L3 paging areas into account.
This document intends to be a guideline for the design of a generic
IP paging architecture and protocol. The various issues addressed in
individual sections should be evaluated more and more, aiming at a
significant framework document for design recommendations. The
implementation and comparison of various protocol proposals as well
as an evaluation by means of simulations and theoretical approaches
is intended to find the best way to go for the architecture's and
protocol's design.
2. Terms
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.
In terms of IP based paging, this document tries to be as close as
possible to the paging problem statement [1]. To resolve ambiguities,
the following terms are defined for the context of this document. In
addition, please be referred to [4].
Access Router
a router that provides access to a (potential) L2
connection to the mobile node
Active State
mobile node state, mainly characterized by the
following characteristics:
1. an established L2 connection
2. the communication peer of mobile node knows the currently
configured IP address of the MN
3. the L2 connection is used to carry L3 data traffic
Black Hole
packet loss without any control of the system
Connection
established L2 connectivity, providing transport
service for L3 traffic
L2
Liebsch, Ohba, Zhang [Page 4]
INTERNET-DRAFT A framework for Dormant Mode Host Alerting September 2002
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
IPsec
Security Architecture for the Internet Protocol (RFC 2401)
Location
smallest indivisible unit at which a mobile node can be
located (e.g. a single base station)
MN
mobile node
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
Liebsch, Ohba, Zhang [Page 5]
INTERNET-DRAFT A framework for Dormant Mode Host Alerting September 2002
for the purpose of routing L3 data traffic to it
3. Dormant mode supporting nodes
There are three kinds of IP nodes that may support dormant mode.
Dormant mobile hosts support both dormant mode and IP mobility (i.e.,
Mobile IP, Mobile IPv6 and/or micro-mobility). A dormant mobile host
may move from one IP subnet to another without updating its mobility
bindings needed for routing IP packets from mobility management
agents to the host. In other words, L3 routability is not guaranteed
for dormant mobile hosts. So additional signaling mechanism (i.e.,
DMHA) is necessary for realizing locatability in order to search the
dormant mobile hosts and notify them of the arrival of data packets
so that they can update their mobility bindings and perform IP
mobility signaling to recover L3 routability.
Dormant stationary hosts support dormant mode but do not support IP
mobility. A dormant stationary host is not supposed to change the IP
subnet or even location in some L2 as long as it is in dormant mode.
However, this does not mean that L3 routability is guaranteed for
dormant hosts. For example, if a traffic channel and a signaling
channel are provided separately with different frequencies, time-
slots or codes, and a dormant stationary host does not listen to the
traffic channel, locatability needs to be provided over the signaling
channel in order for the dormant host to "switch-on" the traffic
channel when it is alerted. Or when L2 dormant mode support is
available, some locatability needs to be provided at L3 by
maintaining information that is necessary to utilize the L2 dormant
mode service. For example, although an 802.11 access point maintains
a list of the MAC addresses of active and dormant stations associated
with it, there must be some mechanism to maintain, as such
information described above, the mapping between the MAC address and
IP address of a dormant host, since 802.11 itself does not care about
IP address.
Dormant routers support both dormant mode and IP packet forwarding.
A dormant router is different from a dormant host in that a previous
hop router of the dormant router triggers alerting based on the next
hop IP address of an incoming packet not on the destination IP
address. When a dormant router that wakes up to receive an incoming
packet then may trigger another alerting to forward the packet, where
the node to be alerted may either a dormant host or a dormant router.
A dormant router may be stationary or mobile.
4. Paging area design
Paging areas can be static or dynamic. A static paging area does not
Liebsch, Ohba, Zhang [Page 6]
INTERNET-DRAFT A framework for Dormant Mode Host Alerting September 2002
change unless re-configured by the network operator manually or via
network management system. A dynamic paging area may change
dynamically in response to changing network dynamics, such as the
changing geographical distribution of the mobile user population and
the changing mobility pattern of the mobile users.
Paging area design is to determine how paging areas should be
constructed and modified. Paging area design could have significant
impact on the signaling overheads incurred for location update and
paging. For example, small paging areas could increase the frequency
at which mobile hosts have to update their locations, but may reduce
the paging signaling overhead incurred by the network to locate the
mobile host. Dynamic paging areas, if designed properly, could reduce
the overall paging-related signaling overhead (including the
signaling overheads for location update and paging). However,
supporting dynamic paging areas may need complex algorithms, software
and interactions among network nodes for maintaining and modifying
the paging areas dynamically. Therefore, a key issue in the design of
paging protocol is to allow a network operator to achieve a proper
balance between paging-related signaling overheads and system
complexity by supporting a proper degree of flexibility in paging
area design.
An IP layer paging area is a set of IP layer network attachment
points. When designing IP layer paging areas, the following issues
that are specific to IP networks also need to be addressed:
1. How should an IP layer paging area be mapped into IP subnets?
2. How should an IP layer paging area be mapped into layer 2
paging areas?
3. How to identify an IP paging area?
4. How to route packets to an IP paging area?
5. How to disburse packets within an IP paging area to the dormant
mobiles?
A straightforward IP layer paging area design is to map IP paging
areas one-to-one to the underlying IP subnets. That is, every subnet
makes a separate IP paging area. This however, could force blanket
paging to the entire network in many cases. For example, in today's
enterprise wireless networks, one single IP subnet is often used to
support all the mobile users in one location. In many such existing
networks, hundreds of mobile users are supported on the same subnet
that has high capacity enabled by, e.g., switched LAN technologies.
In such networks, if the IP subnet is a single IP paging area, all
paging messages could be broadcast to all active and dormant mobile
users on the subnet. This could lead to a significant waste of the
scarce power resources on both the active and dormant mobiles.
Therefore, an IP paging protocol should allow flexible design of
paging areas. For example, it should allow an IP paging area to span
only part of one IP subnet or across multiple IP subnets. Such a
flexible IP paging protocol will allow a network operator to
Liebsch, Ohba, Zhang [Page 7]
INTERNET-DRAFT A framework for Dormant Mode Host Alerting September 2002
customize the design of the paging areas to fit its own business
requirements.
While it is important to support flexible paging area designs, it is
equally important to reduce the potentially high protocol and network
complexity associated with supporting such flexible paging area
designs. Take supporting dynamic paging area for example. When paging
areas are changed dynamically, the number and the shapes of the
paging areas may change accordingly. These changing paging areas need
to be identified at the IP layer. When the paging areas covering a
specific location changes, the changes need to be communicated to the
network entities that are responsible for advertising the paging area
identities to the mobiles. The mobiles in these affected locations
also need to be informed of the changes in a timely manner. These
requirements could significantly increase the complexity of a paging
protocol if the protocol is not designed properly. Support for
flexible paging area design may also impact the architecture of a
paging protocol because it impacts the locations and operations of
paging agents. For example, if a dedicated paging agent is used for
each paging area and N paging agents are configured in a network,
then no more than N paging areas can be supported simultaneously.
Therefore, intelligent methodologies need to be developed to make the
IP paging protocol simple and yet effective in supporting the
flexibility needed in paging area design.
When a paging area contains multiple IP access routers, a paging
message can be sent to these access routers either via unicast or
multicast. Disbursing of paging messages over the wireless media may
be carried out in any way available in each particular wireless
medium.
5. The role of the paging strategy
Many paging strategies exist today. They can be classified into the
following categories:
o Blanket paging:
A paging message is broadcast simultaneously to all dormant
mobiles inside a paging area. Blanket paging is used in most of
today's wireless networks. Its main advantage is that it generates
the least paging latency. The potential drawback, however, is that
broadcasting paging messages to all mobiles in a large paging area
could consume a significant amount of scarce resource, including
power on all the mobiles in the paging area and the radio bandwidth
in the radio network.
o Sequential paging:
With this strategy, a large paging area is divided into small
paging sub-areas. Paging messages are first sent to a subset of the
Liebsch, Ohba, Zhang [Page 8]
INTERNET-DRAFT A framework for Dormant Mode Host Alerting September 2002
paging sub-areas where the network believes the mobile is most likely
to be. If the target mobile is not found in one sub-area, subsequent
paging messages will be sent to another sub-area. This process
continues until the entire paging area is searched or the target
mobile is located. Different techniques may be used to determine how
to divide a large paging area into smaller paging sub-areas and which
sub-areas should be searched first.
o Individual paging:
With this strategy, an individualized paging area is maintained
dynamically for each mobile host. To page a mobile host, paging
messages will be sent to the mobile host's individualized paging
area.
o Other:
Other paging strategies also exist that cannot be clearly
classified into any of the categories mentioned above. For example,
Geographic position-based paging uses the geographical position of a
mobile to determine where a paging message should be send. Group
paging sends paging messages to a group of dormant mobiles at a time
instead of one individual mobile each time.
The choice of paging strategy has a significant impact on the paging
performance (e.g., paging latency), paging-related signaling
overhead, and network complexity. A good paging strategy should
allow a network operator to achieve a balance among
* Paging-related signaling overhead,
* Paging latency, and
* Network complexity
Which paging strategies fit a network operator's business needs
depend on the specific network environment and business needs of each
specific network operator. It is therefore important for a paging
protocol to support different paging strategies.
Furthermore, paging strategy, paging area design and location update
strategy depend on each other closely and impact the design of the
paging protocol. For example, if only blanket paging is used, each
mobile has to update its location every time it moves into a new
location area and the location update has to be performed reliably.
On the other hand, if sequential paging is used, the network could
send subsequent paging messages to enlarge its search area if it
cannot find a dormant mobile in one location area. Therefore, with
sequential paging, a mobile may not necessarily have to update its
location every time it moves into a new location area (e.g., this is
likely the case in movement-based location update strategies) and the
location updates do not necessarily have to be delivered reliably.
This indicates that the range of paging strategies to be supported
could impact the requirements and the design of the paging protocol.
In other words, the paging protocol design could significantly impact
Liebsch, Ohba, Zhang [Page 9]
INTERNET-DRAFT A framework for Dormant Mode Host Alerting September 2002
what paging strategies and location update strategies can be
supported.
The discussion on different paging strategies is out of the scope of
this document, but are discussed inter alia in [4] and [5].
6. Dormant mode location management
6.1 General description
This section addresses the location of the Tracking Agent (TA)
function, tracking a host's location while being dormant. In general,
having the TA function close to the paging areas a mobile terminal is
roaming in allows short signaling paths for dormant mode location
updating. Otherwise, coupling the TA function with a mobility agent
in a mobile terminal's home domain would allow the paging protocol to
benefit from mobility management specific functions. To find an
appropriate solution on where to implement the TA function, more
characteristics of individual approaches have to be studied. This
incorporates in particular security related issues as well as
signaling costs for dormant mode location updating and the paging
process. In general, the location of the TA shall consider the
balance of signaling load for registration and paging, L2 technology
characteristics as well as the mobile terminal's roaming behavior.
6.2 Proposal evaluation
6.2.1 Mobility proprietary solutions
This proposal assumes that each individual IP mobility management
proposal provides proprietary extensions for paging support. This
allows taking advantage of each mobility protocol's specific
functions for paging. Otherwise, this will result in a set of
specific paging protocol extensions and does not meet the requirement
on mobility protocol independence [2], aiming at an IP paging
architecture and protocol solution, which can be deployed with
various IP mobility managed systems. Evaluation of mobility
proprietary paging proposals is out of the scope of this document.
6.2.2 Mobility independent solutions
This proposal assumes the TA function as well as the DMA function to
be entirely de-coupled from the mobility management protocol and to
be part of the generic IP paging framework. Furthermore, both
functions are located in the dormant mobile terminal's visited
domain.
o Disadvantage: Location info database as well as stateful
Liebsch, Ohba, Zhang [Page 10]
INTERNET-DRAFT A framework for Dormant Mode Host Alerting September 2002
entities are to be maintained at home as well as in the visited
domain. Required interactions between the two sites are to be
studied thoroughly.
o Extra paging trigger packet buffer required in the visited
domain for each registered (dormant) mobile terminal.
o Advantage: Keeps dormant mode, paging area location management
and paging inside the visited domain (transparency).
o Extra requirements on the introduction of redundancy and on
fail-over handling mechanisms (handling of stateful entities).
o Implies requirements on the dynamic establishment of security
associations between a mobile terminal and the TA/DMA function.
o Allows flexible deployment of the DMA function w.r.t. its
location and mode (capturing or reception of paging trigger
packets).
6.2.3 Hybrid solutions
This proposal assumes partitioning the protocol into a core protocol
part, which is independent of the mobility protocol, and separate
mobility protocol dependent parts. Dormant mode location management
is done in a mobile terminal's home domain. Placing only the DMA
function in the visited domain, but keeping the TA in the home
domain, would not be a reasonable approach, since paging trigger
packets, either captured or received in the visited domain, would
initiate requesting the TA, located again in the terminal's home
domain, of the addressed dormant mobile terminal's location. The only
reasonable scenario, when placing the TA function into the mobile
terminal's home domain, would be to place the DMA function close to
the TA function, or even to co-locate the two functions.
o Requires coordination with the mobility management approach, but
would reduce the deployment of appropriate fail-over handling
mechanisms to one node, when co-locating the TA/DMA function
with a home mobility agent (assumes existence of a mobility
agent).
o Disadvantage: Requires inter-domain signaling for paging area
updates while a mobile terminal is dormant.
o Disadvantage: L2 support for location tracking is difficult
with regard to the security associations between a mobile
terminal, its visited domain and the home domain.
o Advantage: Implicit security association available between a
mobile terminal and functions located in its home domain.
Liebsch, Ohba, Zhang [Page 11]
INTERNET-DRAFT A framework for Dormant Mode Host Alerting September 2002
6.2.4 Last-hop solutions
This proposal has been addressed to provide paging functionality with
a minimum degree of complexity. It assumes all paging related
functional entities to be placed on Access Routers. This keeps
complexity of functions required for paging low, but restricts the
flexibility in paging area design and deployment of enhanced paging
functions.
The basic approach would rely on forwarding of paging trigger packets
to the last registered IP subnet by means of standard mechanisms
provided by the mobility management scheme. As an example, in case of
Mobile IPv6 the Home Agent intercepts packets according to standard
behavior and forwards these packets to the last registered care-of
address of the dormant mobile terminal. The registered subnet's
Access Router compares the destination address of the incoming packet
with its routing cache entries. If the mobile terminal is active,
the packets could be forwarded by means of standard mechanisms. If
the mobile terminal has entered a dormant mode before, the Access
Router initiates polling the IP subnet to re-activate the mobile
terminal. As an option, a set of L2 Access points, covered by the IP
subnet, might support multiple L2 paging areas. The latter function
would then require again an appropriate protocol between a mobile
terminal and its current AR to handle the different paging areas
within the current IP subnet.
An argument to advocate such an approach is the reduced complexity of
additional functions for paging and the fact that actually no special
paging protocol is required. Only the Access Router should discover
the respective mobile terminal's state and to initiate a paging
function on the IP subnet, which might comprise multiple L2 access
points.
This procedure implies the following restrictions:
o A paging area is restricted to the scope of an individual
Access Router's IP subnet and cannot comprise multiple subnets.
o Does not provide flexibility to access providers with respect
to paging area design.
o No benefit in saving signaling costs when compared to standard
IP mobility management approaches.
6.3 3GPP considerations
Lack of interest in a solution for IP paging for 3GPP Release 99 is
obvious, since paging is done via proprietary architecture and
protocol solutions. Core components deploy the Radio Access Network
Application Part (RANAP) protocol to initiate paging at Radio Network
Controllers (RNC). On the other hand, the standardization considers
Liebsch, Ohba, Zhang [Page 12]
INTERNET-DRAFT A framework for Dormant Mode Host Alerting September 2002
more and more the integration of Internet Protocol solutions for
various functions. Proposals on integrating an IP based framework
for Authentication, Authorization and Accounting (AAA) as well as IP
based mobility management has been considered. IP migrates more and
more towards the architecture's radio access network.
Ideas on "all-IP" systems consider the integration of a set of IP
based infrastructure servers for security and mobility management.
Hence, in case of introducing Mobile IP approaches for mobility
management and to replace the GPRS tunneling protocol (GTP) with
Mobile IP tunnels, stepwise replacement of RANAP procedures with IP
based approaches is possible. In addition to functions for radio
access bearer management and relocation handling, IP paging is a
function to be integrated and handled efficiently.
With respect to current discussion on IP RAN migration scenarios,
stepwise replacement of RANAP procedures for paging could be
considered, terminating the protocol more and more towards the core
network and deployment of IP based approaches towards the RAN seems
to be a reasonable procedure for smooth migration.
Consideration of RNC decomposition into a control node (control-
plane) and a user data packet handling node (user-plane) puts
additional demands on a generic IP paging architecture and protocol
with respect to placement of individual functional entities and
mapping of the generic IP paging protocol to access technology
specific paging functions of future heterogeneous access networks.
7. DMA function
7.1 DMA location and modes
This section focuses on the flexible and efficient deployment of the
Dormant Monitoring Agent (DMA) function. Basically, the DMA function
should be able to work in co-located mode as well as in distributed
mode, which means being located remotely from other paging related
functions. This allows optimization on paging delay as well as on
related signaling costs and performance, dependent on the
registration mechanisms of appropriate mobility management
approaches.
Two approaches are addressed in the following two sections, one is
based on explicit addressing a dormant mobile terminal's DMA
function, the other is based on a mode, where the DMA function has to
capture data packets getting by. Reception of paging trigger packets
assumes the DMA function to be co-located with at least the TA
function in a separate node.
7.1.1 Paging trigger packet reception
To allow explicitly addressing a mobile terminal's DMA function while
Liebsch, Ohba, Zhang [Page 13]
INTERNET-DRAFT A framework for Dormant Mode Host Alerting September 2002
being dormant, the DMA is to be registered with the mobility
management system to receive initial user-data packets on behalf of
the dormant mobile terminal. To deploy appropriate registration
features is according to requirement 4.8 of [2]. Initial user-data
packets are received at the DMA function and are to be buffered after
the function has ascertained that the packet addressed a registered
dormant mobile terminal and has not been forwarded to the DMA
misleadingly.
After the dormant mobile terminal has entered the active state and
its current location has been ascertained after the paging process,
the DMA function has to re-address and send the buffered packet(s) to
the mobile terminal. The DMA is to be de-registered with the mobility
management system by means of appropriate location updating
mechanisms.
In this mode, the acquired and registered DMA function represents a
long-term entity to be responsible for receiving paging trigger
packets. The DMA should not change when a new paging area has been
entered.
o Advantage: Avoid performance degradation at individual DMA
functions, since usually only packets destined to registered
dormant mobile terminals are received by this functional entity.
This avoids running the DMA function in promiscuous mode.
o Advantage: Could benefit from long-term DMA registration with
the platform's mobility management system while being dormant.
o Allows to co-locate the DMA function with the TA function.
o In case if IP-IP encapsulated packets are received at the DMA
function, the actual terminal identifier might be found in the
inner IP packet, which requires additional processing of
received packets.
o This approach requires that nodes, implementing the DMA function,
terminate tunnels for DMHA only.
7.1.2 Paging trigger packet capturing
When no appropriate registration mechanisms are provided by the
mobility management to register an individual DMA function, multiple
DMA functions are necessary to be distributed and placed on relevant
ingress routers or appropriate nodes, where user-data traffic packets
go through on the way to a mobile terminal's location, which has been
registered with the mobility management system before the terminal
has entered the dormant mode. The DMA functions have to inspect all
packets and to capture and process the ones addressed to mobile
terminal's, which have been registered as dormant.
o Advantage: Allows to forego an explicit registration of a DMA
Liebsch, Ohba, Zhang [Page 14]
INTERNET-DRAFT A framework for Dormant Mode Host Alerting September 2002
function with the mobility management system. This saves
signaling when an individual mobile terminal decides to enter
the dormant mode.
o Requires an additional protocol and security association between
the nodes implementing DMA functions and the nodes implementing
other paging related functions.
7.2 Filtering for DMHA
The DMA function should allow filtering of paging trigger packets to
avoid that all packets, addressing a dormant mobile terminal, trigger
a paging process by default. The mobile terminal should be able to
select from a list of packet types, indicating, which packets are
allowed to trigger the paging process. This optimizes the dormant
mode support and further allows to reduce paging specific signaling
costs.
Otherwise, complex and too extensive filter configuration should be
avoided. Therefore, the protocol should allow the mobile terminal to
configure the filter function according to a reasonable selection of
packet types.
Packet filtering at DMAs supports the dormant mode for mobile
terminals as well as for stationary hosts.
8. PA function
The Paging Agent functional entity is responsible for the actual
paging process. Being informed of the paging area to search for the
paged mobile terminal, the PA polls the paging area by means of an
appropriate paging strategy.
Thorough investigation of the PA function results in a further
functional split into a generic part and into multiple attendant
parts, responsible for mapping the generic protocol to access
technology specific functions.
This chapter describes the PA functions and evaluation of addressing
schemes for the individual PA functions and related interfaces. The
latter evaluation distinguishes between addressing of core
components, which includes the interface between the generic PA
function and the PA attendants, and addressing of last-hop
components, which is related to addressing the mobile terminal from
PA attendants either on L3 or on L2. The role of multicast schemes is
described and advantages and disadvantages for individual interfaces
are evaluated.
8.1 Functional split of the PA function
o The generic PA function
This part of the PA function could be placed somewhere in the
Liebsch, Ohba, Zhang [Page 15]
INTERNET-DRAFT A framework for Dormant Mode Host Alerting September 2002
network, possibly being co-located with the TA function. Its protocol
to poll the attendant functions is specified on IP layer and
independent of the domain's individual IP subnet supporting access
technologies.
o The paging attendant functions
The attendants are addressed from the generic PA function during a
paging process. They should be located on a domain's last-hop
subnets, e.g. on Access Routers. Polling a paging area, the generic
PA function addresses all paging attendants comprising the paging
area according to the selected paging strategy. The paging attendants
are then responsible for mapping the generic IP paging protocol to L2
paging functions. Furthermore, these attendants support paging area
update related signaling by means of mapping appropriate L2 signaling
to IP paging area update signaling, which is to be sent to the
responsible TA function.
In general, access technology specific dormant mode and paging
support should be assumed to be present and is recommended to be
used. This section of the DMHA framework document describes the
functions to allow for this mapping, but appropriate design of paging
attendant functions for individual access technologies is out of the
scope of this document.
Some further hints on technology specific support can be found in
Appendix C.
In case of not getting support from access technologies' L2, there
are proposals for enhanced IP paging approaches on the access link.
These approaches are based on multicast addressing or solicited node
multicast addressing, as well as on slotted modes to allow a dormant
mobile terminal to shut down its interface activities periodically.
L3 slotted mode approach is not evaluated in this document for the
following reasons. First, L3 slotted mode might improve power saving
performance of dormant hosts, but will not reduce IP signaling
traffic in the last hop subnet. Technology specific paging on the
access link should be utilized as much as possible when aiming at
both saving power and IP signaling traffic. Second, L3 slotted mode
needs more investigation on possible and required accuracy levels of
synchronization, requirements on IP subnet design (including
security) to realize the accuracy levels of synchronization and
implementation costs. Of course, the discussed and proposed framework
allows for the deployment of L3 slotted mode, but its benefit is
expected to be less compared to the cost of design and implementation
work for such an approach.
8.2 Addressing of core components
Liebsch, Ohba, Zhang [Page 16]
INTERNET-DRAFT A framework for Dormant Mode Host Alerting September 2002
Tbd.
8.3 Addressing of last-hop components
Tbd.
9. Signaling transport
Since battery consumption of hosts is a common issue for both IPv4
and IPv6 nodes, it is necessary that DMHA protocol supports both
IPv4 and IPv6. There are two approaches for defining DMHA transport.
First approach is to define a single protocol that is commonly used
for both IPv4 and IPv6. This is equivalent to defining a single
DMHA protocol above IP layer (e.g, UDP), where minimum IP version
specific information such as packet filtering information might be
allowed to be carried in the message.
Second approach is to define separate protocols for IPv4 and IPv6.
There are following IPv4 specific candidates for DHMA protocol
transport.
o Defining new ICMPv4 types
o Defining new Mobile IPv4 [6] extensions
information.
There are following IPv6 specific candidates for DHMA protocol
transport.
o Defining new ICMPv6 types
o Defining new Mobile IPv6 messages and/or mobility options in
Mobility Header [7]
o Defining new IPv6 Destination Options. The defined IPv6 Destination
Option could be piggybacked in any packets including data packets.
There is another approach in which the first two approaches are
combined, i.e., using a common transport for both IPv4 and IPv6 for
DMHA message exchange among DMHA agents, while applying a separate
transport for IPv4 and IPv6 for DMHA message exchange between host
and DMHA agent.
Basically, higher layer transport is suitable for commonality while
lower layer transport is suitable for optimization in terms of
coupling with other protocol such as Mobile IP. However, the actual
protocol design must also consider security characteristics when
choosing DMHA signaling transport. DMHA security discussion is
Liebsch, Ohba, Zhang [Page 17]
INTERNET-DRAFT A framework for Dormant Mode Host Alerting September 2002
described in section "Security support".
10. Security support
10.1 Security threat categories
DMHA security threats are described in [2,8]. There are basically
two types of attacks related to DMHA. Note that some of the
described attacks can be combined to organize two-party attacks [8].
o Category 1 attacks: Attacks that can be avoided or mitigated by
authenticating and/or encrypting signaling packets used for DMHA.
Category 1 attacks include:
- bogus paging registration messages (detailed explanation
is TBD)
- bogus paging area update messages (detailed explanation
is TBD)
- bogus paging request messages (detailed explanation is TBD)
- bogus paging area advertisement messages (detailed explanation
is TBD)
Note that it is impossible for dormant hosts to avoid receiving
and partially processing bogus paging request and bogus paging
area advertisement messages, however, it is possible to mitigate
the attacks by discarding received messages immediately when
integrity check fails. Considering buttery power consumption of
dormant hosts, the integrity check applied for those messages
should be light weight as much as possible.
o Category 2 attacks: Attacks that cannot be solved by authenticating
or encrypting signaling packets used for DMHA. Category 2 attacks
include:
- paging trigger packets sent from malicious correspondent nodes,
which would result in DoS amplification by (i) producing paging
request messages to be widecast in candidate paging area(s) in
which the target dormant host is expected to be located, (ii)
forming a large sized queue at DMA until the target dormant host
is awaken and (iii) awake the target dormant host to drain its
battery. (Avoiding this attack is not possible since DMA cannot
make a distinction between malicious and legitimate correspondent
nodes.)
Liebsch, Ohba, Zhang [Page 18]
INTERNET-DRAFT A framework for Dormant Mode Host Alerting September 2002
- malicious dormant hosts that do not respond to paging request
messages. This includes the case in which a host performs paging
registration or paging area update with incorrect paging area
information. (Avoiding this attack is not possible since PA
cannot make a distinction between malicious and legitimate
dormant hosts.)
- malicious nodes that make active mode hosts consume batteries
and prevent from entering dormant mode, by continuously sending
data packets. (Avoiding this attack is not possible since active
mode hosts cannot make a distinction between malicious and
legitimate senders.)
10.2 Consideration for Category 1 attacks
10.2.1 Candidate security mechanisms for DMHA
One way to secure IP paging signaling packets is to use IPsec [9]. An
IPsec security association (SA) is identified based on the peers' IP
addresses, security protocol (AH or ESP) and Security Parameter Index
(SPI) [9]. Therefore, if a peer changes its IP address, a new IPsec
SA needs to be established. With virtually any IP paging protocol,
after establishing an IPsec SA with a network agent, a dormant mobile
may change the IP address it uses to communicate with the agent. For
example, a mobile may move into a different IP subnet where it may:
Need to receive acknowledgements to its L3 Location Updates, if a
paging algorithm requires to know a mobile's precise current
location area, OR
Need a new IP address to send IP packets to outside the local IP
subnet (e.g., to perform location update) if the local access IP
router implements packet filtering that will discard outgoing
packets if the source IP address is not part of the address space
in the local subnet.
Establishing a new IPsec SA requires Diffie-Hellman key exchange [10]
in which intensive exponential computation is performed. This can
lead to heavy battery consumption. Furthermore, establishing an IPsec
SA requires at least three message round-trips that will increase
signaling delay. Therefore, IPsec does not seem appropriate for
securing IP paging protocols.
Otherwise, if the IPsec security association could be based on a
static identifier, e.g. a common paging identifier to be unique
Liebsch, Ohba, Zhang [Page 19]
INTERNET-DRAFT A framework for Dormant Mode Host Alerting September 2002
across the borders of the registered paging area as long as the
mobile terminal is dormant, establishment of a new SA could be
avoided in case of the mobile changes it's IP address. This is
basically an issue of implementation and would allow IPsec mechanisms
to be deployed for authentication and encryption without accessing
any key distribution center or other mechanisms for the establishment
of a new SA while a mobile is dormant.
When Mobile IP (v4 or v6) is used for mobility management,
establishment of a new IPsec SA may be avoided if a paging protocol
entity sends signaling packets destined to a mobile to the mobile's
Mobile IP Home Address, which does not change as the mobile moves
about. However, in order for the mobile to receive these packets in
a visited IP subnet, the mobile would have to first obtain a new
local Care-of Address, transition into full active mode and perform
mobility binding with its Home Agent each time it moves into a new L3
Location Area. This could result in a signaling cost that is
comparable to placing the TA on the Home Agent.
For other cases, it would be better to consider using a security
mechanism that builds security associations based on stable
identifiers that do not change while the mobile moves about, but
allows mobiles to use dynamically changing local IP addresses to
receive packets without having to perform mobility binding.
One choice of stable identifier is Cryptographically Generated
Address (CGA) [11]. A CGA contains a part of an IP address (i.e.,
lower 64-bit of an IPv6 address) that is cryptographically generated
based on public key cryptography. This part of the IP address will be
assigned the same value by the sending entity regardless wherever the
sending entity connects to the network. Using CGA, a signaling packet
carries a Message Integrity Check (MIC) field calculated for the data
to send as well as the sender's public key (the public key is
necessary only in the first message exchange). The cryptographically
generated address will be specified as the source IP address of the
signaling packet so that the receiver can authenticate the sender's
IP address as well as the data by using the attached public key.
However, since CGA depends on a particular address structure and
address assignment scheme, it cannot be applied if the address
structure or address assignment scheme is different. For example,
CGA is difficult to apply if the entire part of an IP address is
assigned by the network.
Another choice is to use higher layer security mechanisms in which
stable identifier is defined. Use of TLS [12], or defining
authentication field within DMHA signaling message payload [13]
matches this approach.
10.2.2 Establishing an SA
Liebsch, Ohba, Zhang [Page 20]
INTERNET-DRAFT A framework for Dormant Mode Host Alerting September 2002
SAs that are used for avoiding or mitigating Category 1 attacks can
be established either statically or dynamically. Static SAs could be
applicable for small sized networks only, where scalability is not
necessarily required for key management. Dynamic SAs would be
necessary for other cases. There are following ways to dynamically
establish a SA between host and DMHA agent, or between two DMHA
agents.
o Establishing an SA based on strong authentication (i.e., by using
some other pre-shared SA or using PKI)
- IKE[10] (mostly used for establishing IPsec SAs)
- AAA[14,15] with appropriate key distribution mechanisms (tied
with client authentication)
- Kerberos[16] (tied with client authentication)
o Establishing an SA based on weak authentication
- CGA[11]
o Purpose Built Key approach
The idea of this mechanism is to allow the establishment of a SA for
a specific function (like dormant mode and paging). When this
function is not required anymore (after a mobile has been paged and
re-activated), the security association is deleted. In case of
paging, a key could be generated before a mobile enters the dormant
mode and be kept on the mobile terminal as well as on paging relevant
nodes within the network as a shared secret. The association to an
individual mobile terminal should be identified uniquely by means of
a static identifier, which could be a proprietary paging related
identifier or a mobility management related static identifier (e.g.
the home address in Mobile IP). Static means, that it should not
change while the respective mobile terminal is dormant. Further, it
should be avoided, that validity of this identifier is based on a
lifetime, which is to be refreshed while being dormant. The validity
should expire after a successful paging process and after the mobile
terminal has been fully re-activated.
As an option, the generation and exchange of the PBK could be coupled
with the IP paging protocol procedures.
10.3 Consideration for Category 2 attacks
For paging trigger packets sent from malicious correspondent nodes,
the only way to solve this problem is packet filtering. Ingress
Liebsch, Ohba, Zhang [Page 21]
INTERNET-DRAFT A framework for Dormant Mode Host Alerting September 2002
filtering or packet filtering at access routers through which
correspondent nodes are connected to the Internet is effective for
blind masquerade attacks by which an attacker randomly changes the
source IP address fields of packets used for the attack. For attacks
from a malicious correspondent node that has a correct IP address
assigned at the connected subnet, packet filtering at DMA as
described in "Filtering for DMHA" would be effective for attackers
who are not aware of what types of packets trigger paging.
For attacks from malicious dormant hosts that do not respond to
paging request messages, adaptive paging timeout mechanism could be
effective in which the paging timeout value becomes small as the
number of paging failure increases. In addition, validity check for
paging area information contained in paging registration and paging
area update messages against the host's actual location would be
necessary.
For attacks from malicious nodes that make active mode hosts consume
batteries by continuously sending data packets, the target host can
enter a low power mode when it receives a large amount of unimportant
packets, as is described in [8].
11. Availability
Availability is an issue to be addressed and to be taken into account
already before the actual design of the architecture and protocol for
IP paging is done. To allow for efficient introduction of redundancy
and deployment of mechanisms for fail-over handling, this should be
taken into consideration when taking decisions on distributing or co-
locating stateful entities.
11.1 Related nodes
With regard to IP paging, this issue is mainly related to the
Tracking Agent functional entity as well as to the DMA functional
entity.
o DMA co-located with TA
When having the DMA co-located with the TA, the same database could
be accessed to check for individual registered mobile terminals'
entries. This requires the registration of the node implementing the
DMA to allow reception of paging trigger packets at the DMA, as
discussed in section 7.1.1. Otherwise, such a configuration allows
efficient management of redundancy, since less stateful entities are
to be mirrored. Furthermore, appropriate protocols for fail-over
handling could manage redundant nodes easier.
o Separated and distributed DMA(s) from TA
Liebsch, Ohba, Zhang [Page 22]
INTERNET-DRAFT A framework for Dormant Mode Host Alerting September 2002
Such a configuration requires distribution of DMAs within the network
or on a domain's last-hop subnets, as discussed in 7.1.2. A protocol
is to be deployed between distributed DMAs and an individual TA
function to coordinate registries. Both functions, TA as well as
distributed DMAs, have to keep and manage states for individual
registered dormant mobile terminals. Dependent on the network
topology, multiple DMAs keep the same registry for an individual
mobile terminal.
11.2 Evaluated mechanisms
To be done.
11.3 Proposed solution
To be done.
A REFERENCES
[1] J. Kempf, "Dormant Mode Host Alerting Problem Statement",
RFC 3132, June 2001
[2] J. Kempf et al., "Requirements and Functional Architecture for
an IP Host Alerting Protocol", RFC 3154, August 2001.
[3] J. Kempf et al., "Dormant Mode Host Alerting (DMHA) Protocol
Assessment",
draft-ietf-seamoby-paging-protocol-assessment-01.txt,
work in progress, February 2002
[4] 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
[5] W.-S. Wong / V.M. Leung, Location Management for Next-
Generation Personal Communication Networks, IEEE Network,
Sept. 2000
[6] C. Perkins, "IP Mobility Support for IPv4", RFC 3344,
August 2002.
[7] D. Johnson, et al, "Mobility Support in IPv6",
draft-ietf-mobileip-ipv6-17.txt, work in progress.
[8] P. Mutaf and C. Castelluccia, "IP Paging Threat Analysis",
draft-mutaf-paging-threats-00.txt, work in progress,
February 2002.
[9] S. Kent and R. Atkinson, "Security Architecture for the Internet
Protocol", RFC 2401, November 1998.
Liebsch, Ohba, Zhang [Page 23]
INTERNET-DRAFT A framework for Dormant Mode Host Alerting September 2002
[10] D. Harkins and D. Carrel et. al., "The Internet Key Exchange
(IKE)", RFC 2409, November 1998.
[11] G. Montenegro and C. Castelluccia, "SUCV Identifiers and
Addresses", Internet-Draft, draft-montenegro-sucv-02.txt,
work in progress, November 2001.
[12] T. Dierks, et al., "The TLS Protocol Version 1.0", RFC 2246,
January 1999.
[13] T. Zhang, et al., "A Flexible and Scalable IP Paging Protocol",
to appear in IEEE Globecom 2002.
[14] C. Rigney, et al., "Remote Authentication Dial In User Service
(RADIUS)", RFC 2865, June 2000.
[15] P. Calhoun, et al., "Diameter Base Protocol", Internet-Draft,
work in progress, June 2002.
[16] J. Kohl, et al., "The Kerberos Network Authentication Service
(V5)", RFC 1510, Semptember 1993.
[17] "Wireless LAN Medium Access Control (MAC) and Physical
Layer (PHY) specifications", IEEE Std 802.11,
June 1997.
Liebsch, Ohba, Zhang [Page 24]
INTERNET-DRAFT A framework for Dormant Mode Host Alerting September 2002
B AUTHOR'S ADDRESS
Marco Liebsch
NEC Network Laboratories Europe
Adenauerplatz 6, 69115 Heidelberg
Germany
Phone: +49 (0)6221 13708-11
Fax: +49 (0)6221 13708-28
E-mail: marco.liebsch@ccrle.nec.de
Yoshihiro Ohba
Toshiba America Research, Inc.
P.O. Box 136
Convent Station, NJ 07961-0136
USA
Phone: +1 973 829 5174
Fax: +1 973 829 5601
E-mail: yohba@tari.toshiba.com
Tao Zhang
Telcordia Technologies
445 South Street, Room 1J-214B
Morristown, New Jersey 07960
USA
Phone: +1 973 829 4539
E-mail: tao@research.telcordia.com
Liebsch, Ohba, Zhang [Page 25]
INTERNET-DRAFT A framework for Dormant Mode Host Alerting September 2002
Appendix C Overview on access technologies
Appendix C.1 802.11 Power Management
The power management capability of IEEE 802.11 [17] for an
infrastructure network can be summarized as follows. A station
changing Power Management mode informs the Access Point (AP) of this
fact using the Power Management bits in the Frame Control field of
the transmitted MAC frames. An AP periodically broadcasts beacon
signals to provide time synchronization information and inform
stations in Power Save mode of arriving frames. A station uses the
time synchronization information received from the AP to determine
when it should wake up periodically from Power Save mode. The AP
buffers the MAC frames destined to the station in Power Save mode and
transmit them at designated times.
Unicast frames destined to a host in Power Save mode are transmitted
by the AP and received by the station in different ways from
broadcast/multicast frames. With every beacon transmission, the AP
informs each station in Power Save mode of the unicast frames
buffered by the AP for the station and whether these frames are to be
sent to the station during a content-free or a contention time
period. If a unicast frame is to be sent in a contention period, the
station will poll the AP to receive the unicast frame. If a frame is
to be sent during a contention-free period, the station will not poll
the AP but will instead remain active until the frame is received or
the contention-free period ends.
The AP notifies the stations of the existence of broadcast/multicast
frames only via selected beacons periodically and the
broadcast/multicast frames are sent immediately after these beacons.
By utilizing the timing differences for multicast/broadcast frames
and unicast frames, three different dormant modes can be realized in
the single Power Save mode.
o All Mode: Both unicast and multicast/broadcast frames are received.
o Unicast Only Mode: Only unicast frames are received.
o Multicast Only Mode: Only multicast/broadcast frames are received.
The dormancy levels of Unicast Only Mode and Multicast Only Mode are
higher than that of All Mode. Unicast Only Mode is effective in terms
of battery saving especially for a host connecting to the network
where broadcast/multicast traffic is high and most of the
broadcast/multicast traffic is not important to the dormant station.
On the other hand, there are also important broadcast/multicast
frames that need to be received by the dormant Host in order to to
receive incoming SIP calls. One example is ARP REQUEST packets which
are broadcast by a node in the last hop subnet in order to obtain the
Liebsch, Ohba, Zhang [Page 26]
INTERNET-DRAFT A framework for Dormant Mode Host Alerting September 2002
MAC address for an IP address of the host. Thus, a mechanism would be
necessary for converting a particular broadcast/multicast MAC frames
to a unicast MAC frame when the dormant host is operating in Unicast
Only Mode.
Liebsch, Ohba, Zhang [Page 27]