draft-ietf-fecframe-framework-11.txt   draft-ietf-fecframe-framework-12.txt 
FEC Framework M. Watson FEC Framework M. Watson
Internet-Draft Netflix, Inc. Internet-Draft Netflix, Inc.
Intended status: Standards Track A. Begen Intended status: Standards Track A. Begen
Expires: May 24, 2011 Cisco Expires: July 22, 2011 Cisco
November 20, 2010 V. Roca
INRIA
January 18, 2011
Forward Error Correction (FEC) Framework Forward Error Correction (FEC) Framework
draft-ietf-fecframe-framework-11 draft-ietf-fecframe-framework-12
Abstract Abstract
This document describes a framework for using Forward Error This document describes a framework for using Forward Error
Correction (FEC) codes with applications in public and private IP Correction (FEC) codes with applications in public and private IP
networks to provide protection against packet loss. The framework networks to provide protection against packet loss. The framework
supports applying FEC to arbitrary packet flows over unreliable supports applying FEC to arbitrary packet flows over unreliable
transport and is primarily intended for real-time, or streaming, transport and is primarily intended for real-time, or streaming,
media. This framework can be used to define Content Delivery media. This framework can be used to define Content Delivery
Protocols that provide FEC for streaming media delivery or other Protocols that provide FEC for streaming media delivery or other
skipping to change at page 1, line 43 skipping to change at page 1, line 45
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on May 24, 2011. This Internet-Draft will expire on July 22, 2011.
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 3, line 29 skipping to change at page 3, line 29
5.4. Packet Format for FEC Repair Packets . . . . . . . . . . . 23 5.4. Packet Format for FEC Repair Packets . . . . . . . . . . . 23
5.4.1. Packet Format for FEC Repair Packets over RTP . . . . 23 5.4.1. Packet Format for FEC Repair Packets over RTP . . . . 23
5.5. FEC Framework Configuration Information . . . . . . . . . 24 5.5. FEC Framework Configuration Information . . . . . . . . . 24
5.6. FEC Scheme Requirements . . . . . . . . . . . . . . . . . 26 5.6. FEC Scheme Requirements . . . . . . . . . . . . . . . . . 26
6. Feedback . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 6. Feedback . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
7. Transport Protocols . . . . . . . . . . . . . . . . . . . . . 30 7. Transport Protocols . . . . . . . . . . . . . . . . . . . . . 30
8. Congestion Control . . . . . . . . . . . . . . . . . . . . . . 31 8. Congestion Control . . . . . . . . . . . . . . . . . . . . . . 31
8.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 31 8.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 31
8.2. Normative Requirements . . . . . . . . . . . . . . . . . . 32 8.2. Normative Requirements . . . . . . . . . . . . . . . . . . 32
9. Security Considerations . . . . . . . . . . . . . . . . . . . 33 9. Security Considerations . . . . . . . . . . . . . . . . . . . 33
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34 9.1. Problem Statement . . . . . . . . . . . . . . . . . . . . 33
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 35 9.2. Attacks Against the Data Flows . . . . . . . . . . . . . . 34
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 36 9.2.1. Access to Confidential Content . . . . . . . . . . . . 34
12.1. Normative references . . . . . . . . . . . . . . . . . . . 36 9.2.2. Content Corruption . . . . . . . . . . . . . . . . . . 35
12.2. Informative references . . . . . . . . . . . . . . . . . . 36 9.3. Attacks Against the FEC Parameters . . . . . . . . . . . . 36
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 38 9.4. When Several Source Flows are to be Protected Together . . 37
9.5. Baseline Secure FEC Framework Operation . . . . . . . . . 37
10. Operations and Management Considerations . . . . . . . . . . . 39
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 41
12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 42
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 43
13.1. Normative references . . . . . . . . . . . . . . . . . . . 43
13.2. Informative references . . . . . . . . . . . . . . . . . . 43
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 45
1. Introduction 1. Introduction
Many applications have a requirement to transport a continuous stream Many applications have a requirement to transport a continuous stream
of packetized data from a source (sender) to one or more destinations of packetized data from a source (sender) to one or more destinations
(receivers) over networks which do not provide guaranteed packet (receivers) over networks which do not provide guaranteed packet
delivery. Primary examples are real-time, or streaming, media delivery. Primary examples are real-time, or streaming, media
applications such as broadcast, multicast or on-demand audio, video applications such as broadcast, multicast or on-demand audio, video
or multimedia. or multimedia.
skipping to change at page 26, line 36 skipping to change at page 26, line 36
5.6. FEC Scheme Requirements 5.6. FEC Scheme Requirements
In order to be used with this framework, an FEC scheme MUST be In order to be used with this framework, an FEC scheme MUST be
capable of processing data arranged into blocks of ADUs (source capable of processing data arranged into blocks of ADUs (source
blocks). blocks).
A specification for a new FEC scheme MUST include the following: A specification for a new FEC scheme MUST include the following:
1. The FEC Encoding ID value that uniquely identifies the FEC 1. The FEC Encoding ID value that uniquely identifies the FEC
scheme. This value MUST be registered with IANA as described in scheme. This value MUST be registered with IANA as described in
Section 10. Section 11.
2. The type, semantics and encoding format of the Repair FEC Payload 2. The type, semantics and encoding format of the Repair FEC Payload
ID. ID.
3. The name, type, semantics and text value encoding rules for zero 3. The name, type, semantics and text value encoding rules for zero
or more FEC-Scheme-Specific Information elements. or more FEC-Scheme-Specific Information elements.
4. A full specification of the FEC code. 4. A full specification of the FEC code.
This specification MUST precisely define the valid FEC-Scheme- This specification MUST precisely define the valid FEC-Scheme-
skipping to change at page 33, line 7 skipping to change at page 33, line 7
military devices, which could warrant a higher FEC strength. military devices, which could warrant a higher FEC strength.
However, in this specification we give preference to the overall However, in this specification we give preference to the overall
stability and network friendliness of average applications. stability and network friendliness of average applications.
o Whenever the source data rate is adapted due to the operation of o Whenever the source data rate is adapted due to the operation of
congestion control mechanisms, the FEC repair data rate MUST be congestion control mechanisms, the FEC repair data rate MUST be
similarly adapted. similarly adapted.
9. Security Considerations 9. Security Considerations
The application of FEC protection to a stream does not provide any First of all, it must be clear that the application of FEC protection
kind of security protection. to a stream does not provide any kind of security. On the opposite,
the FEC Framework itself could be subject to attacks, or could pose
new security risks. The goals of this section are to state the
problem, discuss the risks and identify solutions when feasible. It
also defines a mandatory to implement (but not mandatory to use)
security scheme.
If security services are required for the stream, then they MUST 9.1. Problem Statement
either be applied to the original source data before FEC protection
is applied, or to both the source and repair data, after FEC
protection has been applied.
If integrity protection is applied to source packets before FEC A content delivery system is potentially subject to many attacks.
protection is applied, and no further integrity protection is applied Attacks can target the content, or the CDP, or the network itself,
to repair packets, then a denial-of-service attack is possible if an with completely different consequences, in particular in terms of the
attacker is in a position to inject fake repair transport payloads. number of impacted nodes.
If received by a receiver, such fake repair transport payloads could
cause incorrect FEC decoding resulting in incorrect ADUs being passed
up to the application protocol. A similar attack is possible if an
attacker is in a position to inject fake FEC Framework Configuration
Information or fake FEC Payload IDs. Such incorrect decoded ADUs
would then be detected by the source integrity protection and
discarded, resulting in partial or complete denial of service.
Therefore, in such environments, integrity protection MUST also be
applied to the FEC repair transport payloads, FEC Framework
Configuration Information and FEC Payload IDs, for example using
IPSec to integrity protect all packets. Receivers MUST also verify
the integrity of source symbols before including the source symbols
into the source block.
It is possible that multiple streams with different confidentiality Attacks can have several goals:
requirements (for example, the streams may be visible to different
sets of users) can be FEC protected by a single repair stream. This
scenario is not recommended, since resources will be used to
distribute and FEC decode encrypted data which cannot then be
decrypted by at least some receivers. However, in this scenario,
confidentiality protection MUST be applied before FEC encoding of the
streams, otherwise repair transport payload may be used by a receiver
to decode unencrypted versions of source streams which they do not
have permissions to access.
10. IANA Considerations o They can try to give access to a confidential content (e.g., in
case of a non-free content).
o They can try to corrupt the source flows (e.g., to prevent a
receiver from using them), which is a form of DoS attack.
o They can try to compromise the receiver's behavior (e.g., by
making the decoding of an object computationally expensive), which
is another form of DoS attack.
o They can try to compromise the network's behavior (e.g., by
causing congestion within the network), which potentially impacts
a large number of nodes.
These attacks can be launched either against the source and/or repair
flows (e.g., by sending fake FEC source and/or repair packets) or
against the FEC parameters that are sent either in-band (e.g., in the
Repair FEC Payload ID or in the Explicit Source FEC Payload ID) or
out-of-band (e.g., in the FEC Framework Configuration Information).
Several dimensions to the problem need to be considered. The first
one is the way the FEC Framework is used. The FEC Framework can be
used end-to-end, i.e., it can be included in the final end-device
where the upper application runs; or the FEC Framework can be used in
middleboxes, for instance, to globally protect several source flows
exchanged between two or more distant sites.
A second dimension is the threat model. When the FEC Framework
operates in the end-device, this device (e.g., a personal computer)
might be subject to attacks. Here, the attacker is either the end-
user (who might want to access confidential content) or somebody
else. In all cases the attacker has access to the end-device, but
not necessarily to the full control of the end-device (a secure
domain can exist). Similarly, when the FEC Framework operates in a
middlebox, this middlebox can be subject to attacks or the attacker
can gain access to it. The threats can also concern the end-to-end
transport (e.g., through Internet). Here, examples of threats
include the transmission of fake FEC source or repair packets, the
replay of valid packets, the drop, delay or misordering of packets,
and of course traffic eavesdropping.
The third dimension consists in the desired security services. Among
them, the content integrity and sender authentication services are
probably the most important features. We can also mention DoS
mitigation, anti-replay protection or content confidentiality.
Finally, the fourth dimension consists in the security tools
available. This is the case of the various Digital Rights Management
(DRM) systems, defined out of the context of the IETF and that can be
proprietary solutions. Otherwise SRTP and IPsec/ESP are two tools
that can turn out to be useful in the context of the FEC Framework.
Note that using SRTP requires that the application generates RTP
source flows and, when applied below the FEC Framework, that both the
FEC source and repair packets to be regular RTP packets. Therefore
SRTP is not considered as a universal solution applicable in all use
cases.
In the following sections, we further discuss security aspects
related to the use of the FEC Framework.
9.2. Attacks Against the Data Flows
9.2.1. Access to Confidential Content
Access control to the source flow being transmitted is typically
provided by means of encryption. This encryption can be done by the
content provider itself, or within the application (for instance by
using the Secure Real-time Transport Protocol (SRTP) [RFC3711]), or
at the network layer, on a per-packet basis when IPsec/ESP is used
[RFC4303]. If confidentiality is a concern, it is RECOMMENDED that
one of these solutions is used. Even if we mention these attacks
here, they are neither related to nor facilitated by the use of FEC.
Note that when encryption is applied, this encryption MUST either be
applied on the source data before the FEC protection, or if done
after the FEC protection, then both the FEC source packets and repair
packets MUST be encrypted (and an encryption at least as
cryptographically secure as the encryption applied on the FEC source
packets MUST be used for the FEC repair packets). Otherwise, if
encryption were to be performed only on the FEC source packets after
FEC encoding, a non-authorized receiver could be able to recover the
source data after decoding the FEC repair packets provided that a
sufficient number of such packets were available.
The following considerations apply when choosing where to apply
encryption (and more generally where to apply security services
beyond encryption). Once decryption has taken place, the source data
is in plaintext. The full path between the output of the deciphering
module and the final destination (e.g., the TV display in case of a
video) MUST be secured, in order to prevent any unauthorized access
to the source data.
When the FEC Framework endpoint is the end system (i.e., where the
upper application runs) and if the threat model includes the
possibility that an attacker has access to this end system, then the
end system architecture is very important. More precisely, in order
to prevent an attacker to get hold of the plaintext, all processings,
once deciphering has taken place, MUST occur in a protected
environment. If encryption is applied after FEC protection at the
sending side (i.e., below FEC Framework), it means that FEC decoding
MUST take place in the protected environment. With certain use
cases, this MAY be complicated or even impossible. In that case
applying encryption before FEC protection is preferred.
When the FEC Framework endpoint is a middlebox, the recovered source
flow, after FEC decoding, SHOULD NOT be sent in plaintext to the
final destination(s) if the threat model includes the possibility
that an attacker eavesdrops the traffic. In that case also it is
preferred to apply encryption before FEC protection.
In some cases, encryption could be applied both before and after the
FEC protection. The considerations described above still apply in
such cases.
9.2.2. Content Corruption
Protection against corruptions (e.g., against forged FEC source/
repair packets) is achieved by means of a content integrity
verification/source authentication scheme. This service is usually
provided at the packet level. In this case, after removing all the
forged packets, the source flow might sometimes be recovered.
Several techniques can provide this content integrity/source
authentication service:
o At the application layer, SRTP [RFC3711] provides several
solutions to check the integrity and authenticate the source of
RTP and RTCP messages, among other services. For instance,
associated to the Timed Efficient Stream Loss-Tolerant
Authentication (TESLA) [RFC4383], SRTP is an attractive solution
that is robust to losses, provides a true authentication/integrity
service, and does not create any prohibitive processing load or
transmission overhead. Yet, checking a packet requires a small
delay (a second or more) after its reception with TESLA. Whether
this extra delay, both in terms of startup delay at the client and
end-to-end delay, is appropriate or not depends on the target use
case. In some situations, this might degrade the user experience.
In other situations, this will not be an issue. Other building
blocks can be used within SRTP to provide content integrity/
authentication services.
o At the network layer, IPsec/ESP [RFC4303] offers (among other
services) an integrity verification mechanism that can be used to
provide authentication/content integrity services.
It is up to the developer and the person in charge of deployment, who
know the security requirements and features of the target application
area, to define which solution is the most appropriate. Nonetheless
it is RECOMMENDED that at least one of these techniques is used.
Note that when integrity protection is applied, it is RECOMMENDED
that it takes place on both FEC source and repair packets. The
motivation is to avoid corrupted packets to be considered during
decoding, which would often lead to a decoding failure or result in a
corrupted decoded source flow.
9.3. Attacks Against the FEC Parameters
Attacks on these FEC parameters can prevent the decoding of the
associated object. For instance, modifying the finite field size of
a Reed-Solomon FEC scheme (when applicable) will lead a receiver to
consider a different FEC code.
It is therefore RECOMMENDED that security measures are taken to
guarantee the FEC Framework Configuration Information integrity.
Since the FEC Framework does not define how the FEC Framework
Configuration Information is communicated from sender to receiver, we
cannot provide further recommendations on how to guarantee its
integrity. However, any complete CDP specification MUST give
recommendations on how to achieve it. When the FEC Framework
Configuration Information is sent out-of-band, e.g., in a session
description, it SHOULD be protected, for instance, by digitally
signing it.
Attacks are also possible against some FEC parameters included in the
Explicit Source FEC Payload ID and Repair FEC Payload ID. For
instance, modifying the Source Block Number of an FEC source or
repair packet will lead a receiver to assign this packet to a wrong
block.
It is therefore RECOMMENDED that security measures are taken to
guarantee the Explicit Source FEC Payload ID and Repair FEC Payload
ID integrity. To that purpose, one of the packet-level source
authentication/content integrity techniques of Section 9.2.2 can be
used.
9.4. When Several Source Flows are to be Protected Together
When several source flows, with different security requirements, need
to be FEC protected jointly, within a single FEC Framework instance,
then each flow MAY be processed appropriately, before the protection.
For instance, source Flows that require access control MAY be
encrypted before they are FEC protected.
There are also situations where the only insecure domain is the one
over which the FEC Framework operates. In that case, this situation
MAY be addressed at the network layer, using IPsec/ESP (see
Section 9.5), even if only a subset of the source flows have strict
security requirements.
Since the use of FEC Framework should not add any additional threat,
it is RECOMMENDED that the FEC Framework aggregate flow be in line
with the maximum security requirements of the individual source
flows. For instance, if denial-of-service (DoS) protection is
required, an integrity protection SHOULD be provided below the FEC
Framework, using for instance IPsec/ESP.
Generally speaking, whenever feasible, it is RECOMMENDED to avoid FEC
protecting flows with totally different security requirements.
Otherwise, an important processing would be added to protect the
source flows that do not need it.
9.5. Baseline Secure FEC Framework Operation
This section describes a baseline mode of secure FEC Framework
operation based on the application of the IPsec security protocol,
which is one possible solution to solve or mitigate the security
threats introduced by the use of the FEC Framework.
Two related documents are of interest. First, Section 5.1 of
[RFC5775] defines a baseline secure ALC operation for sender-to-group
transmissions, assuming the presence of a single sender and a source-
specific multicast (SSM) or SSM-like operation. The proposed
solution, based on IPsec/ESP, can be used to provide a baseline FEC
Framework secure operation, for the downstream source flow.
Second, Section 7.1 of [RFC5740] defines a baseline secure NORM
operation, for sender-to-group transmissions as well as unicast
feedbacks from receivers. Here, it is also assumed there is a single
sender. The proposed solution is also based on IPsec/ESP. However,
the difference with respect to the first document relies on the
management of IPsec Security Associations (SA) and corresponding
Security Policy Database (SPD) entries, since NORM requires a second
set of SA and SPD to be defined to protect unicast feedbacks from
receivers.
The FEC Framework has been defined in such a way to be independent
from the application that generates source flows. Some applications
might use purely unidirectional flows, while other applications might
also use unicast feedbacks from the receivers. For instance, this is
the case when considering RTP/RTCP based source flows. Depending on
the specific situation, it is RECOMMENDED that the baseline secure
FEC Framework operation inherits from [RFC5775] in case of purely
unidirectional sender-to-group flows, or [RFC5740] in case both
sender-to-group and unicast feedbacks flows are needed.
Note that the IPsec/ESP requirements profiles outlined in [RFC5775]
and [RFC5740] are commonly available on many potential hosts. They
can form the basis of a secure mode of operation. One potential
limitation, however, is the need for privileged user authorization.
However, automated key management implementations are typically
configured with the privileges necessary to affect system IPsec
configuration.
10. Operations and Management Considerations
The FEC Framework is concerned about the FEC encoding and decoding
operations, and the configuration information that is essential to
control the hosts running these operations. Defining tools for the
operation and management of these hosts is not within the scope of
this specification.
Some applications using the CDPs compatible with the FEC Framework
are one-way meaning that they do not have a way to gather any kind of
feedback from receivers (e.g., broadcast), while some of them may
collect detailed feedback (in case it is a one-to-one application) or
occasional feedback (in case it is a multicast (one-to-many)
application). All these applications have naturally different
management aspects. If any, they also have different requirements or
features for collecting feedback, processing it and acting on it.
The data structures for carrying the feedback also vary.
From an operational viewpoint, it is important to note that in one-
to-many applications, there could be some receivers that are not
capable of decoding the repair packets belonging to a particular FEC
scheme, or some receivers could be non-FEC-capable at all. Such
receivers can opt not to receive the repair packets that they will
not be able to decode in the first place or discard them
appropriately upon receiving them. However, if the source packets
have been modified during FEC encoding according to the rules
specified in Section 5.3, the receivers that are not FEC Framework
compatible will not even be able to use the source packets. When
using FEC Framework in such receiver populations, it is important to
keep the source packets unmodified or offer the unmodified source
packets through another distribution channel to non-compatible
receivers. For details, see Section 5.3.
It is not advisable for the FEC Framework to explicitly list what the
hosts (sender or receiver or even a middle-box) could do upon
observing something in particular or receiving a specific feedback.
The CDPs and the FEC schemes compatible with the FEC Framework SHOULD
make use of existing tools as much as possible and to the extent
possible. For example, for repair flows using RTP transport,
benefiting from all the features of RTCP mechanisms is strongly
RECOMMENDED since RTCP has already solved many of these issues in an
agnostic way of the data carried with RTP.
Overall, the CDPs and FEC schemes compatible with the FEC Framework
widely differ in their capabilities, application and deployment
scenarios such that a common operation and management tool that works
well for all of them does not exist. Thus, as a design choice, the
FEC Framework does not dictate the use of any particular technology
or protocol for transporting FEC data, managing the hosts, signaling
the configuration information or encoding the configuration
information. This provides flexibility and was one of the main goals
of the FEC Framework.
11. IANA Considerations
FEC schemes for use with this framework are identified in protocols FEC schemes for use with this framework are identified in protocols
using FEC Encoding IDs. Values of FEC Encoding IDs are subject to using FEC Encoding IDs. Values of FEC Encoding IDs are subject to
IANA registration. For this purposes, this document creates a new IANA registration. For this purposes, this document creates a new
registry called FEC Framework (FECFRAME) FEC Encoding IDs. registry called FEC Framework (FECFRAME) FEC Encoding IDs.
The values that can be assigned within the FEC Framework (FECFRAME) The values that can be assigned within the FEC Framework (FECFRAME)
FEC Encoding ID registry are numeric indexes in the range [0, 255], FEC Encoding ID registry are numeric indexes in the range (0, 255).
boundaries included. Assignment requests are granted on an IETF Values of 0 and 255 are reserved. Assignment requests are granted on
Consensus basis as defined in [RFC5226]. Section 5.6 defines an IETF Consensus basis as defined in [RFC5226]. Section 5.6 defines
explicit requirements that documents defining new FEC Encoding IDs explicit requirements that documents defining new FEC Encoding IDs
should meet. should meet.
11. Acknowledgments 12. Acknowledgments
This document is based in part on [I-D.watson-tsvwg-fec-sf] and so This document is based in part on [I-D.watson-tsvwg-fec-sf] and so
thanks are due to the additional authors of that document, Mike Luby, thanks are due to the additional authors of that document, Mike Luby,
Magnus Westerlund and Stephan Wenger. That document was in turn Magnus Westerlund and Stephan Wenger. That document was in turn
based on the FEC Streaming Protocol defined by 3GPP in [MBMSTS], and based on the FEC Streaming Protocol defined by 3GPP in [MBMSTS], and
thus, thanks are also due to the participants in 3GPP TSG SA Working thus, thanks are also due to the participants in 3GPP SA Working
Group 4. Further thanks are due to the members of the FECFRAME Group 4. Further thanks are due to the members of the FECFRAME
Working Group for their comments and review. Working Group for their comments and reviews.
12. References 13. References
12.1. Normative references 13.1. Normative references
[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.
[RFC3095] Bormann, C., Burmeister, C., Degermark, M., Fukushima, H., [RFC3095] Bormann, C., Burmeister, C., Degermark, M., Fukushima, H.,
Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T., Le, Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T., Le,
K., Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K., K., Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K.,
Wiebke, T., Yoshimura, T., and H. Zheng, "RObust Header Wiebke, T., Yoshimura, T., and H. Zheng, "RObust Header
Compression (ROHC): Framework and four profiles: RTP, UDP, Compression (ROHC): Framework and four profiles: RTP, UDP,
ESP, and uncompressed", RFC 3095, July 2001. ESP, and uncompressed", RFC 3095, July 2001.
skipping to change at page 36, line 33 skipping to change at page 43, line 33
Jacobson, "RTP: A Transport Protocol for Real-Time Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, July 2003. Applications", STD 64, RFC 3550, July 2003.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226, IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008. May 2008.
[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.
12.2. Informative references 13.2. Informative references
[I-D.watson-tsvwg-fec-sf] [I-D.watson-tsvwg-fec-sf]
Watson, M., "Forward Error Correction (FEC) Streaming Watson, M., "Forward Error Correction (FEC) Streaming
Framework", draft-watson-tsvwg-fec-sf-00 (work in Framework", draft-watson-tsvwg-fec-sf-00 (work in
progress), July 2005. progress), July 2005.
[RFC5725] Begen, A., Hsu, D., and M. Lague, "Post-Repair Loss RLE [RFC5725] Begen, A., Hsu, D., and M. Lague, "Post-Repair Loss RLE
Report Block Type for RTP Control Protocol (RTCP) Extended Report Block Type for RTP Control Protocol (RTCP) Extended
Reports (XRs)", RFC 5725, February 2010. Reports (XRs)", RFC 5725, February 2010.
skipping to change at page 37, line 7 skipping to change at page 44, line 7
[RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. [RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R.
Hakenberg, "RTP Retransmission Payload Format", RFC 4588, Hakenberg, "RTP Retransmission Payload Format", RFC 4588,
July 2006. July 2006.
[I-D.ietf-fecframe-sdp-elements] [I-D.ietf-fecframe-sdp-elements]
Begen, A., "Session Description Protocol Elements for FEC Begen, A., "Session Description Protocol Elements for FEC
Framework", draft-ietf-fecframe-sdp-elements-11 (work in Framework", draft-ietf-fecframe-sdp-elements-11 (work in
progress), October 2010. progress), October 2010.
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
Norrman, "The Secure Real-time Transport Protocol (SRTP)",
RFC 3711, March 2004.
[RFC5740] Adamson, B., Bormann, C., Handley, M., and J. Macker,
"NACK-Oriented Reliable Multicast (NORM) Transport
Protocol", RFC 5740, November 2009.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
RFC 4303, December 2005.
[RFC4383] Baugher, M. and E. Carrara, "The Use of Timed Efficient
Stream Loss-Tolerant Authentication (TESLA) in the Secure
Real-time Transport Protocol (SRTP)", RFC 4383,
February 2006.
[RFC5775] Luby, M., Watson, M., and L. Vicisano, "Asynchronous
Layered Coding (ALC) Protocol Instantiation", RFC 5775,
April 2010.
[MBMSTS] 3GPP, "Multimedia Broadcast/Multicast Service (MBMS); [MBMSTS] 3GPP, "Multimedia Broadcast/Multicast Service (MBMS);
Protocols and codecs", 3GPP TS 26.346, April 2005. Protocols and codecs", 3GPP TS 26.346, April 2005.
Authors' Addresses Authors' Addresses
Mark Watson Mark Watson
Netflix, Inc. Netflix, Inc.
100 Winchester Circle 100 Winchester Circle
Los Gatos, CA 95032 Los Gatos, CA 95032
USA USA
Email: watsonm@netflix.com Email: watsonm@netflix.com
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
Vincent Roca
INRIA
655, av. de l'Europe
Inovallee; Montbonnot
ST ISMIER cedex 38334
France
Email: vincent.roca@inria.fr
URI: http://planete.inrialpes.fr/people/roca/
 End of changes. 20 change blocks. 
55 lines changed or deleted 371 lines changed or added

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