idnits 2.17.1 draft-ietf-rohc-rtp-lla-impl-guide-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1.a on line 15. -- Found old boilerplate from RFC 3978, Section 5.5 on line 204. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 175. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 182. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 188. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: 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. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The abstract seems to contain references ([3]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 14, 2005) is 6983 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 3242 (ref. '3') (Obsoleted by RFC 4362) Summary: 8 errors (**), 0 flaws (~~), 3 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Kristofer Sandlund, Effnet AB 3 INTERNET-DRAFT 4 Expires: August 2005 5 February 14, 2005 7 ROHC LLA Implementer's Guide 8 10 Status of this memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of RFC 3668. 17 By submitting this Internet-Draft, I (we) accept the provisions of 18 Section 3 of RFC 3667 (BCP 78). 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that other 22 groups may also distribute working documents as Internet-Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress". 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/1id-abstracts.html 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html 35 This document is a submission of the IETF ROHC WG. Comments should be 36 directed to the ROHC WG mailing list, rohc@ietf.org. 38 Abstract 40 This document describes common misinterpretations and some ambiguous 41 points of ROHC LLA [3], which defines the Link-Layer Assisted profile 42 for IP/UDP/RTP. 43 These points have been identified by the members of the ROHC working 44 group during implementation of the profile. 46 Table of Contents 48 1. Introduction.....................................................2 49 2. Terminology......................................................2 50 3. CSP Packet Format................................................2 51 4. CRC Verification of CCP packets..................................3 52 5. Security Consideration...........................................3 53 6. Acknowledgments..................................................4 54 7. Authors' Addresses...............................................4 55 8. References.......................................................4 56 8.1. Normative references........................................4 58 1. Introduction 60 ROHC LLA [3] defines a profile for compressing IP/UDP/RTP by using 61 functionality provided by the lower layers to achieve a zero byte 62 compressed header during normal operation. 63 During implementation of this profile, some errors and unclear areas 64 have been identified. This document tries to correct and clarify 65 those points. 67 2. Terminology 69 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 70 "SHOULD, "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 71 document are to be interpreted as described in RFC 2119 [1]. 73 3. CSP Packet Format 75 The format of the CSP packet has been identified as non-interoperable 76 when carrying a RHP header with a 3-bit or 7-bit CRC. This problem 77 occurs due to the payload having been dropped by the compressor, 78 while the decompressor is supposed to use the payload length to infer 79 certain fields in the uncompressed header. These fields are the IPv4 80 total length, the IPv6 payload length, the UDP length and the IPv4 81 header checksum field (all INFERRED fields in [2]). 83 To correct this problem, the CSP packet needs to contain information 84 about the payload length carried in the RHP packet. Therefore the 85 length of the RTP payload is carried in the CSP packet. The redefined 86 format for the CSP packet is therefore as follows: 88 0 1 2 3 4 5 6 7 89 +---+---+---+---+---+---+---+---+ 90 | 1 1 1 1 1 0 1 0 | Packet type identifier 91 +===+===+===+===+===+===+===+===+ 92 / RTP Payload Length / 2 octets 93 +---+---+---+---+---+---+---+---+ 94 : ROHC header without padding : 95 : see [ROHC, section 5.7] : 96 +---+---+---+---+---+---+---+---+ 98 Updating properties: CSP maintains the updating properties of the 99 ROHC header it carries. 101 RTP Payload Length: This field is the length of the payload 102 carried inside the RTP header, stored in network byte order. I.e. 103 this field will be set by the compressor to (UDP length - size of 104 the RTP header including CSRC identifiers). 106 When the decompressor receives a CSP packet, it MUST use the RTP 107 payload length field to calculate the value of fields classified as 108 INFERRED in [2] when attempting to verify a 3- or 7-bit CRC carried 109 in the RHP header enclosed in the CSP. 110 When the encapsulated RHP packet only carries an 8-bit CRC, the RTP 111 payload length MAY be used by the decompressor for verification of 112 the decompressed header. 114 The packet format defined in this section obsoletes the header format 115 for the CSP defined in [3] Section 4.1.2. 117 4. CRC Verification of CCP packets 119 When a CCP packet with the C-bit set is received by the decompressor, 120 the decompressor uses the 7-bit CRC in the packet to verify the 121 context. For this verification to succeed, the decompressor needs to 122 have access to the entire uncompressed header of the latest packet 123 decompressed. 124 Some implementations of [2] might not save the values of INFERRED 125 fields. An implementation of ROHC LLA MUST save these fields in the 126 decompressor context to be able to successfully verify CCP packets. 128 Also, section 4.1.3 of [3] states that upon CRC failure, the actions 129 of [2] section 5.3.2.2.3 MUST be taken. That section specifies that 130 detection of SN wraparound and local repair must be performed. 131 Neither of these steps apply when the failing packet is a CCP, and 132 therefore only the action described when both these steps fail should 133 be taken (i.e the steps a-d). 135 5. Security Consideration 136 This document provides some changes and clarifications to [3], but it 137 is not belived that these changes add any extra security 138 considerations than those listed in [3]. 140 6. Acknowledgments 142 The author would like to thank Joakim Enerstam, Ghyslain Pelletier 143 and Lars-Erik Jonsson for their contributions and comments. 145 7. Authors' Addresses 147 Kristofer Sandlund Tel: +46 920 60917 148 Effnet AB EMail: kristofer.sandlund@effnet.com 149 Stationsgatan 69 150 97234 Lulea 151 Sweden 153 8. References 155 8.1. Normative references 157 [1] S. Bradner, "Key words for use in RFCs to Indicate Requirement 158 Levels", RFC 2119, March 1997. 159 [2] C. Bormann, et. al, "RObust Header Compression (ROHC): Framework 160 and four profiles: RTP, UDP, ESP, and uncompressed", RFC 3095, 161 July 2001. 162 [3] L. Jonsson, G. Pelletier, "RObust Header Compression (ROHC): A 163 Link-Layer Assisted Profile for IP/UDP/RTP", RFC 3242, April 164 2002. 166 Intellectual Property Statement 168 The IETF takes no position regarding the validity or scope of any 169 Intellectual Property Rights or other rights that might be claimed to 170 pertain to the implementation or use of the technology described in 171 this document or the extent to which any license under such rights 172 might or might not be available; nor does it represent that it has 173 made any independent effort to identify any such rights. Information 174 on the procedures with respect to rights in RFC documents can be 175 found in BCP 78 and BCP 79. 177 Copies of IPR disclosures made to the IETF Secretariat and any 178 assurances of licenses to be made available, or the result of an 179 attempt made to obtain a general license or permission for the use of 180 such proprietary rights by implementers or users of this 181 specification can be obtained from the IETF on-line IPR repository at 182 http://www.ietf.org/ipr. 184 The IETF invites any interested party to bring to its attention any 185 copyrights, patents or patent applications, or other proprietary 186 rights that may cover technology that may be required to implement 187 this standard. Please address the information to the IETF at ietf- 188 ipr@ietf.org. 190 Copyright Statement 192 Copyright (C) The Internet Society (2004). This document is subject 193 to the rights, licenses and restrictions contained in BCP 78, and 194 except as set forth therein, the authors retain all their rights. 196 Disclaimer of Validity 198 This document and the information contained herein are provided on an 199 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 200 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 201 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 202 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 203 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 204 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 206 This Internet-Draft expires August 14, 2005.