INTERNET DRAFT                                              P. Liefooghe
Expires May 2002                              Vrije Universiteit Brussel
                                                           November 2001


         CastGate: an auto-tunneling architecture for IP Multicast
                     <draft-liefooghe-castgate-01.txt>


Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC 2026 [1].

   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.

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in
   this document are to be interpreted as described in RFC 2119 [2].

Abstract

   The architecture described in this document aims at giving as many
   unicast-only end-users access to IP multicast content, this without
   the need for their ISPs to upgrade their network infrastructure to
   IP multicast. It further does not require any change to the unicast
   only infrastructure nor to the end-user operating systems. The
   access that is provided, is from a user's perspective as good as a
   real IP multicast connection. It can be used to send and receive ASM
   as well as SSM content. It further allows applying Authentication,
   Authorization and Accounting (AAA) to IP Multicast.








Expires May 2002                                              [Page 1]


Draft                          CastGate                  November 2001

Table of Contents

1 Introduction                                                       2
2 Definitions                                                        3
3 Application Level Tunneling                                        5
4 Dynamic Tunnel Server location.                                    6
4.1 Coarse Grain Tunnel Server Location                              6
4.1.1 The Hierarchical Tunnel Database                               6
4.1.2 Tunnel Database Server Registration                            7
4.1.3 Tunnel Server registration                                    10
4.1.4 Tunnel Database update                                        11
4.1.5 Tunnel Server location                                        11
4.2 Fine Grain Tunnel Server Selection                              12
4.2.1 Path Characterization.                                        12
4.2.2 Tunnel Hand-over                                              13
5 Enhanced UMTP                                                     14
5.1 Compact DATA trailers                                           14
5.2 Explicit Join Acknowledgement                                   14
5.3 Option Negotiation                                              14
6 Tunnel Database Server Interactions.                              16
6.1 The REGISTER Action.                                            17
6.2 BYE Action.                                                     17
6.3 QUERY Action.                                                   18
6.4 TRANSFER Action                                                 18
6.5 Return Value format                                             18
7 Firewalls and NATs.                                               20
7.1 Tunnel Server location.                                         20
7.2 Native Tunneling                                                21
7.3 UMTP over HTTP                                                  21
8 Deployment scenarios.                                             22
8.1 Public                                                          22
8.2 Private                                                         23
9 Security Considerations                                           24
10 Authors' Address                                                 24
11 References                                                       25

1 Introduction

   The deployment of IP multicast is not going as fast as the multicast
   community would want. The major reason for this is that we are in
   some sort of two-fold deadlock situation with problems situated at
   three parties:
   The first party involved is the ISPs. As described by Diot C. et al.
   [3], ISPs are reluctant to deploy IP multicast because it relies on
   a protocol architecture that requires more setup and administration
   than the unicast architecture. This makes that in order for a
   multicast solution to be cost efficient one will need potentially a
   large number of multicast capable customers.

   The second party is the customers. Only a minority of users knows
   about multicast and the potential benefits this technology could
   bring them. They are only interested in the quality of the received
   content. Since it is for consumers not all that clear what multicast

Expires January 2002                                          [Page 2]


Draft                          CastGate                  November 2001

   is about and what they can do with it, they won't be asking their
   ISPs to get multicast.

   The content providers are the last group involved. Although the use
   of multicast could result in a huge bandwidth saving, content
   providers are not eager to invest in this new technology, because
   there are almost no consumers for this type of content.

   From the above it is clear that in order for IP multicast to become
   ubiquitous we need to try to provide as many end-users with a
   multicast "connection".

   The work described in this document aims at breaking this deadlock
   situation. A mechanism, which allows an Internet user with enough
   access bandwidth to access multicast content even when not connected
   to a multicast enabled ISP is described. In this manner we increase
   the multicast-audience and hence make it more attractive for content
   providers to deploy this bandwidth-saving technology. At the same
   time, when we reach the critical mass of multicast capable end-
   users, ISPs will be more willing to deploy multicast.

   The basic idea behind the solution described in this document is
   that it is possible to encapsulate (tunnel) the multicast packets in
   unicast UDP packets between the portion where we do have IP
   multicast (Tunnel Server) and the end-user.

   If we want to promote the use of IP multicast via a tunneling
   mechanism then one major requirement is that the location of an
   appropriate tunnel server and the tunneling itself is fully
   transparent for the user and the applications. This dictates a
   mechanism that automatically locates the best tunnel end-point.

   The CastGate architecture follows the principal Internet design
   "philosophy", namely that one should move complexity to the edges of
   the network and keep the middle of the network simple. It is capable
   of giving every unicast end-user access to IP multicast, this
   without any modification neither to the user's operating system nor
   to the unicast or multicast infrastructure.











2 Definitions

                               RTDS
                                            +=====>C

Expires January 2002                                          [Page 3]


Draft                          CastGate                  November 2001

                               ...........  "                    |
                            ....         ..."                    +C
                  ATDS'   ..                "...                 |
                     ....  TS'    MCast     TS<=.============>CCS+
               C'<=======.======>TS'           .                 |
                        .. TS'               ...                 +C
                         ....            TS<=========>RTS<=>C
                             ..          ...
                               ..........

        C: Client  TS: Tunnel Server  RTDS: Root Tunnel Database Server
        CCS: CastGate Client Service  RTS: Relay Tunnel Server
        ATDS': Authorative TDS for TS's and C's

                        Figure 1: Architectural overview

   Tunnel Server (TS): End-point of one or more UMTP tunnels. Typically
   this is located in the multicast enabled part of the Internet but it
   could also be placed in a non-multicast part of a network and use on
   its turn an UMTP tunnel towards a Tunnels server who is located in
   the Multicast enabled part of the network.

   Relay Tunnel Server (RTS): Is a Tunnel Server, which uses an UMTP
   tunnel to receive IP multicast. It can be used to place the fan-out
   point closer to the end-users without the need to deploy native IP
   multicast up to the fan-out point. E.g. could be placed at or
   integrated with a Broadband Access Server.

   Tunnel Database Server (TDS): A host which stores information about
   the available Tunnel Servers and for what (sub)networks, Country or
   Region they are willing to act as tunnel end-point.

   Root Tunnel Database Server (RTDS): A Tunnel Database server located
   anywhere on the Internet, but with a DNS name known to all members
   in the CastGate architecture.

   Authorative Tunnel Database server (ATDS): A Tunnel Database server
   located within an Autonomous System who is authorative for the
   Tunnel Servers located within the AS.

   CastGate Client Service CCS): A Service installed on the client's
   LAN segment capable of intercepting IGMP Vx [4,5,6] join messages
   and acting as an IGMP Vx querier. It will join the sessions for
   which it sees joins and all received data is tunneled towards the
   "best" Tunnel Server. Data received on the tunnel is multicasted
   locally.

   CastGate Enabled Application: Any kind of multicast application
   (receive only or send and receive) where the CastGate technology was
   integrated. The application is capable of detecting the availability
   of native multicast; if it is not available it switches to a
   tunneled mode of operation.


Expires January 2002                                          [Page 4]


Draft                          CastGate                  November 2001

3 Application Level Tunneling

   In the CastGate architecture we use an application level tunneling
   mechanism where tunneled data (i.e. IP multicast payload) is sent
   over a UDP unicast "connection" between the two tunnel endpoints.
   The client uses a control mechanism to indicate to the tunnel end-
   point which multicast address and port number to join. All data
   received on this multicast channel is then encapsulated in UDP
   datagram packets and sent to the client. Clients will decapsulate
   and multicast the received packets locally. The same mechanism is
   used in the other direction, which makes bi-directional
   communication possible.

   The client applications, however, must satisfy the following
   conditions:

   * Their multicast packets must use UDP.
   * The tunnel endpoint must have a way of knowing each (group, port)
   that the application uses.
   * The application must not rely upon the source address of its
   incoming multicast packets. In particular, the application must not
   use source addresses to identify the original data source(s).

   Most multicast based applications; especially those based on RTP [7]
   satisfy these requirements.

   This application level tunneling has the big advantage that no
   special privileges are needed to run the end-user application and
   that there is no need for kernel-level access as compared to kernel-
   level tunneling solutions like implementing a full-blown routing
   protocol like DVMRP [8].

   The CastGate architecture uses the UDP multicast tunneling protocol
   (UMTP)[9]. The UMTP protocol consists of a tunnel "Slave" and tunnel
   "Master". The Tunnel Slave resides on the multicast enabled part of
   the Internet and will be referenced in this document as the Tunnel
   Server (TS) and will - on command of one or more Master agents - be
   joining potentially multiple multicast channels. The packets
   received on the multicast channels will be unicast UDP-encapsulated
   and send towards the appropriate Masters.

   The Tunnel Master is an agent running on the end-user's machine and
   will request the Tunnel Server to join, and tunnel one or more
   multicast channels. The encapsulated data is re-multicasted locally.

   The Master agent can be integrated in a multicast enabled
   application or can be part of a separate launching application (e.g.
   Session Directory).

   With UMTP, once a Master-Slave relationship has been established it
   is possible to exchange IP multicast bi-directionally.
   UMTP also supports the tunneling of SSM multicast sessions [10] by
   providing the IP source address of the content originator, as well

Expires January 2002                                          [Page 5]


Draft                          CastGate                  November 2001

   as the multicast group IP address and the port number to join in the
   join message to the Tunnel Server.

   The reader is pointed to [8], for full details about the UMTP
   protocol. In section 6, we discuss some enhancements to the UMTP
   Protocol.

4 Dynamic Tunnel Server location.

   If we want to have a user-friendly solution, we cannot expect the
   user to know which Tunnel Server to use. Further, if we would
   statically configure a list of servers it would not be feasible for
   an average end-user to decide which Tunnel Server would be best.

   Hence we use a dynamic and fully transparent mechanism to locate the
   "best" Tunnel Server for a given client.

   To help in locating a set of the most suitable Tunnel Servers for a
   given end-user, we use a hierarchical system of Tunnel Database
   Servers. Tunnel Servers are registered with one or more of these
   Tunnel Database Servers.

   The basic idea behind our approach is that we first obtain a list of
   Tunnel Servers coarsely appropriate for the client (Coarse Grain
   Tunnel Server Location) and then use a "measurement" to determine
   the "best" Tunnel Server (Fine Grain Tunnel Server Location).

   The coarsely appropriate Tunnel Servers could be those assigned to
   the clientÆs subnet or network if these do exists (e.g. those
   located at the ISP). Alternatively this could be Tunnel Servers in
   the clientÆs country or Region. Finally, if there are no Tunnel
   Servers available at the region level then a set of default Tunnel
   Servers is used.

   The second phase is used to actively measure the path and server
   characteristics to make a more "calculated" decision about which
   Tunnel Server is likely to give the best tunnel performance.

4.1 Coarse Grain Tunnel Server Location

4.1.1 The Hierarchical Tunnel Database

   The Hierarchical Tunnel Database is a major component of the
   CastGate architecture and is used to obtain a list of Tunnel Servers
   (TS) roughly appropriate for the Client. It is composed of several
   Tunnel Database Servers (TDS) arranged in a hierarchical manner, and
   contains - in a distributed way - information about the "Tunnel
   Regions" to which each Tunnel Server is assigned.

   A Tunnel Region defines for which part of the Internet the Tunnel
   Server is willing to act. We have three regions: local, country and
   geographic region. With local we indicate Tunnel Servers located in
   the corporate/ISP network; with country we indicate all Tunnel

Expires January 2002                                          [Page 6]


Draft                          CastGate                  November 2001

   Servers located in a given country and with geographic region we
   indicate the Tunnel Servers located in the neighboring countries,
   e.g. the tunnel servers in Europe for a client located in the UK.
   Since it is possible that a network spans multiple countries it is
   allowed to assign a Tunnel Server to a combination of Tunnel Regions
   for example to indicate that the Tunnel Server is only allowed to
   act for those clients of the network located in a specific country.

   The Tunnel Database hierarchy is inspired on the DNS system and is
   composed of at least two Root Tunnel Database Servers located in
   physically dispersed places. It has potentially multiple levels of
   sub Tunnel Database Servers. These Tunnel Database Servers are
   either authorative for a country, an Autonomous System or one or
   more networks. At the leafs of the hierarchy we find the Tunnel
   Servers themselves.

   We do not limit the number of levels in the hierarchy, because it
   allows flexible deployment scenarios e.g. four levels of Tunnel
   Database Servers could prove useful in a situation where a country-
   level ISP deployed its own Tunnel Database Server but has a
   corporate client who wants to be in control of which of his subnets
   gets to use what (local) Tunnel Server(s).

   Each Tunnel Database Server in the hierarchy can have one or more
   Peer Tunnel Database Servers. These Peer Tunnel Database Servers are
   synchronized copies of each other and are used for redundancy
   purposes and for load balancing.

   The Tunnel Database Hierarchy is maintained manually. An
   administrator of a Tunnel Database Server or Tunnel Server needs to
   obtain a login and password from the parent Tunnel Database Server
   administrator before the Tunnel Database Server or Tunnel Server can
   be hooked into the hierarchy.

   The login and password are needed to prevent unauthorized Tunnel
   Database Servers or Tunnel Servers from hijacking either whole
   Tunnel Database sub-levels or networks with CastGate clients.

   Once a login and password is obtained for the parent Tunnel Database
   Server(s), it is possible to use a dynamic mechanism to add Tunnel
   Database Servers or Tunnel Servers below these parents. This dynamic
   mechanism allows flexible addition, migration and removal of Tunnel
   Servers and Tunnel Database Servers.

   The parent Tunnel Database Servers are automatically discovered via
   a query in the distributed database and the child Tunnel Database
   Server or Tunnel Server is automatically registered with all the
   parents.

4.1.2 Tunnel Database Server Registration

   The configuration parameters of a Tunnel Database Server consist of:
   a list of network(s) or sub network(s) for which the Tunnel Database

Expires January 2002                                          [Page 7]


Draft                          CastGate                  November 2001

   Server should become authoritative and a country code. The country
   is typically specified in case of a country-level Tunnel Database
   Server, but it can also be combined with a networks list to indicate
   that the Tunnel Database Server is authoritative for all Tunnel
   Servers assigned to the indicated networks and located in the
   indicated country.

   e.g. pan-European network 134.34.0.0/16
   Configuration of Tunnel Database Server for Tunnel Servers located
   in Spain:

   country=ES
   networks=134.34.0.0/16

   Configuration of Tunnel Database Server for Tunnel Servers located
   in Finland:

   country=FI
   networks=134.34.0.0/16

   The automatic discovery of the parent Tunnel Database Servers
   consists of querying the Hierarchical Tunnel Database for each
   configured network range combined with the optional country. The
   query starts at one of the root Tunnel Database servers and consists
   of performing a longest prefix match between the network range
   provided in the query and the network ranges of the registered
   Tunnel Database Servers in the Hierarchical Tunnel Database. If no
   results are found, a match using the country code is tried.
   The result of the query will yield potentially one or more Tunnel
   Database Servers authoritative for the network or country. The
   returned results contain the IP address, port and prefix length for
   each of the matching Tunnel Database Servers. The prefix length is
   the prefix length of the network range that matched in the case of a
   longest prefix match or zero in the case of a country match.

   The action is repeated against one of the returned Tunnel Database
   Servers (randomly selected), until no longer any match is found.

   It is possible that the last queried Tunnel Database Server
   corresponds to a peer Tunnel Database Server. In such a case we will
   need to perform a ôRegion Transferö with one of the peers prior to
   registration. This region transfer is used to make sure that Tunnel
   Database Server has an up-to-date database before being hooked into
   the hierarchy.
   The steps to decide if the last queried Tunnel Database Server
   corresponds to a peer are indicated in the pseudo code located on
   the next page.







Expires January 2002                                          [Page 8]


Draft                          CastGate                  November 2001

   if prefix length of last queried TDSs <> 0 {
   // Match at network level
   if the last TDSs queried had the same prefix length as the network
   being registered
   {
   if the before last queried TDSs had the same prefix length as the
   network being registered
   {
   // Special case where ISP and customer are registering the same
   network range.
   // We support this because a company would otherwise need to
   indicate all its subnets individually.
   if the IP address of the registering TDS is within the address range
   that is being registered
   {
   // registering corporate TDS
   Perform a Region Transfer with the last queried TDS (= peer TDS) and
   register with the parents of the TDSs that were queried last
   (=before last queried).
   }
   else {
   // registering ISP TDS
   Perform a Region Transfer with the before last queried TDSs and
   register with the TDSs used in the query two steps before the last
   query.
   }
   }
   else {
   // we found (regular) peer TDSs
   Perform a Region Transfer with the last queried TDS (= peer TDS) and
   register with the before last queried TDSs.
   }
   }
   else {
          // no peer TDSs
   Register with the last queried TDSs.
   }
   }
   else { // Country level match only
   if registering country level TDS {
   Perform Region Transfer with the last queried TDS and register with
   the before last queried TDSs (=root TDS).
   }
   else {
   // Found the country but there are no (network level) peers.
   Register with the last queried TDSs.
   }
   }






Expires January 2002                                          [Page 9]


Draft                          CastGate                  November 2001

4.1.3 Tunnel Server registration

   The Tunnel Server registration also uses a similar automatic
   mechanism to figure out the appropriate Tunnel Database Server to
   register with. This will allow easy addition of Tunnel Servers as
   the use of IP multicast content increases.

   The configuration information of a Tunnel Server is comparable to
   that of a Tunnel Database Server. It consists of the registration
   login and password, the (sub)network(s) for which it is allowed to
   act and optionally the country to which the Tunnel Server is
   assigned. The geographic region to which a Tunnel Server belongs is
   inferred from the provided country code. This information is here
   also used to automatically locate the Tunnel Database Servers to
   register with. Alternatively it is also possible to just indicate in
   the configuration the list of Tunnel Database Servers to register
   with, but this is of course less flexible.

   If the Tunnel Database Server where the Tunnel Server is registered
   has some local Tunnel Server Assignment Policy (TSAP), then the TSAP
   takes precedence over the registered information. The Tunnel Server
   Assignment Policy consist of simple rules which tells a Tunnel
   Database Server to "reroute" clients from certain network range
   and/or country to other Tunnel Servers. The use of TSAP proves
   useful to allow some form of Tunnel Traffic Engineering, where
   clients located in some subnets are administratively assigned to
   other Tunnel Server(s) than the ones they normally use.

   A Tunnel Server with a configuration containing a networks=
   0.0.0.0/0 entry, is denoted a "Public" Tunnel Server, because it can
   be used by clients independent of their network. These Tunnel
   Servers register with the root Tunnel Database Servers or if they
   contain a country line, with the Country Tunnel Database Servers. In
   the latter, they are public for clients located in the country and
   its neighboring countries. When the Public Tunnel Servers are
   registered with the root Tunnel Database Servers, they function as
   "Tunnel Servers of last resort".
   If we want to boot-strap the use of CastGate and actively promote
   the use of IP multicast then we will need to deploy multiple of
   these Public Tunnel Servers to accommodate those end-users whose ISP
   did not yet deploy the CastGate technology.

   Once a Tunnel Server is started, it uses each configured
   (sub)network address range optionally combined with the country code
   to iteratively query the Hierarchical Tunnel Database in order to
   locate the Tunnel Database Servers authoritative for the Tunnel
   ServerÆs configured (sub)network and/or country. The iterative query
   performed on the Tunnel Database consists of performing a longest
   prefix match between the provided network address range and the
   network ranges of the authoritative Tunnel Database Servers. If no
   results are found, a match using the country code is tried. One of
   the returned Tunnel Database Servers is on its turn queried with the
   same parameters.

Expires January 2002                                         [Page 10]


Draft                          CastGate                  November 2001

   The query is repeated till no results are returned. The list of
   Tunnel Database Servers to which the last queried Tunnel Database
   Server belonged, is the list with which the Tunnel Server needs to
   register.

4.1.4 Tunnel Database update

   At regular intervals after the initial registration an update of the
   information in the Tunnel Database(s) is performed and consists of
   re-registering. An entry in the Tunnel Database is removed if it is
   not updated within two times the update interval. At Tunnel Server
   or Tunnel Database Server shutdown, a de-registration is performed.
   Details about the registration messages and the timing can be found
   in section 5.4.

   As with DNS, to optimize the interaction it is possible to cache the
   results of the queries in order to prevent the need to iterate
   through the whole hierarchy. It should be noted that the parents of
   the Tunnel Database Servers with which a registration was performed
   should be cached, this to guarantee the registration/update with
   newly added parent Tunnel Database Servers.


4.1.5 Tunnel Server location

   The client part of the architecture can range from a Session
   Directory tool with integrated CastGate functionality to a simple
   JAVA CastGate client Applet running in a web browser. The initial
   step performed by a client will be the retrieval of the list of
   Tunnel Servers coarsely appropriate for the clientÆs location.

   The clientÆs location can be the geographical location (i.e. country
   or region) or the position in the network topology (i.e.
   subnetwork/IP address). The clientÆs geographical location is either
   configured at installation or inferred from the DNS name. The latter
   method simply consists of looking at the country code extension of
   the DNS name and is especially useful when the client component is
   downloaded and executed in a web browser (JAVA Applet CastGate
   Client). If the country cannot be inferred from the DNS name, then
   it should be asked for to the user.

   A Client typically has only knowledge of the root Tunnel Database
   Servers and will use one of them as a start for an iterative query
   of the Hierarchical Tunnel Database in order to obtain a list of
   Tunnel Servers appropriate for his location. To optimize this
   process it is always possible for the client to cache the location
   of the Tunnel Database Servers authoritative for his location.

   When no prior results have been cached, a client will perform the
   following actions:

   The client will at random choose one of the root Tunnel Database
   Servers and send a Tunnel Server Query message towards it. A Tunnel

Expires January 2002                                         [Page 11]


Draft                          CastGate                  November 2001

   Server Query message contains as parameter the country code of the
   client. At the Tunnel Database Server, first a match is tried
   between the client's IP address and the registered (sub)networks of
   the Tunnel Servers or Tunnel Database Servers, using longest prefix
   matching. If no match is found, a match at country level is
   attempted; if no match is found a match at the geographic region is
   tried. A number of Tunnel Server entries in the Tunnel Database are
   registered as "Public" and are returned if no match is found at the
   geographic region.

   The query either yields a list of Tunnel Servers or a list of Tunnel
   Database Servers. In the latter case, one of the Tunnel Database
   Servers is randomly selected and queried with the same Tunnel Server
   Query message. This iterative querying continues till a list of
   Tunnel Servers is returned or no matches are found.

   The list of most recently queried Tunnel Database Servers can be
   cached on disk by the client application as to speed up the process
   when running the application at a later time.

4.2 Fine Grain Tunnel Server Selection

   As the result of querying the Hierarchical Tunnel Database we obtain
   a list of Tunnel Servers coarsely appropriate for the client. These
   Tunnel Servers can be located anywhere in the geographic region
   (e.g. Europe), the country or network. It is clear that especially
   for Tunnel Servers located in the geographic region or country there
   is potentially a significant difference in term of ôtunnel
   performanceö they offer between the different Tunnel Servers. The
   ôtunnel performanceö will depend on the characteristics of the path
   (throughput, delay, jitter and loss) and on the load on the Tunnel
   Server. But, even for Tunnel Servers located in the clientÆs network
   there can possibly be a difference, mainly attributable to the load
   on the Tunnel Server and to a lesser extent to the path
   characteristics.

   In order to make an informed decision when selecting the final
   Tunnel Server, we need to actively measure the characteristics of
   the paths to each Tunnel Server and measure the load on each Tunnel
   Server. Armed with measurements of the current network state we can
   perform application-level congestion avoidance. By application-level
   congestion avoidance we mean that applications can use estimates of
   traffic volume to actively avoid paths that are currently heavily
   loaded. It should be noted that our measurements will only help us
   avoid the network congestion that exists at the time, and for long-
   lived tunnel sessions it is possible that during the course of the
   tunneling congestion occurs along the path.

4.2.1 Path Characterization.

   The Tunnel Server/Path characterization consists of setting up
   "test" CastGate tunnels towards all the Tunnel Servers that were
   returned from the query in the Tunnel Database.

Expires January 2002                                         [Page 12]


Draft                          CastGate                  November 2001

   Through such a "test" tunnel a special "test channel" is joined
   (address and port TBD). The Tunnel Server will act differently for
   this address/port combination as compared to "normal" channels in
   the sense that all traffic sent towards this special channel is
   looped back towards the client. We send on this channel 5
   consecutive data packets of 512 bytes and calculate the average RTT.
   The average RTT is then used to decide which Tunnel Server to use.
   We use 512 bytes measurement packets because this is the average
   packet size one sees in regular IP Multicast sessions.

   It should be noted that initially one of the coarsely appropriate
   Tunnel Servers is used as "temporary" Tunnel Server. On a tunnel
   towards such a temporary Tunnel Server it is already possible to
   join some channels (like the Global Session Announcement channel)
   during the measurement time. The temporary Tunnel Server could be
   for example the Tunnel Server that was used in a previous run.

   The test-packets of 512 bytes are sent, one after the other. The
   sending rate should not exceed the administratively set access
   bandwidth or in the case of asymmetric technologies the smallest
   value of the administratively set access bandwidth tuple divided by
   the number of Tunnel Servers to probe. The limiting of the sending
   rate is induced by the fact that one never should send faster than
   the administratively imposed bandwidth otherwise one is measuring
   the parameters of access technology/parameters rather than the
   Tunnel Server characteristics.
   The probing of all the Tunnel Servers can be performed in parallel
   because the probing is lightweight and the aggregate sending rate
   does not exceeds the access bandwidth. All replies should be
   received within a time-out-period set to [TBD] seconds. Tunnel
   Servers with a total measurement time larger than [TBD] seconds are
   not taken in to account when making a decision, as they will give
   too limited performance.

   The client calculates the mean RTT for each Tunnel Server and
   selects the Tunnel Server with the smallest mean RTT as ôbestö.

   After the measurement we close the tunnels towards the Tunnel
   Servers except the temporary Tunnel Server and the "best" tunnel
   server to perform tunnel hand-over.

4.2.2 Tunnel Hand-over

   If the "best" server is different from the temporary tunnel server a
   tunnel hand-over procedure is started.

   Once the client has chosen the appropriate server, a UMTP tunnel is
   set up with this server. From the moment we start to receive data on
   a joined channel we stop the tunneling of that channel on the
   temporary UMTP Tunnel. We continue to do this until we no longer
   have any "temporary" sessions open. Finally we close the UMTP Tunnel
   with the temporary server.


Expires January 2002                                         [Page 13]


Draft                          CastGate                  November 2001

   From this point on we tunnel from the new tunnel server.

5 Enhanced UMTP

   NOTE: The following should in the end be merged in a new version of
   the UMTP draft and has been kept intentionally terse.

5.1 Compact DATA trailers

   The UMTP protocol as defined in [9], has quite large trailers (12 or
   16 octets) which could lead to unnecessary fragmentation, this is
   why we enhanced the UMTP protocol by defining a "compact" DATA
   command FLOW_DATA, where each channel (i.e. group and port) is
   identified by a unique 2 octet identifier.

   4-octet trailer:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              FlowID           |      TTL      |S|vers.|command|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   The FlowID value is obtained from the peer via an option negotiation
   addition to UMTP.

5.2 Explicit Join Acknowledgement

   We introduce explicit join acknowledgement to allow enhanced
   functionalities like FlowID exchange and channel level
   authorization. The packet layout is the same as in the UMTP
   specification where JOIN_ACK is assigned the value 10 and JOIN_NACK
   the value 11. If after a timeout JOIN_TIMEOUT [TBD] no ACK or NACK
   is received a retransmission is performed, this is repeated
   JOIN_REPEAT [TBD] times.

   A client waits for these messages if the PROBE_ACK contained a valid
   OPT_MAGIC value.

5.3 Option Negotiation

   We introduced Option Negotiation to the UMTP protocol, in order to
   make it more flexible.

   The octets before the PROBE, PROBE_ACK, PROBE_NACK, JOIN, JOIN_ACK
   and JOIN_NACK trailers are used to exchange option information. The
   options consist of a list of option packets one after the other and
   terminated by the OPT_END option.


   Option header


Expires January 2002                                         [Page 14]


Draft                          CastGate                  November 2001

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |             code              |              len              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   .                          0 or more octets                     .
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The following code values have been defined.
                         Code  len  Meaning
   OPT_END                0     0   End of option list
   OPT_MAGIC              1     2   2 octet Magic number (0x1169)
   OPT_FLOWID             2     0   Supports FLOW_DATA data types
   OPT_FLOWID_0           3     2   2 octet Flow ID for Channel/RTP
                                    stream
   OPT_FLOWID_1           4     2   2 octet Flow ID for RTCP stream
   OPT_FRIENDLY           5     1   The peer supports adaptive
                                    Tunneling (aka TCP-Friendly).(1)
                                    1 octet bit mask indicating the
                                    supported TCP Friendly protocols.
   OPT_AUTH               6     0   Authentication is required for this
                                    resource
   OPT_PAP                7     0   supports PAP Authentication
   OPT_CHAP               8     0   supports CHAP Authentication
   OPT_LOGIN              9     n   PAP or CHAP Login name
   OPT_PAP_PASSW         10     n   PAP Password
   OPT_CHAP_PASSW        11     n   CHAP calculated HASH
   OPT_CHAP_CHALL        12    16   16 octet challenge
   OPT_CHAP_ID           13     n   CHAP ID
   OPT_OVERLOADED        14     0   Server is overloaded and did not
                                    process the request
   OPT_SHUTTINGDOWN      15     0   Server is shutting down, client
                                    should switch to other server
   OPT_BANNED            16     0   User/IP address is banned from
                                    this server
   OPT_OVERLIMIT         17     0   Client is over his downstream limit
   OPT_NOTSUBSCRIBED     18     0   Joining a channel the user has no
                                    subscription for
   OPT_RECEIVEONLY       19     0   The client is granted receive-only
                                    access

   1: In the JOIN we indicate which protocols the client supports, in
   the ACK the server indicates which will be used. Empty mask
   indicates that the server does not support network friendly
   tunneling.









Expires January 2002                                         [Page 15]


Draft                          CastGate                  November 2001

   Usage Matrix:

                     PROBE  ACK  NACK    JOIN_ JOIN_GROUP ACK  NACK
   OPT_END            x      x     x       x        x      x     x
   OPT_MAGIC          x      x
   OPT_FLOWID         x      x
   OPT_FLOWID_0                                            x
   OPT_FLOWID_1                                            x
   OPT_FRIENDLY                            x        x      x
   OPT_AUTH                                x        x
   OPT_PAP                                 x        x
   OPT_CHAP                                x        x
   OPT_LOGIN          x
   OPT_PAP_PASSW      x
   OPT_CHAP_PASSW     x
   OPT_CHAP_CHALL     x            x
   OPT_CHAP_ID        x            x
   OPT_OVERLOADED                  x                             x
   OPT_SHUTTINGDOWN                x                             x
   OPT_BANNED                      x                             x
   OPT_NOTSUBSCRIBED               x                             x
   OPT_RECEIVEONLY           x                             x

6 Tunnel Database Server Interactions.

   All the following communications, involving the Tunnel Database,

   * Registration of Tunnel Server with Tunnel Database Server
   * Query of Tunnel Database by the client
   * Transfer between peer Tunnel Database Servers

   are based on HTTP (GET) interactions.

   The use of HTTP allows us to use available web servers and database
   back-ends to act as authorative Tunnel Database Servers, and allows
   the Tunnel Servers and Clients to use a well documented and
   understood protocol.

   All GET interactions have the following format:

   GET /script/castgate.cgs?ACTION=Name& ....

   This is, depending on the value of the ACTION parameter followed by
   one or more additional Name-Value pairs.

   In the case that the list of parameters is exceeding the maximal
   allowed length of a HTTP GET interaction, we need to use a HTTP POST
   interaction, which carries the same information as the GET
   interaction.

   All registration and removal actions need to contain a login and
   password. This to prevent that entries are removed by unauthorized

Expires January 2002                                         [Page 16]


Draft                          CastGate                  November 2001

   persons. In some situations one will need to obtain a valid login
   and password prior to registration. (See section 8)

6.1 The REGISTER Action.

   The REGISTER Action is used when performing a registration of a
   Tunnel Server. The parameter list for this action is composed of the
   following Name-Value pairs:

   SOURCE: The local IP address of the Tunnel Server. It will be this
   IP address that will be returned by the Authorative Tunnel Database
   server when queried for an appropriate Tunnel Server. E.g.
   SOURCE="134.184.50.57"

   PORT: The UDP Port on which the Tunnel Service is waiting for UMTP
   joins.

   NETWORKS: is a comma-separated list of networks, in prefix notation
   for which a Tunnel Server is willing to act. E.g.
   NETWORKS="134.184.1.0/24,134.184.2.0/24"

   These network address ranges are the ranges used by the Firewalls or
   NATs on their external interface (i.e. public address range) if the
   Tunnel Server is located in a network shielded by one or more
   Firewalls or is using NATs.

   COUNTRY: the ISO 3166 alpha-2 country code of the Country for which
   it is willing to act as Tunnel Server. E.g. COUNTRY="BE".

   From the moment a Tunnel Server uses a Country name-value pair it
   indicates that it wants to cooperate in the global effort to provide
   access to IP multicast content. The real scope of this cooperation
   depends on the location in the Tunnel Database hierarchy where this
   Tunnel Server is being registered. I.e. if it registers with the
   root Tunnel Servers then it is truly a 'public' Tunnel Server for
   whole the country and also for the region. In case the registration
   is done with a Tunnel Database Server authorative for a certain
   network then it is a public Tunnel Server, but only for clients in
   the indicated country (and region) and located within the network(s)
   for which the Tunnel Database Server has authority.

6.2 BYE Action.

   A Tunnel Server uses this command when it is being put "off-line".

   This action contains the following parameters:

   SOURCE: The local IP address of the Tunnel Server.
   PORT: The UDP Port of the service that is shutting down.




Expires January 2002                                         [Page 17]


Draft                          CastGate                  November 2001

6.3 QUERY Action.

   This is used - prior to registration - by a Tunnel Server to
   retrieve the list of Tunnel Database Servers authorative for this
   Tunnel Server.

   The Tunnel Client uses this message to retrieve the list of
   potential Tunnel Servers.

   To make a distinction between the different types of query we use
   the TYPE keyword. TYPE=TDS is used to query for the list of
   authorative Tunnel Database Servers, and TYPE=TS is used to query
   for Tunnel Servers.

   The message contains the following MANDATORY field:

   COUNTRY: ISO 3166 alpha-2 country code of the country where the end-
   user is located.

   The longest prefix match is performed with the source IP address of
   the message and will potentially yield one or more results.

6.4 TRANSFER Action

   Similar to DNS we define a transfer mechanism to synchronize a
   freshly started Tunnel Database Server with his peer TDSs.

   This action is secured by installing a common login and password in
   all peer TDS.

   No additional parameters are defined.

6.5 Return Value format

   The REGISTRATION and the BYE actions don't return any data; hence
   standard HTTP return codes are sufficient.

   For the Query and Transfer actions on the other hand we will need to
   return a list of Tunnel Database Servers or Tunnel Servers.

   The headers are standard HTTP headers where the Content-Type
   corresponds to the txt/xml mime-type.

   The proposed format for the data part is based on XML and has the
   following DTD:

   <!ELEMENT SERVERS (SERVER)*>
   <!ELEMENT SERVER (ADDRESS, PORT, TYPE, PREFIXLEN?)>
   <!ELEMENT ADDRESS (#PCDATA)>
   <!ELEMENT PORT (#PCDATA)>
   <!ELEMENT TYPE (#PCDATA)>
   <!ELEMENT PREFIXLEN (#PCDATA)>


Expires January 2002                                         [Page 18]


Draft                          CastGate                  November 2001

   Here ADDRESS corresponds with the (local) IP address in dotted
   decimal notation that was used in the registration of the Tunnel
   Server or Tunnel Database Server. PORT, corresponds to the TCP port
   used by the Tunnel Database server or the UDP port used by the
   Tunnel Server.
   The TYPE field indicates whether the returned IP Address and port
   belong to a Tunnel Server or to a Tunnel Database Server. If the
   type value corresponds to '1' then this is a Tunnel Database Server
   otherwise when the value corresponds to '0' then this is a Tunnel
   Server. The PREFIXLEN field is only present in replies to TYPE=TDS
   type of queries and is used to determine if the returned TDS entries
   are peers or parents.

   e.g.
   In case of TYPE=TDS query yielding two Tunnel Database Server
   entries

   <?xml version="1.0"?>
   <SERVERS>
   <SERVER>
   <ADDRESS>134.184.50.57</ADDRESS>
   <PORT>5632</PORT>
   <TYPE>1</TYPE>
   <PREFIXLEN>16</PREFIXLEN>
   </SERVER>
   <SERVER>
   <ADDRESS>134.184.1.23</ADDRESS>
   <PORT>3456</PORT>
   <TYPE>1</TYPE>
   <PREFIXLEN>16</PREFIXLEN>
   </SERVER>
   </SERVERS>

   In case we return three Tunnel Servers.

   <?xml version="1.0"?>
   <SERVERS>
   <SERVER>
   <ADDRESS>134.184.40.80</ADDRESS>
   <PORT>1243</PORT>
   <TYPE>0</TYPE>
   </SERVER>
   <SERVER>
   <ADDRESS>134.184.1.24</ADDRESS>
   <PORT>2323</PORT>
   <TYPE>0</TYPE>
   </SERVER>
   <SERVER>
   <ADDRESS>134.184.5.34</ADDRESS>
   <PORT>1243</PORT>
   <TYPE>0</TYPE>
   </SERVER>
   </SERVERS>

Expires January 2002                                         [Page 19]


Draft                          CastGate                  November 2001


   For the Zone transfer a more elaborate format is used:

   <!ELEMENT SERVERS (SERVER)*>
   <!ELEMENT SERVER (ADDRESS, PORT, TYPE, LOGIN, PASSWORD, COUNTRIES?,
   NETWORKS?)>
   <!ELEMENT ADDRESS (#PCDATA)>
   <!ELEMENT PORT (#PCDATA)>
   <!ELEMENT TYPE (#PCDATA)>
   <!ELEMENT LOGIN (#PCDATA)>
   <!ELEMENT PASSWORD (#CDATA)>
   <!ELEMENT COUNTRIES (COUNTRY)*>
   <!ELEMENT COUNTRY (#PCDATA)>
   <!ELEMENT NETWORKS (NETWORK)*>
   <!ELEMENT NETWORK (#PCDATA)>

   <?xml version="1.0"?>
   <SERVERS>
   <SERVER>
   <ADDRESS>134.184.1.95</ADDRESS>
   <PORT>6777</PORT>
   <TYPE>1</TYPE>
   <LOGIN>as2026u1</LOGIN>
   <PASSWORD>u12!56D</PASSWORD>
   <COUNTRIES>
   <COUNTRY>BE</COUNTRY>
   </COUNTRIES>
   <NETWORKS>
   <NETWORK>134.184.1.0/24</NETWORK>
   <NETWORK>134.184.5.0/24</NETWORK>
   <NETWORK>134.184.50.0/24</NETWORK>
   </NETWORKS>
   </SERVER>
   </SERVERS>


7 Firewalls and NATs.

7.1 Tunnel Server location.

   The Tunnel Database and Tunnel Server location are based on the HTTP
   protocol (see Section 6), and are hence possible through firewalls
   and NATs. Despite the fact that the messages do contain IP addresses
   and network ranges, there is no need to modify the NATs because the
   addresses will only be used in a local context.

   One should note that we need to use public address ranges (used by
   external interface of the Firewall/NAT) in the registration of
   Tunnel Database servers and Tunnel Servers if they are behind a
   firewall. This, because in the longest prefix match we use the
   source IP address of the request, which is in such a case one of the
   addresses in the "public" range.


Expires January 2002                                         [Page 20]


Draft                          CastGate                  November 2001

7.2 Native Tunneling

   Since all our communication is based on the UMTP protocol and in
   view of the fact that it is using the UDP protocol it is not
   affected by NATs.

   On the other hand due to the restrictions imposed by firewalls it is
   typically impossible to set up multiple UMTP tunnels towards
   different Tunnel Servers. This because the most common type of
   Firewalls, proxy firewalls use a fixed mapping between the tuple
   (firewall IP address, port) and a tuple (UMTP Server IP address,
   port).

   By use of a UMTP Proxy module in the firewall or as process running
   on a machine in the "Demilitarized Zone", one could "restore" the
   dynamic capabilities, which are needed to locate the "best" Tunnel
   Server.

   For this we need to add proxy functionality to the UMTP protocol and
   this can be achieved by defining a new command called PROXY [Value
   TBD], which still uses the same trailer layout as all the other UMTP
   packets. But in case of a PROXY command we change the interpretation
   of the field "(IPv4) multicast address", which will now contain the
   (unicast) IP address of the Tunnel Server and the "Port" field will
   contain the port of the tunnel server to contact. All other fields
   are not used.

   This PROXY message will be sent as the first message in the UMTP
   communication between the client and the firewall/proxy. From the
   moment the UMTP Proxy received this message it knows that it needs
   to forward all messages to the tunnel server defined in the PROXY
   command. This forwarding continues until the UMTP Proxy receives the
   TEAR_DOWN message.

7.3 UMTP over HTTP

   Many corporate environments will only install such UMTP Proxy
   functionality after enough internal clients requested it. In order
   to support also these end-users an alternative tunneling mechanism
   is proposed.

   One obvious solution is to use the HTTP protocol to achieve firewall
   traversal, because this is probably the only protocol for which we
   can be sure that it will be granted traversal. The trade-off for
   this approach is that carrying IP Multicast content (typically audio
   and video) in a TCP connection could result in a sub-optimal user-
   experience. But, the need for access to multimedia content though
   firewalls has already triggered media streaming server vendors in
   implementing (pseudo) streaming through HTTP in one way or another
   and has shown the viability of such an approach.

   The basic idea is that initially a CastGate Client will try to
   communicate with a CastGate Tunnel Server via UMTP; if this fails,

Expires January 2002                                         [Page 21]


Draft                          CastGate                  November 2001

   HTTP will be used. In order not to modify the architecture too much
   we will be carrying unmodified UMTP packets inside HTTP.


   One would be inclined to use one HTTP connection to carry the data
   for multiple groups, but this is not appropriate because TCPÆs rate
   halving in case of packet loss would affect all sessions rather than
   only one single session. Hence, one HTTP connection will be used for
   each individual session (RTP/RTCP traffic will be carried in the
   same HTTP connection).

   We use HTTP POST interactions because this defines a way to carry
   arbitrary blocks of data from the client to the server and reverse.

   In order to detect the packet boundaries in the TCP byte stream we
   use an explicit 2-octet packet length field (in network order) at
   the beginning of each packet.

   In the HTTP Header we use the following fields in order to
   communicate information to HTTP proxies so that they handle the
   streams better.

   Date Header - the reply should include a "Date" header with a value
   at an arbitrary point in the past. This keeps proxies from caching
   the transaction.
   Expires Header û Same as the Date header.
   Pragma: No cache - Tells many HTTP 1.0 proxies not to cache.
   Cache-Control: no-cache û Tells HTTP 1.1 proxies not to cache.

   A special content type has been defined:  application/x-umtp-
   tunneled

   PROBE, PROBE_ACK and PROBE NACK are not used because user
   authentication can be replaced by HTTP level authentication and
   capability negotiation is not needed because the use of HTTP
   tunneling presumes support for FlowID based data transport and
   precludes the use of TCP Compatible/Friendly UMTP data transport.
   The source and destination cookies values in the UMTP messages will
   be ignored because the TCP sequence numbers provide an even higher
   level of protection against spoofing.


8 Deployment scenarios.

8.1 Public

   The initial goal of this architecture is to promote the use of IP
   Multicast by a large number of end-users. Before ISPs start to
   deploy the CastGate technology, we have the option of deploying
   "public" Tunnel Servers. These "pubic" Tunnel Servers are preferably
   located at the "edge" of the IP multicast cloud. These "public"
   Tunnel Servers will register with the Root Tunnel Database Servers

Expires January 2002                                         [Page 22]


Draft                          CastGate                  November 2001

   or with the Tunnel Database Servers authorative for the country in
   which the Tunnel Server is located.

   The nice thing about this architecture is that we don't need from
   "day one" a lot of Tunnel Servers; it can grow gradually as more
   end-users start to use the CastGate technology.

8.2 Private

   Some ISPs will want to be in control of the usage of the CastGate
   technology; hence they will deploy their own Tunnel Database
   Server(s). This will allow them to decide which end-user uses which
   cluster of Tunnel Server. The Tunnel Servers (and Tunnel Database
   Servers) could be fitted with support for RADIUS, which would allow
   for enforcing a user policy from a central location. Such policy
   could consist of authenticating a user using the CHAP mechanism of
   Enhanced UMTP. Each authenticated user is granted access to all
   "public" channels, but depending on the type of subscription (user
   profile) the user is granted access to other "commercial" channels
   (e.g. pay-per-view). It is even feasible to relay for some channels
   the RADIUS authentication to the content providersÆ own RADIUS
   server(s).

   Within the ISP/Corporate context multiple possible deployment
   scenarios exist, here are only a few of them:

   1) Basic Approach

   An ISP could deploy a relay Tunnel Server. This Relay Tunnel Server
   uses the dynamic Tunnel Server location mechanism to find an
   appropriate Tunnel Server who is located in the IP Multicast cloud.
   It then registers itself with the Country Tunnel Database Server(s)
   or with the Root Tunnel Database Servers. By using this method it is
   possible to "aggregate" already some traffic, which is a first
   optimization as compared to the situation where each end-user of the
   ISP is using a separate tunnel.

   As more and more people start the use this Relay Tunnel Server it
   will get overloaded. In such an event, the ISP has two options:

   Add one or more Relay Tunnel Servers.

   This is of course a sub-optimal solution because this will mean an
   extra Tunnel to the IP Multicast enabled part of the Internet.

   or use the method described in the next point.

   2) Medium Approach

   In this scenario, the ISP enables IP Multicast up to the first
   router "inside" his network. This could consist of deploying native
   IP multicast or be made up of a PIM-SM tunnel or DVMRP tunnel.


Expires January 2002                                         [Page 23]


Draft                          CastGate                  November 2001

   On one of the LAN segments of that "enabled" router it is possible
   to deploy multiple Tunnel Servers.

   To further optimize, and to keep traffic out of the core of his
   network he has the option of deploying one or more relay Tunnel
   Servers closer to the end-users. (i.e. POP, BAS Server etc.)

   3) Maximum Approach

   Besides deploying multiple Tunnel Servers at multicast enabled
   portions of his network, an ISP has also the option of deploying one
   or more of his own Tunnel Database Servers. This will allow the ISP
   to be in control of who gets to use what Tunnel Server.

   Also in this scenario, it is possible to place the "fan-out" closer
   to the end-users.

9 Security Considerations

   In the system it is possible for a rogue Tunnel Server to register
   itself as being willing to server for a certain network, with the
   purpose of redirecting Tunnel Users towards him.

   To prevent this, we should always perform consistency checking at
   the Tunnel Database Servers:

   The list of networks provided in the NETWORKS parameter should all
   be a subset of the network to which the address in the parameter
   SOURCE belongs.

   Also for registrations at the country level there does exist the
   same threat.

   There for it is RECOMENDED to only allow registration of Tunnel
   Servers for a given country if the Tunnel Server provides (via HTTP
   authentication mechanism) a valid login and password for that
   country. The person willing to deploy Tunnel Servers for a given
   country should send an Email with contact information towards the
   administrator of the Tunnel Database System. The Tunnel Database
   Administrator can then decide to give a login and password or to
   decline this request.

10 Authors' Address

        Pieter Liefooghe
        Vrije Universiteit Brussel INFO/TW
        Tele.Com Group
        Pleinlaan 2
        1050 Brussel
        Belgium
        Phone: +32 2 6292977
        EMail: pieter@info.vub.ac.be


Expires January 2002                                         [Page 24]


Draft                          CastGate                  November 2001



11 References

[1]  Bradner, S.
     "The Internet Standards Process -- Revision 3."
     RFC 2026, October 1996.
[2]  Bradner, S.
     "Key words for use in RFCs to Indicate Requirement Levels"
     RFC 2119, March 1997.
[3]  Diot, C. et al.
     "Deployment Issues for the IP Multicast Service and Architecture"
     IEEE Network, January 2000.
[4]  Deering, S.E.
     "Host extensions for IP multicasting."
     RFC 1112, August 1989.
[5]  Fenner, W.
     "Internet Group Management Protocol, Version 2."
     RFC 2236, November 1997.
[6]  Cain, B., et al.
     "Internet Group Management Protocol, Version 3."
     Work-in-Progress, Internet-Draft "draft-ietf-idmr-igmp-v3-06.txt"
     January 2001
[7]  Schulzrinne, H. et al.
     "RTP: A Transport Protocol for Real-Time Applications."
     RFC 1889, January 1996.
[8]  Waitzman, D. et al.
     "Distance Vector Multicast Routing Protocol"
     RFC 1075, November 1988.
[9]  Finlayson, R.
     "The UDP Multicast Tunneling Protocol"
     Work-in-Progress, Internet-Draft "draft-finlayson-umtp-05.txt"
     February, 2001.
[10] Holbrook, H., Cain, B.
     "Source-Specific Multicast for IP"
     Work-in-Progress, Internet-Draft "draft-holbrook-ssm-arch-01.txt"
     November, 2000.






Expires January 2002                                         [Page 25]