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]