Internet DRAFT - draft-zhang-mipshop-fmip-arinfo
draft-zhang-mipshop-fmip-arinfo
MIPSHOP Working Group Jian Zhang
Hongfei Chen
Zhongqi Xia
Internet Draft Huawei Technologies
Xiaodong Duan
Zhaomin Zhou
China Mobile
Expires: December 2006 June 29, 2006
AR information for FMIPv6
draft-zhang-mipshop-fmip-arinfo-01.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that
any applicable patent or other IPR claims of which he or she is
aware have been or will be disclosed, and any of which he or she
becomes aware will be disclosed, in accordance with Section 6 of
BCP 79.
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
Jian et al. Expires December 29, 2006 [Page 1]
Internet-Draft AR information for FMIPv6 June 2006
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
This Internet-Draft will expire on December 29, 2006.
Abstract
The document [FMIP] describes a protocol to reduce the handover
latency of MIPv6. In order to reduce the handover latency, MN in
FMIPv6 protocol should first send request message to PAR for NAR's
information, which is (AP-ID, AR-Info). If PAR can not provide (AP-ID,
AR-Info) to MN, MN cannot use FMIPv6 protocol to perform fast
handover. So it is important for PAR to have the information of NAR.
But there is no mechanism to build the (AP-ID, AR-Info) in FMIPv6
protocol. This draft describes a mechanism used to build (AP-ID, AR-
Info) information.
Conventions used in this document
In examples, "C:" and "S:" indicate lines sent by the client and
server respectively.
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 0.
Table of Contents
1. Introduction.................................................3
2. Terminology..................................................4
3. Protocol Overview............................................4
3.1. Reference model.........................................4
3.2. Registration procedure..................................5
3.3. (AP-ID, AR-Info) update procedure.......................6
3.4. Logout procedure........................................7
4. New messages and options.....................................8
4.1. AR Information protocol messages........................8
4.1.1. Registration message...............................9
4.1.2. Registration Acknowledgement message..............10
4.1.3. (AP-ID, AR-Info) update message...................11
4.1.4. (AP-ID, AR-Info) acknowledgement message..........12
4.2. AR Information protocol options........................13
4.2.1. AR registration option............................13
4.2.2. (AP-ID, AR-Info) option...........................15
Jian et al. Expires December 29, 2006 [Page 2]
Internet-Draft AR information for FMIPv6 June 2006
5. AR Operation................................................16
5.1. Conceptual Data Structures.............................16
5.2. Registration with AR-ICR...............................17
5.3. (AP-ID, AR-Info) disposing.............................17
5.4. AR disposing...........................................18
5.5. Provide information for FMIP...........................18
6. AR-ICR Operation............................................18
6.1. Conceptual Data Structures.............................18
6.2. Registration...........................................19
6.3. AR disposing...........................................19
6.4. (AP-ID, AR-Info) disposing.............................20
7. Security Considerations.....................................20
8. IANA Considerations.........................................21
9. Acknowledgments.............................................21
10. References.................................................22
10.1. Normative References..................................22
10.2. Informative References................................22
Author's Addresses.............................................22
Intellectual Property Statement................................23
Disclaimer of Validity.........................................24
Copyright Statement............................................24
Acknowledgment.................................................24
1. Introduction
The document [FMIP] describes a protocol to reduce the handover
latency of MIPv6. In order to reduce the handover latency, MN in
FMIPv6 protocol should first send request message to PAR for NAR's
information, which is (AP-ID, AR-Info). If PAR can not provide (AP-ID,
AR-Info) to MN, MN cannot use FMIPv6 protocol to perform fast
handover. So it is important for PAR to have the information of NAR.
But there is no mechanism to build the (AP-ID, AR-Info) in FMIPv6
protocol. This draft describes a mechanism used to build (AP-ID, AR-
Info) information.
In this draft, a new entity is introduced to collect (AP-ID, AR-Info)
information from AR and forward (AP-ID, AR-Info) information to other
ARs. The forwarding of (AP-ID, AR-Info) information is based on the
AR's location information. There are also some registration and
authentication procedures for security.
Jian et al. Expires December 29, 2006 [Page 3]
Internet-Draft AR information for FMIPv6 June 2006
2. Terminology
Access Router Information Collecting Router (AR-ICR)
A router, which is in the same domain with AR, is used to receive
(AP-ID, AR-Info) information from original AR and forward to other
ARs which is at the same location with original AR.
AR Identifier (AR-ID)
AR Identifier is a 128-bit identifier, which is used to identify
an AR. AR-ID can be a IPv6 address that belongs to AR.
AR Location (AR-Loc)
AR Location is a 32-bit location information identifier, which is
used to ascertain which ARs are at the same location.
3. Protocol Overview
For FMIPv6, (AP-ID, AR-Info) information is very important. If there
lock of (AP-ID, AR-Info) information, MN cannot perform fast handover
based on FMIPv6 protocol. This draft presents a protocol used to
collect (AP-ID, AR-Info) information.
3.1. Reference model
In this protocol, a new entity, which is called AR-ICR, is introduced.
So there are two kinds of entities, one is AR and the other is AR-ICR.
AR sends (AP-ID, AR-Info) information to AR-ICR and receives other
AR's (AP-ID, AR-Info) information from AR-ICR. AR-ICR is responsible
for forwarding (AP-ID, AR-Info) information between ARs based on AR's
location information. The reference model is illustrated in Figure 1.
First, AR must register with AR-ICR in order to use this protocol.
For security, there may be an authentication procedure before AR
sending (AP-ID, AR-Info) to AR-ICR. After that, AR sends update
messages to AR-ICR with one or more (AP-ID, AR-Info). AR-ICR will
forward (AP-ID, AR-Info) to other ARs which are at the same location
with AR where the (AP-ID, AR-Info) was sent. If an AR wants to quit
this protocol, it can send logout message to AR-ICR. AR-ICR will
notify other ARs, which are at the same location, to delete the (AP-
ID, AR-Info) that originate from this AR.
Jian et al. Expires December 29, 2006 [Page 4]
Internet-Draft AR information for FMIPv6 June 2006
Based on this protocol, each AR can know the (AP-ID, AR-Info)s that
belong to adjacent ARs. When AR received RtSolPr message from MN, it
can search its (AP-ID, AR-Info) cache and send PrRtAdv message to MN
with (AP-ID, AR-Info).
+--------------------+
| AR-ICR |
+--------------------+
/ | \
/ | \
/ | \
+-------+ +-------+ +-------+
| AR1 | | AR2 | | AR3 |
+-------+ +-------+ +-------+
/ \ | / \
/ \ | / \
/ \ | / \
/ \ | / \
+------+ +------+ +------+ +------+ +------+
| AP11 | | AP11 | | AP11 | | AP11 | | AP11 |
+------+ +------+ +------+ +------+ +------+
+----+ .
| MN |----> .
+----+ .
Figure 1 Reference model for AR Info Protocol.
3.2. Registration procedure
In order to use AR Info Protocol, AR must register with AR-ICR first.
Then AR-ICR will know who wants to use its service. For security, AR-
ICR can ask AR to do authentication. The registration procedure is
illustrated in Figure 2.
First, AR must send registration message to AR-ICR with AR-ID, AR-Loc,
and AR's lifetime information. AR-ICR will use AR-ID to identify an
AR and its (AP-ID, AR-Info), use AR-Loc to make decision that which
ARs are adjacent, and use AR's lifetime to make sure that AR is still
active. AR-ICR must save this information as described in section 6.
AR-ICR will send registration acknowledgement message to AR to
confirm whether the registration is success or not. If it is
Jian et al. Expires December 29, 2006 [Page 5]
Internet-Draft AR information for FMIPv6 June 2006
necessary, AR-ICR can ask AR to do authentication procedure. This can
be indicated in acknowledgement message.
If AR-ICR asks for authentication, AR can perform authentication
procedure by Radius, Diameter, and so on.
After AR has successful register with AR-ICR, AR-ICR must examine
whether there are some (AP-ID, AR-Info) that need to download to AR
based on AR-Loc. If there are some (AP-ID, AR-Info) needed to
download, AR-ICR will send update message to AR, and AR will save
this information as described in section 5.
AR AR-ICR
| |
| Register with AR-ICR |
|------------------------->|
| |
| Ack of Register |
|<-------------------------|
| |
| Authentication if needed |
|<------------------------>|
| |
| |
| Download (AP-ID, AR-Info)|
|<-------------------------|
| |
| |
Figure 2 Registration procedure.
3.3. (AP-ID, AR-Info) update procedure
It is an important procedure that AR floods (AP-ID, AR-Info) to
adjacent AR based on AR-Loc information. To satisfy this requirement,
AR should send update message to AR-ICR, which includes AP-ID, AR MAC
address, AR IPv6 address, AR prefix, lifetime, and AR-ID. After
received this message, AR-ICR saves this information and sends a
reply to AR. Also, AR-ICR will make a decision that which AR is
adjacent with original AR based on AR-Loc information. Then AR-ICR
forwards this information to adjacent AR.
Jian et al. Expires December 29, 2006 [Page 6]
Internet-Draft AR information for FMIPv6 June 2006
The time when AR sends update message to AR-ICR are described as
below:
1. When AR has finished the registration procedure, AR should send
update message to AR-ICR.
2. When the lifetime of (AP-ID, AR-Info) will be expired, AR should
send update message to AR-ICR.
3. When there are some change in (AP-ID, AR-Info), such as introduce
or remove an AP, AR should send update message to AR-ICR.
Note: If AR wants to withdraw a (AP-ID, AR-Info), it should send
update message to AR-ICR with lifetime must be zero.
AR AR-ICR Adjacent AR
| | |
| Update | |
|------------------->| |
| | |
| Ack | |
|<-------------------| |
| | Update |
| |-------------------->|
| | |
| | |
Figure 3 Update procedure.
3.4. Logout procedure
If an AR wants to quit this protocol, it should send registration
message to AR-ICR with zero lifetime of AR's. When AR-ICR received
this message, AR-ICR sends update message of (AP-ID, AR-Info) to
adjacent AR with zero lifetime of (AP-ID, AR-Info) to notify adjacent
AR to delete (AP-ID, AR-Info) of original AR's. And then, AR-ICR
should delete original AR's information and corresponding (AP-ID, AR-
Info).
Jian et al. Expires December 29, 2006 [Page 7]
Internet-Draft AR information for FMIPv6 June 2006
AR AR-ICR Adjacent AR
| | |
| Logout | |
|------------------->| |
| | |
| | Update |
| |-------------------->|
| | |
| | |
Figure 4 Logout procedure.
4. New messages and options
4.1. AR Information protocol messages
All of messages used in this protocol are extended from ICMPv6
message. The message header is consistent with ICMPv6 message, and
the message of AR info protocol is carried by ICMPv6 message body.
The message is illustrated in Figure 5.
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Body |
Figure 5 Message header of AR info protocol.
ICMP fields:
Type
Represents AR Info protocol, the value is TBD.
Code
Jian et al. Expires December 29, 2006 [Page 8]
Internet-Draft AR information for FMIPv6 June 2006
Always be zero.
Checksum
ICMPv6 checksum.
Reserved
MUST be set to zero by the sender and ignored by the receiver.
Message body
AR Info Protocol message.
4.1.1. Registration message
Registration message is sent by AR to AR-ICR, which is used for
registration. It includes AR registration 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 | Code | Sequence |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AR Registration Option |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6 Registration message.
Type
Message type, the value is TBD.
Code
Must be zero.
Sequence
Jian et al. Expires December 29, 2006 [Page 9]
Internet-Draft AR information for FMIPv6 June 2006
A 16-bit unsigned integer used by the receiving node to sequence
message and by the sending node to match a returned acknowledgement.
Reserved
MUST be set to zero by the sender and ignored by the receiver.
AR Registration Option
AR information used for register with AR-ICR, see section 4.2.1.
4.1.2. Registration Acknowledgement message
Registration acknowledgement message is sent by AR-ICR to AR, which
is used for confirming the registration. It includes registration
code.
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 | Sequence |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7 Registration Acknowledgement message.
Type
Message type, the value is TBD.
Code
8-bit unsigned integer indicating the disposition of the
Registration message. Values of the Code field less than 128
indicate that the Registration was accepted by the AR-ICR. Values
greater than or equal to 128 indicate that the Registration was
rejected by the AR-ICR. The following Code values are currently
defined:
0 Registration accepted
Jian et al. Expires December 29, 2006 [Page 10]
Internet-Draft AR information for FMIPv6 June 2006
1 Accepted but authentication necessary
128 Rejected
Sequence
The Sequence Number in the Registration Acknowledgement is copied
from the Sequence Number field in the Registration message. It is
used by the AR in matching this Registration Acknowledgement with
an Registration message.
Reserved
MUST be set to zero by the sender and ignored by the receiver.
4.1.3. (AP-ID, AR-Info) update message
(AP-ID, AR-Info) update message is used to flood (AP-ID, AR-Info)
information between adjacent ARs. In order to flood (AP-ID, AR-Info)
information between ARs, AR must send (AP-ID, AR-Info) update message
to AR-ICR. AR-ICR will forward (AP-ID, AR-Info) information to
adjacent AR based on AR-Loc.
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 | Sequence |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ AR-ID +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (AP-ID, AR-Info) options...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8 (AP-ID, AR-Info) update message.
Jian et al. Expires December 29, 2006 [Page 11]
Internet-Draft AR information for FMIPv6 June 2006
Type
Message type, the value is TBD.
Code
Must be zero.
Sequence
A 16-bit unsigned integer used by the receiving node to sequence
message and by the sending node to match a returned acknowledgement.
Reserved
MUST be set to zero by the sender and ignored by the receiver.
AR-ID
AR-ID is a 128-bit identifier, which is used to identify an AR. AR-
ID can be an IPv6 address that belongs to AR
(AP-ID, AR-Info) options
(AP-ID, AR-Info) options see section 4.2.2
4.1.4. (AP-ID, AR-Info) acknowledgement message
(AP-ID, AR-Info) acknowledgement message is used to confirm that (AP-
ID, AR-Info) has been received and disposed correctly by AR-ICR.
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 | Sequence |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9 (AP-ID, AR-Info) acknowledgement message.
Type
Jian et al. Expires December 29, 2006 [Page 12]
Internet-Draft AR information for FMIPv6 June 2006
Message type, the value is TBD.
Code
8-bit unsigned integer indicating the disposition of the (AP-ID,
AR-Info) message. Values of the Code field less than 128 indicate
that the (AP-ID, AR-Info) was accepted by the AR-ICR. Values
greater than or equal to 128 indicate that the (AP-ID, AR-Info) was
rejected by the AR-ICR. The following Code values are currently
defined:
0 Registration accepted
128 Rejected
Sequence
The Sequence Number in the (AP-ID, AR-Info) Acknowledgement is
copied from the Sequence Number field in the (AP-ID, AR-Info)
message. It is used by the AR in matching this (AP-ID, AR-Info)
Acknowledgement with a (AP-ID, AR-Info) message.
Reserved
MUST be set to zero by the sender and ignored by the receiver.
4.2. AR Information protocol options
4.2.1. AR registration option
AR registration option is used in Registration message to carry AR-ID
and AR-Loc information.
Jian et al. Expires December 29, 2006 [Page 13]
Internet-Draft AR information for FMIPv6 June 2006
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 | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ AR-ID +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AR-Loc |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10AR Registration Option.
Type
Option type, the value is TBD.
Code
Must be zero.
Lifetime
The lifetime, in time units of 4 seconds, for which AR-ICR SHOULD
retain the entry in its AR cache. If lifetime is zero, AR will
logout from AR-ICR.
Reserved1
MUST be set to zero by the sender and ignored by the receiver.
AR-ID
AR-ID is a 128-bit identifier, which is used to identify an AR. AR-
ID can be an IPv6 address that belongs to AR
AR-Loc
Jian et al. Expires December 29, 2006 [Page 14]
Internet-Draft AR information for FMIPv6 June 2006
AR Location is a 32-bit location information identifier, which is
used to ascertain which ARs are at the same location.
Reserved2
MUST be set to zero by the sender and ignored by the receiver.
4.2.2. (AP-ID, AR-Info) option
(AP-ID, AR-Info) option is used in (AP-ID, AR-Info) update message to
carry (AP-ID, AR-Info) information.
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 | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options...
+-+-+-+-+-+-+-+-+-+
Figure 11(AP-ID, AR-Info) Option.
Type
Option type, the value is TBD.
Code
Must be zero.
Lifetime
The lifetime, in time units of 4 seconds, for which AR/AR-ICR
SHOULD retain the entry in its (AP-ID, AR-Info) cache. If lifetime
is zero, (AP-ID, AR-Info) will be deleted.
Reserved
MUST be set to zero by the sender and ignored by the receiver.
Jian et al. Expires December 29, 2006 [Page 15]
Internet-Draft AR information for FMIPv6 June 2006
Valid Options:
Link Layer Address Option
The Link Layer Address of the interface to which IP Address
Option belongs to. See Link-Layer Address Option defined in RFC
4068 [FMIP].
IP Address Option
The IP Address of the sender which can be used as new router
address by the adjacent AR. See IP Address Option defined in
RFC 4068 [FMIP].
Prefix Information Option
The prefix of the sender used for FMIPv6. See New Router
Prefix Information Option defined in RFC 4068 [FMIP].
5. AR Operation
5.1. Conceptual Data Structures
There are three kinds of data that AR should maintain, AR-ICR
information, AR information, and (AP-ID, AR-Info) information. These
data MAY be implemented in any manner consistent with the external
behavior described in this document.
AR-ICR information contains the following fields:
o The IPv6 address of AR-ICR, which AR is used to send message to.
AR information contains the following fields:
o AR-ID is used to identify AR itself.
o AR-Loc is information of AR's location, which will be used by AR-
ICR to determine adjacent AR.
Jian et al. Expires December 29, 2006 [Page 16]
Internet-Draft AR information for FMIPv6 June 2006
o Lifetime indicates the remaining lifetime for this AR. When AR's
lifetime will be expired, AR MUST send Registration message to AR-
ICR to update AR information saved in AR-ICR.
(AP-ID, AR-Info) information contains the following fields:
o (AP-ID, AR-Info) that may be belong to AR itself or adjacent AR,
and the detail description can be found in RFC 4068 [FMIP].
o Lifetime indicates the remaining lifetime for this entry. When its
own (AP-ID, AR-Info)'s lifetime will be expired, AR MUST send (AP-
ID, AR-Info) update message to AR-ICR to update (AP-ID, AR-Info)
saved in AR-ICR. If the (AP-ID, AR-Info) belongs to adjacent AR,
AR will delete it when its lifetime expired.
o AR-ID is used to identify which AR this entry belongs to.
5.2. Registration with AR-ICR
After AR started AR Info protocol, AR MUST register with AR-ICR. AR
sends Registration message to AR-ICR, with lifetime is none zero.
When AR received Registration acknowledgement message from AR-ICR, AR
MUST check the code field in Registration acknowledgement message. If
the registration is accepted by AR-ICR, then AR can move to next step.
If authentication is required by AR-ICR, then AR MUST perform
authentication procedure using AAA protocol.
If AR wants to quit AR Info Protocol, it MUST send Registration
message to AR-ICR, with lifetime is zero. Then AR can clear all
information and status of AR Info protocol.
5.3. (AP-ID, AR-Info) disposing
In the case that list below, AR MUST send (AP-ID, AR-Info) update
message to AR-ICR. If the lifetime of (AP-ID, AR-Info) is zero, this
entry will be deleted. Otherwise, the entry will be updated.
o Registration procedure has finished.
o Lifetime of (AP-ID, AR-Info) that belongs to AR itself will be
expired.
Jian et al. Expires December 29, 2006 [Page 17]
Internet-Draft AR information for FMIPv6 June 2006
o There is an AP added to network or deleted from network.
AR MUST be able to received adjacent AR's (AP-ID, AR-Info) from AR-
ICR, and save it to local cache, which can be used by FMIPv6 later.
AR MUST check the lifetime of (AP-ID, AR-Info) periodically to see
whether the lifetime will be expired. If the lifetime will be expired
and the entry belongs to AR itself, AR MUST send (AP-ID, AR-Info)
update message to AR-ICR to update the entry. If the lifetime is
expired, the entry belongs to adjacent AR, and there is no update
message received by AR for this entry, AR MUST delete this entry.
5.4. AR disposing
AR MUST check the lifetime of AR periodically to see whether the
lifetime will be expired. If the lifetime will be expired, AR MUST
send Registration message to AR-ICR to update the AR's information
and status.
5.5. Provide information for FMIP
AR MUST be able to search (AP-ID, AR-Info) entry based on AP-ID, so
that FMIPv6 can use this information to perform fast handover.
6. AR-ICR Operation
6.1. Conceptual Data Structures
There are two kinds of data that AR-ICR should maintain, AR
information and (AP-ID, AR-Info) information. These data MAY be
implemented in any manner consistent with the external behavior
described in this document.
AR information contains the following fields:
o AR-ID is used to identify AR.
o AR-Loc is information of AR's location, which will be used by AR-
ICR to determine adjacent AR.
Jian et al. Expires December 29, 2006 [Page 18]
Internet-Draft AR information for FMIPv6 June 2006
o Lifetime indicates the remaining lifetime for AR. When AR's
lifetime will be expired, AR MUST send Registration message to AR-
ICR to update AR information saved in AR-ICR, otherwise AR-ICR
will delete its information and corresponding (AP-ID, AR-Info).
(AP-ID, AR-Info) information contains the following fields:
o (AP-ID, AR-Info) that may be belong to AR itself or adjacent AR,
and the detail description can be found in RFC 4068 [FMIP].
o Lifetime indicates the remaining lifetime for this entry. When its
own (AP-ID, AR-Info)'s lifetime will be expired, AR MUST send (AP-
ID, AR-Info) update message to AR-ICR to update (AP-ID, AR-Info)
saved in AR-ICR. If the (AP-ID, AR-Info) belongs to adjacent AR,
AR will delete it when its lifetime expired.
o AR-ID is used to identify which AR this entry belongs to.
6.2. Registration
AR-ICR MUST be able to receive and process Registration message which
was sent from AR. AR-ICR MUST validate Registration message, save
this information in AR data cache, and then send Registration
acknowledgement message to AR.
If authentication is needed, AR-ICR MUST send Registration
acknowledgement message to AR with that the Code field is set to one.
In this case, AR-ICR MUST support authentication protocols, such as
Radius, Diameter, and so on.
After the Registration procedure has finished, AR-ICR should check
whether there are some (AP-ID, AR-Info) to download to AR based on
AR-Loc.
6.3. AR disposing
When AR-ICR receives Registration message from AR, if the same AR's
information is already exist in AR-ICR, AR-ICR MUST update this
information. Otherwise AR-ICR MUST perform Registration procedure.
Jian et al. Expires December 29, 2006 [Page 19]
Internet-Draft AR information for FMIPv6 June 2006
When received Logout message from AR, if there isn't AR's information
saved in AR-ICR, AR-ICR MUST discard this message silently. If there
is AR's information saved in AR-ICR, AR-ICR searches the (AP-ID, AR-
Info) entries which belongs to AR, and then notifies adjacent AR to
delete these entries. At the end, AR-ICR MUST delete these entries
and AR's information.
AR-ICR MUST check the lifetime of AR's periodically. If it receives
the Registration message before lifetime expired, AR-ICR MUST update
lifetime. Otherwise, AR-ICR MUST notify adjacent AR to delete the
(AP-ID, AR-Info) entries belongs to this AR, and then delete these
entries and AR's information in its own cache.
6.4. (AP-ID, AR-Info) disposing
When received (AP-ID, AR-Info) from AR, AR-ICR MUST check whether the
AR has already registered with it. If AR didn't register with AR-ICR,
AR-ICR MUST discard this message silently. If the lifetime of entry
is zero, AR-ICR MUST delete this entry in its (AP-ID, AR-Info) cache,
and notify adjacent AR to delete this entry. If the lifetime of entry
is not zero, AR-ICR MUST update or add this entry, and then forward
this entry to adjacent AR based on AR-Loc.
AR-ICR MUST check the lifetime of each (AP-ID, AR-Info) entry
periodically. If it receives the Update message for this entry before
lifetime expired, AR-ICR MUST update lifetime. Otherwise, AR-ICR MUST
notify adjacent AR to delete the (AP-ID, AR-Info) entry, and then
delete this entry in its own cache.
AR-ICR MUST update (AP-ID, AR-Info) entries to ARs based on AR-Loc,
which lifetime has not expired.
7. Security Considerations
This document proposed a new AR Info Protocol. For security, each AR
that wants to use this protocol MUST register with AR-ICR. If needed,
there can be an authentication procedure. The new messages are
extended ICMPv6 message. All security provisions in [ICMPv6] apply
equally to this document.
Jian et al. Expires December 29, 2006 [Page 20]
Internet-Draft AR information for FMIPv6 June 2006
8. IANA Considerations
IANA services are required for this document. The values for new
messages must be assigned from the ICMPv6 [ICMPv6] numbering space.
Type of AR Info Protocol message
Type of Registration message
Type of Registration Acknowledgement message
Type of (AP-ID, AR-Info) Update message
Type of (AP-ID, AR-Info) Acknowledgement message
Type of AR Registration Option
Type of (AP-ID, AR-Info) Option
9. Acknowledgments
Jian et al. Expires December 29, 2006 [Page 21]
Internet-Draft AR information for FMIPv6 June 2006
10. References
10.1. Normative References
[RFC-2119]Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[FMIP] Rajeev Koodli(Editor), "Fast Handovers for Mobile IPv6", RFC
4068, July 2005.
[MIP6] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in
IPv6", RFC 3775, June 2004.
[ICMPv6] A. Conta, and S. Deering, "Internet Control Message Protocol
(ICMPv6) for the Internet Protocol Version 6 (IPv6) ", RFC
2463, December 1998
10.2. Informative References
[FMIPbit] Rajeev Koodli(Editor), "Fast Handovers for Mobile IPv6",
draft-koodli-mipshop-rfc4068bis-00,(work in progress), July
2005.
Author's Addresses
Jian Zhang
Huawei Technologies Co., LTD.
No. 3 Xinxi Road, Shangdi,
HaiDian District,
Beijing City,
The P.R.China
Email: hwzhj@huawei.com
Hongfei Chen
Huawei Technologies Co., LTD.
No. 3 Xinxi Road, Shangdi,
HaiDian District,
Beijing City,
The P.R.China
Email: chenhongfei@huawei.com
Jian et al. Expires December 29, 2006 [Page 22]
Internet-Draft AR information for FMIPv6 June 2006
Zhongqi Xia
Huawei Technologies Co., LTD.
No. 3 Xinxi Road, Shangdi,
HaiDian District,
Beijing City,
The P.R.China
Email: xiazhongqi@huawei.com
Xiaodong Duan
Research Institut of China Mobile
53A Xibianmennei Ave,
Xuanwu District,
Beijing City,
The P.R.China
Email: duanxiaodong@chinamobile.com
Zhaomin Zhou
Research Institut of China Mobile
53A Xibianmennei Ave,
Xuanwu District,
Beijing City,
The P.R.China
Email: zhoudaomin@chinamobile.com
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
Jian et al. Expires December 29, 2006 [Page 23]
Internet-Draft AR information for FMIPv6 June 2006
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM 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.
Copyright Statement
Copyright (C) The Internet Society (2006).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Jian et al. Expires December 29, 2006 [Page 24]
