idnits 2.17.1 draft-yousaf-ietf-network-mhdcar-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 734. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 711. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 718. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 724. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == Line 304 has weird spacing: '...ilities gets...' == Line 633 has weird spacing: '...le with each ...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 (April 23, 2008) is 5818 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) -- Looks like a reference, but probably isn't: 'AP-ID' on line 461 -- Looks like a reference, but probably isn't: 'AR-Info' on line 461 ** Downref: Normative reference to an Experimental RFC: RFC 4066 (ref. '1') ** Obsolete normative reference: RFC 3775 (ref. '2') (Obsoleted by RFC 6275) ** Obsolete normative reference: RFC 4068 (ref. '3') (Obsoleted by RFC 5268) -- Possible downref: Non-RFC (?) normative reference: ref. '4' -- Possible downref: Normative reference to a draft: ref. '5' -- Possible downref: Normative reference to a draft: ref. '6' -- Possible downref: Normative reference to a draft: ref. '7' ** Downref: Normative reference to an Experimental RFC: RFC 4065 (ref. '8') Summary: 6 errors (**), 0 flaws (~~), 4 warnings (==), 13 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group F. Z. Yousaf 2 Internet Draft C. Wietfeld 3 Intended status: Standards Track Communication Networks Institute, 4 Expires: October 2008 Dortmund University of Technology, 5 Germany. 6 April 23, 2008 8 Multi-Hop Discovery of Candidate Access Routers (MHD-CAR) 9 draft-yousaf-ietf-network-mhdcar-00.txt 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 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 32 http://www.ietf.org/shadow.html 34 This Internet-Draft will expire on October 23, 2008. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2008). 40 Abstract 42 The Candidate Access Router Discovery (CARD) protocol specified in 43 [1] is aimed to enable seamless IP layer handover by aiding seamless 44 Layer 3 (L3) mobility management protocols like Fast Mobile IP (FMIP) 45 by providing identity and capabilities information of the candidate 46 access routers (CARs) to the mobile node (MN) prior to the initiation 47 of handover while the MN is still connected to its current AR. 49 The specifications as laid down in [1], however, specifies a very 50 generic mechanism of the CARD protocol effective only in specific 51 network architecture scenarios and it doesn't take into account the 52 stringent requirements of a fast moving MN and real time 53 communication sessions, especially when it comes to resolving 54 candidate access routers that my be adjacent geographically but not 55 topologically. 57 This draft addresses the expected shortcomings of the base CARD 58 protocol with respect to fast moving MNs and real time communication 59 sessions by proposing extensions that is expected to improve and/or 60 enhance the performance of the generic CARD protocol as specified in 61 [1]. 63 Table of Contents 65 1. Requirements notation..........................................2 66 2. Introduction...................................................3 67 3. Terminology....................................................4 68 4. CARD Protocol Overview.........................................4 69 4.1. CARD Protocol Operation Summary...........................4 70 4.1.1. Centralized approach using a CARD Server.............6 71 4.1.2. Decentralized approach Using Mobile Node's Handover..6 72 4.2. Expected Issues Related to FMIPv6 with CARD...............7 73 5. Multi Hop Discovery of Candidate Access Router (MHD-CAR).......8 74 5.1. Access Router Operation...................................9 75 5.1.1. CAR Table Conceptual Design.........................10 76 5.2. Mobile Node Operation....................................11 77 5.3. New Access Network Cache Conceptual Design...............12 78 6. Security Considerations.......................................14 79 7. IANA Considerations...........................................14 80 8. Acknowledgments...............................................14 81 9. Normative References..........................................15 82 Author's Addresses...............................................16 83 Intellectual Property Statement..................................16 84 Disclaimer of Validity...........................................17 86 1. Requirements notation 88 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 89 SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 90 document are to be interpreted as described in [9]. 92 2. Introduction 94 Next generation network (NGN) is envisaged to be IP based composed of 95 heterogeneous wireless access network architecture catering to a 96 large number of mobile users with varied quality and service 97 requirements. 99 To accommodate the expected increase in mobile users' population and 100 mobile applications, mobility management protocols, both at the data 101 link layer and network layer are being developed and enhanced to 102 provide and optimum seamless handover to mobile entities. 104 In this respect, Mobile IPv6 (MIPv6) [2] is a L3 mobility management 105 protocol specified for IPv6 networks, as IPv6 is expected to be the 106 internetworking technology of choice due to its various inherent 107 advantages over its predecessor IPv4, but the delay and packet losses 108 incurred by MIPv6 makes it unsuitable to provide seamless handover to 109 mobile users, especially in terms of the stringent quality of service 110 requirements and demands of the NGN. 112 Fast-MIPv6 (FMIPv6) is an extension to the base MIPv6 protocol and 113 specified in [3] that is designed to overcome the inherent functional 114 deficiencies of MIPv6 in terms of providing seamless handover to 115 mobile nodes (MNs). 117 The operational philosophy behind F-MIPv6 is to perform delay 118 incurring sub-processes, such as movement detection and Care-of- 119 Address (CoA) configuration while the MN is still connected to its 120 current access router (AR) and just before it hands over its 121 connection the new AR (NAR). This is only possible if the MN is 122 provided with the identity (L2 and L3 addresses) and capabilities 123 (QoS and other related parameters) information of the candidate 124 access point (CAP) and its associated candidate AR (CAR) well in 125 advance and the degree of seamlessness provided by FMIPv6 is highly 126 dependent on the timely provisioning of the CAR information. 128 The protocol specifications of FMIPv6 does not specify the mechanics 129 of this advance retrieval of identity and capabilities information of 130 CAR(s) and/or selection algorithm of target AR (TAR), but instead it 131 relies on external protocols/algorithms to achieve this performance 132 target. 134 Candidate Access Router Discovery (CARD) is one such protocol [1] 135 that enables a MN to discover and acquire the identity and/or 136 capabilities information of CAR(s) prior to the initiation of 137 handover while it is still connected to its current AR. The problem 138 statement of CAR discovery is documented in [4]. 140 Although specified as a separate protocol, the CARD protocol can be 141 easily integrated into the FMIPv6 protocol framework. 143 The CARD protocol is based on the exchange of a pair of Request/Reply 144 messages between the MN and AR and between AR and AR, every time a MN 145 detects a L2 ID(s) of new in-range AP(s) during link layer scan. 147 Although an effective strategy, but owing to the frequent exchange of 148 CARD messages during every handover instance, it is expected that the 149 base CARD protocol may not scale well for fast moving MNs (moving at 150 vehicular velocities) in terms of signaling load and timely provision 151 of CAR(s) information; thereby adversely impacting the degree of 152 seamlessness provided by mobility management protocols like FMIPv6 153 and any TAR selection algorithm(s). 155 This draft document specifies a mechanism by virtue of which a MN 156 will be able to discover and acquire the identity and capabilities 157 information of CAR(s) "multiple link-hops" away from the current AR 158 incurring minimum signaling load, especially over the wireless link 159 (MN-AR CARD Request/Reply Messages). This mechanism utilizes the 160 original CARD messages with minor modifications and is expected to 161 enhance the performance of the base CARD protocol and thus improve 162 the degree of seamlessness provided by fast handover protocols like 163 FMIPv6. 165 Although MHD-CAR does not introduce any new messages but it proposes 166 changes to the way the CAR Table information is managed and 167 exchanged, besides introducing a new data structure called "New 168 Access Network (NAN) Cache, which is managed and maintained inside 169 the MN. 171 3. Terminology 173 This document refers to [1] and [3] for terminology. The following 174 terms and abbreviations are additionally used in this document. 176 New Access Network (NAN) Cache: 178 A cache maintained by the MN containing identity and capabilities 179 and distance information of the candidate ARs and candidate APs. 181 4. CARD Protocol Overview 183 4.1. CARD Protocol Operation Summary 185 The CARD protocol specifications [1] provides a generic mechanism 186 that allows MNs to resolve the L2 IDs of one or more in-range APs, 187 typically discovered during a scan operation by the MN, to the IP 188 addresses, and additionally the capabilities, of the associated CARs. 190 This reverse address translation is carried out by the MN 191 transmitting a MN-AR CARD Request message towards its current AR, 192 which will resolve the L2 IDs of the discovered AP(s), carried by the 193 received request message, to the corresponding CAR's IP addresses by 194 consulting its local CAR Table. 196 The current AR, after performing reverse address translation and 197 capabilities discovery, will respond by sending a corresponding MN-AR 198 CARD Reply message back to the MN, informing the MN of the resolved 199 CAR(s) IP address(es) and its capabilities. This discovery and 200 acquisition of the CAR(s) identity and capabilities information may 201 be used by the MN to perform TAR selection and/or aid the MN to 202 execute some L3 related handover functions in advance. 204 The CARD protocol provides for the piggybacking of the CARD messages 205 on fast handover protocol messages. 207 The CAR Table is fundamental for performing reverse address 208 translation and capabilities discovery. The CAR Table is a L2-L3 209 address mapping table maintained by each AR. The CAR Table is also 210 provisioned to maintain the capability information of CARs, which is 211 updated periodically depending on the timeout expiry of a capability 212 parameter(s) lifetime or a change in its state and/or value. The CARs 213 also maintains their own AP-to-AR mappings and capability information 214 in the local CAR Tables, in order to aid newly booted MNs to obtain 215 AR'S certification path. The detailed description of the CAR Tables 216 and its entries are not given in the CARD protocol specifications. 218 The CARD specification also suggests and recommends that a MN SHOULD 219 also maintain discovered address and capability information of the 220 local CARs in a local cache to avoid requesting the same information 221 repeatedly and to select an appropriate TAR from the list of CARs as 222 quickly as possible when a handover is imminent. However the 223 conceptual design and management principle of such a local cache is 224 not part of the official CARD specifications. 226 The maintenance of the CAR Table and its efficient dissemination is 227 the key stone to CARD operational capabilities. The CAR Table can be 228 configured statically but that is most inefficient. In this respect 229 the CARD protocol proposes two approaches for the maintenance of the 230 CAR Tables in the ARs which are summarized below. 232 4.1.1. Centralized approach using a CARD Server 234 The centralized approach uses a CARD Server entity that assists the 235 current AR in performing reverse address translation. This 236 centralized approach requires the "neighboring ARs" to register their 237 identities with the CARD server to populate the reverse address 238 translation table prior to the initiation of any reverse address 239 translation, preferably during a CAR boot up time. When the current 240 AR is unable to resolve a L2 ID as requested by a MN, it will query 241 the CARD server using a AR-Server Request message. In response the 242 CARD server will return the IP address of the resolved CAR and the 243 current AR will also update its local CAR Table for subsequent 244 requests. The current AR will then directly contact the CAR and 245 perform capabilities discovery with it. The initial idea was 246 presented in [5] 248 The drawback of this approach however is that additional messages 249 (AR-Server Request and AR-Server Reply) are introduced and the CARD 250 server entity introduces a single point of failure in the network. 251 Also it may not be able to resolve CAR(s) which may belong to some 252 different administrator domain, in which case CARD will fail to 253 resolve the CAR and FMIPv6 protocol will not function. 255 4.1.2. Decentralized approach Using Mobile Node's Handover 257 The decentralized approach makes use of a mobile terminal's handover. 258 The main idea behind this approach is to bootstrap and maintain the 259 association between two neighboring ARs, with overlapping coverage 260 area, by using the first handover of a MN occurring between them. 261 Subsequent handovers of other MNs will serve to refresh the 262 association between the neighboring ARs. 264 During the handover, the MN will send a "Router Identity message" to 265 its current AR containing the IP address of the previous AR. This 266 message will allow the current AR to add or update an entry for the 267 previous AR as its neighbor. As a security measure, a reception of a 268 Router Identity message will trigger the current AR to send an AR-AR 269 message to the previous AR containing the IP address of the MN in 270 order to verify its identity. Upon receiving a positive verification, 271 both the neighboring ARs will update their local CAR tables with each 272 others identity and capabilities information using the normal AR-AR 273 CARD Request/Reply messages. This approach was presented in [6] and 274 [7]. 276 The drawback of this approach however is the introduction of a new 277 message (router identity message) and increase in signaling load over 278 the air link and between ARs and the first MN missing on the 279 advantages offered by seamless handover protocol. Since Router 280 Identity Message is exchanged over the air link, in case of lossy air 281 links or collision the ARs will not be able to maintain credible 282 information. 284 4.2. Expected Issues Related to FMIPv6 with CARD 286 FMIPv6 is designed to provide seamless and fast handover to MNs, but 287 the degree of seamlessness depends on the efficiency of CARD protocol 288 and its ability to resolve the CAR(s) identity and/or capabilities 289 information well in advance and with minimum delay and signaling 290 overhead. 292 FMIPv6 protocol provides two handover modes [3] depending on whether 293 the Fast Binding Acknowledgement (FBAck) message is received by the 294 MN on the previous/current AR's (PAR) link or next/new AR's (NAR) 295 link. In the former case the handover mode is termed "predictive" and 296 in the latter case the handover mode is termed "reactive". 298 Of the two handover modes the predictive mode is more relevant in 299 terms of the CARD protocol because in this mode the MN is able to 300 resolve the CAR information while it is still connected to PAR, but 301 for high speed MNs, it is highly likely that during the address 302 resolution and/or capabilities discovery delay incurred by CARD, the 303 MN may move out of the range of the current AR and perform L2 304 handover with NAR before the NAR identity and/or capabilities gets 305 resolved, and the MN undergoes reactive handover mode, in which case 306 CARD protocol is rendered irrelevant. Reactive handover may account 307 for packet losses for the duration when the MN sends a Fast Binding 308 Update (FBU) towards its current AR from the NAR's link and till a 309 reverse tunnel is not established between PAR and NAR. 311 In case the PAR is unable to resolve the identity of the NAR, the MN 312 will not undergo FMIPv6 handover but revert to MIPv6 handover 313 incurring a higher handover delay associated with MIPv6. 315 Since the CARD protocol is triggered every time a MN receives L2 IDs 316 from in-range APs, this may not be feasible especially for fast 317 moving MNs, because the MN is usually able to listen to neighboring 318 APs when it is almost on the edge of the coverage area of its current 319 AP and, depending on the area of overlap region, it is possible that 320 the MN may move out of the coverage area of the current AP before it 321 has resolved the NAR identity. 323 Fast moving MNs undergo a higher frequency of handover and thus CARD 324 protocol is initiated every time a MN is about to handover to a CAR, 325 thus incurring higher signaling load, especially the MN-AR CARD 326 Request/Reply messages. Since the MN-AR CARD Request/Reply message 327 pair is exchanged over wireless link, they are more error prone than 328 the AR-AR CARD Request/Reply message pair. This may not be suitable 329 for fast moving MNs and/or real time communication sessions, as there 330 is not enough time for retransmissions before a MN moves out of the 331 coverage area of the current AP as explained above. 333 The evident shortcomings of the CARD protocol with respect to fast 334 moving MNs and real time applications are expected to be rectified by 335 empowering the MN to perform reverse address translation and/or 336 capabilities discovery of CAR(s) that may be multiple link-hops away 337 with minimum reliance on current AR and with minimum exchange of MN- 338 AR CARD Request/Reply message pair. This is achieved by Multi Hop 339 Discovery of Candidate Access Router (MHD-CAR) protocol as discussed 340 and detailed in the next sections. 342 5. Multi Hop Discovery of Candidate Access Router (MHD-CAR) 344 MHD-CAR is a protocol aimed at enabling a MN to resolve the identity 345 and capabilities information of CAR(s) that may be geographically 346 adjacent but topologically it may be multiple hops away from the 347 current AR. 349 One of the main feature of MHD-CAR is the ability of the AR's to 350 dynamically update their local CAR Table with the identity 351 information of not only the neighboring ARs but also CARs located 352 multiple hops away. The MHD-CAR operation does not require 353 maintaining and/or managing a CARD Server or using a MN's handover to 354 bootstrap and refresh the CAR Table of an AR. Instead each AR will 355 maintain a snap-shot of the network around it in its local CAR Table. 356 This CAR Table is dynamically configured at the initialization of the 357 AR and is refreshed routinely. 359 Also MHD-CAR requires a MN to maintain a local cache called "New 360 Access Network (NAN) Cache", the information content of which enables 361 a MN to resolve a CAR with minimum reliance on MN-AR CARD 362 Request/Reply messages, thereby decreasing the signaling load, 363 especially over the wireless link and attaining signaling and timing 364 efficiency that may contribute towards improving the probability of a 365 fast moving MN to undergo a Predictive FMIPv6 handover. 367 This distributed approach of MHD-CAR provides a highly scalable, 368 efficient and fault tolerant mechanism by overcoming the inherent 369 shortcomings of the CARD protocol as explained in the previous 370 sections. 372 The MHD-CAR does not introduce any new protocol messages and utilizes 373 the CARD Request/Reply messages. 375 It proposes changes to the way the CAR Table information is managed 376 and exchanged, besides introducing a new data structure called "New 377 Access Network (NAN) Cache, which is maintained inside the MN. 379 The combination of CAR Table and NAN Cache and their management 380 brings the main advantages of MHD-CAR. 382 The functional details of the MHD-CAR are discussed in the subsequent 383 sections. 385 5.1. Access Router Operation 387 As specified in [1], the AR MUST maintain a CAR Table, which is a L2- 388 L3 address mapping table. The arrangement and composition of the CAR 389 Table in MHD-CAR is different from what is suggested in [1] and the 390 details of the CAR Table are elaborated in section 3.1.1. 392 MHD-CAR introduces a parameter, besides many others discussed in 393 section 3.1.1, called 'Distance' in the CAR Table which is a measure 394 of the distance of a CAR, in terms of the number of link-hops, from 395 the local AR which is maintaining the CAR Table. 397 ARs exchange their CAR Table information with their neighboring ARs 398 using AR-AR CARD Request/Reply message pair [1]. Each AR-AR CARD 399 Reply message will carry the CAR Table information of the source AR 400 in the capability container message sub-option. 402 The exchange of CAR Table information with the neighboring ARs takes 403 place with the iterative exchange of unsolicited AR-AR Reply message, 404 where the number of iterations is equal to the specified maximum 405 distance for which the ARs are supposed to maintain the CAR Table. 407 At initialization, each AR will populate its CAR Table with its own 408 identity and capabilities information and set the 'Distance' 409 parameter to zero. The 'Distance' of zero indicates local AR 410 information. Each AR will then exchange its local CAR Table entries 411 with its neighboring ARs using unsolicited AR-AR CARD Reply Message. 413 In the first iteration, the ARs will exchange their local [AP-ID, AR- 414 Information] tuples, and optionally capabilities information, with 415 their neighboring ARs, which will add this new information to their 416 local CAR Tables and increment the 'Distance' by 1. Now each AR will 417 have AR information about their neighboring ARs and this will be 418 indicated by the 'Distance' value of 1, meaning that the neighboring 419 ARs are at a distance of one link-hop away. 421 This new update of the local CAR Tables will prompt the ARs to start 422 the second iteration at random times of sending unsolicited AR-AR 423 Reply messages which will contain the updated new CAR Table 424 information in the capability container sub-option. The receiving ARs 425 will compare the new information with the present CAR Table entries 426 and if no match is found, will add the new CAR information to its 427 local CAR Table by incrementing the distance parameter of all 428 received entries by 1. This new entry will thus be stored in the 429 local CAR Table with the 'Distance' value of 2, indicating that the 430 relevant CAR is at distance of two link-hops away. 432 This new update of the local CAR Tables will prompt the ARs to start 433 the third iteration and this iterative exchange of local CAR Table 434 information with the neighboring ARs will continue until each AR has 435 the information about CAR which is MAXIMUM_DISTANCE_LIMIT away. The 436 value of the MAXIMUM_DISTANCE LIMIT is a constant that depends on the 437 network topology and can be specified by the administrator. How ever 438 the optimum value of the MAXIMUM_DISTANCE LIMIT constant is under 439 investigation. 441 After the MAXIMUM_DISTANCE_LIMIT iterative exchange of unsolicited 442 AR-AR Reply massages, the CAR Tables will converge. It should be 443 noted that the CAR information (identity and capabilities) are 444 carried in the capabilities container sub-option along with the 445 'Distance' information, and the AR-AR messages are only exchanged 446 with their neighbors and ARs are not supposed to forward this 447 message, or else the network can get flooded with these messages. 449 After the convergence of CAR Tables that happens during the ARs 450 initialization/bootup stage, the AR can send out an unsolicited AR-AR 451 Reply message if there is any change in its capabilities or identity 452 information or if a lifetime value of an entry expires, which will 453 again be iteratively distributed amongst ARs MAXIMUM_DISTANCE_LIMIT 454 away. It is expected that the CAR Tables will converge with minimum 455 time without producing excessive traffic on the network links, where 456 the time of convergence is a function of MAXIMUM_DIST_LIMIT. 458 5.1.1. CAR Table Conceptual Design 460 As specified in [1] each AR must maintain a CAR Table which is a L2- 461 L3 address mapping table maintaining a [AP-ID, AR-Info] tuple. The 462 AP-ID mainly contains the address of the AP connected to the router, 463 whereas the AR-Info is the router's valid L2 address, IP address and 464 prefix of the interface to which the AP is connected to. 466 However MHD-CAR proposes additional parameters to the CAR Table. 468 The parameters defined for the AP-ID field are as follows: 470 o L2 ID: The L2 ID of the CAP associated with the corresponding CAR. 471 Usually the 6 Byte MAC Address of the CAP. 473 o L2 Type: Determines the type of access technology (i.e, WiAMX, 474 WLAN, CDMA, UMTS, GPRS, etc,). 476 o Channel Number: The channel/frequency of the CAP. 478 o SNR (RSSI): The SNR (or RSSI) of the received beacon. 480 The parameters defined for the AR-Info field are as follows: 482 o IP Address: The valid IP address (IPv4 or IPv6) of the interface 483 to which the AP is connected to. 485 o IP Prefix: The prefix of the IP address of the interface to which 486 the AP is connected to. 488 o Prefix Length: The prefix length of the IP address of the 489 interface to which the AP is connected to. 491 MHD-CAR introduces the capability container to the CAR Table and the 492 following parameters are defined for it: 494 o Bitrate: The bit rate supported by the CAP. 496 o SSID: The identity of the CAP. 498 o Distance: The distance of the CAR/CAP from the current AR in terms 499 of link-hops. 501 5.2. Mobile Node Operation 503 The CARD specification [1] proposes that a MN SHOULD maintain 504 discovered address and capability information of CARS in a local 505 cache to avoid requesting the same information repeatedly and to 506 select an appropriate target AR from list of CARs as quickly as 507 possible when a handover is imminent, but this proposal will only 508 quicken the CAR selection if the MN has visited that CAR domain 509 previously, whereas it is very much unlikely for a fast moving user 510 to revisit a previously visited CAR domain before the corresponding 511 entry times out. The conceptual design and arrangement of this local 512 cache however is not specified in [1]. 514 In MHD-CAR the MN MUST maintain a local cache, called "New Access 515 Network (NAN)" cache. The NAN cache maintains information of the CARs 516 that will aid the MN in selecting the appropriate CAR for handing 517 over its connection to, when the handover is imminent. The 518 information contents of the NAN cache is derived mostly from the CAR 519 Table that is either "pushed" in the MN by the current AR, or either 520 "pulled" by the MN from its current AR. The NAN cache also derives 521 some of the information contents from the beacon messages received 522 from the in-range wireless APs. 524 The MN can "Pull" the CARD Table from the current AR by sending a 525 wildcard MN-AR CARD Request Message, in response to which the current 526 AR will append the necessary CAR(s) information in the various sub- 527 options of the MN-AR CARD Reply Message. On the other hand the 528 current AR upon sensing the connection of the MN to itself will send 529 an unsolicited MN-AR CARD Reply Message containing the CAR(s) 530 information appended as various sub-options. Whether the CAR 531 information is pulled by or pushed in the MN, the MN will add and/or 532 refresh the relevant entries of its NAN Cache based on the 533 information provided by the MN-AR CARD Reply Message. 535 The NAN Cache will contain the identity and capabilities information 536 of not only the neighboring CAR(s) but of CAR(s) 537 MAXIMUM_DISTANCE_LIMIT away from the current AR. This will allow the 538 MN to perform reverse address translation and capability discovery 539 without the exchange of MN-AR CARD Request/Reply message pair 540 whenever handover is imminent. This will not only reduce the 541 signaling load over the wireless link and improve the probability of 542 resolving a CAR but also reduce the delay incurred due to reverse 543 address translation and capability discovery procedure being carried 544 out locally within the MN without having to perform signal exchange 545 with the AR. 547 Besides relying on MN-AR Card Reply message for keeping it up to 548 date, the NAN Cache will also depend on the L2 information that it 549 receives periodically in the form of beacons from in-range wireless 550 APs. The NAN Cache in essence is a repository that maintains both L2 551 and L3 information regarding CAR(s). The information content of the 552 NAN Cache will be used by the MN to enhance the performance of both 553 L2 and L3 mobility management mechanisms and thus potentially lays 554 the foundation of a cross-layer mobility management schemes. 556 5.3. New Access Network Cache Conceptual Design 558 The information in the NAN Cache is keyed by the L2 ID(s) that the MN 559 receives from the beacon signals of the in-range CAPs. The NAN Cache 560 entries provide information that can also potentially aid TAR 561 selection algorithms. 563 The proposed NAN Cache is composed, but not limited to, the following 564 parameters/fields for every CAR: 566 o Reachability Status: Indicates whether a MN is reachable 567 (attached) to the AP signified by the particular NAN Cache entry. 569 o Context ID: A context id used to match the information exchange 570 between correct CARD Request/Reply message pair. 572 o L2 Type: Determines the type of access technology (i.e, WiMAX, 573 WLAN, CDMA, UMTS, GPRS, etc,). 575 o L2 ID: The L2 ID of the CAP associated with the corresponding CAR. 576 Usually the 6 Byte MAC Address of the CAP. 578 o SSID: SSID of the CAP 580 o Bit Rate: The bit rate supported by the CAP. 582 o Channel Number: The channel number/frequency of the CAP. This 583 entry can be used by selective frequency scanning algorithms to 584 reduce the latency due to scanning delay (For example Probe delay 585 in 802.11 networks). 587 o SNR: The signal to Noise ratio of the CAP. This entry continues to 588 get updated with every received beacon. Can be potentially used to 589 determine the appropriate time of initiating handover with the 590 next CAP/CAR. 592 o Receive Power: Receive power of the CAP. This entry continues to 593 get updated with every received beacon. Potentially used to 594 determine the direction of movement of the MN relative to the 595 "reachable" AP and/or CAP. Also aid in the decision to select the 596 appropriate Target AR (TAR) to handover to. 598 o First Beacon Timestamp: The time a beacon was received from the AP 599 to which this entry belongs. 601 o Last Beacon Timestamp: Records the time stamp of the latest beacon 602 received for the corresponding CAP/CAR. This entry continues to 603 get updated with every received beacon. The information for 604 maintaining the timestamp of the beacons for the corresponding CAP 605 will allow the MN to determine the dwell time and the period for 606 which it remains in the range of a particular CAP. 608 o IP Address Type: Indicates whether the CAR identity information is 609 based on IPv4 or IPv6. 611 o IP Address: The IP address of the interface of the CAR which is 612 connected to the CAP. Its size is 32 bits in case of IPv4 and 128 613 bits in case of IPv6. Used internally 615 o IP Address Prefix: The prefix of the CAR's IP Address. 617 o IP Address Prefix Length: The prefix length of the IP Address. 618 Stored as an integer. 620 o Capability Container: A data structure that contains the 621 capability information, such as QoS parameters and buffer size of 622 the corresponding CAR. 624 The information content of NAN Cache also improves the performance of 625 the L2 handover by aiding selective frequency scanning and thus 626 provides both L2 and L3 information for a combined efficient and a 627 true cross layer mobility management solution. 629 The AR receiving an unsolicited AR-AR CARD Reply message will add or 630 update its local CAR Table with the information contained in the 631 capability container sub-option, and will increment the 'Distance' 632 field for each new received entry by 1. The ARs will continue this 633 inter exchange of their CAR Table with each other through 634 unsolicited AR-AR CARD Reply messages until the CAR Tables converge. 636 The CAR Tables will converge with several inter-exchanges of the 637 AR_AR Reply messages during boot up time as described previously. 639 6. Security Considerations 641 Security issues for this document follow those for CARD protocol. 643 7. IANA Considerations 645 See [8] for instructions on IANA allocation 647 8. Acknowledgments 649 This document was prepared using 2-Word-v2.0.template.dot. 651 9. Normative References 653 [1] M. Liebsch, A. Singh, H. Chaskar, D. Funato, "Candidate Access 654 Router Discovery (CARD)", RFC 4066, July 2005. 656 [2] Johnson, D., "Mobility Support in IPv6", RFC 3775, June 2004. 658 [3] Koodli, R., Ed., "Fast Handover for Mobile IPv6", RFC 4068, 659 July 2005. 661 [4] Trossen, D., Krishanmurthi, G. Chaskar, H., Kempf, J., "Issues 662 in candidate access router discovery for seamless IP-level 663 handoffs", Work in Progress. 665 [5] D. Funato et al., Geographically Adjacent Access Router 666 Discovery Protocol, Internet draft, draft-funato-seamoby-gaard- 667 01.txt, June 2002. 669 [6] Shim, E. and R. Gitlin, "Fast Handoff Using Neighbor 670 Information", Internet Draft, draft-shim-mobileip-neighbor- 671 00.txt, November 2000. 673 [7] Trossen, D., et al., "A Dynamic Protocol for Candidate Access- 674 Router Discovery", Internet draft, draft-trossen-seamoby- 675 dycard-01.txt, March 2003. 677 [8] J. Kempf, ``Instructions for Seamoby and Experimental Mobility 678 Protocol IANA Allocations," RFC 4065, Internet Engineering Task 679 Force, June 2004. 681 [9] Bradner, S., "Key words for use in RFCs to Indicate Requirement 682 Levels", BCP 14, RFC 2119, March 1997. 684 Author's Addresses 686 Faqir Zarrar Yousaf, 687 Communication Networks Institute 688 University of Dortmund 689 Otto-Hahn-Str. 6, 690 D-44227 Dortmund, Germany 692 Email: faqir.yousaf@tu-dortmund.de 694 Christian Wietfeld, 695 Communication Networks Institute 696 University of Dortmund 697 Otto-Hahn-Str. 6, 698 D-44227 Dortmund, Germany 700 Email: christian.wietfeld@tu-dortmund.de 702 Intellectual Property Statement 704 The IETF takes no position regarding the validity or scope of any 705 Intellectual Property Rights or other rights that might be claimed to 706 pertain to the implementation or use of the technology described in 707 this document or the extent to which any license under such rights 708 might or might not be available; nor does it represent that it has 709 made any independent effort to identify any such rights. Information 710 on the procedures with respect to rights in RFC documents can be 711 found in BCP 78 and BCP 79. 713 Copies of IPR disclosures made to the IETF Secretariat and any 714 assurances of licenses to be made available, or the result of an 715 attempt made to obtain a general license or permission for the use of 716 such proprietary rights by implementers or users of this 717 specification can be obtained from the IETF on-line IPR repository at 718 http://www.ietf.org/ipr. 720 The IETF invites any interested party to bring to its attention any 721 copyrights, patents or patent applications, or other proprietary 722 rights that may cover technology that may be required to implement 723 this standard. Please address the information to the IETF at 724 ietf-ipr@ietf.org. 726 Disclaimer of Validity 728 This document and the information contained herein are provided on an 729 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 730 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 731 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 732 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 733 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 734 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 736 Copyright Statement 738 Copyright (C) The IETF Trust (2008). 740 This document is subject to the rights, licenses and restrictions 741 contained in BCP 78, and except as set forth therein, the authors 742 retain all their rights. 744 Acknowledgment 746 Funding for the RFC Editor function is currently provided by the 747 Internet Society.