AVT Core Working Group                                          V. Singh
Internet-Draft                                             T. Karkkainen
Intended status: Experimental                                     J. Ott
Expires: September 15, 2011                                     S. Ahsan
                                                        Aalto University
                                                               L. Eggert
                                                                   Nokia
                                                          March 14, 2011


                         Multipath RTP (MPRTP)
                      draft-singh-avtcore-mprtp-01

Abstract

   The Real-time Transport Protocol (RTP) is used to deliver real-time
   content and, along with the RTP Control Protocol (RTCP), forms the
   control channel between the sender and receiver.  However, RTP and
   RTCP assume a single delivery path between the sender and receiver
   and make decisions based on the measured characteristics of this
   single path.  Increasingly, endpoints are becoming multi-homed, which
   means that they are connected via multiple Internet paths.  Network
   utilization can be improved when endpoints use multiple parallel
   paths for communication.  The resulting increase in reliability and
   throughput can also enhance the user experience.  This document
   extends the Real-time Transport Protocol (RTP) so that a single
   session can take advantage of the availability of multiple paths
   between two endpoints.

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

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

   This Internet-Draft will expire on September 15, 2011.

Copyright Notice




Singh, et al.          Expires September 15, 2011               [Page 1]


Internet-Draft                Multipath RTP                   March 2011


   Copyright (c) 2011 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 Simplified BSD License.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
     1.1.  Requirements Language  . . . . . . . . . . . . . . . . . .  4
     1.2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .  4
     1.3.  Use-cases  . . . . . . . . . . . . . . . . . . . . . . . .  5
   2.  Goals  . . . . . . . . . . . . . . . . . . . . . . . . . . . .  5
     2.1.  Functional goals . . . . . . . . . . . . . . . . . . . . .  5
     2.2.  Compatibility goals  . . . . . . . . . . . . . . . . . . .  6
   3.  RTP Topologies . . . . . . . . . . . . . . . . . . . . . . . .  6
   4.  MPRTP Architecture . . . . . . . . . . . . . . . . . . . . . .  6
     4.1.  Relationship of MPRTP with Session Signaling . . . . . . .  8
   5.  Example Media Flow Diagrams  . . . . . . . . . . . . . . . . .  8
     5.1.  Streaming use-case . . . . . . . . . . . . . . . . . . . .  8
     5.2.  Conversational use-case  . . . . . . . . . . . . . . . . .  9
     5.3.  Challenges with Multipath Interface Discovery  . . . . . . 10
   6.  MPRTP Functional Blocks  . . . . . . . . . . . . . . . . . . . 10
   7.  Available Mechanisms within the Functional Blocks  . . . . . . 11
     7.1.  Session Setup  . . . . . . . . . . . . . . . . . . . . . . 11
     7.2.  Expanding RTP  . . . . . . . . . . . . . . . . . . . . . . 11
     7.3.  Adding New Interfaces  . . . . . . . . . . . . . . . . . . 11
     7.4.  Expanding RTCP . . . . . . . . . . . . . . . . . . . . . . 12
     7.5.  Checking and Failure Handling  . . . . . . . . . . . . . . 12
   8.  MPRTP Protocol . . . . . . . . . . . . . . . . . . . . . . . . 12
     8.1.  Overview . . . . . . . . . . . . . . . . . . . . . . . . . 13
       8.1.1.  Subflow or Interface advertisement . . . . . . . . . . 14
       8.1.2.  Path selection . . . . . . . . . . . . . . . . . . . . 14
       8.1.3.  Opening subflows . . . . . . . . . . . . . . . . . . . 15
     8.2.  RTP Transmission . . . . . . . . . . . . . . . . . . . . . 15
     8.3.  Playout Considerations at the Receiver . . . . . . . . . . 15
     8.4.  Subflow-specific RTCP Statistics and RTCP Aggregation  . . 16
     8.5.  RTCP Transmission  . . . . . . . . . . . . . . . . . . . . 16
   9.  Packet Formats . . . . . . . . . . . . . . . . . . . . . . . . 16
     9.1.  RTCP Extension for Interface advertisement . . . . . . . . 16



Singh, et al.          Expires September 15, 2011               [Page 2]


Internet-Draft                Multipath RTP                   March 2011


       9.1.1.  Interface Advertisement block  . . . . . . . . . . . . 18
     9.2.  MPRTP RTP Header Extension . . . . . . . . . . . . . . . . 19
       9.2.1.  MPRTP RTP Extension for a Subflow  . . . . . . . . . . 20
       9.2.2.  MPRTP RTP Extension for Connectivity Checks  . . . . . 21
       9.2.3.  MPRTP RTP Extension for Keep-alive Packets . . . . . . 21
     9.3.  MPRTP Extension for Subflow Reporting (MPRTCP) . . . . . . 21
       9.3.1.  MPRTCP Generic Extension . . . . . . . . . . . . . . . 21
       9.3.2.  MPRTCP for Subflow-specific SR, RR and XR  . . . . . . 23
   10. SDP Considerations . . . . . . . . . . . . . . . . . . . . . . 25
     10.1. Increased Throughput . . . . . . . . . . . . . . . . . . . 25
     10.2. Increased Reliability  . . . . . . . . . . . . . . . . . . 25
     10.3. MPRTP using preloaded interfaces from ICE  . . . . . . . . 25
   11. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 25
   12. Security Considerations  . . . . . . . . . . . . . . . . . . . 26
   13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 26
   14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26
     14.1. Normative References . . . . . . . . . . . . . . . . . . . 26
     14.2. Informative References . . . . . . . . . . . . . . . . . . 27
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27
































Singh, et al.          Expires September 15, 2011               [Page 3]


Internet-Draft                Multipath RTP                   March 2011


1.  Introduction

   Multi-homed endpoints are becoming common in today's Internet, e.g.,
   devices that support multiple wireless access technologies such as 3G
   and Wireless LAN.  This means that there is often more than one
   network path available between two endpoints.  Transport protocols,
   such as RTP, have not been designed to take advantage of the
   availability of multiple concurrent paths and therefore cannot
   benefit from the increased capacity and reliability that can be
   achieved by pooling their respective capacities.

   Multipath RTP (MPRTP) is an OPTIONAL extension to RTP [1] that allows
   splitting a single RTP stream into multiple subflows that are
   transmitted over different paths.  In effect, this pools the resource
   capacity of multiple paths.  Multipath RTCP (MPRTCP) is an extension
   to RTCP, it is used along with MPRTP to report per-path sender and
   receiver characteristics.

   Other IETF transport protocols that are capable of using multiple
   paths include SCTP [9], MPTCP MPTCP [10] and SHIM6 [11].  However,
   these protocols are not suitable for realtime communications.

1.1.  Requirements Language

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

1.2.  Terminology

   o  Endpoint: host either initiating or terminating an RTP connection.

   o  Interface: logical or physical component that is capable of
      acquiring a unique IP address.

   o  Path: sequence of links between a sender and a receiver.
      Typically, defined by a set of source and destination addresses.

   o  Subflow: flow of RTP packets along a specific path, i.e., a subset
      of the packets belonging to an RTP stream.  The combination of all
      RTP subflows forms the complete RTP stream.  Typically, a subflow
      would map to a unique path, i.e., each combination of IP addresses
      and port pairs (4-tuple) is a unique subflow.








Singh, et al.          Expires September 15, 2011               [Page 4]


Internet-Draft                Multipath RTP                   March 2011


1.3.  Use-cases

   The primary use-case for MPRTP is transporting high bit-rate
   streaming multimedia content between endpoints, where at least one is
   multi-homed.  Such endpoints could be residential IPTV devices that
   connect to the Internet through two different Internet service
   providers (ISPs), or mobile devices that connect to the Internet
   through 3G and WLAN interfaces.  By allowing RTP to use multiple
   paths for transmission, the following gains can be achieved:

   o  Higher quality: Pooling the resource capacity of multiple Internet
      paths allows higher bit-rate and higher quality codecs to be used.
      From the application perspective, the available bandwidth between
      the two endpoints increases.

   o  Load balancing: Transmitting one RTP stream over multiple paths
      can reduce the bandwidth usage, compared to transmitting the same
      stream along a single path.  This reduces the impact on other
      traffic.

   o  Fault tolerance: When multiple paths are used in conjunction with
      redundancy mechanisms (FEC, re-transmissions, etc.), outages on
      one path have less impact on the overall perceived quality of the
      stream.

   A secondary use-case for MPRTP is transporting Voice over IP (VoIP)
   calls to a device with multiple interfaces.  Again, such an endpoint
   could be a mobile device with multiple wireless interfaces.  In this
   case, little is to be gained from resource pooling, i.e., higher
   capacity or load balancing, because a single path should be easily
   capable of handling the required load.  However, using multiple
   concurrent subflows can improve fault tolerance, because traffic can
   shift between the subflows when path outages occur.  This results in
   very fast transport-layer handovers that do not require support from
   signaling.


2.  Goals

   This section outlines the basic goals that multipath RTP aims to
   meet.  These are broadly classified as Functional goals and
   Compatibility goals.

2.1.  Functional goals

   Allow unicast RTP session to be split into multiple subflows in order
   to be carried over multiple paths.  This may prove beneficial in case
   of video streaming.



Singh, et al.          Expires September 15, 2011               [Page 5]


Internet-Draft                Multipath RTP                   March 2011


   o  Increased Throughput: Cumulative capacity of the two paths may
      meet the requirements of the multimedia session.  Therefore, MPRTP
      MUST support concurrent use of the multiple paths.

   o  Improved Reliability: MPRTP SHOULD be able to send redundant
      packets or re-transmit packets along any available path to
      increase reliability.

   The protocol SHOULD be able to open new subflows for an existing
   session when new paths appear and MUST be able to close subflows when
   paths disappear.

2.2.  Compatibility goals

   MPRTP MUST be backwards compatible; an MPRTP stream needs to fall
   back to be compatible with legacy RTP stacks if MPRTP support is not
   successfully negotiated.

   o  Application Compatibility: MPRTP service model MUST be backwards
      compatible with existing RTP applications, i.e., an MPRTP stack
      MUST be able to work with legacy RTP applications and not require
      changes to them.  Therefore, the basic RTP APIs MUST remain
      unchanged, but an MPRTP stack MAY provide extended APIs so that
      the application can configure any additional features provided by
      the MPRTP stack.

   o  Network Compatibility: individual RTP subflows MUST themselves be
      well-formed RTP flows, so that they are able to traverse NATs and
      firewalls.  This MUST be the case even when interfaces appear
      after session initiation.  Interactive Connectivity Establishment
      (ICE) [3] MAY be used for discovering new interfaces or performing
      connectivity checks.


3.  RTP Topologies

   RFC 5117 [12] describes a number of scenarios using mixers and
   translators in single-party (point-to-point), and multi-party (point-
   to-multipoint) scenarios.  RFC 3550 [1] (Section 2.3 and 7.x) discuss
   in detail the impact of mixers and translators on RTP and RTCP
   packets.  MPRTP assumes that if a mixer or translator exists in the
   network, then either all of the multiple paths or none of the
   multiple paths go via this component.


4.  MPRTP Architecture

   In a typical scenario, an RTP session uses a single path.  In an



Singh, et al.          Expires September 15, 2011               [Page 6]


Internet-Draft                Multipath RTP                   March 2011


   MPRTP scenario, an RTP session uses multiple subflows that each use a
   different path.  Figure 1 shows the difference.

   +--------------+                Signaling            +--------------+
   |              |------------------------------------>|              |
   |    Client    |<------------------------------------|    Server    |
   |              |           Single RTP flow           |              |
   +--------------+                                     +--------------+

   +--------------+              Signaling              +--------------+
   |              |------------------------------------>|              |
   |    Client    |<------------------------------------|    Server    |
   |              |<------------------------------------|              |
   +--------------+            MPRTP subflows           +--------------+

     Figure 1: Comparison between traditional RTP streaming and MPRTP


   +-----------------------+         +-------------------------------+
   |      Application      |         |          Application          |
   +-----------------------+         +-------------------------------+
   |                       |         |             MPRTP             |
   +          RTP          +         +- - - - - - - -+- - - - - - - -+
   |                       |         |  RTP subflow  |  RTP subflow  |
   +-----------------------+         +---------------+---------------+
   |          UDP          |         |      UDP      |      UDP      |
   +-----------------------+         +---------------+---------------+
   |           IP          |         |       IP      |       IP      |
   +-----------------------+         +---------------+---------------+

                       Figure 2: MPRTP Architecture

   Figure 2 illustrates the differences between the standard RTP stack
   and the MPRTP stack.  MPRTP receives a normal RTP session from the
   application and splits it into multiple RTP subflows.  Each subflow
   is then sent along a different path to the receiver.  To the network,
   each subflow appears as an independent, well-formed RTP flow.  At the
   receiver, the subflows are combined to recreate the original RTP
   session.  The MPRTP layer performs the following functions:

   o  Path Management: The layer is aware of alternate paths to the
      other host, which may, for example, be the peer's multiple
      interfaces.  So that it is able to send differently marked packets
      along separate paths.  MPRTP also selects interfaces to send and
      receive data.  Furthermore, it manages the port and IP address
      pair bindings for each subflow.





Singh, et al.          Expires September 15, 2011               [Page 7]


Internet-Draft                Multipath RTP                   March 2011


   o  Packet Scheduling: the layer splits a single RTP flow into
      multiple subflows and sends them across multiple interfaces
      (paths).  The splitting MAY BE done using different path
      characteristics.

   o  Subflow recombination: the layer creates the original stream by
      recombining the independent subflows.  Therefore, the multipath
      subflows appear as a single RTP stream to applications.

4.1.  Relationship of MPRTP with Session Signaling

   Session signaling (e.g., SIP [13], RTSP [14]) SHOULD be done over a
   failover-capable or multipath-capable transport for e.g., SCTP [9] or
   MPTCP [10] instead of TCP or UDP.


5.  Example Media Flow Diagrams

   There may be many complex technical scenarios for MPRTP, however,
   this memo only considers the following two scenarios: 1) a
   unidirectional media flow that represents the streaming use-case, and
   2) a bidirectional media flow that represents a conversational use-
   case.

5.1.  Streaming use-case

   In the unidirectional scenario, the receiver (client) initiates a
   multimedia session with the sender (server).  The receiver or the
   sender may have multiple interfaces and both endpoints are MPRTP-
   capable.  Figure 3 shows this scenario.  In this case, host A has
   multiple interfaces.  Host B performs connectivity checks on host A's
   multiple interfaces.  If the interfaces are reachable, then host B
   streams multimedia data along multiple paths to host A. Moreover,
   host B also sends RTCP Sender Reports (SR) for each subflow and host
   A responds with a standard RTCP Receiver Report (RR) for the overall
   session and receiver statistics for each subflow.  Host B distributes
   the packets across the subflows based on the individually measured
   path characteristics.

   Alternatively, to reduce media startup time, host B may start
   streaming multimedia data to host A's initiating interface and then
   perform connectivity checks for the other interfaces.  This method of
   updating a single path session to a multipath session is called
   "multipath session upgrade".







Singh, et al.          Expires September 15, 2011               [Page 8]


Internet-Draft                Multipath RTP                   March 2011


           Host A                           Host B
   -----------------------                ----------
   Address A1   Address A2                Address B1
   -----------------------                ----------
       |            Session Setup             |
       |------------------------------------->|  connections at endpoint
       |<-------------------------------------|  may be "preloaded"
       |            |                         |  (e.g., with ICE)
       |            |                         |
       |       (RTP data B1->A1, B1->A2)      |
       |<=====================================|
       |            |<========================|
       |            |                         |
       Note: there may be more scenarios.

                    Figure 3: Unidirectional media flow

5.2.  Conversational use-case

   In the bidirectional scenario, multimedia data flows in both
   directions.  The two hosts exchange their lists of interfaces with
   each other and perform connectivity checks.  Communication begins
   after each host finds suitable address, port pairs.  Interfaces that
   receive data send back RTCP receiver statistics for that path (based
   on the 4-tuple).  The hosts balance their multimedia stream across
   multiple paths based on the per path reception statistics and its own
   volume of traffic.  Figure 4 describes an example of a bidirectional
   flow.

          Host A                               Host B
  -----------------------              -----------------------
  Address A1   Address A2              Address B1   Address B2
  -----------------------              -----------------------
    |            |                       |            |
    |            Session Setup           |            | connections at
    |----------------------------------->|            | the endpoint may
    |<-----------------------------------|            | be "preloaded"
    |            |                       |            | (e.g., ICE)
    |            |                       |            |
    |    (RTP data B1<->A1, B2<->A2)     |            |
    |<===================================|            |
    |            |<===================================|
    |===================================>|            |
    |            |===================================>|
    |            |                       |            |
      Note: the address pairs may have other permutations,
      and they may be symmetric or asymmetric combinations.




Singh, et al.          Expires September 15, 2011               [Page 9]


Internet-Draft                Multipath RTP                   March 2011


                       Figure 4: Bidirectional flow

5.3.  Challenges with Multipath Interface Discovery

   For some applications, where the user expects immediate playback,
   e.g., High Definition Media Streaming or IPTV, it may not be possible
   to perform connectivity checks within the given time bound.  In these
   cases, connectivity checks MAY need to be done ahead of time.

   [Open Issue: ICE or any other system would have to be aware of the
   endpoint's interfaces ahead of time].


6.  MPRTP Functional Blocks

   This section describes some of the functional blocks needed for
   MPRTP.  We then investigate each block and consider available
   mechanisms in the next section.

   1.  Session Setup: Multipath session setup is an upgrade or add-on to
       a typical RTP session.  Interfaces may appear or disappear at
       anytime during the session.  To preserve backward compatibility
       with legacy applications, a multipath session MUST look like a
       bundle of individual RTP sessions.

   2.  Expanding RTP: For a multipath session, each subflow MUST look
       like an independent RTP flow, so that individual RTCP messages
       can be generated per subflow.  Furthermore, MPRTP splits the
       single multimedia stream into multiple subflows based on path
       characteristics (e.g.  RTT, loss-rate, receiver rate, bandwidth-
       delay product etc.) and dynamically adjusts the load on each
       link.

   3.  Adding Interfaces: Interfaces on the host need to be regularly
       discovered and signaled.  This can be done at session setup
       and/or during the session.  When discovering and receiving new
       interfaces, the MPRTP layer needs to select address and port
       pairs.

   4.  Expanding RTCP: MPRTP MUST recombine RTCP reports from each path
       to re-create a single RTCP message to maintain backward
       compatibility with legacy applications.

   5.  Maintenance and Failure Handling: In a multi-homed endpoint
       interfaces may appear and disappear.  If this happens at the
       sender, it has to re-adjust the load on the available links.  On
       the other hand, if this occurs on the receiver, then the
       multimedia data transmitted by the sender to those interfaces is



Singh, et al.          Expires September 15, 2011              [Page 10]


Internet-Draft                Multipath RTP                   March 2011


       lost.  This data may be re-transmitted along a different path
       i.e., to a different interface on the receiver.  Furthermore, the
       receiver has to explicitly signal the disappearance of an
       interface, or the sender has to detect it.  [Open Issue: What
       happens if the interface that setup the session disappears? does
       the control channel also failover? re-start the session?]

   6.  Teardown: The MPRTP layer releases the occupied ports on the
       interfaces.


7.  Available Mechanisms within the Functional Blocks

   This section discusses some of the possible alternatives for each
   functional block mentioned in the previous section.

7.1.  Session Setup

   MPRTP session can be set up in many possible ways e.g., during
   handshake, or upgraded mid-session.  The capability exchange may be
   done using out-of-band signaling (e.g., SDP [15] in SIP [13], RTSP
   [14]) or in-band signaling (e.g., RTP/RTCP header extension).
   Furthermore, ICE [3] may be used for discovering and performing
   connectivity checks during session setup.

7.2.  Expanding RTP

   RTCP [1] is generated per media session.  However, with MPRTP, the
   media sender spreads the RTP load across several interfaces.  The
   media sender SHOULD make the path selection, load balancing and fault
   tolerance decisions based on the characteristics of each path.
   Therefore, apart from normal RTP sequence numbers defined in [1], the
   MPRTP sender MUST add subflow-specific sequence numbers to help
   calculate fractional losses, jitter, RTT, playout time, etc., for
   each path and a subflow identifier to associate the characteristics
   with a path.  The RTP header extension for MPRTP is shown in
   Section 9).

7.3.  Adding New Interfaces

   When interfaces appear and disappear mid-session, ICE [3] may be used
   for discovering interfaces and performing connectivity checks.
   However, MPRTP may require a capability re-negotiation (using SDP) to
   include all these new interfaces.  This method is referred to as out-
   of-band multipath advertisement.

   Alternatively, when new interfaces appear, the interface
   advertisements may be done in-band using RTP/RTCP extensions.  The



Singh, et al.          Expires September 15, 2011              [Page 11]


Internet-Draft                Multipath RTP                   March 2011


   endpoints perform connectivity checks (see Figure 5 for more
   details).  If the connectivity packets are received by the peers,
   then multimedia data can flow between the new address, port pairs.

7.4.  Expanding RTCP

   To provide accurate per path information an MPRTP endpoint MUST send
   (SR/RR) report for each unique subflow along with the overall session
   RTCP report.  Therefore, the additional subflow reporting affects the
   RTCP bandwidth and the RTCP reporting interval for each subflow.
   RTCP report scheduling for each subflow may cause a problem for RTCP
   recombination and reconstruction in cases when 1) RTCP for a subflow
   is lost, and 2) RTCP for a subflow arrives later than the other
   subflows.  (There may be other cases as well.)

   The sender distributes the media across different paths using the per
   path RTCP reports.  However, this document doesn't cover algorithms
   for congestion control or load balancing.

7.5.  Checking and Failure Handling

   [Note: If the original interface that setup the session disappears
   then does the session signaling failover to another interface?  Can
   we recommend that SIP/RTSP be run over MPTCP, SCTP].


8.  MPRTP Protocol

   To enable a quick start of a multimedia session, a multipath session
   MUST be upgraded from a single path session.  Therefore, no explicit
   changes are needed in multimedia session setup and the session can be
   setup as before.



















Singh, et al.          Expires September 15, 2011              [Page 12]


Internet-Draft                Multipath RTP                   March 2011


           Host A                                   Host B
   -----------------------                  -----------------------
   Address A1   Address A2                  Address B1   Address B2
   -----------------------                  -----------------------
       |            |                           |             |
       |            |      (1)                  |             |
       |--------------------------------------->|             |
       |<---------------------------------------|             |
       |            |      (2)                  |             |
       |<=======================================|             |
       |<=======================================|     (3)     |
       |            |      (4)                  |             |
       |<=======================================|             |
       |<=======================================|             |
       |<=======================================|             |
       |            |      (5)                  |             |
       |- - - - - - - - - - - - - - - - - - - ->|             |
       |<=======================================|     (6)     |
       |<=======================================|             |
       |            |<========================================|
       |<=======================================|             |
       |            |<========================================|

   Key:
   |  Interface
   ---> Signaling Protocol
   <=== RTP Packets
   - -> RTCP Packet

                       Figure 5: MPRTP New Interface

8.1.  Overview

   The bullet points explain the different steps shown in Figure 5 for
   upgrading a standard single path multimedia session to multipath
   session.

      (1) The first two interactions between the hosts represents the
      standard session setup.  This may be SIP or RTSP.

      (2) Following the setup, like in a conventional RTP scenario, host
      B using interface B1 starts to stream data to host A at interface
      A1.

      (3) Host B is an MPRTP-capable media sender and becomes aware of
      another interface B2.





Singh, et al.          Expires September 15, 2011              [Page 13]


Internet-Draft                Multipath RTP                   March 2011


      (4) Host B advertises the multiple interface addresses using an
      RTCP header extensions.

      (5) Host A is an MPRTP-capable media receiver and becomes aware of
      another interface A2.  It advertises the multiple interface
      addresses using an RTCP extension.

      Side note, even if an MPRTP-capable host has only one interface,
      it SHOULD respond to the advertisement with its single interface.

      (6) Each host receives information about the additional interfaces
      and performs the connectivity tests (not shown in figure).  If the
      paths are reachable then the host starts to stream the multimedia
      content using the additional paths.

8.1.1.  Subflow or Interface advertisement

   To advertise the multiple interfaces, an MPRTP-capable endpoint MUST
   add the MPRTP Interface Advertisement defined in Figure 6 with the
   RTCP Sender Report (SR).  Each unique address is encapsulated in an
   Interface Advertisement block and contains the IP address, RTP and
   RTCP port addresses.  The Interface Advertisement blocks are ordered
   based on a decreasing priority level.  On receiving the MPRTP
   Interface Advertisement, an MPRTP-capable receiver MUST respond with
   its own set of interfaces.

   If the sender and receiver have only one interface, then the
   endpoints MUST respond with the default IP, RTP port and RTCP port
   addresses.  If an endpoint receives an RTCP report without the MPRTP
   Interface Advertisement, then the endpoint MUST assume that the other
   endpoint is not MPRTP capable.

8.1.2.  Path selection

   After MPRTP support has been discovered and interface advertisements
   have been exchanged, the sender MUST initiate connectivity checks to
   determine which interface pairs offer valid paths between the sender
   and the receiver.  Each combination of IP addresses and port pairs
   (4-tuple) is a unique subflow.  An endpoint MUST associate a Subflow
   ID to each unique subflow.

   To initiate a connectivity check, the endpoints send an RTP packet
   using the appropriate MPRTP extension header (See Figure 10),
   associated Subflow ID and no RTP payload.  The receiving endpoint
   replies to each connectivity check with an RTCP packet with the
   appropriate packet type (See Figure 7) and Subflow ID.  After the
   endpoint receives the reply, the path is considered a valid candidate
   for sending data.  An endpoint MAY choose to do any number of



Singh, et al.          Expires September 15, 2011              [Page 14]


Internet-Draft                Multipath RTP                   March 2011


   connectivity checks for any interface pairs at any point in a
   session.

   [Open Issue: How should the endpoint adjust the RTCP Reporting
   interval/schedule the RTCP packet on receiving a connectivity check
   containing a new Subflow ID?  Editor: One option is send immediately
   as defined in [4].  Another option is the RTCP timing defined in
   [16].]

8.1.3.  Opening subflows

   The sender MAY open any number of subflows from the set of candidate
   subflows after performing connectivity checks.  To use the subflow,
   the sender simply starts sending the RTP packets with an MPRTP
   extension shown in Figure 9.  The MPRTP extension carries a mapping
   of a subflow packet to the aggregate flow.  Namely, sequence numbers
   and timestamps associated with the subflow.

   An endpoint MAY use all or a subset of candidate subflows for sending
   media packets.  To avoid redoing the connectivity checks the endpoint
   MAY send keep-alive MPRTP packets (see Section 9.2.3) to the passive
   subflows to keep the NAT bindings alive.

   [Open Issue: How to differentiate between Passive and Active
   connections?  Editor: Active paths get "regular flow" of media
   packets while passive paths are for failover of active paths. ]

   [Open Issue: How to keep a passive connection alive, if not actively
   used?  Alternatively, what is the maximum timeout?  Editor: keep-
   alive for ICE/NAT bindings should not be less than 15 seconds [3].]

8.2.  RTP Transmission

   The MPRTP layer SHOULD associate an RTP packet with a subflow based
   on a scheduling strategy.  The scheduling strategy may either choose
   to augment the paths to create higher throughput or use the alternate
   paths for enhancing resilience or error-repair.  Due to the changes
   in path characteristics, an MPRTP sender can change its scheduling
   strategy during an ongoing session.  The MPRTP sender MUST also
   populate the subflow specific fields described in the MPRTP extension
   header (see Section 9.2.1).

8.3.  Playout Considerations at the Receiver

   A media receiver, irrespective of MPRTP support or not, should be
   able to playback the media stream because the received RTP packets
   are compliant to [1], i.e., a non-MPRTP receiver will ignore the
   MPRTP header and still be able to playback the RTP packets.  However,



Singh, et al.          Expires September 15, 2011              [Page 15]


Internet-Draft                Multipath RTP                   March 2011


   the variation of jitter and loss per path may affect proper playout.
   By calculating optimum skew across all paths, the receiver can
   compensate for the jitter by modifying the playout delay (adaptive
   playout) of the received RTP packets.

8.4.  Subflow-specific RTCP Statistics and RTCP Aggregation

   Aggregate RTCP provides the overall media statistics and follows the
   standard RTCP defined in RFC3550 [1].  However, subflow specific RTCP
   provides the per path media statistics because the aggregate RTCP
   report may not provide sufficient per path information to an MPRTP
   scheduler.  Specifically, the scheduler should be aware of each
   path's RTT and loss-rate, which an aggregate RTCP cannot provide.
   The sender/receiver MUST use non-compound RTCP reports defined in
   RFC5506 [5] to transmit the aggregate and subflow-specific RTCP
   reports.  Also, each subflow and the aggregate RTCP report MUST
   follow the timing rules defined in [4].

   The RTCP reporting interval is locally implemented and the scheduling
   of the RTCP reports may depend on the the behavior of each path.  For
   instance, the RTCP interval may be different for a passive path than
   an active path to keep port bindings alive.  Additionally, an
   endpoint may decide to share the RTCP reporting bit rate equally
   across all its paths or schedule based on the receiver rate on each
   path.

8.5.  RTCP Transmission

   The sender sends an RTCP SR on each active path.  For each SR the
   receiver gets, it echoes one back to the same IP address-port pair
   that sent the SR.  The receiver tries to choose the symmetric path
   and if the routing is symmetric then the per-path RTT calculations
   will work out correctly.  However, even if the paths are not
   symmetric, the sender would at maximum, under-estimate the RTT of the
   path by a factor of half of the actual path RTT.


9.  Packet Formats

   In this section we define the protocol structures described in the
   previous sections.

9.1.  RTCP Extension for Interface advertisement

   This sub-section defines the RTCP header extension for in-band
   interface advertisement by the receiver, instead of relying on ICE or
   in situations when the interface appears after SDP session
   establishment.



Singh, et al.          Expires September 15, 2011              [Page 16]


Internet-Draft                Multipath RTP                   March 2011


   The interface advertisement SHOULD immediately follow the Receiver
   Report.  If the Receiver Report is not present, then it MUST be
   appended to the Sender Report.

   The endpoint MUST advertise all its interfaces when a new interface
   appears.  Furthermore, an endpoint MUST advertise all its interfaces
   when it receives an Interface Advertisement.

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |V=2|P|reserved | PT=MP_IA=210  |             length            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     SSRC of packet sender                     |
   +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
   |                 SSRC_1 (SSRC of first source)                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         MPR_Type=0x00        |           block length         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                Interface #1 Advertisement block               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                Interface #2 Advertisement block               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               Interface #... Advertisement block              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                Interface #m Advertisement block               |
   +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

       Figure 6: MPRTP Interface Advertisement. (appended to SR/RR)

      MP_IA: 8 bits

         Contains the constant 210 to identify this as an interface
         advertisement.

      length: 16 bits

         As described for the RTCP packet (see Section 6.4.1 of the RTP
         specification [1]), the length of this is in 32-bit words minus
         one, including the header and any padding.

      MPR_Type: 16-bits

         The MPRR_Type field corresponds to the type of MPRTP RTCP
         packet.  Namely:






Singh, et al.          Expires September 15, 2011              [Page 17]


Internet-Draft                Multipath RTP                   March 2011


    +---------------+--------------------------------------------------+
    |    MPR_Type   | Use                                              |
    |     Value     |                                                  |
    +---------------+--------------------------------------------------+
    |      0x00     | Interface Advertisement                          |
    |      0x01     | Connectivity Check. For this case the length is  |
    |               | set to 0                                         |
    |      TBD      | Keep Alive Packet.                               |
    +---------------+--------------------------------------------------+

           Figure 7: RTP header extension values for MPRTP (MPR_Type)

      block length: 16-bits

         The 16-bit length field is the length of the encapsulated
         advertisement blocks in 32-bit word length not including the
         MPR_Type and length fields.  The value zero indicates there is
         no data following.

      Interface Advertisement block: variable size

         Defined later in 9.1.1.

9.1.1.  Interface Advertisement block

   This block describes a method to represent IPv4, IPv6 and generic
   DNS-type addresses in a block format.  It is based on the sub-
   reporting block in RFC 5760 [6].

   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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Type={0,1,2}  |     Length    |          Subflow ID           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           RTCP Port           |           RTCP Port           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                            Address                            |
   +                                                               +
   :                                                               :
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       Figure 8: Interface Advertisement block during path discovery

      Type: 8 bits

         The Type corresponds to the type of address.  Namely:




Singh, et al.          Expires September 15, 2011              [Page 18]


Internet-Draft                Multipath RTP                   March 2011


            0: IPv4 address

            1: IPv6 address

            2: DNS name

      Length: 8 bits

         The length of the Interface Advertisement block in bytes.

            For an IPv4 address, this should be 9 (i.e., 5 octets for
            the header and 4 octets for IPv4 address).

            For an IPv6 address, this should be 21.

            For a DNS name, the length field indicates the number of
            octets making up the string plus the 5 byte header.

      RTP Port: 2 octets

         The port number to which the sender sends RTP data.  A port
         number of 0 is invalid and MUST NOT be used.

      RTCP Port: 2 octets

         The port number to which receivers send feedback reports.  A
         port number of 0 is invalid and MUST NOT be used.

      Address: 4 octets (IPv4), 16 octets (IPv6), or n octets (DNS name)

         The address to which receivers send feedback reports.  For IPv4
         and IPv6, fixed-length address fields are used.  A DNS name is
         an arbitrary-length string.  The string MAY contain
         Internationalizing Domain Names in Applications (IDNA) domain
         names and MUST be UTF-8 encoded [7].

9.2.  MPRTP RTP Header Extension

   The MPRTP header extension is used to 1) distribute a single RTP
   stream over multiple subflows, 2) perform connectivity checks on the
   advertised interfaces, and 3) keep-alive passive interfaces (paths).

   The header conforms to the 2-byte RTP header extension defined in
   [8].  The header extension contains a 16-bit length field that counts
   the number of 32-bit words in the extension, excluding the four-octet
   extension header (therefore zero is a valid length, see Section 5.3.1
   of [1] for details).




Singh, et al.          Expires September 15, 2011              [Page 19]


Internet-Draft                Multipath RTP                   March 2011


   To signal the use of the above RTP header extensions in SDP, the
   following URI MUST be used: urn:ietf:params:rtp-hdrext:mprtp.

9.2.1.  MPRTP RTP Extension for a Subflow

   The RTP header for each subflow is defined below:

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |V=2|P|1|  CC   |M|     PT      |       sequence number         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           timestamp                           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |           synchronization source (SSRC) identifier            |
      +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
      |      0x10     |     0x00      |        len=N-1 words          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    H-Ext ID   |    length     |          Subflow ID           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  Subflow-specific Seq Number  |    Pad (0)    |   Pad (0)     |
      +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
      |                         RTP payload                           |
      |                             ....                              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                    Figure 9: MPRTP header for subflow

      H-Ext ID and length: 8-bits each

         The field corresponds to the type of MPRTP packet.  Namely:

    +---------------+--------------------------------------------------+
    |    H-Ext ID   | Use                                              |
    |     Value     |                                                  |
    +---------------+--------------------------------------------------+
    |      0x00     | Subflow RTP Header. For this case the Length is  |
    |               | set to 6                                         |
    |      0x01     | Connectivity Check. For this case the length is  |
    |               | set to 0                                         |
    |      TBD      | Keep Alive Packet.                               |
    +---------------+--------------------------------------------------+

           Figure 10: RTP header extension values for MPRTP (H-Ext ID)

      length





Singh, et al.          Expires September 15, 2011              [Page 20]


Internet-Draft                Multipath RTP                   March 2011


         The 8-bit length field is the length of extension data in bytes
         not including the H-Ext ID and length fields.  The value zero
         indicates there is no data following.

      Subflow ID: Identifier of the subflow.  Every RTP packet belonging
      to the same subflow carries the same unique subflow identifier.

      Flow-Specific Sequence Number (FSSN): Sequence of the packet in
      the subflow.  Each subflow has its own strictly monotonically
      increasing sequence number space.

9.2.2.  MPRTP RTP Extension for Connectivity Checks

   [Open Issue: What sequence number to use for the RTP session?
   Alternative 1: An MPRTP receiver MUST NOT send the packet with H-Ext
   ID=0x01 to the decoder and ignore these packets from RTCP
   calculation.  Alternative 2: Instead of sending an RTP packet the
   sender transmits a modified STUN packet.]

9.2.3.  MPRTP RTP Extension for Keep-alive Packets

   [Editor: Waiting for the progress on RTCP guidelines for the RTP keep
   alive packet [16].

9.3.  MPRTP Extension for Subflow Reporting (MPRTCP)

   The MPRTP RTCP header extension is used to 1) provide RTCP feedback
   per subflow to determine the characteristics of each path, 2) perform
   connectivity check on the other endpoint's interfaces, and 3) to keep
   alive a passive connection.

9.3.1.  MPRTCP Generic Extension

   When sending a report for a specific subflow the sender or receiver
   MUST add only the reports associated with that 4-tuple.  Each subflow
   is reported independently using the following MPRTCP Feedback header.















Singh, et al.          Expires September 15, 2011              [Page 21]


Internet-Draft                Multipath RTP                   March 2011


    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |V=2|P|reserved |   PT=SFR=211  |             length            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ H
   |                         SSRC of sender                        | D
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ R
   |         Subflow ID #1         |            reserved           |
   +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
   |                    Subflow-specific reports                   |
   |                             ....                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |V=2|P|reserved |   PT=SFR=211  |             length            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ H
   |                         SSRC of sender                        | D
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ R
   |         Subflow ID #2         |            reserved           |
   +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
   |                    Subflow-specific reports                   |
   |                             ....                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                 Figure 11: MPRTCP Generic Feedback Header

   Subflow ID: 16 bits

      Subflow identifier is the value associated with the subflow the
      endpoint is reporting about.  If it is a sender it MUST use the
      Subflow ID associated with the 4-tuple.  If it is a receiver it
      MUST use the Subflow ID received in the Subflow-specific Sender
      Report.

   length: 16 bits

      The length of this RTCP packet in 32-bit words minus one,
      including the header and any padding.  It MUST contain at least
      one subflow report, for e.g., Sender Subflow Report, Receiver
      Subflow Report, or Subflow Extension Reports, etc.

   Subflow-specific reports: variable

      Subflow-specific report contains all the reports associated with
      the Subflow ID.  For a sender, it MUST include the Subflow-
      specific Sender Report (SSR).  For a receiver, it MUST include
      Subflow-specific Receiver Report (SRR).  Additionally, if the
      receiver supports subflow-specific extension reports then it MUST
      append them to the SRR.




Singh, et al.          Expires September 15, 2011              [Page 22]


Internet-Draft                Multipath RTP                   March 2011


9.3.2.  MPRTCP for Subflow-specific SR, RR and XR

   [Editor: inside the context of subflow specific reports can we reuse
   the payload type code for Sender Report (PT=200), Receiver Report
   (PT=201), Extension Report (PT=207).  Transport and Payload specific
   RTCP messages are session specific and SHOULD be used as before.]

   Example:











































Singh, et al.          Expires September 15, 2011              [Page 23]


Internet-Draft                Multipath RTP                   March 2011


    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |V=2|P|reserved |   PT=SFR=211  |            length=9           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ H
   |                         SSRC of sender                        | D
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ R
   |         Subflow ID #1         |            reserved           |
   +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
   |V=2|P|    RC   |   PT=SR=200   |             length            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         SSRC of sender                        |
   +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
   |              NTP timestamp, most significant word             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |             NTP timestamp, least significant word             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         RTP timestamp                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    subflow's packet count                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     subflow's octet count                     |
   +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
   |V=2|P|reserved |   PT=SFR=211  |             length            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ H
   |                         SSRC of sender                        | D
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ R
   |         Subflow ID #2         |            reserved           |
   +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
   |V=2|P|    RC   |   PT=RR=201   |             length            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     SSRC of packet sender                     |
   +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
   | fraction lost |       cumulative number of packets lost       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           extended highest sequence number received           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      interarrival jitter                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         last SR (LSR)                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   delay since last SR (DLSR)                  |
   +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
   |               Subflow specific extension reports              |
   |                             ....                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Figure 12: Example of reusing RTCP SR and RR inside an MPRTCP header



Singh, et al.          Expires September 15, 2011              [Page 24]


Internet-Draft                Multipath RTP                   March 2011


                        (Bi-directional use-case).


10.  SDP Considerations

   The packet formats specified in this document define extensions for
   RTP and RTCP.  The use of MPRTP is left to the discretion of the
   sender and receiver.

   A participant of a media session MAY use SDP to signal that it
   supports MPRTP.  Not providing this information may/will make the
   sender or receiver ignore the header extensions.  However, MPRTP MAY
   be used by either sender or receiver without prior signaling.

       mprtp-attrib = "a=" "mprtp" [":"
               mprtp-optional-parameter]
               CRLF   ; flag to enable MPRTP

   The literal 'mprtp' MUST be used to indicate support for MPRTP.
   Generally, senders and receivers SHOULD indicate this capability if
   they support MPRTP and would like to use it in the specific media
   session being signaled.  However, it is possible for an MPRTP sender
   to stream data using multiple paths to a non-MPRTP client.

   Currently, there are no extensions defined for the literal 'mprtp'
   but we provide the opportunity to extend it using the mprtp-optional-
   parameter.

10.1.  Increased Throughput

   The MPRTP layer MAY choose to augment paths to increase throughput.
   If the desired media rate exceeds the current media rate, the
   endpoints MUST renegotiate the application specific ("b=AS:") [17]
   bandwidth.

10.2.  Increased Reliability

   TBD

10.3.  MPRTP using preloaded interfaces from ICE

   TBD


11.  IANA Considerations

   This document defines a new SDP attribute, "mprtp", within the
   existing IANA registry of SDP Parameters.



Singh, et al.          Expires September 15, 2011              [Page 25]


Internet-Draft                Multipath RTP                   March 2011


   TBD.


12.  Security Considerations

   All drafts are required to have a security considerations section.
   See RFC 3552 [18] for a guide.


13.  Acknowledgements

   Varun Singh, Saba Ahsan, and Teemu Karkkainen are supported by
   Trilogy (http://www.trilogy-project.org), a research project (ICT-
   216372) partially funded by the European Community under its Seventh
   Framework Program.  The views expressed here are those of the
   author(s) only.  The European Commission is not liable for any use
   that may be made of the information in this document.


14.  References

14.1.  Normative References

   [1]   Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson,
         "RTP: A Transport Protocol for Real-Time Applications", STD 64,
         RFC 3550, July 2003.

   [2]   Bradner, S., "Key words for use in RFCs to Indicate Requirement
         Levels", BCP 14, RFC 2119, March 1997.

   [3]   Rosenberg, J., "Interactive Connectivity Establishment (ICE): A
         Protocol for Network Address Translator (NAT) Traversal for
         Offer/Answer Protocols", RFC 5245, April 2010.

   [4]   Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey,
         "Extended RTP Profile for Real-time Transport Control Protocol
         (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, July 2006.

   [5]   Johansson, I. and M. Westerlund, "Support for Reduced-Size
         Real-Time Transport Control Protocol (RTCP): Opportunities and
         Consequences", RFC 5506, April 2009.

   [6]   Ott, J., Chesterfield, J., and E. Schooler, "RTP Control
         Protocol (RTCP) Extensions for Single-Source Multicast Sessions
         with Unicast Feedback", RFC 5760, February 2010.

   [7]   Yergeau, F., "UTF-8, a transformation format of ISO 10646",
         STD 63, RFC 3629, November 2003.



Singh, et al.          Expires September 15, 2011              [Page 26]


Internet-Draft                Multipath RTP                   March 2011


   [8]   Singer, D. and H. Desineni, "A General Mechanism for RTP Header
         Extensions", RFC 5285, July 2008.

14.2.  Informative References

   [9]   Stewart, R., "Stream Control Transmission Protocol", RFC 4960,
         September 2007.

   [10]  Ford, A., Raiciu, C., Handley, M., Barre, S., and J. Iyengar,
         "Architectural Guidelines for Multipath TCP Development",
         draft-ietf-mptcp-architecture-05 (work in progress),
         January 2011.

   [11]  Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming Shim
         Protocol for IPv6", RFC 5533, June 2009.

   [12]  Westerlund, M. and S. Wenger, "RTP Topologies", RFC 5117,
         January 2008.

   [13]  Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
         Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
         Session Initiation Protocol", RFC 3261, June 2002.

   [14]  Schulzrinne, H., Rao, A., Lanphier, R., Westerlund, M., and M.
         Stiemerling, "Real Time Streaming Protocol 2.0 (RTSP)",
         draft-ietf-mmusic-rfc2326bis-27 (work in progress), March 2011.

   [15]  Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with
         Session Description Protocol (SDP)", RFC 3264, June 2002.

   [16]  Marjou, X. and A. Sollaud, "Application Mechanism for keeping
         alive the Network Address Translator (NAT) mappings associated
         to RTP/RTCP flows.", draft-ietf-avt-app-rtp-keepalive-10 (work
         in progress), March 2011.

   [17]  Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
         Description Protocol", RFC 4566, July 2006.

   [18]  Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on
         Security Considerations", BCP 72, RFC 3552, July 2003.











Singh, et al.          Expires September 15, 2011              [Page 27]


Internet-Draft                Multipath RTP                   March 2011


Authors' Addresses

   Varun Singh
   Aalto University
   School of Science and Technology
   Otakaari 5 A
   Espoo, FIN  02150
   Finland

   Email: varun@comnet.tkk.fi
   URI:   http://www.netlab.tkk.fi/~varun/


   Teemu Karkkainen
   Aalto University
   School of Science and Technology
   Otakaari 5 A
   Espoo, FIN  02150
   Finland

   Email: teemuk@comnet.tkk.fi


   Joerg Ott
   Aalto University
   School of Science and Technology
   Otakaari 5 A
   Espoo, FIN  02150
   Finland

   Email: jo@comnet.tkk.fi


   Saba Ahsan
   Aalto University
   School of Science and Technology
   Otakaari 5 A
   Espoo, FIN  02150
   Finland

   Email: sahsan@cc.hut.fi










Singh, et al.          Expires September 15, 2011              [Page 28]


Internet-Draft                Multipath RTP                   March 2011


   Lars Eggert
   Nokia Research Center
   P.O. Box 407
   Nokia Group  00045
   Finland

   Phone: +358 50 48 24461
   Email: lars.eggert@nokia.com
   URI:   http://research.nokia.com/people/lars_eggert










































Singh, et al.          Expires September 15, 2011              [Page 29]