idnits 2.17.1 draft-ietf-seamoby-cardiscovery-issues-04.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. ** There are 2 instances of too long lines in the document, the longest one being 1 character 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 303: '...es can cause other problems. MNs MUST...' Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 90 has weird spacing: '...ilitate the s...' == Line 212 has weird spacing: '...d bring up ea...' == Line 261 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 238 looks like a reference -- Missing reference section? '4' on line 238 looks like a reference -- Missing reference section? '5' on line 240 looks like a reference -- Missing reference section? '6' on line 240 looks like a reference -- Missing reference section? '7' on line 240 looks like a reference -- Missing reference section? '8' on line 88 looks like a reference -- Missing reference section? '9' on line 256 looks like a reference -- Missing reference section? '10' on line 257 looks like a reference Summary: 10 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-04.txt Hemant Chaskar 4 16 October, 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. This information might be used to alert the user about 182 possible service degradation when moving. If the MN does have choices 183 in what AR might be used for connectivity after moving, i.e., because 184 of overlapping coverage areas, these choices might be presented to the 185 user or the running application might make choices based on certain 186 preferences. Clearly for this, it is necessary to have the knowledge 187 of the capabilities of the neighboring ARs, and this can be 188 obtained using the CAR discovery protocol. 190 Scenario 3: Least-cost phone call 192 Consider the preference expressed by the MN to prioritize handoffs 193 to an AR with minimal cost of access for phone call (``least cost 194 policy"). The ``cost of access" capability of an AR can be obtained 195 using CAR discovery protocol. 197 Scenario 4: Adaptability to change in the coverage topology 199 Consider a situation in which ARs may be temporarily introduced in 200 hot-spots to cater to the existing traffic demand. In such a case, 201 a static configuration of the neighborhood information in ARs is not 202 feasible as the operators may not inform each other of temporary 203 changes. A protocol is therefore needed in such cases for the MN to 204 automatically identify any change in the coverage topology and 205 identify the capabilities of the neighboring ARs. This can be 206 facilitated by the CAR discovery protocol. 208 Scenario 5: Inter-technology handoff 210 Consider the case in which an MN has a variety of wireless access 211 network media available to it, and also possibly a wired interface. 212 Theoretically, the MN could bring up each interface and solicit a 213 Router Advertisement on it, but as the number of interfaces becomes 214 larger, such a procedure results in a larger and larger drain on 215 power. An alternative would be if the MN could solicit for 216 alternative AR choices on an active interface, and use this 217 information to choose handoff target. 219 4. THE CAR DISCOVERY PROBLEM 221 There are two basic problems associated with CAR discovery: 223 1) Mapping from a Layer 2 identifier for an AP to the IP address of 224 the CAR 226 2) Identifying the capabilities of CAR 228 The two problems are related in that both are concerned with 229 obtaining IP-level information about a CAR for the purposes of 230 determination of the target access router for handoff. 231 We discuss these two problems in the following subsections. 233 4.1. CAR IP Address Discovery 235 The seamless handoff protocols defined in [3, 4, 5, 6, 7] require a 236 certain amount of IP level signaling between a MN's current AR and 237 the target AR to which the MN will undergo handoff or has undergone 238 handoff. For [3] and [4], the signaling is required to rearrange 239 routing for a Mobile IP handoff when the MN's link moves to the 240 target AR. For [5], [6], and [7], the signaling is required so that 241 the current AR can transfer IP service context to the target AR. IP 242 service context may include QoS state, AAA state, etc. Being able to 243 quickly set up IP service context on the target AR is important 244 because it determines how quickly the MN will receive the same level 245 of IP service on the target AR as it received on the old. In order 246 for the IP level signaling to occur, the current AR requires the IP 247 address of the target AR. 249 Typically, the seamless handoff protocols assume that the MN knows a 250 Layer 2 identifier for the wireless AP or AR to which it may undergo 251 a handoff. The Layer 2 identifier might be obtained when the MN has 252 Layer 2 beacon contact with the AP. It is now the task of the CAR 253 discovery protocol is to enable mapping from the Layer 2 identifier 254 to the IP address of the CAR that serves this AP. 256 This problem is not dissimilar to reverse address resolution [9] or 257 to the use of DHCP [10] to obtain the address of a host based on its 258 MAC address. In the current case, however, the reverse address 259 translation is occuring across subnets for ARs rather than between a 260 host and a server. Another added twist is that the actual L2 261 identifier may be for the new wireless AP and not for the new AR, 262 whereas the current AR requires the new AR IP address. Any solution 263 to this problem must provide for dynamic autoconfiguration of 264 reverse address resolution, so that ARs and APs that are added and 265 removed can be quickly discovered without requiring much, if any, 266 human intervention. 268 4.2. Identifying Capabilities of CAR 270 Although not common now, future generation mobile networks may 271 consist of ARs that offer coverage in the same geographical area but 272 are heterogeneous in capabilities. The basic functionality shared by 273 all IP routers is that of packet forwarding. In that respect, all 274 ARs are similar. However, heterogeneity may arise among different 275 ARs due to factors such as additional functions performed by ARs 276 (seamless handoff support, security functions, wireless performance 277 enhancing functions, etc.), administrative and business aspects of 278 providing service to MN (service provider, cost of access, etc.), 279 availability of certain type of resources with AR (QoS availability) 280 etc. A solution is needed that will allow the MN to learn the 281 capabilities of CARs that it might be interested in. CAR discovery 282 protocol enables this. 284 However, since the complexity of the process might grow, in particular 285 with growing number of capabilities, limitations in the scope of CAR 286 discovery with respect to, for instance, the number of supported 287 capabilities or the final decision making, might be necessary to cope 288 with this complexity issue. 290 5. SECURITY CONSIDERATIONS 292 CAR discovery may allow other nodes to learn information about an 293 AR, including its IP address and capabilities. Malicious nodes may 294 use this kind of information to launch DoS attacks and/or service 295 hijacking. 297 Information about the capabilities of a CAR often needs to be 298 digitally signed. Otherwise, intentional or accidental APs can 299 capture traffic, to the detriment of the MN. Such captures can 300 result in black holes, and/or can facilitate eavesdropping and active 301 attacks. Attacks like these have already occurred on 802.11 networks. 303 The need for digital signatures can cause other problems. MNs MUST 304 be preprovisioned with information that lets them ascertain the 305 authorization of any CAR. Digital signatures are expensive to compute 306 and verify; this can translate into increased computational load on 307 the CARs and on the MNs, and increased power consumption on the MNs. 309 Therefore, the following topics should be covered in any solution 310 developed for CAR discovery: 312 - Authentication of nodes 313 - Security associations between nodes 314 - Message/payload encryption. 315 - Encryption of CAR capabilities 316 - Additional load on CARs and MN due to additional security measures 318 6. ACKNOWLEDGEMENTS 320 Special thanks are due to John Loughney (Nokia) and Hesham Soliman 321 (Ericsson) for their input during the preparation of this document. 322 Steve Deering's thoughts about how to involve the mobile node in CAR 323 discovery were instrumental in achieving more focus to the problem 324 statement. 326 7. REFERENCES 328 1. "IP Mobility Support", C. Perkins (Editor), RFC 2002, October 329 1996. 331 2. "Mobility Support in IPv6", D. Johnson, C. Perkins, and Jari 332 Arkko, draft-ietf-mobileip-ipv6-17.txt, work in progress, May 333 2002. 335 3. "Low Latency Handoffs in Mobile IPv4", MIPv4 Handoffs Design 336 Team, draft-ietf-mobileip-lowlatency-handoffs-v4-00.txt, work in 337 progress, February 2001. 339 4. "Fast handoffs for Mobile IPv6", MIPv6 handoff Design Team, 340 draft-ietf-mobileip-fast-mipv6-01.txt, work in progress, April 341 2001. 343 5. "Problem Description: Reasons For Performing Context Transfers 344 Between Nodes in an IP Access Network", O. H. Levkowetz, et. al., 345 draft-ietf-seamoby-context-transfer-problem-stat-01.doc, work in 346 progress, May 2001. 348 6. "General requirements for a context transfer framework", H. 349 Sayed, et. al., draft-ietf-seamoby-ct-reqs-00.txt, work in 350 progress, May 2001. 352 7. "Buffer Management for Smooth handoffs in Mobile IPv6", G. 353 Krishnamurthi, R. Chalmers, and C. Perkins, draft-krishnamurthi- 354 mobileip-buffer6-01.txt, work in progress, March 2001. 356 8. "Supporting Optimized Handover for IP Mobility - Requirements 357 for Underlying Systems", J. Kempf, et. al., draft-manyfolks-l2- 358 mobilereq-02.txt, work in progress, November 2001. 360 9. "A Reverse Address Resolution Protocol", R. Finlayson, et. al. 361 RFC 903, June 1984 363 10. "Dynamic Host Configuration Protocol", R. Droms, RFC 1531, 364 October 1993. 366 8. AUTHORS' ADDRSSES 368 Dirk Trossen 370 Communication Systems Laboratory 371 Nokia Research Center 372 5 Wayside Road 373 Burlington, MA 01803, USA 374 Phone: +1 781 993 3605 375 Fax: +1 781 993 1907 376 E-mail: dirk.trossen@nokia.com 378 Govind Krishnamurthi 380 Communication Systems Laboratory 381 Nokia Research Center 382 5 Wayside Road 383 Burlington, MA 01803, USA 384 Phone: +1 781 993 3627 385 Fax: +1 781 993 1907 386 E-mail: govind.krishnamurthi@nokia.com 388 Hemant Chaskar 390 Communication Systems Laboratory 391 Nokia Research Center 392 5 Wayside Road 393 Burlington, MA 01803, USA 394 Phone: +1 781 993 3785 395 Fax: +1 781 993 1907 396 E-mail: hemant.chaskar@nokia.com 398 James Kempf 400 DoCoMo Communication Laboratories, USA 401 181 Metro Drive, Suite 300 402 San Jose, CA 95110, USA 403 Phone: +1 408 451 4711 404 Email: kempf@docomolabs-usa.com