<Individual Submission> 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
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]