MIPSHOP Working Group Jian Zhang Hongfei Chen Internet Draft Huawei Technologies Expires: December 2006 June 1, 2006 AR information for FMIPv6 draft-zhang-mipshop-fmip-arinfo-00.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 The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on November 1, 2006. Jian et al. Expires December 1, 2006 [Page 1] Internet-Draft AR information for FMIPv6 June 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.................................................3 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 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 Jian et al. Expires December 1, 2006 [Page 2] Internet-Draft AR information for FMIPv6 June 2006 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.........................................23 Copyright Statement............................................23 Acknowledgment.................................................23 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. 2. Terminology Access Router Information Collecting Router (AR-ICR) Jian et al. Expires December 1, 2006 [Page 3] Internet-Draft AR information for FMIPv6 June 2006 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. 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 Jian et al. Expires December 1, 2006 [Page 4] Internet-Draft AR information for FMIPv6 June 2006 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 necessary, AR-ICR can ask AR to do authentication procedure. This can be indicated in acknowledgement message. Jian et al. Expires December 1, 2006 [Page 5] Internet-Draft AR information for FMIPv6 June 2006 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. The time when AR sends update message to AR-ICR are described as below: Jian et al. Expires December 1, 2006 [Page 6] Internet-Draft AR information for FMIPv6 June 2006 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 1, 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 1, 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 1, 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 1, 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 1, 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 1, 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 1, 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 1, 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 1, 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 1, 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 1, 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 1, 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 1, 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 1, 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 1, 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 1, 2006 [Page 22] Internet-Draft AR information for FMIPv6 June 2006 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. 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 1, 2006 [Page 23] Internet-Draft AR information for FMIPv6 June 2006 Jian et al. Expires December 1, 2006 [Page 24]