S. Daniel Park Internet Engineering Task Force SAMSUNG Electronics Internet-Draft Hee-Jin Jang Expires : April 2004 Youn-Hee Han SAMSUNG AIT October 2003 Fast Router Advertisement Supporting LWAPP < draft-park-dna-fastra-lwapp-00.txt > Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 except that the right to produce derivative works is not granted [RFC 2026]. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress". The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved. Abstract To provide fast handover in mobile environment, mobile node has to discover neighbor router in visited network because of configuring new IPv6 address as care-of address. This document proposes new method so as to reduce time delay when mobile node moves to a new link particularly supporting LWAPP. This extension is targeted to Detecting Network Attachment (DNA) as well as to LWAPP. Park, Jang, Han Expires - April 2004 [Page 1]  Internet-Draft FastRA Supporting LWAPP October 2003 Table of Contents 1. Introduction.................................................2 2. Terminology..................................................2 3. Motivation...................................................3 4. Fast RA supporting LWAPP.....................................3 5. Operation....................................................4 6. IANA Considerations..........................................5 7. Security Considerations......................................6 8. References...................................................6 9. Authors Address..............................................6 10. IPR Statement................................................6 11. Full Copyright Statement.....................................7 1. Introduction Wireless and mobile node are subject to changing their point of attachment from one access network to another [L2TRIGGER]. The network attachment occurs when a link-layer connection is established and mobile node can send and receive some IP packet in attached network. For network-layer connection, mobile node has to gather required information by receiving RA message from router. The fast handover is able to be used for mobile node to sustain current connection without packet loss and latency. This document proposes new method to reduce time delay when mobile node moves to a new link. In particular, LWAPP [LWAPP] will be used by AP to request RA message using 802.11 frame instead of layer 2 trigger protocol. LWAPP was about to discuss in CAPWAP Working Group. Note that this document only focus on fast RA method and others are out of scope of this document. [L2TRIGGER] can be used for enhanced another method and it will be easily covered in near future if we want. This extension is described in this document can be also applied to Detecting Network Attachment (DNA) as well. 2. Terminology Park, Jang, Han Expires - April 2004 [Page 2]  Internet-Draft FastRA Supporting LWAPP October 2003 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 [KEYWORDS]. o RA Router Advertisement message from router. o LWAPP Light Weight Access Point Protocol between AP and AR. o AP Access Point. o AR Access Router. 3. Motivation When mobile node moves to a new link, two kind of handover are happened on mobile node as link-layer handover and network-layer handover. The network-layer handover occurs when link-layer handover is established in a new link and mobile node can send and receive some IP packets from neighbor nodes. In particular, mobile node has to discovery AR in order to obtain address configuration parameters like valid prefix, lifetime and etc. RA message is used by AR to provide above parameters. In wireless lan, RS message request RA message has to be reached the AR through AP because AP is a bridge. There is no synchronization. The purpose of new proposed method is to synchronize among mobile node, AP and AR. The RA Request message (in LWAPP) is used for synchronization between AP and AR when AP receives Reassociation.request frame from mobile node. This method does not require any modification of current AP except LWAPP supporting, particularly, this scheme does not require additional network-layer operations though. This method also can be efficiently used for fast RA without layer 2 trigger protocol. 4. Fast RA supporting LWAPP In 57 IETF, LWAPP (Light Weight Access Point Protocol) was discussed in CAPWAP BOF. In particular, Control Channel Management messages are used for the discovery of AR by the AP as well as the Park, Jang, Han Expires - April 2004 [Page 3]  Internet-Draft FastRA Supporting LWAPP October 2003 establishment and maintenance of an LWAPP control. New defined RA Request message will be used for request fast RA by AP. Below figure depicts RA Request message format. All LWAPP control messages are sent encapsulated within the LWAPP header with the following header values: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Msg Type | Seq Num | Msg Element Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ o Msg Type 25 (or TBD) o Seq Num set to zero o Msg Element Length set to zero If router receives RA Request message, then router has to send RA message including configuration parameters immediately and this message is silently discarded. Note that RA message from router is unsolicited RA message. Immediately on receiving RA Request message from AP, router has to send unsolicited RA message without random delay. Unsolicited RA message will be sent by router up to MAX_INITIAL_RTR_ADVERTISEMENTS (default 3 times) which can be reconfigured by operator policy. When mobile node does not complete link-layer attachment, unsolicited RA message will be silently discarded. 5. Operation LWAPP must be supported in both AP and AR in order to provide fast RA. Reassociation.request frame is sent by mobile node when mobile node wants to change its association from its current AP to a new AP and Reassociation.reply frame is sent by new AP either allowing or Park, Jang, Han Expires - April 2004 [Page 4]  Internet-Draft FastRA Supporting LWAPP October 2003 denying the request. After establishing association, mobile node sends RS message for RA to the new AR. The new proposed method combines existing methods and make use of LWAPP. During AR discovery phase, AP MUST wait for an interval not less than DiscoveryInterval for receipt of additional discovery replies according to [LWAPP]. In addition, AP MUST store necessary information of the additional discovery replies for candidates. For example, when the AR which AP joined does not function as a default router (does not advertise RA message with Prefix information), or its advertised router lifetime = 0, AP can request unsolicited RA to one of the candidate ARs which are stored during AR discovery phase. Preference indicated by new flag or alternatives can be used for AP to decide its default router among them. When AP receives Reassociation.request frame from mobile node, if AP decides to allow the request, AP sends Reassociation.reply frame to the mobile node as well as RA Request (Type = 25) to the AR using LWAPP simultaneously. After then, AR sends unsolicited RA up to MAX_INITIAL_RTR_ADVERTISEMENTS (default 3 times) including configuration parameters such as valid prefix, lifetime and etc. Note that AR has to send unsolicited RA message without random delay when receiving RA Request message by AP. AR does not reply by RA Request frame and silently discard. [L2TRIGGER] can be used for providing L2 events information from AP to other IP nodes such as mobile node and AR. Because of [L2TRIGGER], it is able to eliminate the latency involved in waiting for a RA beacon from the AR, thus increasing handover performance. Network devices which do not perform L2TRIGGER can be applied for the new proposed method of this document. Of course, AP and AR have to perform LWAPP with RA Request message (Type = 25). [L2TRIGGER] and new proposed method can be combined as enhanced another method. If possible, it will be easily covered in near future. 6. IANA Considerations There are no IANA considerations in this document. Park, Jang, Han Expires - April 2004 [Page 5]  Internet-Draft FastRA Supporting LWAPP October 2003 7. Security Considerations This section is tightly coupled with existing considerations in LWAPP as well as 802.11. 8. References [RFC 2026] Bradner, S., The Internet Standards Process - Revision 3, BCP 9, RFC 2026, October 1996. [KEYWORDS] Bradner, S., Key words for use in RFCs to Indicate Requirement Levels, BCP 14, RFC 2119, March 1997. [LWAPP] P. Calhoun, et. al., Light Weight Access Point Protocol, Internet Draft, June 2003. [L2TRIGGER] Alper E. Yegin., Link-layer Triggers Protocol, Internet Draft, June 2002. 9. Authors Address Soohong Daniel Park Mobile Platform Laboratory, SAMSUNG Electronics EMail: soohong.park@samsung.com Hee-Jin Jang SAMSUNG Advanced Institute of Technology i-Networking Laboratory EMail: heejin.jang@samsung.com Youn-Hee Han SAMSUNG Advanced Institute of Technology i-Networking Laboratory EMail: yh21.han@samsung.com 10. IPR Statement Park, Jang, Han Expires - April 2004 [Page 6]  Internet-Draft FastRA Supporting LWAPP October 2003 The IETF has been notified of intellectual property rights claimed in regard to some or all of the specification contained in this document. For more information consult the online list of claimed rights. Please refer to http://www.ietf.org/ietf/IPR for more information. 11. Full Copyright Statement Copyright (C) The Internet Society (2003). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Park, Jang, Han Expires - April 2004 [Page 7]