idnits 2.17.1 draft-lehtonen-mboned-dynssm-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.a on line 20. -- Found old boilerplate from RFC 3978, Section 5.5 on line 385. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 362. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 369. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 375. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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 : ---------------------------------------------------------------------------- ** There are 13 instances of too long lines in the document, the longest one being 2 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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 (Feb 11, 2005) is 7014 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) ** Downref: Normative reference to an Informational RFC: RFC 3569 (ref. '1') == Outdated reference: A later version (-02) exists of draft-ietf-mboned-ipv6-multicast-issues-01 Summary: 7 errors (**), 0 flaws (~~), 3 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force R. Lehtonen 3 Internet-Draft TeliaSonera 4 Expires: August 15, 2005 S. Venaas 5 University of Southampton 6 M. Hoerdt 7 University Louis Pasteur - LSIIT 8 Feb 11, 2005 10 Requirements for discovery of dynamic SSM sources 11 draft-lehtonen-mboned-dynssm-req-00.txt 13 Status of this Memo 15 This document is an Internet-Draft and is subject to all provisions 16 of Section 3 of RFC 3667. By submitting this Internet-Draft, each 17 author represents that any applicable patent or other IPR claims of 18 which he or she is aware have been or will be disclosed, and any of 19 which he or she become aware will be disclosed, in accordance with 20 RFC 3668. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as 25 Internet-Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 This Internet-Draft will expire on August 15, 2005. 40 Copyright Notice 42 Copyright (C) The Internet Society (2005). 44 Abstract 46 This draft identifies the need for discovering new SSM sources in a 47 multicast session. It also defines the basic requirements for such 48 functionality. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3 54 3. Applicability Statement . . . . . . . . . . . . . . . . . . . 5 55 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 5 56 4.1 General requirements . . . . . . . . . . . . . . . . . . . 5 57 4.2 Host requirements . . . . . . . . . . . . . . . . . . . . 5 58 4.3 Signalling requirements . . . . . . . . . . . . . . . . . 6 59 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 60 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 61 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 62 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 63 8.1 Normative References . . . . . . . . . . . . . . . . . . . 7 64 8.2 Informative References . . . . . . . . . . . . . . . . . . 8 65 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 8 66 Intellectual Property and Copyright Statements . . . . . . . . 10 68 1. Introduction 70 Many multi-party applications make use of multicast. Multicast 71 offers obvious benefits when one party is sending the same content to 72 multiple receivers. Also traditional multicast [3] allows for a 73 multi-party session to be identified by a single group address. 75 Any participant can send to the group without knowing who the 76 receivers are, and all receivers can join the group without knowing 77 who will send. This means for e.g. a video conference, one only 78 needs to give the multicast group address to potential participants, 79 possibly making a public announcement. Participants can then come 80 and go as they like, and those that happen to be sending to or 81 receiving from the group address simultaneously will be able to reach 82 each other. 84 There are several problems with traditional multicast [6] and it's 85 widely believed that Source-Specific Multicast (SSM) [1] is a more 86 scalable and easier to deploy interdomain multicast technology in the 87 long term. One of the simplifications of SSM is that source 88 discovery is not done in the network. It's however precisely the 89 network source discovery (typically using MSDP and Rendezvous-points) 90 that allows anyone to start sending at any point and the receivers to 91 get the data without knowing who the sources are. 93 SSM requires the application to specify exactly which sources it will 94 receive data from. The source addresses must somehow be learned by 95 the receivers out-of-band. With traditional multicast the multicast 96 group to use must be announced out-of-band before the session is to 97 take place. It may be announced using e.g. SDP over HTTP or SAP. 98 For SSM one could also list the addresses of the sources. This works 99 well where all the sources (participants) are known in advance, but 100 this will often not be the case. Also when announcing a multi-party 101 session publicly and allowing anyone to join, there should be a 102 simple mechanism for registering a participant and getting it 103 announced to the others. This draft defines the basic requirements 104 for such functionality. 106 2. Problem Statement 108 As illustrated in the table 1, various multicast applications 109 requirements may require different degree of dynamics in the source 110 discovery process. Existing and future applications require an out 111 of band multicast source discovery mechanism which ideally offers the 112 same level of performances than the current ASM architecture is 113 offering now by in-band means. Distributed Interactive Simulation 114 (D.I.S) [4] is a good example of applications which require a very 115 high level of performance from multicast source discovery. 117 .-------------------------------------------------------------------. 118 |Applications type|Potential transient degree |Current solution for| 119 | |of the sources |for source discovery| 120 .-------------------------------------------------------------------. 121 |Games, D.I.S |High (measured in seconds) |ASM or client-server| 122 .-------------------------------------------------------------------. 123 |Distributed |High |client-server | 124 |File Sharing | | | 125 .-------------------------------------------------------------------. 126 |Conferencing |Medium (measured in minutes)|ASM or client-server| 127 .-------------------------------------------------------------------. 128 |TV/Radio |Low (measured in days) |Static publishing | 129 .-------------------------------------------------------------------. 131 Table 1 : Transient degree of various potential multicast 132 applications. 134 Today most of the multi-party applications containing transient 135 source of data are client-server based and do not take advantage of 136 IP multicast for source discovery. This limits their efficiency and 137 scalability. 139 Operational experience and analysis [2] have shown that current ASM 140 model implemented with MSDP [5] for source discovery has severe 141 scaling and security problems in inter-domain scale. In addition to 142 MSDP there are other problems with the RP based source discovery 143 mechanisms like deployment of new mechanisms into routers, RP as the 144 traffic congestion point and insufficient support for both IP 145 versions. 147 SSM model provides good scaling and security properties and works for 148 both IP versions, but does not provide direct support for source 149 discovery. a typical application that requires discovery of sources 150 during the session is video conferencing. The solution for discovery 151 of new sources during the ongoing session should be standardized for 152 several reasons: 154 o Clients from different origins/vendors may participate in the same 155 multicast session. 157 o Without a standardized solution application writers may decide to 158 solve this problem in different non-compatible ways. 160 o Source discovery must be manageable, so we need a standard that is 161 stable and can be managed/monitored (e.g. to prevent DoS attacks 162 against the multicast infrastructure). 164 In any cases this source discovery standard will facilitate the 165 multi-source multicast applications writers to produce new 166 applications with less cost and wider compatibility across the 167 Internet. The multi-source multicast applications deployment effort 168 can be improved by such a solution. 170 3. Applicability Statement 172 The source discovery mechanism and its requirements only need that 173 the underlying network supports SSM natively end-to-end. The source 174 discovery mechanism is intended to work in both inter-domain and 175 intra-domain cases. The source discovery mechanism should provide 176 required SSM channel information to receivers. Other application 177 specific discovery requirements are out-of-scope (e.g. discovery of 178 source bandwidth, supported codecs, identification, etc.). 180 4. Requirements 182 This section lists the requirements for discovery of dynamic SSM 183 sources. The requirements are separated into general, host and 184 signalling parts. 186 4.1 General requirements 188 1. Solution must provide discovery of dynamic SSM sources during the 189 session, offering a comparable level of performance to the 190 current ASM architecture. 192 2. Solution shouldn't introduce additional requirements on the 193 network (in addition to SSM support). 195 3. Solution must work in SSM address space. 197 4. Solution should be easily manageable and provide good security 198 and control properties. 200 5. Solution should allow co-existence with other source discovery 201 mechanisms. 203 6. Gradual deployment must be possible without affecting the 204 operation of other SSM hosts. 206 7. Adding AAA and related functionalities (e.g. source access 207 control) must be possible. 209 4.2 Host requirements 211 1. Source discovery functionality must have at least three different 212 separatable elements; source, receiver and rendezvous elements. 213 Sources are required to register themselves to discovery 214 process. Receivers are required to understand source discovery 215 signalling. Rendezvous function is needed between sources and 216 receivers for matchmaking and control purposes, a common point 217 source discovery signalling. 219 2. Multiple applications and users on the same host must be able to 220 use the source discovery functionality. 222 3. A group of users must be able to set up their own rendezvous 223 function. 225 4. Rendezvous functionality must be able to work in routers and/or 226 in specific hosts if needed for redundancy, availability and 227 control purposes. 229 5. Rendezvous function should be possible to implement in the SSM 230 application itself. 232 6. Overhead of being rendezvous must not be too big in terms of 233 processing power, memory or signalling traffic consumption. 235 7. It must be possible to add rendezvous fallback and load-sharing 236 properties (these functions are not part of the basic 237 requirement set). 239 8. Registering sources to discovery process must be as simple as 240 possible. 242 9. There shouldn't be additional hypothesis on the receivers than 243 SSM already brings. 245 10. Discovery mechanism should provide enough information on the 246 sources that non-active sources and respective SSM channels can 247 be teared down by the receivers. 249 4.3 Signalling requirements 251 1. Source discovery signalling must be separated from the actual 252 multicast traffic to achieve the following advantages: 254 * Allow path setup before actual traffic is sent (also initial 255 multicast packet gets delivered to receivers). 257 * Allow multicast traffic patterns to be different from source 258 discovery. Sources might send at low or high rates 259 independent of signalling rate. Also the source discovery 260 signalling might be periodical but not necessarily the traffic 261 itself. 263 * While signalling may go via a central control point the 264 multicast traffic should always take the optimal path (no 265 traffic congestion point). 267 2. Signalling architecture must be robust. Information about new 268 sources must be distributed to receivers in less than 1 second. 269 New receivers must get the complete source information in less 270 than 15 seconds (worst case). 272 3. Discovery mechanism must support both IP versions. 274 4. Minimum amount of extra state in routers for source discovery. 276 5. Discovery should use multicast where possible, to reduce the 277 overhead of hosting rendezvous function. 279 6. Standardized and available mechanisms and protocols should be 280 used where appropriate. 282 7. Source discovery signalling should not necessarily be 283 centralized, the rendezvous function may be distributed across 284 the network to improve the robustness of the mechanism. 286 5. Security Considerations 288 This document specifies requirements for source discovery and 289 introduces no new security threats. Security is an important aspect 290 when deciding on a solution. 292 6. IANA Considerations 294 This document has no actions for IANA. 296 7. Acknowledgements 298 Thanks to Jean-Jacques Pansiot and Pekka Savola for review and 299 constructive comments. 301 8. References 303 8.1 Normative References 305 [1] Bhattacharyya, S., "An Overview of Source-Specific Multicast 306 (SSM)", RFC 3569, July 2003. 308 8.2 Informative References 310 [2] Rajvaidya, P., Ramachandran, K. and K. Almeroth, "Detection and 311 Deflection of DoS Attacks Against the Multicast Source Discovery 312 Protocol", IEEE Infocom 2003. 314 [3] Deering, S., "Host extensions for IP multicasting", STD 5, 315 RFC 1112, August 1989. 317 [4] Pullen, J., Myjak, M. and C. Bouwens, "Limitations of Internet 318 Protocol Suite for Distributed Simulation the Large Multicast 319 Environment", RFC 2502, February 1999. 321 [5] Fenner, B. and D. Meyer, "Multicast Source Discovery Protocol 322 (MSDP)", RFC 3618, October 2003. 324 [6] Savola, P., "IPv6 Multicast Deployment Issues", 325 Internet-Draft draft-ietf-mboned-ipv6-multicast-issues-01, 326 September 2004. 328 Authors' Addresses 330 Rami Lehtonen 331 TeliaSonera 332 Hataanpaan valtatie 20 333 Tampere 33100 334 Finland 336 Email: rami.lehtonen@teliasonera.com 338 Stig Venaas 339 University of Southampton 340 School of Electronics and Computer Science 341 Southampton, Hampshire SO17 1BJ 342 United Kingdom 344 Email: stig.venaas@uninett.no 345 Mickael Hoerdt 346 University Louis Pasteur - LSIIT 347 C422 - Pole API - Boulevard Sebastien Brant 348 67400 ILLKIRCH Cedex 349 France 351 Email: hoerdt@clarinet.u-strasbg.fr 353 Intellectual Property Statement 355 The IETF takes no position regarding the validity or scope of any 356 Intellectual Property Rights or other rights that might be claimed to 357 pertain to the implementation or use of the technology described in 358 this document or the extent to which any license under such rights 359 might or might not be available; nor does it represent that it has 360 made any independent effort to identify any such rights. Information 361 on the procedures with respect to rights in RFC documents can be 362 found in BCP 78 and BCP 79. 364 Copies of IPR disclosures made to the IETF Secretariat and any 365 assurances of licenses to be made available, or the result of an 366 attempt made to obtain a general license or permission for the use of 367 such proprietary rights by implementers or users of this 368 specification can be obtained from the IETF on-line IPR repository at 369 http://www.ietf.org/ipr. 371 The IETF invites any interested party to bring to its attention any 372 copyrights, patents or patent applications, or other proprietary 373 rights that may cover technology that may be required to implement 374 this standard. Please address the information to the IETF at 375 ietf-ipr@ietf.org. 377 Disclaimer of Validity 379 This document and the information contained herein are provided on an 380 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 381 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 382 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 383 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 384 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 385 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 387 Copyright Statement 389 Copyright (C) The Internet Society (2005). This document is subject 390 to the rights, licenses and restrictions contained in BCP 78, and 391 except as set forth therein, the authors retain all their rights. 393 Acknowledgment 395 Funding for the RFC Editor function is currently provided by the 396 Internet Society.