1 files changed, 395 insertions, 0 deletions
diff --git a/doc/rfc/rfc3408.txt b/doc/rfc/rfc3408.txt
new file mode 100644
index 0000000..c5877e6
--- /dev/null
+++ b/doc/rfc/rfc3408.txt
@@ -0,0 +1,395 @@
+
+
+
+
+
+
+Network Working Group                                             Z. Liu
+Request for Comments: 3408                                         K. Le
+Category: Standards Track                                          Nokia
+                                                           December 2002
+
+
+       Zero-byte Support for Bidirectional Reliable Mode (R-mode)
+       in Extended Link-Layer Assisted RObust Header Compression
+                             (ROHC) Profile
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2002).  All Rights Reserved.
+
+Abstract
+
+   This document defines an additional mode of the link-layer assisted
+   RObust Header Compression (ROHC) profile, also known as the zero-byte
+   profile, beyond the two defined in RFC 3242.  Zero-byte header
+   compression exists in order to prevent the single-octet ROHC header
+   from pushing a packet voice stream into the next higher fixed packet
+   size for the radio.  It is usable in certain widely deployed older
+   air interfaces.  This document adds the zero-byte operation for ROHC
+   Bidirectional Reliable mode (R-mode) to the ones specified for
+   Unidirectional (U-mode) and Bidirectional Optimistic (O-mode) modes
+   of header compression in RFC 3242.
+
+1.  Introduction
+
+   [RFC3242] defines a zero-byte solution for compression of IP/UDP/RTP
+   packets only for Unidirectional (U-) and Bidirectional Optimistic
+   (O-) modes [RFC3095].  The present specification extends the profile
+   defined in [RFC3242] to provide zero-byte support for Bidirectional
+   Reliable (R-) mode.  This specification and [RFC3242] allow a
+   header-free packet format to be used in all modes to replace the
+   majority of the 1-octet headers of ROHC RTP packets sent during
+   normal operation.  Specifically, the compressor operating in R-mode
+   is allowed to deliver a No-Header Packet (NHP) when [RFC3242] would
+   have required it to deliver a ROHC Reliable Packet Type Zero (R-0)
+   packet [RFC3095].
+
+
+
+Liu & Le                    Standards Track                     [Page 1]
+
+RFC 3408               0-byte Support for R-mode           December 2002
+
+
+   For simplification, this profile is defined in the form of the
+   additions and exceptions to [RFC3242] that are required to extend the
+   RFC 3242 profile with zero-byte support for R-mode.  All terminology
+   used in this document is the same as in [RFC3242].
+
+   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 BCP 14, RFC 2119
+   [RFC2119].
+
+2.  Extensions to the assisting layer (AL) interface
+
+   This section describes additions (some are optional) to the assisting
+   layer interface as defined in [RFC3242, section 4.2].
+
+2.1.  Additional parameters to the compressor to AL interface
+
+   -  Mode, indicating the mode in which the compressor is operating.
+      The AL has slightly different logic depending on the mode value.
+
+   -  SN_ACKed, indicating the latest RTP SN that has been acknowledged.
+      It is used only when Mode value = R-mode.
+
+   Note that these two parameters MUST always be attached to every
+   packet delivered to the AL.
+
+2.2.  Additional interface, assisting layer to compressor
+
+   To improve the compression efficiency of this profile in some
+   specific cases, e.g., when the AL operates in such a way that it
+   often becomes unsafe to send NHPs, it is RECOMMENDED to implement
+   this additional interface.  Here, the word "unsafe" means that the
+   compressor allows the AL to send NHP but the AL cannot guarantee that
+   the RTP SN of the NHP will be correctly decompressed at the receiving
+   side.  The interface is used to carry update_request as described in
+   section 3.  Note that this interface is not required in the sense
+   that the impossibility of implementing such an interface should not
+   be an obstacle to implement this profile over a specific link.
+
+3.  R-mode operation
+
+   For the R-mode, this profile extends ROHC RTP by performing a mapping
+   of the R-0 packet to the NHP packet.  Note that R-0 is the only type
+   of packets in R-mode that can be replaced with NHP.
+
+   On the receiving side, the RTP SN of an NHP is determined by the
+   decompressor as = SN_Ref_D + Offset_D, where SN_Ref_D is the RTP SN
+   of the last update packet received by the decompressor, and Offset_D
+
+
+
+Liu & Le                    Standards Track                     [Page 2]
+
+RFC 3408               0-byte Support for R-mode           December 2002
+
+
+   the sequence number offset between the NHP and the last update
+   packet.  How to derive Offset_D depends on the implementation of this
+   profile over a specific link technology and must be specified in the
+   implementation document(s).  For example, it can be calculated by
+   counting the total number of non-context-updating packets (including
+   NHPs) and packet loss indications received since the last successful
+   context update.  Alternatively, it can be derived using the link
+   timing in the case where the linear mapping between RTP SN and link
+   timing is maintained.
+
+   On the transmitting side, the AL follows the same rule defined in
+   section 4.1.1 of [RFC3242] to determine whether it can send NHP or
+   not, with one modification.  That is, when the AL determines that it
+   has become unsafe (see section 2.2) to send NHPs, the AL records the
+   corresponding RTP SN as SN_break.  Then it waits until the rule is
+   satisfied again and SN_ACKed > SN_break before it resumes sending
+   NHPs.  The latter condition is essentially the counterpart of
+   optimistic approach agreement [RFC3242, section 4.3] of U/O-mode
+   which states that when the AL in U/O-mode determines it is unsafe to
+   send NHP, it must send headers in the subsequent X packets, where X
+   is some agreed number.  There are two reasons for the difference: a)
+   R-mode relies on acknowledgements to synchronize contexts, instead of
+   optimistic approach principle as in U/O-mode; and b) R-0 packets do
+   not update decompressor context while UO-0 packets do.  To meet the
+   condition SN_ACKed > SN_break, the AL can either wait passively for
+   the compressor to send a context update packet (e.g., R-0-CRC
+   triggered by 6-bit SN wrap-around), or send an update_request via the
+   interface from AL to the compressor (section 2.2) to request the
+   compressor to send a context updating packet.  The update_request
+   carries the last SN_break.  Upon receiving an update_request, the
+   compressor SHOULD use a context updating packet (e.g. R-0-CRC) when
+   sending the next packet.  Context updating packets are handled as in
+   [RFC3095].
+
+   Note: the passive waiting as described above might take a long time
+   in the worst case, during which NHPs cannot be sent.  Therefore,
+   sending update_request via the optional AL to compressor interface is
+   RECOMMENDED to improve the worst case performance.
+
+   Note: the update_request may be lost if the AL and compressor are at
+   different locations and the channel between them is unreliable, but
+   such a loss only delays the AL from resuming sending NHP.  Therefore,
+   how frequent the AL sends update_request is an implementation issue.
+   For example, the AL may send one update_request for each packet it
+   receives from the compressor until the conditions to send NHP are
+   met.
+
+
+
+
+
+Liu & Le                    Standards Track                     [Page 3]
+
+RFC 3408               0-byte Support for R-mode           December 2002
+
+
+   Note: as no CRC field is present in R-0 packets, only the function
+   related to RTP SN and packet type identifier needs to be replaced.
+   In addition, NHP packets and packet loss indications in R-mode do not
+   update either the compressor or the decompressor context (as opposed
+   to U/O-mode).  Consequently, the secure reference principle [RFC3095,
+   section 5.5] is not affected in any way and there is no loss of
+   robustness in this profile compared to ROHC RTP.
+
+4.  Differences between R-mode and U/O-mode
+
+   This section clarifies some differences between R-mode and U/O-mode
+   in this profile.
+
+   a) CRC replacement
+      Unlike U/O-mode, CRC replacement [RFC3242, section 3.3] is not an
+      issue for R-mode since R-0 packets do not carry CRC field.
+
+   b) Periodic context verification
+      For U/O-mode, periodic context verification [RFC3242, section 4.6]
+      is RECOMMENDED to provide additional protection against damage
+      propagation after CRC is replaced.  For R-mode, since there is no
+      CRC replacement (see above), no change to ROHC RTP is needed in
+      this regard.  In particular, R-mode has this feature naturally
+      built-in, since the sending of R-0-CRC when 6-bit SN wraps around
+      implicitly provides periodic context verification for R-mode.
+
+   c) CV-REQUEST option
+      For the same reasons as above, the decompressor operating in R-
+      mode SHOULD NOT send CV-REQUEST [RFC3242, section 4.5] to
+      compressor.  This is to avoid unnecessary overhead on the feedback
+      channel.
+
+   d) Context Check Packet (CCP)
+      When CCP [RFC3242, section 4.1.3] is used, compressor operating in
+      R-mode SHOULD set C-bit to 0 (zero) and not generate 7-bit CRC if
+      computation cost at compressor and decompressor causes concern.
+      The use of the CRC field in CCP to perform decompressor context
+      verification is not critical in R-mode (see last note of section 3
+      and item b) above).
+
+   e) Handling of Acknowledgements (ACKs)
+      Special care in the realization of ACKs should be taken for R-mode
+      implementations.  It is RECOMMENDED to avoid the use of
+      interspersed feedback packets [RFC3095, section 5.2.1] to carry
+      ACK information.  The reason is that interspersed feedback packets
+      will interrupt the RTP SN sequencing and thus temporarily disable
+      the sending of NHPs.
+
+
+
+
+Liu & Le                    Standards Track                     [Page 4]
+
+RFC 3408               0-byte Support for R-mode           December 2002
+
+
+5.  IANA Considerations
+
+   A ROHC profile identifier has been reserved by the IANA for the
+   profile defined in this document (0x0105), where 0x0005 is the
+   profile identifier assigned for LLA [RFC3242].
+
+6.  Security Considerations
+
+   The security considerations of ROHC RTP [RFC3095, section 7] apply
+   also to this document with one addition: in the case of a denial-of-
+   service attack scenario where an intruder injects bogus CCP packets
+   onto the link using random CRC values, the CRC check will fail for
+   incorrect reasons at the decompressor side.  This would obviously
+   greatly reduce the advantages of ROHC and any extra efficiency
+   provided by this profile due to unnecessary context invalidation,
+   feedback messages and refresh packets.  However, the same remarks
+   related to the presence of such an intruder apply.
+
+7.  Acknowledgements
+
+   The authors would like to thank Lars-Erik Jonsson and Ghyslain
+   Pelletier for intriguing discussions on LLA that helped to nail down
+   the R-mode operation.  The authors also appreciate valuable input
+   from Carsten Bormann, Christopher Clanton, Mark Cheng, and Thinh
+   Nguyenphu.
+
+8.  References
+
+   [RFC3242]   Jonsson, L. and G. Pelletier, "RObust Header Compression
+               (ROHC): A Link-Layer Assisted Profile for IP/UDP/RTP",
+               RFC 3242, April 2002.
+
+   [RFC3095]   Bormann, C., Burmeister, C., Degermark, M., Fukushima,
+               H., Hannu, H., Jonsson, L., Hakenberg, R., Koren, T., Le,
+               K., Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K.,
+               Wiebke, T., Yoshimura, T. and H. Zheng, "RObust Header
+               Compression (ROHC): Framework and four profiles: RTP,
+               UDP, ESP, and uncompressed", RFC 3095, July 2001.
+
+   [RFC2119]   Bradner, S., "Key words for use in RFCs to indicate
+               requirement levels", BCP 14, RFC 2119, March 1997.
+
+
+
+
+
+
+
+
+
+
+Liu & Le                    Standards Track                     [Page 5]
+
+RFC 3408               0-byte Support for R-mode           December 2002
+
+
+9.  Authors' Addresses
+
+   Zhigang Liu
+   Nokia Research Center
+   6000 Connection Drive
+   Irving, TX 75039
+   USA
+
+   Phone: +1 972 894-5935
+   Fax:   +1 972 894-4589
+   EMail  zhigang.c.liu@nokia.com
+
+
+   Khiem Le
+   Nokia Research Center
+   6000 Connection Drive
+   Irving, TX 75039
+   USA
+
+   Phone: +1 972 894-4882
+   Fax:   +1 972 894-4589
+   EMail: khiem.le@nokia.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Liu & Le                    Standards Track                     [Page 6]
+
+RFC 3408               0-byte Support for R-mode           December 2002
+
+
+10.  Full Copyright Statement
+
+   Copyright (C) The Internet Society (2002).  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assigns.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS 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.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Liu & Le                    Standards Track                     [Page 7]
+