IETF Seamoby Working Group Internet Draft Marco Liebsch Ajoy Singh (Editors) Hemant Chaskar Daichi Funato Eunsoo Shim draft-ietf-seamoby-card-protocol-02.txt Expires: December 2003 June 2003 Candidate Access Router Discovery Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC 2026. 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 To view the list of Internet-Draft Shadow Directories, see http://www.ietf.org/shadow.html. Abstract To enable seamless IP-layer handover of a mobile node (MN) from one access router (AR) to another, the MN is required to discover the identities of candidate ARs (CARs) for handover, along with their capabilities, prior to the initiation of the IP-layer handover. The act of discovery of CARs has two aspects to it: Identifying the IP addresses of the CARs and finding the capabilities of those CARs. This process is called "candidate access router discovery" (CARD). At the time of IP-layer handover, that CAR, whose capabilities is a good match to the preferences of the MN, may be chosen as the target AR for handover. The protocol described in this document allows a mobile node to perform CARD. [Page 1] Internet-Draft Candidate Access Router Discovery June 2003 TABLE OF CONTENTS 1. INTRODUCTION . . . . . . . . . . . . . . . . . . . . . . . . 4 2. TERMINOLOGY. . . . . . . . . . . . . . . . . . . . . . . . . 5 3. CARD PROTOCOL FUNCTIONS. . . . . . . . . . . . . . . . . . . 6 3.1 Reverse Address Translation. . . . . . . . . . . . . . . . 6 3.2 Discovery of CAR Capabilities. . . . . . . . . . . . . . . 6 4. CARD PROTOCOL OPERATION. . . . . . . . . . . . . . . . . . . 7 4.1 Conceptual Data Structures . . . . . . . . . . . . . . . . 10 4.2 Mobile Node - Access Router Operation. . . . . . . . . . . 10 4.2.1 Mobile Node Operation. . . . . . . . . . . . . . . . . 10 4.2.2 Current Access Router Operation. . . . . . . . . . . . 11 4.3 Current Access Router - Candidate Access Router Operation. 12 4.3.1 Current Access Router Operation. . . . . . . . . . . . 12 4.3.2 Candidate Access Router Operation. . . . . . . . . . . 12 4.4 CARD Signaling Failure Recovery. . . . . . . . . . . . . . 13 4.4.1 MN-AR Signaling Failure. . . . . . . . . . . . . . . . 13 4.4.2 AR-AR Signaling Failure. . . . . . . . . . . . . . . . 13 4.5 CARD Protocol Message Piggybacking on the MN-AR Interface. 14 4.6 CARD Protocol Security . . . . . . . . . . . . . . . . . . 14 5. PROTOCOL MESSAGES. . . . . . . . . . . . . . . . . . . . . . 15 5.1 CARD Messages for the Mobile Node-Access Router interface. 15 5.1.1 CARD Main Header Format. . . . . . . . . . . . . . . . 15 5.1.2 CARD Options Format. . . . . . . . . . . . . . . . . . 17 5.1.2.1 CARD Request Option. . . . . . . . . . . . . . . . 18 5.1.2.2 CARD Reply Option. . . . . . . . . . . . . . . . . 18 5.1.3 Sub-Options Format . . . . . . . . . . . . . . . . . . 19 5.1.3.1 L2 ID Sub-Option . . . . . . . . . . . . . . . . . 20 5.1.3.2 Preferences Sub-Option . . . . . . . . . . . . . . 21 5.1.3.3 Requirements Sub-Option. . . . . . . . . . . . . . 21 5.1.3.4 Capability Container Sub-Option. . . . . . . . . . 22 5.1.3.5 Address Sub-Option . . . . . . . . . . . . . . . . 23 5.1.4 Capability AVP Encoding Rule . . . . . . . . . . . . . 23 5.2 CARD Messages for the inter-Access Router Protocol Operation . . . . . . . . . . . . . . . . . . . . . . 24 5.2.1 Protocol Transport . . . . . . . . . . . . . . . . . . 24 5.2.2 Protocol Main Header . . . . . . . . . . . . . . . . . 25 5.2.3 Protocol Payload Types . . . . . . . . . . . . . . . . 25 5.3 Overview on sub-options'/payload types' usage. . . . . . . 26 6. SECURITY CONSIDERATIONS. . . . . . . . . . . . . . . . . . . 27 6.1 Assumptions . . . . . . . . . . . . . . . . . . . . . . . 27 6.2 Security Association between AR and AR . . . . . . . . . . 27 [Page 2] Internet-Draft Candidate Access Router Discovery June 2003 6.3 Security Association between AR and MN . . . . . . . . . . 28 6.4 DoS Attack . . . . . . . . . . . . . . . . . . . . . . . . 28 7. PROTOCOL CONSTANTS . . . . . . . . . . . . . . . . . . . . . 29 8. IANA CONSIDERATIONS . . . . . . . . . . . . . . . . . . . . 29 9. NORMATIVE REFERENCES . . . . . . . . . . . . . . . . . . . . 30 10. INFORMATIVE REFERENCES . . . . . . . . . . . . . . . . . . . 30 11. AUTHORS' ADDRESSES . . . . . . . . . . . . . . . . . . . . . 31 12. IPR STATEMENTS . . . . . . . . . . . . . . . . . . . . . . . 32 13. COPYRIGHT NOTICE . . . . . . . . . . . . . . . . . . . . . . 32 14. ACKNOWLEDGEMENTS . . . . . . . . . . . . . . . . . . . . . . 32 Appendix A MAINTENANCE OF ADDRESS MAPPING TABLES IN ACCESS ROUTERS . . . . . . . . . . . . . . . . . . . 33 Appendix A.1 Centralized Approach using a Server Functional Entity . . . . . . . . . . . . . . . . . . . . . . 33 Appendix A.1.1 Approach . . . . . . . . . . . . . . . . . . . 33 Appendix A.1.2 Associated Protocol Operation . . . . . . . . . 34 Appendix A.1.3 Associated Protocol Messages. . . . . . . . . . 36 Appendix A.1.3.1 CARD Message Transport for the Interface between an AR and the CARD Server . . . . . . . . . 36 Appendix A.1.3.2 Protocol Main Header. . . . . . . . . . . . 36 Appendix A.1.3.3 Protocol Payload Types. . . . . . . . . . . 37 Appendix A.1.4 Associated Security Considerations. . . . . . . 37 Appendix A.1.4.1 Security Associations . . . . . . . . . . . 37 Appendix A.1.4.2 DoS Attack. . . . . . . . . . . . . . . . . 38 Appendix A.1.4.3 CAR Table Contamination . . . . . . . . . . 38 Appendix A.1.5 Associated IPR statements . . . . . . . . . . . 39 Appendix A.2 Decentralized Approach using Mobile Terminals' Handover . . . . . . . . . . . . . . . . . . . . . 40 Appendix A.2.1 Approach. . . . . . . . . . . . . . . . . . . . 40 Appendix A.2.2 Associated Protocol Operation . . . . . . . . . 40 Appendix A.2.3 Associated Protocol Messages. . . . . . . . . . 42 Appendix A.2.4 Associated Security Considerations. . . . . . . 43 Appendix A.2.5 Associated IPR Statements . . . . . . . . . . . 43 Appendix B APPLICATION SCENARIOS. . . . . . . . . . . . . . . . 44 Appendix B.1 CARD Operation in a Mobile-IPv6 Enabled Wireless LAN Network . . . . . . . . . . . . . . . . . . . . 44 Appendix B.2 CARD operation in a Fast Mobile-IPv6 enabled network . . . . . . . . . . . . . . . . . . . . . . 47 [Page 3] Internet-Draft Candidate Access Router Discovery June 2003 Conventions used in this document 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 RFC-2119 [1]. 1. INTRODUCTION IP mobility protocols, such as Mobile IP, enable mobile nodes to execute IP-level handover among access routers. Additionally, work is underway [7][15] to extend the mobility protocols to allow seamless IP handover. The pre-requisite for the seamless IP mobility protocols is the knowledge of candidate access routers (CARs) to which a mobile node can be handed over to. The CAR discovery protocol enables to acquire information about the access routers that are candidates for the mobile node's next handover. The CAR discovery involves identifying a CAR's IP address as well as its capabilities that the mobile node might use for its handover decision. There are cases when a mobile node has a choice of candidates to perform handover to different CARs. The mobile node would choose one based on a match between the mobile node's requirements on a handover candidate and the CAR's capabilities. However, the decision algorithm itself is out of scope of this document. The problem statement of the CAR discovery is discussed in [2]. In this document, a protocol is described to perform CAR discovery. Section 3 describes two main functions of the CAR discovery protocol. Then, section 4 describes the core part of the CARD protocol operation. Finally, the protocol messages' format is described in section 5. In Appendix A, two optional approaches are described to build a local table (CAR table), holding CARs' IP addresses and associated access points' layer-2 addresses, dynamically in access routers. This mapping is required in access routers to identify an individual CAR's IP address and to perform reverse address translation. However, the core protocol, as described in this document up to section 5, assumes this local CAR table (section 4.1) in access routers to be available and filled with the IP addresses of the CARs (and their associated APs' L2 addresses) throughout the core part of the draft. [Page 4] Internet-Draft Candidate Access Router Discovery June 2003 2. TERMINOLOGY This document uses terminology defined in TERMS [6]. In addition, the following terms are used: Mobile Node (MN) A Mobile Node is an IP host capable of moving its point of attachment to the Internet. Access Point (AP) A radio transceiver by which a MN obtains Layer 2 connectivity with the wired network. Access Router (AR) An IP router residing in an access network and connected to one or more APs. An AR offers IP connectivity to MNs. Candidate AR (CAR) An AR to which a MN has a choice of performing IP-level handover. Capability of an AR A characteristic of the service offered by an AR that may be of interest to a MN when the AR is being considered as a handover candidate. L2 ID Identifier of an AP that uniquely identifies that AP. For example, in 802.11 PCF, this could be a MAC address of an AP. [Page 5] Internet-Draft Candidate Access Router Discovery June 2003 3. CARD PROTOCOL FUNCTIONS A CARD protocol accomplishes the following functions. 3.1 Reverse Address Translation If a MN can listen to L2 IDs of new APs prior to making decision about IP-level handover to CARs, a mechanism is needed for reverse address translation. This function of the CARD protocol enables the MN to map the received L2 ID of an AP to the IP address of the associated CAR that connects to the AP. To get the CAR's IP address, the MN sends the L2 ID of the AP to the current AR and the current AR provides the associated CAR's IP address to the MN. In cases where the MN can acquire IP connectivity with CARs prior to making handover decisions, this functionality is trivially realized, since the MN can request CARs individually for reverse address translation. 3.2 Discovery of CAR Capabilities Information about capabilities of CARs can assist the MN in making optimized handover decisions. This capability information serves as input to the target AR selection algorithm. Some of the capability parameters of CARs can be static, while some others can change with time. Definition of capabilities is out of scope of the CARD protocol design. Encoding rules for capabilities and the format of a capability container for capability transport are specified in section 5. There are two approaches for MNs to acquire address and capability information of CARs. One is that the MN sends an explicit request to its current AR and the current AR provides address and capability information to the MN. The other is that the current AR either periodically transmits address and capability information of CARs to the MNs over download channels, or link-layer mechanisms trigger unsolicited transmission of CARs' address and capability information. [Page 6] Internet-Draft Candidate Access Router Discovery June 2003 4. CARD PROTOCOL OPERATION The CARD protocol is used to allow MNs resolving the L2 ID of one or more APs, which are candidates the MN may initiate a handover to, to the IP address of the associated CARs, as well as to discover these CARs' capabilities. Furthermore, the protocol allows populating ARs' CAR tables (section 4.1) with the capabilities of CARs. For this, the CARD protocol makes use of a CARD Request and CARD Reply protocol message handshake between a MN and its current AR, and between a MN's current AR and individual CARs respectively. CARD Request and CARD Reply messages are used on the interface between a MN and its current AR to allow MNs retrieving CARs' address and capability parameter specific information from the network. To allow ARs populating and maintaining their local CAR table with capability parameter information of CARs, a CARD Request and CARD Reply protocol message handshake is also used on the interface between a MN's current AR and CARs to allow updating ARs' CAR table entries with CARs' capability information. An access point's L2 ID, a CAR's IP address and associated capability information is carried as CARD protocol message parameter with a CARD Request or a CARD Reply message respectively. A CAR's capabilities are specified as a list of attribute-value pairs, which is conveyed in a Capability Container message parameter. The CARD protocol enables the MN's current AR to exchange capabilities with CARs and to subsequently convey appropriate capabilities to the connected MNs. Information about the CAR(s) and associated capabilities MAY be used by the MN to perform target access router selection during its IP handover. The current AR initiates capability exchange with a CAR either when it receives a CARD Request message from a MN, containing possibly parameters carrying identifier(s) (L2 ID) of newly discovered AP(s), or when it detects that some of its CAR table's capability entries are about to expire. Upon completion of the MN-solicited capability exchange between a MN's current AR and CARs, the current AR MUST notify the desired capabilities to the MN by sending a CARD Reply message having the desired message parameters appended. The current AR MAY also send periodically unsolicited CARD Reply messages to all connected MNs. This behavior of the AR SHALL depend upon the local policies of the network service providers and need to be configured administratively. The unsolicited CARD Reply SHALL be broadcast from ARs to all the connected MNs. For unsolicited CARD Reply messages sent to connected MNs, the AR MUST set the U-flag of the CARD Reply to indicate to MNs that this particular CARD Reply message has been sent unsolicited. [Page 7] Internet-Draft Candidate Access Router Discovery June 2003 The CARD protocol also enables a MN to optionally indicate its preferences on capabilities of interest to its current AR, which allows the MN's current AR performing optional capability pre- filtering for optimization purposes. Appending the optional Preferences message parameter for a CARD Request message, which is sent to the MN's current AR, the MN can indicate a list of capability attributes, which are of interest to the MN, to its current AR. The AR now returns only these capabilities of interest to the requesting MN. The format of this optional Preferences message parameter is described in section 5.1.3.2. Optionally, the MN can provide its current AR with a list of capability attribute-value pairs, indicating not only the capability parameters (attributes) as required for capability pre-filtering, but also a specific value for a particular capability. This allows the MN's current AR performing CAR pre-filtering and to send only address and capability information of CARs, whose capability values meet the requirements of the MN, back to the requesting MN. The format of this optional Requirements message parameter is described in section 5.1.3.3. As an example, using the optional Preferences message parameter, a MN may indicate to its current AR that it is interested only in IEEE802.11 interface specific capability parameters, since this is the only interface the MN has implemented. Hence, the MN's current AR sends back only CARs' IEEE802.11 specific capabilities. Similarly, using the optional Requirements message parameter, a MN MAY indicate to its current AR that it is only interested in CARs that can satisfy a given QoS constraint. Here, a MN sends the respective QoS attribute with the QoS constraint value to its current AR using the optional Requirements message parameter. The QoS constraint is denoted as an attribute-value pair and encapsulated with the Requirements message parameter, which is appended to the MN-originated CARD Request message. Based on the received optional list of attributes in the Preferences parameter or a list of attribute-value pairs in the Requirements message parameter, the MN's current AR MAY use these parameters for deciding the content of the solicited CARD Reply message, which is to be sent back to the MN. Alternatively, in case no optimization with regard to capability or CAR pre-filtering is performed by the MN's current AR, the current AR MAY choose to silently ignore the optional Requirements and Preferences message parameter as received in the CARD Request message. [Page 8] Internet-Draft Candidate Access Router Discovery June 2003 The CARD protocol operation, as described in this section, distinguishes signaling messages exchanged between a MN and its connecting AR and signaling messages exchanged between ARs. Hence, description of signaling messages described in the following sections have a preceding identifier, referring to the associated interface. Messages that are exchanged between a MN and AR are precluded with "MN-AR", messages between ARs with "AR-AR" respectively. +--------------+ (3)AR-AR CARD Request +----------+ | Current |------------------------->| CAR | | AR |<-------------------------| | +--------------+ (4)AR-AR CARD Reply +----------+ ^ | | | MN-AR MN-AR | | CARD Reply(5) CARD Request(2) V +--------------+ | Mobile | | Node |<-- CARD Init Trigger +--------------+ (1) Figure 1: MN initiated CARD Protocol Overview Figure 1 describes the operation of the MN initiated CARD Request/Reply-based protocol operation. On reception of access points' L2 IDs or the appearance of a CARD initiation trigger (1), the MN passes on one or more L2 ID(s) to its current AR using the MN-AR CARD Request message (2). The MN's current AR resolves the L2 ID to the IP address of the associated CAR or, in case the MN has not attached one or more L2 ID message parameters, it just reads out all CARs' IP address information using the reverse address translation information (L2 ID to IP address mapping) from its local CAR table. In case one or more capability entries have expired in the current AR's CAR table, the current AR then directly contacts the CAR and performs capability discovery with it by performing an AR-AR CARD Request (3) and AR-AR CARD Reply (4) protocol message handshake to retrieve individual CARs' capability information. The current AR then updates capability entries in its local CAR table and passes on the IP address of the CAR(s) and associated capabilities to the MN using the MN-AR CARD Reply message (5). Since the MN-AR CARD Request is sent when a MN discovers new AP(s) during link layer scanning, sometimes a MN might send frequent MN-AR CARD Requests, thereby overwhelming its current AR with CARD Request signaling messages. To counteract this problem, the AR SHOULD set [Page 9] Internet-Draft Candidate Access Router Discovery June 2003 the R-flag (rate limiting) of a subsequent CARD Reply message for flow-control purposes (section 5.1.2.2), thereby requesting the MN to reduce the generation rate of MN-AR CARD Requests. Upon receipt of the MN-AR CARD Reply with the R-flag set, the requesting MN MUST reduce the rate of generation of MN-AR CARD Requests. The exact implementation of a rate-limiting algorithm should be decided by the implementers. 4.1 Conceptual Data Structures AR(s) SHALL maintain a L2-L3 address mapping table (CAR table) that will be used to resolve L2 IDs of candidate APs to the IP address of associated CARs. This address-mapping table can be configured statically for the CARD protocol operation. Optionally, the CAR table MAY be populated dynamically, using either a server-based or a handover-based approach, as described in appendices A.1 and A.2 respectively. ARs SHALL also keep and maintain individual CARs' capabilities in the local CAR table, taking the associated capability lifetime into account. If the lifetime of an individual capability entry has expired, the respective capability is to be discovered and to be updated when requested from a connected MN. The ARs' CAR table may be implemented differently by the different implementations, hence additional details are not provided here. 4.2 Mobile Node - Access Router Operation 4.2.1 Mobile Node Operation To initiate CARD, a MN sends a CARD Request to its current AR, requesting it to resolve the L2 ID of nearby access points to the IP address of associated CARs, and also to obtain capability parameters associated with these CARs. In case the requesting MN want its current AR to resolve specific L2 IDs, the MN-AR CARD Request SHOULD contain the CARD protocol specific L2 ID message parameters, carrying the L2 ID of respective access points, for which reverse address translation to associated CARs' IP address as well as CARs' capability information is being requested. The CARD Request MAY also contain the Preferences or Requirements message parameter, indicating the MN's preferences on capability attributes of interest or its requirements on CARs' capability attribute-value pairs to its current AR. For example, using the Preferences message parameter, a MN may indicate that it is only interested in these CAR(s) supporting a specific air interface technology. Similarly, using the Requirements message parameter, a MN can indicate the list of capability attributes and associated capabilities' values to its current AR. The Requirements message parameter may be used to [Page 10] Internet-Draft Candidate Access Router Discovery June 2003 indicate the cut off values of the capabilities for the desired CAR(s). The MN's current AR MAY use the Preferences and Requirement message parameter to decide about a sub-set of the CAR(s) that can satisfy the MN's need. Upon receipt of the corresponding MN-AR CARD Reply message, which has been sent by the MN's current AR in response to the MN's previously sent request, the MN processes all MN-AR CARD Reply message parameters to retrieve its CARs' address and capability information. 4.2.2 Current Access Router Operation Upon receipt of the requesting MN's MN-AR CARD-Request, containing one or multiple L2 ID message parameters, the connected AR SHALL resolve the requested APs' L2 ID to the IP address of the associated CAR(s). In case no L2 ID parameter has been sent with the MN-AR CARD Request message, the MN's current AR retrieves all CARs' IP address and capability information from its local CAR table. Optionally, when allowed by local policies and supported by respective ARs, the AR MAY retrieve a subset of capabilities or CARs, satisfying the optionally appended Preferences and Requirement message parameter, from its local CAR table. CARs' address information along with associated capabilities are then delivered to the MN using the MN-AR CARD Reply message, having the Address message parameters and appropriate Capability Container parameters appended. The CARs' IP address as well as the capabilities SHALL be encoded according to the format for CARD protocol message parameters as defined in section 5.1.3 of this document. The capabilities are encoded as attribute-value pairs, which are to be encapsulated in a Capability Container message parameter according to the format defined in section 5.1.3.4. The responding current AR shall copy the sequence number received in the MN-AR CARD Request to the MN-AR CARD Reply. The CARD protocol optionally allows service providers to configure AR to send periodic unsolicited CARD Reply Messages to all connected mobile nodes. The unsolicited CARD Reply is delivered as broadcast message to MN(s). The current AR sets the U-flag of the unsolicited CARD Reply to indicate that the message is being sent unsolicited. The interval between consecutive periodic broadcast is a configurable parameter and SHALL be configured by the network administrators. [Page 11] Internet-Draft Candidate Access Router Discovery June 2003 4.3 Current Access Router - Candidate Access Router Operation 4.3.1 Current Access Router Operation The MN's current AR MAY initiate capability exchange with CARs either when it receives a MN-AR CARD Request or when it detects that one or multiple of its local CAR table's capability entries' lifetime is about to expire. Upon receipt of a MN-AR CARD Request, the MN's current AR retrieves the IP address of the associated CAR(s) from its local CARD table. Then the AR SHOULD issue an AR-AR CARD Request to the respective CAR(s) if complete capability information of a CAR is not available in the current AR's CAR table. The AR MAY also issue the AR-AR CARD Request when it detects that one or multiple of its local CAR table's entries are about to expire. The AR-AR CARD Request message format is defined in section 5.2.2. The AR MUST set the sequence number of the CARD Request to one more than the previously used sequence number value. The AR MAY append its own capabilities, encoded as attribute-value pairs and encapsulated with the Capability Container message parameter, to the released AR-AR CARD Request. The MN's current AR SHALL use the IPsec ESP for authenticating the AR-AR CARD Request. The IPsec ESP MAY be also used for encrypting the capability information. Upon receipt of the AR-AR CARD Reply, which has been sent by the CAR in response to the previously sent request, the MN's current AR SHALL extract the capability information from the payload of the received message and buffer the received capabilities in its local CAR table. The lifetime of individual capabilities is to be set according to the lifetime indicated for each capability received. The value of the table entries' timeout shall depend upon the nature of individual capabilities. Then the AR MUST send the MN-AR CARD Reply to the Mobile Node. 4.3.2 Candidate Access Router Operation Upon receipt of a AR-AR CARD Request, a CAR shall extract the capabilities of the MN's current AR from the payload of the received message. The CAR SHALL buffer the received capabilities in its CAR table and set the timer for individual capabilities appropriately. The value of the table entries' timeout depends upon the nature of capabilities received. The CAR then MUST respond with the AR-AR CARD Reply message. The CAR MUST include the same sequence number received in AR-AR CARD Request message to the AR-AR CARD Reply message. The AR-AR CARD Reply shall include the CAR's capabilities as list of attribute-value pairs in the Capability Container message [Page 12] Internet-Draft Candidate Access Router Discovery June 2003 parameter. The CAR SHALL use IPsec ESP for authentication or optionally encryption of the AR-AR CARD Reply message. 4.4 CARD Signaling Failure Recovery For a variety of reasons, the packets carrying CARD protocol signaling may be dropped. In this section we consider mechanisms for recovery from the CARD signaling failures. Broadly the CARD signaling failures can be categorized in MN-AR signaling failures and AR-AR signaling failures. 4.4.1 MN-AR Signaling Failure It is likely that either a CARD Request or CARD Reply may be dropped due to poor radio link conditions. A MN SHALL detect the loss of a MN-AR CARD Request or MN-AR CARD Reply Message using a timeout mechanism (MN_AR_CARD_TIMEOUT). The AR SHALL start a timer (MN_AR_CARD_TIMER) after sending a MN-AR CARD Request message with the given sequence number. The MN SHALL stop the timer as soon as the reply to the MN-AR CARD Request is received by it. Upon expiration of the MN_AR_CARD_TIMER, the MN SHALL declare the outstanding message as lost, resends the same message and restart the MN_AR_CARD_TIMER. The MN shall retry the MN-AR CARD Request for a pre-configured number of times (MN_AR_CARD_RETRIES) before declaring the protocol message exchange aborted. The MN SHALL silently discard any duplicate MN-AR CARD Reply messages received from its current AR. 4.4.2 AR-AR Signaling Failure It is likely that a AR-AR CARD Request or AR-AR CARD Reply may be dropped due to congestion at the intermediate routers or poor link conditions. The MN's current AR SHALL detect the loss of an AR-AR CARD Request or an AR-AR CARD Reply message using a timeout mechanism (AR_AR_CARD_TIMEOUT). The current AR SHALL start a timer (AR_AR_CARD_TIMER) after sending the AR-AR CARD Request with the given sequence number. The current AR SHALL stop the timer as soon as the reply to the AR-AR CARD Request is received by it. Upon expiration of the AR_AR_CARD_TIMER, the MN's current AR SHALL declare the outstanding AR-AR CARD Request as lost and then resends the same message to the CAR. The current AR SHALL retry the AR-AR CARD Request message for a pre-configured number of times (AR_AR_CARD_RETRIES) before declaring the protocol message exchange as aborted. The current AR SHALL silently discard any duplicate AR- AR CARD Reply received from the CAR. [Page 13] Internet-Draft Candidate Access Router Discovery June 2003 4.5 CARD Protocol Message Piggybacking on the MN-AR Interface To allow MNs and ARs appending the ICMP-option type CARD Request and CARD Reply (section 5.1.2) to the ICMP-type Fast Mobile IPv6 signaling messages (CARD protocol message piggybacking), MN and AR should know about the signaling peer's capability for CARD protocol message piggybacking. This requires dynamic discovery of piggybacking capability using the P-flag in the MN-AR CARD Request and the MN-AR CARD Reply message, as well as in the Capability Container message parameter, as described in detail in section 5.1. When not receiving an unsolicited CARD Reply message from the MN's current AR, the MN sends the very first CARD Request to its current AR using the ICMP-type CARD main header for transport, as described in section 5.1.1. In case the MN supports CARD protocol message piggybacking, the P-flag in this very first CARD Request message is to be set. On reception of the CARD Request message, the MN's current AR learns about the MN's piggybacking capability. To indicate its own capability to convey CARD protocol messages with Fast Mobile IPv6 protocol messages, the AR sets the P-flag in the CARD Reply message. In case the AR does not support CARD protocol message piggybacking, all subsequent CARD protocol messages between the MN and this particular AR are to be sent stand-alone, using the CARD main header. In case both nodes, the MN and its current AR, support CARD protocol message piggybacking, subsequent CARD protocol messages can be conveyed as an option via the Fast Mobile IPv6 RtSolPr and PrRtAdv message. During the CARD process, a MN learns about its CARs' piggybacking capability already during the discovery phase, since the Capability Container, as described in section 5.1.3.4, carries also a P-flag, which is to be set appropriately from respective CARs whose capabilities are encapsulated. This allows the MN to immediately perform CARD protocol message piggybacking after a handover to a selected CAR, assumed this CAR supports CARD protocol piggybacking. An application scenario of the CARD-function enabled Fast Mobile- IPv6 protocol, which carries CARD protocol messages between a MN and its current AR by means of CARD protocol message piggybacking, is described in Appendix B.2. 4.6 CARD Protocol Security The MN-AR and AR-AR messages SHALL be protected using IPsec ESP [10]. It is safe to assume that there will be an appropriate SA between a MN and its connected AR, which MAY be used to secure MN-AR CARD Message. It is also assumed that neighboring ARs SHALL establish an appropriate SA to secure the AR-AR CARD messages. [Page 14] Internet-Draft Candidate Access Router Discovery June 2003 5. PROTOCOL MESSAGES 5.1 CARD Messages for the Mobile Node-Access Router Interface 5.1.1 CARD Main Header Format Hosts and Access Routers use the CARD ICMP-type main header when CARD protocol messages, which are to be exchanged between a MN and an AR, cannot be conveyed via another outgoing ICMP-type message, as for example the Fast Mobile-IPv6 'Router Solicitation for Proxy' or 'Proxy Router Advertisement' [7] messages. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Code | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Options ... +-+-+-+-+-+-+-+-+-+-+-+- - - - IP Fields: Source Address: An IP address assigned to the sending interface. Destination Address: An IP address assigned to the receiving interface. Hop Limit: 255 Encapsulating Security Payload (ESP) Header: The sender SHOULD include the Encapsulating Security Payload (ESP) Header, based on the previously established Security Association between the sender and the receiver. ICMP Fields: Type T.B.A (To be assigned) Code 0 Checksum The ICMP checksum. [Page 15] Internet-Draft Candidate Access Router Discovery June 2003 Reserved This field is currently unused. It MUST be initialized with zero by the sender and MUST be ignored by the receiver. Valid Options: CARD Request: The CARD Request allows entities to request CARD specific information from ARs. To process the CARD Request message on the receiver side, further sub-options must be carried, serving as input to the reverse address translation function and/or capability discovery function. CARD Reply: The CARD Reply carries parameters, previously requested with a CARD Request, back to the sender of the CARD Request. In case of unsolicited address information and capabilities are to be sent to a node, the sender uses the CARD Reply without getting an explicit CARD Request before. Further sub-options will be associated with the CARD Reply message. Valid Sub-Options: Layer-2 ID (mandatory): The Layer-2 ID sub-option carries information about the type of an access point as well as the Layer-2 address of the access point associated with the CAR, whose IP address and capability information is to be resolved. Preferences sub-option (optional): The Preferences sub-option carries information about attributes of interest to the requesting entity. Attributes are encoded according to the AVP encoding rule as described in section 5.1.4. For proper settings of AVP Code and Data field, please see section 5.1.3.2. This sub- option is used only in case of performing optional capability pre-filtering on ARs and allows for providing only capabilities of interest to a requesting MN. Requirements (optional): The Requirements sub-option carries information about attribute-value pairs required for pre- filtering of CARs on a MN's current AR. This parameter conveys MN specific attribute-value pairs to allow a MN's current AR to send only CARs of interest, meaning CARs matching the [Page 16] Internet-Draft Candidate Access Router Discovery June 2003 MN's requirements according to the attributes' values, back to the requesting MN. CARs are filtered on ARs according to CARs' capability parameters and given policy or threshold, as encoded in the Requirements sub-option. Attribute-value pairs are encoded according to the AVP encoding rule as described in section 5.1.4. Setting rules of AVP Code and Data field for the Requirements sub-option are described in section 5.1.3.3. Capability container (mandatory): The Capability container sub-option carries information about a single CAR's capabilities. The format of this sub-option is described in section 5.1.3.4. Address (mandatory): The Address sub-option carries information on an individual CAR's resolved IP address. The format of the Address sub-option is described in section 5.1.3.5. 5.1.2 CARD Options Format All options are of the form: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ ... ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Fields: Type: 8-bit identifier of the type of option. The options defined in this document are: Option Name Type -------------------------------------------------- MN-AR CARD Request T.B.A MN-AR CARD Reply T.B.A Length: 8-bit unsigned integer. The length of the option including the type and length fields in units of octets. The value 0 is invalid. [Page 17] Internet-Draft Candidate Access Router Discovery June 2003 5.1.2.1 CARD Request Option 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length |P| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sub-Options +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - - Fields: Type: T.B.A Length: The length of the option in units of octets, including the type and length fields as well as sub-options. Flags: P-flag: Indicates CARD protocol message piggybacking capability of the CARD Request message sender. A description for proper use of this flag can be found in section 4.5 of this document. Reserved bits MUST be initialized with 0. Sequence Number: Allows correlating requests with replies. Valid Sub-Options: - L2 ID sub-option - Preferences sub-option - Requirements sub-option 5.1.2.2 CARD Reply Option 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length |P|U|R| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sub-Options +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - - [Page 18] Internet-Draft Candidate Access Router Discovery June 2003 Fields: Type: T.B.A Length: The length of the option in units of octets, including the type and length fields as well as sub-options. Flags: P-flag: Indicates CARD protocol message piggybacking capability of the CARD Request message sender. A description for proper use of this flag can be found in section 4.5 of this document. U-flag: Indicates an unsolicited CARD Reply. A description for proper use of this flag can be found in section 4 of this document. R-flag: Indicates exceeding CARD Request rate limitation. A description for proper use of this flag can be found in section 4 of this document. Reserved bits MUST be initialized with 0. Sequence Number: Allows correlating requests with replies. Valid Sub-Options: - L2 ID sub-option - Capability Container sub-option - Address sub-option 5.1.3 Sub-Options Format All Sub-Options are of the form: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Sub-Option Type|Sub-Option Len | Sub-Option Data . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Sub-Option Type: 8-bit identifier of the type of option. The Sub-Options defined in this document are: [Page 19] Internet-Draft Candidate Access Router Discovery June 2003 Sub-Option Name Type -------------------------------------------- L2 ID T.B.A Preferences T.B.A Requirements T.B.A Capability Container T.B.A Address T.B.A Option-Length: 8-bit unsigned integer. The length of the option including the type and length fields in units of octets. The value 0 is invalid. 5.1.3.1 L2 ID Sub-Option 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Sub-Option Type|Sub-Option Len | Context-ID |M| L2-Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | L2 ID . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - - Sub-Option Type: T.B.A Sub-Option Length: Length of the Sub-Option (including type and length fields as well as L2 type indicator) in units of 8 octets. Context-ID: Identifies associated L2 ID, IP address and capability information, when coming with separated sub-options. M-flag: This flag indicates that the Context-ID of this particular L2 ID sub-option has been modified by the MN's current AR and set to the same value as a preceding L2 ID received in the same CARD Request message. This adjustment appears in case this L2 ID's associated access point is served by the same CAR as a preceding access point's L2 ID, hence, the same Capability Container and Address sub-option, describing a CAR's IP address and associated capabilities, is valid for this particular L2 ID. [Page 20] Internet-Draft Candidate Access Router Discovery June 2003 L2 type: Indicates the interface type (optional) (Ethernet, IEEE802.11b, ...). If the L2 type indicator is not used, this field MUST be set to 0. L2 ID: The variable length layer-2 identifier of an individual CAR's access point. 5.1.3.2 Preferences Sub-Option 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Sub-Option Type|Sub-Option Len | Preferences +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Sub-Option Type: T.B.A Sub-Option Length: Length of the Sub-Option (including type and length fields) in units of 8 octets. Preferences: AVP encoded preferences (see section 5.1.4). AVPs MUST be encoded according to the AVP encoding rule described in section 5.1.4. Only ATTRIBUTES (AVP Code) need to be set. The VALUE indicator (Data) will not be processed and can be omitted. The 'AVP Length' field is to be set appropriately. The use of the Preferences sub-option is optional and for optimization purpose. 5.1.3.3 Requirements Sub-Option 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Sub-Option Type|Sub-Option Len | Requirements +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Sub-Option Type: T.B.A Sub-Option Length: Length of the Sub-Option (including type and length fields) in units of octets. [Page 21] Internet-Draft Candidate Access Router Discovery June 2003 Requirements: AVP encoded requirements (see section 5.1.4) AVPs MUST be encoded according to the rule described in section 5.1.4. Both, ATTRIBUTES (AVP Code) and VALUES (Data) MUST be set. The use of the Requirements sub-option is optional and for optimization purpose. 5.1.3.4 Capability Container Sub-Option 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Sub-Option Type|Sub-Option Len | Context-ID |P| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AVPs +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - - Sub-Option Type: T.B.A Sub-Option Length: Length of the Sub-Option (including type and length fields as well as AVPs) in units of 8 octets. Context-ID: Identifies L2 ID, IP address and capability triples, coming with separate sub-options. Flags: P-flag: Indicates piggybacking capability of a CAR. This flag allows a MN already after a CARD process to know about a selected new AR's piggybacking capability. Reserved bits MUST be initialized with 0. AVPs: AVPs are a method of encapsulating capability information relevant for the CARD protocol. See section 5.1.4 for the AVP encoding rule. [Page 22] Internet-Draft Candidate Access Router Discovery June 2003 5.1.3.5 Address Sub-Option 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Sub-Option Type|Sub-Option Len | Context-ID | Address Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Address . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - Sub-Option Type: T.B.A Sub-Option Length: Length of the Sub-Option (including type and length fields) in units of octets. Context-ID: Identifies L2 ID, IP address and capability triples, coming with separate sub-options. Address Type: Indicates the type of the address. 0x01 IPv4 0x02 IPv6 Address: The Candidate Access Router's IP address. 5.1.4 Capability AVP encoding rule 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AVP Code |S| Res | AVP Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Attribute Lifetime (present if S = 0) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Data . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - - [Page 23] Internet-Draft Candidate Access Router Discovery June 2003 AVP Code: Identifies the attribute uniquely. Flags: S-flag (Static) 1: identifies a static attribute, lifetime field is not present. Data will follow immediately after the AVP Length field. 0: identifies a dynamic attribute, lifetime field indicates the attribute's lifetime. Reserved (Res) flags MUST be set to 0. Lifetime: Specifies the lifetime of the encoded capability in seconds. This field is only present if the encoded capability has a lifetime associated and the S-bit has not been set. AVP Length: The two octet AVP length field indicates the number of octets in this AVP, including the AVP Code, AVP Flags, AVP Length, Lifetime (if present) and Data. In case the encoded capability is static and does not change with the time, the S-flag MUST be set and the 32-bit Lifetime field is not present in the encoded capability. In this case the Data field follows immediately the AVP length field. If there is a timeout associated with the encoded capability, the S-flag MUST NOT be set and the Lifetime field MUST be present. Note: This document provides no detailed information on how to encode the capability attribute's value, which is to be encoded in the Data field of the generic message format described above. Also details on the interpretation of individual capability parameters is out of scope of this document. 5.2 CARD Messages for the inter-Access Router Protocol Operation 5.2.1 Protocol Transport For the CARD protocol operation on the network side between a MN's current AR and CARs, UDP [9] is used as transport for CARD protocol messages. The associated UDP port for the CARD protocol operation is T.B.A. To authenticate protocol messages between ARs, the IPsec ESP SHOULD be used [10]. [Page 24] Internet-Draft Candidate Access Router Discovery June 2003 5.2.2 Protocol Main Header Protocol main header comprises the first 8 octets: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Version| Res. | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Payload ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - - Version: Indicates the version of the protocol. The version described in this document is version 1. Res.: This field is currently reserved and MUST be set to 0. Type: Message type. Message types specified for this interface: Message Type -------------------------------------- AR-AR CARD Request 0x01 AR-AR CARD Reply 0x02 Length: Length of the subsequent payload in octets. Sequence number: Allows correlating requests with responses. 5.2.3 Protocol Payload Types Payload types and encoding rules are the same as described for the various sub-option types in section 5.1 for the MN-AR interface. The same TLV-encoded format is used to attach the options as payload to the protocol main header. [Page 25] Internet-Draft Candidate Access Router Discovery June 2003 5.3 Overview on sub-options'/payload types' usage The following table indicates, which sub-options or payload types are relevant for the various interfaces in CARD protocol functions. Description Type Interface | | / \ | | MN-AR AR-AR --------------------------------------------------------------- L2 ID T.B.A x Preferences T.B.A x x Requirements T.B.A x Capability Container T.B.A x x Address T.B.A x [Page 26] Internet-Draft Candidate Access Router Discovery June 2003 6. SECURITY CONSIDERATIONS 6.1 Assumptions It is important to note that it is assumed in the protocol that each AR has the correct information in the CAR table about the identities of the geographically neighboring APs and their associated ARs and the association relationship between the APs and the ARs. It is assumed that the ARs registered in the CAR table at each AR are authorized to participate in the CARD protocol. So any security concern regarding the procedure to discover the identities is not considered here. Verifying the authorization status of particular ARs with respect to participating in the CARD protocol is a part of the discovery procedures and thus is not considered here either. The appendices of this draft describe procedures for discovering the identities of the geographically ARs and APs and relevant security considerations. It is assumed also that each AR has the correct information about APs associated with the AR or capability to get it. It could be done as static configuration at the AR or a protocol could be used between the AR and the APs for dynamic discovery and exchange of information such as MAC addresses and operating channels of the APs. It is out of scope of this draft. 6.2 Security Association between AR and AR Each AR receives capability information from its neighboring ARs. If the message is not protected from modification, a malicious attacker can modify the information, which can cause undesirable impacts on the applications using the information. Also if the information is delivered in plain text, a third party can read it. To prevent the information from being compromised, the CARD REPLY messages between ARs SHOULD be authenticated. The messages also MAY be encrypted for privacy of the information. How to establish a security association is out of scope of this memo. But it is assumed that the two CARs can establish a security association. IPsec ESP is the default mechanism for message authentication between ARs. Also, IPsec ESP is the default method for message encryption. Which capability information is collected in the CAR table and allowed to be disclosed depends on the administration policy. In particular, if the CARD protocol runs between ARs in different domains as well as within the same domain, different policies could [Page 27] Internet-Draft Candidate Access Router Discovery June 2003 be established regarding capability information disclosure. The policy can be implemented locally at each AR and thus it is not dealt with here. 6.3 Security Association between AR and MN A malicious node can send bogus CARD REPLY messages to MNs by masquerading the AR. So the MN SHOULD authenticate the CARD REPLY messages from the AR. 6.4 DoS Attack An AR can be overwhelmed with CARD REQUEST messages or even CARD REPLY messages. A MN can also be overwhelmed with CARD REPLY messages. The AR or MN SHOULD implement a rate limiting policy about sending or responding to the messages so that it does not send or process more than a certain number of messages per period. The AR should also implement a rate limiting policy in accepting CARD REQUEST messages from any particular AR or MN. An attacker can send a huge list of capability information by masquerading ARs. It can cause overflow in the buffer for the CAR table at ARs or MNs. So the AR or the MN should put a limit on the size of the capability information for an AR. [Page 28] Internet-Draft Candidate Access Router Discovery June 2003 7. PROTOCOL CONSTANTS MN_AR_CARD_TIMEOUT: This timer value indicates the timeout of an expected CARD Reply message on a MN after a previously released CARD Request message has been sent to the MN's current AR. MN_AR_CARD_RETRIES: This value indicates the number of retries when sending a MN-AR CARD Request from a MN before declaring the message exchange aborted. AR_AR_CARD_TIMEOUT: This timer value indicates the timeout of an expected CARD Reply message on an AR after a previously released CARD Request message has been sent to a CAR. AR_AR_CARD_RETRIES: This value indicates the number of retries when sending an AR-AR CARD Request from a MN's current AR to a CAR before declaring the message exchange aborted. 8. IANA CONSIDERATIONS This section is to provide the Internet Assigned Numbers Authority (IANA) with guidelines to allow assignment and registration of values related to the Candidate Access Router Discovery protocol, in accordance with [11]. The protocol described in this document requires a new ICMP type to be assigned by the IANA for the CARD protocol main header (section 5.1.1). Furthermore, two new ICMP-option types (section 5.1.2) are to be assigned through IETF consensus [11] for the protocol operation between a Mobile Node and its current Access Router. The new ICMP options to be assigned by the IANA shall be used for the CARD Request (section 5.1.2.1) and the CARD Reply (section 5.1.2.2) options. The protocol also requires a UDP port number to be assigned through IETF consensus for the inter-Access Router CARD protocol operation (section 5.2.1). [Page 29] Internet-Draft Candidate Access Router Discovery June 2003 9. NORMATIVE REFERENCES [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [4] Kempf, J.,"Problem Description: Reasons For Performing Context Transfers Between Nodes in an IP Access Network", RFC 3374, September 2002. [8] Narten, T., et al., "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998. [9] Postel, J., "User Datagram Protocol", RFC 768, August 1980. [10]Atkinson, R., Kent, S.,"IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998. [11]Narten, T., Alvestrand, H., "Guidelines for Writing an IANA Considerations Section in RFCs", RFC 2434, October 1998. 10. INFORMATIVE REFERENCES [2] Trossen, D., Krishanmurthi, G. Chaskar, H., Kempf, J. "Issues in candidate access router discovery for seamless IP-level handoffs", draft-ietf-seamoby-cardiscovery-issues-04.txt, work in progress, October 2002. [3] Krishanmurti, G., "Requirements for CAR Discovery Protocolsö, draft-ietf-seamoby-card-requirements-02.txt, work in progress, October 2002. [5] Kenward, B.,"General Requirements for Context Transfer", draft- ietf-seamoby-ct-reqs-05.txt, work in progress, October 2002. [6] Manner, J., Kojo, M. (Ed), "Mobility Related Terminology", draft-ietf-seamoby-mobility-terminology-04.txt, work in progress, April 2003. [7] Koodli, R, et al., "Fast handoffs for Mobile IPv6", draft-ietf- mobileip-fast-mipv6-06.txt, work in progress, March 2003. [12]Funato, D. et al.,"Geographically Adjacent Access Router Discovery Protocolö, draft-funato-seamoby-gaard-01.txt, work in progress, June 2002. [13]Trossen, D. et al.,"A Dynamic Protocol for Candidate Access- Router Discovery", draft-trossen-seamoby-dycard-01.txt, work in progress, March 2003. [Page 30] Internet-Draft Candidate Access Router Discovery June 2003 [14]Shim, E., Gitlin, R.,"Fast Handoff Using Neighbor Information", draft-shim-mobileip-neighbor-00.txt, work in progress, November 2000. [15]El Malki, K. et. al, "Low Latency Handoffs in Mobile IPv4", draft-ietf-mobileip-lowlatency-handoffs-v4-05.txt, work in progress, June 2003. 11. AUTHORS' ADDRESSES Hemant Chaskar Nokia Research Center 5 Wayside Road Burlington, MA 01803, USA Phone: +1 781-993-3785 Email: Hemant.Chaskar@nokia.com Daichi Funato NTT DoCoMo USA Labs 181 Metro Drive, Suite 300 San Jose, CA 95110, USA Phone: +1 408-451-4736 Email: funato@docomolabs-usa.com Marco Liebsch NEC Network Laboratories Kurfuersten-Anlage 36 , 69115 Heidelberg Germany Phone: +49 6221-90511-46 Email: marco.liebsch@ccrle.nec.de Eunsoo Shim NEC Laboratories America, Inc. 4 Independence Way Princeton, NJ 08540, USA Phone: +1 609-951-2909 Email: eunsoo@nec-labs.com Ajoy Singh Motorola Inc 1501 West Shure Dr, USA Phone: +1 847-632-6941 Email: asingh1@email.mot.com [Page 31] Internet-Draft Candidate Access Router Discovery June 2003 12. IPR STATEMENTS The IETF has been notified of intellectual property rights claimed in regard to some or all of the specification contained in this document. For more information consult the online list of claimed rights. Please refer to http://www.ietf.org/ietf/IPR for more information. 13. COPYRIGHT NOTICE "Copyright (C) The Internet Society (date). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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." 14. ACKNOWLEDGEMENTS The CARD design team would like to thank Erik Nordmark for providing valuable insight about the piggybacking of CARD options upon Fast Mobile-IPv6 messages. In addition, the design team would like to thank (in alphabetical order) Dirk Trossen, Govind Krishnamurthi, James Kempf, Madjid Nakhjiri, Pete McCann, Rajeev Koodli, Robert C. Chalmers and other members of the Seamoby WG for their valuable comments on the previous versions of the draft as well as for the general CARD related discussion and feedback. [Page 32] Internet-Draft Candidate Access Router Discovery June 2003 APPENDIX A: MAINTENANCE OF ADDRESS MAPPING TABLES IN ACCESS ROUTERS This appendix gives information on two optional CAR table maintenance schemes for reverse address mapping in access routers. Appendix A.1 Centralized Approach using a Server Functional Entity Appendix A.1.1 Approach The centralized approach works when the MN has IP-layer connectivity with only the current AR. However, the MN can scan L2 beacons from neighboring AP(s) and thereby deduce their L2 ID(s). For example, 802.11 families of MN or cellular handsets with the mobile-assisted handover capability can do this. Figure A.1.1 illustrates the centralized CARD operation. In this operation, ARs have registered their address information with a CARD server in advance. When a MN discovers the L2 ID of APs during L2 scanning, the MN passes one or more L2 ID(s) to its current AR and the AR resolves it to the IP address of the AR. For this, the AR first checks whether the mapping information is locally available in its CAR table. If not, the MN's current AR queries a CARD server with the L2 ID. In response, the CARD server returns the IP address of the CAR to the current AR. Then, the current AR directly contacts the respective CAR and performs capability discovery with it. The current AR then passes the IP address of the CAR and associated capabilities to the MN. The current AR stores the resolved IP address within its local CAR table. The centralized CARD protocol operation introduces additional signaling messages, which are exchanged between the MN's current AR and the CARD server. The signaling messages are shown with the preceding identifier "AR-Server", referring to the associated interface. An initial idea of performing reverse address translation using a centralized server has been described in [12]. [Page 33] Internet-Draft Candidate Access Router Discovery June 2003 +----------+ +------------>| CARD |<-------------+ |+------------| Server |-------------+| || +----------+ || || || || ~~~~~~~~~~~ || (3)AR-Server||(4)AR-Server{ } || (0) CARD CARD || CARD { } ||Registration Request || Reply { IP Cloud } |Request/Reply || { } || || { } || |V ~~~~~~~~~~~ V| +---------+ (5)AR-AR CARD Request +-----+-----+ | Current |------------------------->| CAR | CAR | | AR |<-------------------------| 1 | 2 | +---------+ (6)AR-AR CARD Reply +-----+-----+ ^ | | | (2)MN-AR | |(7)MN-AR | | CARD | | CARD | | Request| V REPLY +---+ +---+ +--------------+ (1) AP1 L2 ID +--|AP1| |AP2| | Mobile |<---------------------+ +---+ +---+ | Node |<--------------------------------+ +--------------+ (1) AP2 L2 ID Figure A.1.1: Centralized Approach for L2-L3 mapping Appendix A.1.2 Associated Protocol Operation Figure A.1.2 shows the timing diagram of the centralized CARD protocol operation. In this figure, the CAR registration process is done before the CARD discovery process (0). CARs register with the CARD server when the CAR is initialized or when the status of the APs' L2 ID, which are associated with the CAR, changes. The CAR MAY also periodically register with the CARD server to update the list of current AP(s) that it supports. The CAR discovery process in the centralized approach is initiated as soon as a MN discovers the L2 ID of a nearby AP during the periodic L2 scanning. The MN sends the L2 ID to its current AR with a MN-AR CARD Request message. If the identity and capability information of the requested CAR is not available in the AR's local CAR table, the current AR subsequently sends an AR-Server CARD Request message to the CARD server to resolve the IP address of the serving AR of the newly discovered AP. The CARD server then resolves the received L2 ID(s) to the IP address of the associated CAR(s) and [Page 34] Internet-Draft Candidate Access Router Discovery June 2003 returns the identity of the CAR(s) to the requesting AR using the AR-Server CARD Reply message. MN current AR CARD Server CAR | | | (Candidate | | | Access | | | Router) | | | | | | | Registration Req | | | |<--------------------| | <~ ~ ~ L2-SCAN (1) | | Registration Reply | | | |-------------------->| | | | | | | | | |MN-AR CARD Request(2)| | | |-------------------->| | | | | AR-Server | | | | CARD Request(3) | | | |------------------>| | | | AR-Server | | | | CARD Reply(4) | | | |<----------------- | | | | | | | | AR-AR CARD Request(5) | | |---------------------------------------->| | | | | | | AR-AR CARD Reply (6) | | |<----------------------------------------| | | | | | MN-AR CARD Reply(7) | | | |<--------------------| | | | | | | | | | | | | | | Figure A.1.2 CARD procedure using a server function for maintenance of reverse address translation information in ARs' CAR tables. Upon receipt of the AR-Server CARD Reply message, the MN's current AR extracts the IP address of the CAR and subsequently requests remaining capabilities by sending an AR-AR CARD Request message to [Page 35] Internet-Draft Candidate Access Router Discovery June 2003 the CAR. The CAR conveys its capabilities to the requesting AR in an AR-AR CARD Reply message. Upon receipt of the AR-AR CARD Reply message, the current AR caches the CAR's capabilities as well as the associated L2-L3 mapping information in its local CAR table and conveys the requested capabilities and address information to the MN using the MN-AR CARD Reply message. Appendix A.1.3 Associated Protocol Messages A.1.3.1 CARD Message Transport for the interface between an AR and the CARD Server For the centralized CARD operation between an AR and the CARD server, UDP is used as transport protocol for CARD protocol messages. A UDP port is T.B.A. To authenticate protocol messages between ARs, IPsec ESP is to be used. A.1.3.2 Protocol Main Header The protocol main header for this interface is the same as used for the interface between ARs on network side, and is described in section 5.2.2. Because ARs need to register with the CARD server function, two additional message types have been specified, which is a CARD Registration Request and a CARD Registration Reply message. The following table lists message types specified for CARD as used between an AR and the CARD server function: Message types specified for this interface: Message Type ------------------------------------ AR-Server CARD Request 0x03 AR-Server CARD Reply 0x04 CARD Registration Request 0x05 CARD Registration Reply 0x06 For the registration related message types, an additional payload type is required and described in section A.1.3.3. [Page 36] Internet-Draft Candidate Access Router Discovery June 2003 A.1.3.3 Protocol Payload Types Payload types and encoding rules are the same as described for the various sub-option types in section 5.1 for the MN-AR interface. The same TLV-encoded format is used to append the options to the protocol main header. For the registration of an AR with a CARD server function, an additional payload type is required to indicate the lifetime of the associated AR's registration. The lifetime option is encoded as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type: T.B.A Length: 0x08 - Length of the lifetime payload option in octets (including type and length fields). Reserved: To be initialized with 0. Lifetime: Indicates the lifetime of a registration in seconds. If the lifetime is set to '0', this indicates a de- registration with a CARD server function. Appendix A.1.4: Associated Security Considerations A.1.4.1 Security Associations The AR-CARD Server communication must be protected using IPsec ESP and a previously established security association. [Page 37] Internet-Draft Candidate Access Router Discovery June 2003 A.1.4.2 DoS Attack The MN-AR communication presents opportunities to an attacker. A rogue MN can use CARD as a denial-of-service (DoS) attack against an AR. It could also flood the backend AR-Server and AR-AR communications. If the MN undertakes a DoS attack by flooding its current AR with real or bogus L2 IDs, the CARD protocol should prevent it. When the AR has an authentication scheme for MNs, it is difficult for a rogue MN to change its identity. Hence, one possible solution is to limit the number of requests from an identical MN within a unit of time. A.1.4.3 CAR Table Contamination When an AR allows caching, CAR table contamination could occur. A MN provides the current AR with unauthenticated observations of AP identifiers that it can hear. Then the AR asks for the authenticated AR information using the CARD server. The CARD server can tell only that there is a registered AR with the given L2 ID, but it cannot tell whether the AR is a CAR of the current AR. (Note that CAR needs to have an access point geographically adjacent to current AR's APs). The current AR relies on the fact that a MN provided the L2 ID that matches a registered AR. A malicious MN may provide a L2 ID, which is the L2 ID of a registered AR but not a CAR of the current AR, that is, has no overlapping coverage with the current AR. Then the current AR would build a CAR table with the IP addresses of ARs that are not CARs. This has implications on the size of CAR table that can be allowed on ARs. A more serious implication is that, if a large number of non-CAR entries appear in the AR'S CAR table, the AR spends processing resources in exchanging capabilities with them. There is a possible solution for this. The ARs can handle this by making the CARD information soft state, so that it times out the AP addresses if it does not receive a confirmation from another MN within a certain period of time. Thus, any bogus information has only a limited lifetime, and even within that lifetime, it cannot do more than to occupy a table slot in the AR's memory. In fact, the AR can use the number of MNs reporting a particular address to weight the relevance of a reported AP. So, if 20 MNs report it, the AP address is more likely to stick around than if only one MN reports it. This is an issue for implementation rather than a protocol issue. However, this issue could not be a problem in actual handover cases. At the time of handover, the MN or AR receives the L2 ID of the AP to which the MN is moving. Or the MN matches the AP L2 ID in the CAR table with the address of the APs it can hear. Thus, an AP's L2 ID [Page 38] Internet-Draft Candidate Access Router Discovery June 2003 that is provided by a malicious MN, but has no wireless connectivity to the CAR, is filtered out when a MN or AR uses the information for handover, so this can do no harm at the time of handover. Appendix A.1.5 Associated IPR statements The IETF has been notified of intellectual property rights claimed in regard to some or all of the specification contained in this Appendix A.1. For more information consult the online list of claimed rights. Please refer to http://www.ietf.org/ietf/IPR for more information. [Page 39] Internet-Draft Candidate Access Router Discovery June 2003 Appendix A.2 Decentralized Approach using Mobile Terminals' Handover Appendix A.2.1 Approach This approach performs CARD over the MN-AR interface as described in Section 4. However, it employs one additional message, called the Router Identity message, over the MN-AR interface to enable ARs to learn about the reverse address translation tables of their neighboring ARs, without being dependent on any centralized server. In this approach, CAR identities in the CAR table of an AR are maintained as soft states. In other words, the entries for CARs are removed from CAR table if not refreshed before the timeout period. The entries for CAR identities in CAR table are created/refreshed according to following mechanism. The key idea behind the decentralized approach is to bootstrap and maintain the association between two ARs as neighbors of each other, using the actual handover of MNs occurring between them as input. The first handover between any two neighboring ARs serves as the bootstrap handover, which invoke the discovery procedure and the subsequent handover serve to refresh the association between the neighboring ARs. After the bootstrap handover, the MNs can perform CARD and thus seamless handover using the CAR information. This idea was presented in [13] and [14]. Appendix A.2.2 Associated Protocol Operation CAR table maintenance using the Router Identity message: Upon the completion of an inter-AR handover, the MN SHOULD send a Router Identity message to its current AR. This message contains the identity (IP address) of the previous AR (pAR), which is already known to the MN. This message is sent as a specific sub-option in the MN-AR CARD Request (see below). It SHOULD be acknowledged with the MN-AR CARD Reply. The Router Identity message enables the MN's current AR to learn that the pAR (still) has an AP whose coverage overlaps with one of the APs of the current AR and vice versa. With this information, the MN's current AR can create or refresh an entry for the pAR as its neighbor. If handover cease between two particular ARs, the associated entries will eventually timeout and removed from each AR's CAR table. Prior to trusting the MN's report, however, the current AR may perform a number of checks to ensure the validity of the received information. As one simple method to verify the accuracy of the Router Identity message, the current AR sends an AR-AR CARD Request [Page 40] Internet-Draft Candidate Access Router Discovery June 2003 message to the pAR. The AR-AR CARD Request includes the identity of the MN. Upon receiving this message, the pAR has to verify that the said MN was indeed attached to it during a reasonable past and respond to the current AR. In this way, each handover of a MN results in a bi-directional discovery process between the two participating ARs. Upon receiving positive verification response, the current AR creates or refreshes as applicable, the entry for the pAR in its local CAR table. In the former case, the current AR and the pAR exchange capabilities using the AR-AR CARD Request and AR-AR CARD Reply protocol messages. When a new entry is created, the ARs MUST exchange their reverse address translation tables. They may exchange other capabilities at this time or may defer it to later time when some MN undergoing handover between them performs CARD as described in Section 4. In the later (refresh) case, ARs may exchange capabilities or defer it until later time when some MN undergoing handover between them performs CARD as described in Section 4. +--------------+ (4)AR-AR CARD Request +----------+ | Current |------------------------->| pAR | | AR |<-------------------------| | +--------------+ (5)AR-AR CARD Reply +----------+ ^ | . | |(3) ACK . Router | | . Identity V . Message (2)+--------------+ +---------------+ | Mobile | | Mobile | | Node |<-- Inter AR Handoff | Node | +--------------+ (1) +---------------+ Figure A.2.1 Use of Router Identity Message for CAR Table Maintenance Finally, note that, in a handover-based protocol, a first handover between a pAR and a MN's current AR (without regard to direction, MN identity and which APs are involved) cannot use CARD, as this handover would bootstrap the CAR table. However, it is hoped that in long term such handover will only amount to a small fraction of total successful handover between pAR and the MN's current AR. Also, if the user of the MN engaging in such first handover is running a non-delay sensitive application at the time of handover, the user may not even realize its impact. [Page 41] Internet-Draft Candidate Access Router Discovery June 2003 Appendix A.2.3 Associated Protocol Messages Router Identity Message Format: The dynamic handover based approach requires a MN to convey the pAR's IP address to its current AR. The pAR's IP address is conveyed from the MN to its current AR as using the following CARD protocol message sub-option. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Sub-Option Type|Sub-Option Len | pAR ID .... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - - Sub-Option Type: T.B.A Sub-Option Length: Length of the Sub-Option in units of octets. pAR ID: IP address of the pAR. The MN's current AR SHOULD acknowledge the receipt of the Router Identity message using the ACK sub-option described below. 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Sub-Option Type|Sub-Option Len | ACK | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Sub-Option Type: T.B.A Sub-Option Length: Length of the Sub-Option in units of octets. ACK: All 1's. [Page 42] Internet-Draft Candidate Access Router Discovery June 2003 Appendix A.2.4 Associated Security Considerations In the design of this protocol, a few assumptions have been made about the security model in place between the MN and the AR, and between ARs. In particular, it has been assumed that prior to any protocol messaging, the AR has authenticated and authorized the MN to participate in CARD. Moreover, in order for two ARs to cooperate without introducing serious security concerns, they must be able to establish a security association. For intra-domain routers, this could be as simple as a shared secret key. For the inter-domain scenario, the two domains must have a previously established relationship that can be leveraged to derive an adequate session key. All messages listed herein should be protected by means of IPsec ESP to provide authentication and to ensure message integrity. Appendix A.2.5 Associated IPR Statements The IETF has been notified of intellectual property rights claimed in regard to some or all of the specification contained in this Appendix A.2. For more information consult the online list of claimed rights. Please refer to http://www.ietf.org/ietf/IPR for more information. [Page 43] Internet-Draft Candidate Access Router Discovery June 2003 APPENDIX B: APPLICATION SCENARIOS This section provides two examples of an application scenario for the CARD protocol operation. One scenario describes CARD protocol operation in a Mobile IPv6 (MIPv6) enabled network, providing access to the infrastructure via wireless LAN Access Points and associated Access Routers. A second scenario describes CARD protocol operation in a Mobile IPv6 enabled network, which has enhanced support for fast handover integrated (Fast Mobile-IPv6), also providing wireless LAN access to the infrastructure. Appendix B.1 CARD Operation in a Mobile-IPv6 Enabled Wireless LAN Network This application scenario assumes a moving MN having access to the infrastructure through wireless LAN (IEEE802.11) APs. Location tracking is performed using the Mobile IPv6 protocol. The following figure illustrates the assumed network sector for description of CARD protocol operation. ----------------------------- / \ +----+ | NETWORK |---| HA | \ / +----+ ----------------------------- | | +-----+ +-----+ | AR1 |---------+ | AR2 | +-----+ | +-----+ | subnet 1 | |subnet 2 +-----+ +-----+ +-----+ | AP1 | | AP2 | | AP3 | +-----+ +-----+ +-----+ ^ ^ ^ \ \ \ v +-----+ | MN | - - ->>>- - - ->>> +-----+ Figure B.1: Assumed network topology A Mobile IPv6 Home Agent (HA), which is connected to the network, maintains location information of the MN in its binding cache. According to Figure B.1, the MN holds currently a care-of address for the subnet 1, supported by AR1, which is registered with its HA. [Page 44] Internet-Draft Candidate Access Router Discovery June 2003 According to the MN's movement, the MN's current environment offers two further wireless LAN APs with increasing link-quality as candidate APs for a handover. To allow the MN taking a decision, on which AP might be the better choice, not only access link quality parameters, but also parameters associated with ARs should be taken into account for the decision process. These AR-related parameters can be, for example, available QoS resources or the type of access technologies supported from an AR. To learn about these candidate ARs' capabilities and associated IP address information, the MN performs CARD. This requires retrieving information about candidate APs' L2 ID, which is broadcast via beacon information from respective APs. Furthermore, associated link-quality parameters are to be retrieved to ascertain, whether or not approaching APs are eligible candidates for a handover. Assume AP2 and AP3 to be suitable candidate APs. The MN encapsulates both L2 IDs (AP2 and AP3) into a CARD Request message, using the L2 ID sub-option, and sends it to its current AR (AR1). AR1 resolves each L2 ID, listed as L2 ID options in the received CARD Request, to the associated IP address of the respective AR, making use of its local CAR table. According to the environment illustrated in Figure B.1, the associated AR IP address of the candidate AP2 will be the same as the MN is currently attached to, which is AR1. Respective IP address of the candidate AR, to which AP3 is connected to, is the address of AR2. Since IP addresses of the MN's CARs are now known to AR1, AR1 retrieves CARs' capabilities from the CAR table, assumed it has valid entries for respective capability parameters in the local CAR table. To ascertain dynamic capabilities, of which lifetime in AR1's CAR table has been expired, AR1 performs inter-AR CARD for capability discovery. Since capability information of AR1 is known to AR1, a respective inter-AR CARD Request is to be sent only to AR2. AR2 in response sends a CARD Reply message back to AR1, having the requested capability parameters encapsulated with the signaling message, all assembled in a capability container sub-option. Now, AR1 sends its own capabilities and the dynamically discovered ones of AR2 back to the MN via a CARD Reply message. Furthermore, AR1 stores the capability parameters of AR2 with the associated lifetimes in its local CAR table. On reception of the CARD Reply message, the MN performs target AR selection, taking AR1's and AR2's capability parameters as well as associated APs' link-quality parameters into account. In case the selected AP is AP2, no IP handover needs to be performed. In case AP3 and the associated AR2 are selected, the MN needs to perform an IP handover according to the Mobily-IPv6 protocol scenario. Figure B.2 illustrates the signaling flow of the previously described application scenario of CARD within a Mobile-IPv6 enabled network. [Page 45] Internet-Draft Candidate Access Router Discovery June 2003 MN AP1 AR1 AP2 AP3 AR2 | | | | | | | connected | | | | | 0-------------0-------0 | | | | | | | | | | | | | | | | | | | | <~~~~~~~~~L2-SCAN (AP2)~~~~~| | | | <~~~~~~~~~L2-SCAN (AP3)~~~~~~~~~~~~~~~~~| | | | | | | (MN-AR) CARD Req | | | | |-------------------->| (AR-AR) CARD Req | | | |---------------------------------------->| | | | (AR-AR) CARD Repl | | (MN-AR) CARD Repl |<----------------------------------------| |<--------------------| | | | | | | | | | [target AR | | | | | selection] | | | | | | | | | | | // // // // // // [either...] | | | | | | | | | | | |-------- L2 attach --------->| | | | | | | | | | connected | | | | 0---------------------0-------0 | | | | | | | | // // // // // // [... or] | | | | | | | | | | | |--------------- L2 attach -------------->| | | | | | | | | connected | | | | 0-----------------------------------------0---------------------0 | | | | | | | | | | MIPv6 Binding Update to the HA | | |------------------------------------------------ - - - > | | | | | | | Figure B.2: CARD protocol operation within a Mobile-IPv6 enabled wireless LAN network. [Page 46] Internet-Draft Candidate Access Router Discovery June 2003 Appendix B.2 CARD Operation in a Fast Mobile-IPv6 Enabled Network This application scenario assumes ARs to be able to perform the fast handover protocol sequence for Mobile IPv6 [7]. The MN scans for new APs to handover to, similar to what Figure B.1 illustrates. To discover candidate APs' associated ARs (CARs), the MN attaches a MN- AR CARD Request option to the ICMP-type Fast Mobile-IPv6 RtSolPr message, which is sent to the MN's current AR (pAR, previous AR). Candidate APs' L2 IDs are encapsulated using the CARD protocol's L2 ID sub-options, which allows the MN to send multiple L2 IDs of candidate APs to its current AR (potentially replaces the "New Attachment Point Link-Layer Address" option of the Fast Mobile-IPv6 protocol). The pAR resolves the received list of candidate APs' L2 IDs to the IP address of associated CARs. Furthermore, the pAR checks its local CAR table to retrieve information about the CARs' capabilities. In case one or multiple associated capability entries of a CAR have expired, the pAR acquires this CAR's capabilities by means of sending an AR-AR CARD Request to the respective CAR. The CAR replies to the requesting pAR with an AR-AR CARD Reply message, having all capabilities encapsulated in a capability container sub-option and attached to the CARD Reply option. On reception of the CARs' capability information, the pAR updates its local CAR table and forwards the address and capability information of the MN's CAR(s) to the MN by means of attaching a MN-AR CARD Reply option, carrying appropriate address and capability container sub-options, to the Fast Mobile-IPv6 PrRtAdv message. When the MN's handover is imminent, the MN selects its new AR and the associated new AP from the discovered list of CARs. According to the Fast Mobile-IPv6 protocol, the MN notifies the pAR of the selected new AR with the Fast Binding Update (F-BU) message, which allows the pAR to perform further protocol sequences for a fast handover according to the Fast Mobile-IPv6 protocol. Optionally, the pAR could perform selection of an appropriate new AR on behalf of the MN after the pAR has the MN's CARs' addresses and associated capabilities available. To allow for selection of an appropriate new AR out of the list of CARs, the MN must send its requirements for the selection process to its pAR together with the MN-MN CARD Request message, appended as a list of attribute-value pairs carried with the CARD protocol's Requirements sub-option. After the pAR has selected the MN's new AR, the address and associated capabilities of the chosen new AR are notified to the MN with the CARD Reply option, which is conveyed to the MN with the Fast Mobile-IPv6 PrRtAdv message. [Page 47] Internet-Draft Candidate Access Router Discovery June 2003 Note: Since the CARD protocol functions and the CARD Request and CARD Reply message provide all information of the RtSolPr and PrRtAdv in a flexible way with regard to discovery and selection of a new AR during a handover process, the CARD Request and CARD Reply options could potentially replace the Fast Mobile-IPv6 RtSolPr and PrRtAdv protocol messages respectively. Figure B.3 illustrates how CARD protocol messages and functions could perform together with the Fast Mobile-IPv6 protocol. MN pAR NAR CAR2 | | as CAR1 | | | | | |-------RtSolPr------>| | | | [MN-AR CARD Req] |-- AR-AR CARD Req*->| | | |-- AR-AR CARD Req*------------>| | |<--AR-AR CARD Repl*------------| | |<--AR-AR CARD Repl*-| | |<------PrRtAdv-------| | | | [MN-AR CARD Repl] | | | | | | | NAR selection | | | |------F-BU---------->|--------HI--------->| | | |<------HACK---------| | | <--F-BACK--|--F-BACK--> | | | | | | Disconnect | | | | forward | | | packets===============>| | | | | | | | | | Connect | | | | | | | RS (with FNA option)======================>| | |<-----------RA (with NAACK option)--------| | |<=================================== deliver packets | | | | Figure B.3: Fast Handover protocol sequence with CARD protocol options *): The CARD protocol interaction between the pAR and CARs is only required in case the lifetime of one or multiple capability entries of the pAR's local CARD table have been expired. Otherwise, the pAR can respond to the requesting MN immediately after having the CARs' address and capability information retrieved from its local CAR table. [Page 48] Internet-Draft Candidate Access Router Discovery June 2003 [Page 49]