TOC 
FEC FrameworkO. Peck
Internet-DraftRADVISION
Intended status: Standards TrackMarch 07, 2010
Expires: September 8, 2010 


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




 TOC 

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.



 TOC 

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.).



 TOC 

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].



 TOC 

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.



 TOC 

3.2.  Notations



 TOC 

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.



 TOC 

5.  Packet Formats

This section defines the formats of the source and repair packets



 TOC 

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.



 TOC 

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           |   _/
             +------------------------------+ --

 Figure 1: Format of repair packets 




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

 Figure 2: Format of the FEC Headers 



 TOC 

5.2.1.  RTP header format

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



 TOC 

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)                   |
     |                            ...                                |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 Figure 3: FEC-MF (Multi-Flow) Header Format 

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

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.



 TOC 

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.



 TOC 

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.



 TOC 

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.



 TOC 

6.1.  Registration of application/mf-fec

Type name: application

Subtype name: mf-fec

Required parameters:

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.



 TOC 

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:

See section 9 for SDP examples.



 TOC 

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:



 TOC 

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                           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 Figure 4: FEC-MF Header Example 



 TOC 

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           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 Figure 5: FEC Headers Example 



 TOC 

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

 Figure 6 



 TOC 

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.



 TOC 

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:



 TOC 

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.



 TOC 

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.



 TOC 

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.



 TOC 

14.  References



 TOC 

14.1. Normative References

[RFC2119] Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” BCP 14, RFC 2119, March 1997 (TXT, HTML, XML).
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, “RTP: A Transport Protocol for Real-Time Applications,” STD 64, RFC 3550, July 2003 (TXT, PS, PDF).
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, “SDP: Session Description Protocol,” RFC 4566, July 2006 (TXT).
[RFC4288] Freed, N. and J. Klensin, “Media Type Specifications and Registration Procedures,” BCP 13, RFC 4288, December 2005 (TXT).
[RFC3555] Casner, S. and P. Hoschka, “MIME Type Registration of RTP Payload Formats,” RFC 3555, July 2003 (TXT).
[RFC4756] Li, A., “Forward Error Correction Grouping Semantics in Session Description Protocol,” RFC 4756, November 2006 (TXT).


 TOC 

14.2. Informative References

[RFC5109] Li, A., “RTP Payload Format for Generic Forward Error Correction,” RFC 5109, December 2007 (TXT).
[RFC5510] Lacan, J., Roca, V., Peltotalo, J., and S. Peltotalo, “Reed-Solomon Forward Error Correction (FEC) Schemes,” RFC 5510, April 2009 (TXT).
[I-D.ietf-fecframe-framework] Watson, M., “Forward Error Correction (FEC) Framework,” draft-ietf-fecframe-framework-07 (work in progress), March 2010 (TXT).
[I-D.ietf-fecframe-sdp-elements] Begen, A., “SDP Elements for FEC Framework,” draft-ietf-fecframe-sdp-elements-06 (work in progress), April 2010 (TXT).
[I-D.galanos-fecframe-rtp-reedsolomon-mf] Galanos, S., “RTP Payload Format for Reed Solomon FEC of Multiple Flows,” draft-galanos-fecframe-rtp-reedsolomon-mf-00 (work in progress), July 2009 (TXT).
[I-D.galanos-fecframe-rtp-reedsolomon] Galanos, S., Peck, O., and V. Roca, “RTP Payload Format for Reed Solomon FEC,” draft-galanos-fecframe-rtp-reedsolomon-01 (work in progress), March 2010 (TXT).
[I-D.ietf-fecframe-pseudo-cdp] Kozat, U. and A. Begen, “Pseudo Content Delivery Protocol (CDP) for Protecting Multiple Source Flows in FEC Framework,” draft-ietf-fecframe-pseudo-cdp-01 (work in progress), March 2009 (TXT).
[RFC5053] Luby, M., Shokrollahi, A., Watson, M., and T. Stockhammer, “Raptor Forward Error Correction Scheme for Object Delivery,” RFC 5053, October 2007 (TXT).


 TOC 

Author's Address

  Orly Peck
  RADVISION
  24 Raul Wallenberg St.
  Tel Aviv 69719
  Israel
Email:  orlyp@radvision.com