doc: Add RFC documents

1 files changed, 1011 insertions, 0 deletions

diff --git a/doc/rfc/rfc6364.txt b/doc/rfc/rfc6364.txt
new file mode 100644
index 0000000..b663683
--- /dev/null
+++ b/doc/rfc/rfc6364.txt
@@ -0,0 +1,1011 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                          A. Begen
+Request for Comments: 6364                                         Cisco
+Category: Standards Track                                   October 2011
+ISSN: 2070-1721
+
+
+             Session Description Protocol Elements for the
+                Forward Error Correction (FEC) Framework
+
+Abstract
+
+   This document specifies the use of the Session Description Protocol
+   (SDP) to describe the parameters required to signal the Forward Error
+   Correction (FEC) Framework Configuration Information between the
+   sender(s) and receiver(s).  This document also provides examples that
+   show the semantics for grouping multiple source and repair flows
+   together for the applications that simultaneously use multiple
+   instances of the FEC Framework.
+
+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/rfc6364.
+
+Copyright Notice
+
+   Copyright (c) 2011 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.
+
+
+
+
+Begen                        Standards Track                    [Page 1]
+
+RFC 6364             SDP Elements for FEC Framework         October 2011
+
+
+   This document may contain material from IETF Documents or IETF
+   Contributions published or made publicly available before November
+   10, 2008.  The person(s) controlling the copyright in some of this
+   material may not have granted the IETF Trust the right to allow
+   modifications of such material outside the IETF Standards Process.
+   Without obtaining an adequate license from the person(s) controlling
+   the copyright in such materials, this document may not be modified
+   outside the IETF Standards Process, and derivative works of it may
+   not be created outside the IETF Standards Process, except to format
+   it for publication as an RFC or to translate it into languages other
+   than English.
+
+Table of Contents
+
+   1. Introduction ....................................................3
+   2. Requirements Notation ...........................................3
+   3. Forward Error Correction (FEC) and FEC Framework ................3
+      3.1. Forward Error Correction (FEC) .............................3
+      3.2. FEC Framework ..............................................4
+      3.3. FEC Framework Configuration Information ....................4
+   4. SDP Elements ....................................................5
+      4.1. Transport Protocol Identifiers .............................6
+      4.2. Media Stream Grouping ......................................6
+      4.3. Source IP Addresses ........................................6
+      4.4. Source Flows ...............................................6
+      4.5. Repair Flows ...............................................7
+      4.6. Repair Window ..............................................8
+      4.7. Bandwidth Specification ....................................9
+   5. Scenarios and Examples .........................................10
+      5.1. Declarative Considerations ................................10
+      5.2. Offer/Answer Model Considerations .........................10
+   6. SDP Examples ...................................................11
+      6.1. One Source Flow, One Repair Flow, and One FEC Scheme ......11
+      6.2. Two Source Flows, One Repair Flow, and One FEC Scheme .....12
+      6.3. Two Source Flows, Two Repair Flows, and Two FEC Schemes ...13
+      6.4. One Source Flow, Two Repair Flows, and Two FEC Schemes ....14
+   7. Security Considerations ........................................15
+   8. IANA Considerations ............................................15
+      8.1. Registration of Transport Protocols .......................15
+      8.2. Registration of SDP Attributes ............................16
+   9. Acknowledgments ................................................16
+   10. References ....................................................17
+      10.1. Normative References .....................................17
+      10.2. Informative References ...................................17
+
+
+
+
+
+
+
+Begen                        Standards Track                    [Page 2]
+
+RFC 6364             SDP Elements for FEC Framework         October 2011
+
+
+1.  Introduction
+
+   The Forward Error Correction (FEC) Framework, described in [RFC6363],
+   outlines a general framework for using FEC-based error recovery in
+   packet flows carrying media content.  While a continuous signaling
+   between the sender(s) and receiver(s) is not required for a Content
+   Delivery Protocol (CDP) that uses the FEC Framework, a set of
+   parameters pertaining to the FEC Framework has to be initially
+   communicated between the sender(s) and receiver(s).  A signaling
+   protocol (such as the one described in [FECFRAME-CFG-SIGNAL]) is
+   required to enable such communication, and the parameters need to be
+   appropriately encoded so that they can be carried by the signaling
+   protocol.
+
+   One format to encode the parameters is the Session Description
+   Protocol (SDP) [RFC4566].  SDP provides a simple text-based format
+   for announcements and invitations to describe multimedia sessions.
+   These SDP announcements and invitations include sufficient
+   information for the sender(s) and receiver(s) to participate in the
+   multimedia sessions.  SDP also provides a framework for capability
+   negotiation, which can be used to negotiate all, or a subset, of the
+   parameters pertaining to the individual sessions.
+
+   The purpose of this document is to introduce the SDP elements that
+   are used by the CDPs using the FEC Framework that choose SDP
+   [RFC4566] for their multimedia sessions.
+
+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.  Forward Error Correction (FEC) and FEC Framework
+
+   This section gives a brief overview of FEC and the FEC Framework.
+
+3.1.  Forward Error Correction (FEC)
+
+   Any application that needs reliable transmission over an unreliable
+   packet network has to cope with packet losses.  FEC is an effective
+   approach that provides reliable transmission, particularly in
+   multicast and broadcast applications where the feedback from the
+   receiver(s) is either not available or quite limited.
+
+
+
+
+
+
+Begen                        Standards Track                    [Page 3]
+
+RFC 6364             SDP Elements for FEC Framework         October 2011
+
+
+   In a nutshell, FEC groups source packets into blocks and applies
+   protection to generate a desired number of repair packets.  These
+   repair packets can be sent on demand or independently of any receiver
+   feedback.  The choice depends on the FEC scheme or the Content
+   Delivery Protocol used by the application, the packet loss
+   characteristics of the underlying network, the transport scheme
+   (e.g., unicast, multicast, and broadcast), and the application
+   itself.  At the receiver side, lost packets can be recovered by
+   erasure decoding provided that a sufficient number of source and
+   repair packets have been received.
+
+3.2.  FEC Framework
+
+   The FEC Framework [RFC6363] outlines a general framework for using
+   FEC codes in multimedia applications that stream audio, video, or
+   other types of multimedia content.  It defines the common components
+   and aspects of Content Delivery Protocols (CDPs).  The FEC Framework
+   also defines the requirements for the FEC schemes that need to be
+   used within a CDP.  However, the details of the FEC schemes are not
+   specified within the FEC Framework.  For example, the FEC Framework
+   defines what configuration information has to be known at the sender
+   and receiver(s) at a minimum, but the FEC Framework neither specifies
+   how the FEC repair packets are generated and used to recover missing
+   source packets, nor dictates how the configuration information is
+   communicated between the sender and receiver(s).  These are rather
+   specified by the individual FEC schemes or CDPs.
+
+3.3.  FEC Framework Configuration Information
+
+   The FEC Framework [RFC6363] defines a minimum set of information that
+   has to be communicated between the sender and receiver(s) for proper
+   operation of a FEC scheme.  This information is called the "FEC
+   Framework Configuration Information".  This information includes
+   unique identifiers for the source and repair flows that carry the
+   source and repair packets, respectively.  It also specifies how the
+   sender applies protection to the source flow(s) and how the repair
+   flow(s) can be used to recover lost data.
+
+   Multiple instances of the FEC Framework can simultaneously exist at
+   the sender and the receiver(s) for different source flows, for the
+   same source flow, or for various combinations of the source flows.
+   Each instance of the FEC Framework provides the following FEC
+   Framework Configuration Information:
+
+
+
+
+
+
+
+
+Begen                        Standards Track                    [Page 4]
+
+RFC 6364             SDP Elements for FEC Framework         October 2011
+
+
+   1.  Identification of the repair flows.
+
+   2.  For each source flow protected by the repair flow(s):
+
+       A.  Definition of the source flow.
+
+       B.  An integer identifier for this flow definition (i.e., tuple).
+           This identifier MUST be unique among all source flows that
+           are protected by the same FEC repair flow.  Integer
+           identifiers can be allocated starting from zero and
+           increasing by one for each flow.  However, any random (but
+           still unique) allocation is also possible.  A source flow
+           identifier need not be carried in source packets, since
+           source packets are directly associated with a flow by virtue
+           of their packet headers.
+
+   3.  The FEC Encoding ID, identifying the FEC scheme.
+
+   4.  The length of the Explicit Source FEC Payload ID (in octets).
+
+   5.  Zero or more FEC-Scheme-Specific Information (FSSI) elements,
+       each consisting of a name and a value where the valid element
+       names and value ranges are defined by the FEC scheme.
+
+   FSSI includes the information that is specific to the FEC scheme used
+   by the CDP.  FSSI is used to communicate the information that cannot
+   be adequately represented otherwise and is essential for proper FEC
+   encoding and decoding operations.  The motivation behind separating
+   the FSSI required only by the sender (which is carried in a Sender-
+   Side FEC-Scheme-Specific Information (SS-FSSI) container) from the
+   rest of the FSSI is to provide the receiver or the third-party
+   entities a means of controlling the FEC operations at the sender.
+   Any FSSI other than the one solely required by the sender MUST be
+   communicated via the FSSI container.
+
+   The variable-length SS-FSSI and FSSI containers transmit the
+   information in textual representation and contain zero or more
+   distinct elements, whose descriptions are provided by the fully
+   specified FEC schemes.
+
+4.  SDP Elements
+
+   This section defines the SDP elements that MUST be used to describe
+   the FEC Framework Configuration Information in multimedia sessions by
+   the CDPs that choose SDP [RFC4566] for their multimedia sessions.
+   Example SDP descriptions can be found in Section 6.
+
+
+
+
+
+Begen                        Standards Track                    [Page 5]
+
+RFC 6364             SDP Elements for FEC Framework         October 2011
+
+
+4.1.  Transport Protocol Identifiers
+
+   This specification defines a new transport protocol identifier for
+   the FEC schemes that take a UDP-formatted input stream and append an
+   Explicit Source FEC Payload ID, as described in Section 5.3 of
+   [RFC6363], to generate a source flow.  This new protocol identifier
+   is called 'FEC/UDP'.  To use input streams that are formatted
+   according to another <proto> (as listed in the table for the 'proto'
+   field in the "Session Description Protocol (SDP) Parameters"
+   registry), the corresponding 'FEC/<proto>' transport protocol
+   identifier MUST be registered with IANA by following the instructions
+   specified in [RFC4566].
+
+   Note that if a FEC scheme does not use the Explicit Source FEC
+   Payload ID as described in Section 4.1 of [RFC6363], then the
+   original transport protocol identifier MUST be used to support
+   backward compatibility with the receivers that do not support FEC
+   at all.
+
+   This specification also defines another transport protocol
+   identifier, 'UDP/FEC', to indicate the FEC repair packet format
+   defined in Section 5.4 of [RFC6363].  For detailed registration
+   information, refer to Section 8.1.
+
+4.2.  Media Stream Grouping
+
+   In the FEC Framework, the 'group' attribute and the FEC grouping
+   semantics defined in [RFC5888] and [RFC5956], respectively, are used
+   to associate source and repair flows.
+
+4.3.  Source IP Addresses
+
+   The 'source-filter' attribute of SDP ("a=source-filter") as defined
+   in [RFC4570] is used to express the source addresses or fully
+   qualified domain names in the FEC Framework.
+
+4.4.  Source Flows
+
+   The FEC Framework allows that multiple source flows MAY be grouped
+   and protected together by single or multiple FEC Framework instances.
+   For this reason, as described in Section 3.3, individual source flows
+   MUST be identified with unique identifiers.  For this purpose, we
+   introduce the attribute 'fec-source-flow'.
+
+
+
+
+
+
+
+
+Begen                        Standards Track                    [Page 6]
+
+RFC 6364             SDP Elements for FEC Framework         October 2011
+
+
+   The syntax for the new attribute in ABNF [RFC5234] is as follows:
+
+        fec-source-flow-line = "a=fec-source-flow:" SP source-id
+             [";" SP tag-length] CRLF
+
+        source-id = "id=" src-id
+        src-id = 1*DIGIT ; Represented as 32-bit non-negative
+                         ; integers, and leading zeros are ignored
+
+        tag-length = "tag-len=" tlen
+        tlen = %x31-39 *DIGIT
+
+   The REQUIRED parameter 'id' is used to identify the source flow.
+   Parameter 'id' MUST be an integer.
+
+   The 'tag-len' parameter is used to specify the length of the Explicit
+   Source FEC Payload ID field (in octets).  In the case that an
+   Explicit Source FEC Payload ID is used, the 'tag-len' parameter MUST
+   exist and indicate its length.  Otherwise, the 'tag-len' parameter
+   MUST NOT exist.
+
+4.5.  Repair Flows
+
+   A repair flow MUST contain only repair packets formatted as described
+   in [RFC6363] for a single FEC Framework instance; i.e., packets
+   belonging to source flows or other repair flows from a different FEC
+   Framework instance cannot be sent within this flow.  We introduce the
+   attribute 'fec-repair-flow' to describe the repair flows.
+
+   The syntax for the new attribute in ABNF is as follows (CHAR and CTL
+   are defined in [RFC5234]):
+
+      fec-repair-flow-line = "a=fec-repair-flow:" SP fec-encoding-id
+           [";" SP flow-preference]
+           [";" SP sender-side-scheme-specific]
+           [";" SP scheme-specific] CRLF
+
+      fec-encoding-id = "encoding-id=" enc-id
+      enc-id = 1*DIGIT ; FEC Encoding ID
+
+      flow-preference = "preference-lvl=" preference-level-of-the-flow
+      preference-level-of-the-flow = 1*DIGIT
+
+
+
+
+
+
+
+
+
+Begen                        Standards Track                    [Page 7]
+
+RFC 6364             SDP Elements for FEC Framework         October 2011
+
+
+      sender-side-scheme-specific = "ss-fssi=" sender-info
+      sender-info = element *( "," element )
+      element     = name ":" value
+      name        = token
+      token       = 1*<any CHAR except CTLs or separators>
+      value       = *<any CHAR except CTLs or separators>
+      separator   = "(" / ")" / "<" / ">" / "@"
+                     / "," / ";" / ":" / "\" / DQUOTE
+                     / "/" / "[" / "]" / "?" / "="
+                     / "{" / "}" / SP / HTAB
+
+      scheme-specific = "fssi=" scheme-info
+      scheme-info = element *( "," element )
+
+   The REQUIRED parameter 'encoding-id' is used to identify the FEC
+   scheme used to generate this repair flow.  These identifiers (in the
+   range of [0 - 255]) are registered by the FEC schemes that use the
+   FEC Framework and are maintained by IANA.
+
+   The OPTIONAL parameter 'preference-lvl' is used to indicate the
+   preferred order for using the repair flows.  The exact usage of the
+   parameter 'preference-lvl' and the pertaining rules MAY be defined by
+   the FEC scheme or the CDP.  If the parameter 'preference-lvl' does
+   not exist, it means that the receiver(s) MAY receive and use the
+   repair flows in any order.  However, if a preference level is
+   assigned to the repair flow(s), the receivers are encouraged to
+   follow the specified order in receiving and using the repair flow(s).
+
+   The OPTIONAL parameters 'ss-fssi' and 'fssi' are containers to convey
+   the FEC-Scheme-Specific Information (FSSI) that includes the
+   information that is specific to the FEC scheme used by the CDP and is
+   necessary for proper FEC encoding and decoding operations.  The FSSI
+   required only by the sender (the Sender-Side FSSI) MUST be
+   communicated in the container specified by the parameter 'ss-fssi'.
+   Any other FSSI MUST be communicated in the container specified by the
+   parameter 'fssi'.  In both containers, FSSI is transmitted in the
+   form of textual representation and MAY contain multiple distinct
+   elements.  If the FEC scheme does not require any specific
+   information, the 'ss-fssi' and 'fssi' parameters MUST NOT exist.
+
+4.6.  Repair Window
+
+   The repair window is the time that spans a FEC block, which consists
+   of the source block and the corresponding repair packets.
+
+   At the sender side, the FEC encoder processes a block of source
+   packets and generates a number of repair packets.  Then, both the
+   source and repair packets are transmitted within a certain duration
+
+
+
+Begen                        Standards Track                    [Page 8]
+
+RFC 6364             SDP Elements for FEC Framework         October 2011
+
+
+   not larger than the value of the repair window.  The value of the
+   repair window impacts the maximum number of source packets that can
+   be included in a FEC block.
+
+   At the receiver side, the FEC decoder should wait at least for the
+   duration of the repair window after getting the first packet in a FEC
+   block, to allow all the repair packets to arrive.  (The waiting time
+   can be adjusted if there are missing packets at the beginning of the
+   FEC block.)  The FEC decoder can start decoding the already received
+   packets sooner; however, it SHOULD NOT register a FEC decoding
+   failure until it waits at least for the duration of the repair
+   window.
+
+   This document specifies a new attribute to describe the size of the
+   repair window in milliseconds and microseconds.
+
+   The syntax for the attribute in ABNF is as follows:
+
+        repair-window-line = "a=repair-window:" window-size unit CRLF
+
+        window-size = %x31-39 *DIGIT ; Represented as
+                                     ; 32-bit non-negative integers
+
+        unit = "ms" / "us"
+
+   <unit> is the unit of time specified for the repair window size.  Two
+   units are defined here: 'ms', which stands for milliseconds; and
+   'us', which stands for microseconds.
+
+   The 'a=repair-window' attribute is a media-level attribute, since
+   each repair flow MAY have a different repair window size.
+
+   Specifying the repair window size in an absolute time value does not
+   necessarily correspond to an integer number of packets or exactly
+   match with the clock rate used in RTP (in the case of RTP transport),
+   causing mismatches among subsequent repair windows.  However, in
+   practice, this mismatch does not break anything in the FEC decoding
+   process.
+
+4.7.  Bandwidth Specification
+
+   The bandwidth specification as defined in [RFC4566] denotes the
+   proposed bandwidth to be used by the session or media.  The
+   specification of bandwidth is OPTIONAL.
+
+
+
+
+
+
+
+Begen                        Standards Track                    [Page 9]
+
+RFC 6364             SDP Elements for FEC Framework         October 2011
+
+
+   In the context of the FEC Framework, the bandwidth specification can
+   be used to express the bandwidth of the repair flows or the bandwidth
+   of the session.  If included in the SDP, it SHALL adhere to the
+   following rules.
+
+   The session-level bandwidth for a FEC Framework instance or the
+   media-level bandwidth for the individual repair flows MAY be
+   specified.  In this case, it is RECOMMENDED that the Transport
+   Independent Application Specific (TIAS) bandwidth modifier [RFC3890]
+   and the 'a=maxprate' attribute be used, unless the Application-
+   Specific (AS) bandwidth modifier [RFC4566] is used.  The use of the
+   AS bandwidth modifier is NOT RECOMMENDED, since TIAS allows the
+   calculation of the bitrate according to the IP version and transport
+   protocol whereas AS does not.  Thus, in TIAS-based bitrate
+   calculations, the packet size SHALL include all headers and payload,
+   excluding the IP and UDP headers.  In AS-based bitrate calculations,
+   the packet size SHALL include all headers and payload, plus the IP
+   and UDP headers.
+
+   For the ABNF syntax information of the TIAS and AS, refer to
+   [RFC3890] and [RFC4566], respectively.
+
+5.  Scenarios and Examples
+
+   This section discusses the considerations for Session Announcement
+   and Offer/Answer Models.
+
+5.1.  Declarative Considerations
+
+   In multicast-based applications, the FEC Framework Configuration
+   Information pertaining to all FEC protection options available at the
+   sender MAY be advertised to the receivers as a part of a session
+   announcement.  This way, the sender can let the receivers know all
+   available options for FEC protection.  Based on their needs, the
+   receivers can choose protection provided by one or more FEC Framework
+   instances and subscribe to the respective multicast session(s) to
+   receive the repair flow(s).  Unless explicitly required by the CDP,
+   the receivers SHOULD NOT send an answer back to the sender specifying
+   their choices, since this can easily overwhelm the sender,
+   particularly in large-scale multicast applications.
+
+5.2.  Offer/Answer Model Considerations
+
+   In unicast-based applications, a sender and receiver MAY adopt the
+   Offer/Answer Model [RFC3264] to set the FEC Framework Configuration
+   Information.  In this case, the sender offers the options available
+   to this particular receiver, and the receiver answers back to the
+   sender with its choice(s).
+
+
+
+Begen                        Standards Track                   [Page 10]
+
+RFC 6364             SDP Elements for FEC Framework         October 2011
+
+
+   Receivers supporting the SDP Capability Negotiation Framework
+   [RFC5939] MAY also use this framework to negotiate all, or a subset,
+   of the FEC Framework parameters.
+
+   The backward compatibility in the Offer/Answer Model is handled as
+   specified in [RFC5956].
+
+6.  SDP Examples
+
+   This section provides SDP examples that can be used by the FEC
+   Framework.
+
+   [RFC5888] defines the media stream identification attribute ('mid')
+   as a token in ABNF.  In contrast, the identifiers for the source
+   flows are integers and can be allocated starting from zero and
+   increasing by one for each flow.  To avoid any ambiguity, using the
+   same values for identifying the media streams and source flows is NOT
+   RECOMMENDED, even when 'mid' values are integers.
+
+   In the examples below, random FEC Encoding IDs will be used for
+   illustrative purposes.  Artificial content for the SS-FSSI and FSSI
+   will also be provided.
+
+6.1.  One Source Flow, One Repair Flow, and One FEC Scheme
+
+                 SOURCE FLOWS             | INSTANCE #1
+                 S1: Source Flow |--------| R1: Repair Flow
+                                          |
+
+                           Figure 1: Scenario #1
+
+   In this example, we have one source video flow (mid:S1) and one FEC
+   repair flow (mid:R1).  We form one FEC group with the
+   "a=group:FEC-FR S1 R1" line.  The source and repair flows are sent to
+   the same port on different multicast groups.  The repair window is
+   set to 150 ms.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Begen                        Standards Track                   [Page 11]
+
+RFC 6364             SDP Elements for FEC Framework         October 2011
+
+
+        v=0
+        o=ali 1122334455 1122334466 IN IP4 fec.example.com
+        s=FEC Framework Examples
+        t=0 0
+        a=group:FEC-FR S1 R1
+        m=video 30000 RTP/AVP 100
+        c=IN IP4 233.252.0.1/127
+        a=rtpmap:100 MP2T/90000
+        a=fec-source-flow: id=0
+        a=mid:S1
+        m=application 30000 UDP/FEC
+        c=IN IP4 233.252.0.2/127
+        a=fec-repair-flow: encoding-id=0; ss-fssi=n:7,k:5
+        a=repair-window:150ms
+        a=mid:R1
+
+6.2.  Two Source Flows, One Repair Flow, and One FEC Scheme
+
+                SOURCE FLOWS
+                S2: Source Flow |         | INSTANCE #1
+                                |---------| R2: Repair Flow
+                S3: Source Flow |
+
+                           Figure 2: Scenario #2
+
+   In this example, we have two source video flows (mid:S2 and mid:S3)
+   and one FEC repair flow (mid:R2) protecting both source flows.  We
+   form one FEC group with the "a=group:FEC-FR S2 S3 R2" line.  The
+   source and repair flows are sent to the same port on different
+   multicast groups.  The repair window is set to 150500 us.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Begen                        Standards Track                   [Page 12]
+
+RFC 6364             SDP Elements for FEC Framework         October 2011
+
+
+        v=0
+        o=ali 1122334455 1122334466 IN IP4 fec.example.com
+        s=FEC Framework Examples
+        t=0 0
+        a=group:FEC-FR S2 S3 R2
+        m=video 30000 RTP/AVP 100
+        c=IN IP4 233.252.0.1/127
+        a=rtpmap:100 MP2T/90000
+        a=fec-source-flow: id=0
+        a=mid:S2
+        m=video 30000 RTP/AVP 101
+        c=IN IP4 233.252.0.2/127
+        a=rtpmap:101 MP2T/90000
+        a=fec-source-flow: id=1
+        a=mid:S3
+        m=application 30000 UDP/FEC
+        c=IN IP4 233.252.0.3/127
+        a=fec-repair-flow: encoding-id=0; ss-fssi=n:7,k:5
+        a=repair-window:150500us
+        a=mid:R2
+
+6.3.  Two Source Flows, Two Repair Flows, and Two FEC Schemes
+
+                 SOURCE FLOWS             | INSTANCE #1
+                 S4: Source Flow |--------| R3: Repair Flow
+
+                 S5: Source Flow |--------| INSTANCE #2
+                                          | R4: Repair Flow
+
+                           Figure 3: Scenario #3
+
+   In this example, we have two source video flows (mid:S4 and mid:S5)
+   and two FEC repair flows (mid:R3 and mid:R4).  The source flows
+   mid:S4 and mid:S5 are protected by the repair flows mid:R3 and
+   mid:R4, respectively.  We form two FEC groups with the
+   "a=group:FEC-FR S4 R3" and "a=group:FEC-FR S5 R4" lines.  The source
+   and repair flows are sent to the same port on different multicast
+   groups.  The repair window is set to 200 ms and 400 ms for the first
+   and second FEC group, respectively.
+
+
+
+
+
+
+
+
+
+
+
+
+Begen                        Standards Track                   [Page 13]
+
+RFC 6364             SDP Elements for FEC Framework         October 2011
+
+
+        v=0
+        o=ali 1122334455 1122334466 IN IP4 fec.example.com
+        s=FEC Framework Examples
+        t=0 0
+        a=group:FEC-FR S4 R3
+        a=group:FEC-FR S5 R4
+        m=video 30000 RTP/AVP 100
+        c=IN IP4 233.252.0.1/127
+        a=rtpmap:100 MP2T/90000
+        a=fec-source-flow: id=0
+        a=mid:S4
+        m=video 30000 RTP/AVP 101
+        c=IN IP4 233.252.0.2/127
+        a=rtpmap:101 MP2T/90000
+        a=fec-source-flow: id=1
+        a=mid:S5
+        m=application 30000 UDP/FEC
+        c=IN IP4 233.252.0.3/127
+        a=fec-repair-flow: encoding-id=0; ss-fssi=n:7,k:5
+        a=repair-window:200ms
+        a=mid:R3
+        m=application 30000 UDP/FEC
+        c=IN IP4 233.252.0.4/127
+        a=fec-repair-flow: encoding-id=0; ss-fssi=n:14,k:10
+        a=repair-window:400ms
+        a=mid:R4
+
+6.4.  One Source Flow, Two Repair Flows, and Two FEC Schemes
+
+                 SOURCE FLOWS             | INSTANCE #1
+                 S6: Source Flow |--------| R5: Repair Flow
+                                 |
+                                 |--------| INSTANCE #2
+                                          | R6: Repair Flow
+
+                           Figure 4: Scenario #4
+
+   In this example, we have one source video flow (mid:S6) and two FEC
+   repair flows (mid:R5 and mid:R6) with different preference levels.
+   The source flow mid:S6 is protected by both of the repair flows.  We
+   form two FEC groups with the "a=group:FEC-FR S6 R5" and
+   "a=group:FEC-FR S6 R6" lines.  The source and repair flows are sent
+   to the same port on different multicast groups.  The repair window is
+   set to 200 ms for both FEC groups.
+
+
+
+
+
+
+
+Begen                        Standards Track                   [Page 14]
+
+RFC 6364             SDP Elements for FEC Framework         October 2011
+
+
+     v=0
+     o=ali 1122334455 1122334466 IN IP4 fec.example.com
+     s=FEC Framework Examples
+     t=0 0
+     a=group:FEC-FR S6 R5
+     a=group:FEC-FR S6 R6
+     m=video 30000 RTP/AVP 100
+     c=IN IP4 233.252.0.1/127
+     a=rtpmap:100 MP2T/90000
+     a=fec-source-flow: id=0
+     a=mid:S6
+     m=application 30000 UDP/FEC
+     c=IN IP4 233.252.0.3/127
+     a=fec-repair-flow: encoding-id=0; preference-lvl=0; ss-fssi=n:7,k:5
+     a=repair-window:200ms
+     a=mid:R5
+     m=application 30000 UDP/FEC
+     c=IN IP4 233.252.0.4/127
+     a=fec-repair-flow: encoding-id=1; preference-lvl=1; ss-fssi=t:3
+     a=repair-window:200ms
+     a=mid:R6
+
+7.  Security Considerations
+
+   There is a weak threat if the SDP is modified in a way that it shows
+   an incorrect association and/or grouping of the source and repair
+   flows.  Such attacks can result in failure of FEC protection and/or
+   mishandling of other media streams.  It is RECOMMENDED that the
+   receiver perform an integrity check on SDP to only trust SDP from
+   trusted sources.  The receiver MUST also follow the security
+   considerations of SDP [RFC4566].  For other general security
+   considerations related to SDP, refer to [RFC4566].  For the security
+   considerations related to the use of source address filters in SDP,
+   refer to [RFC4570].
+
+   The security considerations for the FEC Framework also apply.  Refer
+   to [RFC6363] for details.
+
+8.  IANA Considerations
+
+8.1.  Registration of Transport Protocols
+
+   This specification updates the "Session Description Protocol (SDP)
+   Parameters" registry as defined in Section 8.2.2 of [RFC4566].
+   Specifically, it adds the following values to the table for the
+   'proto' field.
+
+
+
+
+
+Begen                        Standards Track                   [Page 15]
+
+RFC 6364             SDP Elements for FEC Framework         October 2011
+
+
+      Type            SDP Name             Reference
+      ------          ----------           -----------
+      proto           FEC/UDP              [RFC6364]
+      proto           UDP/FEC              [RFC6364]
+
+8.2.  Registration of SDP Attributes
+
+   This document registers new attribute names in SDP.
+
+   SDP Attribute ("att-field"):
+        Attribute name:     fec-source-flow
+        Long form:          Pointer to FEC Source Flow
+        Type of name:       att-field
+        Type of attribute:  Media level
+        Subject to charset: No
+        Purpose:            Provide parameters for a FEC source flow
+        Reference:          [RFC6364]
+        Values:             See [RFC6364]
+
+   SDP Attribute ("att-field"):
+        Attribute name:     fec-repair-flow
+        Long form:          Pointer to FEC Repair Flow
+        Type of name:       att-field
+        Type of attribute:  Media level
+        Subject to charset: No
+        Purpose:            Provide parameters for a FEC repair flow
+        Reference:          [RFC6364]
+        Values:             See [RFC6364]
+
+   SDP Attribute ("att-field"):
+        Attribute name:     repair-window
+        Long form:          Pointer to FEC Repair Window
+        Type of name:       att-field
+        Type of attribute:  Media level
+        Subject to charset: No
+        Purpose:            Indicate the size of the repair window
+        Reference:          [RFC6364]
+        Values:             See [RFC6364]
+
+9.  Acknowledgments
+
+   The author would like to thank the FEC Framework Design Team for
+   their inputs, suggestions, and contributions.
+
+
+
+
+
+
+
+
+Begen                        Standards Track                   [Page 16]
+
+RFC 6364             SDP Elements for FEC Framework         October 2011
+
+
+10.  References
+
+10.1.  Normative References
+
+   [RFC6363]  Watson, M., Begen, A., and V. Roca, "Forward Error
+              Correction (FEC) Framework", RFC 6363, October 2011.
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC4566]  Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
+              Description Protocol", RFC 4566, July 2006.
+
+   [RFC4570]  Quinn, B. and R. Finlayson, "Session Description Protocol
+              (SDP) Source Filters", RFC 4570, July 2006.
+
+   [RFC5888]  Camarillo, G. and H. Schulzrinne, "The Session Description
+              Protocol (SDP) Grouping Framework", RFC 5888, June 2010.
+
+   [RFC5956]  Begen, A., "Forward Error Correction Grouping Semantics in
+              the Session Description Protocol", RFC 5956,
+              September 2010.
+
+   [RFC3890]  Westerlund, M., "A Transport Independent Bandwidth
+              Modifier for the Session Description Protocol (SDP)",
+              RFC 3890, September 2004.
+
+   [RFC5234]  Crocker, D., Ed., and P. Overell, "Augmented BNF for
+              Syntax Specifications: ABNF", STD 68, RFC 5234,
+              January 2008.
+
+   [RFC3264]  Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
+              with Session Description Protocol (SDP)", RFC 3264,
+              June 2002.
+
+10.2.  Informative References
+
+   [FECFRAME-CFG-SIGNAL]
+              Asati, R., "Methods to convey FEC Framework Configuration
+              Information", Work in Progress, September 2011.
+
+   [RFC5939]  Andreasen, F., "Session Description Protocol (SDP)
+              Capability Negotiation", RFC 5939, September 2010.
+
+
+
+
+
+
+
+
+Begen                        Standards Track                   [Page 17]
+
+RFC 6364             SDP Elements for FEC Framework         October 2011
+
+
+Author's Address
+
+   Ali Begen
+   Cisco
+   181 Bay Street
+   Toronto, ON  M5J 2T3
+   Canada
+
+   EMail: abegen@cisco.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Begen                        Standards Track                   [Page 18]
+