Mipshop Working Group Henrik Petander Internet Draft National ICT Australia Expires: April 2007 October 16, 2006 Bicast packet identification header draft-petander-mipshop-bicasthdr-00.txt Status of this Memo 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 becomes aware will be disclosed, in accordance with Section 6 of BCP 79. This document may only be posted in an Internet-Draft. 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 April 16, 2007. Copyright Notice Copyright (C) The Internet Society (2006). All Rights Reserved. Abstract Bicasting or multicasting of traffic can be used to reduce the impact of a handoff by allowing a Mobile Node to receive a stream via multiple paths simultaneously. However, receiving of multiple copies of the packets may have a negative impact on applications which Petander Expires April 16, 2007 [Page 1] Internet-Draft draft-petander-mipshop-bicasthdr-00.txt October 2006 cannot distinguish duplicate packets. This holds true for all applications using TCP which mistakes the packet duplication from bicasting with congestion and reduces the sending rate drastically. This document specifies an IPv6 destination option header which can be used to identify and discard duplicate copies of bicasted packets. Conventions used in this document 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 [1]. This document uses the terms and abbreviations defined in RFC 4068. 1. Introduction Bicasting as specified in [4] can be used to reduce the impact of the handoff. A Mobile Node would receive the packets using two alternate paths, via the old network and a new network. If Mobile Node can only connect to one network at a time, it will receive a single continuous stream of packets with minimal disruptions. When coupled with protocols such as Fast Handovers for Mobile IPv6, packet loss can be avoided completely. However, if Mobile Node can connect both to the new and old network simultaneously during the handoff, it will receive duplicate copies of each packet. This would typically be the case in vertical (inter-technology) handoffs and in some cases in horizontal (intra-technology) handoffs. The impact of duplicate packets is two fold: Firstly, they result in a significant overhead. Secondly, they may have an impact on the application performance, if duplicates are not recognized as such and dropped. This document focuses on the use of the extension header to distinguish and discard duplicates at the receiver. Therefore, the draft addresses the impact on application performance, but does not directly address the overhead of delivering duplicate packets. However, the extension header could be used together with the Fast Handovers for Mobile IPv6 framework [3] for dropping the duplicate packets already at New Access Router to reduce over-the-air overhead of bicasting. The impact on application performance depends on the characteristics of the transport protocol used and the application. This impact is especially large on applications which use TCP as the transport protocol. The problem with TCP is that it mistakes the deliberate duplication of packets from bicasting with duplication from network errors. The Eifel extension to TCP [5] may reduce the impact of the Petander Expires April 16, 2007 [Page 2] Internet-Draft draft-petander-mipshop-bicasthdr-00.txt October 2006 duplicates. However, there may be IPR issues with Eifel which prevent its widespread use. This document specifies a protocol for recognizing duplicates which allows discarding of them at the network layer. The protocol uses an IPv6 extension header for labeling the packets with a sequence number. The sender marks each copy with the same sequence number and the receiver keeps track of received sequence numbers and drops any duplicate packets. 2. Packet identifier destination option header +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1 : Packet identifier destination option header. Type Value is xxxx (to be assigned by IANA). Length 8-bit unsigned integer, representing the length of the Mobility Header in octets, excluding the type and length fields. Sequence number 32-bit sequence number identifies a packet within a flow. The sender sets the field to zero for the first the packet which it bicasts and increments the value for each packet. The receiver keeps track of the received values. 3. Operation of the sender in the protocol The sender MUST set the sequence number to zero of the first packet it bicasts. The sender SHOULD set the same sequence number to each copy of the packet that it sends using different paths. Petander Expires April 16, 2007 [Page 3] Internet-Draft draft-petander-mipshop-bicasthdr-00.txt October 2006 The sender MUST increment the sequence number for each packet that it sends. 4. Operation of the receiver in the protocol The receiver SHOULD keep track of received sequence numbers. Upon receiving a packet, the receiver SHOULD extract the sequence number from the packet and deliver the packet if it has not already received a packet with the same sequence number within its receive window. A reasonable size for the receive window would allow dropping of duplicates received via asymmetric paths, for example via a GPRS link and via a WLAN link. In this case, the window should cover the different latencies of the links. Use of buffering together with bicasting may result in a significantly longer delay for packets from one path. The implementation of the receive window is outside the scope of this specification. 5. Security Considerations The dropping of duplicate packets could be abused by an attacker to drop selected packets from a stream. This threat can be avoided by using IPsec with integrity protection for the bicasted stream[2]. 6. Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, November 1998. 7. Informative References [3] Koodli, R. (ed), "Fast Handovers for Mobile IPv6", RFC 4068, July 2005. Petander Expires April 16, 2007 [Page 4] Internet-Draft draft-petander-mipshop-bicasthdr-00.txt October 2006 [4] El_Malki, K., and Soliman, H. "Simultaneous Bindings for Mobile IPv6 Fast Handovers", draft-elmalki-mobileip-bicasting-v6- 06.txt, July 2005 [5] Ludwig, R., Meyer, M., "The Eifel Detection Algorithm for TCP", RFC 3522, April 2003 Author's Address Henrik Petander National ICT Australia Australian Technology Park Bay 15 Locomotive Workshop, Eveleigh NSW 1430 Australia Email: henrik.petander@nicta.com.au 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. Petander Expires April 16, 2007 [Page 5] Internet-Draft draft-petander-mipshop-bicasthdr-00.txt October 2006 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 (2006). 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. Acknowledgments Funding for the RFC Editor function is currently provided by the Internet Society. Petander Expires April 16, 2007 [Page 6]