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

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