idnits 2.17.1 draft-sarikaya-seamoby-paging-requirements-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories -- however, there's a paragraph with a matching beginning. Boilerplate error? == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 5) being 60 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. (A line matching the expected section header was found, but with an unexpected indentation: ' 1.0 Introduction' ) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 19 instances of too long lines in the document, the longest one being 4 characters in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 121: '...and-alone protocol, it MUST be defined...' RFC 2119 keyword, line 128: '... paging protocol SHOULD also extend an...' RFC 2119 keyword, line 131: '... paging protocol MUST use L2 paging if...' RFC 2119 keyword, line 133: '... dormant mode MN MUST receive and resp...' RFC 2119 keyword, line 135: '...ceive/ respond to L3 pages MUST enable...' (4 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 152 has weird spacing: '... issued defin...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 2001) is 8461 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 2002 (ref. '1') (Obsoleted by RFC 3220) == Outdated reference: A later version (-24) exists of draft-ietf-mobileip-ipv6-13 -- No information found for draft-ietf-mobileip-hmipv6 - is the name correct? -- No information found for draft-ietf-mobileip-regtun - is the name correct? Summary: 9 errors (**), 0 flaws (~~), 4 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET DRAFT Behcet Sarikaya 3 Category: Informational Alcatel 4 Title: draft-sarikaya-seamoby-paging-requirements-00.txt 5 Date: February 2001 7 Requirements for a Layer 3 Paging Protocol 9 Status of this Memo 11 This document is an individual contribution for the Seamoby Working 12 Group. 14 Distribution of this memo is unlimited. 16 This document is an Internet-Draft and is in full conformance with 17 all provisions of Section 10 of RFC2026. Internet-Drafts are working 18 documents of the Internet Engineering Task Force (IETF), its areas, 19 and its working groups. Note that other groups may also distribute 20 working documents as Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at: 29 http://www.ietf.org/ietf/1id-abstracts.txt 31 The list of Internet-Draft Shadow Directories can be accessed at: 33 http://www.ietf.org/shadow.html. 35 Copyright (C) The Internet Society 2000. All Rights Reserved. 37 Abstract 39 This document develops a set of requirements needed to support the mobile 40 nodes that are in the dormant mode by way of a Layer 3 (L3) paging 41 protocol for seamless IP mobility. This draft describes paging, and 42 presents a list of requirements regarding work on developing a L3 paging 43 protocol. 45 Table of Contents 47 1.0 Introduction............................................2 48 2.0 Definitions.............................................2 49 3.0 Advantages of Dormant Mode..............................3 50 4.0 Requirements............................................4 51 5.0 Security Considerations.................................4 52 6.0 IANA Considerations....................................4 53 7.0 References..............................................4 54 8.0 Author's Address........................................5 55 9.0 Full Copyright Statement................................5 57 1.0 Introduction 59 Many existing radio link protocols and mobile systems support 60 location of and radio link establishment with mobile nodes that are 61 not actively listening for delivery of IP packets. This functionality 62 allows mobile nodes to reduce power consumption and decreases 63 signalling load on the network for tracking mobiles that are not 64 actively participating in IP packet generation or reception. 66 When a mobile is in low power consumption mode, special steps need to 67 be taken to locate the mobile. These steps differ depending on the 68 radio link, but the generic name for this process is paging. 70 In this document, after some initial definitions, the requirements 71 related to establishing the paging protocol as an extension to the 72 base Mobile IPv4 [1] and Mobile IPv6 [2] protocols and their respective 73 extensions for regional registrations [3] and [4] are stated. 75 2.0 Definitions 77 The following definitions are relevant with respect to the paging: 79 Dormant Mode - A state in which a mobile node (MN) does not send or 80 receive IP packets. MN enters the dormant mode if it has not had any 81 communication with external IP nodes for a time period that is 82 determined by MN. The behaviour of MN in the dormant mode is 83 specified by the paging protocol. 85 Paging - As a consequence of a MN-bound packet destined for a 86 MN currently in dormant mode, messaging directed to locating the 87 mobile and establishing a last hop connection. This messaging is in 88 addition to simply delivering the packet to the mobile, i.e. last hop 89 routing of packets is NOT considered to be paging. 91 Paging Area - Collection of last hop routers that are searched to 92 locate a MN that is in the dormant mode. A paging 93 area does not necessarily correspond to an IPv4/v6 subnet. 95 3.0 Advantages of Dormant Mode 97 Dormant mode is advantageous to a MN for the following reasons: 99 - Power savings. By reducing the amount of time the mobile is 100 required to listen to L2, the drain on the mobile node's battery 101 is reduced. 103 - Reduced signalling for location tracking. By requiring the 104 mobile to only signal when it crosses a paging area boundary 105 rather than when it switches between L2 access points, the amount 106 of signalling for tracking the mobile is reduced. 108 - Reduced router state. The routers defined in [3] and [4] need not 109 keep the MN in dormant mode in their binding caches. The paging 110 protocol may identify a router that may keep the state in its binding 111 cache on the dormant node MNs. 113 4.0 Requirements 114 The following basic requirements are imposed upon any L3 paging protocol. 115 The requirements of a MN that performs a handover when in dormant mode 116 are stated in the next section. 118 - The operation of MN in the dormant mode is the domain of any L3 119 paging protocol. 121 - L3 paging protocol is not a stand-alone protocol, it MUST be defined 122 as an extension of the base Mobile IPv4 [1] or the base Mobile IPv6 123 [2] protocol. 125 - L3 paging protocol for a future micro mobility protocol to be developed 126 is for further study. 128 - L3 paging protocol SHOULD also extend any regional registration 129 extensions of the base Mobile IPv4/v6 protocol, i.e. [3] or [4]. 131 - L3 paging protocol MUST use L2 paging if available. 133 - The dormant mode MN MUST receive and respond to periodic L3 messages 134 called L3 pages designed to locate MN. The establishment of L2 135 connectivity in order to receive/ respond to L3 pages MUST enable 136 significant power savings to warrant going to the dormant mode. 138 - MN MUST inform the system before going into the dormant mode 140 - If the paging state is to be kept in a single router, the paging 141 protocol MUST clearly identify the steps to be taken in order to ensure 142 a fail-safe mode of operation. 144 4.1 Paging Areas 146 The following are recognized as the requirements related to the paging 147 areas: 149 - The routers defined by the regional registration protocol may be 150 organized into L3 paging areas. 152 - An informational RFC may be issued defining the organization of the 153 paging areas vis-a-vis IPv4/v6 subnets. 155 - A dormant mode MN MUST receive the identification of the paging area 156 in which it entered into the dormant mode. 158 - A dormant mode MN SHOULD register when it changes the paging area. Such 159 registrations may help establish fast handovers in IPv4 [5,7] and 160 IPv6 [6]. 162 5.0 Security Considerations 164 This type of non-protocol document does not directly affect the 165 security of the Internet. 167 6.0 IANA Considerations 169 This document does not directly affect IANA. 171 7.0 References 173 [1] C. Perkins, editor. "IP Mobility Support", RFC 2002, October, 1996. 175 [2] Johnson, D., and C. Perkins, "Mobility Support in IPv6", draft- 176 ietf-mobileip-ipv6-13.txt, work in progress. 178 [3] H. Soliman, C. Castelluccia, K. El-Malki, L. Bellier. "Hierarchical 179 MIPv6 Mobility Management", draft-ietf-mobileip-hmipv6-02.txt, 180 December 2000. 182 [4] Gustafsson, E., et al., "Mobile IP Regional Registration", 183 draft-ietf-mobileip-regtun-03.txt, July, 2000. 185 [5] Calhoun, P., et. al., "Foreign Agent Assisted Hand-off", draft- 186 calhoun-mobileip-proactive-fa-03.txt, work in progress. 188 [6] Tsirtsis, G., Editor, "Fast Handovers for Mobile IPv6", draft- 189 designteam-fast-mipv6-01.txt, work in progress. 191 [7] Al Malki, K., Soliman, H., "Fast Handooffs in Mobile IPv4", 192 draft-elmalki-mobileip-fast-handoffs-03.txt, work in progress. 194 8.0 Author's Address 196 Questions about this memo can be directed to: 198 Behcet Sarikaya 199 Alcatel USA M/S CTO2 200 1201 E. Campbell Rd. 201 Richardson, TX 75081-1936 USA 202 Tel: 1-972-996-5075 203 Fax: 1-972-996-5174 204 Email: Behcet.Sarikaya@usa.alcatel.com 206 9.0 Full Copyright Statement 208 Copyright (C) The Internet Society (2000). All Rights Reserved. 210 This document and translations of it may be copied and furnished to 211 others, and derivative works that comment on or otherwise explain it 212 or assist in its implementation may be prepared, copied, published 213 and distributed, in whole or in part, without restriction of any 214 kind, provided that the above copyright notice and this paragraph are 215 included on all such copies and derivative works. However, this docu- 216 ment itself may not be modified in any way, such as by removing the 217 copyright notice or references to the Internet Society or other 218 Internet organizations, except as needed for the purpose of develop- 219 ing Internet standards in which case the procedures for copyrights 220 defined in the Internet Standards process must be followed, or as 221 required to translate it into languages other than English. The lim- 222 ited permissions granted above are perpetual and will not be revoked 223 by the Internet Society or its successors or assigns. This document 224 and the information contained herein is provided on an "AS IS" basis 225 and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DIS- 226 CLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED 227 TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT 228 INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR 229 FITNESS FOR A PARTICULAR PURPOSE."