Seamoby Working Group Dirk Trossen
INTERNET DRAFT Govind Krishnamurthi
25 October 2002 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-00.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 25 April 2003 [Page i]
Internet Draft Dynamic CAR Discovery 25 October 2002
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 25 April 2003 [Page ii]
Internet Draft Dynamic CAR Discovery 25 October 2002
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 . . . . . . . . . . . . . 3
3.3. Exchanging Capabilities . . . . . . . . . . . . . . . . . 5
3.4. Collecting Reachability Information . . . . . . . . . . . 6
3.5. TAR Selection . . . . . . . . . . . . . . . . . . . . . . 7
3.6. Security Assumptions . . . . . . . . . . . . . . . . . . 7
4. Protocol Messages 8
4.1. Router Identity Message . . . . . . . . . . . . . . . . . 8
4.2. Reachability Message . . . . . . . . . . . . . . . . . . 10
4.3. Reachability Acknowledgement Message . . . . . . . . . . 11
4.4. Candidate List Request Message . . . . . . . . . . . . . 13
4.5. Candidate List Message . . . . . . . . . . . . . . . . . 14
4.6. Geographical Neighbor Exchange Message . . . . . . . . . 16
4.7. Message Options . . . . . . . . . . . . . . . . . . . . . 18
4.7.1. Lifetime Option . . . . . . . . . . . . . . . . . 19
4.7.2. IP Option . . . . . . . . . . . . . . . . . . . . 20
4.7.3. Privacy Option . . . . . . . . . . . . . . . . . 20
4.7.4. Profile Option . . . . . . . . . . . . . . . . . 22
4.7.5. Capabilities Option . . . . . . . . . . . . . . . 23
4.7.6. Link-Layer Option . . . . . . . . . . . . . . . . 25
5. Protocol Requirements 26
5.1. Requirements for Mobile Nodes . . . . . . . . . . . . . . 26
5.2. Requirements for Access Routers . . . . . . . . . . . . . 27
6. Mobile Node Operation 27
6.1. Movement Detection . . . . . . . . . . . . . . . . . . . 27
6.2. Selecting a Source Address . . . . . . . . . . . . . . . 28
6.3. Sending Router Identity Messages . . . . . . . . . . . . 28
6.4. Tracking AP Beacons . . . . . . . . . . . . . . . . . . . 29
6.5. Sending Reachability Messages . . . . . . . . . . . . . . 29
6.6. Receiving Reachability Acknowledgement Messages . . . . . 30
6.7. Sending Candidate List Request Messages . . . . . . . . . 31
6.8. Receiving Candidate List Messages . . . . . . . . . . . . 32
Trossen, et al. Expires 25 April 2003 [Page iii]
Internet Draft Dynamic CAR Discovery 25 October 2002
7. Access Router Operation 33
7.1. Receiving Router Identity Messages . . . . . . . . . . . 33
7.2. Receiving Reachability Messages . . . . . . . . . . . . . 34
7.3. Sending Reachability Acknowledgement Messages . . . . . . 35
7.4. Receiving Candidate List Request Messages . . . . . . . . 36
7.5. Sending Candidate List Messages . . . . . . . . . . . . . 37
7.6. Sending Geographical Neighbor Exchange Messages . . . . . 38
7.7. Receiving Geographical Neighbor Exchange Messages . . . . 39
8. Protocol Constants 40
9. IANA Considerations 40
10. Security Considerations 40
11. Intellectual Property Rights Notice 41
Acknowledgements 41
References 41
A. Conformance to Requirements 43
B. Optimization with Fast Mobile IPv6 47
Author Addresses 47
Trossen, et al. Expires 25 April 2003 [Page iv]
Internet Draft Dynamic CAR Discovery 25 October 2002
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 candidate
access-router discovery protocol. 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 handsover 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. After handover, a MN listens for new beacons and forwards
this reachability information to the current AR. Using the previously
Trossen, et al. Expires 25 April 2003 [Page 1]
Internet Draft Dynamic CAR Discovery 25 October 2002
collected 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 25 April 2003 [Page 2]
Internet Draft Dynamic CAR Discovery 25 October 2002
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 view
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 List
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 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.
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
Trossen, et al. Expires 25 April 2003 [Page 3]
Internet Draft Dynamic CAR Discovery 25 October 2002
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 [10], 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 | <
| | ------- | AP1 | --- | Router | ------ >
+-+ +-------+ | (PAR) | <
| +----------+
| IP
V Network
$ +----------+
+-+ +-------+ | New | <
| | ------- | AP2 | --- | 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. This
requires that a MN receive beacons from new APs while still connected to
its current AR/AP.
Following a handover, a MN informs its new access router (NAR),
as seen in Figure 1, about its previous point of attachment. In
particular, the MN sends to NAR a Router Identity (RI) message (see
Section 4.1) containing the IP address of the previous access router
Trossen, et al. Expires 25 April 2003 [Page 4]
Internet Draft Dynamic CAR Discovery 25 October 2002
(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,AP1,AP2).
With this information, NAR can create two entries in its Physical
Neighbor List (PNL): 1) an entry for AP2 as a locally attached
access point, and 2) an entry for PAR as a physical neighbor with
the associated access point AP1. Prior to trusting the MN's report,
however, NAR performs a number of checks to ensure the validity of the
received information.
First, AP2 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 manager. A larger set of authorized APs
provides a higher level of reconfigurability, but also increases the
possibility of malicious MNs polluting the AR's PNL.
To further verify the contents of the RI message, the AR sends a
Geographical Neighbor Exchange (GNE) message (see Section 4.6) to the
PAR. The GNE includes both the new and the previous AP identifiers, AP1
and AP2. PAR verifies that AP1 is indeed currently attached via its own
local PNL 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 PNL with an entry for NAR and AP2.
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 PNL entries. If handovers cease between two
particular access routers, the associated references will eventually
timeout and be removed from each AR's PNL.
The dynamic nature of the CAR discovery protocol we propose adapts
well to changes in the network topology. Since the PNL 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 PNL 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.
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
Trossen, et al. Expires 25 April 2003 [Page 5]
Internet Draft Dynamic CAR Discovery 25 October 2002
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 GNE message.
Capabilities have lifetimes that are independent of, although bounded
by, the PNL entries of their associated ARs. They may be refreshed
during normal validation exchanges, or via explicit GNE messages. To
request current capabilities, an AR simply sets the C-bit in the GNE
message. The receiving AR may then return its capability set as a
option in a GNE reply (see Section 4.7.5).
The exact semantics of how to adequately describe capabilities are
beyond the scope of this document. Actually, the CAR discovery protocol
described herein can work with literally any capability representation
required. The Capabilities 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. Collecting 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 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.4), or 2) statefully via Reachability (RM) message (see
Section 4.2). Using the CLR message with a list of APs, the MN can
request CAR selection limited by the explicit list provided.
When the RM message is used, 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
Trossen, et al. Expires 25 April 2003 [Page 6]
Internet Draft Dynamic CAR Discovery 25 October 2002
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
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 options, such as the MN's home address
or current profile. Since RM messages can be acknowledged, the MN can
ensure safe reception, or subsequently retransmit on failure.
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 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.5) 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. 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 MN
Trossen, et al. Expires 25 April 2003 [Page 7]
Internet Draft Dynamic CAR Discovery 25 October 2002
and the AR have formed an appropriate security relationship. 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 to provide authentication and ensure message integrity.
4. Protocol Messages
The CAR discovery protocol described in this document defines the
following six messages and six options. Each message is in the form
of an ICMP packet [9, 2], although other transport protocols could be
used. All messages share a single ICMP type (TBA) with distinct ICMP
code values. Likewise, all options share one ICMP option type (TBA)
with distinct sub-types.
4.1. 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 has been performed and a new CoA has been configured,
if necessary. If a MN is attaching to a new AR, but not handing-over
directly from a previous router, then both the Previous CoA and Previous
AR MUST be set to zero.
This message SHOULD contain Link-Layer options with the previous
and new AP identifiers, if available. 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 | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Previous CoA |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Previous AR |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Router Identity Message Format for IPv4.
Trossen, et al. Expires 25 April 2003 [Page 8]
Internet Draft Dynamic CAR Discovery 25 October 2002
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Previous CoA +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Previous AR +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Router Identity Message Format for IPv6.
IP Fields:
Source Address The current CoA of the MN (see Section 6.2).
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
Trossen, et al. Expires 25 April 2003 [Page 9]
Internet Draft Dynamic CAR Discovery 25 October 2002
Code 0 or 1. For an RI with IPv4 addresses, the code
is 0; the code is 1 for RI messages containing
IPv6 addresses.
Checksum The ICMP checksum.
RI Fields:
Previous CoA The CoA used by the MN at the previous AR.
Previous AR The global IP address of the previous AR.
4.2. Reachability Message
The Reachability (RM) message is sent by the MN 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.
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |A|S|R| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Reachability Message Format.
IP Fields:
Source Address The current CoA of the MN (see Section 6.2).
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
Trossen, et al. Expires 25 April 2003 [Page 10]
Internet Draft Dynamic CAR Discovery 25 October 2002
and the AR, then the sender SHOULD include this
header.
ICMP Fields:
Type TBA
Code 2
Checksum The ICMP checksum.
RM Fields:
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**16).
Acknowledge (A) The Acknowledge bit is set by the sending node
to request an explicit acknowledgement in
response to this message.
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.
4.3. Reachability Acknowledgement Message
The Reachability Acknowledgement (RMA) message is sent from the
current AR to the MN upon reception of a RM message.
IP Fields:
Trossen, et al. Expires 25 April 2003 [Page 11]
Internet Draft Dynamic CAR Discovery 25 October 2002
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number | Reserved | Status |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: Reachability Acknowledgement Message Format.
Source Address The address of the access router. This SHOULD
be the Destination Address from the original RM
message that this RMA is acknowledging.
Destination Address
The current CoA of the MN. This SHOULD be the
Source Address from the original RM message that
this RMA is acknowledging.
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 3
Checksum The ICMP checksum.
RMA Fields:
Sequence Number The Sequence Number in the RMA message is copied
from the Sequence Number field in the RM message
being acknowledged.
Reserved This field is reserved for future use. It MUST
be initialized to zero by the sender and MUST be
ignored by the receiver.
Trossen, et al. Expires 25 April 2003 [Page 12]
Internet Draft Dynamic CAR Discovery 25 October 2002
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
193 Insufficient resources
194 Administratively prohibited
4.4. 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.
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |T|C| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: Candidate List Request Message Format.
IP Fields:
Source Address The current CoA of the MN (see Section 6.2).
Destination Address
The address of the access router as determined
from the last router advertisement of said AR.
Hop Limit/TTL 1
Trossen, et al. Expires 25 April 2003 [Page 13]
Internet Draft Dynamic CAR Discovery 25 October 2002
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 4
Checksum The ICMP checksum.
CLR Fields:
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**16).
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.
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.
4.5. 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.7).
IP Fields:
Trossen, et al. Expires 25 April 2003 [Page 14]
Internet Draft Dynamic CAR Discovery 25 October 2002
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |T| Reserved | Status |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: Candidate List Message Format.
Source Address The address of the access router. This SHOULD
be the Destination Address from the original CLR
message.
Destination Address
The current CoA of the MN. This SHOULD be the
Source Address from the original CLR message.
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 5
Checksum The ICMP checksum.
CL Fields:
Sequence Number The Sequence Number in the CL message is copied
from the Sequence Number field in the associated
Candidate List Request message.
TAR Selection (T) The TAR Selection bit is set by the sending node
to indicate that the sending AR performed TAR
selection on behalf of the MN.
Trossen, et al. Expires 25 April 2003 [Page 15]
Internet Draft Dynamic CAR Discovery 25 October 2002
Reserved This field is reserved for future use. It MUST
be initialized to zero by the sender and MUST be
ignored by the receiver.
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
4.6. Geographical Neighbor Exchange Message
The Geographical Neighbor Exchange (GNE) message is sent from one AR
to another in order to propagate topology information generated by RI
messages. GNE 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.
IP Fields:
Source Address The global IP address of the access router.
This SHOULD be a single, global IP address that
can be used by neighboring ARs to identify this
router (see Section 7.6).
Destination Address
The global IP address of the neighboring access
router. This may not be a unique address if
Trossen, et al. Expires 25 April 2003 [Page 16]
Internet Draft Dynamic CAR Discovery 25 October 2002
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifier |S|T|V|C| Resvd | Status |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: Geographical Neighbor Exchange Message Format.
received from the Previous AR field of a RI
message.
Hop Limit/TTL 255
Authentication Header
If a security association exists between the two
ARs, then the sender SHOULD include this header.
ICMP Fields:
Type TBA
Code 6
Checksum The ICMP checksum.
GNE Fields:
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
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
Trossen, et al. Expires 25 April 2003 [Page 17]
Internet Draft Dynamic CAR Discovery 25 October 2002
process. This bit MUST NOT be set if the S-bit
is unset; i.e., the T-bit can only be set on
initial messages.
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.
Status An 8-bit unsigned integer indicating the status
of handling the originating GNE 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
4.7. Message Options
The CAR discovery protocol described in this document defines six
new ICMP options used in conjunction with the messages defined in the
previous subsections. All options share one ICMP option type (TBA) with
distinct sub-types.
Each option 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
Trossen, et al. Expires 25 April 2003 [Page 18]
Internet Draft Dynamic CAR Discovery 25 October 2002
1 Source - the source of the message
2 Destination - the destination of the message
3 HoA - the home address of the MN
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 Link-Layer - an entity identified by its link-layer address
Moreover, the order of options in the message are important. All
options not associated with a Link-Layer entity MUST be placed in the
message prior to the start of any Link-Layer options. Any option
following a Link-Layer option is automatically associated with the
immediately preceding Link-Layer option; the Entity MUST be set to 8,
Link-Layer.
New options may be added to the protocol in the future. If a
receiving node does not recognize an option, it SHOULD silently ignore
the option and continue processing the message.
4.7.1. Lifetime Option
The Lifetime option is added to RM, RMA and GNE messages in order to
request or grant a lifetime on the state maintained with regard to the
message's peer.
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 | Entity |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9: Lifetime Option Format
Type TBA
Trossen, et al. Expires 25 April 2003 [Page 19]
Internet Draft Dynamic CAR Discovery 25 October 2002
Length 1
Sub-Type 0
Entity An Entity value defined in Section 4.7
indicating to which entity this option applies.
Lifetime The lifetime in seconds associated with Entity.
4.7.2. IP Option
The IP option is added to a message to indicate the global IP address
of a given Entity. For example, an AR with a site-local or private IP
address could provide the global address of a Border Router, along with
a Privacy option, to be used by the MN in its RI message to the next AR.
An AR may also add an IP option to a GNE exchange to provide a single,
global address to be used by a peer (see Section 7.6).
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 | Entity |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10: IPv4 Option Format
Type TBA
Length The size of this option in units of 8 octets.
Sub-Type 1 or 2. For an IPv4 option the code is 1. The
code is 2 for an IPv6 option.
Entity An Entity value defined in Section 4.7
indicating to which entity this option applies.
IP Address The IP address of the target Entity.
4.7.3. Privacy Option
The Privacy option is added to a message in order to associate a
locally unique identifier with an Entity when the global IP address
Trossen, et al. Expires 25 April 2003 [Page 20]
Internet Draft Dynamic CAR Discovery 25 October 2002
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 | Entity |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ IP Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 11: IPv6 Option Format
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.
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 | Entity |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 12: Privacy Option Format
Type TBA
Length 1
Sub-Type 3
Entity An Entity value defined in Section 4.7
indicating to which entity this option applies.
Id A 32-bit unsigned identifier used to identify
the target Entity when multiple nodes may share
a single global IP address.
Trossen, et al. Expires 25 April 2003 [Page 21]
Internet Draft Dynamic CAR Discovery 25 October 2002
4.7.4. Profile Option
A Profile 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 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.
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 | Entity |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|A|R| Reserved | Data Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Profile Data...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 13: Profile Option Format
Type TBA
Length The size of this option in units of 8 octets.
Sub-Type 4
Entity An Entity value defined in Section 4.7
indicating to which entity this option applies.
Absolute (A) The Absolute bit is set by the sending node
to indicate that the profile data included in
the 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
option MUST be removed from the receiving node's
cache for the sending AR.
Trossen, et al. Expires 25 April 2003 [Page 22]
Internet Draft Dynamic CAR Discovery 25 October 2002
Reserved This field is reserved for future use. It MUST
be initialized to zero by the sender and MUST be
ignored by the receiver.
Data Length The actual length in bytes of the Profile Data
contained within the option. This field may
be set to zero if no data is present, e.g., to
revoke the complete profile.
Sequence Number The Sequence Number is assigned by the sender
and used by the receiving node to sequence
profile updates. Each Profile option sent by
a MN MUST use a sequence number greater than
the Sequence Number value sent in any previous
Profile option, if any, to the same receiving
node (modulo 2**32).
Lifetime The lifetime in seconds for the profile included
in the option.
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.
4.7.5. Capabilities Option
A Profile option is added to CL and GNE 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 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.
Type TBA
Length The size of this option in units of 8 octets.
Sub-Type 5
Entity An Entity value defined in Section 4.7
indicating to which entity this option applies.
Absolute (A) The Absolute bit is set by the sending node to
indicate that the capabilities included in the
option MUST override any existing capabilities
Trossen, et al. Expires 25 April 2003 [Page 23]
Internet Draft Dynamic CAR Discovery 25 October 2002
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 | Entity |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|A|R| Reserved | Data Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Capabilities Data...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 14: Capabilities Option Format
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
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.
Data Length The actual length in bytes of the Capabilities
Data contained within the option. This field
may be set to zero if no data is present, i.e.,
to revoke the complete capabilities set.
Sequence Number The Sequence Number is assigned by the sender
and used by the receiving node to sequence
capability updates. Each Capabilities option
sent by an AR MUST use a sequence number greater
than the Sequence Number value sent in any
previous Capabilities option, if any, to the
same receiving node (modulo 2**32).
Lifetime The lifetime in seconds for the capabilities
included in the option.
Capabilities Data The Capabilities Data associated with this
entity. The field MUST be zero-padded to an
Trossen, et al. Expires 25 April 2003 [Page 24]
Internet Draft Dynamic CAR Discovery 25 October 2002
integral number of 8-octet units. The actual
length of the data should be placed in the Data
Length field.
4.7.6. Link-Layer Option
The Link-Layer option is added to messages to describe particular
Entities identified by their link-layer address, namely APs. Each
Link-Layer 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.
Other options may be associated with a Link-Layer option to further
describe properties of the Entity. Any options following a Link-Layer
option, not including another Link-Layer option, are automatically
associated with that Link-Layer option.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Sub-Type | Entity |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Id | Data Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link-Layer Address...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 15: Link-Layer Option Format
Type TBA
Length The size of this option in units of 8 octets.
Sub-Type 6
Entity An Entity value defined in Section 4.7
indicating to which entity this option applies.
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 option. This field
Trossen, et al. Expires 25 April 2003 [Page 25]
Internet Draft Dynamic CAR Discovery 25 October 2002
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.
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 MUST support sending Reachability messages
as described in Section 6.5.
- Every participating MN MUST support receiving Reachability
Acknowledgement messages as described in Section 6.6.
- Every participating MN MUST support sending Candidate List
Request messages as described in Section 6.7.
- Every participating MN MUST 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.
Trossen, et al. Expires 25 April 2003 [Page 26]
Internet Draft Dynamic CAR Discovery 25 October 2002
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.1.
- Every participating AR MUST support receiving Reachability
messages as described in Section 7.2.
- Every participating AR MUST support sending Reachability
Acknowledgement messages as described in Section 7.3.
- Every participating AR MUST support receiving Candidate List
Request messages as described in Section 7.4.
- Every participating AR MUST support sending Candidate List
messages as described in Section 7.5.
- Every participating AR MUST support sending and receiving
Geographical Neighbor Exchange messages as described in
Sections 7.6 and 7.7, respectively.
- Every participating AR SHOULD have a single, global IP address
used to identify itself with neighboring ARs, as described in
Section refsec:op-ar-gne-snd.
- Every participating AR SHOULD support a CAR resolution 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
Trossen, et al. Expires 25 April 2003 [Page 27]
Internet Draft Dynamic CAR Discovery 25 October 2002
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:
- 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 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 following rules:
* The Previous CoA field MUST be assigned the same CoA used by
the MN to send RM messages to the previous AR.
* The Previous AR field MUST be set to 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 option. If a global IP address is not available,
then the handover should be treated as disjoint.
* If the previous AR provided the MN with a Privacy option, a
new Privacy option MUST be added to the RI with the Id field
copied from the original option sent by the AR.
Trossen, et al. Expires 25 April 2003 [Page 28]
Internet Draft Dynamic CAR Discovery 25 October 2002
* If the MN can identify its previous AP, a Link-Layer option
SHOULD be added to the RI with the Entity field set to
Previous AR. 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.
- If the handover was disjoint then the Previous CoA and Previous
AR fields MUST be set to zero.
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
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.
6.5. Sending Reachability Messages
Reachability messages SHOULD be sent to the MN's current AR 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
option. The locally-unique Id assigned to this beacon by the MN
SHOULD be assigned to the Id field of the 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 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 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,
Trossen, et al. Expires 25 April 2003 [Page 29]
Internet Draft Dynamic CAR Discovery 25 October 2002
the S-bit of the RM message MUST be set, and a set of Link-Layer
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 mark 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:
- 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.
- The A-bit SHOULD be set for all RM messages sent.
- 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 th elist, 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 options such as the Profile 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.
If expecting an acknowledgement, 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 protocol
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.
Trossen, et al. Expires 25 April 2003 [Page 30]
Internet Draft Dynamic CAR Discovery 25 October 2002
- 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
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
MUST 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 protocol message 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 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, superceding any
current beacon state maintained by the AR on behalf of the MN.
Trossen, et al. Expires 25 April 2003 [Page 31]
Internet Draft Dynamic CAR Discovery 25 October 2002
The previously maintained Beacon List, if any, will not be
affected.
- The MN MAY include a Profile 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, superceding 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
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, the MN MAY continue with sending new RM messages when
appropriate. The AR MAY send new CLR messages in the future, but
SHOULD NOT retransmit the originating CLR.
Trossen, et al. Expires 25 April 2003 [Page 32]
Internet Draft Dynamic CAR Discovery 25 October 2002
- 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. 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 MN's previous CoA and the global
address of the previous router. If the Previous AR field of the RI
message is zero or set to an address local to the new AR (with the
addition of a possible privacy option), then the handover is considered
local to the AR.
The AR MUST validate the RI message according to the following rules:
- The message MUST contain either a new or previous AP address,
provided via Link-Layer 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 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 either the Previous AR or Previous CoA fields are non-zero,
both MUST be non-zero.
- If the handover is local to the AR, the AR MUST further validate
the message according to the following rules:
* For a non-zero Previous CoA, the AR MUST verify that the MN
was previously attached to the AR within a reasonable amount
of time. This can be accomplished by finding an existing
entry for a MN based on the Previous CoA in the AR's list
of currently supported MNs. State instantiated on the MN's
behalf for other protocols and services MAY also be used as a
source of verification as long as the state has a reasonable
lifetime associated with it.
* If a previous AP address is included, the AR MUST verify that
the link-layer address provided in the option represents a
viable local AP. This check could be made against an actual
Trossen, et al. Expires 25 April 2003 [Page 33]
Internet Draft Dynamic CAR Discovery 25 October 2002
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
Physical Neighbor List 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 also create PNL entries
for the neighboring AR and AP, if available. If the entries do not
already exist, they SHOULD be marked as pending with a small lifetime
(PENDING_LIFETIME). The AR SHOULD then send a GNE to the neighboring AR
according to the rules outlined in Section 7.6.
7.2. 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. The rest of
this subsection assumes that the AR has created the MN entry and will
support the MN for 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 handsover 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 SHOULD update the MN's state according
to the following rules:
- If the A-bit is set, the AR MUST return a RMA message with an
appropriate Status value.
- 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 options. A Beacon Entry MAY
be identified by either the Id field or the actual Link-Layer
Address if provided. If any Link-Layer 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.
Trossen, et al. Expires 25 April 2003 [Page 34]
Internet Draft Dynamic CAR Discovery 25 October 2002
- If the R-bit is unset, the AR SHOULD create or update a Beacon
Entry for each Link-Layer 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 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.
- If an IP option is included with the Entity field set to HoA,
the AR MAY save the MN's HoA as part of MN entry. Whether the
AR saves the HoA or not, it SHOULD set the H-bit in the RMA to
inhibit the MN from continuing to send the HoA in further RM
messages.
- If a Lifetime 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 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 option.
- If a Profile 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.3. Sending Reachability Acknowledgement Messages
The AR MUST send a Reachability Acknowledgment Message to a MN in
response to a RM message if the A-bit is set or in cases where the
AR cannot fulfill the requirements of processing the RM message (as
described in Section 7.2. 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. the RM message.
- If the originating RM message contained a Lifetime option, the AR
SHOULD include a Lifetime option with the granted lifetime for
the MN entry.
The AR MAY also include an IP 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.
Trossen, et al. Expires 25 April 2003 [Page 35]
Internet Draft Dynamic CAR Discovery 25 October 2002
Additionally, the AR MAY include a Privacy option with a 32-bit
identifier to be used by a neighboring AR in subsequent communications.
7.4. Receiving Candidate List Request Messages
If an AR receives a Candidate List Request message from a MN
for which it has no corresponding MN entry, 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 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. The
rest of this subsection assumes that the AR has an associated MN entry
and will support the MN for CAR discovery.
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 handsover 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 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 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 PNL which match the list of reachable AP
reported by the MN.
* Pending entries, those not yet validated via a GNE exchange,
SHOULD NOT be considered.
Trossen, et al. Expires 25 April 2003 [Page 36]
Internet Draft Dynamic CAR Discovery 25 October 2002
* 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. The capabilities sent MAY be a subset of the complete
AR capabilities, dependent upon the MN's profile. 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.5. Sending Candidate List Messages
An AR MUST send a Candidate List message in response to a CLR message
from a supported MN. A MN is considered supported if the AR maintains
state on behalf of the MN as a result of previous RM messages. If the
MN is unsupported and the CLR message does not contain an explicit list
of reachable APs, 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 T-bit MUST be set if a single TAR was selected. This differs
from the case where only one CAR was available, but was not
necessarily selected as a TAR.
- 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
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
option as separate options prior to the next Link-Layer option in
the message.
Trossen, et al. Expires 25 April 2003 [Page 37]
Internet Draft Dynamic CAR Discovery 25 October 2002
7.6. Sending Geographical 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 PNL entries for a neighboring AR. All
Geographical Neighbor Exchange messages sent to a neighboring AR SHOULD
use this identifying address as the Source Address. One exception is
noted below.
An AR MAY send a GNE message to a neighboring router in any of the
following situations:
- The AR receives a valid RI message with a previous AP address
specified as a Link-Layer option with the Entity field set to
Previous AR. In this case, 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 options included in the RI
SHOULD be copied to the GNE.
- The AR attempts to verify the previous AP address of a GNE sent
by a neighboring router, and the V-bit is set in the originating
GNE. The Status field MUST be set to Verified if verification
succeeds, or an appropriate error value otherwise. If the
Destination Address of the originating GNE is not the identifying
address of the AR, the Source Address of the reply GNE MUST be
set to the Destination Address of the initial GNE; an IP 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 GNE from a neighboring router with the
C-bit set. The AR MUST verify that the sending AR is a valid
neighboring AR by checking for a non-pending entry in the PNL.
The return GNE SHOULD contain a Capabilities 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 GNE.
For initial packets of a message stream, those with the S-bit set,
the AR MUST select an Identifier with a good 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
Trossen, et al. Expires 25 April 2003 [Page 38]
Internet Draft Dynamic CAR Discovery 25 October 2002
the originating GNE message. The S, T and V-bits MUST NOT be set in
non-initial packets.
7.7. Receiving Geographical Neighbor Exchange Messages
Upon receiving a Geographical Neighbor Exchange message, the AR MUST
validate the message according to the following rules:
- If the S-bit is not set, the T and V-bits MUST NOT be set.
- If the T-bit is set, the previous AP address MUST be included as
a Link-Layer option with the Entity field set to Previous AR.
- If the T-bit is set, the AR MUST verify that the previous AP's
link-layer address provided in the 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.
The AR MUST silently discard invalid GNE messages. For valid GNE
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
GNE:
- If the T-bit is set, the AR SHOULD create a PNL 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 PNL entry for the
neighboring AR in its PNL, if not already. The AR SHOULD mark
this entry as non-pending. If the new AP is included in the GNE
message, the AR SHOULD create an associated AP entry related to
the neighboring AR in the PNL, if not already. The AR SHOULD
update the lifetime of the new AP entry to AP_LIFETIME.
- If a Lifetime option is included in the GNE, the AR SHOULD update
the lifetime of the corresponding neighbor entry in the PNL, if
it exists, with a value no greater than that specified in the
option. The granted lifetime SHOULD be returned in a GNE reply
message.
If the S-bit is not set, the following rules MUST be followed in
processing the GNE:
- If an IP option is included with the Entity field set to Source,
the address indicated by the option SHOULD be used by the
AR as the identifying address of the neighboring router. An
existing PNL entry for the Source Address of the message SHOULD
Trossen, et al. Expires 25 April 2003 [Page 39]
Internet Draft Dynamic CAR Discovery 25 October 2002
be converted to or merged with a PNL entry for the identifying
address.
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.
MAX_CLR_RETRY 3
AP_LIFETIME 180 sec
AR_LIFETIME 600 sec.
PENDING_LIFETIME 30 sec.
9. IANA Considerations
The messages described herein require a single ICMP type to be
assigned from the available type space. Message code values should be
standardized, but do not require assignment from an existing, restricted
numbering space. Likewise, the options described in this document
require the assignment of a single ICMP option type, and sub-types
should be standardized. If some options could be reused in other
protocols, it may be useful to define unique types for those options.
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 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
Trossen, et al. Expires 25 April 2003 [Page 40]
Internet Draft Dynamic CAR Discovery 25 October 2002
report their handovers. Although a number of verification steps,
outlined in Sections 7.1 and 7.7, provide strong evidence that a given
RI message is valid, it is possible for a malicious MN to pollute
the PNL of ARs. However, since all PNL entries are maintained as
soft-state, the MN or a 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 PNL to eliminate this possibility.
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
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. Request for Comments (Best Current Practice) 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. Request for Comments (Draft Standard) 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), June 2002.
Trossen, et al. Expires 25 April 2003 [Page 41]
Internet Draft Dynamic CAR Discovery 25 October 2002
[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), July 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. IP Mobility Support. Request for Comments
(Proposed Standard) 2002, Internet Engineering Task Force,
October 1996.
[9] J. Postel. Internet Control Message Protocol. Request for
Comments (Standard) 792, Internet Engineering Task Force,
September 1981.
[10] 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 25 April 2003 [Page 42]
Internet Draft Dynamic CAR Discovery 25 October 2002
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 option associated with each Link-Layer
option in a CL message returned to the MN.
Support for Inter-Technology Handoffs
Since the Link-Layer 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 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 GNE message can be used to
request new capabilities. The actual capabilities are carried in the
Capabilities option. Capabilities can also be forwarded to the MN
through the same option, as part of the CL message.
Trossen, et al. Expires 25 April 2003 [Page 43]
Internet Draft Dynamic CAR Discovery 25 October 2002
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 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 25 April 2003 [Page 44]
Internet Draft Dynamic CAR Discovery 25 October 2002
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 PNL 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 PNL 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 option included in any RM message
sent by the MN. The AR can then take advantage of the MN's profile to
Trossen, et al. Expires 25 April 2003 [Page 45]
Internet Draft Dynamic CAR Discovery 25 October 2002
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 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 PNL 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
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, 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 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 25 April 2003 [Page 46]
Internet Draft Dynamic CAR Discovery 25 October 2002
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 in order to allow advertisements from
multiple ARs in the Proxy Router Advertisement. New options would also
be required to carry the AR capabilities and AP identifiers.
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
Trossen, et al. Expires 25 April 2003 [Page 47]
Internet Draft Dynamic CAR Discovery 25 October 2002
Burlington, MA 01803
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 25 April 2003 [Page 48]