Internet Draft J. Noel Chiappa Expires: April 19, 1995 October 19, 1994 Mobilty and Multi-homing with Endpoint Names 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. Internet Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material or to cite them other than as a 'working draft' or 'work in progress.' Please check the Internet Draft abstract listing (in the file 1id-abstracts.txt) contained in the Internet Drafts shadow directories (cd internet-drafts, on nic.ddn.mil, nnsc.nsf.net, ftp.nisc.sri.com, nic.nordu.net, or munnari.oz.au) to learn the current status of any Internet Draft. Abstract When using the Internet protocol suite, processes communicate via transport associations, such as TCP connections; these define end- to-end communication relationships, or contexts, between the processes. Enhanced services, such as for host and service mobility and failure recovery, can be facilitated by distinguishing a transport association from the underlying internetwork service(s) it uses. This distinction will allow relocating one or both ends of the context, while maintaining a consistent and unique reference to that context, independent of its network connectivity. This proposal suggests using domain names to identify the ends of the context, and then uses a combination of domain names, port numbers and protocol identifiers to define transport associations. It then uses an internetwork level control channel between hosts for adding and removing internetwork addresses associated with the ends of the context. This document is a description of the proposed facility, rather than a complete specification. It is intended to convey the concepts and style of the proposed mechanism, saving the details of formats for later. Acknowledgements This document is a moderately edited version of an original document by David Crocker entitled "Transport Context Names (TCN): Concepts and Facilities". The present author feels a somewhat different mechanism is superior to the one proposed by Crocker, and the present author has presented this scheme by making small changes to Crocker's original document. Normally Crocker would appear as a co-author, in view of the fact that the majority of the document is his work, but since he favors a different mechanism, his name does not appear. The current author wishes to thank Crocker for permission to mangle Crocker's original text; any mistakes or other problems are of course the responsibility of the present author. Introduction When using the Internet protocol suite processes communicate via transport associations, such as TCP connections; these define end- to-end communication relationships, or contexts, between the processes. For TCP, the context name is currently called a "connection identifier" and is defined by the source and destination IP addresses and the source and destination port numbers. [TCP], [Cerf] Also explicit is the IP protocol value identifying TCP, itself; it is in the pseudo-header which is covered by the TCP checksum. Identifying a connection in this fashion ties it to a particular IP address pair for the life of the connection. Since IP addresses identify particular host interfaces, this means that all datagrams for the connection must go through the same interfaces. Generally they also will go through the same intermediate routers, since routes tend to be quite stable. When a route becomes unavailable, routing protocols usually require significant time before establishing an alternate. While TCP is persistent and will succeed at sending its data after a network delay, some applications have performance requirements which need quicker recovery from failures. In addition, if an interface fails, all the connections which are terminated at that interface will fail too, even if other interfaces to that host are available. If such connections are to survive the the failure of the interface, they must be able to use one of the other available interfaces. An IP (interface) address specifies the network to which the host is attached. Many forms of host mobility cause the host to be attached to different parts of the communication fabric at different times. For management and scaling, it can be quite helpful for hosts to have different IP addresses according the particular part of the fabric to which they are attached. Because a TCP connection id is tied to particular IP addresses, this means that the connection cannot survive such IP address transitions. This proposal suggests that enhanced services, such as for host and service mobility and failure recovery, can be facilitated by distinguishing a transport association from the underlying internetwork address(es) it uses. This distinction will allow re- locating one or both ends of the context, while maintaining a consistent and unique reference to that context, independent of its network connectivity. Further, it allows using multiple network interfaces as part of the same association, so that a problem through one interface can lead to quick retransmission through one of the alternates. This proposal suggests using a combination of domain name, port number and protocol identifier to define transport associations, and then using control channels between hosts for adding and removing internetwork addresses for the hosts on either end of the association. User packets would still be identified by only address and port, however. This proposal thus suggests a mechanism which mandates no changes in existing packet formats at either transport or internetwork layer. This restriction on keeping existing packet formats is not the way in which the author would prefee to proceed. This design represents what seems to be the best that can be done within that constraint. The author maintains that a better solution would be to include information identifying the endpoint in user packets, but this would mean modification of the packet format. Transport Context Names and Endpoint Names A Transport Context Name (TCN) is a globally unique reference to the communication context and is labeled by the tuple: < Transport service, Source endpoint domain name, Destination endpoint domain name Source transport id, Destination transport id > where: Transport service specifies the transport protocol, such as UDP or TCP; Source endpoint domain name specifies a globally unique reference to the machine or service at one end of the transport context, and Destination endpoint domain name specifies the other end. Source transport id specifies the transport association identifier used by the source, such as the TCP source port number Destination transport id specifies the identifier used by the destination. The TCN is the name of the connection, and is the only identification of the connection used at the interface between the transport layer and the application. (Efficient implementations will undoubtly use a handle which is semantially identical, if not syntactically, e.g. a pointer to a connection control block, CCB.) In addition, the endpoints (approximately "hosts") which are the two ends of the communcation context are identified by one or more globally unique domain names each; these are referred to as Endpoint Names (ENs). These ENs are used at the interface between the internetwork and transport layer. (Again, efficient implementations, etc.) Internetwork Interface Addresses At the internetwork layer, associated with a endpoint name is a list of one or more internetwork interface addresses. A Internetwork Address (IA) defines a specific address to use for conveying internetwork data to a given endpoint and may then be used by the internetwork service for alternate transmission choices, to improve recovery from delivery interruptions, etc. It contains the data: < Internetwork interface identifier > where Internetwork interface identifier specifies a network access identifier, such as IP address, for one endpoint using the network protocol, An Internetwork Address List (IAL) comprises a EN and a set of one or more IAs. It defines the choices that an internetork layer has when deciding where to send a segment of data to get it to a given EN. The list may be modified over the life of the IAL, to permit changing attachment to the Internet, such as for host mobility. (It may well also be useful to permit processes to migrate from one host to another -- assuming that the hosts cooperate among themselves to coordinate the local transfer of the process context. Note that to do this the processes must be given individual process endpoint names, since the TCN needs to stay the same when the process moves; the process cannot use the DNS name of the new host. In addition, there will be some instances in which it is impossible to move a process since the port in the TCN of one or more connections of the process is already in use at the new address. Since *packets* are only identified by address and port, this would not allow finding the correct connection if two connections had the same address and port, even though they had separate TCNs. Fixing this would involve either adding the ability to change port numbers (which involves changing the application interface, since a TCP connection would no longer be identified by the constant port number of the TCN), or either i) the ability to add another address to the destination host or ii) adding more information to the packet. The idea in both of the latter approaches is to allow correct assignment of incoming packets to the appropriate connections. Since we are not modifying the packet format, e.g. to contain an endpoint name directly, this fix is not applicable, leaving address assignment as the only mechanism, other than rejection, for an attempt to move a connection which results in a collision.) When an IAL contains more than one IA, the internetwork layer may choose to send portions of traffic over different IAs. While this may result in increased throughput, its primary benefit is to allow use of different IAs. When one ceases to provide adequate performance, the internetwork may simply mark it as disabled and then send traffic over the remaining IAs. Internetwork Address List Management A IAL must be defined before communication with a particular EN is possible. Using public domain names, such as from the domain name service, and the set of network addresses publicly listed, or obtained from the DNS, for that endpoint, a host must build a IAL prior to sending a specific EN. Alternatively, a host may build a IAL as a result of an attempt to open a connection from another host. In this case of derived use, the other hosts initializes a control channel exchange adding an EN, at least one IA, and, possibly, other IAs, at the destination. A control channel operates between hosts, rather than processes. It needs to have a means of authenticating both participants, particularly since this service permits moving contexts to different addresses. Generally, the protocol is likely to be relatively simple, requiring commands roughly to do simple manipulations of IA entries on a internetwork address list. For example: create (EN, IA) add (EN, IA) delete (EN, IA) list (EN) Also included would be acknowledgements for each, as also negative acks. Its periodic nature, and placement as a key part of the function of the internetwork layer, suggests that ICMP be used for this. Use of TCNs and ENs by Transport Services While actual implementations may behave in a far more integrated fashion, the model for transport/internetwork interactions has a transport service build a transport segment and then pass it to the internetwork service for additional handling. For tranport services, like TCP's use of the pseudo-header, that currently integrate information about the internetwork layer into the transport protocol, they need to change to use only EN's in all locations. This avoids needing to account for the variability in internetwork-layer headers. Additionally, since packets are only identified by internetwork layer addresses, not EN's, the transport layer needs to take some steps to ensure that packet are correctly delivered. The brute-force way to do this is to include the EN in the packet. This represent overhead, and a packet format change. The alternative which may be considered is to include the EN in a pseudo-header which is included in the transport level checksum, but not actually sending the EN over the network. This is not quite as robust as both sending the EN, and including it in the checksum, but it is acceptable. Use of authentication, increasingly common, will increase the robustness to an essentially unquestionable level. Note that this solution is more or less mandated by the problem above, so it's a basically free solution to the problem. Another point involves use with mobile applications or processes, or on hosts with multiple ENs. Since on hosts with multiple ENs present locally, there is no way to tell which EN an incoming packet is sent to (multiple ENs map to a single destination internetwork level address), such systems must be prepared to pass a number of different potential ENs to the transport layer, for the transport layer to use in finding the correct CCB. In a similar vein, as long as each IA in use appears in at most one IAL, there is no ambiguity as to which EN the packet is from. If it appears in multiple IALs however, there is ambiguity. Simplistic implementations may refuse to accept use of a single IA in multiple IALs to prevent the complexity needed to deal with this. Use of ENs and IAs by Internetwork Services Use of a EN/IAL model requires inserting an extra decision process in the internetwork layer prior to passing the segment down to the network service in the cases where an IAL contains more than one IA, since the internetwork layer must decide which of the listed IAs should be used. In order to keep information about IA behavior, a internetwork service might do round-robin use of the available set. When the transport layer signals that a problem is occurring (such as a segment needs to be retransmitted) the internetwork service will take a variety of actions to see if the problem is caused by a fault at the internetwork level; among them, it might choose to send it over a different IA than was initially used. Given the complexity and sensitivity of fault recovery algorithms, this will require research. As a general note, the issue of how to deal with faults in the internetwork between the source and destination endpoint is a complex one. There are a whole range of problems, the recovery strategies for which vary. A failed first-hop router currently demands a different discovery and recovery strategy from a failed intermediate route, which is again different from a failed interface on a multi-homed destination. These are all specific instances of a general class of robustness mechanism, which is changing the path from the source endpoint to the destination endpoint to avoid a failure. As a design fundamental, it's not good to split solving a problem like that up into various layers. Separating the parts can both make it more difficult to do each part (for instance, if there has been policy input to selecting the path, changing interfaces means you have to go back to pick a new path which meets those policy constraints); even worse, it can make deployment of a new strategy to handle the entire problem with a coherent fault analysis and repair strategy almost impossible, due to the ad hoc balkanization of the problem handling in different places. Two things are almost certainly true. For one, its generally best to keep the transport out of routing decisions entirely, and which interface to pick at the destination is just one more routing decision. For another, the selection of an IA through which to reach an EN is a part of the path selection process, and should not be separated from other parts of that path selection. For this reason it seems absolutely necessary to keep the EN<->IA mapping, and the selection of IAs, at the internetwork level. As noted above, on incoming packets, it will be necessary to find the EN (or set of potential ENs) associated with the IA in an incoming packet, and pass this up to the transport layer. 5. EXAMPLE HOST: STABLE.ORG HOST: MOBILE.ORG (IP address: 192.254.254.1) (IP address: 192.253.253.1) CONTROL CHANNEL: CREATE (stable.org, 192.254.254.1) -> <- CONTROL CHANNEL: ACK (stable.org, 192.254.254.1) TCP SYN (TCP: stable.org, mobile.org, 2345, 25; IP: 192.254.254.1 -> 192.253.253.1) -> ...Normal TCP session activity ... (Host mobile.org moves to location with overlapping service) <- CONTROL CHANNEL: ADD (mobile.org, 192.253.253.2) ... Sending TCP data now requires choice of ... IA, either 192.253.253.1 or 192.253.253.2 (Host mobile.org moves fully into second service area) <- CONTROL CHANNEL: DELETE (mobile.org, 192.253.253.1) ... Sending TCP data now requires use only of ... IA 192.253.253.2 Introduction and Upward Compatability This proposal seeks to provide a layered facility for enhancing certain characteristics of Internet service. As mentioned above, it proposes a mechanism which involves no changes in existing packet formats and which permits unmodified systems to continue to function as they do today if they do not need the new services. (This assumes that this facility is not included from the start as a mandated standard, as might be the case with IPv4.) In any case, the way in which upward compatability is arrived at with this design uses two distinct mechanisms. First, the attempt to install the IAL at the far end may fail. If so, the old non-mobile mode is assumed for all transport layers on that host. Then, there is a negotiation at the start of the transport connection, to see if the transport layer on the far end has been upgraded to use EN's instead of IA's. If the round-trip delay on the first transaction is to be avoided, the connection opening packet may be send before the ack on the control channel is returned, provided provision is made for handling the case when the original control channel request is lost. As an example of how this would work, the following details apply to TCP. TCP support would involve a new TCP option; the request option *must* be sent in a SYN packet, to make the issue of what value to use in the pseudo-headers of the TCP checksums solvable. The rule is quite simple; the SYN packet uses the old-type checksum, in which the IA is used in the pseudo-header. If the option is sucessfully negotiated (i.e. an acknowledging option is received in the packet acknowledging that SYN), all future packets are sent with a pseudo-header containing the EN. Any retransmission of the SYN packet, or its acknowledgement, must use the old value, of course. It might appear to the less competent implementor that this means that two different incoming segment processing routines will be needed. This is not so. The checksum computation is structured to have precomputation of a partial checksum of those parts of the pseudo-header (and TCP header) which are guaranteed constant (i.e. the TCN fields); this partial checksum is used as a "seed" to the checksum routine for each incoming packet (instead of the 0 which is normally the starting value of the accumulated checksum). This seed is set to the value computed by using the IA in the pseudo-header to begin with; on reception of the option acknowledgement, the seed value computed using the EN is substituted. The same code may thus be used to process incoming segments of connections both using, and not using, this new facility. Likewise, for the finding of the correct CCB, if some connections are using this mechanism, and some are not, it is necessary to check for matches on either the EN or the IA (the IA from the incoming packet). This may be optimized by handling both the EN *and* the IA as pointers to a database of valid values; if the correct valid value for a given CCB is kept in that CCB, it will be simple to check both the EN and IA for a match. If the foreign and local ports are checked for a match first, this should eliminate most checks of the EN/IA, and two pointer comparisons, with a branch on equal which would not usually be taken, are probably faster than a check to see if a given CCB is using an EN or an IA, followed by the appropriate check for each. The request option includes the sender's EN, as well as the EN of the desired destination endpoint (the latter so that a host with multiple endpoints, or multiple ENs for a single endpoint, knows which endpoint the connection is for, and which EN will be used in the pseudo-header). The acknowledgement option contains no data. Comments This scheme explicitly seeks to avoid changing the Internet infrastructure, for which change there is absolutely no need. Routers simply forward packets to a destination address, and if hosts wish to move from one address to another, there is no need to involve the routers. The facility will support a high degree of host mobility, and will permit connections with high degrees of robustness to isolated network outages, when an alternate path is already available. The internetwork layer is the foundation for Internet services. This proposal seeks to place therein certain functions which properly belong at that layer, for maximum functionality and availability. These functions are optional enhancements to the core internetwork layer operation. However, given their utility, it is hoped that all hosts will eventually implement them. Mobility requires a number of changes to Internet service components. For highly localized mobility, underlying media services need to make the changes transparent. For longer-term, longer-distance mobility, the domain name service needs to support dynamic registration of address changes. IP addresses pertain to host location within the topology of the Internet. Mobility is, by its definition, the process of changing that location. This should naturally cause a host's IP address to change. The proposal described here supports these changes naturally during the lifetime of a transport context. References [TCP] Postel, J., "Transmission Control Protocol", RFC 793, USC/Information Sciences Institute, September 1981 [CERF] Cerf V., and R. Kahn, "A Protocol for Packet Network Interconnection", IEEE Trans. on Communications, Vol. COM-22, No. 5, pp. 637-648, May 1974. Security Considerations This proposal describes a control channel between host-pairs, used to assign IALs for data transfer. Unauthorized use of this channel could cause a internetwork association, such as a TCP connection, to be redirected to an inappropriate host. For most current host exchanges, careful attention to the chain of channel directives should give the recipient as much basis for Author's Address J. Noel Chiappa Email: jnc@lcs.mit.edu Phone: 1-(804)-898-8183 Fax: 1-(804)-898-7663