Seamoby Working Group Dirk Trossen
INTERNET DRAFT Govind Krishnamurthi
14 March 2003 Hemant Chaskar
Nokia Research Center
Robert C. Chalmers
UC Santa Barbara
Eunsoo Shim
NEC Labs America
A Dynamic Protocol for Candidate Access-Router Discovery
draft-trossen-seamoby-dycard-01.txt
Status of This Memo
This document is an individual submission to the Seamoby Working
Group of the Internet Engineering Task Force (IETF). Comments should be
submitted to the SEAMOBY@IETF.ORG mailing list.
Distribution of this memo is unlimited.
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, and
its working groups. Note that other groups may also distribute working
documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference material
or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at:
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at:
http://www.ietf.org/shadow.html.
Abstract
Many protocols currently being developed for seamless IP-level
handovers, such as fast handovers and context transfers, possess an
inherent requirement that the mobile node and/or it's current access
router have a priori knowledge concerning the target of the handover.
In particular, the target access router (TAR) should be known to have
the appropriate set of capabilities necessary to meet the requirements
of the mobile node. Although the TAR selection process occurs at or
Trossen, et al. Expires 14 September 2003 [Page i]
Internet Draft Dynamic CAR Discovery 14 March 2003
near the time of handover, applicable candidate access routers (CARs)
can be identified in advance. In this draft, we propose a dynamic,
distributed protocol, dyCARD, which allows geographically adjacent
routers to exchange capability information, thus providing critical
information to the target selection process.
Trossen, et al. Expires 14 September 2003 [Page ii]
Internet Draft Dynamic CAR Discovery 14 March 2003
Contents
Status of This Memo i
Abstract i
1. Introduction 1
2. Terminology 2
3. Protocol Overview 3
3.1. Conceptual Data Structures . . . . . . . . . . . . . . . 3
3.2. Discovering Neighboring Routers . . . . . . . . . . . . . 4
3.3. Exchanging Capabilities . . . . . . . . . . . . . . . . . 6
3.4. Reporting Reachability Information . . . . . . . . . . . 6
3.5. TAR Selection . . . . . . . . . . . . . . . . . . . . . . 7
3.6. Stateful Mode . . . . . . . . . . . . . . . . . . . . . . 7
3.7. Security Assumptions . . . . . . . . . . . . . . . . . . 8
4. Protocol Messages 8
4.1. ICMP Container . . . . . . . . . . . . . . . . . . . . . 8
4.2. Router Identity Message . . . . . . . . . . . . . . . . . 9
4.3. Reachability Message . . . . . . . . . . . . . . . . . . 10
4.4. Reachability Acknowledgement Message . . . . . . . . . . 12
4.5. Candidate List Request Message . . . . . . . . . . . . . 13
4.6. Candidate List Message . . . . . . . . . . . . . . . . . 14
4.7. Physical Neighbor Exchange Message . . . . . . . . . . . 15
4.8. Message Sub-Options . . . . . . . . . . . . . . . . . . . 17
4.8.1. Pad1 Sub-Option . . . . . . . . . . . . . . . . . 18
4.8.2. PadN Sub-Option . . . . . . . . . . . . . . . . . 19
4.8.3. Lifetime Sub-Option . . . . . . . . . . . . . . . 19
4.8.4. IP Sub-Option . . . . . . . . . . . . . . . . . . 20
4.8.5. Privacy Sub-Option . . . . . . . . . . . . . . . 21
4.8.6. Profile Sub-Option . . . . . . . . . . . . . . . 22
4.8.7. Capabilities Sub-Option . . . . . . . . . . . . . 24
4.8.8. Link-Layer Sub-Option . . . . . . . . . . . . . . 25
4.8.9. MN Identifier Sub-Option . . . . . . . . . . . . 26
4.8.10. MN Token Sub-Option . . . . . . . . . . . . . . . 27
5. Protocol Requirements 28
5.1. Requirements for Mobile Nodes . . . . . . . . . . . . . . 28
5.2. Requirements for Access Routers . . . . . . . . . . . . . 29
6. Mobile Node Operation 30
6.1. Movement Detection . . . . . . . . . . . . . . . . . . . 30
6.2. Selecting a Source Address . . . . . . . . . . . . . . . 30
Trossen, et al. Expires 14 September 2003 [Page iii]
Internet Draft Dynamic CAR Discovery 14 March 2003
6.3. Sending Router Identity Messages . . . . . . . . . . . . 30
6.4. Tracking AP Beacons . . . . . . . . . . . . . . . . . . . 31
6.5. Sending Reachability Messages . . . . . . . . . . . . . . 32
6.6. Receiving Reachability Acknowledgement Messages . . . . . 33
6.7. Sending Candidate List Request Messages . . . . . . . . . 34
6.8. Receiving Candidate List Messages . . . . . . . . . . . . 35
7. Access Router Operation 35
7.1. Identifying Mobile Nodes . . . . . . . . . . . . . . . . 35
7.2. Receiving Router Identity Messages . . . . . . . . . . . 36
7.3. Receiving Reachability Messages . . . . . . . . . . . . . 37
7.4. Sending Reachability Acknowledgement Messages . . . . . . 38
7.5. Receiving Candidate List Request Messages . . . . . . . . 38
7.6. Sending Candidate List Messages . . . . . . . . . . . . . 40
7.7. Sending Physical Neighbor Exchange Messages . . . . . . . 40
7.8. Receiving Physical Neighbor Exchange Messages . . . . . . 42
7.9. Rate Limiting . . . . . . . . . . . . . . . . . . . . . . 43
7.10. Validating Previously Attached MNs . . . . . . . . . . . 44
7.11. Limiting Cache Entries . . . . . . . . . . . . . . . . . 44
8. Protocol Constants 44
9. IANA Considerations 45
10. Security Considerations 45
11. Intellectual Property Rights Notice 45
Acknowledgements 46
References 46
A. Conformance to Requirements 48
B. Optimization with Fast Mobile IPv6 52
Author Addresses 52
Trossen, et al. Expires 14 September 2003 [Page iv]
Internet Draft Dynamic CAR Discovery 14 March 2003
1. Introduction
Mobile IP [8, 4] enables a mobile node (MN) to execute IP-level
handovers between access routers (ARs) which act as points of attachment
to the IP network. However, for many scenarios, the handover latency
and packet loss incurred by standard Mobile IP are too high. Thus,
work is underway to develop protocols intended to provide seamless
handovers (low latency and low packet loss) between ARs [3, 6, 5, 7].
Many of these seamless protocols, however, make the assumption that the
MN and/or the current AR have a priori knowledge of the target of the
handover, the next access router. In order to provide this information
to these seamless solutions, a new protocol is required to discover
geographically adjacent routers, and to collect their capabilities prior
to MN handover.
This document presents such a protocol, dyCARD, a dynamic protocol
for candidate access-router discovery. The protocol serves three key
functions:
1) To provide a reverse mapping from AP layer-2 identifiers to IP
addresses of supporting ARs.
2) To identify physically neighboring access routers sufficiently
in advance of MN handover such that AR capabilities may be
exchanged.
3) To use these collected capabilities in addition to information
provided by the MN, such as reachability and preferences, to
aid the MN in selecting a target access router at or near the
time of handover.
Three general approaches to CAR discovery exist, namely anticipated
discovery, dynamic discovery and hybrid approaches. In the anticipated
approach, the current AR identifies the CARs prior to handover, and
subsequently selects the TAR on the behalf of the MN. Dynamic CAR
selection is controlled by the MN who collects capabilities directly
from reachable ARs and then performs target selection based on local
policy. Hybrid approaches exists between anticipated and dynamic
solutions, where both the AR and MN contribute to CAR discovery and TAR
selection.
In this draft, we present a hybrid approach for CAR discovery. In
the protocol described herein, ARs discover neighboring CARs through the
handover patterns of the mobile nodes. As a MN hands-over between two
adjacent ARs, the ARs learn of one another's existence, and then proceed
to exchange capability information off-line over the wired backbone. At
some point prior to the next handover, the MN queries its current AR
with a list of reachable access points. Using the previously collected
Trossen, et al. Expires 14 September 2003 [Page 1]
Internet Draft Dynamic CAR Discovery 14 March 2003
CAR capabilities and the MN's reachability information, the AR can then
assist the MN in selecting a new target access router.
2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119[1].
Moreover, the following specific terms are used throughout the
document:
Home Address (HoA)
The IPv4 or IPv6 address of the MN that it uses
when it is not moving, i.e., when it is attached
to its home network.
Care-of Address (CoA)
An IPv4 or IPv6 address configured by or
assigned to the MN for use on a foreign network.
Access Router (AR)
A layer-3 device acting as the first-hop IP
router for a mobile node. In Mobile IPv4, this
would be the Foreign Agent.
Access Point (AP) A layer-2 device to which a mobile node connects
through a wireless link. A single AR may have
many APs of differing technologies.
Beacon A layer-2 message emitted by an AP, and received
by a mobile node used to announce the presence
of the AP. The beacon should contain some
unique identifier to allow the mobile node to
distinguish between APs
Capabilities Information describing the services provided by
a given AR.
Profile The requirements and preferences of a MN as they
pertain to handover.
Candidate AR (CAR)
An access router which is a possible target
for a mobile node's handover. A CAR is a
geographical neighbor of the mobile node's
current AR. The two ARs have APs with
overlapping coverage areas.
Trossen, et al. Expires 14 September 2003 [Page 2]
Internet Draft Dynamic CAR Discovery 14 March 2003
Target AR (TAR) A particular CAR chosen as the target of the
mobile node's handover.
Border Router A globally, IP addressable router through which
a privately addressed network connects to the
Internet.
Disjoint Handover A handover to a new AP from which the MN could
not receive beacons while attached to its
previous AP. In other words, the two APs do
not have overlapping coverage areas (from the
viewpoint of the MN).
3. Protocol Overview
3.1. Conceptual Data Structures
This document uses the conceptual data structures listed in this
section to describe the operation of the CAR discovery protocol. A
specific implementation does not necessarily need to implement these
data structures as long as the external behavior is consistent with that
described in this document.
Physical Neighbor Cache
A map of geographically adjacent ARs and their
associated APs. Each AR and AP entry have
independent lifetimes associated with them.
Mobile Node List A list of MNs currently supported by the AR as
part of the stateful mode of the CAR discovery
protocol. Each MN entry has a lifetime
associated with it.
Beacon Entry An entry representing a single, uniquely
identifiable AP beacon. Each Beacon Entry has
an associated link-layer address or other unique
identifier. A locally unique 16-bit Id is
assigned to each Beacon Entry by the MN.
Beacon List A list of AP Beacon Entries maintained by a MN
or AR which represents the current reachability
of a given MN. When maintained by the MN, each
Beacon Entry has an associated lifetime.
Trossen, et al. Expires 14 September 2003 [Page 3]
Internet Draft Dynamic CAR Discovery 14 March 2003
3.2. Discovering Neighboring Routers
In order for an AR to be considered as a candidate for handover, the
coverage area of one or more of its attached access points must overlap
with the coverage of the MN's existing point of attachment. Two ARs
with such overlapping coverage areas are considered to be geographically
adjacent, or physical neighbors. This designation differs from
logically adjacent routers with only a single IP hop separating them.
Geographically adjacent routers can be separated by any number of IP
hops, and could actually be in completely different domains. How then
do geographically adjacent routers discover each other's existence?
One solution to the discovery problem would be to manually configure
this list of physical neighbors for each access router. However, as
previously described [11], such an approach has serious disadvantages,
and in many cases, may be infeasible. For example, two ARs that are
geographically adjacent may be under separate administrative control,
and thus may not be informed of one another's presence. Even within
the same administrative domain, manual configuration demands consistent
network planning and maintenance.
$ MN +----------+
+-+ +-------+ | Previous | <
| | ------- | pAP | --- | Router | ------ >
+-+ +-------+ | (pAR) | <
| +----------+
| IP
V Network
$ +----------+
+-+ +-------+ | New | <
| | ------- | nAP | --- | Router | ------ >
+-+ +-------+ | (nAR) | <
+----------+
Figure 1: Reference Scenario for Handovers.
Therefore, we propose a dynamic approach where geographically
adjacent routers are identified by the handover patterns of the mobile
nodes. In short, if a MN can handover between two access points,
then the associated ARs should be considered as candidates for future
handovers. In this sense, it is crucial that a MN distinguish between
handing-over between two adjacent APs, and simply attaching to a new
access point after having disconnected from its previous AP.
Following a handover, a MN informs its new access router (nAR),
as seen in Figure 1, about its previous point of attachment. In
Trossen, et al. Expires 14 September 2003 [Page 4]
Internet Draft Dynamic CAR Discovery 14 March 2003
particular, the MN sends to nAR a Router Identity (RI) message (see
Section 4.2) containing the IP address of the previous access router
(pAR), the link-layer address of the previous access point, as well as
the link-layer address of the new AP. So, for the scenario depicted in
Figure 1, the MN would send the tuple (pAR,pAP,nAP) to nAR.
With this information, nAR can create or refresh two entries in its
Physical Neighbor Cache (PNC): 1) an entry for nAP as a locally attached
access point, and 2) an entry for pAR as a physical neighbor with the
associated access point pAP. Prior to trusting the MN's report, however,
nAR performs a number of checks to ensure the validity of the received
information.
First, nAP must be authorized as one of nAR's local access points.
This can be achieved through a managed list of APs currently attached
to nAR, or by a larger set of APs that could possibly be attached over
a given period of time. The size and variability of this authorization
list is controlled by the ARs administrator. A larger set of authorized
APs provides a higher level of reconfigurability, but also increases the
possibility of malicious MNs polluting the AR's PNC.
To further verify the contents of the RI message, the AR sends a
Physical Neighbor Exchange (PNE) message (see Section 4.7) to pAR. The
PNE includes both the new and the previous AP identifiers, pAP and nAP.
pAR verifies that pAP is indeed valid via its own local PNC entries, and
that the MN was recently present. pAR replies to nAR, indicating the
result of the validation. If the report was valid, pAR updates its own
PNC with an entry for nAR and nAP.
In this way, each handover of a MN results in a bi-directional
discovery process between the two participating ARs. Further handovers
simply refresh existing PNC entries. If handovers cease between two
particular access routers, the associated references will eventually
timeout and be removed from each AR's PNC.
The dynamic nature of the CAR discovery protocol we propose adapts
well to changes in the network topology. Since the PNC is maintained
as soft-state in the ARs, APs that are removed will timeout. ARs that
no longer overlap, will dissociate, and new APs will be discovered
once a MN performs a handover to it. The protocol design provides
for a tradeoff between the stability of the PNC and the degree of
reconfigurability. Longer lifetimes for cache entries provide a more
stable picture of the neighborhood in the face of few handovers. On
the other hand, lower lifetimes improve robustness, allowing APs to be
removed or moved between ARs more frequently.
Trossen, et al. Expires 14 September 2003 [Page 5]
Internet Draft Dynamic CAR Discovery 14 March 2003
3.3. Exchanging Capabilities
In order to select a particular target from a list of CARs, it is
necessary to learn which services each CAR can provide to the MN. This
set of services, or capabilities, must be exchanged prior to actual
handover to ensure that the information is available at the time of TAR
selection.
During a validation exchange, as described in the previous section,
two ARs may exchange capability information via the PNE message.
Capabilities have lifetimes that are independent of, although bounded
by, the PNC entries of their associated ARs. They may be refreshed
during normal validation exchanges, or via explicit PNE messages. To
request current capabilities, an AR simply sets the C-bit in the PNE
message. The receiving AR may then return its capability set as a
sub-option in a PNE reply (see Section 4.8.7).
The exact semantics of how to adequately describe capabilities are
beyond the scope of this document. Actually, the CAR discovery protocol
described herein works with literally any capability representation
required. The Capabilities sub-option treats the actual data as
a binary block. Marshalling, parsing and management of capability
information is handled outside the CAR discovery protocol.
3.4. Reporting Reachability Information
As part of the TAR selection process, the current AR can use the set
of APs reachable by a MN to limit the total number of CARs considered.
This has two key advantages: 1) the complexity of the TAR selection
algorithm is reduced when fewer CARs are considered, and 2) less
information can be transmitted to the MN in the case that it controls
the TAR selection process.
Reachability information can be transmitted to the AR in two ways:
1) statelessly via the Candidate List Request (CLR) message (see
Section 4.5), or 2) statefully via Reachability (RM) message (see
Section 4.3). The former provides a transaction-based interface where
the mobile node provides the list of reachable APs with each request
for resolution. The latter allows the mobile node to inform the AR
about reachable APs just once. Then, subsequent resolution attempts
can take advantage of the reachability information already available at
the AR. We discuss the stateful mode of the protocol in more detail in
Section 3.6.
Trossen, et al. Expires 14 September 2003 [Page 6]
Internet Draft Dynamic CAR Discovery 14 March 2003
3.5. TAR Selection
At any time prior to handover, a MN may request a list of CARs
from the current AR via the CLR message. The AR should use the MN's
current reachability state, whether included in the current message or
maintained statefully, to limit the set of CARs returned. Moreover, if
the AR has the MN's profile available, it could further reduce and sort
the set of CARs based on the best match between the MN's requirements
and the CAR capabilities. The extent of this reduction could be a
property of the profile itself.
Once a set of CARs has been chosen, the AR transmits this list via
the Candidate List (CL) message (see Section 4.6) to the MN in the form
of the AP identifiers known to the MN. In this way, the list truly
consists of candidate access points. If requested by the MN, via the
C-bit in the CLR, the AR may also add capability information relevant to
the TAR selection process for each of the CARs.
TAR selection is inherently dependent upon the semantics of the MN's
profile and the AR capabilities. Again, this is beyond the scope of the
CAR discovery protocol, and can be handled by a companion TAR-selection
algorithm. The protocol described in this document provides the
mechanism to collect and transport the appropriate information to the
point of TAR selection, which could be at the current AR or the MN, but
plays no part in using that information to select a target AR.
3.6. Stateful Mode
In the stateful mode of the protocol, the AR maintains state on
behalf of the MN that it then uses as part of the CAR/TAR selection
process. This is done statefully so that the MN can provide the
information well before the time of handover, and may actually request
multiple CAR selections based on the state stored at the AR; i.e., the
MN may periodically refresh its current TAR selection.
As a MN hears new beacons emitted by nearby APs, it reports them to
its current AR via the RM message. Each beacon is reported only once
upon initial reception. An acknowledgment is returned by the AR. Both
the MN and the AR maintain a Beacon List which represents the MN's
current reachability state. At the MN, each beacon has an associated
lifetime which is dependent upon the beacon frequency. The lifetime
is refreshed with each received beacon. Once a beacon expires, a RM
message is sent to revoke the entry in the AR's beacon list.
The MN can set the S-bit in the RM message to initiate a
resynchronization, providing the AR with an absolute set of Beacon
Entries. This is used on the initial RM issued after handover to ensure
an existing MN entry at the AR will not be reused, an example being
Trossen, et al. Expires 14 September 2003 [Page 7]
Internet Draft Dynamic CAR Discovery 14 March 2003
the case where a MN moves away and then quickly back again. Moreover,
if the MN detects a synchronization problem due to error conditions in
the acknowledgment, it may choose to send an absolute list of current
beacons to force resynchronization.
The RM message may also be used to provide extra information about
the MN to the AR in the form of sub-options, such as the MN's home
address or current profile. Since RM messages can be acknowledged, the
MN can ensure reception, or subsequently retransmit on failure.
3.7. Security Assumptions
In the design of this protocol, we have made a few assumptions about
the security model in place between the MN and the AR, and between
ARs. In particular, we assume that prior to any protocol messaging,
the the AR has authenticated and authorized the MN to participate in
CAR discovery. Moreover, in order for two ARs to cooperate without
introducing serious security concerns, they must be able to establish a
security association. For intra-domain routers, this could be as simple
as a shared secret key. For the inter-domain scenario, the two domains
must have a previously established relationship that can be leveraged to
derive an adequate session key (e.g., AAA). All messages listed herein
should be protected by IPSec or TLS to provide authentication and ensure
message integrity.
4. Protocol Messages
The CAR discovery protocol described in this document defines five
messages and eleven sub-options. Messages are formed as options so that
they can be piggy-backed on other handover messages, if appropriate.
All messages exchanged between the MN and AR are presented as ICMP
packets [9, 2]. Messages between ARs are presented as payload data
of SCTP packets [10]. All ICMP messages share a single ICMP type and
code (TBA). Likewise, all options share one ICMP option type (TBA) with
distinct sub-types. All SCTP messages share a single Payload Protocol
Identifier (TBA).
4.1. ICMP Container
Protocol messages between the AR and MN are sent using ICMP [9, 2].
Each ICMP packet is formed with a general message format.
IP Fields:
Source Address The current CoA of the MN (see Section 6.2).
Trossen, et al. Expires 14 September 2003 [Page 8]
Internet Draft Dynamic CAR Discovery 14 March 2003
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: ICMP Message Format.
Destination Address
The address of the access router as determined
from the last router advertisement of said AR.
Hop Limit/TTL 1
Authentication Header
If a security association exists between the MN
and the AR, then the sender SHOULD include this
header.
ICMP Fields:
Type TBA
Code TBA
Checksum The ICMP checksum.
Options Each packet SHOULD contain a single message
option defined below.
4.2. Router Identity Message
The Router Identity (RI) message is sent by the MN to its current AR
after handover. The message SHOULD be sent only after any necessary
authentication and authorization has been performed and a new CoA
has been configured, if necessary. This message has an alignment
requirement of 4n.
This message MAY contain an IP sub-option with the global address
of the previous AR. It MAY also include two Link-Layer sub-options
containing the previous and new AP identifiers, if available. If the
handover is disjoint then the previous AR and previous AP sub-options
Trossen, et al. Expires 14 September 2003 [Page 9]
Internet Draft Dynamic CAR Discovery 14 March 2003
MUST NOT be included. If neither AP identifier is available, then the
MN SHOULD NOT send this message.
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 | Sub-Type | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-Options ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Router Identity Message Format.
RI Fields:
Type TBA
Length The size of this message including all
sub-options in units of 8 octets. If the
message does not completely fill the final 8
octets, then padding MUST be added to the end of
the message.
Sub-Type 0
Reserved This field is reserved for future use. It MUST
be initialized to zero by the sender and MUST be
ignored by the receiver.
Sub-Options All sub-options pertaining to this message.
4.3. Reachability Message
The Reachability (RM) message is sent by the MN in stateful mode to
its current AR in order to inform the AR about which APs are reachable
by the MN. This message is also used to send other information about
the MN to the AR, such as the MN's HoA and its current profile, as well
as to periodically refresh the lifetime associated with the MN state
maintained by the AR. This message has an alignment requirement of 4n.
RM Fields:
Type TBA
Trossen, et al. Expires 14 September 2003 [Page 10]
Internet Draft Dynamic CAR Discovery 14 March 2003
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 | Sub-Type |S|R| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-Options ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Reachability Message Format.
Length The size of this message including all
sub-options in units of 8 octets. If the
message does not completely fill the final 8
octets, then padding MUST be added to the end of
the message.
Sub-Type 1
Synchronize (S) The Synchronize bit is set by the sending
node to indicate that the receiving AR should
remove any previous beacon state associated
with the sending MN, treating the contents of
the RM message as an absolute set of current
reachability information.
Revoke (R) The Revoke bit is set by the sender to indicate
that the beacons contained within the message
should be removed from the receiving AR's
current Beacon List associated with the sending
MN.
Reserved This field is reserved for future use. It MUST
be initialized to zero by the sender and MUST be
ignored by the receiver.
Sequence Number The Sequence Number is assigned by the sender
and used by the receiving node to sequence RM
messages. Each RM message sent by a MN MUST
use a sequence number greater than the Sequence
Number value sent in any previous Reachability
message, if any, to the same AR (modulo 2**32).
Sub-Options All sub-options pertaining to this message.
Trossen, et al. Expires 14 September 2003 [Page 11]
Internet Draft Dynamic CAR Discovery 14 March 2003
4.4. Reachability Acknowledgement Message
The Reachability Acknowledgement (RMA) message is sent from the
current AR to the MN upon reception of a RM message. This message has
an alignment requirement of 4n.
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 | Sub-Type | Status |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-Options ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: Reachability Acknowledgement Message Format.
RMA Fields:
Type TBA
Length The size of this message including all
sub-options in units of 8 octets. If the
message does not completely fill the final 8
octets, then padding MUST be added to the end of
the message.
Sub-Type 2
Status An 8-bit unsigned integer indicating the status
of handling the originating RM message. Values
of the Status field less than 128 indicate
success. The following such values are defined:
0 Success
Values of the Status field greater than or equal
to 128 indicate failure to process part or all
of the RM message. The following such Status
values are defined:
128 Bad sequence number
129 Synchronization problem
192 MN is unauthorized
Trossen, et al. Expires 14 September 2003 [Page 12]
Internet Draft Dynamic CAR Discovery 14 March 2003
193 Insufficient resources
194 Administratively prohibited
Sequence Number The Sequence Number in the RMA message is copied
from the Sequence Number field in the RM message
being acknowledged.
Sub-Options All sub-options pertaining to this message.
4.5. Candidate List Request Message
The Candidate List Request (CLR) message is sent by the MN to its
current AR to request a list of CARs or a single TAR. This message
MAY contain Link-Layer and Profile options for immediate use in CAR
selection. This message has an alignment requirement of 4n.
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 | Sub-Type |T|C| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-Options ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: Candidate List Request Message Format.
CLR Fields:
Type TBA
Length The size of this message including all
sub-options in units of 8 octets. If the
message does not completely fill the final 8
octets, then padding MUST be added to the end of
the message.
Sub-Type 3
TAR Selection (T) The TAR Selection bit is set by the sending node
to request that the receiving AR attempt to
perform TAR selection on behalf of the sending
MN.
Trossen, et al. Expires 14 September 2003 [Page 13]
Internet Draft Dynamic CAR Discovery 14 March 2003
Capabilities (C) The Capabilities bit is set by the sending
node to request that the receiving AR include
capabilities for the CARs returned in the
associated CL message.
Reserved This field is reserved for future use. It MUST
be initialized to zero by the sender and MUST be
ignored by the receiver.
Sequence Number The Sequence Number is assigned by the sender
and used by the receiving node to sequence CLR
messages. Each CLR message sent by a MN MUST
use a sequence number greater than the Sequence
Number value sent in any previous Candidate List
Request message, if any, to the same AR (modulo
2**32).
Sub-Options All sub-options pertaining to this message.
4.6. Candidate List Message
The Candidate List (CL) message is sent by the current AR to the MN
in response to a Candidate List Request. Each CAR should be represented
by one or more Link-Layer options indicating the link-layer addresses of
the APs associated with this AR. IP, Privacy and Capabilities options
may follow each Link-Layer option to provide extended information about
each CAR (see Section 4.8). This message has an alignment requirement
of 4n.
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 | Sub-Type | Status |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: Candidate List Message Format.
CL Fields:
Type TBA
Trossen, et al. Expires 14 September 2003 [Page 14]
Internet Draft Dynamic CAR Discovery 14 March 2003
Length The size of this message including all
sub-options in units of 8 octets. If the
message does not completely fill the final 8
octets, then padding MUST be added to the end of
the message.
Sub-Type 4
Status An 8-bit unsigned integer indicating the status
of handling the originating CLR message. Values
of the Status field less than 128 indicate
success. The following such values are defined:
0 Success
Values of the Status field greater than or equal
to 128 indicate failure to process part or all
of the CLR message. The following such Status
values are defined:
128 Bad sequence number
129 MN is not currently supported
130 CAR/TAR selection failed
192 MN is unauthorized
193 Insufficient resources
194 Administratively prohibited
Sequence Number The Sequence Number in the CL message is copied
from the Sequence Number field in the associated
Candidate List Request message.
Sub-Options All sub-options pertaining to this message.
4.7. Physical Neighbor Exchange Message
The Physical Neighbor Exchange (PNE) message is sent from one AR
to another in order to propagate topology information generated by RI
messages. PNE messages are also used to exchange capabilities between
ARs, as well as to periodically refresh those capabilities.
A single message is used for both requests and replies since a single
exchange may actually consist of more than two messages (a verification,
and a two-way capability exchange). To indicate the start of an
exchange, the initiating node MUST set the S-bit in the first message.
Subsequent messages carry the Identifier from the initial message to
indicate that they are part of the same exchange. This message has an
alignment requirement of 4n.
Trossen, et al. Expires 14 September 2003 [Page 15]
Internet Draft Dynamic CAR Discovery 14 March 2003
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 | Sub-Type | Status |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifier |S|T|V|C| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: Physical Neighbor Exchange Message Format.
PNE Fields:
Type TBA
Length The size of this message including all
sub-options in units of 8 octets. If the
message does not completely fill the final 8
octets, then padding MUST be added to the end of
the message.
Sub-Type 5
Status An 8-bit unsigned integer indicating the status
of handling the originating PNE message. Values
of the Status field less than 128 indicate
success. The following such values are defined:
0 Success
1 Verified
Values of the Status field greater than or equal
to 128 indicate failure to process part or all
of the RM message. The following such Status
values are defined:
128 Local AP not verified
129 MN not verified
Identifier A unique identifier used to delineate
independent message exchanges. The Identifier
field should be set by the initiator of a
message exchange with a value not previously
used when communicating with the neighboring
AR. All subsequent messages of that exchange
Trossen, et al. Expires 14 September 2003 [Page 16]
Internet Draft Dynamic CAR Discovery 14 March 2003
MUST copy the Identifier field from the received
message into any reply.
Start (S) The Start bit is set by the sending node to
indicate the start of a new message exchange.
Topology (T) The Topology bit is set by the sending node to
indicate that this message contains topology
related options as part of the CAR discovery
process.
Verify (V) The Verify bit is set by the sending node to
indicate that a verification of the associated
topology information should be performed by the
receiving AR, and a reply be returned with the
status of said verification. The V-bit MUST NOT
be set if the T-bit is unset.
Capabilities (C) The Capabilities bit is set by the sending node
to request that the receiving AR provide its own
capabilities as an option in the reply.
Reserved This field is reserved for future use. It MUST
be initialized to zero by the sender and MUST be
ignored by the receiver.
Sub-Options All sub-options pertaining to this message.
4.8. Message Sub-Options
The CAR discovery protocol described in this document defines eleven
new sub-options used in conjunction with the messages defined in the
previous subsections.
Each sub-option, other than padding, may have an Entity identifier
assigned to distinguish between multiple options of the same type within
the same message. The Entity associates the option with a particular
participant or target of the protocol. The following entities are
defined:
0 None - no entity defined
1 Source - the source of the message
2 Destination - the destination of the message
3 MN - the identity of the mobile node
Trossen, et al. Expires 14 September 2003 [Page 17]
Internet Draft Dynamic CAR Discovery 14 March 2003
4 Previous CoA - the previous CoA of the MN
5 New CoA - the new/current CoA of the MN
6 Previous AR - the previous access router
7 New AR - the new/current access router
8 Previous AP - the previous access point
9 New AP - the new/current access point
10 Link-Layer - an entity identified by its link-layer address
Moreover, the order of sub-options in the message are important.
All sub-options not associated with a Link-Layer entity MUST be placed
in the message prior to the start of any Link-Layer sub-options. Any
sub-option following a Link-Layer sub-option is automatically associated
with the immediately preceding Link-Layer sub-option; the Entity field
MUST be set to 10, Link-Layer.
New sub-options may be added to the protocol in the future. If a
receiving node does not recognize a sub-option, it SHOULD silently
ignore the sub-option and continue processing the message.
4.8.1. Pad1 Sub-Option
The Pad1 sub-option is used to insert one octet of padding into the
Sub-Options area of a message. If more than one octet of padding is
required, the PadN option, described next, should be used, rather than
multiple Pad1 options. This sub-option has no alignment requirements.
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| Type |
+-+-+-+-+-+-+-+-+
Figure 9: Pad1 Sub-Option Format
Pad1 Sub-Options Fields:
Type 0
Trossen, et al. Expires 14 September 2003 [Page 18]
Internet Draft Dynamic CAR Discovery 14 March 2003
4.8.2. PadN Sub-Option
The PadN sub-option is used to insert two or more octets of padding
into the Sub-Options area of a message. For N octets of padding, the
Opt Data Len field contains the value N, and the Padding consists of N-2
zero-valued octets. This sub-option has no alignment requirements.
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 | Padding ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10: PadN Sub-Option Format
PadN Sub-Option Fields:
Type 1
Length The length of the sub-option in octets including
the Type and Length fields.
Padding N-2 octets of padding for a sub-option Length of
N.
4.8.3. Lifetime Sub-Option
The Lifetime sub-option is added to RM, RMA and PNE messages in order
to request or grant a lifetime on the state maintained with regard to
the message's peer. This sub-option has an alignment requirement of 4n.
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 | Entity | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 11: Lifetime Sub-Option Format
Lifetime Sub-Option Fields:
Trossen, et al. Expires 14 September 2003 [Page 19]
Internet Draft Dynamic CAR Discovery 14 March 2003
Type 2
Length 1
Entity An Entity value defined in Section 4.8
indicating to which entity this sub-option
applies.
Reserved This field is reserved for future use. It MUST
be initialized to zero by the sender and MUST be
ignored by the receiver.
Lifetime The lifetime in seconds associated with Entity.
4.8.4. IP Sub-Option
The IP sub-option is added to a message to indicate the global
IP address of a given Entity. For example, the IP address of the
associated AR can accompany the Link-Layer sub-option representing a
candidate target AR in a CL message returned by the AR. An AR may also
add an IP sub-option to a PNE exchange to provide a single, global
address to be used by a peer (see Section 7.7). The sub-option has
an alignment requirement of 4n for IPv4 addresses and 8n for IPv6
addresses.
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 | Entity | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 12: IPv4 Sub-Option Format
IP Sub-Option Fields:
Type 3 or 4. For an IPv4 sub-option the code is 3.
The code is 4 for an IPv6 sub-option.
Length The size of this sub-option in units of 8
octets.
Trossen, et al. Expires 14 September 2003 [Page 20]
Internet Draft Dynamic CAR Discovery 14 March 2003
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 | Entity | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ IP Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 13: IPv6 Sub-Option Format
Entity An Entity value defined in Section 4.8
indicating to which entity this sub-option
applies.
Reserved This field is reserved for future use. It MUST
be initialized to zero by the sender and MUST be
ignored by the receiver.
IP Address The IP address of the target Entity.
4.8.5. Privacy Sub-Option
The Privacy sub-option is added to a message in order to associate
a locally unique identifier with an Entity when the global IP address
provided for that entity is not unique to that device; e.g. an AR with
a private address which uses a global address from a Border Router.
This sub-option has an alignment requirement of 4n.
Privacy Sub-Option Fields:
Type 5
Length 1
Entity An Entity value defined in Section 4.8
indicating to which entity this sub-option
applies.
Trossen, et al. Expires 14 September 2003 [Page 21]
Internet Draft Dynamic CAR Discovery 14 March 2003
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 | Entity | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 14: Privacy Sub-Option Format
Reserved This field is reserved for future use. It MUST
be initialized to zero by the sender and MUST be
ignored by the receiver.
Id A 32-bit unsigned identifier used to identify
the target Entity when multiple nodes may share
a single global IP address.
4.8.6. Profile Sub-Option
A Profile sub-option is added to RM messages in order to transmit a
MN's current profile to an AR. The profile is treated as a binary block
of data. It is not assumed that the entire profile must be sent within
each sub-option. Rather portions of or updates to the profile could be
sent independently. How partial information is managed by the receiver,
however, is outside the scope of this document. This sub-option has an
alignment requirement of 4n.
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 | Entity |A|R| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Length | Profile Data...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 15: Profile Sub-Option Format
Trossen, et al. Expires 14 September 2003 [Page 22]
Internet Draft Dynamic CAR Discovery 14 March 2003
Profile Sub-Option Fields:
Type 6
Length The size of this sub-option in units of 8
octets.
Entity An Entity value defined in Section 4.8
indicating to which entity this sub-option
applies.
Absolute (A) The Absolute bit is set by the sending node to
indicate that the profile data included in the
sub-option MUST override any existing profile
currently cached at the receiving node with
regards to the sending MN.
Revoke (R) The Revoke bit is set by the sending node to
indicate that the profile data included in the
sub-option MUST be removed from the receiving
node's cache for the sending AR.
Reserved This field is reserved for future use. It MUST
be initialized to zero by the sender and MUST be
ignored by the receiver.
Sequence Number The Sequence Number is assigned by the sender
and used by the receiving node to sequence
profile updates. Each Profile sub-option sent
by a MN MUST use a sequence number greater
than the Sequence Number value sent in any
previous Profile sub-option, if any, to the same
receiving node (modulo 2**32).
Lifetime The lifetime in seconds for the profile included
in the sub-option.
Data Length The actual length in bytes of the Profile Data
contained within the sub-option. This field may
be set to zero if no data is present, e.g., to
revoke the complete profile.
Profile Data The Profile Data associated with this entity.
The field MUST be zero-padded to an integral
number of 8-octet units. The actual length of
the data should be placed in the Data Length
field.
Trossen, et al. Expires 14 September 2003 [Page 23]
Internet Draft Dynamic CAR Discovery 14 March 2003
4.8.7. Capabilities Sub-Option
A Profile sub-option is added to CL and PNE messages in order
to transmit an AR's current capabilities to a MN or another AR.
Capabilities are treated as a binary block of data. It is not assumed
that the entire set of capabilities must be sent within each sub-option.
Rather portions of or updates to the capabilities could be sent
independently. How partial information is managed by the receiver,
however, is outside the scope of this document. This sub-option has an
alignment requirement of 4n.
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 | Entity |A|R| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Length | Capabilities Data...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 16: Capabilities Sub-Option Format
Capabilities Sub-Option Fields:
Type 7
Length The size of this sub-option in units of 8
octets.
Entity An Entity value defined in Section 4.8
indicating to which entity this sub-option
applies.
Absolute (A) The Absolute bit is set by the sending node
to indicate that the capabilities included
in the sub-option MUST override any existing
capabilities currently cached at the receiving
node with regards to the sending AR.
Revoke (R) The Revoke bit is set by the sending node to
indicate that the capabilities included in the
sub-option MUST be removed from the receiving
node's cache for the sending AR.
Trossen, et al. Expires 14 September 2003 [Page 24]
Internet Draft Dynamic CAR Discovery 14 March 2003
Reserved This field is reserved for future use. It MUST
be initialized to zero by the sender and MUST be
ignored by the receiver.
Sequence Number The Sequence Number is assigned by the sender
and used by the receiving node to sequence
capability updates. Each Capabilities
sub-option sent by an AR MUST use a sequence
number greater than the Sequence Number value
sent in any previous Capabilities sub-option, if
any, to the same receiving node (modulo 2**32).
Lifetime The lifetime in seconds for the capabilities
included in the sub-option.
Data Length The actual length in bytes of the Capabilities
Data contained within the sub-option. This
field may be set to zero if no data is present,
i.e., to revoke the complete capabilities set.
Capabilities Data The Capabilities Data associated with this
entity. The field MUST be zero-padded to an
integral number of 8-octet units. The actual
length of the data should be placed in the Data
Length field.
4.8.8. Link-Layer Sub-Option
The Link-Layer sub-option is added to messages to describe particular
Entities identified by their link-layer address, namely APs. Each
Link-Layer sub-option may contain an identifier that should be
sufficient to uniquely determine the Entity with respect to the context
of the message. In the case that this identifier is available, the
actual link-layer address may be elided to save bandwidth. This
sub-option has an alignment requirement of 4n.
Other sub-options may be associated with a Link-Layer sub-option to
further describe properties of the Entity. Any sub-options following a
Link-Layer sub-option, not including another Link-Layer sub-option, are
automatically associated with that Link-Layer sub-option.
Link-Layer Sub-Option Fields:
Type 8
Length The size of this sub-option in units of 8
octets.
Trossen, et al. Expires 14 September 2003 [Page 25]
Internet Draft Dynamic CAR Discovery 14 March 2003
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 | Entity | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Id | Data Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link-Layer Address...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 17: Link-Layer Sub-Option Format
Entity An Entity value defined in Section 4.8
indicating to which entity this sub-option
applies.
Reserved This field is reserved for future use. It MUST
be initialized to zero by the sender and MUST be
ignored by the receiver.
Id A locally unique identifier assigned by the MN
to designate this link-layer address.
Data Length The actual length in bytes of the Link-Layer
Address contained within the sub-option. This
field may be set to zero if no address is
present; e.g., the Id is sufficient.
Link-Layer Address
The Link-Layer Address or BSSID associated with
this entity. The field MUST be zero-padded to
an integral number of 8-octet units. The actual
length of the address should be placed in the
Data Length field.
4.8.9. MN Identifier Sub-Option
The MN Identifier sub-option is used by ARs to identify a given
mobile node. The option is included in PNE messages to associate
the topology information with the MN that issued the original Router
Identity message. Section 7.1 describes the method by which ARs can
identify a mobile node. This sub-option has an alignment requirement of
4n.
MN Identifier Sub-Option Fields:
Trossen, et al. Expires 14 September 2003 [Page 26]
Internet Draft Dynamic CAR Discovery 14 March 2003
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 | Entity | ID Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Length | Identifier ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 18: MN Identifier Sub-Option Format
Type 9
Length The size of this sub-option in units of 8
octets.
Entity An Entity value defined in Section 4.8
indicating to which entity this sub-option
applies.
ID Type The type of identifier used (TBD).
Data Length The actual length in bytes of the Identifier
contained within the sub-option.
Identifier The value used to uniquely identify a mobile
node. The field MUST be zero-padded to an
integral number of 8-octet units. The actual
length of the address should be placed in the
Data Length field.
4.8.10. MN Token Sub-Option
The MN Token sub-option is used to carry a token generated by an
AR that is used to verify the presence of a given mobile node after
handover, as described in Section 7.10. The original token is passed to
the MN via either the CL message. After handover, the token is included
with the RI message and the resulting PNE message. This sub-option has
an alignment requirement of 4n.
MN Token Sub-Option Fields:
Type 10
Length The size of this sub-option in units of 8
octets.
Trossen, et al. Expires 14 September 2003 [Page 27]
Internet Draft Dynamic CAR Discovery 14 March 2003
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 | Entity | Index |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Token |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 19: MN Token Sub-Option Format
Entity An Entity value defined in Section 4.8
indicating to which entity this sub-option
applies.
Index The index of the original key used to generate
the token.
Token A 128-bit token generated by an AR, as described
in Section 7.10.
5. Protocol Requirements
The protocol described in this document makes no new requirements
on general IPv4 or IPv6 nodes. Only those nodes, MNs and ARs,
participating in the protocol must support the features described
herein.
5.1. Requirements for Mobile Nodes
A mobile node participating in this CAR discovery protocol MUST
fulfill the following requirements:
- Every participating MN MUST support sending Router Identity
messages as described in Section 6.3.
- Every participating MN MAY support sending Reachability messages
as described in Section 6.5.
- Every participating MN MAY support receiving Reachability
Acknowledgement messages as described in Section 6.6.
Trossen, et al. Expires 14 September 2003 [Page 28]
Internet Draft Dynamic CAR Discovery 14 March 2003
- Every participating MN SHOULD support sending Candidate List
Request messages as described in Section 6.7.
- Every participating MN SHOULD support receiving Candidate List
messages as described in Section 6.8.
- Every participating MN MUST support detecting movement at both
the link-layer and the IP-layer as described in Section 6.1.
- Every participating MN SHOULD support receiving beacons from
nearby APs.
- Every participating MN SHOULD support a TAR resolution protocol
able to incorporate profile and capability information.
5.2. Requirements for Access Routers
An access router participating in this CAR discovery protocol MUST
fulfill the following requirements:
- Every participating AR MUST support receiving Router Identity
messages as described in Section 7.2.
- Every participating AR MUST support receiving Reachability
messages as described in Section 7.3.
- Every participating AR MUST support sending Reachability
Acknowledgement messages as described in Section 7.4.
- Every participating AR MUST support receiving Candidate List
Request messages as described in Section 7.5.
- Every participating AR MUST support sending Candidate List
messages as described in Section 7.6.
- Every participating AR MUST support sending and receiving
Physical Neighbor Exchange messages as described in Sections 7.7
and 7.8, respectively.
- Every participating AR SHOULD be capable of uniquely identifying
attached MNs as described in Section 7.1.
- Every participating AR SHOULD be capable of verifying that
a given MN was attached in the recent past, as described in
Section 7.10.
Trossen, et al. Expires 14 September 2003 [Page 29]
Internet Draft Dynamic CAR Discovery 14 March 2003
- Every participating AR SHOULD have a single, global IP address
used to identify itself with neighboring ARs, as described in
Section 7.7.
- Every participating AR SHOULD support a CAR filtering protocol
able to incorporate profile and capability information.
6. Mobile Node Operation
6.1. Movement Detection
The actual algorithm used to detect movement is necessarily outside
the scope of this document, and dependent upon the mobility protocol
employed by the MN. However, the MN MUST be aware of changes in its
current attachment point, both at the link and network levels. The MN
MUST be able to identify both its current AP, and its current AR. The AR
SHOULD be identifiable by an address not of link-local scope. The AP
can be identified by any unique identifier which we will refer to as the
AP's link-layer address.
Beyond detecting direct handovers between two APs, a MN SHOULD also
be capable of detecting when it disconnects from it current AP/AR
without handing over. This is to ensure that a MN that moves between
two APs with non-overlapping coverage does not incorrectly perceive
the two APs as being physically adjacent. Such a ``disjoint'' change
in access points could possibly be detected by the link-layer itself,
or through more course grained means such as the default router entry
timing out.
If the MN has more than one active interface, then the previous and
current AP SHOULD be tracked independently for each interface.
6.2. Selecting a Source Address
A MN SHOULD maintain a consistent source address for all messages
sent to a given AR. That address MUST uniquely identify the MN at the
AR. In the case that the MN employs the address of the AR (e.g., a MIPv4
Foreign Agent) as its own CoA, then the MN SHOULD use its home address
as the source address of its messages to the AR.
6.3. Sending Router Identity Messages
Upon detecting the completion of a handover, the MN SHOULD send a RI
message to its new AR according to the following rules:
Trossen, et al. Expires 14 September 2003 [Page 30]
Internet Draft Dynamic CAR Discovery 14 March 2003
- In the case that the MN cannot identify either its current or
previous AP, then the RI SHOULD NOT be sent.
- If the MN can identify its current AP, a Link-Layer sub-option
SHOULD be added to the RI with the Entity field set to New AR.
The AP's link-layer address and its length MUST be assigned to
the Link-Layer Address and Data Length fields, respectively. The
Id field SHOULD be set to zero.
- If the handover is not disjoint, the previous and new APs have
overlapping coverage areas (see Section 6.1), then the RI MUST be
sent according to the additional following rules:
* An IP sub-option MUST be included for the global IP address
of the previous AR. This address can be the one used directly
by the MN in communication with said AR, or one supplied
by the AR as an IP sub-option in a previous message. If a
global IP address is not available, then the handover should
be treated as disjoint. The Entity field MUST be set to
Previous AR.
* If the previous AR provided the MN with a Privacy sub-option
in a previous RM or CL message, a new Privacy sub-option MUST
be added to the RI with the Id field copied from the original
sub-option sent by the AR. The Entity field MUST be set to
Previous AR.
* If the previous AR provided the MN with a MN Token sub-option
in a previous RM or CL message, a new MN Token sub-option
MUST be added to the RI with the Index and Token fields
copied from the original sub-option sent by the AR. The
Entity field MUST be set to MN.
* If the MN can identify its previous AP, a Link-Layer
sub-option SHOULD be added to the RI with the Entity field
set to Previous AP. The AP identifier and its length MUST be
assigned to the Link-Layer Address and Data Length fields,
respectively. The Id field SHOULD be set to zero.
* An IP sub-option MAY be included for the previous CoA of the
mobile node, the same CoA used by the MN to send RM messages
to the previous AR. The Entity field MUST be set to Previous
CoA.
6.4. Tracking AP Beacons
Upon handover, a MN MUST clear its current Beacon List, or otherwise
mark the existing beacons in the list such that the next beacon
Trossen, et al. Expires 14 September 2003 [Page 31]
Internet Draft Dynamic CAR Discovery 14 March 2003
from the same AP will be treated as newly heard. When a new beacon
is heard, an entry SHOULD be made in the MN's Beacon List with an
appropriate lifetime. The lifetime could be a property of the beacon
itself or based on the expected beacon frequency. Upon receiving
subsequent beacons from the same AP, the MN SHOULD update the lifetime
of associated beacon in its Beacon List. When a beacon entry's lifetime
expires, it MUST be removed from the Beacon List, or otherwise marked as
no longer active such that the next beacon from that AP will be treated
as newly heard. Only active beacons SHOULD be considered when reporting
reachability information.
6.5. Sending Reachability Messages
Reachability messages SHOULD NOT be sent unless the MN is currently
engaged in the stateful mode of the protocol. If in stateful mode, the
MN SHOULD send an RM in any of the following cases:
- When a new beacon is received, one not already represented in the
MN's Beacon List. In this case, the link-layer address of the AP
(or other unique AP identifier) MUST be included via a Link-Layer
sub-option. The locally-unique Id assigned to this beacon by the
MN SHOULD be assigned to the Id field of the sub-option.
- When the lifetime of a beacon entry in the Beacon List expires.
In this case, the R-bit of the RM message MUST be set. A
Link-Layer sub-option MUST be included in the message indicating
which beacon. If a locally-unique Id was previously assigned to
this beacon and transmitted to the AR, then only the Id SHOULD be
included.
- When the lifetime associated with the MN's state at the AR is
close to expiration. In this case, a Lifetime sub-option SHOULD
be included in the message with the new requested lifetime.
- After receiving a previous RMA message with a Status value
indicating that the AR and MN are unsynchronized. In this case,
the S-bit of the RM message MUST be set, and a set of Link-Layer
sub-options SHOULD be included with the current contents of
the MN's Beacon List. The MN MAY choose to limit the number
of beacons sent in one message. In this case, beacon entries
not sent MUST be deleted or marked in such a way that the next
associated beacon received will trigger a new RM message as
described in this subsection.
Each RM message sent by the MN MUST abide by the following rules:
Trossen, et al. Expires 14 September 2003 [Page 32]
Internet Draft Dynamic CAR Discovery 14 March 2003
- The first RM message sent after handover MUST have the S-bit set
to indicate synchronization in case the AR has pre-existing,
stale state for the MN.
- If any beacons included in the message are to be revoked, the
R-bit is set, then all beacons listed in the message MUST also
be marked for revocation. In other words, a single RM message
may contain beacons to add to the AR's Beacon List, or beacons to
remove from the list, but not both.
- Each RM message MUST have a Sequence Number assigned larger than
any previous RM message sent to the same AR, if any.
Any RM sent may carry additional sub-options such as the Profile
sub-option. Also, the MN MAY choose to delay a RM message a short time
in order to collect a number of beacons in one message.
The MN MAY retransmit a RM message after waiting some period of
time for the associated RMA. The retransmitted message MUST have a new
Sequence Number assigned larger than that of the original message.
Retransmissions MUST be rate limited, and SHOULD NOT be sent more
frequently than one per MIN_RM_PERIOD, and should not be repeated more
than MIN_RM_RETRY times. The MN SHOULD exponentially backoff the
time between each retransmission. If an acknowledgement has not been
received after exhausting the total number of allowed retries, a MN
SHOULD consider itself unsupported by the current AR, and cease sending
further Reachability messages until after handing-over to another AR.
6.6. Receiving Reachability Acknowledgement Messages
Upon receiving a Reachability Acknowledgment message, the MN MUST
validate the message according to the following rules:
- The message MUST originate from the MN's current AR.
- The Sequence Number MUST match an outstanding RM message awaiting
acknowledgement.
An invalid RMA MUST be silently ignored. The MN MUST act on a valid
RMA according to the value of the Status field:
- A Success value indicates that the originating RM was accepted.
The MN SHOULD update its state accordingly and MUST refrain from
retransmitting the originating RM message.
- For a Status value indicating that the sequence number was
incorrect, the MN SHOULD increment the Sequence Number value used
Trossen, et al. Expires 14 September 2003 [Page 33]
Internet Draft Dynamic CAR Discovery 14 March 2003
in the next RM by some reasonable amount. The originating RM MAY
be retransmitted with this new Sequence Number.
- For a Status value indicating a synchronization problem, the MN
SHOULD transmit a new RM message with the S-bit set as described
in Section 6.5.
- For Status values indicating that the MN is not currently
supported by the AR due to security, administrative or resource
constraints, the MN SHOULD cease sending Reachability messages
until after handing-over to another AR.
6.7. Sending Candidate List Request Messages
The MN MAY send a Candidate List Request message to its current AR
at any time prior to handover. The message SHOULD be sent as close to
the time of handover as possible to ensure that the information provided
in the associated CL message is current. The CLR message MUST be sent
according to the following rules:
- Each CLR message MUST have a Sequence Number assigned larger than
any previous CLR message sent to the same AR, if any.
- The MN MAY set the T-bit of the CLR message to request that the
AR return a single TAR rather than a set of CARs. This, however,
may not be supported by the current AR.
- The MN MAY set the C-bit of the CLR message to request that the
AR include capability information with the set of CARs returned
in the CL message.
- The MN MAY include Link-Layer sub-options representing reachable
AP's that should be used to select CARs. This list of APs will
be used by the AR only to respond to this CLR, superseding any
current beacon state maintained by the AR on behalf of the MN.
The previously maintained Beacon List, if any, will not be
affected.
- The MN MAY include a Profile sub-option to be used by the AR
in selecting appropriate CARs. This profile will be used by
the AR only to respond to this message, superseding any current
profile maintained by the AR on behalf of the MN. The previously
maintained profile, if any, will not be affected.
The MN MAY retransmit a CLR message after waiting some period of
time for the associated CL message. The retransmitted message MUST
have a new Sequence Number assigned larger than that of the original
message. Retransmissions MUST be rate limited, and SHOULD NOT be sent
Trossen, et al. Expires 14 September 2003 [Page 34]
Internet Draft Dynamic CAR Discovery 14 March 2003
more frequently than one per MIN_CLR_PERIOD, and should not be repeated
more than MIN_CLR_RETRY times. If an acknowledgement has not been
received after exhausting the total number of allowed retries, a MN
SHOULD consider itself unsupported by the current AR and cease sending
further protocol messages until after handing-over to another AR.
6.8. Receiving Candidate List Messages
Upon receiving a Candidate List message, the MN MUST validate the
message according to the following rules:
- The message MUST originate from the MN's current AR.
- The Sequence Number MUST match an outstanding CLR message
awaiting acknowledgement.
An invalid CL message MUST be silently ignored. The MN MUST act on a
valid CL according to the value of the Status field:
- A Success value indicates that the originating CLR was
accepted, and that at least one CAR or TAR has been selected.
The MN SHOULD pass the selected CAR(s) along to the TAR
resolution algorithm, if one is available, and MUST refrain from
retransmitting the originating CLR message.
- For a Status value indicating that the sequence number was
incorrect, the MN SHOULD increment the Sequence Number value used
in the next CLR by some reasonable amount. The originating CLR
MAY be retransmitted with this new Sequence Number.
- For a Status value indicating that the CAR/TAR selection process
failed, MN MAY send new CLR messages in the future, but SHOULD
NOT retransmit the originating CLR.
- For Status values indicating that the MN is not currently
supported by the AR due to security, administrative or resource
constraints, the MN SHOULD cease sending protocol message until
after handing-over to another AR.
7. Access Router Operation
7.1. Identifying Mobile Nodes
The first step in verifying the presence of a mobile node is to
be able to properly identify it. One option is to use the mobile
node's IP address, either its care-of or home address. The problem
with this approach is that IPv6 nodes can generate any number of
Trossen, et al. Expires 14 September 2003 [Page 35]
Internet Draft Dynamic CAR Discovery 14 March 2003
care-of addresses, and there exists no means for an AR to confirm
that the home address provided actually belongs to the mobile node.
Instead, the access router identifies the MN via the same credentials
originally provided by the mobile node while authenticating with
the AR. In cellular systems, this might be the International Mobile
Subscriber Identifier (IMSI) from the phone's SIM card. For AAA-based
authentication, the user's Network Access Identifier (NAI) would be
used. In either case, this identifier will have been validated by
the access router as part of the process of authentication, and thus
provides a certain level of accountability against malicious activities.
7.2. Receiving Router Identity Messages
A MN sends a Router Identity message to its current AR after
handover. The RI message carries the link-layer addresses of the
previous and/or new APs, as well as the global address of the previous
router. If an IP sub-option for the previous AR (as determined by the
Entity field) is not included or set to an address local to the new AR
(with the addition of a possible privacy sub-option), then the handover
is considered local to the AR.
The AR MUST validate the RI message according to the following rules:
- All RI messages received MUST be rate limited as described in
Section 7.9.
- The message MUST contain either a new or previous AP address,
provided via Link-Layer sub-options with the Entity field set to
New AR or Previous AR, respectively.
- If the new AP address is included in the message, the AR MUST
verify that the link-layer address provided in the sub-option
represents a viable local AP. This check could be made against an
actual list of known attached APs, or a list of APs authorized to
be considered local.
- If the handover is local to the AR, the AR MUST further validate
the message according to the following rules:
* If a previous AP address is included, the AR MUST verify that
the link-layer address provided in the sub-option represents
a viable local AP. This check could be made against an actual
list of known attached APs, or a list of APs authorized to be
considered local.
An invalid RI message MUST be silently ignored. Otherwise, the AR
SHOULD add any local APs referenced in the message (see above) to its
Trossen, et al. Expires 14 September 2003 [Page 36]
Internet Draft Dynamic CAR Discovery 14 March 2003
Physical Neighbor Cache as locally attached, if not already. The AR
SHOULD then update the lifetime of these AP entries to AP_LIFETIME.
If the handover is not local, the AR SHOULD send a PNE to the
previous AR indicated in the RI message according to the rules outlined
in Section 7.7.
7.3. Receiving Reachability Messages
Upon receiving a Reachability message from a MN, the AR SHOULD create
a new MN entry in its list of supported MNs, if not already. The AR MAY
choose not to create a new entry based on administrative or resource
constraints. If the AR chooses not to support the MN, it MUST return
a RMA with the appropriate error value in the Status field. All RM
messages received MUST be rate limited as described in Section 7.9. The
rest of this subsection assumes that the AR has created the MN entry and
will support the MN for stateful CAR discovery.
Upon receiving a RM message, the AR MUST verify that the Sequence
Number is greater than any received from the MN in prior RM messages.
This requirement only covers the current ``session'' with the MN. Once
a MN hands-over to another AR, the MN state MAY be deleted, and future
sequence numbers do not have to be checked against those prior to
deletion. If the sequence number check fails, the AR MUST return a RMA
message with the appropriate error value in the Status field.
For valid RM messages, the AR MUST return a Reachability
Acknowledgment message, and SHOULD update the MN's state according to
the following rules:
- If the S-bit is set, the AR MUST delete all existing Beacon
Entries from the MN's Beacon List.
- If the R-bit is set, the AR MUST delete all Beacon Entries
matching those listed as Link-Layer sub-options. A Beacon Entry
MAY be identified by either the Id field or the actual Link-Layer
Address if provided. If any Link-Layer sub-option is not matched
to an existing Beacon Entry, the AR MUST return a RMA with the
Status field set to indicate that the AR has lost synchronization
with the MN.
- If the R-bit is unset, the AR SHOULD create or update a Beacon
Entry for each Link-Layer sub-option included in the message.
If a non-zero Id is provided, the AR MUST save this Id with the
Beacon Entry. If the AR cannot handle (create or update) all
of the Link-Layer sub-options included in the message, it MUST
return a RMA with the Status field set to indicate that the AR
has lost synchronization with the MN.
Trossen, et al. Expires 14 September 2003 [Page 37]
Internet Draft Dynamic CAR Discovery 14 March 2003
- If an IP sub-option is included with the Entity field set to MN,
the AR MAY save the MN's HoA as part of MN entry.
- If a Lifetime sub-option is included in the message, the AR
SHOULD update the remaining lifetime of the associated MN
entry by a value no greater than that specified in the Lifetime
sub-option. If the specified lifetime is zero, the AR MUST
delete the MN entry immediately. The granted lifetime SHOULD be
returned in the RMA as a separate Lifetime sub-option.
- If a Profile sub-option is included in the message, the AR SHOULD
save the profile data with the associated MN entry for use in
CAR/TAR selection.
7.4. Sending Reachability Acknowledgement Messages
The AR MUST send a Reachability Acknowledgment Message to a MN in
response to a RM message. A RMA sent by the AR MUST abide by the
following rules:
- The Sequence Number MUST be copied from the Sequence Number field
of the originating RM.
- The Status field MUST be set to an error value if part or all of
the RM message could not be processed. A non-error value SHOULD
be used otherwise.
- If the originating RM message contained a Lifetime sub-option,
the AR SHOULD include a Lifetime sub-option with the granted
lifetime for the MN entry.
- The AR MAY include a MN Token sub-option generated according to
Section 7.10.
- The AR MAY also include an IP sub-option with the Entity field
set to Source and the IP Address field set to a global IP address
that the MN should use when referring to this AR in subsequent RI
messages. Additionally, the AR MAY include a Privacy sub-option
with a 32-bit identifier to be used by a neighboring AR in
subsequent communications.
7.5. Receiving Candidate List Request Messages
If an AR receives a Candidate List Request message without Link-Layer
sub-options for a MN for which it has no corresponding MN state, it
SHOULD return a CL message indicating that the MN is not currently
supported. The AR MAY choose not to fulfill the request due to
Trossen, et al. Expires 14 September 2003 [Page 38]
Internet Draft Dynamic CAR Discovery 14 March 2003
administrative or resource constraints. If the AR chooses not to
fulfill the CLR, it MUST return a CL message with the appropriate
error value in the Status field. All CLR messages received MUST be
rate limited as described in Section 7.9. The rest of this subsection
assumes that the AR will accept the CLR message.
Upon receiving a CLR message, the AR MUST verify that the Sequence
Number is greater than any received from the MN in prior CLR messages.
This requirement only covers the current ``session'' with the MN. Once
a MN hands-over to another AR, the MN state MAY be deleted, and future
sequence numbers do not have to be checked against those prior to
deletion. If the sequence number check fails, the AR MUST return a CLR
message with the appropriate error value in the Status field.
For a valid CLR message, the AR MUST process the message according to
the following rules:
- If Link-Layer sub-options are included in the message, the AR
MUST use the associated link-layer addresses as the list of
reachable APs for use in CAR/TAR selection. Otherwise, the AR
MUST use the Beacon Entries from the Beacon List associated with
the MN, if any.
- If a Profile sub-option is included in the message, the AR MUST
use the associated profile data for use in CAR/TAR selection.
Otherwise, the AR MUST use the profile stored in association with
the MN, if any.
- The AR SHOULD select a limited number of CARs based on a number
of factors. The exact selection algorithm is beyond the scope of
this document.
* Only those CARs SHOULD be considered that have associated
AP entries in the PNC which match the list of reachable APs
reported by the MN.
* The MN's profile, if available, SHOULD be used in conjunction
with the neighboring AR capabilities to select the most
appropriate CARs. The total number of CARs returned to the
MN could be a parameter of the MN's profile.
* If the T-bit is set in the CLR message, the AR MAY select a
single CAR as a target AR.
- If the C-bit is set in the CLR message, the AR SHOULD attempt
to return capability information for each CAR in the selected
list as Capabilities sub-options associated with each Link-Layer
sub-option. The capabilities sent MAY be a subset of the
complete AR capabilities, dependent upon the MN's profile.
Trossen, et al. Expires 14 September 2003 [Page 39]
Internet Draft Dynamic CAR Discovery 14 March 2003
Again, how to reduce the capability sets is dependent upon the
format and content of the capabilities and profile, and are
beyond the scope of this document.
7.6. Sending Candidate List Messages
An AR SHOULD send a Candidate List message in response to a CLR
message from an authorized MN. If the CLR message does not contain an
explicit list of reachable APs and the AR does not have reachability
state for the MN, the AR SHOULD return a CL message with an appropriate
Status value indicating the lack of MN state at the AR.
A CL sent by the AR MUST abide by the following rules:
- The Sequence Number MUST be copied from the Sequence Number field
of the originating CLR.
- The Status field MUST be set to an error value if part or all of
the CLR message could not be processed. A non-error value SHOULD
be used otherwise.
- Each selected CAR SHOULD be represented by one or more Link-Layer
sub-options indicating the associated APs selected as targets
for the MN handover. Extra information associated with each AP,
such as related IP addresses or capabilities, MUST follow the
Link-Layer sub-option as separate sub-options prior to the next
Link-Layer sub-option in the message.
- The AR MAY include a MN Token sub-option generated according to
Section 7.10.
7.7. Sending Physical Neighbor Exchange Messages
Each AR SHOULD have a global ``identifying'' IP address that it uses
in communication with neighboring routers. This is necessary since a
single router may have multiple assigned addresses, each interface with
a different address. As the MN moves between routers, it will see only
the interface-specific address of the router. Thus, a single AR would
look like multiple neighbors to another AR that receives RIs from MNs
handing-over from each of the different interfaces. The identifying
address is used to unify the PNC entries for a neighboring AR. All
Physical Neighbor Exchange messages sent to a neighboring AR SHOULD use
this identifying address as the Source Address. One exception is noted
below.
Trossen, et al. Expires 14 September 2003 [Page 40]
Internet Draft Dynamic CAR Discovery 14 March 2003
All PNE messages sent MUST be rate limited as described in
Section 7.9. An AR MAY send a PNE message to a neighboring router in
any of the following situations, however:
- The AR receives a valid RI message with a non-local previous AP
address specified as a Link-Layer sub-option with the Entity
field set to Previous AP. The resulting PNE MUST follow the
following rules:
* The S and T-bits MUST be set.
* The V-bit SHOULD be set unless the AR does not require
verification of the previous AP for some unspecified reason.
* If present, the new AP and/or previous AP Link-Layer
sub-options included in the RI SHOULD be copied to the PNE.
* The AR MUST include a MN Identifier sub-option with the
identity of the MN that originated the RI messages, as
described in Section 7.1.
* If present, the MN Token sub-option included in the RI
message SHOULD be copied to the PNE.
- The AR attempts to verify the previous AP address of a PNE sent
by a neighboring router, and the V-bit is set in the originating
PNE. The reply PNE MUST follow the following rules:
* The T-bit MUST be set and the V-bit MUST be unset.
* The Status field MUST be set to Verified if verification
succeeds or an appropriate error value otherwise.
* If verified, the previous AP identifier from the originating
PNE MUST be included as a Link-Layer sub-option with the
Entity field set to Previous AP.
* If verified, the AR MUST copy the MN Identifier sub-option
from the original PNE message.
* If the Destination Address of the originating PNE is not
the identifying address of the AR, the Source Address of
the reply PNE MUST be set to the Destination Address of the
initial PNE. Furthermore, an IP sub-option SHOULD be added to
the message with the Entity field set to Source and the IP
Address field assigned the identifying address.
- The AR receives a PNE from a neighboring router with the
C-bit set. The AR MUST verify that the sending AR is a valid
Trossen, et al. Expires 14 September 2003 [Page 41]
Internet Draft Dynamic CAR Discovery 14 March 2003
neighboring AR by checking for a entry in the PNC. The return PNE
SHOULD contain a Capabilities sub-option with the AR's capability
information.
- The AR requires the capabilities of a neighboring router, or the
existing set of capabilities are close to expiration. In this
case, the AR MUST set the C-bit of the PNE.
For initial packets of a message stream, those with the S-bit
set, the AR MUST select an Identifier with a significant chance of
remaining unique between the two communicating ARs for the duration of
the exchange. For subsequent packets, the Identifier field MUST be
copied from the originating PNE message. The S bit MUST NOT be set in
non-initial packets.
7.8. Receiving Physical Neighbor Exchange Messages
Upon receiving a Physical Neighbor Exchange message, the AR MUST
validate the message according to the following rules:
- Received PNE messages MUST be rate limited as described in
Section 7.9.
- If the T-bit is not set, the V-bit MUST NOT be set.
- If the T-bit is set, the previous AP address MUST be included as
a Link-Layer sub-option with the Entity field set to Previous AP.
- If a MN Token sub-option is present then a MN Identifier MUST
also be present in the PNE.
The AR MUST silently discard invalid PNE messages. If the S and
T-bits are set, the AR MUST further verify the included topology
information according to the following rules:
- The AR MUST verify that the previous AP's link-layer address
provided in the sub-option represents a viable local AP. This
check could be made against an actual list of known attached APs,
such as the local entries in the PNC, or a list of APs authorized
to be considered local.
- If a MN Token sub-option is present, the AR SHOULD verify that
the MN that sent the originating RI message, as identified by the
MN Identifier sub-option, was indeed present at the AR within
some reasonable amount of time, as described in Section 7.10.
If the topology verification fails and the V-bit of the original PNE
is set, the AR MUST reply with another PNE as described in Section 7.7.
Trossen, et al. Expires 14 September 2003 [Page 42]
Internet Draft Dynamic CAR Discovery 14 March 2003
For verified PNE messages, processing is dependent upon the value of the
S-bit. If the S-bit is set, the following rules MUST be followed in
processing the PNE:
- If the T-bit is set, the AR SHOULD create a PNC entry for the
previous AP as locally attached, if not already. The AR SHOULD
update the lifetime of the previous AP entry to AP_LIFETIME.
- If the T-bit is set, the AR SHOULD create a PNC entry for the
neighboring AR in its PNC, if not already. If the new AP is
included in the PNE message, the AR SHOULD create an associated
AP entry related to the neighboring AR in the PNC, if not
already. The AR SHOULD update the lifetime of the new AP entry
to AP_LIFETIME.
- If a Lifetime sub-option is included in the PNE, the AR SHOULD
update the lifetime of the corresponding neighbor entry in the
PNC, if it exists, with a value no greater than that specified in
the sub-option. The granted lifetime SHOULD be returned in a PNE
reply message.
If the S-bit is not set, the following rules MUST be followed in
processing the PNE:
- If the T-bit is set, the AR SHOULD create PNC entries for the
previous AR and previous AP, if not already. The AR SHOULD
update the lifetime of the AR and AP entries to AR_LIFETIME and
AP_LIFETIME respectively.
- If an IP sub-option is included with the Entity field set to
Source, the address indicated by the sub-option SHOULD be used by
the AR as the identifying address of the neighboring router. An
existing PNC entry for the Source Address of the message SHOULD
be converted to or merged with a PNC entry for the identifying
address.
7.9. Rate Limiting
All messages exchanged between participants MUST be rate limited.
Once the configured rate limit has been reached, subsequent packets MUST
be silently discarded. For messages received from mobile nodes, rate
limiting could be applied on a per-MN basis, as well as to the total
number of RI, CLR and RM messages received. PNE messages SHOULD be rate
limited separately for each neighboring AR, as well as for the total
number of PNE messages sent. Moreover, upon receiving an RI message,
an AR MAY choose not to send a PNE message an existing cache entry
exists for the previous <AR,AP> tuple with a lifetime that is above some
configurable threshold.
Trossen, et al. Expires 14 September 2003 [Page 43]
Internet Draft Dynamic CAR Discovery 14 March 2003
7.10. Validating Previously Attached MNs
In order to verify that the mobile node was recently present, the
previous router seemingly must maintain some short-lived state for each
attached mobile node. For mobile nodes using the stateful mode of
the protocol, this state is available. To support a large number of
mobiles running in stateless mode, however, a more scalable solution is
necessary.
Rather than track the identity of each attached mobile for some
period of time, we propose that the access router generate a token
that it appends to each Candidate List message that it sends to a
mobile node. The mobile node then submits this token with its Router
Identity message, and the token is passed back to the previous AR for
verification along with the mobile's identification as part of the PNE
message. To generate a token, the AR maintains a small list of random
numbers used as keys to hash the identity of the mobile node. Each
random number is associated with an index that is passed along with the
token. Upon receiving a token for verification, the access router uses
the index to lookup the associated key, hashes the MN identity passed in
the PNE message and compares the hash to the token. As time progresses,
new keys are generated and added to the head of the list while old keys
are expired and removed. The length of the list and the frequency of
generated keys are configurable and determine the total amount of time a
mobile will be considered as having been recently attached.
7.11. Limiting Cache Entries
In order to mitigate the effect of erroneous reports made by possibly
malicious MNs, the AR can limit the number of cache entries it creates
in response to any given mobile node. When creating a cache entry,
the AR SHOULD tag the entry with the identity of the mobile node (see
Section 7.1). Further RI messages from the same mobile will not result
in new cache entries being created once the limit is reached. We
recommend a limit of two or three cache entries per mobile node.
8. Protocol Constants
The description of the CAR discovery protocol introduces a number of
constants that we further define in this section. Each of these values
MUST be configurable.
MIN_RM_PERIOD 2 sec.
MAX_RM_RETRY 5
MIN_CLR_PERIOD 0.5 sec.
Trossen, et al. Expires 14 September 2003 [Page 44]
Internet Draft Dynamic CAR Discovery 14 March 2003
MAX_CLR_RETRY 3
AP_LIFETIME 180 sec
AR_LIFETIME 600 sec.
9. IANA Considerations
The message containers described herein require a single ICMP type
to be assigned from the available type space, as well as a single
Payload Protocol Identifier for SCTP. The messages themselves require
a single ICMP option type to be assigned. Message sub-types should be
standardized, but do not require assignment from an existing, restricted
numbering space.
10. Security Considerations
In order to secure both the discovery process, as well as the
capability and profile exchanges, all messages should be secured with
IPSec or TLS to provide authentication and ensure message integrity.
The primary question is whether the security associations between the
MN and AR and between neighboring ARs explicitly provide any type of
authorization to engage in the CAR discovery protocol. If not, then a
separate facility is necessary to provide this type of authorization,
e.g., ACLs.
Even with authorized security associations, the discovery process
is not completely secure since the ARs depend upon the MNs to properly
report their handovers. Although a number of verification steps,
outlined in Sections 7.2, 7.8, 7.10 and 7.11, provide strong evidence
that a given RI message is valid, it is possible for a set of colluding
MNs to pollute the PNC of ARs. However, since all PNC entries are
maintained as soft-state, collection of MNs would need to continually
provide false information to sustain the polluted entries. Moreover,
the polluted entries would not affect non-malicious MNs since CAR
selection is based on the reachability information provided by the
non-malicious MN. If the attack was persistent and widespread, though,
it could possibly result in resource exhaustion at the AR. The AR SHOULD
limit the size of the PNC to eliminate this possibility, and implement
an appropriate cache replacement policy that favors information
collected from local reports, RIs and CLRs.
11. Intellectual Property Rights Notice
Nokia Corporation and/or its affiliates hereby declare that they
are in conformity with Section 10 of RFC 2026. Nokia's contributions
Trossen, et al. Expires 14 September 2003 [Page 45]
Internet Draft Dynamic CAR Discovery 14 March 2003
may contain one or more patents or patent applications. To the extent
Nokia's contribution is adopted to the specification, Nokia undertakes
to license patents technically necessary to implement the specification
on fair, reasonable and nondiscriminatory terms based on reciprocity.
Acknowledgements
The authors would like to acknowledge Richard D. Gitlin for his
efforts in the design of this protocol.
References
[1] S. Bradner. Key words for use in RFCs to Indicate Requirement
Levels. RFC 2119, Internet Engineering Task Force, March 1997.
[2] A. Conta and S. Deering. Internet Control Message Protocol
(ICMPv6) for the Internet Protocol Version 6 (IPv6)
Specification. RFC 2463, Internet Engineering Task Force,
December 1998.
[3] K. El Malki (Editor). Low Latency Handoffs in Mobile IPv4.
Technical Report draft-ietf-mobileip-lowlatency-handoffs-v4-*.txt,
Internet Engineering Task Force (IETF), June 2002.
[4] D. Johnson, C. Perkins, and J. Arkko. Mobility Support in
IPv6. Technical Report draft-ietf-mobileip-ipv6-*.txt, Internet
Engineering Task Force (IETF), January 2003.
[5] J. Kempf (Editor). Problem Description: Reasons for Performing
Context Transfers between Nodes in an IP Access Network.
Request for Comments (Informational) 3374, Internet Engineering
Task Force (IETF), September 2002.
[6] R. Koodli (Editor). Fast Handovers for Mobile IPv6. Technical
Report draft-ietf-mobileip-fast-mipv6-*.txt, Internet
Engineering Task Force (IETF), September 2002.
[7] G. Krishnamurthi, Chalmers R., and C. Perkins. Buffer
Management for Smooth Handovers in Mobile IPv6. Technical
Report draft-krishnamuthi-mobileip-buffer6-*.txt, Internet
Engineering Task Force (IETF), March 2001.
[8] C. Perkins, editor. IP Mobility Support. RFC 2002, Internet
Engineering Task Force, October 1996.
[9] J. Postel. Internet Control Message Protocol. RFC 792,
Internet Engineering Task Force, September 1981.
Trossen, et al. Expires 14 September 2003 [Page 46]
Internet Draft Dynamic CAR Discovery 14 March 2003
[10] R. Stewart, Q. Xie, K. Morneault, C. Sharp, H. Schwarzbauer,
T. Taylor, I. Rytina, M. Kalla, L. Zhang, and V. Paxson. Stream
Control Transmission Protocol. RFC 2960, Internet Engineering
Task Force, October 2000.
[11] D. Trossen, G. Krishnamurthi, H. Chaskar, and J. Kempf.
Issues in Candidate Access Router Discovery. Technical Report
draft-ietf-seamoby-cardiscovery-*.txt, Internet Engineering Task
Force (IETF), November 2001.
Trossen, et al. Expires 14 September 2003 [Page 47]
Internet Draft Dynamic CAR Discovery 14 March 2003
A. Conformance to Requirements
Identifying the IP Address of a CAR
The mapping between the link-layer address of an AP, as known to the
MN, and the IP address of the associated AR is achieved as part of the
dynamic topology discovery process. When the MN sends an RI message
to its new AR, it specifies both the IP address of the previous AR, as
well as the link-layer identifier of the previous AP. This allows ARs
to build the AP to AR mapping. This mapping can then be provided, if
necessary, to the MN as an IP sub-option associated with each Link-Layer
sub-option in a CL message returned to the MN.
Support for Inter-Technology Handoffs
Since the Link-Layer sub-option format does not dictate any
particular length or form for the AP identifiers, dyCARD is independent
of the actual technologies used at the link-level. The only assumption
made by the protocol is that two APs of differing technology with
overlapping coverage areas would not have identifiers that are of the
same length and the same value. In this case, they would be viewed as a
single AP by the ARs.
Identifying CARs having Site-local and Private Addresses
Site-local and private addresses are accommodated by the protocol
through the use of IP and privacy sub-options. If an AR does have a
private address on the interface accessed by the MN, the AR informs the
MN of which global IP address and private Id to use when sending an RI
to the next AR. This global address/private Id pair is then used by
the new AR to contact the previous AR given that the device owning the
global address, such as a Border Router, participates in the exchange.
Exactly how this should be accomplished is beyond the scope of this
document.
Capability Discovery
ARs are able to exchange and refresh capabilities once a neighboring
relationship has been established. The PNE message can be used to
request new capabilities. The actual capabilities are carried in the
Capabilities sub-option. Capabilities can also be forwarded to the MN
through the same sub-option, as part of the CL message.
Trossen, et al. Expires 14 September 2003 [Page 48]
Internet Draft Dynamic CAR Discovery 14 March 2003
Utilization of Network Resources
The CAR discovery protocol we have proposed makes every effort to
limit the bandwidth used, especially over the wireless link between the
MN and the AR.
Specifically, the semi-stateful design of the reachability message
limits the number of messages to at most two per distinct beacon
received, one upon first receiving the beacon and possibly another if
the beacon disappears. Moreover, each RM message can contain multiple
beacon reports. The use of beacon Ids also works towards reducing
bandwidth. Upon reporting a new beacon, the MN assigns it a locally
unique Id which it sends in the Link-Layer sub-option. Later, when the
AR sends a CL message with a list of candidate APs, only the Ids need
be present, the actual addresses may be elided. The same applies to
revoking a previously reported beacon.
Another design feature intended to save bandwidth on the wireless
link is the use of the Beacon List by the AR to reduce the set of
possible CARs sent to the MN. Capabilities sent along with each CAR
could also be reduced to include only those items relevant to the MN's
requirements. Finally, the CLR message includes the T-bit which when
set allows the AR to perform the TAR selection procedure locally and
return only the selected TAR.
Format of Capabilities
The correct operation of the CAR discovery protocol is not dependent
upon the format of capabilities or the MN profile. All messages
exchange capabilities and profiles as binary blocks. The management and
use of these blocks of data are delegated to companion specifications
related to the TAR selection algorithm, and are outside the scope of
this document.
Scope of CAR Discovery
The design of the CAR discovery protocol is in no way restricted
by the location of the two neighboring ARs. They could be within the
same domain, or in different domains administered separately. The
only requirement made by the protocol is that the two ARs are capable
of establishing a security association that provides the explicit
authorization to engage in the CAR discovery protocol.
Trossen, et al. Expires 14 September 2003 [Page 49]
Internet Draft Dynamic CAR Discovery 14 March 2003
Introduction of Dedicated Network Elements for CAR Discovery
The CAR discovery protocol described in this document does not
introduce any new network elements. The only exception is the necessary
presence of some proxy device that would allow the use of a global
address/private Id pair to establish communication with a privately
addressed AR. This, however, is not a new requirement for supporting
private address spaces.
Involvement of Non-CARs in CAR Discovery
Only the MN and the two ARs involved in a particular handover
participate in the CAR discovery protocol.
Dependence on a Mobility Management Protocol
The CAR discovery protocol does not depend on any particular mobility
protocol in order to operate correctly. Within this document, we
use terminology, such as Care-of Address, that is normally related
specifically to Mobile IP. This, however, is done only to simplify the
discussion.
In the presence of other mobility-related protocols, there are
opportunities for optimizing the performance of our protocol. See
Appendix B for details on optimizing performance when used in
conjunction with Fast Mobile IPv6.
Effect of Changes in Network Topology
The dynamic nature of the CAR discovery protocol we propose adapts
well to changes in the network topology. Since the PNC is maintained as
soft-state in the ARs, APs that are removed will timeout. ARs that no
longer overlap, will disassociate, and new APs will be discovered once a
MN handsover to it. The protocol design provides for a tradeoff between
the stability of the PNC and the degree of reconfigurability. Longer
lifetimes applied to AP discovery via RI messages provide a more stable
picture of the neighborhood in the face of few MNs. On the other hand,
lower lifetimes allow APs to be moved between ARs more frequently.
Providing the MN's Requirements to the CAR Discovery Solution
The MN may provide its current AR with a list of its requirements
for CAR selection in the form of a Profile sub-option included in any
RM message sent by the MN. The AR can then take advantage of the MN's
Trossen, et al. Expires 14 September 2003 [Page 50]
Internet Draft Dynamic CAR Discovery 14 March 2003
profile to better select a set of viable CARs, and possibly reduce the
amount of capability information required to send back to the MN.
Secure Capability Transfer
All protocol messages should be protected by IPSec or TLS to provide
authentication and ensure message integrity. The capability data may
also be encrypted and/or digitally signed to further ensure secure
transportation.
Verification of Router Authenticity
Verification of a neighboring AR's authenticity is approached in
two ways. First, the two ARs must establish a security association
via some means outside the scope of the CAR discovery protocol. This
security association should provide an explicit authorization to engage
in exchanging topological information.
Secondly, neighboring ARs are initially discovered through the
handover pattern of MNs. In order for two ARs to have discovered one
another, a MN must have moved between their respective APs. Moreover,
the AP identifiers provided by the MN are verified at both the new and
previous ARs in order to filter out faulty information provided by a
malicious MN.
However, in the case that an incorrect PNC entry is instantiated,
the result is simply a temporary allocation of memory in the AR. MN
handovers will not be affected since only ARs matching the reachability
information provided by the MN are selected as CARs.
Secure Inter-Operability with IETF Protocols
The CAR discovery protocol described in this document employs IPSec
and/or TLS for securing communication between all parties, between
two ARs and between an AR and a MN. The packet formats described
in Section 4 use ICMP and SCTP, although this is not a necessary
constraint. The protocol does not create any new threats to the use of
existing protocols.
Secure Expression of MN's Requirements to the CAR Discovery Solution
All protocol messages should be protected by IPSec or TLS to provide
authentication and ensure message integrity. The profile data may
also be encrypted and/or digitally signed to further ensure secure
transportation.
Trossen, et al. Expires 14 September 2003 [Page 51]
Internet Draft Dynamic CAR Discovery 14 March 2003
B. Optimization with Fast Mobile IPv6
In the presence of other mobility-enabling protocols, such as Fast
Mobile IPv6 [6], it is possible to optimize the message flow of the CAR
discovery protocol described by this document. In particular, the CLR
and CL messages could be overlaid onto the Proxy Router Solicitation and
Proxy Router Advertisement messages, respectively. This would require a
slight change to Fast MIPv6. The options and sub-options defined herein
could be reused to piggyback CARD information on Fast MIPv6 messaging.
Employing this type of optimization would eliminate one round-trip
between the MN and the AR near the time of handover. This is quite
desirable since link quality may fade significantly as a MN reaches
the edge of a given APs coverage area. Moreover, the MN would receive
the most current CAR list available since the transaction would occur
immediately before handover.
Author Addresses
Questions about this memo can be directed to the authors:
Dirk Trossen
Communications Systems Laboratory
Nokia Research Center
5 Bayside Road
Burlington, MA 01803
USA
+1 781 993 3605
+1 781 993 1907 (fax)
dirk.trossen@nokia.com
Govind Krishnamurthi
Communications Systems Laboratory
Nokia Research Center
5 Bayside Road
Burlington, MA 01803
USA
+1 781 993 3627
+1 781 993 1907 (fax)
govind.krishnamurthi@nokia.com
Hemant Chaskar
Communications Systems Laboratory
Nokia Research Center
5 Bayside Road
Burlington, MA 01803
Trossen, et al. Expires 14 September 2003 [Page 52]
Internet Draft Dynamic CAR Discovery 14 March 2003
USA
+1 781 993 3785
+1 781 993 1907 (fax)
hemant.chaskar@nokia.com
Robert C. Chalmers
Department of Computer Science
University of California, Santa Barbara
Santa Barbara, CA 93106
USA
+1 805 893 7520
+1 805 893 8553 (fax)
robertc@cs.ucsb.edu
Eunsoo Shim
NEC Labs America
4 Independence Way
Princeton, NJ, 08540 USA
eunsoo@nec-lab.com
Trossen, et al. Expires 14 September 2003 [Page 53]