[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01

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]


Html markup produced by rfcmarkup 1.126, available from https://tools.ietf.org/tools/rfcmarkup/