Network Working Group F. Z. Yousaf Internet Draft C. Wietfeld Intended status: Standards Track Communication Networks Institute, Expires: October 2008 Dortmund University of Technology, Germany. April 23, 2008 Multi-Hop Discovery of Candidate Access Routers (MHD-CAR) draft-yousaf-ietf-network-mhdcar-00.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on October 23, 2008. Copyright Notice Copyright (C) The IETF Trust (2008). Abstract The Candidate Access Router Discovery (CARD) protocol specified in [1] is aimed to enable seamless IP layer handover by aiding seamless Layer 3 (L3) mobility management protocols like Fast Mobile IP (FMIP) by providing identity and capabilities information of the candidate access routers (CARs) to the mobile node (MN) prior to the initiation of handover while the MN is still connected to its current AR. Yousaf & Wietfeld Expires October 23, 2008 [Page 1] Internet-Draft Multi-Hop Discovery of CARs April 2008 The specifications as laid down in [1], however, specifies a very generic mechanism of the CARD protocol effective only in specific network architecture scenarios and it doesn't take into account the stringent requirements of a fast moving MN and real time communication sessions, especially when it comes to resolving candidate access routers that my be adjacent geographically but not topologically. This draft addresses the expected shortcomings of the base CARD protocol with respect to fast moving MNs and real time communication sessions by proposing extensions that is expected to improve and/or enhance the performance of the generic CARD protocol as specified in [1]. Table of Contents 1. Requirements notation..........................................2 2. Introduction...................................................3 3. Terminology....................................................4 4. CARD Protocol Overview.........................................4 4.1. CARD Protocol Operation Summary...........................4 4.1.1. Centralized approach using a CARD Server.............6 4.1.2. Decentralized approach Using Mobile Node's Handover..6 4.2. Expected Issues Related to FMIPv6 with CARD...............7 5. Multi Hop Discovery of Candidate Access Router (MHD-CAR).......8 5.1. Access Router Operation...................................9 5.1.1. CAR Table Conceptual Design.........................10 5.2. Mobile Node Operation....................................11 5.3. New Access Network Cache Conceptual Design...............12 6. Security Considerations.......................................14 7. IANA Considerations...........................................14 8. Acknowledgments...............................................14 9. Normative References..........................................15 Author's Addresses...............................................16 Intellectual Property Statement..................................16 Disclaimer of Validity...........................................17 1. Requirements notation The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [9]. Yousaf & Wietfeld Expires October 23, 2008 [Page 2] Internet-Draft Multi-Hop Discovery of CARs April 2008 2. Introduction Next generation network (NGN) is envisaged to be IP based composed of heterogeneous wireless access network architecture catering to a large number of mobile users with varied quality and service requirements. To accommodate the expected increase in mobile users' population and mobile applications, mobility management protocols, both at the data link layer and network layer are being developed and enhanced to provide and optimum seamless handover to mobile entities. In this respect, Mobile IPv6 (MIPv6) [2] is a L3 mobility management protocol specified for IPv6 networks, as IPv6 is expected to be the internetworking technology of choice due to its various inherent advantages over its predecessor IPv4, but the delay and packet losses incurred by MIPv6 makes it unsuitable to provide seamless handover to mobile users, especially in terms of the stringent quality of service requirements and demands of the NGN. Fast-MIPv6 (FMIPv6) is an extension to the base MIPv6 protocol and specified in [3] that is designed to overcome the inherent functional deficiencies of MIPv6 in terms of providing seamless handover to mobile nodes (MNs). The operational philosophy behind F-MIPv6 is to perform delay incurring sub-processes, such as movement detection and Care-of- Address (CoA) configuration while the MN is still connected to its current access router (AR) and just before it hands over its connection the new AR (NAR). This is only possible if the MN is provided with the identity (L2 and L3 addresses) and capabilities (QoS and other related parameters) information of the candidate access point (CAP) and its associated candidate AR (CAR) well in advance and the degree of seamlessness provided by FMIPv6 is highly dependent on the timely provisioning of the CAR information. The protocol specifications of FMIPv6 does not specify the mechanics of this advance retrieval of identity and capabilities information of CAR(s) and/or selection algorithm of target AR (TAR), but instead it relies on external protocols/algorithms to achieve this performance target. Candidate Access Router Discovery (CARD) is one such protocol [1] that enables a MN to discover and acquire the identity and/or capabilities information of CAR(s) prior to the initiation of handover while it is still connected to its current AR. The problem statement of CAR discovery is documented in [4]. Yousaf & Wietfeld Expires October 23, 2008 [Page 3] Internet-Draft Multi-Hop Discovery of CARs April 2008 Although specified as a separate protocol, the CARD protocol can be easily integrated into the FMIPv6 protocol framework. The CARD protocol is based on the exchange of a pair of Request/Reply messages between the MN and AR and between AR and AR, every time a MN detects a L2 ID(s) of new in-range AP(s) during link layer scan. Although an effective strategy, but owing to the frequent exchange of CARD messages during every handover instance, it is expected that the base CARD protocol may not scale well for fast moving MNs (moving at vehicular velocities) in terms of signaling load and timely provision of CAR(s) information; thereby adversely impacting the degree of seamlessness provided by mobility management protocols like FMIPv6 and any TAR selection algorithm(s). This draft document specifies a mechanism by virtue of which a MN will be able to discover and acquire the identity and capabilities information of CAR(s) "multiple link-hops" away from the current AR incurring minimum signaling load, especially over the wireless link (MN-AR CARD Request/Reply Messages). This mechanism utilizes the original CARD messages with minor modifications and is expected to enhance the performance of the base CARD protocol and thus improve the degree of seamlessness provided by fast handover protocols like FMIPv6. Although MHD-CAR does not introduce any new messages but it proposes changes to the way the CAR Table information is managed and exchanged, besides introducing a new data structure called "New Access Network (NAN) Cache, which is managed and maintained inside the MN. 3. Terminology This document refers to [1] and [3] for terminology. The following terms and abbreviations are additionally used in this document. New Access Network (NAN) Cache: A cache maintained by the MN containing identity and capabilities and distance information of the candidate ARs and candidate APs. 4. CARD Protocol Overview 4.1. CARD Protocol Operation Summary The CARD protocol specifications [1] provides a generic mechanism that allows MNs to resolve the L2 IDs of one or more in-range APs, Yousaf & Wietfeld Expires October 23, 2008 [Page 4] Internet-Draft Multi-Hop Discovery of CARs April 2008 typically discovered during a scan operation by the MN, to the IP addresses, and additionally the capabilities, of the associated CARs. This reverse address translation is carried out by the MN transmitting a MN-AR CARD Request message towards its current AR, which will resolve the L2 IDs of the discovered AP(s), carried by the received request message, to the corresponding CAR's IP addresses by consulting its local CAR Table. The current AR, after performing reverse address translation and capabilities discovery, will respond by sending a corresponding MN-AR CARD Reply message back to the MN, informing the MN of the resolved CAR(s) IP address(es) and its capabilities. This discovery and acquisition of the CAR(s) identity and capabilities information may be used by the MN to perform TAR selection and/or aid the MN to execute some L3 related handover functions in advance. The CARD protocol provides for the piggybacking of the CARD messages on fast handover protocol messages. The CAR Table is fundamental for performing reverse address translation and capabilities discovery. The CAR Table is a L2-L3 address mapping table maintained by each AR. The CAR Table is also provisioned to maintain the capability information of CARs, which is updated periodically depending on the timeout expiry of a capability parameter(s) lifetime or a change in its state and/or value. The CARs also maintains their own AP-to-AR mappings and capability information in the local CAR Tables, in order to aid newly booted MNs to obtain AR'S certification path. The detailed description of the CAR Tables and its entries are not given in the CARD protocol specifications. The CARD specification also suggests and recommends that a MN SHOULD also maintain discovered address and capability information of the local CARs in a local cache to avoid requesting the same information repeatedly and to select an appropriate TAR from the list of CARs as quickly as possible when a handover is imminent. However the conceptual design and management principle of such a local cache is not part of the official CARD specifications. The maintenance of the CAR Table and its efficient dissemination is the key stone to CARD operational capabilities. The CAR Table can be configured statically but that is most inefficient. In this respect the CARD protocol proposes two approaches for the maintenance of the CAR Tables in the ARs which are summarized below. Yousaf & Wietfeld Expires October 23, 2008 [Page 5] Internet-Draft Multi-Hop Discovery of CARs April 2008 4.1.1. Centralized approach using a CARD Server The centralized approach uses a CARD Server entity that assists the current AR in performing reverse address translation. This centralized approach requires the "neighboring ARs" to register their identities with the CARD server to populate the reverse address translation table prior to the initiation of any reverse address translation, preferably during a CAR boot up time. When the current AR is unable to resolve a L2 ID as requested by a MN, it will query the CARD server using a AR-Server Request message. In response the CARD server will return the IP address of the resolved CAR and the current AR will also update its local CAR Table for subsequent requests. The current AR will then directly contact the CAR and perform capabilities discovery with it. The initial idea was presented in [5] The drawback of this approach however is that additional messages (AR-Server Request and AR-Server Reply) are introduced and the CARD server entity introduces a single point of failure in the network. Also it may not be able to resolve CAR(s) which may belong to some different administrator domain, in which case CARD will fail to resolve the CAR and FMIPv6 protocol will not function. 4.1.2. Decentralized approach Using Mobile Node's Handover The decentralized approach makes use of a mobile terminal's handover. The main idea behind this approach is to bootstrap and maintain the association between two neighboring ARs, with overlapping coverage area, by using the first handover of a MN occurring between them. Subsequent handovers of other MNs will serve to refresh the association between the neighboring ARs. During the handover, the MN will send a "Router Identity message" to its current AR containing the IP address of the previous AR. This message will allow the current AR to add or update an entry for the previous AR as its neighbor. As a security measure, a reception of a Router Identity message will trigger the current AR to send an AR-AR message to the previous AR containing the IP address of the MN in order to verify its identity. Upon receiving a positive verification, both the neighboring ARs will update their local CAR tables with each others identity and capabilities information using the normal AR-AR CARD Request/Reply messages. This approach was presented in [6] and [7]. The drawback of this approach however is the introduction of a new message (router identity message) and increase in signaling load over the air link and between ARs and the first MN missing on the Yousaf & Wietfeld Expires October 23, 2008 [Page 6] Internet-Draft Multi-Hop Discovery of CARs April 2008 advantages offered by seamless handover protocol. Since Router Identity Message is exchanged over the air link, in case of lossy air links or collision the ARs will not be able to maintain credible information. 4.2. Expected Issues Related to FMIPv6 with CARD FMIPv6 is designed to provide seamless and fast handover to MNs, but the degree of seamlessness depends on the efficiency of CARD protocol and its ability to resolve the CAR(s) identity and/or capabilities information well in advance and with minimum delay and signaling overhead. FMIPv6 protocol provides two handover modes [3] depending on whether the Fast Binding Acknowledgement (FBAck) message is received by the MN on the previous/current AR's (PAR) link or next/new AR's (NAR) link. In the former case the handover mode is termed "predictive" and in the latter case the handover mode is termed "reactive". Of the two handover modes the predictive mode is more relevant in terms of the CARD protocol because in this mode the MN is able to resolve the CAR information while it is still connected to PAR, but for high speed MNs, it is highly likely that during the address resolution and/or capabilities discovery delay incurred by CARD, the MN may move out of the range of the current AR and perform L2 handover with NAR before the NAR identity and/or capabilities gets resolved, and the MN undergoes reactive handover mode, in which case CARD protocol is rendered irrelevant. Reactive handover may account for packet losses for the duration when the MN sends a Fast Binding Update (FBU) towards its current AR from the NAR's link and till a reverse tunnel is not established between PAR and NAR. In case the PAR is unable to resolve the identity of the NAR, the MN will not undergo FMIPv6 handover but revert to MIPv6 handover incurring a higher handover delay associated with MIPv6. Since the CARD protocol is triggered every time a MN receives L2 IDs from in-range APs, this may not be feasible especially for fast moving MNs, because the MN is usually able to listen to neighboring APs when it is almost on the edge of the coverage area of its current AP and, depending on the area of overlap region, it is possible that the MN may move out of the coverage area of the current AP before it has resolved the NAR identity. Fast moving MNs undergo a higher frequency of handover and thus CARD protocol is initiated every time a MN is about to handover to a CAR, thus incurring higher signaling load, especially the MN-AR CARD Yousaf & Wietfeld Expires October 23, 2008 [Page 7] Internet-Draft Multi-Hop Discovery of CARs April 2008 Request/Reply messages. Since the MN-AR CARD Request/Reply message pair is exchanged over wireless link, they are more error prone than the AR-AR CARD Request/Reply message pair. This may not be suitable for fast moving MNs and/or real time communication sessions, as there is not enough time for retransmissions before a MN moves out of the coverage area of the current AP as explained above. The evident shortcomings of the CARD protocol with respect to fast moving MNs and real time applications are expected to be rectified by empowering the MN to perform reverse address translation and/or capabilities discovery of CAR(s) that may be multiple link-hops away with minimum reliance on current AR and with minimum exchange of MN- AR CARD Request/Reply message pair. This is achieved by Multi Hop Discovery of Candidate Access Router (MHD-CAR) protocol as discussed and detailed in the next sections. 5. Multi Hop Discovery of Candidate Access Router (MHD-CAR) MHD-CAR is a protocol aimed at enabling a MN to resolve the identity and capabilities information of CAR(s) that may be geographically adjacent but topologically it may be multiple hops away from the current AR. One of the main feature of MHD-CAR is the ability of the AR's to dynamically update their local CAR Table with the identity information of not only the neighboring ARs but also CARs located multiple hops away. The MHD-CAR operation does not require maintaining and/or managing a CARD Server or using a MN's handover to bootstrap and refresh the CAR Table of an AR. Instead each AR will maintain a snap-shot of the network around it in its local CAR Table. This CAR Table is dynamically configured at the initialization of the AR and is refreshed routinely. Also MHD-CAR requires a MN to maintain a local cache called "New Access Network (NAN) Cache", the information content of which enables a MN to resolve a CAR with minimum reliance on MN-AR CARD Request/Reply messages, thereby decreasing the signaling load, especially over the wireless link and attaining signaling and timing efficiency that may contribute towards improving the probability of a fast moving MN to undergo a Predictive FMIPv6 handover. This distributed approach of MHD-CAR provides a highly scalable, efficient and fault tolerant mechanism by overcoming the inherent shortcomings of the CARD protocol as explained in the previous sections. Yousaf & Wietfeld Expires October 23, 2008 [Page 8] Internet-Draft Multi-Hop Discovery of CARs April 2008 The MHD-CAR does not introduce any new protocol messages and utilizes the CARD Request/Reply messages. It proposes changes to the way the CAR Table information is managed and exchanged, besides introducing a new data structure called "New Access Network (NAN) Cache, which is maintained inside the MN. The combination of CAR Table and NAN Cache and their management brings the main advantages of MHD-CAR. The functional details of the MHD-CAR are discussed in the subsequent sections. 5.1. Access Router Operation As specified in [1], the AR MUST maintain a CAR Table, which is a L2- L3 address mapping table. The arrangement and composition of the CAR Table in MHD-CAR is different from what is suggested in [1] and the details of the CAR Table are elaborated in section 3.1.1. MHD-CAR introduces a parameter, besides many others discussed in section 3.1.1, called 'Distance' in the CAR Table which is a measure of the distance of a CAR, in terms of the number of link-hops, from the local AR which is maintaining the CAR Table. ARs exchange their CAR Table information with their neighboring ARs using AR-AR CARD Request/Reply message pair [1]. Each AR-AR CARD Reply message will carry the CAR Table information of the source AR in the capability container message sub-option. The exchange of CAR Table information with the neighboring ARs takes place with the iterative exchange of unsolicited AR-AR Reply message, where the number of iterations is equal to the specified maximum distance for which the ARs are supposed to maintain the CAR Table. At initialization, each AR will populate its CAR Table with its own identity and capabilities information and set the 'Distance' parameter to zero. The 'Distance' of zero indicates local AR information. Each AR will then exchange its local CAR Table entries with its neighboring ARs using unsolicited AR-AR CARD Reply Message. In the first iteration, the ARs will exchange their local [AP-ID, AR- Information] tuples, and optionally capabilities information, with their neighboring ARs, which will add this new information to their local CAR Tables and increment the 'Distance' by 1. Now each AR will have AR information about their neighboring ARs and this will be Yousaf & Wietfeld Expires October 23, 2008 [Page 9] Internet-Draft Multi-Hop Discovery of CARs April 2008 indicated by the 'Distance' value of 1, meaning that the neighboring ARs are at a distance of one link-hop away. This new update of the local CAR Tables will prompt the ARs to start the second iteration at random times of sending unsolicited AR-AR Reply messages which will contain the updated new CAR Table information in the capability container sub-option. The receiving ARs will compare the new information with the present CAR Table entries and if no match is found, will add the new CAR information to its local CAR Table by incrementing the distance parameter of all received entries by 1. This new entry will thus be stored in the local CAR Table with the 'Distance' value of 2, indicating that the relevant CAR is at distance of two link-hops away. This new update of the local CAR Tables will prompt the ARs to start the third iteration and this iterative exchange of local CAR Table information with the neighboring ARs will continue until each AR has the information about CAR which is MAXIMUM_DISTANCE_LIMIT away. The value of the MAXIMUM_DISTANCE LIMIT is a constant that depends on the network topology and can be specified by the administrator. How ever the optimum value of the MAXIMUM_DISTANCE LIMIT constant is under investigation. After the MAXIMUM_DISTANCE_LIMIT iterative exchange of unsolicited AR-AR Reply massages, the CAR Tables will converge. It should be noted that the CAR information (identity and capabilities) are carried in the capabilities container sub-option along with the 'Distance' information, and the AR-AR messages are only exchanged with their neighbors and ARs are not supposed to forward this message, or else the network can get flooded with these messages. After the convergence of CAR Tables that happens during the ARs initialization/bootup stage, the AR can send out an unsolicited AR-AR Reply message if there is any change in its capabilities or identity information or if a lifetime value of an entry expires, which will again be iteratively distributed amongst ARs MAXIMUM_DISTANCE_LIMIT away. It is expected that the CAR Tables will converge with minimum time without producing excessive traffic on the network links, where the time of convergence is a function of MAXIMUM_DIST_LIMIT. 5.1.1. CAR Table Conceptual Design As specified in [1] each AR must maintain a CAR Table which is a L2- L3 address mapping table maintaining a [AP-ID, AR-Info] tuple. The AP-ID mainly contains the address of the AP connected to the router, whereas the AR-Info is the router's valid L2 address, IP address and prefix of the interface to which the AP is connected to. Yousaf & Wietfeld Expires October 23, 2008 [Page 10] Internet-Draft Multi-Hop Discovery of CARs April 2008 However MHD-CAR proposes additional parameters to the CAR Table. The parameters defined for the AP-ID field are as follows: o L2 ID: The L2 ID of the CAP associated with the corresponding CAR. Usually the 6 Byte MAC Address of the CAP. o L2 Type: Determines the type of access technology (i.e, WiAMX, WLAN, CDMA, UMTS, GPRS, etc,). o Channel Number: The channel/frequency of the CAP. o SNR (RSSI): The SNR (or RSSI) of the received beacon. The parameters defined for the AR-Info field are as follows: o IP Address: The valid IP address (IPv4 or IPv6) of the interface to which the AP is connected to. o IP Prefix: The prefix of the IP address of the interface to which the AP is connected to. o Prefix Length: The prefix length of the IP address of the interface to which the AP is connected to. MHD-CAR introduces the capability container to the CAR Table and the following parameters are defined for it: o Bitrate: The bit rate supported by the CAP. o SSID: The identity of the CAP. o Distance: The distance of the CAR/CAP from the current AR in terms of link-hops. 5.2. Mobile Node Operation The CARD specification [1] proposes that a MN SHOULD maintain discovered address and capability information of CARS in a local cache to avoid requesting the same information repeatedly and to select an appropriate target AR from list of CARs as quickly as possible when a handover is imminent, but this proposal will only quicken the CAR selection if the MN has visited that CAR domain previously, whereas it is very much unlikely for a fast moving user to revisit a previously visited CAR domain before the corresponding entry times out. The conceptual design and arrangement of this local cache however is not specified in [1]. Yousaf & Wietfeld Expires October 23, 2008 [Page 11] Internet-Draft Multi-Hop Discovery of CARs April 2008 In MHD-CAR the MN MUST maintain a local cache, called "New Access Network (NAN)" cache. The NAN cache maintains information of the CARs that will aid the MN in selecting the appropriate CAR for handing over its connection to, when the handover is imminent. The information contents of the NAN cache is derived mostly from the CAR Table that is either "pushed" in the MN by the current AR, or either "pulled" by the MN from its current AR. The NAN cache also derives some of the information contents from the beacon messages received from the in-range wireless APs. The MN can "Pull" the CARD Table from the current AR by sending a wildcard MN-AR CARD Request Message, in response to which the current AR will append the necessary CAR(s) information in the various sub- options of the MN-AR CARD Reply Message. On the other hand the current AR upon sensing the connection of the MN to itself will send an unsolicited MN-AR CARD Reply Message containing the CAR(s) information appended as various sub-options. Whether the CAR information is pulled by or pushed in the MN, the MN will add and/or refresh the relevant entries of its NAN Cache based on the information provided by the MN-AR CARD Reply Message. The NAN Cache will contain the identity and capabilities information of not only the neighboring CAR(s) but of CAR(s) MAXIMUM_DISTANCE_LIMIT away from the current AR. This will allow the MN to perform reverse address translation and capability discovery without the exchange of MN-AR CARD Request/Reply message pair whenever handover is imminent. This will not only reduce the signaling load over the wireless link and improve the probability of resolving a CAR but also reduce the delay incurred due to reverse address translation and capability discovery procedure being carried out locally within the MN without having to perform signal exchange with the AR. Besides relying on MN-AR Card Reply message for keeping it up to date, the NAN Cache will also depend on the L2 information that it receives periodically in the form of beacons from in-range wireless APs. The NAN Cache in essence is a repository that maintains both L2 and L3 information regarding CAR(s). The information content of the NAN Cache will be used by the MN to enhance the performance of both L2 and L3 mobility management mechanisms and thus potentially lays the foundation of a cross-layer mobility management schemes. 5.3. New Access Network Cache Conceptual Design The information in the NAN Cache is keyed by the L2 ID(s) that the MN receives from the beacon signals of the in-range CAPs. The NAN Cache Yousaf & Wietfeld Expires October 23, 2008 [Page 12] Internet-Draft Multi-Hop Discovery of CARs April 2008 entries provide information that can also potentially aid TAR selection algorithms. The proposed NAN Cache is composed, but not limited to, the following parameters/fields for every CAR: o Reachability Status: Indicates whether a MN is reachable (attached) to the AP signified by the particular NAN Cache entry. o Context ID: A context id used to match the information exchange between correct CARD Request/Reply message pair. o L2 Type: Determines the type of access technology (i.e, WiMAX, WLAN, CDMA, UMTS, GPRS, etc,). o L2 ID: The L2 ID of the CAP associated with the corresponding CAR. Usually the 6 Byte MAC Address of the CAP. o SSID: SSID of the CAP o Bit Rate: The bit rate supported by the CAP. o Channel Number: The channel number/frequency of the CAP. This entry can be used by selective frequency scanning algorithms to reduce the latency due to scanning delay (For example Probe delay in 802.11 networks). o SNR: The signal to Noise ratio of the CAP. This entry continues to get updated with every received beacon. Can be potentially used to determine the appropriate time of initiating handover with the next CAP/CAR. o Receive Power: Receive power of the CAP. This entry continues to get updated with every received beacon. Potentially used to determine the direction of movement of the MN relative to the "reachable" AP and/or CAP. Also aid in the decision to select the appropriate Target AR (TAR) to handover to. o First Beacon Timestamp: The time a beacon was received from the AP to which this entry belongs. o Last Beacon Timestamp: Records the time stamp of the latest beacon received for the corresponding CAP/CAR. This entry continues to get updated with every received beacon. The information for maintaining the timestamp of the beacons for the corresponding CAP will allow the MN to determine the dwell time and the period for which it remains in the range of a particular CAP. Yousaf & Wietfeld Expires October 23, 2008 [Page 13] Internet-Draft Multi-Hop Discovery of CARs April 2008 o IP Address Type: Indicates whether the CAR identity information is based on IPv4 or IPv6. o IP Address: The IP address of the interface of the CAR which is connected to the CAP. Its size is 32 bits in case of IPv4 and 128 bits in case of IPv6. Used internally o IP Address Prefix: The prefix of the CAR's IP Address. o IP Address Prefix Length: The prefix length of the IP Address. Stored as an integer. o Capability Container: A data structure that contains the capability information, such as QoS parameters and buffer size of the corresponding CAR. The information content of NAN Cache also improves the performance of the L2 handover by aiding selective frequency scanning and thus provides both L2 and L3 information for a combined efficient and a true cross layer mobility management solution. The AR receiving an unsolicited AR-AR CARD Reply message will add or update its local CAR Table with the information contained in the capability container sub-option, and will increment the 'Distance' field for each new received entry by 1. The ARs will continue this inter exchange of their CAR Table with each other through unsolicited AR-AR CARD Reply messages until the CAR Tables converge. The CAR Tables will converge with several inter-exchanges of the AR_AR Reply messages during boot up time as described previously. 6. Security Considerations Security issues for this document follow those for CARD protocol. 7. IANA Considerations See [8] for instructions on IANA allocation 8. Acknowledgments This document was prepared using 2-Word-v2.0.template.dot. Yousaf & Wietfeld Expires October 23, 2008 [Page 14] Internet-Draft Multi-Hop Discovery of CARs April 2008 9. Normative References [1] M. Liebsch, A. Singh, H. Chaskar, D. Funato, "Candidate Access Router Discovery (CARD)", RFC 4066, July 2005. [2] Johnson, D., "Mobility Support in IPv6", RFC 3775, June 2004. [3] Koodli, R., Ed., "Fast Handover for Mobile IPv6", RFC 4068, July 2005. [4] Trossen, D., Krishanmurthi, G. Chaskar, H., Kempf, J., "Issues in candidate access router discovery for seamless IP-level handoffs", Work in Progress. [5] D. Funato et al., Geographically Adjacent Access Router Discovery Protocol, Internet draft, draft-funato-seamoby-gaard- 01.txt, June 2002. [6] Shim, E. and R. Gitlin, "Fast Handoff Using Neighbor Information", Internet Draft, draft-shim-mobileip-neighbor- 00.txt, November 2000. [7] Trossen, D., et al., "A Dynamic Protocol for Candidate Access- Router Discovery", Internet draft, draft-trossen-seamoby- dycard-01.txt, March 2003. [8] J. Kempf, ``Instructions for Seamoby and Experimental Mobility Protocol IANA Allocations," RFC 4065, Internet Engineering Task Force, June 2004. [9] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Yousaf & Wietfeld Expires October 23, 2008 [Page 15] Internet-Draft Multi-Hop Discovery of CARs April 2008 Author's Addresses Faqir Zarrar Yousaf, Communication Networks Institute University of Dortmund Otto-Hahn-Str. 6, D-44227 Dortmund, Germany Email: faqir.yousaf@tu-dortmund.de Christian Wietfeld, Communication Networks Institute University of Dortmund Otto-Hahn-Str. 6, D-44227 Dortmund, Germany Email: christian.wietfeld@tu-dortmund.de Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Yousaf & Wietfeld Expires October 23, 2008 [Page 16] Internet-Draft Multi-Hop Discovery of CARs April 2008 Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The IETF Trust (2008). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Yousaf & Wietfeld Expires October 23, 2008 [Page 17]