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