SAM Research Group J. Buford
Internet-Draft Avaya Labs Research
Intended status: Informational M. Kolberg, Ed.
Expires: September 2, 2010 University of Stirling
T C. Schmidt
HAW Hamburg
M. Waehlisch
link-lab & FU Berlin
March 01, 2010
Application Layer Multicast Extensions to RELOAD
draft-kolberg-sam-baseline-protocol-00
Abstract
We describe protocol and API extensions to P2P-SIP for constructing
SAM sessions using hybrid combinations of Application Layer
Multicast, native multicast, and multicast tunnels. We use the AMT
relay and gateway elements for interoperation between native regions
and ALM regions. The baseline architecture allows different overlay
algorithms and different ALM control algorithms to be used.
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and 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 2, 2010.
Copyright Notice
Buford, et al. Expires September 2, 2010 [Page 1]
Internet-Draft ALM Extensions to RELOAD March 2010
Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Overlay Network . . . . . . . . . . . . . . . . . . . . . 5
2.2. Overlay Multicast . . . . . . . . . . . . . . . . . . . . 5
2.3. Peer . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.4. Multi-Destination Routing . . . . . . . . . . . . . . . . 5
3. Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.1. Overlay . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.2. Overlay Multicast . . . . . . . . . . . . . . . . . . . . 6
3.3. P2PSIP . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.4. NAT . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.5. Regions . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.6. AMT . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
4. Hybrid ALM Tree Operations . . . . . . . . . . . . . . . . . . 8
4.1. ALM-Only Tree - Algorithm 1 . . . . . . . . . . . . . . . 10
4.2. ALM tree with peer at AMT site (AMT-GW) . . . . . . . . . 11
4.3. ALM tree with NM peer using AMT-R . . . . . . . . . . . . 11
4.4. ALM tree with NM peer with P-AMT-R . . . . . . . . . . . . 12
4.5. Mixed Region Scenarios . . . . . . . . . . . . . . . . . . 12
5. Group Management API . . . . . . . . . . . . . . . . . . . . . 13
5.1. Data Types . . . . . . . . . . . . . . . . . . . . . . . . 14
5.2. Send and Receive Calls . . . . . . . . . . . . . . . . . . 14
6. Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
6.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 14
6.2. Tree Lifecylce Messages . . . . . . . . . . . . . . . . . 15
6.2.1. Create Tree . . . . . . . . . . . . . . . . . . . . . 15
6.2.2. Join . . . . . . . . . . . . . . . . . . . . . . . . . 16
6.2.3. Join Accept . . . . . . . . . . . . . . . . . . . . . 16
6.2.4. Join Confirm . . . . . . . . . . . . . . . . . . . . . 17
6.2.5. Join Decline . . . . . . . . . . . . . . . . . . . . . 17
6.2.6. Join Via AMT Gateway . . . . . . . . . . . . . . . . . 18
Buford, et al. Expires September 2, 2010 [Page 2]
Internet-Draft ALM Extensions to RELOAD March 2010
6.2.7. Join Via Native Link . . . . . . . . . . . . . . . . . 18
6.2.8. Leave . . . . . . . . . . . . . . . . . . . . . . . . 19
6.2.9. Leave via AMT Gateway . . . . . . . . . . . . . . . . 20
6.2.10. Re-Form or Optimize Tree . . . . . . . . . . . . . . . 21
6.2.11. Heartbeat . . . . . . . . . . . . . . . . . . . . . . 21
6.3. AMT Gateway Advertisement and Discovery . . . . . . . . . 21
6.4. Peer Region and Multicast Properties Messages . . . . . . 22
7. RELOAD Usages . . . . . . . . . . . . . . . . . . . . . . . . 23
7.1. ALM Usage for RELOAD . . . . . . . . . . . . . . . . . . . 24
7.2. Hybrid ALM Usage for RELOAD . . . . . . . . . . . . . . . 24
8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24
10. Security Considerations . . . . . . . . . . . . . . . . . . . 24
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25
11.1. Normative References . . . . . . . . . . . . . . . . . . . 25
11.2. Informative References . . . . . . . . . . . . . . . . . . 25
Appendix A. Additional Stuff . . . . . . . . . . . . . . . . . . 27
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27
Buford, et al. Expires September 2, 2010 [Page 3]
Internet-Draft ALM Extensions to RELOAD March 2010
1. Introduction
The concept of scalable adaptive multicast includes both scaling
properties and adaptability properties. Scalability is intended to
cover:
o large group size
o large numbers of small groups
o rate of group membership change
o admission control for QoS
o use with network layer QoS mechanisms
o varying degrees of reliability
o trees connect nodes over global internet
Adaptability includes
o use of different control mechanisms for different multicast trees
depending on initial application parameters or application class
o changing multicast tree structure depending on changes in
application requirements, network conditions, and membership
o use of different control mechanisms and tree structure in
different regions of network depending on native multicast
support, network characteristics, and node behavior
In this document we describe a protocol and API extension to P2P-SIP
[P2P-SIP] for constructing SAM sessions using hybrid combinations of
Application Layer Multicast, native multicast, and multicast tunnels.
1.1. Requirements Language
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].
2. Definitions
Buford, et al. Expires September 2, 2010 [Page 4]
Internet-Draft ALM Extensions to RELOAD March 2010
2.1. Overlay Network
P P P P P
..+....+....+...+.....+...
. +P
P+ .
. +P
..+....+....+...+.....+...
P P P P P
Figure 1
Overlay network - An application layer virtual or logical network in
which end points are addressable and that provides connectivity,
routing, and messaging between end points. Overlay networks are
frequently used as a substrate for deploying new network services, or
for providing a routing topology not available from the underlying
physical network. Many peer-to-peer systems are overlay networks
that run on top of the Internet. In the above figure, "P" indicates
overlay peers, and peers are connected in a logical address space.
The links shown in the figure represent predecessor/successor links.
Depending on the overlay routing model, additional or different links
may be present.
2.2. Overlay Multicast
Overlay Multicast (OM): Hosts participating in a multicast session
form an overlay network and utilize unicast connections among pairs
of hosts for data dissemination. The hosts in overlay multicast
exclusively handle group management, routing, and tree construction,
without any support from Internet routers. This is also commonly
known as Application Layer Multicast (ALM) or End System Multicast
(ESM). We call systems which use proxies connected in an overlay
multicast backbone "proxied overlay multicast" or POM.
2.3. Peer
Peer: an autonomous end system that is connected to the physical
network and participates in and contributes resources to overlay
construction, routing and maintenance. Some peers may also perform
additional roles such as connection relays, super nodes, NAT
traversal, and data storage.
2.4. Multi-Destination Routing
Multi-Destination Routing (MDR): A type of multicast routing in which
group member's addresses are explicitly listed in each packet
transmitted from the sender [AGU1984]. XCAST [RFC5058] is an
Buford, et al. Expires September 2, 2010 [Page 5]
Internet-Draft ALM Extensions to RELOAD March 2010
experimental MDR protocol. A hybrid host group and MDR design is
described in [HE2005].
3. Assumptions
3.1. Overlay
Peers connect in a large-scale overlay, which may be used for a
variety of peer-to-peer applications in addition to multicast
sessions. Peers may assume additional roles in the overlay beyond
participation in the overlay and in multicast trees. We assume a
single structured overlay routing algorithm is used. Any of a
variety of multi-hop, one-hop, or variable-hop overlay algorithms
could be used.
Castro et al. [CASTRO2003]compared multi-hop overlays and found that
tree-based construction in a single overlay out-performed using
separate overlays for each multicast session. We use a single
overlay rather than separate overlays per multicast sessions. We
defer federated and hierarchical multi-overlay designs to later
versions of this document.
Peers may be distributed throughout the network, in regions where
native multicast (NM) is available as well as regions where it is not
available.
An overlay multicast algorithm may leverage the overlay's mechanism
for maintaining overlay state in the face of churn. For example, a
peer may hold a number of DHT (Distributed Hash Table) entries. When
the peer gracefully leaves the overlay, it transfers those entries to
the nearest peer. When another peers joins which is closer to some
of the entries than the current peer which holds those entries, than
those entries are migrated. Overlay churn affects multicast trees as
well; remedies include automatic migration of the tree state and
automatic re-join operations for dislocated children nodes.
3.2. Overlay Multicast
The overlay supports concurrent multiple multicast trees. The limit
on number of concurrent trees depends on peer and network resources
and is not an intrinsic property of the overlay. Some multicast
trees will contain peers use ALM only, i.e., the peers do not have NM
connectivity. Some multicast trees will contain peers with a
combination of ALM and NM. Although the overlay could be used to
form trees of NM-only peers, if such peers are all in the same region
we expect native mechanisms to be used for such tree construction,
and if such peers are in different regions we expect AMT to handle
Buford, et al. Expires September 2, 2010 [Page 6]
Internet-Draft ALM Extensions to RELOAD March 2010
most cases of interest.
Peers are able to determine, through configuration or discovery:
o Can they connect to a NM router
o Is an AMT gateway accessible
o Can the peer support the AMT-GW functionality locally
o Is MDR supported in the region
3.3. P2PSIP
We use P2PSIP [I-D.ietf-p2psip-base] as the distibuted hash table
(DHT) for data storage and overlay by which the peers interconnect
and route messages. P2PSIP is a generic P2P overlay, and application
support is defined by profiles called Usages. In this document we
present an Application Layer Multicast (ALM) Usage and a Hybrid ALM
Usage.
We also follow the P2PSIP terminology for overlay specific terms,
such as the distinction between peer, node, and client.
3.4. NAT
Some nodes in the overlay may be in a private address space and
behind firewalls. We use the P2PSIP mechanisms for NAT traversal.
We permit clients to be leaf nodes in an ALM or HALM tree. The
specific capabilities of clients in terms of tree creation and being
parents of other nodes will be described in subsequent versions.
3.5. Regions
A region is a contiguous internetwork such that if native multicast
is available, all routers and end systems can connect to native
multicast groups available in that region. A region may include end
systems.
3.6. AMT
We use AMT [I-D.ietf-mboned-auto-multicast] to connect nodes in ALM
region with nodes in NM region. AMT permits AMT-R and AMT-GW
functionality to be embedded in hosts or specially configured
routers. We assume AMT-R and AMT-GW can be implemented in nodes.
AMT has certain restrictions: 1) isolated sites/hosts can receive
SSM, 2) isolated non-NAT sites/hosts can send SSM, 3) isolated sites/
hosts can receive general multicast. AMT does not permit isolated
Buford, et al. Expires September 2, 2010 [Page 7]
Internet-Draft ALM Extensions to RELOAD March 2010
sites/hosts to send general multicast.
4. Hybrid ALM Tree Operations
Peers use the overlay to support ALM operations such as:
o Create tree
o Join
o Leave
o Re-Form or optimize tree
There are a variety of algorithms for peers to form multicast trees
in the overlay. We permit multiple such algorithms to be supported
in the overlay, since different algorithms may be more suitable for
certain application requirements, and since we wish to support
experimentation. Therefore, overlay messaging corresponding to the
set of overlay multicast operations must carry algorithm
identification information.
For example, for small groups, the join point might be directly
assigned by the rendezvous point, while for large trees the join
request might be propagated down the tree with candidate parents
forwarding their position directly to the new node.
In addition to these overlay level tree operations, some peers may
implement additional operations to map tree operations to native
multicast and/or AMT [I-D.ietf-mboned-auto-multicast] connections
Buford, et al. Expires September 2, 2010 [Page 8]
Internet-Draft ALM Extensions to RELOAD March 2010
+---------------+ +---------------+
| AMT Site | P P P P P | Native MCast |
| ..........+...+....+....+...+.....+....+....... |
| . +---++ ++---+ +P |
| P+ |AMT | |AMT | . |
| . |GW | |RLY | +P |
| . +---++ ++---+ . |
+-----+---------+ +------+--------+
. .
. +------+--------+
. | . Native |
. | . MDR |
P+....+P .....+...+..+P |
. . | P |
+--------+------+ . +---------------+
| Native . MCast| .
| . | . +---------------+
| P-AMT-R+ | P+ |Native Mcast |
| . | . ++---+ |
| P-AMT-R+ | P-AMT-GW+===|AMT | |
| ...+...+.. . |RLY | |
| P | .+....+........+.....+ ++---+ |
+---------------+ P P P P +---------------+
Figure 2
In the above figure we show the hybrid architecture in six regions of
the network. All peers are connected in an overlay, and the figure
shows the predecessor/successor links between peers. The peers may
have other connections in the overlay.
o No native multicast: Peers (P) in this region connect to the
overlay
o Native multicast (NM) with a local AMT gateway (AMT GW). There
are one or more peers (P) connected to the overlay in this region.
o Native multicast with a local AMT relay (AMT RLY). There are one
or more peers (P) connected to the overlay in this region.
o Native multicast with one or more peers which emulate the AMT
relay behavior (P-AMT-R) which also connect to the overlay. There
may be other peers (P) which also connect to the overlay.
o Native MDR is a native multicast region using multi-destination
routing, in which one or more peers reside in the region.
Buford, et al. Expires September 2, 2010 [Page 9]
Internet-Draft ALM Extensions to RELOAD March 2010
o Native multicast with no peers that connect to the overlay, but
for which there is at least one peer in the unicast-only part of
the network which can behave as an AMT-GW (P-AMT-GW) to connect to
multicast sources through an AMT-R for that region. It may be
feasible to also allow non-peer hosts in such a region to
participate as receivers of overlay multicast; for this version,
we prefer to require all hosts to join the overlay as peers.
4.1. ALM-Only Tree - Algorithm 1
Here is a simplistic algorithm for forming a multicast tree in the
overlay. Its main advantage is use of the overlay routing mechanism
for routing both control and data messages. The group creator
doesn't have to be the root of the tree or even in the tree. It
doesn't consider per node load, admission control, or alternative
paths.
As stated earlier, multiple algorithms will co-exist in the overlay.
1. Peer which initiates multicast group:
groupID = create(); // allocate a unique groupId
// the root is the nearest peer in the overlay
// out of band advertisement or
// distribution of groupID,
// perhaps by publishing in DHT
Figure 3
2. Any joining peer:
// out of band discovery of groupID, perhaps by lookup in DHT
joinTree(groupID); // sends "join groupID" message
Figure 4
The overlay routes the join request using the overlay routing
mechanism toward the peer with the nearest id to the groupID.
This peer is the root. Peers on the path to the root join the
tree as forwarding points.
3. Leave Tree:
leaveTree(groupID) // removes this node from the tree
Buford, et al. Expires September 2, 2010 [Page 10]
Internet-Draft ALM Extensions to RELOAD March 2010
Propagates a leave message to each child node and to the parent
node. If the parent node is a forwarding node and this is its
last child, then it propagates a leave message to its parent. A
child node receiving a leave message from a parent sends a join
message to the groupID.
4. Message forwarding:
multicastMsg(groupID, msg);
5.
* SSM tree The creator of the tree is the source. It sends data
messages to the tree root which are forwarded down the tree.
* ASM tree A node sending a data message sends the message to
its parent and its children. Each node receiving a data
message from one edge forwards it to remaining tree edges it
is connected to.
4.2. ALM tree with peer at AMT site (AMT-GW)
The joining peer connects to the tree using the ALM protocol, or, if
the tree includes a peer in an NM region, then the peer can use the
AMT GW to connect to the NM peer through the AMT relay. The peer can
choose the delivery path based on latency and throughput. If the
peer is not a joining peer and is on the overlay path of a join
request:
o If its next hop is a peer in an NM region with AMT-R, then it can
select either overlay routed multicast messages or AMT delivered
multicast messages.
o If its next hop is a peer outside of an NM region, then it could
use either ALM only or use AMT delivery as an alternate path
4.3. ALM tree with NM peer using AMT-R
There are these cases:
o There is no peer in the tree which has an AMT-GW. The NM peer
uses ALM routing.
o There is at least one peer in the tree which can function as
P-AMT-GW. The NM peer can join the tree using ALM routing and/or
connecting to the P-AMT-GW.
Buford, et al. Expires September 2, 2010 [Page 11]
Internet-Draft ALM Extensions to RELOAD March 2010
o There is at least one peer in the tree which is in an AMT-GW
region. The NM peer can join the tree using ALM routing and/or
connecting to the AMT-GW.
4.4. ALM tree with NM peer with P-AMT-R
Either the NM peer supports P-AMT-R or another peer in the multcast
tree in the same region is P-AMT-R capable. The three cases above
apply here, replacing AMT-R with P-AMT-R.
4.5. Mixed Region Scenarios
In version 2 of this document we elaborate on:
o ALM tree topology vs NM topology and NM-ALM edges
o Single NM-ALM edge nodes vs multi NM peers from same region in the
tree
o Initial tree membership is ALM vs initial tree membership is NM
For ALM tree topology vs NM topology, all peers belong to the
overlay, but only P-ALM peers use overlay routing for multicast data
transmission. As a default behavior, a P-NM peer should generally
prefer to join the tree via an AMT-GW node. But there may be special
cases (small trees, short multicast sessions, trees where most of the
members are known to be P-ALM) in which the peer can override this to
specify an ALM-only join. A P-NM peer may also accept P-ALM children
which don't use the AMT tunnel path to participate in the multicast
tree.
Consider 3 types of tree links: P-ALM to P-ALM, P-NM to P-NM and
P-ALM to/from P-NM:
o P-ALM to P-ALM This is a normal ALM tree path with management
strictly in the overlay
o P-NM to P-NM If the peers are in the same region, then the data
path use native multicast capability in that region, and control
occurs in ALM layer for ALM tree coordination and NM layer for
native multicast purposes. If the peers are in different NM
regions, then, if AMT gateways are available and configured to
support an AMT tunnel between the regions, a tunnel is created
using the AMT protocol (or already exists for this multicast
group). The peers connect to their respective AMT gateways using
the AMT procedure.
Buford, et al. Expires September 2, 2010 [Page 12]
Internet-Draft ALM Extensions to RELOAD March 2010
o P-ALM to/from P-NM The connection can be either ALM or AMT tunnel
depending on the context.
We expect two new functions are needed to build hybrid trees:
o joinViaAMTGateway(peer, AMT-GW, group_id) where 'Peer' is the peer
requesting to join the ALM group identified by group_id, and
AMT-GW is the ip address of the AMT gateway that the peer uses in
its native multicast region. Request is transmitted to one or
more parent peer candiates and/or rendezvous peers for the
specified group id, according to the usual join protocol in this
overlay. If the parent peer is a P-AMT-GW, then a tunnel is
formed using the AMT protocol from the P-AMT-GW to the specified
AMT-GW. If parent peer is a peer P-NM in native multicast region,
then 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 rules.
o leaveViaAMTGateway(peer, AMT-GW, group_id)where 'Peer' is the peer
requesting to leave the ALM group identified by group_id, and
AMT-GW is the ip address of the AMT gateway that the peer uses in
its native multicast region. Request is transmitted the parent
peer which is associated with the AMT-GW or provides that role.
If the parent peer is a P-AMT-GW, then it removes the child from
its AMT children list and may tear down the AMT tunnel P-AMT-GW to
the specified AMT-GW if no other children are using it. If parent
peer is a peer P-NM in native multicast region, then the tunnel is
created between P-NM's AMT-GW and the specified AMT-GW, using the
AMT protocol.
Regarding initial tree membership being either P-NM or P-ALM node(s),
we expect the general case should be that hybrid tree formation is
supported transparently regardless.
5. Group Management API
The group management API describes interfaces to register or
deregister multicast listeners, and to send and receive multicast
data. An important issue lies in addressing. While native multicast
is bound to IP addresses, ALM uses arbitrary strings as multicast
names, which will be mapped to the overlay identifier space.
The aim of this API is to implement group-oriented data communication
independent of the underlying distribution technologies. In
particular, applications should be designed to meet efficiency
requirements, but also to remain robust with respect to deployment.
Buford, et al. Expires September 2, 2010 [Page 13]
Internet-Draft ALM Extensions to RELOAD March 2010
The API is located between applications and the group stack at the
current host. We do not consider an interface between hosts.
5.1. Data Types
Address is any address structure suitable with respect to the
technology available at the host. This may be an IPv4 or an IPv6
address, or any overlay identifier.
Handle gives a reference to a specific instance of a communication
object.
5.2. Send and Receive Calls
init(out Handle s) This call gives a handle on a multicast socket,
which will be used for subsequent communication.
join(in Address a, in Handle s) This operation initiates a group
subscription for the address a.
leave(in Address a, in Handle s) This operation results in an
unsubscription for the given address a.
send(in Address a, in Handle s, in Message m) This call sends data m
to the multicast address a.
receive(in Handle s, out Message m) This call delivers data m to the
application.
6. Protocol
6.1. Introduction
In this document we define messages for hybrid overlay multicast tree
creation, using an existing proposal (RELOAD) in the P2P-SIP WG
[I-D.ietf-p2psip-base] for a universal structured peer-to-peer
overlay protocol. RELOAD provides the mechanism to support a number
of overlay topologies. Hence the hybrid overlay multicast framework
[TODO: BUF2008] (hereafter SAM framework) can be used with P2P-SIP,
and that the SAM framework is overlay agnostic.
We are not proposing that these SAM-specific messages be incorporated
into RELOAD since constructing the SAM framework is still a research
activity. However, we do propose that RELOAD add an extension
mechanism.
As discussed in the SAM requirements draft, there are a variety of
Buford, et al. Expires September 2, 2010 [Page 14]
Internet-Draft ALM Extensions to RELOAD March 2010
ALM tree formation and tree maintenance algorithms. The intent of
this specification is to be algorithm agnostic, similar to how RELOAD
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 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.
6.2. Tree Lifecylce Messages
Peers use the overlay to transmit ALM (application layer multicast)
operations and hybrid ALM operations defined in this section.
6.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.
struct {
NodeID PeerId;
opaque SessionKey<0..2^32-1>;
NodeID GroupId;
Dictionary Options;
} CreateALMTree;
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.
Buford, et al. Expires September 2, 2010 [Page 15]
Internet-Draft ALM Extensions to RELOAD March 2010
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.
6.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.
struct {
NodeID PeerId;
NodeID GroupId;
Dictionary Options;
} Join;
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
6.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.
struct {
NodeID ParentPeerId;
NodeID ChildPeerId;
NodeID GroupId;
Dictionary Options;
} JoinAccept;
ParentPeerId: overlay address of a peer which accepts the joining
peer
ChildPeerId: overlay address of joining peer
Buford, et al. Expires September 2, 2010 [Page 16]
Internet-Draft ALM Extensions to RELOAD March 2010
GroupId: the overlay address of the root of the tree
Options: name-value list of options accepted by parent peer
6.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.
struct {
NodeID ChildPeerId;
NodeID ParentPeerId;
NodeID GroupId;
Dictionary Options;
} JoinConfirm;
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
6.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.
struct {
NodeID PeerId;
NodeID ParentPeerId;
NodeID GroupId;
} JoinDecline;
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
Buford, et al. Expires September 2, 2010 [Page 17]
Internet-Draft ALM Extensions to RELOAD March 2010
6.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.
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.
struct {
NodeID PeerId;
IpAddressPort AMT-GW;
NodeID GroupId;
Dictionary Options;
} JoinViaAMTGateway;
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
6.2.7. Join Via Native Link
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
Buford, et al. Expires September 2, 2010 [Page 18]
Internet-Draft ALM Extensions to RELOAD March 2010
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
via NM path, the parent-child relationship established by this join
is for control and membership management
struct {
NodeID ChildPeerId;
NodeID ParentPeerId;
NodeID GroupId;
Dictionary Options;
} JoinWithNativeLink;
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
6.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.
struct {
NodeID PeerId;
NodeID GroupId;
Dictionary Options;
} Leave;
Buford, et al. Expires September 2, 2010 [Page 19]
Internet-Draft ALM Extensions to RELOAD March 2010
PeerId: overlay address of leaving peer
GroupId: the overlay address of the root of the tree
Options: name-value list of options
6.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.
struct {
NodeID PeerId;
NodeID AdjacentPeerId;
IpAddressPort AMT-GW;
NodeID GroupId;
Dictionary Options;
} LeaveViaAMTGateway;
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
Buford, et al. Expires September 2, 2010 [Page 20]
Internet-Draft ALM Extensions to RELOAD March 2010
6.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.
struct {
NodeID GroupId;
NodeID PeerId;
Dictionary Options;
} Reform;
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
6.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.
struct {
NodeID PeerId1;
NodeID PeerId2;
NodeID GroupId;
} Heartbeat;
PeerId1: source of heartbeat
PeerId2: destination of heartbeat
GroupId: overlay address of the root of the tree
6.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
Buford, et al. Expires September 2, 2010 [Page 21]
Internet-Draft ALM Extensions to RELOAD March 2010
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.
struct {
NodeID PeerId;
ResourceID Key;
opaque Region<0..2^32-1>;
Dictionary Options;
} PublishAMTGateway;
struct {
NodeID PeerId;
ResourceID Key;
} LookupAMTGateway;
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
6.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.
struct {
NodeID PeerId;
ResourceID Key;
opaque Region<0..2^32-1>;
Dictionary Options;
} PublishPeerNMInfo;
struct {
NodeID PeerId;
ResourceID Key;
} LookupPeerNMInfo;
PeerId: the peer which is the AMT gateway
Buford, et al. Expires September 2, 2010 [Page 22]
Internet-Draft ALM Extensions to RELOAD March 2010
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.
7. RELOAD Usages
Applications of RELOAD are restricted in the data types that be can
stored in the DHT. The profile of accepted data types for an
application is referred to as a Usage. RELOAD is designed so that
new applications can easily define new Usages. New RELOAD Usages are
needed for hybrid multicast applications since the data types in base
RELOAD and existing usages are not sufficient.
We define an ALM Usage and a Hybrid ALM Usage in RELOAD. The ALM
Usage is sufficient for applications which only require ALM
functionality in the overlay. The Hybrid ALM (HALM) Usage extends
the ALM Usage so that hybrid native multicast and ALM trees can be
used by applications.
The ALM Uaage involves the functions:
o ALM applications use the RELOAD data storage functionality to
store a groupID when a new ALM tree is created in the overlay, and
to retrieve groupIDs for existing ALM trees.
o ALM applications use the RELOAD data storage functionality to
store a set of attributes for an ALM tree, such as owner, tree
size, tree height, tree formation algorithm, and join criteria.
o ALM applications and management tools use the RELOAD data storage
functionality to store diagnostic information about the operation
of tree, including average number of tree, delay from source to
leaf nodes, bandwidth use, lost packet rate. In addition,
diagnostic information may include statistics specific to the tree
root, or to any node in the tree.
The Hybrid ALM Usage involves the following additional functions:
o HALM applications use the RELOAD data storage functionality to
store a set of attributes for a AMT Gateway that can connect to at
least one node in the overlay.
o HALM applications use the RELOAD data storage functionality to
store a set of attributes about a native multicast region
associated with an AMT Gateway.
Buford, et al. Expires September 2, 2010 [Page 23]
Internet-Draft ALM Extensions to RELOAD March 2010
o HALM applications and management tools use the RELOAD data storage
functionality to store diagnostic information about the operation
of AMT and ALM interconnections.
A RELOAD Usage is required [I-D.ietf-p2psip-base] to define the
following:
o Register Kind-Id points
o Define data structures for each kind
o Defines access control rules for each kind
o Defines the Resource Name used to hash to the Resource ID where
the kind is stored
o Addresses restoration of values after recovery from a network
partition
o Defines the types of connections that can be initiated using
AppConnect
The following sections are preliminary steps towards formalizing the
for ALM and HALM Uages.
7.1. ALM Usage for RELOAD
A ALM GroupID is a RELOAD Node-ID. The owner of a ALM group creates
a RELOAD Node-ID as specified in [I-D.ietf-p2psip-base]. This means
that a GroupID is used as a RELOAD Destination for overlay routing
purposes.
7.2. Hybrid ALM Usage for RELOAD
8. Examples
TBD.
9. IANA Considerations
This memo includes no request to IANA.
10. Security Considerations
Overlays are vulnerable to DOS and collusion attacks. We are not
Buford, et al. Expires September 2, 2010 [Page 24]
Internet-Draft ALM Extensions to RELOAD March 2010
solving overlay security issues. We assume the centralized node
authentication model as defined in [I-D.ietf-p2psip-base].
11. References
11.1. Normative References
[RFC0792] Postel, J., "Internet Control Message Protocol", STD 5,
RFC 792, September 1981.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A.
Thyagarajan, "Internet Group Management Protocol, Version
3", RFC 3376, October 2002.
[RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery
Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.
[RFC4605] Fenner, B., He, H., Haberman, B., and H. Sandick,
"Internet Group Management Protocol (IGMP) / Multicast
Listener Discovery (MLD)-Based Multicast Forwarding
("IGMP/MLD Proxying")", RFC 4605, August 2006.
[RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for
IP", RFC 4607, August 2006.
[RFC5058] Boivie, R., Feldman, N., Imai, Y., Livens, W., and D.
Ooms, "Explicit Multicast (Xcast) Concepts and Options",
RFC 5058, November 2007.
11.2. Informative References
[AGU1984] Aguilar, L., "Datagram Routing for Internet Multicasting",
ACM Sigcomm 84 1984, March 1984.
[CASTRO2002]
Castro, M., Druschel, P., Kermarrec, A., and A. Rowstron,
"Scribe: A large-scale and decentralized application-level
multicast infrastructure", IEEE Journal on Selected Areas
in Communications vol.20, No.8, October 2002, <http://
research.microsoft.com/en-us/um/people/antr/past/
jsac.pdf>.
[CASTRO2003]
Castro, M., Jones, M., Kermarrec, A., Rowstron, A.,
Buford, et al. Expires September 2, 2010 [Page 25]
Internet-Draft ALM Extensions to RELOAD March 2010
Theimer, M., Wang, H., and A. Wolman, "An Evaluation of
Scalable Application-level Multicast Built Using Peer-to-
peer overlays", Proceedings of IEEE INFOCOM 2003,
April 2003, <http://research.microsoft.com/en-us/um/
people/mcastro/publications/infocom-compare.pdf>.
[HE2005] He, Q. and M. Ammar, "Dynamic Host-Group/Multi-Destination
Routing for Multicast Sessions", J. Telecommunication
Systems vol. 28, pp. 409-433.
[I-D.ietf-mboned-auto-multicast]
Thaler, D., Talwar, M., Aggarwal, A., Vicisano, L., and T.
Pusateri, "Automatic IP Multicast Without Explicit Tunnels
(AMT)", draft-ietf-mboned-auto-multicast-09 (work in
progress), June 2008.
[I-D.ietf-p2psip-base]
Jennings, C., Lowekamp, B., Rescorla, E., Baset, S., and
H. Schulzrinne, "REsource LOcation And Discovery (RELOAD)
Base Protocol", draft-ietf-p2psip-base-07 (work in
progress), February 2010.
[I-D.ietf-p2psip-sip]
Jennings, C., Lowekamp, B., Rescorla, E., Baset, S., and
H. Schulzrinne, "A SIP Usage for RELOAD",
draft-ietf-p2psip-sip-03 (work in progress), October 2009.
[I-D.irtf-p2prg-rtc-security]
Schulzrinne, H., Marocco, E., and E. Ivov, "Security
Issues and Solutions in Peer-to-peer Systems for Realtime
Communications", draft-irtf-p2prg-rtc-security-05 (work in
progress), September 2009.
[I-D.matuszewski-p2psip-security-overview]
Yongchao, S., Matuszewski, M., and D. York, "P2PSIP
Security Overview and Risk Analysis",
draft-matuszewski-p2psip-security-overview-01 (work in
progress), October 2009.
[I-D.waehlisch-sam-common-api]
Waehlisch, M., Schmidt, T., and S. Venaas, "A Common API
for Transparent Hybrid Multicast",
draft-waehlisch-sam-common-api-01 (work in progress),
October 2009.
[RFC1930] Hawkinson, J. and T. Bates, "Guidelines for creation,
selection, and registration of an Autonomous System (AS)",
BCP 6, RFC 1930, March 1996.
Buford, et al. Expires September 2, 2010 [Page 26]
Internet-Draft ALM Extensions to RELOAD March 2010
[RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC
Text on Security Considerations", BCP 72, RFC 3552,
July 2003.
[RFC4286] Haberman, B. and J. Martin, "Multicast Router Discovery",
RFC 4286, December 2005.
Appendix A. Additional Stuff
This becomes an Appendix.
Authors' Addresses
John Buford
Avaya Labs Research
233 Mt. Airy Rd
Basking Ridge, New Jersey 07920
USA
Phone: +1 908 848 5675
Email: buford@avaya.com
Mario Kolberg (editor)
University of Stirling
Dept. Computing Science and Mathematics
Stirling, FK9 4LA
UK
Phone: +44 1786 46 7440
Email: mkolberg@ieee.org
URI: http://www.cs.stir.ac.uk/~mko
Thomas C. Schmidt
HAW Hamburg
Berliner Tor 7
Hamburg, 20099
Germany
Email: schmidt@informatik.haw-hamburg.de
URI: http://inet.cpt.haw-hamburg.de/members/schmidt
Buford, et al. Expires September 2, 2010 [Page 27]
Internet-Draft ALM Extensions to RELOAD March 2010
Matthias Waehlisch
link-lab & FU Berlin
Hoenower Str. 35
Berlin 10318
Germany
Email: mw@link-lab.net
Buford, et al. Expires September 2, 2010 [Page 28]