Internet DRAFT - draft-guenkova-mmusic-sdp-ng-streamtrack
draft-guenkova-mmusic-sdp-ng-streamtrack
IETF MMUSIC WG T. Guenkova-Luy
Internet-Draft A. Schorr
Expires: August 10, 2005 F. Hauck
University of Ulm
I. Wolf
B. Feiten
T-Systems
International
M. Gomez
F. Galan
Agora Systems
Telma Mota
Portugal Telecom
Inovacao
Willem Romijn
Lucent Technologies
February 10, 2005
Stream Tracking Description for Resource Management Guarantees in
the Network
draft-guenkova-mmusic-sdp-ng-streamtrack-00
Status of this Memo
By submitting this Internet-Draft, the authors certify that any
applicable patent or other IPR claims of which the authors are aware
have been disclosed, or will be disclosed, and any of which the
authors become aware will be disclosed, in accordance with RFC 3668.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Guenkova, et al. Expires August 10, 2005 [Page 1]
Internet-Draft Stream Tracking Description February 2005
This Internet-Draft will expire on August 10, 2005.
Abstract
This document defines an extension to the Session Description
Protocol (SDP) and to Session Description Protocol new generation
(SDPng - work in progress). The intention of this draft is to provide
descriptions in SDP and SDPng that specify the source port of media
streams. Such specification within the session description is
required in many network quality of service (QoS) management systems
in order to be able to track the media streams from their source to
their destination. Thus the QoS management system can differentiate
the stream tracks end-to-end and guarantee QoS for every single
media.
Table of Contents
1. Introduction..........................................2
2. Motivation............................................3
3. RTP traffic tracking descriptions in SDP and SDPng....6
3.1. SDP enhancement of the "m=" line......................6
3.2. SDPng enhancement of the <rtp:ip-addr> component of the RTP
package.....................................................7
4. IANA Considerations...................................9
5. Security considerations..............................10
References.................................................10
Authors' Addresses.........................................11
Acknowledgements...........................................13
Copyright Notice...........................................13
Liability notice...........................................13
1. Introduction
The intention of this draft is to provide descriptions in SDP [1] and
SDPng [2] that specify the source port of media streams. Such
specification within the session description is required in many
network quality of service (QoS) management systems in order to be
able to track the media streams from their source to their
destination, especially in cases where it is necessary to distinguish
between several different network flows which are all sent from the
same source IP address to the same destination. Thus the QoS
management system can differentiate the stream tracks end-to-end and
guarantee QoS for every single media. Additionally, this draft can be
considered an extension to RFC 3312 [3]. RFC 3312 also treats
resource reservation issues, but it addresses predominantly the
problem of resource reservation coordination using the Session
Initiation Protocol (SIP) [4]. The problem of indicating and
distinguishing the network flows of the multimedia end-to-end in
order to guarantee their reservation is not treated in RFC 3312.
Guenkova, et al. Expires August 10, 2005 [Page 2]
Internet-Draft Stream Tracking Description February 2005
In this draft we consider first the multimedia management
architectures that serve as motivation for the proposed SDP and SDPng
enhancements. We discuss the structure of the enhancements and give
corresponding examples. The draft is concluded with security
considerations about the usage of the proposed enhancements.
2. Motivation
Most of the Next Generation Network specifications have a similar
architecture to the one proposed by the 3GPP UMTS IP Multimedia
Subsystem (IMS) [5] and include a dedicated platform for delivering
of Multimedia Services over the underlying Packet-Switched network.
Such multimedia provisioning platforms usually comprise the following
elements:
o A control plane based on signalling proxy entities, usually SIP-
based [4].
o A native service-provisioning platform, implemented over a set of
Application Servers based on the native signalling protocol(s)
supported by the platform.
o A set of media-processing elements, for the provisioning of
advanced multimedia services.
o A set of interconnection elements, belonging to both the signalling
and the media-processing level that enable the access to foreign
services, service domains or legacy systems.
The multimedia-services control plane can be decomposed into three
main logical control functions:
o Access proxy function (e.g. P-CSCF in IMS networks): This is the
entry point for subscribers to the multimedia-provisioning
platform.
o Query proxy function (e.g. I-CSCF in IMS networks): This entity
allows locating the service control function that handles a
particular user. This proxy behaves also as an entry point in the
home network for external Foreign Service domains.
o Serving proxy function (e.g. S-CSCF in IMS networks): This is the
entity that serves the users in the home network. It performs
service-level control and authorization.
The "access proxy function" is the entity in charge of ensuring QoS
for the negotiated multimedia sessions. In order to accomplish this
task, it contacts the QoS brokerage entities in the access network to
reserve the required resources for the requested multimedia streams.
This interaction is usually performed using a policy control protocol
Guenkova, et al. Expires August 10, 2005 [Page 3]
Internet-Draft Stream Tracking Description February 2005
like COPS [6].
QoS Control elements may be classified according to two main
categories: brokerage and enforcement elements. QoS Brokers (Policy
Decision Points or PDPs, in COPS terminology) are the elements in
charge of performing policy-based admission control and managing QoS
resources at a global level. For scalability reasons, this element
may be divided into a set of access network brokerage elements (the
actual PDPs) and a core QoS broker. QoS enforcement elements (Policy
Enforcement Points or PEPs, in COPS terminology) are the network
routing nodes, which are in charge of applying the QoS configurations
set up by the brokerage elements. Routing elements - the actual PEPs
-are usually classified into:
o Access Routers (AR) which constitute the entry point to the network
for subscribers.
o The Core Routers (CR) is in charge of managing QoS reservations for
aggregated flows (macroflows).
o The Edge Routers (ER) is in charge of interconnecting several
DiffServ [7] domains or IntServ [8] to DiffServ mapping.
In the presented Multimedia Service Provisioning Platform
architecture, the access proxy element (AProxy) will contact its
local Access Network's QoS Broker (ANQosBr) in order to reserve the
required resources for the steams that are negotiated through
multimedia signalling. After a successful negotiation all the QoS-
related interactions will be exchanged through the QoS provisioning
part of the architecture, with no further interactions between the
Service and the QoS provisioning elements.
In order to request QoS resources for a particular multimedia stream,
the access proxy element must provide the Access Network QoS Broker
not only a description of the required network resources (e.g.
Service type, stream QoS characterization, etc.), but also some
filtering criteria that enable QoS elements to identify the
reservation target streams. Streams can usually be identified from
the network point of view by a combination of elements from the 5-
tuple (source address, source port, destination address, destination
port, transport protocol).
The sequence of interaction events between the components shown in
Fig. 1 is:
o The AProxy will interpret the SDP/SDPng content in order to arrange
the type of QoS network reservation to be requested from the
ANQosBroker.
o In order to uniquely identify the reservation for a specific flow,
filtering information must be provided to the ANQoSBroker.
Guenkova, et al. Expires August 10, 2005 [Page 4]
Internet-Draft Stream Tracking Description February 2005
o The ANQoSBroker will configure the AR accordingly.
Since there is not an explicit relationship between the SIP session
identifier and the media session (e.g. RTP session), the AR must know
all the parameters referred in the filtering information in order to
uniquely identify and control the admission of the packets of a
single flow.
+------------+ Coordination +--------------+
| ANQosBr |<-------------->| Other QoS |
|(PEP1)(PDP2)| | provisioning |
+------------+ | elements |
^ | +--------------+
COPS | |
| |
\/ |
+-------+ |
|AProxy | |
|(PDP1) | | QoS configuration
+-------+ |
^ |
| |
SIP/SDP | |
or | |
SIP/SDPng | |
| |
| \/
+------+ +-------+ Access +----+ Core
| Host |<=====>| AR |<===> Network <===>| ER |<===> Network
| | Media | (PEP2)| (QoS 1) | | (QoS 2)
+------+ +-------+ +----+
Figure 1: Multimedia Service Provisioning Platform
Although session description protocols [1][2] describe in detail the
multimedia-oriented service characteristics of streams, they only
provide a basic description of their associated network parameters,
conveying only the IP addresses, transport protocols, and reception
ports of the streams composing the session. Several common practice
mechanisms (e.g. symmetric RTP uses the local listening port also as
the source port for outgoing streams [9]) are applied in order to
infer the sender port information from the exchanged session
descriptions delivered through the multimedia signalling, since the
sender port information is not explicitly given in the session
descriptions. This kind of practices should be discouraged, as they
are vulnerable and error-prone, with the consequences of network
resource wasting and exposure to exploitation by malicious users.
Guenkova, et al. Expires August 10, 2005 [Page 5]
Internet-Draft Stream Tracking Description February 2005
Therefore, session descriptions conveyed in the multimedia signalling
should be enhanced in order to include complete and univocal stream
descriptions, so that access proxy elements may provide to the QoS
subsystem all the necessary parameters for an effective flow
distinction and tracking.
Please note that, although intended for the architecture depicted
above, this extension may be useful for any network element issuing
resource reservation requests based on information conveyed in
multimedia session descriptions too, such as:
o User terminals (e.g. using RSVP [10]).
o Routers implementing any signalling tracking mechanism for
automatic QoS resource reservation.
3. RTP traffic tracking descriptions in SDP and SDPng
Session Description Protocol (SDP) [1] is intended for describing
multimedia sessions for the purposes of session announcement, session
invitation, and other forms of multimedia session initiation.
SDPng [2] is a meta-protocol that can describe other protocols and
configuration mechanisms of the applications. Just like its
predecessor SDP [1], SDPng is carried as an attachment of other
configuration protocols (e.g. SIP [4], RTSP [11]) to exchange for
example configuration information about RTP-based [9] multimedia
streams. SDPng is a successor protocol of the Session Description
Protocol [1] and is designed to be modular and extensible using the
eXtensible Markup Language (XML) [12](unlike its predecessor SDP).
SDPng is designed to support more complex media features and
scenarios than SDP, including quality of service (QoS), security
support for media transfer, etc [13].
Sections 3.1 and 3.2 describe the proposed enhancements for SDP and
SDPng to include information about media source ports, thus enabling
effective flow distinction and tracking as discussed and motivated in
Chapter 2.
3.1. SDP enhancement of the "m=" line
The following defines the model for the SDP enhancement:
m=<media> <port>/<number of ports>/<sender port>/<number of sender
ports> <proto> <fmt>
An example corresponding to the above model is:
Guenkova, et al. Expires August 10, 2005 [Page 6]
Internet-Draft Stream Tracking Description February 2005
m=video 49170/2/50080/2 RTP/AVP 31
Meaning of the example:
o The media type is "video"
o The first RTP receiving port in use is 49170
o The second RTP receiving port in use is 49172
o The first RTCP port that corresponds the first receiving RTP port
is 49171
o The second RTCP port that corresponds the second receiving RTP port
is 49173
o The first RTP sending port in use is 50080
o The second RTP sending port in use is 50082
o The first RTCP sending port that corresponds the first RTP sending
port is 50081
o The second RTCP sending port that corresponds the second RTP
sending port is 550083
o The protocol in use is RTP with the AVP profile [14]
o The applied payload format is number 31 according to [14]
Note that if QoS shall be guaranteed for RTP streams, it shall also
be guaranteed for their corresponding RTCP traffic, as the timely
reports for the RTP traffic are important for the QoS relevant
adaptations of the traffic.
3.2. SDPng enhancement of the <rtp:ip-addr> component of the RTP
package
Due to the line wrapping of the format required for this document the
original indentation as usual for XML layout does not appear
correctly, i.e. the bracket pairs "<" and "/>" or "<" and ">", or
"</" and ">" always indicate single unbreakable lines. Additionally,
the conventional ordering of the XML hierarchical elements appears as
hierarchical tree layout. All the XML examples and schemas in this
document are proven on wellformness and validity with XMLSpy Software
[15].
The following SDPng definition is the expression that corresponds to
the definition in SDP within the previous Section 3.1. In order to
Guenkova, et al. Expires August 10, 2005 [Page 7]
Internet-Draft Stream Tracking Description February 2005
achieve similar expressiveness as the "m=" line in SDP, we redefine
the <rtp:ip-addr> element of SDPng. The new definition of the IP
address and RTP ports in the SDPng RTP package (see [2]) is provided
through the application of two new XML complex types.
The XML schema snippets corresponding the new "IP addresses" and "RTP
ports" complex types are:
Port Type:
<xsd:complexType name="portType">
<xsd:sequence>
<xsd:element name="rtp-port" type="sdpng:opttoken"
minOccurs="0"/>
<xsd:element name="rtcp-port" type="sdpng:opttoken"
minOccurs="0"/>
<xsd:element name="rtp-port-offset" type="sdpng:opttoken"
minOccurs="0"/>
<xsd:element name="rtp-sendport" type="sdpng:opttoken"
minOccurs="0"/>
<xsd:element name="rtcp-sendport" type="sdpng:opttoken"
minOccurs="0"/>
<xsd:element name="rtp-sendport-offset" type="sdpng:opttoken"
minOccurs="0"/>
</xsd:sequence>
</xsd:complexType>
IP Address Type:
<xsd:complexType name="addrType">
<xsd:complexContent>
<xsd:extension base="rtp:portType">
<xsd:attribute name="ip" type="xsd:NMTOKEN" use="required"/>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
The definition of the new corresponding element in the RTP XML schema
would be then:
<xsd:element name="ip-addr" type="sdpng:opttoken" minOccurs="0"/>
As a result of this new definition the port definitions are put in
the container for the IP Address <rtp:ip-addr>. The complete
definition is still a sub-element of the <rtp:udp> container [2] as
shown in the example below:
Guenkova, et al. Expires August 10, 2005 [Page 8]
Internet-Draft Stream Tracking Description February 2005
<rtp:udp name="rtp-cfg001">
...
<rtp:ip-addr ip="134.60.70.80">
<rtp:rtp-port>49170</rtp:rtp-port>
<rtp:rtcp-port>49171</rtp:rtcp-port>
<rtp:rtp-port-offset>1</rtp:rtp-port-offset>
<rtp:rtp-sendport>50080</rtp:rtp-sendport>
<rtp:rtcp-sendport>50081</rtp:rtcp-sendport>
<rtp:rtp-sendport-offset>1</rtp:rtp-sendport-offset>
</rtp:ip-addr>
...
</rtp:udp>
This SDPng description corresponds to the same parameter
configuration as in the SDP example given in Section 3.1. The
difference to SDP is that the pairs of RTP and RTCP ports are now
combined in a way that it is evident how the single ports belong
together (compared to the SDP "a=rtcp:" definition [1]). The elements
<rtp:rtp-port-offset> and <rtp:rtp-sendport-offset> indicate that
additional pair/-s of correspondingly receiving and sending RTP/RTCP
ports SHALL be considered. The counting of the port numbers of every
next pair starts in this case with the number of the RTCP port as
basis.
For example:
<rtp:rtp-port>49170</rtp:rtp-port>
<rtp:rtcp-port>49171</rtp:rtcp-port>
<rtp:rtp-port-offset>1</rtp:rtp-port-offset>
specifies that 1 additional pair of ports shall be taken, i.e.
o The first RTP receiving port in use is 49170
o The first RTCP port that corresponds the first receiving RTP port
is 49171
o The second RTP receiving port in use is 49172 (i.e. RTCP port 1
plus 1)
o The second RTCP port that corresponds the second receiving RTP port
is 49173 (i.e. RTCP port 1 plus 2).
In case of n-port offsets:
<rtp:rtp-port>49170</rtp:rtp-port>
<rtp:rtcp-port>49171</rtp:rtcp-port>
<rtp:rtp-port-offset>n</rtp:rtp-port-offset>
every n-th pair of RTP/RTCP ports is calculated as RTP_n=RTCP_1+n and
Guenkova, et al. Expires August 10, 2005 [Page 9]
Internet-Draft Stream Tracking Description February 2005
RTCP_n= RTCP_1+n+1
The same definition holds true also for the RTP/RTCP sender ports
(i.e. rtp:rtp-sendport>, <rtp:rtcp-sendport> and <rtp:rtp-sendport-
offset>).
4. IANA Considerations
The IANA should set up a registry for XML namespaces for SDPng and
SDPng package definitions.
The SDP parameter registry (http://www.iana.org/assignments/sdp-
parameters) should be converted to SDPng package definitions.
The inputs of this draft are not concurrent to the inputs of the
original SDPng draft [2], hence they SHOULD be considered as
belonging to the same namespace as long as SDPng is concerned.
The exact structure of the SDPng namespace depends also on the fact
if SDPng work in progress [2] shall be continued or if this draft
shall take over the SDPng development.
5. Security considerations
The explicit definition of RTP/RTCP receiver and sender ports allows
the QoS entities in the network to prove upon the session
descriptions that the terminals are in line with their QoS
specifications as the complete sender-to-receiver track is monitored.
Furthermore, network resource wasting and/or exposure of the network
streams to exploitation by malicious users is avoided as the QoS
relevant streams are declared explicitly for monitoring in the
session descriptions.
The problem of the security should also be studies further with
respect to Firewall and NAT traversal, as the proposed solution in
this document requires interactions between the session signalling
and the multimedia streaming. In order to achieve correspondence
between these two types of signalling the security components SHALL
apply similar to the IMS architecture (see also Chapter 2) in order
to guarantee conformant treatment for both the session signalling and
the corresponding multimedia streaming.
Since SDP and SDPng are a description formats carried by other
protocols (SIP [8], RTSP [11], etc.), SDP and SDPng rely on the
security provided by their carriers to guarantee faultless end-to-end
transfer.
Guenkova, et al. Expires August 10, 2005 [Page 10]
Internet-Draft Stream Tracking Description February 2005
References
[1] M. Handley, V. Jacobson, "SDP: Session Description
Protocol", IETF RFC 2327, April 1998 and M. Handley, V.
Jacobson, C. Perkins, "SDP: Session Description Protocol",
draft-ietf-mmusic-sdp-new-23.txt, December 2004.
[2] D. Kutscher et al., "Session description and capability
negotiation", IETF Internet-Draft, Work-in-progress: draft-
ietf-mmusic-sdpng-07, October 2003.
[3] G. Camarillo, W. Marshall, J. Rosenberg, "Integration of
Resource Management and Session Initiation Protocol", IETF
RFC 3312, October 2002.
[4] J. Rosenberg et al., "SIP: Session Initiation Protocol",
IETF RFC 3261, June 2002.
[5] 3GPP TS 23.228 v 6.8.0, "IP Multimedia Subsystem (IMS);
Stage 2 (Release 6)", December 2004.
[6] D. Durham et al, "The COPS (Common Open Policy Service)
Protocol", IETF RFC 2748, January 2000.
[7] S. Blake et al., "An Architecture for Differentiated
Service", IETF RFC 2475, December 1998.
[8] R. Braden, D. Clark, S. Shenker, "Integrated Services in the
Internet Architecture: an Overview", IETF RFC 1633, June
1994.
[9] H. Schulzrinne et al., "RTP: A Transport Protocol for Real-
Time Applications", IETF RFC 3550, July 2003.
[10] R. Braden et al, "Resource ReSerVation Protocol (RSVP) --
Version 1 Functional Specification", IETF RFC 2205,
September 1997.
[11] H. Schulzrinne, A. Rao, R. Lanphier, "Real Time Streaming
Protocol (RTSP)", IETF RFC 2326, April 1998 and H.
Schulzrinne et al., "Real Time Streaming Protocol (RTSP)",
draft-ietf-mmusic-rfc2326bis-07.txt, July 2004.
[12] W3C, "Extensible Markup Language (XML) 1.0 (Second
Edition)".
[13] J. Ott, C. Perkins, "SDPng Transition", IETF Internet-Draft
(draft-ietf-mmusic-sdpng-trans-04), May 2003.
[14] H. Schulzrinne, S. Casner, "RTP Profile for Audio and Video
Conferences with Minimal Control", IETF RFC 3551, July 2003
Guenkova, et al. Expires August 10, 2005 [Page 11]
Internet-Draft Stream Tracking Description February 2005
[15] Altova GmbH & Altova Inc., XMLSpy IDE version 4.3,
www.altova.com
Authors' Addresses
Teodora Guenkova-Luy
Dept. Distributed Systems, University of Ulm,
Oberer Eselsberg, 89069 Ulm, Germany
Tel: +49 (0)731 502-4148
Fax: +49 (0)731 502-4142
e-Mail: guenkova@vs.informatik.uni-ulm.de
Andreas Schorr
Dept. Distributed Systems, University of Ulm,
Oberer Eselsberg, 89069 Ulm, Germany
Tel: +49 (0)731 502-4147
Fax: +49 (0)731 502-4142
e-Mail: schorr@informatik.uni-ulm.de
Franz Hauck
Dept. Distributed Systems, University of Ulm,
Oberer Eselsberg, 89069 Ulm, Germany
Tel: +49 (0)731 502-4143
Fax: +49 (0)731 502-4142
e-Mail: hauck@informatik.uni-ulm.de
Ingo Wolf
T-Systems International GmbH
Goslarer Ufer 35, 10589 Berlin, Germany
Tel: +49 (0)30 3497 2526
Fax: +49 (0)30 3497 2929
E-mail: wolfi@t-systems.com
Bernhard Feiten
T-Systems International GmbH
Goslarer Ufer 35, 10589 Berlin, Germany
Tel: +49 (0)30 3497 2528
Fax: +49 (0)30 3497 2929
e-Mail: Bernhard.Feiten@t-systems.com
Miguel Gomez
Agora Systems, S.A.
Aravaca 12, 1 A. 28040 Madrid, Spain
Tel: +34-91-533-58-57
Fax: +34-91-534-84-77
e-Mail: miguel.gomez@agora-2000.com
Guenkova, et al. Expires August 10, 2005 [Page 12]
Internet-Draft Stream Tracking Description February 2005
Fermin Galan
Agora Systems, S.A.
Aravaca 12, 1 A. 28040 Madrid, Spain
Tel: +34-91-533-58-57
Fax: +34-91-534-84-77
e-Mail: fermin.galan@agora-2000.com
Telma Mota
Portugal Telecom Inova??o, SA
Rua Eng. Jos? Ferreira Pinto Basto
3810 AVEIRO, Portugal
Tel: +351-234-403-280
e-mail: telma@ptinovacao.pt
Willem A. Romijn
Lucent Technologies Nederland B.V.
Larenseweg 50
1221 CN Hilversum
The Netherlands
Tel: +31 35 687 4672
e-mail: romijn@lucent.com
Acknowledgements
The work described in this draft is based on results of IST FP6
Integrated Project DAIDALOS. DAIDALOS receives research funding from
the European Community's Sixth Framework Programme. Apart from this,
the European Commission has no responsibility for the content of this
draft. The information in this document is provided as is and no
guarantee or warranty is given that the information is fit for any
particular purpose. The user thereof uses the information at its sole
risk and liability.
Additional support has been provided by the DFG within the AKOM
framework.
Copyright Notice
Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Liability notice
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Guenkova, et al. Expires August 10, 2005 [Page 13]
