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 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= /// 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 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 "" 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 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: IP Address Type: The definition of the new corresponding element in the RTP XML schema would be then: As a result of this new definition the port definitions are put in the container for the IP Address . The complete definition is still a sub-element of the container [2] as shown in the example below: Guenkova, et al. Expires August 10, 2005 [Page 8] Internet-Draft Stream Tracking Description February 2005 ... 49170 49171 1 50080 50081 1 ... 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 and 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: 49170 49171 1 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: 49170 49171 n 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>, and ). 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]