draft-ietf-fecframe-sdp-elements-02.txt   draft-ietf-fecframe-sdp-elements-03.txt 
FEC Framework A. Begen FEC Framework A. Begen
Internet-Draft Cisco Systems Internet-Draft Cisco Systems
Intended status: Standards Track November 3, 2008 Intended status: Standards Track June 4, 2009
Expires: May 7, 2009 Expires: December 6, 2009
SDP Elements for FEC Framework SDP Elements for FEC Framework
draft-ietf-fecframe-sdp-elements-02 draft-ietf-fecframe-sdp-elements-03
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any This Internet-Draft is submitted to IETF in full conformance with the
applicable patent or other IPR claims of which he or she is aware provisions of BCP 78 and BCP 79. This document may contain material
have been or will be disclosed, and any of which he or she becomes from IETF Documents or IETF Contributions published or made publicly
aware will be disclosed, in accordance with Section 6 of BCP 79. available before November 10, 2008. The person(s) controlling the
copyright in some of this material may not have granted the IETF
Trust the right to allow modifications of such material outside the
IETF Standards Process. Without obtaining an adequate license from
the person(s) controlling the copyright in such materials, this
document may not be modified outside the IETF Standards Process, and
derivative works of it may not be created outside the IETF Standards
Process, except to format it for publication as an RFC or to
translate it into languages other than English.
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
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
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."
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 May 7, 2009. This Internet-Draft will expire on December 6, 2009.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2008). Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
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.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 3 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 4
3. Forward Error Correction (FEC) and FEC Framework . . . . . . . 3 3. Forward Error Correction (FEC) and FEC Framework . . . . . . . 4
3.1. Forward Error Correction (FEC) . . . . . . . . . . . . . . 3 3.1. Forward Error Correction (FEC) . . . . . . . . . . . . . . 4
3.2. FEC Framework . . . . . . . . . . . . . . . . . . . . . . 4 3.2. FEC Framework . . . . . . . . . . . . . . . . . . . . . . 5
3.3. FEC Framework Configuration Information . . . . . . . . . 5 3.3. FEC Framework Configuration Information . . . . . . . . . 6
4. SDP Descriptors for FEC Framework . . . . . . . . . . . . . . 6 4. SDP Descriptors for FEC Framework . . . . . . . . . . . . . . 7
4.1. Transport Protocol Identifiers . . . . . . . . . . . . . . 6 4.1. Transport Protocol Identifiers . . . . . . . . . . . . . . 8
4.2. Media Stream Grouping . . . . . . . . . . . . . . . . . . 7 4.2. Media Stream Grouping . . . . . . . . . . . . . . . . . . 8
4.3. Source IP Addresses . . . . . . . . . . . . . . . . . . . 9 4.3. Source IP Addresses . . . . . . . . . . . . . . . . . . . 10
4.4. Source Flows . . . . . . . . . . . . . . . . . . . . . . . 9 4.4. Source Flows . . . . . . . . . . . . . . . . . . . . . . . 10
4.5. Repair Flows . . . . . . . . . . . . . . . . . . . . . . . 9 4.5. Repair Flows . . . . . . . . . . . . . . . . . . . . . . . 10
4.6. Repair Window . . . . . . . . . . . . . . . . . . . . . . 11 4.6. Repair Window . . . . . . . . . . . . . . . . . . . . . . 11
4.7. Bandwidth Specification . . . . . . . . . . . . . . . . . 11 4.7. Bandwidth Specification . . . . . . . . . . . . . . . . . 12
5. Scenarios and Examples . . . . . . . . . . . . . . . . . . . . 12 5. Scenarios and Examples . . . . . . . . . . . . . . . . . . . . 13
5.1. Session Announcement Considerations . . . . . . . . . . . 12 5.1. Declarative Considerations . . . . . . . . . . . . . . . . 13
5.2. Offer/Answer Considerations . . . . . . . . . . . . . . . 12 5.2. Offer/Answer Model Considerations . . . . . . . . . . . . 13
5.3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 13 5.3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 14
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 . 14
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 . . . . . . . . . . . . . . . . . . . . . . . . 15
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 . . . . . . . . . . . . . . . . . . . . . . . 16
6. Security Considerations . . . . . . . . . . . . . . . . . . . 16 6. Security Considerations . . . . . . . . . . . . . . . . . . . 17
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
7.1. Transport Protocols . . . . . . . . . . . . . . . . . . . 16 7.1. Transport Protocols . . . . . . . . . . . . . . . . . . . 17
7.2. Attribute Names . . . . . . . . . . . . . . . . . . . . . 17 7.2. Attribute Names . . . . . . . . . . . . . . . . . . . . . 18
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19
9. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 18 9. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 19
9.1. draft-ietf-fecframe-sdp-elements-02 . . . . . . . . . . . 18 9.1. draft-ietf-fecframe-sdp-elements-03 . . . . . . . . . . . 19
9.2. draft-ietf-fecframe-sdp-elements-01 . . . . . . . . . . . 18 9.2. draft-ietf-fecframe-sdp-elements-02 . . . . . . . . . . . 19
9.3. draft-ietf-fecframe-sdp-elements-00 . . . . . . . . . . . 18 9.3. draft-ietf-fecframe-sdp-elements-01 . . . . . . . . . . . 19
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 9.4. draft-ietf-fecframe-sdp-elements-00 . . . . . . . . . . . 19
10.1. Normative References . . . . . . . . . . . . . . . . . . . 19 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
10.2. Informative References . . . . . . . . . . . . . . . . . . 19 10.1. Normative References . . . . . . . . . . . . . . . . . . . 20
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 20 10.2. Informative References . . . . . . . . . . . . . . . . . . 21
Intellectual Property and Copyright Statements . . . . . . . . . . 21 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 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
Framework, a set of parameters pertaining to the FEC Framework MUST Framework, a set of parameters pertaining to the FEC Framework MUST
be initially communicated between the sender(s) and receiver(s). A be initially communicated between the sender(s) and receiver(s). A
skipping to change at page 3, line 25 skipping to change at page 4, line 25
[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 must 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 may 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 MUST be 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
skipping to change at page 4, line 39 skipping to change at page 5, line 39
For a proper operation, the information required by the FEC Framework For a proper operation, the information required by the FEC Framework
and the details of an FEC scheme have to be communicated between the 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 sender and receiver(s). One way to provide this information is to
use the Session Description Protocol (SDP) [RFC4566]. SDP provides a use the Session Description Protocol (SDP) [RFC4566]. SDP provides a
commonly used text-based format for announcements and invitations commonly used text-based format for announcements and invitations
that describe multimedia sessions. These SDP announcements and that describe multimedia sessions. These SDP announcements and
invitations include sufficient information for clients to participate invitations include sufficient information for clients to participate
in multimedia sessions. By using the SDP capability negotiation in multimedia sessions. By using the SDP capability negotiation
framework, all or a subset of the parameters pertaining to the FEC framework, all or a subset of the parameters pertaining to the FEC
Framework MAY also be negotiated between the sender and receiver(s). Framework may also be negotiated between the sender and receiver(s).
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 MUST be used by the CDPs using the FEC Framework that choose SDP
[RFC4566] as their session description protocol. [RFC4566] as their session description protocol.
Note that there are many similarities between the FEC Framework Note that there are many similarities between the FEC Framework
[I-D.ietf-fecframe-framework] and the FEC Building Block [RFC5052], [I-D.ietf-fecframe-framework] and the FEC Building Block [RFC5052],
which describes a framework that uses FEC codes to provide which describes a framework that uses FEC codes to provide
reliability to bulk data transfer applications running over IP reliability to bulk data transfer applications running over IP
multicast or broadcast. See [I-D.ietf-fecframe-framework] for multicast or broadcast. See [I-D.ietf-fecframe-framework] for
skipping to change at page 6, line 40 skipping to change at page 7, line 40
The variable-length opaque SS-FSSI and FSSI containers transmit the The variable-length opaque SS-FSSI and FSSI containers transmit the
information in the form of an octet string. The FEC schemes define information in the form of an octet string. The FEC schemes 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.
Editor's note: Should we mandate base64 encoding for these fields in
SDP?
Editor's note: When RTP transport is used for the source and/or
repair flows, the information included in the FSSI/SS-FSSI containers
will be carried via the format-specific parameters ("a=fmtp" line).
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
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 configurations can be found in Section 5.
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
skipping to change at page 8, line 9 skipping to change at page 9, line 16
receivers choose receiving the appropriate repair flow(s) that they receivers choose receiving the appropriate repair flow(s) that they
can support and decode. Alternatively, different instances (whether can support and decode. Alternatively, different instances (whether
they use the same FEC scheme or not) may use larger and smaller they use the same FEC scheme or not) may use larger and smaller
source block sizes, which accommodate the receivers that have looser source block sizes, which accommodate the receivers that have looser
and tighter latency requirements, respectively. In addition, and tighter latency requirements, respectively. In addition,
different instances may also provide FEC protection at different different instances may also provide FEC protection at different
redundancy levels. This is particularly useful in multicast redundancy levels. This is particularly useful in multicast
scenarios where different receivers might experience different packet scenarios where different receivers might experience different packet
loss rates and each receiver can choose the repair flow that is loss rates and each receiver can choose the repair flow that is
tailored to its needs. tailored to its needs.
____| FEC FRAMEWORK
/ | INSTANCE | FEC FRAMEWORK
/ | 3: Repair Flow +--------| INSTANCE
/ | | 3: Repair Flow
SOURCE FLOWS / | FEC FRAMEWORK |
0: Source Flow |___/ |------| INSTANCE SOURCE FLOWS | | FEC FRAMEWORK
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
| 5: Repair Flow | 5: Repair Flow
| 6: Repair Flow | 6: Repair Flow
| 7: Repair Flow | 7: Repair Flow
Figure 1: Example scenario with multiple FEC Framework instances Figure 1: Example scenario with multiple FEC Framework instances
The 'group' attribute and the FEC grouping semantics defined in The 'group' attribute and the FEC grouping semantics defined in
[RFC4756] are used to associate source and repair flows together with [I-D.ietf-mmusic-rfc3388bis] and [I-D.ietf-mmusic-rfc4756bis],
the following additional requirement: 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 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 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 generic tag is used by all of the FEC schemes for the Source FEC
Payload ID, as defined in [I-D.ietf-fecframe-framework]. Payload ID, as defined in [I-D.ietf-fecframe-framework].
The 'group' attribute MAY be used to group multiple repair flows with
one or more source flows. Note that [RFC3388] prohibits an "m" line
identified by its 'mid' attribute from appearing in more than one
"a=group:FEC" line. Thus, [RFC3388] mandates us to write
a=group:FEC 0 1 2 3 4 5 6 7
for the scenario sketched in Figure 1. This limitation prevents us
from indicating particular associations between the source and repair
flows by using an "a=group:FEC" line per FEC Framework instance
[RFC4756].
Editor's note: The FEC grouping and flow association issues are
currently under discussion in FECFRAME and MMUSIC WGs (See
[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.
MAY assign different levels of priority to each repair flow. See [I-D.ietf-mmusic-rfc4756bis] explains how the additive repair flows
Section 4.5 for details. 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.
Editor's note: Additional requirements or exceptions regarding
source filters are TBD.
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
and protected together by a single or multiple FEC Framework and protected together by a single or multiple FEC Framework
instances. For this reason, as described in Section 3.3, individual instances. For this reason, as described in Section 3.3, individual
source flows MUST be identified with unique identifiers. For this source flows MUST be identified with unique identifiers. For this
purpose, we introduce the attribute 'fec-source-flow'. purpose, we introduce the attribute 'fec-source-flow'.
The syntax for the new attribute in ABNF [RFC5234] is as follows: The syntax for the new attribute in ABNF [RFC5234] is as follows:
skipping to change at page 10, line 9 skipping to change at page 11, line 6
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 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-preference]
[";" 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-priority = "priority=" priority-of-the-flow flow-preference = "preference-lvl=" preference-level-of-the-flow
priority-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 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 'preference-lvl' is used to indicate the
of the repair flows. The exact usage of the parameter 'priority' and preferred order of using the repair flows. The exact usage of the
the pertaining rules MAY be defined by the FEC scheme or the CDP. If parameter 'preference-lvl' and the pertaining rules MAY be defined by
no value is specified for the parameter 'priority', it means that the the FEC scheme or the CDP. If no value is specified for the
receiver(s) MAY receive and use the repair flows in any order. parameter 'preference-lvl', it means that the receiver(s) MAY receive
However, if a priority is assigned to the repair flow(s), the and use the repair flows in any order. However, if a preference
receivers MUST follow the specified order in receiving and using the level is assigned to the repair flow(s), the receivers are encouraged
repair flow(s). to follow the specified order in receiving and using the repair
flow(s).
The OPTIONAL parameters 'ss-fssi' and 'fssi' are opaque containers to The OPTIONAL parameters 'ss-fssi' and 'fssi' are opaque containers to
convey the FEC-Scheme-Specific Information (FSSI) that includes the convey the FEC-Scheme-Specific Information (FSSI) that includes the
information that is specific to the FEC scheme used by the CDP and is information that is specific to the FEC scheme used by the CDP and is
necessary for proper FEC encoding and decoding operations. The FSSI necessary for proper FEC encoding and decoding operations. The FSSI
required only by the sender (called Sender-Side FSSI) MUST be required only by the sender (called Sender-Side FSSI) MUST be
communicated in the container specified by the parameter 'ss-fssi'. communicated in the container specified by the parameter 'ss-fssi'.
Any other FSSI MUST be communicated in the container specified by the Any other FSSI MUST be communicated in the container specified by the
parameter 'fssi'. In both containers, FSSI is transmitted in the parameter 'fssi'. In both containers, FSSI is transmitted in the
form of an octet string. The FEC schemes define the structure of form of an octet string. The FEC schemes define the structure of
skipping to change at page 11, line 36 skipping to change at page 12, line 31
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 Currently, two units are defined: "ms", which stands for
milliseconds and "us", which stands for microseconds. The default milliseconds and "us", which stands for microseconds. The default
unit is "ms". Alternative units MAY be defined in the future by unit is "ms". Alternative units MAY be defined in the future by
registering them with IANA. 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 value. repair flow MAY have a different repair window size.
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
skipping to change at page 12, line 27 skipping to change at page 13, line 23
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. SDP examples that can be used by the FEC
Framework are also provided. Framework are also provided.
5.1. Session Announcement 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 group(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.
5.2. Offer/Answer 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 all available options
to the receiver and the receiver answers back to the sender with its to the receiver and the receiver answers back to the sender with its
choice(s). Note that some FEC protection options MAY be offered to choice(s). Note that some FEC protection options MAY be offered to
only a particular set of (e.g., premium) receivers. 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 [RFC3388]. If a receiver receives an offer containing specified in [I-D.ietf-mmusic-rfc4756bis].
FEC grouping and it does not understand the FEC grouping semantics,
it MAY respond with an answer that ignores the grouping attribute or
MAY refuse the request. In the first case, the offerer MUST
establish the connection without FEC. In the second case, if the
offerer still wishes to establish the session, it SHOULD retry the
request with an offer without FEC.
5.3. Examples 5.3. Examples
Editor's note: More examples showing the usage of multiple FEC
Framework instances, additivity of the repair flows and
prioritization of the repair flows will be provided once the issues
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 will be with IANA. In the examples below, an FEC Encoding ID of zero will be
used for illustrative purposes. Artificial content for the SS-FSSI used for illustrative purposes. Artificial content for the SS-FSSI
and FSSI will also be provided. and FSSI will also be provided.
[RFC3388] defines the media stream identification attribute ('mid') [I-D.ietf-mmusic-rfc3388bis] defines the media stream identification
as a token in ABNF. In contrast, the identifiers for the source attribute ('mid') as a token in ABNF. In contrast, the identifiers
flows MUST be integers and SHOULD be allocated starting from zero and for the source flows MUST be integers and SHOULD be allocated
increasing by one for each flow. To avoid any ambiguity, using the starting from zero and increasing by one for each flow. To avoid any
same values for identifying the media streams and source flows is NOT ambiguity, using the same values for identifying the media streams
RECOMMENDED, even when 'mid' values are integers. and source flows is NOT 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
SOURCE FLOWS | INSTANCE #1 SOURCE FLOWS | INSTANCE #1
0: Source Flow |---------| 1: Repair Flow 0: Source Flow |---------| 1: Repair Flow
|
Figure 6: Scenario #1 Figure 2: 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-XR
R1" line. The source and repair flows are sent to the same port on S1 R1" line. The source and repair flows are sent to the same port
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 S1 R1 a=group:FEC-XR 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 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 224.1.2.1/127 c=IN IP4 233.252.0.2/127
a=fec-repair-flow: encoding-id=0; ss-fssi=1Q2A3Z; fssi=4W5S6X a=fec-repair-flow: encoding-id=0; ss-fssi=1Q2A3Z; 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
0: Source Flow |_________| 2: Repair Flow 0: Source Flow | | INSTANCE #1
|---------| 2: Repair Flow
1: Source Flow | 1: Source Flow |
Figure 8: Scenario #2 Figure 3: 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-XR S1 S2 R1" line. The
and repair flows are sent to the same port on different multicast source and repair flows are sent to the same port on different
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 S1 S2 R1 a=group:FEC-XR 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 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=video 30000 RTP/AVP 101 m=video 30000 RTP/AVP 101
c=IN IP4 224.1.1.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:S2
m=application 30000 udp/fec m=application 30000 udp/fec
c=IN IP4 224.1.2.1/127 c=IN IP4 233.252.0.3/127
a=fec-repair-flow: encoding-id=0; ss-fssi=1Q2A3Z; fssi=4W5S6X a=fec-repair-flow: encoding-id=0; ss-fssi=1Q2A3Z; 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 |_
\-------| INSTANCE #2 1: Source Flow |---------| INSTANCE #2
| 3: Repair Flow | 3: Repair Flow
Figure 10: Scenario #3 Figure 4: 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: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:
S1 R1" and "a=group:FEC S2 R2" lines. The source and repair flows FEC-XR S1 R1" and "a=group:FEC-XR S2 R2" lines. The source and
are sent to the same port on different multicast groups. The repair repair flows are sent to the same port on different multicast groups.
window is set to 200 ms and 400 ms for the first and second FEC The repair window is set to 200 ms and 400 ms for the first and
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 S1 R1 a=group:FEC-XR S1 R1
a=group:FEC S2 R2 a=group:FEC-XR 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 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=video 30000 RTP/AVP 101 m=video 30000 RTP/AVP 101
c=IN IP4 224.1.1.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:S2
m=application 30000 udp/fec m=application 30000 udp/fec
c=IN IP4 224.1.2.1/127 c=IN IP4 233.252.0.3/127
a=fec-repair-flow: encoding-id=0; ss-fssi=1Q2A3Z; fssi=4W5S6X a=fec-repair-flow: encoding-id=0; ss-fssi=1Q2A3Z; fssi=4W5S6X
a=repair-window: 200 ms a=repair-window: 200 ms
a=mid:R1 a=mid:R1
m=application 30000 udp/fec m=application 30000 udp/fec
c=IN IP4 224.1.2.2/127 c=IN IP4 233.252.0.4/127
a=fec-repair-flow: encoding-id=0; ss-fssi=123QAZ; fssi=456WSX a=fec-repair-flow: encoding-id=0; ss-fssi=123QAZ; 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 There is a weak threat if the SDP is modified in a way that it shows
[RFC4566]. For the security considerations related to source/FEC incorrect association and/or grouping of the source and repair flows.
media stream grouping in SDP and use of source address filters in Such attacks may result in failure of FEC protection and/or
SDP, refer to [RFC4756] and [RFC4570], respectively. mishandling of other media streams. It is RECOMMENDED that the
receiver SHOULD do integrity check on SDP and follow the security
considerations of SDP [RFC4566] to only trust SDP from trusted
sources. For other general security considerations related to SDP,
refer to [RFC4566]. For the security considerations related to the
use of source address filters in SDP, refer to [RFC4570].
7. IANA Considerations 7. IANA Considerations
7.1. Transport Protocols 7.1. Transport Protocols
The 'proto' sub-field of the media description line ("m=") describes The 'proto' sub-field of the media description line ("m=") describes
the transport protocol used. This document registers the following the transport protocol used. This document registers the following
values: values:
UDP/FEC UDP/FEC
skipping to change at page 18, line 12 skipping to change at page 19, 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-02 9.1. 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.2. draft-ietf-fecframe-sdp-elements-02
The following are the major changes compared to version 01: The following are the major changes compared to version 01:
o Clarified the definitions for the FSSI fields. o Clarified the definitions for the FSSI fields.
o Hostnames in the SDP examples are fixed. o Hostnames in the SDP examples are fixed.
9.2. draft-ietf-fecframe-sdp-elements-01 9.3. 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.3. draft-ietf-fecframe-sdp-elements-00 9.4. 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 25 skipping to change at page 20, line 39
[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.
[RFC4756] Li, A., "Forward Error Correction Grouping Semantics in [I-D.ietf-mmusic-rfc3388bis]
Session Description Protocol", RFC 4756, November 2006. Camarillo, G., "The SDP (Session Description Protocol)
Grouping Framework", draft-ietf-mmusic-rfc3388bis-02 (work
in progress), January 2009.
[RFC3388] Camarillo, G., Eriksson, G., Holler, J., and H. [I-D.ietf-mmusic-rfc4756bis]
Schulzrinne, "Grouping of Media Lines in the Session Begen, A., "Forward Error Correction Grouping Semantics in
Description Protocol (SDP)", RFC 3388, December 2002. Session Description Protocol",
draft-ietf-mmusic-rfc4756bis-02 (work in progress),
April 2009.
[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,
skipping to change at page 20, line 5 skipping to change at page 21, line 23
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] [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-01 Information", draft-ietf-fecframe-config-signaling-01
(work in progress), November 2008. (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] [I-D.ietf-mmusic-sdp-capability-negotiation]
Andreasen, F., "SDP Capability Negotiation", Andreasen, F., "SDP Capability Negotiation",
draft-ietf-mmusic-sdp-capability-negotiation-09 (work in draft-ietf-mmusic-sdp-capability-negotiation-10 (work in
progress), July 2008. progress), May 2009.
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
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
 End of changes. 57 change blocks. 
160 lines changed or deleted 172 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/