draft-ietf-fecframe-framework-07.txt   draft-ietf-fecframe-framework-08.txt 
FEC Framework Working Group M. Watson FEC Framework Working Group M. Watson
Internet-Draft Qualcomm, Inc. Internet-Draft Qualcomm, Inc.
Intended status: Standards Track March 5, 2010 Intended status: Standards Track June 1, 2010
Expires: September 6, 2010 Expires: December 3, 2010
Forward Error Correction (FEC) Framework Forward Error Correction (FEC) Framework
draft-ietf-fecframe-framework-07 draft-ietf-fecframe-framework-08
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 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
streaming media delivery or other packet flows. Content Delivery streaming media delivery or other packet flows. Content Delivery
Protocols defined using this framework can support any FEC Scheme Protocols defined using this framework can support any FEC Scheme
(and associated FEC codes) which is compliant with various (and associated FEC codes) which is compliant with various
requirements defined in this document. Thus, Content Delivery requirements defined in this document. Thus, Content Delivery
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.
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and 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). Note that other groups may also distribute
other groups may also distribute working documents as Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts. 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."
The list of current Internet-Drafts can be accessed at This Internet-Draft will expire on December 3, 2010.
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on September 6, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the BSD License. described in the Simplified BSD License.
This document may contain material from IETF Documents or IETF This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this 10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process. modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
skipping to change at page 6, line 35 skipping to change at page 6, line 35
and repair data flows - e.g. UDP, DCCP. and repair data flows - e.g. UDP, DCCP.
'Application Data Unit' The unit of source data provided as payload 'Application Data Unit' The unit of source data provided as payload
to the transport layer to the transport layer
'ADU Flow' A sequence of ADUs associated with a transport layer flow 'ADU Flow' A sequence of ADUs associated with a transport layer flow
identifier (such as the standard 5-tuple { Source IP Address, identifier (such as the standard 5-tuple { Source IP Address,
Source Transport Port, Destination IP Address, Destination Source Transport Port, Destination IP Address, Destination
Transport Port, Transport Protocol } in the case of UDP) Transport Port, Transport Protocol } in the case of UDP)
'Application protocol' Control protocols used to establish and 'Application protocol' Control protocol used to establish and
control the source data flow being protected - e.g. RTSP. control the source data flow being protected - e.g. RTSP.
'FEC Code' An algorithm for encoding data such that the encoded data 'FEC Code' An algorithm for encoding data such that the encoded data
flow is resiliant to data loss (Note: in general FEC Codes may flow is resiliant to data loss (Note: in general FEC Codes may
also be used to make a data flow resiliant to corruption, but that also be used to make a data flow resiliant to corruption, but that
is not considered here). is not considered here).
'FEC Scheme' A specification which defines the additional protocol 'FEC Scheme' A specification which defines the additional protocol
aspects required to use a particular FEC code with the FEC aspects required to use a particular FEC code with the FEC
Framework, or (in the context of RMT), with the RMT FEC Building Framework, or, in the context of RMT, with the RMT FEC Building
Block. Block.
'Source Block' A group of ADUs which are to be FEC protected as a
single block
'Protection amount' The relative increase in data sent due to the 'Protection amount' The relative increase in data sent due to the
use of FEC. use of FEC.
'FEC Framework Configuration Information' Information which controls 'FEC Framework Configuration Information' Information which controls
the operation of the FEC Framework. the operation of the FEC Framework.
'FEC Source Packet' At a sender (resp. receiver) a payload submitted 'FEC Source Packet' At a sender (resp. receiver) a payload submitted
to (resp. received from) the Transport protocol containing an ADU to (resp. received from) the Transport protocol containing an ADU
along with an optional Source FEC Payload ID. along with an optional Source FEC Payload ID.
skipping to change at page 7, line 37 skipping to change at page 7, line 34
repair packets. repair packets.
'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
The following definitions are aligned with [RFC5052] The following definitions are aligned with [RFC5052]
'Source symbol' unit of data used during the encoding process. 'Source symbol' unit of data used during the encoding process.
Encoding symbol: unit of data generated by the encoding process.
With systematic codes, source symbols are part of the encoding
symbols.
'Encoding symbol' unit of data generated by the encoding process. 'Encoding symbol' unit of data generated by the encoding process.
With systematic codes, source symbols are part of the encoding With systematic codes, source symbols are part of the encoding
symbols. symbols.
'Repair symbol' encoding symbol that is not a source symbol. 'Repair symbol' encoding symbol that is not a source symbol.
'Code rate' the k/n ratio, i.e., the ratio between the number of 'Code rate' the k/n ratio, i.e., the ratio between the number of
source symbols and the number of encoding symbols. By definition, source symbols and the number of encoding symbols. By definition,
the code rate is such that: 0 < code rate <= 1. A code rate close the code rate is such that: 0 < code rate <= 1. A code rate close
to 1 indicates that a small number of repair symbols have been to 1 indicates that a small number of repair symbols have been
produced during the encoding process. produced during the encoding process.
'Systematic code' FEC code in which the source symbols are part of 'Systematic code' FEC code in which the source symbols are part of
the encoding symbols. The Reed-Solomon codes introduced in this the encoding symbols. The Reed-Solomon codes introduced in this
document are systematic. document are systematic.
'Source Block' s group of ADUs which are to be FEC protected as a 'Source Block' group of ADUs which are to be FEC protected as a
single block. single block.
'Packet Erasure Channel' a communication path where packets are 'Packet Erasure Channel' a communication path where packets are
either dropped (e.g., by a congested router, or because the number either dropped (e.g., by a congested router, or because the number
of transmission errors exceeds the correction capabilities of the of transmission errors exceeds the correction capabilities of the
physical layer codes) or received. When a packet is received, it physical layer codes) or received. When a packet is received, it
is assumed that this packet is not corrupted. is assumed that this packet is not corrupted.
3. Requirements notation 3. Requirements notation
skipping to change at page 35, line 11 skipping to change at page 35, line 11
whenever the source packet flow bandwidth is adapted due to the whenever the source packet flow bandwidth is adapted due to the
operation of congestion control mechanisms, the FEC repair packet operation of congestion control mechanisms, the FEC repair packet
flow bandwidth MUST be similarly adapted. flow bandwidth MUST be similarly adapted.
10. Security Considerations 10. Security Considerations
The application of FEC protection to a stream does not provide any The application of FEC protection to a stream does not provide any
kind of security protection. kind of security protection.
If security services are required for the stream, then they MUST If security services are required for the stream, then they MUST
either be applied to the original source transport payload before FEC either be applied to the original source data before FEC protection
protection is applied, or to both the source and repair data, after is applied, or to both the source and repair data, after FEC
FEC protection has been applied. protection has been applied.
If integrity protection is applied to source packets before FEC If integrity protection is applied to source packets before FEC
protection is applied, and no further integrity protection is applied protection is applied, and no further integrity protection is applied
to repair packets, then a denial of service attack is possible if an to repair packets, then a denial of service attack is possible if an
attacker is in a position to inject fake repair transport payloads. attacker is in a position to inject fake repair transport payloads.
If received by a receiver, such fake repair transport payloads could If received by a receiver, such fake repair transport payloads could
cause incorrect FEC decoding resulting in incorrect source transport cause incorrect FEC decoding resulting in incorrect Application Data
payloads being passed up to the application protocol. Such incorrect Units being passed up to the application protocol. A similar attack
packets would then be detected by the source integrity protection and may be possible if an attacker is in a position to inject fack FEC
discarded, resulting in partial or complete denial of service. Framework Configuration Information or fake FEC Payload IDs. Such
Therefore, in such environments, integrity protection MUST also be incorrect decoded Application Data Units would then be detected by
applied to the FEC repair transport payloads, for example using the source integrity protection and discarded, resulting in partial
IPsec. Receivers MUST also verify the integrity of source transport or complete denial of service. Therefore, in such environments,
payloads before including the source transport payload into the integrity protection MUST also be applied to the FEC repair transport
source block for FEC purposes. payloads, FEC Framework Configuration Information and FEC Payload
IDs, for example using IPsec to integrity protect all packets.
Receivers MUST also verify the integrity of source symbols before
including the source symbols into the source block for FEC purposes.
It is possible that multiple streams with different confidentiality It is possible that multiple streams with different confidentiality
requirements (for example, the streams may be visible to different requirements (for example, the streams may be visible to different
sets of users) can be FEC protected by a single repair stream. This sets of users) can be FEC protected by a single repair stream. This
scenario is not recommended, since resources will be used to scenario is not recommended, since resources will be used to
distribute and decode data which cannot then be decrypted by at least distribute and decode data which cannot then be decrypted by at least
some receivers. However, in this scenario, confidentiality some receivers. However, in this scenario, confidentiality
protection MUST be applied before FEC encoding of the streams, protection MUST be applied before FEC encoding of the streams,
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
 End of changes. 13 change blocks. 
36 lines changed or deleted 27 lines changed or added

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