INTERNET DRAFT P. Liefooghe Expires January 2002 Vrije Universiteit Brussel July 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 January 2002 [Page 1] Draft CastGate July 2001 Table of Contents 1 Introduction........................................................2 2 Definitions.........................................................3 3 Application Level Tunneling.........................................4 4 Dynamic Tunnel Server location......................................6 4.1 Hierarchical Tunnel Database....................................6 4.2 Tunnel Server registration......................................7 4.3 Tunnel Server location..........................................8 4.3.1 Path Characterization.......................................9 4.3.2 Tunnel Hand-over............................................9 5 Firewalls and NATs.................................................10 5.1 Tunnel Server location.........................................10 5.2 Tunneling......................................................10 6 Enhanced UMTP......................................................11 6.1 Compact DATA trailers..........................................11 6.2 Explicit Join Acknowledgement..................................11 6.3 Option Negotiation.............................................11 7 Tunnel Database Server Interactions................................13 7.1 The REGISTER Action............................................14 7.2 BYE Action.....................................................14 7.3 QUERY Action...................................................15 7.4 TRANSFER Action................................................15 7.5 Return Value format............................................15 8 Deployment scenarios...............................................17 8.1 Public.........................................................17 8.2 Private........................................................18 9 Security Considerations............................................19 10 Authors' Address..................................................19 11 References........................................................19 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 July 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 ........... " | .... ..." +C ATDS' .. "... | .... TS' MCast TS<=.============>CCS+ C'<=======.======>TS' . | .. TS' ... +C .... TS<=========>RTS<=>C .. ... .......... Expires January 2002 [Page 3] Draft CastGate July 2001 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. 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 Expires January 2002 [Page 4] Draft CastGate July 2001 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 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. Expires January 2002 [Page 5] Draft CastGate July 2001 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. 4.1 Hierarchical Tunnel Database. The hierarchical system of Tunnel Database Servers forms a distributed Tunnel Database, which contains information about the 'Tunnel Regions' to which each registered Tunnel Server belongs. As Tunnel Regions we defined local, country and regional. With local we indicate Tunnel Servers located in the corporate/ISP network; with country we indicate all Tunnel Servers located in a given country and with regional we indicate the Tunnel Servers located in the neighboring countries. E.g. all tunnel servers in Europe for a client located in the UK. The idea is that a client will try to look first for tunnel servers in its own network and expand to the country if none are found. If there are no Tunnel Servers in the country, then Tunnel Servers in the region will be used. The Tunnel Database hierarchy is inspired on the DNS system and is composed of two Root Tunnel Database Server located in physically disperse places and potentially multiple levels of Sub Tunnel Database Servers typically authorative for Tunnel Servers located in separate Autonomous Systems. These Sub Tunnel Database Servers could then be used to implement local Tunnel Server Access policies or do some form of 'Tunnel Traffic Engineering'. E.g. three levels of Tunnel Database servers could prove useful in a situation where an ISP deployed its own Tunnel Database Server but has a corporate client who wants to be in control of his own tunneling policy. The Tunnel Database Hierarchy is build up statically and could use a registration procedure similar to the DNS system. In the registration procedure, the manager of the Sub Tunnel Database Server will need to indicate for which network(s) or sub network(s) and/or Country it is willing to act as authorative Tunnel Database Server. Expires January 2002 [Page 6] Draft CastGate July 2001 4.2 Tunnel Server registration Since Tunnel Servers will be added as the use of IP multicast content increases we need a mechanism where the newly added Tunnel Servers are registered automatically with the appropriate (authorative) Tunnel Database Server. At the installation/configuration of the Tunnel Server we provide the (sub)network(s) to which a Tunnel Server belongs. Optionally the country to which the Tunnel Server belongs is provided. The latter will be especially useful when this Tunnel Server will act as 'public' Tunnel Server. With 'public' Tunnel Server we understand a Tunnel Server, which can be used by clients located in the indicated country or region. If we really want to 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 this information to query one of the two root Tunnel Database Servers in order to locate one or more authorative (sub-level) Tunnel Database Servers. The query performed on the Tunnel Database consists of performing a longest prefix match between the list of provided networks and the network ranges of the authorative Tunnel Database Servers. If no results are found, a match using the country code is tried. This query will yield, potentially one or more entries of Tunnel Database Servers authorative for the domain/country the Tunnel Server is located in. The same query is performed against each of these Tunnel Database servers, which in turn can return a new list of (sub level) authorative Tunnel Database Servers. The above-mentioned action is repeated till no results are returned. The list of Tunnel Database Servers to which this query was sent, is the list with which we need to register. Details about the registration message itself can be found in section 6.1. At regular intervals [TBD] an update of the information in the Tunnel Database(s) is performed. And consists of re-sending the registration message. An entry in the Tunnel Database is removed if it isn't updated within two times the update interval. At Tunnel Server shutdown, a de-registration is performed. (See Section 6.2) Expires January 2002 [Page 7] Draft CastGate July 2001 4.3 Tunnel Server location The client application (Session Directory, CastGate enabled application or CastGate Client Service) is configured with the country where the end-user is located. A Client has no prior knowledge about, the location of the authorative Tunnel Database servers or Tunnel Servers, unless manually configured or "remembered" from a previous discovery. Hence the Tunnel Server location procedure consists of retrieving the list of authorative Tunnel Database servers and then querying one in order to retrieve the list of Tunnel Servers appropriate for this client. The discovery of the list of authorative Tunnel Database Servers and the set of Tunnel Servers for a given client consists of querying the distributed Tunnel Database with the combination of the IP address of the client and the Country ID. The actions performed are as indicated: The client will at random choose one of the root Tunnel Database Servers and send a Tunnel Database Server discovery query towards it (see Section 6.3.). At the Tunnel Database servers in general, we first try a match 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 the level of the country is attempted; if no match is found a query at the level of the region is performed. A number of Tunnel Server entries in the Tunnel Database are marked as "default" and are returned if no match is found in the 'Region' of the country where the end-user is located. If the source of the query (details in case of firewalls or NAT: See Section 5) lies within the sub network or network address range of one or more Tunnel Database Servers, then the list of Sub Tunnel Database servers is returned. In such an event the client randomly selects one of the Tunnel Database Servers and sends the same query towards this Tunnel Database Server. Using the described mechanism, we will finally end up at a Tunnel Database Server who is authorative for the client's subnet. This authorative Tunnel Database server will then return the addresses (and port numbers) of one or more Tunnel Servers appropriate for the client. All the results, (especially the list of returned Authorative Tunnel Database Servers) can be remembered by the client application as to speed up the process when running the application at a later time. Expires January 2002 [Page 8] Draft CastGate July 2001 When we have located multiple potential Tunnel Servers we randomly pick one if the list of Tunnel Servers all belong to the same (sub)network or one can choose to use a "measurement" to determine which tunnel server is best suited for handling the client. If the query only resulted in one Tunnel Server, we simply set up a UMTP tunnel with this particular server. In the case of a measurement action, the following sequence of operation is carried out: First a temporary UMTP tunnel is set up with the Tunnel Server that was used in a previous run, if this server is member of the list of potential Tunnel Servers or with a randomly chosen Tunnel Server if the previously used Tunnel Server is not present in the list. Through this temporary tunnel it is already possible to join some multicast sessions. (E.g. get a list of available sessions via SAP/SDP) While the tunneling of these sessions is happening, we start at the client a path characterization process to measure which server is best suited for acting as final Tunnel Server. 4.3.1 Path Characterization. The path characterization consists of setting up - one after the other - "dummy" UMTP tunnels towards all the Tunnel Servers that were returned from the query in the Tunnel Database. Through such a "dummy" UMTP tunnel a special "test channel" (Address and Port, TBD) is joined. The Tunnel Server will act differently for this test channel compared to "normal" channels in the sense that all traffic sent towards this special channel is looped back towards the client. The layout of the test packets and the exact measurement method will strongly depend on the type of application that will be used. Hence, we leave the details up to the multicast application programmer who is adding tunneling support to his application. But as a rule of thumb, we need the path characterization to use a test stream equivalent to the session that will be joined by the application. The client will know through this mechanism, which Tunnel Server is best suited. 4.3.2 Tunnel Hand-over If the "best" server is different from the temporary tunnel server a tunnel hand-over procedure is started. Expires January 2002 [Page 9] Draft CastGate July 2001 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. From this point on we tunnel from the new tunnel server. 5 Firewalls and NATs. 5.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. 5.2 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. Expires January 2002 [Page 10] Draft CastGate July 2001 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. 6 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. 6.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. 6.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. 6.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 Expires January 2002 [Page 11] Draft CastGate July 2001 options consist of a list of option packets one after the other and terminated by the OPT_END option. Option header 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 12] Draft CastGate July 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 7 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 13] Draft CastGate July 2001 persons. In some situations one will need to obtain a valid login and password prior to registration. (See section 8) 7.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. 7.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 14] Draft CastGate July 2001 7.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. 7.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. 7.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 15] Draft CastGate July 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 16] Draft CastGate July 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 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 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. Expires January 2002 [Page 17] Draft CastGate July 2001 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. 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.) Expires January 2002 [Page 18] Draft CastGate July 2001 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 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" Expires January 2002 [Page 19] Draft CastGate July 2001 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 20]