INTERNET DRAFT P. Liefooghe Expires May 2002 Vrije Universiteit Brussel November 2001 CastGate: an auto-tunneling architecture for IP Multicast 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: 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
134.184.50.57
5632 1 16
134.184.1.23
3456 1 16 In case we return three Tunnel Servers.
134.184.40.80
1243 0
134.184.1.24
2323 0
134.184.5.34
1243 0 Expires January 2002 [Page 19] Draft CastGate November 2001 For the Zone transfer a more elaborate format is used:
134.184.1.95
6777 1 as2026u1 u12!56D BE 134.184.1.0/24 134.184.5.0/24 134.184.50.0/24 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]