draft-ietf-avt-rapid-acquisition-for-rtp-02.txt   draft-ietf-avt-rapid-acquisition-for-rtp-03.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: February 26, 2010 T. VanCaenegem Expires: March 8, 2010 T. VanCaenegem
Alcatel-Lucent Alcatel-Lucent
Z. Vax Z. Vax
Microsoft Corporation Microsoft Corporation
August 25, 2009 September 4, 2009
Unicast-Based Rapid Acquisition of Multicast RTP Sessions Unicast-Based Rapid Acquisition of Multicast RTP Sessions
draft-ietf-avt-rapid-acquisition-for-rtp-02 draft-ietf-avt-rapid-acquisition-for-rtp-03
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 February 26, 2010. This Internet-Draft will expire on March 8, 2010.
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 42 skipping to change at page 3, line 42
11. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 35 11. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 35
12. Security Considerations . . . . . . . . . . . . . . . . . . . 35 12. Security Considerations . . . . . . . . . . . . . . . . . . . 35
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37
13.1. Registration of SDP Attributes . . . . . . . . . . . . . . 37 13.1. Registration of SDP Attributes . . . . . . . . . . . . . . 37
13.2. Registration of SDP Attribute Values . . . . . . . . . . . 37 13.2. Registration of SDP Attribute Values . . . . . . . . . . . 37
13.3. Registration of FMT Values . . . . . . . . . . . . . . . . 37 13.3. Registration of FMT Values . . . . . . . . . . . . . . . . 37
13.4. SFMT Values for RAMS Messages Registry . . . . . . . . . . 38 13.4. SFMT Values for RAMS Messages Registry . . . . . . . . . . 38
13.5. RAMS TLV Space Registry . . . . . . . . . . . . . . . . . 38 13.5. RAMS TLV Space Registry . . . . . . . . . . . . . . . . . 38
14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 39 14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 39
15. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 39 15. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 39
15.1. draft-ietf-avt-rapid-acquisition-for-rtp-02 . . . . . . . 39 15.1. draft-ietf-avt-rapid-acquisition-for-rtp-03 . . . . . . . 40
15.2. draft-ietf-avt-rapid-acquisition-for-rtp-01 . . . . . . . 40 15.2. draft-ietf-avt-rapid-acquisition-for-rtp-02 . . . . . . . 40
15.3. draft-ietf-avt-rapid-acquisition-for-rtp-00 . . . . . . . 40 15.3. draft-ietf-avt-rapid-acquisition-for-rtp-01 . . . . . . . 40
15.4. draft-versteeg-avt-rapid-synchronization-for-rtp-03 . . . 40 15.4. draft-ietf-avt-rapid-acquisition-for-rtp-00 . . . . . . . 40
15.5. draft-versteeg-avt-rapid-synchronization-for-rtp-02 . . . 40 15.5. draft-versteeg-avt-rapid-synchronization-for-rtp-03 . . . 40
15.6. draft-versteeg-avt-rapid-synchronization-for-rtp-01 . . . 41 15.6. draft-versteeg-avt-rapid-synchronization-for-rtp-02 . . . 41
16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 41 15.7. draft-versteeg-avt-rapid-synchronization-for-rtp-01 . . . 41
16.1. Normative References . . . . . . . . . . . . . . . . . . . 41 16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 42
16.1. Normative References . . . . . . . . . . . . . . . . . . . 42
16.2. Informative References . . . . . . . . . . . . . . . . . . 43 16.2. Informative References . . . . . . . . . . . . . . . . . . 43
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 44 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 44
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
skipping to change at page 17, line 11 skipping to change at page 17, line 11
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 towards its upstream multicast router for the new Join message towards its upstream multicast router for the new
primary 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). A particularly important, thus mandatory, field in the burst). A particularly important field in the RAMS-I message
RAMS-I message carries the RTP sequence number of the first burst carries the RTP sequence number of the first packet transmitted
packet. in the retransmission session to allow RR to detect any missing
initial packet(s). Note that the first RTP packet transmitted in
the retransmission session is not necessarily a burst packet. It
could be a payload-specific RTP packet (See
[I-D.begen-avt-rtp-mpeg2ts-preamble] for an example). When RS
accepts the request, this field MUST be populated in the RAMS-I
message and it is RECOMMENDED that the RAMS-I message is sent
early enough in the session to be useful. If RS rejects the
request, this field SHALL NOT exist in the RAMS-I message.
It is RECOMMENDED to include a sender report with the RAMS-I It is RECOMMENDED to include a sender report with the RAMS-I
message in the same compound RTCP packet. This also allows rapid message in the same compound RTCP packet. This allows rapid
synchronization among multiple RTP flows synchronization among multiple RTP flows
[I-D.ietf-avt-rapid-rtp-sync]. [I-D.ietf-avt-rapid-rtp-sync].
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) SHOULD be populated information (for the new multicast session) SHOULD be populated
in at least one of the RAMS-I messages. Note that RS MAY send in at least one of the RAMS-I messages. Note that RS MAY send
the RAMS-I message after a significant delay, so RR SHOULD NOT the RAMS-I message after a significant delay, so RR SHOULD NOT
make protocol dependencies on quickly receiving an RAMS-I make protocol dependencies on quickly receiving an RAMS-I
message. message.
skipping to change at page 26, line 13 skipping to change at page 26, line 20
buffering requirement of the receiver, it may tailor the burst buffering requirement of the receiver, it may tailor the burst
more precisely, e.g., by choosing an appropriate starting point. more precisely, e.g., by choosing an appropriate starting point.
The methods used by RR to determine this value are application The methods used by RR to determine this value are application
specific, and thus, out of the scope of this document. specific, and thus, out of the scope of this document.
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 the specified value since unicast burst SHOULD NOT be smaller than the specified value since
it will not be able to build up the desired level of buffer at RR it will not be able to build up the desired level of buffer at RR
and may cause buffer underruns. and may cause buffer underruns.
Type: TBD Type: 1
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 milliseconds of data that RR can buffer that denotes the maximum milliseconds of data that RR can buffer
without losing the burst data due to buffer overflow. without losing the burst data due to buffer overflow.
RR may have knowledge of its buffering requirements. These RR may have knowledge of its buffering requirements. These
requirements may be application or device specific. For instance, requirements may be application or device specific. For instance,
one particular RR may have more physical memory than another RR, one particular RR may have more physical memory than another RR,
and thus, can buffer more data. If RS knows the buffering ability and thus, can buffer more data. If RS knows the buffering ability
of the receiver, it may tailor the burst more precisely. The of the receiver, it may tailor the burst more precisely. The
methods used by the receiver to determine this value are methods used by the receiver to determine this value are
application specific, and thus, out of scope. 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 Type: 2
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 Type: 3
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.3. RAMS Information 7.3. RAMS Information
The RAMS Information message is identified by SFMT=2. 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.
skipping to change at page 27, line 24 skipping to change at page 27, line 24
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 7. 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SFMT=2 | MSN | Response | | SFMT=2 | MSN | Response |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|RTP SN of the First Burst Pkt. | Optional TLV-encoded Fields |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Optional TLV-encoded Fields (and Padding, if needed) : : Optional TLV-encoded Fields (and Padding, if needed) :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: 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.
o Response (16 bits): Mandatory field that denotes the RS response o Response (16 bits): Mandatory field that denotes the RS response
code for this RAMS-I message. code for this RAMS-I message.
Editor's note: HTTP/SIP-like response codes will be defined and Editor's note: HTTP/SIP-like response codes will be defined and
registered with IANA in a later version. registered with IANA in a later version.
o RTP SN of the First Burst Pkt. (16 bits): Mandatory field that o RTP Seqnum of the First Packet (16 bits): TLV element that
specifies the RTP sequence number of the first packet that will be specifies the RTP sequence number of the first packet that will be
sent as part of the burst. This allows RR to know if one or more sent in the retransmission session. This allows RR to know
packets have been dropped at the beginning of the burst. whether one or more packets sent by RS have been dropped at the
beginning of the retransmission session. If RS accepts the RAMS
request, this element MUST exist. If RS rejects the RAMS request,
this element SHALL NOT exist.
Type: 31
o Earliest Multicast Join Time (32 bits): Optional TLV element that o Earliest Multicast Join Time (32 bits): Optional TLV element that
specifies the time difference (i.e., delta time) between the specifies the time difference (i.e., delta time) between the
arrival of this RAMS-I message and the earliest time instant when arrival of this RAMS-I message and the earliest time instant when
RR could join the primary multicast session in RTP ticks. A zero RR could join the primary multicast session in RTP ticks. A zero
value in this field means that RR can join the primary multicast value in this field means that RR can join the primary multicast
session right away. session right away.
Note that if the RAMS request has been accepted, RS SHOULD send Note that if the RAMS request has been accepted, RS SHOULD send
this field at least once, so that RR knows when to join the this field at least once, so that RR knows when to join the
primary multicast session. If the burst request has been rejected primary multicast session. If the burst request has been rejected
as indicated in the Response field, this field MAY be omitted or as 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 set to 0. In that case, it is up to RR when or whether to join
the primary multicast session. the primary multicast session.
Type: TBD Type: 32
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 Type: 33
Length: TBD
o Max Burst Bitrate (32 bits): Optional TLV element that denotes
the maximum bitrate (in bits per second) that will be used by RS
for the unicast burst.
Type: TBD o Max Transmit Bitrate (32 bits): Optional TLV element that denotes
the maximum bitrate (in bits per second) that will be used by RS.
Length: TBD Type: 34
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.4. RAMS Termination 7.4. RAMS Termination
skipping to change at page 29, line 46 skipping to change at page 29, line 44
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: 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.
Type: TBD Type: 61
Length: TBD
The semantics of the RAMS-T feedback message is independent of the The semantics of the RAMS-T feedback message is independent of the
payload type. 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
skipping to change at page 34, line 37 skipping to change at page 34, line 37
updated text for this section will be provided in a later version. updated text for this section will be provided in a later version.
10. Known Implementations 10. Known Implementations
10.1. Open Source RTP Receiver Implementation by Cisco 10.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_3/user/guide/ http://www.cisco.com/en/US/docs/video/cds/cda/vqe/3_4/user/guide/
ch1_over.html vqe_guide3_4.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]
skipping to change at page 35, line 23 skipping to change at page 35, line 23
http://informitv.com/articles/2008/10/13/channelchangetimes/ http://informitv.com/articles/2008/10/13/channelchangetimes/
11. Open Issues 11. Open Issues
o Discussion of acquisition for the individual RTP streams vs. the o Discussion of acquisition for the individual RTP streams vs. the
whole RTP session. whole RTP session.
o Updating the NAT section. o Updating the NAT section.
o Completing the TLV types, lengths, etc.
o Response/status codes for RAMS. o Response/status codes for RAMS.
12. Security Considerations 12. Security Considerations
Applications that are using RAMS make heavy use of the unicast Applications that are using RAMS make heavy use of the unicast
feedback mechanism described in [I-D.ietf-avt-rtcpssm] and the feedback mechanism described in [I-D.ietf-avt-rtcpssm] and the
payload format defined in [RFC4588]. Thus, these applications are payload format defined in [RFC4588]. Thus, these applications are
subject to the general security considerations discussed in subject to the general security considerations discussed in
[I-D.ietf-avt-rtcpssm] and [RFC4588]. In this section, we give an [I-D.ietf-avt-rtcpssm] and [RFC4588]. In this section, we give an
overview of the guidelines and suggestions described in these overview of the guidelines and suggestions described in these
skipping to change at page 37, line 18 skipping to change at page 37, line 16
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
Note to the RFC Editor: In the following, please replace "XXXX" with
the number of this document prior to publication as an RFC.
13.1. Registration of SDP Attributes 13.1. Registration of SDP Attributes
This document registers a new attribute name in SDP. This document registers a new attribute name in SDP.
SDP Attribute ("att-field"): SDP Attribute ("att-field"):
Attribute name: rams-updates Attribute name: rams-updates
Long form: Support for Updated RAMS Request Messages Long form: Support for Updated RAMS Request Messages
Type of name: att-field Type of name: att-field
Type of attribute: Media level Type of attribute: Media level
Subject to charset: No Subject to charset: No
Purpose: See this document Purpose: See this document
Reference: This document Reference: [RFCXXXX]
Values: None Values: None
13.2. Registration of SDP Attribute Values 13.2. 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: [RFCXXXX]
13.3. Registration of FMT Values 13.3. Registration of FMT Values
Within the RTPFB range, the following format (FMT) value is Within the RTPFB range, the following format (FMT) value is
registered: registered:
Name: RAMS Name: RAMS
Long name: Rapid Acquisition of Multicast Sessions Long name: Rapid Acquisition of Multicast Sessions
Value: 6 Value: 6
Reference: This document Reference: [RFCXXXX]
13.4. SFMT Values for RAMS Messages Registry 13.4. SFMT Values for RAMS Messages Registry
This document creates a new sub-registry for the sub-feedback message This document creates a new sub-registry for the sub-feedback message
type (SFMT) values to be used with the FMT value registered for RAMS type (SFMT) values to be used with the FMT value registered for RAMS
messages. The registry is called the SFMT Values for RAMS Messages messages. The registry is called the SFMT Values for RAMS Messages
Registry. This registry is to be managed by the IANA according to Registry. This registry is to be managed by the IANA according to
the Specification Required policy of [RFC5226]. the Specification Required policy of [RFC5226].
The length of the SFMT field in the RAMS messages is a single octet, The length of the SFMT field in the RAMS messages is a single octet,
allowing 256 values. The registry is initialized with the following allowing 256 values. The registry is initialized with the following
entries: entries:
Value Name Reference Value Name Reference
----- -------------------------------------------------- ------------- ----- -------------------------------------------------- -------------
1 RAMS Request This document 1 RAMS Request [RFCXXXX]
2 RAMS Information This document 2 RAMS Information [RFCXXXX]
3 RAMS Termination This document 3 RAMS Termination [RFCXXXX]
The SFMT values 0 and 255 are reserved for future use. The SFMT values 0 and 255 are reserved for future use.
Any registration for an unassigned SFMT value MUST contain the Any registration for an unassigned SFMT value MUST contain the
following information: following information:
o Contact information of the one doing the registration, including o Contact information of the one doing the registration, including
at least name, address, and email. at least name, address, and email.
o A detailed description of what the new SFMT represents and how it o A detailed description of what the new SFMT represents and how it
skipping to change at page 39, line 4 skipping to change at page 39, line 4
introducing new message types unless it is absolutely necessary. introducing new message types unless it is absolutely necessary.
13.5. RAMS TLV Space Registry 13.5. RAMS TLV Space Registry
This document creates a new IANA TLV space registry for the RAMS This document creates a new IANA TLV space registry for the RAMS
extensions. The registry is called the RAMS TLV Space Registry. extensions. The registry is called the RAMS TLV Space Registry.
This registry is to be managed by the IANA according to the This registry is to be managed by the IANA according to the
Specification Required policy of [RFC5226]. Specification Required policy of [RFC5226].
The length of the Type field in the TLV elements is a single octet, The length of the Type field in the TLV elements is a single octet,
allowing 256 values. The registry is initialized with the following allowing 256 values. The Type values 0 and 255 are reserved for
entries: future use. The Type values between (and including) 128 and 254 are
reserved for private extensions.
The registry is initialized with the following entries:
Type Description Reference Type Description Reference
---- -------------------------------------------------- ------------- ---- -------------------------------------------------- -------------
TBD TBD This document 1 Min RAMS Buffer Fill Requirement [RFCXXXX]
... ... 2 Max RAMS Buffer Fill Requirement [RFCXXXX]
3 Max Receive Bitrate [RFCXXXX]
The registry entries are TBC. 31 RTP Seqnum of the First Packet [RFCXXXX]
32 Earliest Multicast Join Time [RFCXXXX]
The TYPE values 0 and 255 are reserved for future use. The TYPE 33 Burst Duration [RFCXXXX]
values between (and including) 128 and 254 are reserved for private 34 Max Transmit Bitrate [RFCXXXX]
extensions. 61 Extended RTP Seqnum of First Multicast Packet [RFCXXXX]
Any registration for an unassigned TYPE value MUST contain the Any registration for an unassigned Type value MUST contain the
following information: following information:
o Contact information of the one doing the registration, including o Contact information of the one doing the registration, including
at least name, address, and email. at least name, address, and email.
o A detailed description of what the new TLV element represents and o A detailed description of what the new TLV element represents and
how it shall be interpreted. how it shall be interpreted.
14. Acknowledgments 14. Acknowledgments
skipping to change at page 39, line 41 skipping to change at page 40, line 5
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,
Dan Wing, Tony Faustini, Jeff Goldberg, Muriel Deschanel, Orit Levin, Dan Wing, Tony Faustini, Jeff Goldberg, Muriel Deschanel, Orit Levin,
Roni Even, Guy Hirson, Tom Taylor, Xavier Marjou, Ye-Kui Wang, Zixuan Roni Even, Guy Hirson, Tom Taylor, Xavier Marjou, Ye-Kui Wang, Zixuan
Zou, Ingemar Johansson, Haibin Song, Ning Zong, Jonathan Lennox and Zou, Ingemar Johansson, Haibin Song, Ning Zong, Jonathan Lennox and
Sean Sheedy. Sean Sheedy.
15. Change Log 15. Change Log
15.1. draft-ietf-avt-rapid-acquisition-for-rtp-02 15.1. draft-ietf-avt-rapid-acquisition-for-rtp-03
The following are the major changes compared to version 02:
o Clarifications for the RAMS-I message.
o Type values have been assigned.
15.2. draft-ietf-avt-rapid-acquisition-for-rtp-02
The following are the major changes compared to version 01: The following are the major changes compared to version 01:
o Port mapping discussion has been removed since it will be o Port mapping discussion has been removed since it will be
discussed in a separate draft. discussed in a separate draft.
o Security considerations section has been added. o Security considerations section has been added.
o Burst shaping section has been completed. o Burst shaping section has been completed.
o Most of the outstanding open issues have been addressed. o Most of the outstanding open issues have been addressed.
15.2. draft-ietf-avt-rapid-acquisition-for-rtp-01 15.3. draft-ietf-avt-rapid-acquisition-for-rtp-01
The following are the major changes compared to version 00: The following are the major changes compared to version 00:
o Formal definitions of vendor-neutral and private extensions and o Formal definitions of vendor-neutral and private extensions and
their IANA registries have been added. their IANA registries have been added.
o SDP examples were explained in more detail. o SDP examples were explained in more detail.
o The sub-FMT field has been introduced in the RAMS messages for o The sub-FMT field has been introduced in the RAMS messages for
message type identification. message type identification.
o Some terminology has been fixed. o Some terminology has been fixed.
o NAT considerations section has been added. o NAT considerations section has been added.
15.3. draft-ietf-avt-rapid-acquisition-for-rtp-00 15.4. draft-ietf-avt-rapid-acquisition-for-rtp-00
This is a resubmission of version 03 as a WG item. This is a resubmission of version 03 as a WG item.
15.4. draft-versteeg-avt-rapid-synchronization-for-rtp-03 15.5. 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.5. draft-versteeg-avt-rapid-synchronization-for-rtp-02 15.6. 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.6. draft-versteeg-avt-rapid-synchronization-for-rtp-01 15.7. 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.
 End of changes. 34 change blocks. 
72 lines changed or deleted 81 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/