idnits 2.17.1 draft-asaeda-mboned-sap-limitation-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 abstract seems to contain references ([2], [7]), 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 seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, 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 6, 2011) is 4799 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 4566 (ref. '3') (Obsoleted by RFC 8866) == Outdated reference: A later version (-09) exists of draft-ietf-fecframe-config-signaling-04 == Outdated reference: A later version (-15) exists of draft-ietf-fecframe-framework-13 Summary: 2 errors (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). 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 7, 2011 INRIA 6 March 6, 2011 8 Limitations of Session Announcement Protocol (SAP) 9 draft-asaeda-mboned-sap-limitation-00 11 Abstract 13 The Session Announcement Protocol (SAP) [2] has historically been 14 used to announce information for all available IP multicast sessions 15 to the prospective receivers in the experimental MBone. Each 16 receiver can then discover which sessions are available and which 17 ones he may want to join. Although SAP is easy to use, SAP is not 18 scalable and controlling the SAP message transmission in a wide area 19 network is not easy. Therefore this document describes the 20 limitations of SAP when used in the global Internet. Furthermore, 21 SAP has recently been used as a convenient method for conveying 22 configuration information to a set of receivers that are already 23 interested by a multicast session (e.g., to carry FEC Framework 24 Configuration Information [7]). This documents describes the 25 limitations of SAP for this type of usage, since this latter is 26 rather different from its original goals. 28 Status of this Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on September 7, 2011. 45 Copyright Notice 47 Copyright (c) 2011 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 This document may contain material from IETF Documents or IETF 61 Contributions published or made publicly available before November 62 10, 2008. The person(s) controlling the copyright in some of this 63 material may not have granted the IETF Trust the right to allow 64 modifications of such material outside the IETF Standards Process. 65 Without obtaining an adequate license from the person(s) controlling 66 the copyright in such materials, this document may not be modified 67 outside the IETF Standards Process, and derivative works of it may 68 not be created outside the IETF Standards Process, except to format 69 it for publication as an RFC or to translate it into languages other 70 than English. 72 Table of Contents 74 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 75 1.1. SAP as a Component of a Session Discovery Mechanism . . . . 4 76 1.2. SAP as a Component of a Configuration Information 77 Transport Mechanism . . . . . . . . . . . . . . . . . . . . 4 78 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 5 79 3. Potential Limitations with SAP . . . . . . . . . . . . . . . . 5 80 3.1. Announcement Interval vs. Latency (SAP as a Session 81 Discovery Mechanism) . . . . . . . . . . . . . . . . . . . 5 82 3.2. Announcement Interval vs. Latency (SAP as a 83 Configuration Information Transport Mechanism) . . . . . . 6 84 3.3. Difficulties in Scope Definition (both SAP Uses) . . . . . 6 85 3.4. ASM Dependency (both SAP Uses) . . . . . . . . . . . . . . 7 86 3.5. Lack of Sender and Receiver Control during 87 Announcements (both SAP Uses) . . . . . . . . . . . . . . . 8 88 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 8 89 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8 90 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 9 91 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 92 7.1. Normative References . . . . . . . . . . . . . . . . . . . 9 93 7.2. Informative References . . . . . . . . . . . . . . . . . . 9 94 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 96 1. Introduction 98 1.1. SAP as a Component of a Session Discovery Mechanism 100 Session configuration information (e.g., IP multicast session or 101 channel information) can be described with the Session Description 102 Protocol (SDP) [3] syntax, or written in a metafile whose format has 103 been defined elsewhere. The Session Announcement Protocol (SAP) [2] 104 has been used to announce information for all available multicast 105 sessions to the prospective receivers in the experimental MBone. In 106 a SAP announcement procedure, the entire session information must be 107 periodically transmitted and all active session descriptions must be 108 continuously refreshed. If ever a session is no longer announced, 109 its description eventually times out and is deleted from the 110 available session list (this is a "soft-state" protocol). 112 SAP enables to keep the session information active by periodically 113 refreshing it, and it provides a robust and fault-tolerant system. 114 However, it requires the periodic message transmission (i.e., message 115 flooding) that may cause major overheads or overloads. Although this 116 strategy keeps the implementation simple, it rises significant 117 overheads which further reduces its scalability. 119 Another issue is closely related to a security or policy management. 120 Indeed, using SAP and existing scoping techniques make it difficult 121 to control precisely the amount of traffic distributed as well as the 122 distribution area itself. 124 This document describes the limitations of SAP when used in the 125 global Internet, inspired by the work originally published by the 126 authors in [6]. 128 1.2. SAP as a Component of a Configuration Information Transport 129 Mechanism 131 More recently SAP has been used as a convenient method for conveying 132 configuration information to a set of receivers that are already 133 interested in a multicast session (e.g., these receivers have 134 obtained the content description through another mechanism and have 135 decided to join the session). For instance SAP can be used to convey 136 the FEC Framework Configuration Information (FFCI) of a given 137 FECFRAME Instance [7]. The FFCI is the information that the FEC 138 Framework needs in order to apply FEC protection to the upper 139 application flows [8]. Said differently, this FFCI defines the way 140 the packets containing encoding symbols (e.g., result of a Reed- 141 Solomon encoding) are generated from one or several upper application 142 flows (e.g., an RTP stream containing video). This use-case is 143 significantly different from the traditional one since the receivers 144 have already expressed their interest in joining the FECFRAME 145 Instance session and now need to collect additional information on 146 how to exploit the associated flow(s). 148 This document describes the limitations of SAP for this type of usage 149 that is rather different from the original goals of SAP. 151 2. Terminology 153 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 154 NOT","SHOULD", "SHOULD NOT", "RECOMMENDED","MAY", and "OPTIONAL" in 155 this document are to be interpreted as described in RFC 2119 [1]. 157 3. Potential Limitations with SAP 159 3.1. Announcement Interval vs. Latency (SAP as a Session Discovery 160 Mechanism) 162 SAP improves the robustness and data consistency in front of packet 163 losses by periodically transmitting SAP messages. However, 164 transmitting a large number of SAP messages with active multicast 165 session information in a flooding manner may cause major overheads. 166 The solution defined in [2] is the time period between repetitions of 167 an announcement. This period is chosen such that the total bandwidth 168 used by all announcements on a single SAP group remains below a 169 preconfigured limit, and the bandwidth limit should be assumed to be 170 4000 bits per second, if not specified. 172 However, this solution largely increases the latency experienced by 173 end users especially when the number of sessions increases. In its 174 definition, since the minimum interval of SAP message transmission is 175 200 seconds, end users experience a minimum waiting time of 200 176 seconds to obtain the entire session list, irrespective of the number 177 of observed multicast sessions, message size of multicast session 178 information, and bandwidth SAP uses. Let us assume the average 179 message size of a single multicast session information is about 300 180 bytes. When there are more than 500 active multicast sessions, an 181 interval time of each session announcement becomes greater than 200 182 seconds and the average announcement interval increases accordingly. 183 For instance, if 2000 multicast sessions are active in the Internet, 184 each session announcement interval is between 800 seconds and 1600 185 seconds. In this case, if some SAP message is lost, users may need 186 to wait 1600 seconds for the next announcement as maximum. 188 Obviously, it is possible to make the announcement interval shorter 189 by changing the SAP configuration on a sender side and provide 190 shorter latency for the sender-receiver communication. However, it 191 makes the total amount of SAP messages transmitted larger and may 192 increase the probability of creating congestions. 194 3.2. Announcement Interval vs. Latency (SAP as a Configuration 195 Information Transport Mechanism) 197 Using SAP as a configuration information transport mechanism raises 198 the problem of choosing an appropriate announcement interval. The 199 goal of the algorithm introduced in [2] is to control SAP 200 transmission overhead, in particular when the number of active 201 sessions is high and generates a large number of announcements. When 202 SAP is used as a configuration information transport mechanism, the 203 problem is totally different, since SAP is used within a given 204 session and the goal is to ensure that all receivers, including late- 205 comers, retrieve the configuration information (e.g., the FEC 206 Framework Configuration Information) in a timely manner. To achieve 207 this goal it is desired to set up periodic transmissions. For 208 instance, [7] suggests a time interval in the range of 1 - 200 209 seconds that defaults to 60 seconds (to be compared to the one hour 210 minimum implicit timeout duration of SAP). SAP SHOULD enable such a 211 flexibility when defining the announcement interval strategy. 213 A receiver SHOULD be able to determine the validity period of each 214 SAP announcement, since SAP entries are cached by the reaceiver and 215 are automatically discarded at timeout. SAP specifies that the 216 announcement interval can be predicted by the receiver and defines a 217 minimum of one hour for an implicit timeout of the entries, with the 218 goal to allow for transient network partitionings (as described in 219 section 4 of [2]). This approach contradicts the goal of precisely 220 controlling the announcement interval strategy with a possibility to 221 use intervals in the range of a few seconds. Therefore, a solution 222 could be for the SAP sender to communicate the announcement interval 223 being used to the receivers. The current SAP specification does not 224 allow the time-interval to be signaled in the SAP header which 225 requires to include this information within the payload itself (given 226 in [7]), making the technique dependant on the configuration 227 information being transported which is not a desired property. 229 3.3. Difficulties in Scope Definition (both SAP Uses) 231 Multicast data senders or network administrators may want to define 232 an area where data packets sent within a session will be confined. 233 This area is called "scope area" and the end users who belong to this 234 scope area are the only ones who can receive the session data. 236 When IP multicast was initially deployed in the MBone, the Time-To- 237 Live (TTL) field of the IP header was used to control the 238 distribution of multicast traffic. A multicast router configured 239 with a TTL threshold drops any multicast packet in which the TTL 240 falls below the threshold. For instance, a router at the boundary of 241 an organization configures the threshold to 32, which denotes an 242 "organization" scope boundary. 244 The drawbacks of this "TTL scoping" are: 1) the senders must be 245 sufficiently aware of the network topology to determine the TTL value 246 to use, and 2) complex scope areas cannot be defined (e.g., between 247 overlapped areas). Especially the first point becomes big obstacles 248 for general end users to precisely set up the data distribution area. 249 TTL scoping, which only defines a rough granularity, does not provide 250 a complete solution. 252 The "administratively scoped IP multicast" approach [4] provides 253 clear and simple semantics and scope boundaries are associated to 254 multicast addresses. With IPv4, packets addressed to the 255 administratively scoped multicast address range 239/8 (i.e., from 256 239.0.0.0 to 239.255.255.255) cannot cross the configured 257 administrative boundaries. Since scoped addresses are defined 258 locally, the same multicast address can be used in different non- 259 overlapping areas. Oppositely, an administrator can define multiple 260 areas that overlap by dividing the administratively scoped address 261 range, which is not possible with TTL scoping. 263 However, administrative scoping has several major limitations. An 264 administrator may want to partition the scope area to disjoint areas 265 on a per receiver basis, or he may want to limit data distribution 266 according to the transmission rate or the content category of each 267 session, or he may want to use the data sender's address as a keyword 268 to set up the scope. Note that the latter aspect is nowadays 269 feasible since Source-Specific Multicast (SSM) [5] requires that a 270 join request specifies both the multicast and source addresses. 272 SSM highlights another contradiction in the administrative scoping 273 approach: the address range dedicated to SSM, 232/8 with IPv4, cannot 274 cover the address range dedicated to administrative scoping, 239/8. 275 Although the problem can be solved by defining yet another SSM 276 specific administrative scoping address range, defining a new 277 addressing architecture requires modifying application, end host, and 278 router implementations or configurations. Hence, using multicast 279 addresses to define a scope is not a complete solution either. 281 3.4. ASM Dependency (both SAP Uses) 283 SAP relies on the ASM model, since every SAP instance can send 284 announcements in the SAP announcement group. For instance, to 285 receive SAP announcement messages for the global scope IPv4 multicast 286 sessions, all prospective receivers must join session 224.2.127.254 287 (without specifying any source address). This is another major 288 limitation of SAP since some Internet Service Providers (ISPs) may 289 want to provide only SSM multicast routing. It is known that a 290 versatile announcement protocol should not rely on any specific 291 routing architecture. 293 Moreover, this communication model is subject to a Denial-of-Service 294 attack. If malicious hosts flood high bandwidth stream to this 295 global announcement address, 224.2.127.254, then all prospective 296 receivers and multicast routers that listen to SAP messages will 297 receive this high bandwidth flow which will impact their own 298 performance and that of their network. 300 3.5. Lack of Sender and Receiver Control during Announcements (both SAP 301 Uses) 303 Network administrators or service providers may want to define 304 approved senders and restrict multicast data transmissions or 305 announcement only from them. However, in a spontaneous announcement 306 protocol, it is impossible to allow to send announcement messages 307 only from approved senders or make non-approved senders stop sending 308 announcement messages. 310 In addition, it is difficult to hide multicast session information 311 announced by an announcement protocol from non-approved receivers if 312 they are inside the scoped network. For instance, SAP messages might 313 be encrypted to prevent non-authorized client from reading them. 314 However, it adds more complexity to SAP by combining with additional 315 key sharing mechanism. 317 Conceptually, it is difficult to disallow non-approved data receivers 318 to receive session information announced by an announcement protocol, 319 if the announcement data is flooded to their network. It is the 320 basic concept that IP multicast requires scoping configuration to 321 address this issue. However, defining a fine-grained scope areas 322 with using TTL or a multicast address range is a big challenge as 323 described in Section 3.3. 325 4. Security Considerations 327 TBD 329 5. IANA Considerations 331 This document does not require any action from IANA. 333 6. Acknowledgments 335 TBD 337 7. References 339 7.1. Normative References 341 [1] Bradner, S., "Key words for use in RFCs to indicate requirement 342 levels", RFC 2119, March 1997. 344 [2] Handley, M., Perkins, C., and E. Whelan, "Session Announcement 345 Protocol", RFC 2974, October 2000. 347 [3] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 348 Description Protocol", RFC 4566, July 2006. 350 [4] Mayer, D., "Administratively scoped IP multicast", RFC 2365, 351 July 1998. 353 [5] Holbrook, H. and B. Cain, "Source-Specific Multicast for IP", 354 RFC 4607, August 2006. 356 7.2. Informative References 358 [6] Asaeda, H. and V. Roca, "Policy and Scope Management for 359 Multicast Channel Announcement", IEICE Trans. on Information and 360 Systems, Vol.E88-D, No.7, pp.1638-1645, July 2005. 362 [7] Asati, R., "Methods to convey FEC Framework Configuration 363 Information", draft-ietf-fecframe-config-signaling-04 (Work in 364 Progress), January 2011. 366 [8] Watson, M., Begen, A., and V. Roca, "Forward Error Correction 367 (FEC) Framework", draft-ietf-fecframe-framework-13 (Work in 368 Progress), February 2011. 370 Authors' Addresses 372 Hitoshi Asaeda 373 Keio University 374 Graduate School of Media and Governance 375 5322 Endo 376 Fujisawa, Kanagawa 252-0882 377 Japan 379 Email: asaeda@wide.ad.jp 380 URI: http://www.sfc.wide.ad.jp/~asaeda/ 382 Vincent Roca 383 INRIA 384 655, av. de l'Europe 385 Inovalle; Montbonnot 386 ST ISMIER cedex 38334 387 France 389 Email: vincent.roca@inria.fr 390 URI: http://planete.inrialpes.fr/people/roca/