One document matched: draft-koren-avt-ecrtp-reorder-00.txt

   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.