AVT Internet Draft S. Narayanan (Editor) Document: draft-narayanan-mrtp-00.txt D. Bushmitch Expires: January 9, 2005 Panasonic S. Mao Virginia Tech S. Panwar Polytechnic Univ July 09, 2004 MRTP: A Multi-Flow Real-time Transport Protocol Status of this Memo By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on January 9, 2005 Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. Narayanan et. al. Expires - January 13, 2005 [Page 1] Internet-draft MRTP:A Multi-Flow Real-time Transport Protocol July 2004 Abstract Multimedia data transport over ad hoc networks is a challenging problem. The dynamic nature of the underlying routing and the highly varying quality of the wireless communication links present additional hurdles for the transport of real-time traffic between hosts. However, the mesh topology of ad hoc networks implies the existence of multiple paths between any two nodes. It has been shown in the literature that path diversity provides an effective means of combating transmission errors and topology changes that are typical in ad hoc networks. Moreover, data partitioning techniques, such as striping and thinning, have been demonstrated to improve the queuing performance of real-time data. Recognizing the advantages of these techniques, as well as the increasing need for video services in ad hoc networks, we propose a new transport protocol to support multipath transport of real-time data. The new protocol, called Multi-flow Real-time Transport Protocol (MRTP), provides a convenient vehicle for real-time multimedia applications to partition and to transmit data using multiple flows. Even though the basic idea of MRTP is presented in the context of ad hoc networks, the benefits demonstrated by the use of MRTP is equally applicable to other types of IP network providing multi-media streaming services including the Internet. Conventions used in this document 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 [1]. Narayanan, et al. Expires - January [Page 2] Internet-draft MRTP:A Multi-Flow Real-time Transport Protocol July 2004 Table of Contents 1. Introduction...................................................4 2. Terminology....................................................5 3. Protocol overview..............................................6 3.1 Session and Flow Management................................8 3.2 Traffic Flow Allocator.....................................8 3.3 Flow Time Stamping and Sequence Numbering Module...........9 3.4 QoS Reporting Module......................................10 3.5 Comments on Real-time Stream Reassembly at the Receiver...10 4. MRTP Message Formats..........................................11 4.1 MRTP Data Packet..........................................11 4.2 MRTCP QoS Report Packets..................................12 4.3 MRTCP Session/Flow Control Packets........................15 4.4 Extension Headers.........................................17 4.5 MRTP Profiles.............................................18 5. Operation of MRTP/MRTCP.......................................18 5.1 MRTCP Session Establishment...............................18 5.2 MRTCP Session termination.................................21 5.3 Flow Addition.............................................21 5.4 Flow Deletion.............................................22 5.5 Data Transfer Issues......................................23 5.6 QoS Reports...............................................23 6. Traffic Partitioning..........................................23 7. Usage scenarios...............................................24 7.1 Unicast Video Streaming...................................24 7.2 Parallel Video Downloading................................25 7.3 Realtime Multicasting.....................................26 8. Comparison to existing protocol specifications................26 9. Protocol constants............................................27 9.1 Payload types.............................................27 9.2 Status field..............................................28 9.3 Timers....................................................28 9.4 Retries...................................................28 10. Open issues..................................................28 11. Security Considerations......................................28 Acknowledgments..................................................30 Author's Addresses...............................................30 Narayanan, et al. Expires - January [Page 3] Internet-draft MRTP:A Multi-Flow Real-time Transport Protocol July 2004 1. Introduction Ad hoc networks are wireless mobile networks without an infrastructure. Since no pre-installed base stations are required, ad hoc networks can be deployed quickly in applications such as conventions, disaster recovery operations, and battle fields communication. When deployed, mobile nodes cooperate with each other to find routes and relay packets for each other. It is foreseeable that real-time service will be needed in ad hoc networks once such networks become more widespread. As compared to a wire line link, a wireless link usually has higher transmission error rates because of shadowing, fading, path loss, and interference from other transmitting wireless users. An end-to-end path found in ad hoc networks has an even higher error rate since it is the concatenation of multiple wireless links. Moreover, user mobility creates a constantly changing network topology. In addition to user mobility, ad hoc networks need to reconfigure themselves when users join or leave the network. In ad hoc networks, an end-to-end route may only exist for a short period of time. Real-time multimedia services have stringent delay and bandwidth requirements. Even though some packet loss is generally tolerable, the quality of reconstructed video and audio will be impaired, as errors propagate to the consecutive frames (case of the dependency introduced among frames belonging to one group of pictures (GOP) at the encoder [2]). It has been shown that, in addition to traditional error control schemes, e.g., Forward Error Correction (FEC) and Automatic Repeat Request (ARQ), path diversity provides additional dimension for multimedia coding and transport design [3][4][5]. Using multiple paths can provide higher aggregate bandwidth, better error resilience, and load balancing for a multimedia session. Similar observations were made in wireline networks for audio streaming [6] and video streaming using multiple servers [7]. Many believe that multipath transport has more potential in ad hoc networks, where link bandwidth may fluctuate and paths are generally unreliable. In addition, multipath routing is relatively simple since many ad hoc routing protocols can return multiple paths for a route query at a relatively small additional cost [8] as compared to a single path routing. In addition to the above advantages, data partitioning techniques, such as striping [9] and thinning [10], have been demonstrated to improve the queuing performance of real-time data. Using multiple paths for real-time transport provides a means for traffic partitioning and shaping, which in turn reduces short term Narayanan, et al. Expires - January [Page 4] Internet-draft MRTP:A Multi-Flow Real-time Transport Protocol July 2004 correlation in real-time traffic and thus improves the queueing performance of the underlying network queues [10][11]. This draft describes a new protocol, the Multi-flow Real-time Transport Protocol (MRTP), for real-time transport over ad hoc networks using multiple paths. MRTP is a transport protocol recommended to be implemented in the user space of the hosts operating system. Given multiple paths maintained by an underlying multipath routing protocol, MRTP and its companion control protocol, the Multi-flow Real-time Transport Control Protocol (MRTCP), provide essential support for multiple path real-time transport, including session and flow management, data partitioning, traffic dispersion, timestamping, sequence numbering, and Quality of Service (QoS) reporting. 2. Terminology This document uses the following terms. Many terms used by this document is compatible with RTP [20], hence the current version of this document only defines the terminology specifically introduced by the MRTP/MRTCP protocol. MRTP Flow - A designation of real-time data packets between the sender and receiver, defined by a four tuple, , that uniquely identifies a flow of data packets between two IP end points. This is similar to an RTP flow. MRTP Session - An association of one or more MRTP flows, intended to carry a single original real-time multimedia stream between the sender and the receiver Sender - the host which is the originator of the real-time traffic Receiver - the host to which real-time traffic is destined Initiator - the originator of the first MRTCP signaling packets in order to manage the MRTP session. Responder - the receiver of the first MRTCP signaling packet in managing the MRTP session. MRTP packet - the data packet defined by this document which carries MRTP data. MRTCP packet - Narayanan, et al. Expires - January [Page 5] Internet-draft MRTP:A Multi-Flow Real-time Transport Protocol July 2004 the signaling packets and QoS reports defined by this document to manage MRTP sessions and provide QoS information on the session respectively. Sender report - MRTCP packet originated by the sender of the MRTP data packets to describe various QoS-related parameters of the MRTP flow or MRTP session Receiver report - MRTCP packet originated by the receiver of the MRTP data packets to describe various reception QoS-related parameters of the MRTP flow or MRTP session 3. Protocol overview MRTP provides a framework for applications to transmit real-time data over multiple real-time flows (what will be called association of flows). MRTP provides end-to-end transport service to any two hosts with terminating MRTP protocol stacks. To enable the end-to-end real- time transport MRTP establishes multiple streams, or in other words, MRTP established real-time session over the association of multiple real-time flows. Each flow is similar to the flow created by a well- known RTP protocol. A companion control protocol, MRTCP, provides the essential session-based and flow-based control (including session management functions), and QoS feedback used for assuring the end-to- end quality of service transport session. Figure 1 illustrates an example MRTP session, in which three flows are used. The sender (S) first partitions the real-time multimedia stream into several substreams. Applications can make the choice of data partitioning method and parameters of data partitioning based on particular requirements at hand (see Sect. 6). Then, each substream is assigned to one flow or multiple flows (i.e., substream could be replicated over multiple flows) by the MRTP traffic allocator, and sent to traverse path, partially or fully disjoint with other flows toward the receiver (R). The receiver reassembles the multiple flows it receives using a set of re-sequencing buffers, each corresponding to each flow. MRTP data packets received from various flows are put into their right substream order using the MRTP flow timestamps and the sequence numbers carried in packetsÆ headers. The final stream reassembly from the corresponding substreams occurs in the final stream reassembly buffer, as the flows are re-arranged by the processes inverse to that of traffic partitioning and flow assignment. Narayanan, et al. Expires - January [Page 6] Internet-draft MRTP:A Multi-Flow Real-time Transport Protocol July 2004 --------->-----------(o)------------->-------------- / \ | | ( S )----->-------(o)----->------(o)------------>-----( R ) | | \ / --------->-----------(o)--------------->------------ Figure 1 Example MRTP Session The protocol stack of MRTP is shown in Figure 2. MRTP uses UDP datagram service for real-time transport and TCP/UDP protocols for MRTCP. Specifically, TCP is used for all flow and session management communications by MRTCP, while UDP is used for MRTCP QoS reporting. An underlying multipath ad hoc routing protocol maintains multiple paths from the source (S) to the receiver (R). +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | MRTP || MRTCP | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | UDP || TCP | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IP | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2 MRTP Protocol Stack Each MRTP flow utilizes UDP traffic between different set of UDP ports, thus allowing for path differentiation by the underlying routing protocol. This specification does not address the problem of specific routing mechanisms for MRTP flows. The main functional components (blocks) of the MRTP protocol architecture are: (1) Session and Flow Management Module, (2) Traffic Flow Allocator (also responsible for final stream reassembly at the receiver), (3) Flow Time Stamping and Sequence Numbering Module, (4) QoS Reporting Module. These components are described in greater detail in the following subsections. Narayanan, et al. Expires - January [Page 7] Internet-draft MRTP:A Multi-Flow Real-time Transport Protocol July 2004 +-------------------------------+ +--------------------------+ | Sessions and Flow Mngmt. | - | QoS Reporting | +-------------------------------+ +--------------------------+ | | +-------------------------------+ +--------------------------+ | Traffic Flow Allocator | - |Time Stamping and Seq. Num| +-------------------------------+ +--------------------------+ Figure 3 MRTP Architecture 3.1 Session and Flow Management MRTP is a session-oriented protocol (unlike well-known RTP). MRTP Session is defined as a ready to stream or an actively streaming association of multiple MRTP flows. Each MRTP session normally corresponds to a single original end-to-end real-time stream transmitted by MRTP between a sender (S) and a receiver (R). An MRTP session should be established using MRTP Control Protocol (MRTCP) prior to any actual MRTP data streaming over MRTP flows taking place. Using MRTCP Sender (S) and Receiver (R) nodes exchange information on available paths, session and flow IDs, and initial sequence numbers as part of the session establishment mechanism. Since the paths in an ad hoc network are short-lived, the set of MRTP flows used in an MRTP session is not static. Throughout any active MRTP session, a new flow may be added to the session when a better path is found, and a stale or otherwise undesired flow may be removed from the session based on QoS reports. Each MRTP session has a unique and randomly generated Session_ID, and each flow in the session has a unique and randomly generated Flow_ID as well. All MRTP data packets belonging to same session carry its Session_ID, and packets belong to a particular flow carry the corresponding MRTP Flow_ID. For additional details on MRTP session and flow management using MRTCP please see section 5. 3.2 Traffic Flow Allocator The MRTP Traffic Allocator module partitions and disperses the applicationÆs real-time traffic stream among multiple MRTP flows at the MRTP Sender (S). MRTP Traffic Allocator module also does the reverse stream reconstruction from multiple flows at the MRTP Receiver (R) node. A simple traffic partitioning scheme, which assigns multimedia streamÆs data to multiple flows using the round-robin-based algorithm is provided on the default basis within the MRTP protocol engine. This algorithm partitions applicationÆs traffic among flows in round- robin fashion on both, the equal and the variable-sized block basis. Narayanan, et al. Expires - January [Page 8] Internet-draft MRTP:A Multi-Flow Real-time Transport Protocol July 2004 In order not to constraint the traffic partitioning toward the round- robin type only, MRTP provides the capability for applications to partition senderÆs traffic into multiple flows themselves. Application utilizing MRTP transport MAY utilize some application- specific traffic partitioning scheme (see section 6 for greater detail). The mapping between substreams and flows is established during MRTP session establishment procedure. Section 6 also describes the implications of various traffic partitioning approaches to transmitted traffic characteristics and underlying complexity of MRTP. Traffic partitioning by a Traffic Allocator can be viewed as a two- step process. First, original stream data is partitioned using some data partitioning scheme thus producing multiple substreams. Second, substreams are assigned to their corresponding MRTP flows. Each produced can be assigned to one more MRTP flows. Alternatively, several substreams could be also combined and carried in a single MRTP flow. This provides for a highly flexible stream flow partitioning scheme. When multiple MRTP flows are reconstructed at the (R) node (utilizing flow sequence numbering and MRTP flowID headers), the processes inverse to the originally applied substream flow assignment process and flow partitioning process must be utilized by the traffic Allocator in order to reconstruct the original traffic stream. This reconstruction occurs in the final stream reconstruction buffer. 3.3 Flow Time Stamping and Sequence Numbering Module MRTP protocol data units (PDUs) or simply so-called MRTP packets are similar to RTP packets in their structure and function. Their packet format is described in detail in Sect. 5. To provide support for real-time transport mechanisms and QoS assessment of the MRTP flows and MRTP session performance, time-stamping and sequence numbering is applied toward all MRTP packets. These two functions are similar to those performed in RTP [20] for RTP flow management and QoS. MRTP Timestamps are used for payload synchronization purposes, along with providing ability to determine transmission jitter, delay and other QoS characteristics. The Timestamp carried in an MRTP data packet denotes the sampling instance of the first byte in its payload. The sequence number indicates the relative positioning of this MRTP packet in the whole packet substream assigned to a particular MRTP flow. Sequence number can be used by the receiving node to detect MRTP packet loss and to attempt to restore the original packet sequence. Each flow is assigned a randomly generated initial sequence Narayanan, et al. Expires - January [Page 9] Internet-draft MRTP:A Multi-Flow Real-time Transport Protocol July 2004 number during the MRTP session set up time, or when the flow is added into the ongoing session. The flow sequence number is increased by one for each packet transmitted in this flow. 3.4 QoS Reporting Module MRTP QoS Reporting Module generates periodic QoS Sender and Receiver Reports. An MRTP Sender Report (SR) or Receiver Report (RR) carries both, the per-flow QoS statistics and the overall MRTP QoS session statistics. These reports allow (S) and (R) to communicate to each other various QoS parameters of the current MRTP session and its associated MRTP flows. For example, the overall MRTP session packet loss rate can be easily determined from individual MRTP flows loss rates. Session and flow QoS-related characteristics are also made available to applications via corresponding MRTP API function calls. Both, SR and RR packets are PDUs of an MRTCP - - a Multi-Flow Real-time Control Protocol, a companion control protocol of an MRTP. A single SR or RR can carry QoS report for a single or multiple MRTP flows. In case multiple flows statistics are included, these are transmitted in multiple report blocks, as indicated by the format of SS and RR packets (see section 4.2). Unlike RTP, the MRTP SR and RR SHOULD be sent at an interval set by the application. The default interval for sending RR and SR SHOULD be set to one for every 10 data frames. Since the number of the participants in the MRTP session is relatively small (2 for point-to- point MRTP session, and possibly more for other complex MRTP usage scenarios TBD). Timely QoS reports enable S and R nodes to quickly adapt to the frequent path failures and rate fluctuations characteristic of ad hoc networks. For example, the encoder can change the coding parameters or encoding mode for the next frame, introducing more (or less) redundancy for error resilience, or the traffic allocator can modify substream-flow allocation to avoid the use of a stale MRTP flow. Session QoS statistics are easily derived from the SRs and RRs associated with sessionÆs MRTP flows. 3.5 Comments on Real-time Stream Reassembly at the Receiver The receiver (R) Traffic Allocator uses a separate reassembly buffer for each MRTP flow to reorder the received packets, the process during which the flow sequence numbers of the MRTP packets are used to put them in substreams original order. The original real-time data stream is reconstructed by combining the substreams, using the session IDs, flow IDs and sequence numbers in the MRTP packet headers. The substream to flow mapping (not necessarily one-to-one Narayanan, et al. Expires - January [Page 10] Internet-draft MRTP:A Multi-Flow Real-time Transport Protocol July 2004 mapping) must also be applied using the substream number in the MRTP packet header. For reliable transport protocols, a packet arriving early will stay in the re-sequencing buffer waiting for all the packets with the smaller sequence numbers to arrive. On the other hand, for most of the real-time applications, a received frame is decoded and displayed according to its timestamp and the display timer. Therefore, a deadline for each packet is enforced. In addition, because of the error control (e.g. FEC and MDC) and error concealment (e.g. copy- from-the-previous-frame) schemes applied at the decoder, a certain amount of packet loss is tolerable. There is plenty of literature on the re-sequencing delay, e.g., see [12] and [13]. Previous work shows that both the re-sequencing delay and buffer requirements are moderate if the traffic allocation is adaptive to the path conditions inferred from the QoS feedbacks. 4. MRTP Message Formats MRTP/MRTCP defines three types of packets for data and control, namely, MRTP data packets, MRTCP QoS report packets, and MRTCP session/flow control packets. It also provides the flexibility of defining new extension headers or profiles for future multimedia applications. 4.1 MRTP Data Packet The format of an MRTP data packet is illustrated in Fig. 5.1 The header fields are explained as follows: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Version|Pad|E|M| Payload Type | Source ID |Destination ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Session ID | Flow ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Substream number | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flow Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Timestamp | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Payload | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | à | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Payload | Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 5.1 Narayanan, et al. Expires - January [Page 11] Internet-draft MRTP:A Multi-Flow Real-time Transport Protocol July 2004 Version: 4 bits, version of MRTP/MRTCP. Pad: 2 bits, padding bytes are put at the end to align the packet boundary to 32 bits word. There could be 0 to 3 padding bytes. E (Extension): 1 bit, if set, the fixed header is followed by one or more extension headers, with a format defined later. M (Marker): 1 bit, it is used to allow significant events such as frame boundaries to be marked in the packet stream. Payload Type: 8 bits, it carries a value indicating the format of the payload. The values are defined in a companion profile. It is compatible with RTP's profile. Note that this field is one bit longer than that in RTP. This bit can be used to define new extension headers which are not defined in the RTP profiles. Source ID: 8 bits, it is the ID of the sender of this packet. It is randomly generated at the session setup time. Destination ID: 8 bits, it is the ID of the receiver of this packet. It is randomly generated at the session setup time. Session ID:16 bits, it is the randomly generated ID of the MRTP session, which is carried by all the packets belonging to this session. Flow ID: 16 bits, it is the ID of the flow, randomly generated at the session setup time, or when a new flow joins the association. Substream Number: A number uniquely identifying the substream the current packet belongs to within the partitioned stream. Flow Sequence Number: 32 bits, it is the sequence number of this packet in the flow belongs to. The initial flow sequence number is randomly generated in the session setup time or when the new flow joins the session. Timestamp: 32 bits, it reflects the sampling instance of the first byte in payload. Payload: the multimedia data carried in the packet. Padding: 0 to 3 bytes, it is used to align the packet boundary with 32 bits word. 4.2 MRTCP QoS Report Packets SR packets are the QoS report packets sent by a sender. The MRTP SR packet format is shown in Fig.5.2. RR packets have a format similar to the SR packet format, with the Total Packet Count and the Total Octet Count fields removed. Some of the header fields are the same as that of MRTP. The new fields are explained as follows: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Version| R |E|R| Payload Type | Source ID |Destination ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Session ID | Number of Flows | Narayanan, et al. Expires - January [Page 12] Internet-draft MRTP:A Multi-Flow Real-time Transport Protocol July 2004 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Current FlowID | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NTP Timestamp, Most significant word | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NTP Timestamp, Least significant word | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MRTP Timestamp | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Session Total packet count | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Session Total octet count | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Session Inter arrival jitter | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Session Last report received (SLR) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Session Delay since last report (SDLR) | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | Flow ID | Source ID | Destination ID| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Total packet count | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Total octet count | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Inter arrival jitter | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Highest sequence number received | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Last report received (LR) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Delay since last report (DLR) | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | Flow ID | Source ID | Destination ID| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | à | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | à | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | Profile-specific extensions | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 5.2 Version: 4 bits. Version of the MRTP. Revd: 4 bits. These four bits are reserved for future use. Payload Type: 8 bits. Note MRTP uses inband signlling. This field is used to multiplex/demultiplex different MRTP/MRTCP packets. Narayanan, et al. Expires - January [Page 13] Internet-draft MRTP:A Multi-Flow Real-time Transport Protocol July 2004 Source ID: 8 bits. The node ID of the source of this packet. It is randomly generated during the session setup time. Note that collisions in this field should be resolved. Destination ID: 8 bits. The node ID of the destination of this packet. It is randomly generated during the session setup time. When a flow has multiple receivers, the source ID and destination ID are used to discriminate them. Session ID: 16 bits. The ID of the MRTP session. Current Flow ID: 16 bits. The ID of the flow via which this report is sent. Length: 16 bits. The total length in bytes of this report packet. NTP Timestamp: 64 bits. It indicates the wallclock time when this report was sent so that it may be used in combination with timestamps returned in reception reports from other receivers to measure the round-trip time (RTT). MRTP Timestamp: 32 bits. This is the MRTP timestamp corresponding to the same time as the NTP timestamp. This is used with NTP Timestamp for synchronization and RTT estimation. %Corresponds to the same time as the NTP timestamp (above), but in the same units and with the same random offset as the RTP timestamps in data packets. It may be used in synchronization, in estimating the RTP clock frequency, and in RTT estimation. Session Total Packet Count: 32 bits. This is the total number of MRTP data packets sent on this session. This can be used by a receiver to compute the loss ratio of the session. Session Total Octet Count: 32 bits. This is the total number of multimedia data bytes sent on this session. Session Interarrival Jitter: 32 bits. It is the interarrival jitter of this session, calculated using the same algorithm as RTP (Appendix A.8 of [20]. Session Last Report Received: 32 bits. We use the middle 32 bits out of 64 in the NTP timestamp received as part of the most recent MRTCP report packet from this session. Session Delay Since Last Report Received: 32 bits. This is the delay, expressed in units of 1/65536 seconds, between receiving the last SR or RR packet from this session and sending this report. Flow ID: 16 bits. The ID of the flow this report block is about. Source ID: 8 bits. The ID of the source of this flow being reported in the current block. Destination ID: 8 bits. The ID of the receiver of this flow being reported in the current block. Note this is used when a flow has multiple receivers, Total Packet Count: 32 bits. This is the total number of MRTP data packets sent on this flow. This can be used by a receiver to compute the loss ratio of the flow. Total Octet Count: 32 bits. This is the total number of multimedia data bytes sent on this flow. Narayanan, et al. Expires - January [Page 14] Internet-draft MRTP:A Multi-Flow Real-time Transport Protocol July 2004 Interarrival Jitter: 32 bits. It is the interarrival jitter of this flow, calculated using the same algorithm as RTP (Appendix A.8 of [20]. Highest Sequence Number Received: 32 bits. This is he highest sequence number received in this flow. Last Report Received: 32 bits. We use the middle 32 bits out of 64 in the NTP timestamp received as part of the most recent MRTCP report packet from this flow. Delay Since Last Report Received: 32 bits. This is the delay, expressed in units of 1/65536 seconds, between receiving the last SR or RR packet from this flow and sending this report. Profile-Specific Extensions: extension of this format can be defined in future profiles. Note that to increase the reliability of feedbacks, RR or SR packets may be sent on the best path or sent on multiple paths. In the latter case, the MRTP Timestamp field is used to screen old or duplicated reports. With MRTP, both the sender and the receiver estimate the RTT. The estimated RTT can be used to adapt to the transmission conditions, or to set the retransmission timers for session/flow control packets. 4.3 MRTCP Session/Flow Control Packets MRTCP control packets include the packets used to set up an MRTP session, to manage the set of flows in use, and to describe a participant of the MRTP session. The Hello Session packet is sent by either a sender or a receiver (called the initiator) to initiate an MRTP session. The packet format is shown in Fig. 5.3.1. Following the common header, there is a randomly generated session ID and the total number of flows proposed to be used in this session. Next is a number of flow maps, each maps a flow ID to the corresponding source/destination sockets and the substream. A randomly generated initial sequence number for the flow follows the flow map. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Version| R |E|R| Payload Type | Source ID |Destination ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Session ID | Number of Flows | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Status Field | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | Flow ID | Source ID | Destination ID| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Narayanan, et al. Expires - January [Page 15] Internet-draft MRTP:A Multi-Flow Real-time Transport Protocol July 2004 | Substream number | Flow Status Field | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Flow| Source IP address | 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Info| Destination IP address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Port number | Destination port number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Initial Flow Sequence number | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ Flow | Flow ID | Source ID | Destination ID| 2 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Info | à | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | à | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | Profile specific extensions | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 5.3.1 An ACK Hello Session packet is sent to acknowledge the reception of a Hello Session packet or another ACK Hello Session packet. Its format is similar to the Hello Session packet format, but with two differences: (1) the Payload Type field has a different value; and (2) The Initial Flow Sequence Number field is replaced by a Flow Status field. A value of SUCCESS for this field means the proposed flow has been confirmed by the remote node, while a value of FAIL means the flow is denied. The values of these macros are defined in the MRTP profiles. MRTP Bye Session and ACK Bye Session packets are used to terminate an MRTP session. The format of a Bye Session packet is given in Fig. 5.3.2. The format of an ACK Bye Session packet is similar to Fig.5.3.2. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Version| R |E|R| Payload Type | Source ID |Destination ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Session ID | Number of Flows | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Status Field | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Profile specific extensions | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 5.3.2 Narayanan, et al. Expires - January [Page 16] Internet-draft MRTP:A Multi-Flow Real-time Transport Protocol July 2004 Flow control packets, Add/Delete Flow and ACK Add/Delete Flow, are used to add or remove flows from an MRTP session. The format of the Add Flow (ACK Add Flow) packets is similar to the Hello Session (ACK Hello Session) format, with different Payload Type values. The Delete Flow (ACK Delete Flow) packet format is similar to that of the Hello Session (ACK Hello Session) packet, but with different Payload Type values and without the Initial Flow Sequence Number field. The fields in the packet structures defined in the sections are defined similar to the descriptions in section 4.1 and 4.2. Participant Descriptions as in RTP, MRTP uses Source Description to describe the source and CNAME to identify an end point. In MRTP, each participant is also identified by a unique ID, e.g., a source ID or a destination ID. The IDs can be randomly assigned, or be calculated from the CNAME, e.g., using a hash function. 4.4 Extension Headers MRTP uses extension headers to support additional functions not supported by the current headers. The extension header format is given in Fig.5.4. The Type field is defined by MRTP profiles. The MRTP extension header has a variable length, indicated by the length 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Version| R |E|R| Payload Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Extension header specific data (variable length) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 5.4 Several examples of the MRTP extension headers are: Source routing extension header: since multiple paths are used in MRTP, source routing can be used to explicitly specify the route for each packet. However, if the lower layers do not support source routing, application-level source routing can be implemented by defining a source routing extension header carrying the route for the packet. Authentication extension header: this header provides a simple authentication mechanism using an ID field and a Password field encrypted with application specific encryption schemes. This extension header can be used in the session/flow control packets to validate the operations requested, or in the RR or SR to validate the QoS report. Narayanan, et al. Expires - January [Page 17] Internet-draft MRTP:A Multi-Flow Real-time Transport Protocol July 2004 Striping extension header: this extension header should have fields pointing to the starting timestamp and the ending timestamp of a video stream, which may be stored on several distributed servers. When downloading the video in parallel from the servers, the receiver uses these fields to tell each server which segment of the video stream should be downloaded from it. We borrow the daisy-chain headers idea from IPv6 [14]. There is a one-bit Extension field in the MRTP/MRTCP common header and all the extension headers. If this bit is set to 1, there is another header following the current header. This provides flexibility to combine different extension headers for a specific application. 4.5 MRTP Profiles Like RTP, MRTP needs additional profile specifications to define sets of payload type codes and their mapping to payload formats, and payload format specifications to define how to carry a specific encoding. These profiles and payload format specifications are compatible with those of RTP. New multimedia services can be easily supported by defining new MRTP profiles. 5. Operation of MRTP/MRTCP MRTP is a session-oriented protocol that requires management of the MRTP session to establish the associations between flows and session and between substreams and flows. Modification of these associations during the lifetime of the session is also required. This section defines a set of session operations and the state transition at the MRTP end nodes to execute these operations. These MRTP operations use the packet formats defined in section 4. Session operations can be initiated either by the sender or by the receiver of the data stream. The end point that initiates the operation is referred to as the æinitiatorÆ and the other node is referred to as the æresponderÆ. 5.1 MRTCP Session Establishment The MRTCP session establishment procedure allows the initiator to suggest a specific ææsubstream-to-flowÆÆ mapping and a ææflow-to- sessionÆÆ mapping. If the responder agrees with the suggestion, it can accept the session request and an MRTP session is established between the two nodes. If the responder finds the associations un-acceptable, it can reject the request. Figure 7.1 provides the state transition diagram the MRTP end nodes MUST follow to establish an MRTP session. This state transition is unique to a session ID, i.e. a state variable should be maintained for each of the session ID the particular end node is dealing with. Narayanan, et al. Expires - January [Page 18] Internet-draft MRTP:A Multi-Flow Real-time Transport Protocol July 2004 The initiator MUST allocate the required number of ports for the flows it is planning to use in the session. Then the initiator generates a Hello packet as described in section 4.3. The initiator MUST fill-in only the source port field in the flow maps or the destination port field depending on whether it is the sender or the receiver of data of the session. The other port number in the flow map MUST be initialized to zero. The initiator MUST also assign the substream number for each of the flows requested. After transmitting the Hello packet to the responder, the state for the session ID is set to INITIATED. If no response is received within HELLO_PACKET_TIMER time, the Hello packet MUST be retransmitted HELLO_PACKET_RETRY number of times. If all the retries fail, a SESSION_ESTABLISHMENT_FAILED error is returned to the higher layer. When the Hello packet is received at the responder, the responder verifies the session ID in the Hello packet is not already in use. If the session ID is already in use and the current state of the session is IN_PROGRESS, the responder MUST ignore the Hello packet. If the session ID is already in use and the current state is not IN_PROGRESS, the responder sends an Ack Hello packet with Status field set to FAILED. If the session ID is not in use, the responder checks if it can support the session with the corresponding number of flows as specified in the Hello packet. It sets the state for the session ID to IN_PROGRESS. Then the responder generates an Ack Hello packet for transmission to the initiator. In the Ack Hello packet, the responder MUST set the Number of Flows field to the number of flows it is willing to support - - this value MUST be less than or equal to the Number of Flows field in the Hello packet. The responder then opens ports for each of the flows it can support and MUST set the value in the source or the destination port number of the flows maps depending on whether it is the sender or receiver of data. The flow status field for the flows that are accepted MUST be set to SUCCESS and the flows not accepted MUST be set to FAIL. The responder can leave one of the port numbers in the flow map for flows not accepted to be zero. The Ack Hello packet is retransmitted ACK_PACKET_RETRY number of times every ACK_PACKET_TIMER time. If all the retries fail, the session ID is deleted from the active-session list. When the initiator receives Ack hello packet, it verifies whether the number of flows suggested is acceptable, if not an Ack Hello packet with global status field set to FAILURE MUST be returned to the responder. If the value is acceptable, returns the Ack hello packet back to the responder and sets its state for the session ID to CONNECTED. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Current State | Event | Action | End State | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Init | Send Hello | None | Initiated | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Narayanan, et al. Expires - January [Page 19] Internet-draft MRTP:A Multi-Flow Real-time Transport Protocol July 2004 | Init | Receive Hello | Send Ack | In_Progress | | | && acceptable | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Init | Receive Hello | Send Ack | Init | | | && unacceptable | fail | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Timer Expiry | | | | Initiated |&& retry count < | Send Hello | Initiated | | | HELLO_PACKET_RETRY | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Timer Expiry | | | | Initiated |&& retry count >= | None | Failed | | | HELLO_PACKET_RETRY | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Initiated | Receive Hello | Send Ack | Initiated | | | | fail | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Initiated | Receive Ack | Send Ack | Connected | | | && acceptable | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Initiated | Receive Ack | Send Ack | Failed | | | && unacceptable | fail | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | In Progress | Receive Hello | Ignore | In_Progress | | | from same source | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | In Progress | Receive Hello | Send Ack | In_Progress | | | from diff source | fail | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Ack timer expiry | | | | In Progress | && retry count < | Re-send Ack | In Progress | | | ACK_PACKET_RETRY | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Ack timer expiry | | | | In Progress | && retry count >= | None | Failed | | | ACK_PACKET_RETRY | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | In Progress | Receive Ack fail | None | Failed | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | In Progress | Receive Ack Success | None | Connected | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Failed | None |Inform Higher | Init | | | | layer | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 6.1 Narayanan, et al. Expires - January [Page 20] Internet-draft MRTP:A Multi-Flow Real-time Transport Protocol July 2004 5.2 MRTCP Session termination Either the sender or the receiver of the data stream can initiate termination of the session. Figure 6.2 provides the state transition table to be used by these end nodes in handling the MRTCP BYE packet. As with session establishment, this state table is to be used per session ID. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Current State | Event | Action | End State | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Connected | Send Bye | None | Termination | | | | | _Initiated | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Connected | Receive Bye | Send Ack | Disconnected| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Termination | Timer Expiry | | Termination | | _Initiated |&& retry count < | Send Bye | _Initiated | | | BYE_PACKET_RETRY | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Termination | Timer Expiry | | | | _Initiated |&& retry count >= | None | Failed | | | BYE_PACKET_RETRY | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Termination | Receive Bye | Send ack | Disconnected| | _Initiated | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Termination | Receive Ack | None | Disconnected| | _Initiated | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Termination | Receive Hello | Send Ack | Termination | | _Initiated | from diff source | fail | _Initiated | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Failed | None |Inform Higher | Init | | | | Layer | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 6.2 If the initiator fails to received a response from the responder after BYE_PACKET_RETRY number of retries, it MUST assume the session to be terminated, clear all internal state and release all memory/ports used by the session. The responder MUST always accept a termination request and acknowledge the request with a ACK BYE packet. 5.3 Flow Addition When a new path is found, a new flow can be added to the association by sending an Add Flow packet. These mechanisms enable MRTP to quickly react to topology changes in the ad hoc network. Figure 6.3 depicts the state transition table for flow addition. This table is Narayanan, et al. Expires - January [Page 21] Internet-draft MRTP:A Multi-Flow Real-time Transport Protocol July 2004 very similar to session establishment operation except that on failure the state of the session is still CONNECTED. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Current State | Event | Action | End State | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Connected | Send Hello (ADD) | None |ADD Initiated| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Connected | Receive Hello (ADD) | Send Ack | ADD | | | && acceptable | | succeeded | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Connected | Receive Hello (ADD) |Send Ack fail | ADD | | | && unacceptable | | failed | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ADD | Timer Expiry | | ADD | | Initiated |&& retry count < |Send Hello(ADD)| Initiated | | | HELLO_PACKET_RETRY | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ADD | Timer Expiry | | ADD | | Initiated |&& retry count >= | None | Failed | | | HELLO_PACKET_RETRY | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |ADD Initiated | Receive Hello | Send Ack | ADD | | | | fail | Initiated | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |ADD Initiated | Receive Ack | None |ADD succeeded| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |ADD Initiated | Receive Ack Fail | None | ADD Failed | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ADD Succeeded | None |Inform Higher | Connected | | | | layer-added | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ADD Failed | None |Inform Higher | Connected | | | |layer-not added| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 6.3 5.4 Flow Deletion During an MRTP session, some flows may become unavailable. For example, an intermediate node may leave the network or run out of battery power. In this case, either the sender or the receiver can delete the flow from the MRTP session by issuing a Delete Flow packet carrying the ID of the broken flow. The state transition diagram for Flow Deletion is the same as that of the flow addition defined in section 5.3. Narayanan, et al. Expires - January [Page 22] Internet-draft MRTP:A Multi-Flow Real-time Transport Protocol July 2004 5.5 Data Transfer Issues When the MRTP session is established, packets carrying the original multimedia stream data are transmitted on the multiple flows associated with the session. Each packet carries a sequence number that is local to its flow and a timestamp that is used by the receiver to synchronize the flows. Note that the core implementation of MRTP does not guarantee the reliable delivery of MRTP data packets. However, MRTP is flexible in supporting various error control schemes. For example, redundancy can be introduced at the sender when assigning the packets to the flows. Both the open-loop error control schemes (e.g., Forward Error Correction (FEC) and MDC [15]) and closed-loop error control schemes ( e.g., Automatic Repeat Request (ARQ) [16]) can be implemented above MRTP for better error resilience. 5.6 QoS Reports During the MRTP session, the receiver keeps monitoring the QoS performance of all the flows, such as the accumulated packet loss, the highest sequence number received, and the jitter. These statistics are put in a compound report packet that is sent to the sender. The report packets can be sent on a single flow, e.g., the best flow in terms of bandwidth, RTT, or loss probability, or some (or all) of the flows for better reliability. The frequency at which the QoS reports are sent is set by the application. A participant in the session keeps a record of the MRTP timestamp of the last received report from each report sender. When it receives multiple reports from the same MRTP sender, it checks the MRTP timestamp in the reports and discards those duplicated or stale QoS reports. 6. Traffic Partitioning To transport real-time data using multiple MRTP flows, the original multimedia stream needs to be divided into several substreams. These substreams are then assigned to corresponding MRTP flows. Substream replication among several MRTP flows as well as substreams aggregation over a single MRTP flow are both permitted and increase the flexibility of traffic partitioning. In addition to generating multiple substreams, traffic partitioning also changes the correlation structure of the data stream. The majority of real-time media traffic sources can be characterized by data rate burstiness, which could be present over multiple time and space aggregation scales. This manifests itself in a so-called Long Range Dependence (LRD) [17]. However, it is the short-term correlation structure of the input traffic within a critical time scale (CTS) of the queuing system that affects the queuing performance most [18][11]. The default MRTP traffic partitioning process, which is included within Narayanan, et al. Expires - January [Page 23] Internet-draft MRTP:A Multi-Flow Real-time Transport Protocol July 2004 MRTP traffic Allocator engine and introduced below lowers the auto- correlation between samples of the multimedia stream within the critical time scales of the underlying networking queues. There are two flavors of the Default MRTP data partitioning: a) equal-size block round robin thinning b) varying size block round robin thinning. In equal size block round robin thinning, the original data stream is divided by traffic Allocator in equally sized (B) blocks of data. Each subsequent block of real-time data is then assigned to the next in line substream, till the overall number of substreams used in MRTP session is reached. Then the process is restarted with the assignment of the next block to the first substream. In varying-size block round robin thinning, each unit of data (i.e., block) submitted by application to MRTP traffic Allocator engine can have different size (e.g., majority of frames in compressed video data have varying size). Once again, each subsequent block of real-time data is assigned to the next in line substream, till the overall number of substreams in MRTP session is reached. Then the process is restarted with the assignment of the next block to the first substream used in MRTP session. This simple traffic partitioning may not be optimal for some applications and can be overridden by applications with specific requirements. Traffic can be assigned to multiple flows with a granularity of packet, frame, group of pictures, or substream. Traffic partitioning not only divides the realtime data into multiple flows, but also provides a means for traffic shaping to achieve load balancing and better queueing performance. Thus application has the flexibility to introduce its own traffic partitioning schema. For example, striping [10] can be utilized by the application. All that the application needs to do is to indicate the substreamÆs index with each data unit obtained as a result of the application-specific traffic partitioning and passed to MRTP for transmission. 7. Usage scenarios 7.1 Unicast Video Streaming This is a point-to-point scenario, where a wireless sensor network is deployed to monitor, e.g., wild life, in a remote region. Some sensors carry a video camera, and others are simple relays that relay the captured video to the base. Source routing, or some other simple routing protocols can be used. A camera sensor initiates an MRTP session to the base. The captured video is transmitted using multiple flows going through different relays. In this way, a relative high rate video can be scattered to multiple paths each is bandwidth-limited. Redundancy can also be Narayanan, et al. Expires - January [Page 24] Internet-draft MRTP:A Multi-Flow Real-time Transport Protocol July 2004 added by transmitting a more important substream using multiple flows. Some sensors may be damaged or may run out of power. In this case, the underlying multipath routing protocol informs MRTP about the path changes. Either the sender or the receiver can delete a failed flow, or add a new flow to the session. The server at the base maintains a resequencing buffer for each flow, as well as enforcing a deadline for each packet expected to arrive. 7.2 Parallel Video Downloading This is a many-to-one scenario. Consider an ad hoc network, where each node maintains a cache for recently downloaded files. When a node A wants to download a movie, it would be more efficient to search the caches of other nearby nodes first than going directly to the Internet. If the movie is found in the caches of nodes B, C, and D, A can initiate an MRTP session to these nodes, downloading a piece of the movie simultaneously %(or sequentially, depending on the coding scheme used) from each of them. A pair of pointers is used for each flow indicating the segment of the video assigned to that flow. There are three flows, each with a unique flow ID, in this MRTP session. However, the flows have the same session ID since they belong to the same MRTP session. Resequencing buffers are used in A to reorder the packets, using the sequence numbers and the timestamps in their headers. A similar application of video streaming in Content Delivery Networks (CDN) using multiple servers is presented in [7]. During the transmission, Node D moves out of the network. Node A would delete the flow from D and adjust the file pointers in the other two flows. Now the part of the video initially chosen from D will be downloaded from B and C instead, by sending Add Flow packets to B and C with updated pointers. On the other hand, node A may broadcast probes periodically to find new neighbors with the movie and replace the stale flows in the session. Note that MRTP provides the flexibility for applications to implement these schemes. Combined with multistream video coding schemes, e.g., layered coding with unequal protection of the base layer packets [5] or multiple description coding [15], error resilience can be greatly improved. The video encoder and the traffic allocator adapt to transmission errors and topology changes using the information carried in the QoS reports. Narayanan, et al. Expires - January [Page 25] Internet-draft MRTP:A Multi-Flow Real-time Transport Protocol July 2004 7.3 Realtime Multicasting This is a multicast application similar to a video teleconferencing using RTP. Unlike RTP, MRTP uses multiple multicast trees. In [19], algorithms are given for computing two maximally disjoint multicast trees, where one is used for multicasting and the other is maintained as backup. This algorithm can be adapted to support multiple multicast trees in an MRTP session. For the example, if there are two multicast trees used, where each multicast tree is a flow and both flows belong to the same MRTP session. Since there may be a large number of participants in the session, QoS feedback should be suppressed, as in RTP, to avoid feedback explosion. The RTCP transmission interval computing algorithm [20] can be used to dynamical compute the interval between two back-to-back QoS reports according to the current number of participants and the available bandwidth. Since a flow may have more than one receiver, the sender ID field in a RR packet is used to identify its sender. The QoS metrics for a flow are computed over all the receivers of this flow. 8. Comparison to existing protocol specifications One natural question arises is that can any of the current existing protocols provides the same support, i.e., do we really need such a new protocol? There are two existing protocols that are closely related to our proposal. One is the Realtime Transport Protocol (RTP) [20]. RTP is a multicast-oriented protocol for Internet realtime applications. RTP itself does not support the use of multiple flows. An application could implement multipath realtime transport using RTP, but it would have to perform all the overhead processing of managing multiple flows, partitioning traffic, etc. It would be nice to abstract such common functions and relieve applications of such burdon. Usually a RTP session uses a multicast tree and a whole audio or video stream is sent on each edge of the tree. Compared with RTP, MRTP provides more flexible data partitioning and uses multiple paths for better queueing performance and better error resilience. The use of multiple flows makes MRTP more suitable for ad hoc networks, where routes are ephemeral. When multiple disjoint paths are used for a realtime session, the probability that all the paths fail simultaneously is relatively low, making better error control possible by exploiting path diversity [5]. In addition, since a wireless link's bandwidth usually fluctuates with signal strength, using multiple flows makes the realtime traffic more evenly distributed, resulting in lower queueing delay, smaller jitter, and less buffer overflow at an intermediate node. Furthermore, RTP focuses on multicast applications, where feedback is suppressed to avoid feedback explosion [20]. For example, RTP Receiver Reports (RR) Narayanan, et al. Expires - January [Page 26] Internet-draft MRTP:A Multi-Flow Real-time Transport Protocol July 2004 or Sender Reports (SR) are sent at least 5 seconds apart. Considering the typical lifetime of an ad hoc route, this is too coarse for the sender to react to path failures. With MRTP, since only a few routes are in use, it is possible to provide much timely feedback, enabling the source encoder and the traffic allocator to quickly adapt to the path changes. For example, with MRTP, it is possible to perform mode selection for each video frame or macroblock, to retransmit a lost packet, or to disperse packets to other better paths. In fact, MRTP is a natural extension of RTP exploiting path diversity in ad hoc networks. The other closely related protocol is the Stream Control Transport Protocol (SCTP) [21]. SCTP is a message-based transport layer protocol initially designed for reliable signaling in the Internet ( e.g., out-of-band control messages for Voice over IP (VoIP) call setup or teardown). One attractive feature of SCTP is that it supports multi-homing and multi-streaming, where multiple network interfaces or multiple streams can be used for a single SCTP session. With SCTP, generally one primary path is used and other paths are used as backups or retransmission channels. But there are several recent papers proposing to adapt SCTP to use multiple paths simultaneously for data transport [22][23]. SCTP cannot be applied directly for multimedia data because there is no timestamping and QoS feedback services. With MRTP, the design is focused on supporting realtime applications, with timestamping and QoS feedback as its essential modes of operation. Moreover, since SCTP is a transport layer protocol and is implemented in the system kernel, it is hard, if not impossible, to make changes to it. A new multimedia application, with a new coding format, a new transport requirement, etc., could only with difficulty be supported by SCTP. MRTP is largely an application layer protocol and is implemented in the user space as an integral part of an application. New multimedia services can be easily supported by defining new profiles and new extension headers. Indeed, MRTP is complementary to SCTP by supporting real- time multimedia services using multiple paths. MRTP can establish multiple paths by using SCTP sockets, taking advantage of the multi- homing and the multi-streaming features of SCTP. In this case, one or multiple MRTP flows can be mapped to a SCTP stream. MRTP is also flexible in working with other multipath routing protocols, e.g., the Multipath Dynamic Source Routing protocol in [5], when their implementations are available. 9. Protocol constants 9.1 Payload types DATA Payload : 1 Sender Report : 2 Receiver Report : 3 Narayanan, et al. Expires - January [Page 27] Internet-draft MRTP:A Multi-Flow Real-time Transport Protocol July 2004 Hello Packet : 4 Ack Hello : 5 Bye Packet : 6 Ack Bye : 7 9.2 Status field FAILED : 0 SUCCESS : 1 9.3 Timers HELLO_PACKET_TIMER : 1 second ACK_PACKET_TIMER : 1 second BYE_PACKET_TIMER : 1 second 9.4 Retries HELLO_PACKET_RETRIES : 3 ACK_PACKET_RETRIES : 3 BYE_PACKET_RETRIES : 3 10. Open issues The following open questions need to be addressed to complete the design of the proposed protocol: . Should we define a new session management protocol, as done in this draft? Or should we define extensions to SDP and use an existing signaling protocol like SIP? . The frequency of SR and RR reporting? . Assume security to be provided by lower layers? . More informative status fields? 11. Security Considerations MRTP has the same security requirements as RTP [20]. MRTP depends on underlying protocol to provide the required authentication, integrity and confidentiality. The complete design of security mechanisms using the extension headers as part of the MRTP protocol itself is TBD. References 1. Y. Wang and Q.-F. Zhu, ``Error control and concealment for video communication: a review,'' in Proc. IEEE, vol.86, issue 5, pp.974-997, May 1998. 2. N. Gogate, D. Chung, S.~S. Panwar, Y. Wang,``Supporting image/video applications in a multihop radio environment using route diversity and multiple description coding,'' IEEE Trans. Circuit Syst. Video Technol., vol.12, no.9, pp.777-792, Sept. 2002. Narayanan, et al. Expires - January [Page 28] Internet-draft MRTP:A Multi-Flow Real-time Transport Protocol July 2004 3. S. Mao, S. Lin, D. Bushmitch, S. Narayanan, S. S. Panwar, Y. Wang, and R. Izmailov, ``Real time transport with path diversity,'' the second NY Metro Area Networking Workshop, New York, September 2002. 4. S. Mao, S. Lin, S. S. Panwar, and Y. Wang, ``Video transport over ad hoc networks: Multistream coding with multipath transport,''IEEE JSAC Special Issue on Recent Advances in Wireless Multimedia, vol.21, no.10, pp.1721-1737, December 2003. 5. Y.~J. Liang, E.~G. Steinbach, and B. Girod, ``Multi-stream voice over IP using packet path diversity,'' in Proc. IEEE Multimedia Siganl Processing Workshop, pp.555-560, Sept. 2001. 6. J.~G. Apostolopoulos, T. Wong, W. Tan, and S. Wee, ``On Multiple Description Streaming in Content Delivery Networks,'' in Proc. IEEE INFOCOM, pp.1736-1745, June 2002. 7. E. M. Royer and C.-K. Toh, ``A review of current routing protocols for ad hoc mobile wireless networks,'' IEEE Personal Communications, vol.6 issue.2, pp.46-55, April 1999. 8. P. J. Shenoy and H. M. Vin, ``Efficient striping techniques for multimedia file servers,'' Performance Evaluation, vol.38, pp.175-199, 1999. 9. D. Bushmitch, R. Izmailov, S. Panwar, A. Pal, ``Thinning, Striping and Shuffling: Traffic Shaping and Transport Techniques for Variable Bit Rate Video,'' in Proc. IEEE GLOBECOM'02, Taipei, 2002. 10. D. Bushmitch, ``Thinning, striping and shuffling: Traffic shaping and transport techniques for VBR video,'' PhD Dissertation, Electrical and Computer Engineering Department, Polytechnic University, 2003. 11. N. Gogate and S. S. Panwar, ``On a resequencing model for high speed networks,'' in Proc. IEEE INFOCOM'94, vol.1, pp.40-47, April 1994. 12. Y. Nebat and M. Sidi, ``Resequencing considerations in parallel downloads,'' in Proc. IEEE INFOCOM'03, April 2003. 13. C. Huitema, IPv6: The new Internet Protocol. Prentice Hall, 1998. 14. Y. Wang and S. Lin, ``Error resilient video coding using multiple description motion compensation,'' IEEE Trans. Circuits Syst. Video Technol., vol.12, no.6, pp.438-452,September 2002. 15. S. Mao, S. Lin, S. S. Panwar, and Y. Wang, ``Reliable transmission of video over ad hoc networks using automatic repeat request and multipath transport,'' in Proc. IEEE VTC Fall 2001, vol.2, pp.615-619, October 2001. 16. W. E. Leland, M. S. Taqqu, W. Willinger, and D. V. Wilson, ``On the self-similar nature of Ethernet traffic,'' IEEE/ACM Trans. Networking, vol.2, pp.1-15, February 1994. Narayanan, et al. Expires - January [Page 29] Internet-draft MRTP:A Multi-Flow Real-time Transport Protocol July 2004 17. B. Ryu and A. Elwalid, ``The importance of LRD of VBR video traffic in ATM traffic engineering: Myths and realities,'' in Proc. ACM SIGCOMM, 1996. 18. S. Sajama and Z. J. Haas, ``Independent-tree ad hoc multicast routing (ITAMAR),'' in Proc. IEEE Fall VTC'01, October 2001. 19. H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson, ``RTP: A transport protocol for realtime applications,'' IETF Request For Comments 3550. [Online]. Available at: http://www.ietf.org. 20. R.~R. Stewart and Q. Xie, Stream Control Transmission Protocol: A Reference Guide. Reading, MA: Addison-Wesley, 2001. 21. D.~S. Phatak and T. Goff, ``A novel mechanism for data streaming across multiple IP links for improving throughput and reliabilit in mobile environments,'' in Proc. IEEE INFOCOM, pp.773-782, June 2002. 22. H.-Y. Hsieh and R. Sivakumar, ``A transport layer approach for achieving aggregate bandwidths on multi-homed mobile hosts,'' in Proc. ACM Inter. Conf. Mob. Comp. Networking, pp.83-95, September 2002. Acknowledgments < TBD> Author's Addresses Sathya Narayanan Panasonic Digital Networking Lab, 2 Research Way, Princeton, NJ 08540 Phone: (609) 734 7599 Email: sathya@Research.Panasonic.COM Dennis Bushmitch Panasonic Digital Networking Lab, 2 Research Way, Princeton, NJ 08540 Phone: (609) 734 Email: db@Research.Panasonic.COM Shiwen Mao Virginia Polytechnic Institute and State University 340 Whittemore Hall (0111), Blacksburg, VA 24061 Email: smao@vt.edu Shivendra Panwar Polytechnic University Brooklyn, NY Narayanan, et al. Expires - January [Page 30] Internet-draft MRTP:A Multi-Flow Real-time Transport Protocol July 2004 Phone: (618) 260 3740 Email: panwar@catt.poly.edu Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Narayanan, et al. Expires - January [Page 31] Internet-draft MRTP:A Multi-Flow Real-time Transport Protocol July 2004 Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Narayanan, et al. Expires - January [Page 32]