doc: Add RFC documents

1 files changed, 619 insertions, 0 deletions

diff --git a/doc/rfc/rfc6683.txt b/doc/rfc/rfc6683.txt
new file mode 100644
index 0000000..061e598
--- /dev/null
+++ b/doc/rfc/rfc6683.txt
@@ -0,0 +1,619 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                          A. Begen
+Request for Comments: 6683                                         Cisco
+Category: Informational                                   T. Stockhammer
+ISSN: 2070-1721                                           Nomor Research
+                                                             August 2012
+
+
+Guidelines for Implementing Digital Video Broadcasting - IPTV (DVB-IPTV)
+   Application-Layer Hybrid Forward Error Correction (FEC) Protection
+
+Abstract
+
+   Annex E of the Digital Video Broadcasting - IPTV (DVB-IPTV) technical
+   specification defines an optional Application-Layer Forward Error
+   Correction (AL-FEC) protocol to protect the streaming media
+   transported using RTP.  The DVB-IPTV AL-FEC protocol uses two layers
+   for FEC protection.  The first (base) layer is based on the 1-D
+   interleaved parity code.  The second (enhancement) layer is based on
+   the Raptor code.  By offering a layered approach, the DVB-IPTV AL-FEC
+   protocol offers good protection against both bursty and random packet
+   losses at a cost of decent complexity.  This document describes how
+   one can implement the DVB-IPTV AL-FEC protocol by using the 1-D
+   interleaved parity code and Raptor code that have already been
+   specified in separate documents.
+
+Status of This Memo
+
+   This document is not an Internet Standards Track specification; it is
+   published for informational purposes.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Not all documents
+   approved by the IESG are a candidate for any level of Internet
+   Standard; see Section 2 of RFC 5741.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   http://www.rfc-editor.org/info/rfc6683.
+
+
+
+
+
+
+
+
+
+
+
+Begen & Stockhammer           Informational                     [Page 1]
+
+RFC 6683           Guidelines for DVB AL-FEC Protocol        August 2012
+
+
+Copyright Notice
+
+   Copyright (c) 2012 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (http://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+   include Simplified BSD License text as described in Section 4.e of
+   the Trust Legal Provisions and are provided without warranty as
+   described in the Simplified BSD License.
+
+Table of Contents
+
+   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  2
+   2.  DVB-IPTV AL-FEC Specification  . . . . . . . . . . . . . . . .  5
+     2.1.  Base-Layer FEC . . . . . . . . . . . . . . . . . . . . . .  5
+     2.2.  Enhancement-Layer FEC  . . . . . . . . . . . . . . . . . .  7
+     2.3.  Hybrid Decoding Procedures . . . . . . . . . . . . . . . .  7
+   3.  Session Description Protocol (SDP) Signaling . . . . . . . . .  8
+   4.  Security Considerations  . . . . . . . . . . . . . . . . . . .  9
+   5.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . .  9
+   6.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
+     6.1.  Normative References . . . . . . . . . . . . . . . . . . . 10
+     6.2.  Informative References . . . . . . . . . . . . . . . . . . 10
+
+1.  Introduction
+
+   In 2007, the IP Infrastructure (IPI) Technical Module (TM) of the
+   Digital Video Broadcasting (DVB) consortium published a technical
+   specification [ETSI-TS-102-034v1.3.1] through the European
+   Telecommunications Standards Institute (ETSI).
+   [ETSI-TS-102-034v1.3.1] covers several areas related to the
+   transmission of MPEG2 transport stream-based services over IP
+   networks.
+
+   Annex E of [ETSI-TS-102-034v1.3.1] defines an optional protocol for
+   Application-Layer Forward Error Correction (AL-FEC) to protect the
+   streaming media for DVB-IP services transported using RTP [RFC3550].
+   In 2009, DVB updated the specification in a new revision that is
+   available as [ETSI-TS-102-034v1.4.1].  Among others, some updates and
+   modifications to the AL-FEC protocol have been made.  This document
+   describes how one can implement the DVB-IPTV AL-FEC protocol by using
+   the 1-D interleaved parity code [RFC6015] and Raptor code
+   specifications [RFC6681] [RFC6682].
+
+
+
+Begen & Stockhammer           Informational                     [Page 2]
+
+RFC 6683           Guidelines for DVB AL-FEC Protocol        August 2012
+
+
+   The DVB-IPTV AL-FEC protocol uses two layers for protection:  a base
+   layer that is produced by the 1-D interleaved parity code (also
+   simply referred to as "parity code" in the remainder of this
+   document), and an enhancement layer that is produced by the Raptor
+   code.  Whenever a receiver supports the DVB-IPTV AL-FEC protocol, the
+   decoding support for the base-layer FEC is mandatory while the
+   decoding support for the enhancement-layer FEC is optional.  Both the
+   interleaved parity code and the Raptor code are systematic FEC codes,
+   meaning that source packets are not modified in any way during the
+   FEC encoding process.
+
+   The DVB-IPTV AL-FEC protocol considers protection of single-sequence
+   source RTP flows only.  In the AL-FEC protocol, the source stream can
+   only be an MPEG-2 transport stream.  The FEC data at each layer are
+   generated based on some configuration information, which also
+   determines the exact associations and relationships between the
+   source and repair packets.  This document shows how this
+   configuration may be communicated out-of-band in the Session
+   Description Protocol (SDP) [RFC4566].
+
+   In DVB-IPTV AL-FEC, the source packets are carried in the source RTP
+   stream and the generated FEC repair packets at each layer are carried
+   in separate streams.  At the receiver side, if all of the source
+   packets are successfully received, there is no need for FEC recovery
+   and the repair packets may be discarded.  However, if there are
+   missing source packets, the repair packets can be used to recover the
+   missing information.
+
+   The block diagram of the encoder side for the systematic DVB-IPTV
+   AL-FEC protection is described in Figure 1.  Here, the source packets
+   are fed into the parity encoder to produce the parity repair packets.
+   The source packets may also be fed to the Raptor encoder to produce
+   the Raptor repair packets.  Source packets as well as the repair
+   packets are then sent to the receiver(s) over an IP network.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Begen & Stockhammer           Informational                     [Page 3]
+
+RFC 6683           Guidelines for DVB AL-FEC Protocol        August 2012
+
+
+                              +--------------+
+   +--+  +--+  +--+  +--+ --> |  Systematic  | -> +--+  +--+  +--+  +--+
+   +--+  +--+  +--+  +--+     |FEC Protection|    +--+  +--+  +--+  +--+
+                              +--------------+
+                              |    Parity    | -> +==+  +==+  +==+
+                              |    Encoder   |    +==+  +==+  +==+
+                              +--------------+
+                              |    Raptor    | -> +~~+  +~~+
+                              |    Encoder   |    +~~+  +~~+
+                              +--------------+
+
+   Source Packet: +--+
+                  +--+
+
+   Base-layer Repair Packet: +==+
+                             +==+
+
+   Enhancement-layer Repair Packet: +~~+
+                                    +~~+
+
+          Figure 1: Block Diagram for the DVB-IPTV AL-FEC Encoder
+
+   The block diagram of the decoder side for the systematic DVB-IPTV
+   AL-FEC protection is described in Figure 2.  This is a minimum
+   performance decoder since the receiver only supports decoding the
+   base-layer repair packets.  If there is a loss among the source
+   packets, the parity decoder attempts to recover the missing source
+   packets by using the base-layer repair packets.
+
+                              +--------------+
+   +--+   X     X    +--+ --> |  Systematic  | -> +--+  +--+  +--+  +--+
+   +--+              +--+     |FEC Protection|    +--+  +--+  +--+  +--+
+                              +--------------+
+         +==+  +==+  +==+ --> |    Parity    |
+         +==+  +==+  +==+     |    Decoder   |
+                              +--------------+
+
+   Lost Packet: X
+
+    Figure 2: Block Diagram for the DVB-IPTV AL-FEC Minimum Performance
+                                  Decoder
+
+   On the other hand, if the receiver supports decoding both the base-
+   layer and enhancement-layer repair packets, a combined (hybrid)
+   decoding approach is employed to improve the recovery rate of the
+   lost packets.  In this case, the decoder is called an enhanced
+   decoder.  Section 2.3 outlines the procedures for hybrid decoding.
+
+
+
+
+Begen & Stockhammer           Informational                     [Page 4]
+
+RFC 6683           Guidelines for DVB AL-FEC Protocol        August 2012
+
+
+                              +--------------+
+   +--+   X     X     X   --> |  Systematic  | -> +--+  +--+  +--+  +--+
+   +--+                       |FEC Protection|    +--+  +--+  +--+  +--+
+                              +--------------+
+         +==+  +==+  +==+ --> |    Parity    |
+         +==+  +==+  +==+     |    Decoder   |
+                              +--------------+
+               +~~+  +~~+ --> |    Raptor    |
+               +~~+  +~~+     |    Decoder   |
+                              +--------------+
+
+   Lost Packet: X
+
+     Figure 3: Block Diagram for the DVB-IPTV AL-FEC Enhanced Decoder
+
+2.  DVB-IPTV AL-FEC Specification
+
+   The DVB-IPTV AL-FEC protocol comprises two layers of FEC protection:
+   1-D interleaved parity FEC for the base layer and Raptor FEC for the
+   enhancement layer.  The performance of these FEC codes has been
+   examined in detail in [DVB-A115].
+
+2.1.  Base-Layer FEC
+
+   The 1-D interleaved parity FEC uses the exclusive OR (XOR) operation
+   to generate the repair symbols.  In a group of D x L source packets,
+   the XOR operation is applied to each group of D source packets whose
+   sequence numbers are L apart from each other to generate a total of L
+   repair packets.  Due to interleaving, this FEC is effective against
+   bursty packet losses up to burst sizes of length L.
+
+   The DVB-IPTV AL-FEC protocol requires that the D x L block of the
+   source packets protected by the 1-D interleaved FEC code be wholly
+   contained within a single source block of the Raptor code, if both
+   FEC layers are used.
+
+   Originally, the DVB-IPTV AL-FEC protocol had adopted the 1-D
+   interleaved FEC payload format from [SMPTE2022-1] in
+   [ETSI-TS-102-034v1.3.1].  However, some incompatibilities with RTP
+   [RFC3550] have been discovered in this specification.  These issues
+   have all been addressed in [RFC6015] (for details, refer to Section 1
+   of [RFC6015]).  Some of the changes required by [RFC6015] are,
+   however, not backward compatible with the existing implementations
+   that were based on [SMPTE2022-1].
+
+   In a recent liaison statement from the IETF AVT WG to DVB TM-IPI, it
+   has been recommended that DVB TM-IPI define a new RTP profile for the
+
+
+
+
+Begen & Stockhammer           Informational                     [Page 5]
+
+RFC 6683           Guidelines for DVB AL-FEC Protocol        August 2012
+
+
+   AL-FEC protocol since in the new profile, several of the issues could
+   easily be addressed without jeopardizing the compliance to RTP
+   [RFC3550].
+
+   At the writing of this document, it was not clear whether or not a
+   new RTP profile would be defined for the AL-FEC protocol.  DVB TM-IPI
+   attempted to address some of the issues in the updated specification
+   [ETSI-TS-102-034v1.4.1]; however, there are still outstanding issues.
+
+   The following is a list of the exceptions that need to be considered
+   by an implementation adopting [RFC6015] to be compliant with the DVB-
+   IPTV AL-FEC protocol as specified in [ETSI-TS-102-034v1.4.1].
+
+   o  SSRC (synchronization source)
+      The DVB-IPTV AL-FEC protocol requires that the SSRC fields of the
+      FEC packets be set to zero.
+
+      This requirement conflicts with RTP [RFC3550].  Unless signaled
+      otherwise, RTP uses random SSRC values with collision detection.
+      An explicit SSRC signaling mechanism is currently defined in
+      [RFC5576] and can be used for this purpose.
+
+   o  CSRC (contributing source)
+      The DVB-IPTV AL-FEC protocol does not support the protection of
+      the CSRC entries in the source packets.  Thus, in an
+      implementation compliant to DVB-IPTV AL-FEC protocol, the source
+      stream must not have any CSRC entries in its packets, and
+      subsequently the CC fields of the source RTP packets will be zero.
+
+      Note that if there are no RTP mixers used in a system running the
+      DVB-IPTV AL-FEC protocol, the CC field of the source RTP packets
+      will be zero and this is no longer an issue.  Thus, if defined,
+      the new RTP profile for the DVB-IPTV AL-FEC protocol should forbid
+      the use of any RTP mixers.
+
+   o  Timestamp
+      In the DVB-IPTV AL-FEC protocol, the timestamp fields of the FEC
+      packets are ignored by the receivers.
+
+   o  Payload Type
+      The DVB-IPTV AL-FEC protocol sets the PT fields of the FEC packets
+      to 96.
+
+      A static payload type assignment for the base-layer FEC packets is
+      outside the scope of [RFC6015].  If defined, the new RTP profile
+      for the DVB-IPTV AL-FEC protocol may assign 96 as the payload type
+      for the base-layer FEC packets.
+
+
+
+
+Begen & Stockhammer           Informational                     [Page 6]
+
+RFC 6683           Guidelines for DVB AL-FEC Protocol        August 2012
+
+
+   In implementations that are based on [RFC6015] and are willing to be
+   compliant with the DVB-IPTV AL-FEC protocol as specified in
+   [ETSI-TS-102-034v1.3.1], all these exceptions must be considered as
+   well; however, in this case, the sender does not have to select a
+   random initial sequence number for the FEC stream as suggested by
+   [RFC3550].
+
+   Note that neither [ETSI-TS-102-034v1.3.1] nor [ETSI-TS-102-034v1.4.1]
+   implements the 1-D interleaved parity code as specified in [RFC6015].
+   Thus, the payload format registered in [RFC6015] must not be used by
+   the implementations that are compliant with the
+   [ETSI-TS-102-034v1.3.1] or [ETSI-TS-102-034v1.4.1] specification.
+
+2.2.  Enhancement-Layer FEC
+
+   The Raptor code is a fountain code where as many encoding symbols as
+   needed can be generated by the encoder on-the-fly from source data.
+   Due to the fountain property of the Raptor code, multiple enhancement
+   layers may also be specified, if needed.
+
+   The details of the Raptor code are provided in [RFC6681].  The FEC
+   scheme for the enhancement layer SHALL be the Raptor FEC scheme for a
+   Single Sequenced Flow with FEC encoding ID 5.  The RTP payload format
+   for Raptor FEC is specified in [RFC6682].
+
+   It is important to note that the DVB-IPTV AL-FEC protocol in the
+   latest specification [ETSI-TS-102-034v1.4.1] allows both UDP-only and
+   RTP-over-UDP encapsulations for the enhancement-layer FEC stream.
+   The initial specification [ETSI-TS-102-034v1.3.1] exclusively permits
+   UDP-only encapsulation for the enhancement-layer FEC stream.
+
+   When SDP is used for signaling, the transport protocol identifier
+   indicates whether an RTP-over-UDP or UDP-only encapsulation is used.
+   In case of any other signaling framework, the differentiation of the
+   protocol for the enhancement-layer stream is achieved either
+   explicitly through a protocol identifier or implicitly by the version
+   number of the DVB IPTV Handbook.  If none of the above signaling is
+   provided, the receiver shall concur from the packet size of the
+   repair packets if RTP-over-UDP or UDP-only encapsulation is used.
+
+2.3.  Hybrid Decoding Procedures
+
+   The receivers that support receiving and decoding both the base- and
+   enhancement-layer FEC perform hybrid decoding to improve the repair
+   performance.  The following steps may be followed to perform hybrid
+   decoding:
+
+
+
+
+
+Begen & Stockhammer           Informational                     [Page 7]
+
+RFC 6683           Guidelines for DVB AL-FEC Protocol        August 2012
+
+
+   1.  Base-layer (Parity) Decoding:  In this step, the repair packets
+       that are encoded by the parity encoder are processed as usual to
+       repair as many missing source packets as possible.
+
+   2.  Enhancement-layer (Raptor) Decoding:  If there are still missing
+       source packets after the first step, the repair packets that are
+       Raptor encoded are processed with the source packets already
+       received and the source packets that are recovered in the first
+       step.
+
+   3.  Hybrid Decoding:  If there are still missing source packets after
+       the second step, the unprocessed base-layer (parity) repair
+       packets are converted to a form in which they can be added to the
+       Raptor decoding process.  With this additional information,
+       Raptor decoding may potentially recover any remaining missing
+       source packet.
+
+   The procedure that should be followed to benefit from the base-layer
+   repair packets in the Raptor decoding process is explained in detail
+   in Annex E.5.2 of [ETSI-TS-102-034v1.4.1].
+
+3.  Session Description Protocol (SDP) Signaling
+
+   This section provides an SDP [RFC4566] example for
+   [ETSI-TS-102-034v1.4.1].  The example uses the FEC grouping semantics
+   [RFC5956].
+
+   In the example, we have one source video stream (mid:S1), one FEC
+   repair stream (mid:R1) that is produced by the 1-D interleaved parity
+   FEC code, as well as another FEC repair stream (mid:R2) that is
+   produced by the Raptor FEC code.  We form one FEC group with the
+   "a=group:FEC-FR S1 R1 R2" line.  The source and repair streams are
+   sent to the same port on different multicast groups.  The source,
+   base-layer FEC, and enhancement-layer FEC streams are all
+   encapsulated in RTP.
+
+   Due to the exceptions described in Section 2.1, a
+   [ETSI-TS-102-034v1.4.1]-compliant implementation must not use the RTP
+   payload format defined in [RFC6015].  Instead, it may use the payload
+   format that has been registered by DVB TM-IPI for
+   [ETSI-TS-102-034v1.3.1].
+
+
+
+
+
+
+
+
+
+
+Begen & Stockhammer           Informational                     [Page 8]
+
+RFC 6683           Guidelines for DVB AL-FEC Protocol        August 2012
+
+
+        v=0
+        o=ali 1122334455 1122334466 IN IP4 fec.example.com
+        s=DVB-IPTV AL-FEC Example
+        t=0 0
+        a=group:FEC-FR S1 R1 R2
+        m=video 30000 RTP/AVP 100
+        c=IN IP4 233.252.0.1/127
+        a=rtpmap:100 MP2T/90000
+        a=mid:S1
+        m=application 30000 RTP/AVP 96
+        c=IN IP4 233.252.0.2/127
+        a=rtpmap:96 vnd.dvb.iptv.alfec-base/90000
+        a=mid:R1
+        m=application 30000 RTP/AVP 111
+        c=IN IP4 233.252.0.3/127
+        a=rtpmap:111 vnd.dvb.iptv.alfec-enhancement/90000
+        a=mid:R2
+
+   Note that in the example above, the payload type has been chosen as
+   96 for the base-layer FEC stream and there is no "a=fmtp:" line to
+   specify the format parameters.  Due to the lack of the format
+   parameters for "vnd.dvb.iptv.alfec-base", it is not possible to learn
+   the FEC parameters from the SDP description.
+
+4.  Security Considerations
+
+   This specification adds no new security considerations to the DVB-
+   IPTV AL-FEC protocol.
+
+5.  Acknowledgments
+
+   This document is based on [ETSI-TS-102-034v1.3.1] and
+   [ETSI-TS-102-034v1.4.1].  Thus, the authors would like to thank the
+   editors of [ETSI-TS-102-034v1.3.1] and [ETSI-TS-102-034v1.4.1].  The
+   authors also would like to thank those who reviewed earlier versions
+   of this document.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Begen & Stockhammer           Informational                     [Page 9]
+
+RFC 6683           Guidelines for DVB AL-FEC Protocol        August 2012
+
+
+6.  References
+
+6.1.  Normative References
+
+   [ETSI-TS-102-034v1.3.1]
+              ETSI TS 102 034 V1.3.1, "Transport of MPEG 2 TS Based DVB
+              Services over IP Based Networks", October 2007.
+
+   [ETSI-TS-102-034v1.4.1]
+              ETSI TS 102 034 V1.4.1, "Transport of MPEG 2 TS Based DVB
+              Services over IP Based Networks", August 2009.
+
+   [RFC6015]  Begen, A., "RTP Payload Format for 1-D Interleaved Parity
+              Forward Error Correction (FEC)", RFC 6015, October 2010.
+
+   [RFC6681]  Watson, M., Stockhammer, T., and M. Luby, "Raptor FEC
+              Schemes for FECFRAME", RFC RFC6681, August 2012.
+
+   [RFC6682]  Watson, M., Stockhammer, T., and M. Luby, "RTP Payload
+              Format for Raptor Forward Error Correction (FEC)",
+              RFC 6682, August 2012.
+
+   [RFC3550]  Schulzrinne, H., Casner, S., Frederick, R., and V.
+              Jacobson, "RTP: A Transport Protocol for Real-Time
+              Applications", STD 64, RFC 3550, July 2003.
+
+   [RFC5576]  Lennox, J., Ott, J., and T. Schierl, "Source-Specific
+              Media Attributes in the Session Description Protocol
+              (SDP)", RFC 5576, June 2009.
+
+   [RFC4566]  Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
+              Description Protocol", RFC 4566, July 2006.
+
+   [RFC5956]  Begen, A., "Forward Error Correction Grouping Semantics in
+              the Session Description Protocol", RFC 5956,
+              September 2010.
+
+6.2.  Informative References
+
+   [DVB-A115]
+              "DVB Application Layer FEC Evaluations (DVB Document
+              A115)", May 2007, <http://www.dvb.org/technology/
+              standards/a115.tm3783.AL-FEC_Evaluation.pdf>.
+
+   [SMPTE2022-1]
+              SMPTE 2022-1-2007, "Forward Error Correction for Real-Time
+              Video/Audio Transport over IP Networks", 2007.
+
+
+
+
+Begen & Stockhammer           Informational                    [Page 10]
+
+RFC 6683           Guidelines for DVB AL-FEC Protocol        August 2012
+
+
+Authors' Addresses
+
+   Ali Begen
+   Cisco
+   181 Bay Street
+   Toronto, ON  M5J 2T3
+   Canada
+
+   EMail:  abegen@cisco.com
+
+
+   Thomas Stockhammer
+   Nomor Research
+   Brecherspitzstrasse 8
+   Munich,   81541
+   Germany
+
+   EMail:  stockhammer@nomor.de
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Begen & Stockhammer           Informational                    [Page 11]
+