Mobility Optimizations Group Nick 'Sharkey' Moore, Monash CTIE INTERNET-DRAFT JinHyeock Choi, Samsung SAIT Brett Pentland, Monash CTIE 09 July 2004 Tunnel Buffering for Mobile IPv6 Status of this Memo By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, and any of which I 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. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. Moore, Choi, Pentland Expires: 09 January 2005 [Page 1] INTERNET-DRAFT Tunnel Buffering 09 July 2004 Abstract Tunnel Buffering (TB) is an interoperable enhancement to Mobile IPv6 to reduce packet loss during movement, and to avoid retransmission when movement is complete. TB does this by 'pausing' the packets which are to be send over a MobileIPv6 or HMIPv6 tunnel until movement is complete. Table of Contents Status of this Memo ......................................... 1 Copyright Notice ............................................ 1 Abstract .................................................... 2 Table of Contents ........................................... 2 1. Introduction ............................................. 3 1.1 History ......................................... 3 2. Messages ................................................. 4 2.1 BU / LBU ........................................ 4 2.2 BAck / LBAck .................................... 5 3. Requirements ............................................. 6 3.1 Mobile Node ..................................... 6 3.2 Home Agent ...................................... 6 3.3 Mobility Anchor Point ........................... 7 3.4 Access Router & Correspondent Nodes ............. 7 4. Security Considerations .................................. 8 5. IANA Considerations ...................................... 8 6. References ............................................... 9 Author's Addresses .......................................... 10 Acknowledgements ............................................ 10 Full Copyright Statement .................................... 11 Intellectual Property Statement ............................. 11 Disclaimer of Validity ...................................... 11 Moore, Choi, Pentland Expires: 09 January 2005 [Page 2] INTERNET-DRAFT Tunnel Buffering 09 July 2004 1. Introduction Mobile IPv6 [RFC3775] uses tunnels to route traffic to Mobile Nodes (MN). The MN informs its Home Agent (HA) of its location, using a Binding Update (BU) message, and the HA tunnels packets intended for the MN to that location. Hierarchical Mobile IPv6 [HMIPv6] and Edge Handovers [EDGE-01] work equivalently, with a Mobility Anchor Point (MAP) being notified of the MNs location with a Local Binding Update (LBU). The HA tunnels traffic to the MAP, which then tunnels the traffic to the MN. Unfortunately, the MN cannot generally inform the HA/MAP of its new location until it has arrived there, and so the HA/MAP may forward packets to the old location during movement. Tunnel Buffering (TB) considers the situation where a MN anticipates that it is about to move, but does not know where it is about to move to. In this case, the MN can send a special (L)BU requesting that its traffic be buffered until it has determined its new link CoA and can send another (L)BU. 1.1 History This draft is based on ideas which were previously published in [EDGE-00] but which we feel stand on their own and are best presented in a separate draft. Greg Daley at Monash CTIE proposed the 'P' flag. Richard Nelson, who is now at Waikato University, New Zealand, started us on the idea of buffering on movement anticipation. There are also some similarities with [SMOOTH], although this draft was developed independently. This version of Edge Handovers has been implemented as an experimental patch to Linux 2.4.22 / Mipl-1.0. See for further information on our work. Moore, Choi, Pentland Expires: 09 January 2005 [Page 3] INTERNET-DRAFT Tunnel Buffering 09 July 2004 2. Messages The following signals, defined in [HMIPv6] are used in this version of EH: 2.1 PAUSE flag on BU / LBU An extra flag is added to the Binding Update defined in [RFC3775] and the Local Binding Update [HMIPv6]. The position of this flag is shown below, subject to IANA approval: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence # | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |A|H|L|K|M|P| Reserved | Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . Mobility Options . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Description of flags: A,H,L,K See [RFC3775] 6.1.7 M See [HMIPV6] 4.1 P 'Pause' flag. P=1 indicates a request for the HA / MAP to buffer packets. P=0 indicates a request for the HA / MAP to forward packets. This draft uses the notation 'BU+P' or 'LBU+P' to indicate a (Local) Binding Update with the flag set, and 'BU-P' or 'LBU-P' to indicate an (L)BU with the flag cleared. Moore, Choi, Pentland Expires: 09 January 2005 [Page 4] INTERNET-DRAFT Tunnel Buffering 09 July 2004 2.2 PAUSE flag in BAck / LBack Additionally, a PAUSE flag is added to the Binding Acknowledgement / Local Binding Acknowledgement messages. The position of this flag is shown below, subject to IANA approval: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Status |K|P| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence # | Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . Mobility options . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Description of flags: K See [RFC3775] 6.1.8 P 'Pause' flag confirming buffering of packets. P=1 indicates that the HA / MAP is buffering packets. P=0 indicates that the HA / MAP is forwarding packets. This draft uses the notation 'BAck+P' or 'LBAck+P' to indicate a (Local) Binding Acknowledgement with the flag set, and 'BAck-P' or 'LBAck-P' to indicate an (L)BAck with the flag cleared. Moore, Choi, Pentland Expires: 09 January 2005 [Page 5] INTERNET-DRAFT Tunnel Buffering 09 July 2004 3. Requirements 3.1 Mobile Node The MN, if it determines that it is about to move to an unknown location: * SHOULD send an LBU+P(RCoA -> OLCoA) to its MAP if using HMIPv6. * MAY send a BU+P(HAddr -> OCoA) to its HA if not using HMIPv6. * SHOULD NOT send a BU to its HA if using HMIPv6. The MN, once it has completed movement and knows its new location: * MUST send an LBU-P(RCoA -> LCoA) to its MAP if using HMIPv6. * MUST send a BU-P(HAddr -> NCoA) to its HA if it not using HMIPv6. 3.2 Home Agent * The HA SHOULD, on reception of a BU+P with a valid HAddr and currently active CoA, cease tunneling packets to the MN and instead retain them in a buffer. It SHOULD send a BAck+P to the MN. * The HA SHOULD limit the number of packets retained, it MAY limit the total size of the packets retained, and it MAY limit the time for which it will retain a packet. Packets exceeding the limits MAY be disposed of in any order. * The HA SHOULD, on reception of a BU-P with a valid HAddr and a valid CoA, forward packets retained for that HAddr to the CoA and resume tunneling packets. It SHOULD send a BAck-P to the MN. Moore, Choi, Pentland Expires: 09 January 2005 [Page 6] INTERNET-DRAFT Tunnel Buffering 09 July 2004 3.3 Mobility Anchor Point (equivalent to HA) * The MAP SHOULD, on reception of an LBU+P with a valid RCoA and currently active LCoA, cease tunneling packets to the MN and instead retain them in a buffer. It SHOULD send a LBAck+P to the MN. * The MAP SHOULD limit the number of packets retained, it MAY limit the total size of the packets retained, and it MAY limit the time for which it will retain a packet. Packets exceeding the limits MAY be disposed of in any order. * The MAP SHOULD, on reception of a LBU-P with a valid RCoA and a valid LCoA, forward packets retained for that RCOA to the LCoA and resume tunneling packets. It SHOULD send a BAck-P to the MN. 3.4 Access Routers & Correspondent Nodes As in HMIPv6, there are no requirements for Access Routers or for Correspondent Nodes beyond that specified in [RFC3775] and [NODEREQS]. Moore, Choi, Pentland Expires: 09 January 2005 [Page 7] INTERNET-DRAFT Tunnel Buffering 09 July 2004 4. Security Considerations A spoofed binding update with 'P' set may cause traffic to be buffered, this is no worse for the MN than a spoofed BU to a arbitrary location, and the effect to the HA/MAP is limited to a small waste of memory. Spoofing large numbers of binding updates for different MNs may conceivably cause a large waste of memory. 5. IANA Considerations The 'P' flag in BU and BAck needs to be assigned. Moore, Choi, Pentland Expires: 09 January 2005 [Page 8] INTERNET-DRAFT Tunnel Buffering 09 July 2004 6.1 RFC References [RFC2119] S. Bradner, "Keywords to use in RFCs to Indicate Requirement Levels". RFC2119 (BCP 14). [RFC2461] T. Narten, E. Nordmark and W. Simpson, "Neighbour Discovery for IP version 6". RFC 2461 (Draft Standard). [RFC3775] D. Johnson, C. Perkins, J. Arkko, "Mobility Support in IPv6". RFC 3775 (Proposed Standard). 6.2 Internet Draft References [EDGE-00] N. Moore, JH. Choi, G. Daley, "Edge Handovers for MIPv6". (superceded) [EDGE-01] N. Moore, JH. Choi, G. Daley, "Edge Handovers for MIPv6". [HMIPv6] H. Soliman, C. Castelluccia, K. El-Malki, L. Bellier, "Hierarchical Mobile IPv6 mobility management (HMIPv6)". [NODEREQS] J. Loughney (ed) "IPv6 Node Requirements". [SMOOTH] G. Krishnamurthi, R. C. Chalmers, C. Perkins, "Buffer Management for Smooth Handovers in IPv6". (expired) Moore, Choi, Pentland Expires: 09 January 2005 [Page 9] INTERNET-DRAFT Tunnel Buffering 09 July 2004 Authors' Addresses: Nick 'Sharkey' Moore or Centre for Telecommunications and Information Engineering Monash University 3800 Victoria, Australia JinHyeock Choi Samsung Advanced Institute of Technology P.O. Box 111, Suwon 440-600 Korea Brett Pentland Centre for Telecommunications and Information Engineering Monash University 3800 Victoria, Australia Acknowledgments This work has been supported by the Australian Telecommunications Cooperative Research Centre (AT-CRC) Funding for the RFC Editor function is currently provided by the Internet Society. Moore, Choi, Pentland Expires: 09 January 2005 [Page 10] INTERNET-DRAFT Tunnel Buffering 09 July 2004 Full Copyright Statement Copyright (C) The Internet Society (2004). 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. Intellectual Property Statement The IETF takes no position regarding the validity or scope of any intellectual property 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; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in IETF Documents can be found in BCP 78 and 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 which 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 PURPOS Moore, Choi, Pentland Expires: 09 January 2005 [Page 11]