idnits 2.17.1 draft-jung-seamoby-paging-buffload-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: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. == The page length should not exceed 58 lines per page, but there was 5 longer pages, the longest (page 2) being 60 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 13 instances of too long lines in the document, the longest one being 7 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- 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 (December 2001) is 8167 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-01) exists of draft-renker-paging-ipv6-00 Summary: 6 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Seamoby Working Group H. Jung 3 Internet Draft S. Koh 4 Document:draft-jung-seamoby-paging-buffload-00.txt ETRI/KOREA 5 Category: Informational December 2001 7 Reducing the Buffering Load of Paging Agent in IP Paging 8 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC 2026. 15 Internet-Drafts are draft documents valid for a maximum of six months 16 and may be updated, replaced, or obsoleted by other documents at any 17 time. It is inappropriate to use Internet-Drafts as reference 18 material or to cite them other than as "work in progress." 20 The list of current Internet-Drafts can be accessed at 21 http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft 22 Shadow Directories can be accessed at http://www.ietf.org/shadow.html 24 Convention used in this draft 26 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 27 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 28 document are to be interpreted as described in RFC 2119. 30 Abstract 32 This draft defines two procedures to distribute buffering load in IP 33 paging using PA. A couple of documents using the PA, which includes 34 all functions defined RFC 3154 in an entity, have beee submitted for 35 cadidate protocol for IP paging. In this PA paging approach, the 36 centralized buffering in PA can be a bottleneck point if a PA has to 37 manage large paging area and a number of idle mobile hosts. To 38 address the problem, it can be good solution to distribute buffering 39 load among ARs in the paging area. 41 1. Introduction 43 IP paging has been designed to decrease the signaling load for 44 location registration and to prevent rapid power consumption of 45 mobile nodes. For these purposes, the IETF SeaMoby WG has recently 46 produced substantial documents, including Problem Statement and 47 Requirements for IP paging protocol [1, 2]. Based on the functional 48 requirements, specific proposals for IP paging protocol have been 49 made in the Working Group. In some IP paging schemes currently 50 considered, an agent called Paging Agent(PA), or Paging Function(PF), 51 is employed to perform all the functionalities required for IP paging 52 which are specified in RFC3154 [3, 4]. 54 In this document, we consider the buffering functionality of PA, 55 which is one of the IP paging functionalities. The PA temporarily 56 buffers the data destined to a idle MN, until the location of MN is 57 known to PA. In this approach, a PA must perform the buffering for 58 all of the MNs in the network. Therefore, the PA is likely to be 59 overloaded due to the buffering operations for all the MNs in the 60 network. The buffering load at the PA becomes more severe, as the 61 size of paging area gets larger and the number of idle MNs in the 62 area increases. In this document, we propose an alternate buffering 63 scheme designed to ensure that the buffering load of PA can be 64 reduced significantly, compared to the existing scheme. The main 65 idea of the proposed scheme is that the buffering for a MN is 66 performed by its last-registered AR other than PA. The last- 67 registered AR represents an AR which a MN has registered to, after it 68 entered the current paging area. By this, the buffering load of PA 69 can be distributed into the boundary ARs of the paging area. 71 2. Buffering Scheme Using the Last-Registered ARs 73 The proposed scheme is designed based on the principle that the 74 processing load of PA can be alleviated by distributing its buffering 75 load over the ARs(or Foreign Agents) in the paging area, which can 76 also be described in the literature [5, 6]. In the proposed scheme, 77 the buffering functionality is performed by ARs other than PA, 78 diffferently from the existing paging schemes. Figure 1 illustrates 79 the distribution of buffering load using the last-registered ARs in 80 the paging area. We assume that MN's idle registration is 81 acomplished by registrating its serving PA address as CoA to HA. 82 Then the location update will be done only if the serving PA is 83 changed. 85 In the figure a MN registered its idle state to PA through AR-A. It 86 means that AR-A is the last-registered AR of the MN. We assume that 87 the MN is now located in the coverage of AR-D by way of AR-B and AR- 88 C. When the PA receives data packets destined to idle MN from 89 HA(1a), it realizes that the MN is in the idle state, and it thus 90 forwards the recevied packets to the last registered AR, AR-A(1b). 91 The AR-A will save these packets in its buffer. The PA now initiates 92 the paging procedure(1c) to locate the MN in the paging area. 94 Each router in the area will receive the L3 paging message and then 95 translate it into the corresponding L2 paging signaling through air 96 interface(2). 98 The MN receives the paging signal and then responds with the 99 registration message to the last-registered AR-A(3b) as well as the 100 PA(3a), through its currently serving AR-D. The last-registered AR-A 101 will then forward the buffered data packets to the MN by way of AR- 102 D(4). Hereafter, the MN comes back to the active state, and thus it 103 will receive the subsequent data packets directly from HA, not via 104 the last-registered AR-A. 106 | 107 | (1a) 108 V 109 +------+ 110 | | 111 | PA |<--------------+ 112 | | | 113 +------+ | 114 | | | 115 (1b)| | | 116 +------------+ | | 117 | |(1c) | 118 | | |(3a) 119 | | | 120 +----|--------------|------------------|--------+ 121 | | +---------+--+------+-----------|-+ | 122 | | | | (3b) | | | | 123 | | | +---------------------------+-+ | | 124 | | | | | | (4)| | | | 125 | V V V V V V | V | 126 | +------+ +------+ +------+ +------+ | 127 | | AR-A | | AR-B | | AR-C | | AR-D | | 128 | +------+ +------+ +------+ +------+ | 129 | |(2) |(2) |(2) ^ |(2) | 130 | | | | | | ^ | 131 | V V V | V | | 132 | +------+ | 133 | | MN | | 134 | +------+ | 135 | | 136 | IP paging area | 137 +-----------------------------------------------+ 139 Figure 1: Buffering Using the Last-Registered AR 141 The only requirement to implement the proposed scheme is that each of 142 ARs in the area needs to have the buffer capacity. On the other 143 hand, it is relatively easy to extend the paging signaling algorithm 144 and messages to support the proposed scheme. 146 3. Further Enhancement of the Proposed Scheme 148 The proposed scheme is effective in that the buffering load of PA can 149 be alleviated. However, it is noted that the border routers of the 150 paging area are usually the last-registered ARs, and thus the 151 buffering loads for the area may be concentrated on these border ARs. 152 Another concern of the scheme is that a failure of the 153 buffering(last-registered) AR, which may not be on the data path, 154 induces overall failure of data delivery. 156 One possible way to address the problems described above is to select 157 and use the most suitable AR in the paging area as the buffering AR 158 for each MN. The selection of the most suitable AR will be made by 159 PA, based on the state information gathered by interaction between PA 160 and candidate ARs in the area. Such state information may be the 161 simple status of AR(running or failed), or may include more detailed 162 system status such as available buffer memory and current processing 163 loads. 165 In any way, the PA needs to collect the state information from ARs in 166 the area. On the reverse, each AR must report its state information 167 to the PA. For this purpose, a new signaling mechanism may be 168 specified along with signaling messages on the basis of periodic time 169 or a pre-configured rule. Alternatively, an existing IP routing or 170 management protocols such as RIP, OSPF, SNMP may be used or extended 171 for conveying the status information. 173 In the enhanced scheme using the most suitable AR, the buffering 174 procedures are similar to those using the last-registered AR, other 175 than the following differences: 177 When PA receives the packet destined to MN from HA, it first selects 178 the best candidate AR as the buffering AR for the MN, based on the 179 collected state information. 181 After that, the PA begins to locate the idle MN by sending paging 182 signal message. The paging message must contain information(like an 183 identifier) to indicate which AR is serving for the MN as the 184 buffering AR in the area. 186 In resonse to the paging message, the MN sends registration message 187 to PA as well as its buffering AR. The buffering AR will then 188 forwards the buffered packets to MN. 190 4. Implementation Notes 192 TBD 194 5. Security Considerations 196 TBD 198 6. References 200 [1] J. Kempf. Dormant mode host alerting(ip paging) problem 201 statement. Request for Comments 3132, Internet Engineering Task 202 Force, June 2001. 204 [2] J. Kempf, C. Castelluccia, et. al., Requirements and Functional 205 Architecture for an IP Host Alerting Protocol, Request for Comments 206 3154, Internet Engineering Task Force, August 2001 208 [3] Rajeev Koodli, et. al., Dormant Mode Handover Support in Mobile 209 Networks, Internet draft, draft-koodli-paging-01.txt, Internet 210 Engineering Task Force, May 2002 212 [4] G. Renker, et. al., Paging Concept for IP based Networks, 213 internet draft, draft-renker-paging-ipv6-00.txt, Internet Engineering 214 Task Force, June 2001 216 [5] R. Ramjee, et. al., IP Paging Service for Mobile Hosts, ACM 217 MOBICOM, 2001 219 [6] X. Zhang, et. al., P-MIP: Paging in Mobile IP, The Fourth 220 International Workshop on Wireless Mobile Multimedia, Rome, Italy, 221 July 2001 223 7. Authors' Addresses 225 HeeYoung Jung 226 Protocol Engineering Center 227 Electronics and Telecommunication Research Institute 228 161 Kajung-Dong, Yusong-Gu, Taejon, Korea 229 Phone: +82 42 860-4928 230 EMail: hyjung@etri.re.kr 231 Fax: +82 42 861-5404 233 Seok Joo Koh 234 Protocol Engineering Center 235 Electronics and Telecommunication Research Institute 236 161 Kajung-Dong, Yusong-Gu, Taejon, Korea 237 Phone: +82 42 860-6218 238 EMail: sjkoh@etri.re.kr 239 Fax: +82 42 861-5404 241 Full Copyright Statement 243 "Copyright(C) The Internet Society(2000). All Rights Reserved. This 244 document and translations of it may be copied and furnished to others, and 245 derivative works that comment on or otherwise explain it or assist in its 246 implementation may be prepared, copied, published and distributed, in whole 247 or in part, without restriction of any kind, provided that the above 248 copyright notice and this paragraph are included on all such copies and 249 derivative works. However, this document itself may not be modified in any 250 way, such as by removing the copyright notice or references to the Internet 251 Society or other Internet organizations, except as needed for the purpose of 252 developing Internet standards in which case the procedures for copyrights 253 defined in the Internet Standards process must be followed, or as required 254 to translate it into languages other than English. 256 The limited permissions granted above are perpetual and will not be 257 revoked by the Internet Society or its successors or assigns. 259 This document and the information contained herein is provided on an "AS IS" 260 basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE 261 DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO 262 ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY 263 RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 264 PARTICULAR PURPOSE."