draft-ietf-fecframe-framework-01.txt   draft-ietf-fecframe-framework-02.txt 
FEC Framework Working Group M. Watson FEC Framework Working Group M. Watson
Internet-Draft Digital Fountain Internet-Draft Digital Fountain
Intended status: Standards Track November 16, 2007 Intended status: Standards Track July 12, 2008
Expires: May 19, 2008 Expires: January 13, 2009
Forward Error Correction (FEC) Framework Forward Error Correction (FEC) Framework
draft-ietf-fecframe-framework-01 draft-ietf-fecframe-framework-02
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 34 skipping to change at page 1, line 34
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on May 19, 2008. This Internet-Draft will expire on January 13, 2009.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Abstract Abstract
This document describes for a framework for using forward error This document describes for 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 Forward Error Correction to arbitrary packet flows supports applying Forward Error Correction to arbitrary packet flows
over unreliable transport and is primarily intended for real-time, or over unreliable transport and is primarily intended for real-time, or
streaming, media. This framework can be used to define Content streaming, media. This framework can be used to define Content
Delivery Protocols that provide Forward Error Correction for Delivery Protocols that provide Forward Error Correction for
skipping to change at page 3, line 11 skipping to change at page 3, line 11
Protocols can be defined which are not specific to a particular FEC Protocols can be defined which are not specific to a particular FEC
Scheme and FEC Schemes can be defined which are not specific to a Scheme and FEC Schemes can be defined which are not specific to a
particular Content Delivery Protocol. particular Content Delivery Protocol.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Definitions/Abbreviations . . . . . . . . . . . . . . . . . . 6 2. Definitions/Abbreviations . . . . . . . . . . . . . . . . . . 6
3. Requirements notation . . . . . . . . . . . . . . . . . . . . 8 3. Requirements notation . . . . . . . . . . . . . . . . . . . . 8
4. Architecture Overview . . . . . . . . . . . . . . . . . . . . 9 4. Architecture Overview . . . . . . . . . . . . . . . . . . . . 9
5. Procedural overview . . . . . . . . . . . . . . . . . . . . . 12 5. Procedural overview . . . . . . . . . . . . . . . . . . . . . 13
5.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 12 5.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 13
5.2. Sender Operation . . . . . . . . . . . . . . . . . . . . . 13 5.2. Sender Operation . . . . . . . . . . . . . . . . . . . . . 14
5.3. Receiver Operation . . . . . . . . . . . . . . . . . . . . 15 5.3. Receiver Operation . . . . . . . . . . . . . . . . . . . . 16
6. Protocol Specification . . . . . . . . . . . . . . . . . . . . 18 6. Protocol Specification . . . . . . . . . . . . . . . . . . . . 19
6.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 18 6.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 19
6.2. Structure of the source block . . . . . . . . . . . . . . 18 6.2. Structure of the source block . . . . . . . . . . . . . . 19
6.3. Packet format for FEC Source packets . . . . . . . . . . . 18 6.3. Packet format for FEC Source packets . . . . . . . . . . . 19
6.4. Packet Format for FEC Repair packets . . . . . . . . . . . 20 6.4. Packet Format for FEC Repair packets . . . . . . . . . . . 21
6.5. FEC Framework Configuration Information . . . . . . . . . 20 6.4.1. Packet Format for FEC Repair packets over RTP
6.6. FEC Scheme requirements . . . . . . . . . . . . . . . . . 22 (informative) . . . . . . . . . . . . . . . . . . . . 21
7. Transport Protocols . . . . . . . . . . . . . . . . . . . . . 25 6.5. FEC Framework Configuration Information . . . . . . . . . 22
8. Congestion Control . . . . . . . . . . . . . . . . . . . . . . 26 6.6. FEC Scheme requirements . . . . . . . . . . . . . . . . . 23
8.1. Normative requirements . . . . . . . . . . . . . . . . . . 27 7. Transport Protocols . . . . . . . . . . . . . . . . . . . . . 26
9. Security Considerations . . . . . . . . . . . . . . . . . . . 29 8. Congestion Control . . . . . . . . . . . . . . . . . . . . . . 27
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 8.1. Normative requirements . . . . . . . . . . . . . . . . . . 28
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 31 9. Security Considerations . . . . . . . . . . . . . . . . . . . 30
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 33 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 32
Intellectual Property and Copyright Statements . . . . . . . . . . 34 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 33
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 34
Intellectual Property and Copyright Statements . . . . . . . . . . 35
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 packetised data from a source (sender) to one or more destinations of packetised 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.
Forward Error Correction is a well-known technique for improving Forward Error Correction is a well-known technique for improving
reliability of packet transmission over networks which do not provide reliability of packet transmission over networks which do not provide
guaranteed packet delivery, especially in multicast and broadcast guaranteed packet delivery, especially in multicast and broadcast
applications. The FEC Building Block defined in [3] provides a applications. The FEC Building Block defined in [RFC5052] provides a
framework for definition of Content Delivery Protocols (CDPs) for framework for definition of Content Delivery Protocols (CDPs) for
object delivery (including, primarily, file delivery) which make use object delivery (including, primarily, file delivery) which make use
of separately defined FEC Schemes. Any CDP defined according to the of separately defined FEC Schemes. Any CDP defined according to the
requirements of the FEC Building Block can then easily be used with requirements of the FEC Building Block can then easily be used with
any FEC Scheme which is also defined according to the requirements of any FEC Scheme which is also defined according to the requirements of
the FEC Building Block. (Note that the term "Forward Erasure the FEC Building Block. (Note that the term "Forward Erasure
Correction" is sometimes used, 'erasures' being a type of error in Correction" is sometimes used, 'erasures' being a type of error in
which data is lost and this loss can be detected, rather than being which data is lost and this loss can be detected, rather than being
received in corrupted form - the focus of this document is strictly received in corrupted form - the focus of this document is strictly
on erasures, however the term Forward Error Correction is more widely on erasures, however the term Forward Error Correction is more widely
used). used).
This document defines a framework for the definition of CDPs which This document defines a framework for the definition of CDPs which
provide for FEC protection of arbitrary packet flows over unreliable provide for FEC protection of arbitrary packet flows over unreliable
transports such as UDP. As such, this document complements the FEC transports such as UDP. As such, this document complements the FEC
Building Block of [3], by providing for the case of arbitrary packet Building Block of [RFC5052], by providing for the case of arbitrary
flows over unreliable transport, the same kind of framework as that packet flows over unreliable transport, the same kind of framework as
document provides for object delivery. This document does not define that document provides for object delivery. This document does not
a complete Content Delivery Protocol, but rather defines only those define a complete Content Delivery Protocol, but rather defines only
aspects that are expected to be common to all Content Delivery those aspects that are expected to be common to all Content Delivery
Protocols based on this framework. Protocols based on this framework.
This framework does not define how the flows to be protected are This framework does not define how the flows to be protected are
determined, nor how the details of the protected flows and the FEC determined, nor how the details of the protected flows and the FEC
streams which protect them are communicated from sender to receiver. streams which protect them are communicated from sender to receiver.
It is expected that any complete Content Delivery Protocol It is expected that any complete Content Delivery Protocol
specification which makes use of this framework will address these specification which makes use of this framework will address these
signalling requirements. However, this document does specify the signalling requirements. However, this document does specify the
information which is required by the FEC Framework at the sender and information which is required by the FEC Framework at the sender and
receiver - for example details of the flows to be FEC protected, the receiver - for example details of the flows to be FEC protected, the
flow(s) that will carry the FEC protection data and an opaque flow(s) that will carry the FEC protection data and an opaque
container for FEC-Scheme-specific information. container for FEC-Scheme-specific information.
FEC Schemes designed for use with this framework must fulfil a number FEC Schemes designed for use with this framework must fulfil a number
of requirements defined in this document. Note that these of requirements defined in this document. Note that these
requirements are different from those defined in [3] for FEC Schemes requirements are different from those defined in [RFC5052] for FEC
for object delivery. However there is a great deal of commonality Schemes for object delivery. However there is a great deal of
and FEC Schemes defined for object delivery may be easily adapted for commonality and FEC Schemes defined for object delivery may be easily
use with the framework defined here. adapted for use with the framework defined here.
2. Definitions/Abbreviations 2. Definitions/Abbreviations
'FEC' Forward Error Correction. 'FEC' Forward Error Correction.
'AL-FEC' Application Layer Forward Error Correction 'AL-FEC' Application Layer Forward Error Correction
'FEC Framework' A protocol framework for definition of Content 'FEC Framework' A protocol framework for definition of Content
Delivery Protocols using FEC, such as the framework defined in Delivery Protocols using FEC, such as the framework defined in
this document. this document.
skipping to change at page 8, line 9 skipping to change at page 8, line 9
Content Delivery Protocol (CDP): A complete application protocol Content Delivery Protocol (CDP): A complete application protocol
specification which, through the use of the framework defined in specification which, through the use of the framework defined in
this document, is able to make use of FEC Schemes to provide this document, is able to make use of FEC Schemes to provide
Forward Error Correction capabilities. Forward Error Correction capabilities.
3. Requirements notation 3. Requirements notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [1]. document are to be interpreted as described in [RFC2119].
4. Architecture Overview 4. Architecture Overview
The FEC Framework is described in terms of an additional protocol The FEC Framework is described in terms of an additional protocol
layer between the transport layer (e.g. UDP or DCCP) and Application layer between the transport layer (e.g. UDP or DCCP) and Application
and Transport Protocols running over this transport layer. Examples and Transport Protocols running over this transport layer. Examples
of such protocols are RTP, RTCP, etc. As such, the data path of such protocols are RTP, RTCP, etc. As such, the data path
interface between the FEC Framework and both underlying and overlying interface between the FEC Framework and both underlying and overlying
layers can be thought of as being the same as the standard interface layers can be thought of as being the same as the standard interface
to the transport layer - i.e. the data exchanged consists of datagram to the transport layer - i.e. the data exchanged consists of datagram
payloads each associated with a single transport flow identified by payloads each associated with a single transport flow identified by
the standard 5-tuple { Source IP Address, Source Transport Port, the standard 5-tuple { Source IP Address, Source Transport Port,
Destination IP Address, Destination Transport Port, Transport Destination IP Address, Destination Transport Port, Transport
Protocol }. Protocol }.
The FEC Framework makes use of an FEC Scheme, in a similar sense to The FEC Framework makes use of an FEC Scheme, in a similar sense to
that defined in [3] and uses the terminology of that document. The that defined in [RFC5052] and uses the terminology of that document.
FEC Scheme provides FEC encoding and decoding and describes the The FEC Scheme provides FEC encoding and decoding and describes the
protocol fields and or procedures used to identify packet payload protocol fields and or procedures used to identify packet payload
data in the context of the FEC Scheme. The interface between the FEC data in the context of the FEC Scheme. The interface between the FEC
Framework and an FEC Scheme, which is described in this document, is Framework and an FEC Scheme, which is described in this document, is
a logical one, which exists for specification purposes only. At an a logical one, which exists for specification purposes only. At an
encoder, the FEC Framework passes groups of transport packet payloads encoder, the FEC Framework passes groups of transport packet payloads
to the FEC Scheme for FEC Encoding. The FEC Scheme returns FEC to the FEC Scheme for FEC Encoding. The FEC Scheme returns FEC
repair packet payloads, encoded FEC Payload ID information for each repair packet payloads, encoded FEC Payload ID information for each
of the repair packets and, in some cases, encoded FEC Payload ID of the repair packets and, in some cases, encoded FEC Payload ID
information for each of the source packets. At a decoder, the FEC information for each of the source packets. At a decoder, the FEC
Framework passes transport packet payloads (source and repair) to the Framework passes transport packet payloads (source and repair) to the
skipping to change at page 9, line 44 skipping to change at page 9, line 44
This document defines certain FEC Framework Configuration Information This document defines certain FEC Framework Configuration Information
which MUST be available to both sender and receiver(s). For example, which MUST be available to both sender and receiver(s). For example,
this information includes the specification of the transport flows this information includes the specification of the transport flows
which are to be FEC protected, specification of the transport flow(s) which are to be FEC protected, specification of the transport flow(s)
which will carry the FEC protection (repair) data and the which will carry the FEC protection (repair) data and the
relationship(s) between these 'source' and 'repair' flows (i.e. which relationship(s) between these 'source' and 'repair' flows (i.e. which
source flow(s) are protected by each repair flow. The FEC Framework source flow(s) are protected by each repair flow. The FEC Framework
Configuration Information also includes information fields which are Configuration Information also includes information fields which are
specific to the FEC Scheme. This information is analagous to the FEC specific to the FEC Scheme. This information is analagous to the FEC
Object Transmission Information defined in [3]. Object Transmission Information defined in [RFC5052].
The FEC Framework does not define how the FEC Framework Configuration The FEC Framework does not define how the FEC Framework Configuration
Information for the stream is communicated from sender to receiver. Information for the stream is communicated from sender to receiver.
This must be defined by any Content Delivery Protocol specification This must be defined by any Content Delivery Protocol specification
as described in the following sections. as described in the following sections.
In this architecture we assume that the interface to the transport In this architecture we assume that the interface to the transport
layer supports the concepts of payloads to be transported and layer supports the concepts of payloads to be transported and
identification transport flows on which those payloads are identification transport flows on which those payloads are
transported. Since this is an interface internal to the transported. Since this is an interface internal to the
skipping to change at page 12, line 5 skipping to change at page 11, line 51
| +--------------------------------------------+ | | +--------------------------------------------+ |
| | | |
| | IP | | | | IP | |
| | | |
| +--------------------------------------------+ | | +--------------------------------------------+ |
Content Delivery Protocol Content Delivery Protocol
+ - - - - - - - - - - - - - - - - - - - - - - - + + - - - - - - - - - - - - - - - - - - - - - - - +
Figure 1: FEC Framework Architecture Figure 1: FEC Framework Architecture
The contents of the transport payload for repair packets is fully
defined by the FEC Scheme. FEC Schemes MAY define a means for repair
data to be carried over RTP, in which case the repair packet payload
format starts with the RTP header. This specification provides
guidelines for the use of RTP for the repair flows in this manner,
however the explicit specification of this case is delegated to FEC
Schemes.
The use of RTP for repair packets is independent of the protocols
used for source packets: if RTP is used for source packets then
repair packets may or may not use RTP and vice versa (although it is
unlikely that there are useful scenarios where non-RTP source flows
are protected by RTP repair flows). FEC Schemes are expected to
recover entire transport payloads for recovered source packets in all
cases. For example if RTP is used for source flows, the FEC Scheme
is expected to recover the entire UDP payload, including the RTP
header.
Editor's note: An alternative possibility would be to define a
single RTP Payload Format (and associated MIME Type) for the
carriage of FEC repair data for any FEC Scheme. In this case, FEC
Scheme specifications need not mention RTP: the encapsulation of
repair payloads in RTP packets will be defined for all schemes by
a single RTP Payload Format specification.
5. Procedural overview 5. Procedural overview
5.1. General 5.1. General
The mechanism defined in this document does not place any The mechanism defined in this document does not place any
restrictions on the source transport payloads which can be protected restrictions on the source transport payloads which can be protected
together, except that the source transport payload is carried over a together, except that the source transport payload is carried over a
supported transport protocol (See Section 7). The data may be from supported transport protocol (See Section 7). The data may be from
multiple transport flows that are protected jointly. The FEC multiple transport flows that are protected jointly. The FEC
framework handles the packet flows as a sequence of 'source blocks' framework handles the packet flows as a sequence of 'source blocks'
skipping to change at page 19, line 44 skipping to change at page 20, line 44
and FEC Source Packet are identical. and FEC Source Packet are identical.
Since the addition of the Explicit Source FEC Payload ID increases Since the addition of the Explicit Source FEC Payload ID increases
the packet length, then in applications where avoidance of IP packet the packet length, then in applications where avoidance of IP packet
fragmentation is a goal, Content Delivery Protocols SHOULD consider fragmentation is a goal, Content Delivery Protocols SHOULD consider
the Explicit Source FEC Payload ID size when determining the size of the Explicit Source FEC Payload ID size when determining the size of
source transport payloads that will be delivered using the FEC source transport payloads that will be delivered using the FEC
Framework. Framework.
Note: The Explicit Source FEC Payload ID is placed at the end of the Note: The Explicit Source FEC Payload ID is placed at the end of the
packet so that in the case that Robust Header Compression [2] or packet so that in the case that Robust Header Compression [RFC3095]
other header compression mechanisms are used and in the case that a or other header compression mechanisms are used and in the case that
ROHC profile is defined for the protocol carried within the transport a ROHC profile is defined for the protocol carried within the
payload (for example RTP), then ROHC will still be applied for the transport payload (for example RTP), then ROHC will still be applied
FEC Source packets. Applications that may be used with this for the FEC Source packets. Applications that may be used with this
Framework should consider that FEC Schemes may add this Explicit Framework should consider that FEC Schemes may add this Explicit
Source FEC Payload ID and thereby increase the packet size. Source FEC Payload ID and thereby increase the packet size.
6.4. Packet Format for FEC Repair packets 6.4. Packet Format for FEC Repair packets
The packet format for FEC Repair packets is shown in Figure 5. The The packet format for FEC Repair packets is shown in Figure 5. 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.
+------------------------------------+ +------------------------------------+
skipping to change at page 20, line 28 skipping to change at page 21, line 28
| Repair Symbols | | Repair Symbols |
+------------------------------------+ +------------------------------------+
Figure 5: Packet format for repair packets Figure 5: Packet format for repair packets
The Repair FEC Payload ID field contains information required for the The Repair FEC Payload ID field contains information required for the
operation of the FEC algorithm at the receiver. This information is operation of the FEC algorithm at the receiver. This information is
defined by the FEC Scheme. The format of the Repair FEC Payload ID defined by the FEC Scheme. The format of the Repair FEC Payload ID
field is defined by the FEC Scheme. field is defined by the FEC Scheme.
6.4.1. Packet Format for FEC Repair packets over RTP (informative)
For FEC Schemes which specify the use of RTP for repair packets, the
packet format for repair packets includes an RTP header as shown in
Figure 6.
+------------------------------------+
| IP header |
+------------------------------------+
| Transport header (UDP) |
+------------------------------------+
| RTP Header |
+------------------------------------+
| Repair FEC Payload ID |
+------------------------------------+
| Repair Symbols |
+------------------------------------+
Figure 6: Packet format for repair packets
6.5. FEC Framework Configuration Information 6.5. FEC Framework Configuration Information
The FEC Framework Configuration Information is information that the The FEC Framework Configuration Information is information that the
FEC Framework needs in order to apply FEC protection to the transport FEC Framework needs in order to apply FEC protection to the transport
flows. A complete Content Delivery Protocol specification that uses flows. A complete Content Delivery Protocol specification that uses
the framework specified here MUST include details of how this the framework specified here MUST include details of how this
information is derived and communicated between sender and receiver. information is derived and communicated between sender and receiver.
The FEC Framework Configuration Information includes identification The FEC Framework Configuration Information includes identification
of a set of source packet flows. For example, in the case of UDP, of a set of source packet flows. For example, in the case of UDP,
skipping to change at page 22, line 6 skipping to change at page 23, line 32
repair packets as part of an FEC decoding operation. Integer flow repair packets as part of an FEC decoding operation. Integer flow
identifiers SHOULD be allocated starting from zero and increasing by identifiers SHOULD be allocated starting from zero and increasing by
one for each flow. one for each flow.
A single FEC repair flow provides repair packets for a single A single FEC repair flow provides repair packets for a single
instance of the FEC Framework. Other packets MUST NOT be sent within instance of the FEC Framework. Other packets MUST NOT be sent within
this flow i.e. all packets in the FEC repair flow MUST be FEC repair this flow i.e. all packets in the FEC repair flow MUST be FEC repair
packets as defined in Section 6.4 and MUST relate to the same FEC packets as defined in Section 6.4 and MUST relate to the same FEC
Framework instance. Framework instance.
In the case that RTP is used for repair packets, the identification
of the repair packet flow MAY also include the RTP Payload Type to be
used for repair packets.
6.6. FEC Scheme requirements 6.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 source transport capable of processing data arranged into blocks of source transport
packet payloads (source blocks). packet payloads (source blocks).
A specification for a new FEC scheme MUST include the following A specification for a new FEC scheme MUST include the following
things: things:
1. The FEC Encoding ID value that uniquely identifies the FEC 1. The FEC Encoding ID value that uniquely identifies the FEC
skipping to change at page 31, line 7 skipping to change at page 32, line 7
otherwise repair transport payload may be used by a receiver to otherwise repair transport payload may be used by a receiver to
decode unencrypted versions of source streams which they do not have decode unencrypted versions of source streams which they do not have
permissionions to view. permissionions to view.
10. IANA Considerations 10. IANA Considerations
tbd tbd
11. Acknowledgments 11. Acknowledgments
This document is based in large part on [4] and so thanks are due to This document is based in large part on [I-D.watson-tsvwg-fec-sf] and
the additional authors of that document, Mike Luby, Magnus Westerlund so thanks are due to the additional authors of that document, Mike
and Stephan Wenger. That document was in turn based on the FEC Luby, Magnus Westerlund and Stephan Wenger. That document was in
streaming protocol defined by 3GPP in [5] and thus thanks are also turn based on the FEC streaming protocol defined by 3GPP in [MBMSTS]
due to the participants in 3GPP TSG SA working group 4. and thus thanks are also due to the participants in 3GPP TSG SA
working group 4.
12. References 12. References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[2] 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, K., Liu, Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T., Le,
Z., Martensson, A., Miyazaki, A., Svanbro, K., Wiebke, T., K., Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K.,
Yoshimura, T., and H. Zheng, "RObust Header Compression (ROHC): Wiebke, T., Yoshimura, T., and H. Zheng, "RObust Header
Framework and four profiles: RTP, UDP, ESP, and uncompressed", Compression (ROHC): Framework and four profiles: RTP, UDP,
RFC 3095, July 2001. ESP, and uncompressed", RFC 3095, July 2001.
[3] Watson, M., Luby, M., and L. Vicisano, "Forward Error Correction [RFC5052] Watson, M., Luby, M., and L. Vicisano, "Forward Error
(FEC) Building Block", RFC 5052, August 2007. Correction (FEC) Building Block", RFC 5052, August 2007.
[4] Watson, M., "Forward Error Correction (FEC) Streaming [I-D.watson-tsvwg-fec-sf]
Framework", draft-watson-tsvwg-fec-sf-00 (work in progress), Watson, M., "Forward Error Correction (FEC) Streaming
July 2005. Framework", draft-watson-tsvwg-fec-sf-00 (work in
progress), July 2005.
[5] 3GPP, "Multimedia Broadcast/Multicast Service (MBMS); Protocols [MBMSTS] 3GPP, "Multimedia Broadcast/Multicast Service (MBMS);
and codecs", 3GPP TS 26.346, April 2005. Protocols and codecs", 3GPP TS 26.346, April 2005.
Author's Address Author's Address
Mark Watson Mark Watson
Digital Fountain Digital Fountain
39141 Civic Center Drive 39141 Civic Center Drive
Suite 300 Suite 300
Fremont, CA 94538 Fremont, CA 94538
U.S.A. U.S.A.
Email: mark@digitalfountain.com Email: mark@digitalfountain.com
Full Copyright Statement Full Copyright Statement
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
skipping to change at page 34, line 44 skipping to change at line 1120
attempt made to obtain a general license or permission for the use of attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
 End of changes. 22 change blocks. 
68 lines changed or deleted 117 lines changed or added

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