Below are the first 10 and last 10 pages of uncorrected machine-read text (when available) of this chapter, followed by the top 30 algorithmically extracted key phrases from the chapter as a whole.
Intended to provide our own search engines and external engines with highly rich, chapter-representative searchable text on the opening pages of each chapter. Because it is UNCORRECTED material, please consider the following text as a useful but insufficient proxy for the authoritative book pages.

Do not use for reproduction, copying, pasting, or reading; exclusively for search engines.

OCR for page 13
III. COMPARISON OF DOD AND ISO PROTOCOLS This section presents a general description of the major functional differences between the ISO and DOD protocol sets at the transport and network layers and then discusses particular aspects of the protocols: performance, security, and risk. COMPARISON OF DOD AND ISO TRANSPORT LAYERS Differences between the Defense Department's TCP protocol and the International Standards Organization's TP-4 protocol are described in terms of items visible to users of the protocol. Internal differences in mechanism that have no effect on the service seen by the user are not con- sidered. A second much simpler protocol, the User Datagram Protocol (UDP), providing datagram or connectionless service at the transport layer is also briefly considered. In summary, the services provided by TCP and TP-4 are functionally quite similar. Several functions, however, including data transfer inter- face, flow control, connection establishment binding, and out-of-band sig- nals are provided in significantly different ways by the two protocols. Neither seems intrinsically superior, but some effort would be required to convert a higher-level protocol using TCP to make use of TP-4. The exact amount of work needed will vary with the nature of the higher-level protocol implementations and the operating systems in which they are embedded. A programmmer experienced with the higher-level protocols would require about six months to design, implement, and Lest modifications of the three major DOD higher level protocols (file transfer, mail, and Telnet) to work with TP-4. There are several areas in which the openness and lack of experience with the TP-4 specification leave questions- about just what functionality is provided and whether incompatibilities are allowed. These areas in- clude connection-establishment binding, flow control, addressing, and provision of expedited network service. The best way to resolve these questions seems to be to implement and test TP-4 in a military environ- ment and to further specify desired procedures where there is unwanted latitude allowed by the standard (see the recommendations section XI). There is one area in which the NBS-proposed Federal Information Pro- cessing Standard (F1PS) differs from the ISO specification: The F]PS provides a graceful closing service as in TCP, while the ISO does not.

OCR for page 13
Data Transfer Interface TCP is stream oriented. It does not deliver any End of Transmission (EOT), but accepts a "push" on the send side which has an effect much like an EOT causes data being buffered to be sent. TP-4 is block oriented and does deliver EOT indications. By indicat- ing EOT, a sending user should be able to accomplish the same effect as "push" in TCP in most reasonable TP-4 implementations. The impact of this is uncertain. Neither type of interface is inher- ently better than the other. Some applications will find it more conve- nient to have a stream-type interface (for example, interactive terminal handling), while others might prefer a block mode (for example, file transfer). It should be possible for TP-4 to approximate the stream mode by forwarding data without an EOT from the sending user and delivering data to the receiving user before an EOT is received. Some work would have to be done on applications using one type of protocol to modify them to use the other. F ~ ow Contro ~ TCP has octet units of allocation, with no EOT and hence no impact of EOT on the allocation. The segment size, Transport Protocol Data Unit (TPDU) size, used by the protocol is invisible to the user, WhO sees al- Jocations in units of octets. TP-4 has segment units of allocation, with a common segment size for both directions negotiated as part of connection establishment. Although in some implementations the protocol's flow control is not directly vis- ible to the users, in others it is. In the latter case, users of TP-4 wild see allocations in units of segments and will have to be aware of the segment size for this to be meaningful (for example, to know that a window of four lOO-byte segments seen will be consumed by two messages of 101 to 200 bytes each). The impact is uncertain. Both octet and segment units of flow control can be argued to have their advantages for different types of application. The former makes it easy to indicate buffering limits in terms of total bytes (appropriate for stream transfer), while the latter makes it easy to indicate buffering limits in terms of messages (appropriate for block mode). The way in which flow control is exerted over an interface is complex and one of the most performance-sensitive areas of protocols, so a significant conversion and tuning effort would be required to get an application used with one type of high-level protocol to be able to per- form using another. Error Detect i on TCP applies ones-complement addition checksum. TP-4 uses an ISO - 14 -

OCR for page 13
algorithm.8 The error-detection properties of the TCP procedure have not been studied carefully, but the ISO algorithm is thought to be some- what stronger and hence allows fewer nondetected errors in data passed to users. It should be noted that the TCP checksum is defined to include certain fields from the IP level including addresses so that double pro- tection against misdelivery errors is provided. The practical difference in error-detection power is probably not important. Simultaneous Call Between Same Users TCP will establish one call. TP-4 will establish two calls if both sides support multiple calls, no call if they allow only one call (that is, see each other as busy), or in very unusual circumstances, one call. The impact is minor since most applications naturally have an initiator and a responder side. Multiple Calls Between Same Addresses TCP allows only one call between a given pair of source and destina- tion ports. TP-4 allows more than one by using reference numbers. The impact is minor since it is easy to generate a new per-call port number on the calling side in most cases. This can be a problem in TCP, however, if both are well-known ports. Addressing TCP provides sixteen bit ports for addressing within a node identified by the internet layer. Some of these ports are assigned to well-known ap- plications, others are free for dynamic assignment as needed. TP-4 provides a variable-length transport suffix (same as Transport Service Access Point Identifier) in the call-request packet. The use of addresses at different levels in the ISO mode] has not yet been solidi- fied, but it seems likely that addressing capabilities similar to TCP's will eventually be provided by TP-4 (or possibly the session layer) along with standard addresses for common applications. The impact is likely to be minimal, but this is an open area of the ISO specifications that may need further definition for use by DOD. Binding User Entities to Connections TCP requires a prior Listen Request from a user entity for it to be able to accept an incoming connection request. Normally a user entity must exist and declare itself to TCP, giving prior approval to accept a for additional information, see Information-Processing Systems, Open-Systems Interconnection, -Con ~

OCR for page 13
call from a specific or general remote entity. In some implementations it may be possible for a nonresident user entity to cause a Listen Request to be posted and an instance of the entity to be created when a matching connection request arrives. TOP does not queue an incoming connection request with no matching Listen Request but instead rejects the connec- tion. TP-4 requires no prior request but passes a Call Indication to a user entity whenever a Cal] Request is received. It is, however, left open as an implementation decision as to how TP-4 finds and/or creates an appro- priate user entity to give the Call Indication, that is, the service does not include or define how user applications make themselves available for calls (no Listen Service Primitive). The implementation guidelines indi- cate that well-known addresses, prior process existence, and Call Request queuing are all facilities that may or may not be provided at the imple- mentor's choice.9 This would seem to allow for different choices and hence failure to establish a connection between standard implementations (for example, caller expects requests not to be queued, while callee does queu i ng, and hence never responds). The practical impact is uncertain due to lack of experience with how the various options allowed by the TP-4 standard will be used in practice. TCP seems more oriented to a prior authorization mode of operation, while TP-4 most easily supports an indication-with-later-acceptance scenario. It is not clear how TP-4 will support rejecting calls to nonexistent or inactive user entities and how user entities could control how many calls they wou ~ ~ accept. Th i s area may requ i re DOD ref i nement. OtJi-of-Band Signals TCP allows the user to specify an urgent condition at any point in the normal data stream. Several such indications may be combined, with only the last one shown to the destination. There is no limit to the number of urgent indications that can be sent. The TCP urgent messages are sent requesting expedited service from the network layer so network bottlenecks can be bypassed as well. TP-4 allows users to send expedited data units carrying up to sixteen octets of user data. These are only half synchronized with the normal data stream since they may be delivered before previously sent normal data, but not after subsequently sent normal data. Each expedited data unit is delivered to the destination, and only one can be outstanding at a time. ISO has indicated its intention to allow transport protocols to use network-level expedited service, but this is not yet defined. 9Specification of a Transport Protocol for Computer Communications, Vol. 5: -Guidance for the Implementor, Section 2.~.2. National Bureau of Standards, Institute for Computer Sciences and Technology, (Washington, D.C.) U.S. Department of Commerce, January 1983. - 16 -

OCR for page 13
The impact is primarily for applications like terminal traffic han- dlers that must deal with interrupt-type signals of various types. The need to read an arbitrary amount of normal data and recognize urgent data in the normal stream are difficulties with TOP urgent service, but it has been used successfully by the Teinet protocol. The lack of full synchro- nization of the signal and normal data in TP-4 may require users to insert their own synchronization marks in the normal data stream has was the case with the old ARPA Network Control Program (NCP)], and the limitation of one outstanding signal may be restrictive. Some effort would be required to convert higher-level protocols using one transport protocol to using the other. Security The committee has determined that the TOP and TP-4 are sufficiently equivalent in their security-related properties so that no significant technical points favor the use of one over the other. The DOD protocol architecture assigns the security-marking function to the IP layer and provides an [l-byte security option with a defined coding in the IP header. TP-4 provides a variable-length security option carried in Call Re- quest packets. A variable-length security option field is also provided in the ISO IP. Standard encoding of security markings are under consider- ation but not yet defined and accepted. In addition to these explicit security-marking fields, the existence, coding, and placement of other header fields have security implications. If data is encrypted, for example, a checksum is usually used to deter- mine if the decrypted data is correct, so the strength of the checksum has security implications. Precedence TOP supports precedence by using three bits provided in IP headers of every packet. TP-4 provides a 2-byte priority option in Call Request packets. A 2-byte priority option in the ISO IP header is also under consideration. Currently, no implementations make use of precedence information (to support preemption, for example). There should be no impact, therefore, of changing from one protocol to the other. Type of Service The types of network service that can be requested via TOP and TP-4 are somewhat different. The impact seems minimal since few networks do anything with the type of service fields at present with the exception of DARPA's packet radio and satellite nets. This may become more important in the future.

OCR for page 13
Datagram Service TOP provides only reliable session service. A separate User Datagram Protocol (UDP) in the DOD architecture supports transaction or connection- less-type interaction where individual messages are exchanged. UDP is merely an addition of the port-addressing layer to the basic datagram ser- vice provided by IP. No delivery confirmation or sequencing is provided (although IP provides fragmentation and reassembly). The NBS TP-4 specification originally presented to the committee pro- vided unit-data-transfer service within the same protocol framework as sessions.~° This material has since been deleted to bring the NBS pro- posal into conformance with ISO work. A separate ISO datagram protocol similar to UDP has been defined and is expected to become a draft proposed standard in June 1984. Closing TOP provides a graceful closing mechanism that ensures that all data submitted by users are delivered before the connection is terminated. The NBS TP-4 provides a similar mechanism, but is not included in the ISO standard TP-4, which provides only an immediate disconnect service. Im- pact is significant if the ISO version is used because users would then have to add their own graceful termination handshake if desired. COMPARISON OF DOD AND ISO INTERNET LAYERS The internet protocols of DOD and ISO are much more similar to one another than the transport protocols. This is not surprising since the Defense Department's IP was used as the basis for the International Stan- dards Organization's IP. Some reformatting, renaming, and recoding of fields has been done. Hence not only are the services to higher layers essentially equivalent, but the protocol mechanisms themselves are also nearly identical. Due to the format changes, however, the two proto- cois are incompatible. I t should be noted that the IP itself forms only part of the internet layer. For clarity it should also be noted that the internet layer in ISO is considered to be the top sublayer within the network layer. In DOD, there is an additional Internet Control Message Protocol (ICMP) that deals with error conditions, congestion control, and simple routing updates to host computers. There is also a Gateway-to-Gateway Protocol (GOP) that deals with internet management and routing updates for gateways. In the ISO, only the IF itself has so far been considered, iONational Bureau of Standards, Specification of a~Transport Protocol for" Computer Communications, Vol.- 3, C1 ass 4 Protocol, ICST/HLNP-83-3, February 1983. — 18 —

OCR for page 13
while most error reporting, control, and routing functions are considered "management" functions that remain to be addressed in the future. The only significant differences in the IPs themselves are in the areas of addressing and error reporting. The DOD IP has a fixed-length, 32-bit source and destination addresses (identifying network and host) plus an 8-bit "protocol number" field to identify the higher-level pro- toco] for which the IP data is intended. The ISO IP has variable-length source and destination addresses whose format and content are not yet specified, although preliminary documentation indicates that ISO intends to support a similar level of addressing (network/host) in a more global context which would allow use of current DOD addresses as a subset. There is no equivalent of the DOD protocol number field, although possibly the tail of the variable-length ISO addresses could be used for this purpose. formats. Error reporting is provided within the ISO IP by means of a separate packet type, while the DOD provides more complete error- and status- reporting functions via the separate Internet Control Message Protocol (ICMP), including routing "redirect" messages to hosts that have sent datagrams via nonoptimal routes. In summary, from the functional point of view, DOD and ISO IP can be considered essentially equivalent with the provision that the ISO-address- ing scheme is suitably resolved. The absence of routing and control pro- cedures from the ISO internet layer means that additional procedures beyond IP would be needed to produce a complete, functioning, internet even if the ISO IP were adopted. It appears that the existing DOD ICMP and GGP or its successors could be modified to operate with the ISO IP with modest effort, but this requires further study and validation in an operational system. A table at the end of this chapter compares DOD and ISO IP Dacket COMPARISON ON THE BASIS OF PERFORMANCE, SECURITY, AND RISK Performance The performance of a transport protocol, such as TOP or TP-4, is a function of its implementation as well as its inherent design. Experience in implementing TOP and other proprietary protocols has demonstrated that implementation considerations usually dominate. This makes it difficult to compare protocols, since a wide range in efficiency of implementations is possible. Furthermore, there are a number of dimensions along which an implementation can be optimized. Despite the difficulties, protocol designers have developed several metrics for comparing transport protocols. These view protocol perfor- mance from a variety of perspectives, including (~) user response time, (2) throughput on a single connection, (3) network and host computer resource utilization. Protocol efficiency can also be significantly affected by the communications environment. Protocol efficiency must be

OCR for page 13
considered in a wide range of communications environments, including local area networks, satellite links, terrestrial links, and packet- switched networks. The critical algorithms most affecting protocol performance are those that perform end-to-end error control and end-to-end flow control. These algorithms affect the response time, throughput, and resource utilization of the protocol during the data transfer phase. The efficiency of the connection management procedures may also be important in applications involving frequent connections of brief duration. The committee compared the algorithms and message formats specified for each protocol for critical functions, including flow-and error-con- tro] and connection management. They concluded that since the two proto- cols were sufficiently similar there would be no significant difference in performance of TCP or TP-4 implementations of equal quality optimized for a given environment. The committee compared the error-and-flow-control algorithms of TCP/IP and TP-4. Both employ window-based techniques using large-sequence number spaces and both permit large window sizes. Their differences are minor. TCP performs its error-and-flow-control in units of octets, rather than the protocol data units employed by TP-4. This adds a small amount of overhead to TCP calculation in return for a finer control over host buffer memory. The committee did not consider the difference significant, assuming that appropriate buffer management strategies are implemented by transport and higher-level protocols. TP-4 employs more sophisticated techniques to ensure that flow-control information is reliably transmitted than does TCP. These more sophisticated techniques may reduce TP-4 pro- toco] overhead during periods of light load in some applications, possibly adding slightly more CPU load in other cases. The committee did not con- sider these effects significant. Both protocols employ a three-way handshake for establishing a trans- port connection. The differences between the TCP and TP-4 handshake are related to the addressing conventions employed for establishing connec- tions and do not affect protocol efficiency. In the common cases where a client process requests a connection to a server process, the TCP and TP-4 operations are equivalent. Both protocols permit a range of policy decisions in their implementa- tion. These include (~) selection of timer values used to recover from transmission errors and lost packets, (2) selection of window sizes at the receiver and transmitter, and (3) selection of protocol data unit sizes. Both permit substantial reduction in control-message overhead by expanding window sizes. Both permit credits to be granted "optimistic- ally," permitting receiver buffers to be shared over several transport connections and permitting credit reduction in the event of buffer con- gestion. Both permit optimizing protocol efficiency by delaying control- message traffic when it does not need to be transmitted, combining it with later data or control traffic. - 20 -

OCR for page 13
The most significant difference between TCP and TP-4 flow control derives from slight differences in expression of flow control at the transport layer service interface. TCP employs a stream mode] while TP-4 uses a message model. These two models are equivalent in function, how- ever, some higher-level applications protocols may be more naturally expressed in one model than the other. The committee considered the possibility that current ARPA protocols might require some adaptation to operate more efficiently with TP-4. For this reason the committee recommends that the DOD study the operation of current DOD higher-level protocols on TP-4 (recommendation 5, Chapter XI). Security The committee considered the impact of security requirements on trans- port protocols primarily and also on overall protocol hierarchies in the DOD, The American National Standards Institute (ANSI), and ISO. Based on the information the committee received, it finds that: The current TCP-4 and TP-4 are sufficiently equivalent in their security-redated properties that no significant tech- nical points would favor the use of one over the other. There is no technical impediment to their equivalent evolution over time in the security area. There are several risks in implementing a new protocol or protocol family. These include (~) fatal flaws in protocol design not easily rectified, (2) errors in protocol specification, (3) ambiguities in proto- co] specification, (4) errors in protocol implementation, (5) performance degradation due to inefficient implementation, (6) performance degrada- tion due to "untuned" implementation, and (7) performance degradation due to untuned application protocols. This list of risks comes from experience in implementing computer networks based on the DOD protocols and proprietary commercial protocols. Considering that it took more than ten years for the current TCP proto- cols to reach their current state of maturity and that the TP-4 protocol is only about two years old, the committee devoted considerable attention to the maturity of TP-4. Fatal Flaws in Protocol Design Early ARPANET protocols had a number of "fatal" design errors that resulted in deadlocks or other serious system failures. Commercial net- works had similar problems in early design phases. The committee con- sidered the possibility that TP-4 could suffer from similar faults and concluded that this was unlikely. TP-4 employs design techniques similar to those of TCP and proprietary transport protocols. The faults encoun- tered in the ARPANET are now well known. Indeed, the state of the art in ~ 21 -

OCR for page 13
transport protocol design is now quite mature. The developers of the TP-4 protocol were familiar with the earlier protocols and their problems. Errors and Ambiguities in Protocol Specification . . . Early in the development of TP-4, NBS developed a formal protocol specification and a test environment based on this specification. A protocol implementation can be partially compiled automatically from the formal specification. Other implementations can be tested against this master implementation. The NBS protocol laboratory was used to debug the formal specification of TP-4 and is currently being used to certify other implementations of TP-4. The laboratory has also developed and employed tools to analyze the specification for possible problems. The existence of this laboratory and the results obtained to date led the committee to conclude that there is no substantial risk associated with the TP-4 protocol specification. In contrast TCP has only recently received a formal specification. To the committee's knowledge most existing TCP implementations predate the formal TCP specification and have not been derived from the formal specification. In the committee's opinion the formal TCP specification is likely to have more bugs or ambiguities than the TP-4 specification. At the present time NBS has developed the only formal specification for ISO TP-4. ISO is currently developing standards for formal specifi- cation techniques that are similar to those used by NBS. When these specifications are complete ISO wild update the TP-4 specification to include a formal description. In translating the current informal ISO specification into the formal specification there is a risk that the ISO specification may be changed such that it is no longer consistent with the current NBS specification. The National Bureau of Standards is playing a key role in developing the ISO formal specification techniques and formal specification. It plans to generate automatically an imple- mentation of the ISO formal specification and verify it against the NBS specification using the NBS test tools. In the committee's opinion this makes the risk of unintentional changes in the ISO specification quite ~ owe. One possible risk remains. The ISO specification for TP-4 that was approved is an informal document subject to the ambiguities of informal protocol specifications. The formalization may remove ambiguities that have gone undetected and that were the basis of its approval. It is conceivable that once these ambiguities are exposed, the current consensus for TP-4 may dissolve. The committee considers this risk to be very low. The areas of ambiguity in protocol specifications are typically only of concern to protocol implementors. The current protocol implementors through much of the world are typically using the NBS formal specifica- tions as a basis of their implementations of TP-4 and have access to the NBS test tools for certifying their implementations. In the event of a possible conflict, the majority of implementors could be expected to sup- port resolution of ambiguities in favor of the current NBS formal specifi- cation, making it unlikely that ISO would approve an alternate resolution. - 22 - ,

OCR for page 13
Errors in Protocol Implementation Several factors influence the likelihood of errors in a protocol implementation. These include the complexity of the protocol, quality of the protocol specification, the experience of the implementors, and the availability of test tools. Based on the availability of the NBS test tools and formal protocol specification for TP-4, the committee did not see any significant risk of errors in implementing TP-4. Performance Issues The largest risk in implementing TP-4 concerns the performance of the implementations. This risk is not inherent in the protocol as specified, but is present in new implementations of any transport protocol. Experi- ence has shown that performance can often be improved by a factor of two or more by careful attention to implementation details and careful perfor- mance measurement and tuning. The committee considered it likely that some initial implementations of TP-4 will have significantly lower perfor- mance than the current mature implementations of TOP. Evidence to support this conclusion may be found in data supplied by the DOD which show a wide range of performance of TOP implementations. Some members of the committee expressed the belief that over the long term, TP-4 will afford better performance due to widespread commercial support. Vendors will be highly motivated to optimize performance of their TP-4 implementations, since a large number of users will benchmark implementation performance. Many individuals will become familiar with implementations of TP-4 and with configuring and operating networks based on TP-4. Initially, this expertise will be found in organizations devel- oping TP-4 implementations and installation. The committee believes that the largest performance risks are short term. The performance of existing DOD high-level protocols may be affected by subtle differences between TP-4 and TOP interfaces. High- leve] DOD implementations and protocols may require retuning to attain some high-level efficiency using TP-4. Another short-term risk is potential lack of experience in configuring and operating TP-4-based networks. The committee believes that a program of testing and devel- opment would minimize these risks, ensuring that the current high-level DOD protocols run effectively on TP-4-based networks. There is a possibility that the equivalent, but different, protocol mechanisms and interfaces in TP-4 may manifest some undesirable behavior that is not expected and which cannot easily be removed by tuning. In this event ISO may find it necessary to make some modifications to TP-4. It is unlikely that such problems will be serious enough to prevent an early transition to TP-4. If such problems are discovered, it is expected that they can be handled through the normal standards process of periodic enhancement. A number of proprietary commercial networking protocols are similar in operation to TP-4 and do not have serious performance problems. Any enhancements that may be desirable can probably be added to TP-4 in a compatible fashion, permitting interoperation of enhanced and unenhanced implementations. - 23 -

OCR for page 13
TABLE: Comparison of DOD and ISO IP Packet Formats DOD ISO (not in correct order) _ _ _ _ _ Protocol version: 4 bits Header Length (in 32-bit words): 4 bits Type of service: ~ bits (includes 3-bit Precedence) Total Length: 16 bits ID: 16 bits Don't Fragment flag More Fragments flag Fragment offset: 13 bits Time to live (see): ~ bits Protocol number: ~ bits Header checksum: l6 bits (provided by subnet layer) (in ICMP) Source address: 32 bits Dest. address: 32 bits OPTIONS: NOR, Security, Source Route, Record Route, Stream ID, Time Stamp DATA Version: ~ bits "Header] Length (in bytes): ~ bits Quality of service**: ~ bits Precedence**: ~ bits Segment Length: 16 bits Data Unit ID*: 16 bits Segmentation Permitted flag More Segments flag Segment offset*: 16 bits Lifetime (.5 see): ~ bits Header checksum: l6 bits Network Layer Protocol ID: ~ bits tGenerate3 Error flag Type: 5 bits Total Length*: 16 bits Source address length: ~ bits Source address: var. Dest. address length: 8 bits Dest. address: var. OPTIONS: Padding, Security Source Route, Record Route, Quality of service, Precedence, Error reason (only for error type) DATA * only present if segmentation 1s 1n use ** in options - 24 -