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]