1999.
[RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor
Discovery for IP Version 6 (IPv6)", RFC 2461, December
1998.
[RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address
Autoconfiguration", RFC 2462, December 1998.
[RFC3095] Bormann, C., Burmeister, C., Degermark, M., Fukushima,
H., Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T.,
Le, K., Liu, Z., Martensson, A., Miyazaki, A., Svanbro,
K., Wiebke, T., Yoshimura, T., and H. Zheng, "RObust
Header Compression (ROHC): Framework and four profiles:
RTP, UDP, ESP, and uncompressed ", RFC 3095, July 2001.
[BT] IEEE, "IEEE Standard for information technology -
Telecommunication and information exchange between
systems - LAN/MAN - Part 15.1: Wireless Medium Access
Control (MAC) and Physical Layer (PHY) specifications for
Wireless Personal Area Networks (WPANs)", IEEE Standard
802.15.1, 2002.
[EAP] Aboba, B., Simon, D., Arkko, J., Eron, P., and H.
Levokowetz, "Extensible Authentication Protocol (EAP) Key
Management Framework", Work in Progress.
Appendix A. Timing and Trigger Considerations
Basic Mobile IP handover signaling can introduce disruptions to the
services running on top of Mobile IP, which may introduce unwanted
latencies that practically prohibit its use for certain types of
services. Mobile IP latency and packet loss are optimized through
several alternative procedures, such as Fast Mobile IP [FMIPv6] and
Low Latency Mobile IP [LLMIP].
Feature re-establishment through context transfer should contribute
zero (optimally) or minimal extra disruption of services in
conjunction with handovers. This means that the timing of context
transfer SHOULD be carefully aligned with basic Mobile IP handover
events, and with optimized Mobile IP handover signaling mechanisms,
as those protocols become available.
Furthermore, some of those optimized mobile IP handover mechanisms
may provide more flexibility in choosing the timing and ordering for
the transfer of various context information.
Appendix B. Multicast Listener Context Transfer
In the past, credible proposals have been made in the Seamoby Working
Group and elsewhere for using context transfer to the speed of
handover of authentication, authorization, and accounting context,
distributed firewall context, PPP context, and header compression
context. Because the Working Group was not chartered to develop
context profile definitions for specific applications, none of the
documents submitted to Seamoby were accepted as Working Group items.
At this time, work to develop a context profile definition for RFC
3095 header compression context [RFC3095] and to characterize the
performance gains obtainable by using header compression continues,
but is not yet complete. In addition, there are several commercial
wireless products that reportedly use non-standard, non-interoperable
context transfer protocols, though none is as yet widely deployed.
As a consequence, it is difficult at this time to point to a solid
example of how context transfer could result in a commercially
viable, widely deployable, interoperable benefit for wireless
networks. This is one reason why CXTP is being proposed as an
Experimental protocol, rather than Standards Track. Nevertheless, it
seems valuable to have a simple example that shows how handover could
benefit from using CXTP. The example we consider here is
transferring IPv6 MLD state [RFC2710]. MLD state is a particularly
good example because every IPv6 node must perform at least one MLD
messaging sequence on the wireless link to establish itself as an MLD
listener prior to performing router discovery [RFC2461] or duplicate
address detection [RFC2462] or before sending/receiving any
application-specific traffic (including Mobile IP handover signaling,
if any). The node must subscribe to the Solicited Node Multicast
Address as soon as it comes up on the link. Any application-specific
multicast addresses must be re-established as well. Context transfer
can significantly speed up re-establishing multicast state by
allowing the nAR to initialize MLD for a node that just completed
handover without any MLD signaling on the new wireless link. The
same approach could be used for transferring multicast context in
IPv4.
An approximate quantitative estimate for the amount of savings in
handover time can be obtained as follows: MLD messages are 24 octets,
to which the headers must be added, because there is no header
compression on the new link, where the IPv6 header is 40 octets, and
a required Router Alert Hop-by-Hop option is 8 octets including
padding. The total MLD message size is 72 octets per subscribed
multicast address. RFC 2710 recommends that nodes send 2 to 3 MLD
Report messages per address subscription, since the Report message is
unacknowledged. Assuming 2 MLD messages sent for a subscribed
address, the MN would need to send 144 octets per address
subscription. If MLD messages are sent for both the All Nodes
Multicast address and the Solicited Node Multicast address for the
node’s link local address, a total of 288 octets are required when
the node hands over to the new link. Note that some implementations
of IPv6 are optimized by not sending an MLD message for the All Nodes
Multicast Address, since the router can infer that at least one node
is on the link (itself) when it comes up and always will be.
However, for purposes of this calculation, we assume that the IPv6
implementation is conformant and that the message is sent. The
amount of time required for MLD signaling will depend on the per node
available wireless link bandwidth, but some representative numbers
can be obtained by assuming bandwidths of 20 kbps or 100 kbps. With
these 2 bit rates, the savings from not having to perform the pre-
router discovery messages are 115 msec. and 23 msec., respectively.
If any application-specific multicast addresses are subscribed, the
amount of time saved could be more substantial.
This example might seem a bit contrived as MLD is not used in the 3G
cellular protocols, and wireless local area network protocols
typically have enough bandwidth if radio propagation conditions are
optimal. Therefore, sending a single MLD message might not be viewed
as a performance burden. An example of a wireless protocol where MLD
context transfer might be useful is IEEE 802.15.1 (Bluetooth)[BT].
IEEE 802.15.1 has two IP "profiles": one with PPP and one without.
The profile without PPP would use MLD. The 802.15.1 protocol has a
maximum bandwidth of about 800 kbps, shared between all nodes on the
link, so a host on a moderately loaded 802.15.1 access point could
experience the kind of bandwidth described in the previous paragraph.
In addition, 802.15.1 handover times are typically run upwards of a
second or more because the host must resynchronize its frequency
hopping pattern with the access point, so anything the IP layer could
do to alleviate further delay would be beneficial.
The context-specific data field for MLD context transfer included in
the CXTP Context Data Block message for a single IPv6 multicast
address has the following format:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Subnet Prefix on nAR Wireless Interface +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Subscribed IPv6 Multicast Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Subnet Prefix on a nAR Wireless Interface field contains a subnet
prefix that identifies the interface on which multicast routing
should be established. The Subscribed IPv6 Multicast Address field
contains the multicast address for which multicast routing should be
established.
The pAR sends one MLD context block per subscribed IPv6 multicast
address.
No changes are required in the MLD state machine.
Upon receipt of a CXTP Context Data Block for MLD, the state machine
takes the following actions:
- If the router is in the No Listeners present state on the
wireless interface on which the Subnet Prefix field in the
Context Data Block is advertised, it transitions into the
Listeners Present state for the Subscribed IPv6 Multicast
Address field in the Context Data Block. This transition is
exactly the same as if the router had received a Report
message.
- If the router is in the Listeners present state on that
interface, it remains in that state but restarts the timer, as
if it had received a Report message.
If more than one MLD router is on the link, a router receiving an MLD
Context Data Block SHOULD send the block to the other routers on the
link. If wireless bandwidth is not an issue, the router MAY instead
send a proxy MLD Report message on the wireless interface that
advertises the Subnet Prefix field from the Context Data Block.
Since MLD routers do not keep track of which nodes are listening to
multicast addresses (only whether a particular multicast address is
being listened to) proxying the subscription should cause no
difficulty.
Authors’ Addresses
Rajeev Koodli
Nokia Research Center
313 Fairchild Drive
Mountain View, California 94043
USA
EMail: rajeev.koodli@nokia.com
John Loughney
Nokia
Itdmerenkatu 11-13
00180 Espoo
Finland
EMail: john.loughney@nokia.com
Madjid F. Nakhjiri
Motorola Labs
1301 East Algonquin Rd., Room 2240
Schaumburg, IL, 60196
USA
EMail: madjid.nakhjiri@motorola.com
Charles E. Perkins
Nokia Research Center
313 Fairchild Drive
Mountain View, California 94043
USA
EMail: charles.perkins@.nokia.com
Full 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.
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.
Intellectual Property
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.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.