Network Working Group W. Lei Internet-Draft W. Zhang Intended Status: Experimental S. Liu Expires: January 24, 2015 Northeastern University July 25, 2014 Multipath Real-Time Transport Protocol Based on Application-Level Relay (MPRTP-AR) draft-leiwm-avtcore-mprtp-ar-02 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 January 24, 2015. Copyright Notice Leiwm, et al. Expires January 24, 2015 [Page 1] Internet-Draft MPRTP-AR July 25, 2014 Copyright (c) 2014 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 . . . . . . . . . . . . . . . . . . . . . 5 4.3 Subflow Recombination . . . . . . . . . . . . . . . . . . . 6 4.4 Subflow Reporting . . . . . . . . . . . . . . . . . . . . . 6 5. MPRTP-AR Packet Format . . . . . . . . . . . . . . . . . . . . 7 5.1 MPRTP-AR Data Packet . . . . . . . . . . . . . . . . . . . . 7 5.1.1 MPRTP-AR Data Packet for RTP packet . . . . . . . . . . 8 5.1.2 MPRTP-AR Data Packet for RTCP packet . . . . . . . . . . 8 5.2 MPRTP-AR Control Packet . . . . . . . . . . . . . . . . . . 9 5.2.1 MPRTP-AR Sender Report . . . . . . . . . . . . . . . . . 9 5.2.2 MPRTP-AR Receiver Report . . . . . . . . . . . . . . . . 11 5.2.3 MPRTP-AR keep-alive packet . . . . . . . . . . . . . . . 13 6. SDP Considerations . . . . . . . . . . . . . . . . . . . . . . 13 6.1 Signaling MPTP Capability in SDP . . . . . . . . . . . . . . 13 6.2 An Offer/Answer Example . . . . . . . . . . . . . . . . . . 14 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 15 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 8.1 Normative References . . . . . . . . . . . . . . . . . . . . 16 8.2 Informative References . . . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 Leiwm, et al. Expires January 24, 2015 [Page 2] Internet-Draft MPRTP-AR July 25, 2014 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 January 24, 2015 [Page 3] Internet-Draft MPRTP-AR July 25, 2014 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 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 report packets are used to monitor the transport quality of Leiwm, et al. Expires January 24, 2015 [Page 4] Internet-Draft MPRTP-AR July 25, 2014 each active path. MPRTP-AR-aware user agent MUST generate individual MPRTP-AR report packets for per subflow. The user agent sender generates MPRTP-AR Sender Report (SR) packets for each subflow and sends them along the associated active path. The user agent receiver generates a MPRTP-AR Receiver Report (RR) packet when receiving a MPRTP-AR SR packet and sends it 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 RR 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 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 Leiwm, et al. Expires January 24, 2015 [Page 5] Internet-Draft MPRTP-AR July 25, 2014 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 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. 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 Sender Report (SR) packets for each subflow and sends them along the associated active path. The user agent receiver generates a MPRTP-AR Receiver Report (RR) packets when receiving a MPRTP-AR SR and sends it along the default path. The user agent sender calculates the transmission interval of MPTP SR packets according to some strategy. The user agent sender may generate MPRTP-AR SR packets at a constant rate. In this case, it is recommended that the default interval of subflow MPRTP-AR SR packets be one second. The user agent sender may also generate MPRTP-AR SR 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. Leiwm, et al. Expires January 24, 2015 [Page 6] Internet-Draft MPRTP-AR July 25, 2014 Cumulative counts are used in both the MPRTP-AR SR and RR 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 RR 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 RR 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. 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 Leiwm, et al. Expires January 24, 2015 [Page 7] Internet-Draft MPRTP-AR July 25, 2014 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: 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 Leiwm, et al. Expires January 24, 2015 [Page 8] Internet-Draft MPRTP-AR July 25, 2014 eight-octet MPTP header and an intact RTCP packet. An example is shown 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 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 Sender Report (SR) packets and MPRTP-AR Receiver Report (RR) packets. 5.2.1 MPRTP-AR Sender Report Leiwm, et al. Expires January 24, 2015 [Page 9] Internet-Draft MPRTP-AR July 25, 2014 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 SR 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 SR. 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 January 24, 2015 [Page 10] Internet-Draft MPRTP-AR July 25, 2014 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 SR 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 SR packet was generated. This field can be used to estimate the average payload data rate. 5.2.2 MPRTP-AR 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 SR (LSR) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | delay since last SR (DLSR) | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ MPTP RR 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 RR. 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: 24 bits The total number of MPRTP-AR data packets from a subflow that have Leiwm, et al. Expires January 24, 2015 [Page 11] Internet-Draft MPRTP-AR July 25, 2014 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, 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 RR is issued, the current value of J is sampled. Last SR timestamp (LSR): 32 bits The middle 32 bits out of 64 in the NTP timestamp received as part of the most recent MPRTP-AR SR from a subflow. If no MPRTP-AR SR has been received yet, the field is set to zero. Leiwm, et al. Expires January 24, 2015 [Page 12] Internet-Draft MPRTP-AR July 25, 2014 Delay since last SR (DLSR): 32 bits The delay, expressed in units of 1/65536 seconds, between receiving the last MPRTP-AR SR from a subflow and sending this MPRTP-AR RR. If no MPRTP-AR SR 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 RR is received, calculates the total round-trip time A-LSR using the last SR 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. 6. SDP Considerations 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 Leiwm, et al. Expires January 24, 2015 [Page 13] Internet-Draft MPRTP-AR July 25, 2014 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]. 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 IP4 192.0.2.1 s= c=IN IP4 192.0.2.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 192.0.3.1, 192.0.4.1 and 192.0.5.1 respectively. Modified Offer: v=0 o=alice 2890866901 2890866902 IN IP4 192.0.2.1 s= c=IN IP4 192.0.2.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 1a3b6c9d0e2f6g1qazxsw23edcvfr45t IP4/192.0.3.1/ 10000 a=relay-path:2 0o9i8u7y6t5r4e3w2q0okm9ijn8uhb7y IP4/192.0.5.1/ Leiwm, et al. Expires January 24, 2015 [Page 14] Internet-Draft MPRTP-AR July 25, 2014 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 IP4 192.0.6.1 s= c=IN IP4 192.0.6.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 IP4 192.0.6.1 s= c=IN IP4 192.0.6.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 2w3e4r5t6y7u8i9o0p1q2wsx3edc4rfv IP4/192.0.3.1/ 10000 a=relay-path:2 4r5t6y7u8i9o0p1q2w3e4rfv5tgb6yhn IP4/192.0.4.1/ 10000 7. Security Considerations TBD All drafts are required to have a security considerations section. See RFC 3552 [10] for a guide. 8. References Leiwm, et al. Expires January 24, 2015 [Page 15] Internet-Draft MPRTP-AR July 25, 2014 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. [12] Lei, W., Zhang, W, and Liu, S., "A Framework of Multipath Transport System Based on Application-Level Relay", draft-leiwm-tsvwg-mpts-ar-02 (work in progress), July 2014. Leiwm, et al. Expires January 24, 2015 [Page 16] Internet-Draft MPRTP-AR July 25, 2014 Authors' Addresses Weimin Lei Northeastern University Institute of Communication and Information System College of Information Science and Engineering Shenyang, China, 110819 P. R. China Phone: +86-24-8368-3048 Email: leiweimin@ise.neu.edu.cn Wei Zhang Northeastern University Institute of Communication and Information System College of Information Science and Engineering Shenyang, China, 110819 P. R. China Email: zhangwei1@ise.neu.edu.cn Shaowei Liu Northeastern University Institute of Communication and Information System College of Information Science and Engineering Shenyang, China, 110819 P. R. China Email: liu_nongfu@163.com Leiwm, et al. Expires January 24, 2015 [Page 17]