AVT Core Working Group W. Lei Internet-Draft W. Zhang Intended status: Experimental S. Liu Expires: September 12, 2013 Northeastern University March 12, 2013 Multipath RTP based on RTP Relay Application (MPRTP-RA) draft-leiwm-avtcore-mprtp-ra-00 Abstract This document defines the framework of multipath transmission of real-time media based on relay. The framework allows participants to use multiple paths,including the default IP path and relay paths, to transport media in a RTP session. A relay path may via one or more RTP relay nodes which provide relay services for media data. This framework describes function blocks and behaviors of MPRTP-RA-capable RTP agent and RTP relay. The framework also defines multipath transport protocol by extending RTP, and relay control protocol named OpenPath. 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 12, 2013. Copyright Notice Copyright (c) 2013 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. Leiwm, et al. Expires September 12, 2013 [Page 1] Internet-Draft MPRTP: Multipath RTP based on RTP Relay Application Mar 2013 Table of Contents 1 Introduction................................................. 3 2 Terminology.................................................. 4 3 Definitions.................................................. 4 4 Goals........................................................ 5 4.1 Functional goals............................................. 5 4.2 Compatibility goals.......................................... 5 5 MPRTP-RA Topologies.......................................... 6 6 MPRTP-RA Use Scenarios....................................... 7 7 Overview of operation........................................ 9 7.1 Usage Scenario in SIP system................................. 10 8 MPRTP-RA Agent Behavior...................................... 12 8.1 MPRTP-RA session management.................................. 12 8.2 Path management.............................................. 12 8.3 Flow partitioning and scheduling............................. 15 8.4 Subflow recombination........................................ 15 8.5 Subflow RTP transmission..................................... 15 8.6 Subflow RTCP transmission.................................... 15 9 RTP Relay Behavior........................................... 16 9.1 Path-Table................................................... 16 9.2 Connection Management........................................ 18 9.3 Relay Service Management..................................... 18 9.4 Path Validity Management..................................... 19 9.5 Query Messages Processing.................................... 19 9.6 Path-Table Modification Messages Processing.................. 19 9.7 RTP/RTCP Packet Processing................................... 20 10 OpenPath Protocol............................................ 20 10.1 Protocol Overview............................................ 21 10.1.1 Relay-to-Controller.......................................... 21 10.1.2 Controller-to-Relay.......................................... 22 10.1.3 Symmetric.................................................... 23 10.2 Common Structures............................................ 23 10.2.1 OpenPath Common Header....................................... 23 10.2.2 Common Body of OpenPath Failure Responses.................... 24 10.2.3 Transport Address Structure.................................. 25 10.3 OpenPath Request and Success Response Message Format......... 26 10.3.1 HELLO........................................................ 26 10.3.2 START/STOP/BYE............................................... 26 10.3.3 ECHO......................................................... 26 10.3.4 NOTIFY/DELETE_PATH........................................... 27 10.3.5 FEATURES..................................................... 27 10.3.6 STATISTICS................................................... 28 10.3.7 ADD-PATH/ UPDATE_PATH........................................ 28 11 MPRTP-RA Packet Formats...................................... 28 11.1 RTP Header Extension for MPRTP-RA............................ 29 11.1.1 MPRTP-RA RTP Extensions for a Subflow........................ 30 11.2 RTCP Extension for MPRTP-RA (MPRTCP-RA)...................... 30 Leiwm, et al. Expires September 12, 2013 [Page 2] Internet-Draft MPRTP: Multipath RTP based on RTP Relay Application Mar 2013 11.2.1 MPRTCP-RA Extensions for Subflow Reporting (SR/RR)........... 31 11.2.2 MPRTCP-RA Extensions for Subflow Path Probe.................. 33 11.2.3 MPRTCP-RA Extensions for Subflow Keepalive................... 34 12 SDP Considerations........................................... 34 12.1 Signaling MPRTP-RA Header Extension in SDP................... 34 12.2 Signaling MPRTP-RA Capability in SDP......................... 35 12.3 Relay Path Advertisement in SDP.............................. 35 12.4 Offer/Answer................................................. 36 12.4.1 An Example................................................... 37 13 IANA Considerations.......................................... 38 13.1 MPRTP-RA Header Extension.................................... 38 13.2 MPRTCP-RA Packet Type........................................ 39 13.3 SDP Attributes............................................... 39 14 Security Considerations...................................... 40 15 References................................................... 40 15.1 Normative References......................................... 40 15.2 Informative References....................................... 4E 1. Introduction Media transmission in traditional networks mainly depends on a single path, such as the default IP path determined by routing protocols. However, the default IP path usually is not optimal and sometimes even worse when the path via different Internet Service Provider (ISP) networks. IP communication applications usually adopt a relay-based way to transfer media. Relay-based media transmission is used to be a general solution for NAT and firewall traversal which usually makes direct media transmission between the sender and the receiver unfeasible. And this can provide communication applications with opportunities to autonomously select media transmission path by replacing the default IP path with a relay path. Whether the default IP path or the relay path, the end-to-end media session mainly uses transport protocols dedicated to single-path media transmission, such as RTP. However, the single path may not be capable of handling load requirements of media transmission, especially when transporting high bit- rate multimedia content. Using multiple paths between source and destination for media transmission has been shown to be an effective method to increase throughput and reliability. This document defines the framework of multipath transmission of real-time media based on relay. The framework allows participants to use multiple paths, including the default IP path and relay paths, to transport media in a RTP session. This framework describes the function blocks and behaviors of the MPRTP-RA- capable RTP agent and RTP relay. The framework also defines the application- level multipath transport protocol by extending RTP, and the relay control Leiwm, et al. Expires September 12, 2013 [Page 3] Internet-Draft MPRTP: Multipath RTP based on RTP Relay Application Mar 2013 protocol named OpenPath. 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 RFC2119 [2]. 3. Definitions 1) Endpoint: host either initiating or terminating a RTP flow. 2) 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 should map to a unique path. 3) Path: sequence of logical links between a sender and a receiver. We define it by a set of addresses. All available paths for a MPRTP-RA session include a default path and one or more relay paths. 4) Default path: a path between a sender and a receiver, which is same as the path negotiated and established by a normal RTP session. It is determined by the c= and m= lines in Session Description Protocol (SDP) during session setup. If either the sender or the receiver is not behind a symmetric NAT, the default path may be the direct network path between the sender and the receiver. Otherwise, it may traverse a third-party node, such as a TURN server or a media server which is responsible for relaying RTP packets. 5) Relay path: a path via one or multiple RTP relay nodes between a sender and a receiver. A relay path is defined by a sequence of (S, R1, ..., Rm, D), where Ri denotes the address of the i-th relay node and m denotes the number of relay nodes in this path. 6) Candidate path: a path that is either a default path or a relay path. 7) Active path: a path that carries media data. 8) RTP Relay: an intermediary entity that primarily plays the role of forwarding RTP subflow according to a Path-Table. RTP Relay receives RTP packets from its upstream entity of the subflow that the received RTP packets belong to, obtains the next-hop transport address based on the matching results in the Path-Table, and forwards the RTP packets to the corresponding next-hop transport address. All RTP fields produced by initial RTP protocol remain intact. 9) Path-Table: a table consisting of a set of path entries. 10) MPRTP-RA Session: a special type of RTP session in which the original Leiwm, et al. Expires September 12, 2013 [Page 4] Internet-Draft MPRTP: Multipath RTP based on RTP Relay Application Mar 2013 single media stream is split into multiple subflows and each subflow is mapped to a unique path. 4. Goals This section outlines the basic goals that multipath RTP based on RTP relay aims to meet. These are broadly classified as Functional goals and Compatibility goals. 4.1 Functional goals In multipath RTP based on RTP relay, the original media flow in a RTP session is split into multiple subflows which are carried over multiple paths. This may prove beneficial in case of video streaming. 1) Increased Throughput: In some cases, the relay path, which is assigned to a media session according to the location of participants and the current network status, has better transport capacity than the default path between the participants. And cumulative transport capacity of multiple paths may better meet the requirements of the high bit-rate media session. 2) Improved Reliability: when multiple paths are available, MPRTP-RA agent can use some of them to send redundant packets or re-transmit packets to increase reliability. When one active path occurs failure such as errors, unreachability or congestion, MPRTP-RA agent can tear down the corresponding subflow or switch the subflow load to other candidate paths based on a scheduling strategy. 3) Load balancing: transmitting a RTP stream over multiple paths reduces the bandwidth usage on a single path, which in turn reduces the impact of the media stream on other traffic on that path and then avoids congestion in network hot-spots. From the perspective of the whole network, the network load balancing and network utilization can be significantly improved. 4.2 Compatibility goals MPRTP-RA MUST be backwards compatible. In other words, if multiple paths are not available, the endpoints supporting the extension in this document should fall back to be compatible with legacy RTP stacks. 1) Application Compatibility: MPRTP-RA-capable RTP applications MUST be backwards compatible with existing RTP applications and not require any change to them. Moreover, regardless of whether the receiver is MPRTP-RA- capable, the MPRTP-RA-capable sender is allowed to use multiple paths for transmission. The media receiver with legacy RTP stack is still able to reconstruct and playback the media stream because the received RTP packets are compliant to [RFC3550]. Leiwm, et al. Expires September 12, 2013 [Page 5] Internet-Draft MPRTP: Multipath RTP based on RTP Relay Application Mar 2013 2) Network Compatibility: individual RTP subflows MUST themselves be well- formed RTP flows, so that they are able to traverse NATs and firewalls. 5. MPRTP-RA Topologies For a multimedia session, the media transmission path from the source to its receiver is usually the default IP path determined by routing protocols, such as OSPF. However, the default IP path usually is not optimal and sometimes even when the path goes through different ISP networks. If the media transmission path is switched to another path, referred to as a relay path, which goes through one or more relay nodes, and if network bandwidth and other performance metrics between the endpoints and its neighboring relay nodes and between two successive relay nodes if they exist can be ensured, the quality of the received media can be improved. In addition, when transporting high bit-rate multimedia content, the single path may not be capable of handling the load requirements of media transmission. It is an increasingly common practice for the endpoints with high access bandwidth through well-connected access networks. The bandwidth constraints of an end-to-end multimedia session are gradually migrating from user access network to inside the network. In this case, using multiple paths, including the default IP path and the relay paths, between the source and the destination for media transmission has been shown to be a more effective method than using a single path. The media sender balances their multimedia stream across multiple paths based on the path reception statistics (e.g. RTT, loss-rate, delay etc.). The resource capacity of multiple paths can well meet the throughput requirements, better packet losses and delays within a predictable range, such that enhance user experience. The relay nodes mentioned above may be deployed in a variety of ways. Combined with application requirements, application service providers can deploy a large number of proprietary media servers with high network bandwidth and computing performance in their system. The participating nodes that access the same application may also self-organize to form a dynamic overlay network among which the nodes with higher performance can provide media relay service to others. This specification presents the notion of "RTP relay", which could be considered as intermediate systems at the RTP level. The deployment of RTP relay nodes provides more options of media transport paths different from the default path. RFC3550 supports the use of RTP-level translators and mixers, and discusses the impact on RTP and RTCP packets in detail. RFC5117 describes a number of scenarios using mixers and translators in point-to-point and point-to- multipoint topologies. MPRTP-RA presented in this document assumes that if a mixer or translator exists in the network, then either all of the multiple Leiwm, et al. Expires September 12, 2013 [Page 6] Internet-Draft MPRTP: Multipath RTP based on RTP Relay Application Mar 2013 paths or none of the multiple paths go via this component. 6. MPRTP-RA Usage Scenarios MPRTP-RA can be applied in many multimedia application scenarios for multipath multimedia transport, including point-to-point real-time communication, many-to-one parallel streaming and one-to-many multicast streaming. In these scenarios, higher bit-rate and higher quality codecs are allowed to be used. Figure 1 illustrates a point-to-point MPRTP-RA session. There are three paths between the sender and the receiver, including the default path, one relay path via one RTP relay node and one relay path via two RTP relay nodes. Applications running at the sender side can choose a data partitioning method according to its particular requirements. Then, each flow is assigned to a path. The receiver reassembles the received flows using a resequencing buffer to retrieve the reconstructed flow which is decoded and displayed. RTP data(A, Relay-1,B) +------------+ +------------------->| RTP Relay-1|------------------------+ | +------------+ | | V +--------+ RTP data(A,B) +--------+ | User A |----------------------------------------------->| User B | +--------+ +--------+ | ^ | RTP data(A, Relay-2,Relay-3,B) | | +------------+ +------------+ | +--->| RTP Relay-2|-------------------->| RTP Relay-3|-----+ +------------+ +------------+ Figure 1. A point-to-point multipath RTP session A wide range of applications require data transmission from geographically distributed sources to one destination. For instance, large volume data of high definition movies are stored at multiple geographically distributed locations. The audiences need to retrieve and integrate data from several locations. This usage scenario can be completed by a many-to-one MPRTP session, which is depicted in Figure 2. A MPRTP-RA agent streams different portions of a video from three servers concurrently. The path between the server and the MPRTP-RA agent may go through one or more RTP relay nodes. Leiwm, et al. Expires September 12, 2013 [Page 7] Internet-Draft MPRTP: Multipath RTP based on RTP Relay Application Mar 2013 +---+ | A |----------------------------------------------------+ +---+ | | V +---+ +---------+ +---+ | B |------------------|RTP Relay|-------------------->| D | +---+ +---------+ +---+ ^ | +---+ +---------+ | | C |------------------|RTP Relay|-----------------------+ +---+ +---------+ Figure 2. A many-to-one multipath RTP session Many video applications are typically characterized by a wide range of connection qualities and receiving devices which are with different capabilities ranging from cell phones with small screens and restricted processing power to high-end PC with high-definition display. These systems are usually adopting layered coding. Layered coding enables the encoding of a high-quality video bit stream containing one or more subset bit streams that can themselves be decoded independently. This usage scenario can be completed by a one-to-many MPRTP-RA session, which is depicted in figure 3. A video source is encoded into multiple streams, each of which is transported by a source tree for video multicast. +---+ +------------------------->| A | | +--->+---+ | | +---------+ | +------------------->|RTP Relay|----------------|------+ | +---------+ | | | | | | | | | V +---+ +------------------+ | +---+ | S | | | | B | +---+ +------------------|--+ +---+ | | | ^ | | | | | +---------+ | | +------------------->|RTP Relay|-------------|---------+ +---------+ | | | | +------>+---+ +------------------------->| C | +---+ Figure 3. A one-to-many multipath RTP session Leiwm, et al. Expires September 12, 2013 [Page 8] Internet-Draft MPRTP: Multipath RTP based on RTP Relay Application Mar 2013 7. Overview of operation As intermediate entities, RTP relay nodes provide data relay service to the communicating endpoints. Then multiple relay paths may be generated between a sender and a receiver. If the RTP relay nodes are deployed by application service provider, the relay paths may be assigned by the server system. If the RTP relay nodes are those participating nodes with higher performance, MPRTP-RA-capable endpoints can query the third-party component to obtain relay paths when they want to establish MPRTP-RA session. Whether it is the server system or the third party component, for simplicity sake, we call it controller below. The controller is responsible for selecting one or multiple relay paths for a media flow. Considering the execution efficiency, the relay path is designed to be unidirectional. A bidirectional media flow in a conversational use-case is regarded as two independent unidirectional flows in opposite directions. Relay paths are assigned for each unidirectional flow. The sender and the RTP relay nodes need to know the relay path information so they can correctly forward subflow data along a particular relay path. An alternative approach, similar to source routing, is that the sender can store the entire route in packet headers. Each intermediate node will simply examine the headers of a received packet and forward it to the next node as indicated in the source route. The advantage of the method is to simplify the implementation of RTP relay nodes. They need not store any path information and can perform routing of RTP packets only based on RTP extension headers. But this method introduces traffic overhead considerably, especially when the payload traffic is relatively small. In practice, the sender and the RTP relay nodes need not to know the complete information of the associated path. They just need to know the next-hop transport address for each path associated with them. A pair of transport address comprises one network address plus one port. During assigning the relay paths for a media flow, the controller associates a unique path identifier to each relay path and communicates with RTP relay nodes to set the corresponding path information. When the controller is located in server system, the next-hop transport addresses of the sender for each relay paths and the associated path identifiers should be advertised to the sender using a kind of out-of-band signaling (e.g., Session Description Protocol (SDP) in Session Initiation Protocol (SIP), Real-Time Streaming Protocol (RTSP)). A RTP relay node performs packet lookups and forwarding based on Path-Table which stores path information. The Path-Table contains a set of path entries which can be added, updated and deleted by the controller via OpenPath protocol. The controller is free to be implemented in any way, provided that Leiwm, et al. Expires September 12, 2013 [Page 9] Internet-Draft MPRTP: Multipath RTP based on RTP Relay Application Mar 2013 correct semantics of OpenPath protocol are preserved. For example, the controller can be implemented as a function module of SIP server or a standalone component. The sender performs connectivity checks on multiple relay paths to ascertain reachability before using them. If the path is reachable, then it is referred to available path. According to the transmission requirements of the current RTP session, the sender selects the default path and one or multiple available relay paths as active paths among all the available paths to transmit multimedia data to the receiver. The sender distributes the packets across the active paths based on a scheduling strategy and dynamically adjusts the load on each path. The receiver combines the received subflows to recreate the original RTP session. A multipath RTP session should be established before using multiple paths to transport media flow. It can be set up in many possible ways e.g., during session establishment, or at anytime during the session. To reduce media startup time, endpoints can start transporting multimedia data via the default path and then perform path connectivity checks for relay paths. If there are one or multiple available relay paths, the endpoints update the single path session to a multipath session. For a multipath RTP session, each subflow appears as an independent RTP flow. To monitor the transport quality of the path, the participants MUST generate individual RTCP messages for per subflow. To maintain backward compatibility with legacy applications, the participants MUST also send aggregate RTCP packets along with the subflow specific RTCP packets. Specifically, the participants generate aggregate RTCP following the normal RTCP defined in RFC3550, and send them along the default path. Meanwhile, the sender generates RTCP Sender Reports (SR) for each subflow and sends them along the same path as the subflow RTP packets. The receiver responds with a RTCP Receiver Report (RR) for each subflow, which is sent along the default path. 7.1 Usage Scenario in SIP system Figure 4 depicts a kind of usage scenario in which SIP is used as a separate signaling to advertise relay paths information. In this case, two participants are MPRTP-RA-capable. Leiwm, et al. Expires September 12, 2013 [Page 10] Internet-Draft MPRTP: Multipath RTP based on RTP Relay Application Mar 2013 +-----------------+ (1)INVITE | SIP Server | (3)INVITE +---------------------->| --------------|------------------------+ | +-------------------| | Controller |<-------------------+ | | | (6)200OK +-----------------+ (4)200OK | | | | ^ ^ ^ | | | | (2)(5) | |(2)(5) | (2)(5) | | | V +-------+ V +------+ | V +--------+ P-1/P-3 | +------------+ | P-1/P-3 +--------+ | User A |<---------|----->| RTP Relay-1|<-------|----------->| User B | +--------+ | +------------+ | +--------+ ^ | | ^ | V V | | +------------+ +------------+ | +--->| RTP Relay-2|<------------------->| RTP Relay-3|<-------+ P-2/P-4 +------------+ +------------+ P-2/P-4 Figure 4. Usage Scenario for Relay-based Multipath Transmission in SIP System (1) User A sends the INVITE to the SIP server that serves her domain. SIP server extracts the current addressable locations of the caller and the callee, and the media information including media types and listed media codecs. SIP server assigns the appropriate relay paths for the media flow from user B to user A with the aid of a dedicated component named controller. (2) In this example, two relay paths assigned to the media flow from user B to user A are (B, Relay-1, A) and (B, Relay-3, Relay-2, A), named P-1 and P-2. And each relay path is associated with a globally unique path identifier, separately named PID-1 and PID-2. The controller component sends an AddPath request of OpenPath protocol to each of the three selected RTP relay nodes. AddPath request includes the corresponding path identifier and next-hop transport address of the receiving RTP relay node. For Relay-1, the path identifier is PID-1 and the next-hop transport address is the current addressable location of user A. For Relay-2, the path identifier is PID-2 and the next-hop transport address is the current addressable location of user A.For Relay-3, the path identifier is PID-2 and the next-hop transport address is Relay-2's IP address and relay service port. (3) SIP server inserts the path identifiers and the next-hop transport addresses of user B into SDP body of INVITE and forward the modified INVITE to user B. The next-hop transport addresses of user B for P-1 and P-2 are separately the rely address of Relay-1 and Relay-3. (4) User B answers the call and sends back a 200 OK response. In the same way, SIP server assigns the appropriate relay paths for the media flow from user A to user B with the aid of the controller. (5) In this example, the controller assigns the same relay paths with Leiwm, et al. Expires September 12, 2013 [Page 11] Internet-Draft MPRTP: Multipath RTP based on RTP Relay Application Mar 2013 opposite direction for the media flow from user A to user B based on symmetry principle.They are separately (A, Relay-1, B) and (A, Relay-2, Relay-3, B), named P-3 and P-4, associated with the path identifiers of PID-3 and PID-4. The controller component sends an AddPath request of OpenPath protocol to each of the three selected RTP relay nodes. For Relay- 1, the path identifier is PID-3 and the next-hop transport address is the current addressable location of user B. For Relay-2, the path identifier is PID-4 and the next-hop transport address is Relay-3's IP address and relay service port. For Relay-3, the path identifier is PID-4 and the next-hop transport address is the current addressable location of user B. (6) SIP server inserts the path identifiers and the next-hop transport addresses of user A into SDP body of 200 OK response and forwards it to user A. The next-hop transport addresses of user A for P-3 and P-4 are separately the rely address of Relay-1 and Relay-2. (7) Through the signaling process above, user A and user B separately obtain the information of candidate relay paths as the sending peer of the corresponding media flow. After connectivity check, user A and user B take advantage of multiple paths to transport the media flow. 8. MRTP Agent Behavior Given multiple paths, MPRTP-RA and its companion control protocol, multipath RTCP (MRTCP-RA), need to provide essential support for multipath media transport, including session and path management, flow partitioning and scheduling, subflow recombination, QoS feedback for each subflow as well as payload type identification, sequence numbering, timestamping and delivery monitoring. 8.1 MPRTP-RA session management RTP is a session-oriented protocol. At the same way, a multipath RTP session needs to be established before transporting data on multiple paths. The multipath RTP session setup uses a way of out-of-band signaling (e.g., SDP in SIP or RTSP). The capability exchange and relay path advertisement should be done during the signaling process. A multipath RTP session may be setup from the beginning, or may be upgraded from a typical single path RTP session. To be backward compatibility with legacy applications, a multipath RTP session must look like a bundle of individual RTP sessions. 8.2 Path management The sender gathers candidate paths from the out-of-band signaling for the multipath RTP session setup. The default path is determined by the c= and m= lines in SDP. It may be the direct network path between the sender and the Leiwm, et al. Expires September 12, 2013 [Page 12] Internet-Draft MPRTP: Multipath RTP based on RTP Relay Application Mar 2013 receiver, or may traverse a third-party node, such as a TURN server or a dedicated relay server. For the latter, IP address and port of the third- party node is in the c= and m= lines in SDP. Candidate relay paths may change during a session. For example, a relay node on the relay path fails during the session, or additional relay paths are assigned for the session. The changes should be advertised to the sender by the same way of out-of-band signaling. The sender needs to perform path probes to determine if the path is available and if so, obtains the transmission quality of the path at the same time. After obtaining a new candidate path, the sender first performs path probe process, if the path is available, marks it available and puts it into the available path list ordered based on a decreasing priority level; if the path is not available, marks it unavailable and puts it into the unavailable path list. The sender will periodically perform path probes for all the paths in available path list to actively detect path failure and perceive the dynamic changes to the path. If the probe process for a particular path fails, the path will be marked unavailable and removed from the available path list to the unavailable path list. The sender should also perform path probes for the paths in unavailable path list in a longer cycle. If the probe process for a particular path successes, the path will be marked available and removed from the unavailable path list to the available path list. If no media is received on a relay path within a given time, RTP relay nodes will withdraw the corresponding resources allocated for this path.Therefore, all the relay paths should be kept alive periodically. To meet this requirement, the sender MUST multiplex the subflow specific RTP and RTCP packets on the same port. On the one hand, the multiplexed RTCP packets can be used to keep alive the relay path. This is in line with the recommendation made in RFC6263. On the other hand, multiplexing RTP and RTCP reduces the number of ports used by per multipath RTP session. For non- active paths, the sender only needs to periodically send RTCP keepalive packets. When RTP and RTCP packets are multiplexed onto a single port, 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 to follow the guidelines in the RTP/AVP profile [RFC3551] for the choice of RTP payload type values, with the additional restriction in RFC5761. Using the information in the subflow reports, a sender can monitor active paths for failure (e.g., errors, unreachability, and congestion). If failure happens in an active path, the sender may perform flow repartitioning and spread the RTP load across other active paths, or may select a new path from the available path list to replace the failure path. Leiwm, et al. Expires September 12, 2013 [Page 13] Internet-Draft MPRTP: Multipath RTP based on RTP Relay Application Mar 2013 8.3 Flow partitioning and scheduling This document does not limit the usage of multiple paths. The sender may concurrently use multiple paths to obtain higher throughput, or may send all traffic on a specified path while all other available paths are used only rarely to enhance resilience (e.g., for retransmission, for error-repair, or for redundancy packets). The sender MUST only use the default path and the relay paths in available path list as the active path. How to select multiple paths among all available paths and how many paths to use concurrently are outside the scope of this document. If multiple paths are used concurrently, the original multimedia stream should be divided into several substreams. The partition may be done based on media type, encoding scheme and path characteristics. Flow partitioning methods are outside the scope of this document. An application should make appropriate choices according to its own needs. Payload format specifications for particular payload types should be developed to adapt them to multipath transport. Here, we introduce several options for reference only. A simple flow partitioning scheme is to assign packets to multiple subflows using the round-robin algorithm. Specifically, the original media stream is first divided into blocks of equal-sized temporal length. Then, a subflow is assembled by picking blocks periodically from the original blocks in an increasing order. This method can be applied to both audio and video formats. However, all the data are treated equally and not distinguished based on their different importance in terms of decoded media quality.And great correlations exist among subflows which are sent along paths with different transport capacity. Furthermore, a multistream coder using layered coding, multiple description coding or object-oriented coding can produce multiple compressed media flows. 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. The sender should associate a subflow with an active path based on a scheduling strategy. A scheduling policy should jointly consider various factors including the estimated path bandwidth information, the path reception statistics (e.g. RTT, loss-rate, delay etc.), the relative importance of subflow data and so on. Due to the changes in path characteristics, the sender should be able to change its scheduling strategy during an ongoing session to fully explore the potential of multipath transport. Leiwm, et al. Expires September 12, 2013 [Page 14] Internet-Draft MPRTP: Multipath RTP based on RTP Relay Application Mar 2013 8.4 Subflow recombination A media receiver, irrespective of MPRTP-RA support or not, should be able to process the media stream received from multiple paths correctly. A legacy receiver just ignores the MPRTP-RA extension headers and follows the normal process defined in RTP. A MPRTP-RA-capable receiver first restores the order of each subflow using path identifier and subflow sequence numbers. It then examines the head-of-line packets of the subflows and orders them according to their timestamps and original flow sequence numbers. Therefore, the multipath subflows appear as a single RTP stream to the existing up-level applications which do not require changes. 8.5 Subflow RTP transmission In a multipath RTP session, if multiple paths are used to send the media stream, RTP packets MUST follow the subflow specific fields described in the MPRTP-RA extension headers. Specifically, the subflow specific fields include path identifier and subflow-specific sequence number. The corresponding RTP header extension is shown in section 10. A Path identifier, which is globally unique, is used to identify a specific path by the sender and RTP relay nodes. Meanwhile, the path identifier in RTP packets is also used to identify a subflow by the receiver. Apart from normal RTP sequence numbers defined in RTP, the multipath sender MUST add subflow-specific sequence numbers to help calculate fractional losses, jitter, RTT, playout time, etc, for each path. The initial subflow sequence number is randomly generated when the subflow is first established in the MPRTP-RA session. 8.6 Subflow RTCP transmission The participants generate aggregate RTCP reports to provide the overall media statistics and follow the normal RTCP defined in [RFC3550]. Aggregate RTCP reports are transmitted along the default path. Meanwhile, the participants also generate individual RTCP reports for per subflow to provide the per path media statistics. The sender generates RTCP Sender Reports for each unique subflow and sends them along the same path as the subflow RTP packets. The subflow specific RTP and RTCP packets are multiplexed on a single port. As the relay path is unidirectional, the receiver generates RTCP Receiver Reports for each unique subflow and sends them along the default path. The aggregate and subflow-specific RTCP reports MUST NOT be compounded as defined in RFC 5506. Although subflow RTCP SRs and RRs are not sent along the same path, they still can be used to measure round-trip propagation to the receiver along different paths as defined in RFC3550. Since all subflow RTCP RRs are sent along the default path, the calculated round-trip propagation delays can Leiwm, et al. Expires September 12, 2013 [Page 15] Internet-Draft MPRTP: Multipath RTP based on RTP Relay Application Mar 2013 correctly represent relative size of transmission delays of different paths. In RTP, RTCP reports are transmitted at a low rate. This algorithm effectively keeps the bandwidth used by RTCP to a relatively constant ratio of the total session bandwidth. However, such a feedback rate may not be frequent enough for the sender to quickly adapt to path fluctuation and transmission errors. Timely RTCP reports are necessary for multipath transport environments. The additional subflow RTCP reports MUST follow the timing rules defined in RFC 4585 [5]. For point-to-point applications, since the number of the participants is relatively small, subflow RTCP reports are usually sent sufficiently frequently. The RTCP reporting interval may be locally implemented and may depend on the behavior of each path. For instance, the RTCP interval may be different for an active path, an alternate path, and an unavailable path. Additionally, an endpoint may decide to share the RTCP reporting bandwidth equally across all its paths or schedule based on the rate on each path. 9. RTP Relay Behavior A RTP relay node performs RTP/RTCP packet lookups and forwarding based on a Path-Table. All the RTP Relay nodes are managed by a controller over connections using a protocol referred to as OpenPath protocol. 9.1 Path-Table The Path-Table contains a set of path entries each of which corresponds to an associated relay path. Each path entry consists of match fields, result fields and counters (see table 1). Leiwm, et al. Expires September 12, 2013 [Page 16] Internet-Draft MPRTP: Multipath RTP based on RTP Relay Application Mar 2013 Table 1: Fields in a path entry. +-------------------------------------+---------------------------+ | Fields | Bits | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | Match fields | +-----------------------------------------------------------------+ | Path Identifier | 32 | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | Result fields | +-----------------------------------------------------------------+ | Next-hop transport address type | 8 | +-------------------------------------+---------------------------+ | | For an IPv6 address, this | |Next-hop transport IP address | is 128;for an IPv4 address| | | , this is 32. | +-------------------------------------+---------------------------+ | Next-hop transport port | 16 | +-------------------------------------+---------------------------+ | Idle timeout | 16 | +-------------------------------------+---------------------------+ | Hard timeout | 16 | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | Counters | +-----------------------------------------------------------------+ | Received packets | 64 | +-------------------------------------+---------------------------+ | Received bytes | 64 | +-------------------------------------+---------------------------+ | Duration (seconds) | 32 | +-------------------------------------+---------------------------+ | Duration (nanoseconds | 32 | +-----------------------------------------------------------------+ Match fields are used to match against RTP/RTCP packets. Match fields only consist of Path ID in this document. Path ID: a 32 bit unsigned integer uniquely identifying the associated path. Result fields include next-hop transport address and idle timeout. Next-hop transport address is to determine where the matched packets are forwarded. Type: corresponds to the type of the next-hop transport address. Namely: 1: IPv4 address 2: IPv6 address IP Address: the address to which the relay node forwards the matched packets. Leiwm, et al. Expires September 12, 2013 [Page 17] Internet-Draft MPRTP: Multipath RTP based on RTP Relay Application Mar 2013 Port: the port number to which the relay node forwards the matched packets. It is multiplexed by RTP and RTCP packets. Counters are maintained for each path entry and updated for matching RTP packets. Received packets: the amount of packets the path has matched. Received bytes: the amount of bytes the path has matched. Duration: the amount of time the path has been installed in the RTP relay node. 9.2 Connection Management A RTP relay node communicates with the controller over a connection which may be encrypted using TLS or run directly over TCP. The RTP relay node initiates a standard TLS or TCP connection to the controller. The RTP relay node can get the IP address of the controller in a number of ways, such as manual configuration, DNS domain name queries and so on. When a connection is established, the RTP relay node immediately sends a HELLO message to the controller. The relay ID field is set to the unique identifier of the RTP relay node. The version field is set to the highest OpenPath protocol version supported by the RTP relay node. The HELLO message contains the IP address and port of the RTP relay node for the relay service. Upon receipt of this message, the controller checks the included OpenPath protocol version. If the version is not supported, the controller responds to the HELLO with a failure response; otherwise, the controller replies with a success response. The RTP relay node completes the registration process by exchanging HELLO messages. If a failure response to the HELLO message is received, the RTP relay node then terminate the connection. Otherwise, the connection proceeds and the RTP relay node may start relay service. During the lifetime of the connection, Echo requests should be sent periodically from either the RTP relay node or the controller, and the request receiver must return an ECHO reply. 9.3 Relay Service Management After receiving a success response to the HELLO message, the RTP relay node may send a START message to the controller to indicate that it has enough capacity to provide relay service. In the case that the RTP relay node is overloaded, or under other some situations, the RTP relay node may send a STOP message to the controller to Leiwm, et al. Expires September 12, 2013 [Page 18] Internet-Draft MPRTP: Multipath RTP based on RTP Relay Application Mar 2013 indicate that it will no longer receive new relay service requests (i.e. ADD_PATH messages) for a while. During this period, the RTP relay node still provides relay service for those existing relay paths. And ECHO messages still need to be sent periodically between the RTP relay node and the controller.When the RTP relay node recovers from an overloaded state, it may send a START message to the controller to indicate that it has additional capacities to provide new relay services. When the RTP relay node wants to stop relay service permanently, it should actively send a BYE message to the controller before terminating the connection. In this way, the controller can be ready in time to do some remedial measures. For instance, the controller may assign new relay paths for the affected media flow. 9.4 Path Validity Management Each path entry has an idle timeout and a hard timeout associated with it. These two fields control how quickly a path entry expires. When a path entry is inserted by an ADD_PATH request or modified by a UPDATE_PATH request, its idle timeout and hard timeout are set with the values from the message. If either value is non-zero, the RTP relay node must note the arrival time of RTP/RTCP packet on the associated path, as it may need to evict the path entry later. A non-zero hard timeout field causes the path entry to be removed after the given number of seconds, regardless of how many packets it has matched. A non-zero idle timeout field causes the path entry to be removed when it has matched no packets in the given number of seconds. Using these two fields, the RTP relay node can actively clear those expired path entries. In addition, the controller may actively remove path entries by sending DELETE_PATH messages.If the RTP relay node actively removes a path entry, it must send a NOTIFY message to the controller. The NOTIFY message contains a complete description of the path entry including the reason for removal, the path entry duration and statistics at the time of removal. 9.5 Query Messages Processing After connection establishment, the RTP relay node may receive Feature requests from the controller to provide capabilities information. The RTP relay node must respond with a Feature reply that specifies its capabilities. During the lifetime of the connection, the controller may periodically collect statistics from a RTP relay node by sending STATISTICS requests. The RTP relay node must respond with a Statistics reply that specifies its current statistics. 9.6 Path-Table Modification Messages Processing Leiwm, et al. Expires September 12, 2013 [Page 19] Internet-Draft MPRTP: Multipath RTP based on RTP Relay Application Mar 2013 Path-Table in the RTP relay node is managed by the controller through Path- Table modification messages. This document defines three Path-Table modification message types: ADD_PATH for inserting a new path entry, DELETE_PATH for removing an existing path entry, and UPDATE_PATH for modifying an existing path entry. For ADD_PATH requests, the RTP relay node must first check if any path entry with the same path identifier has existed in the Path-Table. If an overlap conflict exists between an existing path entry and the ADD_PATH request, the RTP relay node must refuse the addition and respond with a failure response. For valid ADD_PATH requests, the RTP relay node must insert a new path entry in the Path-Table and respond to the controller with a success response. The counters of received packets and received bytes in the new inserted entry are set to zero. For DELETE_PATH requests, if a matching entry exists in the Path-Table, it must be removed, and a success response is returned to the controller. For DELETE_PATH requests, if no path entry matches, no path entry modification occurs, and a failure response is returned to the controller. For UPDATE_PATH requests, if a matching entry exists in the Path-Table, the result fields of this entry is updated with the value from the request, and counter fields are left unchanged. For UPDATE_PATH requests, if no path entry matches, no path entry modification occurs, and a failure response is returned to the controller. 9.7 RTP/RTCP Packet Processing The main function of RTP relay node is to provide media relay service to the associated subflows. All subflows associated with a RTP relay node share a common relay port of the RTP relay node. On receiving a data packet, RTP relay node first distinguishes whether it is a RTP packet or a RTCP packet. Then RTP relay node extracts the path ID from the appropriate position in the packet and does matching in the Path-Table. If the received packet does not match a path entry in the Path-Table, RTP relay node should drop the packet. If the received packet matches a path entry in the Path-Table, RTP relay node forwards it to the associated next- hop transport address in the matched path entry. Meanwhile, RTP relay node updates the associated statistical counters in the matched path entry. If the received packet is a RTCP probe packet, RTP relay node needs to do some special handling before forwarding it to the associated next-hop transport address. In this case, RTP relay node generates a Relay Node block and appends it to the received RTCP probe packet. 10. OpenPath Protocol Leiwm, et al. Expires September 12, 2013 [Page 20] Internet-Draft MPRTP: Multipath RTP based on RTP Relay Application Mar 2013 The controller is implementation-specific. However, between the controller and the RTP relay node, all messages MUST be formatted according to the OpenPath protocol. 10.1 Protocol Overview OpenPath is based on a request/response transaction model. Each transaction consists of a request and a response. A response uses the same transaction id as is in the associated request to facilitate pairing. The transaction id is a 32-bit identifier generated by the request sender. All OpenPath messages begin with a common OpenPath header. OpenPath messages MAY contain a body. The structure and interpretation of a body depends on the message type. OpenPath messages are guaranteed delivery over a connection-oriented channel. All integer fields are carried in network octet order, that is, most significant byte first. Octets designated as padding have the value zero. OpenPath message types fall into three classes: relay-to-controller, controller-to-relay and symmetric. Relay-to-controller messages are initiated by the RTP relay node and used to manage the channel connection and update the controller of changes to the RTP relay node. Controller-to- relay messages are initiated by the controller and used to manage the Path- Table or inspect the state of the RTP relay node. Symmetric messages are initiated by either the controller or the RTP relay node. The message types used by OpenPath are described below. 10.1.1 Relay-to-Controller Relay-to-Controller messages are initiated by the controller and require a response from the controller. HELLO: The RTP relay node registers with the controller by sending a HELLO request. The HELLO request contain the unique identifier of the RTP relay node, the highest OpenPath protocol version supported by the RTP relay node, and the IP address and port of the RTP relay node for the relay service. The controller must respond with a HELLO response that indicates the outcome of registration. This is commonly performed upon establishment of the OpenPath connection channel. START: The RTP relay node starts relay service by sending a START request. The controller must respond with a START response that indicates the outcome of relay service startup. STOP: The RTP relay node may stop relay service temporarily by sending a STOP request. For instance, when the RTP relay node is overloaded, it may Leiwm, et al. Expires September 12, 2013 [Page 21] Internet-Draft MPRTP: Multipath RTP based on RTP Relay Application Mar 2013 want to refuse accepting any new relay service requests for a while. The controller must respond with a STOP response that indicates the outcome of relay service pause. During relay service pause, the RTP relay node still provides relay service for those existing relay paths. The RTP relay node may restart relay service by sending a START request after a while. BYE: The RTP relay node may terminate the relay service permanently by sending a BYE request, such as before terminating the OpenPath connection channel or exiting. Meanwhile, the RTP relay node ceases relay service for all existing relay paths. If the RTP relay node wants to start relay service again, it must first perform registration with the controller. NOTIFY: When the RTP relay node actively removes a path entry, it may notify the controller by sending a NOTIFY request. For instance, in order to save the resource, the RTP relay node actively removes those path entries which lack activity. 10.1.2 Controller-to-Relay Controller-to-Relay messages are initiated by the controller and require a response from the RTP relay node. FEATURES: The controller may request the capabilities of a RTP relay node by sending a FEATURES request. The RTP relay node must respond with a FEATURES response that specifies the capabilities of the RTP relay node. This is commonly performed after successful registration of the RTP relay node. STATISTICS: The controller may periodically collect statistics from the RTP relay node by sending STATISTICS requests. The RTP relay node must respond with a STATISTICS response that specifies current statistics of the RTP relay node. ADD_PATH: When the controller needs to assign relay paths for a media flow, the controller must send an ADD_PATH request to each RTP relay node on the assigned relay path. The RTP relay node must respond with an ADD_PATH response that specifies the outcome of adding a new path entry. A relay path is assigned successfully only when each RTP relay node replies with an ADD_PATH success response. UPDATE_PATH: The controller may want to modify an existing path entry in the Path-Table of a RTP relay node by sending a UPDATE_PATH request. For instance, a media stream may be "put on hold" and transmission of media may be ceased for a while. In this case, the controller may update the idle timeout and hard timeout of the corresponding path entries of all the RTP relay nodes on the affected relay paths to a longer time. The RTP relay node must respond with an UPDATE_PATH response that specifies the outcome of updating an existing path entry. Leiwm, et al. Expires September 12, 2013 [Page 22] Internet-Draft MPRTP: Multipath RTP based on RTP Relay Application Mar 2013 DELETE_PATH: The controller may delete an existing path entry in the Path- Table of a RTP relay node by sending a DELETE_PATH request, such as when a media stream ends normally. The RTP relay node must respond with a DELETE_PATH response that specifies the outcome of deleting an existing path entry. 10.1.3 Symmetric Symmetric messages are sent in either direction. ECHO: Echo requests MUST be sent periodically from either the controller or the RTP relay node. And the receiver must return an ECHO response. ECHO messages can be used to measure the latency of a controller-relay connection, as well as verify the peer's liveness. The receiver of an ECHO request must respond with an ECHO response, which consists of an OpenPath header plus the unmodified body of an ECHO request message. 10.2 Common Structures This section describes structures used by multiple messages. 10.2.1 OpenPath Common Header Common OpenPath header 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 |R|S| Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Relay ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Transaction ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Version (V): 6 bits This field identifies the version of OpenPath protocol version being used.The version defined by this document is one (1). R: 1 bit If the R bit is set, the message is an OpenPath request; otherwise, the message is an OpenPath response. S: 1 bit When the message is a request, this bit is reserved. When the message is a response, if the S bit is set, the message is a success response; otherwise, the message is a failure response. Leiwm, et al. Expires September 12, 2013 [Page 23] Internet-Draft MPRTP: Multipath RTP based on RTP Relay Application Mar 2013 Type: 8 bits This field identifies the type of the OpenPath messages. This document defines 11 OpenPath message types: +----------------------------------------------------------------+ | Type Value | Type Name | Sending Direction | +--------------+---------------+---------------------------------+ | 1 | HELLO | RTP relay -> Controller | +--------------+---------------+---------------------------------+ | 2 | BYTE | RTP relay -> Controller | +--------------+---------------+---------------------------------+ | 3 | ECHO | RTP relay -> Controller or | | | | Controller -> RTP relay | +--------------+---------------+---------------------------------+ | 4 | START | RTP relay -> Controller | +--------------+---------------+---------------------------------+ | 5 | STOP | RTP relay -> Controller | +--------------+---------------+---------------------------------+ | 6 | NOTIFY | RTP relay -> Controller | +--------------+---------------+---------------------------------+ | 7 | FEATURES | Controller -> RTP relay | +--------------+---------------+---------------------------------+ | 8 | STATISTICS | Controller -> RTP relay | +--------------+---------------+---------------------------------+ | 9 | ADD-PATH | Controller -> RTP relay | +--------------+---------------+---------------------------------+ | 10 | DETELE-PATH | Controller -> RTP relay | +--------------+---------------+---------------------------------+ | 11 | UPDATE-PATH | Controller -> RTP relay | +----------------------------------------------------------------+ Length: 16 bits The length field indicates the total length of the message in 32-bit words including the header and any padding. Relay ID: 32 bits This field is a 32-bit identifier that corresponds to a globally unique RTP relay node. It is generated by the RTP relay node when it startups, and remains unchanged during the entire lifecycle of the RTP relay node. Transaction ID: 32 bits This field identifies the transaction id associated with this message. It is randomly generated by the request sender and discarded when the associated response message is received. The transaction ids of responses must always match the request that prompted them. 10.2.2 Common Body of OpenPath Failure Responses Leiwm, et al. Expires September 12, 2013 [Page 24] Internet-Draft MPRTP: Multipath RTP based on RTP Relay Application Mar 2013 OpenPath failure responses of all message types MAY contain an optional body after the common OpenPath header. If the body is present, it conforms to a common structure 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Status code | Rlength | reason | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | reason | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Status code: 8 bits This field is a numeric result code that indicates the outcome of a request processing. Rlength: 8 bits This field is the length of the reason phrase in 16-bit word length. Reason: variable size This field is a short textual description of the status code. 10.2.3 Transport Address Structure A RTP relay node needs to advertise the controller about its transport address for relay service. The controller also needs to tell the RTP relay node about the transport address of its next-hop node for each associated path. A transport address is defined as follow. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Address Type | Pad(0) | Port | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type: 8 bits This field is the type of transport address. Namely: 1: IPv4 address 2: IPv6 address Port: 16 bits This field is the port number part of transport address. Address: 4 octets (IPv4), 16 octets (IPv6) Leiwm, et al. Expires September 12, 2013 [Page 25] Internet-Draft MPRTP: Multipath RTP based on RTP Relay Application Mar 2013 The IP address part of transport address. 10.3 OpenPath Request and Success Response Message Format 10.3.1 HELLO The HELLO request contains a body beyond a common OpenPath header. The body contains the transport address of the RTP relay node to provide relay service. 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 |R|S| Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Relay ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Transaction ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Address Type | Pad(0) | Port | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The HELLO success response only contains a common OpenPath header. 10.3.2 START/STOP/BYE The START/STOP/BYE requests and their success responses have no body; that is, they only contain a common OpenPath header. 10.3.3 ECHO An ECHO request consists of a common OpenPath header and an optional body. If the body is absent, the ECHO request/response messages are used to simply verify liveness between the controller and the RTP relay node. The body may contain a timestamp to check latency between the controller and the RTP relay node. Example: Leiwm, et al. Expires September 12, 2013 [Page 26] Internet-Draft MPRTP: Multipath RTP based on RTP Relay Application Mar 2013 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 |R|S| Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Relay ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Transaction ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NTP timestamp, most significant word | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NTP timestamp,least significant word | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ NTP timestamp: Using the timestamp format of the Network Time Protocol (NTP), which is in seconds relative to 0h UTC on 1 January 1900 [RFC1305]. 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. 10.3.4 NOTIFY/DELETE_PATH The NOTIFY/DELETE_PATH requests contain a body beyond a common OpenPath header. The body only contains a Path ID field. 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 |R|S| Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Relay ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Transaction ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Path ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Path ID: 32 bits This field is a 32-bit identifier that corresponds to a globally unique path. It is generated by the controller when assigning relay paths for a media flow. The NOTIFY/DELETE_PATH success responses only contain a common OpenPath header. 10.3.5 FEATURES Leiwm, et al. Expires September 12, 2013 [Page 27] Internet-Draft MPRTP: Multipath RTP based on RTP Relay Application Mar 2013 The FEATURES request only contains a common OpenPath header. The FEATURES success response contains a body beyond the common OpenPath header. (to be continued) 10.3.6 STATISTICS The STATISTICS request only contains a common OpenPath header. The STATISTICS success response contains a body beyond the common OpenPath header. (to be continued) 10.3.7 ADD-PATH/ UPDATE_PATH The ADD-PATH/ UPDATE_PATH requests contain a body beyond a common OpenPath header. The body contains match fields and result fields of a path entry. The result fields contain next-hop transport address and idle/hard timeout. 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 |R|S| Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Relay ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Transaction ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Path ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Address Type | Pad(0) | Port | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Idle timeout | Hard timeout | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Idle timeout: 16 bits This field is the number of seconds after which the path will timeout if no traffic. Hard timeout: 16 bits This field is the number of seconds after which the path must expire regardless of whether or not packets go through the path. The ADD-PATH/ UPDATE_PATH success responses only contain a common OpenPath header. 11. MPRTP-RA Packet Formats Leiwm, et al. Expires September 12, 2013 [Page 28] Internet-Draft MPRTP: Multipath RTP based on RTP Relay Application Mar 2013 In this section we define the RTP/RTCP protocol structures to meet the requirements described in the previous sections. 11.1 RTP Header Extension for MPRTP-RA The MPRTP-RA header extension is used to distribute a single RTP stream over multiple subflows which are transmitted along different paths. The header conforms to the one-byte RTP header extension defined in [9]. 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). 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0xBE | 0xDE | length=N-1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MPID | LEN | reserved | MPRTP-RA header data | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | .... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RTP payload | | .... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ MPID:This field corresponds to the type of MPRTP-RA packet.Namely: +----------------------------------------------------------------+ | MPID value | Use | +--------------+-------------------------------------------------+ | 0x01 | Subflow RTP header. For this case the LEN | | | is set to 6. | +--------------+-------------------------------------------------+ LEN: This field is the number that minus one of extension data bytes following the one-byte header. MPRTP-RA header data: This field carries the MPID specific data as described in the following sub-sections. Leiwm, et al. Expires September 12, 2013 [Page 29] Internet-Draft MPRTP: Multipath RTP based on RTP Relay Application Mar 2013 11.1.1 MPRTP-RA RTP Extensions 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 | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | 0xBE | 0xDE | length=2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0x1 | LEN=6 | reserved | Subflow-specific Seq Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Path ID | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | RTP payload | | .... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ MPID=0x1: This field indicates that the MPRTP-RA header extension carries subflow specific information. Subflow-Specific Sequence Number (SSSN): This field is sequence of the packet in the subflow. Each subflow has its own strictly monotonically increasing sequence number space. Path ID: This field is identifier of the path as well as the subflow. Every RTP along the same path carries the same unique path identifier. 11.2 RTCP Extension for MPRTP-RA (MPRTCP-RA) The RTCP header extension for MPRTP-RA is used to 1) provide RTCP feedback of per subflow to determine the characteristics of each path, 2) probe the transport capability of each path, and 3) keep alive each path. Leiwm, et al. Expires September 12, 2013 [Page 30] Internet-Draft MPRTP: Multipath RTP based on RTP Relay Application Mar 2013 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=MPRTCP-RA | length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SSRC of packet sender | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | SSRC_1 (SSRC of the first source) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |MPRTCP-RA Type | block length | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | MPRTCP-RA data | | .... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ PT=MPRTCP-RA=211: This field identifies that it is a Multipath RTCP packets. MPRTCP-RA Type: 8 bits This field corresponds to the type of MPRTP-RA RTCP packet. Namely: +---------------------------------------------------------------+ |MPRTCP-RA Type value | Use | +---------------------+-----------------------------------------+ | 0 | Subflow Specific Report | +---------------------+-----------------------------------------+ | 1 | Path Probe | +---------------------+-----------------------------------------+ | 2 | Keep Alive | +---------------------+-----------------------------------------+ block length: 8 bits This field is the length of the encapsulated MPRTCP-RA data in 16-bit word length following block length field. The value zero indicates there is no data following. MPRTCP-RA data: variable size This field will be defined later in the following sub-sections. 11.2.1 MPRTCP-RA Extensions for Subflow Reporting (SR/RR) When sending a report for a specific subflow the sender or receiver MUST add only the reports associated with that path. Each subflow is reported independently using the following MPRTCP-RA Feedback header. Leiwm, et al. Expires September 12, 2013 [Page 31] Internet-Draft MPRTP: Multipath RTP based on RTP Relay Application Mar 2013 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=MPRTCP-RA | length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SSRC of packet sender | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | SSRC_1 (SSRC of the first source) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0 | block length | reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Path ID #1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Subflow-specific reports | | .... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0 | block length | reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Path ID #2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Subflow-specific reports | | .... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ MPRTCP-RA Type=0 The value indicates that the encapsulated block is a subflow report. Path ID: 32 bits This field is the identifier of the path associated with the subflow that the endpoint is reporting about. Subflow-specific reports: variable Subflow-specific report contains all the reports associated with the path ID. For a sender, it MUST include a Subflow-specific Sender Report (SSR). For a receiver, it MUST include a Subflow-specific Receiver Report (SRR). Additionally, if the receiver supports subflow-specific extension reports then it MUST append them to the SRR. An example of SSR is shown below: Leiwm, et al. Expires September 12, 2013 [Page 32] Internet-Draft MPRTP: Multipath RTP based on RTP Relay Application Mar 2013 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=MPRTCP-RA | length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SSRC of packet sender | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | SSRC_1 (SSRC of the first source) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0 | block length | reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Path ID #1 | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ |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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 11.2.2 MPRTCP-RA Extensions for Subflow Path Probe The Relay Node block describes a method to represent capacity information of the relay node in a block format. (to be continued) 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=MPRTCP-RA | length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SSRC of packet sender | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | SSRC_1 (SSRC of the first source) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1 |block length=3 | reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Path ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ MPRTCP-RA Type=1 The value indicates that the encapsulated block is a subflow path probe. Leiwm, et al. Expires September 12, 2013 [Page 33] Internet-Draft MPRTP: Multipath RTP based on RTP Relay Application Mar 2013 11.2.3 MPRTCP-RA Extensions for Subflow Keep Alive This sub-section defines the RTCP header extension for keeping alive a relay path. 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=MPRTCP-RA | length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SSRC of packet sender | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | SSRC_1 (SSRC of the first source) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 2 |block length=3 | reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Path ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ MPRTCP_Type=2 The value indicates that the encapsulated block is a subflow Keep Alive. Path ID: 32 bits This field is the identifier of the path that the endpoint is keeping alive. 12. SDP Considerations The indication of the presence of the RTP header extension, and the advertisement of MPRTP-RA capability and relay paths, MUST be performed out- of-band, for example, as part of a SIP offer/answer exchange using SDP. This section defines dedicated extensions in SDP. SDP syntax and procedures are available that can be re-used or easily adapted to provide the necessary capabilities. 12.1 Signaling MPRTP-RA Header Extension in SDP The RTP header extensions (see Section 11) which used in a MPRTP-RA session need to be signaled in the out-of-band signaling during session setup. As defined in RFC5285, the sender MUST use the following URI in extmap: urn:ietf:params:rtp-hdrext:mprtp-relay. This is a media level parameter. Legacy RTP clients will ignore this header extension. Example: v=0 o=alice 2890844526 2890844527 IN IP4 192.0.2.1 s= Leiwm, et al. Expires September 12, 2013 [Page 34] Internet-Draft MPRTP: Multipath RTP based on RTP Relay Application Mar 2013 c=IN IP4 192.0.2.1 t=0 0 m=video 49170 RTP/AVP 98 a=rtpmap:98 H264/90000 a=fmtp:98 profile-level-id=42A01E; a=extmap:1 urn:ietf:params:rtp-hdrext:mprtp-relay 12.2 Signaling MPRTP-RA Capability in SDP A MPRTP-RA-capable participant of a media session MUST use SDP to indicate that it supports MPRTP-RA. The mprtp-relay attribute defined here will be used to indicate the support for MPRTP-RA. The syntax of the mprtp-relay attribute is defined using the following Augmented BNF, as defined in [RFC5234]. mprtp-relay-attrib = "a=" "mprtp-relay" CRLF ; flag to enable MPRTP-RA The endpoint MUST use "a=mprtp-relay" if it supports MPRTP-RA and would like to use it in the specific media session being signaling. The mprtp- relay attribute is a media level parameter. A MPRTP-RA-capable sender multiplexes RTP and RTCP packets of each subflow on a single port. To be compatible with legacy endpoints, the MPRTP-RA- capable endpoint MUST indicate support of multiplexing by adding "a=rtcp- mux" in SDP [RFC5761]. When an MPRTP-RA-capable endpoint receives an SDP containing "a=mprtp-relay" but without "a=rtcp-mux", the endpoint MUST infer that the peer, if as a sender, supports multiplexing of RTP and RTCP packets. The MPRTP-RA-capable sender MAY use multiple paths concurrently to increase throughput. If the desired media rate exceeds the current media rate, the MPRTP-RA-capable sender MUST renegotiate the application specific ("b=AS:xxx") [RFC4566] bandwidth. 12.3 Relay Path Advertisement in SDP The information of candidate relay paths MUST be advertised to the sender in the out-of-band signaling. The relay-path attribute is extended to advertise candidate relay paths in SDP. The syntax of the mprtp-relay attribute is defined using the following Augmented BNF, as defined in [RFC5234]. The definitions of DIGIT, SP and CRLF are according to RFC4234. relay-path-attrib = "a=" relay-path-label ":" counter SP path-id SP transport-address CRLF relay-path-label = "relay-path" counter = 1*DIGIT path-id = 32token-char transport-address = addrtype ":" unicast-address ":" port Leiwm, et al. Expires September 12, 2013 [Page 35] Internet-Draft MPRTP: Multipath RTP based on RTP Relay Application Mar 2013 ; addrtype from RFC4566, typically "IP4" | "IP6" ; port from RFC4566 unicast-address = IP4-address / IP6-address ; IP4-address from RFC4566 ; IP6-address from RFC4566 token-char = %x21 / %x23-27 / %x2A-2B / %x2D-2E / %x30-39 / %x41-5A / %x5E- 7E The path identifier and the next-hop transport address of the sender for each candidate relay path is encapsulated in a relay-path attribute. The parameter indicates the priority of the associated relay path and it is a monotonically increasing positive integer starting at 1. Number 1 is the highest priority. The counter must be reset for each media line. The relay-path attributes are ordered based on a decreasing priority level. The parameter indicates the path identifier of the associated relay path. The is the next-hop transport address of the sender for associated candidate relay path. The is the address type. This document only defines IP4 and IP6 for IPv4 addresses and IPv6 addresses respectively. Example: a=relay-path:1 1a3b6c9d0e2f6g1qazxsw23edcvfr45t IP4/192.0.3.2/10000 12.4 Offer/Answer When SDP is used to negotiate MPRTP-RA sessions following the offer/answer mode [RFC3264], the "mprtp-relay" attribute indicates the desire to transport media flow on multiple paths. If the offerer wishes to use MPRTP- RA, it MUST include a media-level "a=mprtp-relay" attribution in the initial SDP offer. If the answerer wishes to use MPRTP-RA, it MUST include this attribute in the answer. Even if the other party does not support MPRTP-RA, the offerer or the answerer can still unilaterally enable MPRTP-RA which is backwards compatible. When SDP is used in a declarative manner, the "mprtp-relay" attribute indicates that the message sender can send or receive media data over multiple paths. The message receiver SHOULD be capable to stream media to multiple paths or be prepared to receive media from multiple paths. The following sub-section shows an example of SDP offer and answer to negotiate MPRTP-RA sessions. Leiwm, et al. Expires September 12, 2013 [Page 36] Internet-Draft MPRTP: Multipath RTP based on RTP Relay Application Mar 2013 12.4.1 An Example We take the usage scenario shown in Figure 4 in Section 7.1 as an example. In this example, both the endpoints are MPRTP-RA capable. 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=rtcp-mux a=mprtp-relay 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=rtcp-mux a=mprtp-relay a=relay-path:1 1a3b6c9d0e2f6g1qazxsw23edcvfr45t IP4/192.0.3.1/10000 a=relay-path:2 0o9i8u7y6t5r4e3w2q0okm9ijn8uhb7y IP4/192.0.5.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 IP4 192.0.6.1 s= c=IN IP4 192.0.6.1 Leiwm, et al. Expires September 12, 2013 [Page 37] Internet-Draft MPRTP: Multipath RTP based on RTP Relay Application Mar 2013 t=0 0 m=video 36120 RTP/AVP 98 a=rtpmap:98 H264/90000 a=fmtp:98 profile-level-id=42A01E; a=rtcp-mux a=mprtp-relay 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=rtcp-mux a=mprtp-relay a=relay-path:1 2w3e4r5t6y7u8i9o0p1q2wsx3edc4rfv IP4/192.0.3.1/10000 a=relay-path:2 4r5t6y7u8i9o0p1q2w3e4rfv5tgb6yhn IP4/192.0.4.1/10000 13. IANA Considerations The following contact information shall be used for all registrations in this document: Contact: Weimin Lei mailto:leiweimin@ise.neu.edu.cn tel:+86-24-8368-3048 Note to the RFC-Editor: When publishing this document as an RFC, please replace "RFC XXXX" with the actual RFC number of this document and delete this sentence. 13.1 MPRTP-RA Header Extension This document defines a new extension URI to the RTP Compact Header Extensions sub-registry of the Real-Time Transport Protocol (RTP) Parameters registry, according to the following data: Extension URI: urn:ietf:params:rtp-hdrext:mprtp-relay Description: Multipath RTP based on relay Reference: RFC XXXX Leiwm, et al. Expires September 12, 2013 [Page 38] Internet-Draft MPRTP: Multipath RTP based on RTP Relay Application Mar 2013 13.2 MPRTCP-RA Packet Type A new RTCP packet format has been registered with the RTCP Packet type (PT) Registry: Name: MPRTCP-RA Long name: Multipath RTCP base on Relay Application Value: 211 Reference: RFC XXXX. This document defines a substructure for MPRTCP-RA packets. A new sub-registry has been set up for the sub-report block type (MPRTCP-RA Type) values for the MPRTCP-RA packet, with the following registrations created initially: Name: Subflow Specific Report Long name: Subflow Specific Report for Multipath RTP based on Relay Application Value: 0 Reference: RFC XXXX. Name: Path Probe Long name: Path Probe for Multipath RTP based on Relay Application Value: 1 Reference: RFC XXXX. Name: Keep Alive Long name: Keep Alive for Multipath RTP based on Relay Application Value: 2 Reference: RFC XXXX. Further values may be registered on a first come, first served basis. For each new registration, it is mandatory that a permanent, stable, and publicly accessible document exists that specifies the semantics of the registered parameter as well as the syntax and semantics of the associated sub-report block. The general registration procedures of [RFC4566] apply. 13.3 SDP Attributes In the registry for SDP parameters, the attributes named "mprtp-relay" and "relay-path" have been registered as follows: SDP Attribute ("att-field"): Attribute Name: mprtp-relay Long form: Multipath RTP based on Relay Application Type of name: att-field Type of attribute: Media level only Subject to charset: No Purpose: This attribute is used to indicate support for Multipath RTP based on Relay Application. Leiwm, et al. Expires September 12, 2013 [Page 39] Internet-Draft MPRTP: Multipath RTP based on RTP Relay Application Mar 2013 Reference: See this document Values: See this document. SDP Attribute ("att-field"): Attribute Name: relay-path Long form: Relay Path of Multipath RTP based on Relay Application Type of name: att-field Type of attribute: Media level only Subject to charset: No Purpose: This attribute is used to describe the path identifier and the next-hop transport address of the sender for a relay path. Reference: See this document Values: See this document. 14. Security Considerations TBD All drafts are required to have a security considerations section. See RFC 3552 [13] for a guide. 15. References 15.1 Normative References [1] Mills, D., "Network Time Protocol (Version 3) Specification, Implementation and Analysis", RFC 1305, March 1992. [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [3] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003. [4] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video Conferences with Minimal Control", STD 65, RFC 3551, July 2003. [5] 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. [6] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008. [7] Singer, D. and H. Desineni, "A General Mechanism for RTP Header Extensions", RFC 5285, July 2008. Leiwm, et al. Expires September 12, 2013 [Page 40] Internet-Draft MPRTP: Multipath RTP based on RTP Relay Application Mar 2013 [8] Johansson, I. and M. Westerlund, "Support for Reduced-Size Real-Time Transport Control Protocol (RTCP): Opportunities and Consequences", RFC 5506, April 2009. [9] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and Control Packets on a Single Port", RFC 5761, April 2010. 15.2 Informative References [10] Schulzrinne, H., Rao, A., Lanphier, R., "Real Time Streaming Protocol (RTSP)", RFC2326, April 1998. [11] 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. [12] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002. [13] Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on Security Considerations", BCP 72, RFC 3552, July 2003. [14] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006. [15] Westerlund, M. and S. Wenger, "RTP Topologies", RFC 5117, January 2008. [16] Marjou, X. and A. Sollaud, "Application Mechanism for Keeping Alive the NAT Mappings Associated with RTP / RTP Control Protocol (RTCP) Flows", RFC 6263, June 2011. 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 Leiwm, et al. Expires September 12, 2013 [Page 41] Internet-Draft MPRTP: Multipath RTP based on RTP Relay Application Mar 2013 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: liushaowei@research.neu.edu.cn Leiwm, et al. Expires 2013 [Page 42]