idnits 2.17.1 draft-ietf-seamoby-cardiscovery-issues-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 -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. == 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 separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 21 has weird spacing: '... months and m...' == Line 28 has weird spacing: '... The list of...' -- 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 (July 2001) is 8319 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 2002 (ref. '1') (Obsoleted by RFC 3220) == Outdated reference: A later version (-24) exists of draft-ietf-mobileip-ipv6-13 == Outdated reference: A later version (-11) exists of draft-ietf-mobileip-lowlatency-handoffs-v4-00 ** Downref: Normative reference to an Experimental draft: draft-ietf-mobileip-lowlatency-handoffs-v4 (ref. '3') -- No information found for draft-ietf-mobileip-fast-mipv6 - is the name correct? -- Possible downref: Normative reference to a draft: ref. '4' == Outdated reference: A later version (-04) exists of draft-ietf-seamoby-context-transfer-problem-stat-01 ** Downref: Normative reference to an Informational draft: draft-ietf-seamoby-context-transfer-problem-stat (ref. '5') == Outdated reference: A later version (-05) exists of draft-ietf-seamoby-ct-reqs-00 ** Downref: Normative reference to an Informational draft: draft-ietf-seamoby-ct-reqs (ref. '6') -- Possible downref: Normative reference to a draft: ref. '7' Summary: 9 errors (**), 0 flaws (~~), 7 warnings (==), 5 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-00.txt Hemant Chaskar 4 Expires: January 2002 Nokia 5 James Kempf 6 Sun Microsystems, Inc. 7 July 2001 9 Issues in candidate access router discovery for seamless IP handoffs 11 Status of This Memo 13 This document is an Internet-Draft and is in full conformance 14 with all provisions of Section 10 of RFC2026. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet 19 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six 21 months and may be updated, replaced, or made obsolete by other 22 documents at any time. It is inappropriate to use Internet-Drafts 23 as reference material or to cite them other than as "work in 24 progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 Copyright Notice 33 Copyright (c) The Internet Society (2001). All rights reserved. 35 ABSTRACT 37 Handoff in IP mobility protocols involves moving a mobile node's 38 Layer 3 routing reachability information from one access router to 39 another, before or after the mobile node has established a Layer 2 40 connection with the radio access point that is covered by the new 41 access router. In addition, other context information about the 42 mobile node's packet session may be transferred from the old access 43 router to the new one, in order to minimize the service disruption 44 during the handoff process. While the exact details of how this is 45 accomplished vary depending on the IP mobility and seamless handoff 46 protocols, one common thread required for seamless handoffs is 47 identifying the candidate access routers for the mobile node's 48 handoff. When a collection of candidates has been identified, an 49 algorithm is run to determine the target access router, and this 50 router becomes the target of handoff at Layer 3. This document 51 presents a problem statement describing issues involved in designing 52 a candidate access router discovery protocol. The document does not 53 discuss the algorithm by which the actual target router is 54 identified, nor how the handoff to the target is achieved. 56 TABLE OF CONTENTS 58 1. INTRODUCTION 1 60 2. TERMINOLOGY 1 62 3. CANDIDATE ACCESS ROUTER DISCOVERY PROBLEM 2 64 3.1 Anticipated CAR Discovery 2 65 3.2 Dynamic CAR Discovery 3 66 3.3 Hybrid CAR Discovery 3 68 4. SPECIFIC ISSUES IN CAR DISCOVERY 3 70 4.1 Identifying PAARs 3 71 4.2 Identifying capabilities of PAARs 4 72 4.3 Security considerations 5 74 5. REFERENCES 5 76 6. AUTHORS' ADDRESS 6 78 ACKNOWLEDGMENTS 80 Special thanks are due to John Loughney (Nokia) for his input 81 during the preparation of this document. 83 1. INTRODUCTION 85 IP mobility protocols enable mobile nodes (MNs) to change the access 86 routers (ARs) by which they access the Internet. An AR providing 87 Internet connectivity to the MN changes when movement of the MN 88 causes a change in the radio access point through which the MN 89 communicates with the wired network, such that the new radio access 90 point is in a new subnet. There are existing solutions [1, 2] that 91 enable MNs to execute handoffs between the ARs. Additionally, work is 92 underway [3, 4, 5, 6, 7], to define protocols that would allow 93 seamless, meaning low latency and low packet loss, handoffs of MNs 94 between the ARs. These handoff solutions assume that the identity of 95 the new AR is known to the old AR. They do not provide a solution to 96 the problem of discovering the target AR for the MN's handoff. What 97 is required is a protocol that would allow an AR or an MN to discover 98 the neighboring ARs for handoff, along with their capabilities. This 99 information can be used for selecting the actual target AR for the 100 MN's handoff. This draft discusses the issues involved in the problem 101 of candidate AR discovery. The draft does not discuss the problem of 102 actually selecting the target AR to which handoff is performed, nor 103 the actual handoff process itself. 105 2. TERMINOLOGY 107 Access Point (AP) 109 A radio transceiver by which an MN obtains Layer 2 connectivity 110 with the wired network. 112 Access Router (AR) 114 An IP router residing in an access network and connected to one 115 or more APs. An AR offers IP connectivity to MN. 117 Physically Adjacent AR (PAAR) 119 An AR whose coverage area is such that an MN may move from the 120 coverage area of the AR currently serving the MN into the coverage 121 area of this AR. 123 Candidate AR (CAR) 125 This is an AR that is a candidate for MN's handoff. CAR is 126 necessarily a PAAR of the AR currently serving the MN, and also has 127 the capability set required to serve the MN. 129 Target AR (TAR) 131 This is an AR with which the procedures for MN's handoff 132 are initiated. 134 TAR Selection Algorithm 136 The algorithm that determines a unique TAR for MN's handoff from 137 the set of CARs. The exact nature and definition of this algorithm 138 is outside the scope of this document. 140 3. CANDIDATE ACCESS ROUTER DISCOVERY PROBLEM 142 There are two basic approaches to CAR discovery, namely, Anticipated 143 CAR Discovery and Dynamic CAR Discovery. 145 3.1 Anticipated CAR Discovery 147 In this approach, an AR currently serving the MN identifies all CARs 148 for the MN's handoff, at some point prior to handoff. This 149 information is then immediately available at the time of handoff as 150 input to the TAR Selection Algorithm. Another input into the TAR 151 Selection Algorithm may be the preferences expressed by the MN prior 152 to the handoff, or preferences enforced by the administrative 153 control. At the time of handoff, it may only be required to provide 154 input to TAR Selection Algorithm about the reachability of 155 neighboring ARs from the MN. The advantage of this approach is that 156 the handoff can be executed quickly because the AR has already 157 collected much of the information needed by the TAR Selection 158 Algorithm. Also, this approach does not generate much radio traffic 159 for performing CAR discovery. 161 The Anticipated CAR Discovery problem encompasses the areas outlined 162 in the box in Figure 1. 164 ----------------------------------------------------------------- 165 | All routers | 166 | | | 167 | | Physical adjacency discovery | 168 | v | 169 | Local map of PAARs at current AR | 170 | | | 171 | | Capability identification | 172 | v | 173 | CARs for MN's handoff identified at current AR | 174 | | | 175 --------------------------|-------------------------------------- 176 | 177 | Predefined preferences of the MN 178 AR Reachability | negotiated at admission time or 179 for the MN | administrative preferences 180 | | | 181 v v v 182 TAR Selection Algorithm executed at the time of 183 handoff to determine unique TAR for MN's handoff 185 Figure 1: The Anticipated CAR Discovery Problem 187 3.2 Dynamic CAR Discovery 189 In this approach, an MN dynamically obtains information about 190 the available ARs for handoff, along with their capabilities. When 191 the MN detects an AR that has capabilities which match its 192 preferences, the MN may notify the currently serving AR to perform a 193 handoff to this AR using one or more of the seamless handoff 194 protocols. The advantage of this technique is that the MN has 195 fine-grained control over the TAR selection. However, this approach 196 generates more radio traffic during the CAR discovery step. Also, it 197 is required that the MN can listen to or, in some cases, even talk to 198 the PAARs for collecting capability information and negotiating 199 preferences, while still being connected to the current AR. 201 The Dynamic CAR Discovery problem encompasses the areas outlined 202 in the box in Figure 2. 204 -------------------------------------------------------------- 205 | | 206 | PAARs identified by MN | 207 | | | 208 | | Capability identification by MN | 209 | | | 210 | v | 211 | CARs for MN's handoff identified at MN | 212 | | | 213 ---------------------------|---------------------------------- 214 | 215 | TAR selection by MN at the 216 | time of handoff 217 v 218 Unique TAR identity sent to current AR 220 Figure 2: Dynamic CAR Discovery Problem 222 3.3 Hybrid CAR Discovery 224 In practice, a hybrid of the above techniques for CAR discovery may 225 be used. In the hybrid approach, the partitioning of capability 226 information between the two techniques as well as the partitioning of 227 TAR selection process between the MN and the current AR is possible. 229 4. SPECIFIC ISSUES IN CAR DISCOVERY 231 The following sections describe the specific issues in the CAR 232 discovery, may it be done in anticipated, dynamic or hybrid way. 234 4.1 Identifying PAARs 236 A basic requirement for a new AR to be considered as a CAR for MN's 237 handoff is that the coverage area of the new AR be "physically 238 adjacent" to that of the AR currently serving the MN. In other words, 239 a new AR must be a PAAR. Note, the physical adjacency of the coverage 240 areas of two ARs is not necessarily implied by their "logical" 241 adjacency. Logical adjacency of two ARs means that there is just one 242 IP hop between the two ARs, while physical adjacency of two ARs 243 implies that the MN can actually move from the coverage area of one 244 AR to another. Conversely, PAARs need not be logically adjacent, and 245 may even have IP addresses in different administrative domains. 247 One approach is to manually configure this physical neighborhood at 248 each AR. However, such an approach has disadvantages and in many 249 cases, may not be feasible. For instance, two ARs that are physically 250 adjacent may be under different administrative control, and thus, are 251 not informed about each other's presence. Even within the same 252 administrative domain, the manual configuration approach demands much 253 network planning in terms of the coverage areas of different ARs. 254 Finally, the manual configuration approach is not suitable if the 255 routers can be physically relocated or their coverage area changed, 256 thus altering the physical adjacency of their coverage areas. Such a 257 scenario is very common when ARs are temporarily introduced in 258 hot spots. Clearly, a more automatic and dynamic mechanism is needed 259 that would allow an AR to discover physically adjacent ARs around 260 itself without much administrative intervention. 262 For the Anticipated CAR Discovery, the process of identifying PAARs 263 requires a protocol that allows ARs to exchange physical adjacency 264 information in advance of handoff. In Dynamic CAR Discovery, the MN 265 automatically serves as the judge of whether an AR is a PAAR. In the 266 latter case, if the MN can hear a Router Advertisement of the new AR, 267 then the new AR is PAAR. 269 4.2 Identifying capabilities of PAARs: 271 Although not common now, the future generation mobile networks may 272 consist of ARs that are physically adjacent, but are heterogeneous in 273 administrative control, function, capability, link layer technology 274 and resources. An MN that is attached to a given AR may have specific 275 requirements as regards these parameters. For example, the MN may 276 need some hardware or software support from the access router to run 277 certain IP-based applications. Support for QoS, security, multicast, 278 header compression etc. are some other aspects that need to be 279 considered when choosing the CAR for MN's handoff. It may also be 280 required to assure some security association or policy agreement 281 between the current AR and its physical neighbor in order to allow 282 MN's handoff between them. The various capabilities that need to be 283 identified in PAAR for smooth handoff are outside the scope of this 284 draft. However, as an illustration, the capabilities to be identified 285 may include administrative parameters such as ISP, organization and 286 policy information; cost of access parameters; information about 287 radio interfaces; information about availability of any application 288 logic such as multicast support, header compression capability, 289 playout buffer hosting for streaming applications, TCP PEPs and media 290 transcoding functionality; Internet connectivity parameters such as 291 need for NAT traversal; resource parameters such as load and so on. 293 In the Anticipated CAR Discovery, capability exchange between ARs 294 occurs over the Internet. Thus, a protocol is needed that would allow 295 ARs to exchange capability information. 297 In the Dynamic CAR Discovery approach, the MN is soliciting or 298 receiving the capabilities of PAARs directly. Some protocol is 299 required to allow the MN to solicit, or the ARs to advertise their 300 capabilities. 302 4.3 Security considerations 304 AR discovery may allow other nodes to learn the following pieces of 305 information about an AR: 307 - Physical location 308 - Capabilities 309 - State of capabilities. 311 Malicious nodes may use this kind of information to launch attacks of 312 the DoS-style and/or service hijacking. Therefore, the following 313 topics should be covered in any protocol developed for AR discovery: 315 - Authentication of nodes 316 - Security associations between nodes 317 - Message/payload encryption. 319 5. REFERENCES 321 [1] IP Mobility Support, C. Perkins (Editor), RFC 2002, October 1996. 323 [2] Mobility Support in IPv6, D. Johnson and C. Perkins, 324 draft-ietf-mobileip-ipv6-13.txt, 325 work in progress, November 2000. 327 [3] Low Latency Handoffs in Mobile IPv4, MIPv4 Handoffs Design Team, 328 draft-ietf-mobileip-lowlatency-handoffs-v4-00.txt, 329 work in progress, February 2001. 331 [4] Fast handoffs for Mobile IPv6, MIPv6 handoff Design Team, 332 draft-ietf-mobileip-fast-mipv6-01.txt, 333 work in progress, April 2001. 335 [5] Problem Description: Reasons For Performing Context Transfers 336 Between Nodes in an IP Access Network, O. H. Levkowetz et. al., 337 draft-ietf-seamoby-context-transfer-problem-stat-01.doc, 338 work in progress, May 2001. 340 [6] General requirements for a context transfer framework, H. Sayed 341 et. al., draft-ietf-seamoby-ct-reqs-00.txt, 342 work in progress, May 2001. 344 [7] Buffer Management for Smooth handoffs in Mobile IPv6, 345 G. Krishnamurthi, R. Chalmers, and C. Perkins, 346 draft-krishnamurthi-mobileip-buffer6-01.txt, 347 work in progress, March 2001. 349 6. AUTHORS' ADDRESS 351 Dirk Trossen 352 Communication Systems Laboratory, Nokia Research Center 353 5 Wayside Road 354 Burlington, MA 01803, USA 356 Phone: +1 781 993 3605 357 Fax: +1 781 993 1907 358 E-mail: dirk.trossen@nokia.com 360 Govind Krishnamurthi 361 Communication Systems Laboratory, Nokia Research Center 362 5 Wayside Road 363 Burlington, MA 01803, USA 365 Phone: +1 781 993 3627 366 Fax: +1 781 993 1907 367 E-mail: govind.krishnamurthi@nokia.com 369 Hemant Chaskar 370 Communication Systems Laboratory, Nokia Research Center 371 5 Wayside Road 372 Burlington, MA 01803, USA 374 Phone: +1 781 993 3785 375 Fax: +1 781 993 1907 376 E-mail: hemant.chaskar@nokia.com 378 James Kempf 379 Network and Security Research Center, Sun Labs 380 Sun Microsystems, Inc. 381 15 Network Circle 382 Menlo Park, CA 94025, USA 384 Phone: +1 650 786 5890 385 Fax: +1 650 786 6445 386 E-mail: james.kempf@eng.sun.com