IETF Seamoby Working Group
Internet Draft Marco Liebsch
Category: Experimental Ajoy Singh
(Editors)
Hemant Chaskar
Daichi Funato
Eunsoo Shim
draft-ietf-seamoby-card-protocol-05.txt
Expires: May 2004 November 2003
Candidate Access Router Discovery
Status of this Memo
This document is an Internet-Draft and is subject to 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 November 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. . . . . . . . . . . . 12
4.3 Current Access Router - Candidate Access Router Operation. 13
4.3.1 Current Access Router Operation. . . . . . . . . . . . 13
4.3.2 Candidate Access Router Operation. . . . . . . . . . . 15
4.4 CARD Signaling Failure Recovery. . . . . . . . . . . . . . 16
4.4.1 MN-AR Signaling Failure. . . . . . . . . . . . . . . . 16
4.4.2 AR-AR Signaling Failure. . . . . . . . . . . . . . . . 16
4.5 CARD Protocol Message Piggybacking on the MN-AR Interface. 16
4.6 CARD Protocol Security . . . . . . . . . . . . . . . . . . 18
5. PROTOCOL MESSAGES. . . . . . . . . . . . . . . . . . . . . . 19
5.1 CARD Messages for the Mobile Node-Access Router interface. 19
5.1.1 CARD Main Header Format. . . . . . . . . . . . . . . . 19
5.1.2 CARD Options Format. . . . . . . . . . . . . . . . . . 21
5.1.2.1 CARD Request Option. . . . . . . . . . . . . . . . 22
5.1.2.2 CARD Reply Option. . . . . . . . . . . . . . . . . 23
5.1.3 Sub-Options Format . . . . . . . . . . . . . . . . . . 24
5.1.3.1 L2 ID Sub-Option . . . . . . . . . . . . . . . . . 25
5.1.3.2 Preferences Sub-Option . . . . . . . . . . . . . . 26
5.1.3.3 Requirements Sub-Option. . . . . . . . . . . . . . 27
5.1.3.4 Capability Container Sub-Option. . . . . . . . . . 27
5.1.3.5 Address Sub-Option . . . . . . . . . . . . . . . . 28
5.1.4 Capability AVP Encoding Rule . . . . . . . . . . . . . 29
5.2 CARD Messages for the inter-Access Router Protocol
Operation . . . . . . . . . . . . . . . . . . . . . . 30
5.2.1 Protocol Transport . . . . . . . . . . . . . . . . . . 30
5.2.2 Protocol Main Header . . . . . . . . . . . . . . . . . 30
5.2.3 Protocol Payload Types . . . . . . . . . . . . . . . . 31
5.3 Overview on sub-options'/payload types' usage. . . . . . . 31
6. SECURITY CONSIDERATIONS. . . . . . . . . . . . . . . . . . . 32
6.1 Assumptions . . . . . . . . . . . . . . . . . . . . . . . 32
6.2 Security Association between AR and AR . . . . . . . . . . 32
[Page 2]
Internet-Draft Candidate Access Router Discovery November 2003
6.3 Security Association between AR and MN . . . . . . . . . . 33
6.4 DoS Attack . . . . . . . . . . . . . . . . . . . . . . . . 33
7. PROTOCOL CONSTANTS . . . . . . . . . . . . . . . . . . . . . 34
8. IANA CONSIDERATIONS . . . . . . . . . . . . . . . . . . . . 35
9. NORMATIVE REFERENCES . . . . . . . . . . . . . . . . . . . . 36
10. INFORMATIVE REFERENCES . . . . . . . . . . . . . . . . . . . 36
11. AUTHORS' ADDRESSES . . . . . . . . . . . . . . . . . . . . . 37
12. IPR STATEMENTS . . . . . . . . . . . . . . . . . . . . . . . 37
13. COPYRIGHT NOTICE . . . . . . . . . . . . . . . . . . . . . . 38
14. CONTRIBUTORS . . . . . . . . . . . . . . . . . . . . . . . . 38
15. ACKNOWLEDGEMENTS . . . . . . . . . . . . . . . . . . . . . . 38
Appendix A MAINTENANCE OF ADDRESS MAPPING TABLES IN
ACCESS ROUTERS. . . . . . . . . . . . . . . . . . . 39
Appendix A.1 Centralized Approach using a Server Functional
Entity. . . . . . . . . . . . . . . . . . . . . . . 39
Appendix A.2 Decentralized Approach using Mobile Terminals'
Handover. . . . . . . . . . . . . . . . . . . . . . 40
Appendix B APPLICATION SCENARIOS . . . . . . . . . . . . . . . 43
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 November 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
[Brad97].
1. INTRODUCTION
IP mobility protocols, such as Mobile IP, enable mobile nodes to
execute IP-level handover among access routers. Additionally, work
is underway [Kood03][Malk03] 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 [TKCK02].
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 November 2003
2. TERMINOLOGY
This document uses terminology defined in TERMS [MaKo03].
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 November 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.
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.
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.
[Page 6]
Internet-Draft Candidate Access Router Discovery November 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 may 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 are 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 appropriate 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 needs to be configured administratively.
The unsolicited CARD Reply SHALL be multicast from ARs, using the
multicast address CARD_UNSOL_MC_ADDR given in section 7 as
destination address. 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 without being solicited.
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.
[Page 7]
Internet-Draft Candidate Access Router Discovery November 2003
The format of this optional Preferences message parameter is
described in Section 5.1.3.2.
Optionally, the MN can provide its current AR with a list of
capability attribute-value pairs, indicating not only the capability
parameters (attributes) as required for capability pre-filtering,
but also a specific value for a particular capability. This allows
the MN's current AR performing CAR pre-filtering and to send only
address and capability information of CARs, whose capability values
meet the requirements of the MN, back to the requesting MN. The
format of this optional Requirements message parameter is described
in Section 5.1.3.3.
As an example, using the optional Preferences message parameter, a
MN MAY indicate to its current AR that it is interested only in
IEEE802.11a 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.11a 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. The Requirements
message parameter may be used to indicate the cut off values of the
capabilities for the desired CAR(s). 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
current 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 November 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 may pass 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 the 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 NOT send
more than CARD_REQUEST_RATE requests per second. 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 November 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 referred to 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.
MNs SHOULD maintain discovered address and capability information of
CARs in a local cache to avoid requesting for the same information
repeatedly and to select an appropriate target AR from the list of
CARs as quickly as possible when a handover is imminent.
MNs and ARs SHOULD maintain sequence numbers of latest received
unsolicited CARD Reply messages in their local cache to allow
identification of recent information and replay attacks. In case a
MN receives both solicited and unsolicited CARD Reply messages, the
MN should always consider the latest information received as valid.
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.
[Page 10]
Internet-Draft Candidate Access Router Discovery November 2003
In case the MN appends multiple L2 ID sub-options to a CARD Request
for being resolved by its current AR, each L2 ID MUST be assumed
being associated with an AP, which connects to a different CAR.
Since L2 IDs, address information and capability information come
with separate sub-options within one CARD protocol message, each
sub-option carries a Context-ID, which allows matching parameters
that 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 new CARD Request protocol messages must have
the sequence number incremented respectively.
To support error recovery in case a MN-AR CARD Request or a MN-AR
CARD Reply gets lost, the sending MN performs signaling failure
recovery according to the timeout-based mechanism as described in
section 4.4.1. This allows detection of lost signaling messages and
performing retransmissions.
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.
In some cases a L2 ID parameter is present in a CARD Reply message.
The Status-Code field in the L2 ID parameter indicates one of the
following reasons for being sent towards the MN.
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 is associated with an AP that connects to the same
CAR as an AP, whose L2 ID has been requested in the same CARD
Request message and has already been resolved by the AR, the
respective L2 ID sub-option is sent back to the requesting MN,
indicating MATCH in the Status-Code field. This status code is an
indicator, that the Context-ID of this particular L2 ID sub-option
has been adapted to the Context-ID of the associated CAR's Address
[Page 11]
Internet-Draft Candidate Access Router Discovery November 2003
and Capability Container sub-option, which is sent with this CARD
Reply message. 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 sends back L2 ID and address information of all CARs.
Since the received parameters' Context-IDs cannot be correlated with
a L2 ID's Context-ID of a previously sent request, the AR chooses
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 IDs' Context-ID allow the MN to assign a
particular L2 ID to the associated Address and the possibly received
Capability Container sub-option.
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.
[Page 12]
Internet-Draft Candidate Access Router Discovery November 2003
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.
In case the MN-AR CARD Reply message gets lost on its way towards
the requesting MN, the MN will request the same information again
after a timeout indication appeared. ARs can detect a request for
retransmission when receiving a MN-AR CARD Request with the same
sequence number as the previously received request. In this case,
ARs must assume that the previously sent MN-AR CARD Reply message
got lost and must retransmit the CARD Reply message.
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
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. An unsolicited CARD Reply message MAY be advertised
immediately after a major change in CARs' capabilities appeared.
Subsequent unsolicited CARD Reply messages must be released within
the interval MIN_CARD_ADVERT_INTERVAL and MAX_CARD_ADVERT_INTERVAL
for a configurable amount of advertisements. The actual interval for
an individual unsolicited CARD Reply is a randomly chosen value
between these two boundary values. Consecutive unsolicited CARD
Reply messages MUST have the sequence number incremented for each
message respectively to counteract replay attacks.
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.
[Page 13]
Internet-Draft Candidate Access Router Discovery November 2003
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, which are 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 there is no need for the receiving CAR to process
this field due to the absence of a L2 ID and an Address sub-option.
Furthermore, the current AR MAY set the P-flag in the Capability
Container sub-option to inform the CAR about its own capability to
perform CARD protocol message piggybacking.
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.
To support error recovery in case an AR-AR CARD Request or an AR-AR
CARD Reply gets lost, the sending AR performs signaling failure
recovery according to the timeout-based mechanism as described in
section 4.4.2. This allows detection of lost inter-AR signaling
messages and performing retransmissions.
Upon receipt of the AR-AR CARD Reply, which has been sent by the CAR
in response to the previously sent request, the MN's current AR
SHALL extract the capability information from the payload of the
received message and store 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 its 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
[Page 14]
Internet-Draft Candidate Access Router Discovery November 2003
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 store 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 to the AR-AR CARD Reply message as received in AR-AR CARD
Request 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.
In case the AR-AR CARD Reply message gets lost on its way towards
the requesting AR, the AR will request the same information again
from the CAR after a timeout indication appeared. CARs can detect a
request for retransmission when receiving an AR-AR CARD Request with
the same sequence number as the previously received request. In this
case, CARs must assume that the previously sent AR-AR CARD Reply
message got lost and must retransmit the AR-AR CARD Reply message.
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 must 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 15]
Internet-Draft Candidate Access Router Discovery November 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 MN-AR CARD Request or MN-AR CARD Reply
may be dropped due to poor radio link conditions. A MN SHALL
retransmit the CARD Request using the same message sequence number,
if it does not receive a CARD Reply within MR_AR_CARD_TIMEOUT
seconds. The MN SHALL retry sending 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
and take the latest information received as valid.
4.4.2 AR-AR Signaling Failure Recovery
It is likely that an 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 retransmit the AR-AR CARD
Request using the same message sequence number, if it does not
receive a CARD Reply within AR_AR_CARD_TIMEOUT seconds. 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 messages received from the CAR and
take the latest information received as valid.
To avoid superfluous requests for retransmission on the MN-AR
interface caused by a failure in signaling between ARs, the
specified MN_AR_CARD_TIMEOUT value is larger than the AR-AR CARD
signaling will take including possible retransmissions between ARs.
This ensures, that a MN requests its current AR for retransmission
only in case the MN-AR CARD Request or the MN-AR CARD Reply got
lost, as well as in case the AR-AR CARD procedure has aborted.
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
[Kood03] signaling messages (CARD protocol message piggybacking), MN
and AR should know about the signaling peer's capability for CARD
[Page 16]
Internet-Draft Candidate Access Router Discovery November 2003
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. The format of these messages and
parameters is described 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
Router Solicitation for Proxy (RtSolPr) and Proxy Router
Advertisement (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.
If a MN wants to use the reverse address translation function of the
Fast Mobile IPv6 protocol, it can use CARD protocol message
piggybacking to retrieve only CARs' capability information. To
indicate to the current AR's CARD protocol processing function to
not perform reverse address translation, the piggybacked CARD
Request message MUST have the A-flag set. This causes the current AR
to append only Capability Container sub-options, carrying the CARs'
capability parameters. To allow associating a Capability Container,
which is sent as a parameter of the CARD Reply message, to the IP
address information of the appropriate CAR, which is sent as a
parameter of the Fast Mobile IPv6 PrRtAdv message, the Context-ID of
an individual Capability Container can be used as an index, pointing
to the associated IP address in the PrRtAdv message options. The
Context-ID of individual Capability Containers is to be set
appropriately by the MN's current AR. Details about how individual
Context-ID values can be associated with a particular IP address
option of the PrRtAdv message is out of the scope of this document.
[Page 17]
Internet-Draft Candidate Access Router Discovery November 2003
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 [AtKe98]. The CARD protocol assumes that there will be an
appropriate IPsec Security Association (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.
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 18]
Internet-Draft Candidate Access Router Discovery November 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' [Kood03] 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 19]
Internet-Draft Candidate Access Router Discovery November 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 support
processing the CARD Request message on the
receiver side, further sub-options may 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.
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.
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
[Page 20]
Internet-Draft Candidate Access Router Discovery November 2003
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 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
information about CARs of interest (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. Rules for proper setting of
the AVP Code and Data field for the
Requirements sub-option are described in
Section 5.1.3.3.
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
[Page 21]
Internet-Draft Candidate Access Router Discovery November 2003
Length: 8-bit unsigned integer. The length of the
option including the type and length fields in
units of 8 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|A| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-Options
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - -
Fields:
Type: T.B.A
Length: The length of the option in units of 8 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.
A-flag: Indicates that the requesting entity does NOT
want the receiver of this message to perform
reverse address translation. This flag could be
set in case CARD protocol messages are
piggybacked with a protocol that performs
reverse address translation. For details refer
to Section 4.5
The flag combination A=1 and C=0 is invalid.
Reserved bits MUST be initialized with 0.
[Page 22]
Internet-Draft Candidate Access Router Discovery November 2003
Sequence Number:
Allows correlating requests with replies.
Valid Sub-Options:
- L2 ID sub-option
- Preferences sub-option
- Requirements sub-option
To ensure meeting requirements on boundary alignment, individual
sub-options MUST take care of meeting 32-bit boundary alignment
requirements respectively. To meet the 8n boundary alignment
requirement of the entire CARD Request option, padding the tail of
the option might be necessary.
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 8 octets, including
the type and length fields as well as sub-options.
Flags: P-flag: Indicates CARD protocol message piggybacking
capability of the CARD Reply 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.
[Page 23]
Internet-Draft Candidate Access Router Discovery November 2003
Sequence Number:
Allows correlating requests with replies.
Valid Sub-Options:
- L2 ID sub-option
- Capability Container sub-option
- Address sub-option
To ensure meeting requirements on boundary alignment, individual
sub-options MUST take care of meeting 32-bit boundary alignment
requirements respectively. To meet the 8n boundary alignment
requirement of the entire CARD Reply option, padding the tail of the
option might be necessary.
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. Indicates the length of the
option. For details on how this value needs to be set
be referred to the description of individual sub-
options in the following Sections.
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.
[Page 24]
Internet-Draft Candidate Access Router Discovery November 2003
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
Sub-Option Length:
Length of the sub-option (including type and length
fields) in units of octets.
Context-ID: Labels associated L2 ID, IP address and capability
parameters that belong to the same node (AR) but are
encoded in separate sub-options.
Status Code: This field allows ARs to inform a requesting entity
about processing results of a particular L2 ID. This
requires the L2 ID sub-option to be 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 about 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 of
individual parameters to the correct value
that allows matching associated L2 ID,
address and capability information on the
receiver side.
0x02: MATCH - This value is set by an AR to
identify that this particular L2 ID matches
the same CAR information, which has been
resolved previously for a different L2 ID of
[Page 25]
Internet-Draft Candidate Access Router Discovery November 2003
the same CARD Request. The AR sets this value
for the Status Code, matches the associated
Context-ID with the one of the previously
resolved L2 ID and sends the L2 ID back to
the requesting entity with the CARD Reply
message.
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.
L2 type: Indicates the interface type.
The L2 type identifier serves also as an indication
of the subsequent L2 ID field's length without
padding.
The following types are initially defined:
Technology | L2 type
--------------+---------
IEEE802.11a | T.B.A.
IEEE802.11b | T.B.A.
IEEE802.11g | T.B.A.
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 octets.
Preferences: List of capability attribute values (section 5.1.4).
[Page 26]
Internet-Draft Candidate Access Router Discovery November 2003
Only ATTRIBUTE (AVP Code, see section 5.1.4) fields needs to present
and be set for individual capabilities, which are of interest to the
requesting entity. The LIFETIME and VALUE (Data) indicator will not
be processed and can be omitted. The AVP LENGTH indicator is also
not present, since the preferences are indicated only with a list of
16-bit encoded ATTRIBUTE fields. In case 32-bit boundary alignment
requirements cannot be met with the list of ATTRIBUTE values,
padding the missing 16-bit is to be done with an ATTRIBUTE value of
0x0000.
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.
Requirements: AVP encoded requirements (see Section 5.1.4)
AVPs MUST be encoded according to the rule described in Section
5.1.4. Both, the ATTRIBUTE (AVP Code) and VALUE (Data) field MUST be
present and set appropriately.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - -
[Page 27]
Internet-Draft Candidate Access Router Discovery November 2003
Sub-Option Type:
0x03
Sub-Option Length:
Length of the sub-option in units of 8 octets. The
sub-option Length does not include the length of the
Capability Container sub-option header, which
comprises the sub-option Type field, the sub-option
Length field, the Context-ID, the P-flag and the
Reserved field.
Context-ID: Labels associated L2 ID, IP address and capability
parameters that belong to the same node (AR) but are
encoded in separate sub-options.
Flags: P-flag: Indicates piggybacking capability of the CAR
whose capabilities are conveyed in this
Capability Container. 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.
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.
[Page 28]
Internet-Draft Candidate Access Router Discovery November 2003
Context-ID: Labels associated L2 ID, IP address and capability
parameters that belong to the same node (AR) but are
encoded in 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 | AVP Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attribute Lifetime | Data . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - -
AVP Code: Identifies the attribute uniquely. The AVP Code
0x0000 is reserved and MUST NOT be assigned to a
capability.
AVP Length: The two octet AVP length field indicates the
number of octets in this AVP, including the AVP Code,
AVP Length, Reserved, Lifetime and Data field.
Reserved: This field is reserved for future use and MUST be set
to 0.
Lifetime: Specifies the lifetime of the encoded capability
in seconds. In case of a static capability, the
Lifetime field MUST be set to the maximum value
(0xffff), which indicates that the lifetime of this
capability parameter never expires. A lifetime value
of 0x0000 deletes a capability entry.
Data: This variable length field has the Value of the
capability attribute encoded.
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.
[Page 29]
Internet-Draft Candidate Access Router Discovery November 2003
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 [Post80] is used for transport of CARD
protocol messages. The associated UDP port for the CARD protocol
operation is T.B.A.
To protect CARD protocol messages between ARs, the IPsec ESP
[AtKe98] 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.
5.2.2 Protocol Main Header
The 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.
Reserved: This field is currently reserved and MUST be
set to 0.
Type: Message type.
The following message types are specified for this interface:
Message Type
--------------------------------------
AR-AR CARD Request 0x01
AR-AR CARD Reply 0x02
[Page 30]
Internet-Draft Candidate Access Router Discovery November 2003
Sequence number:
Allows correlating requests with responses.
5.2.3 Protocol Payload Types
On this protocol interface, the Capability Container parameter is
used to convey capabilities between ARs. Optionally, the Preferences
parameter can be used for capability pre-filtering during the inter-
AR capability discovery procedure. Payload types and encoding rules
are the same as described for the respective 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.
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 0x01 x
Address 0x02 x
Capability Container 0x03 x x
Preferences 0x04 x x
Requirements 0x05 x
[Page 31]
Internet-Draft Candidate Access Router Discovery November 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 document.
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 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 32]
Internet-Draft Candidate Access Router Discovery November 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. IPsec ESP is the default mechanism for CARD
signaling message authentication between an AR and a MN. Also, IPsec
ESP is the default method for message encryption.
Authentication of unsolicited CARD Reply messages, which are
multicast from an AR towards MNs, is an open issue and the
specification of an appropriate protection mechanism is out of scope
of this document.
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. A rate limiting
policy is described in Section 4.
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.
Making authentication of CARD protocol messages mandatory supports
protection of ARs against CARD Request flooding with spoofed
addresses, since authenticating the requests makes DoS less likely
as the attacker's identity is revealed and its account can be
disabled.
[Page 33]
Internet-Draft Candidate Access Router Discovery November 2003
7. PROTOCOL CONSTANTS
Mobile Node protocol constants:
MN_AR_CARD_TIMEOUT: 1 second
This timer value specifies 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 specifies the number of retries when
sending a MN-AR CARD Request from a MN before
declaring the message exchange aborted.
CARD_REQUEST_RATE: 2 requests/second
This value specifies the maximum rate a MN is
allowed to send new CARD Requests to an AR.
Access Router protocol constants:
AR_AR_CARD_TIMEOUT: 300 milliseconds
This timer value specifies 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: 2
This value specifies 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 second
MAX_CARD_ADVERT_INTERVAL (MN-AR): 60 seconds
MIN_CARD_UPDATE_INTERVAL (AR-AR): 60 seconds
CARD_UNSOL_MC_V6_ADDR: T.B.A (To be assigned by IANA)
CARD_UNSOL_MC_V4_ADDR: T.B.A (To be assigned by IANA)
[Page 34]
Internet-Draft Candidate Access Router Discovery November 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 [NaAl98].
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 [Kood03] to perform CARD protocol
message piggybacking (Section 4.5), avoiding conflicts in option
types must be taken into account. The new option 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). To uniquely identify
specific access technologies in the L2-Type field of a CARD L2 ID
sub-option, the IANA should also assign fixed numbers to identify
well-known access technologies (Section 5.1.3.1). Initially, values
for IEEE802.11a, IEEE802.11b and IEEE802.11g should be assigned. To
allow MNs receiving unsolicited CARD Reply messages only in case
they are of interest to them, a well-known multicast IP address for
IPv4 and IPv6 (link-local) needs to be assigned by IANA for that
purpose (section 7).
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, as well as to assign the UDP port number for inter-AR
protocol operation and an IPv6 link-local and IPv4 well known
multicast address for unsolicited CARD Reply message multicast. This
document also authorizes IANA to assign fixed L2 Type values for the
wireless technologies IEEE802.11a, IEEE802.11b and IEEE802.11g. Note
that it is not possible to identify all possible access technologies
where CARD can be applicable, so we have chosen three access
technologies to begin with. Assignment of further technologies' L2-
type identifiers should be requested from IANA in the future and
it's recommended that the assignment will be done on the basis of
Designated Experts.
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.
[Page 35]
Internet-Draft Candidate Access Router Discovery November 2003
9. NORMATIVE REFERENCES
[Brad97] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[Kemp02] Kempf, J., "Problem Description: Reasons For Performing
Context Transfers Between Nodes in an IP Access Network",
RFC 3374, September 2002.
[NaNS98] Narten, T., et al., "Neighbor Discovery for IP Version 6
(IPv6)", RFC 2461, December 1998.
[Post80] Postel, J., "User Datagram Protocol", RFC 768, August 1980.
[AtKe98] Atkinson, R., Kent, S.,"IP Encapsulating Security Payload
(ESP)", RFC 2406, November 1998.
[NaAl98] Narten, T., Alvestrand, H., "Guidelines for Writing an IANA
Considerations Section in RFCs", RFC 2434, October 1998.
10. INFORMATIVE REFERENCES
[TKCK02] Trossen, D., Krishanmurthi, G. Chaskar, H., Kempf, J.,
"Issues in candidate access router discovery for seamless
IP-level handoffs", Work in Progress, October 2002.
[Kris02] Krishanmurti, G., "Requirements for CAR Discovery
Protocolsö, Work in Progress, October 2002.
[Kenw02] Kenward, B., "General Requirements for Context
Transfer", Work in Progress, October 2002.
[MaKo03] Manner, J., Kojo, M. (Ed), "Mobility Related Terminology",
Work in Progress, April 2003.
[Kood03] Koodli, R, et al., "Fast handoffs for Mobile IPv6", Work in
Progress, October 2003.
[Funa02] Funato, D. et al., "Geographically Adjacent Access Router
Discovery Protocolö, Work in Progress, June 2002.
[Tros03] Trossen, D. et al., "A Dynamic Protocol for Candidate
Access-Router Discovery", Work in Progress, March 2003.
[ShGi00] Shim, E., Gitlin, R., "Fast Handoff Using Neighbor
Information", Work in Progress, November 2000.
[Malk03] El Malki, K. et al., "Low Latency Handoffs in Mobile IPv4",
Work in Progress, October 2003.
[Page 36]
Internet-Draft Candidate Access Router Discovery November 2003
11. AUTHORS' ADDRESSES
Hemant Chaskar
Nokia Research Center
5 Wayside Road
Burlington, MA 01803, USA
Phone: +1 781-993-3785
Email: Hemant.Chaskar@nokia.com
Daichi Funato
NTT DoCoMo USA Labs
181 Metro Drive, Suite 300
San Jose, CA 95110, USA
Phone: +1 408-451-4736
Email: funato@docomolabs-usa.com
Marco Liebsch
NEC Network Laboratories
Kurfuersten-Anlage 36 , 69115 Heidelberg
Germany
Phone: +49 6221-90511-46
Email: marco.liebsch@ccrle.nec.de
Eunsoo Shim
NEC Laboratories America, Inc.
4 Independence Way
Princeton, NJ 08540, USA
Phone: +1 609-951-2909
Email: eunsoo@nec-labs.com
Ajoy Singh
Motorola Inc
1501 West Shure Dr, USA
Phone: +1 847-632-6941
Email: asingh1@email.mot.com
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.
[Page 37]
Internet-Draft Candidate Access Router Discovery November 2003
13. COPYRIGHT NOTICE
"Copyright (C) The Internet Society (date). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph
are included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."
14. CONTRIBUTORS
The authors would like to thank Vijay Devarapalli (Nokia) and Henrik
Petander (Helsinki University of Technology) for formally reviewing
the protocol specification draft and providing valuable comments and
input for technical discussions.
15. ACKNOWLEDGEMENTS
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 document as well as for the general CARD related discussion and
feedback. In addition, the authors would like to thank Erik Nordmark
for providing valuable insight about the piggybacking of CARD
options upon Fast Mobile IPv6 messages.
[Page 38]
Internet-Draft Candidate Access Router Discovery November 2003
APPENDIX A: MAINTENANCE OF ADDRESS MAPPING TABLES IN ACCESS ROUTERS
This appendix provides 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 the MN-AR interface as
described in Chapter 4 of this document. Additionally, the
centralized approach introduces a new entity, the CARD server, to
assist the current AR in performing 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 illustrates a 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 between an AR and the
CARD server function are shown with the preceding identifier "AR-
Server", referring to the associated interface.
An initial idea of performing reverse address translation using a
centralized server has been described in [Funa02].
[Page 39]
Internet-Draft Candidate Access Router Discovery November 2003
+----------+
+------------>| 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: Centralized Approach for L2-L3 mapping
Appendix A.2 Decentralized Approach using Mobile Terminals'
Handover
This approach performs CARD over the MN-AR interface as described in
Chapter 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 expires. The entries for CAR identities in the 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
[Page 40]
Internet-Draft Candidate Access Router Discovery November 2003
bootstrap handover, which invokes 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 [ShGi00] and [Tros03].
Maintenance of the CAR table could be done using an additional
option for the CARD protocol operation 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
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 Chapter 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
[Page 41]
Internet-Draft Candidate Access Router Discovery November 2003
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 42]
Internet-Draft Candidate Access Router Discovery November 2003
APPENDIX B: APPLICATION SCENARIOS
This section provides two examples of an application scenario for
the CARD protocol operation. One scenario describes a 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 the
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 43]
Internet-Draft Candidate Access Router Discovery November 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 the associated 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 Mobile IPv6 protocol operation.
Figure B.2 illustrates the signaling flow of the previously
described application scenario of CARD within a Mobile IPv6 enabled
network.
[Page 44]
Internet-Draft Candidate Access Router Discovery November 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 45]
Internet-Draft Candidate Access Router Discovery November 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 [Kood03]. 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 46]
Internet-Draft Candidate Access Router Discovery November 2003
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
*) Note with regard to the example signaling illustrated in
Figure B.3: 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 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 47]