idnits 2.17.1 draft-waehlisch-sam-common-api-02.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 : ---------------------------------------------------------------------------- ** There are 4 instances of too long lines in the document, the longest one being 3 characters in excess of 72. == There are 1 instance of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. == There are 1 instance of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 392 has weird spacing: '...terface denot...' == Line 397 has weird spacing: '...tHandle refer...' == Line 485 has weird spacing: '... scheme refer...' == Line 488 has weird spacing: '... group ident...' == Line 490 has weird spacing: '...tiation ident...' == (2 more instances...) -- The document date (March 8, 2010) is 5162 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2119' is defined on line 531, but no explicit reference was found in the text == Outdated reference: A later version (-18) exists of draft-ietf-mboned-auto-multicast-10 -- Obsolete informational reference (is this intentional?): RFC 4395 (Obsoleted by RFC 7595) -- Obsolete informational reference (is this intentional?): RFC 4601 (Obsoleted by RFC 7761) Summary: 2 errors (**), 0 flaws (~~), 11 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SAM Research Group M. Waehlisch 3 Internet-Draft link-lab & FU Berlin 4 Intended status: Informational T C. Schmidt 5 Expires: September 9, 2010 HAW Hamburg 6 S. Venaas 7 cisco Systems 8 March 8, 2010 10 A Common API for Transparent Hybrid Multicast 11 draft-waehlisch-sam-common-api-02 13 Abstract 15 Group communication services are most efficiently implemented on the 16 lowest layer available. However, as the deployment status of 17 multicast technologies largely varies throughout the Internet, 18 globally operational group solutions are frequently forced to using a 19 stable, upper layer protocol controlled by the application itself. 20 This document describes a common multicast API that is suitable for 21 transparent underlay and overlay communication. It proposes abstract 22 naming and addressing by multicast URIs and discusses mapping 23 mechanisms between different namespaces and distribution 24 technologies. Additionally, it describes the application of this API 25 for building gateways that interconnect current multicast domains 26 throughout the Internet. 28 Status of this Memo 30 This Internet-Draft is submitted to IETF 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), its areas, and its working groups. Note that 35 other groups may also distribute working documents as Internet- 36 Drafts. 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 The list of current Internet-Drafts can be accessed at 44 http://www.ietf.org/ietf/1id-abstracts.txt. 46 The list of Internet-Draft Shadow Directories can be accessed at 47 http://www.ietf.org/shadow.html. 49 This Internet-Draft will expire on September 9, 2010. 51 Copyright Notice 53 Copyright (c) 2010 IETF Trust and the persons identified as the 54 document authors. All rights reserved. 56 This document is subject to BCP 78 and the IETF Trust's Legal 57 Provisions Relating to IETF Documents 58 (http://trustee.ietf.org/license-info) in effect on the date of 59 publication of this document. Please review these documents 60 carefully, as they describe your rights and restrictions with respect 61 to this document. Code Components extracted from this document must 62 include Simplified BSD License text as described in Section 4.e of 63 the Trust Legal Provisions and are provided without warranty as 64 described in the BSD License. 66 Table of Contents 68 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 69 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 70 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 71 3.1. Objectives and Reference Scenarios . . . . . . . . . . . . 5 72 3.2. Group Communication Stack & API . . . . . . . . . . . . . 6 73 3.3. Mapping . . . . . . . . . . . . . . . . . . . . . . . . . 8 74 3.4. Naming and Addressing . . . . . . . . . . . . . . . . . . 9 75 4. Hybrid Multicast API . . . . . . . . . . . . . . . . . . . . . 9 76 4.1. Abstract Data Types . . . . . . . . . . . . . . . . . . . 9 77 4.2. Send/Receive Calls . . . . . . . . . . . . . . . . . . . . 10 78 4.3. Socket Options . . . . . . . . . . . . . . . . . . . . . . 10 79 4.4. Service Calls . . . . . . . . . . . . . . . . . . . . . . 10 80 5. Functional Details . . . . . . . . . . . . . . . . . . . . . . 11 81 5.1. Mapping . . . . . . . . . . . . . . . . . . . . . . . . . 11 82 5.2. URI Scheme . . . . . . . . . . . . . . . . . . . . . . . . 11 83 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 84 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 85 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 86 9. Informative References . . . . . . . . . . . . . . . . . . . . 12 87 Appendix A. Practical Example of the API . . . . . . . . . . . . 13 88 Appendix B. Deployment Use Cases for Hybrid Multicast . . . . . . 15 89 B.1. DVMRP . . . . . . . . . . . . . . . . . . . . . . . . . . 15 90 B.2. PIM-SM . . . . . . . . . . . . . . . . . . . . . . . . . . 15 91 B.3. PIM-SSM . . . . . . . . . . . . . . . . . . . . . . . . . 16 92 B.4. BIDIR-PIM . . . . . . . . . . . . . . . . . . . . . . . . 17 93 Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 17 94 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 96 1. Introduction 98 Currently, group application programmers need to make a choice of the 99 distribution technology required at runtime. There is no common 100 communication interface that abstracts multicast subscriptions from 101 the underlying deployment. The standard multicast socket options 102 [RFC3493], [RFC3678] are bound to an IP version and do not 103 distinguish between naming and addressing of multicast identifiers. 104 Group communication, however, is commonly implemented in different 105 flavors and on different layers (e.g., IP vs. application layer 106 multicast), and may be based on different technologies on the same 107 tier (e.g., IPv4 vs. IPv6). 109 Multicast application development should be decoupled of 110 technological deployment throughout the infrastructure. It requires 111 a common multicast API that offers calls to transmit and receive 112 multicast data independent of the supporting layer and the underlying 113 technological details. For inter-technology transmissions, a 114 consistent view on multicast states is needed, as well. This 115 document describes an abstract group communication API and core 116 functions necessary for transparent operations. Specific 117 implementation guidelines with respect to operating systems or 118 programming languages are out-of-scope of this document. 120 In contrast to the standard multicast socket interface, the API 121 introduced in this document abstracts naming and addressing. Using a 122 multicast address in the current socket API predefines the 123 corresponding routing layer. In this memo, the multicast address 124 used for joining a group denotes an application layer data stream 125 that is identified by a multicast URI and without an association to 126 the underlying distribution technology. Group name can be mapped to 127 variable routing identifiers. 129 The aim of this common API is twofold: 131 o Enable any application programmer to implement group-oriented data 132 communication independent of the underlying delivery mechanisms. 133 In particular, allow for a late binding of group applications to 134 multicast technologies that makes applications efficient, but 135 robust with respect to deployment aspects. 137 o Allow for a flexible namespace support in group addressing, and 138 thereby separate naming and addressing/routing schemes from the 139 application design. This abstraction not only reduces the 140 dependency on specific apects of underlying protocols, but may 141 open application design to extend to specifically flavored group 142 services. 144 Multicast technologies may be various P2P-based, IPv4 or IPv6 network 145 layer multicast, or implemented by some other application service. 146 Corresponding namespaces may be IP addresses, overlay hashes, other 147 application layer group identifiers, e.g., , or 148 names defined by the applications. 150 This document also proposes and discusses mapping mechanisms between 151 different namespaces and forwarding technologies. Additionally, the 152 multicast API provides internal interfaces to access current 153 multicast states at the host. Multiple multicast protocols may run 154 in parallel on a single host. These protocols may interact to 155 provide a gateway function that bridges data between different 156 domains. The application of this API at gateways operating between 157 current multicast instances throughout the Internet is described, as 158 well. 160 2. Terminology 162 This document uses the terminology as defined for the multicast 163 protocols [RFC2710],[RFC3376],[RFC3810],[RFC4601],[RFC4604]. In 164 addition, the following terms will be used. 166 Group Address: A Group Address is a routing identifier. It 167 represents a technological identifier and thus reflects the 168 distribution technology in use. Multicast packet forwarding is 169 based on this ID. 171 Group Name: A Group Name is an application identifier that is used 172 by applications to manage (e.g., join/leave and send/receive) a 173 multicast group. The Group Name does not imply any distribution 174 technologies but represents a logical identifier. 176 Multicast Namespace: A Multicast Namespace is a collection of 177 designators (i.e., names or addresses) for groups that share a 178 common syntax. Typical instances of namespaces are IPv4 or IPv6 179 multicast addresses, overlay group ids, group names defined on the 180 application layer (e.g., SIP or Email), or some human readable 181 strings. 183 Multicast Domain: A Multicast Domain accommodates nodes and routers 184 of a common, single multicast forwarding technology and is bound 185 to a single namespace. 187 Interface An Interface is a forwarding instance of a distribution 188 technology on a given node. For example, the IP interface 189 192.168.1.1 at an IPv4 host. 191 Inter-domain Multicast Gateway: An Inter-domain Multicast Gateway 192 (IMG) is an entity that interconnects different multicast domains. 193 Its objective is to forward data between these domains, e.g., 194 between IP layer and overlay multicast. 196 3. Overview 198 3.1. Objectives and Reference Scenarios 200 The default use case addressed in this memo targets at applications 201 that participate in a group by using a common identifier taken from 202 some common namespace. Programmers should be able to transparently 203 use this identifier in their program without the need to consider a 204 deployment status in target domains. Aided by gateways and, where 205 available, by a node-specific multicast middleware, applications 206 shall be enabled to establish group communication, even if resident 207 in domains that are not connected by a common multicast service 208 technology. 210 This document covers the following two general scenarios: 212 1. Multicast domains running the same multicast technology but 213 remaining isolated, possibly only connected by network layer 214 unicast. 216 2. Multicast domains running different multicast technologies, but 217 hosting nodes that are members of the same multicast group. 219 +-------+ +-------+ 220 | Member| | Member| 221 | Foo | | G | 222 +-------+ +-------+ 223 \ / 224 *** *** *** *** 225 * ** ** ** * 226 * * 227 * MCast Tec A * 228 * * 229 * ** ** ** * 230 *** *** *** *** 231 +-------+ +-------+ | 232 | Member| | Member| +-------+ 233 | G | | Foo | | IMG | 234 +-------+ +-------+ +-------+ 235 | | | 236 *** *** *** *** *** *** *** *** 237 * ** ** ** * * ** ** ** * 238 * * +-------+ * * 239 * MCast Tec A * --| IMG |-- * MCast Tec B * +-------+ 240 * * +-------+ * * - | Member| 241 * ** ** ** * * ** ** ** * | G | 242 *** *** *** *** *** *** *** *** +-------+ 244 Figure 1: Reference scenarios for hybrid multicast, interconnecting 245 group members from isolated homogeneous and heterogeneous domains. 247 It is assumed throughout the document that the domain composition, as 248 well as the node attachement to a specific technology remain 249 unchanged during a multicast session. 251 3.2. Group Communication Stack & API 253 Multicast applications may use a group communication stack to deliver 254 and receive multicast data. This group communication stack exhibits 255 two tasks: 257 o It provides an extended API that supports a common multicast 258 interface with namespace support. 260 o It bridges data between different multicast technologies. 262 The group communication API consists of three parts: (1) Send/Receive 263 Calls, (2) Socket Options, and (3) Service Calls. (1) provides a 264 minimal API to initiate a multicast socket, send and receive 265 multicast data in a technology-transparent fashion. (2) allows for 266 the configuration of the multicast socket, i.e., setting path length 267 and associate interfaces explicitly. (3) returns internal multicast 268 states per interface such as the multicast groups under subscription. 270 The general procedure to initiate multicast communication is the 271 following: 273 1. An application opens a multicast socket. 275 2. An application subscribes/leaves/sends to a logical group 276 identifier. 278 3. A function maps the logical group ID (Group Name) to a technical 279 group ID (Group Address). 281 4. The technical group ID is allocated or revised if already in use. 283 The multicast socket describes a group communication channel composed 284 of one or multiple interfaces. A socket may be created without 285 explicit interface association by the application, which leaves the 286 choice of the underlying forwarding technology to the group 287 communication stack. However, an application may also bind the 288 socket to one or multiple dedicated interfaces, which predefines the 289 forwarding technology and the namespace(s) of the Group Address(es). 291 Applications are not required to maintain states for Group Addresses. 292 The group communication stack accounts for the mapping of the Group 293 Name to the Group Address(es) and vice versa. Multicast data passed 294 to the application will be augmented by the corresponding Group Name. 295 Multiple multicast subscriptions thus can be conducted on a single 296 multicast socket without the need for Group Name encoding at the 297 application side. 299 Hosts may support several multicast protocols. The group 300 communication stack discovers available multicast-enabled 301 communication interfaces. It provides a minimal hybrid function that 302 bridges data between different interfaces and multicast domains. 303 Details of service discovery are out-of-scope of this document. 305 The extended multicast functions can be implemented by a middleware, 306 for example. 308 *-------* *-------* 309 | App 1 | | App 2 | 310 *-------* *-------* 311 | | 312 *---------------------* ---| 313 | Middleware | | 314 *---------------------* | 315 | | | 316 *---------* | | 317 | Overlay | | \ Group Communication 318 *---------* | / Stack 319 | | | 320 | | | 321 *---------------------* | 322 | Underlay | | 323 *---------------------* ---| 325 Figure 2: The middleware covers underlay and overlay for the 326 application 328 3.3. Mapping 330 A mapping is required between a Group Name and the Group Address 331 space, as well as between Group Addresses in different namespaces. 333 Two (or more) identifiers in different namespaces may belong to 335 a. the same multicast channel (i.e., same technical ID). 337 b. different multicast channels (i.e., different technical IDs). 339 This decision can be solved based on invertible mappings. However, 340 the application of such functions depends on the cardinality of the 341 namespaces and thus does not hold in general. A large identifier 342 space (e.g., IPv6) cannot obviously be mapped to a smaller set (e.g., 343 IPv4). 345 A mapping can be realized by embedding smaller in larger namespaces 346 or selecting an arbitrary, unused ID in the target space. The 347 relation between logical and technical ID is stored based on a 348 mapping service (e.g., DHT). The middleware thus queries the mapping 349 service first, and creates an new technical group ID only if there is 350 no identifier available for the namespace in use. The Group Name is 351 associated with one or more Group Addresses, which belong to 352 different namespaces. Depending on the scope of the mapping service, 353 it ensures a consistent use of the technical ID in a local or global 354 domain. 356 All group members subscribe to the same Group Name within the same 357 namespace. 359 3.4. Naming and Addressing 361 The Group Name is used by applications to identify groups. It hides 362 the deployed technology employed to distribute data. In contrast to 363 this, multicast forwarding operates on Group Addresses. Although 364 both identifiers may be identical in symbols, they carry different 365 meaning. They may also belong to different namespaces. The 366 namespace of the Group Address reflects the routing technology, and 367 the namespace of the Group Name represents the context in which the 368 application operates. 370 A multicast socket (IPv4/v6 interface) can be used by multiple 371 logical multicast IDs from different namespaces (IPv4-group address, 372 IPv6-group address). In practice, a library that implements the 373 defined API would provide high-level data types to the application 374 similar to the current socket API (e.g., InetAddress in Java). Using 375 this data type would implicitly determine the namespace. 377 To reflect namespace specific treatment for applications, identifiers 378 in API calls are represented by URIs. An implementation of the API 379 may provide convenience functions that detect the namespace of a 380 Group Name (e.g., InetAddress instead of Inet6Address and 381 Inet4Address). Details of automatic identifcation is out-of-scope of 382 this document. 384 4. Hybrid Multicast API 386 4.1. Abstract Data Types 388 URI is any kind of Group Address or Group Name that follows the 389 syntax defined in Section 5.2. For example, ipv4://224.1.2.3:5000 390 and sip://news@cnn.com. 392 Interface denotes the interface and thus the layer and instance on 393 which the corresponding call will be effective. This may be 394 unspecified to leave the decicision to the group communication 395 stack. 397 SocketHandle references on an instance of a multicast socket. 399 4.2. Send/Receive Calls 401 init(out SocketHandle h, [in enum Interface i] This call initiates a 402 multicast socket and provides the application programmer with a 403 corresponding handle. If no interfaces will be assigned based on 404 the call, the default interface will be selected and associated 405 with the socket. The call may return an error code in the case of 406 failures, e.g., due to a non-operational middleware. 408 join(in SocketHandle h, in URI g, [in Interface i]) This operation 409 initiates a group subscription. Depending on the interfaces that 410 are associated with the socket , this may result in an IGMP/MLD 411 report or overlay subscriptions. 413 leave(in SocketHandle h, in URI g, [in Interface i]) This operation 414 results in an unsubscription for the given address. 416 send(in SocketHandle h, in URI g, in Message msg) This call passes 417 multicast data for a Multicast Name g from the application to the 418 multicast socket. 420 receive(in SocketHandle h, out URI g, out Message msg) This call 421 passes multicast data and the corresponding Group Name g to the 422 application. 424 4.3. Socket Options 426 getInterfaces(out enum Interface i) This call returns a list of all 427 available multicast communication interfaces at the current host. 429 addInterface(in SocketHandle h, in Interface i) This call adds a 430 distribution channel to the socket. This may be an overlay or 431 underlay interface, e.g., IPv6 or DHT. Multiple interfaces of the 432 same technology may be associated with the socket. 434 delInterface(in SocketHandle h, in Interface i) This call removes an 435 interface from the socket. 437 setTTL(in SocketHandle h) This function configures the maximum hop 438 count for the socket h a multicast message is allowed to traverse. 440 4.4. Service Calls 442 groupSet(out enum URI g, in Interface i) This operation returns all 443 registered multicast groups. The information can be provided by 444 group management or routing protocols. The return values 445 distinguish between sender and listener states. 447 neighborSet(out enum URI g, in Interface i) This function can be 448 invoked to get the set of multicast routing neighbors. 450 designatedHost(out Bool b, in URI g) This function returns true, if 451 the host has the role of a designated forwarder or querier. Such 452 an information is provided by almost all multicast protocols to 453 handle packet duplication, if multiple multicast instances serve 454 on the same subnet. 456 updateListener(out URI g, in Interface i) This upcall is invoked to 457 inform a group service about a change of listener states for a 458 group. This is the result of receiver new subscriptions or 459 leaves. The group service may call groupSet to get updated 460 information. 462 5. Functional Details 464 In this section, we describe the functional details of the API and 465 the middleware. 467 TODO 469 5.1. Mapping 471 Group Name to Group Address, SSM/ASM TODO 473 5.2. URI Scheme 475 Multicast Names and Multicast Addresses are described based on a URI 476 scheme. The scheme defines a subset of the URI specified in 477 [RFC3986] and follows the guidelines in [RFC4395]. 479 The multicast URI is defined as follows: 481 scheme "://" group "@" instantiation ":" port "/" sec-credentials 483 The parts of the URI are defined as follows: 485 scheme referes to the specification of the assigned identifier 486 [RFC3986]. 488 group identifies the group. 490 instantiation identifies the entitiy that generates the instance of 491 the group (e.g., a SIP domain or a source in SSM). 493 port identifies a specific application at an instance of a group. 495 sec-credentials used to implement security credentials (e.g., to 496 authorize a multicast group access). 498 TODO 500 6. IANA Considerations 502 This document makes no request of IANA. 504 7. Security Considerations 506 This draft does neither introduce additional messages nor novel 507 protocol operations. TODO 509 8. Acknowledgements 511 We would like to thank the HAMcast-team (Dominik Charousset, Gabriel 512 Hege, Fabian Holler, Alexander Knauf, Sebastian Meiling, and 513 Sebastian Woelke) at the HAW Hamburg for fruitful discussions. 515 This work is partially supported by the German Federal Ministry of 516 Education and Research within the HAMcast project, which is part of 517 G-Lab. 519 9. Informative References 521 [I-D.ietf-mboned-auto-multicast] 522 Thaler, D., Talwar, M., Aggarwal, A., Vicisano, L., and T. 523 Pusateri, "Automatic IP Multicast Without Explicit Tunnels 524 (AMT)", draft-ietf-mboned-auto-multicast-10 (work in 525 progress), March 2010. 527 [RFC1075] Waitzman, D., Partridge, C., and S. Deering, "Distance 528 Vector Multicast Routing Protocol", RFC 1075, 529 November 1988. 531 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 532 Requirement Levels", BCP 14, RFC 2119, March 1997. 534 [RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast 535 Listener Discovery (MLD) for IPv6", RFC 2710, 536 October 1999. 538 [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. 539 Thyagarajan, "Internet Group Management Protocol, Version 540 3", RFC 3376, October 2002. 542 [RFC3493] Gilligan, R., Thomson, S., Bound, J., McCann, J., and W. 543 Stevens, "Basic Socket Interface Extensions for IPv6", 544 RFC 3493, February 2003. 546 [RFC3678] Thaler, D., Fenner, B., and B. Quinn, "Socket Interface 547 Extensions for Multicast Source Filters", RFC 3678, 548 January 2004. 550 [RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery 551 Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. 553 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 554 Resource Identifier (URI): Generic Syntax", STD 66, 555 RFC 3986, January 2005. 557 [RFC4395] Hansen, T., Hardie, T., and L. Masinter, "Guidelines and 558 Registration Procedures for New URI Schemes", BCP 35, 559 RFC 4395, February 2006. 561 [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, 562 "Protocol Independent Multicast - Sparse Mode (PIM-SM): 563 Protocol Specification (Revised)", RFC 4601, August 2006. 565 [RFC4604] Holbrook, H., Cain, B., and B. Haberman, "Using Internet 566 Group Management Protocol Version 3 (IGMPv3) and Multicast 567 Listener Discovery Protocol Version 2 (MLDv2) for Source- 568 Specific Multicast", RFC 4604, August 2006. 570 [RFC5015] Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano, 571 "Bidirectional Protocol Independent Multicast (BIDIR- 572 PIM)", RFC 5015, October 2007. 574 Appendix A. Practical Example of the API 575 -- Application above middleware: 577 //Initialize multicast socket; the middleware selects all available 578 //interfaces 579 MulticastSocket m = new MulticastSocket(); 581 URI mcAddressv4 = new URI("ipv4://224.1.2.3:5000"); 582 m.join(mcAddressv4); 584 URI mcAddressv6 = new URI("ipv6://[FF02:0:0:0:0:0:0:3]:6000"); 585 m.join(mcAddressv6) 587 URI mcAddressSIP = new URI("sip://news@cnn.com"); 588 m.join(mcAddressSIP) 590 -- Middleware: 592 join(URI mcAddress) { 593 //Select interfaces in use 594 for all this.interfaces { 595 switch (interface.type) { 596 case "ipv6": 597 //... map logical ID to routing address 598 Inet6Address rtAddressIPv6 = new Inet6Address() 599 mapNametoAddress(mcAddress,rtAddressIPv6) 600 interface.join(rtAddressIPv6) 601 case "ipv4": 602 //... map logical ID to routing address 603 Inet4Address rtAddressIPv4 = new Inet4Address() 604 mapNametoAddress(mcAddress,rtAddressIPv4) 605 interface.join(rtAddressIPv4) 606 case "sip": 607 //... map logical ID to routing address 608 SIPAddress rtAddressSIP = new SIPAddress() 609 mapNametoAddress(mcAddress,rtAddressSIP) 610 interface.join(rtAddressSIP) 611 case "dht": 612 //... map logical ID to routing address 613 DHTAddress rtAddressDHT = new DHTAddress() 614 mapNametoAddress(mcAddress,rtAddressDHT) 615 interface.join(rtAddressDHT) 616 //... 617 } 618 } 619 } 621 Appendix B. Deployment Use Cases for Hybrid Multicast 623 This section describes the application of the defined API to 624 implement an IMG. 626 B.1. DVMRP 628 The following procedure describes a transparent mapping of a DVMRP- 629 based any source multicast service to another many-to-many multicast 630 technology. 632 An arbitrary DVMRP [RFC1075] router will not be informed about new 633 receivers, but will learn about new sources immediately. The concept 634 of DVMRP does not provide any central multicast instance. Thus, the 635 IMG can be placed anywhere inside the multicast region, but requires 636 a DVMRP neighbor connectivity. The group communication stack used by 637 the IMG is enhanced by a DVMRP implementation. New sources in the 638 underlay will be advertised based on the DVMRP flooding mechanism and 639 received by the IMG. Based on this the updateSender() call is 640 triggered. The relay agent initiates a corresponding join in the 641 native network and forwards the received source data towards the 642 overlay routing protocol. Depending on the group states, the data 643 will be distributed to overlay peers. 645 DVMRP establishes source specific multicast trees. Therefore, a 646 graft message is only visible for DVMRP routers on the path from the 647 new receiver subnet to the source, but in general not for an IMG. To 648 overcome this problem, data of multicast senders will be flooded in 649 the overlay as well as in the underlay. Hence, an IMG has to 650 initiate an all-group join to the overlay using the namespace 651 extension of the API. Each IMG is initially required to forward the 652 received overlay data to the underlay, independent of native 653 multicast receivers. Subsequent prunes may limit unwanted data 654 distribution thereafter. 656 B.2. PIM-SM 658 The following procedure describes a transparent mapping of a PIM-SM- 659 based any source multicast service to another many-to-many multicast 660 technology. 662 The Protocol Independent Multicast Sparse Mode (PIM-SM) [RFC4601] 663 establishes rendezvous points (RP). These entities receive listener 664 and source subscriptions of a domain. To be continuously updated, an 665 IMG has to be co-located with a RP. Whenever PIM register messages 666 are received, the IMG must signal internally a new multicast source 667 using updateSender(). Subsequently, the IMG joins the group and a 668 shared tree between the RP and the sources will be established, which 669 may change to a source specific tree after a sufficient number of 670 data has been delivered. Source traffic will be forwarded to the RP 671 based on the IMG join, even if there are no further receivers in the 672 native multicast domain. Designated routers of a PIM-domain send 673 receiver subscriptions towards the PIM-SM RP. The reception of such 674 messages invokes the updateListener() call at the IMG, which 675 initiates a join towards the overlay routing protocol. Overlay 676 multicast data arriving at the IMG will then transparently be 677 forwarded in the underlay network and distributed through the RP 678 instance. 680 B.3. PIM-SSM 682 The following procedure describes a transparent mapping of a PIM-SSM- 683 based source specific multicast service to another one-to-many 684 multicast technology. 686 PIM Source Specific Multicast (PIM-SSM) is defined as part of PIM-SM 687 and admits source specific joins (S,G) according to the source 688 specific host group model [RFC4604]. A multicast distribution tree 689 can be established without the assistance of a rendezvous point. 691 Sources are not advertised within a PIM-SSM domain. Consequently, an 692 IMG cannot anticipate the local join inside a sender domain and 693 deliver a priori the multicast data to the overlay instance. If an 694 IMG of a receiver domain initiates a group subscription via the 695 overlay routing protocol, relaying multicast data fails, as data are 696 not available at the overlay instance. The IMG instance of the 697 receiver domain, thus, has to locate the IMG instance of the source 698 domain to trigger the corresponding join. In the sense of PIM-SSM, 699 the signaling should not be flooded in underlay and overlay. 701 One solution could be to intercept the subscription at both, source 702 and receiver sites: To monitor multicast receiver subscriptions 703 (updateListener()) in the underlay, the IMG is placed on path towards 704 the source, e.g., at a domain border router. This router intercepts 705 join messages and extracts the unicast source address S, initializing 706 an IMG specific join to S via regular unicast. Multicast data 707 arriving at the IMG of the sender domain can be distributed via the 708 overlay. Discovering the IMG of a multicast sender domain may be 709 implemented analogously to AMT [I-D.ietf-mboned-auto-multicast] by 710 anycast. Consequently, the source address S of the group (S,G) 711 should be built based on an anycast prefix. The corresponding IMG 712 anycast address for a source domain is then derived from the prefix 713 of S. 715 B.4. BIDIR-PIM 717 The following procedure describes a transparent mapping of a BIDIR- 718 PIM-based any source multicast service to another many-to-many 719 multicast technology. 721 Bidirectional PIM [RFC5015] is a variant of PIM-SM. In contrast to 722 PIM-SM, the protocol pre-establishes bidirectional shared trees per 723 group, connecting multicast sources and receivers. The rendezvous 724 points are virtualized in BIDIR-PIM as an address to identify on-tree 725 directions (up and down). However, routers with the best link 726 towards the (virtualized) rendezvous point address are selected as 727 designated forwarders for a link-local domain and represent the 728 actual distribution tree. The IMG is to be placed at the RP-link, 729 where the rendezvous point address is located. As source data in 730 either cases will be transmitted to the rendezvous point address, the 731 BIDIR-PIM instance of the IMG receives the data and can internally 732 signal new senders towards the stack via updateSender(). The first 733 receiver subscription for a new group within a BIDIR-PIM domain needs 734 to be transmitted to the RP to establish the first branching point. 735 Using the updateListener() invocation, an IMG will thereby be 736 informed about group requests from its domain, which are then 737 delegated to the overlay. 739 Appendix C. Change Log 741 Changes since draft-waehlisch-sam-common-api-01 743 1. TODO 745 Authors' Addresses 747 Matthias Waehlisch 748 link-lab & FU Berlin 749 Hoenower Str. 35 750 Berlin 10318 751 Germany 753 Email: mw@link-lab.net 754 URI: http://www.inf.fu-berlin.de/~waehl 755 Thomas C. Schmidt 756 HAW Hamburg 757 Berliner Tor 7 758 Hamburg 20099 759 Germany 761 Email: schmidt@informatik.haw-hamburg.de 762 URI: http://inet.cpt.haw-hamburg.de/members/schmidt 764 Stig Venaas 765 cisco Systems 766 Tasman Drive 767 San Jose, CA 95134 768 USA 770 Email: stig@cisco.com