draft-ietf-avt-rapid-acquisition-for-rtp-00.txt   draft-ietf-avt-rapid-acquisition-for-rtp-01.txt 
AVT B. VerSteeg AVT B. VerSteeg
Internet-Draft A. Begen Internet-Draft A. Begen
Intended status: Standards Track Cisco Systems Intended status: Standards Track Cisco Systems
Expires: November 13, 2009 T. VanCaenegem Expires: December 18, 2009 T. VanCaenegem
Alcatel-Lucent Alcatel-Lucent
Z. Vax Z. Vax
Microsoft Corporation Microsoft Corporation
May 12, 2009 June 16, 2009
Unicast-Based Rapid Acquisition of Multicast RTP Sessions Unicast-Based Rapid Acquisition of Multicast RTP Sessions
draft-ietf-avt-rapid-acquisition-for-rtp-00 draft-ietf-avt-rapid-acquisition-for-rtp-01
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. This document may contain material provisions of BCP 78 and BCP 79. This document may contain material
from IETF Documents or IETF Contributions published or made publicly from IETF Documents or IETF Contributions published or made publicly
available before November 10, 2008. The person(s) controlling the available before November 10, 2008. The person(s) controlling the
copyright in some of this material may not have granted the IETF copyright in some of this material may not have granted the IETF
Trust the right to allow modifications of such material outside the Trust the right to allow modifications of such material outside the
IETF Standards Process. Without obtaining an adequate license from IETF Standards Process. Without obtaining an adequate license from
skipping to change at page 1, line 46 skipping to change at page 1, line 46
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on November 13, 2009. This Internet-Draft will expire on December 18, 2009.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info). publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. and restrictions with respect to this document.
skipping to change at page 3, line 19 skipping to change at page 3, line 19
3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 7 3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 7
4. Elements of Delay in Multicast Applications . . . . . . . . . 7 4. Elements of Delay in Multicast Applications . . . . . . . . . 7
5. Protocol Design Considerations and Their Effect on 5. Protocol Design Considerations and Their Effect on
Resource Management for Rapid Acquisition . . . . . . . . . . 9 Resource Management for Rapid Acquisition . . . . . . . . . . 9
6. Rapid Acquisition of Multicast RTP Sessions . . . . . . . . . 11 6. Rapid Acquisition of Multicast RTP Sessions . . . . . . . . . 11
6.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 11 6.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 11
6.2. Message Flows . . . . . . . . . . . . . . . . . . . . . . 12 6.2. Message Flows . . . . . . . . . . . . . . . . . . . . . . 12
6.3. Shaping the Unicast Burst . . . . . . . . . . . . . . . . 20 6.3. Shaping the Unicast Burst . . . . . . . . . . . . . . . . 20
6.4. Failure Cases . . . . . . . . . . . . . . . . . . . . . . 20 6.4. Failure Cases . . . . . . . . . . . . . . . . . . . . . . 20
7. Encoding of the Signaling Protocol in RTCP . . . . . . . . . . 21 7. Encoding of the Signaling Protocol in RTCP . . . . . . . . . . 21
7.1. RAMS Request . . . . . . . . . . . . . . . . . . . . . . . 22 7.1. Extensions . . . . . . . . . . . . . . . . . . . . . . . . 21
7.2. RAMS Information . . . . . . . . . . . . . . . . . . . . . 23 7.1.1. Vendor-Neutral Extensions . . . . . . . . . . . . . . 22
7.3. RAMS Termination . . . . . . . . . . . . . . . . . . . . . 26 7.1.2. Private Extensions . . . . . . . . . . . . . . . . . . 22
7.4. Extensions . . . . . . . . . . . . . . . . . . . . . . . . 27 7.2. RAMS Request . . . . . . . . . . . . . . . . . . . . . . . 23
7.3. RAMS Information . . . . . . . . . . . . . . . . . . . . . 24
7.4. RAMS Termination . . . . . . . . . . . . . . . . . . . . . 27
8. SDP Definitions and Examples . . . . . . . . . . . . . . . . . 28 8. SDP Definitions and Examples . . . . . . . . . . . . . . . . . 28
8.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 28 8.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 28
8.2. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 28 8.2. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 29
9. NAT Considerations . . . . . . . . . . . . . . . . . . . . . . 31 9. Signaling Ports via Publish Ports (PubPorts) RTCP Message . . 31
10. Known Implementations . . . . . . . . . . . . . . . . . . . . 31 10. NAT Considerations . . . . . . . . . . . . . . . . . . . . . . 32
10.1. Open Source RTP Receiver Implementation by Cisco . . . . . 31 11. Known Implementations . . . . . . . . . . . . . . . . . . . . 33
10.2. IPTV Commercial Implementation by Microsoft . . . . . . . 31 11.1. Open Source RTP Receiver Implementation by Cisco . . . . . 33
11. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 32 11.2. IPTV Commercial Implementation by Microsoft . . . . . . . 34
12. Security Considerations . . . . . . . . . . . . . . . . . . . 32 12. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 34
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32 13. Security Considerations . . . . . . . . . . . . . . . . . . . 34
13.1. Registration of SDP Attribute Values . . . . . . . . . . . 32 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34
13.2. Registration of FMT Values . . . . . . . . . . . . . . . . 33 14.1. Registration of SDP Attribute Values . . . . . . . . . . . 34
14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 33 14.2. Registration of FMT Values . . . . . . . . . . . . . . . . 35
15. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 33 14.3. SFMT Values for RAMS Messages Registry . . . . . . . . . . 35
15.1. draft-versteeg-avt-rapid-synchronization-for-rtp-03 . . . 34 14.4. RAMS TLV Space Registry . . . . . . . . . . . . . . . . . 36
15.2. draft-versteeg-avt-rapid-synchronization-for-rtp-02 . . . 34 15. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 36
15.3. draft-versteeg-avt-rapid-synchronization-for-rtp-01 . . . 34 16. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 37
16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 35 16.1. draft-ietf-avt-rapid-acquisition-for-rtp-01 . . . . . . . 37
16.1. Normative References . . . . . . . . . . . . . . . . . . . 35 16.2. draft-ietf-avt-rapid-acquisition-for-rtp-00 . . . . . . . 37
16.2. Informative References . . . . . . . . . . . . . . . . . . 36 16.3. draft-versteeg-avt-rapid-synchronization-for-rtp-03 . . . 37
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 37 16.4. draft-versteeg-avt-rapid-synchronization-for-rtp-02 . . . 37
16.5. draft-versteeg-avt-rapid-synchronization-for-rtp-01 . . . 38
17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 38
17.1. Normative References . . . . . . . . . . . . . . . . . . . 38
17.2. Informative References . . . . . . . . . . . . . . . . . . 40
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 41
1. Introduction 1. Introduction
Most multicast flows carry a stream of inter-related data. Certain Most multicast flows carry a stream of inter-related data. Certain
information must first be acquired by the receivers to start information must first be acquired by the receivers to start
processing any data sent in the multicast session. This document processing any data sent in the multicast session. This document
refers to this information as Reference Information. The Reference refers to this information as Reference Information. The Reference
Information is conventionally sent periodically in the multicast Information is conventionally sent periodically in the multicast
session and usually consists of items such as a description of the session and usually consists of items such as a description of the
schema for the rest of the data, references to which data to process schema for the rest of the data, references to which data to process,
for the receivers, encryption information including keys, as well as encryption information including keys, as well as any other
any other information required to process the data in the primary information required to process the data in the primary multicast
multicast stream. stream.
Real-time multicast applications require the receivers to buffer Real-time multicast applications require the receivers to buffer
data. The receiver may have to buffer data to smooth out the network data. The receiver may have to buffer data to smooth out the network
jitter, to allow loss-repair methods such as Forward Error Correction jitter, to allow loss-repair methods such as Forward Error Correction
and retransmission to recover the missing packets, and to satisfy the and retransmission to recover the missing packets, and to satisfy the
data processing requirements of the application layer. data processing requirements of the application layer.
When a receiver joins a multicast session, it has no control over When a receiver joins a multicast session, it has no control over
what point in the flow is currently being transmitted. Sometimes the what point in the flow is currently being transmitted. Sometimes the
receiver may join the session right before the Reference Information receiver may join the session right before the Reference Information
skipping to change at page 6, line 12 skipping to change at page 6, line 12
in the RTP/RTCP protocol family. This improves the versatility of in the RTP/RTCP protocol family. This improves the versatility of
the existing implementations, and promotes faster deployment and the existing implementations, and promotes faster deployment and
better interoperability. To this effect, we use the unicast better interoperability. To this effect, we use the unicast
retransmission support of RTP [RFC4588] and the capabilities of RTCP retransmission support of RTP [RFC4588] and the capabilities of RTCP
to handle the signaling needed to accomplish the acquisition. The to handle the signaling needed to accomplish the acquisition. The
packet(s) carrying the Reference Information are sent by the feedback packet(s) carrying the Reference Information are sent by the feedback
target in the auxiliary unicast RTP session for rapid acquisition. target in the auxiliary unicast RTP session for rapid acquisition.
These are constructed as retransmission packets that would have been These are constructed as retransmission packets that would have been
sent in a unicast RTP session to recover the missing packets at an sent in a unicast RTP session to recover the missing packets at an
RTP receiver that has never received any packet. In fact, a single RTP receiver that has never received any packet. In fact, a single
RTP session MAY be used for both rapid acquisition and RTP session SHOULD be used for both rapid acquisition and
retransmission-based loss repair. Furthermore, the session can be retransmission-based loss repair. This session can be used to
used to simultaneously provide the unicast burst for the rapid simultaneously provide the unicast burst for the rapid acquisition
acquisition and the repair packets requested by the RTP receivers and the repair packets requested by the RTP receivers when they
when they detect lost burst packets or lost RTP packets in the detect lost burst packets or lost RTP packets in the primary
primary multicast stream. The conventional RTCP feedback message multicast stream. The conventional RTCP feedback (NACK) message that
that requests the retransmission of the missing packets [RFC4585] requests the retransmission of the missing packets [RFC4585]
indicates their sequence numbers. However, upon joining a new indicates their sequence numbers. However, upon joining a new
session the RTP receiver has never received a packet, and thus, does session the RTP receiver has never received a packet, and thus, does
not know the sequence numbers. Instead, the RTP receiver sends a not know the sequence numbers. Instead, the RTP receiver sends a
newly defined RTCP feedback message to request the Reference newly defined RTCP feedback message to request the Reference
Information needed to rapidly get on the track with the primary Information needed to rapidly get on the track with the primary
multicast session. It is also worth noting that in order to issue multicast session. It is also worth noting that in order to issue
the initial RTCP message to the feedback target, the SSRC of the the initial RTCP message to the feedback target, the SSRC of the
session to be joined must be known prior to any packet reception, and session to be joined must be known prior to any packet reception, and
hence, needs to be signaled out-of-band (or otherwise communicated to hence, needs to be signaled out-of-band (or otherwise communicated to
the RTP receiver in advance of the initiation of the rapid the RTP receiver in advance of the initiation of the rapid
acquisition operation). In a Session Description Protocol (SDP) acquisition operation). In a Session Description Protocol (SDP)
description, the SSRC MUST be signaled through the 'ssrc' attribute description, the SSRC MUST be signaled through the 'ssrc' attribute
[I-D.ietf-avt-rtcpssm]. [I-D.ietf-avt-rtcpssm].
In the rest of this specification, we have the following outline: In In the rest of this specification, we have the following outline: In
Section 4, we describe the delay components in generic multicast Section 4, we describe the delay components in generic multicast
applications. Section 5 presents an overview of the protocol design applications. Section 5 presents an overview of the protocol design
considerations for rapid acquisition. We provide the protocol considerations for rapid acquisition. We provide the protocol
details of the rapid acquisition method in Section 6 and Section 7. details of the rapid acquisition method in Section 6 and Section 7.
Section 8 and Section 9 discuss the SDP signaling issues with Section 8, Section 9 and Section 10 discuss the SDP signaling issues
examples and NAT-related issues, respectively. with examples, an RTCP port signaling method and NAT-related issues,
respectively.
Note that Section 3 provides a list of the definitions frequently Note that Section 3 provides a list of the definitions frequently
used in this document. used in this document.
2. Requirements Notation 2. Requirements Notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
skipping to change at page 7, line 19 skipping to change at page 7, line 19
Primary Multicast Session: The multicast RTP session to which RTP Primary Multicast Session: The multicast RTP session to which RTP
receivers can join at a random point in time. receivers can join at a random point in time.
Primary Multicast Stream: The RTP stream carried in the primary Primary Multicast Stream: The RTP stream carried in the primary
multicast session. multicast session.
Source Filtering Group Management Protocol (SFGMP): Following the Source Filtering Group Management Protocol (SFGMP): Following the
definition in [RFC4604], SFGMP refers to the Internet Group definition in [RFC4604], SFGMP refers to the Internet Group
Management Protocol (IGMP) version 3 [RFC3376] and the Multicast Management Protocol (IGMP) version 3 [RFC3376] and the Multicast
Listener Discovery Protocol (MLD) version 2 [RFC3810] in the IPv4 and Listener Discovery Protocol (MLD) version 2 [RFC3810] in the IPv4 and
IPv6 networks, respectively. IPv6 networks, respectively. However, the rapid acquisition method
introduced in this document does not depend on a specific version of
either of these group management protocols. In the remainder of this
document, SFGMP will refer to any group management protocol that has
Join and Leave functionalities.
Feedback Target: (Unicast RTCP) Feedback target as defined in Feedback Target: (Unicast RTCP) Feedback target as defined in
[I-D.ietf-avt-rtcpssm]. [I-D.ietf-avt-rtcpssm].
Retransmission Packet: An RTP packet that is formatted as defined in Retransmission Packet: An RTP packet that is formatted as defined in
[RFC4588]. [RFC4588].
Reference Information: The set of certain media content and metadata Reference Information: The set of certain media content and metadata
information that is sufficient for an RTP receiver to start usefully information that is sufficient for an RTP receiver to start usefully
consuming a media stream. The meaning, format and size of this consuming a media stream. The meaning, format and size of this
information are specific to the application and are out of scope of information are specific to the application and are out of scope of
this document. this document.
Burst (Stream): A unicast stream of RTP retransmission packets that (Unicast) Burst (Stream): A unicast stream of RTP retransmission
enable an RTP receiver to rapidly acquire the Reference Information. packets that enable an RTP receiver to rapidly acquire the Reference
The burst stream is typically transmitted at an accelerated rate. Information. The burst stream is typically transmitted at an
accelerated rate.
Retransmission Server (RS): The RTP/RTCP endpoint that can generate Retransmission Server (RS): The RTP/RTCP endpoint that can generate
the retransmission packets and the burst stream. the retransmission packets and the burst stream.
4. Elements of Delay in Multicast Applications 4. Elements of Delay in Multicast Applications
In an any-source (ASM) or a single-source (SSM) multicast delivery In an any-source (ASM) or a single-source (SSM) multicast delivery
system, there are three major elements that contribute to the overall system, there are three major elements that contribute to the overall
acquisition delay when an RTP receiver switches from one multicast acquisition delay when an RTP receiver switches from one multicast
session to another one. These are: session to another one. These are:
skipping to change at page 8, line 40 skipping to change at page 8, line 45
proximity of the actual time the receiver joined the session to the proximity of the actual time the receiver joined the session to the
next time the Reference Information will be sent to the receivers in next time the Reference Information will be sent to the receivers in
the session, whether the Reference Information is sent contiguously the session, whether the Reference Information is sent contiguously
or not, and the size of the Reference Information. For some or not, and the size of the Reference Information. For some
multicast flows, there is a little or no interdependency in the data, multicast flows, there is a little or no interdependency in the data,
in which case the Reference Information latency will be nil or in which case the Reference Information latency will be nil or
negligible. For other multicast flows, there is a high degree of negligible. For other multicast flows, there is a high degree of
interdependency. One example of interest is the multicast flows that interdependency. One example of interest is the multicast flows that
carry compressed audio/video. For these flows, the Reference carry compressed audio/video. For these flows, the Reference
Information latency may become quite large and be a major contributor Information latency may become quite large and be a major contributor
to the overall delay. to the overall delay. Refer to [I-D.begen-avt-rtp-mpeg2ts-preamble]
for details.
The buffering component of the overall acquisition delay is driven by The buffering component of the overall acquisition delay is driven by
the way the application layer processes the payload. In many the way the application layer processes the payload. In many
multicast applications, an unreliable transport protocol such as UDP multicast applications, an unreliable transport protocol such as UDP
[RFC0768] is often used to transmit the data packets, and the [RFC0768] is often used to transmit the data packets, and the
reliability, if needed, is usually addressed through other means such reliability, if needed, is usually addressed through other means such
as Forward Error Correction and retransmission as Forward Error Correction and retransmission
[I-D.ietf-rmt-pi-norm-revised]. These loss-repair methods require [I-D.ietf-rmt-pi-norm-revised]. These loss-repair methods require
buffering at the receiver side to function properly. In many buffering at the receiver side to function properly. In many
applications, it is also often necessary to de-jitter the incoming applications, it is also often necessary to de-jitter the incoming
skipping to change at page 10, line 15 skipping to change at page 10, line 20
scope for this document. The receiver should be able to signal the scope for this document. The receiver should be able to signal the
server with the bandwidth that it believes it can handle. The server server with the bandwidth that it believes it can handle. The server
also needs to be able to rate limit the flow in order to stay within also needs to be able to rate limit the flow in order to stay within
the performance envelope that it knows about. Both the server and the performance envelope that it knows about. Both the server and
receiver need to be able to inform the other of changes in the receiver need to be able to inform the other of changes in the
requested and delivered rates. However, the protocol must be robust requested and delivered rates. However, the protocol must be robust
in the presence of packet loss, so this signaling must include the in the presence of packet loss, so this signaling must include the
appropriate default behaviors. appropriate default behaviors.
A second challenge is that for some uses (e.g., high-bitrate video) A second challenge is that for some uses (e.g., high-bitrate video)
the unicast burst bandwidth is high while the flow duration of the the unicast burst bitrate is high while the flow duration of the
unicast burst is short. This is because the purpose of the unicast unicast burst is short. This is because the purpose of the unicast
burst is to allow the RTP receiver to join the multicast quickly and burst is to allow the RTP receiver to join the multicast quickly and
thereby limit the overall resources consumed by the burst. Such thereby limit the overall resources consumed by the burst. Such
high-bitrate, short-duration flows are not amenable to conventional high-bitrate, short-duration flows are not amenable to conventional
admission control techniques. For example, per-flow signaled admission control techniques. For example, end-to-end per-flow
admission control techniques such as RSVP have too much latency and signaled admission control techniques such as RSVP have too much
control channel overhead to be a good fit for rapid acquisition. latency and control channel overhead to be a good fit for rapid
Similarly, using a TCP (or TCP-like) approach with a 3-way handshake acquisition. Similarly, using a TCP (or TCP-like) approach with a
and slow-start to avoid inducing congestion would defeat the purpose 3-way handshake and slow-start to avoid inducing congestion would
of attempting rapid acquisition in the first place by introducing defeat the purpose of attempting rapid acquisition in the first place
many RTTs of delay. by introducing many RTTs of delay.
These observations lead to certain unavoidable requirements and goals These observations lead to certain unavoidable requirements and goals
for a rapid acquisition protocol. These are: for a rapid acquisition protocol. These are:
o The protocol must be designed to allow a deterministic upper bound o The protocol must be designed to allow a deterministic upper bound
on the extra bandwidth used (compared to just joining the on the extra bandwidth used (compared to just joining the
multicast session). A reasonable size bound is e*B, where B is multicast session). A reasonable size bound is e*B, where B is
the "nominal" bandwidth of the primary multicast stream, and e is the "nominal" bandwidth of the primary multicast stream, and e is
an "excess-bandwidth" coefficient The total duration of the an "excess-bandwidth" coefficient The total duration of the
unicast burst must have a reasonable bound; long unicast bursts unicast burst must have a reasonable bound; long unicast bursts
skipping to change at page 11, line 7 skipping to change at page 11, line 14
o The scheme must minimize (or better eliminate) any gap between the o The scheme must minimize (or better eliminate) any gap between the
unicast burst and the primary multicast stream, which has to be unicast burst and the primary multicast stream, which has to be
repaired later, or in the absence of repair, will result in loss repaired later, or in the absence of repair, will result in loss
being experienced by the application. being experienced by the application.
In addition to the above, there are some other protocol design issues In addition to the above, there are some other protocol design issues
to be considered. First, there is at least one RTT of "slop" in the to be considered. First, there is at least one RTT of "slop" in the
control loop. In starting a rapid acquisition burst, this manifests control loop. In starting a rapid acquisition burst, this manifests
as the time between the client requesting the unicast burst and the as the time between the client requesting the unicast burst and the
burst description (and possibly the first unicast burst packets) burst description and/or the first unicast burst packets arriving at
arriving at the receiver. For managing and terminating the unicast the receiver. For managing and terminating the unicast burst, there
burst, there are two possible approaches for the control loop: The are two possible approaches for the control loop: The receiver can
receiver can adapt to the unicast burst as received, converge based adapt to the unicast burst as received, converge based on observation
on observation and explicitly terminate the unicast burst with a and explicitly terminate the unicast burst with a second control loop
second control loop exchange (which takes a minimum of one RTT, just exchange (which takes a minimum of one RTT, just as starting the
as starting the unicast burst does). Alternatively, the server unicast burst does). Alternatively, the server generating the
generating the unicast burst can pre-compute the burst parameters unicast burst can pre-compute the burst parameters based on the
based on the information in the initial request and tell the receiver information in the initial request and tell the receiver the burst
the burst duration. duration.
The protocol described in the next section allows either method of The protocol described in the next section allows either method of
controlling the rapid acquisition unicast burst. controlling the rapid acquisition unicast burst.
6. Rapid Acquisition of Multicast RTP Sessions 6. Rapid Acquisition of Multicast RTP Sessions
We start this section with an overview of the rapid acquisition of We start this section with an overview of the rapid acquisition of
multicast sessions (RAMS) method. multicast sessions (RAMS) method.
6.1. Overview 6.1. Overview
skipping to change at page 11, line 40 skipping to change at page 11, line 47
defines an architecture that introduces the concept of Distribution defines an architecture that introduces the concept of Distribution
Source, which - in an SSM context - distributes the RTP data and Source, which - in an SSM context - distributes the RTP data and
redistributes RTCP information to all RTP receivers. This RTCP redistributes RTCP information to all RTP receivers. This RTCP
information is retrieved from the Feedback Target, to which RTCP information is retrieved from the Feedback Target, to which RTCP
unicast feedback traffic is sent. The Feedback Target MAY be unicast feedback traffic is sent. The Feedback Target MAY be
implemented in one or more entities different from the Distribution implemented in one or more entities different from the Distribution
Source, and different RTP receivers MAY use different Feedback Source, and different RTP receivers MAY use different Feedback
Targets. Targets.
This document builds further on these concepts to reduce the This document builds further on these concepts to reduce the
acquisition time when an RTP receiver wants to join a multicast acquisition time when an RTP receiver joins a multicast session at a
session at a random point in time by introducing the concept of the random point in time by introducing the concept of the Burst Source
Burst Source and new RTCP feedback messages. The Burst Source has a and new RTCP feedback messages. The Burst Source has a cache where
cache where the most recent packets from the primary multicast the most recent packets from the primary multicast session are
session are continuously stored. When an RTP receiver wants to continuously stored. When an RTP receiver wants to receive the
receive the primary multicast stream, prior to joining the SSM primary multicast stream, prior to joining the SSM session, it may
session, it will first request a unicast burst from the Burst Source. first request a unicast burst from the Burst Source. In this burst,
In this burst, the packets are formatted as RTP retransmission the packets are formatted as RTP retransmission packets [RFC4588] and
packets [RFC4588] and carry the Reference Information. This carry the Reference Information. This information allows the RTP
information allows the RTP receiver to start usefully consuming the receiver to start usefully consuming the RTP packets sent in the
RTP packets sent in the primary multicast session. primary multicast session.
Using an accelerated rate (as compared to the rate of the primary Using an accelerated rate (as compared to the rate of the primary
multicast stream) for the unicast burst implies that at a certain multicast stream) for the unicast burst implies that at a certain
point in time, the payload transmitted in the unicast burst is going point in time, the payload transmitted in the unicast burst is going
to be the same as the payload multicast in the SSM session, i.e., the to be the same as the payload multicast in the SSM session, i.e., the
unicast burst will catch up with the primary multicast stream. At unicast burst will catch up with the primary multicast stream. At
this point, the RTP receiver no longer needs to receive the unicast this point, the RTP receiver no longer needs to receive the unicast
burst and can join the primary multicast session. This method is burst and can join the primary multicast session. This method is
referred to as the Rapid Acquisition of Multicast Sessions (RAMS). referred to as the Rapid Acquisition of Multicast Sessions (RAMS).
skipping to change at page 13, line 30 skipping to change at page 13, line 30
| | | |----------->| (RR) | | | | |----------->| (RR) |
+-----------+ +----------+ +----------+ +-----------+ +----------+ +----------+
'''> Unicast RTCP Messages '''> Unicast RTCP Messages
~~~> SFGMP Messages ~~~> SFGMP Messages
...> Unicast RTP Flow ...> Unicast RTP Flow
---> Multicast RTP Flow ---> Multicast RTP Flow
Figure 2: Flow diagram for unicast-based rapid acquisition Figure 2: Flow diagram for unicast-based rapid acquisition
A Retransmission Source can equally act as a Burst Source. The A Retransmission Source may equally act as a Burst Source. The
Retransmission Source can also incorporate the Feedback Target Retransmission Source may also incorporate the Feedback Target
([I-D.ietf-avt-rtcpssm] permits the feedback target to be a ([I-D.ietf-avt-rtcpssm] permits the feedback target to be a
retransmission server, since it is a logical function to which RRs retransmission server, since it is a logical function to which RRs
send their unicast feedback), and we will use the term Retransmission send their unicast feedback), and we will use the term Retransmission
Server (RS) in the remainder of the document to refer to a single Server (RS) in the remainder of the document to refer to a single
physical entity comprising these three entities. Note that the same physical entity comprising these three entities that share state.
method (with the identical message flows) would also apply in a Note that the same method (with the identical message flows) would
scenario where rapid acquisition is performed by a feedback target also apply in a scenario where rapid acquisition is performed by a
co-located with the media source. feedback target co-located with the media source.
As the unicast burst packets are formatted as RTP retransmission As the unicast burst packets are formatted as RTP retransmission
packets [RFC4585], the unicast burst and RTP retransmissions MAY be packets [RFC4585], the unicast burst and RTP retransmissions are sent
provided in one and the same RTP (retransmission) session. over the same RTP (retransmission) session.
The unicast burst is triggered by the RTCP feedback message defined
in this document, whereas an RTP retransmission is triggered by an
RTCP NACK message defined in [RFC4585]. Pending on RAMS practices,
there may be a gap between the end of the burst and the reception of
the primary multicast stream because of the imperfections in the
switch-over. If needed, RR can make use of the RTCP NACK message to
request a retransmission for the missing packets in the gap.
Editor's note: As stated above, FT, Burst Source and Retransmission The unicast burst is triggered by an RTCP feedback message defined in
Source are logical entities. For efficiency and simplicity, they MAY this document, whereas an RTP retransmission is triggered by an RTCP
be implemented by a single physical Retransmission Server (RS). In a NACK message defined in [RFC4585]. Based on its design, in an RAMS
number of places throughout this document we assume (and explicitly implementation, there may be a gap between the end of the burst and
state so) that all three are implemented by the same physical entity the reception of the primary multicast stream because of the
and therefore share the same IP address and the port number. The imperfections in the switch-over. If needed, RR may make use of the
authors look to the AVT community for recommendations on whether this RTCP NACK message to request a retransmission for the missing packets
is sufficient or the mechanism has to explicitly address other in the gap.
topologies where FT, Burst Source and Retransmission Source are not
co-located.
Figure 3 depicts an example of messaging flow for rapid acquisition. Figure 3 depicts an example of messaging flow for rapid acquisition.
The RTCP feedback messages are explained below. Note that the The RTCP feedback messages are explained below. Note that the
messages indicated in parentheses may or may not be present during messages indicated in parentheses may or may not be present during
rapid acquisition. rapid acquisition.
+-----------+ +----------------+ +----------+ +------------+ +-----------+ +----------------+ +----------+ +------------+
| Multicast | | Retransmission | | | | RTP | | Multicast | | Retransmission | | | | RTP |
| Source | | Server | | Router | | Receiver | | Source | | Server | | Router | | Receiver |
| | | (RS) | | | | (RR) | | | | (RS) | | | | (RR) |
skipping to change at page 16, line 41 skipping to change at page 16, line 41
obtained out-of-band. See Section 8 for details. obtained out-of-band. See Section 8 for details.
2. Response: RS receives the RAMS-R message and decides whether to 2. Response: RS receives the RAMS-R message and decides whether to
accept it or not. RS MUST send an (at least one) RAMS- accept it or not. RS MUST send an (at least one) RAMS-
Information (RAMS-I) message to RR. The first RAMS-I message MAY Information (RAMS-I) message to RR. The first RAMS-I message MAY
precede the unicast burst or it MAY be sent during the burst. precede the unicast burst or it MAY be sent during the burst.
Additional RAMS-I messages MAY be sent during the burst and these Additional RAMS-I messages MAY be sent during the burst and these
RAMS-I messages may or may not be a direct response to an RAMS-R RAMS-I messages may or may not be a direct response to an RAMS-R
message. message.
Note that RS learns the IP address and port information for RR Note that RS learns the IP address information for RR from the
from the RAMS-R message it received. (This description glosses RAMS-R message it received. (This description glosses over the
over the NAT details. Refer to Section 9 for a discussion of NAT details. Refer to Section 10 for a discussion of NAT-related
NAT-related issues.) issues.)
If RS cannot provide a rapid acquisition service, RS rejects the If RS cannot provide a rapid acquisition service, RS rejects the
request and informs RR immediately via an RAMS-I message. If RR request and informs RR immediately via an RAMS-I message. If RR
receives a message indicating that its rapid acquisition request receives a message indicating that its rapid acquisition request
has been denied, it abandons the rapid acquisition attempt and has been denied, it abandons the rapid acquisition attempt and
MAY immediately join the multicast session by sending an SFGMP MAY immediately join the multicast session by sending an SFGMP
Join message to its upstream multicast router for the new primary Join message towards its upstream multicast router for the new
multicast session. primary multicast session.
If RS accepts the request, it sends an RAMS-I message to RR If RS accepts the request, it sends an RAMS-I message to RR
(before commencing the unicast burst or during the unicast burst) (before commencing the unicast burst or during the unicast burst)
that comprises fields that can be used to describe the unicast that comprises fields that can be used to describe the unicast
burst (e.g., the maximum bitrate and the duration of the unicast burst (e.g., the maximum bitrate and the duration of the unicast
burst). burst).
The unicast burst duration MAY be calculated by RS, and its value The unicast burst duration MAY be calculated by RS, and its value
MAY be updated by messages received from RR. The join time MAY be updated by messages received from RR. The join time
information (for the new multicast session) MUST be populated in information (for the new multicast session) MUST be populated in
skipping to change at page 18, line 20 skipping to change at page 18, line 21
multicast session any time during or after the end of the unicast multicast session any time during or after the end of the unicast
burst via an SFGMP Join message. However, there may be missing burst via an SFGMP Join message. However, there may be missing
packets if RR joins the primary multicast session too early or packets if RR joins the primary multicast session too early or
too late. For example, if RR starts receiving the primary too late. For example, if RR starts receiving the primary
multicast stream while it is still receiving the unicast burst at multicast stream while it is still receiving the unicast burst at
a high excess bitrate, this may result in an increased risk of a high excess bitrate, this may result in an increased risk of
packet loss. Or, if RR joins the primary multicast session some packet loss. Or, if RR joins the primary multicast session some
time after the unicast burst is finished, there may be a gap time after the unicast burst is finished, there may be a gap
between the burst and multicast data (a number of RTP packets may between the burst and multicast data (a number of RTP packets may
be missing). In both cases, RR MAY issue retransmissions be missing). In both cases, RR MAY issue retransmissions
requests [RFC4585] to fill the gap. requests (via RTCP NACK messages) [RFC4585] to fill the gap.
Yet, there are cases where the remaining available bandwidth may Yet, there are cases where the remaining available bandwidth may
limit the number of retransmissions that can be provided within a limit the number of retransmissions that can be provided within a
certain time period, causing the retransmission data to arrive certain time period, causing the retransmission data to arrive
too late at RR (from an application-layer point of view). To too late at RR (from an application-layer point of view). To
cope with such cases, the RAMS-I message allows RS to signal cope with such cases, the RAMS-I message allows RS to signal
explicitly when RR should send the SFGMP Join message. explicitly when RR should send the SFGMP Join message.
Alternatively, RS may pre-compute the burst duration and the time Alternatively, RS may pre-compute the burst duration and the time
RR should send the SFGMP Join message. This information may be RR should send the SFGMP Join message. This information may be
conveyed in the RAMS-I message and can be updated in a subsequent conveyed in the RAMS-I message and can be updated in a subsequent
skipping to change at page 19, line 15 skipping to change at page 19, line 16
number minus one. number minus one.
If RR wants to stop the burst prior to receiving the multicast If RR wants to stop the burst prior to receiving the multicast
data, it sends an RAMS-T message without an RTP sequence number. data, it sends an RAMS-T message without an RTP sequence number.
Note that RR MUST send at least one RAMS-T message. Against the Note that RR MUST send at least one RAMS-T message. Against the
possibility of a message loss, RR MAY repeat the RAMS-T message possibility of a message loss, RR MAY repeat the RAMS-T message
multiple times as long as it follows the RTCP timer rules defined multiple times as long as it follows the RTCP timer rules defined
in [RFC4585]. in [RFC4585].
9. Terminate with RTCP BYE: When RR is no longer interested in 9. Terminate with RTCP BYE: When RR is receiving the burst, if RR
receiving the primary multicast stream and the associated unicast becomes no longer interested in the primary multicast stream, RR
burst, RR SHALL issue an RTCP BYE message to RS to terminate the SHALL issue an RTCP BYE message for the RTP retransmission
burst and the RTP retransmission session. Upon receiving an RTCP session and another RTCP BYE message for the primary multicast
BYE message, RS MUST terminate the rapid acquisition operation, session.
and cease transmitting any further packets of the associated
unicast burst. Section 6.1 of [RFC3550] mandates the RTCP BYE
message always to be sent with a sender or receiver report in a
compound RTCP packet (If no data has been received, an empty
receiver report MUST be included). With the information
contained in the receiver report, RS can also figure out how many
duplicate RTP packets have been delivered to RR (Note that this
will be an upper-bound estimate as one or more packets might have
been lost during the burst transmission). The impact of
duplicate packets and measures that can be taken to minimize the
impact of receiving duplicate packets will be addressed in
Section 6.3.
Note that if RR decides to switch to a new multicast session Upon receiving an RTCP BYE message, RS MUST terminate the rapid
after it already joined a multicast session following a rapid acquisition operation, and cease transmitting any further regular
acquisition request, RR MUST also send an RTCP BYE message to the retransmission packets as well as retransmission packets
Feedback Target for the RTP session associated with the current associated with the unicast burst. Section 6.1 of [RFC3550]
primary multicast stream. mandates the RTCP BYE message always to be sent with a sender or
receiver report in a compound RTCP packet (If no data has been
received, an empty receiver report MUST be included). With the
information contained in the receiver report, RS can also figure
out how many duplicate RTP packets have been delivered to RR
(Note that this will be an upper-bound estimate as one or more
packets might have been lost during the burst transmission). The
impact of duplicate packets and measures that can be taken to
minimize the impact of receiving duplicate packets will be
addressed in Section 6.3.
Editor's note: Is there a benefit for sending an RAMS-T message Note that an RTCP BYE message issued for the RTP retransmission
in conjuction with an RTCP BYE message in this case? session terminates the whole session and ceases transmitting any
further packets in that RTP session. Thus, in this case there is
no need for sending an (explicit) RAMS-T message, which would
only terminate the burst.
Note that for the purpose of gathering detailed information about Note that for the purpose of gathering detailed information about
RR's rapid acquisition experience, [I-D.begen-avt-rapid-sync-rtcp-xr] RR's rapid acquisition experience, [I-D.begen-avt-rapid-sync-rtcp-xr]
defines an RTCP Extended Report (XR) Block. This report is designed defines an RTCP Extended Report (XR) Block. This report is designed
to be payload-independent, thus, it can be used by any multicast to be payload-independent, thus, it can be used by any multicast
application that supports rapid acquisition. Support for this XR application that supports rapid acquisition. Support for this XR
report is, however, optional. report is, however, optional.
6.3. Shaping the Unicast Burst 6.3. Shaping the Unicast Burst
skipping to change at page 20, line 46 skipping to change at page 20, line 46
In the case the RAMS-T message sent by RR does not reach its In the case the RAMS-T message sent by RR does not reach its
destination, RS may continue sending the unicast burst even though RR destination, RS may continue sending the unicast burst even though RR
no longer needs it. In some cases, RS has not pre-computed the burst no longer needs it. In some cases, RS has not pre-computed the burst
duration and does not know when to stop the burst. To cover that duration and does not know when to stop the burst. To cover that
case, RR MAY repeat the RAMS-T message multiple times as long as it case, RR MAY repeat the RAMS-T message multiple times as long as it
follows the RTCP timer rules defined in [RFC4585]. RS MUST be follows the RTCP timer rules defined in [RFC4585]. RS MUST be
provisioned to deterministically terminate the burst at some point, provisioned to deterministically terminate the burst at some point,
even if it never receives an RAMS-T message for an ongoing burst. even if it never receives an RAMS-T message for an ongoing burst.
Upon a failure if RR becomes no longer interested in receiving the If RR becomes no longer interested in receiving the primary multicast
primary multicast stream and the associated unicast burst, RR SHALL stream and the associated unicast burst, RR SHALL issue an RTCP BYE
issue an RTCP BYE message to RS to terminate the burst and the RTP message to RS to terminate the RTP retransmission session. Only
retransmission session. Only after that, RR MAY send a new rapid after that, RR MAY send a new rapid acquisition request for another
acquisition request for another primary multicast session. primary multicast session.
7. Encoding of the Signaling Protocol in RTCP 7. Encoding of the Signaling Protocol in RTCP
This section defines the formats of the RTCP transport-layer feedback This section defines the formats of the RTCP transport-layer feedback
messages that are exchanged between the Retransmission Server (RS) messages that are exchanged between the Retransmission Server (RS)
and RTP Receiver (RR) during rapid acquisition. These messages are and RTP Receiver (RR) during rapid acquisition. These messages are
payload-independent and MUST be used by all RTP-based multicast referred to as the RAMS Messages. They are payload-independent and
applications that support rapid acquisition regardless of the payload MUST be used by all RTP-based multicast applications that support
they carry. rapid acquisition regardless of the payload they carry.
Specific payload formats are not defined in this document, but a Payload-specific feedback messages are not defined in this document,
framework is presented that allows payload-specific information to be but an extension mechanism is provided where further optional
included in the exchange. payload-independent and payload-specific information can be included
in the exchange.
The common packet format for the RTCP feedback messages is defined in The common packet format for the RTCP feedback messages is defined in
Section 6.1 of [RFC4585]. Each feedback message has a fixed-length Section 6.1 of [RFC4585]. Each feedback message has a fixed-length
field for version, padding, feedback message type (FMT), payload type field for version, padding, feedback message type (FMT), payload type
(PT), length, SSRC of packet sender, SSRC of media source as well as (PT), length, SSRC of packet sender, SSRC of media source as well as
a variable-length field for feedback control information (FCI). In a variable-length field for feedback control information (FCI).
the transport-layer feedback messages, the PT field is set to RTPFB
(205).
In the feedback messages defined in this section, optional extensions In the RAMS messages, the PT field is set to RTPFB (205) and the FMT
are encoded by using TLV elements as described below and sketched in field is set to RAMS (6). Individual RAMS messages are identified by
Figure 4: a sub-field called Sub Feedback Message Type (SFMT).
7.1. Extensions
To improve the functionality of the RAMS method in certain
applications, it may be desirable to define new fields in the RAMS
Request, Information and Termination messages. Such fields MUST be
encoded as TLV elements as described below and sketched in Figure 4:
o Type: A single-octet identifier that defines the type of the o Type: A single-octet identifier that defines the type of the
parameter represented in this TLV element. parameter represented in this TLV element.
o Length: A two-octet field that indicates the length of the Value o Length: A two-octet field that indicates the length of the TLV
field in octets. element excluding the Type and Length fields in octets. Note that
this length does not include any padding that is required for
alignment.
o Value: Variable-size set of octets that contains the specific o Value: Variable-size set of octets that contains the specific
value for the parameter. value for the parameter.
If a TLV element does not fall on a 32-bit boundary, the last word If a TLV element does not fall on a 32-bit boundary, the last word
must be padded to the boundary using further bits set to 0. must be padded to the boundary using further bits set to 0.
In an RAMS message any vendor-neutral or private extension MUST be
placed after the mandatory fields (if any). The support for
extensions is OPTIONAL.
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Value | | Type | Length | Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value contd. / | Value contd. /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Structure of a TLV element Figure 4: Structure of a TLV element
Editor's note: The optional fields in the RAMS messages (defined
below) will be converted to TLV elements in a later version of this
document.
7.1. RAMS Request 7.1.1. Vendor-Neutral Extensions
The RAMS Request message is identified by PT=RTPFB and FMT=6. If the goal in defining new TLV elements is to extend the
functionality in a vendor-neutral manner, they MUST be registered
with IANA through the guidelines provided in Section 14.4.
The current document defines several vendor-neutral extensions in the
following sections.
7.1.2. Private Extensions
It is desirable to allow vendors to use private extensions in TLV
format. For interoperability, such extensions MUST NOT collide with
each other.
A certain range of TLV Types is reserved for private extensions
(Refer to Section 14.4). IANA management for these extensions is
unnecessary and they are the responsibility of individual vendors.
The structure that MUST be used for the private extensions is
depicted in Figure 5. Here, the enterprise numbers are used from
http://www.iana.org/assignments/enterprise-numbers. This will ensure
the uniqueness of the private extensions and avoid any collision.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Ent. Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ent. Number contd. | Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value contd. /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: Structure of a private extension
7.2. RAMS Request
The RAMS Request message is identified by SFMT=1.
The FCI field MUST contain only one RAMS Request. The FCI field MUST contain only one RAMS Request.
The RAMS Request is used by RR to request rapid acquisition for a new The RAMS Request is used by RR to request rapid acquisition for a new
multicast RTP session. multicast RTP session.
The FCI field has the structure depicted in Figure 5. The FCI field has the structure depicted in Figure 6.
Editor's note: We have not finalized whether RAMS-R messages need a Editor's note: We have not finalized whether RAMS-R messages need a
sequence number or not. sequence number or not.
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Min RAMS Buffer Fill Requirement | | SFMT=1 | Optional TLV-encoded Fields |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ |
| Max RAMS Buffer Fill Requirement | : Optional TLV-encoded Fields (and Padding, if needed) :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Max Receive Bitrate |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: (TLV-encoded Extensions) :
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: FCI field syntax for the RAMS Request message Figure 6: FCI field syntax for the RAMS Request message
o Min RAMS Buffer Fill Requirement (32 bits): Optional TLV element o Min RAMS Buffer Fill Requirement (32 bits): Optional TLV element
that denotes the minimum number of octets of content the RTP that denotes the minimum number of octets of content the RTP
receiver desires to have in its buffer as a result of the unicast receiver desires to have in its buffer as a result of the unicast
burst. burst.
The RTP receiver may have knowledge of its buffering requirements. The RTP receiver may have knowledge of its buffering requirements.
These requirements may be application or device specific. For These requirements may be application or device specific. For
instance, the receiver may need to have a certain amount of data instance, the receiver may need to have a certain amount of data
in its application buffer to handle interdependency within the in its application buffer to handle interdependency within the
data. If RS is told the buffering ability of the receiver, it may data. If RS is told the buffering ability of the receiver, it may
tailor the burst more precisely. The methods used by the receiver tailor the burst more precisely. The methods used by the receiver
to determine this value are application specific, and thus, out of to determine this value are application specific, and thus, out of
scope. scope.
If specified, the amount of backfill that will be provided by the If specified, the amount of backfill that will be provided by the
unicast burst SHOULD NOT be smaller than this value since it will unicast burst SHOULD NOT be smaller than this value since it will
not be able to build up the desired level of buffer at RR and may not be able to build up the desired level of buffer at RR and may
cause buffer underruns. cause buffer underruns.
Type: TBD
Length: TBD
o Max RAMS Buffer Fill Requirement (32 bits): Optional TLV element o Max RAMS Buffer Fill Requirement (32 bits): Optional TLV element
that denotes the maximum number of octets of content the RTP that denotes the maximum number of octets of content the RTP
receiver can buffer without losing the burst data due to buffer receiver can buffer without losing the burst data due to buffer
overflow. overflow.
The RTP receiver may have knowledge of its buffering requirements. The RTP receiver may have knowledge of its buffering requirements.
These requirements may be application or device specific. For These requirements may be application or device specific. For
instance, one receiver may have more physical memory than another instance, one receiver may have more physical memory than another
receiver, and thus, can buffer more data. If RS knows the receiver, and thus, can buffer more data. If RS knows the
buffering ability of the receiver, it may tailor the burst more buffering ability of the receiver, it may tailor the burst more
precisely. The methods used by the receiver to determine this precisely. The methods used by the receiver to determine this
value are application specific, and thus, out of scope. value are application specific, and thus, out of scope.
If specified, the amount of backfill that will be provided by the If specified, the amount of backfill that will be provided by the
unicast burst SHOULD NOT be larger than this value since it may unicast burst SHOULD NOT be larger than this value since it may
cause buffer overflows at RR. cause buffer overflows at RR.
Type: TBD
Length: TBD
o Max Receive Bitrate (32 bits): Optional TLV element that denotes o Max Receive Bitrate (32 bits): Optional TLV element that denotes
the maximum bitrate (in bits per second) that the RTP receiver can the maximum bitrate (in bits per second) that the RTP receiver can
process the unicast burst. This rate should include whatever process the unicast burst. This rate should include whatever
knowledge the receiver has that would provide an upper bound on knowledge the receiver has that would provide an upper bound on
the unicast burst bitrate. The limits may include local receiver the unicast burst bitrate. The limits may include local receiver
limits as well as network limits that are known to the receiver. limits as well as network limits that are known to the receiver.
If specified, the unicast burst bitrate SHOULD NOT be larger than If specified, the unicast burst bitrate SHOULD NOT be larger than
this value since it may cause congestion and packet loss. this value since it may cause congestion and packet loss.
Type: TBD
Length: TBD
The semantics of the RAMS-R feedback message is independent of the The semantics of the RAMS-R feedback message is independent of the
payload type. payload type.
7.2. RAMS Information 7.3. RAMS Information
The RAMS Information message is identified by PT=RTPFB and FMT=7. The RAMS Information message is identified by SFMT=2.
The FCI field MUST contain only one RAMS Information. The FCI field MUST contain only one RAMS Information.
The RAMS Information is used to describe the unicast burst that will The RAMS Information is used to describe the unicast burst that will
be sent for rapid acquisition. It also includes other useful be sent for rapid acquisition. It also includes other useful
information for RR as described below. Optional payload-specific information for RR as described below. Optional payload-specific
information MAY follow RAMS Information. information MAY follow RAMS Information.
The FCI field has the structure depicted in Figure 6. The FCI field has the structure depicted in Figure 7.
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MSN |S| Response | Rsvd. | | SFMT=2 | MSN |S| Response | Rsvd. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extended RTP Seqnum of the First Burst Packet | | Extended RTP Seqnum of the First Burst Packet |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Earliest Multicast Join Time | : Optional TLV-encoded Fields (and Padding, if needed) :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Burst Duration |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Max Burst Bitrate |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: (TLV-encoded Extensions) :
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: FCI field syntax for the RAMS Information message Figure 7: FCI field syntax for the RAMS Information message
o Message Sequence Number (8 bits) : Mandatory field that denotes o Message Sequence Number (8 bits) : Mandatory field that denotes
the sequence number of this RAMS-I message. During rapid the sequence number of this RAMS-I message. During rapid
acquisition, multiple RAMS-I messages MAY be sent and/or the same acquisition, multiple RAMS-I messages MAY be sent and/or the same
RAMS-I message MAY be repeated. The first RAMS-I message SHALL RAMS-I message MAY be repeated. The first RAMS-I message SHALL
have an MSN value of 0. This value SHALL NOT be changed if the have an MSN value of 0. This value SHALL NOT be changed if the
same RAMS-I message is sent to the same RR multiple times for same RAMS-I message is sent to the same RR multiple times for
redundancy purposes. If a new information is conveyed in a new redundancy purposes. If a new information is conveyed in a new
RAMS-I message, the MSN value SHALL be incremented by one. RAMS-I message, the MSN value SHALL be incremented by one.
skipping to change at page 25, line 7 skipping to change at page 26, line 4
Editor's note: The use of this flag is still under discussion. Editor's note: The use of this flag is still under discussion.
o Response (8 bits): Mandatory field that denotes the RS response o Response (8 bits): Mandatory field that denotes the RS response
code for this RAMS-I message. code for this RAMS-I message.
Editor's note: Response codes will be defined and registered with Editor's note: Response codes will be defined and registered with
IANA in a later version. Current proposals include: IANA in a later version. Current proposals include:
1. Success 1. Success
2. Bad_Request 2. Bad_Request
3. No_Server_Resources_Available 3. No_Server_Resources_Available
4. No_Network_Resources_Available 4. No_Network_Resources_Available
5. No_Buffered_Content_Available 5. No_Buffered_Content_Available
o Rsvd (16 bits): Reserved. This field SHALL be set to 0. o Rsvd (8 bits): Reserved. This field SHALL be set to 0.
o Extended RTP Seqnum of the First Burst Packet (32 bits): o Extended RTP Seqnum of the First Burst Packet (32 bits):
Mandatory field that specifies the extended RTP sequence number of Mandatory field that specifies the extended RTP sequence number of
the first packet that will be sent as part of the burst. This the first packet that will be sent as part of the burst. This
allows RR to know if one or more packets have been dropped at the allows RR to know if one or more packets have been dropped at the
beginning of the burst. 32-bit extended RTP sequence number is beginning of the burst. 32-bit extended RTP sequence number is
constructed by putting the 16-bit RTP sequence number in the lower constructed by putting the 16-bit RTP sequence number in the lower
two bytes and octet 0's in the higher two bytes. two bytes and octet 0's in the higher two bytes.
o Earliest Multicast Join Time (32 bits): Optional TLV element that o Earliest Multicast Join Time (32 bits): Optional TLV element that
skipping to change at page 25, line 43 skipping to change at page 26, line 39
Editor's note: We need to decide whether we will use ms or RTP Editor's note: We need to decide whether we will use ms or RTP
ticks in this field. ticks in this field.
Note that if the RAMS request has been accepted, RS MUST send this Note that if the RAMS request has been accepted, RS MUST send this
field at least once, so that RR knows when to join the primary field at least once, so that RR knows when to join the primary
multicast session. If the burst request has been rejected as multicast session. If the burst request has been rejected as
indicated in the Response field, this field MAY be omitted or set indicated in the Response field, this field MAY be omitted or set
to 0. In that case, it is up to RR when or whether to join the to 0. In that case, it is up to RR when or whether to join the
primary multicast session. primary multicast session.
Type: TBD
Length: TBD
o Burst Duration (32 bits): Optional TLV element that denotes the o Burst Duration (32 bits): Optional TLV element that denotes the
duration of the burst that RS is planning to send (in RTP ticks). duration of the burst that RS is planning to send (in RTP ticks).
In the absence of additional stimulus, RS will send a burst of In the absence of additional stimulus, RS will send a burst of
this duration. However, the burst duration may be modified by this duration. However, the burst duration may be modified by
subsequent events, including changes in the primary multicast subsequent events, including changes in the primary multicast
stream and reception of RAMS-T messages. stream and reception of RAMS-T messages.
Note that RS MUST terminate the flow in a deterministic timeframe, Note that RS MUST terminate the flow in a deterministic timeframe,
even if it does not get an RAMS-T or a BYE from RR. It is even if it does not get an RAMS-T or a BYE from RR. It is
optional to send this field in an RAMS-I message when the burst optional to send this field in an RAMS-I message when the burst
request is accepted. If the burst request has been rejected as request is accepted. If the burst request has been rejected as
indicated in the Response field, this field MAY be omitted or set indicated in the Response field, this field MAY be omitted or set
to 0. to 0.
Type: TBD
Length: TBD
o Max Burst Bitrate (32 bits): Optional TLV element that denotes o Max Burst Bitrate (32 bits): Optional TLV element that denotes
the maximum bitrate (in bits per second) that will be used by RS the maximum bitrate (in bits per second) that will be used by RS
for the unicast burst. for the unicast burst.
Type: TBD
Length: TBD
The semantics of the RAMS-I feedback message is independent of the The semantics of the RAMS-I feedback message is independent of the
payload type. payload type.
The RAMS-I message MAY be sent multiple times at the start of, prior The RAMS-I message MAY be sent multiple times at the start of, prior
to, or during the unicast burst. The subsequent RAMS-I messages MAY to, or during the unicast burst. The subsequent RAMS-I messages MAY
signal changes in any of the fields. signal changes in any of the fields.
7.3. RAMS Termination 7.4. RAMS Termination
The RAMS Termination message is identified by PT=RTPFB and FMT=8. The RAMS Termination message is identified by SFMT=3.
The FCI field MUST contain only one RAMS Termination. The FCI field MUST contain only one RAMS Termination.
The RAMS Termination may be used to assist RS in determining when to The RAMS Termination may be used to assist RS in determining when to
stop the burst. stop the burst.
If prior to sending the RAMS-T message RR has already joined the If prior to sending the RAMS-T message RR has already joined the
primary multicast session and received at least one RTP packet from primary multicast session and received at least one RTP packet from
the multicast session, RR includes the sequence number of the first the multicast session, RR includes the sequence number of the first
RTP packet in the RAMS-T message. With this information, RS can RTP packet in the RAMS-T message. With this information, RS can
decide when to terminate the unicast burst. decide when to terminate the unicast burst.
If RR issues the RAMS-T message before it has joined and/or begun If RR issues the RAMS-T message before it has joined and/or begun
receiving RTP packets from the primary multicast session, RR does not receiving RTP packets from the primary multicast session, RR does not
specify any sequence number in the RAMS-T message, which indicates RS specify any sequence number in the RAMS-T message, which indicates RS
to stop the burst immediately. However, the RAMS-T message may get to stop the burst immediately. However, the RAMS-T message may get
lost and RS may not receive this message. lost and RS may not receive this message.
The FCI field has the structure depicted in Figure 7. The FCI field has the structure depicted in Figure 8.
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extended RTP Seqnum of First Multicast Packet | | SFMT=3 | Optional TLV-encoded Fields |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ |
: (TLV-encoded Extensions) : : Optional TLV-encoded Fields (and Padding, if needed) :
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: FCI field syntax for the RAMS Termination message Figure 8: FCI field syntax for the RAMS Termination message
o Extended RTP Seqnum of First Multicast Packet (32 bits): Optional o Extended RTP Seqnum of First Multicast Packet (32 bits): Optional
TLV element that specifies the extended RTP sequence number of the TLV element that specifies the extended RTP sequence number of the
of the first multicast packet received by RR. If no RTP packet of the first multicast packet received by RR. If no RTP packet
has been received from the primary multicast session, this field has been received from the primary multicast session, this field
does not exist and tells RS to stop the burst immediately. does not exist and tells RS to stop the burst immediately.
The semantics of the RAMS-T feedback message is independent of the Type: TBD
payload type.
7.4. Extensions
To improve the functionality of the RAMS method in certain
applications, it may be desirable to define new fields in the RAMS
Request, Information and Termination messages. Such fields MUST be
defined as TLV elements. If the goal in defining these new fields is
to extend the protocol in a vendor-neutral manner, they MUST be
registered with IANA through an Informational or a Standards-track
RFC. The support for these new fields is OPTIONAL. In an RAMS
message, any extension MUST be placed after any existing mandatory
field for that message.
Editor's note: We should specify the requirements for registering
new TLV elements.
It is also desirable to allow vendors to use vendor-specific
extensions (in TLV format) in any of the RAMS messages. For
interoperability, such extensions MUST NOT collide with each other.
Editor's note: Some approaches are currently being examined for
vendor-specific extensions. A potential solution is depicted in
Figure 8. In this approach, the enterprise numbers are used from
http://www.iana.org/assignments/enterprise-numbers. This will ensure
the uniqueness of the vendor-specific extensions.
0 1 2 3 Length: TBD
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Mandatory Fields as Defined in This Document :
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = TBD | Length | Ent. Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ent. Number contd. | Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value contd. /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: Structure of a vendor-specific extension The semantics of the RAMS-T feedback message is independent of the
payload type.
8. SDP Definitions and Examples 8. SDP Definitions and Examples
8.1. Definitions 8.1. Definitions
The syntax of the 'rtcp-fb' attribute has been defined in [RFC4585]. The syntax of the 'rtcp-fb' attribute has been defined in [RFC4585].
Here we add the following syntax to the 'rtcp-fb' attribute (the Here we add the following syntax to the 'rtcp-fb' attribute (the
feedback type and optional parameters are all case sensitive): feedback type and optional parameters are all case sensitive):
(In the following ABNF [RFC5234], fmt, SP and CRLF are used as (In the following ABNF [RFC5234], fmt, SP and CRLF are used as
skipping to change at page 29, line 6 skipping to change at page 29, line 15
8.2. Examples 8.2. Examples
This section provides a declarative SDP [RFC4566] example for This section provides a declarative SDP [RFC4566] example for
enabling rapid acquisition of multicast RTP sessions. The following enabling rapid acquisition of multicast RTP sessions. The following
example uses the SDP grouping semantics [RFC3388], the RTP/AVPF example uses the SDP grouping semantics [RFC3388], the RTP/AVPF
profile [RFC4585], the RTP retransmissions [RFC4588], the RTCP profile [RFC4585], the RTP retransmissions [RFC4588], the RTCP
extensions for SSM sessions with unicast feedback extensions for SSM sessions with unicast feedback
[I-D.ietf-avt-rtcpssm] and the source-specific media attributes [I-D.ietf-avt-rtcpssm] and the source-specific media attributes
[I-D.ietf-mmusic-sdp-source-attributes]. [I-D.ietf-mmusic-sdp-source-attributes].
In the example below, we have two primary source streams and two In the example shown Figure 9, we have a primary multicast stream and
unicast retransmission streams for each of these source streams. The a unicast retransmission stream. The source stream is multicast from
source streams are multicast from a distribution source (with a a distribution source (with a source IP address of 192.0.2.2) to the
source IP address of 8.166.1.1) in different multicast sessions. For multicast destination address of 233.252.0.2 and port 41000. A
each source stream, a feedback target address (9.30.30.1) is also feedback target (with an address of 192.0.2.1 and port of 41001) is
specified with the 'rtcp' attribute. The RTP receiver(s) can report specified with the 'rtcp' attribute. The RTP receiver(s) can report
missing packets on the source stream to the feedback target and missing packets on the source stream to this feedback target and
request retransmissions. The parameter 'rtx-time' specifies the time request retransmissions. The parameter 'rtx-time' specifies the time
in milliseconds (measured from the time a packet was first sent) that in milliseconds (measured from the time a packet was first sent) that
the sender (in this case the feedback target) keeps an RTP packet in the sender (in this case the feedback target) keeps an RTP packet in
its buffers available for retransmission. its buffers available for retransmission.
For the first source stream, only the conventional retransmission Editor's note: In the context of RAMS, we may need a clarification
support is enabled. For the second source stream, both the on the selection/definition of rtx-time. Would it indicate the time
conventional retransmission and rapid acquisition support are the packet needs to be available after it has been received by RS?
enabled. This is achieved by the "a=rtcp-fb:98 nack ssli" line.
The RTP retransmissions are sent on a unicast session with a
destination port of 41002. The RTCP port for the unicast session
(41003) is specified with the 'rtcp' attribute. In this example,
both the conventional retransmission and rapid acquisition support
are enabled. This is achieved by the additional "a=rtcp-fb:98 nack
ssli" line. Note that this declarative SDP includes the "a=sendonly"
line for the media description of the retransmission stream and is
for the Retransmission Server (RS). Its counterpart for the RTP
Receiver (RR) includes the "a=recvonly" line as shown in Figure 10.
When an RTP receiver requires rapid acquisition for a new multicast When an RTP receiver requires rapid acquisition for a new multicast
session it wants to join, it sends an RAMS-R message to the feedback session it wants to join, it sends an RAMS-R message to the feedback
target. This feedback message has to have the SSRC of the primary target of that primary multicast session. This feedback message has
source session for which rapid acquisition is requested for. to have the SSRC of the primary multicast stream for which rapid
However, since this RTP receiver has not received any RTP packets acquisition is requested for. However, since this RTP receiver has
from this primary source session yet, the RTP receiver MUST learn the not received any RTP packets from the primary multicast session yet,
SSRC value from the 'ssrc' attribute of the media description the RTP receiver MUST learn the SSRC value from the 'ssrc' attribute
[I-D.ietf-avt-rtcpssm]. In addition to the SSRC value, the 'cname' of the media description [I-D.ietf-avt-rtcpssm]. In addition to the
source attribute MUST also be present in the SDP description SSRC value, the 'cname' source attribute MUST also be present in the
[I-D.ietf-mmusic-sdp-source-attributes]. Note that listing the SSRC SDP description [I-D.ietf-mmusic-sdp-source-attributes].
values for the primary source sessions in the SDP file does not
create a problem in SSM sessions when an SSRC collision occurs. This Note that listing the SSRC values for the primary multicast sessions
is because in SSM sessions, an RTP receiver that observed an SSRC in the SDP file does not create a problem in SSM sessions when an
collision with a media source MUST change its own SSRC SSRC collision occurs. This is because in SSM sessions, an RTP
[I-D.ietf-avt-rtcpssm] by following the rules defined in [RFC3550]. receiver that observed an SSRC collision with a media source MUST
change its own SSRC [I-D.ietf-avt-rtcpssm] by following the rules
defined in [RFC3550].
A feedback target that receives an RAMS-R feedback message becomes A feedback target that receives an RAMS-R feedback message becomes
aware that the prediction chain at the RTP receiver side has been aware that the prediction chain at the RTP receiver side has been
broken or does not exist any more. If the necessary conditions are broken or does not exist any more. If the necessary conditions are
satisfied (as outlined in Section 7 of [RFC4585]) and available satisfied (as outlined in Section 7 of [RFC4585]) and available
resources exist, the feedback target MAY react to the RAMS-R message resources exist, the feedback target MAY react to the RAMS-R message
by sending any payload-specific feedback message(s) and starting the by sending any transport-layer and payload-specific feedback
unicast burst. message(s) and starting the unicast burst.
v=0 v=0
o=ali 1122334455 1122334466 IN IP4 rams.example.com o=ali 1122334455 1122334466 IN IP4 rams.example.com
s=Rapid Acquisition Examples s=Rapid Acquisition Example
t=0 0 t=0 0
a=group:FID 1 2
a=group:FID 3 4 a=group:FID 3 4
a=rtcp-unicast:rsi a=rtcp-unicast:rsi
m=video 40000 RTP/AVPF 96 m=video 41000 RTP/AVPF 98
i=Primary Multicast Stream #1 i=Primary Multicast Stream #2
c=IN IP4 224.1.1.1/255 c=IN IP4 233.252.0.2/255
a=source-filter: incl IN IP4 224.1.1.1 192.0.2.2 a=source-filter: incl IN IP4 233.252.0.2 192.0.2.2
a=recvonly a=recvonly
a=rtpmap:96 MP2T/90000 a=rtpmap:98 MP2T/90000
a=rtcp:40001 IN IP4 192.0.2.1 a=rtcp:41001 IN IP4 192.0.2.1
a=rtcp-fb:96 nack a=rtcp-fb:98 nack
a=mid:1 a=rtcp-fb:98 nack ssli
m=video 40002 RTP/AVPF 97 a=ssrc:123321 cname:iptv-ch32@rams.example.com
i=Unicast Retransmission Stream #1 (Ret. Support Only) a=mid:3
m=video 41002 RTP/AVPF 99
i=Unicast Retransmission Stream #2 (Ret. and Rapid Acq. Support)
c=IN IP4 192.0.2.1 c=IN IP4 192.0.2.1
a=recvonly a=sendonly
a=rtpmap:97 rtx/90000 a=rtpmap:99 rtx/90000
a=rtcp:40003 a=rtcp:41003
a=fmtp:97 apt=96 a=fmtp:99 apt=98; rtx-time=5000
a=fmtp:97 rtx-time=3000 a=mid:4
a=mid:2
Figure 9: Example SDP for RS when RAMS support is enabled
v=0
o=ali 1122334455 1122334466 IN IP4 rams.example.com
s=Rapid Acquisition Example
t=0 0
a=group:FID 3 4
a=rtcp-unicast:rsi
m=video 41000 RTP/AVPF 98 m=video 41000 RTP/AVPF 98
i=Primary Multicast Stream #2 i=Primary Multicast Stream #2
c=IN IP4 224.1.1.2/255 c=IN IP4 233.252.0.2/255
a=source-filter: incl IN IP4 224.1.1.2 192.0.2.2 a=source-filter: incl IN IP4 233.252.0.2 192.0.2.2
a=recvonly a=recvonly
a=rtpmap:98 MP2T/90000 a=rtpmap:98 MP2T/90000
a=rtcp:41001 IN IP4 192.0.2.1 a=rtcp:41001 IN IP4 192.0.2.1
a=rtcp-fb:98 nack a=rtcp-fb:98 nack
a=rtcp-fb:98 nack ssli a=rtcp-fb:98 nack ssli
a=ssrc:123321 cname:iptv-ch32@rams.example.com a=ssrc:123321 cname:iptv-ch32@rams.example.com
a=mid:3 a=mid:3
m=video 41002 RTP/AVPF 99 m=video 41002 RTP/AVPF 99
i=Unicast Retransmission Stream #2 (Ret. and Rapid Acq. Support) i=Unicast Retransmission Stream #2 (Ret. and Rapid Acq. Support)
c=IN IP4 192.0.2.1 c=IN IP4 192.0.2.1
a=recvonly a=recvonly
a=rtpmap:99 rtx/90000 a=rtpmap:99 rtx/90000
a=rtcp:41003 a=rtcp:41003
a=fmtp:99 apt=98; rtx-time=5000 a=fmtp:99 apt=98; rtx-time=5000
a=mid:4 a=mid:4
Figure 10: Example SDP for RR when RAMS support is enabled
The offer/answer model considerations [RFC3264] for the 'rtcp-fb' The offer/answer model considerations [RFC3264] for the 'rtcp-fb'
attribute are provided in Section 4.2 of [RFC4585]. attribute are provided in Section 4.2 of [RFC4585].
Editor's note: We will provide more SDP examples in a later version Editor's note: We will provide more SDP examples in later versions
as needed. as needed.
9. NAT Considerations 9. Signaling Ports via Publish Ports (PubPorts) RTCP Message
Editor's note: This section will explain the potential issues Editor's note: The PubPorts message described in this section can be
experienced in NAT environments. Some solution approaches will be used in non-RAMS contexts as well. Based on the feedback from AVT,
presented. This section will also include a recommendation for the we can move this discussion to a separate document.
RTP/RTCP Muxing solution that is discussed in
[I-D.ietf-avt-rtp-and-rtcp-mux].
10. Known Implementations As described in Section 6.2, when RR wants to acquire a new multicast
RTP session, it sends an RAMS-R message to the feedback target
address of that session. Upon receipt of this RTCP message, RS
learns the IP address of RR. Depending on the available resources,
RS may accept the request message and create a new unicast RTP
session. While RS can normally use the port(s) specified in the SDP
for the unicast session, in certain situations (e.g., when another
application is already using the port or a NAPT(s) is between RS and
RR), RR may need to receive RTP (and RTCP) traffic on a different
transport address (i.e., a different UDP port). RTSP signaling is
too slow to accomplish this, so we propose to use a new RTCP
extension called PubPorts to communicate the new RTP (and RTCP) ports
to RS.
10.1. Open Source RTP Receiver Implementation by Cisco The PubPorts message has the following layout:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P| FMT | PT | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of Packet Sender |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of Media Source |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RTP Port | RTCP Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 11: FCI field syntax for the PubPorts message
Editor's note: We will finalize the layout of this feedback message
in a later version.
After RR sends this message to RS, RS will begin sending this SSRC to
the RTP (and RTCP) ports indicated.
If RTP/RTCP multiplexing [I-D.ietf-avt-rtp-and-rtcp-mux] is supported
by RR, it can provide the same port in the RTP and RTCP port fields.
A zero value in either the RTP or RTCP port fields indicates that RS
should send the RTP or RTCP to the transport address it received the
RTCP from; this is helpful to optimize NAT scenarios (Section 10).
10. NAT Considerations
For a variety of reasons, one or more NAPT devices (hereafter simply
called NAT) are expected to exist between RR and RS. NATs have a
variety of operating characteristics for UDP traffic [RFC4787]. For
a NAT to permit traffic from RS to arrive at RR, the NAT(s) must
first either:
a. See UDP traffic sent from RR (which is on the 'inside' of the
NAT) to RS (which is on the 'outside' of the NAT). This traffic
is sent to the same transport address as the subsequent response
traffic, OR;
b. Be configured to forward certain ports (e.g., using HTML
configuration, UPnP IGD [UPnP-IGD], DLNA [DLNA]). Details of
this are out of scope of this document.
For both (a) and (b), RR is responsible for maintaining the NAT's
state if it wants to receive traffic from the RS on that port. For
(a), RR MUST send UDP traffic to keep the NAT binding alive, at least
every 30 seconds [RFC4787]. Note that while (a) is more like an
automatic/dynamic configuration, (b) is more like a manual/static
configuration.
When using (a), RR will need to first learn the UDP port(s) of the
NAT's binding(s) from the perspective of RS. This is done by sending
a STUN [RFC5389] messages from RR to the RTP port of RS which will be
used for incoming RTP traffic. If RTP/RTCP multiplexing is not
supported by RR, it will need to send a second STUN message to the
RTCP port of RS which will be used for incoming RTCP traffic. If
RTP/RTCP multiplexing is supported by RR, it only needs to learn one
port. RS receives the STUN message(s) and responds to them. RR now
knows the UDP ports from the perspective of RS. RR sends a PubPorts
message to RS, following the procedures described in Section 9. The
STUN round-trip can be avoided if RR supports RTP/RTCP multiplexing
and if RR can receive the RTP/RTCP from RS on the same transport
address on which RR transmits the RTCP messages to RS (See
Section 9).
11. Known Implementations
11.1. Open Source RTP Receiver Implementation by Cisco
An open source RTP Receiver code that implements the functionalities An open source RTP Receiver code that implements the functionalities
introduced in this document is available. For documentation, visit introduced in this document is available. For documentation, visit
the following URL: the following URL:
http://www.cisco.com/en/US/docs/video/cds/cda/vqe/3_0/user/guide/ http://www.cisco.com/en/US/docs/video/cds/cda/vqe/3_0/user/guide/
ch1_over.html ch1_over.html
The code is also available at: The code is also available at:
ftp://ftpeng.cisco.com/ftp/vqec/ ftp://ftpeng.cisco.com/ftp/vqec/
Note that this code is under development and may be based on an Note that this code is under development and may be based on an
earlier version of this document. As we make progress in the draft, earlier version of this document. As we make progress in the draft,
the source code will also be updated to reflect the changes. the source code will also be updated to reflect the changes.
Some preliminary results based on this code are available in [CCNC09] Some preliminary results based on this code are available in [CCNC09]
and [IC2009]. and [IC2009].
10.2. IPTV Commercial Implementation by Microsoft 11.2. IPTV Commercial Implementation by Microsoft
Rapid Acquisition of Multicast RTP Sessions is supported as part of Rapid Acquisition of Multicast RTP Sessions is supported as part of
the Microsoft Mediaroom Internet Protocol Television (IPTV) and the Microsoft Mediaroom Internet Protocol Television (IPTV) and
multimedia software platform. This system is in wide commercial multimedia software platform. This system is in wide commercial
deployment. More information can be found at: deployment. More information can be found at:
http://www.microsoft.com/mediaroom http://www.microsoft.com/mediaroom
http://informitv.com/articles/2008/10/13/channelchangetimes/ http://informitv.com/articles/2008/10/13/channelchangetimes/
11. Open Issues 12. Open Issues
o Update message formats to reflect the TLV encapsulations.
o Check whether we can register only one FMT value for all RAMS
messages and use a sub FMT value in the messages to indicate the
specific RAMS message. This change seams feasible and will be
made in a later version.
o Define the structure for vendor-specific extensions and check o Discussion of acquisition for the individual RTP streams vs. the
whether SDES can be used for this purpose. whole RTP session.
o The use of extended seqnums in the RAMS messages. o The use of extended RTP sequence numbers in the RAMS messages.
o Check whether RFC 5506 should be used/supported. o Check whether RFC 5506 should be used/supported.
o Update the SDP example (Use correct unicast and multicast o Completing burst shaping, NAT and security considerations
addresses). sections.
o Burst shaping issues and security considerations sections.
12. Security Considerations 13. Security Considerations
TBC. TBC.
13. IANA Considerations 14. IANA Considerations
This document registers a new SDP attribute value and several new
RTCP packets.
The following contact information shall be used for all registrations The following contact information shall be used for all registrations
in this document: in this document:
Ali Begen Ali Begen
abegen@cisco.com abegen@cisco.com
170 West Tasman Drive 170 West Tasman Drive
San Jose, CA 95134 USA San Jose, CA 95134 USA
13.1. Registration of SDP Attribute Values 14.1. Registration of SDP Attribute Values
This document registers a new value for the 'nack' attribute to be This document registers a new value for the 'nack' attribute to be
used with the 'rtcp-fb' attribute in SDP. For more information about used with the 'rtcp-fb' attribute in SDP. For more information about
'rtcp-fb', refer to [RFC4585]. 'rtcp-fb', refer to [RFC4585].
Value name: ssli Value name: ssli
Long name: Stream Synchronization Loss Indication Long name: Stream Synchronization Loss Indication
Usable with: nack Usable with: nack
Reference: This document Reference: This document
13.2. Registration of FMT Values 14.2. Registration of FMT Values
Within the RTPFB range, the following three format (FMT) values are Within the RTPFB range, the following format (FMT) value is
registered: registered:
Name: RAMS-R Name: RAMS
Long name: Rapid Acquisition of Multicast Sessions Request Long name: Rapid Acquisition of Multicast Sessions
Value: 6 Value: 6
Reference: This document Reference: This document
Name: RAMS-I 14.3. SFMT Values for RAMS Messages Registry
Long name: Rapid Acquisition of Multicast Sessions Information
Value: 7
Reference: This document
Name: RAMS-T This document creates a new sub-registry for the sub-feedback message
Long name: Rapid Acquisition of Multicast Sessions Termination type (SFMT) values to be used with the FMT value registered for RAMS
Value: 8 messages. The registry is called the SFMT Values for RAMS Messages
Reference: This document Registry. This registry is to be managed by the IANA according to
the Specification Required policy of [RFC5226].
14. Acknowledgments The length of the SFMT field in the RAMS messages is a single octet,
allowing 256 values. The registry is initialized with the following
entries:
Value Name Reference
----- -------------------------------------------------- -------------
1 RAMS Request This document
2 RAMS Information This document
3 RAMS Termination This document
The SFMT values 0 and 255 are reserved for future use.
Any registration for an unassigned SFMT value MUST contain the
following information:
o Contact information of the one doing the registration, including
at least name, address, and email.
o A detailed description of what the new SFMT represents and how it
shall be interpreted.
Note that new RAMS functionality should be introduced by using the
extension mechanism within the existing RAMS message types not by
introducing new message types unless it is absolutely necessary.
14.4. RAMS TLV Space Registry
This document creates a new IANA TLV space registry for the RAMS
extensions. The registry is called the RAMS TLV Space Registry.
This registry is to be managed by the IANA according to the
Specification Required policy of [RFC5226].
The length of the Type field in the TLV elements is a single octet,
allowing 256 values. The registry is initialized with the following
entries:
Type Description Reference
---- -------------------------------------------------- -------------
TBD TBD This document
... ...
The registry entries are TBC.
The TYPE values 0 and 255 are reserved for future use. The TYPE
values between (and including) 128 and 254 are reserved for private
extensions.
Any registration for an unassigned TYPE value MUST contain the
following information:
o Contact information of the one doing the registration, including
at least name, address, and email.
o A detailed description of what the new TLV element represents and
how it shall be interpreted.
15. Acknowledgments
The authors would like to specially thank Peilin Yang for his The authors would like to specially thank Peilin Yang for his
contributions to this document and detailed reviews. contributions to this document and detailed reviews.
The authors also thank the following individuals for their The authors also thank the following individuals for their
contributions, comments and suggestions to this document: Dave Oran, contributions, comments and suggestions to this document: Dave Oran,
Tony Faustini, Jeff Goldberg, Muriel Deschanel, Orit Levin, Roni Dan Wing, Tony Faustini, Jeff Goldberg, Muriel Deschanel, Orit Levin,
Even, Guy Hirson, Tom Taylor, Xavier Marjou, Ye-Kui Wang, Zixuan Zou, Roni Even, Guy Hirson, Tom Taylor, Xavier Marjou, Ye-Kui Wang, Zixuan
Ingemar Johansson, Haibin Song, Ning Zong, Jonathan Lennox and Sean Zou, Ingemar Johansson, Haibin Song, Ning Zong, Jonathan Lennox and
Sheedy. Sean Sheedy.
15. Change Log 16. Change Log
15.1. draft-versteeg-avt-rapid-synchronization-for-rtp-03 16.1. draft-ietf-avt-rapid-acquisition-for-rtp-01
The following are the major changes compared to version 00:
o Formal definitions of vendor-neutral and private extensions and
their IANA registries have been added.
o SDP examples were explained in more detail.
o The sub-FMT field has been introduced in the RAMS messages for
message type identification.
o Some terminology has been fixed.
o NAT considerations section has been added.
16.2. draft-ietf-avt-rapid-acquisition-for-rtp-00
This is a resubmission of version 03 as a WG item.
16.3. draft-versteeg-avt-rapid-synchronization-for-rtp-03
The following are the major changes compared to version 02: The following are the major changes compared to version 02:
o The title and message names have been changed. o The title and message names have been changed.
o RTCP message semantics have been added. RAMS protocol has been o RTCP message semantics have been added. RAMS protocol has been
revised to handle updated requests and responses. revised to handle updated requests and responses.
o Definitions have been revised. o Definitions have been revised.
o RTP/RTCP muxing reference has been added. o RTP/RTCP muxing reference has been added.
15.2. draft-versteeg-avt-rapid-synchronization-for-rtp-02 16.4. draft-versteeg-avt-rapid-synchronization-for-rtp-02
The following are the major changes compared to version 01: The following are the major changes compared to version 01:
o The discussion around MPEG2-TS has been moved to another document. o The discussion around MPEG2-TS has been moved to another document.
o The RAMS-R, RAMS-I and RAMS-T messages have been extensively o The RAMS-R, RAMS-I and RAMS-T messages have been extensively
modified and they have been made mandatory. modified and they have been made mandatory.
o IANA Considerations section has been updated. o IANA Considerations section has been updated.
o The discussion of RTCP XR report has been moved to another o The discussion of RTCP XR report has been moved to another
document. document.
o A new section on protocol design considerations has been added. o A new section on protocol design considerations has been added.
15.3. draft-versteeg-avt-rapid-synchronization-for-rtp-01 16.5. draft-versteeg-avt-rapid-synchronization-for-rtp-01
The following are the major changes compared to version 00: The following are the major changes compared to version 00:
o The core of the rapid synchronization method is now payload- o The core of the rapid synchronization method is now payload-
independent. But, the draft still defines payload-specific independent. But, the draft still defines payload-specific
messages that are required for enabling rapid synch for the RTP messages that are required for enabling rapid synch for the RTP
flows carrying MPEG2-TS. flows carrying MPEG2-TS.
o RTCP APP packets have been removed, new RTCP transport-layer and o RTCP APP packets have been removed, new RTCP transport-layer and
payload-specific feedback messages have been defined. payload-specific feedback messages have been defined.
o The step for leaving the current multicast session has been o The step for leaving the current multicast session has been
removed from Section 6.2. removed from Section 6.2.
o A new RTCP XR (Multicast Join) report has been defined. o A new RTCP XR (Multicast Join) report has been defined.
o IANA Considerations section have been updated. o IANA Considerations section have been updated.
o Editorial changes to clarify several points. o Editorial changes to clarify several points.
16. References 17. References
16.1. Normative References 17.1. Normative References
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, July 2003. Applications", STD 64, RFC 3550, July 2003.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A.
Thyagarajan, "Internet Group Management Protocol, Version Thyagarajan, "Internet Group Management Protocol, Version
skipping to change at page 36, line 18 skipping to change at page 39, line 46
(SDP)", draft-ietf-mmusic-sdp-source-attributes-02 (work (SDP)", draft-ietf-mmusic-sdp-source-attributes-02 (work
in progress), October 2008. in progress), October 2008.
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008. Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
with Session Description Protocol (SDP)", RFC 3264, with Session Description Protocol (SDP)", RFC 3264,
June 2002. June 2002.
16.2. Informative References [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008.
17.2. Informative References
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
August 1980. August 1980.
[I-D.ietf-rmt-pi-norm-revised] [I-D.ietf-rmt-pi-norm-revised]
Adamson, B., Bormann, C., London, U., and J. Macker, Adamson, B., Bormann, C., London, U., and J. Macker,
"NACK-Oriented Reliable Multicast Protocol", "NACK-Oriented Reliable Multicast Transport Protocol",
draft-ietf-rmt-pi-norm-revised-11 (work in progress), draft-ietf-rmt-pi-norm-revised-13 (work in progress),
April 2009. June 2009.
[I-D.begen-avt-rtp-mpeg2ts-preamble] [I-D.begen-avt-rtp-mpeg2ts-preamble]
Begen, A., "RTP Payload Format for MPEG2-TS Preamble", Begen, A., "RTP Payload Format for MPEG2-TS Preamble",
draft-begen-avt-rtp-mpeg2ts-preamble-00 (work in draft-begen-avt-rtp-mpeg2ts-preamble-00 (work in
progress), March 2009. progress), March 2009.
[I-D.begen-avt-rapid-sync-rtcp-xr] [I-D.begen-avt-rapid-sync-rtcp-xr]
Begen, A., "Rapid Multicast Synchronization Report Block Begen, A. and E. Friedrich, "Multicast Acquisition Report
Type for RTCP XR", draft-begen-avt-rapid-sync-rtcp-xr-00 Block Type for RTCP XR",
(work in progress), March 2009. draft-begen-avt-rapid-sync-rtcp-xr-01 (work in progress),
May 2009.
[I-D.ietf-avt-rtp-and-rtcp-mux] [I-D.ietf-avt-rtp-and-rtcp-mux]
Perkins, C. and M. Westerlund, "Multiplexing RTP Data and Perkins, C. and M. Westerlund, "Multiplexing RTP Data and
Control Packets on a Single Port", Control Packets on a Single Port",
draft-ietf-avt-rtp-and-rtcp-mux-07 (work in progress), draft-ietf-avt-rtp-and-rtcp-mux-07 (work in progress),
August 2007. August 2007.
[RFC4787] Audet, F. and C. Jennings, "Network Address Translation
(NAT) Behavioral Requirements for Unicast UDP", BCP 127,
RFC 4787, January 2007.
[RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,
"Session Traversal Utilities for NAT (STUN)", RFC 5389,
October 2008.
[UPnP-IGD]
Forum, UPnP., "Universal Plug and Play (UPnP) Internet
Gateway Device (IGD)", November 2001.
[DLNA] , DLNA., "http://www.dlna.org/home".
[CCNC09] Begen, A., Glazebrook, N., and W. VerSteeg, "A Unified [CCNC09] Begen, A., Glazebrook, N., and W. VerSteeg, "A Unified
Approach for Repairing Packet Loss and Accelerating Approach for Repairing Packet Loss and Accelerating
Channel Changes in Multicast IPTV (IEEE CCNC)", Channel Changes in Multicast IPTV (IEEE CCNC)",
January 2009. January 2009.
[IC2009] Begen, A., Glazebrook, N., and W. VerSteeg, "Reducing [IC2009] Begen, A., Glazebrook, N., and W. VerSteeg, "Reducing
Channel Change Times in IPTV with Real-Time Transport Channel Change Times in IPTV with Real-Time Transport
Protocol (IEEE Internet Computing)", May 2009. Protocol (IEEE Internet Computing)", May 2009.
Authors' Addresses Authors' Addresses
 End of changes. 103 change blocks. 
334 lines changed or deleted 537 lines changed or added

This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/