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