idnits 2.17.1 draft-asaeda-mboned-session-announcement-req-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 17. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 321. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 332. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 339. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 345. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard 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 ([3]), 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 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 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 (July 6, 2008) is 5772 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) -- Possible downref: Non-RFC (?) normative reference: ref. '2' ** Downref: Normative reference to an Experimental RFC: RFC 2974 (ref. '3') ** Obsolete normative reference: RFC 4566 (ref. '4') (Obsoleted by RFC 8866) Summary: 6 errors (**), 0 flaws (~~), 4 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MBONED Working Group H. Asaeda 3 Internet-Draft K. Mishima 4 Expires: January 7, 2009 Keio University 5 V. Roca 6 INRIA 7 July 6, 2008 9 Requirements for IP Multicast Session Announcement in the Internet 10 draft-asaeda-mboned-session-announcement-req-00 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on January 7, 2009. 37 Abstract 39 The Session Announcement Protocol (SAP) [3] was used to announce 40 information for all available multicast sessions to the prospective 41 receiver in an experimental network. It is usefull and easy to use, 42 but difficult to control the SAP message transmission in a wide area 43 network. This document describes the several major limitations SAP 44 has and the requirement of multicast session announcement in the 45 global Internet. 47 Conventions used in this document 49 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 50 NOT","SHOULD", "SHOULD NOT", "RECOMMENDED","MAY", and "OPTIONAL" in 51 this document are to be interpreted as described in RFC 2119 [1]. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 56 2. Potential Problems in SAP . . . . . . . . . . . . . . . . . . 5 57 2.1. Announcement Interval vs. Latency . . . . . . . . . . . . 5 58 2.2. Difficulties in Scope Definition . . . . . . . . . . . . . 5 59 2.3. Communication Dependency . . . . . . . . . . . . . . . . . 6 60 2.4. Lack of Sender and Receiver Control . . . . . . . . . . . 7 61 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 8 62 4. Normative References . . . . . . . . . . . . . . . . . . . . . 9 63 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 64 Intellectual Property and Copyright Statements . . . . . . . . . . 11 66 1. Introduction 68 The Session Announcement Protocol (SAP) [3] was a necessary component 69 to announce information for all available multicast sessions to the 70 prospective receiver in the experimental MBone. In a SAP 71 announcement procedure, the entire session information must be 72 periodically transmitted and all active session descriptions 73 (described with the Session Description Protocol (SDP) [4] syntax) 74 must be continuously refreshed. If ever a session is no longer 75 announced, its description eventually times out and is deleted from 76 the available session list. This is a major property of a "soft- 77 state" protocol. 79 SAP enables to keep the session information active and refresh it, 80 and builds robust and fault-tolerant systems. However, it requires 81 the periodic message transmission (i.e. message flooding) that may 82 cause major overheads or overloads. Although this strategy keeps the 83 implementation simple, it rises costs and further reduces its 84 scalability. 86 Another issue is closely related to a security or policy management. 87 As with the above issue, it is difficult to control a data sender or 88 a receiver and the amount of traffic or the data distribution area 89 even with existing scoping techniques. 91 This document explains the issues SAP has been raised and clarifies 92 the requirements that should fulfill an ideal session announcement 93 system. This document describes work originally published by Asaeda 94 and Roca in IEICE Transactions on Information and Systems [2]. 96 2. Potential Problems in SAP 98 2.1. Announcement Interval vs. Latency 100 SAP improves the robustness and data consistency in front of packet 101 losses by transmitting each message several times. However, 102 transmitting a large number of active multicast sesssion information 103 in a flooding manner may cause major overheads. The solution defined 104 in [3] is the time period between repetitions of an announcement. 105 This period is chosen such that the total bandwidth used by all 106 announcements on a single SAP group remains below a preconfigured 107 limit, and the bandwidth limit should be assumed to be 4000 bits per 108 second, if not specified. 110 However, this solution largely increases the latency experienced by 111 end users especially when the number of sessions increases. In its 112 definition, since the minimum interval of SAP message transmission is 113 200 seconds, end users experience a minimum waiting time of 200 114 seconds to obtain the entire session list, irrespective of the number 115 of observed multicast sessions, message size of multicast session 116 information, and bandwidth SAP uses. Let us assume the average 117 message size of a single multicast session information is about 300 118 bytes. When there are more than 500 active multicast sessions, an 119 interval time of each session announcement becomes greater than 300 120 seconds and the average announcement interval increases accordingly. 121 For instance, if 2000 multicast sessions are active in the Internet, 122 each session announcement interval is between 800 seconds and 1600 123 seconds. In this case, if some SAP message is lost, users may need 124 to wait 1600 seconds for the next announcement as maximum. 126 Obviously, it is possible to make the announcement interval shorter 127 by changing the SAP configuration on a sender side and provide 128 shorter latency for the sender-receiver communication. However, it 129 makes the total ammount of SAP messages transmitted larger and may 130 increase the probability of creating congestions. 132 2.2. Difficulties in Scope Definition 134 Multicast data senders or network administrators may want to define 135 an area where data packets sent within a session will be confined. 136 This area is called "scope area". An end user who belongs to the 137 scope area can receive the session data. 139 When IP multicast was initially deployed in the MBone, the Time-To- 140 Live (TTL) field of the IP header was used to control the 141 distribution of multicast traffic. A multicast router configured 142 with a TTL threshold drops any multicast packet in which the TTL 143 falls below the threshold. For instance, a router at the boundary of 144 an organization configures the threshold to 32 which denotes an 145 "organization" scope boundary. 147 The drawbacks of this "TTL scoping" are: 1) the senders must be 148 sufficiently aware of the network topology to determine the TTL value 149 to use, and 2) complex scope areas cannot be defined (e.g., between 150 overlapped areas). Especially the first point becomes big obstacles 151 for general end users to precisely set up the data distribution area. 152 TTL scoping, which only defines a rough granularity, does not provide 153 a complete solution. 155 The "administratively scoped IP multicast" approach [5] provides 156 clear and simple semantics such as scope boundaries are associated to 157 multicast addresses. With IPv4, packets addressed to the 158 administratively scoped multicast address range 239/8 (i.e. from 159 239.0.0.0 to 239.255.255.255) cannot cross the configured 160 administrative boundaries. Since scoped addresses are defined 161 locally, the same multicast address can be used in different non- 162 overlapping areas. Oppositely, an administrator can define multiple 163 areas overlap by dividing the administratively scoped address range, 164 which is not possible with TTL scoping. 166 However, administrative scoping has several major limitations. An 167 administrator may want to partition the scope area to disjoint areas 168 on a per receiver basis, or he may want to limit data distribution 169 according to the transmission rate or the content category of each 170 session, or he may want to use the data sender's address as a keyword 171 to set up the scope. Note that the latter aspect is nowadays 172 feasible since Source-Specific Multicast (SSM) [6] requires that a 173 join request specifies both the multicast and source addresses. 175 SSM highlights another contradiction in the administrative scoping 176 approach: the address range dedicated to SSM, 232/8 with IPv4, cannot 177 cover the address range dedicated to administrative scoping, 239/8. 178 Although the problem can be solved by defining yet another SSM 179 specific administrative scoping address range, defining a new 180 addressing architecture requires modifying application, end host, and 181 router implementations or configurations. Hence, using multicast 182 addresses to define a scope is not a complete solution either. 184 2.3. Communication Dependency 186 SAP relies on the ASM model, since every SAP instance can send 187 announcements in the SAP announcement group. For instance, to 188 receive SAP announcement messages for the global scope IPv4 multicast 189 sessions, all prospective receivers must join session 224.2.127.254 190 (without specifying any source address). This is another major 191 limitation of SAP since some Internet Service Providers (ISPs) may 192 want to provide only SSM multicast routing. It is known that a 193 versatile announcement protocol should not rely on any specific 194 routing architecture. 196 Moreover, this communication model is subject to a Denial-of-Service 197 attack. If malicious hosts flood high bandwidth stream to this 198 global announcement address, 224.2.127.254, then all prospective 199 receivers including multicast routers listening SAP messages take in 200 the stream and their networks may be corrupted or destroyed 201 unintentionally. 203 2.4. Lack of Sender and Receiver Control 205 Network administrators or service providers may want to define 206 approved senders and restrict multicast data transmissions or 207 announcement only from them. However, it is difficult to configure 208 approved senders only who can send SAP messages or non-approved 209 senders who are disabled to send SAP messages. 211 In addition, it is diffucult to hide multicast session information 212 announced by SAP from non-approved receivers if they are inside the 213 scoped network. SAP messages might be encrypted to prevent non 214 authorized client from reading it. However, it adds more complexity 215 to SAP by combining with a key sharing mechanism. 217 3. Requirements 219 According to the SAP analysis aforementioned, the requirements for IP 220 multicast session announcement are defined as follows; 222 o Information consistency: Information consistency, which warrants 223 that end users have a consistant view of session announcement, is 224 of major importance. 226 o Low information update latency: IP multicast session would be 227 fully dynamic. The list of sessions should be updated rapidly 228 after the creation, modification, or removal of the session 229 information. 231 o Low bandwidth consumption: IP multicast session announcement 232 should effectively consume the network bandwidth so that it does 233 not affect other communications or services. 235 o Scalability: Session announcement can be used by a large number of 236 end users spread throughout the Internet, and can manage a very 237 large number of sessions. 239 o High availability: The scheme must be robust in front of host/link 240 failures and packet losses. This can be fulfilled either by 241 transmitting messages periodically or by keeping track of failures 242 and recovering them. 244 o Scope control: Scope control is required to preserve bandwidth 245 resources and offer a certain level of confidentiality in IP 246 multicast communication. 248 o No dependency on a routing architecture: The session announcement 249 scheme must accommodate (or be independent of) any kind of 250 multicast routing protocol or communication model. 252 o Sender and receiver control: Administrators must be able to allow 253 to announce multicast sessions only from approved multicast 254 senders and only to approved multicast data receivers in their 255 network. They must be able to filter out malicious users. 257 4. Normative References 259 [1] Bradner, S., "Key words for use in RFCs to indicate requirement 260 levels", RFC 2119, March 1997. 262 [2] Asaeda, H. and V. Roca, "Policy and Scope Management for 263 Multicast Channel Announcement", IEICE Trans. on Information and 264 Systems Vol.E88-D, No.7, July 2005. 266 [3] Handley, M., Perkins, C., and E. Whelan, "Session Announcement 267 Protocol", RFC 2974, October 2000. 269 [4] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 270 Description Protocol", RFC 4566, July 2006. 272 [5] Mayer, D., "Administratively scoped IP multicast", RFC 2365, 273 July 1998. 275 [6] Holbrook, H. and B. Cain, "Source-Specific Multicast for IP", 276 RFC 4607, August 2006. 278 Authors' Addresses 280 Hitoshi Asaeda 281 Keio University 282 Graduate School of Media and Governance 283 5322 Endo 284 Fujisawa, Kanagawa 252-8520 285 Japan 287 Email: asaeda@wide.ad.jp 289 Kazuhiro Mishima 290 Keio University 291 Graduate School of Media and Governance 292 5322 Endo 293 Fujisawa, Kanagawa 252-8520 294 Japan 296 Email: three@sfc.wide.ad.jp 298 Vincent Roca 299 INRIA 300 Planete Research Team 301 655, Avenue de l'Europe 302 Montbonnot - Saint Martin, Saint Ismier 38334 303 France 305 Email: vincent.roca@inrialpes.fr 307 Full Copyright Statement 309 Copyright (C) The IETF Trust (2008). 311 This document is subject to the rights, licenses and restrictions 312 contained in BCP 78, and except as set forth therein, the authors 313 retain all their rights. 315 This document and the information contained herein are provided on an 316 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 317 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 318 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 319 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 320 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 321 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 323 Intellectual Property 325 The IETF takes no position regarding the validity or scope of any 326 Intellectual Property Rights or other rights that might be claimed to 327 pertain to the implementation or use of the technology described in 328 this document or the extent to which any license under such rights 329 might or might not be available; nor does it represent that it has 330 made any independent effort to identify any such rights. Information 331 on the procedures with respect to rights in RFC documents can be 332 found in BCP 78 and BCP 79. 334 Copies of IPR disclosures made to the IETF Secretariat and any 335 assurances of licenses to be made available, or the result of an 336 attempt made to obtain a general license or permission for the use of 337 such proprietary rights by implementers or users of this 338 specification can be obtained from the IETF on-line IPR repository at 339 http://www.ietf.org/ipr. 341 The IETF invites any interested party to bring to its attention any 342 copyrights, patents or patent applications, or other proprietary 343 rights that may cover technology that may be required to implement 344 this standard. Please address the information to the IETF at 345 ietf-ipr@ietf.org.