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

Versions: 00

   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, <Source IP, Source Port,
     Destination IP, Destination port>, 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]


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