idnits 2.17.1 draft-ietf-seamoby-cardiscovery-issues-03.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 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard 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 an Authors' Addresses Section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 90 has weird spacing: '...ilitate the s...' == Line 207 has weird spacing: '...d bring up ea...' == Line 256 has weird spacing: '...not for the n...' -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? '1' on line 78 looks like a reference -- Missing reference section? '2' on line 78 looks like a reference -- Missing reference section? '3' on line 233 looks like a reference -- Missing reference section? '4' on line 233 looks like a reference -- Missing reference section? '5' on line 235 looks like a reference -- Missing reference section? '6' on line 235 looks like a reference -- Missing reference section? '7' on line 235 looks like a reference -- Missing reference section? '8' on line 88 looks like a reference -- Missing reference section? '9' on line 251 looks like a reference -- Missing reference section? '10' on line 252 looks like a reference Summary: 8 errors (**), 0 flaws (~~), 4 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 IETF Seamoby Working Group Dirk Trossen 2 INTERNET-DRAFT Govind Krishnamurthi 3 draft-ietf-seamoby-cardiscovery-issues-03.txt Hemant Chaskar 4 12 June, 2002 Nokia 5 James Kempf 6 DoCoMo 7 Issues in candidate access router discovery 8 for seamless IP-level handoffs 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. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as Internet- 17 Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six 19 months and may be updated, replaced, or obsoleted by other 20 documents at any time. It is inappropriate to use Internet-Drafts 21 as reference material or to cite them other than as ``work in 22 progress.'' 23 The list of current Internet-Drafts can be accessed at 24 http://www.ietf.org/ietf/1id-abstracts.txt. 25 The list of Internet-Draft Shadow Directories can be accessed at 26 http://www.ietf.org/shadow.html. 28 Copyright notice 30 Copyright (c) The Internet Society (2002). All rights reserved. 32 Abstract 34 Handoff in IP mobility protocols involves moving a mobile node's 35 Layer 3 routing reachability point from one access router to 36 another, before or after the mobile node has established a Layer 2 37 connection with the radio access point that is covered by the new 38 access router. In addition, other context information about the 39 mobile node's IP service may be transferred from the old access 40 router to the new one, in order to minimize the service disruption 41 during the handoff process. While the exact details of how this is 42 accomplished vary depending on the IP mobility and seamless handoff 43 protocols, one common thread required for IP-level handoffs is 44 discovering the candidate access routers for the mobile node's 45 handoff. Discovering the candidate access router involves 46 identifying its IP address as well as its capabilities that the 47 mobile node might be interested in. At the time of IP-level handoff, 48 if a collection of candidates is identified, an algorithm is run to 49 determine the target access router for the mobile node's handoff. 50 This document describes the problem of candidate access router 51 discovery. The document does not discuss the algorithm by which the 52 actual target access router is selected, nor how the handoff to the 53 target is achieved. 55 Table of Content 56 1. INTRODUCTION...................................................3 57 1.1. Seamless Handoff Protocols...................................3 58 1.2. Choice for Handoff...........................................3 59 2. TERMINOLOGY....................................................4 60 3. MOTIVATION FOR CAR DISCOVERY...................................4 61 4. THE CAR DISCOVERY PROBLEM......................................6 62 4.1. CAR IP Address Discovery.....................................6 63 4.2. Identifying Capabilities of CAR..............................7 64 5. SECURITY CONSIDERATIONS........................................7 65 6. ACKNOWLEDGEMENTS...............................................7 66 7. REFERENCES.....................................................7 67 8. AUTHORS' ADDRESSES.............................................8 69 1. INTRODUCTION 71 IP mobility protocols enable mobile nodes (MNs) to change the access 72 routers (ARs) by which they obtain the Layer 3 connectivity to the 73 Internet, while communicating with another node over the Internet. 74 An AR providing Internet connectivity to the MN changes when there 75 is a change (usually as a result of movement of the MN) in the 76 access point (AP) through which the MN communicates with the wired 77 network, such that the AR serving the new AP is in a new subnet. 78 There are existing solutions [1, 2] that enable MNs to execute IP- 79 level handoffs between the ARs. 81 1.1. Seamless Handoff Protocols 83 Additionally, work is underway [3, 4, 5, 6, 7], to define protocols 84 that would allow seamless, meaning low latency and low packet loss, 85 handoffs of MNs between the ARs. These seamless handoff solutions 86 assume that the (wireless) link protocol is capable of delivering a 87 Layer 2 identifier for the new AP or the radio interface of new AR 88 [8] to the current AR or to the MN, and require that the current AR 89 be able to translate this Layer 2 identifier to the IP address of 90 the new AR in order to facilitate the seamless handoff. In addition 91 to simply providing the Layer 2 to IP address mapping, the AR needs 92 some way to determine if the Layer 2 identifier is that of a 93 legitimate AP or AR or whether it is an imposter. Some link layers 94 provide Layer 2 security mechanisms for this purpose. 96 1.2. Choice for Handoff 98 In future mobile networks, there will be cases when MN has a choice 99 of performing IP-level handoff to a different AR. For example, an MN 100 having network interface cards supporting two or more wireless 101 access technologies (such as, 3G and wireless LAN) and communicating 102 over one of them, may wish to switch to a different access network 103 if it feels that the IP service offered by the latter better suits 104 its requirements. A generalization of this case is when the MN has a 105 choice of different APs (of possibly different media and access 106 technologies) connected to different ARs, for the sake of 107 maintaining Internet connectivity. These different ARs may have 108 different capabilities (different service providers, different load 109 conditions, different wired QoS availability, etc.). The MN requires 110 some means of obtaining information about the capabilities of these 111 ARs so that the best decision about the handoff target can be made. 112 Note that there might be scenarios when a handoff is essential to at 113 least one of these ARs (old connection is fading fast) as well as 114 those when MN may live without performing a handoff to any of these 115 ARs (coverage of new AR is subsumed within that of the current AR). 116 Further, depending upon the handoff scenario, seamless handoff 117 protocols may or may not be used. 119 The two problems are linked in the sense that they both involve 120 determining the information about a new AR (IP address and 121 capabilities) that is a candidate for the next handoff. In this 122 document, we discuss the problem of Candidate Access Router (CAR) 123 discovery. 125 2. TERMINOLOGY 127 Access Point (AP) 129 A radio transceiver by which an MN obtains Layer 2 connectivity 130 with the wired network. 132 Access Router (AR) 134 An IP router residing in an access network and connected to one or 135 more APs. An AR offers IP connectivity to MN. 137 Capability of AR 139 A characteristic of the IP service offered by an AR that may be of 140 interest to an MN when the AR is being considered as a handoff 141 candidate. 143 Candidate AR (CAR) 145 An AR to which MN has a choice of performing IP-level handoff. This 146 means that MN has the right radio interface to connect to an AP that 147 is served by this AR, as well as the coverage of this AR overlaps 148 with that of the AR to which MN is currently attached to. 150 Target AR (TAR) 152 An AR with which the procedures for the MN's IP-level handoff are 153 initiated. TAR is selected after running a TAR Selection Algorithm 154 that takes into account the capabilities of CARs, preferences of MN 155 and any local policies. 157 3. MOTIVATION FOR CAR DISCOVERY 159 This section describes some features that can be implemented with 160 the help of CAR discovery protocol. 162 Scenario 1: Load balancing 164 Consider an AR to which an MN is currently attached. This AR is 165 denoted by AR1. Further, assume that AR1 is heavily loaded. Suppose 166 there is another AR, denoted by AR2, that is reachable from the 167 attached MN and is not heavily loaded. Then, MN may decide to 168 undergo handoff to AR2. Such load balancing can be achieved using 169 the capability information about AR2 obtained via CAR discovery 170 protocol. 172 Scenario 2: Resource intensive applications 174 Consider an MN running a streaming video application, which might be 175 an important application for the future mobile networks. These 176 applications require high bandwidth and possibly other QoS support 177 to be available at the AR serving the MN. When this MN moves into 178 the coverage area of a new AR, it is possible that the new AR does 179 not have the capability to support the MN's application. The MN can 180 then be informed about this fact when it is still connected to the 181 current AR. Clearly for this, it is necessary to have the knowledge 182 of the capabilities of the neighboring ARs, and this can be 183 obtained using the CAR discovery protocol. 185 Scenario 3: Least-cost phone call 187 Consider the preference expressed by the MN to prioritize handoffs 188 to an AR with minimal cost of access for phone call (``least cost 189 policy"). The ``cost of access" capability of an AR can be obtained 190 using CAR discovery protocol. 192 Scenario 4: Adaptability to change in the coverage topology 194 Consider a situation in which ARs may be temporarily introduced in 195 hot-spots to cater to the existing traffic demand. In such a case, 196 a static configuration of the neighborhood information in ARs is not 197 feasible as the operators may not inform each other of temporary 198 changes. A protocol is therefore needed in such cases for the MN to 199 automatically identify any change in the coverage topology and 200 identify the capabilities of the neighboring ARs. This can be 201 facilitated by the CAR discovery protocol. 203 Scenario 5: Inter-technology handoff 205 Consider the case in which an MN has a variety of wireless access 206 network media available to it, and also possibly a wired interface. 207 Theoretically, the MN could bring up each interface and solicit a 208 Router Advertisement on it, but as the number of interfaces becomes 209 larger, such a procedure results in a larger and larger drain on 210 power. An alternative would be if the MN could solicit for 211 alternative AR choices on an active interface, and use this 212 information to choose handoff target. 214 4. THE CAR DISCOVERY PROBLEM 216 There are two basic problems associated with CAR discovery: 218 1) Mapping from a Layer 2 identifier for an AP to the IP address of 219 the CAR 221 2) Identifying the capabilities of CAR 223 The two problems are related in that both are concerned with 224 obtaining IP-level information about a CAR for the purposes of 225 determination of the target access router for handoff. 226 We discuss these two problems in the following subsections. 228 4.1. CAR IP Address Discovery 230 The seamless handoff protocols defined in [3, 4, 5, 6, 7] require a 231 certain amount of IP level signaling between a MN's current AR and 232 the target AR to which the MN will undergo handoff or has undergone 233 handoff. For [3] and [4], the signaling is required to rearrange 234 routing for a Mobile IP handoff when the MN's link moves to the 235 target AR. For [5], [6], and [7], the signaling is required so that 236 the current AR can transfer IP service context to the target AR. IP 237 service context may include QoS state, AAA state, etc. Being able to 238 quickly set up IP service context on the target AR is important 239 because it determines how quickly the MN will receive the same level 240 of IP service on the target AR as it received on the old. In order 241 for the IP level signaling to occur, the current AR requires the IP 242 address of the target AR. 244 Typically, the seamless handoff protocols assume that the MN knows a 245 Layer 2 identifier for the wireless AP or AR to which it may undergo 246 a handoff. The Layer 2 identifier might be obtained when the MN has 247 Layer 2 beacon contact with the AP. It is now the task of the CAR 248 discovery protocol is to enable mapping from the Layer 2 identifier 249 to the IP address of the CAR that serves this AP. 251 This problem is not dissimilar to reverse address resolution [9] or 252 to the use of DHCP [10] to obtain the address of a host based on its 253 MAC address. In the current case, however, the reverse address 254 translation is occuring across subnets for ARs rather than between a 255 host and a server. Another added twist is that the actual L2 256 identifier may be for the new wireless AP and not for the new AR, 257 whereas the current AR requires the new AR IP address. Any solution 258 to this problem must provide for dynamic autoconfiguration of 259 reverse address resolution, so that ARs and APs that are added and 260 removed can be quickly discovered without requiring much, if any, 261 human intervention. 263 4.2. Identifying Capabilities of CAR 265 Although not common now, future generation mobile networks may 266 consist of ARs that offer coverage in the same geographical area but 267 are heterogeneous in capabilities. The basic functionality shared by 268 all IP routers is that of packet forwarding. In that respect, all 269 ARs are similar. However, heterogeneity may arise among different 270 ARs due to factors such as additional functions performed by ARs 271 (seamless handoff support, security functions, wireless performance 272 enhancing functions, etc.), administrative and business aspects of 273 providing service to MN (service provider, cost of access, etc.), 274 availability of certain type of resources with AR (QoS availability) 275 etc. A solution is needed that will allow the MN to learn the 276 capabilities of CARs that it might be interested in. CAR discovery 277 protocol enables this. 279 5. SECURITY CONSIDERATIONS 281 CAR discovery may allow other nodes to learn information about an 282 AR, including its IP address and capabilities. Malicious nodes may 283 use this kind of information to launch DoS attacks and/or service 284 hijacking. Therefore, the following topics should be covered in any 285 solution developed for CAR discovery: 287 - Authentication of nodes 288 - Security associations between nodes 289 - Message/payload encryption. 291 6. ACKNOWLEDGEMENTS 293 Special thanks are due to John Loughney (Nokia) and Hesham Soliman 294 (Ericsson) for their input during the preparation of this document. 295 Steve Deering's thoughts about how to involve the mobile node in CAR 296 discovery were instrumental in achieving more focus to the problem 297 statement. 299 7. REFERENCES 301 1. ``IP Mobility Support", C. Perkins (Editor), RFC 2002, October 302 1996. 304 2. ``Mobility Support in IPv6", D. Johnson, C. Perkins, and Jari 305 Arkko, draft-ietf-mobileip-ipv6-17.txt, work in progress, May 306 2002. 308 3. ``Low Latency Handoffs in Mobile IPv4", MIPv4 Handoffs Design 309 Team, draft-ietf-mobileip-lowlatency-handoffs-v4-00.txt, work in 310 progress, February 2001. 312 4. ``Fast handoffs for Mobile IPv6", MIPv6 handoff Design Team, 313 draft-ietf-mobileip-fast-mipv6-01.txt, work in progress, April 314 2001. 316 5. ``Problem Description: Reasons For Performing Context Transfers 317 Between Nodes in an IP Access Network", O. H. Levkowetz, et. al., 318 draft-ietf-seamoby-context-transfer-problem-stat-01.doc, work in 319 progress, May 2001. 321 6. ``General requirements for a context transfer framework", H. 322 Sayed, et. al., draft-ietf-seamoby-ct-reqs-00.txt, work in 323 progress, May 2001. 325 7. ``Buffer Management for Smooth handoffs in Mobile IPv6", G. 326 Krishnamurthi, R. Chalmers, and C. Perkins, draft-krishnamurthi- 327 mobileip-buffer6-01.txt, work in progress, March 2001. 329 8. ``Supporting Optimized Handover for IP Mobility - Requirements 330 for Underlying Systems", J. Kempf, et. al., draft-manyfolks-l2- 331 mobilereq-02.txt, work in progress, November 2001. 333 9. ``A Reverse Address Resolution Protocol", R. Finlayson, et. al. 334 RFC 903, June 1984 336 10. ``Dynamic Host Configuration Protocol", R. Droms, RFC 1531, 337 October 1993. 339 8. AUTHORS' ADDRSSES 341 Dirk Trossen 343 Communication Systems Laboratory 344 Nokia Research Center 345 5 Wayside Road 346 Burlington, MA 01803, USA 347 Phone: +1 781 993 3605 348 Fax: +1 781 993 1907 349 E-mail: dirk.trossen@nokia.com 351 Govind Krishnamurthi 353 Communication Systems Laboratory 354 Nokia Research Center 355 5 Wayside Road 356 Burlington, MA 01803, USA 357 Phone: +1 781 993 3627 358 Fax: +1 781 993 1907 359 E-mail: govind.krishnamurthi@nokia.com 361 Hemant Chaskar 363 Communication Systems Laboratory 364 Nokia Research Center 365 5 Wayside Road 366 Burlington, MA 01803, USA 367 Phone: +1 781 993 3785 368 Fax: +1 781 993 1907 369 E-mail: hemant.chaskar@nokia.com 371 James Kempf 373 DoCoMo Communication Laboratories, USA 374 181 Metro Drive, Suite 300 375 San Jose, CA 95110, USA 376 Phone: +1 408 451 4711 377 Email: kempf@docomolabs-usa.com