draft-ietf-fecframe-sdp-elements-06.txt   draft-ietf-fecframe-sdp-elements-07.txt 
FEC Framework A. Begen FEC Framework A. Begen
Internet-Draft Cisco Internet-Draft Cisco
Intended status: Standards Track April 28, 2010 Intended status: Standards Track July 12, 2010
Expires: October 30, 2010 Expires: January 13, 2011
SDP Elements for FEC Framework Session Description Protocol (SDP) Elements for FEC Framework
draft-ietf-fecframe-sdp-elements-06 draft-ietf-fecframe-sdp-elements-07
Abstract Abstract
This document specifies the use of Session Description Protocol (SDP) This document specifies the use of Session Description Protocol (SDP)
to describe the parameters required to signal the Forward Error to describe the parameters required to signal the Forward Error
Correction (FEC) Framework Configuration Information between the Correction (FEC) Framework Configuration Information between the
sender(s) and receiver(s). This document also provides examples that sender(s) and receiver(s). This document also provides examples that
show the semantics for grouping multiple source and repair flows show the semantics for grouping multiple source and repair flows
together for the applications that simultaneously use multiple together for the applications that simultaneously use multiple
instances of the FEC Framework. instances of the FEC Framework.
skipping to change at page 1, line 36 skipping to change at page 1, line 36
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on October 30, 2010. This Internet-Draft will expire on January 13, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 12 skipping to change at page 2, line 26
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
than English. than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 4 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 4
3. Forward Error Correction (FEC) and FEC Framework . . . . . . . 4 3. Forward Error Correction (FEC) and FEC Framework . . . . . . . 4
3.1. Forward Error Correction (FEC) . . . . . . . . . . . . . . 4 3.1. Forward Error Correction (FEC) . . . . . . . . . . . . . . 4
3.2. FEC Framework . . . . . . . . . . . . . . . . . . . . . . 5 3.2. FEC Framework . . . . . . . . . . . . . . . . . . . . . . 5
3.3. FEC Framework Configuration Information . . . . . . . . . 6 3.3. FEC Framework Configuration Information . . . . . . . . . 5
4. SDP Descriptors for FEC Framework . . . . . . . . . . . . . . 7 4. SDP Elements . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.1. Transport Protocol Identifiers . . . . . . . . . . . . . . 8 4.1. Transport Protocol Identifiers . . . . . . . . . . . . . . 6
4.2. Media Stream Grouping . . . . . . . . . . . . . . . . . . 8 4.2. Media Stream Grouping . . . . . . . . . . . . . . . . . . 7
4.3. Source IP Addresses . . . . . . . . . . . . . . . . . . . 9 4.3. Source IP Addresses . . . . . . . . . . . . . . . . . . . 7
4.4. Source Flows . . . . . . . . . . . . . . . . . . . . . . . 10 4.4. Source Flows . . . . . . . . . . . . . . . . . . . . . . . 7
4.5. Repair Flows . . . . . . . . . . . . . . . . . . . . . . . 10 4.5. Repair Flows . . . . . . . . . . . . . . . . . . . . . . . 8
4.6. Repair Window . . . . . . . . . . . . . . . . . . . . . . 11 4.6. Repair Window . . . . . . . . . . . . . . . . . . . . . . 9
4.7. Bandwidth Specification . . . . . . . . . . . . . . . . . 12 4.7. Bandwidth Specification . . . . . . . . . . . . . . . . . 10
5. Scenarios and Examples . . . . . . . . . . . . . . . . . . . . 13 5. Scenarios and Examples . . . . . . . . . . . . . . . . . . . . 11
5.1. Declarative Considerations . . . . . . . . . . . . . . . . 13 5.1. Declarative Considerations . . . . . . . . . . . . . . . . 11
5.2. Offer/Answer Model Considerations . . . . . . . . . . . . 14 5.2. Offer/Answer Model Considerations . . . . . . . . . . . . 11
5.3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 14 6. SDP Examples . . . . . . . . . . . . . . . . . . . . . . . . . 12
5.3.1. One Source Flow, One Repair Flow and One FEC Scheme . 14 6.1. One Source Flow, One Repair Flow and One FEC Scheme . . . 12
5.3.2. Two Source Flows, One Repair Flow and One FEC 6.2. Two Source Flows, One Repair Flow and One FEC Scheme . . . 13
Scheme . . . . . . . . . . . . . . . . . . . . . . . . 15 6.3. Two Source Flows, Two Repair Flows and Two FEC Schemes . . 14
5.3.3. Two Source Flows, Two Repair Flows and Two FEC 6.4. One Source Flow, Two Repair Flows and Two FEC Schemes . . 15
Schemes . . . . . . . . . . . . . . . . . . . . . . . 16 7. Security Considerations . . . . . . . . . . . . . . . . . . . 16
6. Security Considerations . . . . . . . . . . . . . . . . . . . 17 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 8.1. Registration of Transport Protocols . . . . . . . . . . . 16
7.1. Transport Protocols . . . . . . . . . . . . . . . . . . . 18 8.2. Registration of SDP Attributes . . . . . . . . . . . . . . 17
7.2. Attribute Names . . . . . . . . . . . . . . . . . . . . . 18 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
9. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 19 10.1. Normative References . . . . . . . . . . . . . . . . . . . 18
9.1. draft-ietf-fecframe-sdp-elements-06 . . . . . . . . . . . 19 10.2. Informative References . . . . . . . . . . . . . . . . . . 18
9.2. draft-ietf-fecframe-sdp-elements-05 . . . . . . . . . . . 19
9.3. draft-ietf-fecframe-sdp-elements-04 . . . . . . . . . . . 19 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 19
9.4. draft-ietf-fecframe-sdp-elements-03 . . . . . . . . . . . 19
9.5. draft-ietf-fecframe-sdp-elements-02 . . . . . . . . . . . 20
9.6. draft-ietf-fecframe-sdp-elements-01 . . . . . . . . . . . 20
9.7. draft-ietf-fecframe-sdp-elements-00 . . . . . . . . . . . 20
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
10.1. Normative References . . . . . . . . . . . . . . . . . . . 21
10.2. Informative References . . . . . . . . . . . . . . . . . . 21
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 22
1. Introduction 1. Introduction
The Forward Error Correction (FEC) Framework, described in The Forward Error Correction (FEC) Framework, described in
[I-D.ietf-fecframe-framework], outlines a general framework for using [I-D.ietf-fecframe-framework], outlines a general framework for using
FEC-based error recovery in packet flows carrying media content. FEC-based error recovery in packet flows carrying media content.
While a continuous signaling between the sender(s) and receiver(s) is While a continuous signaling between the sender(s) and receiver(s) is
not required for a Content Delivery Protocol (CDP) that uses the FEC not required for a Content Delivery Protocol (CDP) that uses the FEC
Framework, a set of parameters pertaining to the FEC Framework MUST Framework, a set of parameters pertaining to the FEC Framework has to
be initially communicated between the sender(s) and receiver(s). A be initially communicated between the sender(s) and receiver(s). A
signaling protocol (such as the one described in signaling protocol (such as the one described in
[I-D.ietf-fecframe-config-signaling]) is required to enable such [I-D.ietf-fecframe-config-signaling]) is required to enable such
communication and the parameters must be appropriately encoded so communication and the parameters need to be appropriately encoded so
that they can be carried by the signaling protocol. that they can be carried by the signaling protocol.
One format to encode the parameters is the Session Description One format to encode the parameters is the Session Description
Protocol (SDP) [RFC4566]. SDP provides a simple text-based format Protocol (SDP) [RFC4566]. SDP provides a simple text-based format
for announcements and invitations to describe multimedia sessions. for announcements and invitations to describe multimedia sessions.
These SDP announcements and invitations include sufficient These SDP announcements and invitations include sufficient
information for the sender(s) and receiver(s) to participate in the information for the sender(s) and receiver(s) to participate in the
multimedia sessions. SDP also provides a framework for capability multimedia sessions. SDP also provides a framework for capability
negotiation, which may be used to negotiate all or a subset of the negotiation, which can be used to negotiate all or a subset of the
parameters pertaining to the individual sessions. parameters pertaining to the individual sessions.
The purpose of this document is to introduce the SDP elements that The purpose of this document is to introduce the SDP elements that
MUST be used by the CDPs using the FEC Framework that choose SDP are used by the CDPs using the FEC Framework that choose SDP
[RFC4566] as their session description protocol. [RFC4566] as their session description protocol.
2. Requirements Notation 2. Requirements Notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
3. Forward Error Correction (FEC) and FEC Framework 3. Forward Error Correction (FEC) and FEC Framework
This section gives a brief overview of FEC and the FEC Framework. This section gives a brief overview of FEC and the FEC Framework.
3.1. Forward Error Correction (FEC) 3.1. Forward Error Correction (FEC)
Any application that needs a reliable transmission over an unreliable Any application that needs a reliable transmission over an unreliable
packet network has to cope with packet losses. FEC is an effective packet network has to cope with packet losses. FEC is an effective
approach that provides reliable transmission particularly in approach that provides reliable transmission particularly in
multicast and broadcast applications where the feedback from the multicast and broadcast applications where the feedback from the
receiver(s) is potentially limited. receiver(s) is either not available or quite limited.
In a nutshell, FEC groups source packets into blocks and applies In a nutshell, FEC groups source packets into blocks and applies
protection to generate a desired number of repair packets. These protection to generate a desired number of repair packets. These
repair packets may be sent on demand or independently of any receiver repair packets can be sent on demand or independently of any receiver
feedback. The choice depends on the FEC scheme or the Content feedback. The choice depends on the FEC scheme or the Content
Delivery Protocol used by the application, the packet loss Delivery Protocol used by the application, the packet loss
characteristics of the underlying network, the transport scheme characteristics of the underlying network, the transport scheme
(e.g., unicast, multicast and broadcast) and the application. At the (e.g., unicast, multicast and broadcast) and the application. At the
receiver side, lost packets can be recovered by erasure decoding receiver side, lost packets can be recovered by erasure decoding
provided that a sufficient number of source and repair packets have provided that a sufficient number of source and repair packets have
been received. been received.
3.2. FEC Framework 3.2. FEC Framework
skipping to change at page 5, line 30 skipping to change at page 5, line 30
The FEC Framework also defines the requirements for the FEC schemes 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 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 schemes are not specified within the FEC Framework. For example, the
FEC Framework defines what configuration information has to be known FEC Framework defines what configuration information has to be known
at the sender and receiver(s) at minimum, but the FEC Framework at the sender and receiver(s) at minimum, but the FEC Framework
neither specifies how the FEC repair packets are generated and used neither specifies how the FEC repair packets are generated and used
to recover missing source packets, nor dictates how the configuration to recover missing source packets, nor dictates how the configuration
information is communicated between the sender and receiver(s). information is communicated between the sender and receiver(s).
These are rather specified by the individual FEC schemes or CDPs. These are rather specified by the individual FEC schemes or CDPs.
For a proper operation, the information required by the FEC Framework
and the details of an FEC scheme have to be communicated between the
sender and receiver(s). One way to provide this information is to
use the Session Description Protocol (SDP) [RFC4566]. SDP provides a
commonly used text-based format for announcements and invitations
that describe multimedia sessions. These SDP announcements and
invitations include sufficient information for clients to participate
in multimedia sessions. By using the SDP capability negotiation
framework, all or a subset of the parameters pertaining to the FEC
Framework may also be negotiated between the sender and receiver(s).
The purpose of this document is to introduce the SDP elements that
MUST be used by the CDPs using the FEC Framework that choose SDP
[RFC4566] as their session description protocol.
Note that there are many similarities between the FEC Framework
[I-D.ietf-fecframe-framework] and the FEC Building Block [RFC5052],
which describes a framework that uses FEC codes to provide
reliability to bulk data transfer applications running over IP
multicast or broadcast. See [I-D.ietf-fecframe-framework] for
further details.
3.3. FEC Framework Configuration Information 3.3. FEC Framework Configuration Information
The FEC Framework defines a minimum set of information that MUST be The FEC Framework [I-D.ietf-fecframe-framework] defines a minimum set
communicated between the sender and receiver(s) for a proper of information that has to be communicated between the sender and
operation of an FEC scheme. This information is called the FEC receiver(s) for a proper operation of an FEC scheme. This
Framework Configuration Information. This information specifies how information is called the FEC Framework Configuration Information.
the sender applies protection to the source flow(s) and how the This information includes unique identifiers for the source and
repair flow(s) can be used to recover lost data. In other words, repair flows that carry the source and repair packets, respectively.
this information specifies the relationship(s) between the source and It also specifies how the sender applies protection to the source
repair flows. flow(s) and how the repair flow(s) can be used to recover lost data.
The FEC Framework Configuration Information includes identifiers for
unique identification of the source and repair flows that carry the
source and repair packets, respectively. For example, a packet flow
that is transmitted over UDP is uniquely identified by the tuple of
{Source IP Address, Destination IP Address, Source UDP Port,
Destination UDP Port}. However, an integer identifier MAY be used
internally within the FEC scheme as a shorthand to identify this
flow.
Multiple instances of the FEC Framework MAY simultaneously exist at Multiple instances of the FEC Framework can simultaneously exist at
the sender and the receiver(s) for different source flows, for the the sender and the receiver(s) for different source flows, for the
same source flow, or for various combinations of source flows. Each same source flow, or for various combinations of the source flows.
instance of the FEC Framework MUST provide the following FEC Each instance of the FEC Framework provides the following FEC
Framework Configuration Information: Framework Configuration Information:
1. Identification of the repair flows. 1. Identification of the repair flows.
2. For each source flow protected by the repair flow(s): 2. For each source flow protected by the repair flow(s):
a. Definition of the source flow. a. Definition of the source flow.
b. An integer identifier for this flow definition (i.e., tuple). b. An integer identifier for this flow definition (i.e., tuple).
This identifier MUST be unique amongst all source flows that are This identifier MUST be unique amongst all source flows that are
skipping to change at page 6, line 41 skipping to change at page 6, line 13
1. Identification of the repair flows. 1. Identification of the repair flows.
2. For each source flow protected by the repair flow(s): 2. For each source flow protected by the repair flow(s):
a. Definition of the source flow. a. Definition of the source flow.
b. An integer identifier for this flow definition (i.e., tuple). b. An integer identifier for this flow definition (i.e., tuple).
This identifier MUST be unique amongst all source flows that are This identifier MUST be unique amongst all source flows that are
protected by the same FEC repair flow. The identifiers SHOULD be protected by the same FEC repair flow. The identifiers SHOULD be
allocated starting from zero and increasing by one for each flow. allocated starting from zero and increasing by one for each flow.
A source flow identifier need not be carried in source packets A source flow identifier need not be carried in source packets
since source packets are directly associated with a flow by virtue since source packets are directly associated with a flow by virtue
of their packet headers. Note that an application MAY wildcard of their packet headers.
some of the fields if only a subset of the fields of the tuple
(e.g., {Destination IP Address, Destination UDP Port} ) is
sufficient.
3. The FEC Encoding ID that identifies the FEC scheme. 3. The FEC Encoding ID, identifying the FEC scheme.
4. The length of the Explicit Source FEC Payload ID (in bytes). 4. The length of the Explicit Source FEC Payload ID (in bytes).
This value MAY be zero indicating that no Explicit Source FEC 5. Zero or more FEC-Scheme-Specific Information (FSSI) elements, each
Payload ID is used by the FEC scheme. If it is nonzero, however, consisting of a name and a value where the valid element names and
it means that the Explicit Source FEC Payload ID is used. In this value ranges are defined by the FEC scheme.
case, only one FEC scheme MUST be used for this source flow,
unless the generic tag (defined in [I-D.ietf-fecframe-framework])
is used by all of the FEC schemes protecting this source flow.
5. A container for the FEC-Scheme-Specific Information (FSSI) that is
required by only the receiver or by both the receiver and sender.
6. Another container for the FSSI that is only required by the
sender. This is referred to as the Sender-Side FEC-Scheme-
Specific Information (SS-FSSI).
FSSI includes the information that is specific to the FEC scheme used FSSI includes the information that is specific to the FEC scheme used
by the CDP. FSSI is used to communicate the information that cannot by the CDP. FSSI is used to communicate the information that cannot
be adequately represented otherwise and is essential for proper FEC be adequately represented otherwise and is essential for proper FEC
encoding and decoding operations. The motivation behind separating encoding and decoding operations. The motivation behind separating
the FSSI required only by the sender from the rest of the FSSI is to the FSSI required only by the sender (which is carried in Sender-Side
provide the receiver or the third party entities a means of FEC-Scheme-Specific Information (SS-FSSI) container) from the rest of
controlling the FEC operations at the sender. Any FSSI other than the FSSI is to provide the receiver or the third party entities a
the one solely required by the sender MUST be communicated via the means of controlling the FEC operations at the sender. Any FSSI
FSSI container. 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 The variable-length SS-FSSI and FSSI containers transmit the
information in textual representation and MAY contain multiple information in textual representation and contain zero or more
distinct elements. For the fully-specified FEC schemes, a full distinct elements, whose descriptions are provided by the fully-
description of these elements for both containers MUST be provided. specified FEC schemes.
If the FEC scheme does not require any specific information, the FSSI
MAY be null.
Note that when RTP transport is used for the source and/or repair
flows, the information in the FSSI/SS-FSSI containers will be carried
via the format-specific parameters (i.e., "a=fmtp" line).
4. SDP Descriptors for FEC Framework 4. SDP Elements
This section defines the SDP elements that MUST be used to describe This section defines the SDP elements that MUST be used to describe
the FEC Framework Configuration Information in multimedia sessions by the FEC Framework Configuration Information in multimedia sessions by
the CDPs that choose SDP [RFC4566] as their session description the CDPs that choose SDP [RFC4566] as their session description
protocol. Example SDP configurations can be found in Section 5. protocol. Example SDP descriptions can be found in Section 6.
4.1. Transport Protocol Identifiers 4.1. Transport Protocol Identifiers
This specification defines a class of new transport protocol This specification defines a class of new transport protocol
identifiers for SDP media descriptions. For all existing identifiers identifiers for SDP media descriptions. For all existing identifiers
<proto>, this specification defines the identifier 'FEC/<proto>'. <proto> (listed in the table for the 'proto' field in the Session
This identifier MAY be used as the transport protocol identifier in Description Protocol (SDP) Parameters registry), this specification
the media descriptions for the source data to indicate that the FEC defines the identifier 'FEC/<proto>'. This identifier MAY be used as
Source Packet format defined in Section 6.3 of the transport protocol identifier in the media descriptions for the
[I-D.ietf-fecframe-framework] is used, where the original transport source data to indicate that the FEC Source Packet format defined in
payload field is formatted according to <proto>. However, if the FEC Section 5.3 of [I-D.ietf-fecframe-framework] is used, where the
scheme does not use the Explicit Source FEC Payload ID as described original transport payload field is formatted according to <proto>.
in Section 6.3 of [I-D.ietf-fecframe-framework], then the original However, if the FEC scheme does not use the Explicit Source FEC
transport protocol identifier MUST be used to support backward Payload ID as described in Section 4.1 of
compatibility with the receivers that do not support FEC at all. [I-D.ietf-fecframe-framework], 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 This specification also defines another transport protocol
identifier, 'UDP/FEC', to indicate the FEC Repair Packet format identifier, 'UDP/FEC', to indicate the FEC Repair Packet format
defined in Section 6.4 of [I-D.ietf-fecframe-framework]. defined in Section 5.4 of [I-D.ietf-fecframe-framework].
4.2. Media Stream Grouping 4.2. Media Stream Grouping
The FEC Framework [I-D.ietf-fecframe-framework] states that multiple In FEC Framework, the 'group' attribute and the FEC grouping
instances of the FEC Framework MAY exist at the sender and the semantics defined in [RFC5888] and [I-D.ietf-mmusic-rfc4756bis],
receiver(s), and a source flow MAY be protected by multiple FEC respectively are used to associate source and repair flows together.
Framework instances. Furthermore, within a single FEC Framework
instance, multiple source flows MAY be protected by multiple repair
flows. However, each repair flow MUST provide protection for a
single FEC Framework instance. An example scenario is shown in
Figure 1. Here, source flows 0 and 1 are grouped together and
protected by repair flow 3; source flow 0 is also protected by repair
flow 4; source flows 1 and 2 are grouped together and protected by
repair flows 5, 6 and 7.
The motivation behind grouping source flows before applying FEC
protection is that a better coding performance may be achieved by
doing so and many receivers may benefit from this grouping. For
example, consider a layered video source that consists of one base
layer (e.g., source flow 0) and one enhancement layer (e.g., source
flow 1), where each layer is carried in a separate flow. Repair flow
3 protects the combination of the base and enhancement layers for the
receivers who receive both layers, and repair flow 4 protects the
base layer only, for the receivers who want the base layer only, or
who receive both layers but prefer FEC protection for the base layer
only due to a bandwidth and/or processing-power limitation.
Using multiple FEC Framework instances for a single source flow
provides flexibility to the receivers. Different instances may offer
repair flows that are generated by different FEC schemes, and
receivers choose receiving the appropriate repair flow(s) that they
can support and decode. Alternatively, different instances (whether
they use the same FEC scheme or not) may use larger and smaller
source block sizes, which accommodate the receivers that have looser
and tighter latency requirements, respectively. In addition,
different instances may also provide FEC protection at different
redundancy levels. This is particularly useful in multicast
scenarios where different receivers might experience different packet
loss rates and each receiver can choose the repair flow that is
tailored to its needs.
| FEC FRAMEWORK
+--------| INSTANCE
| | 3: Repair Flow
|
SOURCE FLOWS | | FEC FRAMEWORK
0: Source Flow |_| |-----| INSTANCE
__| 1: Source Flow | | 4: Repair Flow
| | 2: Source Flow
| | FEC FRAMEWORK
|__________________________| INSTANCE
| 5: Repair Flow
| 6: Repair Flow
| 7: Repair Flow
Figure 1: Example scenario with multiple FEC Framework instances
The 'group' attribute and the FEC grouping semantics defined in
[I-D.ietf-mmusic-rfc3388bis] and [I-D.ietf-mmusic-rfc4756bis],
respectively are used to associate source and repair flows together
with the following additional requirement:
In the case that the Explicit Source FEC Payload ID is used, then
only one FEC scheme MUST be used for this source flow, unless the
generic tag is used by all of the FEC schemes for the Source FEC
Payload ID, as defined in [I-D.ietf-fecframe-framework].
The FEC Framework also supports additivity among the repair flows,
meaning that multiple repair flows MAY be decoded jointly to improve
the recovery chances of the missing packets.
[I-D.ietf-mmusic-rfc4756bis] explains how the additive repair flows
can be described in SDP.
4.3. Source IP Addresses 4.3. Source IP Addresses
The 'source-filter' attribute of SDP ("a=source-filter") as defined The 'source-filter' attribute of SDP ("a=source-filter") as defined
in [RFC4570] is used to express the source addresses or fully in [RFC4570] is used to express the source addresses or fully
qualified domain names in the FEC Framework. qualified domain names in the FEC Framework.
4.4. Source Flows 4.4. Source Flows
The FEC Framework allows that multiple source flows MAY be grouped The FEC Framework allows that multiple source flows MAY be grouped
skipping to change at page 10, line 24 skipping to change at page 8, line 14
fec-source-flow-line = "a=fec-source-flow:" source-id fec-source-flow-line = "a=fec-source-flow:" source-id
[";" SP tag-length] CRLF [";" SP tag-length] CRLF
source-id = "id=" src-id source-id = "id=" src-id
src-id = 1*DIGIT src-id = 1*DIGIT
tag-length = "tag-len=" tlen tag-length = "tag-len=" tlen
tlen = *DIGIT tlen = *DIGIT
The MANDATORY parameter 'id' is used to identify the source flow. The REQUIRED parameter 'id' is used to identify the source flow.
Note that the parameter 'id' MUST be an integer. Parameter 'id' MUST be an integer.
The OPTIONAL 'tag-len' parameter is used to specify the length of the The OPTIONAL 'tag-len' parameter is used to specify the length of the
Explicit Source FEC Payload ID field (in bytes) and MUST be used Explicit Source FEC Payload ID field (in bytes). If no value is
according to the requirements listed in Section 4.2. If no value is
specified for the 'tag-len' parameter, it indicates a value of zero. specified for the 'tag-len' parameter, it indicates a value of zero.
However, in the case that an Explicit Source FEC Payload ID is used,
the 'tag-len' parameter MUST exist and indicate its length.
4.5. Repair Flows 4.5. Repair Flows
A repair flow MUST contain only repair packets formatted as described A repair flow MUST contain only repair packets formatted as described
in [I-D.ietf-fecframe-framework] for a single FEC Framework instance. in [I-D.ietf-fecframe-framework] for a single FEC Framework instance,
In other words, packets belonging to source flows or other repair i.e., packets belonging to source flows or other repair flows from a
flows from a different FEC Framework instance MUST NOT be sent within different FEC Framework instance cannot be sent within this flow. We
this flow. We introduce the attribute 'fec-repair-flow' to describe introduce the attribute 'fec-repair-flow' to describe the repair
the repair flows. flows.
The syntax for the new attribute in ABNF is as follows: The syntax for the new attribute in ABNF is as follows:
fec-repair-flow-line = "a=fec-repair-flow:" SP fec-encoding-id fec-repair-flow-line = "a=fec-repair-flow:" SP fec-encoding-id
[";" SP flow-preference] [";" SP flow-preference]
[";" SP sender-side-scheme-specific] [";" SP sender-side-scheme-specific]
[";" SP scheme-specific] CRLF [";" SP scheme-specific] CRLF
fec-encoding-id = "encoding-id=" enc-id fec-encoding-id = "encoding-id=" enc-id
enc-id = 1*DIGIT ; FEC Encoding ID enc-id = 1*DIGIT ; FEC Encoding ID
flow-preference = "preference-lvl=" preference-level-of-the-flow flow-preference = "preference-lvl=" preference-level-of-the-flow
preference-level-of-the-flow = *DIGIT preference-level-of-the-flow = *DIGIT
sender-side-scheme-specific = "ss-fssi=" sender-info sender-side-scheme-specific = "ss-fssi=" sender-info
sender-info = *CHAR sender-info = *CHAR
scheme-specific = "fssi=" scheme-info scheme-specific = "fssi=" scheme-info
scheme-info = *CHAR scheme-info = *CHAR
The MANDATORY parameter 'encoding-id' is used to identify the FEC The REQUIRED parameter 'encoding-id' is used to identify the FEC
scheme used to generate this repair flow. These identifiers MUST be scheme used to generate this repair flow. These identifiers MUST be
registered with IANA by the FEC schemes that use the FEC Framework. registered with IANA by the FEC schemes that use the FEC Framework.
The OPTIONAL parameter 'preference-lvl' is used to indicate the The OPTIONAL parameter 'preference-lvl' is used to indicate the
preferred order of using the repair flows. The exact usage of the preferred order of using the repair flows. The exact usage of the
parameter 'preference-lvl' and the pertaining rules MAY be defined by parameter 'preference-lvl' and the pertaining rules MAY be defined by
the FEC scheme or the CDP. If no value is specified for the the FEC scheme or the CDP. If no value is specified for the
parameter 'preference-lvl', it means that the receiver(s) MAY receive parameter 'preference-lvl', it means that the receiver(s) MAY receive
and use the repair flows in any order. However, if a preference and use the repair flows in any order. However, if a preference
level is assigned to the repair flow(s), the receivers are encouraged level is assigned to the repair flow(s), the receivers are encouraged
skipping to change at page 12, line 16 skipping to change at page 10, line 16
packets and generates a number of repair packets. Then both the packets and generates a number of repair packets. Then both the
source and repair packets are transmitted within a certain duration source and repair packets are transmitted within a certain duration
not larger than the value of the repair window. The value of the not larger than the value of the repair window. The value of the
repair window impacts the maximum number of source packets that can repair window impacts the maximum number of source packets that can
be included in an FEC block. be included in an FEC block.
At the receiver side, the FEC decoder should wait at least for the At the receiver side, the FEC decoder should wait at least for the
duration of the repair window after getting the first packet in an duration of the repair window after getting the first packet in an
FEC block to allow all the repair packets to arrive (The waiting time FEC block to allow all the repair packets to arrive (The waiting time
can be adjusted if there are mising packets at the beginning of the can be adjusted if there are mising packets at the beginning of the
FEC block). The FEC decoder may start decoding the already received FEC block). The FEC decoder can start decoding the already received
packets sooner, however, it SHOULD NOT register an FEC decoding packets sooner, however, it SHOULD NOT register an FEC decoding
failure until it waits at least for the repair-window duration. failure until it waits at least for the repair-window duration.
This document specifies a new attribute to describe the size of the This document specifies a new attribute to describe the size of the
repair window in milliseconds and microseconds. repair window in milliseconds and microseconds.
The syntax for the attribute in ABNF is as follows: The syntax for the attribute in ABNF is as follows:
repair-window-line = "a=repair-window:" window-size repair-window-line = "a=repair-window:" window-size
[unit] CRLF [unit] CRLF
window-size = 1*DIGIT window-size = 1*DIGIT
unit = ms / us unit = ms / us
<unit> is the unit of time the repair window size is specified with. <unit> is the unit of time the repair window size is specified with.
Currently, two units are defined: 'ms', which stands for Two units are defined here: 'ms', which stands for milliseconds and
milliseconds and 'us', which stands for microseconds. The default 'us', which stands for microseconds.
unit is 'ms'. Alternative units MAY be defined in the future by
registering them with IANA.
The 'a=repair-window' attribute is a media-level attribute since each The 'a=repair-window' attribute is a media-level attribute since each
repair flow MAY have a different repair window size. repair flow MAY have a different repair window size.
Specifying the repair window size in an absolute time value may not Specifying the repair window size in an absolute time value does not
correspond to an integer number of packets or exactly match with the necessarily correspond to an integer number of packets or exactly
clock rate used in RTP (in case of RTP transport) causing mismatches match with the clock rate used in RTP (in case of RTP transport)
among subsequent repair windows. However, in practice, this mismatch causing mismatches among subsequent repair windows. However, in
does not break anything in the FEC decoding process. practice, this mismatch does not break anything in the FEC decoding
process.
4.7. Bandwidth Specification 4.7. Bandwidth Specification
The bandwidth specification as defined in [RFC4566] denotes the The bandwidth specification as defined in [RFC4566] denotes the
proposed bandwidth to be used by the session or media. The proposed bandwidth to be used by the session or media. The
specification of bandwidth is OPTIONAL. specification of bandwidth is OPTIONAL.
In the context of the FEC Framework, the bandwidth specification can In the context of the FEC Framework, the bandwidth specification can
be used to express the bandwidth of the repair flows or the bandwidth 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 of the session. If included in the SDP, it SHALL adhere to the
following rules: following rules:
The session-level bandwidth for an FEC Framework instance MAY be The session-level bandwidth for an FEC Framework instance or the
media-level bandwidth for the individual repair flows MAY be
specified. In this case, it is RECOMMENDED to use the Transport specified. In this case, it is RECOMMENDED to use the Transport
Independent Application Specific (TIAS) bandwidth modifier [RFC3890] Independent Application Specific (TIAS) bandwidth modifier [RFC3890]
and the 'a=maxprate' attribute for the session. and the 'a=maxprate' attribute unless the Application Specific (AS)
bandwidth modifier [RFC4566] is used. The use of AS bandwidth
The media-level bandwidth for the individual repair flows MAY also be modifier is NOT RECOMMENDED since TIAS allows the calculation of the
specified. In this case, it is RECOMMENDED to use the TIAS bandwidth bitrate according to the IP version and transport protocol, whereas
modifier [RFC3890]. AS does not. Thus, in TIAS-based bitrate calculations, the packet
size SHALL include all headers and payload, excluding the IP and UDP
The Application Specific (AS) bandwidth modifier [RFC4566] MAY be headers. In AS-based bitrate calculations, the packet size SHALL
used instead of TIAS, however, this is NOT RECOMMENDED since TIAS include all headers and payload, plus the IP and UDP headers.
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 For the ABNF syntax information of the TIAS and AS, refer to
[RFC3890] and [RFC4566], respectively. [RFC3890] and [RFC4566], respectively.
5. Scenarios and Examples 5. Scenarios and Examples
This section discusses the considerations for session announcement This section discusses the considerations for Session Announcement
and offer/answer models. SDP examples that can be used by the FEC and Offer/Answer Models.
Framework are also provided.
5.1. Declarative Considerations 5.1. Declarative Considerations
In multicast-based applications, the FEC Framework Configuration In multicast-based applications, the FEC Framework Configuration
Information pertaining to all FEC protection options available at the Information pertaining to all FEC protection options available at the
sender MAY be advertised to the receivers as a part of a session sender MAY be advertised to the receivers as a part of a session
announcement. This way, the sender can let the receivers know all announcement. This way, the sender can let the receivers know all
available options for FEC protection. Based on their needs, the available options for FEC protection. Based on their needs, the
receivers MAY choose protection provided by one or more FEC Framework receivers MAY choose protection provided by one or more FEC Framework
instances and subscribe to the respective multicast group(s) to instances and subscribe to the respective multicast session(s) to
receive the repair flow(s). Unless explicitly required by the CDP, receive the repair flow(s). Unless explicitly required by the CDP,
the receivers SHOULD NOT send an answer back to the sender specifying the receivers SHOULD NOT send an answer back to the sender specifying
their choices. their choices since this can easily overwhelm the sender particularly
in large-scale multicast applications.
5.2. Offer/Answer Model Considerations 5.2. Offer/Answer Model Considerations
In unicast-based applications, a sender and receiver MAY adopt the In unicast-based applications, a sender and receiver MAY adopt the
offer/answer model [RFC3264] to set the FEC Framework Configuration Offer/Answer Model [RFC3264] to set the FEC Framework Configuration
Information. In this case, the sender offers all available options Information. In this case, the sender offers the options available
to the receiver and the receiver answers back to the sender with its to this particular receiver and the receiver answers back to the
choice(s). Note that some FEC protection options MAY be offered to sender with its choice(s).
only a particular set of receivers.
Receivers supporting the SDP Capability Negotiation Framework Receivers supporting the SDP Capability Negotiation Framework
[I-D.ietf-mmusic-sdp-capability-negotiation] MAY also use this [I-D.ietf-mmusic-sdp-capability-negotiation] MAY also use this
framework to negotiate all or a subset of the FEC Framework framework to negotiate all or a subset of the FEC Framework
parameters. parameters.
The backward compatibility in offer/answer model is handled as The backward compatibility in Offer/Answer Model is handled as
specified in [I-D.ietf-mmusic-rfc4756bis]. specified in [I-D.ietf-mmusic-rfc4756bis].
5.3. Examples 6. SDP Examples
[I-D.ietf-mmusic-rfc3388bis] defines the media stream identification This section provides SDP examples that can be used by the FEC
attribute ('mid') as a token in ABNF. In contrast, the identifiers Framework.
for the source flows MUST be integers and SHOULD 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, an FEC Encoding ID of zero will be used for [RFC5888] defines the media stream identification attribute ('mid')
as a token in ABNF. In contrast, the identifiers for the source
flows MUST be integers and SHOULD 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 illustrative purposes. Artificial content for the SS-FSSI and FSSI
will also be provided. will also be provided.
5.3.1. One Source Flow, One Repair Flow and One FEC Scheme 6.1. One Source Flow, One Repair Flow and One FEC Scheme
SOURCE FLOWS | INSTANCE #1 SOURCE FLOWS | INSTANCE #1
0: Source Flow |---------| 1: Repair Flow S1: Source Flow |--------| R1: Repair Flow
| |
Figure 2: Scenario #1 Figure 1: Scenario #1
In this example, we have one source video flow (mid:S1) and one FEC 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-XR 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 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. on different multicast groups. The repair window is set to 150 ms.
v=0 v=0
o=ali 1122334455 1122334466 IN IP4 fec.example.com o=ali 1122334455 1122334466 IN IP4 fec.example.com
s=FEC Framework Examples s=FEC Framework Examples
t=0 0 t=0 0
a=group:FEC-XR S1 R1 a=group:FEC-FR S1 R1
m=video 30000 RTP/AVP 100 m=video 30000 RTP/AVP 100
c=IN IP4 233.252.0.1/127 c=IN IP4 233.252.0.1/127
a=rtpmap:100 MP2T/90000 a=rtpmap:100 MP2T/90000
a=fec-source-flow: id=0 a=fec-source-flow: id=0
a=mid:S1 a=mid:S1
m=application 30000 udp/fec m=application 30000 udp/fec
c=IN IP4 233.252.0.2/127 c=IN IP4 233.252.0.2/127
a=fec-repair-flow: encoding-id=0; ss-fssi=n:7,k:5 a=fec-repair-flow: encoding-id=0; ss-fssi=n:7,k:5
a=repair-window:150 a=repair-window:150
a=mid:R1 a=mid:R1
5.3.2. Two Source Flows, One Repair Flow and One FEC Scheme 6.2. Two Source Flows, One Repair Flow and One FEC Scheme
SOURCE FLOWS SOURCE FLOWS
0: Source Flow | | INSTANCE #1 S2: Source Flow | | INSTANCE #1
|---------| 2: Repair Flow |---------| R2: Repair Flow
1: Source Flow | S3: Source Flow |
Figure 3: Scenario #2 Figure 2: Scenario #2
In this example, we have two source video flows (mid:S1 and mid:S2) In this example, we have two source video flows (mid:S2 and mid:S3)
and one FEC repair flow (mid:R1), protecting both source flows. We and one FEC repair flow (mid:R2), protecting both source flows. We
form one FEC group with the "a=group:FEC-XR S1 S2 R1" line. The 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 source and repair flows are sent to the same port on different
multicast groups. The repair window is set to 150500 us. multicast groups. The repair window is set to 150500 us.
v=0 v=0
o=ali 1122334455 1122334466 IN IP4 fec.example.com o=ali 1122334455 1122334466 IN IP4 fec.example.com
s=FEC Framework Examples s=FEC Framework Examples
t=0 0 t=0 0
a=group:FEC-XR S1 S2 R1 a=group:FEC-FR S2 S3 R2
m=video 30000 RTP/AVP 100 m=video 30000 RTP/AVP 100
c=IN IP4 233.252.0.1/127 c=IN IP4 233.252.0.1/127
a=rtpmap:100 MP2T/90000 a=rtpmap:100 MP2T/90000
a=fec-source-flow: id=0 a=fec-source-flow: id=0
a=mid:S1 a=mid:S2
m=video 30000 RTP/AVP 101 m=video 30000 RTP/AVP 101
c=IN IP4 233.252.0.2/127 c=IN IP4 233.252.0.2/127
a=rtpmap:101 MP2T/90000 a=rtpmap:101 MP2T/90000
a=fec-source-flow: id=1 a=fec-source-flow: id=1
a=mid:S2 a=mid:S3
m=application 30000 udp/fec m=application 30000 udp/fec
c=IN IP4 233.252.0.3/127 c=IN IP4 233.252.0.3/127
a=fec-repair-flow: encoding-id=0; ss-fssi=n:7,k:5 a=fec-repair-flow: encoding-id=0; ss-fssi=n:7,k:5
a=repair-window:150500us a=repair-window:150500us
a=mid:R1 a=mid:R2
5.3.3. Two Source Flows, Two Repair Flows and Two FEC Schemes 6.3. Two Source Flows, Two Repair Flows and Two FEC Schemes
SOURCE FLOWS | INSTANCE #1 SOURCE FLOWS | INSTANCE #1
0: Source Flow |---------| 2: Repair Flow S4: Source Flow |--------| R3: Repair Flow
1: Source Flow |---------| INSTANCE #2 S5: Source Flow |--------| INSTANCE #2
| 3: Repair Flow | R4: Repair Flow
Figure 4: Scenario #3 Figure 3: Scenario #3
In this example, we have two source video flows (mid:S1 and mid:S2) In this example, we have two source video flows (mid:S4 and mid:S5)
and two FEC repair flows (mid:R1 and mid:R2). The source flows and two FEC repair flows (mid:R3 and mid:R4). The source flows
mid:S1 and mid:S2 are protected by the repair flows mid:R1 and mid:S4 and mid:S5 are protected by the repair flows mid:R3 and
mid:R2, respectively. We form two FEC groups with the "a=group: mid:R4, respectively. We form two FEC groups with the "a=group:
FEC-XR S1 R1" and "a=group:FEC-XR S2 R2" lines. The source and 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. 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 The repair window is set to 200 ms and 400 ms for the first and
second FEC group, respectively. second FEC group, respectively.
v=0 v=0
o=ali 1122334455 1122334466 IN IP4 fec.example.com o=ali 1122334455 1122334466 IN IP4 fec.example.com
s=FEC Framework Examples s=FEC Framework Examples
t=0 0 t=0 0
a=group:FEC-XR S1 R1 a=group:FEC-FR S4 R3
a=group:FEC-XR S2 R2 a=group:FEC-FR S5 R4
m=video 30000 RTP/AVP 100 m=video 30000 RTP/AVP 100
c=IN IP4 233.252.0.1/127 c=IN IP4 233.252.0.1/127
a=rtpmap:100 MP2T/90000 a=rtpmap:100 MP2T/90000
a=fec-source-flow: id=0 a=fec-source-flow: id=0
a=mid:S1 a=mid:S4
m=video 30000 RTP/AVP 101 m=video 30000 RTP/AVP 101
c=IN IP4 233.252.0.2/127 c=IN IP4 233.252.0.2/127
a=rtpmap:101 MP2T/90000 a=rtpmap:101 MP2T/90000
a=fec-source-flow: id=1 a=fec-source-flow: id=1
a=mid:S2 a=mid:S5
m=application 30000 udp/fec m=application 30000 udp/fec
c=IN IP4 233.252.0.3/127 c=IN IP4 233.252.0.3/127
a=fec-repair-flow: encoding-id=0; ss-fssi=n:7,k:5 a=fec-repair-flow: encoding-id=0; ss-fssi=n:7,k:5
a=repair-window:200ms a=repair-window:200ms
a=mid:R1 a=mid:R3
m=application 30000 udp/fec m=application 30000 udp/fec
c=IN IP4 233.252.0.4/127 c=IN IP4 233.252.0.4/127
a=fec-repair-flow: encoding-id=0; ss-fssi=n:14,k:10 a=fec-repair-flow: encoding-id=0; ss-fssi=n:14,k:10
a=repair-window:400ms a=repair-window:400ms
a=mid:R2 a=mid:R4
6. Security Considerations 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.
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 There is a weak threat if the SDP is modified in a way that it shows
incorrect association and/or grouping of the source and repair flows. incorrect association and/or grouping of the source and repair flows.
Such attacks may result in failure of FEC protection and/or Such attacks may result in failure of FEC protection and/or
mishandling of other media streams. It is RECOMMENDED that the mishandling of other media streams. It is RECOMMENDED that the
receiver SHOULD do integrity check on SDP and follow the security receiver SHOULD do integrity check on SDP and follow the security
considerations of SDP [RFC4566] to only trust SDP from trusted considerations of SDP [RFC4566] to only trust SDP from trusted
sources. For other general security considerations related to SDP, sources. For other general security considerations related to SDP,
refer to [RFC4566]. For the security considerations related to the refer to [RFC4566]. For the security considerations related to the
use of source address filters in SDP, refer to [RFC4570]. use of source address filters in SDP, refer to [RFC4570].
7. IANA Considerations The security considerations for the FEC Framework also apply. Refer
to [I-D.ietf-fecframe-framework] for details.
The following contact information shall be used for all registrations 8. IANA Considerations
in this document:
Ali Begen Note to the RFC Editor: In the following, please replace "XXXX" with
abegen@cisco.com the number of this document prior to publication as an RFC.
7.1. Transport Protocols 8.1. Registration of Transport Protocols
The 'proto' sub-field of the media description line ("m=") describes This specification updates the Session Description Protocol (SDP)
the transport protocol used. This document registers the following Parameters registry as defined in Section 8.2.2 of [RFC4566].
values:
UDP/FEC Specifically, it adds the following values to the table for the
'proto' field.
7.2. Attribute Names Type SDP Name Reference
------ ---------- -----------
proto UDP/FEC [RFCXXXX]
As recommended by [RFC4566], the following attribute names should be 8.2. Registration of SDP Attributes
registered with IANA.
Note to the RFC Editor: In the following, please replace "XXXX" with This document registers new attribute names in SDP.
the number of this document prior to publication as an RFC.
SDP Attribute ("att-field"): SDP Attribute ("att-field"):
Attribute name: fec-source-flow Attribute name: fec-source-flow
Long form: Pointer to FEC Source Flow Long form: Pointer to FEC Source Flow
Type of name: att-field Type of name: att-field
Type of attribute: Media level Type of attribute: Media level
Subject to charset: No Subject to charset: No
Purpose: See this document Purpose: Provide parameters for an FEC source flow
Reference: [RFCXXXX] Reference: [RFCXXXX]
Values: See this document Values: See [RFCXXXX]
SDP Attribute ("att-field"): SDP Attribute ("att-field"):
Attribute name: fec-repair-flow Attribute name: fec-repair-flow
Long form: Pointer to FEC Repair Flow Long form: Pointer to FEC Repair Flow
Type of name: att-field Type of name: att-field
Type of attribute: Media level Type of attribute: Media level
Subject to charset: No Subject to charset: No
Purpose: See this document Purpose: Provide parameters for an FEC repair flow
Reference: [RFCXXXX] Reference: [RFCXXXX]
Values: See this document Values: See [RFCXXXX]
SDP Attribute ("att-field"): SDP Attribute ("att-field"):
Attribute name: repair-window Attribute name: repair-window
Long form: Repair Window Size Long form: Pointer to FEC Repair Window
Type of name: att-field Type of name: att-field
Type of attribute: Media level Type of attribute: Media level
Subject to charset: No Subject to charset: No
Purpose: See this document Purpose: Indicate the size of the repair window
Reference: [RFCXXXX] Reference: [RFCXXXX]
Values: See this document Values: See [RFCXXXX]
8. Acknowledgments 9. Acknowledgments
The author would like to thank the FEC Framework Design Team for The author would like to thank the FEC Framework Design Team for
their inputs, suggestions and contributions. their inputs, suggestions and contributions.
9. Change Log
9.1. draft-ietf-fecframe-sdp-elements-06
The following are the major changes compared to version 05:
o Addressed the comments received during the WGLC.
9.2. draft-ietf-fecframe-sdp-elements-05
The following are the major changes compared to version 04:
o Updated boilerplate.
9.3. draft-ietf-fecframe-sdp-elements-04
The following are the major changes compared to version 03:
o Incorporated final outstanding issues for the WGLC.
9.4. draft-ietf-fecframe-sdp-elements-03
The following are the major changes compared to version 02:
o Now referencing to 3388bis and 4756bis instead of RFC 3388 and RFC
4756, respectively. Also cleaned up the editor's notes regarding
the grouping issues.
o Parameter "priority" has been replaced with "preference-lvl" for
the repair flows.
9.5. draft-ietf-fecframe-sdp-elements-02
The following are the major changes compared to version 01:
o Clarified the definitions for the FSSI fields.
o Hostnames in the SDP examples are fixed.
9.6. draft-ietf-fecframe-sdp-elements-01
The following are the major changes compared to version 00:
o Additive repair flows can now be from different instances. The
sender may also assign different levels of priorities to each
repair flow regardless of whether the repair flows are additive or
not.
o SDP examples are fixed.
o Comments posted in the mailing list are incorporated.
9.7. draft-ietf-fecframe-sdp-elements-00
This is the initial version, which is based on an earlier individual
submission. The following are the major changes compared to that
document:
o The opaque container in the FEC Framework Configuration
Information (FEC-Scheme-Specific Information) is now divided into
two parts: information needed only by the sender and information
needed by the receiver. The repair flow descriptors are also
updated accordingly.
o "Minimum Buffer Size" is now called "Repair Window." Its size can
also be specified in microseconds in addition to milliseconds.
o Simple examples with complete SDPs are included.
o "Scheme ID" is changed to "Encoding ID" to be consistent with the
framework draft.
o Some other editorial changes.
10. References 10. References
10.1. Normative References 10.1. Normative References
[I-D.ietf-fecframe-framework] [I-D.ietf-fecframe-framework]
Watson, M., "Forward Error Correction (FEC) Framework", Watson, M., "Forward Error Correction (FEC) Framework",
draft-ietf-fecframe-framework-07 (work in progress), draft-ietf-fecframe-framework-09 (work in progress),
March 2010. July 2010.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006. Description Protocol", RFC 4566, July 2006.
[RFC4570] Quinn, B. and R. Finlayson, "Session Description Protocol [RFC4570] Quinn, B. and R. Finlayson, "Session Description Protocol
(SDP) Source Filters", RFC 4570, July 2006. (SDP) Source Filters", RFC 4570, July 2006.
[I-D.ietf-mmusic-rfc3388bis] [RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description
Camarillo, G. and H. Schulzrinne, "The SDP (Session Protocol (SDP) Grouping Framework", RFC 5888, June 2010.
Description Protocol) Grouping Framework",
draft-ietf-mmusic-rfc3388bis-04 (work in progress),
November 2009.
[I-D.ietf-mmusic-rfc4756bis] [I-D.ietf-mmusic-rfc4756bis]
Begen, A., "Forward Error Correction Grouping Semantics in Begen, A., "Forward Error Correction Grouping Semantics in
Session Description Protocol", Session Description Protocol",
draft-ietf-mmusic-rfc4756bis-07 (work in progress), draft-ietf-mmusic-rfc4756bis-10 (work in progress),
April 2010. June 2010.
[RFC3890] Westerlund, M., "A Transport Independent Bandwidth [RFC3890] Westerlund, M., "A Transport Independent Bandwidth
Modifier for the Session Description Protocol (SDP)", Modifier for the Session Description Protocol (SDP)",
RFC 3890, September 2004. RFC 3890, September 2004.
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008. Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
with Session Description Protocol (SDP)", RFC 3264, with Session Description Protocol (SDP)", RFC 3264,
June 2002. June 2002.
10.2. Informative References 10.2. Informative References
[RFC5052] Watson, M., Luby, M., and L. Vicisano, "Forward Error
Correction (FEC) Building Block", RFC 5052, August 2007.
[I-D.ietf-fecframe-config-signaling] [I-D.ietf-fecframe-config-signaling]
Asati, R., "Methods to convey FEC Framework Configuration Asati, R., "Methods to convey FEC Framework Configuration
Information", draft-ietf-fecframe-config-signaling-02 Information", draft-ietf-fecframe-config-signaling-03
(work in progress), February 2010. (work in progress), June 2010.
[I-D.ietf-mmusic-sdp-capability-negotiation] [I-D.ietf-mmusic-sdp-capability-negotiation]
Andreasen, F., "SDP Capability Negotiation", Andreasen, F., "SDP Capability Negotiation",
draft-ietf-mmusic-sdp-capability-negotiation-13 (work in draft-ietf-mmusic-sdp-capability-negotiation-13 (work in
progress), March 2010. progress), March 2010.
Author's Address Author's Address
Ali Begen Ali Begen
Cisco Cisco
170 West Tasman Drive 181 Bay Street
San Jose, CA 95134 Toronto, ON M5J 2T3
USA Canada
Email: abegen@cisco.com Email: abegen@cisco.com
 End of changes. 92 change blocks. 
407 lines changed or deleted 242 lines changed or added

This html diff was produced by rfcdiff 1.38. The latest version is available from http://tools.ietf.org/tools/rfcdiff/