One document matched: draft-ietf-seamoby-card-protocol-01.txt
Differences from draft-ietf-seamoby-card-protocol-00.txt
IETF Seamoby Working Group CARD Design Team
Internet Draft Marco Liebsch
Ajoy Singh
(Editors)
Hemant Chaskar
Daichi Funato
draft-ietf-seamoby-card-protocol-01.txt
Expires: September 2003 March 2003
Candidate Access Router Discovery
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC 2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet
Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
To view the list of Internet-Draft Shadow Directories, see
http://www.ietf.org/shadow.html.
Abstract
To enable seamless IP-layer handover of a mobile node (MN) from one
access router (AR) to another, the MN is required to discover the
identities of candidate ARs (CARs) for handover, along with their
capabilities, prior to the initiation of the IP-layer handover.
Depending upon the mode of operation, the current AR may or may not
be involved in the CAR discovery process. The act of discovery of
CARs has two aspects to it: Identifying the IP addresses of the CARs
and finding the capabilities of those CARs. This process is called
"candidate access router discovery" (CARD). At the time of IP-layer
handover, that CAR, whose capabilities are a good match to the
preferences of the MN, may be chosen as the target AR (TAR) for
handover. This draft describes a solution to perform CARD.
CARD Design Team Expires û September 2003 [Page 1]
Internet-Draft Candidate Access Router Discovery March 2003
TABLE OF CONTENTS
1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. CARD Protocol Functions . . . . . . . . . . . . . . . . . . . . 4
3.1 Reverse Address Translation . . . . . . . . . . . . . . . . 4
3.2 Discovery of CAR Capabilities . . . . . . . . . . . . . . . 5
4. CARD Protocol Operation . . . . . . . . . . . . . . . . . . . . 6
4.1 MN-Orchestrated CARD. . . . . . . . . . . . . . . . . . . . 6
4.2 Network-Assisted CARD . . . . . . . . . . . . . . . . . . . 7
5. Protocol Messages . . . . . . . . . . . . . . . . . . . . . . .12
5.1 CARD Messages for the interface MN - AR . . . . . . . . . .12
5.1.1 CARD Main Header Format. . . . . . . . . . . . . . . .12
5.1.2 CARD Options Format . . . . . . . . . . . . . . . . . .14
5.1.2.1 CARD Request Option .. . . . . . . . . . . . . . .15
5.1.2.2 CARD Reply Option .. . . . . . . . . . . . . . . .15
5.1.3 Sub-Options Format .. . . . . . . . . . . . . . . . . .16
5.1.3.1 L2-ID Sub-Option . . . . . . . . . . . . . . . . .17
5.1.3.2 Preferences Sub-Option . . . . . . . . . . . . . .17
5.1.3.3 Requirements Sub-Option .. . . . . . . . . . . . .18
5.1.3.4 Capability Container Sub-Option. . . . . . . . . .18
5.1.3.5 Address Sub-Option . . . . . . . . . . . . . . . .19
5.1.4 CARD AVP encoding . . . . . . . . . . . . . . . . . . .20
5.2 CARD Messages for the interface between ARs (AR - AR) . . .21
5.2.1 Protocol transport (AR-AR). . . . . . . . . . . . . . .21
5.2.2 Protocol main header. . . . . . . . . . . . . . . . . .21
5.2.3 Protocol payload types. . . . . . . . . . . . . . . . .22
5.3 CARD Messages for the interface between an
AR and the CARD server . . . . . . . . . . . . . . . . . . .22
5.3.1 Protocol transport (AR-Server function) . . . . . . . .22
5.3.2 Protocol main header. . . . . . . . . . . . . . . . . .22
5.3.3 Protocol payload types. . . . . . . . . . . . . . . . .23
5.4 Overview on sub-options'/payload types' usage . . . . . . .24
6. Security Considerations . . . . . . . . . . . . . . . . . . . .24
6.1 Security Associations . . . . . . . . . . . . . . . . . . .24
6.2 DoS Attack . . . . . . . . . . . . . . . . . . . . . . . .24
6.3 CAR Cache Contamination . . . . . . . . . . . . . . . . . .25
7. IANA considerations . . . . . . . . . . . . . . . . . . . . . .26
8. References . . . . . . . . . . . . . . . . . . . . . . . . . .26
9. Authors' addresses . . . . . . . . . . . . . . . . . . . . . .27
10. IPR Statements. . . . . . . . . . . . . . . . . . . . . . . . .27
11. Copyright Notice . . . . . . . . . . . . . . . . . . . . . . .28
12. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . .28
CARD Design Team Expires û September 2003 [Page 2]
Internet-Draft Candidate Access Router Discovery March 2003
Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
this document are to be interpreted as described in RFC-2119 [1].
1. Introduction
IP mobility protocols enable mobile nodes (MNs) to execute IP-level
handover between access routers (ARs). CAR discovery (CARD) enables
acquiring information about the ARs that are candidates (CARs) for
the MN's handover.
In future wireless networks, there will be cases when a MN has a
choice of performing IP-level handover to different CARs. The MN
would then choose one of them as a target access router (TAR) for
handover, based on a match between a MN's requirements and CARs'
capabilities. The MN requires some means of obtaining information
about the CARs so that the best decision about the TAR can be made.
The CARD protocol enables this.
The problem statement and requirements for CARD are discussed in [2]
and [3] respectively. In this draft, we describe a solution to
perform CARD. We begin by describing two main functions of the CARD
protocol. Then, we describe two modes of protocol operation that we
think cover most of the important handover scenarios. Finally, we
describe the messages and protocol operation of MN-AR, AR-AR and AR-
server interfaces of the CARD protocol.
2. Terminology
Mobile Node (MN)
A Mobile Node is an IP host capable of moving its point of
attachment to the Internet.
Access Point (AP)
A radio transceiver by which a MN obtains Layer 2 connectivity with
the wired network.
Access Router (AR)
An IP router residing in an access network and connected to one or
more APs. An AR offers IP connectivity to MNs.
CARD Design Team Expires û September 2003 [Page 3]
Internet-Draft Candidate Access Router Discovery March 2003
Candidate AR (CAR)
An AR to which a MN has a choice of performing IP-level handover.
This implies that the MN has the right radio interface to connect to
an AP that is served by this AR, as well as the coverage of this AR
overlaps with that of the AR to which the MN is currently attached
to.
Capability of AR
A characteristic of the service offered by an AR that may be of
interest to a MN when the AR is being considered as a handover
candidate.
L2 ID
Identifier of an AP, that uniquely identifies that AP. For example,
in 802.11 PCF, this could be a MAC address of an AP.
Target AR (TAR)
An AR with which the procedures for the MN's IP-level handover are
initiated. The TAR is selected after running a TAR Selection
algorithm that takes into account the capabilities of CARs,
preferences of the MN and any other local policies.
3. CARD Protocol Functions
A CARD protocol accomplishes the following functions.
3.1 Reverse Address Translation
This functionality refers to mapping the L2 ID of a new AP that the
MN can hear, to the IP address of the CAR that connects to the new
AP. In cases where the MN can acquire IP connectivity with CARs
prior to making handover decisions, this functionality is trivially
realized.
However, if a MN can only listen to L2 IDs of new APs prior to
making decision about IP-level handover to CARs, a special mechanism
is needed for reverse address translation. This could be realized
via cached information in the MN. Alternatively, the MN may seek the
help of the current AR, wherein the MN sends L2 IDs of new APs to
the current AR and expects it to resolve the L2 IDs to the IP
address of CARs.
CARD Design Team Expires û September 2003 [Page 4]
Internet-Draft Candidate Access Router Discovery March 2003
Note: In some networks, such as cellular networks, link-layer
technology may be capable of delivering the L2 ID of the new AP to
the current AR. In this case the current AR can send CAR address
information to a MN without receiving an explicit request for
reverse address translation before.
Finally, few comments are in order. First, note that the new AR can
be in a different subnet than that of the current AR (even far away
from the current AR in terms of IP hops). Second, when the MN
delivers L2 IDs of APs to the reverse address translation module,
implicit is the assumption that MN is satisfied with the signal
strength of the new APs. Lower level criteria such as signal
strength are out of scope of capabilities that we refer to in the
CARD protocol. Finally, establishment of a L2 security association
between a MN and individual AP(s) is assumed to be performed in
accordance with the relevant L2 mechanism, and is outside the scope
of the CARD protocol.
3.2 Discovery of CAR Capabilities
Information about capabilities of CARs can assist the MN in making
optimized handover decisions. This capability information serves as
input to the TAR selection algorithm. Some of the capability
parameters of CARs can be static, some others can change only on a
long time scale, while the rest can be highly dynamic. Definition of
capabilities is out of scope of the CARD protocol design. Encoding
rules for capabilities and the format of a capability container for
capability transport are specified in section 5.
If the MN can establish robust IP connectivity with CARs before
making handover decisions, the MN can directly ask for capability
information from the CARs. Alternatively, certain capabilities may
be periodically transmitted over downlink channels.
On the other hand, if the MN cannot establish IP connectivity with
CARs before making handover decisions, the current AR can assist the
MN in retrieving capability information from the CAR.
CARD Design Team Expires û September 2003 [Page 5]
Internet-Draft Candidate Access Router Discovery March 2003
4. CARD Protocol Operation
There are two modes of CARD protocol operation, namely the MN-
orchestrated CARD and the network-assisted CARD. These are described
below.
4.1 MN-Orchestrated CARD
In this mode, the MN performs CARD without any assistance from the
current AR. For this, the MN needs to have a capability to establish
IP connectivity with a CAR, while still being connected to its
current AR at IP level. In this case, the MN by itself discovers
capabilities of a CAR over the IP connectivity it establishes with
the CAR. The MN then performs TAR selection.
Figure 1 describes the timing diagram of MN-Orchestrated CARD. In
this mode of operation while being connected with current AR, a MN
establishes the IP layer connectivity with the serving AR of the
newly discovered AP and then obtains the capabilities from it. The
MN discovers the new access point ID during the periodic L2 scan of
the non-IP-connected interfaces. Subsequently, the MN requests the
capabilities of the newly discovered CAR by sending MN-AR CARD
Request ICMP options. The CAR in turn returns the capabilities to
the MN by sending AR-MN CARD Reply ICMP options. The capabilities
are encoded as sub-options of the AR-MN CARD Reply ICMP option. The
MN-AR CARD Request and the AR-MN CARD Reply ICMP options are either
piggybacked upon ongoing Router Advertisement/Solicitation messages
or sent as part of new ICMP messages. Section 5 describes the format
of the ICMP options as well as the header of the new ICMP message
required for delivering CARD options in stand-alone mode.
CARD Design Team Expires û September 2003 [Page 6]
Internet-Draft Candidate Access Router Discovery March 2003
MN current AR CAR1 CAR2
| Existing | | |
| IP Connectivity | | |
|<------------------->| | |
| | | |
| <~ ~ ~ L2-SCAN (1) | | |
| | | |
| Establish IP connectivity (2) | |
|<--------------------------------------->| |
| | | |
| | | |
| | | |
| | | |
| MN-AR CARD Request ICMP Option (3) | |
|---------------------------------------->| |
| | | |
| | | |
| AR-MN CARD Reply ICMP Option (4) | |
|<----------------------------------------| |
| | | |
| | | |
| | | |
| Establish IP Connectivity (2) |
|<------------------------------------------------------------->|
| | | |
| | | |
| MN-AR CARD Request ICMP Option (3) |
|-------------------------------------------------------------->|
| | | |
| | | |
| AR-MN CARD|Reply ICMP Option (4) |
|<------------------------------------------------------------- |
| | | |
| | | |
Figure 1: MN Orchestrated CARD timing diagram
4.2 Network-Assisted CARD
This mode caters to the case where the MN has IP layer connectivity
with the current AR only. However, the MN is capable of listening to
the L2 beacons from the neighboring AP(s) and thereby deducing their
L2 ID(s). For example, 802.11 families of MN or cellular handsets
with the mobile assisted handover capability are capable of
performing the aforementioned functions.
CARD Design Team Expires û September 2003 [Page 7]
Internet-Draft Candidate Access Router Discovery March 2003
The MN discovers the L2 ID of an AP during L2 scan process. The MN
passes on one or more L2 ID(s) to its current AR and the current AR
resolves it to the IP address of the CAR. For this, the current AR
first checks if the mapping is available locally in its cache. If
not, the current AR queries a CARD server with the said L2 ID and
the CARD server in turn returns the IP address of the CAR to the
current AR. The current AR then directly contacts the CAR and
performs capability discovery with it. The current AR then passes on
the IP address of the CAR and its capabilities to the MN. When the
handoff is imminent, the MN runs the TAR selection algorithm to
choose one AR as a target for handover from the set of CARs and
their capabilities it has learned through the CARD protocol. The
network-assisted CARD protocol operation is illustrated in Figure 2
below.
+----------+
+------------>| CARD |<-------------+
|+------------| Server |-------------+|
|| +----------+ ||
|| ||
|| ~~~~~~~~~~~ ||
(3)AR-Server||(4)AR-Server{ } || (0) CARD
CARD || CARD { } ||Registration
Request || Reply { IP Cloud } ||Request/Reply
|| { } ||
|| { } ||
|V ~~~~~~~~~~~ V|
+---------+ (5)AR-AR CARD Request +-----+-----+
| Current |------------------------->| CAR | CAR |
| AR |<-------------------------| 1 | 2 |
+---------+ (6)AR-AR CARD Reply +-----+-----+
^ | | |
(2)MN-AR | |(7)MN-AR | |
CARD | | CARD | |
Request| V REPLY +---+ +---+
+--------------+ (1) AP1 L2 ID +--|AP1| |AP2|
| Mobile |<---------------------+ +---+ +---+
| Node |<--------------------------------|
+--------------+ (1) AP2 L2 ID
Figure 2: CARD Protocol Overview (Network Assisted Mode)
CARD Design Team Expires û September 2003 [Page 8]
Internet-Draft Candidate Access Router Discovery March 2003
Note on TAR selection at current AR: Throughout this draft, we have
assumed that TAR selection is always performed on the MN. However,
there was also interest in the working group to enable TAR selection
on the current AR. In this case, there is a need to inform the
current AR about its requirements, so that the current AR can make
appropriate choice of a TAR from the set of CARs and their
capabilities. TAR selection on the current AR has not been discussed
in this draft as the working group consensus is pending on it.
Note on capability pre-filtering:
In case of implementing TAR selection in the MN, CAR capabilities
are required to be conveyed to the MN as input to the TAR selection
algorithm. The following approaches can be used for this purpose:
(A) Providing full capability set for TAR selection
The MN receives the full set of capability information from the
sender of capabilities. In the MN orchestrated mode, this sender is
the CAR, while in the network assisted mode it is the current AR.
Since no MN preferences for capabilities are to be transmitted to
the current AR, but the full set of capability information is to be
conveyed to the MN, this approach is "uplink optimized".
(B) Providing partial capability set for TAR selection
The MN informs the sender about the capabilities of interest. In the
MN orchestrated mode, this sender is the CAR, while in the network
assisted mode it is the current AR. In response, the sender sends a
subset of the CARs' capabilities to the MN to be used as input for
the TAR selection function.
Since this approach considers a reduced set of capabilities to be
sent to the MN but assumes a set of preferences to be sent
previously to the current AR, this approach is "downlink optimized".
As an enhancement to approach (B), context transfer (CT) framework
[4,5] can help to avoid sending the MN's preferences for pre-
filtering the capability information to the current AR for each
handover event. After the MN's preferences for pre-filtering have
been provided to the current AR once, this information can be
transferred to the selected TAR by means of CT mechanisms.
CARD Design Team Expires û September 2003 [Page 9]
Internet-Draft Candidate Access Router Discovery March 2003
Figure 3 describes the timing diagram of the Network Assisted CARD.
It is to be noted that in Figure 3, the CAR registration process is
not shown in critical path of the CARD discovery process. The CARs
register with the CARD server when the CAR is initialized or when
status of some of the L2 AP associated with the CAR or the
capability associated with the CAR change. The CAR MAY also
periodically register with the CARD server to update its capability
as well as the list of the current AP(s) being supported by it.
The CAR discovery process is initiated as soon as a mobile node
discovers the link layer ID of nearby AP during periodic L2 scan
process. The MN sends L2 ID of the AP to the connected AR in MN-AR
CARD Request ICMP option to obtain the identity and the capabilities
of the associated CAR. If not available in local cache, the current
AR subsequently sends AR-Server CARD Request message to the CARD
server to resolve the IP address of the serving AR of the newly
discovered AP. The CARD server then resolves the link layer ID to
the IP address of the CAR and returns the identity of the CAR as
well as available static capabilities to the requesting AR in the
Server-AR CARD Reply message. The capabilities are encoded according
to the encoding rule described in section 5.1.4 and conveyed in a
capability container attached to the Server-AR CARD Reply message.
Upon receipt of the Server-AR CARD Reply message, the current AR
extracts the IP address of the CAR and in turn requests remaining
capabilities by sending AR-AR CARD Request message to the CAR. The
CAR subsequently conveys its capabilities to the requesting AR in
AR-AR CARD Reply message. Upon receipt of the AR-AR CARD Reply
message, the current AR caches the capabilities as well as the L2-L3
mapping information in local cache and encodes the capabilities as
the sub-options of the AR-MN CARD Reply ICMP options. The AR-MN CARD
reply ICMP options are conveyed to the Mobile Node either as
piggybacked options of an outgoing FMIP Proxy Router Advertisement
message or the options of the new AR-MN CARD ICMP message. The
format of the new MN-AR ICMP message is described in section 5.1.
CARD Design Team Expires û September 2003 [Page 10]
Internet-Draft Candidate Access Router Discovery March 2003
MN current AR CARD Server CAR
| | | (Candidate
| | | Access
| | | Router)
| | | |
| | | Registration Req |
| | |<--------------------|
| <~ ~ ~ L2-SCAN (1) | | Registration Reply |
| | |-------------------->|
| | | |
| | | |
|MN-AR CARD Req ICMP | | |
| Option (2) | | |
|-------------------->| | |
| | AR-Server | |
| | CARD Req (3) | |
| |------------------>| |
| | Server-AR | |
| | CARD Reply (4) | |
| |<----------------- | |
| | | |
| | AR-AR CARD Req (5) |
| |---------------------------------------->|
| | | |
| | AR-AR CARD Reply (6) |
| |<----------------------------------------|
| | | |
| AR-MN CARD Reply | | |
| ICMP Options (7) | | |
|<--------------------| | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
Figure 3: Network Assisted CARD timing diagram
CARD Design Team Expires û September 2003 [Page 11]
Internet-Draft Candidate Access Router Discovery March 2003
5. Protocol Messages
5.1 CARD Messages for the interface MN - AR
5.1.1 CARD Main Header Format
Hosts and Access Routers use the CARD ICMP-type main header when
CARD protocol messages, to be exchanged between a MN and an AR,
cannot be piggybacked by another outgoing ICMP-type message, as for
example for Fast-MIPv6 purposes.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options ...
+-+-+-+-+-+-+-+-+-+-+-+-
IP Fields:
Source Address:
An IP address assigned to the sending
interface.
Destination Address:
An IP address assigned to the receiving
interface.
Hop Limit: 255
Authentication Header:
The sender SHOULD include the Authentication
Header, based on the previously established
Security Association between the sender and the
receiver.
ICMP Fields:
Type T.B.A (To be assigned)
Code 0
Checksum The ICMP checksum.
Reserved This field is unused. It MUST be initialized
with zero by the sender and MUST be ignored by
CARD Design Team Expires û September 2003 [Page 12]
Internet-Draft Candidate Access Router Discovery March 2003
the receiver.
Valid Options:
CARD Request: The CARD Request allows entities to request CARD
specific information. To process the CARD
Request message on the receiver side, further
sub-option must be carried with the message,
serving as input for the reverse address
translation function and/or capability discovery
function.
CARD Reply: The CARD Reply carries parameters, previously
requested with a CARD Request, back to the
sender of the CARD Request. Further sub-options
will be associated with the CARD Reply message.
Valid Sub-Options:
Layer-2 ID:
The Layer-2 ID carries information about the
type of access point as well as the Layer-2
address of the access point associated with the
CAR whose IP address and capability information
is to be resolved.
Preferences sub-option:
The Preferences sub-option carries information
about attributes of interest for the requesting
entity. Attributes are encoded according to the
AVP encoding rule as described in section
5.1.4. For settings of AVP Code and Data field,
please see section 5.1.3.2. This sub-option is
used only in case of performing capability pre-
filtering on ARs, which is referred to as
option to network assisted CARD and is
described in section 4.2.
Requirements:
The Requirements sub-option carries information
about attribute-value pairs required for TAR
selection to the entity performing TAR
selection. Currently, only the MN performs TAR
selection, hence, this sub-option is not used
so far, as long as working group consensus on
this issue is pending (please refer to section
4.2). Attribute-value pairs are encoded
according to the AVP encoding rule as described
in section 5.1.4. For settings of AVP Code and
Data field, please see section 5.1.3.3.
CARD Design Team Expires û September 2003 [Page 13]
Internet-Draft Candidate Access Router Discovery March 2003
Capability container:
The Capability container sub-option carries
information about a single CAR's capabilities.
The format of this sub-option is described in
section 5.1.3.4.
Address:
The Address sub-option carries information on a
resolved AR's IP address. The associated AR is
indicated either as a CAR or as a selected TAR,
depending on the protocol operation.
5.1.2 CARD Options Format
All options are of the form:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ... ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fields:
Type: 8-bit identifier of the type of option. The
options defined in this document are:
Option Name Type
--------------------------------------------------
MN-AR CARD Request T.B.A
MN-AR CARD Reply T.B.A
Length: 8-bit unsigned integer. The length of the
option including the type and length fields in
units of octets. The value 0 is invalid.
CARD Design Team Expires û September 2003 [Page 14]
Internet-Draft Candidate Access Router Discovery March 2003
5.1.2.1 CARD Request Option
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |P| Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-Options
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - -
Fields:
Type: T.B.A
Length: The length of the option in units of octets, including
the type and length fields as well as sub-options.
Flags: P-bit: Indicates Piggybacking capability of the
sender.
Remaining flags are reserved and MUST be initialized
with 0.
Sequence Number:
Allows correlating requests with replies.
Valid Sub-Options:
- L2-ID sub-option
- Preferences sub-option
- Requirements sub-option
5.1.2.2 CARD Reply Option
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |P| Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-Options
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - -
CARD Design Team Expires û September 2003 [Page 15]
Internet-Draft Candidate Access Router Discovery March 2003
Fields:
Type: T.B.A
Length: The length of the option in units of octets, including
the type and length fields as well as sub-options.
Flags: P-bit: Indicates piggybacking capability of the
message sender.
Remaining flags are reserved and MUST be initialized
with 0.
Sequence Number:
Allows correlating requests with replies.
Valid Sub-Options:
- L2-ID sub-option
- Capability Container sub-option
- Address sub-option
5.1.3 Sub-Options Format
All Sub-Options are of the form:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Sub-Option Type|Sub-Option Len | Sub-Option Data . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Sub-Option Type: 8-bit identifier of the type of option. The
Sub-Options defined in this document are:
Sub-Option Name Type
--------------------------------------------
L2-ID T.B.A
Preferences T.B.A
Requirements T.B.A
Capability Container T.B.A
Address T.B.A
Option-Length: 8-bit unsigned integer. The length of the
option including the type and length fields in
CARD Design Team Expires û September 2003 [Page 16]
Internet-Draft Candidate Access Router Discovery March 2003
units of octets. The value 0 is invalid.
5.1.3.1 L2-ID Sub-Option
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Sub-Option Type|Sub-Option Len | Context-ID | L2-Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| L2-ID . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - -
Sub-Option Type:
T.B.A
Sub-Option Length:
Length of the Sub-Option (including type and length
Fields as well as L2 type indicator) in units of 8
octets.
Context-ID: Identifies matching L2-ID, IP address and capability
information, when coming with separated sub-options.
L2 type: Indicates the interface type
(Ethernet, IEEE802.11b, ...).
L2-ID: The variable length layer-2 identifier of an
Individual CAR's Access Point. (bit and byte ordering
specifics?)
5.1.3.2 Preferences Sub-Option
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Sub-Option Type|Sub-Option Len | Preferences
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Sub-Option Type:
T.B.A
Sub-Option Length:
Length of the Sub-Option (including type and length
fields) in units of 8 octets.
Preferences: AVP encoded preferences (see section 5.1.4).
CARD Design Team Expires û September 2003 [Page 17]
Internet-Draft Candidate Access Router Discovery March 2003
AVPs MUST be encoded according to the rule described in section
5.1.4. Only ATTRIBUTES (AVP Code) need to be set. VALUE indicator
(Data) will not be processed and can be omitted. 'AVP Length' field
is to be set appropriately.
5.1.3.3 Requirements Sub-Option
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Sub-Option Type|Sub-Option Len | Requirements
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Sub-Option Type:
T.B.A
Sub-Option Length:
Length of the Sub-Option (including type and length
fields) in units of octets.
Requirements: AVP encoded requirements (see section 5.1.4)
AVPs MUST be encoded according to the rule described in section
5.1.4. Both, ATTRIBUTES (AVP Code) and VALUES (Data) MUST be set.
5.1.3.4 Capability Container Sub-Option
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Sub-Option Type|Sub-Option Len |P| Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Context-ID | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVPs
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - -
Sub-Option Type:
T.B.A
Sub-Option Length:
Length of the Sub-Option (including type and length
fields as well as AVPs) in units of 8 octets.
CARD Design Team Expires û September 2003 [Page 18]
Internet-Draft Candidate Access Router Discovery March 2003
Flags: P-flag: Indicates piggybacking capability of a CAR.
This flag allows a MN already after CARD process to
know about a selected new AR's piggybacking
capability.
Remaining flags are reserved and MUST be initialized
with 0.
Context-ID: Identifies L2-ID, IP address and capability triples,
coming with separated sub-options.
Reserved: This field MUST be initialized with 0.
AVPs: AVPs are a method of encapsulating capability
information relevant for the CARD protocol. See
section 5.1.4 for AVP encoding rule.
5.1.3.5 Address Sub-Option
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Sub-Option Type|Sub-Option Len | Address Type | Node Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Context-ID | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - -
Sub-Option Type:
T.B.A
Sub-Option Length:
Length of the Sub-Option (including type and length
fields) in units of octets.
Address Type: Indicates the type of the address.
0x01 IPv4
0x02 IPv6
Node Type: Indicates the node type the subsequent address is
associated to.
CARD Design Team Expires û September 2003 [Page 19]
Internet-Draft Candidate Access Router Discovery March 2003
Currently, the following node types are specified:
0x01 CAR Address
0x02 TAR Address
Context-ID: Identifies L2-ID, IP address and capability triples,
coming with separated sub-options.
Address: The Target Access Router's IP address.
5.1.4 CARD AVP encoding
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVP Code | AVP Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S| Reserved | Attribute Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - -
AVP Code: Identifies the attribute uniquely.
Flags: S: Static 1: static attribute, lifetime field
is ignored
0: lifetime field indicates the
attribute's lifetime. If
lifetime is set to 0, the
attribute value is valid only
for this single request!
Remaining flags are reserved and MUST be set to 0.
AVP Length: The three octet AVP length field indicates the
number of octets in this AVP, including the AVP Code,
AVP Flags, AVP Length, Lifetime and Data.
CARD Design Team Expires û September 2003 [Page 20]
Internet-Draft Candidate Access Router Discovery March 2003
5.2 CARD Messages for the interface between ARs (AR - AR)
5.2.1 Protocol transport (AR-AR)
For the CARD protocol operation between a MN's current AR and CARs
on the network side, UDP is used as transport for CARD protocol
messages. A UDP port for CARD is to be assigned.
To authenticate protocol messages between ARs, the IPSec
Authentication header is to be used.
5.2.2 Protocol main header
Protocol main header comprises the first 8 octets:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| Flags | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Payload ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - -
Version: Indicates the version of the protocol.
Flags: All flags are reserved and MUST be set to 0.
Type: Message type.
Message types specified for this interface:
Message Type
--------------------------------------
AR-AR CARD Request 0x01
AR-AR CARD Reply 0x02
Length: Length of the subsequent payload in octets.
Sequence number:
Allows correlating requests with responses.
CARD Design Team Expires û September 2003 [Page 21]
Internet-Draft Candidate Access Router Discovery March 2003
5.2.3 Protocol payload types
Payload types and encoding rules are the same as described for the
various sub-option types in section 5.1 for the Interface MN-AR.
Same TLV-encoded format is used to attach the options to the
protocol main header.
5.3 CARD Messages for the interface between an AR and the CARD server
5.3.1 Protocol transport (AR-Server function)
For the CARD protocol operation between an AR and the CARD server
function on the network side, UDP is used as transport for CARD
protocol messages. A UDP port for CARD is to be assigned.
Note:
However, if for security and reliability reasons use of, for
example, RADIUS or DIAMETER is preferable (assuming the CARD server
function to be integrated with a RADIUS/AAA server), CARD protocol
messages and payload is to be encoded appropriately.
This needs to be discussed.
To authenticate protocol messages between ARs, the IPSec
Authentication header is to be used.
5.3.2 Protocol main header
The protocol main header for this interface is the same as used for
the interface between ARs on network side, and is described in
section 5.2.2.
Since ARs need to register with the CARD server function, two
additional message types have been specified, which is a CARD
REGISTRATION REQUEST and a CARD REGISTRATION REPLY message.
The following table lists message types specified for CARD between
an AR and the CARD server function:
Message types specified for this interface:
Message Type
------------------------------------
AR-Server CARD Request 0x03
AR-Server CARD Reply 0x04
CARD Registration Request 0x05
CARD Registration Reply 0x06
CARD Design Team Expires û September 2003 [Page 22]
Internet-Draft Candidate Access Router Discovery March 2003
For the registration related message types, an additional payload
type is required and described in section 5.3.3.
5.3.3 Protocol payload types
Payload types and encoding rules are the same as described for the
various sub-option types in section 5.1 for the Interface MN-AR.
Same TLV-encoded format is used to attach the options to the
protocol main header.
For the registration of an AR with a CARD server function, an
additional payload type is required to indicate the lifetime of the
AR's registration. The lifetime option is encoded as follows
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 | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: T.B.A
Length: 0x08 - Length of the lifetime payload option in octets
(including type and length fields).
Reserved:
To be initialized with 0.
Lifetime:
Indicates the lifetime of a registration in seconds. If the
lifetime is set to '0', this indicates a de-registration
with a CARD server function.
CARD Design Team Expires û September 2003 [Page 23]
Internet-Draft Candidate Access Router Discovery March 2003
5.4 Overview on sub-options'/payload types' usage
The following table indicates which sub-options or payload types are
relevant for the various interfaces in CARD protocol functions.
Description Type Interface
MN-AR AR-Server AR-AR
---------------------------------------------------------------
L2-ID T.B.A x x
Preferences T.B.A x x
Requirements T.B.A x
Capability Container T.B.A x x x
Address T.B.A x x
Lifetime T.B.A x
6. Security Considerations
6.1 Security Associations
The AR-CARD Server communication and AR-AR communication need to be
protected using security associations between them. These security
associations can be established using current best practices. For
example, statically programmed passwords or certificates (note that
ARs and CARD server are in the same administrative domain) can be
used to create session keys for message protection using IPSec.
Alternatively, IPSec policy framework may be used to push
credentials on these network entities from the policy server, which
in turn can be used to create session keys for message protection
using IPSec. It is not the intent of the CARD protocol to define a
mechanism to create AR-CARD server and AR-AR security associations.
It is implicit that the MN will have a security association with the
current AR.
Note: For AR-AR messaging, the CARD protocol shares security
requirements with FMIPv6 and CT. Thus a common solution to establish
security association between ARs can be used for FMIPv6, CT and CARD
protocol.
6.2 DoS Attack
The MN-AR communication presents chances to an attacker. A rogue MN
can use CARD as a Denial-of-Service (DoS) attack against an AR. It
may also flood the backend AR-Server and AR-AR communications. If
the MN undertakes a DoS attack by flooding the AR with real or bogus
layer 2 addresses, the CARD should prevent it. Since the requests
from a MN come from within its subnet, the AR may know who is
CARD Design Team Expires û September 2003 [Page 24]
Internet-Draft Candidate Access Router Discovery March 2003
sending the requests. One possible solution is to limit the number
of requests from a MN within a unit of time. But still, the rogue MN
may change its identity so that the AR cannot detect. Another
solution may be to define a kind of 'scope ID'. This is something to
be configured administratively, but would make detection of ARs,
which are not CARs easier and avoids cache overflow. For example,
operators may set their ARs' scope-IDs based on the rough location
and ARs register their scope-IDs to a server. When a current AR
requests the L2-L3 mapping from the server, the server returns the
mapping with its scope-ID. The current AR detects that this AR is
potentially no CAR. Then, it can avoid further attempts to perform
reverse address translation and capability discovery for this AR.
6.3 CAR Cache Contamination
When caching is allowed at AR, the issue of preventing cache
contamination needs to be addressed. A MN provides the current AR
with unauthenticated observations of AP identifiers that it can
hear. Then the AR asks for the authenticated AR information via the
CARD server. The CARD server can tell only that there is a
registered AR with the given L2 address but it cannot tell whether
the AR is a CAR of the current AR (Note that CAR needs to have an
access point geographically adjacent to current AR). Now the current
AR relies on the fact that a MN provided the L2 address matching to
a registered AR. A malicious MN may provide a L2 address, which is
the L2 address of a registered AR but not a CAR of the current AR,
that is, no overlapping coverage with the current AR. Then the
current AR will build a CAR cache table with IP addresses of ARs
that are not CARs. This has implications on size of cache that can
be allowed on ARs. A more serious implication is that if large
number of non-CAR entries appear in AR cache, AR spends processing
power in performing capability exchange procedures with them.
However, this issue may not be a problem in actual handover cases.
At the time of handover, the MN or AR will receive the layer 2
address of the AP to which the MN is moving. Or the MN will match
the AP layer 2 addresses in the CAR table with the address of the
Aps it can hear. Thus, an AP address that is provided by a malicious
MN but has no wireless connectivity to the CAR will get filtered out
when the MN or AR uses the information for handover, so this issue
can do no harm when the time of handover.
Note: If cache contains bogus entries, hit ratio will go down. So,
L2-IP mapping needs to be done from the CARD server. There is no
guarantee, that answer from the CARD server will come in time for
handover.
CARD Design Team Expires û September 2003 [Page 25]
Internet-Draft Candidate Access Router Discovery March 2003
This contaminated cache issue can be considered as a failure of the
CAR cache table optimization. In addition to the æscope IDÆ solution
described above, there is another possible solution for this
optimization. The ARs can handle this by making the CARD information
soft state, so that it times out the AP addresses if it doesnÆt
receive a confirmation from another MN within a certain period of
time. Thus, any bogus information has only limited lifetime, and
even within that lifetime, it cannot do more than to occupy a table
slot in the ARÆs memory. In fact, the AR can use the number of MNs
reporting a particular address to weight the relevance of a reported
AP. So, if 20 MNs report it, the AP address is more likely to stick
around than if only 1 reports it. Note that this is not a protocol
issue but an optimization issue for implementation.
For additional security concerns, the reader is referred to [3].
7. IANA considerations
This will be done later when the protocol proposal has been
finalized.
8. References
[1]Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2]Trossen, D., Krishanmurthi, G. Chaskar, H., Kempf, J. ôIssues in
candidate access router discovery for seamless IP-level
handoffs", draft-ietf-seamoby-cardiscovery-issues-04.txt, work in
progress, October 2002.
[3]Krishanmurti, G., ôRequirements for CAR Discovery Protocolsö,
draft-ietf-seamoby-card-requirements-02.txt, a work in progress,
October 2002.
[4]Kempf, J.,"Problem Description: Reasons For Performing Context
Transfers Between Nodes in an IP Access Network", RFC 3374,
September 2002.
[5]Kenward, B.,"General Requirements for Context Transfer", draft-
ietf-seamoby-ct-reqs-05.txt, a work in progress, October 2002.
CARD Design Team Expires û September 2003 [Page 26]
Internet-Draft Candidate Access Router Discovery March 2003
9. Authors' Addresses
Hemant Chaskar
Nokia Research Center
5 Wayside Road
Burlington, MA 01803, USA
Phone: 781 993 3785
Email: Hemant.Chaskar@nokia.com
Daichi Funato
NTT DoCoMo USA Labs
181 Metro Drive, Suite 300
San Jose, CA 95110, USA
Phone: +1 408-451-4736
EMail: funato@docomolabs-usa.com
Marco Liebsch
NEC Network Laboratories
Kurfuersten-Anlage 36 , 69115 Heidelberg
Germany
Phone: +49/(0)6221 90511 46
Email: marco.liebsch@ccrle.nec.de
Ajoy Singh
Motorola Inc
1501 West Shure Dr
Phone: 847 632 6941
Email: asingh1@email.mot.com
10. IPR Statements
The IETF has been notified of intellectual property rights claimed
in regard to some or all of the specification contained in this
document. For more information consult the online list of claimed
rights.
Please refer to http://www.ietf.org/ietf/IPR for more information.
CARD Design Team Expires û September 2003 [Page 27]
Internet-Draft Candidate Access Router Discovery March 2003
11. Copyright Notice
"Copyright (C) The Internet Society (date). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph
are included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."
12. Acknowledgements
The CARD design team would like to thank Erik Nordmark for providing
valuable insight about the piggybacking of CARD options upon FMIPv6
messages. In addition, the design team would like to thank (in
alphabetical order) Eunsoo Shim, Govind Krishnamurthi, James Kempf,
Madjid Nakhjiri, Pete McCann, Rajeev Koodli, and other members of
the Seamoby WG for their valuable comments on the previous version
of the draft as well as the general CARD related discussion and
feedback on the WG mailing list.
CARD Design Team Expires û September 2003 [Page 28]
| PAFTECH AB 2003-2026 | 2026-04-24 09:02:22 |