[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
SSM Proxy protocol (SSMP) draft
Hi
Attached is an Internet-Draft describing the SSM Proxy protocol (SSMP). SSMP is
an application-layer protocol which extends the Source-Specific Multicast
architecture to provide efficient support for large and dynamic sets of senders.
For more background information please see:
http://www.nrg.cs.uoregon.edu/ssmproxies/index.html
And my implementation-oriented page is at:
http://www.cs.uoregon.edu/~fabbri/SSMP/index.html
We look forward to hearing your comments!
-Aaron
-------------------==============================------------------
Aaron Fabbri http://www.cs.uoregon.edu/~fabbri fabbri@cs.uoregon.edu
-------------------==============================------------------
UONRG Aaron Fabbri
INTERNET DRAFT Daniel Zappala
Expire in six months University of Oregon,
Network Research Group
May 30, 2001
SSM-Proxy Protocol (SSMP)
<draft-uonrg-ssmpp-v1-00.txt>
Status of this Memo
This document is a Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026.
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.
Abstract
This draft specifies the initial SSM-Proxy protocol (SSMP). SSMP is
an application-layer protocol which uses Single-Source Multicast
(SSM) as a network-layer primitive to efficiently support multiple-
sender multicast groups and the Any-Source Multicast (ASM) service
model.
Contents
1. Introduction
1.1 Purpose ......................................... 2
1.2 Overall Operation ............................... 3
1.3 Advantages ...................................... 4
1.4 Implementation .................................. 6
2. Notational Conventions and Generic Grammar ............ 7
Fabbri, Zappala [Page 1]
INTERNET DRAFT SSM Proxy Protocol (SSMP) 30 May 2001
3. Protocol Parameters
3.1 SSMP Version .................................... 7
4. SSMP Messages
4.1 General Packet Format ........................... 7
4.2 Message Types ................................... 8
4.3 Request ......................................... 8
4.4 Response ........................................ 9
4.5 Control Channel Message ......................... 11
4.6 IP Addresses and Port Numbers ................... 11
4.7 UNICAST/1.0 Messages ............................ 12
4.8 MULTICAST/1.0 Messages .......................... 12
5. Protocol Operation .................................... 13
5.1 Simplifying Assumptions ......................... 14
5.2 Protocol States ................................. 14
5.3 Pseudocode Definitions .......................... 14
5.4 Joining and Leaving ............................. 15
5.5 Message Handling ................................ 16
5.6 Proxy List Maintenance .......................... 18
5.7 UNICAST/1.0 Operation ........................... 18
5.8 MULTICAST/1.0 Operation ......................... 19
6. Protocol Examples ..................................... 20
7. Security Considerations ............................... 21
8. Terminology ........................................... 22
9. Future Enhancements ................................... 23
10. References ............................................ 23
1. Introduction
1.1 Purpose
For many years the networking community has been debating how to
support multicast communication on the Internet. One of the largest
questions is how much functionality should be implemented at the
network (IP) layer. Initial efforts have focused on developing
network-layer protocols such as PIM[1], MSDP[2], and MBGP[3] which
implement the Any-Source Multicast (ASM) group model in a fairly
robust and efficient manner. Unfortunately, these protocols are
somewhat complex and have seen slow deployment. Others have proposed
that multicast functionality be implemented solely at the edges of
the network [4], greatly simplifying deployment at the cost of some
performance. Another promising new approach adopts a more simple
Fabbri, Zappala [Page 2]
INTERNET DRAFT SSM Proxy Protocol (SSMP) 30 May 2001
multicast service model called Source-Specific Multicast (SSM), which
is implemented at the network layer. By making each multicast group
source-specific, SSM defines away the address allocation [5] problem
and removes source location complexity [2] from the network layer.
In this way, SSM alleviates some of the main problems associated with
the Any-Source Multicast (ASM) model.
We see two scenarios for SSM deployment: In the first scenario, SSM
is rapidly deployed and ASM is phased out. In this case, we wish to
augment SSM with an application-layer protocol which supports ASM
multicast groups. In the second scenario, SSM is deployed alongside
ASM. In this case, we want extend SSM to provide ASM with additional
application-layer services such as access control, fault tolerance,
lower setup delay, and permanent multicast addresses. Regardless of
the scenario, our main goal is to efficiently support potentially
large and dynamic sets of senders on top of an SSM infrastructure.
Toward this goal, this draft presents the Source-Specific Multicast
Proxy protocol (SSMP). SSMP is an application-layer protocol which
uses SSM as a network-layer primitive and generalizes the concept of
a session relay, first proposed by Holbrook and Cheriton[7].
1.2 Overall Operation
There are two simple ways of supporting multiple-sender groups with
SSM, proposed by Holbrook and Cheriton[7]. The first approach is to
use a separate (S,G) channel for each sender. This scheme results in
low end-to-end delay, high routing state, and places the burden of
source discovery on the receivers. The second approach, called
session relay, uses a single (S,G) channel. Senders unicast data to
S, and S multicasts this data down its tree. This approach results
in higher delay and low routing state. It does not require receivers
to perform source discovery but has poor fault tolerance.
Our protocol (SSMP) compromises between these two approaches by
generalizing the session relay (SR) approach to allow multiple active
SRs (proxies) for each group. In SSMP choosing exactly one proxy for
a group is equivalent to the session relay approach.
The SSMP protocol coordinates multiple multicast channels to
efficiently support Any-Source Multicast (ASM) style communication.
Each SSMP session (group) advertises a primary channel which we
denote (S0,G0). Each SSMP session also maintains a set of proxies
{P0,P1,...,Pk}, with P0=S0 being the primary proxy (S0,G0).
Backwards compatibility with SSM-only hosts is achieved by allowing
them to join the (S0,G0) channel to receive content. Likewise,
standard SSM senders may use this primary channel as a session relay.
Fabbri, Zappala [Page 3]
INTERNET DRAFT SSM Proxy Protocol (SSMP) 30 May 2001
[S1] R
| ^
V /
(P2)<========>(P0)------->R
/ ^ \
/\ // \---->R
R<---/ \ // V
/ V V R
V R (P1)<-_
R | \__
R<----| --[S2]
V
R
Figure 1 -- Basic SSM Proxy protocol
Figure 1 illustrates the basic operation of the protocol. Each SSMP
session maintains a set of proxies {P0,...,Pn}, and advertises the
primary proxy P0 and the primary channel (P0,G0). A host Pi wishing
to become a proxy contacts P0 and requests to join the set of
proxies. P0 then adds Pi to its list of proxies, and distributes
this list among all of the proxies. A sender (S1) sends to the group
by choosing a proxy (P2) and unicasting its data to it. This proxy
(P2) forwards this data to the other proxies, and then each proxy
multicasts it on its direct channel. Receivers subscribe to the
direct channel (Pi,Gi) of a nearby proxy to receive content.
For better performance (lower cost and delay) senders and receivers
should attach to the nearest proxy to reduce delay and routing state
(i.e. the proxy-rooted trees will not overlap). Middleware at the
client (sender or receiver) should automate selection of a nearest
proxy.
1.3 Advantages
Figure 2 summarizes the benefits of the SSM Proxy protocol. A key
goal of SSMP is to implement multiple-sender groups *efficiently*.
We have shown using simulation[8,9] that using a few proxies can
reduce the average delay significantly versus the session relay
(single proxy) approach, with little or no increase in bandwidth
cost. To achieve this level of efficiency, senders and receivers
should join to their nearest proxy. For this reason, the SSMP
implementation should include a routine for choosing the nearest (by
either hops or RTT delay) of a set of hosts.
Fabbri, Zappala [Page 4]
INTERNET DRAFT SSM Proxy Protocol (SSMP) 30 May 2001
Feature Protocol Properties
_________________________________________________________________
| | | |
| Source | SSM | Receiver burden |
| discovery with | Session Relay | Rendezvous through session |
| large, dynamic | | relay |
| set of senders | SSMP | Rendezvous through proxies |
|----------------|---------------|--------------------------------|
| Router state | SSM | O(|senders|) |
| | Session Relay | O(1) |
| | SSMP | O(1) with nearest attachment |
|----------------|---------------|--------------------------------|
| Sender set-up | SSM | Time for receivers to discover |
| delay | | and join new (S,G) |
| | Session Relay | None |
| | SSMP | None, unless waiting for |
| | | dynamic nearest attachment |
|----------------|---------------|--------------------------------|
| Fault tolerance| SSM | Good: per-sender channels are |
| | | independent |
| | Session Relay | Poor: whole group depends on |
| | | single session relay |
| | SSMP | Good: receivers experiencing |
| | | bad service may join another |
| | | proxy |
|----------------|---------------|--------------------------------|
| Sender-to- | SSM | Best: shortest path source |
| receiver delay | | trees |
| | Session Relay | Poor: session relay may be far |
| | | from shortest path from |
| | | sender to receiver |
| | SSMP | Good: approaches that of |
| | | separate channels (SSM) as |
| | | more proxies are used |
|----------------|---------------|--------------------------------|
| Backward | SSM | By definition |
| compatibility | Session Relay | " " |
| w/ SSM-only | SSMP | Yes: receivers can join primary|
| hosts | | channel, senders can use |
| | | relay immediately |
|________________|_______________|________________________________|
Figure 2 -- Comparison of SSM and SSM Proxy protocols
One of the goals of the SSM Proxy protocol is to provide multicast
application developers with a useful (higher) level of abstraction
for creating multiple-sender groups. For instance, SSMP handles
Fabbri, Zappala [Page 5]
INTERNET DRAFT SSM Proxy Protocol (SSMP) 30 May 2001
source discovery so the application developer need not implement it.
Since only the proxies need to be aware of changes in the set of
senders, and since proxies are few and well-known, source discovery
is handled more efficiently than were it implemented at the
receivers. Another advantage of SSMP is that it is backwards-
compatible with SSM-only hosts; session relay is supported for
senders, and receivers can simply join the advertised primary channel
(S0,G0).
1.4 Implementation
As shown in figure 3, the SSMP proxy protocol is divided into modules
or "sub-protocols". The proxy-distribution module handles all
control messages specific to the data distribution algorithm being
used by the proxies. The authentication module handles access control
and encryption services. In SSMP version 1.0, the authentication
protocol is trivial; anyone is allowed to send to the group.
Additionally, the only proxy-distribution protocol a SSMP/1.0 proxy
*must* support is UNICAST/1.0, which is designed to be as simple as
possible. The lower box in figure 3 represents the part of the
protocol used by multicast clients (senders and/or receivers). A
client may use the SSMP client protocol to automate attaching to the
nearest proxy, and to provide feedback to the proxies. [TODO:
receiver feedback is important to avoid dangling proxies].
__________________________________________
| ____________________ ________________ |
|| | | | |
|| Proxy-Distribution | | Authentication | |
||____________________| |________________| |
| |
| SSMP - proxy protocol |
|__________________________________________|
__________________________________________
| |
| SSMP - client protocol |
|__________________________________________|
Figure 3 - SSM Proxy protocol components
The remainder of this document is arranged as follows: Sections 2
through 4 specify the syntax of SSMP control messages. Section 5
specifies protocol semantics and behavior, and section 6 provides
some examples. Section 7 discusses security issues, and section 8
defines commonly used terms.
Fabbri, Zappala [Page 6]
INTERNET DRAFT SSM Proxy Protocol (SSMP) 30 May 2001
2. Notational Conventions and Generic Grammar
This document uses the Augmented Backus-Naur Form (ABNF) format as
described in RFC 2234 to specify protocol syntax. For this reason,
multiple syntax options are separated by '/' instead of the common or
character '|'. All SSMP messages are encoded in the 7-bit US-ASCII
character set.
3. Protocol Parameters
3.1 SSMP Version
SSMP uses a "<major>.<minor>" numbering scheme to indicate versions
of the protocol. The protocol versions are intended to allow proxies
to indicate the format of a message and its capacity for
understanding further SSMP communication, rather than the features
obtained via that communication. This versioning policy mimics that
of the HTTP/1.0 specification, and more details can be found in [RFC
1945].
The version of an SSMP message is indicated by an SSMP-Version field
in the first line of the message.
SSMP-Version = "SSMP" "/" 1*DIGIT "." 1*DIGIT
This document defines SSMP/1.0. In addition to the message format
defined below, SSMP/1.0 proxies must support the following sub-
protocol message formats:
Proxy-Distribution = "UNICAST/1.0"
Auth-Type = "NONE/0.0"
4. SSMP Messages
4.1 General Packet Format
Proxies handle two types of packets. Data packets are received via
UDP from senders and from other proxies, and are forwarded without
modification. Data packets contain no header; they simply contain
network byte order data.
SSMP-Message packets are received via TCP from other proxies (and
possibly clients) and are defined in sections 4.2 through 4.4. Each
SSMP message begins with the SSMP-Version string followed by a space.
SSMP-Packet = Data-Packet
/ SSMP-Version SP SSMP-Message
Fabbri, Zappala [Page 7]
INTERNET DRAFT SSM Proxy Protocol (SSMP) 30 May 2001
Data-Packet = ; Defined by application
4.2 Message Types
SSMP messages fall into three general categories; requests,
responses, and control channel messages. Requests and responses
generally indicate one-to-one communication, whereas control channel
messages are multicast on the primary proxy's control channel
(S0,Gc).
SSMP-Message = Request
/ Response
/ Control-Channel-Message
4.3 Request
There are two types of request messages, those which originate from a
proxy and those which are from a client.
Request = Proxy-Request
/ Client-Request
There are four types of Proxy-Request messages. The first type,
Proxy-Join-Request, is sent from a secondary to a primary proxy to
join the SSMP group. The Proxy-Join-Detail message specifies inter-
proxy communication and authentication parameters during proxy
joining. A proxy may leave a SSMP session by sending a Proxy-Leave-
Request. Finally, a proxy may send a Proxy-Ping-Request to another
proxy to determine if it is still alive.
Proxy-Request = Proxy-Join-Request
/ Proxy-Join-Detail
/ Proxy-Leave-Request
/ Proxy-Ping-Request
A secondary proxy wishing to join a SSMP session sends a Proxy-Join-
Request message, indicating its direct channel group address G which
the new proxy will use to multicast data to its local receivers. The
secondary proxy's host address S is inferred from the source address
listed in the IP header.
Proxy-Join-Request = "Proxy-Join-Req" CRLF
"G=" SSM-Group-Addr CRLF
During the joining process, a secondary proxy must also provide
parameters needed for the proxy distribution and authentication
algorithms being used via the Proxy-Join-Detail message. The Proxy-
Join-Detail is composed of two sections, a Proxy-Distribution section
Fabbri, Zappala [Page 8]
INTERNET DRAFT SSM Proxy Protocol (SSMP) 30 May 2001
and an optional Proxy-Join-Authen section.
Proxy-Join-Detail = "Proxy-Join-Detail" CRLF
Proxy-Distribution
[Proxy-Join-Authen]
The Proxy-Distribution section contains the Proxy-Dist field which
identifies the particular proxy distribution type being used. Any
additional parameters needed by the distribution type must also be
specified. Specifics are presented in sections 4.7 and 4.8.
Proxy-Distribution = "Proxy-Distribution" CRLF
"Proxy-Dist=" Distribution-ID CRLF
*( Distribution-Parameter "=" Value CRLF)
Distribution-ID = "UNICAST" "/" Version
/ "MULTICAST" "/" Version
Version = 1*DIGIT "." 1*DIGIT
The Proxy-Join-Authen section is reserved for specifying any proxy
authentication information needed during the join process. Proxy
authentication is not required for this specification of SSMP/1.0.
Proxy-Join-Authen = "" ; Not required for SSMP/1.0
When a secondary proxy wishes to leave an SSMP group, it sends a
Proxy-Leave-Request message to the primary proxy and specifies its
direct channel group address.
Proxy-Leave-Request = "Proxy-Leave-Req" CRLF
"G=" SSM-Group-Addr CRLF
The SSMP protocol uses periodic ping messages to verify that proxies
are still active.
Proxy-Ping-Request = "Ping" CRLF
4.4 Response
There are three general types of response messages; those coming from
a proxy and those from a client.
Response = Proxy-Response
/ Client-Response
There are three types of Proxy-Response messages.
Fabbri, Zappala [Page 9]
INTERNET DRAFT SSM Proxy Protocol (SSMP) 30 May 2001
Proxy-Response = Proxy-Join-Reply
/ Proxy-Join-Status
/ Proxy-OK
A primary proxy sends a Proxy-Join-Reply in response to an initial
Proxy-Join-Request. The Proxy-Join-Reply message tells the joining
(secondary) proxy which types of Proxy-Distribution and
Authentication sub-protocols it must support.
Proxy-Join-Reply = "Proxy-Join-Reply" CRLF
[ "Auth-Type=" Auth-Type CRLF
*(Auth-Parameter "=" Auth-Value CRLF) ]
[ "Proxy-Dist=" Proxy-Dist-ID CRLF ]
In SSMP/1.0, the following authentication and distribution sub-
protocols *must* be supported:
Auth-Type = "NONE/0.0"
Proxy-Dist = "UNICAST/1.0"
Proxies *may* also support multicast based proxy distribution:
Proxy-Dist = "MULTICAST/1.0"
The primary proxy replies to a Proxy-Join-Detail message with a
Proxy-Join-Status message. The Proxy-Join-Status message can
optionally contain a Proxy-List-Update message to reduce proxy setup
delay under low-load conditions.
Proxy-Join-Status = "Proxy-Join-Status" CRLF
Status-Code
[Proxy-List-Update]
The Proxy-Join-Status message includes a status code which tells the
secondary proxy what information (if any) is required to complete the
joining process.
Status-Code = Join-Status-ID [SP Join-Status-Text] CRLF
The Join-Status-ID field is a three-digit integer string. The
Status-Code message may optionally include a textual description of
the status code. Suggested Join-Status-Text contents are included as
comments (preceded by ";").
Join-Status-ID = "100" ;Join Complete
/ "200" ;Join Refused
/ "211" ;Auth. type not supported
/ "212" ;Auth. failed, access denied
Fabbri, Zappala [Page 10]
INTERNET DRAFT SSM Proxy Protocol (SSMP) 30 May 2001
/ "221" ;Dist. type not supported
/ "222" ;Invalid topo. parameters
The last type of proxy reply message is the generic Proxy-OK message.
The Proxy-OK message is used as a response to periodic inter-proxy
ping messages, and also as a generic affirmative response code.
Proxy-OK = "OK" CRLF
4.5 Control Channel Messages
Control channel messages are protocol messages which are multicast
from the primary proxy on the control channel (S0,Gc). The primary
use of the control channel is to distribute the current list of
proxies in a scalable manner. The control channel is also used to
notify all proxies at once that the SSMP group/session is ending.
Control-Channel-Mesg = Proxy-List-Update
/ End-SSMP-Group
The Proxy-List-Update message is used to periodically announce the
current list of proxies which belong to a SSMP group. All IP
addresses and port numbers are formatted in human-readable text.
Proxy-List-Update = "Proxy-List-Update" CRLF
1*( IP-Addr "," SSM-Group-Addr ","
UDP-Port "," TCP-Port CRLF)
"End-Proxy-List" CRLF
The primary proxy may end a SSMP group by multicasting an End-SSMP-
Group message to all proxies.
End-SSMP-Group = "End-SSMP-Group" CRLF
4.6 IP Addresses and Port Numbers
IP addresses are sent in human-readable text for clarity. This
document assumes IPv4, and formats addresses in the standard dotted
quad notation. The following definitions do NOT use the ABNF grammar
for clarity.
IP-Addr (informally) = "1.0.0.0" through "255.255.255.255"
SSM group addresses are a special case of IP address in the 232/8
range.
Fabbri, Zappala [Page 11]
INTERNET DRAFT SSM Proxy Protocol (SSMP) 30 May 2001
SSM-Group-Addr (informally) = "232.0.0.0"
through "232.255.255.255"
TCP and UDP port numbers are also sent in readable text. UDP and TCP
port numbers are syntactically equivalent.
TCP-Port = UDP-Port = "1024" through "65535"
4.7 UNICAST/1.0 Messages
When a secondary proxy joins a SSMP session it specifies any
information needed for inter-proxy communication in the Proxy-
Distribution section of the Proxy-Join-Detail message. The only
proxy distribution algorithm which *must* be supported by a SSMP/1.0
proxy is UNICAST/1.0. The UNICAST/1.0 algorithm requires knowledge
of two port numbers for each proxy; the control port and the relay
port. This information must be provided in the Proxy-Join-Detail
request as follows:
Proxy-Join-Detail = "SSMP/1.0" SP "Proxy-Join-Detail" CRLF
"Proxy-Distribution" CRLF
"Proxy-Dist=UNICAST/1.0" CRLF
"Control-Port=" TCP-Port CRLF
"Relay-Port=" UDP-Port CRLF
[Proxy-Join-Authen]
The parameters (Control-Port, etc.) may be listed in any order.
The operation of the UNICAST/1.0 algorithm is presented in section
5.7.
4.8 MULTICAST/1.0 Messages
Another proxy distribution algorithm which *may* be supported by
SSMP/1.0 proxies is MULTICAST/1.0. MULTICAST/1.0 employs an extra
multicast channel from each proxy called the relay channel.
MULTICAST/1.0 requires the same information for each proxy as
UNICAST/1.0 does, with the addition of an additional group address
Relay-Group. In this case, the Proxy-Distribution section of the
Proxy-Join-Detail message has the following format:
Proxy-Distribution = "SSMP/1.0" SP "Proxy-Join-Detail" CRLF
"Proxy-Distribution" CRLF
"Proxy-Dist=MULTICAST/1.0" CRLF
"Control-Port=" TCP-Port CRLF
"Relay-Port=" UDP-Port CRLF
Fabbri, Zappala [Page 12]
INTERNET DRAFT SSM Proxy Protocol (SSMP) 30 May 2001
"Relay-Group=" SSM-Group-Addr CRLF
[Proxy-Join-Authen]
Note that the parameters (Control-Port, etc.) may be listed in any
order.
Since the additional Relay-Group state must be kept for each proxy,
the format of the Proxy-List-Update message must be modified to
contain this data:
Proxy-List-Update = "Proxy-List-Update" CRLF
1*( IP-Addr "," Direct-Group ","
UDP-Port "," TCP-Port CRLF ","
Relay-Group )
"End-Proxy-List" CRLF
The Direct-Group field contains the SSM group address of the proxy's
direct channel, and the Relay-Group contains the group address of the
proxy's relay channel.
Direct-Group = SSM-Group-Addr
Relay-Group = SSM-Group-Addr
To be modular, we should not allow the proxy distribution algorithm
to modify other parts of the protocol. This definition of
MULTICAST/1.0 violates this ideal by requiring a modification to the
Proxy-List-Update message. To increase modularity, we could
introduce another message type which only contains the extra group
addresses required by MULTICAST/1.0. Then, ideally, we could use a
separate channel, say (S0,Gd), to distribute this information, since
it is only useful to proxies and not the larger audience (senders,
receivers) which subscribe to the control channel (S0,Gc). In the
case of MULTICAST/1.0, the change is so small that we choose the
simple approach outlined above. In the future, if more complex proxy
distribution algorithms are introduced, separate messages and/or
control channels should be added if their cost does not outweigh the
improvements in modularity.
The operation of the MULTICAST/1.0 algorithm is presented in section
5.8.
5 Protocol Operation
This section specifies the semantics and ordering of SSMP messages.
5.1 Simplifying Assumptions
Fabbri, Zappala [Page 13]
INTERNET DRAFT SSM Proxy Protocol (SSMP) 30 May 2001
o All SSMP messages (except control channel multicasts) are sent
via TCP. The host which sends the first request in a chain of
messages is responsible for closing the TCP connection as soon
as the operation is completed.
o No host may act as more than one proxy in a single SSMP group.
In other words, any host address S_i occurs at most once in
any proxy list. The protocol syntax is designed to handle
multiple proxies with the same host IP address correctly, but
this assumption simplifies the implementation.
o Proxy lists are ordered in increasing order of join time from
head to tail. The first (head) proxy in a proxy list is the
primary proxy. Proxies are added to the tail of the list
as they join and are deleted in place when they leave.
o We assume the proxy distribution type UNICAST/1.0 is used, and
define changes required for MULTICAST/1.0 in sections 4.8 and
5.8.
5.2 Proxy States
A SSMP proxy can be in one of the following top-level states at any
time:
INACTIVE
SEC_JOINED
PRI_ACTIVE SEC_ACTIVE
PRI_DONE SEC_DONE
PRI_EXIT SEC_EXIT
Initially a proxy is INACTIVE. Other states are preceded with PRI_
or SEC_ to indicate that the proxy is a primary or secondary proxy,
respectively.
5.3 Pseudocode Definitions
The next two sections use pseudocode to describe proxy behavior.
Thorough error checking and special cases are omitted for clarity,
and comments are preceded with a semicolon ';'. Our pseudocode uses
the following global definitions at each proxy:
Variable Description
---------- ----------
STATE Current top-level state
pendingProxyList A list of proxies in the process of joining
proxyList List of all proxies joined to the session
Fabbri, Zappala [Page 14]
INTERNET DRAFT SSM Proxy Protocol (SSMP) 30 May 2001
S The local host IP address
G The SSM multicast address to be used for the
local direct channel
S0 The IP address of the primary proxy
Gc SSM multicast address of the control channel
control_port The TCP port on which the proxy will receive
SSMP messages
relay_port The UDP port on which the proxy will receive
data to be relayed to the SSMP group
error() A function which indicates an error condition
and exits
In our pseudocode we create SSMP messages using the simple syntax:
Message-Name ( *[parameter-name = parameter-value] )
5.4 Joining and Leaving
A secondary proxy must complete the joining process before it
responds to messages on its TCP control port. First, the secondary
proxy uses an out of band session advertisement service to determine
the primary proxy's host address S0 and TCP control port
S0_control_port. The secondary proxy then joins a session managed by
a primary proxy as follows:
------------------------------------------------------------
JOIN_GROUP( S0, S0_control_port ) processing
if STATE == INACTIVE
open TCP connection to S0, S0_control_port
send Proxy-Join-Request(G=G)
receive msg
if msg.ID != Proxy-Join-Reply
error()
if msg.parameter(Proxy-Dist-ID) != UNICAST/1.0
error()
send Proxy-Join-Detail(
Proxy-Dist = UNICAST/1.0
Control-Port = control_port
Relay-Port = relay_port
)
receive msg
if msg.ID != Proxy-Join-Status
error()
if msg.parameter( Join-Status-ID ) == 100 ; Join Complete
STATE = SEC_JOINED
; Begin listening on control_port and control channel
; Begin listening on relay_port
Fabbri, Zappala [Page 15]
INTERNET DRAFT SSM Proxy Protocol (SSMP) 30 May 2001
; Finish any other initialization
STATE = SEC_ACTIVE
------------------------------------------------------------
A secondary proxy may need to exit an active SSMP group. Before
exiting, a proxy must (if possible) notify the primary proxy and any
senders attached to it that it intends to leave. The leaving proxy
should wait [TODO: define] long enough to allow other proxies and
attached senders to adapt to operation without it.
------------------------------------------------------------
LEAVE_GROUP() processing
if STATE == SEC_ACTIVE
open TCP connection to S0, S0_control_port
STATE = SEC_DONE ; no longer a proxy but waiting to leave
send Proxy-Leave-Request(G=G)
receive msg
if msg.ID != Proxy-OK
error()
; Notify senders, currently unspecified [TODO: specify]
sleep until we receive a proxy list update which does not
contain this proxy
STATE = SEC_EXIT
------------------------------------------------------------
When a SSMP session is finished, the primary proxy may end the group
by multicasting End-SSMP-Group messages on the control channel.
Since we assume unreliable multicast service, we send out multiple
copies to reduce the chance of not notifying any proxies.
------------------------------------------------------------
END_GROUP() processing
if STATE == PRI_ACTIVE
STATE = PRI_DONE
send End-SSMP-Group on multicast channel (S0,Gc)
sleep one second
send End-SSMP-Group on multicast channel (S0,Gc)
sleep one second
send End-SSMP-Group on multicast channel (S0,Gc)
sleep one second
STATE == PRI_EXIT
------------------------------------------------------------
5.5 Message Handling
This section describes the behavior of a proxy when it receives a
Fabbri, Zappala [Page 16]
INTERNET DRAFT SSM Proxy Protocol (SSMP) 30 May 2001
message on its (TCP) control port. Whereas the previous section
outlines how proxies join and leave SSMP sessions, this section
describes steady-state behavior.
First we describe how a primary proxy handles incoming control port
messages:
------------------------------------------------------------
PRIMARY_CONTROL_PORT( msg ) processing
if( STATE == PRI_ACTIVE )
switch( msg.ID )
case Proxy-Join-Request:
InetAddress S_i = msg.sourceAddr
InetAddress G_i = msg.parameter( G )
pendingProxyList.add( S_i:G )
reply = Proxy-Join-Reply(
Proxy-Dist = "UNICAST/1.0"
)
send reply
case Proxy-Join-Detail:
if msg.parameter(Proxy-Dist) != UNICAST/1.0
error()
control_port = msg.parameter(Control-Port)
relay_port = msg.parameter(Relay-Port)
S_i = msg.sourceAddr
(S_i:G_i) = pendingProxyList.lookup( S_i )
pendingProxyList.remove( S_i:G_i )
proxyList.add( S_i:G_i:control_port:relay_port)
reply = Proxy-Join-Status(
Join-Status-ID = 100 ; Join Complete
)
send reply
case Proxy-Leave-Request:
proxyList.remove( msg.sourceAddr )
send Proxy-OK
case Proxy-Ping-Request:
send Proxy-OK
------------------------------------------------------------
Next we describe how a secondary proxy handles control port messages.
Once a secondary proxy has joined a SSMP session, it handles incoming
control port messages as follows:
------------------------------------------------------------
Fabbri, Zappala [Page 17]
INTERNET DRAFT SSM Proxy Protocol (SSMP) 30 May 2001
SECONDARY_CONTROL_PORT( msg ) processing
if STATE == SEC_ACTIVE
switch( msg.ID )
case P_PING:
send Proxy-OK
------------------------------------------------------------
5.6 Proxy List Maintenance
The proxy list is maintained by the primary proxy and distributed to
all proxies. This list is soft-state; if a proxy on the list cannot
be contacted within some amount of time [TODO: specify?] it must be
deleted from the list. It is the responsibility of the primary proxy
to maintain timers and attempt to ping proxies which it has not heard
from within a certain amount of time.
The proxy list may need to be distributed to a very large number of
hosts; multicast receivers and senders need the proxy list to
determine the closest proxy to attach to and to be able to switch to
another proxy as desired. Since the proxy list may have a large and
dynamic audience, we use multicast to periodically distribute the
latest copy in a scalable manner. The period between updates may be
increased or decreased; a larger interval uses less bandwidth but
increases join latency since a host or proxy may have to wait longer
to hear the first proxy list announcement.
5.7 UNICAST/1.0 Operation
Recall that SSMP defines a module called "proxy distribution" which
handles distribution of data (not SSMP-Messages) between proxies.
The only proxy distribution SSMP/1.0 proxies *must* support is
UNICAST/1.0.
To source data in an SSMP session, a source sends data to the relay
port of the proxy P_i it has chosen. This proxy becomes the *source
proxy* for that data. In UNICAST/1.0, the source proxy will unicast
(UDP) this data to the relay port of each other proxy in its proxy
list, and then multicast this data on its direct channel (P_i,G_i).
A proxy P_j which receives data from another proxy can be called a
*receive proxy*, and simply multicasts the data on its direct channel
(P_j,G_j). The following pseudocode summarizes this behavior:
------------------------------------------------------------
RECEIVE_RELAY_PORT( packet ) processing
if STATE == PRI_ACTIVE or STATE == SEC_ACTIVE
if proxyList.contains( packet.sourceAddr )
Fabbri, Zappala [Page 18]
INTERNET DRAFT SSM Proxy Protocol (SSMP) 30 May 2001
AND packet.sourceAddr != S ; this proxy may be a source
; we are a receive proxy
multicast packet on (S,G) ; our direct channel
else
; we are the source proxy
foreach proxy in proxyList
if proxy != S ; don't send to yourself
udp-send packet to proxy.S, proxy.relay_port
multicast packet on (S,G)
------------------------------------------------------------
UNICAST/1.0 is desirable because it keeps multicast routing state to
a minimum; each proxy uses one or two multicast channels. The
trade-off is that the unicast replication to each proxy increases the
bandwidth cost.
5.8 MULTICAST/1.0 Operation
To reduce the bandwidth cost associated with UNICAST/1.0, we can
replace unicast proxy distribution with multicast. This requires
each proxy to source an additional channel called a *relay channel*
which is used to multicast data to the other proxies. Each proxy
joins the relay channel for each of the other proxies. When a source
proxy receives data from a sender, it multicasts it on its relay
channel and then multicasts it on its direct channel.
Operation of a proxy with MULTICAST/1.0 is identical to that of a
UNICAST/1.0 proxy except for the following changes:
o MULTICAST/1.0 requires one item of additional state to be kept
for each proxy; the relay channel group address Relay-Group.
o Proxies must also distribute this additional state. Changes to
the message formats required to accomplish this are defined in
section 4.8.
o Assuming, for simplicity, that a proxy receives all incoming
data (unicast from senders AND multicast from a source proxy)
on its relay port, the RECEIVE_RELAY_PORT processing (defined
in 5.7) must be modified as follows:
------------------------------------------------------------
RECEIVE_RELAY_PORT( packet ) processing
if STATE == PRI_ACTIVE or STATE == SEC_ACTIVE
if proxyList.contains( packet.sourceAddr )
and packet.sourceAddr != S
Fabbri, Zappala [Page 19]
INTERNET DRAFT SSM Proxy Protocol (SSMP) 30 May 2001
; we are a receive proxy
multicast packet on (S,G) ; our direct channel
else
; we are the source proxy
multicast packet on (S,Relay-Group) ; this is the change
multicast packet on (S,G)
------------------------------------------------------------
o When a primary proxy allows a secondary proxy to join the SSMP
group, it must subscribe to the relay channel of the new
proxy. If a proxy leaves, it must unsubscribe.
o When a secondary proxy receives a Proxy-List-Update which
differs from its current proxy list, it must subscribe to the
relay channels of any new proxies and unsubscribe from the
relay channels of any proxies which have left.
6 Protocol Examples
Below are some examples of SSMP message exchanges. Entries marked
with a "->" represent a secondary proxy sending to the primary proxy,
and "<-" is a reply.
Example Proxy Join:
-> SSMP/1.0 Proxy-Join-Req ; A new proxy wishes to join.
G=232.11.11.11 ; its direct channel group
<- SSMP/1.0 Proxy-Join-Reply ; Primary proxy responds,
Auth-Type=NONE/0.0 ; optionally w/ authentication
Proxy-Dist=UNICAST/1.0 ; and proxy distribution info.
-> SSMP/1.0 Proxy-Join-Detail
Proxy-Distribution
Proxy-Dist=UNICAST/1.0 ; Default proxy data distribution
Control-Port=4123 ; TCP port
Relay-Port=4122 ; UDP port
<- SSMP/1.0 Proxy-Join-Status
101 Join Complete
; Later the new proxy will receive a Proxy-List-Update message on the
; multicast control channel:
<- SSMP/1.0 Proxy-List-Update
Begin-Proxy-List ; S,G,RelayPort,ControlPort
128.223.6.11,232.22.22.22,4123,4124
Fabbri, Zappala [Page 20]
INTERNET DRAFT SSM Proxy Protocol (SSMP) 30 May 2001
128.23.2.1,232.22.22.44,4123,4124
128.24.3.4,232.22.22.66,4123,4124
128.25.2.11,232.22.22.88,4123,4124
End-Proxy-List
Example Proxy Leave:
-> SSMP/1.0 Proxy-Leave
G=232.11.11.11 ; S is determined via TCP/IP
<- SSMP/1.0 OK
[TODO: add to protocol]
Example Receiver Request:
; SSMP proxies may or may not implement this. We generally use the
; control multicast channel to periodically distribute the proxy list
; in a scalable way, but a proxy may want to support 1-to-1 proxy list
; distribution under low-load conditions to reduce proxy setup delay.
-> SSMP/1.0 Proxy-List-Request
<- SSMP/1.0 Proxy-List-Update
Begin-Proxy-List ; S,G,RelayPort,ControlPort
128.223.6.11,232.22.22.22,4123,4124
128.23.2.1,232.22.22.44,4123,4124
128.24.3.4,232.22.22.66,4123,4124
End-Proxy-List
7 Security Considerations
Denial of Service
A proxy join request creates state and eventually results in
additional consumption of bandwidth. In UNICAST/1.0, the amount of
bandwidth used for proxy distribution grows with the number of
proxies joined to the session. With MULTICAST/1.0, each proxy join
also creates (S,G) state at routers as proxies join the direct
channel of each new proxy. For these reasons, host(s) can attempt
a denial of service attack by completing a large number of proxy
join requests. Although the requirement that each proxy's host
must have a unique IP address may help, a primary proxy *may*
implement controls to limit damage from such an attack:
o Limit the total number of proxies which may join a SSMP
Fabbri, Zappala [Page 21]
INTERNET DRAFT SSM Proxy Protocol (SSMP) 30 May 2001
group.
o Limit the rate at which new proxies are allowed to join
the SSMP group.
Address Spoofing
This specification assumes that incoming packets contain the correct
source address in their IP header. A host may interrupt operation of
a SSMP group by sending a message with a falsified source address.
Source Control
SSMP/1.0 implements the Any-Source Multicast (ASM) model, allowing
any host to send to a group. Since many applications need to control
who may send to a group, future versions of SSMP will include source
authentication which will be enforced by the proxies.
Proxy Authentication
SSMP is designed to accommodate proxy authentication, which will be
specified in a future version.
8 Terminology
ASM - Any-Source Multicast service model. Another name for ISM (see
ISM below) which was recently adopted by the IETF to avoid the
connotation that "Internet Standard" multicast was the only
standardized model.
channel - A source-specific multicast group (see SSM).
cost - aggregate bandwidth usage
delay - the length of the path between senders and receivers, usually
expressed in number of hops or milliseconds
direct channel - Each proxy sources a direct channel which local
receivers subscribe to to receive data.
group - the members (senders and receivers) of an Any-Source
Multicast (see ASM) session
ISM - Internet Standard Multicast service model [6]. In the ISM
model, a multicast group is identified by a single group IP address,
G. In an ISM group, senders need not be members and can send
Fabbri, Zappala [Page 22]
INTERNET DRAFT SSM Proxy Protocol (SSMP) 30 May 2001
multicast packets addressed to G at any time. An ISM group can
contain multiple senders.
PIM - Protocol Independent Multicast [1] is a very popular protocol
which implements Any-Source Multicast (see ASM) at the network layer.
PIM-SM - Protocol Independent Multicast--Sparse Mode is a specific
implementation of PIM (see PIM) which efficiently supports sparse
multicast groups.
primary proxy - The primary proxy of an SSMP group can be thought of
as the coordinator of the group. The primary proxy is the source of
the control multicast channel and serves as an application-layer
rendezvous point (RP) for the group. Each SSMP group has exactly one
primary proxy.
proxy - a generalization of the session relay concept[7]
receive proxy - A receive proxy is a proxy which receives data from
another proxy.
relay channel - In multicast proxy distribution (MULTICAST/1.0), each
proxy sources a relay channel which other proxies in that group join
to receive data from a source proxy.
RTT - round trip time
secondary proxy - A secondary proxy is any SSMP proxy which is not a
primary proxy. Each SSMP group has zero or more secondary proxies.
session relay - Session relay, described in [7], is one way of
supporting a multicast group with multiple senders using SSM.
source proxy - A source proxy is the proxy which a sender relays its
data to. A source proxy is responsible for distributing this data to
each of the other proxies in the SSMP group.
SSM - Source-Specific Multicast service model. In the SSM service
model, each sender creates its own group which is identified by two
IP address, (S,G), where S is the unicast address of the source, and
G is an IP address in the 232/8 (232.0.0.0 to 232.255.255.255) range.
SSMP - SSM Proxy protocol is the protocol defined in this document.
SSMP extends SSM (see SSM) with an application-layer protocol which
allows it to efficiently support ASM (see ASM).
SSMP session - An SSM Proxy protocol session is essentially an ASM-
style (see ASM) multicast group implemented by the SSMP and SSM
Fabbri, Zappala [Page 23]
INTERNET DRAFT SSM Proxy Protocol (SSMP) 30 May 2001
protocols.
9 Future Enhancements
o Source and/or proxy authentication.
o Investigate using an application-layer multicast protocol
such as Narada for proxy distribution?
o The distributed nature of the protocol (e.g. multiple
proxies and channels) should lend its self well to
implementing reliability...
10 References
[1] S. E. Deering, D. Estrin, D. Farinacci, V. Jacobson, C. Liu, and
L. Wei. The PIM Architecture for Wide-Area Multicast
Routing. IEEE/ACM Transactions on Networking, 4(2):153--162,
Apr. 1996.
[2] David Meyer and Bill Fenner, "Multicast Source Discovery Protocol
(MSDP)", Work in progress, draft-ietf-msdp-spec-09.txt, May 2001.
[3] Bates, R. Chandra, D. Katz, and Y. Rekhter, "Multiprotocol
extensions for BGP-4," RFC 2283, Internet Engineering Task Force,
Feb. 1998.
[4] Yang-Hua Chu, Sanjay Rao, and Hui Zhang. "A case for end system
multicast." In Proceedings of ACM Sigmetrics, Santa Clara, CA,
2000.
[5] Satish Kumar, Pavlin Radoslavov, David Thaler, Cengiz
Alaettinoglu, Deborah Estrin, and Mark Handley, "The MASC/BGMP
architecture for inter-domain multicast routing," in Proceedings
of
SIGCOMM '98, Vancouver, Canada, Sept. 1998.
[6] D. Cheriton and Steve Deering. Multicast Routing in Datagram
Internetworks and Extended LANs. ACM Transactions on Computer
Systems, pages 85-111, May 1990.
[7] Hugh W. Holbrook and David R. Cheriton, "IP Multicast Channels:
EXPRESS Support for Large-scale Single-source Applications, " in
Proceedings of the ACM SIGCOMM'99, Cambridge, Massachusetts, USA,
1999.
Fabbri, Zappala [Page 24]
INTERNET DRAFT SSM Proxy Protocol (SSMP) 30 May 2001
[8] Daniel Zappala and Aaron Fabbri, "An Evaluation of Shared
Multicast Trees with Multiple Active Cores," in International
Conference on Networking, ICN'01, July 2001.
[9] Daniel Zappala and Aaron Fabbri, "Using SSM Proxies to Provide
Efficient Multiple-Source Multicast Delivery". Submitted, 2001.
Fabbri, Zappala [Page 25]