[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06 07 08

Network Working Group                                             W. Lei
Internet-Draft                                                  W. Zhang
Intended Status: Experimental                                     S. Liu
Expires: July 24, 2017                           Northeastern University
                                                        January 24, 2017


                 Multipath Real-Time Transport Protocol
              Based on Application-Level Relay (MPRTP-AR)
                    draft-leiwm-avtcore-mprtp-ar-07


Abstract

   Currently, most multimedia applications utilize a combination of
   real-time transport protocol (RTP) and user datagram protocol (UDP).
   Application programs at the source end format payload data into RTP
   packets using RTP specifications and dispatch them using unreliable
   UDP along a single path. Multipath transport is an important way to
   improve the efficiency of data delivery. In order to apply the
   framework of multipath transport system based on application-level
   relay (MPTS-AR) to RTP-based multimedia applications, this document
   defines a multipath real-time transport protocol based on
   application-level relay (MPRTP-AR), which is a concrete
   application-specific multipath transport protocol (MPTP). Packet
   formats and packet types of MPRTP-AR follow the common rules
   specified in MPTP profile. Based on MPRTP-AR, RTP-based multimedia
   applications can make full use of the advantages brought by MPTS-AR.

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 July 24, 2017.


Leiwm, et al.            Expires July 24, 2017                  [Page 1]


Internet-Draft                  MPRTP-AR                January 24, 2017

Copyright Notice

   Copyright (c) 2015 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  . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . .  3
   3. Overview  . . . . . . . . . . . . . . . . . . . . . . . . . . .  3
   4. MPRTP-AR User Agent Behavior  . . . . . . . . . . . . . . . . .  5
     4.1 Flow Partitioning  . . . . . . . . . . . . . . . . . . . . .  5
     4.2 Subflow Packaging  . . . . . . . . . . . . . . . . . . . . .  6
     4.3 Subflow and Flow Recombination . . . . . . . . . . . . . . .  6
     4.4 Subflow Reporting  . . . . . . . . . . . . . . . . . . . . .  6
     4.5 Flow Reporting . . . . . . . . . . . . . . . . . . . . . . .  7
   5. MPRTP-AR Packet Format  . . . . . . . . . . . . . . . . . . . .  8
     5.1 MPRTP-AR Data Packet . . . . . . . . . . . . . . . . . . . .  8
       5.1.1 MPRTP-AR Data Packet for RTP packet  . . . . . . . . . .  8
       5.1.2 MPRTP-AR Data Packet for RTCP packet . . . . . . . . . .  9
     5.2 MPRTP-AR Control Packet  . . . . . . . . . . . . . . . . . . 10
       5.2.1 MPRTP-AR Subflow Sender Report . . . . . . . . . . . . . 10
       5.2.2 MPRTP-AR Subflow Receiver Report . . . . . . . . . . . . 12
       5.2.3 MPRTP-AR keep-alive packet . . . . . . . . . . . . . . . 14
       5.2.4 MPRTP-AR Flow Recombination Report . . . . . . . . . . . 14
   6. SDP Considerations  . . . . . . . . . . . . . . . . . . . . . . 15
     6.1 Signaling MPTP Capability in SDP . . . . . . . . . . . . . . 16
     6.2 An Offer/Answer Example  . . . . . . . . . . . . . . . . . . 16
   7. Security Considerations . . . . . . . . . . . . . . . . . . . . 18
   8. References  . . . . . . . . . . . . . . . . . . . . . . . . . . 18
     8.1 Normative References . . . . . . . . . . . . . . . . . . . . 18
     8.2 Informative References . . . . . . . . . . . . . . . . . . . 18
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20









Leiwm, et al.            Expires July 24, 2017                  [Page 2]


Internet-Draft                  MPRTP-AR                January 24, 2017


1. Introduction

   Currently, most multimedia applications utilize a combination of
   real-time transport protocol (RTP) [1] and user datagram protocol
   (UDP). Application programs at the source end format payload data
   into RTP packets using RTP specifications and dispatch them using
   unreliable UDP along a single path. Multipath transport is an
   important way to improve the efficiency of data delivery. In order to
   apply the framework of multipath transport system based on
   application-level relay (MPTS-AR) [12] to RTP-based multimedia
   applications, this document defines a multipath real-time transport
   protocol based on application-level relay (MPRTP-AR), which is a
   concrete application-specific multipath transport protocol (MPTP).
   Packet formats and packet types of MPRTP-AR follow the common rules
   specified in MPTP profile [12]. Based on MPRTP-AR, RTP-based
   multimedia applications can make full use of the advantages brought
   by MPTS-AR.

2. Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].

3. Overview

   The protocol stack architecture of the MPRTP-AR is shown in figure 1.
   MPRTP-AR is divided into two sub-layers: RTP sub-layer and multipath
   transport control (MPTC) sub-layer. RTP sub-layer is fully compatible
   with the existing RTP specifications and provides upper applications
   with the same application programming interfaces (APIs) as those
   provided by normal RTP. MPTC sub-layer provides essential support for
   multipath transport, including path management, flow partitioning,
   subflow packaging, subflow recombination, subflow reporting and so
   on. At the user agent sender, RTP sub-layer first formats the data
   received from upper application into RTP packets and then passes them
   to lower MPTC sub-layer. MPTC sub-layer further formats the RTP
   packets into MPRTP-AR data packets. At the user agent receiver, MPTC
   sub-layer extracts the RTP/RTCP packet by removing the fixed header
   fields of MPRTP-AR data packet from the received packet and passes it
   directly to upper RTP sub-layer. RTP sub-layer follows the normal
   process defined in RTP specification to restore original data flow.
   This design decision is to maximize backwards compatibility with
   existing RTP applications. Moreover, MPRTP-AR can make full use of
   real-time transport functions provided by normal RTP including
   payload type identification, sequence numbering, timestamping and so
   on.




Leiwm, et al.            Expires July 24, 2017                  [Page 3]


Internet-Draft                  MPRTP-AR                January 24, 2017


            +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
            |       RTP-based multimedia Applications         |
            |    (VoIP, video conference, streaming, ...)     |
            +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                ^
                                | Application Programming
                                | Interfaces (APIs)
                                V
            +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   MPRTP-AR |                RTP sub-layer                    |
   layer    +- - - - - - - - - - - - - - - - - - - - - - - - -+
            |                MPTC sub-layer                   |
            +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
            |                    UDP                          |
            +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
            |                    IP                           |
            +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

          Figure 1. The protocol stack architecture of MPRTP-AR

   As defined in MPTP profile, MPRTP-AR packets are divided into two
   types: MPRTP-AR data packets and MPRTP-AR control packets. MPRTP-AR
   control packets include MPRTP-AR keep-alive packets and MPRTP-AR
   report packets.

   Besides RTP packets, RTP sub-layer generates real-time transport
   control (RTCP) packets following the normal RTCP defined in [1] to
   provide the overall media transport statistics. So, payload content
   of MPTC sub-layer includes both RTP packets and RTCP packets. In MPTC
   sub-layer, each RTP/RTCP packet is treated as an independent piece of
   payload data and packaged into an individual MPRTP-AR data packet.
   RTCP packets may be treated the exact same as RTP packets which are
   distributed across multiple paths. In addition, as described in RTP
   specification, RTCP traffic is limited to a small fraction of the
   session bandwidth, which is recommended no more than five percent.
   So, RTCP packets may also be treated differently from RTP packets and
   delivered along any one of active paths, such as the default path or
   the best path among all active paths based on quality of delivery.

   When RTP and RTCP packets are multiplexed, the RTCP packet type field
   occupies the same position in the packet as the combination of the
   RTP marker (M) bit and the RTP payload type (PT). This field is used
   to distinguish RTP and RTCP packets. It is RECOMMENDED that RTP
   sub-layer follows the guidelines in the RTP/AVP profile [3] for the
   choice of RTP payload type values, with the additional restriction in
   [4].

   MPRTP-AR keep-alive packets are used to keep relay paths alive



Leiwm, et al.            Expires July 24, 2017                  [Page 4]


Internet-Draft                  MPRTP-AR                January 24, 2017


   actively by user agent. The user agent sender generates MPRTP-AR
   keep-alive packets periodically for both active paths and non-active
   paths and sends them along the associated path. The user agent
   receiver does nothing when receiving MPRTP-AR keep-alive packets.

   MPRTP-AR report packets are used to monitor the transport quality of
   each active path and multiple concurrent paths. MPRTP-AR-aware user
   agent MUST generate individual MPRTP-AR report packets for per
   subflow. The user agent sender generates MPRTP-AR Subflow Sender
   Report (SSR) packets for each subflow and sends them along the
   associated active path. The user agent receiver generates a MPRTP-AR
   Subflow Receiver Report (SRR) packet when receiving a MPRTP-AR SSR
   packet and sends it along the default path. In addition, the user
   agent receiver optionally generates MPRTP-AR Flow Recombination
   Report (FRR) packets for the whole flow and send them to the user
   agent sender along the default path. The user agent sender may modify
   its strategies of flow partitioning and scheduling based on the
   transport quality feedback in MPRTP-AR SRR and FRR packets.

4. MPRTP-AR User Agent Behavior

   In addition to user agent behaviors defined in [12], MPRTP-AR user
   agent needs to follow the following behaviors to support multipath
   transport for RTP-based multimedia applications.

4.1 Flow Partitioning

   If multiple paths are used concurrently, the original multimedia
   stream should be divided into several substreams. Considering the
   characteristics of multimedia data, flow partitioning may be done
   based on a number of factors, such as media type, encoding scheme and
   path characteristics. Flow partitioning methods can be divided into
   coding-aware partitioning methods and coding-unaware partitioning
   methods. Coding-unaware partitioning methods can be performed in MPTC
   sub-layer. MPTC sub-layer does not care what media type (such as
   audio and video) the payload data is and what coding method the
   payload data uses. MPTC sub-layer dispatches the formatted RTP/RTCP
   packets passed from upper RTP sub-layer to multiple subflows
   evenly based on the local information maintained, such as the
   delivery quality of the associated active paths.

   For multimedia applications, a multistream coder using layered
   coding, multiple description coding or object-oriented coding can
   produce multiple compressed media flows. In this case, coding-aware
   partitioning methods could be performed in RTP sub-layer. In layered
   coding, a flow is either the base layer or one of the enhancement
   layers; in multiple description coding, a flow typically consists of
   packets from a description; in object-oriented coding, various



Leiwm, et al.            Expires July 24, 2017                  [Page 5]


Internet-Draft                  MPRTP-AR                January 24, 2017


   objects are coded individually and placed in so-called elementary
   steams. Each coding flow corresponds to a separate subflow, or
   several coding flows are multiplexed into one subflow. Data
   participant in this way can effectively reduce the correlations among
   subflows and adverse impact of different transport qualities among
   multiple paths on the final quality of media data received in the
   receiving end.

4.2 Subflow Packaging

   For each subflow, the assigned RTP packets are treated as payload
   data and formatted into MPRTP-AR data packets. The initial SSSN is
   randomly generated when the subflow is first established and the SSSN
   in subsequent subflow MPRTP-AR data packets for RTP packets is
   monotonically increasing. The flow sequence number increments by one
   for each assigned RTP packet from upper application. The initial
   value of flow the sequence number SHOULD be random.

   The assigned RTCP packets are also formatted into MPRTP-AR data
   packets except for the difference that the SSSN and FSN are fixed to
   zero.

4.3 Subflow and Flow Recombination

   The user agent receiver recombines the original data flow according
   to MPRTP-AR data packets received from multiple paths. After
   receiving a MPRTP-AR data packet, MPTC sub-layer first extracts the
   RTP/RTCP packet by removing the fixed header fields of MPTP data
   packet from the received packet and passes it directly to upper RTP
   sub-layer. MPTC sub-layer has no need to restore firstly the order of
   each subflow using path identifier and SSSN in MPTP data packet
   headers before passing the encapsulated RTP/RTCP packets up to RTP
   sub-layer. The RTP sub-layer follows the normal process defined in
   RTP specification to recombine the original data flow.

4.4 Subflow Reporting

   User agent generates MPRTP-AR report packets for per subflow to
   monitor the quality of path delivery. The user agent sender generates
   MPRTP-AR Subflow Sender Report (SSR) packets for each subflow and
   sends them along the associated active path. The user agent receiver
   generates a MPRTP-AR Subflow Receiver Report (SRR) packets when
   receiving a MPRTP-AR SSR and sends it along the default path.

   The user agent sender calculates the transmission interval of
   MPRTP-AR SSR packets according to some strategy. The user agent
   sender may generate MPRTP-AR SSR packets at a constant rate. In this
   case, it is recommended that the default interval of MPRTP-AR SSR



Leiwm, et al.            Expires July 24, 2017                  [Page 6]


Internet-Draft                  MPRTP-AR                January 24, 2017


   packets be one second. The user agent sender may also generate
   MPRTP-AR SSR packets at a variable rate. For example, the report
   traffic is limited to a small fraction of the associated subflow data
   traffic. In this case, it is recommended that the fraction of the
   subflow data traffic added for subflow report be fixed at 5%, which
   makes reference to the recommended value in RTP specification.

   Reception quality feedback is useful for the user agent sender who
   may modify its strategies of flow partitioning and scheduling based
   on the estimated transport qualities of multiple paths.

   Cumulative counts are used in both the MPRTP-AR SSR and SRR packets
   so that differences may be calculated between any two reports to make
   measurements over both short and long time periods, and to provide
   resilience against the loss of a report. The difference between the
   last two reports received can be used to estimate the recent
   transport quality of the associated path. The difference between the
   two reports with a longer time interval can be used to estimate the
   long-term transport quality of the associated path. The NTP timestamp
   is also included so that rates may be calculated from these
   differences over the interval between two reports.

   An example calculation is the packet loss rate over the interval
   between two MPRTP-AR SRR packets. The difference in the cumulative
   number of packets lost gives the number lost during that interval.
   The difference in the highest SSSNs received gives the number of
   packets expected during the interval. The ratio of these two is the
   packet loss fraction over the interval. This ratio provides a
   short-term packet loss measurement if the two reports are
   consecutive. The loss rate per second can be obtained by dividing the
   loss fraction by the difference in NTP timestamps, expressed in
   seconds. The number of packets received is the number of packets
   expected minus the number lost.

   In addition to the cumulative counts which allow both long-term and
   short-term measurements using differences between reports, MPRTP-AR
   SRR packets include an interarrival jitter field which provides
   short-term measurement of network congestion from a single report.
   Packet loss tracks persistent congestion while the jitter measure
   tracks transient congestion. The jitter measure may indicate
   congestion before it leads to packet loss. The interarrival jitter
   field is only a snapshot of the jitter at the time of a report and is
   not intended to be taken quantitatively. Rather, it is intended for
   comparison across a number of reports.

4.5 Flow Reporting

   The user agent receiver optionally generates MPRTP-AR Flow



Leiwm, et al.            Expires July 24, 2017                  [Page 7]


Internet-Draft                  MPRTP-AR                January 24, 2017


   Recombination Report (FRR) packets for the whole recombined flow and
   sends them to the user agent sender along the default path. Real-time
   applications are generally latency- and loss rate-sensitive.
   Therefore, the flow recombination reports include the cumulative
   packet loss rate and interarrival jitter caused by out-of-order
   packets which arrive at the receiver along different paths. The user
   agent receiver calculates the transmission interval of MPRTP-AR FRR
   packets according to some strategy. In this document, it is
   recommended that the default interval of MPRTP-AR FRR packets be one
   second.

5. MPRTP-AR Packet Format

   Packet types and packet formats of MPRTP-AR follow the common rules
   specified in MPTP profile. As defined in MPTP profile, MPRTP-AR
   packets are divided into two types: MPRTP-AR data packets and
   MPRTP-AR control packets. MPRTP-AR control packets include MPRTP-AR
   keep-alive packets and MPRTP-AR report packets. For all the MPRTP-AR
   packets, the application-specific MPTP type (AMT) field in the fixed
   MPTP header is set to 1.

5.1 MPRTP-AR Data Packet

   As stated in section 3, the RTP packets and RTCP packets are packaged
   into MPRTP-AR data packets intact. Each RTP packet and RTCP packet
   corresponds to a MPRTP-AR data packet.

5.1.1 MPRTP-AR Data Packet for RTP packet

   A MPRTP-AR data packet carrying a RTP packet consists of a fixed
   eight-octet MPTP header and an intact RTP packet. An example is shown
   below:



















Leiwm, et al.            Expires July 24, 2017                  [Page 8]


Internet-Draft                  MPRTP-AR                January 24, 2017


        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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
MPTP   |V=1|1|P| AMT=1 |0|1|0|0| rsvd  |             SSSN              |
header +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                      Path Identifier                          |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                    Flow Sequence Number                       |
       +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
RTP    |V=2|P|X|  CC   |M|     PT      |       sequence number         |
packet +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                         RTP timestamp                         |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |           synchronization source (SSRC) identifier            |
       +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
       |            contributing source (CSRC) identifiers             |
       |                             ....                              |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The MPTP packet type (T) field is set to 1 to indicate that this
   packet is a MPRTP-AR data packet.

   The application-specific MPTP type (AMT) field is set to 1 to
   indicate that this packet is a MPRTP-AR packet.

   For RTP-based multimedia applications, latency and jitter are the
   primary concerns, and occasional packet lost is acceptable. So the
   delay bit in the type of service (TOS) field is set to indicate that
   prompt delivery is important for this packet.

   The initial SSSN is randomly generated when the subflow is first
   established. The SSSN is increased by one for each subsequent
   MPRTP-AR data packets carrying RTP packets of the same subflow.

   The initial FSN is randomly generated when the multipath session is
   first established. The FSN is increased by one for each RTP packet.

5.1.2 MPRTP-AR Data Packet for RTCP packet

   A MPRTP-AR data packet carrying a RTCP packet consists of a fixed
   eight-octet MPTP header and an intact RTCP packet. An example is
   shown below:









Leiwm, et al.            Expires July 24, 2017                  [Page 9]


Internet-Draft                  MPRTP-AR                January 24, 2017


        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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
MPTP   |V=1|1|P| AMT=1 |1|0|0|1| rsvd  |           SSSN=0              |
header +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                      Path Identifier                          |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                  Flow Sequence Number=0                       |
       +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
RTCP   |V=2|P|    RC   |      PT       |             length            |
packet +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                     SSRC of packet sender                     |
       +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
       |                             ....                              |
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The MPTP packet type (T) field is set to indicate that this packet
   is a MPRTP-AR data packet.

   The application-specific MPTP type (AMT) field is set to 1 to
   indicate that this packet is a MPRTP-AR packet.

   In a RTP session, RTCP packets have higher transmission requirements
   of precedence and reliability than RTP packets. So the precedence and
   reliability bits of the type of service (TOS) field are set to
   indicate that the payload data in this MPTP data packet is more
   important and requires a higher level of effort to ensure delivery.

   The SSSN field and FSN field in MPRTP-AR data packets carrying RTCP
   packets are fixed to zero.

5.2 MPRTP-AR Control Packet

   MPRTP-AR control packets include MPRTP-AR keep-alive packets and
   MPRTP-AR report packets. MPRTP-AR report packets include MPRTP-AR
   Subflow Sender Report (SSR) packets, MPRTP-AR Subflow Receiver Report
   (SRR) packets, and MPRTP-AR Flow Recombination Report (FRR) packets.

5.2.1 MPRTP-AR Subflow Sender Report











Leiwm, et al.            Expires July 24, 2017                 [Page 10]


Internet-Draft                  MPRTP-AR                January 24, 2017


    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=1|0|P| AMT=1 |      CT=1     |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Path Identifier                          |
   +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
   |              NTP timestamp, most significant word             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |             NTP timestamp, least significant word             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    subflow's packet count                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     subflow's octet count                     |
   +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

   MPRTP-AR SSR summarizes the data transmissions of the associated
   subflow. The fields have the following meaning:

   The MPTP packet type (T) field is set to zero to indicate that this
   packet is a MPRTP-AR control packet.

   The application-specific MPTP type (AMT) field is set to 1 to
   indicate that this packet is a MPRTP-AR packet whose packet formats
   follow the rules specified in this document.

   The MPTP control packet type field is set to 1 to indicate that this
   packet is a MPRTP-AR SSR.

   NTP timestamp: 64 bits
      Indicates the wallclock time when this report was sent so that it
      may be used in combination with timestamps returned in receiver
      reports to measure round-trip propagation to the user agent
      receiver.

      Wallclock time (absolute date and time) is represented using the
      timestamp format of the Network Time Protocol (NTP), which is in
      seconds relative to 0h UTC on 1 January 1900 [5]. The full
      resolution NTP timestamp is a 64-bit unsigned fixed-point number
      with the integer part in the first 32 bits and the fractional part
      in the last 32 bits. An implementation is not required to run the
      Network Time Protocol in order to use this MPTP extension. On a
      system that has no notion of wallclock time but does have some
      system-specific clock such as "system uptime", a user agent sender
      MAY use that clock as a reference to calculate relative NTP
      timestamps.

   subflow's packet count: 32 bits



Leiwm, et al.            Expires July 24, 2017                 [Page 11]


Internet-Draft                  MPRTP-AR                January 24, 2017


      The total number of MPRTP-AR data packets with non-zero SSSN value
      transmitted within a subflow by the user agent sender since
      starting transmission up until the time this MPRTP-AR SSR packet
      was generated.

   subflow's octet count: 32 bits
      The total number of payload octets (i.e., not including header or
      padding) transmitted in MPRTP-AR data packets by the user agent
      sender since starting transmission up until the time this MPRTP-AR
      SSR packet was generated. This field can be used to estimate the
      average payload data rate.

5.2.2 MPRTP-AR Subflow Receiver Report

    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=1|0|P| AMT=1  |     CT=2     |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Path Identifier                          |
   +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
   |    highest SSSN received      | cumulative num of packets lost|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      interarrival jitter                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         last SSR (LSR)                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   delay since last SSR (DLSR)                 |
   +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

   MPRTP-AR SRR conveys statistics on the reception of MPTP data packets
   from a single subflow. The fields have the following meaning:

   The MPTP packet type (T) field is set to zero to indicate that this
   packet is a MPRTP-AR control packet.

   The application-specific MPTP type (AMT) field is set to 1 to
   indicate that this packet is a MPRTP-AR packet.

   The MPTP control packet type field is set to 2 to indicate that this
   packet is a MPRTP-AR SRR.

   The highest subflow-specific sequence number (SSSN) received: 16 bits
      The highest subflow-specific sequence number received in an
      MPRTP-AR data packet from a subflow.

   Cumulative number of packets lost: 16 bits
      The total number of MPRTP-AR data packets from a subflow that have



Leiwm, et al.            Expires July 24, 2017                 [Page 12]


Internet-Draft                  MPRTP-AR                January 24, 2017


      been lost since the beginning of reception. Note that a user agent
      receiver cannot tell whether any packets were lost after the last
      one received. This number is defined to be the number of packets
      expected less the number of packets actually received. The number
      of packets expected is defined to be the highest SSSN of MPTP data
      packets received less the initial SSSN received. The number of
      packets received includes any which are late. Thus, packets that
      arrive late are not counted as lost.

   Interarrival jitter: 32 bits
      An estimate of the statistical variance of the interarrival time
      of the MPRTP-AR data packets with non-zero SSSN value in a
      subflow, measured in timestamp units and expressed as an unsigned
      integer. The interarrival jitter J is defined to be the mean
      deviation (smoothed absolute value) of the difference D in packet
      spacing at the user agent receiver compared to the user agent
      sender for a pair of successive packets in a subflow. As shown in
      the equation below, the difference D is also equivalent to the
      difference in the "relative transit time" for the two successive
      packets; the relative transit time is the difference between a
      packet's RTP timestamp and the user agent receiver's clock at the
      time of arrival, measured in the same units.

      If Si is the RTP timestamp from packet i, and Ri is the time of
      arrival in RTP timestamp units for packet i, then for two packets
      i and j, D may be expressed as

         D(i,j) = (Rj - Ri) - (Sj - Si) = (Rj - Sj) - (Ri - Si)

      The interarrival jitter SHOULD be calculated continuously as each
      MPTP data packet with non-zero SSSN value i is received from a
      subflow, using this difference D for that packet and the previous
      packet i-1 in order of arrival (not necessarily in sequence),
      according to the formula

         J(i) = J(i-1) + (|D(i-1,i)| - J(i-1))/16

      This algorithm is the optimal first-order estimator and the gain
      parameter 1/16 gives a good noise reduction ratio while
      maintaining a reasonable rate of convergence [11].

      Whenever a MPRTP-AR SRR is issued, the current value of J is
      sampled.

   Last SSR timestamp (LSR): 32 bits
      The middle 32 bits out of 64 in the NTP timestamp received as part
      of the most recent MPRTP-AR SSR from a subflow. If no MPRTP-AR SSR
      has been received yet, the field is set to zero.



Leiwm, et al.            Expires July 24, 2017                 [Page 13]


Internet-Draft                  MPRTP-AR                January 24, 2017


   Delay since last SSR (DLSR): 32 bits
      The delay, expressed in units of 1/65536 seconds, between
      receiving the last MPRTP-AR SSR from a subflow and sending this
      MPRTP-AR SRR. If no MPRTP-AR SSR has been received yet from this
      subflow, the DLSR field is set to zero.

   The user agent sender can compute the round-trip propagation delay to
   the user agent receiver along a specific active path by doing the
   following. The user agent sender records the time A when this
   MPRTP-AR SRR is received, calculates the total round-trip time A-LSR
   using the last SSR timestamp (LSR) field, and then subtracting this
   field to leave the round-trip propagation delay as (A - LSR - DLSR).

5.2.3 MPRTP-AR keep-alive packet

    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=1|0|P| AMT=1 |      CT=3     |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Path Identifier                          |
   +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

   MPRTP-AR keep-alive packet is used to keep the active path alive. It
   only contains a fixed eight-octet MPTP header.

   The MPTP packet type (T) field is set to zero to indicate that this
   packet is a MPRTP-AR control packet.

   The application-specific MPTP type (AMT) field is set to 1 to
   indicate that this packet is a MPRTP-AR packet.

   The MPTP control packet type field is set to 3 to indicate that this
   packet is a MPRTP-AR keep-alive packet.

5.2.4 MPRTP-AR Flow Recombination Report















Leiwm, et al.            Expires July 24, 2017                 [Page 14]


Internet-Draft                  MPRTP-AR                January 24, 2017


    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=1|0|P| AMT=1  |     CT=4     |            Length             |
   +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
   |                      highest FSN received                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  cumulative num of packets lost               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      interarrival jitter                      |
   +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

   MPRTP-AR FRR conveys statistics on the reception of MPTP data packets
   of the whole recombined flow. The fields have the following meaning:

   The MPTP packet type (T) field is set to zero to indicate that this
   packet is a MPRTP-AR control packet.

   The application-specific MPTP type (AMT) field is set to 1 to
   indicate that this packet is a MPRTP-AR packet.

   The MPTP control packet type field is set to 4 to indicate that this
   packet is a MPRTP-AR FRR.

   The highest Flow Sequence Number (FSN) received: 32 bits
      The highest flow sequence number received in an MPRTP-AR data
      packet of the whole flow.

   Cumulative number of packets lost: 32 bits
      The total number of MPRTP-AR data packets of a whole flow that
      have been lost since the beginning of reception. Note that a user
      agent receiver cannot tell whether any packets were lost after the
      last one received. This number is defined to be the number of
      packets expected less the number of packets actually received. The
      number of packets expected is defined to be the highest FSN of
      MPTP data packets received less the initial FSN received. The
      number of packets received includes any which are late. Thus,
      packets that arrive late are not counted as lost.

   Interarrival jitter: 32 bits
      An estimate of the statistical variance of the interarrival time
      of the MPRTP-AR data packets with non-zero SSSN value in a flow,
      measured in timestamp units and expressed as an unsigned integer.
      Its calculation method is identical as the field with the same
      name.

6. SDP Considerations




Leiwm, et al.            Expires July 24, 2017                 [Page 15]


Internet-Draft                  MPRTP-AR                January 24, 2017


6.1 Signaling MPTP Capability in SDP

   This document defines a new mptp-name value for the mptp-relay
   attribute: "mprtp-ar" for RTP-based multimedia application-specific
   MPTP, i.e. MPRTP-AR.

   RTP and RTCP packets are multiplexed to transport. So the rtcp-mux
   attribute MUST be used in Session Description Protocol (SDP) [8] to
   indicate support for multiplexing of RTP and RTCP packets [4]. When
   an endpoint receives an SDP containing "a=mptp-relay" but without
   "a=rtcp-mux", the endpoint MUST infer that the peer, if as a user
   agent sender, supports multiplexing of RTP and RTCP packets.

   A user agent sender MAY use multiple paths concurrently to increase
   throughput. If the desired media rate exceeds the current media rate,
   the user agent sender MUST renegotiate the application specific
   ("b=AS:xxx") [8] bandwidth.

6.2 An Offer/Answer Example

   We take the usage scenario shown in Section 5.1 in [12] as an
   example. Session Initiation Protocol (SIP) [7] and SDP is used to
   negotiate a multipath session following the offer/answer model [9].

   As recommended in [13] and [14], this example uses IPV6 addresses.

   User A includes an initial SDP offer in the session invitation
   message. The initial SDP offer is shown as following.

   Initial Offer:
      v=0
      o=alice 2890866901 2890866902 IN IP6 2001:db8:a0b:102::1
      s=
      c=IN IP6 2001:db8:a0b:102::1
      t=0 0
      m=video 39160 RTP/AVP 98
      a=rtpmap:98 H264/90000
      a=fmtp:98 profile-level-id=42A01E;
      a=mptp-relay:mprtp-ar
      a=rtcp-mux

   When the invitation message is processed by the server system, two
   candidate relay paths are assigned for the media flow from user B to
   user A. The initial SDP offer in the session invitation message is
   modified as shown below. The IP addresses of RTP relay-1/relay-2/
   relay-3 are 2001:db8:a0b:103::1, 2001:db8:a0b:104::1 and
   2001:db8:a0b:105::1 respectively.




Leiwm, et al.            Expires July 24, 2017                 [Page 16]


Internet-Draft                  MPRTP-AR                January 24, 2017


   Modified Offer:
      v=0
      o=alice 2890866901 2890866902 IN IP6 2001:db8:a0b:102::1
      s=
      c=IN IP6 2001:db8:a0b:102::1
      t=0 0
      m=video 39160 RTP/AVP 98
      a=rtpmap:98 H264/90000
      a=fmtp:98 profile-level-id=42A01E;
      a=mptp-relay:mprtp-ar
      a=rtcp-mux
      a=relay-path:1 0x1a3b6c9d IP6/2001:db8:a0b:103::1/10000
      a=relay-path:2 0x9i8u7y6t IP6/2001:db8:a0b:105::1/10000

   If user B accepts the invitation, it includes an initial SDP answer
   in the session reply message. The initial SDP answer is shown as
   following.

   Initial Answer:
      v=0
      o=bob 2890866903 2890866904 IN IP6 2001:db8:a0b:106::1
      s=
      c=IN IP6 2001:db8:a0b:106::1
      t=0 0
      m=video 36120 RTP/AVP 98
      a=rtpmap:98 H264/90000
      a=fmtp:98 profile-level-id=42A01E;
      a=mptp-relay:mprtp-ar
      a=rtcp-mux

   When the relay message is processed by the server system, two
   candidate relay paths are assigned for the media flow from user A to
   user B. The initial SDP answer in the session invitation message is
   modified as shown below.

   Modified Answer:
      v=0
      o=bob 2890866903 2890866904 IN IP6 2001:db8:a0b:106::1
      s=
      c=IN IP6 2001:db8:a0b:106::1
      t=0 0
      m=video 36120 RTP/AVP 98
      a=rtpmap:98 H264/90000
      a=fmtp:98 profile-level-id=42A01E;
      a=mptp-relay:mprtp-ar
      a=rtcp-mux
      a=relay-path:1 0x2w3e4r5t IP6/2001:db8:a0b:103::1/10000
      a=relay-path:2 0x4r5t6y7u IP6/2001:db8:a0b:104::1/10000



Leiwm, et al.            Expires July 24, 2017                 [Page 17]


Internet-Draft                  MPRTP-AR                January 24, 2017


7. Security Considerations

   TBD

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

8. References

8.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]  Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video
        Conferences with Minimal Control", STD 65, RFC 3551, July 2003.

   [4]  Perkins, C. and M. Westerlund, "Multiplexing RTP Data and
        Control Packets on a Single Port", RFC 5761, April 2010.

   [5]  Mills, D., "Network Time Protocol (Version 3) Specification,
        Implementation and Analysis", RFC 1305, March 1992.

   [6]  Crocker, D. and P. Overell, "Augmented BNF for Syntax
        Specifications: ABNF", STD 68, RFC 5234, January 2008.

8.2 Informative References

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

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

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

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

   [11] Cadzow, J., Foundations of Digital Signal Processing and Data
        Analysis New York, New York: Macmillan, 1987.




Leiwm, et al.            Expires July 24, 2017                 [Page 18]


Internet-Draft                  MPRTP-AR                January 24, 2017


   [12] Lei, W., Zhang, W., and S. Liu, "A Framework of Multipath
        Transport System Based on Application-Level Relay",
        draft-leiwm-tsvwg-mpts-ar-05 (work in progress), January 2016.

   [13] Huston, G., Lord, A., and P. Smith, "IPv6 Address Prefix
        Reserved for Documentation", RFC3849, July 2004.

   [14] Robachevsky, A., "Mandating use of IPv6 in examples",
        draft-robachevsky-mandating-use-of-ipv6-examples-01 (work in
        progress), April 2016.









































Leiwm, et al.            Expires July 24, 2017                 [Page 19]


Internet-Draft                  MPRTP-AR                January 24, 2017


Authors' Addresses

   Weimin Lei
   Northeastern University
   Department of Communication and Electronic Engineering
   College of Computer Science and Engineering
   Shenyang, China, 110819
   P. R. China

   Phone: +86-24-8368-3048
   Email: leiweimin@mail.neu.edu.cn


   Wei Zhang
   Northeastern University
   Department of Communication and Electronic Engineering
   College of Computer Science and Engineering
   Shenyang, China, 110819
   P. R. China

   Email: zhangwei1@mail.neu.edu.cn


   Shaowei Liu
   Northeastern University
   IDepartment of Communication and Electronic Engineering
   College of Computer Science and Engineering
   Shenyang, China, 110819
   P. R. China

   Email: liu_nongfu@163.com




















Leiwm, et al.            Expires July 24, 2017                 [Page 20]


Html markup produced by rfcmarkup 1.124, available from https://tools.ietf.org/tools/rfcmarkup/