draft-ietf-fecframe-framework-12.txt   draft-ietf-fecframe-framework-13.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: July 22, 2011 Cisco Expires: August 19, 2011 Cisco
V. Roca V. Roca
INRIA INRIA
January 18, 2011 February 15, 2011
Forward Error Correction (FEC) Framework Forward Error Correction (FEC) Framework
draft-ietf-fecframe-framework-12 draft-ietf-fecframe-framework-13
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 45 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 July 22, 2011. This Internet-Draft will expire on August 19, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2011 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
skipping to change at page 3, line 20 skipping to change at page 3, line 20
4. Procedural Overview . . . . . . . . . . . . . . . . . . . . . 13 4. Procedural Overview . . . . . . . . . . . . . . . . . . . . . 13
4.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 13 4.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 13
4.2. Sender Operation . . . . . . . . . . . . . . . . . . . . . 14 4.2. Sender Operation . . . . . . . . . . . . . . . . . . . . . 14
4.3. Receiver Operation . . . . . . . . . . . . . . . . . . . . 17 4.3. Receiver Operation . . . . . . . . . . . . . . . . . . . . 17
5. Protocol Specification . . . . . . . . . . . . . . . . . . . . 21 5. Protocol Specification . . . . . . . . . . . . . . . . . . . . 21
5.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 21 5.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 21
5.2. Structure of the Source Block . . . . . . . . . . . . . . 21 5.2. Structure of the Source Block . . . . . . . . . . . . . . 21
5.3. Packet Format for FEC Source Packets . . . . . . . . . . . 21 5.3. Packet Format for FEC Source Packets . . . . . . . . . . . 21
5.3.1. Generic Explicit Source FEC Payload ID . . . . . . . . 23 5.3.1. Generic Explicit Source FEC Payload ID . . . . . . . . 23
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 . . . . 24
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
9.1. Problem Statement . . . . . . . . . . . . . . . . . . . . 33 9.1. Problem Statement . . . . . . . . . . . . . . . . . . . . 33
9.2. Attacks Against the Data Flows . . . . . . . . . . . . . . 34 9.2. Attacks Against the Data Flows . . . . . . . . . . . . . . 34
9.2.1. Access to Confidential Content . . . . . . . . . . . . 34 9.2.1. Access to Confidential Content . . . . . . . . . . . . 34
9.2.2. Content Corruption . . . . . . . . . . . . . . . . . . 35 9.2.2. Content Corruption . . . . . . . . . . . . . . . . . . 35
9.3. Attacks Against the FEC Parameters . . . . . . . . . . . . 36 9.3. Attacks Against the FEC Parameters . . . . . . . . . . . . 36
9.4. When Several Source Flows are to be Protected Together . . 37 9.4. When Several Source Flows are to be Protected Together . . 37
9.5. Baseline Secure FEC Framework Operation . . . . . . . . . 37 9.5. Baseline Secure FEC Framework Operation . . . . . . . . . 37
10. Operations and Management Considerations . . . . . . . . . . . 39 10. Operations and Management Considerations . . . . . . . . . . . 39
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 41 10.1. What are the Key Aspects to Consider? . . . . . . . . . . 39
12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 42 10.2. Operational and Management Recommendations . . . . . . . . 40
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 43 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 43
13.1. Normative references . . . . . . . . . . . . . . . . . . . 43 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 44
13.2. Informative references . . . . . . . . . . . . . . . . . . 43 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 45
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 45 13.1. Normative references . . . . . . . . . . . . . . . . . . . 45
13.2. Informative references . . . . . . . . . . . . . . . . . . 45
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 47
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 23, line 24 skipping to change at page 23, line 24
and consists of an unsigned packet sequence number in network-byte and consists of an unsigned packet sequence number in network-byte
order. The allocation of sequence numbers to packets is independent order. The allocation of sequence numbers to packets is independent
of any FEC scheme and of the source block construction, except that of any FEC scheme and of the source block construction, except that
the use of this sequence number places a constraint on source block the use of this sequence number places a constraint on source block
construction. Source packets within a given source block MUST have construction. Source packets within a given source block MUST have
consecutive sequence numbers (where consecutive includes wrap-around consecutive sequence numbers (where consecutive includes wrap-around
from the maximum value which can be represented in two octets (65535) from the maximum value which can be represented in two octets (65535)
to 0). Sequence numbers SHOULD NOT be reused until all values in the to 0). Sequence numbers SHOULD NOT be reused until all values in the
sequence number space have been used. sequence number space have been used.
Note that if the original packets of the source flow are already
carrying a packet sequence number that is at least two bytes long,
there is no need to add the generic Explicit Source FEC Payload ID
and modify the packets.
5.4. Packet Format for FEC Repair Packets 5.4. Packet Format for FEC Repair Packets
The packet format for FEC repair packets is shown in Figure 7. The The packet format for FEC repair packets is shown in Figure 7. The
transport payload consists of a Repair FEC Payload ID field followed transport payload consists of a Repair FEC Payload ID field followed
by repair data generated in the FEC encoding process. by repair data generated in the FEC encoding process.
+------------------------------------+ +------------------------------------+
| IP Header | | IP Header |
+------------------------------------+ +------------------------------------+
| Transport Header | | Transport Header |
skipping to change at page 39, line 7 skipping to change at page 39, line 7
Note that the IPsec/ESP requirements profiles outlined in [RFC5775] Note that the IPsec/ESP requirements profiles outlined in [RFC5775]
and [RFC5740] are commonly available on many potential hosts. They and [RFC5740] are commonly available on many potential hosts. They
can form the basis of a secure mode of operation. One potential can form the basis of a secure mode of operation. One potential
limitation, however, is the need for privileged user authorization. limitation, however, is the need for privileged user authorization.
However, automated key management implementations are typically However, automated key management implementations are typically
configured with the privileges necessary to affect system IPsec configured with the privileges necessary to affect system IPsec
configuration. configuration.
10. Operations and Management Considerations 10. Operations and Management Considerations
The FEC Framework is concerned about the FEC encoding and decoding The question of operating and managing the FEC Framework and the
operations, and the configuration information that is essential to associated FEC scheme(s) is of high practical importance. The goals
control the hosts running these operations. Defining tools for the of this section are to discuss the general requirements, aspects
operation and management of these hosts is not within the scope of related to a specific deployment and solutions whenever possible.
this specification.
Some applications using the CDPs compatible with the FEC Framework In particular, this section discusses the questions of
are one-way meaning that they do not have a way to gather any kind of interoperability across vendors/use cases and whether defining
feedback from receivers (e.g., broadcast), while some of them may mandatory to implement (but not mandatory to use) solutions is
collect detailed feedback (in case it is a one-to-one application) or beneficial.
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- 10.1. What are the Key Aspects to Consider?
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 Several aspects need to be considered since they will directly impact
hosts (sender or receiver or even a middle-box) could do upon the way the FEC Framework and the associated FEC schemes can be
observing something in particular or receiving a specific feedback. operated and managed.
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 This section lists them as follows:
widely differ in their capabilities, application and deployment
scenarios such that a common operation and management tool that works o A Single Small Generic Component within a Larger (and Often
well for all of them does not exist. Thus, as a design choice, the Legacy) Solution: The FEC Framework is one component within a
FEC Framework does not dictate the use of any particular technology larger solution which includes both one or several upper-layer
or protocol for transporting FEC data, managing the hosts, signaling applications (that generate one or several ADU flows) and an
the configuration information or encoding the configuration underlying protocol stack. A key design principle is that the FEC
information. This provides flexibility and was one of the main goals Framework should be able to work without making any assumption
of the FEC Framework. with respect to either the upper-layer application(s) or the
underlying protocol stack, even if there are special cases where
assumptions are made.
o One-to-One with Feedback vs. One-to-Many with Feedback vs. One-to-
Many without Feedback Scenarios: The FEC Framework can be used in
use cases that completely differ from one another. Some use cases
are one-way (e.g., in broadcast networks), with either a one-to-
one, one-to-many or many-to-many transmission model, and the
receiver(s) cannot send any feedback to the sender(s). Other use
cases follow a bidirectional one-to-one, one-to-many, or many-to-
many scenario, and the receiver(s) can send feedback to the
sender(s).
o Non-FEC Framework Capable Receivers: With the one-to-many and
many-to-many use cases, the receiver population might have
different capabilities with respect to the FEC Framework itself
and the supported FEC schemes. Some receivers might not be
capable of decoding the repair packets belonging to a particular
FEC scheme, while some other receivers might not be supporting the
FEC Framework at all.
o Internet vs. non-Internet Networks: The FEC Framework can be
useful in many use cases that use a transport network that is not
the public Internet (e.g., with IPTV or Mobile TV). In such
networks, the operational and management considerations can be
achieved through an open or proprietary solution, which is
specified outside of the IETF.
o Congestion Control Considerations: See Section 8 for a discussion
on whether congestion control is needed or not, and its
relationships with the FEC Framework.
o Within End-Systems vs. within Middleboxes: The FEC Framework can
be used within end-systems, very close to the upper-layer
application, or within dedicated middleboxes, for instance when it
is desired to protect one or several flows while they cross a
lossy channel between two or more remote sites.
o Protecting a Single Flow vs. Several Flows Globally: The FEC
Framework can be used to protect a single flow, or several flows
globally.
10.2. Operational and Management Recommendations
Overall, from the discussion of Section 10.1, it is clear that 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 method or protocol that works well
for all of them would be too complex to define. 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 is one of the main goals
of the FEC Framework. However, this section gives some
recommendations.
o A Single Small Generic Component within a Larger (and Often
Legacy) Solution: It is anticipated that the FEC Framework will
often be used to protect one or several RTP streams. Therefore,
there are use cases that may take advantage of RTCP to collect
feedback information, and one can take advantage of the tools
using (or used by) RTCP to operate and manage the FEC Framework
instance along with the associated FEC schemes.
o One-to-One with Feedback vs. One-to-Many with Feedback vs. One-to-
Many without Feedback Scenarios: With use cases that are one-way,
the FEC Framework sender does not have any way to gather feedback
from receivers. With use cases that are bidirectional, the FEC
Framework sender can collect detailed feedback (e.g., in case of a
one-to-one scenario) or at least occasional feedback (e.g., in
case of a multicast, one-to-many scenario). All these
applications have naturally different operational and 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.
o Non-FEC Framework Capable Receivers: Section 5.3 gives
recommendations on how to provide backward compatibility in
presence of receivers that cannot support the FEC scheme being
used, or the FEC Framework itself: basically the use of Explicit
Source FEC Payload ID is banned. Additionally, a non-FEC
Framework capable receiver MUST also have a means not to receive
the repair packets that it will not be able to decode in the first
place or a means to identify and discard them appropriately upon
receiving them. This can be achieved by sending repair packets on
a different transport-layer flow. In case of an RTP source flow,
this can also be achieved by using an RTP framing for FEC repair
packets with a different payload type. Both source and repair
packets can then be sent on the same transport-layer flow. It is
the responsibility of the sender to select the appropriate
mechanism when needed.
o Within End-Systems vs. within Middleboxes: When the FEC Framework
is used within middleboxes, it is RECOMMENDED that the paths
between the hosts where the sending applications run and the
middlebox that performs FEC encoding be as reliable as possible,
since these paths are not protected against erasures by default.
Similarly, it is RECOMMENDED that the paths between the
middleboxes that perform FEC decoding and the end-systems where
the receiving applications operate, in situations where this is a
different host, be as reliable as possible since these paths are
not protected against losses by default.
The recommendation for the sending side is particularly important
with FEC schemes that do not modify the ADU for backward
compatibility purposes (i.e. do not use any Explicit Source FEC
Payload ID) and rely for instance on the RTP sequence number field
to identify FEC source packets within their source block. In this
case, a lost or excessively delayed packet on this path directly
leads to a gap in the RTP sequence number space seen by the
FECFRAME instance. With FEC schemes that indicate in the Repair
FEC Payload ID, for each source block, the base RTP sequence
number and number of consecutive RTP packets that belong to this
source block, a missing ADU could cause the FECFRAME sender to
switch to a new source block. However, some FEC schemes and/or
receivers may not necessarily handle such varying source block
sizes. Thus, all the ADUs SHOULD be fed into the FEC encoder in
their proper sequence and within a desired certain delay. For
cases when this cannot be guaranteed, the sender and receiver
implementations need to concider a potential solution and its
consequences.
o Protecting a Single Flow vs. Several Flows Globally: In the
general case, the various ADU flows that are globally protected
can have different features, and in particular different real-time
requirements (in case of real-time flows). The process of
globally protecting these flows SHOULD take into account the
requirements of each individual flow. In particular, it would be
counter-productive to add repair traffic to a real-time flow for
which the FEC decoding delay at a receiver makes decoded ADUs for
this flow useless because they do not satisfy the associated real-
time constraints. From a practical point of view, this means that
the source block creation process at the sending FEC Framework
instance, SHOULD consider the most stringent real-time
requirements of the ADU flows being globally protected.
o ADU Flow Bundle Definition and Flow Delivery: By design a repair
flow might enable a receiver to recover the ADU flow(s) that it
protects even if none of the associated FEC source packets are
received. Therefore, when defining the bundle of ADU flows that
are globally protected and when defining which receiver receives
which flow, the repair flow(s) SHOULD only be received by
receivers that are authorized to receive all the associated ADU
flows. See Section 9.4 for additional recommendations for
situations where a strict access control to ADU flows is needed.
Additionally when multiple ADU flows are globally protected, a
receiver who wants to benefit from FECFRAME loss protection SHOULD
receive all the ADU flows of the bundle. Otherwise, the missing
FEC source packets would be considered as lost which might
significantly reduce the efficiency of the FEC scheme.
11. IANA Considerations 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).
 End of changes. 12 change blocks. 
57 lines changed or deleted 190 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/