and input for technical discussions. The authors would also like to
thank James Kempf for reviewing and for providing a lot of valuable
comments and editing help.
12. 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.
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.
These schemes replace static configuration of the AP L2 ID-to-CAR IP
address mapping in the CAR table. Details on these mechanisms are
out of the scope of this document. The intention of this appendix is
to provide only a basic idea on flexible 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 Section 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 that neighboring ARs register with the
CARD server to populate the reverse address translation table. The
registration of AR 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 an MN discovers the
L2 ID of APs during L2 scanning, it passes one or more L2 IDs to its
current AR, and the AR resolves them 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 it is 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 is described in [Funa02].
+----------+
+------------>| 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
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 state. The entries for CARs are removed from the
CAR table if they are not refreshed before the timeout period expires
and are created or refreshed according to the 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 to invoke the discovery procedure, and the
subsequent handover serves 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 is done by using an additional option
for the CARD protocol operation performed between an 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), and 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 is no
longer possible between two ARs, the associated entries eventually
timeout and are 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. One simple method is to verify the accuracy of the
Router Identity message by sending 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 verifies that the MN was indeed
attached to it during a reasonable past interval and responds 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 a 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 exchange to a later time
when some MN undergoing handover between them performs CARD as
described in Section 4. In the latter (refresh) case, ARs may
exchange capabilities or defer exchanges until a later time when
another MN undergoes handover.
Finally, note that in a handover-based protocol, a first handover
between a pAR and an MN’s current AR cannot use CARD, as this
handover bootstraps the CAR table. However, in the long term, such a
handover will only amount to a small fraction of total successful
handover between the two ARs. Also, if the MN engaging in such a
first handover is running a non-delay sensitive application at the
time of handover, the user may not even realize its impact.
Appendix B. Application Scenarios
This section provides two examples of application scenarios for CARD
protocol operation. One scenario describes a CARD protocol operation
in a Mobile IPv6 (MIPv6) 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.
This application scenario assumes a moving MN having access to the
infrastructure through wireless LAN (IEEE802.11) APs. Mobility
management is performed using the Mobile IPv6 protocol. The
following figure illustrates the assumed access network design.
Appendix B.1. CARD Operation in a Mobile IPv6-Enabled Wireless LAN
Network
-----------------------------
/ \ +----+
| 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) maintains location information for the
MN in its binding cache. In Figure B.1, the MN holds a care-of
address for the subnet 1, supported by AR1. As the MN moves, the
MN’s current environment offers two further wireless LAN APs with
increasing link-quality as candidate APs for a handover. To
facilitate decision making, parameters associated with ARs are taken
into account during the decision process. The 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 IDs. Furthermore, associated link-quality parameters are
retrieved to ascertain whether approaching APs are eligible
candidates for a handover. If AP2 and AP3 are 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 the message to
its current AR (AR1).
AR1 resolves each L2 ID listed in L2 ID options to the associated IP
address of the respective CAR, 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. The corresponding IP
address of the candidate AR, to which AP3 is connected, is the
address of AR2. IP addresses of the MN’s CARs are now known to AR1,
which retrieves the CARs’ capabilities from the CAR table. Assuming
that it has valid entries for respective capability parameters to
refresh dynamic capabilities, whose associated lifetimes in AR1’s CAR
table have expired, AR1 performs Inter-AR CARD for capability
discovery. Since capability information for AR1 is known to AR1, a
respective Inter-AR CARD Request is sent only to AR2. In response,
AR2 sends a CARD Reply message back to AR1, encapsulating the
requested capability parameters with the signaling message in a
Capability Container sub-option.
Next, 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.
Upon receipt of the CARD Reply message, the MN performs target AR
selection, taking AR1’s and AR2’s capability parameters and
associated APs’ link-quality parameters into account. If the
selected AP is AP2, no IP handover needs to be performed. If 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.
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
Appendix B.2. CARD Operation in a Fast Mobile IPv6 Network
This application scenario assumes that ARs can perform the fast
handover protocol sequence for Mobile IPv6 [Kood03]. The MN scans
for new APs for handover, similar to Figure B.1. To discover the 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. (This 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
addresses of associated CARs. The pAR checks its local CAR table to
retrieve information about the CARs’ capabilities. If any table
entries have expired, the pAR acquires this CAR’s capabilities by
sending an AR-AR CARD Request to the respective CAR. The CAR replies
with an AR-AR CARD Reply message, encapsulating all capabilities in a
Capability Container sub-option and attaching them to the CARD Reply
option. On receipt of the CARs’ capability information, the pAR
updates its local CAR table and forwards the address and capability
information to the MN by attaching a MN-AR CARD Reply option 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, allowing the pAR to perform a
fast handover according to the Fast Mobile IPv6 protocol.