Internet DRAFT - draft-buford-irtf-sam-overlay-protocol
draft-buford-irtf-sam-overlay-protocol
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]
