Subject: SSM Proxy protocol (SSMP) draft

From: Aaron J Fabbri <[email-masked]>
Date: Fri, 8 Jun 2001 16:43:51 -0700 (PDT)

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    [email-masked]
   -------------------==============================------------------

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]