Internet Draft                                                 James
                                                                  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

   This document is a working group contribution for consideration by
   the Seamoby Working Group of the Internet Engineering Task Force.
   Distribution of this memo is unlimited.
   This document is an Internet-Draft and is in full conformance
   with all provisions of Section 10 of RFC2026.

   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/ietf/1id-abstracts.txt
   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

                                Abstract

   This document develops an architecture and a set of requirements
   needed to support alerting of mobile nodes that are in the dormant
   mode. The architecture and requirements are designed to guide
   development of an IP protocol for alerting dormant IP mobile hosts,
   commonly called 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
                              Paging Requirements                April 2001

    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.



                              Paging Requirements                April 2001

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-
                              Paging Requirements                April 2001

   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

                              Paging Requirements                April 2001

      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.

                              Paging Requirements                April 2001


         - 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.

































                              Paging Requirements                April 2001

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-
      ietf-mobileip-ipv6-13.txt, a work in progress.

   [4] Braden, R., "Requirements for Internet Hosts - Communication
      Layers," STD003, October, 1989.

7.   Author's Addresses

   James Kempf
   Sun Microsystems Laboratories
   901 San Antonio Rd.
   UMTV29-235
   Palo Alto, CA
   95303-4900

   Phone:+1 650.336.1684
   Email:James.Kempf@Sun.COM


8.   Full Copyright Statement

   Copyright (C) The Internet Society (2000).  All Rights Reserved.
   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph
   are included on all such copies and derivative works. However, this
   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."