SAM J. Buford Internet Draft Avaya Labs Intended status: Experimental March 12, 2008 Expires: September 12, 2008 SAM Overlay Protocol draft-buford-irtf-sam-overlay-protocol-01.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on September 12, 2008. Copyright Notice Copyright (C) The IETF Trust (2008). Abstract The previously proposed Hybrid Overlay Multicast Framework uses a structured peer-to-peer overlay to connect peers in different types of multicast regions of the Internet. We use AMT (Automatic IP Buford Expires September 12, 2008 [Page 1] Internet-Draft SAM Overlay Protocol March 12, 2008 Multicast Without Explicit Tunnels) to connect peers in ALM (Application Layer Multicast) regions with peers in native multicast regions. Here we define the overlay messaging needed to support the multicast tree operations. One goal of this approach is to ensure that the SAM framework is compatible with the P2P-SIP overlay, which is still being defined. Another goal is to be overlay agnostic so that different overlay algorithms can interoperate in a single SAM (Scalable Adaptive Multicast) session. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [RFC2119]. Table of Contents 1. Introduction...................................................3 2. Tree Lifecylce Messages........................................3 2.1. Create Tree...............................................4 2.2. Join......................................................4 2.3. Join Accept...............................................4 2.4. Join Confirm..............................................5 2.5. Join Decline..............................................5 2.6. Join Via AMT Gateway......................................5 2.7. JoinWithNativeLink........................................6 2.8. Leave.....................................................7 2.9. Leave Via AMT Gateway.....................................7 2.10. Re-Form or Optimize Tree.................................8 2.11. Heartbeat................................................8 3. AMT Gateway Advertisement and Discovery........................8 4. Peer Region and Multicast Properties Messages..................9 5. Message Format.................................................9 5.1. P2PP Extension............................................9 5.2. Experimental Message......................................9 6. SAM Extension-Body............................................10 7. Message Encoding..............................................10 8. Change History................................................11 9. Security Considerations.......................................11 10. IANA Considerations..........................................11 11. References...................................................11 11.1. Normative References....................................11 11.2. Informative References..................................11 Author's Addresses...............................................12 Full Copyright Statement.........................................13 Intellectual Property............................................13 Buford Expires September 12, 2008 [Page 2] Internet-Draft SAM Overlay Protocol March 12, 2008 Acknowledgment...................................................13 1. Introduction In this document we define messages for hybrid overlay multicast tree creation, using an existing proposal (P2PP) in the P2P-SIP WG [BAS2007] for a universal structured peer-to-peer overlay protocol. The purpose of this approach is to ensure that the hybrid overlay multicast framework [BUF2008] (hereafter SAM framework) can be implemented on P2P-SIP overlays, and that the SAM framework is overlay agnostic. Since P2PP is intended to cover at least a variety of structured multi-hop algorithms, it is suitable for achieving an overlay agnostic approach. We are not proposing that these SAM-specific messages be incorporated into [BAS2007] since constructing the SAM framework is still a research activity. However, we do propose that P2PP add an extension mechanism, defined here as the "Experimental" message type. This document also defines a SAM extension to P2PP using this Experimental message type. As discussed in the SAM requirements draft, there are a variety of ALM tree formation and tree maintenance algorithms. The intent of this specification is to be algorithm agnostic, similar to how P2PP is overlay algorithm agnostic. We assume that all control messages are propagated using overlay routed messages. The message types needed for ALM behavior are divided into the following categories: o Tree life-cycle (create, join, leave, re-form, heartbeat) o AMT [THA2007] gateway advertisement and discovery o Peer region and multicast properties For encoding we propose a single SAM message type be added to P2PP. Implementations of P2PP compliant with this specification MUST support this new message type and all subtypes defined here. 2. Tree Lifecylce Messages Peers use the overlay to transmit ALM (application layer multicast) operations and hybrid ALM operations defined in this section. Buford Expires September 12, 2008 [Page 3] Internet-Draft SAM Overlay Protocol March 12, 2008 2.1. Create Tree A new ALM tree is created in the overlay with the identity specified by GroupId. The usual interpretation of GroupId is that the peer with peer id closest to and less than the GroupId is the root of the tree. The tree has no children at the time it is created. The GroupId is generated from a well-known session key to be used by other Peers to address the multicast tree in the overlay. The generation of the GroupId from the SessionKey MUST be done using the overlay's id generation mechanism. Create(PeerId, SessionKey, GroupId, Options) PeerId: the overlay address of the peer that creates the multicast tree. SessionKey: a well-known string when hashed using the overlay's id generation algorithm produces the GroupId. GroupId: the overlay address of the root of the tree Options: name-value list of properties to be associated with the tree, such as the maximum size of the tree, restrictions on peers joining the tree, latency constraints, preference for distributed or centralized tree formation and maintenance, heartbeat interval. 2.2. Join Causes the distributed algorithm for peer join of a specific ALM group to be invoked. If successful, the PeerId is notified of one or more candidate parent peers in one or more JoinAccept messages. The particular ALM join algorithm is not specified in this protocol. Join(PeerId, GroupId, Options) PeerId: overlay address of joining/leaving peer GroupId: the overlay address of the root of the tree Options: name-value list of options proposed by joining peer 2.3. Join Accept Tells the requesting joining peer that the indicated peer is available to act as its parent in the ALM tree specified by GroupId, with the corresponding Options specified. A peer MAY receive more than one JoinAccept from diffent candidate parent peers in the GroupId tree. The peer accepts a peer as parent using a JoinConfirm message. A JoinAccept which receives neither a JoinConfirm or JoinDecline response MUST expire. JoinAccept(ParentPeerId, ChildPeerId, GroupId, Options) Buford Expires September 12, 2008 [Page 4] Internet-Draft SAM Overlay Protocol March 12, 2008 ParentPeerId: overlay address of a peer which accepts the joining peer ChildPeerId: overlay address of joining peer GroupId: the overlay address of the root of the tree Options: name-value list of options accepted by parent peer 2.4. Join Confirm A peer receiving a JoinAccept message which it wishes to accept MUST explicitly accept it before the expiration of the JoinAccept using a JoinConfirm message. The joining peer MUST include only those options from the JoinAccept which it also accepts, completing the negotiation of options between the two peers. JoinConfirm(ChildPeerId, ParentPeerId, GroupId, Options) ChildPeerId: overlay address of joining peer which is a child of the parent peer ParentPeerId: overlay address of the peer which is the parent of the joining peer GroupId: the overlay address of the root of the tree Options: name-value list of options accepted by both peers 2.5. Join Decline A peer receiving a JoinAccept message which does not wish to accept it MAY explicitly decline it using a JoinDecline message. JoinDecline(PeerId, ParentPeerId, GroupId) PeerId: overlay address of joining peer which declines the JoinAccept ParentPeerId: overlay address of the peer which issued a JoinAccept to this peer GroupId: the overlay address of the root of the tree 2.6. Join Via AMT Gateway A request to create a hybrid native multicast connection for the specified PeerId peer to join the tree identified by the GroupId. The request is transmitted to one or more parent peer candidates and/or rendezvous peers for the specified group id, according to the usual join protocol in this overlay. Buford Expires September 12, 2008 [Page 5] Internet-Draft SAM Overlay Protocol March 12, 2008 If the parent peer is a P-AMT-GW (a peer which supports the AMT-GW interface), then after JoinAccept and JoinConfirm steps, instead of an overlay parent-child link, an AMT tunnel is formed using the AMT protocol from the P-AMT-GW to the specified AMT-GW to which the Peer is associated. If parent peer is a peer P-NM in native multicast region, then after JoinAccept and JoinConfirm steps, the tunnel is created between P- NM's AMT-GW and the specified AMT-GW, using the AMT protocol. If parent peer is a P-ALM, then the requested is propagated to other peers in the tree according to the join processing rules. JoinViaAMTGateway(PeerId, AMT-GW, GroupId, Options) PeerID: the peer requesting to join the ALM group identified by group_id AMT-GW: ip address of the AMT gateway that the peer uses in its native multicast region. Options: name-value list of options proposed by joining peer 2.7. JoinWithNativeLink This allows child to select specific parent peer, overriding selection based on the basic join method. Typical use is for a peer in NM region to join the multicast group using the local native multicast path for this GroupId. Joining peer determines: o It is in an NM region, determined for example using MRD (Multicast Router Discovery) [RFC4286] or configuration o It knows the native multicast address (NMA) in its region, if it exists, which corresponds to the GroupId o It can connect to the NMA using IGMP o Either 1) there is at least one peer that is in the same NM region that is already part of the GroupId, or 2) the region has an AMT- GW which can connect to some P-AMT-GW or P-NM in another NM region which is part of the GroupId. It uses a separate discovery step such as LookupPeerNMInfo described later. o If there is no such peer in the GroupId, then this joining peer is the first peer to be added which is in an NM region. It CANNOT join using this message type. ParentPeer and ChildPeer are either in same NM region or in two different NM regions with capability for AMT. Since media is passed Buford Expires September 12, 2008 [Page 6] Internet-Draft SAM Overlay Protocol March 12, 2008 via NM path, the parent-child relationship established by this join is for control and membership management JoinWithNativeLink(ChildPeer,ParentPeer,GroupId, Options) ChildPeerId: overlay address of joining peer which is a child of the parent peer ParentPeerId: overlay address of the peer which is the parent of the joining peer GroupId: the overlay address of the root of the tree Options: name-value list of options accepted by both peers 2.8. Leave A peer which is part of an ALM tree idenfied by GroupId which intends to detach from either a child or parent peer SHOULD send a Leave message to the peer it wishes to detach from. A peer receiving a Leave message from a peer which is neither in its parent or child lists SHOULD ignore the message. Leave(PeerId, GroupId, Options) PeerId: overlay address of leaving peer GroupId: the overlay address of the root of the tree Options: name-value list of options 2.9. Leave Via AMT Gateway A peer which is part of an ALM tree identified by GroupId which intends to detach from either a child or parent peer and which uses an AMT tunnel to connect to the peer SHOULD send a LeaveViaAMTGateway message to the peer it wishes to detach from. A peer receiving a LeaveViaAMTGateway message from a peer which is neither in its parent or child lists SHOULD ignore the message. The request is transmitted the AdjacentPeerId. AdjacentPeerId MUST remove the specified PeerId from its children or parent lists if present. If AdjacentPeerId is a P-AMT-GW, then it MAY tear down the AMT tunnel from P-AMT-GW to the specified AMT-GW if no other children are using it. If AdjacentPeerId is a peer P-NM (peer in a native multicast region), then the tunnel between P-NM's AMT-GW and the specified AMT- GW MAY be removed according to the policy and configuration of the AMT-GW. LeaveViaAMTGateway(PeerId, AdjacentPeerId, AMT-GW, GroupId, Options) Buford Expires September 12, 2008 [Page 7] Internet-Draft SAM Overlay Protocol March 12, 2008 PeerId: overlay address of leaving peer AdjacentPeerId: overlay address of an adjacent (parent or child) peer AMT-GW: ip address of the AMT gateway that the peer uses in its native multicast region. GroupId: the overlay address of the root of the tree Options: name-value list of options 2.10. Re-Form or Optimize Tree This triggers a reorganization of either the entire tree or only a sub-tree. It MAY include hints to specific peers of recommended parent or child peers to reconnect to. A peer receiving this message MAY ignore it, MAY propagate it to other peers in its subtree, and MAY invoke local algorithms for selecting preferred parent and/or child peers. Reform(GroupId, { PeerId }, Options) GroupId: the overlay address of the root of the tree PeerId: if omitted, then the tree is reorganized starting from the root, otherwise it is reorganized only at the sub-tree identified by PeerId. Options: name-value list of options 2.11. Heartbeat A node signals to its adjacent nodes in the tree that it is alive. If a peer does not receive a Heartbeat message within N heartbeat time intervals, it MUST treat this as an explicit Leave message from the unresponsive peer. N is configurable. Heartbeat(PeerId1, PeerId2, GroupId) PeerId1: source of heartbeat PeerId2: destination of heartbeat GroupId: overlay address of the root of the tree 3. AMT Gateway Advertisement and Discovery Allows peer to disclose to other peers in the overlay their ability to act as a native-multicast gateway (as in AMT) for peers in a given region. We expect to use the P2P Publish and Lookup messages for this purpose. But to avoid collision with the semantics of those operations, we temporarily define shadow versions within the SAM extension. Publish stores an advertisement object for a peer with is an AMT gateway in the DHT for the overlay, under a given key. Buford Expires September 12, 2008 [Page 8] Internet-Draft SAM Overlay Protocol March 12, 2008 PublishAMTGateway(PeerId, Key, Region, Options) LookupAMTGateway(PeerId, Key) PeerId: the peer which is the AMT gateway Key: the key by which other peers lookup the advertisement, details TBD. There can be more than one key. Region: an id for a region, using some region identification scheme TBD. For example, the Autonomous System Number (ASN) could be used.[RFC1930] Options: Name-value list of options 4. Peer Region and Multicast Properties Messages Peers can advertise the network region that they belong to and its native multicast properties if any. Similar to AMT Gateway advertisement and discovery, uses the DHT for lookup and publish. PublishPeerNMInfo(PeerId, Key, Options) LookupPeerNMInfo(PeerId, Key) PeerId: the peer which is the AMT gateway Key: the key by which other peers lookup the advertisement, details TBD. There can be more than one key. Options: Name-value list of options 5. Message Format 5.1. P2PP Extension We propose a new message be added to the 18 existing message types: P2PP-Msg = ... | Experimental 5.2. Experimental Message Experimental = Common-header Peer-Info Certificate-Sign-Request Password Extension-Name Extension-Body Extension-Name = SAM | ... Extension-Body = extension-specific Buford Expires September 12, 2008 [Page 9] Internet-Draft SAM Overlay Protocol March 12, 2008 6. SAM Extension-Body The extension-body used by the SAM extension to P2PP is as follows. Extension-Body = Extension-Message-Type | Arguments | Options Extension-Message-Type = CreateTree | Join | JoinAccept | JoinConfirm | JoinDecline | JoinViaAMTGateway | JoinWithNativeLink | Leave | LeaveViaAMTGateway | Heartbeat | PublishAMTGateway | LookupAMTGateway | PublishPeerNMInfo | LookupPeerNMInfo | Reform Arguments = PID | GroupId | Key | SessionKey | AMT-GW PID = PeerId | AdjacentPeerId | ChildPeerId | ParentPeerId Options = {Option}* Option = Name, Value 7. Message Encoding P2PP uses a binary encoding. The encoding for the SAM extension messages will be defined in a subsequent draft. Buford Expires September 12, 2008 [Page 10] Internet-Draft SAM Overlay Protocol March 12, 2008 8. Change History o 01 - Add JoinWithNativeLink message 9. Security Considerations Overlays are vulnerable to DOS and collusion attacks. We are not solving overlay security issues. For this version we assume centralized peer authentication model similar to what is proposed for P2P-SIP. 10. IANA Considerations This document has no actions for IANA. 11. References 11.1. Normative References [RFC1930] J. Hawkinson, S. Bates. "Guidelines for Creation, Selection, and Registration of an Autonomous System (AS)". BCP 6, RFC 1930, March 1996. [RFC2119] S. Bradner, "Key Words for Use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997 [RFC4286] B. Haberman, J. Martin, "Multicast Router Discovery". RFC 4286, Dec. 2005 11.2. Informative References [BUF2008] J. Buford. Hybrid Overlay Multicast Framework. February 2008. Internet Draft draft-irtf-sam-hybrid-overlay- framework-02, work in progress. [BAS2007] S. Baset, H. Schulzrinne, M. Matuszewski. Internet Draft draft-baset-p2psip-p2pp-01, Work in progress. [THA2007] D. Thale, M. Talwar, A. Aggarwal, L. Vicisano, T. Pusateri. Automatic IP Multicast Without Explicit Tunnels (AMT). Internet Draft draft-ietf-mboned-auto-multicast-08, Work in progress. Oct 2007. Buford Expires September 12, 2008 [Page 11] Internet-Draft SAM Overlay Protocol March 12, 2008 Author's Addresses John Buford Avaya Labs 307 Middletown-Lincroft Road Lincroft, NJ 07738, USA Email: buford at samrg dot org Buford Expires September 12, 2008 [Page 12] Internet-Draft SAM Overlay Protocol March 12, 2008 Full Copyright Statement Copyright (C) The IETF Trust (2008). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Buford Expires September 12, 2008 [Page 13]