Transport Area Working Group M. Watson Internet-Draft M. Luby Expires: January 8, 2006 Digital Fountain M. Westerlund Ericsson S. Wenger Nokia July 7, 2005 Forward Error Correction (FEC) Streaming Framework draft-watson-tsvwg-fec-sf-00 Status of this Memo By submitting this Internet-Draft, each author represents that any 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 aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at 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 January 8, 2006. Copyright Notice Copyright (C) The Internet Society (2005). Abstract This document defines a framework for applying Forward Error Correction to UDP flows, primarily intended for streaming media. This framework can be used to define Content Delivery Protocols, in the context of the RMT FEC Building Block, that provide Forward Error Watson, et al. Expires January 8, 2006 [Page 1] Internet-Draft FEC Streaming Framework July 2005 Correction for streaming media delivery. Content Delivery Protocols defined using this framework can support FEC Schemes (and associated FEC codes) compliant with the FEC Building Block. Thus, Content Delivery Protocols can be defined which are not specific to a particular FEC Scheme. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Definitions/Abbreviations . . . . . . . . . . . . . . . . . . 5 3. Requirements notation . . . . . . . . . . . . . . . . . . . . 6 4. Architecture Overview . . . . . . . . . . . . . . . . . . . . 7 5. Procedural overview . . . . . . . . . . . . . . . . . . . . . 9 5.1 General . . . . . . . . . . . . . . . . . . . . . . . . . 9 5.2 Sender Operation . . . . . . . . . . . . . . . . . . . . . 11 5.3 Receiver Operation . . . . . . . . . . . . . . . . . . . . 12 6. Protocol Specification . . . . . . . . . . . . . . . . . . . . 13 6.1 General . . . . . . . . . . . . . . . . . . . . . . . . . 13 6.2 Structure of the source block . . . . . . . . . . . . . . 13 6.3 Packet format for FEC Source packets . . . . . . . . . . . 14 6.4 Packet Format for FEC Repair packets . . . . . . . . . . . 15 6.5 FEC Streaming Configuration Information . . . . . . . . . 16 6.6 FEC Scheme requirements . . . . . . . . . . . . . . . . . 17 7. Session Description Protocol elements . . . . . . . . . . . . 19 7.1 udp/fec/ transport protocol identifier . . . . . . 19 7.2 udp/fec transport protocol identifier . . . . . . . . . . 20 7.3 fec-declaration attribute . . . . . . . . . . . . . . . . 20 7.4 fec-oti-extension attribute . . . . . . . . . . . . . . . 20 7.5 fec attribute . . . . . . . . . . . . . . . . . . . . . . 20 7.6 FEC media grouping semantics . . . . . . . . . . . . . . . 20 7.7 SDP example . . . . . . . . . . . . . . . . . . . . . . . 20 8. Congestion Control . . . . . . . . . . . . . . . . . . . . . . 21 8.1 Normative requirements . . . . . . . . . . . . . . . . . . 22 9. Security Considerations . . . . . . . . . . . . . . . . . . . 24 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . 25 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 26 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 26 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 26 Intellectual Property and Copyright Statements . . . . . . . . 28 Watson, et al. Expires January 8, 2006 [Page 2] Internet-Draft FEC Streaming Framework July 2005 1. Introduction Many applications have a requirement to transport a continuous stream of packetised data from a source (sender) to one or more destinations (receivers) over networks which do not provide guaranteed packet delivery. Primary examples are media streaming applications such as broadcast, multicast or on-demand audio, video or multi-media. Forward Error Correction is a well-known technique for improving reliability of packet transmission over networks which do not provide guaranteed packet delivery, especially in multicast and broadcast applications. The FEC Building Block defined in [4] provides a framework for definition of Content Delivery Protocols (CDPs) which make use of separately defined FEC Schemes. Any CDP defined according to the requirements of this building block can then easily be used with any FEC Scheme which is also defined according to the requirements of the FEC building block (Note that it is also possible that CDPs define additional requirements on the FEC Scheme. Such CDPs can clearly only be used with FEC Schemes compliant with those requirements.) This document defines a framework for the definition of CDPs, in the sense of the FEC Building Block, which provide for FEC protection of streamed data flows over UDP. This document does not define a complete Content Delivery Protocol, but rather defines only those aspects that are expected to be common to all Content Delivery Protocols that support streaming data over UDP. The framework defined in this document is not specific to a single streaming application protocol. The framework provides FEC protection for application protocol flows over UDP and for combined protection of multiple such flows. For example, multiple RTP flows may be protected together with the associated RTCP flows and potentially also other related flows such as MIKEY packets. For many FEC Schemes in many loss conditions, the improvement in reliability achievable through the use of FEC with a given FEC overhead increases as the amount of data protected as a single block increases. Thus there is considerable advantage in the ability to protect multiple streams together, particularly in cases where the receiver requires all the streams in order to offer a useful service to the user. This framework does not define how the flows to be protected are determined, nor how the details of the protected flows and the FEC streams which protect them are communicated from sender to receiver. It is expected that any complete Content Delivery Protocol specification which makes use of this framework will address these signalling requirements. However, this document does specify the information which is required by the FEC Streaming Framework at Watson, et al. Expires January 8, 2006 [Page 3] Internet-Draft FEC Streaming Framework July 2005 sender and receiver - for example details of the flows to be FEC protected and the flow(s) that will carry the FEC protection data. We also specify SDP [5] attributes which a Content Delivery Protocol MAY use to communicate this information. Watson, et al. Expires January 8, 2006 [Page 4] Internet-Draft FEC Streaming Framework July 2005 2. Definitions/Abbreviations Source Block: A logical block of data constructed from some subset of the source packets of the application protocol flows to which the FEC protection is to be applied. FEC: Forward Error Correction. See [4]. Symbol: A unit of data processed by the Forward Error Correction code. A symbol is always considered as a unit i.e. it is either completely received or completely lost. Source symbol: A symbol of a source block. Repair symbol: A symbol containing information generated by the FEC code from a source block which can be used to recover lost source symbols from that source block. Encoding symbol: A source symbol or a repair symbol. Source Packet Information (SPI): Information related to or from a source packet which is included in the source block. FEC Streaming Configuration Information: Information which controls the operation of the FEC Streaming Framework. FEC Payload ID: See [4]. Source FEC Payload ID: An FEC Payload ID specifically for use with source packets. Repair FEC Payload ID: An FEC Payload ID specifically for use with repair packets. FEC Object Transmission Information: See [4]. FEC Encoding ID: See [4]. Content Delivery Protocol (CDP): See [4]. Watson, et al. Expires January 8, 2006 [Page 5] Internet-Draft FEC Streaming Framework July 2005 3. Requirements notation The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [1]. Watson, et al. Expires January 8, 2006 [Page 6] Internet-Draft FEC Streaming Framework July 2005 4. Architecture Overview The FEC Streaming Framework (FEC-SF) is defined as an additional protocol layer between UDP and Application and Transport Protocols running over UDP. Examples of such protocols are RTP, RTCP, etc. As such, the data path interface between the FEC-SF and both underlying and overlying layers can be thought of as being the same as the standard interface to UDP - i.e. the data exchanged consists of UDP datagram payloads each associated with a single UDP flow identified by the standard 5-tuple { Source IP Address, Source UDP Port, Destination IP Address, Destination UDP Port, Protocol }, where the Protocol field value in this case is UDP. The FEC-SF makes use of an FEC Scheme, in the sense of [4] and uses the terminology of that document. The FEC Scheme provides FEC encoding and decoding and describes the protocol fields used to identify packet payload data in the context of the FEC Scheme; i.e. it is the FEC Scheme specification, which MUST be defined according to [4], which defines the format and interpretation of the FEC Payload ID fields which are included in packets to identify the FEC source or repair symbol data which are carried by those packets. Alternatively, an FEC Scheme may define some other mechanism to identify the symbol data contained in a packet, in which case the FEC Payload ID fields described in the FEC Building Block and this specification may have zero length. The FEC Streaming Framework does not define how the FEC Object Transmission Information for the stream is communicated from sender to receiver. This must be defined by any Content Delivery Protocol specification according to the requirements of the FEC Building Block. However, this specification does define new Session Description Protocol (SDP) [5] elements which MAY be used by Content Delivery Protocols for this purpose. This document defines certain FEC Streaming Configuration Information which MUST be available to both sender and receiver(s). For example, this information includes the specification of the UDP flows which are to be FEC protected, specification of the UDP flow(s) which will carry the FEC protection (repair) data and the relationship(s) between these 'source' and 'repair' flows. The FEC Streaming Framework assumes that the Content Delivery Protocol includes appropriate signalling to communicate this FEC Streaming Configuration Information from sender to receiver(s). In many cases, Content Delivery Protocols may use SDP to communicate information about the UDP streams. This document defines suitable extensions to SDP which MAY be used to communicate the FEC Streaming Configuration Information from sender to receiver(s). Watson, et al. Expires January 8, 2006 [Page 7] Internet-Draft FEC Streaming Framework July 2005 The architecture outlined above is illustrated in the Figure 1. + - - - - - - -- - - - - - - - - - - - - - - - - + | | +--------------------------------------------+ | | | | | Application | | | | | +--------------------------------------------+ | +---------------------------------+ | | | Application/ | | | | Transport Protocol (e.g. RTP) | | | | | |-Configuration/Coordination | +---------------------------------+ | | ^ | | | UDP flows | | v v | +--------------------------------------------+ | +----------------+ | | | | | | FEC Streaming Framework (this document) |------| FEC Scheme | | | | | | +--------------------------------------------+ | +----------------+ ^ | | UDP flows | v | +--------------------------------------------+ | | | | | UDP | | | | +--------------------------------------------+ | +--------------------------------------------+ | | | | | IP | | | | | +--------------------------------------------+ | Content Delivery Protocol + - - - - - - - - - - - - - - - - - - - - - - - + Figure 1: FEC Streaming Framework Architecture Watson, et al. Expires January 8, 2006 [Page 8] Internet-Draft FEC Streaming Framework July 2005 5. Procedural overview 5.1 General The mechanism defined in this document consists of three components: (i) construction of a 'source block' from source media packets belonging to one or several UDP packet flows. The UDP flows MAY include, for example, RTP, RTCP and SRTP packets and also other protocols related to the stream such as MIKEY packets. (ii) extension of source packets to indicate the source block and the position within the source block occupied by the data from an related to the source packet. (iii) definition of repair packets, sent over UDP, which can be used by the FEC decoder to reconstruct missing portions of the source block. The mechanism does not place any restrictions on the source data which can be protected together, except that the source data is carried over UDP. The data may be from several different UDP flows that are protected jointly. In general, multiple source blocks will be constructed for a stream each constructed from different sets of source packets. For example, each source block may be constructed from those source packets related to a particular segment of the stream in time. A receiver supporting this streaming framework MUST support the packet format for FEC Source packets and MAY also support the packet format for FEC Repair packets. This document does not define how the sender determines which source packets are included in which source blocks. A specific Content Delivery Protocol MAY define this mapping or it MAY be left as implementation dependent at the sender. However, a CDP specification MUST define how a receiver determines the length of time it should wait to receive FEC repair packets for any given source block. At the sender, the mechanism processes original UDP packets to create: (i) a stored copy of the original packets in the form of one or more 'source block(s)'. The source block is a logical block of data to which the the FEC code will subsequently be applied. It is constructed by concatenating 'Source Packet Information' (SPI) for each source packet. The SPI for a packet contains a short identifier for the flow the packet belongs to, the length of the Watson, et al. Expires January 8, 2006 [Page 9] Internet-Draft FEC Streaming Framework July 2005 packet, the UDP payload and possible padding bytes. (ii) FEC Source packets for transmission to the receiver. The FEC Streaming Framework uses the FEC encoder specified by the FEC Scheme in use to generate the desired quantity of repair symbols from a source block. These repair symbols are then sent using the FEC repair packet format to the receiver. The FEC Repair packets are sent to a UDP destination port different from any of the original UDP packets' destination port(s) as indicated by the FEC Streaming Configuation Information. The receiver recovers original source packets directly from any FEC Source packets received. The receiver also uses the received FEC Source Packets to construct a stored copy of the original packets in the same source block format as constructed at the sender. If any FEC Source packets related to a given source block have been lost, then this copy of the source block at the receiver will be incomplete. If sufficient FEC source and FEC Repair packets related to that source block have been received, the FEC Framework may use the FEC decoding algorithm defined by the FEC Scheme to recover a (hopefully, but not necessarily, complete) copy of the source block. The SPI for the missing source packets can then be extracted from the completed parts of the source block and used to reconstruct the source packets to be passed to the application. Note that the receiver may need to buffer received source packets to allow time for the FEC Repair packets to arrive and FEC decoding to be performed before some or all of the received or recovered packets are passed to the application. If such a buffer is not provided, then the application must be able to deal with the severe re-ordering of packets that will be required. However, such buffering is Content Delivery Protocol and/or implementation-specific and is not specified here. The FEC Source packets MUST contain information which identifies the source block and the position within the source block occupied by the SPI derived from the packet. The identity of the source block and the position within the source block occupied by the SPI for a source packet are together known as the 'Source FEC Payload ID'. This information MAY be encoded into a specific field within the FEC Source packet format defined in this specification, called the Source FEC Payload ID field. The exact contents and format of the Source FEC Payload ID field are defined by the FEC Scheme. Alternatively, the FEC Scheme or CDP MAY define how the Source FEC Payload ID is derived from other fields within the source packets. This document defines the way that the Source FEC Payload ID field is appended to Watson, et al. Expires January 8, 2006 [Page 10] Internet-Draft FEC Streaming Framework July 2005 source packets to form FEC Source packets. The FEC Repair packets MUST contain information which identifies the source block and the relationship between the contained repair data and the original source block. This is known as the 'Repair FEC Payload ID'. This information MUST be encoded into a specific field, the Repair FEC Payload ID field, the contents and format of which are defined by the FEC Scheme. Any FEC Schemes to be used in conjunction with this specification MUST be a systematic FEC Scheme and MUST be based on source blocks. The FEC Scheme MAY use different FEC Payload ID field formats for FEC Source packets and FEC Repair packets. 5.2 Sender Operation It is assumed that the sender has constructed or received original data packets for the session. These may be RTP, RTCP, MIKEY or other UDP packets. The following operations describe a possible way to generate compliant FEC Source packet and FEC repair packet streams: 1. A source block is constructed as specified in Section 6.2, by concatenating the SPI for each original source packet. In doing so, the Source FEC Payload ID information of the FEC Source packet can be determined and included in the Source FEC Payload ID field, if defined. In the SPI the identity of the packet's UDP flow is marked using a short 'UDP flow ID', defined in this specification. The association of UDP flow specifications to UDP flow IDs is defined by the FEC Streaming Configuation Information. 2. The FEC Source packet is constructed according to Section 6.3. The identity of the original flow is maintained by the source packet through the use of the same UDP ports and IP addresses which have been advertised by the Content Delivery Protocol (for example using SDP), as carrying FEC Source packets generated from an original stream of a particular protocol (e.g. RTP, RTCP, SRTP, MIKEY etc.). The FEC Source packet generated is sent according to normal UDP procedures. 3. The FEC encoder generates repair symbols from a source block and the FEC Streaming Framework places these symbols into FEC Repair packets, to be conveyed to the receiver(s). These repair packets are sent using normal UDP procedures to a unique destination port to separate them from any of the source packet flows. The ports to be used for FEC Repair packets are defined in the FEC Streaming Configuration Information. Watson, et al. Expires January 8, 2006 [Page 11] Internet-Draft FEC Streaming Framework July 2005 5.3 Receiver Operation The following describes a possible receiver algorithm, when receiving an FEC source or repair packet: 1. If an FEC Source packet is received (as indicated by the UDP flow on which was received): a. The original source packet is reconstructed by removing the Source FEC Payload ID. The resulting packet MAY be buffered to allow time for the FEC repair. b. The SPI for the resulting packet is placed into the source block according to the Source FEC Payload ID and the source block format described in Section 6.2. The IP addresses and UDP ports the packet was received on/sent from are used to determine the UDP flow ID within the SPI. 2. If an FEC repair packet is received (as indicated by the UDP flow on which it was received), the contained repair symbols are associated with a source block according to the Repair FEC Payload ID. 3. If at least one source packet is missing and at least one repair packet has been received for a source block then FEC decoding may be desirable. The FEC decoder determines if the source block constructed in step 1 plus the associated repair symbols received in step 2 contain enough symbols for decoding of any or all of the missing source symbols in the source block and, if so, performs a decoding operation. 4. Any SPI that was reconstructed during the decoding operation is then used to reconstruct the missing source packets and these are buffered as normal received source packets (see step 1a above). Note that the above procedure may result in a situation in which not all original source packets are recovered. Source packets which are correctly received and those which are reconstructed MAY be delivered to the application out of order and in a different order from the order of arrival at the receiver. Alternatively, buffering and packet re-ordering MAY be required to re-order received and reconstructed source packets into the order they were placed into the source block, if that is necessary according to the application. Watson, et al. Expires January 8, 2006 [Page 12] Internet-Draft FEC Streaming Framework July 2005 6. Protocol Specification 6.1 General This section specifies the protocol elements for the FEC Streaming Framework. The protocol consists of three components which are described in the following sections: 1. Construction of a source block from source packets. The FEC code will be applied to this source block to produce the repair data. 2. A format for packets containing source data. 3. A format for packets containing repair data. The operation of the FEC Streaming Framework is governed by certain FEC Streaming Configuation Information. This configuration information is also defined in this section. A complete protocol specification that uses this framework MUST specify the means to determine and communicate this information between sender and receiver. Suitable Session Description Protocol elements for this purpose are defined in Section 7. 6.2 Structure of the source block This clause defines the layout of the source block. The source block consists of concatenation of SPI for at least one original source UDP packet. Let n be the number of UDP packets in the source block. n MAY be determined dynamically during the source block construction process. T be the source symbol size in bytes. Note: this information is provided by the FEC Scheme as defined in Section 6.6. R[i] denote the octets of the UDP payload of the i-th UDP packet to be added to the source block, 0 <= i < n. l[i] be the length of R[i] in octets L[i] denote two octets representing the value of l[i] in network byte order (high order octet first) Watson, et al. Expires January 8, 2006 [Page 13] Internet-Draft FEC Streaming Framework July 2005 f[i] denote an integer 'UDP flow ID' identifying the UDP flow from which the i-th packet was taken F[i] denote a single octet representing the value of f[i] s[i] be the smallest integer such that s[i]*T >= (l[i]+3). Note s[i] is the length of SPI[i] in units of symbols. P[i] denote s[i]*T-(l[i]+3) zero octets. Note: P[i] are padding octets to align the start of each UDP packet with the start of a symbol. SPI[i] be the concatenation of F[i] ,L[i], R[i] and P[i]. Then, the source block is constructed by concatenating SPI[i] for i = 0, 2, ... n-1. The source block size, S, is then given by sum {s[i]*T, i=0, ..., n-1}. Source blocks are identified by integer Source Block Numbers and symbols within a source block by integer Encoding Symbol IDs. This specification does not specify how Source Block Numbers are allocated to source blocks. Symbols are numbered consecutively starting from zero within the source block. Each source packet is associated with the Encoding Symbol ID of the first symbol containing SPI for that packet. Thus, the Encoding Symbol ID value associated with the j-th source packet, ESI[j], is given by ESI[j] = 0, for j=0 ESI[j] = sum{s[i], i=0,...,(j-1)}, for 0 < j < n A UDP flow is uniquely defined by an IP source and destination address and UDP source and destination port values. The assignment of UDP flow ID values to UDP flows is part of the FEC Streaming Configuration Information. 6.3 Packet format for FEC Source packets The packet format for FEC Source packets MUST be used to transport the payload of an original source UDP packet. As depicted in Figure 2, it consists of the original UDP packet, followed by the Source FEC Payload ID field. Watson, et al. Expires January 8, 2006 [Page 14] Internet-Draft FEC Streaming Framework July 2005 +------------------------------------+ | IP header | +------------------------------------+ | UDP header | +------------------------------------+ | Original UDP Payload | +------------------------------------+ | Source FEC Payload ID | +------------------------------------+ Figure 2: Structure of the FEC packet format for FEC Source packets The IP and UDP header fields MUST be identical to those of the original source packet. The Original UDP Payload field MUST be identical to the UDP payload of the original source packet. The UDP payload of the FEC Source packet MUST consist of the Original UDP Payload followed by the Source FEC Payload ID field. The Source FEC Payload ID field contains information required for the operation of the FEC algorithm and defined by the FEC Scheme. The format of the Source FEC Payload ID field is defined by the FEC Scheme. Note that in the case that the FEC Scheme or CDP defines a means to derive the Source FEC Payload ID from other information in the packet (for example the RTP Sequence number), then the Source FEC Payload ID field described here may have zero length. Note: The Source FEC Payload ID is placed at the end of the packet so that in the case that Robust Header Compression [3] or other header compression mechanisms are used and in the case that a ROHC profile is defined for the protocol carried within the UDP payload (for example RTP), then ROHC will still be applied for the FEC Source packets. 6.4 Packet Format for FEC Repair packets The packet format for FEC Repair packets is shown in Figure 3. The UDP payload consists of a Repair FEC Payload ID field and one or more repair symbols generated by the FEC encoding process. Watson, et al. Expires January 8, 2006 [Page 15] Internet-Draft FEC Streaming Framework July 2005 +------------------------------------+ | IP header | +------------------------------------+ | UDP header | +------------------------------------+ | Repair FEC Payload ID | +------------------------------------+ | Repair Symbols | +------------------------------------+ Figure 3: Packet format for repair packets The Repair FEC Payload ID field contains information required for the operation of the FEC algorithm. This information is defined by the FEC Scheme. The format of the Repair FEC Payload ID field is defined by the FEC Scheme. Any number of whole repair symbols may be contained within an FEC Repair packet, subject to packet size restrictions or other restrictions defined by the FEC Scheme. The number of repair symbols within a packet can be determined from the symbol length and the packet length. Partial repair symbols MUST NOT be included in FEC repair packets. 6.5 FEC Streaming Configuration Information The FEC Streaming Configuration Information is information that the FEC Streaming Framework needs in order to apply FEC protection to the UDP flows. A complete Content Delivery Protocol specification for streaming that uses the framework specified here MUST include details of how this information is derived and communicated between sender and receiver. The FEC Streaming Configuration Information includes identification of a number of UDP packet flows. Each UDP packet flow is uniquely identified by a tuple { Source IP Address, Destination IP Address, Source UDP port, Destination UDP port }. A single instance of the FEC-SF provides FEC protection for all packets of a specified set of source UDP packet flows, by means of one or more UDP packet flows containing repair packets. The FEC Streaming Configuation Information includes, for each instance of the FEC-SF: 1. Identification of the UDP packet flow(s) carrying FEC Repair packets, known as the FEC repair flow(s). Watson, et al. Expires January 8, 2006 [Page 16] Internet-Draft FEC Streaming Framework July 2005 2. For each source UDP packet flow protected by the FEC repair flow(s): a. Identification of the UDP packet flow carrying source packets. b. An integer identifier, between 0 and 255, for this flow. This identifier MUST be unique amongst all source UDP packet flows which are protected by the same FEC repair flow. 3. The FEC Encoding ID, FEC Instance ID (if applicable) and, optionally, the symbol size. Item (3) above is included in the FEC Object Transmission Information. Multiple instances of the FEC-SF, with separate and independent FEC Streaming Configuration Information, may be present at a sender or receiver. A single instance of the FEC-SF protects all packets of all the source UDP packet flows identified in (2) above i.e. all packets on those flows MUST be FEC Source packets as defined in Section 6.3. A single source UDP packet flow MUST NOT be protected by more than one FEC-SF instance. A single FEC repair flow provides repair packets for a single instance of the FEC-SF. Other packets MUST NOT be sent within 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-SF instance. The FEC-SF requires to be informed of the symbol size to be used for each source block. This information MAY be included in the FEC Streaming Configuration Information or it MAY be communicated by other means, for example within the FEC Repair Payload ID field. A complete Content Delivery Protocol specification MUST specify how this information is communicated between sender and receiver. 6.6 FEC Scheme requirements In order to be used with this framework, an FEC Scheme MUST: - adhere to the requirements of [4] - be systematic - be based on discrete source blocks Watson, et al. Expires January 8, 2006 [Page 17] Internet-Draft FEC Streaming Framework July 2005 - specify how the Source Block Number and Encoding Symbol ID associated with a source packet are derived or communicated from sender to receiver (for example, within the Source FEC Payload ID field) - specify how the symbol length is derived or communicated from sender to receiver (for example, as part of the FEC Object Transmission Information). Watson, et al. Expires January 8, 2006 [Page 18] Internet-Draft FEC Streaming Framework July 2005 7. Session Description Protocol elements This section defines Session Descrption Protocol elements which MAY be used by Content Delivery Protocols that make use of this framework to communicate the FEC Streaming Configuration Information. NOTE: It is for further discussion whether these SDP elements should be defined here or in the context of a specific and complete Content Delivery Protocol specification for streaming. This specification defines a class of new Transport Protocol identifiers for use in SDP media descriptions. For all existing identifiers this specification defines the identifier 'udp/ fec/'. This identifier may be used as the Transport Protocol identifier for a media description for source data to indicate that the FEC Source packet format defined in Section 6.3 is used, with the original UDP payload field formated according to . Note that in the case of an FEC Scheme in which the Source FEC Payload ID has zero length, then the original Transport Protocol identifier MAY be used to support interoperability with devices which do not support the FEC Source packet format at all, whilst also providing FEC protection for those devices which support it. A further Transport Protocol identifier, 'udp/fec', is defined to indicate the the FEC Repair Packet format defined in Section 6.4. This specification describes the use of SDP attributes defined in [6] and the FEC grouping semantics defined in [7] to provide the FEC Streaming Configuration Information. The 'fec-declaration' attribute may be used at either the session or media layer to declare a local identifier for a set of FEC parameters. This local identifier can then be referenced in the other attributes. This avoids duplication of parameter declarations within the SDP. The 'fec' parameter is used on the media level to associate a media description with a previous FEC parameter declaration. Finally, the 'FEC' grouping attribute semantics is used to associate together source and repair flows and assign UDP flow identifiers to be used in the source block construction. Mechanisms for communicating the corresponance between source flows and the UDP Flow Identifiers that are included within the source block require further discussion. 7.1 udp/fec/ transport protocol identifier tbc Watson, et al. Expires January 8, 2006 [Page 19] Internet-Draft FEC Streaming Framework July 2005 7.2 udp/fec transport protocol identifier tbc 7.3 fec-declaration attribute See [6]. 7.4 fec-oti-extension attribute See [6]. 7.5 fec attribute See [6]. 7.6 FEC media grouping semantics This attribute is used to group source flows and the single repair flow that protects them as described in [7] with the following additional requirements: The media components grouped by an instance of the FEC grouping attribute MUST include exactly one component with the udp/fec protocol identifier. The media components grouped by an instance of the FEC grouping attribute MUST include at least one and MAY include more than one source media stream with protocol identifier udp/fec/, where is a valid protocol identifier registered with IANA. In the case of an FEC Scheme which defines an FEC Payload ID field of zero length, then the media components grouped by an instance of the FEC grouping attribite MAY include source media streams with protocol identified udp/, where is a valid protocol identifier registered with IANA. 7.7 SDP example tbc Watson, et al. Expires January 8, 2006 [Page 20] Internet-Draft FEC Streaming Framework July 2005 8. Congestion Control This section starts with a informative section on the motivation of the normative requirements for congestion control, which are spelled out in Section 8.1. Informative Note: The enforcement of Congestion Control (CC) principles has gained a lot of momentum in the IETF over the recent years. While the need of CC over the open Internet is unquestioned, and the goal of TCP friendliness is generally agreed for most (but not all) applications, the subject of congestion detection and measurement in heterogenous networks can hardly be considered as solved. Most congestion control algorithms detect and measure congestion by taking (primarily or exclusively) the packet loss rate into account. This appears to be inappropriate in environments where a large percentage of the packet losses are the result link-layer errors and independent of the network load. Note that such environments exist in the "open Internet", as well as in "closed" IP based networks. An example for the former would be the use of IP/UDP/RTP based streaming from an Internet- connected streaming server to a device attached to the Internet using cellular technology. The authors of this draft are primarily interested in applications where the application reliability requirements and end-to-end reliability of the network differ, such that it warrants higher layer protection of the packet stream - for example due to the presence of unreliable links in the end-to-end path - and where real-time or other constraints prohibit the use of higher layer (transport or application) feedback. A typical example for such applications is multicast and broadcast streaming to wireless devices or multimedia transmission over heterogenous, but partly wireless networks. In other cases, application reliability requirements may be so high that the required end-to-end reliability is difficult to achieve even over wired networks. Furthermore the end-to-end network reliability may not be known in advance. This FEC framework is not proposed, nor intended, as a QoS enhancement tool to combat losses resulting from highly congested networks. It should not be used for such purposes. In order to prevent such mis-use, standardization could be left to bodies most concerned with the problem described above. However, the IETF defines base standards used by several bodies, including DVB-H, 3GPP, 3GPP2, all of which appear to share the environment and the problem described. Watson, et al. Expires January 8, 2006 [Page 21] Internet-Draft FEC Streaming Framework July 2005 Alternatively, a clear applicability statement could be used - for example restricting use of the framework to networks with wireless links. However, there may be applications where the use of FEC may be justified to combat congestion-induced packet losses - particularly in lightly loaded networks, where congestion is the result of relatively rare random peaks in instantaneous traffic load - thereby intentionally violating congestion control principles. One possible example for such an application could be a no-matter-what, brute-force FEC protection of traffic generated as an emergency signal. We propose a third approach, which is to require at a minimum that the use of this framework with any given application, in any given environment, does not cause congestion issues which the application alone would not itself cause i.e. the use of this framework must not make things worse. Taking above considerations into account, the normative text of this section implements a small set of constraints for the FEC, which are mandatory for all senders compliant with this FEC framework. Further restrictions may be imposed for certain Content Delivery Protocols. In this it follows the spirit of the congestion control section of RTP and its Audio-Visual Profile (RFC3550/STD64 and RFC3551/STD65). One of the constraints effectively limits the bandwidth for the FEC protected packet stream to be no more than roughly twice as high as the original, non-FEC protected packet stream. This disallows the (static or dynamic) use of excessively strong FEC to combat high packet loss rates, which may otherwise be chosen by naively implemented dynamic FEC-strength selection mechanisms. We acknowledge that there may be a few exotic applications, e.g. IP traffic from space-based senders, or senders in certain hardened military devices, which would warrant a higher FEC strength. However, in this specification we give preference to the overall stability and network friendliness of the average application, and for those a factor of 2 appears to be appropriate. A second constraint requires that the FEC protected packet stream be in compliance with the congestion control in use for the application and network in question. 8.1 Normative requirements The bandwidth of FEC Repair packet flows MUST NOT exceed the bandwidth of the source packet flows being protected. In addition, whenever the source packet flow bandwidth is adapted due to the Watson, et al. Expires January 8, 2006 [Page 22] Internet-Draft FEC Streaming Framework July 2005 operation of congestion control mechanisms, the FEC repair packet flow bandwidth MUST be similarly adapted. Watson, et al. Expires January 8, 2006 [Page 23] Internet-Draft FEC Streaming Framework July 2005 9. Security Considerations The application of FEC protection to a stream does not provide any kind of security protection. If security services are required for the stream, then they MUST either be applied to the original source data before FEC protection is applied, or to both the source and repair data, after FEC protection has been applied. If integrity protection is applied to source packets before FEC protection is applied, and no further integrity protection is applied to repair packets, then a denial of service attack is possible if an attacker is in a position to inject fake repair packets. If received by a receiver, such fake repair packets could cause incorrect FEC decoding resulting in incorrect source packets being passed up to the application protocol. Such incorrect packets would then be detected by the source integrity protection and discarded, resulting in partial or complete denial of service. Therefore, in such environments, integrity protection MUST also be applied to the FEC Repair packets, for example using IPsec. Receivers MUST also verify the integrity of source packets before including the source data into the source block for FEC purposes. It is possible that multiple streams with different confidentiality requirements (for example, the streams may be visible to different sets of users) can be FEC protected by a single repair stream. This scenario is not recommended, since resources will be used to distribute and decode data which cannot then be decrypted by at least some receivers. However, in this scenario, confidentiality protection MUST be applied before FEC encoding of the streams, otherwise repair data may be used by a receiver to decode unencrypted versions of source streams which they do not have permissionions to view. Watson, et al. Expires January 8, 2006 [Page 24] Internet-Draft FEC Streaming Framework July 2005 10. IANA Considerations tbc Watson, et al. Expires January 8, 2006 [Page 25] Internet-Draft FEC Streaming Framework July 2005 11. Acknowledgments This framework is based in large part on the FEC streaming protocol defined by 3GPP in [8] and thus thanks are due to the participants in 3GPP TSG SA working group 4. 12. References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997. [3] Bormann, C., Burmeister, C., Degermark, M., Fukushima, H., Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T., Le, K., Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K., Wiebke, T., Yoshimura, T., and H. Zheng, "RObust Header Compression (ROHC): Framework and four profiles: RTP, UDP, ESP, and uncompressed", RFC 3095, July 2001. [4] Watson, M., "Forward Error Correction (FEC) Building Block", draft-ietf-rmt-fec-bb-revised-00 (work in progress), May 2005. [5] Handley, M., "SDP: Session Description Protocol", draft-ietf-mmusic-sdp-new-24 (work in progress), February 2005. [6] Mehta, H., "SDP Descriptors for FLUTE", draft-mehta-rmt-flute-sdp-03 (work in progress), July 2005. [7] Li, A., "FEC Grouping Semantics in SDP", draft-li-mmusic-fec-grouping-00 (work in progress), June 2005. [8] 3GPP, "Multimedia Broadcast/Multicast Service (MBMS); Protocols and codecs", 3GPP TS 26.346 6.1.0, April 2005. Authors' Addresses Mark Watson Digital Fountain 39141 Civic Center Drive Suite 300 Fremont, CA 94538 U.S.A. Email: mark@digitalfountain.com Watson, et al. Expires January 8, 2006 [Page 26] Internet-Draft FEC Streaming Framework July 2005 Michael Luby Digital Fountain 39141 Civic Center Drive Suite 300 Fremont, CA 94538 U.S.A. Email: luby@digitalfountain.com Magnus Westerlund Ericsson Ericsson Research SE-164 80 Stockholm SWEDEN Email: magnus.westerlund@ericsson.com Stephan Wenger Nokia Email: Stephan.Wenger@nokia.com Watson, et al. Expires January 8, 2006 [Page 27] Internet-Draft FEC Streaming Framework July 2005 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Watson, et al. Expires January 8, 2006 [Page 28]