idnits 2.17.1 draft-ietf-mboned-session-announcement-req-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The abstract seems to contain references ([2]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 3 instances of lines with multicast IPv4 addresses in the document. If these are generic example addresses, they should be changed to use the 233.252.0.x range defined in RFC 5771 Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet has text resembling RFC 2119 boilerplate text. -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 8, 2010) is 5162 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 4566 (ref. '3') (Obsoleted by RFC 8866) Summary: 5 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MBONED Working Group H. Asaeda 3 Internet-Draft Keio University 4 Intended status: Informational V. Roca 5 Expires: September 9, 2010 INRIA 6 March 8, 2010 8 Requirements for IP Multicast Session Announcement 9 draft-ietf-mboned-session-announcement-req-03 11 Abstract 13 The Session Announcement Protocol (SAP) [2] was used to announce 14 information for all available IP multicast sessions to the 15 prospective receiver in an experimental network. It is easy to use, 16 but not scalable and difficult to control the SAP message 17 transmission in a wide area network. This document describes the 18 issues and the requirements for multicast session announcement in the 19 global Internet. 21 Status of this Memo 23 This Internet-Draft is submitted to IETF in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF), its areas, and its working groups. Note that 28 other groups may also distribute working documents as Internet- 29 Drafts. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 The list of current Internet-Drafts can be accessed at 37 http://www.ietf.org/ietf/1id-abstracts.txt. 39 The list of Internet-Draft Shadow Directories can be accessed at 40 http://www.ietf.org/shadow.html. 42 This Internet-Draft will expire on September 9, 2010. 44 Copyright Notice 46 Copyright (c) 2010 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the BSD License. 59 This document may contain material from IETF Documents or IETF 60 Contributions published or made publicly available before November 61 10, 2008. The person(s) controlling the copyright in some of this 62 material may not have granted the IETF Trust the right to allow 63 modifications of such material outside the IETF Standards Process. 64 Without obtaining an adequate license from the person(s) controlling 65 the copyright in such materials, this document may not be modified 66 outside the IETF Standards Process, and derivative works of it may 67 not be created outside the IETF Standards Process, except to format 68 it for publication as an RFC or to translate it into languages other 69 than English. 71 Table of Contents 73 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 74 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 75 3. Potential Problems in SAP . . . . . . . . . . . . . . . . . . 6 76 3.1. Announcement Interval vs. Latency . . . . . . . . . . . . 6 77 3.2. Difficulties in Scope Definition . . . . . . . . . . . . . 6 78 3.3. ASM Dependency . . . . . . . . . . . . . . . . . . . . . . 7 79 4. Lack of Sender and Receiver Control in Announcement . . . . . 9 80 5. Potential Problems in Central Server Model . . . . . . . . . . 10 81 6. Potential Problems in Discovery Model . . . . . . . . . . . . 11 82 7. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 12 83 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 84 8.1. Normative References . . . . . . . . . . . . . . . . . . . 13 85 8.2. Informative References . . . . . . . . . . . . . . . . . . 13 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 88 1. Introduction 90 IP multicast session or channel information is described with the 91 Session Description Protocol (SDP) [3] syntax or written in a 92 metafile. 94 The Session Announcement Protocol (SAP) [2] was used to announce 95 information for all available multicast sessions to the prospective 96 receiver in the experimental MBone. In a SAP announcement procedure, 97 the entire session information must be periodically transmitted and 98 all active session descriptions must be continuously refreshed. If 99 ever a session is no longer announced, its description eventually 100 times out and is deleted from the available session list. This is a 101 major property of a "soft-state" protocol. 103 SAP enables to keep the session information active and refresh it, 104 and builds robust and fault-tolerant systems. However, it requires 105 the periodic message transmission (i.e. message flooding) that may 106 cause major overheads or overloads. Although this strategy keeps the 107 implementation simple, it rises costs and further reduces its 108 scalability. 110 Another issue is closely related to a security or policy management. 111 As with the above issue, it is difficult to control a data sender or 112 a receiver and the amount of traffic or the data distribution area 113 even with existing scoping techniques. 115 This document explains the issues SAP and other systems have raised 116 and clarifies the requirements that should fulfill an ideal session 117 announcement system. This document describes work originally 118 published by Asaeda and Roca in IEICE Transactions on Information and 119 Systems [6]. 121 2. Terminology 123 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 124 NOT","SHOULD", "SHOULD NOT", "RECOMMENDED","MAY", and "OPTIONAL" in 125 this document are to be interpreted as described in RFC 2119 [1]. 127 3. Potential Problems in SAP 129 3.1. Announcement Interval vs. Latency 131 SAP improves the robustness and data consistency in front of packet 132 losses by transmitting each message several times. However, 133 transmitting a large number of active multicast session information 134 in a flooding manner may cause major overheads. The solution defined 135 in [2] is the time period between repetitions of an announcement. 136 This period is chosen such that the total bandwidth used by all 137 announcements on a single SAP group remains below a preconfigured 138 limit, and the bandwidth limit should be assumed to be 4000 bits per 139 second, if not specified. 141 However, this solution largely increases the latency experienced by 142 end users especially when the number of sessions increases. In its 143 definition, since the minimum interval of SAP message transmission is 144 200 seconds, end users experience a minimum waiting time of 200 145 seconds to obtain the entire session list, irrespective of the number 146 of observed multicast sessions, message size of multicast session 147 information, and bandwidth SAP uses. Let us assume the average 148 message size of a single multicast session information is about 300 149 bytes. When there are more than 500 active multicast sessions, an 150 interval time of each session announcement becomes greater than 200 151 seconds and the average announcement interval increases accordingly. 152 For instance, if 2000 multicast sessions are active in the Internet, 153 each session announcement interval is between 800 seconds and 1600 154 seconds. In this case, if some SAP message is lost, users may need 155 to wait 1600 seconds for the next announcement as maximum. 157 Obviously, it is possible to make the announcement interval shorter 158 by changing the SAP configuration on a sender side and provide 159 shorter latency for the sender-receiver communication. However, it 160 makes the total amount of SAP messages transmitted larger and may 161 increase the probability of creating congestions. 163 3.2. Difficulties in Scope Definition 165 Multicast data senders or network administrators may want to define 166 an area where data packets sent within a session will be confined. 167 This area is called "scope area". An end user who belongs to the 168 scope area can receive the session data. 170 When IP multicast was initially deployed in the MBone, the Time-To- 171 Live (TTL) field of the IP header was used to control the 172 distribution of multicast traffic. A multicast router configured 173 with a TTL threshold drops any multicast packet in which the TTL 174 falls below the threshold. For instance, a router at the boundary of 175 an organization configures the threshold to 32, which denotes an 176 "organization" scope boundary. 178 The drawbacks of this "TTL scoping" are: 1) the senders must be 179 sufficiently aware of the network topology to determine the TTL value 180 to use, and 2) complex scope areas cannot be defined (e.g., between 181 overlapped areas). Especially the first point becomes big obstacles 182 for general end users to precisely set up the data distribution area. 183 TTL scoping, which only defines a rough granularity, does not provide 184 a complete solution. 186 The "administratively scoped IP multicast" approach [4] provides 187 clear and simple semantics such as scope boundaries are associated to 188 multicast addresses. With IPv4, packets addressed to the 189 administratively scoped multicast address range 239/8 (i.e. from 190 239.0.0.0 to 239.255.255.255) cannot cross the configured 191 administrative boundaries. Since scoped addresses are defined 192 locally, the same multicast address can be used in different non- 193 overlapping areas. Oppositely, an administrator can define multiple 194 areas overlap by dividing the administratively scoped address range, 195 which is not possible with TTL scoping. 197 However, administrative scoping has several major limitations. An 198 administrator may want to partition the scope area to disjoint areas 199 on a per receiver basis, or he may want to limit data distribution 200 according to the transmission rate or the content category of each 201 session, or he may want to use the data sender's address as a keyword 202 to set up the scope. Note that the latter aspect is nowadays 203 feasible since Source-Specific Multicast (SSM) [5] requires that a 204 join request specifies both the multicast and source addresses. 206 SSM highlights another contradiction in the administrative scoping 207 approach: the address range dedicated to SSM, 232/8 with IPv4, cannot 208 cover the address range dedicated to administrative scoping, 239/8. 209 Although the problem can be solved by defining yet another SSM 210 specific administrative scoping address range, defining a new 211 addressing architecture requires modifying application, end host, and 212 router implementations or configurations. Hence, using multicast 213 addresses to define a scope is not a complete solution either. 215 3.3. ASM Dependency 217 SAP relies on the ASM model, since every SAP instance can send 218 announcements in the SAP announcement group. For instance, to 219 receive SAP announcement messages for the global scope IPv4 multicast 220 sessions, all prospective receivers must join session 224.2.127.254 221 (without specifying any source address). This is another major 222 limitation of SAP since some Internet Service Providers (ISPs) may 223 want to provide only SSM multicast routing. It is known that a 224 versatile announcement protocol should not rely on any specific 225 routing architecture. 227 Moreover, this communication model is subject to a Denial-of-Service 228 attack. If malicious hosts flood high bandwidth stream to this 229 global announcement address, 224.2.127.254, then all prospective 230 receivers including multicast routers listening SAP messages take in 231 the stream and their networks may be corrupted or destroyed. 233 4. Lack of Sender and Receiver Control in Announcement 235 Network administrators or service providers may want to define 236 approved senders and restrict multicast data transmissions or 237 announcement only from them. However, in a spontaneous announcement 238 protocol, it is impossible to allow to send announcement messages 239 only from approved senders or make non-approved senders stop sending 240 announcement messages. 242 In addition, it is difficult to hide multicast session information 243 announced by an announcement protocol from non-approved receivers if 244 they are inside the scoped network. For instance, SAP messages might 245 be encrypted to prevent non-authorized client from reading them. 246 However, it adds more complexity to SAP by combining with additional 247 key sharing mechanism. 249 Conceptually, it is difficult to disallow non-approved data receivers 250 to receive session information announced by an announcement protocol, 251 if the announcement data is flooded to their network. It is the 252 basic concept that IP multicast requires scoping configuration to 253 address this issue. However, defining a fine-grained scope areas 254 with using TTL or a multicast address range is a big challenge as 255 described in Section 3.2. 257 5. Potential Problems in Central Server Model 259 Emails, RSS (Rich Site Summary or Really Simple Syndication), and the 260 Web are the alternative ways of conveying session descriptions. 261 These applications are of wide use and can be used to carry many 262 kinds of information. However, to provide a multicast announcement 263 function, these approaches would have to rely on a central server or 264 a central management system. This server-based approach reduces 265 flexibility of fine-grained user and session management. 267 Session announcement should be decided by data senders or 268 administrators policy, such as scoping policy [4], or content-level 269 or user-level access control, to define "who can access which 270 contents". Defining and applying such site-local policy or user 271 management would be very difficult or impossible on a single server 272 in the global Internet. This condition contradicts the requirements 273 experienced in the traditional MBone and expected in current or 274 future use. 276 In addition, emails and the RSS feed are implemented with a 277 "subscription model". The subscription model requires end users to 278 know the address of service providers and have subscribed to the 279 services for getting session information prior to receiving the 280 contents information. This condition is not reasonable for session 281 announcement, because end users do not always know potential data 282 senders. 284 Finally, server-based systems may require a large amount of 285 operational costs or cause scalability problems for the fine-grained 286 user and session management and session announcement, especially when 287 the systems need to support a large number of users and contents 288 information. 290 6. Potential Problems in Discovery Model 292 Session information discovery is another possible approach to 293 retrieve session information. Currently, there are information 294 discovery systems largely deployed in the Internet. However, an 295 information discovery system usually adopts crawling method to 296 discover information. If an information discovery system is used for 297 session information discovery, it not only causes a number of traffic 298 but also takes time for gathering all available session information 299 in the entire Internet or updating the collected session information. 300 This is a drawback for searching the available IP multicast session 301 information, because many of IP multicast sessions are possibly 302 launched and terminated highly dynamically. 304 Another issue resided in an information discovery system is that it 305 is difficult to enable a scoping function on it, as each site-local 306 operator or administrator does not control the service, especially 307 when the system is implemented with the server-based approach as 308 described in Section 5. 310 7. Requirements 312 According to the analyses aforementioned, the requirements for IP 313 multicast session announcement are defined as follows; 315 o Information consistency: Information consistency, which warrants 316 that end users have a consistent view of session announcement, is 317 of major importance. 319 o Low information update latency: IP multicast session would be 320 fully dynamic. The list of sessions should be updated rapidly 321 after the creation, modification, or removal of the session 322 information. 324 o Low bandwidth consumption: IP multicast session announcement 325 should effectively consume the network bandwidth so that it does 326 not affect other communications or services. 328 o Scalability: Session announcement can be used by a large number of 329 end users spread throughout the Internet, and can manage a very 330 large number of sessions. 332 o High availability: The scheme must be robust in front of host/link 333 failures and packet losses. This can be fulfilled either by 334 transmitting messages periodically or by keeping track of failures 335 and recovering them. 337 o Scope control: Scope control is required to preserve bandwidth 338 resources and offer a certain level of confidentiality in IP 339 multicast communication. 341 o Sender control: Administrators must be able to allow to announce 342 multicast sessions only from approved multicast senders. 344 o User access control: Administrators or data senders must be able 345 to configure approved multicast data receivers. They must be able 346 to filter out malicious users. 348 o No dependency on a routing architecture: The session announcement 349 scheme must accommodate (or be independent of) any kind of 350 multicast routing protocol or communication model. 352 o Security consideration: In order to provide secure multicast 353 communication, session announcement should have a function that 354 enables to encrypt session information and distribute it to only 355 the legitimate users. 357 8. References 359 8.1. Normative References 361 [1] Bradner, S., "Key words for use in RFCs to indicate requirement 362 levels", RFC 2119, March 1997. 364 [2] Handley, M., Perkins, C., and E. Whelan, "Session Announcement 365 Protocol", RFC 2974, October 2000. 367 [3] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 368 Description Protocol", RFC 4566, July 2006. 370 [4] Mayer, D., "Administratively scoped IP multicast", RFC 2365, 371 July 1998. 373 [5] Holbrook, H. and B. Cain, "Source-Specific Multicast for IP", 374 RFC 4607, August 2006. 376 8.2. Informative References 378 [6] Asaeda, H. and V. Roca, "Policy and Scope Management for 379 Multicast Channel Announcement", IEICE Trans. on Information and 380 Systems, Vol.E88-D, No.7, pp.1638-1645, July 2005. 382 Authors' Addresses 384 Hitoshi Asaeda 385 Keio University 386 Graduate School of Media and Governance 387 5322 Endo 388 Fujisawa, Kanagawa 252-8520 389 Japan 391 Email: asaeda@wide.ad.jp 392 URI: http://www.sfc.wide.ad.jp/~asaeda/ 394 Vincent Roca 395 INRIA 396 Planete Research Team 397 655, Avenue de l'Europe 398 Montbonnot - Saint Martin, Saint Ismier 38334 399 France 401 Email: vincent.roca@inrialpes.fr 402 URI: http://planete.inrialpes.fr/~roca/