doc: Add RFC documents

1 files changed, 563 insertions, 0 deletions

diff --git a/doc/rfc/rfc7104.txt b/doc/rfc/rfc7104.txt
new file mode 100644
index 0000000..3cc25a3
--- /dev/null
+++ b/doc/rfc/rfc7104.txt
@@ -0,0 +1,563 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                          A. Begen
+Request for Comments: 7104                                         Cisco
+Category: Standards Track                                         Y. Cai
+ISSN: 2070-1721                                                Microsoft
+                                                                   H. Ou
+                                                                   Cisco
+                                                            January 2014
+
+
+   Duplication Grouping Semantics in the Session Description Protocol
+
+Abstract
+
+   Packet loss is undesirable for real-time multimedia sessions, but it
+   can occur due to congestion or other unplanned network outages.  This
+   is especially true for IP multicast networks, where packet loss
+   patterns can vary greatly between receivers.  One technique that can
+   be used to recover from packet loss without incurring unbounded delay
+   for all the receivers is to duplicate the packets and send them in
+   separate redundant streams.  This document defines the semantics for
+   grouping redundant streams in the Session Description Protocol (SDP).
+   The semantics defined in this document are to be used with the SDP
+   Grouping Framework.  Grouping semantics at the Synchronization Source
+   (SSRC) level are also defined in this document for RTP streams using
+   SSRC multiplexing.
+
+Status of This Memo
+
+   This is an Internet Standards Track document.
+
+   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).  Further information on
+   Internet Standards is available in 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/rfc7104.
+
+
+
+
+
+
+
+
+
+
+
+
+Begen, et al.                Standards Track                    [Page 1]
+
+RFC 7104          Duplication Grouping Semantics in SDP     January 2014
+
+
+Copyright Notice
+
+   Copyright (c) 2014 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. Requirements Notation ...........................................3
+   3. Duplication Grouping ............................................3
+      3.1. "DUP" Grouping Semantics ...................................3
+      3.2. Duplication Grouping for SSRC-Multiplexed RTP Streams ......3
+      3.3. SDP Offer/Answer Model Considerations ......................4
+   4. SDP Examples ....................................................5
+      4.1. Separate Source Addresses ..................................5
+      4.2. Separate Destination Addresses .............................6
+      4.3. Temporal Redundancy ........................................7
+   5. Security Considerations .........................................7
+   6. IANA Considerations .............................................8
+   7. Acknowledgments .................................................8
+   8. References ......................................................8
+      8.1. Normative References .......................................8
+      8.2. Informative References .....................................9
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Begen, et al.                Standards Track                    [Page 2]
+
+RFC 7104          Duplication Grouping Semantics in SDP     January 2014
+
+
+1.  Introduction
+
+   The Real-time Transport Protocol (RTP) [RFC3550] is widely used today
+   for delivering IPTV traffic and other real-time multimedia sessions.
+   Many of these applications support very large numbers of receivers
+   and rely on intra-domain UDP/IP multicast for efficient distribution
+   of traffic within the network.
+
+   While this combination has proved successful, there does exist a
+   weakness.  As [RFC2354] noted, packet loss is not avoidable, even in
+   a carefully managed network.  This loss might be due to congestion;
+   it might also be a result of an unplanned outage caused by a flapping
+   link, a link or interface failure, a software bug, or a maintenance
+   person accidentally cutting the wrong fiber.  Since UDP/IP flows do
+   not provide any means for detecting loss and retransmitting packets,
+   it is left up to the RTP layer and the applications to detect, and
+   recover from, packet loss.
+
+   One technique to recover from packet loss without incurring unbounded
+   delay for all the receivers is to duplicate the packets and send them
+   in separate redundant streams.  Variations on this idea have been
+   implemented and deployed today [IC2011].  [RTP-DUP] explains how
+   duplication can be achieved for RTP streams without breaking the RTP
+   and RTP Control Protocol (RTCP) functionality.  In this document, we
+   describe the semantics needed in the Session Description Protocol
+   (SDP) [RFC4566] to support this technique.
+
+2.  Requirements Notation
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
+   "OPTIONAL" in this document are to be interpreted as described in
+   [RFC2119].
+
+3.  Duplication Grouping
+
+3.1.  "DUP" Grouping Semantics
+
+   Each "a=group" line is used to indicate an association relationship
+   between the redundant streams.  The streams included in one "a=group"
+   line are called a "Duplication Group".
+
+   Using the SDP Grouping Framework in [RFC5888], this document defines
+   "DUP" as the grouping semantics for redundant streams.
+
+
+
+
+
+
+
+Begen, et al.                Standards Track                    [Page 3]
+
+RFC 7104          Duplication Grouping Semantics in SDP     January 2014
+
+
+   The "a=group:DUP" semantics MUST be used to group the redundant
+   streams, except when the streams are specified in the same media
+   description, i.e., in the same "m" line (see Section 3.2).  In an
+   "a=group:DUP" line, the order of the listed redundant streams does
+   not strictly indicate the order of transmission, although it is
+   RECOMMENDED that the stream listed first be sent first, with the
+   other stream(s) being the (time-delayed) duplicate(s).
+
+3.2.  Duplication Grouping for SSRC-Multiplexed RTP Streams
+
+   [RFC5576] defines an SDP media-level attribute, called "ssrc-group",
+   for grouping the RTP streams that are SSRC multiplexed and carried in
+   the same RTP session.  The grouping is based on the SSRC identifiers.
+   Since SSRC-multiplexed RTP streams are defined in the same "m" line,
+   the "group" attribute cannot be used.
+
+   This section explains how duplication is used with SSRC-multiplexed
+   streams using the "ssrc-group" attribute [RFC5576].
+
+   The semantics of "DUP" for the "ssrc-group" attribute are the same as
+   the one defined for the "group" attribute, except that the SSRC
+   identifiers are used to designate the duplication grouping
+   associations: a=ssrc-group:DUP *(SP ssrc-id) [RFC5576].  As above,
+   while in an "a=ssrc-group:DUP" line, the order of the listed
+   redundant streams does not necessarily indicate the order of
+   transmission, but it is RECOMMENDED that the stream listed first be
+   sent first, with the other stream(s) being the (time-delayed)
+   duplicate(s).
+
+3.3.  SDP Offer/Answer Model Considerations
+
+   When offering duplication grouping using SDP in an offer/answer model
+   [RFC3264], the following considerations apply.
+
+   A node that is receiving an offer from a sender may or may not
+   understand line grouping.  It is also possible that the node
+   understands line grouping but does not understand the "DUP"
+   semantics.  From the viewpoint of the sender of the offer, these
+   cases are indistinguishable.
+
+   When a node is offered a session with the "DUP" grouping semantics
+   but it does not support line grouping or the duplication grouping
+   semantics, as per [RFC5888], the node responds to the offer either
+   (1) with an answer that omits the grouping attribute or (2) with a
+   refusal to the request (e.g., "488 Not Acceptable Here" or "606 Not
+   Acceptable in SIP").
+
+
+
+
+
+Begen, et al.                Standards Track                    [Page 4]
+
+RFC 7104          Duplication Grouping Semantics in SDP     January 2014
+
+
+   In the first case, the original sender of the offer must send a new
+   offer without any duplication grouping.  In the second case, if the
+   sender of the offer still wishes to establish the session, it should
+   retry the request with an offer without the duplication grouping.
+   This behavior is specified in [RFC5888].
+
+4.  SDP Examples
+
+4.1.  Separate Source Addresses
+
+   In this example, the redundant streams use the same IP destination
+   address (232.252.0.1), but they are sourced from different addresses
+   (198.51.100.1 and 198.51.100.2).  Thus, the receiving host needs to
+   join both source-specific multicast (SSM) sessions separately.
+
+       v=0
+       o=ali 1122334455 1122334466 IN IP4 dup.example.com
+       s=DUP Grouping Semantics
+       t=0 0
+       m=video 30000 RTP/AVP 100
+       c=IN IP4 233.252.0.1/127
+       a=source-filter:incl IN IP4 233.252.0.1 198.51.100.1 198.51.100.2
+       a=rtpmap:100 MP2T/90000
+       a=ssrc:1000 cname:ch1@example.com
+       a=ssrc:1010 cname:ch1@example.com
+       a=ssrc-group:DUP 1000 1010
+       a=mid:Ch1
+
+   Note that in actual use, SSRC values, which are random 32-bit
+   numbers, can be much larger than the ones shown in this example.
+   Also, note that this SDP description does not use the "duplication-
+   delay" attribute (defined in [DELAYED-DUP]) since the sender does not
+   apply any delay between the redundant streams upon transmission.
+   Alternatively, one MAY explicitly insert an "a=duplication-delay:0"
+   line before the "a=mid:Ch1" line for informational purposes.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Begen, et al.                Standards Track                    [Page 5]
+
+RFC 7104          Duplication Grouping Semantics in SDP     January 2014
+
+
+4.2.  Separate Destination Addresses
+
+   In this example, the redundant streams have different IP destination
+   addresses.  The example shows the same UDP port number and IP source
+   address for each stream, but either or both could have been different
+   for the two streams.
+
+        v=0
+        o=ali 1122334455 1122334466 IN IP4 dup.example.com
+        s=DUP Grouping Semantics
+        t=0 0
+        a=group:DUP S1a S1b
+        m=video 30000 RTP/AVP 100
+        c=IN IP4 233.252.0.1/127
+        a=source-filter:incl IN IP4 233.252.0.1 198.51.100.1
+        a=rtpmap:100 MP2T/90000
+        a=mid:S1a
+        m=video 30000 RTP/AVP 101
+        c=IN IP4 233.252.0.2/127
+        a=source-filter:incl IN IP4 233.252.0.2 198.51.100.1
+        a=rtpmap:101 MP2T/90000
+        a=mid:S1b
+
+   Optionally, one could be more explicit and insert an
+   "a=duplication-delay:0" line before the first "m" line.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Begen, et al.                Standards Track                    [Page 6]
+
+RFC 7104          Duplication Grouping Semantics in SDP     January 2014
+
+
+4.3.  Temporal Redundancy
+
+   In this example, the redundant streams have the same IP source and
+   destination addresses (i.e., they are transmitted in the same SSM
+   session).  Due to the same source and destination addresses, the
+   packets in both streams will be routed over the same path.  To
+   provide resiliency against packet loss, the duplicate of an original
+   packet is transmitted 50 milliseconds (ms) later as indicated by the
+   "duplication-delay" attribute (defined in [DELAYED-DUP]).
+
+        v=0
+        o=ali 1122334455 1122334466 IN IP4 dup.example.com
+        s=Delayed Duplication
+        t=0 0
+        m=video 30000 RTP/AVP 100
+        c=IN IP4 233.252.0.1/127
+        a=source-filter:incl IN IP4 233.252.0.1 198.51.100.1
+        a=rtpmap:100 MP2T/90000
+        a=ssrc:1000 cname:ch1a@example.com
+        a=ssrc:1010 cname:ch1a@example.com
+        a=ssrc-group:DUP 1000 1010
+        a=duplication-delay:50
+        a=mid:Ch1
+
+5.  Security Considerations
+
+   In general, the security considerations of [RFC4566] apply to this
+   document as well.
+
+   There is a weak threat for the receiver that the duplication grouping
+   can be modified to indicate relationships that do not exist.  Such
+   attacks might result in failure of the duplication mechanisms and/or
+   mishandling of the media streams by the receivers.
+
+   In order to avoid attacks of this sort, the SDP description needs to
+   be integrity protected and provided with source authentication.  This
+   can, for example, be achieved on an end-to-end basis using S/MIME
+   [RFC5652] [RFC5751] when the SDP is used in a signaling packet using
+   MIME types (application/sdp).  Alternatively, HTTPS [RFC2818] or the
+   authentication method in the Session Announcement Protocol (SAP)
+   [RFC2974] could be used as well.  As for the confidentiality, if it
+   is desired, it can be useful to use a secure, encrypted transport
+   method to carry the SDP description.
+
+
+
+
+
+
+
+
+Begen, et al.                Standards Track                    [Page 7]
+
+RFC 7104          Duplication Grouping Semantics in SDP     January 2014
+
+
+6.  IANA Considerations
+
+   This document registers the following semantics with IANA in the
+   "Semantics for the "group" SDP Attribute" subregistry (under the
+   "Session Description Protocol (SDP) Parameters" registry:
+
+   Semantics                              Token   Reference
+   -------------------------------------  ------  ---------
+   Duplication                            DUP     [RFC7104]
+
+   This document also registers the following semantics with IANA in the
+   "Semantics for the "ssrc-group" SDP Attribute" subregistry under the
+   "Session Description Protocol (SDP) Parameters" registry:
+
+   Token    Semantics                      Reference
+   -------  -----------------------------  ---------
+   DUP      Duplication                    [RFC7104]
+
+7.  Acknowledgments
+
+   The authors would like to thank Colin Perkins, Bill Ver Steeg, Dave
+   Oran, and Toerless Eckert for their input and suggestions.
+
+8.  References
+
+8.1.  Normative References
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC3264]  Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
+              with Session Description Protocol (SDP)", RFC 3264, June
+              2002.
+
+   [RFC3550]  Schulzrinne, H., Casner, S., Frederick, R., and V.
+              Jacobson, "RTP: A Transport Protocol for Real-Time
+              Applications", STD 64, RFC 3550, July 2003.
+
+   [RFC4566]  Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
+              Description Protocol", RFC 4566, July 2006.
+
+   [RFC5576]  Lennox, J., Ott, J., and T. Schierl, "Source-Specific
+              Media Attributes in the Session Description Protocol
+              (SDP)", RFC 5576, June 2009.
+
+   [RFC5888]  Camarillo, G. and H. Schulzrinne, "The Session Description
+              Protocol (SDP) Grouping Framework", RFC 5888, June 2010.
+
+
+
+
+Begen, et al.                Standards Track                    [Page 8]
+
+RFC 7104          Duplication Grouping Semantics in SDP     January 2014
+
+
+8.2.  Informative References
+
+   [DELAYED-DUP]
+              Begen, A., Cai, Y., and H. Ou, "Delayed Duplication
+              Attribute in the Session Description Protocol", Work in
+              Progress, December 2013.
+
+   [IC2011]   Evans, J., Begen, A., Greengrass, J., and C. Filsfils,
+              "Toward Lossless Video Transport, IEEE Internet Computing,
+              vol. 15/6, pp. 48-57", November 2011.
+
+   [RFC2354]  Perkins, C. and O. Hodson, "Options for Repair of
+              Streaming Media", RFC 2354, June 1998.
+
+   [RFC2818]  Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
+
+   [RFC2974]  Handley, M., Perkins, C., and E. Whelan, "Session
+              Announcement Protocol", RFC 2974, October 2000.
+
+   [RFC5652]  Housley, R., "Cryptographic Message Syntax (CMS)", STD 70,
+              RFC 5652, September 2009.
+
+   [RFC5751]  Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet
+              Mail Extensions (S/MIME) Version 3.2 Message
+              Specification", RFC 5751, January 2010.
+
+   [RTP-DUP]  Begen, A. and C. Perkins, "Duplicating RTP Streams", Work
+              in Progress, October 2013.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Begen, et al.                Standards Track                    [Page 9]
+
+RFC 7104          Duplication Grouping Semantics in SDP     January 2014
+
+
+Authors' Addresses
+
+   Ali Begen
+   Cisco
+   181 Bay Street
+   Toronto, ON  M5J 2T3
+   Canada
+
+   EMail: abegen@cisco.com
+
+
+   Yiqun Cai
+   Microsoft
+   1065 La Avenida
+   Mountain View, CA  94043
+   USA
+
+   EMail: yiqunc@microsoft.com
+
+
+   Heidi Ou
+   Cisco
+   170 W. Tasman Dr.
+   San Jose, CA  95134
+   USA
+
+   EMail: hou@cisco.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Begen, et al.                Standards Track                   [Page 10]
+