draft-ietf-mmusic-sdp-bwparam-02.txt   draft-ietf-mmusic-sdp-bwparam-03.txt 
Network Working Group Magnus Westerlund Network Working Group Magnus Westerlund
INTERNET-DRAFT Ericsson INTERNET-DRAFT Ericsson
Category: Standards Track May 15, 2003 Category: Standards Track May 27, 2003
Expires: November 2003 Expires: November 2003
A Transport Independent Bandwidth Modifier for the Session A Transport Independent Bandwidth Modifier for the Session
Description Protocol (SDP). Description Protocol (SDP).
<draft-ietf-mmusic-sdp-bwparam-02.txt> <draft-ietf-mmusic-sdp-bwparam-03.txt>
Status of this memo Status of this memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts. groups may also distribute working documents as Internet-Drafts.
skipping to change at page 1, line 43 skipping to change at page 1, line 43
should be directed to the authors. should be directed to the authors.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved. Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract Abstract
The existing Session Description Protocol (SDP) bandwidth modifiers The existing Session Description Protocol (SDP) bandwidth modifiers
and their values include the bandwidth needed also for the transport and their values include the bandwidth needed also for the transport
and IP layers. When using SDP in protocols like Session Announcement and IP layers. When using SDP with protocols like the Session
Protocol (SAP), Session Initiation Protocol (SIP) and Real-Time Announcement Protocol (SAP), the Session Initiation Protocol (SIP)
Streaming Protocol (RTSP) and the involved hosts reside in networks and the Real-Time Streaming Protocol (RTSP) and when the involved
running different IP versions, the interpretation of what lower layer hosts reside in networks running different IP versions, the
bandwidths are included is not clear. This documents defines a interpretation of what lower layer bandwidths are included is not
bandwidth modifier that does not include transport overhead; instead clear. This document defines a bandwidth modifier that does not
an additional packet rate attribute is defined. The transport include transport overhead; instead an additional packet rate
independent bit-rate value together with the maximum packet rate can attribute is defined. The transport independent bit-rate value
then be used to calculate the real bit-rate over the transport together with the maximum packet rate can then be used to calculate
actually used. the real bit-rate over the transport actually used.
TABLE OF CONTENTS TABLE OF CONTENTS
1. Definitions.........................................................3 1. Definitions.........................................................3
1.1. Glossary.......................................................3 1.1. Glossary.......................................................3
1.2. Terminology....................................................3 1.2. Terminology....................................................3
2. Introduction........................................................3 2. Introduction........................................................3
2.1. The Bandwidth Attribute........................................3 2.1. The Bandwidth Attribute........................................3
2.1.1. Conference Total..........................................3 2.1.1. Conference Total..........................................3
2.1.2. Application Specific Maximum..............................3 2.1.2. Application Specific Maximum..............................3
skipping to change at page 4, line 4 skipping to change at page 4, line 4
The Conference Total is indicated by giving the modifier "CT". The The Conference Total is indicated by giving the modifier "CT". The
meaning of Conference total is to give a maximum bandwidth that a meaning of Conference total is to give a maximum bandwidth that a
conference session will use. Its purpose is to decide if this session conference session will use. Its purpose is to decide if this session
can co-exist with any other sessions. Defined in RFC 2327 [1]. can co-exist with any other sessions. Defined in RFC 2327 [1].
2.1.2. Application Specific Maximum 2.1.2. Application Specific Maximum
The Application Specific maximum bandwidth is indicated by the The Application Specific maximum bandwidth is indicated by the
modifier "AS". The interpretation of this attribute is dependent on modifier "AS". The interpretation of this attribute is dependent on
the application's notion of maximum bandwidth. For an RTP application the application's notion of maximum bandwidth. For an RTP application
this attribute is the RTP session bandwidth as defined in RFC 1889 this attribute is the RTP session bandwidth as defined in RFC XXXX
[4]. The session bandwidth includes the bandwidth that the RTP data [4]. The session bandwidth includes the bandwidth that the RTP data
traffic will consume, including the lower layers down to IP layer. traffic will consume, including the lower layers down to IP layer.
Therefore, the bandwidth is in most cases calculated over RTP Therefore, the bandwidth is in most cases calculated over RTP
payload, RTP header, UDP and IP. Defined in RFC 2327 [1]. payload, RTP header, UDP and IP. Defined in RFC 2327 [1].
2.1.3. RTCP Report bandwidth 2.1.3. RTCP Report bandwidth
In RFC YYYY [9], which defines two new bandwidth modifiers are In RFC YYYY [9], two bandwidth modifiers are defined. These
defined. These modifiers, "RS" and "RR", define the amount of modifiers, "RS" and "RR", define the amount of bandwidth that is
bandwidth that is assigned for RTCP reports by active data senders assigned for RTCP reports by active data senders and RTCP reports by
and RTCP reports by other participants (receivers), respectively. other participants (receivers), respectively.
2.2. IPv6 and IPv4 2.2. IPv6 and IPv4
Today there are two IP versions 4 [15] and 6 [14] used in parallel on Today there are two IP versions 4 [15] and 6 [14] used in parallel on
the Internet. This creates problems and there exist a number of the Internet. This creates problems and there exist a number of
possible transition mechanisms. possible transition mechanisms.
------------------ ---------------------- ------------------ ----------------------
| IPv4 domain | | IPv6 Domain | | IPv4 domain | | IPv6 Domain |
| | ---------| | | | | ---------| | |
skipping to change at page 8, line 11 skipping to change at page 8, line 11
have a different header size than UDP, which is the protocol most have a different header size than UDP, which is the protocol most
often used for real-time media today. This results in even more often used for real-time media today. This results in even more
possible transport combinations to calculate overhead for. possible transport combinations to calculate overhead for.
4. Problem Scope 4. Problem Scope
The problems described in chapter 3 are common and effect application The problems described in chapter 3 are common and effect application
level signaling using SDP, other signaling protocols, and also level signaling using SDP, other signaling protocols, and also
resource reservation protocols. However this document targets the resource reservation protocols. However this document targets the
specific problem of signaling the bit-rate in SDP. The problems need specific problem of signaling the bit-rate in SDP. The problems need
to further considered in other effected protocols and in new to be considered in other affected protocols and in new protocols
protocols being designed. In the MMUSIC WG there is work on a being designed. In the MMUSIC WG there is work on a replacement of
replacement of SDP called SDP-NG. It is recommended that the problems SDP called SDP-NG. It is recommended that the problems outlined in
outlined in this document be considered when designing solutions for this document be considered when designing solutions for specifying
specifying bandwidth in SDP-NG. bandwidth in SDP-NG [18].
As this specification only targets carrying the bit-rate information As this specification only targets carrying the bit-rate information
within SDP it will have a limited applicability. As SDP information within SDP it will have a limited applicability. As SDP information
normally is transported end-to-end by an application protocol, nodes normally is transported end-to-end by an application protocol, nodes
between the end-points will not have access to the bit-rate between the end-points will not have access to the bit-rate
information. It will normally only be the end points that are able to information. It will normally only be the end points that are able to
take this information into account. An interior node will need to take this information into account. An interior node will need to
receive the information through other means than SDP, and that is receive the information through other means than SDP, and that is
outside the scope of this specification. outside the scope of this specification.
skipping to change at page 10, line 45 skipping to change at page 10, line 45
not implement "TIAS", it is RECOMMENDED to also include the "AS" not implement "TIAS", it is RECOMMENDED to also include the "AS"
modifier when using "TIAS". The presence of a value including lower- modifier when using "TIAS". The presence of a value including lower-
layer overhead, even with its problems, is better than none. However, layer overhead, even with its problems, is better than none. However,
an SDP application implementing TIAS SHOULD ignore the "AS" value and an SDP application implementing TIAS SHOULD ignore the "AS" value and
use "TIAS" instead when both are present. use "TIAS" instead when both are present.
When using TIAS for an RTP-transported stream, the "maxprate" When using TIAS for an RTP-transported stream, the "maxprate"
attribute, defined next, SHALL be included at the corresponding SDP attribute, defined next, SHALL be included at the corresponding SDP
level. level.
6.3. Packet Rate parameters 6.3. Packet Rate parameter
To be able to calculate the bandwidth value including the lower To be able to calculate the bandwidth value including the lower
layers actually used, a packet rate attribute is also defined. layers actually used, a packet rate attribute is also defined.
The SDP session and media level maximum packet rate attribute is The SDP session and media level maximum packet rate attribute is
defined as: defined as:
a=maxprate:<packet-rate> ; see section 6.6 for ABNF definition. a=maxprate:<packet-rate> ; see section 6.6 for ABNF definition.
The <packet-rate> is a floating-point value for the stream's maximum The <packet-rate> is a floating-point value for the stream's maximum
skipping to change at page 15, line 45 skipping to change at page 15, line 45
[11] S. Casner, V. Jacobson, "Compressing IP/UDP/RTP Headers for Low- [11] S. Casner, V. Jacobson, "Compressing IP/UDP/RTP Headers for Low-
Speed Serial Links", IETF RFC 2508, February 1999. Speed Serial Links", IETF RFC 2508, February 1999.
[12] C. Bormann, et. al., "RObust Header Compression (ROHC): [12] C. Bormann, et. al., "RObust Header Compression (ROHC):
Framework and four profiles", IETF RFC 3095, July 2001. Framework and four profiles", IETF RFC 3095, July 2001.
[13] Tsirtsis, G. and Srisuresh, P., "Network Address Translation - [13] Tsirtsis, G. and Srisuresh, P., "Network Address Translation -
Protocol Translation (NAT-PT)", RFC 2766, Internet Engineering Protocol Translation (NAT-PT)", RFC 2766, Internet Engineering
Task Force, February 2000. Task Force, February 2000.
[14] S. Deering and R. Hinden, "Internet Protocol, Version 6 (IPv6) [14] S. Deering and R. Hinden, "Internet Protocol, Version 6 (IPv6)
Specification", RFC 2460, Internet Engineering Task Force, Specification", RFC 2460, Internet Engineering Task Force,
December 1998. December 1998.
[15] J. Postel, "internet protocol", RFC 791, Internet Engineering [15] J. Postel, "Internet Protocol", RFC 791, Internet Engineering
Task Force, September 1981. Task Force, September 1981.
[16] Braden, R., Zhang, L., Berson, S., Herzog, S. and S. Jamin, [16] Braden, R., Zhang, L., Berson, S., Herzog, S. and S. Jamin,
"Resource ReSerVation Protocol (RSVP) -- Version 1 Functional "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional
Specification", RFC 2205, September 1997. Specification", RFC 2205, September 1997.
[17] Davie, B., et. al., "Integrated Services in the Presence of [17] Davie, B., et. al., "Integrated Services in the Presence of
Compressible Flows," RFC 3006, Internet Engineering Task Force, Compressible Flows," RFC 3006, Internet Engineering Task Force,
November 2000. November 2000.
[18] Kutscher, Ott, Bormann, "Session Description and Capability
Negotiation," IETF draft, work in progress, march 2003.
13. IPR Notice 13. IPR Notice
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and IETF's procedures with respect to rights in standards-track and
skipping to change at page 17, line 10 skipping to change at page 17, line 10
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE
OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY
IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A
PARTICULAR PURPOSE. PARTICULAR PURPOSE.
Changes Changes
[Note to RFC Editor: Remove this section when publishing] [Note to RFC Editor: Remove this section when publishing]
The following changes have been done to this version compared to The following changes have been done to this version compared to
draft-ietf-mmusic-sdp-bwparam-010.txt: draft-ietf-mmusic-sdp-bwparam-01.txt:
- Improved language in the whole draft - Improved language in the whole draft
- Updated the problem scope section (4) to clarify what part of the - Updated the problem scope section (4) to clarify what part of the
whole problem space that this specification provides solution to. whole problem space that this specification provides solution to.
- Clarified that the tunneling problem example may not be applicable - Clarified that the tunneling problem example may not be applicable
for the TIAS parameters (Section 2.2). for the TIAS parameters (Section 2.2).
- Included text about RFC 3006, which provides hints in RSVP that - Included text about RFC 3006, which provides hints in RSVP that
header compression is possible. header compression is possible.
- Removed an inconsistency in the normative language regarding the - Removed an inconsistency in the normative language regarding the
usage of "maxprate" attribute. It shall always be present when usage of "maxprate" attribute. It shall always be present when
TIAS is used. TIAS is used.
The following changes have been done to this version compared to
draft-ietf-mmusic-sdp-bwparam-02.txt
- Updated language in abstract.
- Replaced a reference to RFC 1889 with RFC XXXX.
- Added a SDP-NG informative reference.
- Corrected two language errors in Section 4.
- Fixed reference [15].
RFC-Editor Considerations RFC-Editor Considerations
Please remove this and the previous section before publishing. Please remove this and the previous section before publishing.
Please update reference [4] (draft-ietf-avt-rtp-new-12.txt) with the Please update reference [4] (draft-ietf-avt-rtp-new-12.txt) with the
correct publication date and RFC number when they are available. correct publication date and RFC number when they are available.
Please remove the parenthesis pointing out the draft file. Please remove the parenthesis pointing out the draft file. Please
update all occurrences of XXXX with the RFC number that [4] receive.
Please replace any occurrences of YYYY with the RFC number that is Please replace any occurrences of YYYY with the RFC number that is
given to the draft in reference [9] when published. Please update given to the draft in reference [9] when published. Please update
reference [9] with the correct date of publication and remove the reference [9] with the correct date of publication and remove the
parenthesis pointing out the draft. parenthesis pointing out the draft.
This Internet-Draft expires in November 2003. This Internet-Draft expires in November 2003.
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/