Internet Engineering Task Force Russell J Clark INTERNET-DRAFT Mostafa H Ammar Kenneth L Calvert Georgia Institute of Technology May, 1994 Using DNS to Support Multiprotocol Interoperability 1 Status of this Memo This document is an Internet-Draft. 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.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet- Drafts Shadow Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). 2 Abstract Multiprotocol systems are a vital tool for achieving interoperability in today's heterogeneous communication networks. An important aspect of these systems is the need to determine which of the multiple available protocols will be used to carry out a given communication task; an uninformed choice can result in failure to communicate when communication should be possible. In this document we consider ways to make information about hosts' supported protocol configurations available through the Domain Name System. We discuss various representation approaches, and describe their use with multiprotocol applications. We present the use of our approach with an example multiprotocol system incorporating IPng protocols. 3 Introduction The past decade has seen the development and deployment of many different protocol architectures, including TCP/IP, SNA, DECNET, and IPX. Radical growth in the number of interconnected systems has accompanied this proliferation of protocol suites. As a result of INTERNET-DRAFT DNS to Support Multiprotocol Interoperability May, 1994 these two facts, there is an ever-increasing need to interconnect systems that do not currently use the same communication protocols. In a previous paper [3] we discussed support for multiple protocol suites as a method of achieving interoperability in current and future networks. Such an approach is based upon the observation that universal support for any single architecture or even protocol is unlikely. The basic idea is to embrace heterogeneity by developing frameworks for dealing with it. This document presents one element of such a framework, namely a method enabling hosts to obtain information about the protocols supported by other hosts. This document considers the use of directory services to provide information about the various protocols that hosts support. Such information is useful in a multiprotocol context because there may be more than one protocol configuration supporting a given communication service, and choosing the wrong configuration can lead to a failure to communicate. Using directory services to provide this information at runtime is a natural extension of the primary use of these services today, i.e. mapping names to address information. We describe a generic approach, along with a working implementation based on a widely-used directory service, the Internet Domain Name System [8, 9]. While our approach supports a wide variety of multiprotocol architectures, we include examples that demonstrate its use with IPv4 and IPng protocols. The document proceeds as follows. In the next section, we describe our notion of a multiprotocol system. In Section 5, we consider possible methods of encoding the required information in a directory database. General features of a directory service supporting this function are discussed in Section 6. In Section 7 we consider ways to implement these features using the existing Internet Domain Name System. Finally, Section 8 contains some concluding remarks. 4 A Multiprotocol System We consider the environment necessary to support multiprotocol systems. Each such system provides services to users via an abstraction that hides details of the protocols from the user and serves as an endpoint for one communication instance, such as a connection. For lack of a better name, we shall refer to this abstraction as a session. The session contains information that determines which protocols process outgoing messages sent by a user, and that enables incoming messages from the network to be routed to the user. In addition, it may contain (pointers to) local state information required by the protocols. A protocol entity (PE) is an abstract representation of a part of the communication subsystem that implements a particular protocol. A convenient description of a protocol entity is: ``a component that adds a header to outgoing messages, and thus affects interoperability Clark, Ammar, and Calvert [Page 2] INTERNET-DRAFT DNS to Support Multiprotocol Interoperability May, 1994 with other systems''. Each session has associated with it a sequence of protocol entities, namely the protocol ``stack'' implementing the communication (Note that in practice, the session does not have associated with it complete, separate protocol implementations, but rather capabilities to access the implementations, which are shared across sessions. The distinction is immaterial here.) The sequence of PEs associated with a session is here called a protocol path, or simply a path. The general scenario by which a user obtains network services through a session object involves the following steps: 1. Service Determination. Determine the type of service needed by the user. Note that ``service'' here may include such aspects as the format of the address by which the destination host is identified. 2. Protocol Path Determination. Determine the combination of protocols required to provide the needed service. 3. Protocol Path Configuration. Create a session object with the required protocol path, and pass it to the user. 4. Communication. The user performs the appropriate operations (open connections, send, receive, etc.) via the session. Note that service determination may be performed by the user, or by some combination of user and communication subsystem. For example, the user may know the name of a desired destination, but not its address (or even its address format). To obtain the required information, either the user or the communication subsystem may make use of a directory service, which maps names to network addresses. Such a directory service may be a simple file local to the host, or a separate remote service, accessed via the network itself. The protocol determination step is typically performed by the communication subsystem; however, it could be handled by the user if the subsystem allows the user to request a session object with any arbitrary protocol path. A well-known example of an environment following this model is the Berkeley UNIX socket interface. The socket abstraction provides users with uniform access to network protocol (and other IPC) services, while the socket data structure itself contains most of the information that determines the protocol path used for communications via the socket. When requesting allocation of a socket, the user must specify both a socket type (e.g. stream, sequence of packets) and an address family (e.g. Internet, OSI, etc.). The former generally determines the transport-level protocol used (e.g. TCP for streams, ISO TP4 for sequence of packets); while the latter determines the network-level protocol used (e.g. IP). Clark, Ammar, and Calvert [Page 3] INTERNET-DRAFT DNS to Support Multiprotocol Interoperability May, 1994 4.1 Protocol Path Determination Approaches We have identified two possible approaches to the problem of Protocol Path Determination in a multiprotocol environment. The directory-based approach makes use of a database of information describing the protocols supported by hosts on the network. The path discovery approach tries to establish communication using all of the possible paths, and monitors the results. This document focuses on the directory-based approach. Network directory services such as the Internet Domain Name System (DNS) or the OSI directory service (X.500) provide a distributed database of information about hosts, their addresses, and the applications they support. In current architectures this database is typically consulted to map host and service names to their respective network and application addresses during path determination. Adding information about a host's protocol paths to this database is thus a rather natural way to support path determination in a multiprotocol environment. An important feature of the directory-based approach is that it does not require all hosts to make use of the directory service. For example, a host supporting only a single protocol suite need not refer to the directory's protocol path information at all, because its path determination problem is simple. To aid other multiprotocol hosts in establishing communication with the single-protocol host, information describing the protocol(s) it supports should be stored in the directory service, but no modification of its communication subsystem---or the way it uses the directory service, if any---is required. Note also that universal agreement on a single directory service is not required: it is only necessary that each multiprotocol host have access to a distributed database that contains some encoding of the protocol path information for the hosts with which it communicates. Nor is it necessary for every directory service to use the same encoding; different encodings might be used in different parts of the network. The only requirement is that users of a particular directory service agree on a standard method of encoding protocol path information. In the next section we consider some possibilities for such an encoding. 5 Encoding Protocol Path Information We would like to encode information about a host's supported protocols in a form that enables another host to determine --- at a minimum --- whether a protocol path common to both hosts exists. Information about a host's supported protocols can be stored in a directory service in any of several forms. Such an encoding scheme requires that globally-understood identifiers be assigned to some parts of the protocol structure. There are at least three levels at which such identifiers might be assigned: Protocol Entity, Protocol Path, Clark, Ammar, and Calvert [Page 4] INTERNET-DRAFT DNS to Support Multiprotocol Interoperability May, 1994 +-----------+ | USER | +-----------+ / \ +-----------+ +-----------+ | FTP | | TELNET | +-----------+ +-----------+ \ / +-----------+ | TCP | -----+-----------+---- / | \ +-----------+ +-----------+ +-----------+ | IP | | SIPP | | CLNP | +-----------+ +-----------+ +-----------+ Figure 1: A multiprotocol host. Protocol Graph. To compare these approaches, we consider a host with the protocols indicated in Figure 1. This host includes two different application PEs, one transport PE, and three network PEs. It supports six different protocol paths: three for each TCP application. This host implements traditional IPv4 as well as both the SIPP and TUBA IPng proposals [5, 10]. Let us consider the three protocol representation options as they would represent this particular example. o Protocol Entity: The first option involves assigning identifiers to the PEs themselves. The host protocol structure can then be represented in any of several ways, e.g. by giving for each PE, a list of the PEs to which it has edges (its uses-list). The host of Figure 1 would thus have an entry for ``TCP'' with a uses-list containing ``IP'', ``SIPP'' and ``CLNP''. The global identifiers are ``TCP'', ``IP'', etc. This approach can easily handle novel paths and configuration changes, and allows for partial matches when a complete matching path cannot be found. Partial matches might be useful in establishing a minimal level of communication with an unknown system. Another way to assign identifiers at the PE level is to encode the PE's uses-list (i.e. its outgoing edges) in the identifier. Thus an implementation of TCP that can use both IP and CLNP would have a different identifier than one that can only use IP. The protocols could then be represented as a simple list of PEs. This would generally yield a smaller representation, at the expense of Clark, Ammar, and Calvert [Page 5] INTERNET-DRAFT DNS to Support Multiprotocol Interoperability May, 1994 a larger number of agreed-upon identifiers. o Protocol Path: The second representation option is to assign a standard identifier to every protocol path and store a list of the paths supported. This approach simplifies path determination by providing a representation at the exact level where a match is sought. However, prior agreement on an identifier for every possible supported path is required; this may be a problem when new protocols and paths are introduced. This approach also provides a significant degree of redundant information because an application that uses multiple protocols will have a separate entry for each set of protocols it can use. For example, both the FTP and TELNET applications in Figure 1 would be incorporated into three path entries. o Protocol Graph: In this option, the entire collection of protocols supported by a host is assigned a standard identifier. This collection of protocols is known as a protocol graph. A significant problem with this representation approach is that it requires every existing protocol configuration to be known a priori so that a standard identifier can be assigned to it. This is infeasible given the diversity in the installed configurations of even single protocol suite systems. From the above discussion, the protocol entity and protocol path options appear to have the most potential. In order to more carefully compare the feasibility of the two approaches we examine the number of data items required to represent various collections of protocols. For the host in Figure 1, assuming that a PE's uses-list is encoded in its identifier, both options require the same number of stored items: six PEs vs. six protocol paths. When a new application is added using TCP, the PE approach requires the addition of a single PE entry. The protocol path approach however, requires three additional path entries. If a new network layer PE were added, the PE approach would require the addition of one PE plus the addition or update of the transport PE that used this network PE. The protocol path approach would require a new path entry for each application using this new protocol. In general, the PE approach is more efficient whenever a host includes applications that can operate over multiple different protocols. Since multiprotocol systems are becoming more common, and indeed this is precisely the kind of system we are interested in supporting, the PE representation approach appears to be the most appropriate. As systems add more applications, the benefits of the PE approach are further realized. Clark, Ammar, and Calvert [Page 6] INTERNET-DRAFT DNS to Support Multiprotocol Interoperability May, 1994 6 An Ideal Directory Service In this section we present the design requirements for a directory service that most effectively supports the protocol path determination task. Our objective is to describe the necessary directory service features in a context which is free from the constraints of any current directory service products. Later we discuss how most of these features can be provided in a production directory service. A problem in current directory service usage is the assumption that the availability of a particular network address for a host implies that the host supports a network protocol which utilizes that address. This assumption causes problems, for example, when translating gateways are used to provide transparent communication between two distinct protocols. In this scenario, the originating host must obtain an address for the destination that is compatible with the originating host's network protocol. For example, a host X which only supports IP cannot use a NSAP address to refer to another host Y even if X can communicate with Y through an IP/CLNP gateway. Host X will need an IP address to identify Y. Our multiprotocol directory service maintains network address information independent of the installed protocol information. While it is true that before using a given network layer protocol it is necessary to obtain a network address for that protocol, the existence of a certain type of address for a system does not necessarily imply that the system directly supports any protocols which use that address. Graph information is represented in the directory service as a collection of PEs and their uses-lists. The name of the PE is stored as a single string entry. The uses-list is stored as a string describing the set of PEs this PE can use. Conjunction and disjunction are indicated by the characters ``&'' and ``|'' respectively. Conjunction in a uses-list indicates that a PE requires the services of both underlying PEs to operate; e.g. OSI Presentation may require several Session Functional Units. Disjunction indicates that a PE can operate on any of the underlying PEs; e.g. TCP can select either IP, SIPP, or CLNP. Table 1 presents the information desired in a directory service entry for the protocol host shown in Figure 1. PEs with an empty uses-list are known as base PEs. These indicate that no lower layer matching information is available for protocol paths that include this PE. In general, the network layer protocols will serve as base PEs. If a PE can operate over multiple PEs it will have more than one entry in the uses list. Table 2 presents the information for a traditional TCP/IP host. The two main functions of a directory service for multiprotocol systems are: Clark, Ammar, and Calvert [Page 7] INTERNET-DRAFT DNS to Support Multiprotocol Interoperability May, 1994 ______________________________ | PE Name | Uses-list | |---------+------------------| | FTP | TCP | |---------+------------------| | TELNET | TCP | |---------+------------------| | TCP | IP | SIPP | CLNP | |---------+------------------| | IP | | |---------+------------------| | SIPP | | |---------+------------------| | CLNP | | |---------+------------------| Table 1: Protocol Graph Entry for a Multiprotocol Host. _______________________ | PE Name | Uses-list | |---------+-----------| | FTP | TCP | |---------+-----------| | TELNET | TCP | |---------+-----------| | TCP | IP | |---------+-----------| | IP | | |---------+-----------| Table 2: Protocol Graph Entry for a Single-Protocol Host. o LookupHost(input: Hostname, output: AddressInfo, GraphInfo) This function retrieves the addressing and protocol graph information for the specified host from the directory service. The addressing information is returned as a collection of network addresses of various types. The graph information is returned as a collection of PEs with their uses-lists. The initiating host will invoke this routine once for the remote host and again to obtain its own local graph information. o MatchPath(input: GraphInfo, LocalGraphInfo, output: Path) This routine compares the two protocol graphs and returns one or more common protocol paths. The overall goal is to find a protocol path that is common to both graphs and will provide communication between the user application and a base PE. The exact return value and algorithm used is dependent upon the ultimate goal of the Clark, Ammar, and Calvert [Page 8] INTERNET-DRAFT DNS to Support Multiprotocol Interoperability May, 1994 multiprotocol system. Achieving each of the goals we consider is equivalent in complexity to solving the subgraph-isomorphism problem. While the only known solutions to this problem are intractable for large graphs, the limited size of the protocol graphs coupled with the focused goals outlined below makes it feasible to solve this problem as part of communication establishment. The three possible path matching goals are: -- Succeed or Fail: If the user is only interested in obtaining communication or finding out if communication is possible then a function that simply finds and returns the first successful match would suffice. This algorithm should start by matching a single PE and then try to build a single matching path. -- All Matches: If a user wishes to be able to choose from multiple possible paths then it is necessary for the function to find all matches between the two graphs and return them. This function would be useful when there are several protocols supported by both hosts but one may be more appropriate for the given application. It is also possible that one or more of the valid paths may be temporarily unavailable due to a network failure. In this case the multiple paths would allow the user (or application) to try several different paths until one succeeds. -- Partial Matches: In some cases there may not be a complete match found from the application all the way down to the base PE. In this case it may be appropriate to return partial match information about the PEs that did match. This would allow the system either to obtain a degraded level of communication or provide meaningful diagnostics to indicate exactly which components of the protocol architecture are missing. Partial matches might also be used as an aid in determining which gateway or translating bridge services might be useful in obtaining the desired communication. The algorithm for finding partial matches should be able to start anywhere in the protocol graph and find all PEs that match between the two graphs. We will be exploring the use of partial matches for discovering gateway services as part of our future research. Each of these preceding protocol path matching goals focus on finding paths that allow hosts to communicate. These goals could be further qualified to find paths that provide a particular service. This limits the matching algorithm to a specific PE or set of PEs with which to start the search and for which a path is considered valid. Clark, Ammar, and Calvert [Page 9] INTERNET-DRAFT DNS to Support Multiprotocol Interoperability May, 1994 7 A DNS-Compatible Implementation The Internet Domain Name Service (DNS) is a popular example of the type of directory service that could provide protocol information. In this section we present an approach to using DNS to provide this extended service. Our primary objective in this design is to develop a mechanism for delivering multiprotocol information that provides as many of the features identified in Section 6 as possible while minimizing the impact on current directory service implementations. Our approach requires that additional DNS support be provided only in multiprotocol systems that will take advantage of the new DNS features. The changes we propose have no impact on systems that currently use the DNS directory services. An alternative approach to using DNS would be to extend an X.500 implementation such as QUIPU, which is available with the ISO Development Environment (ISODE) [12]. While this approach would give us more flexibility to define new host information records, the ubiquity of DNS in the current Internet makes it more suitable for providing a system which could be deployed today. 7.1 An Overview of DNS The DNS, described in [8] and [9], provides a hierarchically distributed database of network host information. It is used primarily to provide hostname to network address resolution. The two main components of the DNS are the domain server and the resolver. The domain server provides name service within a DNS domain. A domain corresponds to an administrative group such as a company or university. The resolver generally runs on the client host and provides the lookup service by successively querying domain servers. The actual data is stored on the server hosts in text files known as master files. The basic unit of information stored in the DNS is a resource record (RR). Each RR includes, among other things, a NAME field representing the node to which this entry pertains, a TYPE field representing the type of information stored, and an RDATA field representing the actual data for this entry. Some important types of RRs are: A --- the host address, MX --- mail exchange information, WKS --- the supported well-known services, and TXT --- a free-format text field. The WKS record format has a 32-bit address entry indicating the IP address, an 8-bit entry indicating a protocol, and a variable length bitmap indicating which services use that protocol. The protocol field contains the identifier of a protocol that uses IP such as TCP or UDP. The bitmap indicates which of the well-known services are supported on the host: if a service is supported then the appropriate bit is set. These well-known service numbers are used as port identifiers in the TCP and UDP protocols. For example, if FTP is supported then bit 21 is set since FTP uses port 21 of TCP. The protocol and well-known service numbers are Clark, Ammar, and Calvert [Page 10] INTERNET-DRAFT DNS to Support Multiprotocol Interoperability May, 1994 defined in the Internet Assigned Numbers document [11]. The standard interpretation of the protocol field in the WKS record is that it represents a transport layer protocol such as TCP. The service bitmap represents direct users of the transport layer. This interpretation is consistent with the TCP/IP network model where application services sit directly on top of the transport protocol and the well-known service number is used as the port identifier in the transport protocol. The organization of this record implies that any service listed will use the transport protocol listed for this record; an application using TCP should be listed in a separate resource record from an application using UDP. 7.2 A Multiprotocol Usage of DNS While the DNS was developed primarily for the TCP/IP environment, it has evolved to accommodate heterogeneous networks. For diversity at the network layer, a number of address formats have been defined. These address formats include an X.25 format, ISDN format, and an OSI style NSAP format. These are stored as RRs of TYPE X25, ISDN, and NSAP respectively. The RR type A is used for 32-bit IP addresses only. An interesting aspect of the original design of DNS is the inclusion of a CLASS field in each resource record. This attribute is reserved for specifying information about the ``supported protocol family'' of a host [8]. The most natural extension of DNS to the multiprotocol environment is to use the CLASS field to designate which protocol architectures are supported. For instance, a class could be defined to indicate use of the OSI protocols. Unfortunately, this field has become largely meaningless in the current usage as only one value, ``CLASS=IN'' for Internet, has been widely used. Instead of designating different classes, each of the previously mentioned address type records has been created within the Internet class. As we mentioned earlier, we are interested in developing a multiprotocol DNS that is compatible with most current DNS implementations. Our experience with current name server implementations, such as the BSD named program, is that they are largely hard coded for use with RR entries of class Internet. This means that the addition of a new CLASS value would require that current servers be modified to support the new classes and their associated types. We have decided not to pursue this approach since this change would conflict with our goal of not requiring the replacement of current systems. We have identified three possible approaches to using the current DNS architecture for distributing multiprotocol host information. All of these approaches use the alternative described in Section 6 where identifiers are assigned to PEs. They all use the currently defined Clark, Ammar, and Calvert [Page 11] INTERNET-DRAFT DNS to Support Multiprotocol Interoperability May, 1994 IN class resource records. The first two are based on the WKS RR and the third is based on the TXT RR. In the remainder of this section we compare these options and present our proposed solution. Each of the sample DNS entries presented in this section depict the master file format used by the DNS server to store the domain information. 7.2.1 A WKS Resource Record Approach The first proposal involves extending the semantics of the WKS entries to allow any PE to be represented in the protocol or service fields. Figure 2 shows a DNS master file entry for the host shown in Figure 1. Each line in this example corresponds to a separate RR. All of these RRs are associated with the host ``mphost''. The second field in each record indicates that the entry is of class IN for Internet. The third field indicates the type of RR data stored in this entry. The remaining fields contain the actual RR data. The first line in this example is the standard Internet address entry containing the IP address. The second line contains a host information entry describing the type of system associated with this host. In this case it is a Sun Microsystems Sparc 1 workstation running the SunOS operating system version 4.1. The third line contains a SIPP (Address SEQuence) address record. The current proposal for the format of this entry is described in [14]. The fourth line is an NSAP type record providing an OSI-format address. This format is described in [6] and is currently being updated [7]. ; Name Class RR-Type RR-Data ;----------------------------------------------------- mphost IN A 127.1.1.1 mphost IN HINFO "Sparc 1" "SunOS 4.1" mphost IN ASEQ 8:1:127.1.1.1 mphost IN NSAP 49.5100bd5a00 mphost IN WKS 127.1.1.1 ip tcp mphost IN WKS 127.1.1.1 sipp tcp mphost IN WKS 127.1.1.1 clnp tcp mphost IN WKS 127.1.1.1 tcp ftp telnet Figure 2: A multiprotocol DNS entry using WKS. The remaining four lines of the sample DNS data are the WKS entries used to describe this host's supported protocols. Each entry specifies a PE and the set of PEs that use it. The fourth field indicates the IP address for this WKS entry. The fifth field specifies a PE and the remaining fields indicate the users of that PE. If a PE A uses a PE B then A will appear in an entry where B is in the fifth field. The only PEs that must appear in field five of a WKS entry are those that themselves are used by other PEs in the protocol Clark, Ammar, and Calvert [Page 12] INTERNET-DRAFT DNS to Support Multiprotocol Interoperability May, 1994 graph. While this arrangement is natural for the traditional case where hosts have one or two transport protocols and multiple applications, it is exactly the reverse from what is needed in multiprotocol hosts where a single application may use multiple protocols. The presence of the address field in the WKS entries causes some problems when using them with multiple protocols. This problem can be seen in the second and third WKS entries where the IP address is given but a SIPP or CLNP network protocol is listed as the PE. Because the address field has a fixed length of 32-bits, it is not possible to vary the address given to agree with the protocol specified. In general, our use of the DNS in this approach ignores the address in the WKS entries. Note also that we have provided explicit entries indicating the presence of the network layer protocols. This is consistent with our goal outlined in Section 6 of keeping the protocol information separate from the addressing information. We do not assume that a network protocol is available on a host just because of the presence of that protocol's network address. The overloading of the WKS semantics in this approach could be a problem for any current users of the WKS field and current server implementations. One server implementation, the BSD named program, makes explicit use of the getprotobyname() and getservbyname() routines to resolve the protocol and service fields as it reads the WKS entries from a master file. In UNIX systems these routines traditionally use the /etc/protocols and /etc/services data files to obtain assigned numbers for protocol and service names. Using additional PEs like SIPP and CLNP in the protocols field (field five) will either cause problems in maintaining these data files or require that the name server be re-written to use an alternate data source. 7.2.2 A WKS Resource Record Approach With External Data In order to avoid this overload of the protocol field in WKS entries we consider an alternate proposal using WKS RRs. In this approach, only PEs above the transport layer will appear in the bitmap portion (fields six and above) of the WKS entry. This alternative is characterized by the use of an external data source that provides additional meaning to the DNS entries. This data source could be maintained locally on the host or distributed by some other directory mechanism. We use this external information to map the PE entries in the fifth field to their uses-list. This maintains more consistency with the standard WKS usage by alleviating the need to store network layer PEs in the fifth field. A sample entry of this type is found in Figure 3. As in the previous approach, only those PEs that are used by another PE will appear in field five of a WKS entry. The external definitions of the protocol and service identifiers from Clark, Ammar, and Calvert [Page 13] INTERNET-DRAFT DNS to Support Multiprotocol Interoperability May, 1994 ; Name Class RR-Type RR-Data ;-------------------------------------------------- mphost IN A 127.1.1.1 mphost IN HINFO "Sparc 1" "SunOS 4.1" mphost IN ASEQ 8:1:127.1.1.1 mphost IN NSAP 49.5100bd5a00 mphost IN WKS 127.1.1.1 tcp ftp telnet Figure 3: A multiprotocol DNS entry using WKS and external data. the WKS entry are given in Table 3. This is the additional data that must be provided to indicate the uses-lists of the WKS PEs. We assume that the ``tcp'' implementation supports either ``ip'', ``sipp'' or ``clnp'' [2]. ____________________________________________ | Assigned Name | PE Name | Uses-list | |---------------+---------+----------------| | ftp | FTP | TCP | |---------------+---------+----------------| | tcp | TCP | IP, SIPP, CLNP | |---------------+---------+----------------| | telnet | TELNET | TCP | |---------------+---------+----------------| Table 3: Definitions of protocol and service identifiers. Using both the WKS entry and PE definitions, a communication subsystem can build a protocol graph describing the available protocol paths on the host of interest. The capabilities of this approach are the same as for the previous approach. The principle advantage of this approach is that it maintains greater compatibility with current WKS semantics for the protocol specifiers. This compatibility comes at the expense of requiring an additional data source and additional agreement on the meanings of the assigned names provided by that source. 7.2.3 A TXT Resource Record Approach The final alternative we present uses the DNS TXT entries to encode protocol graph information. Currently, there is no widely used format for TXT entries(1). We propose that the TXT field be used to store a _____________________________ (1)Rosenbaum has proposed a new mechanism for using TXT fields for arbitrary string attributes [13]. At the time of this writing, this Clark, Ammar, and Calvert [Page 14] INTERNET-DRAFT DNS to Support Multiprotocol Interoperability May, 1994 description of the PEs available on a host as well as the uses-lists of those PEs. The general format of the PE entries is ``/''. Figure 4 shows a grammar for parsing these TXT entries. We use the leading string ``PEInfo'' to distinguish these protocol descriptions from other TXT fields in use. ::= "PEInfo:" ::= ";" ::= ::= "/" ::= ::= "|" ::= ::= "&" ::= ::= [a-zA-Z0-9-] ::= Figure 4: A sample grammar for parsing PEInfo TXT entries. Figure 5 shows a possible DNS entry for a host with the protocols given in Figure 1. Multiple PE entries in one TXT record are separated by a ``;''. If no uses-list is present, the entry is assumed to be a base PE. The entries are grouped by the protocol layer described. This grouping has no semantic meaning for the system and is strictly for the convenience of the person reading the file. ; Name Class RR-Type RR-Data ;---------------------------------------------------- mphost IN A 127.1.1.1 mphost IN HINFO "Sparc 1" "SunOS 4.1" mphost IN ASEQ 8:1:127.1.1.1 mphost IN NSAP 49.5100bd5a00 mphost IN TXT "PEInfo:IP;SIPP,CLNP" mphost IN TXT "PEInfo:TCP/IP|CLNP|SIPP" mphost IN TXT "PEInfo:FTP/TCP;TELNET/TCP" Figure 5: A multiprotocol DNS entry. For our current implementation we have elected to pursue the use of the TXT fields to describe protocol graph information. This approach provides the most flexibility in encoding and presents the least danger of conflicting with current implementation and usage. One issue to note is that while the TXT RRs are defined in the specification [9] from 1987, they are not supported by all DNS _____________________________ was an experimental Internet standard. Clark, Ammar, and Calvert [Page 15] INTERNET-DRAFT DNS to Support Multiprotocol Interoperability May, 1994 implementations. The version of named found in the 4.3 Reno release of BSD UNIX includes support for TXT but the older BSD version that provides the basis for Sun OS 4.1.3 does not. This means that the WKS-based alternatives described above may indeed be more compatible with existing servers. However, since the use of newer address types like NSAP and ASEQ will require updating of name servers anyway, we expect that most Internet name servers will include support for TXT fields. As a proof of concept, we developed a working multiprotocol FTAM implementation capable of carrying out a file transfer with hosts supporting one of several different protocol architectures. This work is described in [4]. 8 Concluding Remarks In order to effectively use multiprotocol systems for communication in heterogeneous networks we must develop mechanisms for efficiently combining the protocol architectures and managing their use. Managing the use of these systems involves both determining which protocols should be used and then specifying that usage to the systems. This document describes our work in using a directory service to aid in the determination task. We described a practical extension of the current DNS for multiprotocol systems that involves no modification to the currently deployed DNS server software. It should be noted that the examples used in this document deal with multiprotocol systems that can be implemented today. Many other multiprotocol configurations are possible and are supported by our approach. We expect that as new architectures are developed, the problems considered here will become even more important. Current proposals for the next generation Internet protocols all involve some sort of transition strategy where both current and future protocols will need to co-exist. Our proposed architecture is an appropriate solution to this multiprotocol co-existence problem. The use of a directory service to solve this problem has some potential drawbacks that should be addressed. The usefulness of the directory service is limited by the accuracy of the directory information. If a host changes protocol graphs, by updating or replacing software, and the directory entries for that host are not correctly updated, other hosts will be unable to establish communication with that host. The question of accuracy of the DNS entries has been raised in the Internet community. Indeed the Internet host requirements document [1] specifically warns that a host should not rely on the WKS entries to provide accurate information regarding the services available from another host. These concerns over accuracy lead to the likelihood that the directory service itself may not be enough to provide Clark, Ammar, and Calvert [Page 16] INTERNET-DRAFT DNS to Support Multiprotocol Interoperability May, 1994 up-to-date information about a network host. Our future work will look at ways to combine the directory service with a more dynamic discovery system that determines the supported protocols from the host itself when the directory service information is incomplete. 9 Acknowledgments The authors would like to acknowledge the support for this work by a grant from the National Science Foundation (NCR-9305115) and the TRANSOPEN project of the Army Research Lab (formerly AIRMICS) under contract number DAKF11-91-D-0004. 10 References [1] R. Braden. Requirements for internet hosts - application and support. RFC 1123, October 1989. [2] R. W. Callon. TCP and UDP with bigger addresses (TUBA), a simple proposal for internet addressing and routing. RFC 1347, June 1992. [3] R. J. Clark, M. H. Ammar, and K. L. Calvert. Multi-protocol architectures as a paradigm for achieving inter-operability. Proceedings of IEEE INFOCOM, April 1993. [4] R. J. Clark, K. L. Calvert, and M. H. Ammar. On the use of directory services to support multiprotocol interoperability. In To appear in Proceedings of IEEE INFOCOM, June 1994. [5] S. Deering. Simple internet protocol plus (SIPP) specification. Internet Draft, November 1993. [6] B. Manning. DNS NSAP RRs. RFC 1348, July 1992. [7] B. Manning and R. Colella. DNS NSAP Resource Records. Internet Draft, December 1993. [8] P. Mockapetris. Domain names - concepts and facilities. RFC 1034, November 1987. [9] P. Mockapetris. Domain names - implementation and specification. RFC 1035, November 1987. [10] D. Piscitello. Use of iso clnp in tuba environments. Internet Draft, February 1994. [11] J. Reynolds and J. Postel. Assigned numbers. RFC 1340, July 1992. Clark, Ammar, and Calvert [Page 17] INTERNET-DRAFT DNS to Support Multiprotocol Interoperability May, 1994 [12] M. T. Rose. The ISO Development Environment User's Manual - Version 7.0. Performance Systems International, July 1991. [13] R. Rosenbaum. Using the domain name system to store arbitrary string attributes. RFC1464, May 1993. [14] S. Thomson and C. Huitema. DNS extensions to support simple internet protocol plus (SIPP). Internet Draft, March 1994. 11 Authors' Address Russell J Clark - rjc@cc.gatech.edu Mostafa H Ammar - ammar@cc.gatech.edu Kenneth L Calvert - calvert@cc.gatech.edu College of Computing Georgia Institute of Technology Atlanta, GA 30332-0280 Clark, Ammar, and Calvert [Page 18]