idnits 2.17.1 draft-camarillo-mmusic-separate-streams-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 6 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 3 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (May 22, 2002) is 8010 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 2327 (ref. '1') (Obsoleted by RFC 4566) -- Possible downref: Non-RFC (?) normative reference: ref. '2' Summary: 3 errors (**), 0 flaws (~~), 4 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force SIP WG 3 Internet Draft G. Camarillo 4 Ericsson 5 A. Monrad 6 Ericsson 7 draft-camarillo-mmusic-separate-streams-00.txt 8 May 22, 2002 9 Expires: December 2002 11 Mapping of Media Streams to Resource Reservation Flows 13 STATUS OF THIS MEMO 15 This document is an Internet-Draft and is in full conformance with 16 all provisions of Section 10 of RFC2026. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress". 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt 31 To view the list Internet-Draft Shadow Directories, see 32 http://www.ietf.org/shadow.html. 34 Abstract 36 This document defines an extension to the SDP grouping framework. It 37 allows to request that different media streams are mapped into 38 different resource reservation flows. 40 Table of Contents 42 1 Introduction ........................................ 3 43 1.1 Terminology ......................................... 3 44 2 KIS Semantics ....................................... 3 45 3 Example ............................................. 3 46 4 IANA Considerations ................................. 4 47 5 Security Considerations ............................. 4 48 6 Authors' Addresses .................................. 4 49 7 Normative References ................................ 5 50 8 Informative References .............................. 5 52 1 Introduction 54 Resource reservation protocols assign network resources to particular 55 flows of IP packets. When a router receives an IP packet, it applies 56 a filter in order to map the packet to the flow it belongs and 57 provide it with the Quality of Service (QoS) corresponding to that 58 flow. Routers typically use the source and the destination IP 59 addresses and port numbers to filter packets. 61 Multimedia sessions typically contain multiple media streams (e.g. an 62 audio stream and a video stream). In order to provide QoS for a 63 multimedia session it is necessary to map all the media streams to 64 resource reservation flows. This mapping can be performed in 65 different ways. Two possibilities are to map all the media streams to 66 a single resource reservation flow and to map every single media 67 stream to a different resource reservation flow. Some applications 68 require that the latter type of mapping is performed (i.e., a single 69 media stream is mapped to a single resource reservation flow). This 70 document defines the syntax needed to express that need in SDP [1]. 71 For this purpose, we make use of the SDP grouping framework [2] and 72 define a new "semantics" attribute called KIS (Keep It Separate). 74 1.1 Terminology 76 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 77 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 78 and "OPTIONAL" are to be interpreted as described in RFC 2119 [3] and 79 indicate requirement levels for compliant SIP implementations. 81 2 KIS Semantics 83 We define a new "semantics" attribute within the SDP grouping 84 framework [2]: KIS (Keep It Separate). 86 Media lines grouped using KIS semantics SHOULD NOT be mapped into the 87 same resource reservation flow. A different resource reservation flow 88 SHOULD be used (or established) for each media line of the KIS group. 90 3 Example 92 A user agent receives a SIP [4] INVITE with the SDP below: 94 v=0 95 o=Laura 289083124 289083124 IN IP4 one.example.com 96 t=0 0 97 c=IN IP4 192.0.0.1 98 a=group:KIS 1 2 99 m=audio 30000 RTP/AVP 0 100 a=mid:1 101 m=video 30002 RTP/AVP 31 102 a=mid:2 104 This user agent uses RSVP [5] to perform resource reservation. Since 105 both media streams are part of a KIS group, the user agent will 106 establish two different RSVP sessions; one for the audio stream and 107 one for the video stream. An RSVP session is defined by the triple: 108 (DestAddress, ProtocolId[, DstPort]). Table 1 shows the parameters 109 used to establish both RSVP sessions. 111 Session Number DestAddress ProtocolId DstPort 112 ________________________________________________ 113 1 192.0.0.1 UDP 30000 114 2 192.0.0.1 UDP 30002 116 Table 1: Parameters needed to establish both RSVP sessions 118 If the same user agent received an SDP session description with the 119 same media streams but without the group line, it would be free to 120 map both media streams into the same RSVP session. 122 4 IANA Considerations 124 IANA needs to register the following new "semantics" attribute for 125 the SDP grouping framework [2]: 127 KIS: Keep It Separate 129 5 Security Considerations 131 An attacker adding group lines using the KIS semantics to an SDP 132 session description could force a user agent to establish a larger 133 number of resource reservation flows than needed. It is thus 134 RECOMMENDED that some kind of integrity protection is applied to SDP 135 session descriptions. 137 6 Authors' Addresses 138 Gonzalo Camarillo 139 Ericsson 140 Advanced Signalling Research Lab. 141 FIN-02420 Jorvas 142 Finland 143 electronic mail: Gonzalo.Camarillo@ericsson.com 145 Atle Monrad 146 Ericsson 147 N-4898 Grimstad 148 Norway 149 electronic mail: atle.monrad@ericsson.com 151 7 Normative References 153 [1] M. Handley and V. Jacobson, "SDP: session description protocol," 154 RFC 2327, Internet Engineering Task Force, Apr. 1998. 156 [2] G. Camarillo, J. Holler, G. Eriksson, and H. Schulzrinne, 157 "Grouping of m lines in SDP," Internet Draft, Internet Engineering 158 Task Force, Feb. 2002. Work in progress. 160 [3] S. Bradner, "Key words for use in RFCs to indicate requirement 161 levels," RFC 2119, Internet Engineering Task Force, Mar. 1997. 163 8 Informative References 165 [4] J. Rosenberg, H. Schulzrinne, et al. , "SIP: Session initiation 166 protocol," Internet Draft, Internet Engineering Task Force, Feb. 167 2002. Work in progress. 169 [5] R. Braden, Ed., L. Zhang, S. Berson, S. Herzog, and S. Jamin, 170 "Resource ReSerVation protocol (RSVP) -- version 1 functional 171 specification," RFC 2205, Internet Engineering Task Force, Sept. 172 1997. 174 Full Copyright Statement 176 Copyright (c) The Internet Society (2002). All Rights Reserved. 178 This document and translations of it may be copied and furnished to 179 others, and derivative works that comment on or otherwise explain it 180 or assist in its implementation may be prepared, copied, published 181 and distributed, in whole or in part, without restriction of any 182 kind, provided that the above copyright notice and this paragraph are 183 included on all such copies and derivative works. However, this 184 document itself may not be modified in any way, such as by removing 185 the copyright notice or references to the Internet Society or other 186 Internet organizations, except as needed for the purpose of 187 developing Internet standards in which case the procedures for 188 copyrights defined in the Internet Standards process must be 189 followed, or as required to translate it into languages other than 190 English. 192 The limited permissions granted above are perpetual and will not be 193 revoked by the Internet Society or its successors or assigns. 195 This document and the information contained herein is provided on an 196 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 197 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 198 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 199 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 200 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.