FEC Framework B. Chen Internet Draft Huawei Technologies Co., Ltd. Intended status: Standard Track Z. Zou Expires: April 23, 2010 Huawei Technologies Co., Ltd. October 23, 2009 Source FEC payload Mapping Information for sequence flow draft-zixuan-fecframe-source-mi-01.txt Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. This document may not be modified, and derivative works of it may not be created, and it may not be published except as an Internet-Draft. This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. This document may not be modified, and derivative works of it may not be created, except to publish it as an RFC and to translate it into languages other than English. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. 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." ZiXuan Expires April 23, 2010 [Page 1] Internet-Draft source FEC payload MI October 2009 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 April 23, 2010. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Abstract Per FEC Framework, FEC source packet carries source FEC payload ID for FEC protection of arbitrary packet flow. Source FEC payload ID will contain information identifying the source block and the position within the source block. However, in order to maintain backwards compatibility, this document enables the receiver to get this information without appending source FEC payload ID. This information is obtained using the combination of information provided in the FEC payload header and source FEC payload mapping information unit (MIU). Therefore, both non-FEC- capable and FEC-capable receivers can work together in a multicast session. Two ways to signal the source block structure are defined, one for general procedure and anther for systematic procedure that the order of the packets in the source block is deterministic. Table of Contents 1. Introduction ................................................ 4 2. Conventions used in this document ........................... 4 3. General procedures for structure of the source block ........ 5 3.1. Introduction ........................................... 5 3.2. Source block creation and example ...................... 5 3.3. Packet format for repair packet ........................ 6 3.4. Packet format for Source FEC payload MIU ............... 6 3.5. FEC payload header format .............................. 7 3.6. The source FEC payload MIU format ...................... 8 4. Systematic procedures for structure of the source block ..... 9 ZiXuan Expires April 23, 2010 [Page 2] Internet-Draft source FEC payload MI October 2009 4.1. Introduction ........................................... 9 4.2. Source block creation and example ...................... 10 4.3. Packet format for repair packet ........................ 11 4.4. FEC payload header format .............................. 12 4.5. The source FEC payload MIU format ...................... 12 5. Session Description Protocol (SDP) signaling ................ 13 6. Security Considerations ..................................... 13 7. Normative References ........................................ 13 8. Acknowledgments ............................................. 14 Authors' Addresses ............................................. 14 ZiXuan Expires April 23, 2010 [Page 3] Internet-Draft source FEC payload MI October 2009 1. Introduction This document specifies a new FEC payload header and a source FEC payload mapping information unit (MIU) for the FEC backwards compatibility. FEC Framework [I-D.ietf-fecframe-framework] defines packet format for FEC source packet and FEC repair packet. Per FEC framework, FEC source packet carries generic explicit FEC payload ID for FEC protection of arbitrary packet flow. A FEC-Framework-incompatible client would fail to understand the source packet with FEC payload ID included. FEC Framework describes a non-FEC Framework-compatible case where FEC payload is not included in source packet, because FEC payload ID can be derived from other information (e.g. sequence number of some kind used by application protocol) from source packet. However, in order to maintain backwards compatibility, the format defined by this document enables the receiver to get this information without appending source FEC payload ID. This information is obtained using the combination of information provided in the FEC payload header and source FEC payload mapping information unit (MIU). Therefore, both non-FEC-capable and FEC-capable receivers can work together in a multicast session. The operation of the FEC mechanism requires that the receiver can get information identifying the source block and the position within the source block. The information is dependent on the source block structure, there are different ways to signal the source block structure. If the source block is deterministic, this case is referred to as a ''systematic''. In this case the MIU can be predigested and transmitted in the repair flow. Otherwise, the source block is not deterministic. This case is referred to as the ''general''. In this case, MIU is carried in separate packet flow, the FEC payload header is used to enable transmit MIU in separate flow and also to carry FEC repair flow. Accordingly, this document defines two FEC schemes, one for the case of a systematic structure of source block and anther for the case of general structure of source block. 2. Conventions used in this document 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 [RFC-2119]. ZiXuan Expires April 23, 2010 [Page 4] Internet-Draft source FEC payload MI October 2009 3. General procedures for structure of the source block 3.1. Introduction This section specifies a general way to create the source block. As described in [I-D.ietf-fecframe-framework], a source block is generated by the FEC Framework from an ordered sequence of Application Data Units. The allocation of Application Data Units to blocks is dependent on application. This scheme is the same as that specified in [3GPP MBMS Specification]. This scheme specifies a FEC payload header and a source FEC payload mapping information unit (MIU) in separate packet flow. 3.2. Source block creation and example The following steps are provided. 1. For the packet placed into the source block create a byte array as follows: a) The value of the packet flow identifier, followed by the value of the packet size, are first written as single byte and two- byte value in network byte order respectively into the first available bytes in the source block b) Append the entire packet including its application header c) If the next available byte is not the first byte of a new symbol, then padding bytes up to the next symbol boundary 2. Append any packets one after the other in the following way: a) The procedure is repeated starting each packet flow identifier at the start of the next symbol b) The allocation of Packets to source block is dependent on application An example of forming a source block is given in figure blow. In this example, three packets of size 26, 42 and 10, which taken from flow 0 and flow 1, have been placed into a source block. ZiXuan Expires April 23, 2010 [Page 5] Internet-Draft source FEC payload MI October 2009 +---Source Block --+ +------------------+ |0|26|xxxxxxxxxxxxx| +------------------+ |x xx xxxxxxxxxx000| +------------------+ |1|42|xxxxxxxxxxxxx| +------------------+ |x xx xxxxxxxxxxxxx| +------------------+ |x xx xxxxxxxxxx000| +------------------+ |0|10|xxxxxxxxxx000| +------------------+ Figure 1 Structure of a Source Block 3.3. Packet format for repair packet The packet format for FEC repair packet is shown in Figure 2. The transport payload consists of Application Protocol header, FEC payload header and FEC repair packet. +------------------------------------+ | IP header | +------------------------------------+ | Transport header | +------------------------------------+ | Application Protocol header | +------------------------------------+ | FEC payload header | +------------------------------------+ | Repair FEC payload ID | +------------------------------------+ | FEC repair data | +------------------------------------+ Figure 2 Packet Format for FEC repair packet 3.4. Packet format for Source FEC payload MIU The packet format for source FEC payload MIU is shown in Figure 3. The transport payload consists of Application Protocol header, FEC payload header and source FEC payload MIU(s). ZiXuan Expires April 23, 2010 [Page 6] Internet-Draft source FEC payload MI October 2009 +------------------------------------+ | IP header | +------------------------------------+ | Transport header | +------------------------------------+ | Application Protocol header | +------------------------------------+ | FEC payload header | +------------------------------------+ | Source FEC payload MIU 1 | +------------------------------------+ | Source FEC payload MIU 2 | +------------------------------------+ | ......... | +------------------------------------+ | Source FEC payload MIU N | +------------------------------------+ Figure 3 Packet format for source FEC payload MIU 3.5. FEC payload header format The FEC payload header format is shown in Figure 4. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | fec_id | PT | Num flows | reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4 FEC payload header format o fec_id (8 bits): This field identifies the FEC scheme used for FEC protection. The FEC scheme identified by this field determines the content of source FEC payload ID and FEC repair packet carried by FEC payload. o PT (8 bits): PT (Payload Type) field indicates the FEC payload type. If PT is set to 1, it indicates that MIU is carried in the separate flow and the FEC payload is MIU. If PT is set to 2, it indicates that MIU is carried in the separate flow and FEC payload is repair packet. If PT is set to 3, it indication that MIU is carried in the repair flow and FEC payload is repair packet. ZiXuan Expires April 23, 2010 [Page 7] Internet-Draft source FEC payload MI October 2009 o Num flows (8 bits): The number of source flows in a single source block. o reserved (8 bits): reserved for future use. 3.6. The source FEC payload MIU format The source FEC payload MIU format is shown in Figure 5. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |FID | length | initial_seq_number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Source_FEC_Payload_ID 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Source_FEC_Payload_ID 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | ......... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Source_FEC_Payload_ID N | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 5 The source FEC payload MIU format o Source flow Identifier (FID) (4 bits): This field identifies the source packet flow to which FEC protection is applied. o Length (12 bits): This field indicates the number of source FEC payload ID involved in a source FEC payload MIU. o Initial_seq_number (16 bits): This field indicates the sequence number of the starting source packet with respect to FID of a source block. The starting source packet belongs to the source packet flow identified by FID field. ZiXuan Expires April 23, 2010 [Page 8] Internet-Draft source FEC payload MI October 2009 o Source_FEC_Payload_ID (Variable Length): A source FEC Payload Identificaiton specifically for use with source packets. The field size is dependent upon the FEC scheme identified by fec_id field in FEC payload header. This field in conjunction with initial_seq_number determines which source block a FEC source packet belongs to and the position of a FEC source packet in the FEC source block. MIU Example: A MIU example is shown in Figure 6, where compact no-code FEC scheme is used to protect two flows. The FID of protected flows is 1 and 2 respectively. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | fec_id=0 | PT=1 | Num flows=2 | reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |FID=1 | length=3 | ISN=14567 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | sbn=0 | esi=0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | sbn=0 | esi=6 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | sbn=0 | esi=10 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |FID=2 | length=2 | ISN=5734 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | sbn=0 | esi=15 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | sbn=0 | esi=19 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 6 MIU Example 4. Systematic procedures for structure of the source block 4.1. Introduction This section specifies a systematic way to create the source block. There is a modified version in section 3, which the order of packets in the source block is deterministic. ZiXuan Expires April 23, 2010 [Page 9] Internet-Draft source FEC payload MI October 2009 4.2. Source block creation and example The following steps are provided. 1. For the packet placed into the source block create a byte array as follows: a) The value of the packet flow identifier, followed by the value of the packet size, are first written as single byte and two- byte value in network byte order respectively into the first available bytes in the source block b) Append the entire packet including its application header c) If the next available byte is not the first byte of a new symbol, then padding bytes up to the next symbol boundary d) Add padding so that the byte array is in the size of the largest packet protected by this source block 2. Append any packets one after the other in the following way: a) The procedure is repeated starting each packet flow identifier at the start of the next symbol b) Packets from the same flow are consecutive in the source block c) The packets of the same flow are in an increasing order of the sequence number d) The sequence number of packets belonging to the same flow must be consecutive in a single source block e) The packets of the different flow are in an increasing order of the flow number An example of forming a source block is given in figure blow. In this example, three packets of size 26, 42 and 10, which taken from flow 0 and flow 1, have been placed into a source block. ZiXuan Expires April 23, 2010 [Page 10] Internet-Draft source FEC payload MI October 2009 +---Source Block --+ +------------------+ |0|26|xxxxxxxxxxxxx| +------------------+ |x xx xxxxxxxxxx000| +------------------+ |0 00 0000000000000| +------------------+ |0|10|xxxxxxxxxx000| +------------------+ |0 00 0000000000000| +------------------+ |0 00 0000000000000| +------------------+ |1|42|xxxxxxxxxxxxx| +------------------+ |x xx xxxxxxxxxxxxx| +------------------+ |x xx xxxxxxxxxx000| +------------------+ Figure 7 Structure of a Source Block 4.3. Packet format for repair packet The packet format for FEC repair packet is shown in Figure 8. The transport payload consists of Application Protocol header, FEC payload header and FEC repair packet. ZiXuan Expires April 23, 2010 [Page 11] Internet-Draft source FEC payload MI October 2009 +------------------------------------+ | IP header | +------------------------------------+ | Transport header | +------------------------------------+ | Application Protocol header | +------------------------------------+ | FEC payload header | +------------------------------------+ | Source FEC payload MIU | +------------------------------------+ | Repair FEC payload ID | +------------------------------------+ | FEC repair data | +------------------------------------+ Figure 8 Packet Format for FEC repair packet 4.4. FEC payload header format See Section 3.6 4.5. The source FEC payload MIU format The source FEC payload MIU format is shown in Figure 9. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |FID | length | initial_seq_number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 9 The source FEC payload MIU format o Source flow Identifier (FID) (4 bits): This field identifies the source packet flow to which FEC protection is applied. o Length (12 bits): This field indicates the number of source FEC payload ID involved in a source FEC payload MIU. ZiXuan Expires April 23, 2010 [Page 12] Internet-Draft source FEC payload MI October 2009 o Initial_seq_number (16 bits): This field indicates the sequence number of the starting source packet with respect to FID of a source block. The starting source packet belongs to the source packet flow identified by FID field. o Source_FEC_Payload_ID (Variable Length): This field is not used by this scheme. MIU Example: A MIU example is shown in Figure 10, where compact no-code FEC scheme is used to protect two flows. The FID of protected flows is 1 and 2 respectively. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | fec_id=0 | PT=3 | Num flows=2 | reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |fid=1 | length=3 | ISN=14567 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |fid=2 | length=2 | ISN=5734 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 10 MIU Example 5. Session Description Protocol (SDP) signaling According to the FEC framework, the scheme must define an format for MIU. This section provides the media subtype registration for the FEC Mapping Information. The FEC Mapping Information is indicated in SDP using a media block with the protocol identifier ''UDP/FEC-MI''. The media type shall be ''application''. 6. Security Considerations TBC. 7. Normative References [rfc3550] H. Schulzrinne, S. Casner, R. Frederick and V. Jacobson, " RTP: A Transport Protocol for Real-Time Applications", RFC3550, July 2003. ZiXuan Expires April 23, 2010 [Page 13] Internet-Draft source FEC payload MI October 2009 [RFC4585] J. Ott, S. Wenger, N. Sato, C. Burmeister and J. Rey," Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/AVPF), RFC4585, July 2006 [RFC4588] J. Rey, D. Leon, A. Miyazaki, V. Varsa and R. Hakenberg, "RTP Retransmission Payload Format", RFC 4588, July 2006 [RFC5053] M. Luby, A. Shokrollahi, M. Watson and T. StockhammerRaptor ''Forward Error Correction Scheme for Object Delivery'', RFC5053, September 2007 [RFC5445] M. Watson, ''Basic Forward Error Correction (FEC) Schemes'', RFC5445, March 2009 [I-D.ietf-fecframe-framework] M. Watson, ''Forward Error Correction (FEC) Framework'', draft-ietf-fecframe-framework-03 (work in progress), October 24, 2008. 8. Acknowledgments Authors' Addresses ZiXuan Zou Huawei Technologies Co., Ltd. Bantian, longgang Industrial Base, B1 Email:tendyntu@huawei.com Bing Chen Huawei Technologies Co., Ltd. Bantian, longgang Industrial Base, B1 Email:chen.b@huawei.com ZiXuan Expires April 23, 2010 [Page 14]