IETF Seamoby Working Group
Internet Draft                                            Marco Liebsch
                                                             Ajoy Singh
                                                              (Editors)
                                                         Hemant Chaskar
                                                          Daichi Funato
                                                            Eunsoo Shim
draft-ietf-seamoby-card-protocol-03.txt
Expires: February 2004                                      August 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 . . . . . . . . . . . . . . . . . . . 35

   11. AUTHORS' ADDRESSES . . . . . . . . . . . . . . . . . . . . . 36

   12. IPR STATEMENTS . . . . . . . . . . . . . . . . . . . . . . . 36

   13. COPYRIGHT NOTICE . . . . . . . . . . . . . . . . . . . . . . 36

   14. ACKNOWLEDGEMENTS . . . . . . . . . . . . . . . . . . . . . . 37

   Appendix A  MAINTENANCE OF ADDRESS MAPPING TABLES IN
               ACCESS ROUTERS . . . . . . . . . . . . . . . . . . . 38
   Appendix A.1 Centralized Approach using a Server Functional
                 Entity . . . . . . . . . . . . . . . . . . . . . . 39

   Appendix A.2  Decentralized Approach using Mobile Terminals'
                 Handover . . . . . . . . . . . . . . . . . . . . . 41
   Appendix B  APPLICATION SCENARIOS. . . . . . . . . . . . . . . . 42
   Appendix B.1 CARD Operation in a Mobile-IPv6 Enabled Wireless
                LAN Network . . . . . . . . . . . . . . . . . . . . 43
   Appendix B.2 CARD operation in a Fast Mobile-IPv6 enabled
                network . . . . . . . . . . . . . . . . . . . . . . 46



                                                              [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 discovery of
   capabilities.


   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 others can change with time.

   Definition of capabilities is out of scope of this document. 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 periodically
   advertises address and capability information of CARs to the MNs over
   downlink channels without being previously solicited from a MN.


                                                              [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 ARs to
   populate and maintain their local CAR table (section 4.1) with the
   capabilities of CARs. For this, the CARD protocol makes use of a
   CARD Request and CARD Reply protocol message between a MN and its
   current AR (section 5.1.2), and between a MN's current AR and
   individual CARs respectively (section 5.2.2).

   To allow MNs retrieving its CARs' address and capability
   information, the CARD Request and CARD Reply messages used between a
   MN and its current AR contain one or more access points' L2 ID and
   the IP address of associated CARs respectively. Optionally, the CARD
   Reply messages can also contain CARs' capability information. A
   CAR's capabilities are specified as a list of attribute-value pairs,
   which is conveyed in a Capability Container message parameter.

   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 multicast from ARs. 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.


   The CARD protocol also enables a MN to optionally indicate its
   preferences on capabilities of interest to its current AR by
   including the Preferences message parameter in the CARD Request
   message. The MN's current AR MAY use this information to perform
   optional capability pre-filtering for optimization purposes and
   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.


                                                              [Page 7]


Internet-Draft     Candidate Access Router Discovery         June 2003


   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.

   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.










                                                              [Page 8]


Internet-Draft     Candidate Access Router Discovery         June 2003



          +--------------+  (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). In case the MN wants its AR to
   perform capability discovery in addition to reverse address
   translation, this must be indicated in the MN-AR CARD Request
   message by means of setting the C-flag. Without setting the C-flag,
   the AR receiving the CARD Request message will perform only reverse
   address translation. 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
   any 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 via 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, in case capability information has been requested,
   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 MN MUST send
   only one CARD Request per CARD_RETRANSMISSION_INTERVAL and not more
   than CARD_MAX_RETRIES. If the MN sends requests more frequently, the
   AR SHOULD drop the CARD requests and not process them.



                                                              [Page 9]


Internet-Draft     Candidate Access Router Discovery         June 2003

   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 SHOULD 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. If the
   MN wants its AR performing only reverse address translation without
   appending CARs' capabilities to the CARD Reply, the MN refrains from
   setting the C-flag in the CARD Request message. If the MN wants to
   perform capability discovery, the CARD Request MUST have the C-flag
   set. 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 indicate the cut off values of the
   capabilities for the desired CAR(s).

   In case the MN appends multiple L2 ID sub-option to a CARD Request
   for being resolved by its current AR, each L2 ID MUST be assumed
   belonging to an AP, which connects to a different CAR. Since L2 IDs,
   address information and capability information comes with separate
   sub-options within one CARD protocol message, each sub-option


                                                             [Page 10]


Internet-Draft     Candidate Access Router Discovery         June 2003

   carries a Context-ID, which allows matching parameters, which belong
   together. Hence, the MN MUST assign different Context-ID values to
   the L2 ID sub-options it appends to the CARD Request message. The
   Status-Code field in the CARD Request message MUST always be set to
   NONE (0x00) by a MN.

   When sending the CARD Request protocol message, the MN MUST set the
   message's sequence number to allow correlation of replies with
   requests. Successive CARD Request protocol messages must have the
   sequence number incremented by one respectively.

   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.

   Processing the Context-ID of Address sub-options allows the MN to
   assign the resolved IP address of a specific CAR to a L2 ID.

   RESOLVER ERROR Status-Code indication:
   In case the MN's current AR could not resolve a particular L2 ID,
   which has previously sent to the AR in a CARD Request, this L2 ID
   sub-option comes back with the CARD Reply to the requesting MN,
   indicating RESOLVER ERROR in the Status-Code field of the L2 ID sub-
   option.

   MATCH Status-Code indication:
   In case a L2 ID belongs to an AP that connects to the same CAR as an
   AP, whose L2 ID has been requested in the same CARD Request message
   and already been resolved by the AR, the respective L2 ID sub-option
   comes back to the requesting MN, indicating MATCH in the Status-Code
   field. This status code is an indicator, that the Context-ID of this
   L2 ID sub-option has been adapted to the Context-ID of the
   associated CAR's Address and Capability Container sub-option, coming
   with this CARD Reply. This approach avoids sending the same CAR's
   address and capability information multiple times with the same CARD
   Reply message in case two or more L2 IDs resolve to the same CAR.

   CANDIDATE Status-Code indication:
   In case the MN does not append a particular L2 ID to the CARD
   Request, an AR send back L2 ID and address information of all CARs.
   Since these L2 IDs' Context-IDs cannot be correlated with a L2 ID
   Context-ID of a previously sent request, the AR has chosen values
   for the Context-ID and marks these candidate L2 IDs with CANDIDATE
   in the status code of the distributed L2 IDs. However, individual
   values of L2 ID Context-IDs allow the MN to assign the L2 ID to the
   associated Address and possibly received Capability Container sub-
   option.



                                                             [Page 11]


Internet-Draft     Candidate Access Router Discovery         June 2003


   4.2.2 Current Access Router Operation

   Upon receipt of a 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, assumed the MN
   requests CARs' capabilities with the CARD Request having the C-flag
   set.
   In the first case, where the AR resolves only requested L2 IDs, the
   AR does not send back the L2 ID to the requesting MN. Only in case
   two or more L2 IDs match the same CAR information, L2 ID sub-option
   is sent back to the MN, indicating MATCH in the Status-Code field of
   the L2 ID. Furthermore, the AR sets the Context-ID of the returned
   L2 ID to the same value of the resolved CAR's L2 ID, Address and
   Capability Container sub-option. In case an AR cannot resolve a
   particular L2 ID, this L2 ID sub-option is to be sent back to the
   MN, indicating RESOLVER ERROR in the L2 ID sub-option's Status-Code
   field.
   In the second case, where the AR did not receive any L2 ID with a
   CARD Request, all candidate APs' L2 IDs are sent to a requesting MN
   with the CARD Reply message. Here, the AR marks the Status-Code of
   individual L2 IDs as CANDIDATE, indicating to the MN, that the
   associated Context-ID cannot be matched with the ID of a previously
   sent request to resolve a particular L2 ID.

   In any case, the AR MUST set the Context-ID of the Address and the
   Capability Container sub-option to the same value of the associated
   L2 ID sub-option.

   Optionally, when allowed by local policies and supported by
   respective ARs for capability discovery, 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. 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
   an AR to send periodic unsolicited CARD Reply messages to all
   connected mobile nodes. The unsolicited CARD Reply is delivered via


                                                             [Page 12]


Internet-Draft     Candidate Access Router Discovery         June 2003

   multicast to MN(s). The current AR sets the U-flag of the
   unsolicited CARD Reply to indicate that the message is being sent
   unsolicited. L2 ID sub-options, which append to an unsolicited CARD
   Reply message, MUST indicate CANDIDATE in the L2 ID sub-option's
   Status-Code. Consecutive unsolicited CARD Reply messages MUST have
   the sequence number incremented for each message respectively to
   counteract replay attacks. Subsequent unsolicited CARD Reply
   messages must be released within the interval
   MIN_CARD_ADVERT_INTERVAL and MAX_CARD_ADVERT_INTERVAL. The actual
   interval for an individual unsolicited CARD Reply is a randomly
   chosen value between these two boundary values.


   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 CAR 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.

   In case the AR-AR CARD Request conveys the current AR's capabilities
   to the CAR, the associated Capability Container can have any value
   set for the Context-ID, since this field is not reasonable to be
   processed here anyway due to the absence of a L2 ID or an Address
   sub-option. Furthermore, the P-flag in the Capability Container sub-
   option MUST be set to 0, since this indication is needed only for
   the MN-AR interface.

   Optionally, a current AR MAY append the Preferences sub-option to
   the AR-AR CARD Request to obtain only capability parameters of
   interest from a CAR.

   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


                                                             [Page 13]


Internet-Draft     Candidate Access Router Discovery         June 2003

   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. In case the inter-AR CARD signaling has
   been initiated due to a previously received MN-AR CARD Request, the
   AR now sends the MN-AR CARD Reply to the Mobile Node.

   Optionally, CARs can send unsolicited CARD Reply messages to
   globally adjacent ARs. In case the current AR receives an
   unsolicited CARD Reply message from one CAR it has an entry for
   within his local CAR table, the current AR has to check that the
   sequence number of the received CARD Reply has increased compared to
   the previously received unsolicited CARD Reply message, which has
   been sent from the same CAR. Then, the current AR can update its
   local CAR table according to the received capabilities.


   4.3.2 Candidate Access Router Operation

   Upon receipt of an AR-AR CARD Request, a CAR shall extract the
   capabilities of the MN's current AR from the payload of the received
   message, assumed the sending AR appended its own capabilities to the
   AR-AR CARD Request. 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 responds 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 parameter. In case the sending AR has appended an
   optional Preferences sub-option, the CAR MAY perform capability
   filtering and send back only these capabilities, which are of
   interest to the requesting AR, identified according to the
   Preferences sub-option. Since the AR-AR CARD Reply is based on a
   previously received AR-AR CARD Request, the CAR MUST set the U-flag
   of the AR-AR CARD Reply to 0.

   Optionally, the CAR MAY send an unsolicited CARD Reply message to
   globally adjacent ARs in case one or more of its capability
   parameters change. The unsolicited CARD Reply messages should
   address globally adjacent ARs' unicast address and have the U-flag
   set. Consecutive unsolicited CARD Reply messages MUST have the
   sequence number incremented respectively. To avoid that unsolicited
   CARD Reply messages are sent too frequently, CARs SHOULD wait at
   least for MIN_CARD_UPDATE_INTERVAL before sending an updating
   message to a globally adjacent AR. The CAR MUST set the U-flag in
   unsolicited AR-AR CARD Reply messages.


                                                             [Page 14]


Internet-Draft     Candidate Access Router Discovery         June 2003


   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 Recovery

   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 MN 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 Recovery

   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 MAY 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 MAY start a timer
   (AR_AR_CARD_TIMER) after sending the AR-AR CARD Request with the
   given sequence number. The current AR should then 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 declares the
   outstanding AR-AR CARD Request as lost and then resends the same
   message to the CAR. The current AR MAY 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 15]


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' authenticity MUST be ensured 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 messages. It is also assumed that neighboring
   ARs SHALL establish an appropriate SA to secure the AR-AR CARD
   messages.



                                                             [Page 16]


Internet-Draft     Candidate Access Router Discovery         June 2003

   IPSec ESP MUST be used with a non-null integrity protection and
   origin authentication algorithm and SHOULD be used with a non-null
   encryption algorithm for protecting the confidentiality of the CARD
   information.



                                                             [Page 17]


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:
                        IPSec ESP MUST be used with a non-null
                        integrity protection and origin authentication
                        algorithm and SHOULD be used with a non-null
                        encryption algorithm for protecting the
                        confidentiality of the CARD information.

         ICMP Fields:

         Type           T.B.A (To be assigned)

         Code           0

         Checksum       The ICMP checksum.


                                                             [Page 18]


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


                                                             [Page 19]


Internet-Draft     Candidate Access Router Discovery         June 2003

                        CARs of interest, meaning CARs matching the
                        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


                                                             [Page 20]


Internet-Draft     Candidate Access Router Discovery         June 2003

                        option including the type and length fields in
                        units of octets.  The value 0 is invalid.


   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|C|       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.

               C-flag:  Indicates that the requesting entity is
                        interested also in associated CARs'
                        capabilities. If the MN wants the AR to append
                        CARs' capability parameters to the CARD Reply
                        in addition to address information, the MN must
                        set this flag.

               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

   To ensure meeting 32-bit boundary alignment of the entire CARD
   Request option, individual sub-options MUST take care of meeting 32-
   bit boundary alignment requirements respectively.


                                                             [Page 21]


Internet-Draft     Candidate Access Router Discovery         June 2003


   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|         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.

               U-flag:  Indicates an unsolicited CARD Reply.
                        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




   To ensure meeting 32-bit boundary alignment of the entire CARD Reply
   option, individual sub-options MUST take care of meeting 32-bit
   boundary alignment requirements respectively.


                                                             [Page 22]


Internet-Draft     Candidate Access Router Discovery         June 2003



   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:


            Sub-Option Name                         Type
            --------------------------------------------
            L2 ID                                   0x01
            Address                                 0x02
            Capability Container                    0x03
            Preferences                             0x04
            Requirements                            0x05


   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.


   Since some sub-options have variable lengths in value, it is to be
   ensured that individual sub-options meet requirement on 32-bit
   boundary alignment.


   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  |  Status Code  |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |    L2-Type    |     L2 ID . . .
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - -


   Sub-Option Type:
                  0x01



                                                             [Page 23]


Internet-Draft     Candidate Access Router Discovery         June 2003

   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.

   Status Code:   This field allows ARs to inform a requesting entity
                  about processing results of this L2 ID in case the L2
                  ID sub-option is sent back to the requesting entity
                  with a CARD Reply message.

                  The following status codes are specified:

                  0x00:    NONE - This value is to be set in case the
                           L2 ID is appended to a CARD Request.

                  0x01:   CANDIDATE - This value is to be set by an AR
                          when sending a L2 ID sub-option in a CARD
                          Reply for information of candidate APs' L2
                          IDs. Candidate L2 IDs can be sent either with
                          an unsolicited CARD Reply or in case a MN
                          does not request for resolution of specific
                          L2 IDs with a CARD Request. In this case, the
                          AR MUST set the Context-ID field
                          appropriately to allow matching associated
                          address and capability information on the
                          receiver side.

                  0x02:   MATCH - This value is set by an AR, which
                          has identified, that this particular L2 ID
                          matches the same CAR information that has
                          been resolved previously for a different L2
                          ID of the same CARD Request. The AR sets this
                          value for the Status Code, matches the
                          associated Context-ID to the one of the
                          previously resolved L2 ID and sends the L2 ID
                          back to the requesting entity.

                  0x03:   RESOLVER ERROR - This value is to be set by
                          an AR in case this particular L2 ID cannot be
                          resolved. To notify the requesting entity,
                          the AR sets this value for the Status Code
                          and sends the L2 ID sub-option back to the
                          requesting entity with the CARD Reply
                          message.



                                                             [Page 24]


Internet-Draft     Candidate Access Router Discovery         June 2003

   L2 type:       Indicates the interface type (optional)

                  If the L2 type indicator is not used, this field MUST
                  be set to 0x00.

   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:
                  0x04

   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:
                  0x05

   Sub-Option Length:
                  Length of the Sub-Option (including type and length
                  fields) in units of octets.


                                                             [Page 25]


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:
                  0x03

   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 26]


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:
                  0x02

   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 27]


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 MUST be
   used [10].


                                                             [Page 28]


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|U| Res.|     Type      |           Reserved            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                        Sequence Number                        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |            Payload ...
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - -


   Version:       Indicates the version of the protocol.
                  The version described in this document is version 1.

   U-flag:        Indicates an unsolicited AR-AR CARD Reply message if
                  set to 1. This flag MUST be set to 0 in case the CARD
                  Reply has been previously solicited or in case the
                  message is a CARD Request.

   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


   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 29]


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 30]


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
   adjacent 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 MUST 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 31]


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 MUST 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 32]


Internet-Draft     Candidate Access Router Discovery         June 2003


7. PROTOCOL CONSTANTS


   Mobile Node protocol constants:

   MN_AR_CARD_TIMEOUT:                 1 second

                        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:                 5

                        This value indicates the number of retries when
                        sending a MN-AR CARD Request from a MN before
                        declaring the message exchange aborted.


   CARD_RETRANSMISSION_INTERVAL:       1 seconds

   CARD_MAX_RETRIES:                   3



   Access Router protocol constants:

   AR_AR_CARD_TIMEOUT:                 1 second

                        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:                 3

                        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.

   MIN_CARD_ADVERT_INTERVAL (MN-AR):   1 seconds

   MAX_CARD_ADVERT_INTERVAL (MN-AR):   60 seconds






                                                             [Page 33]


Internet-Draft     Candidate Access Router Discovery         June 2003

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 option types (section 5.1.2) are to be
   assigned for the protocol operation between a Mobile Node and its
   current Access Router. Since these options may be appended to Fast
   Mobile IPv6 protocol messages [7] to perform CARD protocol message
   piggybacking (section 4.5), avoiding conflicts in option types must
   be taken into account. The new options types 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 for the inter-Access Router CARD
   protocol operation (section 5.2.1).

   This document authorizes IANA to assign the new ICMP type to the
   CARD protocol main header and to the CARD Request and CARD Reply
   option. For future assignment of capability APV codes (section
   5.1.4), it is recommended that assignment will be done on the basis
   of Designated Experts.


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



                                                             [Page 34]


Internet-Draft     Candidate Access Router Discovery         June 2003

   [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.

   [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


                                                             [Page 35]


Internet-Draft     Candidate Access Router Discovery         June 2003

   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


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



                                                             [Page 36]


Internet-Draft     Candidate Access Router Discovery         June 2003

   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 authors would like to thank Vijay Deverapali and Henrik Petander
for formally reviewing and providing valuable comments on the draft.
The authors would also like to thank Robert  C. Chalmers, James Kemf
and Dirk Trossen for valuable discussion on the mailing list and Erik
Nordmark for providing valuable insight about the piggybacking of CARD
options upon Fast Mobile-IPv6 message. In addition, the authors
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 37]


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.
   Details on these mechanisms are out of the scope of this document
   and intention of this appendix is to provide only a basic idea on
   flexibly extensions to the CARD protocol as described in this
   document.

   Appendix A.1 Centralized Approach using a Server Functional Entity

   The centralized approach performs CARD over MN-AR interface as
   described in section 4 of this document. Additionally, the
   centralized approach introduces a new entity, the CARD server, to
   assist the current AR in reverse address translation. The
   centralized approach requires neighboring AR(s) to register with the
   CARD server to populate the reverse address translation table. The
   registration of AR(s) addresses with the CARD server is performed
   prior to initiation of any reverse address translation request.


   Figure A.1.1 illustrates typical scenario of the centralized CARD
operation.
   In this example, 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 then 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


                                                             [Page 38]


Internet-Draft     Candidate Access Router Discovery         June 2003

   interface.



                                   +----------+
                     +------------>|   CARD   |<-------------+
                     |+------------|  Server  |-------------+|
                     ||            +----------+             ||
                     ||                                     ||
                     ||             ~~~~~~~~~~~             ||
         (3)AR-Server||(4)AR-Server{           }            ||(0) CARD
             CARD    ||    CARD   {             }           ||Reg Req/
           Request   ||   Reply  {    IP Cloud   }          |  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


                                                             [Page 39]


Internet-Draft     Candidate Access Router Discovery         June 2003


   Appendix A.2 Decentralized Approach using Mobile Terminals'
                Handover

   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 the CAR table if not refreshed before the timeout
   period. The entries for CAR identities in CAR table are created or
   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].

   Maintenance of the CAR table could be done using an additional
   option for the CARD protocol performed between a MN and its current
   AR. This message serves as 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 can be sent as a specific sub-option
   in the MN-AR CARD Request message. 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
   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


                                                             [Page 40]


Internet-Draft     Candidate Access Router Discovery         June 2003

   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.

   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 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 42]


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 43]


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 44]


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 allow 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 45]


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 CAR 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 46]


Internet-Draft     Candidate Access Router Discovery         June 2003




















                                                             [Page 47]