idnits 2.17.1 draft-kolberg-sam-baseline-protocol-01.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 653 has weird spacing: '... Handle gives...' -- The document date (July 12, 2010) is 5036 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC0792' is defined on line 1169, but no explicit reference was found in the text == Unused Reference: 'RFC3376' is defined on line 1175, but no explicit reference was found in the text == Unused Reference: 'RFC3810' is defined on line 1179, but no explicit reference was found in the text == Unused Reference: 'RFC4605' is defined on line 1182, but no explicit reference was found in the text == Unused Reference: 'RFC4607' is defined on line 1187, but no explicit reference was found in the text == Unused Reference: 'CASTRO2002' is defined on line 1199, but no explicit reference was found in the text == Unused Reference: 'CASTRO2003' is defined on line 1207, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-p2psip-sip' is defined on line 1231, but no explicit reference was found in the text == Unused Reference: 'I-D.irtf-p2prg-rtc-security' is defined on line 1236, but no explicit reference was found in the text == Unused Reference: 'I-D.matuszewski-p2psip-security-overview' is defined on line 1247, but no explicit reference was found in the text == Unused Reference: 'RFC1112' is defined on line 1259, but no explicit reference was found in the text == Unused Reference: 'RFC3552' is defined on line 1266, but no explicit reference was found in the text == Outdated reference: A later version (-18) exists of draft-ietf-mboned-auto-multicast-10 == Outdated reference: A later version (-26) exists of draft-ietf-p2psip-base-08 == Outdated reference: A later version (-21) exists of draft-ietf-p2psip-sip-04 == Outdated reference: A later version (-06) exists of draft-waehlisch-sam-common-api-02 Summary: 0 errors (**), 0 flaws (~~), 18 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SAM Research Group J. Buford 3 Internet-Draft Avaya Labs Research 4 Intended status: Informational M. Kolberg, Ed. 5 Expires: January 13, 2011 University of Stirling 6 T C. Schmidt 7 HAW Hamburg 8 M. Waehlisch 9 link-lab & FU Berlin 10 July 12, 2010 12 Application Layer Multicast Extensions to RELOAD 13 draft-kolberg-sam-baseline-protocol-01 15 Abstract 17 We describe protocol and API extensions to P2P-SIP for constructing 18 Scalable Adaptive Multicast (SAM) sessions using hybrid combinations 19 of Application Layer Multicast (ALM), native multicast, and multicast 20 tunnels. We use the AMT relay and gateway elements for 21 interoperation between native regions and ALM regions. The baseline 22 architecture allows different overlay algorithms and different ALM 23 control algorithms to be used. 25 Status of this Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on January 13, 2011. 42 Copyright Notice 44 Copyright (c) 2010 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 61 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 2.1. Overlay Network . . . . . . . . . . . . . . . . . . . . . 5 63 2.2. Overlay Multicast . . . . . . . . . . . . . . . . . . . . 5 64 2.3. Peer . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 65 2.4. Multi-Destination Routing . . . . . . . . . . . . . . . . 5 66 3. Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . 6 67 3.1. Overlay . . . . . . . . . . . . . . . . . . . . . . . . . 6 68 3.2. Overlay Multicast . . . . . . . . . . . . . . . . . . . . 6 69 3.3. RELOAD . . . . . . . . . . . . . . . . . . . . . . . . . . 7 70 3.4. NAT . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 71 3.5. Regions . . . . . . . . . . . . . . . . . . . . . . . . . 7 72 3.6. AMT . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 73 4. Hybrid ALM Tree Operations . . . . . . . . . . . . . . . . . . 8 74 4.1. ALM-Only Tree - Algorithm 1 . . . . . . . . . . . . . . . 10 75 4.2. ALM tree with peer at AMT site (AMT-GW) . . . . . . . . . 11 76 4.3. ALM tree with NM peer using AMT-R . . . . . . . . . . . . 12 77 4.4. ALM tree with NM peer with P-AMT-R . . . . . . . . . . . . 12 78 4.5. ALM tree with peer P-AMT-GW . . . . . . . . . . . . . . . 13 79 4.6. Mixed Region Scenarios . . . . . . . . . . . . . . . . . . 13 80 5. Group Management API . . . . . . . . . . . . . . . . . . . . . 14 81 5.1. Data Types . . . . . . . . . . . . . . . . . . . . . . . . 15 82 5.2. Send and Receive Calls . . . . . . . . . . . . . . . . . . 15 83 6. Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 84 6.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 16 85 6.2. Tree Lifecylce Messages . . . . . . . . . . . . . . . . . 16 86 6.2.1. Create Tree . . . . . . . . . . . . . . . . . . . . . 16 87 6.2.2. Join . . . . . . . . . . . . . . . . . . . . . . . . . 17 88 6.2.3. Join Accept . . . . . . . . . . . . . . . . . . . . . 17 89 6.2.4. Join Confirm . . . . . . . . . . . . . . . . . . . . . 18 90 6.2.5. Join Decline . . . . . . . . . . . . . . . . . . . . . 19 91 6.2.6. Join Via AMT Gateway . . . . . . . . . . . . . . . . . 19 92 6.2.7. Join Via Native Link . . . . . . . . . . . . . . . . . 20 93 6.2.8. Leave . . . . . . . . . . . . . . . . . . . . . . . . 21 94 6.2.9. Leave via AMT Gateway . . . . . . . . . . . . . . . . 21 95 6.2.10. Re-Form or Optimize Tree . . . . . . . . . . . . . . . 22 96 6.2.11. Heartbeat . . . . . . . . . . . . . . . . . . . . . . 22 97 6.3. AMT Gateway Advertisement and Discovery . . . . . . . . . 23 98 6.4. Peer Region and Multicast Properties Messages . . . . . . 24 99 7. RELOAD Usages . . . . . . . . . . . . . . . . . . . . . . . . 24 100 7.1. ALM Usage for RELOAD . . . . . . . . . . . . . . . . . . . 26 101 7.2. Hybrid ALM Usage for RELOAD . . . . . . . . . . . . . . . 26 102 8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 103 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 104 10. Security Considerations . . . . . . . . . . . . . . . . . . . 26 105 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26 106 11.1. Normative References . . . . . . . . . . . . . . . . . . . 26 107 11.2. Informative References . . . . . . . . . . . . . . . . . . 27 108 Appendix A. Additional Stuff . . . . . . . . . . . . . . . . . . 28 109 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 28 111 1. Introduction 113 The concept of scalable adaptive multicast includes both scaling 114 properties and adaptability properties. Scalability is intended to 115 cover: 117 o large group size 119 o large numbers of small groups 121 o rate of group membership change 123 o admission control for QoS 125 o use with network layer QoS mechanisms 127 o varying degrees of reliability 129 o trees connect nodes over global internet 131 Adaptability includes 133 o use of different control mechanisms for different multicast trees 134 depending on initial application parameters or application class 136 o changing multicast tree structure depending on changes in 137 application requirements, network conditions, and membership 139 o use of different control mechanisms and tree structure in 140 different regions of network depending on native multicast 141 support, network characteristics, and node behavior 143 In this document we describe a protocol and API extension to RELOAD 144 [I-D.ietf-p2psip-base] for constructing SAM sessions using hybrid 145 combinations of Application Layer Multicast, native multicast, and 146 multicast tunnels. 148 1.1. Requirements Language 150 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 151 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 152 document are to be interpreted as described in RFC 2119 [RFC2119]. 154 2. Definitions 155 2.1. Overlay Network 157 P P P P P 158 ..+....+....+...+.....+... 159 . +P 160 P+ . 161 . +P 162 ..+....+....+...+.....+... 163 P P P P P 165 Figure 1 167 Overlay network - An application layer virtual or logical network in 168 which end points are addressable and that provides connectivity, 169 routing, and messaging between end points. Overlay networks are 170 frequently used as a substrate for deploying new network services, or 171 for providing a routing topology not available from the underlying 172 physical network. Many peer-to-peer systems are overlay networks 173 that run on top of the Internet. In the above figure, "P" indicates 174 overlay peers, and peers are connected in a logical address space. 175 The links shown in the figure represent predecessor/successor links. 176 Depending on the overlay routing model, additional or different links 177 may be present. 179 2.2. Overlay Multicast 181 Overlay Multicast (OM): Hosts participating in a multicast session 182 form an overlay network and utilize unicast connections among pairs 183 of hosts for data dissemination. The hosts in overlay multicast 184 exclusively handle group management, routing, and tree construction, 185 without any support from Internet routers. This is also commonly 186 known as Application Layer Multicast (ALM) or End System Multicast 187 (ESM). We call systems which use proxies connected in an overlay 188 multicast backbone "proxied overlay multicast" or POM. 190 2.3. Peer 192 Peer: an autonomous end system that is connected to the physical 193 network and participates in and contributes resources to overlay 194 construction, routing and maintenance. Some peers may also perform 195 additional roles such as connection relays, super nodes, NAT 196 traversal, and data storage. 198 2.4. Multi-Destination Routing 200 Multi-Destination Routing (MDR): A type of multicast routing in which 201 group member's addresses are explicitly listed in each packet 202 transmitted from the sender [AGU1984]. XCAST [RFC5058] is an 203 experimental MDR protocol. A hybrid host group and MDR design is 204 described in [HE2005]. 206 3. Assumptions 208 3.1. Overlay 210 Peers connect in a large-scale overlay, which may be used for a 211 variety of peer-to-peer applications in addition to multicast 212 sessions. Peers may assume additional roles in the overlay beyond 213 participation in the overlay and in multicast trees. We assume a 214 single structured overlay routing algorithm is used. Any of a 215 variety of multi-hop, one-hop, or variable-hop overlay algorithms 216 could be used. 218 Castro et al. [CASTRO2003]compared multi-hop overlays and found that 219 tree-based construction in a single overlay out-performed using 220 separate overlays for each multicast session. We use a single 221 overlay rather than separate overlays per multicast sessions. We 222 defer federated and hierarchical multi-overlay designs to later 223 versions of this document. 225 Peers may be distributed throughout the network, in regions where 226 native multicast (NM) is available as well as regions where it is not 227 available. 229 An overlay multicast algorithm may leverage the overlay's mechanism 230 for maintaining overlay state in the face of churn. For example, a 231 peer may hold a number of DHT (Distributed Hash Table) entries. When 232 the peer gracefully leaves the overlay, it transfers those entries to 233 the nearest peer. When another peers joins which is closer to some 234 of the entries than the current peer which holds those entries, than 235 those entries are migrated. Overlay churn affects multicast trees as 236 well; remedies include automatic migration of the tree state and 237 automatic re-join operations for dislocated children nodes. 239 3.2. Overlay Multicast 241 The overlay supports concurrent multiple multicast trees. The limit 242 on number of concurrent trees depends on peer and network resources 243 and is not an intrinsic property of the overlay. Some multicast 244 trees will contain peers use ALM only, i.e., the peers do not have NM 245 connectivity. Some multicast trees will contain peers with a 246 combination of ALM and NM. Although the overlay could be used to 247 form trees of NM-only peers, if such peers are all in the same region 248 we expect native mechanisms to be used for such tree construction, 249 and if such peers are in different regions we expect AMT to handle 250 most cases of interest. 252 Peers are able to determine, through configuration or discovery: 254 o Can they connect to a NM router 256 o Is an AMT gateway accessible 258 o Can the peer support the AMT-GW functionality locally 260 o Is MDR supported in the region 262 3.3. RELOAD 264 We use RELOAD [I-D.ietf-p2psip-base] as the distibuted hash table 265 (DHT) for data storage and overlay by which the peers interconnect 266 and route messages. RELOAD is a generic P2P overlay, and application 267 support is defined by profiles called Usages. In this document we 268 present an Application Layer Multicast (ALM) Usage and a Hybrid ALM 269 Usage. 271 We also follow the RELOAD terminology for overlay specific terms, 272 such as the distinction between peer, node, and client. 274 3.4. NAT 276 Some nodes in the overlay may be in a private address space and 277 behind firewalls. We use the RELOAD mechanisms for NAT traversal. 278 We permit clients to be leaf nodes in an ALM or HALM tree. The 279 specific capabilities of clients in terms of tree creation and being 280 parents of other nodes will be described in subsequent versions. 282 3.5. Regions 284 A region is a contiguous internetwork such that if native multicast 285 is available, all routers and end systems can connect to native 286 multicast groups available in that region. A region may include end 287 systems. 289 3.6. AMT 291 We use AMT [I-D.ietf-mboned-auto-multicast] to connect nodes in ALM 292 region with nodes in NM region. AMT permits AMT-R and AMT-GW 293 functionality to be embedded in hosts or specially configured 294 routers. We assume AMT-R and AMT-GW can be implemented in nodes. 295 AMT has certain restrictions: 1) isolated sites/hosts can receive 296 SSM, 2) isolated non-NAT sites/hosts can send SSM, 3) isolated sites/ 297 hosts can receive general multicast. AMT does not permit isolated 298 sites/hosts to send general multicast. 300 4. Hybrid ALM Tree Operations 302 Peers use the overlay to support ALM operations such as: 304 o Create tree 306 o Join 308 o Leave 310 o Re-Form or optimize tree 312 There are a variety of algorithms for peers to form multicast trees 313 in the overlay. We permit multiple such algorithms to be supported 314 in the overlay, since different algorithms may be more suitable for 315 certain application requirements, and since we wish to support 316 experimentation. Therefore, overlay messaging corresponding to the 317 set of overlay multicast operations must carry algorithm 318 identification information. 320 For example, for small groups, the join point might be directly 321 assigned by the rendezvous point, while for large trees the join 322 request might be propagated down the tree with candidate parents 323 forwarding their position directly to the new node. 325 In addition to these overlay level tree operations, some peers may 326 implement additional operations to map tree operations to native 327 multicast and/or AMT [I-D.ietf-mboned-auto-multicast] connections 329 In the response to join requests, NM peers indicate further details, 330 such as their AMT-Relay, their public IP address (if they are in a 331 private network), and NM peers in AMT regions indicate their AMT 332 gateway etc. This information allows joining peers to establish 333 features of existing tree peers. For NM peers this information 334 enables them to establish if the tree NM peers belong to the same or 335 a different NM region in the network, and ways to connect to it. 337 It is up to the joining peer to then decide to join the tree via ALM 338 or AMT. Joining peers will select the most suitable peer to connect 339 to based on criteria such as lowest latency, throughput or highest 340 capacity. 342 As this decision might be application dependent, this draft does not 343 attempt to prescribe any of these criteria, it is up to the joining 344 peer to select the most suitable candidate. 346 +---------------+ +---------------+ 347 | AMT Site | P1 P2 P3 P4 P5 | Native MCast | 348 | ..........+...+....+....+...+.....+....+....... | 349 | . +---++ ++---+ +P6 | 350 | P21+ |AMT | |AMT | . | 351 | . |GW | |RLY | +P7 | 352 | . +---++ ++---+ . | 353 +-----+---------+ +------+--------+ 354 . . 355 . +------+--------+ 356 . | . Native | 357 . | . MDR | 358 P20+....+P19 .....+...+..+P8 | 359 . . | P9 | 360 +--------+------+ . +---------------+ 361 | Native . MCast| . 362 | ... | . +---------------+ 363 | P-AMT-R18+ | P10+ |Native Mcast | 364 | . | . ++---+ | 365 | P-AMT-R17+ | P-AMT-GW11+===|AMT | | 366 | .+...+.. . |RLY | | 367 | P16 | .+....+........+.....+ ++---+ | 368 +---------------+ P15 P14 P13 P12 +---------------+ 370 Figure 2 372 In the above figure we show the hybrid architecture in six regions of 373 the network. All peers are connected in an overlay, and the figure 374 shows the predecessor/successor links between peers. AMT gateways 375 (AMT-GW) do not have native multicast connectivity to the multicast 376 backbone. AMT-Relays (AMT-R) do have native multicast connectivity 377 to the multicast backbone. AMT Gateways provide a connection to the 378 native mulicast backbone via AMT Relays. The peers may have other 379 connections in the overlay. 381 o No native multicast: Peers (P19 and P20) in this region connect to 382 the overlay 384 o Native multicast (NM) in an AMT region with a local AMT gateway 385 (AMT GW). There are one or more peers (P21) connected to the 386 overlay in this region. 388 o Native multicast with a local AMT relay (AMT RLY). There are one 389 or more peers (P6 and P7) connected to the overlay in this region. 391 o Native multicast with one or more peers which emulate the AMT 392 relay behavior (P-AMT-R17 and P-AMT-R18) which also connect to the 393 overlay. There may be other peers (P16) which also connect to the 394 overlay. 396 o Native MDR is a native multicast region using multi-destination 397 routing, in which one or more peers (P8 and P9) reside in the 398 region. 400 o Native multicast with no peers that connect to the overlay, but 401 for which there is at least one peer in the unicast-only part of 402 the network which can behave as an AMT-GW (P21 and P-AMT-GW11) to 403 connect to multicast sources through an AMT-R for that region. It 404 may be feasible to also allow non-peer hosts in such a region to 405 participate as receivers of overlay multicast; for this version, 406 we prefer to require all hosts to join the overlay as peers. 408 4.1. ALM-Only Tree - Algorithm 1 410 Here is a simplistic algorithm for forming a multicast tree in the 411 overlay. Its main advantage is use of the overlay routing mechanism 412 for routing both control and data messages. The group creator 413 doesn't have to be the root of the tree or even in the tree. It 414 doesn't consider per node load, admission control, or alternative 415 paths. 417 As stated earlier, multiple algorithms will co-exist in the overlay. 419 1. Peer which initiates multicast group: 421 groupID = create(); // allocate a unique groupId 422 // the root is the nearest peer in the overlay 423 // out of band advertisement or 424 // distribution of groupID, 425 // perhaps by publishing in DHT 427 Figure 3 429 2. Any joining peer: 431 // out of band discovery of groupID, perhaps by lookup in DHT 432 joinTree(groupID); // sends "join groupID" message 434 Figure 4 436 The overlay routes the join request using the overlay routing 437 mechanism toward the peer with the nearest id to the groupID. 438 This peer is the root. Peers on the path to the root join the 439 tree as forwarding points. 441 3. Leave Tree: 443 leaveTree(groupID) // removes this node from the tree 445 Propagates a leave message to each child node and to the parent 446 node. If the parent node is a forwarding node and this is its 447 last child, then it propagates a leave message to its parent. A 448 child node receiving a leave message from a parent sends a join 449 message to the groupID. 451 4. Message forwarding: 453 multicastMsg(groupID, msg); 455 5. For the message forwarding there are two approaches: 457 * SSM tree: The creator of the tree is the source. It sends 458 data messages to the tree root which are forwarded down the 459 tree. 461 * ASM tree: A node sending a data message sends the message to 462 its parent and its children. Each node receiving a data 463 message from one edge forwards it to remaining tree edges it 464 is connected to. 466 4.2. ALM tree with peer at AMT site (AMT-GW) 468 In this case, the joining peer is within an AMT region (such as P21 469 in Figure 2) and attempts to connect to the tree using the ALM 470 protocol. A number of peers which are already member of the tree may 471 respond to this request. 473 There are the following cases: 475 o There is at least one NM peer in the tree which is in the same NM 476 region as the joining peer. The joining peer uses ALM routing or 477 connects directly to the NM peer. 479 o The tree includes at least one NM peer which is in another NM 480 region which supports an AMT-R (such as P6 and P7 in Figure 2) or 481 another peer which can function as a P-AMT-R (P-AMT-R17 in 482 Figure 2), the joining peer can use its AMT-GW to connect to one 483 of the NM peers. 485 o There is no NM peer in the tree. The NM peer uses ALM routing. 487 If the peer is not a joining peer and is on the overlay path of a 488 join request: 490 o If its next hop is a peer in an NM region with AMT-R, then it can 491 select either overlay routed multicast messages or AMT delivered 492 multicast messages. 494 o If its next hop is a peer outside of an NM region, then it could 495 use either ALM only or use AMT delivery as an alternate path 497 4.3. ALM tree with NM peer using AMT-R 499 In this case, the joining peer is within a NM region (such as P6 in 500 Figure 2)and initially attempts to connect to the tree using the ALM 501 protocol. Again, a number of peers which are members of the tree 502 respond to the request. 504 There are the following cases: 506 o There is at least one NM peer in the tree which is in the same NM 507 region as the joining peer (such as P7 in Figure 2). The joining 508 peer uses ALM routing or connects directly to the NM peer. 510 o There is at least one NM peer in the tree which is in a different 511 NM region as the joining peer (such as P16 in Figure 2). 513 o There is at least one peer in the tree which can function as 514 P-AMT-GW (P-AMT-GW11 in Figure 2). The NM peer can join the tree 515 using ALM routing and/or connecting to the P-AMT-GW via its local 516 AMT-R. 518 o There is at least one peer in the tree which is in an AMT-GW 519 region (P21 in Figure 2). The NM peer can join the tree using ALM 520 routing and/or connecting to the peer via the AMT-GW and its local 521 AMT-R. 523 o There is no NM peer in the tree. The NM peer uses ALM routing. 525 4.4. ALM tree with NM peer with P-AMT-R 527 Either the NM peer supports P-AMT-R (P-AMT-R18 in Figure 2) or 528 another peer in the multicast tree in the same region is P-AMT-R (P16 529 via P-AMT-R17 in Figure 2) capable. The last three cases above apply 530 here, replacing AMT-R with P-AMT-R. 532 4.5. ALM tree with peer P-AMT-GW 534 Here the joining peer supports P-AMT-GW (P-AMT-GW11 in Figure 2). If 535 the tree includes peers which are in a NM region which supports a 536 AMT-R (P6 and P7 in Figure 2), or a peer featuring P-AMT-R (P-AMT-R17 537 in Figure 2) the joining peer can connect to these using its AMT-GW 538 functionality. 540 4.6. Mixed Region Scenarios 542 In version 2 of this document we elaborate on: 544 o ALM tree topology vs NM topology and NM-ALM edges 546 o Single NM-ALM edge nodes vs multi NM peers from same region in the 547 tree 549 o Initial tree membership is ALM vs initial tree membership is NM 551 For ALM tree topology vs NM topology, all peers belong to the 552 overlay, but only P-ALM peers use overlay routing for multicast data 553 transmission. As a default behavior, a P-NM peer should generally 554 prefer to join the tree via an AMT-GW node. But there may be special 555 cases (small trees, short multicast sessions, trees where most of the 556 members are known to be P-ALM) in which the peer can override this to 557 specify an ALM-only join. A P-NM peer may also accept P-ALM children 558 which don't use the AMT tunnel path to participate in the multicast 559 tree. 561 Consider 3 types of tree links: P-ALM to P-ALM, P-NM to P-NM and 562 P-ALM to/from P-NM: 564 o P-ALM to P-ALM This is a normal ALM tree path with management 565 strictly in the overlay 567 o P-NM to P-NM If the peers are in the same region, then the data 568 path use native multicast capability in that region, and control 569 occurs in ALM layer for ALM tree coordination and NM layer for 570 native multicast purposes. If the peers are in different NM 571 regions, then, if AMT gateways are available and configured to 572 support an AMT tunnel between the regions, a tunnel is created 573 using the AMT protocol (or already exists for this multicast 574 group). The peers connect to their respective AMT gateways using 575 the AMT procedure. 577 o P-ALM to/from P-NM The connection can be either ALM or AMT tunnel 578 depending on the context. 580 We expect two new functions are needed to build hybrid trees: 582 o joinViaAMTGateway(peer, AMT-GW, group_id) where 'Peer' is the peer 583 requesting to join the ALM group identified by group_id, and 584 AMT-GW is the ip address of the AMT gateway that the peer uses in 585 its native multicast region. Request is transmitted to one or 586 more parent peer candiates and/or rendezvous peers for the 587 specified group id, according to the usual join protocol in this 588 overlay. If the parent peer is a P-AMT-GW, then a tunnel is 589 formed using the AMT protocol from the P-AMT-GW to the specified 590 AMT-GW. If parent peer is a peer P-NM in native multicast region, 591 then the tunnel is created between P-NM's AMT-GW and the specified 592 AMT-GW, using the AMT protocol. If parent peer is a P-ALM, then 593 the requested is propagated to other peers in the tree according 594 to the join rules. 596 o leaveViaAMTGateway(peer, AMT-GW, group_id)where 'Peer' is the peer 597 requesting to leave the ALM group identified by group_id, and 598 AMT-GW is the ip address of the AMT gateway that the peer uses in 599 its native multicast region. Request is transmitted the parent 600 peer which is associated with the AMT-GW or provides that role. 601 If the parent peer is a P-AMT-GW, then it removes the child from 602 its AMT children list and may tear down the AMT tunnel P-AMT-GW to 603 the specified AMT-GW if no other children are using it. If parent 604 peer is a peer P-NM in native multicast region, then the tunnel is 605 created between P-NM's AMT-GW and the specified AMT-GW, using the 606 AMT protocol. 608 Regarding initial tree membership being either P-NM or P-ALM node(s), 609 we expect the general case should be that hybrid tree formation is 610 supported transparently regardless. 612 5. Group Management API 614 The group management API describes interfaces for application 615 programmers to initiate a group, register or deregister multicast 616 listeners, and to send and receive multicast data. It is the aim to 617 provide a stable programming environment that facilitates a late 618 service binding and remains robust with respect to deployment 619 aspects. Following this objective, an application programmer should 620 be enabled to implement a group communication access that will become 621 operational by any group service available, e.g., native multicast, 622 different kinds of overlays, or hybrid services as described in this 623 document. The subsequent calls are part of a universal group service 624 access concept and aligned with the more general API specification 625 presented in [I-D.waehlisch-sam-common-api]. 627 An important issue of group access lies in naming and addressing. 628 While applications sharing access to the same group should use a 629 common name, different underlying technologies deploy different 630 addressing schemes. For example, native multicast is bound to IP 631 addresses (IPv4/IPv6), whereas ALM uses arbitrary strings as 632 multicast names, which will be mapped to the overlay identifier 633 space. Name and address support thus needs to account for variable 634 namespaces, but still provide abstract data types that keep code 635 independent of particular selections. We achieve this by introducing 636 Multicast URIs (cf., [I-D.waehlisch-sam-common-api]). 638 In this way, the API provides access to implementing group-oriented 639 data communication independent of the underlying distribution 640 technologies. In particular, applications can be designed to meet 641 efficiency requirements independent of deployment aspects in the 642 target domain. The API is located between applications and the group 643 stack at the current host. Here we do not consider the interface 644 between hosts, which is outlined in Section 6. 646 5.1. Data Types 648 Multicast URI is any kind of multicast address or multicast name 649 that follows the syntax: 650 ://@:/. Examples 651 are ip://224.1.2.3:5000/F06E34 or sip://news@cnn.com. 653 Handle gives a reference to a specific instance of a communication 654 object. 656 5.2. Send and Receive Calls 658 init(out Handle s) This call creates a multicast socket that is 659 bound to some virtual multicast interface and provides a 660 corresponding handle to the application programmer, which will be 661 used for subsequent communication. 663 join(in Handle s, in URI g) This operation initiates a group 664 subscription for the name g, including the corresponding tree 665 access. 667 leave(in Handle s, in URI g) This operation results in an 668 unsubscription for the given name g, including the corresponding 669 disconnect of the tree. 671 send(in Handle s, in URI g,in Message m) This call sends data m to 672 the multicast group name g. It simultaneously initiates creation 673 of the group state, if not already present. 675 receive(in Handle s, out URI g, out Message m) This call delivers 676 data m to the application along with an indicator of the group 677 membership. 679 6. Protocol 681 6.1. Introduction 683 In this document we define messages for hybrid overlay multicast tree 684 creation, using an existing proposal (RELOAD) in the P2P-SIP WG 685 [I-D.ietf-p2psip-base] for a universal structured peer-to-peer 686 overlay protocol. RELOAD provides the mechanism to support a number 687 of overlay topologies. Hence the hybrid overlay multicast framework 688 [I-D.irtf-sam-hybrid-overlay-framework] (hereafter SAM framework) can 689 be used with P2P-SIP, and that the SAM framework is overlay agnostic. 691 We are not proposing that these SAM-specific messages be incorporated 692 into RELOAD since constructing the SAM framework is still a research 693 activity. However, we do propose that RELOAD add an extension 694 mechanism. 696 As discussed in the SAM requirements draft, there are a variety of 697 ALM tree formation and tree maintenance algorithms. The intent of 698 this specification is to be algorithm agnostic, similar to how RELOAD 699 is overlay algorithm agnostic. We assume that all control messages 700 are propagated using overlay routed messages. 702 The message types needed for ALM behavior are divided into the 703 following categories: 705 o Tree life-cycle (create, join, leave, re-form, heartbeat) 707 o AMT gateway advertisement and discovery 709 o Peer region and multicast properties 711 6.2. Tree Lifecylce Messages 713 Peers use the overlay to transmit ALM (application layer multicast) 714 operations and hybrid ALM operations defined in this section. 716 6.2.1. Create Tree 718 A new ALM tree is created in the overlay with the identity specified 719 by GroupId. The usual interpretation of GroupId is that the peer 720 with peer id closest to and less than the GroupId is the root of the 721 tree. The tree has no children at the time it is created. 723 The GroupId is generated from a well-known session key to be used by 724 other Peers to address the multicast tree in the overlay. The 725 generation of the GroupId from the SessionKey MUST be done using the 726 overlay's id generation mechanism. 728 struct { 729 NodeID PeerId; 730 opaque SessionKey<0..2^32-1>; 731 NodeID GroupId; 732 Dictionary Options; 733 } CreateALMTree; 735 PeerId: the overlay address of the peer that creates the multicast 736 tree. 738 SessionKey: a well-known string when hashed using the overlay's id 739 generation algorithm produces the GroupId. 741 GroupId: the overlay address of the root of the tree 743 Options: name-value list of properties to be associated with the 744 tree, such as the maximum size of the tree, restrictions on peers 745 joining the tree, latency constraints, preference for distributed or 746 centralized tree formation and maintenance, heartbeat interval. 748 6.2.2. Join 750 Causes the distributed algorithm for peer join of a specific ALM 751 group to be invoked. If successful, the PeerId is notified of one or 752 more candidate parent peers in one or more JoinAccept messages. The 753 particular ALM join algorithm is not specified in this protocol. 755 struct { 756 NodeID PeerId; 757 NodeID GroupId; 758 Dictionary Options; 759 } Join; 761 PeerId: overlay address of joining/leaving peer 763 GroupId: the overlay address of the root of the tree 765 Options: name-value list of options proposed by joining peer 767 6.2.3. Join Accept 769 Tells the requesting joining peer that the indicated peer is 770 available to act as its parent in the ALM tree specified by GroupId, 771 with the corresponding Options specified. A peer MAY receive more 772 than one JoinAccept from diffent candidate parent peers in the 773 GroupId tree. The peer accepts a peer as parent using a JoinConfirm 774 message. A JoinAccept which receives neither a JoinConfirm or 775 JoinDecline response MUST expire. 777 struct { 778 NodeID ParentPeerId; 779 NodeID ChildPeerId; 780 NodeID GroupId; 781 Dictionary Options; 782 } JoinAccept; 784 ParentPeerId: overlay address of a peer which accepts the joining 785 peer 787 ChildPeerId: overlay address of joining peer 789 GroupId: the overlay address of the root of the tree 791 Options: name-value list of options accepted by parent peer 793 6.2.4. Join Confirm 795 A peer receiving a JoinAccept message which it wishes to accept MUST 796 explicitly accept it before the expiration of the JoinAccept using a 797 JoinConfirm message. The joining peer MUST include only those 798 options from the JoinAccept which it also accepts, completing the 799 negotiation of options between the two peers. 801 struct { 802 NodeID ChildPeerId; 803 NodeID ParentPeerId; 804 NodeID GroupId; 805 Dictionary Options; 806 } JoinConfirm; 808 ChildPeerId: overlay address of joining peer which is a child of the 809 parent peer 811 ParentPeerId: overlay address of the peer which is the parent of the 812 joining peer 814 GroupId: the overlay address of the root of the tree 816 Options: name-value list of options accepted by both peers 818 6.2.5. Join Decline 820 A peer receiving a JoinAccept message which does not wish to accept 821 it MAY explicitly decline it using a JoinDecline message. 823 struct { 824 NodeID PeerId; 825 NodeID ParentPeerId; 826 NodeID GroupId; 827 } JoinDecline; 829 PeerId: overlay address of joining peer which declines the JoinAccept 831 ParentPeerId: overlay address of the peer which issued a JoinAccept 832 to this peer 834 GroupId: the overlay address of the root of the tree 836 6.2.6. Join Via AMT Gateway 838 A request to create a hybrid native multicast connection for the 839 specified PeerId peer to join the tree identified by the GroupId. 840 The request is transmitted to one or more parent peer candidates 841 and/or rendezvous peers for the specified group id, according to the 842 usual join protocol in this overlay. 844 If the parent peer is a P-AMT-GW (a peer which supports the AMT-GW 845 interface), then after JoinAccept and JoinConfirm steps, instead of 846 an overlay parent-child link, an AMT tunnel is formed using the AMT 847 protocol from the P-AMT-GW to the specified AMT-GW to which the Peer 848 is associated. 850 If parent peer is a peer P-NM in native multicast region, then after 851 JoinAccept and JoinConfirm steps, the tunnel is created between P- 852 NM's AMT-GW and the specified AMT-GW, using the AMT protocol. If 853 parent peer is a P-ALM, then the requested is propagated to other 854 peers in the tree according to the join processing rules. 856 struct { 857 NodeID PeerId; 858 IpAddressPort AMT-GW; 859 NodeID GroupId; 860 Dictionary Options; 861 } JoinViaAMTGateway; 863 PeerID: the peer requesting to join the ALM group identified by 864 group_id 865 AMT-GW: ip address of the AMT gateway that the peer uses in its 866 native multicast region. 868 Options: name-value list of options proposed by joining peer 870 6.2.7. Join Via Native Link 872 This allows child to select specific parent peer, overriding 873 selection based on the basic join method. Typical use is for a peer 874 in NM region to join the multicast group using the local native 875 multicast path for this GroupId. Joining peer determines: 877 o It is in an NM region, determined for example using MRD (Multicast 878 Router Discovery) [RFC4286] or configuration 880 o It knows the native multicast address (NMA) in its region, if it 881 exists, which corresponds to the GroupId 883 o It can connect to the NMA using IGMP 885 o Either 1) there is at least one peer that is in the same NM region 886 that is already part of the GroupId, or 2) the region has an AMT- 887 GW which can connect to some P-AMT-GW or P-NM in another NM region 888 which is part of the GroupId. It uses a separate discovery step 889 such as LookupPeerNMInfo described later. 891 o If there is no such peer in the GroupId, then this joining peer is 892 the first peer to be added which is in an NM region. It CANNOT 893 join using this message type. 895 ParentPeer and ChildPeer are either in same NM region or in two 896 different NM regions with capability for AMT. Since media is passed 897 via NM path, the parent-child relationship established by this join 898 is for control and membership management 900 struct { 901 NodeID ChildPeerId; 902 NodeID ParentPeerId; 903 NodeID GroupId; 904 Dictionary Options; 905 } JoinWithNativeLink; 907 ChildPeerId: overlay address of joining peer which is a child of the 908 parent peer 910 ParentPeerId: overlay address of the peer which is the parent of the 911 joining peer 912 GroupId: the overlay address of the root of the tree 914 Options: name-value list of options accepted by both peers 916 6.2.8. Leave 918 A peer which is part of an ALM tree idenfied by GroupId which intends 919 to detach from either a child or parent peer SHOULD send a Leave 920 message to the peer it wishes to detach from. A peer receiving a 921 Leave message from a peer which is neither in its parent or child 922 lists SHOULD ignore the message. 924 struct { 925 NodeID PeerId; 926 NodeID GroupId; 927 Dictionary Options; 928 } Leave; 930 PeerId: overlay address of leaving peer 932 GroupId: the overlay address of the root of the tree 934 Options: name-value list of options 936 6.2.9. Leave via AMT Gateway 938 A peer which is part of an ALM tree identified by GroupId which 939 intends to detach from either a child or parent peer and which uses 940 an AMT tunnel to connect to the peer SHOULD send a LeaveViaAMTGateway 941 message to the peer it wishes to detach from. A peer receiving a 942 LeaveViaAMTGateway message from a peer which is neither in its parent 943 or child lists SHOULD ignore the message. 945 The request is transmitted the AdjacentPeerId. AdjacentPeerId MUST 946 remove the specified PeerId from its children or parent lists if 947 present. 949 If AdjacentPeerId is a P-AMT-GW, then it MAY tear down the AMT tunnel 950 from P-AMT-GW to the specified AMT-GW if no other children are using 951 it. If AdjacentPeerId is a peer P-NM (peer in a native multicast 952 region), then the tunnel between P-NM's AMT-GW and the specified AMT- 953 GW MAY be removed according to the policy and configuration of the 954 AMT-GW. 956 struct { 957 NodeID PeerId; 958 NodeID AdjacentPeerId; 959 IpAddressPort AMT-GW; 960 NodeID GroupId; 961 Dictionary Options; 962 } LeaveViaAMTGateway; 964 PeerId: overlay address of leaving peer 966 AdjacentPeerId: overlay address of an adjacent (parent or child) peer 968 AMT-GW: ip address of the AMT gateway that the peer uses in its 969 native multicast region. 971 GroupId: the overlay address of the root of the tree 973 Options: name-value list of options 975 6.2.10. Re-Form or Optimize Tree 977 This triggers a reorganization of either the entire tree or only a 978 sub-tree. It MAY include hints to specific peers of recommended 979 parent or child peers to reconnect to. A peer receiving this message 980 MAY ignore it, MAY propagate it to other peers in its subtree, and 981 MAY invoke local algorithms for selecting preferred parent and/or 982 child peers. 984 struct { 985 NodeID GroupId; 986 NodeID PeerId; 987 Dictionary Options; 988 } Reform; 990 GroupId: the overlay address of the root of the tree 992 PeerId: if omitted, then the tree is reorganized starting from the 993 root, otherwise it is reorganized only at the sub-tree identified by 994 PeerId. 996 Options: name-value list of options 998 6.2.11. Heartbeat 1000 A node signals to its adjacent nodes in the tree that it is alive. 1001 If a peer does not receive a Heartbeat message within N heartbeat 1002 time intervals, it MUST treat this as an explicit Leave message from 1003 the unresponsive peer. N is configurable. 1005 struct { 1006 NodeID PeerId1; 1007 NodeID PeerId2; 1008 NodeID GroupId; 1009 } Heartbeat; 1011 PeerId1: source of heartbeat 1013 PeerId2: destination of heartbeat 1015 GroupId: overlay address of the root of the tree 1017 6.3. AMT Gateway Advertisement and Discovery 1019 Allows peer to disclose to other peers in the overlay their ability 1020 to act as a native-multicast gateway (as in AMT) for peers in a given 1021 region. We expect to use the P2P Publish and Lookup messages for 1022 this purpose. But to avoid collision with the semantics of those 1023 operations, we temporarily define shadow versions within the SAM 1024 extension. Publish stores an advertisement object for a peer with is 1025 an AMT gateway in the DHT for the overlay, under a given key. 1027 struct { 1028 NodeID PeerId; 1029 ResourceID Key; 1030 opaque Region<0..2^32-1>; 1031 Dictionary Options; 1032 } PublishAMTGateway; 1034 struct { 1035 NodeID PeerId; 1036 ResourceID Key; 1037 } LookupAMTGateway; 1039 PeerId: the peer which is the AMT gateway 1041 Key: the key by which other peers lookup the advertisement, details 1042 TBD. There can be more than one key. 1044 Region: an id for a region, using some region identification scheme 1045 TBD. For example, the Autonomous System Number (ASN) could be used. 1046 [RFC1930] 1048 Options: Name-value list of options 1050 6.4. Peer Region and Multicast Properties Messages 1052 Peers can advertise the network region that they belong to and its 1053 native multicast properties if any. Similar to AMT Gateway 1054 advertisement and discovery, uses the DHT for lookup and publish. 1056 struct { 1057 NodeID PeerId; 1058 ResourceID Key; 1059 opaque Region<0..2^32-1>; 1060 Dictionary Options; 1061 } PublishPeerNMInfo; 1063 struct { 1064 NodeID PeerId; 1065 ResourceID Key; 1066 } LookupPeerNMInfo; 1068 PeerId: the peer which is the AMT gateway 1070 Key: the key by which other peers lookup the advertisement, details 1071 TBD. There can be more than one key. 1073 Options: Name-value list of options. 1075 7. RELOAD Usages 1077 Applications of RELOAD are restricted in the data types that be can 1078 stored in the DHT. The profile of accepted data types for an 1079 application is referred to as a Usage. RELOAD is designed so that 1080 new applications can easily define new Usages. New RELOAD Usages are 1081 needed for hybrid multicast applications since the data types in base 1082 RELOAD and existing usages are not sufficient. 1084 We define an ALM Usage and a Hybrid ALM Usage in RELOAD. The ALM 1085 Usage is sufficient for applications which only require ALM 1086 functionality in the overlay. The Hybrid ALM (HALM) Usage extends 1087 the ALM Usage so that hybrid native multicast and ALM trees can be 1088 used by applications. 1090 The ALM Usage involves the functions: 1092 o ALM applications use the RELOAD data storage functionality to 1093 store a groupID when a new ALM tree is created in the overlay, and 1094 to retrieve groupIDs for existing ALM trees. 1096 o ALM applications use the RELOAD data storage functionality to 1097 store a set of attributes for an ALM tree, such as owner, tree 1098 size, tree height, tree formation algorithm, and join criteria. 1100 o ALM applications and management tools use the RELOAD data storage 1101 functionality to store diagnostic information about the operation 1102 of tree, including average number of tree, delay from source to 1103 leaf nodes, bandwidth use, lost packet rate. In addition, 1104 diagnostic information may include statistics specific to the tree 1105 root, or to any node in the tree. 1107 The Hybrid ALM Usage involves the following additional functions: 1109 o HALM applications use the RELOAD data storage functionality to 1110 store a set of attributes for a AMT Gateway that can connect to at 1111 least one node in the overlay. 1113 o HALM applications use the RELOAD data storage functionality to 1114 store a set of attributes about a native multicast region 1115 associated with an AMT Gateway. 1117 o HALM applications and management tools use the RELOAD data storage 1118 functionality to store diagnostic information about the operation 1119 of AMT and ALM interconnections. 1121 A RELOAD Usage is required [I-D.ietf-p2psip-base] to define the 1122 following: 1124 o Register Kind-Id points 1126 o Define data structures for each kind 1128 o Defines access control rules for each kind 1130 o Defines the Resource Name used to hash to the Resource ID where 1131 the kind is stored 1133 o Addresses restoration of values after recovery from a network 1134 partition 1136 o Defines the types of connections that can be initiated using 1137 AppConnect 1139 The following sections are preliminary steps towards formalizing the 1140 for ALM and HALM Uages. 1142 7.1. ALM Usage for RELOAD 1144 A ALM GroupID is a RELOAD Node-ID. The owner of a ALM group creates 1145 a RELOAD Node-ID as specified in [I-D.ietf-p2psip-base]. This means 1146 that a GroupID is used as a RELOAD Destination for overlay routing 1147 purposes. 1149 7.2. Hybrid ALM Usage for RELOAD 1151 8. Examples 1153 TBD. 1155 9. IANA Considerations 1157 This memo includes no request to IANA. 1159 10. Security Considerations 1161 Overlays are vulnerable to DOS and collusion attacks. We are not 1162 solving overlay security issues. We assume the centralized node 1163 authentication model as defined in [I-D.ietf-p2psip-base]. 1165 11. References 1167 11.1. Normative References 1169 [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, 1170 RFC 792, September 1981. 1172 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1173 Requirement Levels", BCP 14, RFC 2119, March 1997. 1175 [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. 1176 Thyagarajan, "Internet Group Management Protocol, Version 1177 3", RFC 3376, October 2002. 1179 [RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery 1180 Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. 1182 [RFC4605] Fenner, B., He, H., Haberman, B., and H. Sandick, 1183 "Internet Group Management Protocol (IGMP) / Multicast 1184 Listener Discovery (MLD)-Based Multicast Forwarding 1185 ("IGMP/MLD Proxying")", RFC 4605, August 2006. 1187 [RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for 1188 IP", RFC 4607, August 2006. 1190 [RFC5058] Boivie, R., Feldman, N., Imai, Y., Livens, W., and D. 1191 Ooms, "Explicit Multicast (Xcast) Concepts and Options", 1192 RFC 5058, November 2007. 1194 11.2. Informative References 1196 [AGU1984] Aguilar, L., "Datagram Routing for Internet Multicasting", 1197 ACM Sigcomm 84 1984, March 1984. 1199 [CASTRO2002] 1200 Castro, M., Druschel, P., Kermarrec, A., and A. Rowstron, 1201 "Scribe: A large-scale and decentralized application-level 1202 multicast infrastructure", IEEE Journal on Selected Areas 1203 in Communications vol.20, No.8, October 2002, . 1207 [CASTRO2003] 1208 Castro, M., Jones, M., Kermarrec, A., Rowstron, A., 1209 Theimer, M., Wang, H., and A. Wolman, "An Evaluation of 1210 Scalable Application-level Multicast Built Using Peer-to- 1211 peer overlays", Proceedings of IEEE INFOCOM 2003, 1212 April 2003, . 1215 [HE2005] He, Q. and M. Ammar, "Dynamic Host-Group/Multi-Destination 1216 Routing for Multicast Sessions", J. Telecommunication 1217 Systems vol. 28, pp. 409-433. 1219 [I-D.ietf-mboned-auto-multicast] 1220 Thaler, D., Talwar, M., Aggarwal, A., Vicisano, L., and T. 1221 Pusateri, "Automatic IP Multicast Without Explicit Tunnels 1222 (AMT)", draft-ietf-mboned-auto-multicast-10 (work in 1223 progress), March 2010. 1225 [I-D.ietf-p2psip-base] 1226 Jennings, C., Lowekamp, B., Rescorla, E., Baset, S., and 1227 H. Schulzrinne, "REsource LOcation And Discovery (RELOAD) 1228 Base Protocol", draft-ietf-p2psip-base-08 (work in 1229 progress), March 2010. 1231 [I-D.ietf-p2psip-sip] 1232 Jennings, C., Lowekamp, B., Rescorla, E., Baset, S., and 1233 H. Schulzrinne, "A SIP Usage for RELOAD", 1234 draft-ietf-p2psip-sip-04 (work in progress), March 2010. 1236 [I-D.irtf-p2prg-rtc-security] 1237 Schulzrinne, H., Marocco, E., and E. Ivov, "Security 1238 Issues and Solutions in Peer-to-peer Systems for Realtime 1239 Communications", draft-irtf-p2prg-rtc-security-05 (work in 1240 progress), September 2009. 1242 [I-D.irtf-sam-hybrid-overlay-framework] 1243 Buford, J., "Hybrid Overlay Multicast Framework", 1244 draft-irtf-sam-hybrid-overlay-framework-02 (work in 1245 progress), February 2008. 1247 [I-D.matuszewski-p2psip-security-overview] 1248 Yongchao, S., Matuszewski, M., and D. York, "P2PSIP 1249 Security Overview and Risk Analysis", 1250 draft-matuszewski-p2psip-security-overview-01 (work in 1251 progress), October 2009. 1253 [I-D.waehlisch-sam-common-api] 1254 Waehlisch, M., Schmidt, T., and S. Venaas, "A Common API 1255 for Transparent Hybrid Multicast", 1256 draft-waehlisch-sam-common-api-02 (work in progress), 1257 March 2010. 1259 [RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, 1260 RFC 1112, August 1989. 1262 [RFC1930] Hawkinson, J. and T. Bates, "Guidelines for creation, 1263 selection, and registration of an Autonomous System (AS)", 1264 BCP 6, RFC 1930, March 1996. 1266 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 1267 Text on Security Considerations", BCP 72, RFC 3552, 1268 July 2003. 1270 [RFC4286] Haberman, B. and J. Martin, "Multicast Router Discovery", 1271 RFC 4286, December 2005. 1273 Appendix A. Additional Stuff 1275 This becomes an Appendix. 1277 Authors' Addresses 1279 John Buford 1280 Avaya Labs Research 1281 233 Mt. Airy Rd 1282 Basking Ridge, New Jersey 07920 1283 USA 1285 Phone: +1 908 848 5675 1286 Email: buford@avaya.com 1288 Mario Kolberg (editor) 1289 University of Stirling 1290 Dept. Computing Science and Mathematics 1291 Stirling, FK9 4LA 1292 UK 1294 Phone: +44 1786 46 7440 1295 Email: mkolberg@ieee.org 1296 URI: http://www.cs.stir.ac.uk/~mko 1298 Thomas C. Schmidt 1299 HAW Hamburg 1300 Berliner Tor 7 1301 Hamburg, 20099 1302 Germany 1304 Email: schmidt@informatik.haw-hamburg.de 1305 URI: http://inet.cpt.haw-hamburg.de/members/schmidt 1307 Matthias Waehlisch 1308 link-lab & FU Berlin 1309 Hoenower Str. 35 1310 Berlin 10318 1311 Germany 1313 Email: mw@link-lab.net