summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc7104.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc7104.txt')
-rw-r--r--doc/rfc/rfc7104.txt563
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]
+