draft-ietf-fecframe-sdp-elements-01.txt   draft-ietf-fecframe-sdp-elements-02.txt 
FEC Framework A. Begen FEC Framework A. Begen
Internet-Draft Cisco Systems Internet-Draft Cisco Systems
Intended status: Standards Track July 14, 2008 Intended status: Standards Track November 3, 2008
Expires: January 15, 2009 Expires: May 7, 2009
SDP Elements for FEC Framework SDP Elements for FEC Framework
draft-ietf-fecframe-sdp-elements-01 draft-ietf-fecframe-sdp-elements-02
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 34 skipping to change at page 1, line 34
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."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 15, 2009. This Internet-Draft will expire on May 7, 2009.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2008). Copyright (C) The IETF Trust (2008).
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 the semantics sender(s) and receiver(s). This document also provides examples that
for grouping multiple source and repair flows together for the show the semantics for grouping multiple source and repair flows
applications that simultaneously use multiple instances of the FEC together for the applications that simultaneously use multiple
Framework. instances of the FEC Framework.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 3 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 3
3. Forward Error Correction (FEC) and FEC Framework . . . . . . . 3 3. Forward Error Correction (FEC) and FEC Framework . . . . . . . 3
3.1. Forward Error Correction (FEC) . . . . . . . . . . . . . . 3 3.1. Forward Error Correction (FEC) . . . . . . . . . . . . . . 3
3.2. FEC Framework . . . . . . . . . . . . . . . . . . . . . . 4 3.2. FEC Framework . . . . . . . . . . . . . . . . . . . . . . 4
3.3. FEC Framework Configuration Information . . . . . . . . . 5 3.3. FEC Framework Configuration Information . . . . . . . . . 5
4. SDP Descriptors for FEC Framework . . . . . . . . . . . . . . 6 4. SDP Descriptors for FEC Framework . . . . . . . . . . . . . . 6
4.1. Transport Protocol Identifiers . . . . . . . . . . . . . . 6 4.1. Transport Protocol Identifiers . . . . . . . . . . . . . . 6
4.2. Media Stream Grouping . . . . . . . . . . . . . . . . . . 7 4.2. Media Stream Grouping . . . . . . . . . . . . . . . . . . 7
4.3. Source IP Addresses . . . . . . . . . . . . . . . . . . . 9 4.3. Source IP Addresses . . . . . . . . . . . . . . . . . . . 9
4.4. Source Flows . . . . . . . . . . . . . . . . . . . . . . . 9 4.4. Source Flows . . . . . . . . . . . . . . . . . . . . . . . 9
4.5. Repair Flows . . . . . . . . . . . . . . . . . . . . . . . 9 4.5. Repair Flows . . . . . . . . . . . . . . . . . . . . . . . 9
4.6. Repair Window . . . . . . . . . . . . . . . . . . . . . . 10 4.6. Repair Window . . . . . . . . . . . . . . . . . . . . . . 11
4.7. Bandwidth Specification . . . . . . . . . . . . . . . . . 11 4.7. Bandwidth Specification . . . . . . . . . . . . . . . . . 11
5. Scenarios and Examples . . . . . . . . . . . . . . . . . . . . 12 5. Scenarios and Examples . . . . . . . . . . . . . . . . . . . . 12
5.1. Session Announcement Considerations . . . . . . . . . . . 12 5.1. Session Announcement Considerations . . . . . . . . . . . 12
5.2. Offer/Answer Considerations . . . . . . . . . . . . . . . 12 5.2. Offer/Answer Considerations . . . . . . . . . . . . . . . 12
5.3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 13 5.3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 13
5.3.1. One Source Flow, One Repair Flow and One FEC Scheme . 13 5.3.1. One Source Flow, One Repair Flow and One FEC Scheme . 13
5.3.2. Two Source Flows, One Repair Flow and One FEC 5.3.2. Two Source Flows, One Repair Flow and One FEC
Scheme . . . . . . . . . . . . . . . . . . . . . . . . 14 Scheme . . . . . . . . . . . . . . . . . . . . . . . . 14
5.3.3. Two Source Flows, Two Repair Flows and Two FEC 5.3.3. Two Source Flows, Two Repair Flows and Two FEC
Schemes . . . . . . . . . . . . . . . . . . . . . . . 15 Schemes . . . . . . . . . . . . . . . . . . . . . . . 15
6. Security Considerations . . . . . . . . . . . . . . . . . . . 16 6. Security Considerations . . . . . . . . . . . . . . . . . . . 16
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
7.1. Transport Protocols . . . . . . . . . . . . . . . . . . . 16 7.1. Transport Protocols . . . . . . . . . . . . . . . . . . . 16
7.2. Attribute Names . . . . . . . . . . . . . . . . . . . . . 17 7.2. Attribute Names . . . . . . . . . . . . . . . . . . . . . 17
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18
9. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 18 9. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 18
9.1. draft-ietf-fecframe-sdp-elements-01 . . . . . . . . . . . 18 9.1. draft-ietf-fecframe-sdp-elements-02 . . . . . . . . . . . 18
9.2. draft-ietf-fecframe-sdp-elements-00 . . . . . . . . . . . 18 9.2. draft-ietf-fecframe-sdp-elements-01 . . . . . . . . . . . 18
9.3. draft-ietf-fecframe-sdp-elements-00 . . . . . . . . . . . 18
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
10.1. Normative References . . . . . . . . . . . . . . . . . . . 19 10.1. Normative References . . . . . . . . . . . . . . . . . . . 19
10.2. Informative References . . . . . . . . . . . . . . . . . . 20 10.2. Informative References . . . . . . . . . . . . . . . . . . 19
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 20 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 20
Intellectual Property and Copyright Statements . . . . . . . . . . 21 Intellectual Property and Copyright Statements . . . . . . . . . . 21
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
skipping to change at page 3, line 45 skipping to change at page 3, line 45
"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 the packet losses. FEC is an packet network has to cope with packet losses. FEC is an effective
effective approach that provides reliable transmission particularly approach that provides reliable transmission particularly in
in multicast and broadcast applications where the feedback from the multicast and broadcast applications where the feedback from the
receiver(s) may be potentially limited. In a nutshell, FEC groups receiver(s) is potentially limited.
source packets into blocks and applies protection to generate a
desired number of repair packets.
Repair packets MAY be sent on demand or independently of any receiver In a nutshell, FEC groups source packets into blocks and applies
feedback. The choice depends on the FEC code used by the protection to generate a desired number of repair packets. These
application, the error characteristics of the underlying network, the repair packets may be sent on demand or independently of any receiver
transport scheme (e.g., unicast, multicast, and broadcast), and the feedback. The choice depends on the FEC scheme or the Content
application. At the receiver side, lost packets can be recovered by Delivery Protocol used by the application, the packet loss
erasure decoding provided that a sufficient number of source and characteristics of the underlying network, the transport scheme
repair packets are received. See [I-D.ietf-fecframe-framework] for (e.g., unicast, multicast and broadcast) and the application. At the
further details. 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 3.2. FEC Framework
The FEC Framework [I-D.ietf-fecframe-framework] outlines a general The FEC Framework [I-D.ietf-fecframe-framework] outlines a general
framework for using FEC codes in multimedia applications that stream framework for using FEC codes in multimedia applications that stream
audio, video or other types of multimedia content. It defines the audio, video or other types of multimedia content. It defines the
common components and aspects of Content Delivery Protocols (CDP). common components and aspects of Content Delivery Protocols (CDP).
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
skipping to change at page 5, line 20 skipping to change at page 5, line 20
Framework Configuration Information. This information specifies how Framework Configuration Information. This information specifies how
the sender applies protection to the source flow(s) and how the the sender applies protection to the source flow(s) and how the
repair flow(s) can be used to recover lost data. In other words, repair flow(s) can be used to recover lost data. In other words,
this information specifies the relationship(s) between the source and this information specifies the relationship(s) between the source and
repair flows. repair flows.
The FEC Framework Configuration Information includes identifiers for The FEC Framework Configuration Information includes identifiers for
unique identification of the source and repair flows that carry the unique identification of the source and repair flows that carry the
source and repair packets, respectively. For example, a packet flow source and repair packets, respectively. For example, a packet flow
that is transmitted over UDP is uniquely identified by the tuple of that is transmitted over UDP is uniquely identified by the tuple of
{Source IP Address, Destination IP Address, Source UDP port, {Source IP Address, Destination IP Address, Source UDP Port,
Destination UDP port}. However, an integer identifier MAY be used Destination UDP Port}. However, an integer identifier MAY be used
internally within the FEC scheme as a shorthand to identify this internally within the FEC scheme as a shorthand to identify this
flow. flow.
Multiple instances of the FEC Framework MAY simultaneously exist at Multiple instances of the FEC Framework MAY 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 source flows. Each
instance of the FEC Framework MUST provide the following FEC instance of the FEC Framework MUST provide the following FEC
Framework Configuration Information: Framework Configuration Information:
1. Identification of the repair flows. 1. Identification of the repair flows.
skipping to change at page 5, line 46 skipping to change at page 5, line 46
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. Note that an application MAY wildcard
some of the fields if only a subset of the fields of the tuple some of the fields if only a subset of the fields of the tuple
(e.g., {Destination IP Address, Destination UDP port} ) is (e.g., {Destination IP Address, Destination UDP Port} ) is
sufficient. sufficient.
3. The FEC Encoding ID that identifies the FEC scheme. 3. The FEC Encoding ID that identifies 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 This value MAY be zero indicating that no Explicit Source FEC
Payload ID is used by the FEC scheme. If it is nonzero, however, Payload ID is used by the FEC scheme. If it is nonzero, however,
it means that the Explicit Source FEC Payload ID is used. In this it means that the Explicit Source FEC Payload ID is used. In this
case, only one FEC scheme MUST be used for this source flow, case, only one FEC scheme MUST be used for this source flow,
unless the generic tag (defined in [I-D.ietf-fecframe-framework]) unless the generic tag (defined in [I-D.ietf-fecframe-framework])
is used by all of the FEC schemes protecting this source flow. is used by all of the FEC schemes protecting this source flow.
5. An opaque container for the FEC-Scheme-Specific Information 5. An opaque container for the FEC-Scheme-Specific Information (FSSI)
required only by the sender. This information is referred to as that is required by only the receiver or by both the receiver and
the Sender-Side FEC-Scheme-Specific Information (SS-FSSI). sender.
6. An opaque container for the FEC-Scheme-Specific Information 6. Another opaque container for the FSSI that is only required by the
required by the receiver. This information is referred to as the sender. This is referred to as the Sender-Side FEC-Scheme-
Receiver-Side FEC-Scheme-Specific Information (RS-FSSI). 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 from the rest of the FSSI is to
provide the receiver or the 3rd party entities a means of controlling provide the receiver or the 3rd party entities a means of controlling
the FEC operations at the sender. Any FSSI other than the one solely the FEC operations at the sender. Any FSSI other than the one solely
required by the sender MUST be communicated via the RS-FSSI required by the sender MUST be communicated via the FSSI container.
container.
The variable-length opaque SS-FSSI and RS-FSSI containers transmit The variable-length opaque SS-FSSI and FSSI containers transmit the
the information in the form of an octet string. The FEC schemes information in the form of an octet string. The FEC schemes define
define the structure of this octet string, which MAY contain multiple the structure of this octet string, which MAY contain multiple
distinct elements. If the FEC scheme does not require any specific distinct elements. If the FEC scheme does not require any specific
information, the FSSI MAY be null. For the fully-specified FEC information, the FSSI MAY be null. For the fully-specified FEC
schemes, a full description of the encoded information in both schemes, a full description of the encoded information in both
containers MUST be provided. See [I-D.ietf-fecframe-framework] for containers MUST be provided. See [I-D.ietf-fecframe-framework] for
details. details.
4. SDP Descriptors for FEC Framework 4. SDP Descriptors for FEC Framework
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
skipping to change at page 7, line 34 skipping to change at page 7, line 34
Framework instances. Furthermore, within a single FEC Framework Framework instances. Furthermore, within a single FEC Framework
instance, multiple source flows MAY be protected by multiple repair instance, multiple source flows MAY be protected by multiple repair
flows. However, each repair flow MUST provide protection for a flows. However, each repair flow MUST provide protection for a
single FEC Framework instance. An example scenario is shown in single FEC Framework instance. An example scenario is shown in
Figure 1. Here, source flows 0 and 1 are grouped together and 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 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 flow 4; source flows 1 and 2 are grouped together and protected by
repair flows 5, 6 and 7. repair flows 5, 6 and 7.
The motivation behind grouping source flows before applying FEC The motivation behind grouping source flows before applying FEC
protection is that a better coding performance can be achieved by protection is that a better coding performance may be achieved by
doing so and many receivers may benefit from this grouping. For doing so and many receivers may benefit from this grouping. For
example, consider a layered video source that consists of one base example, consider a layered video source that consists of one base
layer (e.g., source flow 0) and one enhancement layer (e.g., source 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 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 3 protects the combination of the base and enhancement layers for the
receivers who receive both layers, and repair flow 4 protects 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 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 who receive both layers but prefer FEC protection for the base layer
only due to their bandwidth and/or processing limitations. only due to a bandwidth and/or processing-power limitation.
Using multiple FEC Framework instances for a single source flow Using multiple FEC Framework instances for a single source flow
provides flexibility to the receivers. Different instances may use provides flexibility to the receivers. Different instances may offer
larger or smaller source block sizes, which accommodate the receivers repair flows that are generated by different FEC schemes, and
that have looser and tighter latency requirements, respectively. receivers choose receiving the appropriate repair flow(s) that they
Different instances may also provide FEC protection at different can support and decode. Alternatively, different instances (whether
redundancy levels. This enables the receivers experiencing different they use the same FEC scheme or not) may use larger and smaller
packet loss rates to choose the repair flows that are tailored to source block sizes, which accommodate the receivers that have looser
their needs. 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 ____| FEC FRAMEWORK
/ | INSTANCE / | INSTANCE
/ | 3: Repair Flow / | 3: Repair Flow
/ /
SOURCE FLOWS / | FEC FRAMEWORK SOURCE FLOWS / | FEC FRAMEWORK
0: Source Flow |___/ |------| INSTANCE 0: Source Flow |___/ |------| INSTANCE
__| 1: Source Flow | | 4: Repair Flow __| 1: Source Flow | | 4: Repair Flow
| | 2: Source Flow | | 2: Source Flow
| | FEC FRAMEWORK | | FEC FRAMEWORK
|__________________________| INSTANCE |__________________________| INSTANCE
skipping to change at page 8, line 44 skipping to change at page 8, line 47
"a=group:FEC" line. Thus, [RFC3388] mandates us to write "a=group:FEC" line. Thus, [RFC3388] mandates us to write
a=group:FEC 0 1 2 3 4 5 6 7 a=group:FEC 0 1 2 3 4 5 6 7
for the scenario sketched in Figure 1. This limitation prevents us for the scenario sketched in Figure 1. This limitation prevents us
from indicating particular associations between the source and repair from indicating particular associations between the source and repair
flows by using an "a=group:FEC" line per FEC Framework instance flows by using an "a=group:FEC" line per FEC Framework instance
[RFC4756]. [RFC4756].
Editor's note: The FEC grouping and flow association issues are Editor's note: The FEC grouping and flow association issues are
currently under discussion in FECFRAME and MMUSIC WGs. This section currently under discussion in FECFRAME and MMUSIC WGs (See
will be updated once a decision is made. [I-D.begen-mmusic-rfc4756bis]). This section will be updated once a
decision is made.
The FEC Framework also supports additivity among the repair flows, The FEC Framework also supports additivity among the repair flows,
meaning that multiple repair flows MAY be decoded jointly to improve meaning that multiple repair flows MAY be decoded jointly to improve
the recovery chances of the missing packets. In addition, the sender the recovery chances of the missing packets. In addition, the sender
MAY assign different levels of priority to each repair flow. See MAY assign different levels of priority to each repair flow. See
Section 4.5 for details. Section 4.5 for details.
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
skipping to change at page 10, line 7 skipping to change at page 10, line 10
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 In other words, packets belonging to source flows or other repair
flows from a different FEC Framework instance MUST NOT be sent within flows from a different FEC Framework instance MUST NOT be sent within
this flow. We introduce the attribute 'fec-repair-flow' to describe this flow. We introduce the attribute 'fec-repair-flow' to describe
the repair flows. the repair 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:" fec-encoding-id fec-repair-flow-line = "a=fec-repair-flow:" fec-encoding-id
[";" SP flow-priority] [";" SP sender-side-scheme-specific] [";" SP flow-priority] [";" SP sender-side-scheme-specific]
[";" SP receiver-side-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-priority = "priority=" priority-of-the-flow flow-priority = "priority=" priority-of-the-flow
priority-of-the-flow = *DIGIT priority-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
receiver-side-scheme-specific = "rs-fssi=" receiver-info scheme-specific = "fssi=" scheme-info
receiver-info = *CHAR scheme-info = *CHAR
The MANDATORY parameter 'encoding-id' is used to identify the FEC The MANDATORY 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 'priority' is used to indicate the priorities The OPTIONAL parameter 'priority' is used to indicate the priorities
of the repair flows. The exact usage of the parameter 'priority' and of the repair flows. The exact usage of the parameter 'priority' and
the pertaining rules SHOULD be defined by the FEC scheme or the CDP. the pertaining rules MAY be defined by the FEC scheme or the CDP. If
If no value is specified for the parameter 'priority', it means that no value is specified for the parameter 'priority', it means that the
the receiver(s) MAY receive and use the repair flows in any order. receiver(s) MAY receive and use the repair flows in any order.
However, if a priority is assigned to the repair flow(s), the However, if a priority is assigned to the repair flow(s), the
receivers MUST follow the specified order in receiving and using the receivers MUST follow the specified order in receiving and using the
repair flow(s). repair flow(s).
The OPTIONAL parameters 'ss-fssi' and 'rs-fssi' are opaque containers The OPTIONAL parameters 'ss-fssi' and 'fssi' are opaque containers to
to convey the FEC-Scheme-Specific Information (FSSI) that includes convey the FEC-Scheme-Specific Information (FSSI) that includes the
the information that is specific to the FEC scheme used by the CDP information that is specific to the FEC scheme used by the CDP and is
and is necessary for proper FEC encoding and decoding operations. necessary for proper FEC encoding and decoding operations. The FSSI
The FSSI required only by the sender (called Sender-Side FSSI) MUST required only by the sender (called Sender-Side FSSI) MUST be
be communicated in the container specified by the parameter 'ss- communicated in the container specified by the parameter 'ss-fssi'.
fssi'. Any other FSSI (called Receiver-Side FSSI) MUST be Any other FSSI MUST be communicated in the container specified by the
communicated in the container specified by the parameter 'rs-fssi'. parameter 'fssi'. In both containers, FSSI is transmitted in the
In both containers, FSSI is transmitted in the form of an octet form of an octet string. The FEC schemes define the structure of
string. The FEC schemes define the structure of this octet string, this octet string, which MAY contain multiple distinct elements. If
which MAY contain multiple distinct elements. If the FEC scheme does the FEC scheme does not require any specific information, the 'ss-
not require any specific information, the 'ss-fssi' and 'rs-fssi' fssi' and 'fssi' parameters MAY be null and ignored.
parameters MAY be null and ignored.
4.6. Repair Window 4.6. Repair Window
An FEC encoder processes a block of source packets and generates a An FEC encoder processes a block of source packets and generates a
number of repair packets, which are then transmitted within a certain number of repair packets, which are then transmitted within a certain
duration. At the receiver side, the FEC decoder tries to decode all duration. At the receiver side, the FEC decoder tries to decode all
the packets received within the repair window to recover the missing the packets received within the repair window to recover the missing
packets, if there are any. Repair window stands for the time that packets, if there are any. Repair window stands for the time that
spans the source packets and the corresponding repair packets. spans the source packets and the corresponding repair packets.
Assuming that there is no issue of delay variation, the FEC decoder Assuming that there is no issue of delay variation, the FEC decoder
skipping to change at page 13, line 19 skipping to change at page 13, line 23
request with an offer without FEC. request with an offer without FEC.
5.3. Examples 5.3. Examples
Editor's note: More examples showing the usage of multiple FEC Editor's note: More examples showing the usage of multiple FEC
Framework instances, additivity of the repair flows and Framework instances, additivity of the repair flows and
prioritization of the repair flows will be provided once the issues prioritization of the repair flows will be provided once the issues
related to FEC grouping and flow association are resolved. related to FEC grouping and flow association are resolved.
Editor's note: As of now, no FEC Encoding ID has been registered Editor's note: As of now, no FEC Encoding ID has been registered
with IANA. In the examples below, an FEC Encoding ID of zero and an with IANA. In the examples below, an FEC Encoding ID of zero will be
encoding (i.e., payload format) of 'parityfec' will be used for used for illustrative purposes. Artificial content for the SS-FSSI
illustrative purposes. Artificial content for the SS-FSSI and RS- and FSSI will also be provided.
FSSI will also be provided.
[RFC3388] defines the media stream identification attribute ('mid') [RFC3388] defines the media stream identification attribute ('mid')
as a token in ABNF. In contrast, the identifiers for the source as a token in ABNF. In contrast, the identifiers for the source
flows MUST be integers and SHOULD be allocated starting from zero and flows MUST be integers and SHOULD be allocated starting from zero and
increasing by one for each flow. To avoid any ambiguity, using the increasing by one for each flow. To avoid any ambiguity, using the
same values for identifying the media streams and source flows is NOT same values for identifying the media streams and source flows is NOT
RECOMMENDED, even when 'mid' values are integers. RECOMMENDED, even when 'mid' values are integers.
5.3.1. One Source Flow, One Repair Flow and One FEC Scheme 5.3.1. One Source Flow, One Repair Flow and One FEC Scheme
skipping to change at page 14, line 6 skipping to change at page 14, line 6
0: Source Flow |---------| 1: Repair Flow 0: Source Flow |---------| 1: Repair Flow
Figure 6: Scenario #1 Figure 6: 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 S1 repair flow (mid:R1). We form one FEC group with the "a=group:FEC S1
R1" line. The source and repair flows are sent to the same port on 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. different multicast groups. The repair window is set to 150 ms.
v=0 v=0
o=ali 1122334455 1122334466 IN IP4 fec.rocks.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 S1 R1 a=group:FEC S1 R1
m=video 30000 RTP/AVP 100 m=video 30000 RTP/AVP 100
c=IN IP4 224.1.1.1/127 c=IN IP4 224.1.1.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 RTP/AVP 110 m=application 30000 udp/fec
c=IN IP4 224.1.2.1/127 c=IN IP4 224.1.2.1/127
a=rtpmap:110 1d-interleaved-parityfec/90000 a=fec-repair-flow: encoding-id=0; ss-fssi=1Q2A3Z; fssi=4W5S6X
a=fec-repair-flow: encoding-id=0; ss-fssi=1Q2A3Z; rs-fssi=4W5S6X
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 5.3.2. Two Source Flows, One Repair Flow and One FEC Scheme
SOURCE FLOWS | INSTANCE #1 SOURCE FLOWS | INSTANCE #1
0: Source Flow |_________| 2: Repair Flow 0: Source Flow |_________| 2: Repair Flow
1: Source Flow | 1: Source Flow |
Figure 8: Scenario #2 Figure 8: 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:S1 and mid:S2)
and one FEC repair flow (mid:R1), protecting both source flows. We and one FEC repair flow (mid:R1), protecting both source flows. We
form one FEC group with the "a=group:FEC S1 S2 R1" line. The source form one FEC group with the "a=group:FEC S1 S2 R1" line. The source
and repair flows are sent to the same port on different multicast and repair flows are sent to the same port on different multicast
groups. The repair window is set to 150500 us. groups. The repair window is set to 150500 us.
v=0 v=0
o=ali 1122334455 1122334466 IN IP4 fec.rocks.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 S1 S2 R1 a=group:FEC S1 S2 R1
m=video 30000 RTP/AVP 100 m=video 30000 RTP/AVP 100
c=IN IP4 224.1.1.1/127 c=IN IP4 224.1.1.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=video 30000 RTP/AVP 101 m=video 30000 RTP/AVP 101
c=IN IP4 224.1.1.2/127 c=IN IP4 224.1.1.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:S2
m=application 30000 RTP/AVP 110 m=application 30000 udp/fec
c=IN IP4 224.1.2.1/127 c=IN IP4 224.1.2.1/127
a=rtpmap:110 1d-interleaved-parityfec/90000 a=fec-repair-flow: encoding-id=0; ss-fssi=1Q2A3Z; fssi=4W5S6X
a=fec-repair-flow: encoding-id=0; ss-fssi=1Q2A3Z; rs-fssi=4W5S6X
a=repair-window: 150500 us a=repair-window: 150500 us
a=mid:R1 a=mid:R1
5.3.3. Two Source Flows, Two Repair Flows and Two FEC Schemes 5.3.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 0: Source Flow |---------| 2: Repair Flow
1: Source Flow |_ 1: Source Flow |_
\-------| INSTANCE #2 \-------| INSTANCE #2
| 3: Repair Flow | 3: Repair Flow
skipping to change at page 16, line 6 skipping to change at page 16, line 6
In this example, we have two source video flows (mid:S1 and mid:S2) In this example, we have two source video flows (mid:S1 and mid:S2)
and two FEC repair flows (mid:R1 and mid:R2). The source flows and two FEC repair flows (mid:R1 and mid:R2). The source flows
mid:S1 and mid:S2 are protected by the repair flows mid:R1 and mid:S1 and mid:S2 are protected by the repair flows mid:R1 and
mid:R2, respectively. We form two FEC groups with the "a=group:FEC mid:R2, respectively. We form two FEC groups with the "a=group:FEC
S1 R1" and "a=group:FEC S2 R2" lines. The source and repair flows S1 R1" and "a=group:FEC S2 R2" lines. The source and repair flows
are sent to the same port on different multicast groups. The repair 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 window is set to 200 ms and 400 ms for the first and second FEC
group, respectively. group, respectively.
v=0 v=0
o=ali 1122334455 1122334466 IN IP4 fec.rocks.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 S1 R1 a=group:FEC S1 R1
a=group:FEC S2 R2 a=group:FEC S2 R2
m=video 30000 RTP/AVP 100 m=video 30000 RTP/AVP 100
c=IN IP4 224.1.1.1/127 c=IN IP4 224.1.1.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=video 30000 RTP/AVP 101 m=video 30000 RTP/AVP 101
c=IN IP4 224.1.1.2/127 c=IN IP4 224.1.1.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:S2
m=application 30000 RTP/AVP 110 m=application 30000 udp/fec
c=IN IP4 224.1.2.1/127 c=IN IP4 224.1.2.1/127
a=rtpmap:110 1d-interleaved-parityfec/90000 a=fec-repair-flow: encoding-id=0; ss-fssi=1Q2A3Z; fssi=4W5S6X
a=fec-repair-flow: encoding-id=0; ss-fssi=1Q2A3Z; rs-fssi=4W5S6X
a=repair-window: 200 ms a=repair-window: 200 ms
a=mid:R1 a=mid:R1
m=application 30000 RTP/AVP 111 m=application 30000 udp/fec
c=IN IP4 224.1.2.2/127 c=IN IP4 224.1.2.2/127
a=rtpmap:111 1d-interleaved-parityfec/90000 a=fec-repair-flow: encoding-id=0; ss-fssi=123QAZ; fssi=456WSX
a=fec-repair-flow: encoding-id=0; ss-fssi=123QAZ; rs-fssi=456WSX
a=repair-window: 400 ms a=repair-window: 400 ms
a=mid:R2 a=mid:R2
6. Security Considerations 6. Security Considerations
For the general security considerations related to SDP, refer to For the general security considerations related to SDP, refer to
[RFC4566]. For the security considerations related to source/FEC [RFC4566]. For the security considerations related to source/FEC
media stream grouping in SDP and use of source address filters in media stream grouping in SDP and use of source address filters in
SDP, refer to [RFC4756] and [RFC4570], respectively. SDP, refer to [RFC4756] and [RFC4570], respectively.
skipping to change at page 18, line 12 skipping to change at page 18, line 12
Reference: This document Reference: This document
Values: See this document Values: See this document
8. Acknowledgments 8. 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. Change Log
9.1. draft-ietf-fecframe-sdp-elements-01 9.1. 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.2. draft-ietf-fecframe-sdp-elements-01
The following are the major changes compared to version 00: The following are the major changes compared to version 00:
o Additive repair flows can now be from different instances. The o Additive repair flows can now be from different instances. The
sender may also assign different levels of priorities to each sender may also assign different levels of priorities to each
repair flow regardless of whether the repair flows are additive or repair flow regardless of whether the repair flows are additive or
not. not.
o SDP examples are fixed. o SDP examples are fixed.
o Comments posted in the mailing list are incorporated. o Comments posted in the mailing list are incorporated.
9.2. draft-ietf-fecframe-sdp-elements-00 9.3. draft-ietf-fecframe-sdp-elements-00
This is the initial version, which is based on an earlier individual This is the initial version, which is based on an earlier individual
submission. The following are the major changes compared to that submission. The following are the major changes compared to that
document: document:
o The opaque container in the FEC Framework Configuration o The opaque container in the FEC Framework Configuration
Information (FEC-Scheme-Specific Information) is now divided into Information (FEC-Scheme-Specific Information) is now divided into
two parts: information needed only by the sender and information two parts: information needed only by the sender and information
needed by the receiver. The repair flow descriptors are also needed by the receiver. The repair flow descriptors are also
updated accordingly. updated accordingly.
skipping to change at page 19, line 9 skipping to change at page 19, line 13
framework draft. framework draft.
o Some other editorial changes. 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-02 (work in progress), draft-ietf-fecframe-framework-03 (work in progress),
July 2008. October 2008.
[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.
skipping to change at page 19, line 39 skipping to change at page 19, line 43
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.
[I-D.ietf-fecframe-config-signaling]
Asati, R., "Signaling Protocol to convey FEC Framework
Configuration Information",
draft-ietf-fecframe-config-signaling-00 (work in
progress), July 2008.
[I-D.ietf-mmusic-sdp-capability-negotiation]
Andreasen, F., "SDP Capability Negotiation",
draft-ietf-mmusic-sdp-capability-negotiation-08 (work in
progress), December 2007.
10.2. Informative References 10.2. Informative References
[RFC5052] Watson, M., Luby, M., and L. Vicisano, "Forward Error [RFC5052] Watson, M., Luby, M., and L. Vicisano, "Forward Error
Correction (FEC) Building Block", RFC 5052, August 2007. Correction (FEC) Building Block", RFC 5052, August 2007.
[I-D.ietf-fecframe-config-signaling]
Asati, R., "Methods to convey FEC Framework Configuration
Information", draft-ietf-fecframe-config-signaling-01
(work in progress), November 2008.
[I-D.begen-mmusic-rfc4756bis]
Begen, A., "Forward Error Correction Grouping Semantics in
Session Description Protocol",
draft-begen-mmusic-rfc4756bis-00 (work in progress),
October 2008.
[I-D.ietf-mmusic-sdp-capability-negotiation]
Andreasen, F., "SDP Capability Negotiation",
draft-ietf-mmusic-sdp-capability-negotiation-09 (work in
progress), July 2008.
Author's Address Author's Address
Ali Begen Ali Begen
Cisco Systems Cisco Systems
170 West Tasman Drive 170 West Tasman Drive
San Jose, CA 95134 San Jose, CA 95134
USA USA
Email: abegen@cisco.com Email: abegen@cisco.com
 End of changes. 40 change blocks. 
105 lines changed or deleted 117 lines changed or added

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