IRTF MobOpts RG K. Mitani Internet-Draft R. Shibui Expires: August 22, 2005 K. Gogo F. Teraoka KEIO University February 21, 2005 Unified L2 Abstractions for L3-Driven Fast Handover draft-koki-mobopts-l2-abstractions-02.txt 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 22, 2005. Copyright Notice Copyright (C) The Internet Society (2005). Abstract This draft proposes unified L2 abstractions for L3-driven fast handover. For efficient network communication, it is vital for a protocol layer to know or utilize other layer's information such as L2 triggers. However, in current operating systems, each protocol layer is designed independently and information exchange between Mitani, et al. Expires August 22, 2005 [Page 1] Internet-Draft L2 Abstractions February 2005 protocol layers is not allowed. To solve the problem, this draft defines nine kinds of L2 abstractions in the form of "Primitive". This concept can be applied to L3-driven fast handover mechanism using "Primitives". Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Primitives for L2 Abstractions . . . . . . . . . . . . . . . . 6 4. Definitions of Primitives . . . . . . . . . . . . . . . . . . 7 4.1 L2-LinkStatus (Type 1) . . . . . . . . . . . . . . . . . . 7 4.2 L2-PeerList (Type 1) . . . . . . . . . . . . . . . . . . . 7 4.3 L2-PeerFound (Type 2) . . . . . . . . . . . . . . . . . . 7 4.4 L2-PeerLost (Type 2) . . . . . . . . . . . . . . . . . . . 7 4.5 L2-LinkUp (Type 2) . . . . . . . . . . . . . . . . . . . . 8 4.6 L2-LinkDown (Type 2) . . . . . . . . . . . . . . . . . . . 8 4.7 L2-LinkToBeDown (Type 2) . . . . . . . . . . . . . . . . . 8 4.8 L2-LinkConnect (Type 3) . . . . . . . . . . . . . . . . . 8 4.9 L2-LinkDisconnect (Type 3) . . . . . . . . . . . . . . . . 8 5. Definitions of Static Parameters . . . . . . . . . . . . . . . 9 5.1 Network Interface ID . . . . . . . . . . . . . . . . . . . 9 6. Definitions of Dynamic Parameters . . . . . . . . . . . . . . 10 6.1 Peer . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 6.2 Condition . . . . . . . . . . . . . . . . . . . . . . . . 10 6.3 Peer List . . . . . . . . . . . . . . . . . . . . . . . . 10 6.4 Enable/Disable . . . . . . . . . . . . . . . . . . . . . . 10 6.5 Ack/Error . . . . . . . . . . . . . . . . . . . . . . . . 10 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 11 A. Example Scenario . . . . . . . . . . . . . . . . . . . . . . . 13 B. Example Operation for FMIPv6 . . . . . . . . . . . . . . . . . 15 C. Example Mapping of Primitives and IEEE802.11 . . . . . . . . . 17 C.1 L2-LinkStatus . . . . . . . . . . . . . . . . . . . . . . 17 C.2 L2-PeerList . . . . . . . . . . . . . . . . . . . . . . . 17 C.3 L2-PeerFound . . . . . . . . . . . . . . . . . . . . . . . 17 Mitani, et al. Expires August 22, 2005 [Page 2] Internet-Draft L2 Abstractions February 2005 C.4 L2-PeerLost . . . . . . . . . . . . . . . . . . . . . . . 17 C.5 L2-LinkUp . . . . . . . . . . . . . . . . . . . . . . . . 18 C.6 L2-LinkDown . . . . . . . . . . . . . . . . . . . . . . . 18 C.7 L2-LinkToBeDown . . . . . . . . . . . . . . . . . . . . . 18 C.8 L2-LinkConnect . . . . . . . . . . . . . . . . . . . . . . 18 C.9 L2-LinkDisconnect . . . . . . . . . . . . . . . . . . . . 18 Intellectual Property and Copyright Statements . . . . . . . . 19 Mitani, et al. Expires August 22, 2005 [Page 3] Internet-Draft L2 Abstractions February 2005 1. Introduction In recent years, the environment around computers is not static and changes dynamically. Especially, when a mobile node moves to a different network, its environment considerably changes. For example, in the case of wireless communication, parameters such as radio strength changes widely depends on time or site. For efficient network communication, it is vital for a protocol layer to know or utilize other layer's information. There are several proposals for seamless handovers in IPv6 network such as Fast Handovers for Mobile IPv6 (FMIPv6) [1] and Hierarchical Mobile IPv6 (HMIPv6) [2]. In FMIPv6, the network layer must know the indication of a handover from the link layer in advance to achieve seamless handovers. However, each protocol layer is designed independently and information exchange between protocol layers is not allowed. For further handover enhancements, this document defines nine kinds of L2 triggers in the form of "Primitive". This concept can be applied to L3-driven fast handover mechanism using "Primitives". Mitani, et al. Expires August 22, 2005 [Page 4] Internet-Draft L2 Abstractions February 2005 2. Terminology This document uses the following terms. L3-Driven Fast Handover The handover which is initiated by the network layer on a mobile node. Since it allows L3 handover preparation during communication, it can reduce packet loss during handover. L3-driven fast handover mechanism requires L2 information as a trigger of handover procedure. Peer The attachment point of a mobile node. (e.g., An access point in IEEE 802.11 networks.) Primitive A unit of information which is sent from one layer to another. There are four classes of primitives: Request, Confirm, Indication and Response. Mitani, et al. Expires August 22, 2005 [Page 5] Internet-Draft L2 Abstractions February 2005 3. Primitives for L2 Abstractions Each layer offers its services by the form of primitives. There are four classes of primitives as shown in Figure 1: Request, Confirm, Indication, and Response. The request is issued by the layer that wants to get services or information from another layer, and the confirm is the acknowledgment of the request. The indication is a notification of information to the layer that requested the service, and the response is the acknowledgment of the indication. In this architecture, each layer can communicate evenly. ------------------------------------------------------ Request Response || /\ /\ || Layer N || || || || ------------||------||----------||------||------------ || || || || \/ || || \/ Layer N-m Confirm Indication ------------------------------------------------------ Figure 1: Primitives The primitive consists of five fields: the protocol layer id to which this primitive should be sent, the protocol id to which protocol entity this primitive should be sent, the primitive class (i.e., request, confirm, indication, or response), the primitive name, and parameters. There are three different usages of "Primitives": Type 1. To provide L2 information to upper layers immediately A "Request" primitive is an acquisition request for L2 informaiton. As a "Confirm" primitive, L2 information returns immediately. Type 2. To notify upper layers of L2 events asynchronously "Request" and "Confirm" primitives are used just for registration. When an event occurs, an "Indication" primitive is asynchronously delivered to an upper layer. Type 3. To control L2 actions from upper layers Mitani, et al. Expires August 22, 2005 [Page 6] Internet-Draft L2 Abstractions February 2005 A "Request" primitive is a request for operation. Ack or nack returns immediately as a "Confirm" primitive. Mitani, et al. Expires August 22, 2005 [Page 7] Internet-Draft L2 Abstractions February 2005 4. Definitions of Primitives In order to obtain and change L2 information, some sorts of Primitives described below are necessary. The following Primitives are defined. 4.1 L2-LinkStatus (Type 1) The L2-LinkStatus.request is sent to the link layer when an upper layer needs the current information of a link. The L2-LinkStatus.request primitive contains "Network Interface ID" parameter. In response, the L2-LinkStatus.confirm returns. The L2-LinkStatus.confirm primitive contains three parameters: "Network Interface ID", "Peer" and "Condition". "Peer" and "Condition" indicate the current status about the link between a mobile node and a peer. 4.2 L2-PeerList (Type 1) The L2-PeerList.request is sent to the link layer when an upper layer needs a list of candidate peers. The L2-PeerList.request primitive contains "Network Interface ID" parameter. In response, the L2-PeerList.confirm returns with "Network Interface ID" parameter and "Peer List" parameter. "Peer List" parameter is the list of candidate peers. 4.3 L2-PeerFound (Type 2) The L2-PeerFound.indication is asynchronously provided to an upper layer when new peers are detected. This primitive carries "Network Interface ID" parameter and "Peer List" parameter. "Peer List" parameter contains the information of new peers detected by a mobile node. In order to use this notification, the registration process using L2-PeerFound.request and L2-PeerFound.confirm is needed in advance. The L2-PeerFound.request primitive has two parameters: "Network Interface ID" and "Enable/Disable". "Enable/Disable" parameter shows whether this notification function is turned on. When this registration succeeds, the L2-PeerFound.confirm returns with "Network Interface ID" parameter and "Ack" parameter in response. 4.4 L2-PeerLost (Type 2) The L2-PeerLost.indication is asynchronously provided to an upper layer when a peer included in the list of candidate peers is got lost. This primitive carries "Network Interface ID" parameter and "Peer List" parameter. "Peer List" parameter contains the information of the peers which disappeared from the candidates list. Mitani, et al. Expires August 22, 2005 [Page 8] Internet-Draft L2 Abstractions February 2005 The registration process using the L2-PeerLost.request and the L2-PeerLost.confirm is similar to the L2-PeerFound above. 4.5 L2-LinkUp (Type 2) The L2-LinkUp.indication is asynchronously provided to an upper layer when a new link is connected. This primitive carries "Network Interface ID" parameter and "Peer" parameter. The L2-LinkUp.request contains "Network Interface ID" parameter and "Enable/Disable" parameter for registration. When the registration succeeds, the L2-LinkUp.confirm with "Network Interface ID" parameter and "Ack" parameter returns. 4.6 L2-LinkDown (Type 2) The L2-LinkDown.indication is asynchronously provided to an upper layer when an existing link is disconnected. The registration processing is same as the L2-LinkUp above. 4.7 L2-LinkToBeDown (Type 2) The L2-LinkToBeDown.indication is asynchronously provided to an upper layer when an existing link is to be disconnected. This notification contains two parameters: "Network Interface ID" and "Peer". "Peer" parameter is the attachment point at which the link quality is degrading. In the registration processing, the L2-LinkToBeDown.request carries "Network Interface ID" parameter and "Enable/Disable" parameter. 4.8 L2-LinkConnect (Type 3) The L2-LinkConnect.request is sent to the link layer when an upper layer has to change or create a new link to the specific "Peer". This primitive carries "Network Interface ID" parameter and "Peer" parameter. This operation begins after sending L2-LinkConnect.confirm with "Ack" by the link layer. 4.9 L2-LinkDisconnect (Type 3) The L2-LinkDisconnect.request is sent to the link layer when an upper layer has to destroy an existing link to the specific "Peer". This primitive carries "Network Interface ID" parameter and "Peer" parameter. This operation begins after sending L2-LinkConnect.confirm with "Ack" by the link layer. Mitani, et al. Expires August 22, 2005 [Page 9] Internet-Draft L2 Abstractions February 2005 5. Definitions of Static Parameters This section lists static parameters. Once the values of static parameters are configured, they do not change frequently during communication. The following parameters are transferred as a part of primitives. 5.1 Network Interface ID "Network interface ID" parameter identifies uniquely the network interface in a node. The identifier is an implementation-specific consideration (e.g., name, index or unique address assigned to each interface). This parameter also contains the network interface type which indicates the kind of technology of the network interface (e.g., IEEE802.11a/b/g, 3GPP, etc.). This parameter is required for all the primitives. Mitani, et al. Expires August 22, 2005 [Page 10] Internet-Draft L2 Abstractions February 2005 6. Definitions of Dynamic Parameters This section lists dynamic parameters. The values of dynamic parameters change frequently during communication. The following parameters are transferred as a part of primitives. 6.1 Peer "Peer" parameter uniquely identifies the peer. 6.2 Condition "Condition" parameter consists of the following sub-parameters: available bandwidth and link quality level. These sub-parameters are the abstracted information for considering current quality-of service. The abstraction algorithms of sub-parameters depend on hardware device and software implementation. The useful range of link quality level is from one to five; VERY GOOD, GOOD, FAIR, BAD, VERY BAD. Each GOOD and BAD level is calcurated as a high or low watermark. 6.3 Peer List "Peer List" parameter consists of arbitrary couples of two sub-parameters: "Peer" and "Condition". This parameter shows a list of peers and its condition. 6.4 Enable/Disable "Enable/Disable" flag is used for turning event notification on/off. When an upper layer needs notifications, the "Request" primitive with "Enable" is sent to the link layer as registration. When an upper layer needs no more notifications, the "Request" primitive with "Disable" is sent. 6.5 Ack/Error When an upper layer requests some notifications, the link layer receives and confirms this "Request". If the "Request" is valid, the "Confirm" primitive with "Ack" is sent. And if it is invalid, the "Confirm" with "Error" is sent to the upper layer. Mitani, et al. Expires August 22, 2005 [Page 11] Internet-Draft L2 Abstractions February 2005 7. Security Considerations It is recommended that the implementers consider the security features to manage the L2 information. 8 References [1] Koodli, R., Dommety, G., Malki, K., Khalil, M., Perkins, C., Soliman, H., Tsirtsis, G. and A. Yegin, "Fast Handovers for Mobile IPv6", draft-ietf-mipshop-fast-mipv6-03 (work in progress), October 2004. [2] Soliman, H., Castelluccia, C., Malki, K. and L. Bellier, "Hierarchical Mobile IPv6 mobility management (HMIPv6)", draft-ietf-mipshop-hmipv6-02 (work in progress), June 2004. Authors' Addresses Koki Mitani Graduate School of Science and Technology, KEIO University 3-14-1 Hiyoshi, Kohoku-ku Yokohama, Kanagawa 223-8522 Japan Phone: +81-45-566-1425 EMail: koki@tera.ics.keio.ac.jp URI: http://www.tera.ics.keio.ac.jp/ Rie Shibui Graduate School of Science and Technology, KEIO University 3-14-1 Hiyoshi, Kohoku-ku Yokohama, Kanagawa 223-8522 Japan Phone: +81-45-566-1425 EMail: shibrie@tera.ics.keio.ac.jp URI: http://www.tera.ics.keio.ac.jp/ Mitani, et al. Expires August 22, 2005 [Page 12] Internet-Draft L2 Abstractions February 2005 Kazutaka Gogo Faculty of Science and Technology, KEIO University 3-14-1 Hiyoshi, Kohoku-ku Yokohama, Kanagawa 223-8522 Japan Phone: +81-45-566-1425 EMail: gogo@tera.ics.keio.ac.jp URI: http://www.tera.ics.keio.ac.jp/ Fumio Teraoka Graduate School of Science and Technology, KEIO University 3-14-1 Hiyoshi, Kohoku-ku Yokohama, Kanagawa 223-8522 Japan Phone: +81-45-566-1425 EMail: tera@ics.keio.ac.jp URI: http://www.tera.ics.keio.ac.jp/ Mitani, et al. Expires August 22, 2005 [Page 13] Internet-Draft L2 Abstractions February 2005 Appendix A. Example Scenario For example, the picture below shows L3-driven fast handover mechanism using the L2 triggers on MN. L2 L3 | | Low | Signal-----LinkToBeDown.ind------->| | | | Handover AP<---------PeerList.req------Preparation Scan---------PeerList.cnf--------->| | | |<-------LinkConnect.req----L3 Handover L2 Handover--LinkConnect.cnf-------->: : : : : finish---------LinkUp.ind---------->: | : | finish | | L2: Link Layer on MN L3: Network Layer on MN req: Request cnf: Confirm ind: Indication Figure 2: L3-Driven Fast Handover Mechanism In the beginning of the L3-driven handover procedure, L2 detects radio signal strength is going down. Then L2 sends L2-LinkToBeDown.indication to L3. L3 prepares for handover (e.g., CoA generation, DAD, ND cache creation, and routing table setting) and sends L2-PeerList.request to L2 if the list of access points is needed. If L3 decides to perform handover according to some rules, L3 sends L2-LinkConnect.request with some parameters about candidate access points to request L2 handover. L2 handover begins after sending L2-LinkConnect.confirm to L3. When L2 handover finished, L2 sends L2-LinkUp.indication to notify L3. At last, L3 performs handover (e.g., sending BU). One of the important features of L3-driven fast handover using Primitives is that the L3 handover preparation can be done during Mitani, et al. Expires August 22, 2005 [Page 14] Internet-Draft L2 Abstractions February 2005 communication. So, it can reduce disruption time during handover. Mitani, et al. Expires August 22, 2005 [Page 15] Internet-Draft L2 Abstractions February 2005 Appendix B. Example Operation for FMIPv6 Figure 3 shows the predictive mode of FMIPv6 operation with L3-driven link switching mechanism. MN L2 MN L3 PAR L3 | | | AP<---------PeerList.req----------| | Scan---------PeerList.cnf--------->| | | |---RtSolPr-->| | |<--PrRtAdv---| |---------PeerFound.ind--------->| | | |---RtSolPr-->| | |<--PrRtAdv---| | | | ~ ~ ~ | | | Low | | Signal-----LinkToBeDown.ind------->| | NAR L3 | |-----FBU---->| | | | |----HI---->| | | |<--HAck----| | |<----FBack---| | |<-------LinkConnect.req---L3 Handover | | L2 Handover--LinkConnect.cnf-------->: | : : | : : | finish---------LinkUp.ind---------->: | | :-----------FNA---------->| | finish<======packets=========| | | | MN L2 : Link Layer on Mobile Node MN L3 : Network Layer on Mobile Node PAR L3 : Network Layer on Previous Access Router NAR L3 : Network Layer on New Access Router req : Request cnf : Confirm ind : Indication RtSolPr : Router Solicitation for Proxy PrRtAdv : Proxy Router Advertisement FBU : Fast Binding Update FBack : Fast Binding Acknowledgment FNA : Fast Neighbor Advertisement HI : Handover Initiate HAck : Handover Acknowledge Figure 3: L3-Driven Fast Handover Mechanism with FMIPv6 Mitani, et al. Expires August 22, 2005 [Page 16] Internet-Draft L2 Abstractions February 2005 When the MN establishes link connectivity with the PAR, it performs router discovery. Then, the MN can send RtSolPr message to the PAR in order to resolve access point identifiers to subnet router information. To send RtSolPr, a MN discovers one or more access points by sending L2-PeerList.request to the link layer. As a response to L2-PeerList.request, L2-PeerList.confirm returns with "Peer List" parameter which contains identifiers and conditions of nearby access points. After initial AP discovery, L2-PeerFound.indication with "Peer List" is also sent from the link layer when one or more access points are discovered. When the link layer of the MN detects radio signal strength is going down, it sends L2-LinkToBeDown.indication to the network layer. Then, the MN sends FBU to PAR as the beginning of L3 handover procedure. The NCoA required for FBU message is determined according to the MN's policy database and received PrRtAdv message. As a response to FBU, the MN receives FBack and then switches its link by L2-LinkConnect.request with specific "Peer" parameter immediately. The handover policy of the MN is outside the scope of this document. After L2 handover, the link layer of the MN sends L2-LinkUp.indication to the network layer. The MN sends FNA message to NAR immediately. The NAR will send tunneled and buffered packets to the MN. Mitani, et al. Expires August 22, 2005 [Page 17] Internet-Draft L2 Abstractions February 2005 Appendix C. Example Mapping of Primitives and IEEE802.11 This section shows examples of the mapping between "Primitives" and IEEE802.11 parameters. C.1 L2-LinkStatus Most of parameters for L2-LinkStatus are related to the configuration of network interface hardware. So, the operating system and the device driver module can easily collect such information. However, to create the "Condition" parameter, the MN should maintain statistics and parameters related to current wireless environment. There are two sub-parameters of the "Condition" parameter: available bandwidth, link quality level. An available bandwidth of the current peer can be obtained by maintaining transmission rate indication and statistics of frame transmission at every time the frame transmission occurs. A link quality level can be updated by maintaining the following parameters and statistics at every time the frame reception occurs: receive signal strength indication (RSSI), transmission/ reception rate indication, transmit/receive latency, bit error rate, frame error rate and noise level. Some parameters can be managed by setting threshold from software. When the parameters cross the threshold, an interrupt is generated for the software. C.2 L2-PeerList In IEEE 802.11 networks, L2-PeerList returns all detected APs as peer candidates (by "Peer List" parameter). Therefore, the MN should always maintain the database of available access points according to reception of beacon frame, probe response frame and all frames. This AP database is managed in consideration of time, number of frames and signal strength. There are some network interface hardwares that can notify events to operating system only when the desired event occurs, by setting threshold from software. Moreover, the MN can transmit probe request frame for access point discovery, if needed. C.3 L2-PeerFound In IEEE 802.11 networks, L2-PeerFound is notified when new peers are detected by listening beacons or scanning APs. If the received frame (mainly beacon or probe response) is not in the AP database described in Appendix C.2, then the link layer can create L2-PeerFound.indication. C.4 L2-PeerLost In IEEE 802.11 networks, L2-PeerLost is notified when an AP included Mitani, et al. Expires August 22, 2005 [Page 18] Internet-Draft L2 Abstractions February 2005 in the list of candidate APs is got lost by listening beacons or scanning APs. If the entry in the AP database described in Appendix C.2 expires, or signal strength of the received frame (mainly beacon or probe response) is under threshold, then the link layer can create L2-PeerLost.indication. C.5 L2-LinkUp In IEEE 802.11 networks, L2-LinkUp is notified when association or reassociation event occurs. When such event occurs, the MN receives association response frame or reassociation response frame. Immediately after receiving it, the link layer can create L2-LinkUp.indication. C.6 L2-LinkDown In IEEE 802.11 networks, L2-LinkDown is notified when disassociation event occurs. When such event occurs, the MN sends disassociation frame to AP, or the entry of the specific AP is deleted from the AP database described in Appendix C.2. By detecting such events, the link layer can create L2-LinkDown.indication. C.7 L2-LinkToBeDown In IEEE 802.11 networks, L2-LinkToBeDown is notified when radio signal strength of the connected AP is going down. By maintaining parameters for a link quality level like the description in Appendix C.1, the link layer can create L2-LinkToBeDown.indication. C.8 L2-LinkConnect In IEEE802.11 networks, each AP is identified by BSSID, the service set of several APs is identified by SSID. When L2-LinkConnect is used to connect specific AP or service set, the link layer should set BSSID or SSID. Also, the channel should be set appropriately at the same time by searching database described in Appendix C.2. C.9 L2-LinkDisconnect In IEEE802.11 networks, the MN sends disassociation message to the AP for disconnection. When L2-LinkDisconnect is used for disconnection from the current AP, the link layer should send disassociation message to the appropriate AP, and stop data transmission. Mitani, et al. Expires August 22, 2005 [Page 19] Internet-Draft L2 Abstractions 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. Mitani, et al. Expires August 22, 2005 [Page 20]