draft-ietf-fecframe-framework-14.txt   draft-ietf-fecframe-framework-15.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: September 5, 2011 Cisco Expires: December 11, 2011 Cisco
V. Roca V. Roca
INRIA INRIA
March 4, 2011 June 9, 2011
Forward Error Correction (FEC) Framework Forward Error Correction (FEC) Framework
draft-ietf-fecframe-framework-14 draft-ietf-fecframe-framework-15
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 September 5, 2011. This Internet-Draft will expire on December 11, 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 39 skipping to change at page 3, line 39
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
10.1. What are the Key Aspects to Consider? . . . . . . . . . . 39 10.1. What are the Key Aspects to Consider? . . . . . . . . . . 39
10.2. Operational and Management Recommendations . . . . . . . . 40 10.2. Operational and Management Recommendations . . . . . . . . 40
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 43 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 44
12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 44 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 45
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 45 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 46
13.1. Normative references . . . . . . . . . . . . . . . . . . . 45 13.1. Normative references . . . . . . . . . . . . . . . . . . . 46
13.2. Informative references . . . . . . . . . . . . . . . . . . 45 13.2. Informative references . . . . . . . . . . . . . . . . . . 46
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 47 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 48
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 11, line 5 skipping to change at page 11, line 5
source and repair data respectively. This is because the use of RTP source and repair data respectively. This is because the use of RTP
for the source data is separate from and independent of the use of for the source data is separate from and independent of the use of
RTP for the repair data. The appearance of two RTP instances is more RTP for the repair data. The appearance of two RTP instances is more
natural when one considers that in many FEC codes, the repair payload natural when one considers that in many FEC codes, the repair payload
contains repair data calculated across the RTP headers of the source contains repair data calculated across the RTP headers of the source
packets. Thus, a repair packet carried over RTP starts with an RTP packets. Thus, a repair packet carried over RTP starts with an RTP
header of its own which is followed (after the Repair Payload ID) by header of its own which is followed (after the Repair Payload ID) by
repair data containing bytes which protect the source RTP headers (as repair data containing bytes which protect the source RTP headers (as
well as repair data for the source RTP payloads). well as repair data for the source RTP payloads).
+--------------------------------------------+ +--------------------------------------------+
| Application | | Application |
+--------------------------------------------+ +--------------------------------------------+
| |
| |
| |
+ - - - - - - - - - - - - - - - - - - - - - - - -+ + - - - - - - - - - - - - - - - - - - - - - - - -+
| +--------------------------------------------+ | | +--------------------------------------------+ |
| Application Layer | | Application Layer |
| +--------------------------------------------+ | | +--------------------------------------------+ |
| | | |
| + -- -- -- -- -- -- -- -- -- -- --+ | | | + -- -- -- -- -- -- -- -- -- -- --+ | |
| RTP (Optional) | | | RTP (Optional) | |
| | | |- Configuration/Coordination | | | |- Configuration/
+- -- -- -- -- -- -- -- -- -- -- -+ | +- -- -- -- -- -- -- -- -- -- -- -+ | Coordination
| | | | | | | |
| ADU flows | | ADU flows |
| | v | | | v |
+--------------------------------------------+ +----------------+ +--------------------------------------------+ +------------+
| | FEC Framework (This document) |<--->| FEC Scheme | | | FEC Framework (This document) |<--->| FEC Scheme |
+--------------------------------------------+ +----------------+ +--------------------------------------------+ +------------+
| | | | | | | |
Source | Repair | Source | Repair |
| | | | | | | |
+-- -- -- -- --|-- --+ -- -- -- -- -- + -- --+ +-- -- -- -- --|-- --+ -- -- -- -- -- + -- --+
| | RTP Layer | | RTP Processing | | | | | RTP Layer | | RTP Processing | | |
| (Optional) | +-- -- -- |- -- -+ | | (Optional) | +-- -- -- |- -- -+ |
| | +-- -- -- -- -- -- -- |--+ | | | | +-- -- -- -- -- -- -- |--+ | |
| | RTP (De)multiplexing | | | | RTP (De)multiplexing | |
| +-- -- -- --- -- -- -- -- -- -- -- -- -- -- -+ | | +-- -- -- --- -- -- -- -- -- -- -- -- -- -- -+ |
| |
| +--------------------------------------------+ | | +--------------------------------------------+ |
| Transport Layer (e.g., UDP) | | Transport Layer (e.g., UDP) |
| +--------------------------------------------+ | | +--------------------------------------------+ |
| |
| +--------------------------------------------+ | | +--------------------------------------------+ |
| IP | | IP |
| +--------------------------------------------+ | | +--------------------------------------------+ |
| Content Delivery Protocol | | Content Delivery Protocol |
+ - - - - - - - - - - - - - - - - - - - - - - - + + - - - - - - - - - - - - - - - - - - - - - - - +
Figure 1: FEC Framework architecture Figure 1: FEC Framework architecture
The content of the transport payload for repair packets is fully The content of the transport payload for repair packets is fully
defined by the FEC scheme. For a specific FEC scheme, a means MAY be defined by the FEC scheme. For a specific FEC scheme, a means MAY be
defined for repair data to be carried over RTP, in which case the defined for repair data to be carried over RTP, in which case the
repair packet payload format starts with the RTP header. This repair packet payload format starts with the RTP header. This
corresponds to defining an RTP payload format for the specific FEC corresponds to defining an RTP payload format for the specific FEC
scheme. scheme.
skipping to change at page 16, line 12 skipping to change at page 16, line 12
carrying the source packet will be the same whether or not the carrying the source packet will be the same whether or not the
FEC Framework is applied). FEC Framework is applied).
+----------------------+ +----------------------+
| Application | | Application |
+----------------------+ +----------------------+
| |
|(1) ADUs |(1) ADUs
| |
v v
+----------------------+ +------------------+ +----------------------+ +----------------+
| FEC Framework | | | | FEC Framework | | |
| |-------------------------->| FEC Scheme | | |-------------------------->| FEC Scheme |
|(2) Construct source |(3) Source Block | | |(2) Construct source |(3) Source Block | |
| blocks | | (4) FEC Encoding | | blocks | |(4) FEC Encoding|
|(6) Construct FEC |<--------------------------| | |(6) Construct FEC |<--------------------------| |
| source and repair | | | | source and repair | | |
| packets |(5) Explicit Source FEC | | | packets |(5) Explicit Source FEC | |
+----------------------+ Payload IDs +------------------+ +----------------------+ Payload IDs +----------------+
| Repair FEC Payload IDs | Repair FEC Payload IDs
| Repair symbols | Repair symbols
| |
|(7) FEC source and repair packets |(7) FEC source and repair packets
v v
+----------------------+ +----------------------+
| Transport Layer | | Transport Layer |
| (e.g., UDP) | | (e.g., UDP) |
+----------------------+ +----------------------+
Figure 2: Sender operation Figure 2: Sender operation
+----------------------+ +----------------------+
| Application | | Application |
+----------------------+ +----------------------+
| |
|(1) ADUs |(1) ADUs
| |
v v
+----------------------+ +------------------+ +----------------------+ +----------------+
| FEC Framework | | | | FEC Framework | | |
| |-------------------------->| FEC Scheme | | |-------------------------->| FEC Scheme |
|(2) Construct source |(3) Source Block | | |(2) Construct source |(3) Source Block | |
| blocks | | (4) FEC Encoding | | blocks | |(4) FEC Encoding|
|(6) Construct FEC |<--------------------------| | |(6) Construct FEC |<--------------------------| |
| source packets and| | | | source packets and| | |
| repair payloads |(5) Explicit Source FEC | | | repair payloads |(5) Explicit Source FEC | |
+----------------------+ Payload IDs +------------------+ +----------------------+ Payload IDs +----------------+
| | Repair FEC Payload IDs | | Repair FEC Payload IDs
| | Repair symbols | | Repair symbols
| | | |
|(7) Source |(7') Repair payloads |(7) Source |(7') Repair payloads
| packets | | packets |
| | | |
| + -- -- -- -- -+ | + -- -- -- -- -+
| | RTP | | | RTP |
| +-- -- -- -- --+ | +-- -- -- -- --+
v v v v
skipping to change at page 19, line 12 skipping to change at page 19, line 12
reconstructed source packets into the order they were placed into the reconstructed source packets into the order they were placed into the
source block, if that is necessary according to the application. source block, if that is necessary according to the application.
+----------------------+ +----------------------+
| Application | | Application |
+----------------------+ +----------------------+
^ ^
| |
|(6) ADUs |(6) ADUs
| |
+----------------------+ +------------------+ +----------------------+ +----------------+
| FEC Framework | | | | FEC Framework | | |
| |<---------------------------| FEC Scheme | | |<--------------------------| FEC Scheme |
|(2)Extract FEC Payload|(5) ADUs | | |(2)Extract FEC Payload|(5) ADUs | |
| IDs and pass IDs & | | (4) FEC Decoding | | IDs and pass IDs & | |(4) FEC Decoding|
| payloads to FEC |--------------------------->| | | payloads to FEC |-------------------------->| |
| scheme |(3) Explicit Source FEC | | | scheme |(3) Explicit Source FEC | |
+----------------------+ Payload IDs +------------------+ +----------------------+ Payload IDs +----------------+
^ Repair FEC Payload IDs ^ Repair FEC Payload IDs
| Source payloads | Source payloads
| Repair payloads | Repair payloads
| |
|(1) FEC source and repair packets |(1) FEC source and repair packets
| |
+----------------------+ +----------------------+
| Transport Layer | | Transport Layer |
| (e.g., UDP) | | (e.g., UDP) |
+----------------------+ +----------------------+
Figure 4: Receiver operation Figure 4: Receiver operation
+----------------------+ +----------------------+
| Application | | Application |
+----------------------+ +----------------------+
^ ^
| |
|(6) ADUs |(6) ADUs
| |
+----------------------+ +------------------+ +----------------------+ +----------------+
| FEC Framework | | | | FEC Framework | | |
| |<---------------------------| FEC Scheme | | |<--------------------------| FEC Scheme |
|(2)Extract FEC Payload|(5) ADUs | | |(2)Extract FEC Payload|(5) ADUs | |
| IDs and pass IDs & | | (4) FEC Decoding | | IDs and pass IDs & | |(4) FEC Decoding|
| payloads to FEC |--------------------------->| | | payloads to FEC |-------------------------->| |
| scheme |(3) Explicit Source FEC | | | scheme |(3) Explicit Source FEC | |
+----------------------+ Payload IDs +------------------+ +----------------------+ Payload IDs +----------------+
^ ^ Repair FEC Payload IDs ^ ^ Repair FEC Payload IDs
| | Source payloads | | Source payloads
| | Repair payloads | | Repair payloads
| | | |
|Source |Repair payloads |Source |Repair payloads
|packets | |packets |
| | | |
+-- |- -- -- -- -- -- -+ +-- |- -- -- -- -- -- -+
|RTP| | RTP Processing | |RTP| | RTP Processing |
| | +-- -- -- --|-- -+ | | +-- -- -- --|-- -+
skipping to change at page 40, line 37 skipping to change at page 40, line 37
Overall, from the discussion of Section 10.1, it is clear that the Overall, from the discussion of Section 10.1, it is clear that the
CDPs and FEC schemes compatible with the FEC Framework widely differ CDPs and FEC schemes compatible with the FEC Framework widely differ
in their capabilities, application and deployment scenarios such that in their capabilities, application and deployment scenarios such that
a common operation and management method or protocol that works well 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 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 choice, the FEC Framework does not dictate the use of any particular
technology or protocol for transporting FEC data, managing the hosts, technology or protocol for transporting FEC data, managing the hosts,
signaling the configuration information or encoding the configuration signaling the configuration information or encoding the configuration
information. This provides flexibility and is one of the main goals information. This provides flexibility and is one of the main goals
of the FEC Framework. However, this section gives some of the FEC Framework. However, this section gives some RECOMMENDED
recommendations. guidelines.
o A Single Small Generic Component within a Larger (and Often o A Single Small Generic Component within a Larger (and Often
Legacy) Solution: It is anticipated that the FEC Framework will Legacy) Solution: It is anticipated that the FEC Framework will
often be used to protect one or several RTP streams. Therefore, often be used to protect one or several RTP streams. Therefore,
there are use cases that may take advantage of RTCP to collect implementations SHOULD make feedback information accessible via
feedback information, and one can take advantage of the tools RTCP to enable users to take advantage of the tools using (or used
using (or used by) RTCP to operate and manage the FEC Framework by) RTCP to operate and manage the FEC Framework instance along
instance along with the associated FEC schemes. with the associated FEC schemes.
o One-to-One with Feedback vs. One-to-Many with Feedback vs. One-to- 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, Many without Feedback Scenarios: With use cases that are one-way,
the FEC Framework sender does not have any way to gather feedback the FEC Framework sender does not have any way to gather feedback
from receivers. With use cases that are bidirectional, the FEC from receivers. With use cases that are bidirectional, the FEC
Framework sender can collect detailed feedback (e.g., in case of a Framework sender can collect detailed feedback (e.g., in case of a
one-to-one scenario) or at least occasional feedback (e.g., in one-to-one scenario) or at least occasional feedback (e.g., in
case of a multicast, one-to-many scenario). All these case of a multicast, one-to-many scenario). All these
applications have naturally different operational and management applications have naturally different operational and management
aspects. If any, they also have different requirements or aspects. If any, they also have different requirements or
features for collecting feedback, processing it and acting on it. features for collecting feedback, processing it and acting on it.
The data structures for carrying the feedback also vary. The data structures for carrying the feedback also vary.
Implementers SHOULD make feedback available using either an in-
band or out-of-band asynchronous reporting mechanism. When an
out-of-band solution is preferred, a standardized reporting
mechanism, such as Syslog [RFC5424] or SNMP notifications
[RFC3411], is RECOMMENDED. When required, a mapping mechanism
between the Syslog and SNMP reporting mechanisms could be used, as
described in [RFC5675] and [RFC5676].
o Non-FEC Framework Capable Receivers: Section 5.3 gives o Non-FEC Framework Capable Receivers: Section 5.3 gives
recommendations on how to provide backward compatibility in recommendations on how to provide backward compatibility in
presence of receivers that cannot support the FEC scheme being presence of receivers that cannot support the FEC scheme being
used, or the FEC Framework itself: basically the use of Explicit used, or the FEC Framework itself: basically the use of Explicit
Source FEC Payload ID is banned. Additionally, a non-FEC Source FEC Payload ID is banned. Additionally, a non-FEC
Framework capable receiver MUST also have a means not to receive 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 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 place or a means to identify and discard them appropriately upon
receiving them. This can be achieved by sending repair packets on receiving them. This SHOULD be achieved by sending repair packets
a different transport-layer flow. In case of an RTP source flow, on a different transport-layer flow. In case of RTP transport and
this can also be achieved by using an RTP framing for FEC repair if both source and repair packets will be sent on the same
packets with a different payload type. Both source and repair transport-layer flow, this SHOULD be achieved by using an RTP
packets can then be sent on the same transport-layer flow. It is framing for FEC repair packets with a different payload type. It
the responsibility of the sender to select the appropriate is the responsibility of the sender to select the appropriate
mechanism when needed. mechanism when needed.
o Within End-Systems vs. within Middleboxes: When the FEC Framework o Within End-Systems vs. within Middleboxes: When the FEC Framework
is used within middleboxes, it is RECOMMENDED that the paths is used within middleboxes, it is RECOMMENDED that the paths
between the hosts where the sending applications run and the between the hosts where the sending applications run and the
middlebox that performs FEC encoding be as reliable as possible, middlebox that performs FEC encoding be as reliable as possible,
i.e., are not prone to packet loss, packet reordering, or varying i.e., are not prone to packet loss, packet reordering, or varying
delays in delivering packets. delays in delivering packets.
Similarly, it is RECOMMENDED that the paths between the Similarly, it is RECOMMENDED that the paths between the
middleboxes that perform FEC decoding and the end-systems where middleboxes that perform FEC decoding and the end-systems where
the receiving applications operate, in situations where this is a the receiving applications operate, in situations where this is a
different host, be as reliable as possible. different host, be as reliable as possible.
The recommendation for the sending side is particularly important o Management of Communication Issues Before Reaching the Sending
with FEC schemes that do not modify the ADU for backward FECFRAME Instance: Let us consider situations where the FEC
compatibility purposes (i.e. do not use any Explicit Source FEC Framework is used within middleboxes. At the sending side, the
Payload ID) and rely for instance on the RTP sequence number field general reliability recommendation for the path between the
to identify FEC source packets within their source block. In this sending applications and the middlebox is important but it may not
case, packet loss or packet reordering leads to a gap in the RTP guarantee that a loss, reordering or important delivery delay
sequence number space seen by the FECFRAME instance. Similarly, cannot happen, for whatever reason. If such a rare event happens,
varying delay in delivering packets over this path can lead to this event SHOULD NOT compromise the operation of the FECFRAME
significant timing issues. With FEC schemes that indicate in the instances, neither at the sending side nor receiving side. This
Repair FEC Payload ID, for each source block, the base RTP is particularly important with FEC schemes that do not modify the
sequence number and number of consecutive RTP packets that belong ADU for backward compatibility purposes (i.e., do not use any
to this source block, a missing ADU or an ADU delivered out of Explicit Source FEC Payload ID) and rely for instance on the RTP
order could cause the FECFRAME sender to switch to a new source sequence number field to identify FEC source packets within their
block. However, some FEC schemes and/or receivers may not source block. In this case, packet loss or packet reordering
necessarily handle such varying source block sizes. In this case, leads to a gap in the RTP sequence number space seen by the
another solution SHOULD be considered that is use-case specific FECFRAME instance. Similarly, varying delay in delivering packets
and whose consequences need to be carefully considered (e.g., by over this path can lead to significant timing issues. With FEC
duplicating the last ADU received before the loss, or by inserting schemes that indicate in the Repair FEC Payload ID, for each
a zero'ed ADU, depending on the ADU flow nature). source block, the base RTP sequence number and number of
consecutive RTP packets that belong to this source block, a
missing ADU or an ADU delivered out of order 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. In this case, one could consider
duplicating the last ADU received before the loss, or inserting
zero'ed ADU(s), depending on the ADU flow nature. Implementers
SHOULD consider the consequences of such alternative approaches
based on their use cases.
o Protecting a Single Flow vs. Several Flows Globally: In the o Protecting a Single Flow vs. Several Flows Globally: In the
general case, the various ADU flows that are globally protected general case, the various ADU flows that are globally protected
can have different features, and in particular different real-time can have different features, and in particular different real-time
requirements (in case of real-time flows). The process of requirements (in case of real-time flows). The process of
globally protecting these flows SHOULD take into account the globally protecting these flows SHOULD take into account the
requirements of each individual flow. In particular, it would be requirements of each individual flow. In particular, it would be
counter-productive to add repair traffic to a real-time flow for counter-productive to add repair traffic to a real-time flow for
which the FEC decoding delay at a receiver makes decoded ADUs for which the FEC decoding delay at a receiver makes decoded ADUs for
this flow useless because they do not satisfy the associated real- this flow useless because they do not satisfy the associated real-
time constraints. From a practical point of view, this means that time constraints. From a practical point of view, this means that
the source block creation process at the sending FEC Framework the source block creation process at the sending FEC Framework
instance, SHOULD consider the most stringent real-time instance, SHOULD consider the most stringent real-time
requirements of the ADU flows being globally protected. requirements of the ADU flows being globally protected.
o ADU Flow Bundle Definition and Flow Delivery: By design a repair 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 flow might enable a receiver to recover the ADU flow(s) that it
protects even if none of the associated FEC source packets are protects even if none of the associated FEC source packets are
received. Therefore, when defining the bundle of ADU flows that received. Therefore, when defining the bundle of ADU flows that
are globally protected and when defining which receiver receives are globally protected and when defining which receiver receives
which flow, the repair flow(s) SHOULD only be received by which flow, the sender SHOULD make sure that the ADU flow(s) and
receivers that are authorized to receive all the associated ADU repair flow(s) of that bundle will only be received by receivers
flows. See Section 9.4 for additional recommendations for that are authorized to receive all the ADU flows of that bundle.
situations where a strict access control to ADU flows is needed. 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 Additionally when multiple ADU flows are globally protected, a
receiver who wants to benefit from FECFRAME loss protection SHOULD receiver who wants to benefit from FECFRAME loss protection SHOULD
receive all the ADU flows of the bundle. Otherwise, the missing receive all the ADU flows of the bundle. Otherwise, the missing
FEC source packets would be considered as lost which might FEC source packets would be considered as lost which might
significantly reduce the efficiency of the FEC scheme. 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
skipping to change at page 45, line 33 skipping to change at page 46, 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.
[RFC5424] Gerhards, R., "The Syslog Protocol", RFC 5424, March 2009.
[RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An
Architecture for Describing Simple Network Management
Protocol (SNMP) Management Frameworks", STD 62, RFC 3411,
December 2002.
13.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 46, line 15 skipping to change at page 47, line 22
progress), October 2010. progress), October 2010.
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
Norrman, "The Secure Real-time Transport Protocol (SRTP)", Norrman, "The Secure Real-time Transport Protocol (SRTP)",
RFC 3711, March 2004. RFC 3711, March 2004.
[RFC5740] Adamson, B., Bormann, C., Handley, M., and J. Macker, [RFC5740] Adamson, B., Bormann, C., Handley, M., and J. Macker,
"NACK-Oriented Reliable Multicast (NORM) Transport "NACK-Oriented Reliable Multicast (NORM) Transport
Protocol", RFC 5740, November 2009. Protocol", RFC 5740, November 2009.
[RFC5675] Marinov, V. and J. Schoenwaelder, "Mapping Simple Network
Management Protocol (SNMP) Notifications to SYSLOG
Messages", RFC 5675, October 2009.
[RFC5676] Schoenwaelder, J., Clemm, A., and A. Karmakar,
"Definitions of Managed Objects for Mapping SYSLOG
Messages to Simple Network Management Protocol (SNMP)
Notifications", RFC 5676, October 2009.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
RFC 4303, December 2005. RFC 4303, December 2005.
[RFC4383] Baugher, M. and E. Carrara, "The Use of Timed Efficient [RFC4383] Baugher, M. and E. Carrara, "The Use of Timed Efficient
Stream Loss-Tolerant Authentication (TESLA) in the Secure Stream Loss-Tolerant Authentication (TESLA) in the Secure
Real-time Transport Protocol (SRTP)", RFC 4383, Real-time Transport Protocol (SRTP)", RFC 4383,
February 2006. February 2006.
[RFC5775] Luby, M., Watson, M., and L. Vicisano, "Asynchronous [RFC5775] Luby, M., Watson, M., and L. Vicisano, "Asynchronous
Layered Coding (ALC) Protocol Instantiation", RFC 5775, Layered Coding (ALC) Protocol Instantiation", RFC 5775,
 End of changes. 19 change blocks. 
119 lines changed or deleted 153 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/