RTP Payload Format for Multi-Flow FEC
draft-peck-fecframe-rtp-mf-01

Abstract

This document defines a new RTP payload format for the Forward Error Correction (FEC) that is used to protect multiple source flows. The format defined by this document enables the protection of multiple media sources encapsulated in RTP with one or more repair flows and is based on the FEC framework (described in [I-D.ietf-fecframe-framework]) and the SDP Elements for FEC Framework (described in [I-D.ietf-fecframe-sdp-elements]).

Status of this Memo

This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and 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 September 8, 2010.

Copyright Notice

Copyright (c) 2010 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 (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License.

Table of Contents

1.  Introduction
2.  Requirements Notation
3.  Definitions, Notations and Abbreviations
    3.1.  Definitions
    3.2.  Notations
4.  Source Correlation
5.  Packet Formats
    5.1.  Source Packets
    5.2.  Repair Packets
        5.2.1.  RTP header format
        5.2.2.  FEC-MF header format
        5.2.3.  FEC Headers Format
        5.2.4.  Repair Data Format
6.  Payload Format Parameters
    6.1.  Registration of application/mf-fec
7.  Mapping of SDP Parameters
8.  FEC Packet Example
    8.1.  MF-FEC Header Example
    8.2.  FEC Headers Example
    8.3.  SDP Example
9.  Application considerations
10.  Offer/Answer considerations
11.  Security Considerations
12.  IANA Considerations
13.  Acknowledgments
14.  References
    14.1.  Normative References
    14.2.  Informative References
§  Author's Address

1.  Introduction

This document defines a new RTP payload format for the Forward Error Correction (FEC) protecting multiple source flows.

[I-D.ietf-fecframe-framework] allows multiple source flows to be protected by the same FEC repair flow.

Multiple source flows are transmitted either as Multi-Session or as Multi-source (see definition below).

The format defined by this document enables the protection of multiple media source flows (Multi-Session or Multi-Source transmission) with one or more repair flows without adding additional information to the source packets.

The method described in this document is generic to all FEC schemes.

2.  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 [RFC2119] (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.).

3.  Definitions, Notations and Abbreviations

This document uses the following definitions and notations. For further definitions that apply to FEC Framework in general, see [I-D.ietf-fecframe-framework].

3.1.  Definitions

FEC: Forward Error Correction.

Source Flow: The packet flow to which FEC protection is to be applied.

Repair Flow: The packet flow carrying FEC data.

Source Block: The group of source data packets which are to be FEC protected as a single block.

Source Packets: Packets that are transmitted over a source flow

Repair/FEC Packets: Packets that are transmitted over a repair flow

FEC header: A FEC-scheme specific header as defined by different I-Ds, usually follows the RTP header.

FEC-MF header: The FEC Multi-flow header. Contains information about the different source-flows and their order in the FEC block.

multi-session transmission: In multi-session transmission, media data from a single media source is split over multiple RTP sessions. The term "layered multicast" is equivalent to multi-session transmission for sessions using multicast addresses.

multi-source transmission: In multi-source transmission, data from a single media source is sent as several RTP streams in the same RTP session. The sources contained in an RTP session are identified by their synchronization source identifiers (SSRCs) or, if combined by a RTP mixer, by their contributing source identifiers (CSRCs), as defined in RTP [RFC3550].

Source Correlation: The logical association of RTP streams transferred as multiple separate sessions or as multiple sources in the same session to one layered media.

3.2.  Notations

4.  Source Correlation

When a FEC packet protects multiple source-flows (multi-session or multi-source transmission), the receiver must correlate between a received FEC packet and the RTP source-packets protected by it.

For correlating between FEC packets and source flow packets sent as multi-sessions, this draft uses the 'fec-source-flow' (see section 6.2) parameter sent in SDP as defined in SDP Elements for FEC Framework. The list of different 'fec-source-flow' identifiers are used in a newly defined FEC-MF-Header.

For correlating FEC packets and source flows sent as multi-source, the 'fec-source-flow' parameter is used as well. However, as stated in RFC 3550 (section 5.2) 'multiplexing multiple related sources of the same medium in one RTP session using different SSRC values is the norm for multicast sessions'. When different SSRCs are used on the same RTP session, the encoder is receiving RTP packets that use multiple sequence-number spaces. Since a FEC encoder is not always aware of other source-flows transmitted on the same RTP session in multicast transmission, the SSRC should be used for source correlation in order to uniquely identify the protected source-flow.

The coupling of the fec-source-flow and the source flow SSRC identifier creates a unique identifier for a source-flow, and therefore enables the FEC decoding procedure for multiple source flows.

If the FEC encoding is done in a "middle-box" that receives the different source flows to be protected, the FEC encoder should validate the fec-source-flow idnetifiers for collisions. When a collision is detected, the FEC encoder should answer with a different fec-source-flow than the one offered. The fec-source-flow MUST not be changed during the session.

5.  Packet Formats

This section defines the formats of the source and repair packets

5.1.  Source Packets

The FEC Framework requires that source packets will contain information identifying the source block and the position within the source block occupied by the packet. However, in order to maintain backwards compatibility, this document enables the receiver to get this information without appending additional information to the source packet. Specifically this information is obtained using the combination of sequence number and SSRC identifier found in the RTP header, and information provided in the FEC header and FEC-MF header of each repair packet. Such behavior enables both non-FEC-capable and FEC-capable receivers to receive and interpret the same source packets sent in a multicast session.

5.2.  Repair Packets

The FEC repair packets contain information that enables the receiver to reconstruct the source block in the remote end. This is done by using the RTP header of the repair packets as well as other headers placed within the RTP payload. The additional headers, referred to as the FEC headers as shown in Figure 1 from the [FECFRAME-FRAMEWORK] (section 6.4.1), are the FEC-MF header and the additional FEC headers for each source-flow, as shown in Figure 2.

The FEC repair packets MUST be sent in a separate RTP session from the protected source-flows.

             +------------------------------+
             |          IP Header           |
             +------------------------------+
             |       Transport Header       |
             +------------------------------+
             |          RTP Header          |
             +------------------------------+ --_
             |          FEC Headers         |    \
             +------------------------------+     > RTP Payload
             |        Repair Data           |   _/
             +------------------------------+ --

  +------------------------------+
  |          RTP Header          |
  +------------------------------+ --_
  |       FEC-MF Header          |    \
  +------------------------------+     \
  |          FEC Headers         |      \
  |            ....              |       > RTP Payload
  +------------------------------+     /
  |        Repair Data           |   _/
  +------------------------------+ --

5.2.1.  RTP header format

The RTP header is formatted according to [RFC3550] with some further clarifications listed below:

• Payload Type: The (dynamic) payload type for the repair packets is determined through out-of-band means. Note that this document registers new payload formats for the repair packets (Refer to Section 6 for details). According to [RFC3550], an RTP receiver that cannot recognize a payload type must discard it. This provides for backward compatibility. The FEC mechanisms can then be used in a multicast group with mixed FEC-capable and non-FEC-capable receivers. If a non-FEC-capable receiver receives a repair packet, it will not recognize the payload type, and hence, will discard the repair packet.
• Sequence Number (SN): The sequence number maintains the standard definition. It is one higher than the sequence number in the previously transmitted repair packet. The initial value of the sequence number is random (unpredictable) [RFC3550].
• Timestamp (TS): The timestamp is set to a time corresponding to the repair packet's transmission time. Note that the timestamp value has no use in the actual FEC protection process and is usually useful for jitter calculations.
• Synchronization Source (SSRC): The SSRC value is randomly assigned as suggested by [RFC3550].

5.2.2.  FEC-MF header format

The FEC-MF header includes information that enables the receiver to correlate a received FEC packet with the protected source-flows.

The FEC-MF header includes a list of source-flow identifiers (FID list), and optionaly, a list of SSRC identifiers (SSRC list) for uniquely identifying the protected source flows. The optional SSRC list is appended to the FEC-MF header.

Specific FEC-scheme information for every source-flow is provided by the FEC headers appended to the MF-FEC header. The FEC headers are ordered by the FID in the FID list.

The order of the FIDs (and the matching FEC headers) should be the same as the order of the source flows as they were arranged in the FEC source block before encoding. This is required to ensure the correct construction of the FEC block for the decoding process.

The format of the FEC-MF header is shown in figure 3.

      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |L| Num Flows   |      FID      |     FID       |       FID     |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |     FID       |       FID     |     padding   |   padding     |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                 SSRC identifiers (Optional)                   |
     |                            ...                                |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The FEC-MF header consists of the following general fields:

• L-Bit- A bit indicating whether the optional list of SSRC identifiers is appended to the FEC-MF header. When set to 0, no SSRC identifiers are specified (for cases where the FID is sufficient as a unique identifier). When set to 1, a list of SSRC identifiers is appended to the FEC-MF header. The length of this list is (4 bytes * Num Flows). Each 4 bytes represent the SSRC of the flow specified by the order of the FID list in the FEC-MF header.
• Num Flows - The number of source flows protected by this FEC packet. Maximum number of protected source flows is 128.
• FID - Source flow Identifier. The FEC-MF includes a list of FID identifying each source flow. The FID value is as specified in the id parameter in the "fec-source-flow" field in SDP. See example in section 6.3.3. The number of FID fields is 'Num Flows' which represents the FID list size . The FEC-MF header will be padded with zeros to 4-bytes alignment, if needed, after the last FID field (calculation for number of padded bytes is: 4-((2+Num Flows)%4)). Each FID is correlated with a FEC header appended to the FEC-MF header by the order of the FID in the FID list. The number of appended FEC headers MUST equal the value of 'Num Flows'. Since FID field is 8 bits, the "fec-source-flow" field in SDP should be between 0 and 255. This limits the number of source-flows protected by FEC to 256 flows.
• SSRC identifiers - list of SSRC identifiers (optional). If the L-Bit is 0, the list length is 0. If set to 1, the list length is (4*Num Flows), where each SSRC is taken from the protected source-flow SSRC field in the RTP header, and is represented by 4 bytes.

Editor's Note: in order to avoid sending unnecessary SSRC identifiers, it should be defined when the SSRC is redundant information. SSRC is redundant when Multi-Source is not used, or when there is only one sender for the RTP session. In this case the 'fec-source-flow' is a unique idetifier for a source flow.

5.2.3.  FEC Headers Format

The FEC-MF header is followed by a list of FEC headers, according to the FEC-scheme signalled by SDP (See Section 6). Each FEC header in the list represents the matching fec-source-flow in the FID list by order.

5.2.4.  Repair Data Format

The repair data is added after the last FEC header in the RTP repair packet. It includes the result of FEC scheme code over the source block constructed from the different source-flows. The repair data format is defined by the FEC scheme used for this repair packet as signalled by SDP.

6.  Payload Format Parameters

According to the FEC framework, when RTP is used as a transport for repair packet flows, the scheme must define an RTP Payload Format for the repair data. This section provides the media subtype registration for the Multi-Flow FEC. The parameters that are required to configure the FEC encoding and decoding operations are also defined in this section.

6.1.  Registration of application/mf-fec

Type name: application

Subtype name: mf-fec

Required parameters:

• FEC-scheme - the FEC scheme used for encoding. The value used here should be the FEC payload type as it was registered in the relevant RFC/draft.

Optional parameters: None.

Encoding considerations: This media type is framed and binary, see section 4.8 in [RFC4288]

Security considerations: Please see security consideration in [I-D.ietf-fecframe-framework]

Interoperability considerations: None.

Published specification: TBD

Applications that use this media type: Multimedia applications that want to improve resiliency against packet loss by sending redundant data for multiple source media flows.

Additional information: None.

Magic number(s): none defined

File extension(s): none defined

Macintosh file type code(s): none defined

Person & email address to contact for further information: Orly Peck, orlyp@radvision.com

Intended usage: COMMON

Restrictions on usage: This media type depends on RTP framing, and hence is only defined for transfer via RTP [RFC3550]. Transport within other framing protocols is not defined at this time.

7.  Mapping of SDP Parameters

For a proper operation details of the FEC operation have to be communicated between the sender and the receiver. The receiver must be notified that the FEC operation was used for multiple source flows. Specifically, the receiver has to know the FEC scheme that was used by the sender to encode the source flows. In addition, different FEC scheme-specific parameters should be communicated. One way to provide this information is to use the Session Description Protocol (SDP) [RFC4566].

The mapping of the media type specification for "mf-fec" and their parameters in SDP is as follows:

• The media type (e.g., "application") goes into the "m=" line as the media name.
• The media subtype ("mf-fec") goes into the "a=rtpmap" line as the encoding name.
• The 'FEC-scheme' goes into the "a=fmtp" line, followed by a semicolon-separated list of parameter that are required for the specific used FEC-scheme.
• The "group" and "fec-source-flow" attributes should be used according to [I-D.ietf-fecframe-sdp-elements].

See section 9 for SDP examples.

8.  FEC Packet Example

This section demonstrates the structure and data in a FEC packet protecting multiple source flows.

In this example, the following FEC packet is the result of Reed-Solomon encoding for 3 different source flows. Two of the source flows (1 and 2) share the same RTP session and same payload type, and are differentiated by different SSRC identifiers (Multi-Source Transmission). The other source flow (3) is transmitted through a different RTP session but share the same SSRC identifier as the one used by source-flow 2 (Mutliple-Session Transmission).

The FEC payload represents the Reed-Solomon scheme over RTP as defined in draft-galanos-fecframe-rtp-reedsolomon-01. This draft is general for all FEC schemes transmitted through RTP, and the use of Reed-Solomon is only for illustration purposes.

The source-flows protected by this FEC packet are defined as follows:

• source-flow-1: identified as fec-source-flow: id=0 in SDP, with SSRC=10.
• source-flow-2: identified as fec-source-flow: id=0 in SDP, with SSRC=11.
• source-flow-3: identified as fec-source-flow: id=1 in SDP, with SSRC=11.

8.1.  MF-FEC Header Example

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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  num FID=3    |   FID=0       |     FID=0     |     FID=1     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                           SSRC = 10                           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                           SSRC = 11                           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                           SSRC = 11                           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

8.2.  FEC Headers Example

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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    n_r        |       i       |        SN_base=1000           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|          Reserved     |  BML  |       Num Packets=5           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    n_r        |       i       |        SN_base=0              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|          Reserved     |  BML  |       Num Packets=6           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    n_r        |       i       |        SN_base=500            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|          Reserved     |  BML  |       Num Packets=6           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

8.3.  SDP Example

The following example demonstrates the SDP for the above FEC packet example.

	   v=0
	   o=orly 1122334455 1122334466 IN IP4 fec.example.com
	   s= MF FEC Example
	   t=0 0
	   a=group:FEC S1 S2 R1
	   m=video 30000 RTP/AVP 100
	   c=IN IP4 224.1.1.1/127
	   a=rtpmap:100 MP2T/90000
	   a=fec-source-flow: id=0
	   a=mid:S1
	   m=video 30002 RTP/AVP 100
	   c=IN IP4 224.1.1.1/127
	   a=rtpmap:100 MP2T/90000
	   a=fec-source-flow: id=1
	   a=mid:S2
	   m=application 30000 RTP/AVP 110
	   c=IN IP4 224.1.2.1/127
	   a=rtpmap:110 fec-mf/90000
	   a=fmtp:110 FEC-scheme=reed-solomon-fec; max_N:5;
	          repair-window:200000; symbol-size:8
	   a=mid:R1

9.  Application considerations

Protecting multiple flows with the same repair flow might be more efficient in terms of bandwidth overhead and FEC strength. An appropriate example for bandwidth efficiency would be a 3D interactive video application (2D plus depth) where a FEC protection must be applied to a single frame only, due to latency considerations. If, for example, each frame (2D or depth) is transmitted by 4 RTP packets, the miniumum bandwidth overheader for protecting each source flow separately is 25%, with a single repair packet for each frame (one for 2D frame, and one for depth frame). By protecting both frames together (2D and depth) with the same repair flow, the bandwidth overhead can be reduced to 12.5% (A single repair packet for all 8 RTP source packets). This, ofcourse, reduces the FEC strength to the level chosen be the application.

Protecting multiple source flows can increase FEC strength as described in the following example: When protecting each frame separately with a single repair packet, if two packets are lost from a the same frame, they cannot be repaired.

However, if we protect both flows (8 RTP packets) with a scheme such as Reed-Solomon, with 2 repair packets (without actually increasing the bandwidth overhead), any two lost packets from both frames (total of 8 RTP packets) may be repaired. However, an example for an application that is not suitable for multiple source flows protection, would be an application that protects two flows where one of the flows is prone to high packet loss rates, and the other source flow is prone to low packet loss rates. Protecting both flows with one repair flow, will damage the rate of successful repairing of packets of the flow that is prone to low packet loss rate.

10.  Offer/Answer considerations

When offering multiple source flows FEC protection over RTP using SDP in an Offer/Answer model [RFC3264], the following considerations apply:

• When protecting multiple sources, the sender may suggest various FEC-schemes to be used for the FEC protection. Each FEC-scheme should be indicated as a separate offer. The receiver may choose the supported/preferred FEC-scheme to be used.
• The specific FEC-scheme parameters can also be indicated as separated offers. For example, using the same FEC-scheme but with two differnt repair-window size parameters should be indicated in separated offers. Once the receiver decides the FEC-scheme to be used, it should choose the specific offer among the different offers for the chosen scheme based on the FEC-scheme parameters.
• When a receiver does not support the fec-mf scheme, these offers MUST be ignored and deleted from the answer. The sender may add other single source flow FEC protection offers for receivers that do not support multiple source flows protection.
• If multiple source flow FEC protection is not desired by the receiver, it can be deleted from the answer.

11.  Security Considerations

Multiple flow FEC protection is FEC-scheme independent. Any FEC scheme can be used for protection. Therefore, the security considerations for using multiple flow FEC protection are dependent on the actual used FEC-scheme, and should be taken under considerations when using it.

Other security considerations are implied by using RTP for multiple flow protection:

RTP packets using the payload format defined in this specification are subject to the security considerations discussed in the RTP specification [RFC3550] and in any applicable RTP profile. The main security considerations for the RTP packet carrying the RTP payload format defined within this memo are confidentiality, integrity and source authenticity. Confidentiality is achieved by encrypting the RTP payload. Integrity of the RTP packets is achieved through a suitable cryptographic integrity protection mechanism. Such a cryptographic system may also allow the authentication of the source of the payload. A suitable security mechanism for this RTP payload format should provide confidentiality, integrity protection, and at least source authentication capable of determining if an RTP packet is from a member of the RTP session.

Note that the appropriate mechanism to provide security to RTP and payloads following this memo may vary. It is dependent on the application, transport and signaling protocol employed. Therefore, a single mechanism is not sufficient, although if suitable, using the Secure Real-time Transport Protocol (SRTP) [RFC3711] is recommended. Other mechanisms that may be used are IPsec [RFC4301] and Transport Layer Security (TLS) [RFC5246] (RTP over TCP); other alternatives may exist.

12.  IANA Considerations

New media subtypes are subject to IANA registration. For the registration of the payload formats and their parameters introduced in this document, refer to Section 7.

13.  Acknowledgments

Some parts of this document are borrowed from the following documents: [RFC5109], [draft-ietf-fecframe-1d2d-parity-scheme-01], [draft-galanos-fecframe-rtp-reedsolomon-mf-00]. The author would like to thank the editors of these documents.

14.  References

14.1. Normative References

14.2. Informative References

Author's Address