IP Mobility Optimizations (Mob T. Melia Opts) RG NEC Internet-Draft R. Aguiar Expires: August 19, 2005 IT February 15, 2005 Network initiated handover in fast mobile IPv6 draft-melia-mobopts-niho-fmip-00 Status of this Memo This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. 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 become aware will be disclosed, in accordance with RFC 3668. 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 August 19, 2005. Copyright Notice Copyright (C) The Internet Society (2005). Abstract Mobile IPv6 enables a Mobile Node to maintain its connectivity to the Internet when moving from an Access Router to another, a process referred to as handover. Several proposals [5] and [6] were made in order to improve the handover delay to support real-time traffic, such as Voice over IP. These proposals keep a fundamental Melia & Aguiar Expires August 19, 2005 [Page 1] Internet-Draft Network Initiated Handover in FMIPv6 February 2005 characteristic of Mobile IP, namely the handover process is triggered by the Mobile Terminal. This document expands this concept to cover situations where the handover has to be performed by network management issues, such as spectrum allocation. The document describes a control architecture based on the policy management. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 6 3.1 Building Blocks . . . . . . . . . . . . . . . . . . . . . 6 3.2 Protocol Operation . . . . . . . . . . . . . . . . . . . . 7 3.3 Mobile Terminal Initiated Handover . . . . . . . . . . . . 9 3.4 Network Initiated Handover . . . . . . . . . . . . . . . . 9 4. ICMPv6 Messages Format . . . . . . . . . . . . . . . . . . . . 10 4.1 HandoverRequest . . . . . . . . . . . . . . . . . . . . . 10 4.2 HandoverDecision . . . . . . . . . . . . . . . . . . . . . 12 4.3 HandoverAcknowledge . . . . . . . . . . . . . . . . . . . 14 4.4 FastNeighborAdvertisement . . . . . . . . . . . . . . . . 15 4.5 New Options . . . . . . . . . . . . . . . . . . . . . . . 17 4.5.1 Handover Priority Options . . . . . . . . . . . . . . 17 4.5.2 Link-Layer Address (LLA) Options . . . . . . . . . . . 17 4.5.3 IPv6 Address Options . . . . . . . . . . . . . . . . . 18 4.5.4 Handover Refused Options . . . . . . . . . . . . . . . 19 4.5.5 Candidate AR Options . . . . . . . . . . . . . . . . . 19 5. Miscellaneous . . . . . . . . . . . . . . . . . . . . . . . . 19 5.1 DAD Handling . . . . . . . . . . . . . . . . . . . . . . . 19 5.2 Determining New Care of Address . . . . . . . . . . . . . 20 5.3 Packet Loss . . . . . . . . . . . . . . . . . . . . . . . 20 6. Security Considerations . . . . . . . . . . . . . . . . . . . 21 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 8. Normative References . . . . . . . . . . . . . . . . . . . . . 21 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 22 A. Mobility Extensions to COPS . . . . . . . . . . . . . . . . . 22 Intellectual Property and Copyright Statements . . . . . . . . 29 Melia & Aguiar Expires August 19, 2005 [Page 2] Internet-Draft Network Initiated Handover in FMIPv6 February 2005 1. Introduction Current standard Mobile IPv6 provides Internet connectivity to mobile nodes roaming from one access router to another. To reduce the handover latency some extensions to standard Mobile IPv6 have been proposed and are currently in the stage to be accepted as experimental RFC. In all these approaches, handover is initiated by the mobile terminal. It is expected that radio resource usage optimization will be a task of major relevance in future wireless network environments, with millions of users roaming between access routers across multiple technologies (i.e. 802.11, 802.16...). This can resort to mechanisms and algorithms able to gather measurements and instruct an handover according to predefined mobility patterns, mechanisms for intelligent flow balancing, mechanisms for optimized resource re-allocation, mechanisms for user-traffic performance optimization, or mechanisms for user profiling (e.g. access rights). For these expectations to be realized, network control capabilities are required, including the ability to force specific terminals to perform handovers, either between access points or between different technologies. This proposal addresses the problem of how to deploy fast mobility in such an environment where the network can also impose terminal handover. Based on the Fast Mobile FMIPv6 protocol [6], we propose a new approach to globally manage mobility, supporting both existing Mobile Terminal initiated handovers (MTIHO), and new Network initiated handovers (NIHO). In both cases, handover will be managed by a control entity, performing access control and network resources optimization. Although, the protocol is independent of specific layer two technologies, cross layer integration for specific technologies can be possible. Figure 1 represents the target network architecture. In this architecture, a control entity is required. This is an usual entity in radio networks, managing spectrum resources. This unit acts as Policy Decision Point (PDP), decides on which mobile nodes should move to what location (the case of NIHO) and (eventually) and performs admission control in case of MTIHO. A MTIHO is mainly initiated because of user preferences settings (including link level signal drop) and a NIHO is initiated either because of terminal mobility or optimization reasons. Mobile Nodes (MN) are moving across (potentially heterogeneous) wireless networks. MNs are equipped with one/several network device(s) and are capable to discover surrounding wireless network Melia & Aguiar Expires August 19, 2005 [Page 3] Internet-Draft Network Initiated Handover in FMIPv6 February 2005 (via for instance CARD [2]). MN are capable to initiate an handover procedure (MTIHO) as well as to act in response to handover procedures initiated by the network. Access Routers (ARs) support different types of wireless access technologies, managed at the IP level. ARs are able to instruct the MNs about an initiated handover procedure. ARs also act as network access control points, performing as Policy Enforcement Points (PEP). Out of the scope of this document is to define how a PDP takes any decision to initiate an handover (e.g. predictive algorithms based on cross layer solutions), and how the PDP performs admission control in case of MTIHO (e.g. network access control restrictions). In Figure 1 the handover situation is represented, with both the old link and the new link connections. +------------+ +-+ old | Previous | < | | ---------- | Access | ------ > ----\ +-+ link | Router | < \ MN | (PAR) | \ | +------------+ \ | - ^ \ | | v +---------------+ | | +-----+ IP | Correspondent | | | | PDP | Network | Node | | | +-----+ +---------------+ | | ^ / | v v / V +------------+ / +-+ new | New | < / | | ---------- | Access | ------ > ----/ +-+ link | Router | < MN | (NAR) | +------------+ Figure 1: Network Architecture 2. Terminology In this document, several words are used to signify the requirements of the specification. These words are often capitalized. 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 BCP 14 [1]. This document frequently uses the following terms: Melia & Aguiar Expires August 19, 2005 [Page 4] Internet-Draft Network Initiated Handover in FMIPv6 February 2005 IPv6 The Internet Protocol Version 6. ICMPv6 The Internet Message Control Protocol for the Internet Protocol Version 6. Handover (HO) Namely the process of changing the current point of attachment to the Network. Mobile Terminal Initiated Handover (MTIHO) An HO initiated by the mobile node. Network Initiated Handover (NIHO) An HO initiated by the network. Previous Access Router (PAR) The MN's default router prior to its handover. New Access Router (NAR) The MN's anticipated default router subsequent to its handover. Old CoA (oCoA) The MN's Care of Address valid on the PAR's subnet. New CoA (nCoA) The MN's Care of Address valid on the NAR's subnet. Policy Decision Point (PDP) A logical entity that makes policy decisions for itself or for other network elements that request such decisions [7]. Policy Enforcement Point (PEP) A logical entity that enforces policy decisions [7]. In our case, the AR performs this function. This document also uses frequently the following terms, associated with protocol messages: Handover Reqest (HOReq) A protocol message, adapted from the Router Solicitation for Proxy as defined in [6]. This message indicates here simply the MN willingness to roam. Handover Decision (HODec) This is the protocol control message to handover, either in response to a HOReq, in the case of a solicited handover (MTIHO) Melia & Aguiar Expires August 19, 2005 [Page 5] Internet-Draft Network Initiated Handover in FMIPv6 February 2005 or as consequence of network spectrum optimization, in the case of a NIHO. Handover Acknowledge (HOAck) A message from the MN instructing its PAR to redirect its traffic (towards NAR), thus confirming the realization of an handover. Previously known (see [6]) as FBU. FastNeighborAdvertisement (FNA) A message from the MN to the NAR to announce attachment, and to confirm use of nCoA. 3. Protocol Overview 3.1 Building Blocks The proposed protocol uses the following functional entities: HO client and attendant, PEP and PDP. The HO client is installed on the mobile terminal. The HO client is responsible for the termination of the messages on the access network part, inside the MN. The HO attendant is installed in the AR. It implements the logic to handle the engine protocol and terminates the message on the access network part, inside the AR. A PEP is located in each AR. Logically can be implemented internally or externally to the HO attendant. The PDP is typically the control entity in the network (e.g. user access control unit, network management unit). It is the central entity in this architecture that performs admission control, in case of MTIHO, and takes decision on relocation of MN across different ARs, in the case of NIHO. This entity effective performs inter AR communication, and thus avoid superfluous direct message exchange between the PAR and the NAR. The protocol is implemented via the ICMPv6 protocol, over the last wireless/wired hop. The communication between PEP and PDP is performed via COPS messages, as defined in [8]. For this purpose extensions for mobility purposes have been proposed in Appendix A. Out of the scope of this document is to describe how the internal PEP--HO attendant communication inside the AR can be implemented. One of the functions that the PDP SHOULD implement is the Duplicate Address Detection (DAD) process. The protocol specification allows Melia & Aguiar Expires August 19, 2005 [Page 6] Internet-Draft Network Initiated Handover in FMIPv6 February 2005 the PDP to perform DAD during the HO process before admission control mechanisms take place. If the MN is suggesting a nCoA already in use, then the PDP should compute an alternative CoA to be sent to the MN. Note that any mechanism (e.g. stateless autoconfiguration, Cryptographically Generated Addresses (CGA)) could have been applied here. 3.2 Protocol Operation In the following sections, the protocol operation is described. A two level architecture, i.e. Access Routers (PEP) and PDP, is assumed. The PDP entity is integrated in the fast mobility process to allow terminal admission control and system performance optimization. In future wireless networks, the shared radio media will need to be managed and optimized: even MTIHO has to be authorized by the PDP before being able to be completed, for access authorization and network resource issues. {MN} {PAR,oPEP} PDP {NAR,nPEP} | ____ HOReq _____\ | | | | (ICMPv6) / | __HOCRequest__\| | | | (COPS) /| | | | | | | | /__HOCDecision_|__HOCDecision_\| | | \ (COPS) | (COPS) /| | /__ HODec________ | | | | \ (ICMPv6) | | | | | | | | ____ HOAck _____\ | __HOCReport___\| | | (ICMPv6) / | (COPS) /| | | | | | ==== L2 ===== | | | reassociation | | | |__________________________FNA _____________________\| | /| | | |/__HOCReport___| | | |\ (COPS) | | | /__HOCDecision_| | | | \ (COPS) | | | | __HOCReport___\| | | | /| | Figure 2: Signalling Flow In Figure 2 an overview of the signalling scheme is presented. The protocol operation involve MNs (implementing an HO client), ARs Melia & Aguiar Expires August 19, 2005 [Page 7] Internet-Draft Network Initiated Handover in FMIPv6 February 2005 (implementing an HO attendant and a PEP) and the PDP. The protocol provides an homogeneous way to manage mobile terminal initiated handover (MTIHO) and network initiated handover (NIHO). HandoverRequest (HOReq)- only used in MTIHO This message initiates a MTIHO. The datagram is sent to the current AR (oAR) containing a list, ordered by preference, up to 3 possible candidate ARs. This message has a flag indicating if the HO is imminent. This flag should be set if the MN is requesting the HO by loss of signal reasons. The handover might be initiated because of mobility reasons (loss of signal) or as a consequence of user preferences. HandoverDecision (HODec) This message contains the candidate access router to which the MN should handover to. This indication could be solicited (e.g. reply to an HoReq in case of MTIHO) or unsolicited, in case of NIHO. HandoverAcknowledge (HOAck) By means of this datagram the MN could either accept to change its point of attachment or reject/sustain the undergoing handover. It is realistic to assume that between the HOReq and the HOAck messages the MN, due to mobility specific patterns, might not have access to the target AP specified in the HODec. In this case the MN COULD stop the handover process by means of a specific flag. However, the usage of this option SHOULD then be followed by a MTIHO. FastNeighborAdvertisement (FNA) After changing his physical connection the mobile terminal has to advertise his presence on the new link in order to populate the nAR's IPv6 neighbour cache. This step is important for packet delivery. COPS HOCRequest In order to request a handover admission the PEP in oAR sends the list of candidate access routers to the PDP for validation. COPS HOCDecision By means of this message the PDP can advertise the handover candidate access router or indicate to the HO attendant in the oAR the conclusion of a successful HO. COPS HOCReport This message is used for reporting purposes. Melia & Aguiar Expires August 19, 2005 [Page 8] Internet-Draft Network Initiated Handover in FMIPv6 February 2005 3.3 Mobile Terminal Initiated Handover When a Mobile Terminal (MT) initiates a MTIHO, the HO client sends a HOReq message to its current AR containing a list, ordered by preference, of up to three possible candidate ARs that is able to access, and the associated nCoA requested for each one of these sub-networks. The AR (via the PEP component) forwards the request for approval to the PDP. Upon receiving this message, the PDP verifies the request and answers according to its internal rules, preferentially with the first occurrence of the list. The PDP sends a HOCDecision (COPS) message to both the nAR (unsolicited policy message) and the oAR (current AR). The oAR processes the message, and informs the MN that it can now move to the network provided in the message HODec (ICMPv6). As soon as the HO client receives a HODec it sends a HOAck (ICMPv6) message to the oAR, and performs the (link layer) disconnection from the current link and attachment to the new one. Note that the MT may stop the handover when it receives the HODec message, sending a HOAck (ICMPv6) message with code 1. When connected to the new link, the MN MUST send a FNA message to the nAR; by means of this message the IPv6 neighbour cache is updated. The nAR after receiving this message informs the PDP that the MT is attached on the new link, and therefore this indication is then forwarded to the oAR in order to conclude the successful handover. The process is finalized with a confirmation Report, HOCReport (COPS), from the oAR. To better support real time applications, layer two latency should be optimized. Furthermore, flow duplication techniques at IP level SHOULD be considered. Intelligent duplication mechanisms would allow data to be bicasted, during the HO duration, to the old CoA and the new CoA. In the MN side the only operation required is the reordering of the duplicated packets that has to be processed in an application-independent way. 3.4 Network Initiated Handover When the network initiates a NIHO the procedure is similar to the one described in Section 3.3, with a single exception. The mobile terminal does not send any HOReq (ICMPv6) message and the datagram HODec (ICMPv6) contains a flag indicating that this is a Network Initiated Handover and the AR to where the MN has to move. The remaining process is exactly the same. A MT may send an HOAck (ICMPv6) with code 1 to stop the Handover procedure; this must only be used if the AR that the PDP is targeting is no longer available to Melia & Aguiar Expires August 19, 2005 [Page 9] Internet-Draft Network Initiated Handover in FMIPv6 February 2005 the MN. In this case the MT must send a HOReq (ICMPv6) immediately afterwards. The policies taken by the PDP in case the MT rejects the HODec (ICMPv6) are outside the scope of this document. 4. ICMPv6 Messages Format All the ICMPv6 messages have a common Type specified in [3]. The messages are distinguished based on the subtype field. In section Section 7 the Subtypes are specified. For all the ICMPv6 messages the checksum is defined as in [4]. 4.1 HandoverRequest The HandoverRequest message is sent by Mobile Nodes willing to roam to another access router. Mobile Nodes will be expecting an HandoverDecision. 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Subtype | Reserved | HOSessionID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Options ... +-+-+-+-+-+-+-+-+-+-+-+-+- Figure 3: HandoverRequest (HOReq) message IP Fields: Source Address IP address of the sending interface Destination Address IP address of the Access Router Hop Limit 1 Authentication Header If a Security Association is established between the Mobile Node and the Access Router the sender SHOULD include this header. ICMP Fields: Melia & Aguiar Expires August 19, 2005 [Page 10] Internet-Draft Network Initiated Handover in FMIPv6 February 2005 Type The Experimental Mobility protocol Type Code 0 Intra-Domain HO (default) 1 Inter-Domain HO Checksum The ICMPv6 Checksum Subtype See section Section 7. Reserved MUST be set to zero from the sender and ignored by the receiver. HOsessionID This field has a first bit equal to 0 in this message. The HO_client MUST also compute a 15 bit number for the leftover bits, in order to identify the ongoing handover. This is an useful countermeasure to solve race conditions in case both MTIHO and NIHO are issued for the same target Mobile Node. Furthermore, this number SHOULD be incremental, in order for the network to have an idea of how often the MT performs HOs. Valid Options: Handover Priority Option Indicates the priority of the Handover with increasing values. Link Layer Address Option This indicates the source link layer of the sender. IPv6 Address Option (HomeAddress) This indicated the home address of the mobile node, helping to identify the MT. Candidate AR Option This option MUST be included indicating the number of candidate access routers the terminal is asking for validation. The PEP in the PAR is in charge of forwarding this request to the PDP. According to the number of identified candidate ARs this option will contain, up to a maximum of three tuples. Each tuple contains a LLA field (Candidate LLA1) for the access interface of the AP belonging to the NAR, a IPv6 Address field (Candidate AR Melia & Aguiar Expires August 19, 2005 [Page 11] Internet-Draft Network Initiated Handover in FMIPv6 February 2005 IPv6 1) for the NAR IPv6 address, and a second IPv6 Address field(Candidate nCoA 1) containing a precomputed nCoA. If this field is filled with 0s, the MT is requesting a nCoA from the PDP. The tuple {LLA, NAR IPv6 addr, nCoA} is intended to avoid any lengthy discovery phase during an HO process. Already existing mechanisms SHOULD be used (see [2]) to perform address resolution starting from the layer two identifier. The HOReq message could be set to be Imminent or Not-Imminent. For instance, if the MN triggers a MTIHO because of mobility reasons, the loss of connection could be imminent. In that case the network should consider this handover as high priority and should wait the current HO to be concluded before issuing any NIHO for the same target mobile node. This mechanism SHOULD be implemented to avoid unuseful handshakes and wastage of bandwidth. 4.2 HandoverDecision The HandoverDecision is sent to mobile nodes either in response to a HOReq (MTIHO), or as an unsolicited message (NIHO). 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Subtype | Reserved | HOSessionID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Options ... +-+-+-+-+-+-+-+-+-+-+-+-+- Figure 4: HandoverDecision (HODec) message IP Fields: Source Address IP address of the sending interface. Destination Address IP address of the Access Router. Hop Limit 1 Melia & Aguiar Expires August 19, 2005 [Page 12] Internet-Draft Network Initiated Handover in FMIPv6 February 2005 Authentication Header If a Security Association is established between the Mobile Node and the Access Router the sender SHOULD include this header. ICMP Fields: Type The Experimental Mobility protocol Type Code 0 Network Initiated HO 1 Mobile Terminal Initiated HO 2 Handover Refused Checksum The ICMPv6 Checksum. Subtype See section Section 7. Reserved MUST be set to zero from the sender and ignored by the receiver. HOsessionID If the message is a response to a MTIHO, it contains the same HOSessionID of the HOReq message. If this message is the first message in a NIHO, then this field has a first bit equal to 1. The HO_attendant MUST fill the left bits with a 15 bits number, to identify the ongoing handover. Furthermore, this number SHOULD be incremental. Valid Options: Link Layer Address Option This indicates the source link layer of the sender. Handover Refused Option Indicates whether the HO can be performed or not. This option is valid only in case of MTIHO. Candidate AR Option This option is included in both MTIHO and NIHO. The tuple included is only one. It cannot be combined with an Handover Melia & Aguiar Expires August 19, 2005 [Page 13] Internet-Draft Network Initiated Handover in FMIPv6 February 2005 Refused Option. This option is useful to help the DAD mechanisms implemented in the PDP. In fact in case the nCoA provided in the HOReq message cannot be used in the new AR subnet the PDP MUST compute an alternative CoA and provide the MN with this fresh information. If the message is sent to initiate a NIHO the mobile node SHOULD obey to the network. The only situation when the mobile node may refuse the HO is because it cannot see the AR selected by the network, because of his own movement. After rejecting this HO, the MT has to start a MTIHO. 4.3 HandoverAcknowledge The HandoverAcknowledge is sent from a mobile node to the PAR to confirm the undergoing handover will take place. In case of MTIHO the mobile node can still reject the handover mainly because of the mobility pattern. In case of NIHO the mobile node can reject the handover because the network is targeting an AP not "visible" form a mobile node point of view. 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Subtype | Reserved | HOSessionID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Options ... +-+-+-+-+-+-+-+-+-+-+-+-+- Figure 5: HandoverAcknowledge (HOAck) message IP Fields: Source Address IP address of the sending interface Destination Address IP address of the Access Router Hop Limit 1 Melia & Aguiar Expires August 19, 2005 [Page 14] Internet-Draft Network Initiated Handover in FMIPv6 February 2005 Authentication Header If a Security Association is established between the Mobile Node and the Access Router the sender SHOULD include this header. ICMP Fields: Type The Experimental Mobility protocol Type Code 0 Handover Performed 1 Handover Sustained Checksum The ICMPv6 Checksum Subtype See section Section 7. Reserved MUST be set to zero from the sender and ignored by the receiver. HOsessionID This field should have the same value of the corresponding field of the HODec message referred to by this HOAck. Valid Options: No options MUST be included. The CODE field in the ICMPv6 header indicates if the HO is performed or not. No extra options are here required. 4.4 FastNeighborAdvertisement A MN sends a Fast Neighbor Advertisement to announce itself to the NAR. Melia & Aguiar Expires August 19, 2005 [Page 15] Internet-Draft Network Initiated Handover in FMIPv6 February 2005 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . Mobility Options . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 6: Fast Neighbor Advertisement (FNA) Message IP fields: Souce Address The nCoA. Destination Address The NAR's IP address. Mobility Options The message MUST contain the Mobility Header Link-Layer Address of the MN in MH-LLA option format (see Figure 7.) The MN sends Fast Neighbor Advertisement to the NAR, as soon as it regains connectivity on the new link. Arriving packets can be immediately forwarded. If there is no entry at all, it creates one and sets it to REACHABLE. If there is an entry in INCOMPLETE state without a link-layer address, it sets it to REACHABLE. The combination of NCoA (present in source IP address) and the Link-Layer Address (present as a Mobility Option) SHOULD be used to distinguish the MN from other nodes. 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Option-Code | Pad0=0 | LLA | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LLA | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 7: Mobility Header Link-Layer Address Option The size of this option in octets not including the Type, Length and Option-Code fields. Melia & Aguiar Expires August 19, 2005 [Page 16] Internet-Draft Network Initiated Handover in FMIPv6 February 2005 Option-Code: 2 Link-layer Address of the MN. LLA: The variable length link-layer address. 4.5 New Options All the options are specified according to the format in Figure 8. The type values are defined from the Neighbor Discovery options space. The Length field is in units of 8 octets. The Option Code provides additional 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 | Length | Option-Code | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ .. .. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 8: Option Format 4.5.1 Handover Priority Options Handover Priority 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 | Option-Code | Priority | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 9: Handover Priority Option Type: To be Assigned by IANA Option-Code: 0 Priority: 0 Regular 1 Imminent 4.5.2 Link-Layer Address (LLA) Options Link-Layer Address (LLA) Option: Melia & Aguiar Expires August 19, 2005 [Page 17] Internet-Draft Network Initiated Handover in FMIPv6 February 2005 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 | Option-Code | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Link Layer Address + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 11: LLA Option Type: To be Assigned by IANA Option-Code: 0 MT LLA 1 AP LLA 4.5.3 IPv6 Address Options IPv6 Address 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 | Option-Code | Prefix Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + IPv6 Address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 13: IPv6 Option Type: To be Assigned by IANA Option-Code: 0 Home Address 1 New Care Of Address 2 Old Care Of Address 3 New AR Address Melia & Aguiar Expires August 19, 2005 [Page 18] Internet-Draft Network Initiated Handover in FMIPv6 February 2005 4.5.4 Handover Refused Options Handover Refused 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 | Option-Code | Reason | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 15: HO Refused Option Type: To be Assigned by IANA Option-Code: 0 Reason: 0 Not Available 1 QoS Reasons 2 A4C Reasons 3 Unknown Reason 4.5.5 Candidate AR Options Candidate AR 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 | Option-Code | Candidate Nr | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1 LLA Option + 2 IPv6 Address Options...... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 17: Candidate AR Option Type: To be Assigned by IANA Option-Code: 0 Candidate Nr: Number of LLA+2xIPv6 for Candidate ARs 5. Miscellaneous 5.1 DAD Handling Duplicate Address Detection (DAD) was defined in [9] to avoid address duplication on links when stateless address auto-configuration is used, and is a source of extra delay in an handover. Melia & Aguiar Expires August 19, 2005 [Page 19] Internet-Draft Network Initiated Handover in FMIPv6 February 2005 The probability of a identifier duplication on the same AR cannot be ignored. In this draft, the PDP takes the responsibility for DAD process. Note that in many cases, the PDP may already have the knowledge required to assess whether the expectable MN's CoA request will be a duplicate or not, even before the MN tries to move to the new subnet. The PDP can have a list of all nodes on its controlled PEPs (ARs), and by periodically searching this list, and evaluating potential nCoA created by stateless autoconfiguration, can detect danger of potential MN address duplication or not. For these potential conflicting addresses, the PDP can prepare alternative CoA before the HOReq message appears (even if this potential conflict may eventually never appear). This reduces the DAD time to a process performed decoupled from the HO. Note that for non-imminent HOReq messages, DAD can be performed during the handover process. 5.2 Determining New Care of Address Typically, the MN formulates its prospective nCoAs using the information provided by discovering its surrounding wireless networks (via for instance CARD [2], or by router advertisements received). The PDP should use this prospective nCoA in the HODec message, unless it detects a potential DAD situation. In this case it provides a new nCoA in the HODec message. The MT must always use the nCoA indicate in the HODec message. 5.3 Packet Loss Two problems exist associated with packet loss. The loss of one of the fast-handover messages and the loss of packets during the handover process. For the loss of control messages, timing mechanisms should be in place both in the MT, in the AR and in the PDP, per HOSession. These timers will reissue ONCE a message if no corresponding answer is received before the timeout. For the loss of data packets, the link switching required during handover may not be synchronous with the handover signalling and packet transmission. Thus packets may arrive at NAR before the MN is able to establish its link there, or arrive to the OAR when the link does not exist anymore. These packets will be lost unless they are buffered by the NAR. The protocol considers the use of bicasting from the PAR to the NAR in order to minimize this situation. No buffering is considered in order to simplify protocol operation in very large networks. Melia & Aguiar Expires August 19, 2005 [Page 20] Internet-Draft Network Initiated Handover in FMIPv6 February 2005 6. Security Considerations Security SA previous HO -- It is likely that MNs have to get authenticated and authorized previous to any handover. During this process a security association with the serving AR will be established to protect the ongoing communications. During the handover the transfer of such keying material from the PAR to the NAR ensures only already authenticated nodes can roam within the same administrative domain. It is out of the scope of this document to define how those mechanisms should be in place, however the handover latency interaction between the proposed approach and existing security mechanisms SHOULD be optmized. 7. IANA Considerations This document defines three new experimental messages which use the Experimental Mobility Protocol format. These require three new Subtype value assignments of the Experimental Mobility Protocol Subtype Registry as follow: Subtype Description Reference ------- ----------- --------- 2 HOReq Section 4.1 3 HODec Section 4.2 4 HOAck Section 4.3 8. Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] Liebsch, M., "Candidate Access Router Discovery", Internet-Draft draft-ietf-seamoby-card-protocol-08, September 2004. [3] Kempf, J., "Instructions for Seamoby Experimental Protocol IANA Allocations", Internet-Draft draft-ietf-seamoby-iana-02, June 2004. [4] Conta, A. and S. Deering, "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", RFC 2463, December 1998. [5] Soliman, H., Castelluccia, C., Malki, K. and L. Bellier, "Hierarchical MIPv6 mobility management (HMIPv6)", Internet-Draft draft-ietf-mobileip-hmipv6-06, July 2002. Melia & Aguiar Expires August 19, 2005 [Page 21] Internet-Draft Network Initiated Handover in FMIPv6 February 2005 [6] Koodli, R., "Fast Handovers for Mobile IPv6", Internet-Draft draft-ietf-mipshop-fast-mipv6-03, October 2004. [7] Yavatkar, R., Pendarakis, D. and R. Guerin, "A Framework for Policy-based Admission Control", RFC 2753, January 2000. [8] Durham, D., Boyle, J., Cohen, R., Herzog, S., Rajan, R. and A. Sastry, "The COPS (Common Open Policy Service) Protocol", RFC 2748, January 2000. [9] Thomson, S. and T. Narten, "IPv6 Stateless Address Autoconfiguration", RFC 2462, December 1998. Authors' Addresses Telemaco Melia NEC Europe Network Laboratories Kufuerstenanlage 36 Heidelberg 69115 Germany Phone: +49 6221 90511 42 Email: telemaco.melia@netlab.nec.de Rui L.A. Aguiar Instituto de Telecomunicacoes Universidade de Aveiro Aveiro 3810 Portugal Phone: +351 234 377900 Email: ruilaa@det.ua.pt Appendix A. Mobility Extensions to COPS Here are described the extensions proposed to handle the mobility options. Common Header Melia & Aguiar Expires August 19, 2005 [Page 22] Internet-Draft Network Initiated Handover in FMIPv6 February 2005 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 | Op Code | Client-type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Version: 1 Flags: 0x01 (HO Request, MTIHO Decision, HO Report) 0x00 (NIHO Decision) Op. Code: 1 (HO Request) 2 (HO Decision) 3 (HO Report) Client-type: To be defined Message Length: done internally Client Handle 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length (octets) | C-Num | C-Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Cops Handler | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ C-Num: 1 C-Type: 1 Cops Handler: Context Melia & Aguiar Expires August 19, 2005 [Page 23] Internet-Draft Network Initiated Handover in FMIPv6 February 2005 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length (octets) | C-Num | C-Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | R-Type | M-Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ C-Num: 2 C-Type: 1 R-Type: 0x01 Incoming Message / Admission Control M-Type: 0x01 Mobile Terminal Initated Handover 0x02 Network Initiated Handover Decision: Flags 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length (octets) | C-Num | C-Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Command-Code | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ C-Num: 6 C-Type: 1 Command-Code: 0 No decision 1 Request Accepted 2 Request Denied Flags: 0 Report-Type Melia & Aguiar Expires August 19, 2005 [Page 24] Internet-Draft Network Initiated Handover in FMIPv6 February 2005 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length (octets) | C-Num | C-Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Report-Type | //////////////////// | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ C-Num: 12 C-Type: 1 Report-Type: 1 Success 2 Failure ClientSI Data -- ClientSI Message Header 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length (octets) | C-Num | C-Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ C-Num: 9 C-Type: 1 Fast HO ID Melia & Aguiar Expires August 19, 2005 [Page 25] Internet-Draft Network Initiated Handover in FMIPv6 February 2005 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length (octets) | D-Num | D-Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | HOSessionID | Priority | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Home Address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Home Address Prefix Length | Prefix Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + IPv6 Address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ D-Num: 9 D-Type: 1 HOSessionID: Session Identifier Priority: Handover Priority Home Address: Home Address Home Address: Prefix Length: Home Address IPv6 Prefix Length Prefix Length: IPv6 prefix length IPv6 Address: MT Care of Address Fast HO Candidate AR Object Melia & Aguiar Expires August 19, 2005 [Page 26] Internet-Draft Network Initiated Handover in FMIPv6 February 2005 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length (octets) | D-Num | D-Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + AP Link Layer Address + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + AR Address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AR Prefix Length | MT CoA Prefix Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + MT CoA + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ D-Num: 10 D-Type: 1 AP Link Layer Address: new AP Link Layer Address AR Prefix Length: IPv6 prefix length AR Address: new AR IPv6 Address MT CoA Prefix Length: IPv6 prefix length MT CoA: new MT Care of Address Fast HO Status Object Melia & Aguiar Expires August 19, 2005 [Page 27] Internet-Draft Network Initiated Handover in FMIPv6 February 2005 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length (octets) | D-Num | D-Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | HOSessionID | Status | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ D-Num: 11 D-Type: 1 (Handover Decision) 2 (Handover Status Decision) HOSessionID: Session Identifier Status: 0x00 (Handover Decision) Handover not performed 0x01 (Handover Decision) Handover performed 0x02 (Handover Status Decision) Handover Timed out 0x03 (Handover Status Decision) Handover performed Fast HO Accepted AR Object 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length (octets) | D-Num | D-Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ///////////////// | AR | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ D-Num: 12 D-Type: 1 AR: 0, 1 or 2 corresponding to the 1st, 2nd or 3rd match Melia & Aguiar Expires August 19, 2005 [Page 28] Internet-Draft Network Initiated Handover in FMIPv6 February 2005 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 (2005). 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. Melia & Aguiar Expires August 19, 2005 [Page 29]