Internet Engineering Task Force Tmima Koren Audio/Video Transport Working Group Patrick Ruddy INTERNET-DRAFT Cisco Systems EXPIRES: September 2005 February 2005 Packet reordering in Extended CRTP (ECRTP) draft-koren-avt-ecrtp-reorder-00.txt Status of this memo This document is an Internet-Draft and is in full conformance with all provisions of Section 5 of RFC3667. 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 cite them other than as "work in progress". 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. The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/lid-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 (2005). All Rights Reserved. Abstract Extended RTP Header Compression (ECRTP) is tolerant to packet misordering. This document describes how ECRTP validates packets that arrive out of order. 1. Introduction A few Enhancements to CRTP (ECRTP) are defined in RFC3545. With these enhancements, CRTP performs well over links with packet loss, packet reordering and long delays. This document explains how to verify the decompression of out of order packets when using ECRTP. 1.1. Out of order packet validation Packets are not guaranteed to arrive at the destination in the same order they were sent. When using header compression, the decompressor might receive packets out of order. ECRTP uses the twice algorithm to reconstruct packets when there is packet loss or misordering, and verifies the validity of the reconstructed packet by calculating the UDP checksum or the header checksum of the packet and comparing to the checksum that was included in the compressed packet. The UDP checksum verifies all the fields in the packet except for the IP ID. Hence the validity of the IP ID in the reconstructed packet relies on the validity of the delta IP ID. If a packet arrives out of order by skipping a few packets, we can guarantee the validity of the IP ID up to N + 1 packets forward, where N is the link quality indicator used in ECRTP. When any delta field is changing, the change is repeated in N + 1 packets, so if the arriving packet is within N + 1 packets forward, either it includes a change in the IP ID, or the IP ID in the decompressor context is valid. If the packet includes a new delta IP ID, it also includes the IP ID. If a packet arrives out of order backwards, we can restore the IP ID by remembering the last RTP sequence number where the delta IP ID has changed. Hence validation of out of order packets backwards depends on when the delta IP ID changed last. Note that in IPv6 there is no limit on the number of packets forward or backward that can be verified since there is no IP ID in the IPv6 IP header. 2. IANA Considerations This document does not require any assignments from IANA. 3. Security Considerations The security issues of this document are the same as [ECRTP]. 4. References Normative References [ECRTP] T. Koren, S. Casner, J. Geevarghese, B. Thompson, P. Ruddy, "Enhanced Compressed RTP (CRTP) for Links with High Delay, Packet Loss and Reordering", RFC3545, July 2003. [CRTP] S. Casner, V. Jacobson, "Compressing IP/UDP/RTP Headers for Low-Speed Serial Links", RFC 2508, February 1999. [TCRTP] B. Thompson, T. Koren, D. Wing, "Tunneling Multiplexed Compressed RTP ("TCRTP")", draft-ietf-avt-tcrtp-08.txt, September 2004. 5. Authors' Addresses Tmima Koren 170 West Tasman Drive San Jose, CA 95134-1706 United States of America Phone: +1 408 527 6169 Email: tmima@cisco.com Patrick Ruddy Cisco Systems, Inc. 3rd Floor 96 Commercial Street Leith, Edinburgh EH6 6LX Scotland EMail: pruddy@cisco.com 6. Copyright Notice 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. 7. Disclaimers 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. 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.