draft-ietf-seamoby-paging-requirements-00.txt   draft-ietf-seamoby-paging-requirements-01.txt 
Internet Draft James A new Request for Comments is now available in online RFC libraries.
Kempf
for the
Paging
Design
Team
Category: Informational
Document: draft-ietf-seamoby-paging-requirements-00.txt
Date: April 2001
Requirements for an IP Mobile Node Alerting Protocol
Status of this Memo RFC 3154
This document is a working group contribution for consideration by Title: Requirements and Functional Architecture for an IP
the Seamoby Working Group of the Internet Engineering Task Force. Host Alerting Protocol
Distribution of this memo is unlimited. Author(s): J. Kempf, C. Castelluccia, P. Mutaf, N. Nakajima,
This document is an Internet-Draft and is in full conformance Y. Ohba, R. Ramjee, Y. Saifullah, B. Sarikaya,
with all provisions of Section 10 of RFC2026. X. Xu
Status: Informational
Date: August 2001
Mailbox: James.Kempf@Sun.COM, pars.mutaf@inria.fr,
claude.castelluccia@inria.fr,
nnakajima@tari.toshiba.com,
yohba@tari.toshiba.com, ramjee@bell-labs.com,
Yousuf.Saifullah@nokia.com,
Behcet.Sarikaya@usa.alcatel.com,
xiaofeng.xu@usa.alcatel.com
Pages: 16
Characters: 31534
Updates/Obsoletes/SeeAlso: None
Internet-Drafts are working documents of the Internet Engineering I-D Tag: draft-ietf-seamoby-paging-requirements-01.txt
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/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Abstract URL: ftp://ftp.rfc-editor.org/in-notes/rfc3154.txt
This document develops an architecture and a set of requirements This document develops an architecture and a set of requirements
needed to support alerting of mobile nodes that are in the dormant needed to support alerting of hosts that are in dormant mode. The
mode. The architecture and requirements are designed to guide architecture and requirements are designed to guide development of
development of an IP protocol for alerting dormant IP mobile hosts, an IP protocol for alerting dormant IP mobile hosts, commonly called
commonly called paging. paging.
Table of Contents
Status of this Memo................................................1
Abstract...........................................................1
1. Introduction ...................................................2
2. Terminology ....................................................2
3. Requirements ...................................................2
3.1. Impact on Power Consumption ...............................2
3.2. No Routers ................................................2
3.3. Multiple Dormant Modes ....................................3
3.4. Independence of Mobility Protocol .........................3
3.5. Support for Existing Mobility Protocols ...................3
3.6. Dormant Mode Termination ..................................3
3.7. Network Updates ...........................................3
3.8. Efficient Utilization of L2 ...............................3
3.9. Future L3 Paging Support ..................................3
3.10. Robustness ................................................3
3.11. Flexibility of Administration .............................4
3.12. Security ..................................................4
4. Functional Architecture ........................................4
4.1. Functional Entities .......................................4
4.2. Interfaces ................................................5
5. Security Considerations ........................................6
6. References .....................................................7
7. Author's Addresses .............................................7
8. Full Copyright Statement .......................................7
1. Introduction
In [1], a problem statement was developed to explain why an IP
protocol was desirable for alerting mobile nodes in dormant mode,
commonly called paging. In this draft, a set of requirements is
developed for guiding the development of an IP paging protocol.
Based on the requirements, an architecture is developed to represent
the functional relationships between logical functional entities
involved.
2. Terminology
Please see [1] for definition of terms used in describing paging.
3. Requirements
The following requirements are identified for the IP paging
protocol.
3.1. Impact on Power Consumption
The IP paging protocol MUST minimize impact on the mobile node's
dormant mode operation, in order to minimize excessive power drain.
3.2. No Routers
Since the basic issues involved in handling mobile routers are not
well understood and since mobile routers have not exhibited a
requirement for paging, the IP paging protocol MAY NOT support
routers. However, the IP paging protocol MAY support a router acting
as a host.
3.3. Multiple Dormant Modes
Recognizing that there are multiple possible dormant modes on the
mobile node, the IP paging protocol MUST make no assumptions about
the implementation of dormant mode on the mobile.
3.4. Independence of Mobility Protocol
Recognizing that IETF may support multiple mobility protocols in the
future, the IP paging protocol MUST be designed modularly so there
is no dependence on the underlying mobility protocol. The protocol
SHOULD specify and provide support for a mobility protocol to hook
into paging.
3.5. Support for Existing Mobility Protocols
The IP mobility protocol MUST specify the binding to the existing IP
mobility protocols, namely mobile IPv4 [2] and mobile IPv6 [3].
3.6. Dormant Mode Termination
Upon receipt of a page (either with or without an accompanying L3
packet), the mobile node MUST execute the steps in its mobility
protocol to re-establish a routable L3 link with the Internet.
3.7. Network Updates
Recognizing that locating a dormant mode mobile requires the network
to have a rough idea of where the mobile node is located, the IP
paging protocol SHOULD provide the network a way to inform a dormant
mode mobile node what paging area it is in and the IP paging
protocol SHOULD provide a means whereby the mobile node can inform
the network when it changes paging area. The IP paging protocol MAY
additionally provide a way for the mobile node to inform the network
what paging area it is in at some indeterminate point prior to
entering dormant mode.
3.8. Efficient Utilization of L2
Recognizing that many existing wireless link protocols support
paging at L2 and that these protocols are often intimately tied into
the mobile node's dormant mode support, the IP paging protocol
SHOULD provide hooks to utilize an L2 paging protocol if available.
3.9. Future L3 Paging Support
Recognizing that future dormant mode and wireless link protocols may
be designed that more efficiently utilize IP, the IP paging protocol
SHOULD NOT require L2 support for paging.
3.10. Robustness
The IP mobility protocol MUST be designed to be robust with respect
to failure of network elements involved in the protocol. The self-
healing characteristics SHOULD NOT be any worse than existing
routing protocols.
3.11. Flexibility of Administration
The IP paging protocol SHOULD provide a way to flexibly auto-
configure paging areas to reduce the amount of administration
necessary in maintaining a wireless network with paging.
3.12. Security
A threat analysis MUST be conducted for the IP paging protocol, to
identify possible threats from hostile mobile nodes and network
elements. The protocol MUST be designed to counter those threats.
4. Functional Architecture
In this section, a functional architecture is developed that
describes the logical functional entities involved in IP paging.
Please note that the logical architecture makes absolutely no
commitment to any physical implementation of these functional
entities. A physical implementation may merge particular functional
entities, for example. The purpose of the functional architecture is
to identify the relevant system interfaces upon which protocol
development may be required.
4.1. Functional Entities
The functional architecture contains the following elements:
Mobile Node - The Mobile Node (MN) is a mobile host in the sense
of [4] connected to a wired IP backbone through a wireless link
over which IP datagrams are exchanged. The host supports some
type of IP mobility protocol (for example, mobile IP [2] [3]).
The Mobile Node is capable of entering dormant mode in order to
save power (see [1] for a detailed discussion of dormant mode).
The Mobile Node also supports a protocol allowing the network to
awaken it from dormant mode if a packet arrives. This protocol
may be a specialized L2 paging channel or it may be a time-
slotted dormant mode in which the mobile node periodically wakes
up and listens to L2 for IP traffic, the details of the L2
implementation are not important. A dormant Mobile Node is also
responsible for determining when its paging area has changed and
for responding to changes in paging area by informing the
Tracking Agent about its location. Since routers are presumed not
to require dormant mode support, a Mobile Node is never a router.
Paging Agent - The Paging Agent is responsible for alerting the
Mobile Node when a packet arrives and the Mobile Node is in
dormant mode. Alerting of the mobile node proceeds through a
protocol that is peculiar to the L2 link and to the Mobile Node's
dormant mode implementation, though it can involve IP if
supported by the L2. Additionally, the Paging Agent maintains
paging areas by periodically wide casting information over the
mobile node's link to identify the paging area. The paging area
information may be wide cast at L2 or it may also involve IP.
Tracking Agent - The Tracking Agent is responsible for tracking a
Mobile Node's location while it is in dormant mode. It receives
periodic updates from a dormant Mobile Node when the Mobile Node
changes paging area. When a packet arrives for the Mobile Node at
the Dormant Target Router, the Tracking Agent is responsible for
notifying the Paging Agent in the Mobile Node's last reported
paging area to awaken (page) the Mobile Node.
Dormant Target Router - The Dormant Target Router is the router
to which the Mobile Node's packets are targeted while the Mobile
Node is in Dormant Mode (and thus does not have an active L2
connection to the Internet). It is the responsibility of the
Dormant Target Router to inform the Tracking Agent when a packet
has arrived for the Mobile Node so the Tracking Agent can
initiate paging, and to deliver the packet to the Mobile Node
when informed by the Tracking Agent that the Mobile Node again
has a routable connection to the Internet. In addition, the
Mobile Node or its Tracking Agent may arrange for a particular
router to function as a Dormant Target Router when the Mobile
Node enters dormant mode.
4.2. Interfaces
This functional architecture generates the following list of
interfaces. Those interfaces that are declared to be open are
candidates for protocol development, closed interfaces are internal
and will not require any protocol work.
Mobile Node - Paging Agent (MN-PA) - The MN-PA interface supports
the following two types of traffic:
- Wide casing of paging area information from the Paging
Agent.
- The Paging Agent alerting the Mobile Node when informed by
the Tracking Agent that a packet has arrived.
Mobile Node - Tracking Agent (MN-TA) - The MN-TA interface
supports the following type of traffic:
- The Mobile Node informing the Tracking Agent when it has
changed paging area, and, prior to entering dormant mode, in
what paging area it is located.
Tracking Agent - Paging Agent (TA-PA) - The TA-PA interface
supports the following two types of traffic:
- Alerting from the Tracking Agent when the Tracking Agent has
determined that a packet has arrived for a dormant Mobile Node
whose last reported position was within the paging area
controlled by the Paging Agent.
- Negative response indication from the Paging Agent if the
Mobile Node does not respond to a page.
Dormant Target Router - Target Agent (DTR-TA) - The DTA-TA
interface supports the following types of traffic:
- A report from the Dormant Target Router to the Tracking
Agent that a packet has arrived for a dormant mobile node for
which it has no route.
- A report from the Tracking Agent to the Dormant Target
Router giving the route and indicating that the Mobile Node is
once again connected. This may also involve the Dormant Target
Router handing off the packet to the Target Agent for
delivery.
5. Security Considerations
IP paging is a new area for IETF and requires careful consideration
of security requirements.
6. References
[1] Kempf, J., "Sending IP Traffic to Dormant Mobile Devices:
Problem Statement," draft-ietf-seamoby-paging-problem-statement-
02.txt, a work in progress.
[2] Perkins, C., ed., "IP Mobility Support," RFC 2002, October,
1996.
[3] Johnson, D., and Perkins, C., "Mobility Support in Ipv6," draft- This document is a product of the Context Transfer, Handoff Candidate
ietf-mobileip-ipv6-13.txt, a work in progress. discovery and Dormant Mode Host Alerting Working Group of the of the
IETF.
[4] Braden, R., "Requirements for Internet Hosts - Communication This memo provides information for the Internet community. It does
Layers," STD003, October, 1989. not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
7. Author's Addresses This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to IETF-REQUEST@IETF.ORG. Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG.
James Kempf Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
Sun Microsystems Laboratories an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body
901 San Antonio Rd. help: ways_to_get_rfcs. For example:
UMTV29-235
Palo Alto, CA
95303-4900
Phone:+1 650.336.1684 To: rfc-info@RFC-EDITOR.ORG
Email:James.Kempf@Sun.COM Subject: getting rfcs
8. Full Copyright Statement help: ways_to_get_rfcs
Copyright (C) The Internet Society (2000). All Rights Reserved. Requests for special distribution should be addressed to either the
This document and translations of it may be copied and furnished to author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless
others, and derivative works that comment on or otherwise explain it specifically noted otherwise on the RFC itself, all RFCs are for
or assist in its implementation may be prepared, copied, published unlimited distribution.echo
and distributed, in whole or in part, without restriction of any Submissions for Requests for Comments should be sent to
kind, provided that the above copyright notice and this paragraph RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC
are included on all such copies and derivative works. However, this Authors, for further information.
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English. The limited permissions granted above are perpetual and
will not be revoked by the Internet Society or its successors or
assigns. This document and the information contained herein is
provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE
INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."
 End of changes. 

This html diff was produced by rfcdiff 1.25, available from http://www.levkowetz.com/ietf/tools/rfcdiff/