Internet Info 1997 December

home *** CD-ROM | disk | FTP | other *** search

/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ien / ien-186 < prev next >

Wrap

Text File | 1988-12-02 | 153KB | 4,040 lines

IEN 186 1 June 1981 PROPOSED DCEC IP SPECIFICATION prepared by Mary M. Bernstein System Development Corporation 2500 Colorado Avenue Santa Monica, CA 90406 (213) 820-4111 Abstract This document specifies the Internet Protocol (IP) which supports the interconnection of communication subnetworks. The document includes an introducion to IP with a model of operation, a defin- ition of services provided to users, and a description architec- tural and environmental requirements. The protocol service interfaces and mechanisms are specified using an abstract state machine model. System Development Corporation 1 June 1981 IEN 186 FOREWORD This document has been submitted to the DCEC for consideration as a standard specification of the Internet Protocol. The document incorporates the organization and specification techniques presented in the DCEC Protocol Specification Guidelines. This is a preliminary version; a revised version is to be released in December 1981. Any comments regarding completeness and con- sistency or suggestions for improvement of this document are wel- comed. Mary M. Bernstein System Development Corporation 2500 Colorado Avenue Santa Monica, CA 90406 (213) 820-4111 ARPANET: brnstein@dti CONTENTS 1. OVERVIEW................................................. 1 1.1 Scenario............................................ 4 2. DESCRIPTION OF SERVICES PROVIDED TO UPPER LAYERS......... 6 2.1 Datagram Service.................................... 6 2.2 Virtual Network Services............................ 6 2.3 Error Reporting Service............................. 7 3. UPPER LAYER SERVICE/INTERFACE SPECIFICATION.............. 8 3.1 Interaction Primitives.............................. 8 3.1.1 Service Request Primitives 8 3.1.2 Service Response Primitives 9 3.2 Abstract Machine Definition of Upper Level Services and Interaction Discipline.......................... 10 3.2.1 Machine Identifier 10 3.2.2 State Diagram 11 3.2.3 State Vector 11 3.2.4 State Machine Data Structures 11 3.2.5 Event List 12 3.2.6 Events and Actions 12 4. DESCRIPTION OF LOWER LAYER SERVICE REQUIREMENTS.......... 14 4.1 Data Transfer....................................... 14 4.2 Error Reporting..................................... 14 5. LOWER LAYER SERVICE/INTERFACE SPECIFICATION.............. 15 5.1 Interaction Primitives.............................. 15 5.1.1 Service Request Primitives 15 5.1.2 Service Response Primitives 16 5.2 Abstract Machine Definition of Lower Level Services and Interaction Discipline.......................... 16 5.2.1 Machine Identifier 16 5.2.2 State Diagram 17 5.2.3 State Vector 17 5.2.4 State Machine Data Structures 17 5.2.5 Event List 17 5.2.6 Events and Actions 18 6. MECHANISM SPECIFICATION.................................. 19 6.1 Overview of IP Mechanisms........................... 19 6.1.1 Routing Mechanism 19 6.1.2 Fragmentation and Reassembly 21 6.1.3 Checksum 22 6.1.4 Time To Live 23 6.1.5 Type of Service 23 6.1.6 Data Options 23 6.1.7 Error Report Datagrams 24 6.2 Internet Protocol Header Format..................... 26 6.2.1 Version 26 6.2.2 Internet Header Length 26 6.2.3 Type of Service 27 6.2.4 Total Length 27 6.2.5 Identification 27 6.2.6 Flags 28 6.2.7 Fragment Offset 28 6.2.8 Time to Live 28 6.2.9 Protocol 28 6.2.10 Header Checksum 29 6.2.11 Source Address 29 6.2.12 Destination Address 29 6.2.13 Padding 29 6.2.14 Options 29 6.2.15 Specific Option Definitions 31 6.2.16 Error Report Datagrams 33 6.3 Extended State Machine Representation............... 35 6.3.1 State Machine Identification 35 6.3.2 State Machine Diagram 35 6.3.3 State Vector 36 6.3.4 State Machine Data Structures 37 6.3.5 Event List 39 6.3.6 State Machine Events and Actions 39 7. EXECUTION ENVIRONMENT REQUIREMENTS....................... 72 7.1 Inter-process communication......................... 72 7.2 Timing.............................................. 72 8. BIBLIOGRAPHY............................................. 73 9. GLOSSARY................................................. 74 System Development Corporation 1 June 1981 -1- IEN 186 1. OVERVIEW This document specifies the Internet Protocol (IP) which supports the interconnection of communication subnetworks. The document introduces the Internet Protocol's role and purpose, defines the services provided to users, and specifies the mechanisms needed to support those services. This document also defines the ser- vices required of the lower protocol layer, describes the upper and lower interfaces, and outlines the operating system primi- tives needed for implementation. In addition, a glossary of terms and a set of appendices discussing certain aspects of IP are included. The reader is assumed to be familiar with the DCEC Architecture Report which presents a protocol architecture model for DoD communication services[1]. This document incorporates the organization and specification techniques presented in the DCEC Protocol Specification Guidelines[2]. The Internet Protocol is designed to interconnect packet-switched communication subnetworks to form an internetwork. IP transmits blocks of data, called internet datagrams, from sources to desti- nations throughout the internet. Sources and destinations are hosts located on either the same subnetwork or connected subnet- works. IP is purposely limited in scope to provide the basic functions necessary to deliver a block of data. Each internet datagram is an independent entity unrelated to any other internet datagram. IP does not create connections or logical circuits. IP has no mechanisms to promote data reliability, flow control, sequencing, or other services commonly found in host-to-host pro- tocols. +------+ +-----+ +------+ +-----+ |Telnet| | FTP | | EFTP | ... | | +------+ +-----+ +------+ +-----+ | | | | +-----+ +-----+ +-----+ | TCP | | UDP | ... | | +-----+ +-----+ +-----+ | | | +--------------------------------+ | HOST INTERNET PROTOCOL | +--------------------------------+ | +------------------------+ | Subnetwork Protocol | +------------------------+ 1. Example Host Protocol Hierarchy This document specifies a host IP. In the DoD architectural model, a host IP resides between transport layer and the lower System Development Corporation 1 June 1981 -2- IEN 186 network sublayer in each internet host. In each gateway, a site interconnecting two or more subnets, an IP resides above two or more subnetwork entities. In a gateway, IP is closely coupled to the Gateway to Gateway Protocol (GGP) to form a gateway IP. A gateway IP supports many of the same functions as a host IP, but provides additional services such as maintenance of current internet topology data. Throughout the remainder of the docu- ment, a host IP is simply referred to as IP. GATEWAY INTERNET PROTOCOL +-----------------------------------+ | Gateway-Gateway Protocol | +- - - - - - - - - - - - - - - - - -+ | Internet Protocol | +-----------------------------------+ | | | +---------+ +---------+ +---------+ |subnet 1 | |subnet 2 | ... |subnet i | | protocol| | protocol| | protocol| +---------+ +---------+ +---------+ | | | ARPANET local net public net 2. Example Gateway Protocol Hierarchy A protocol in an upper layer passes data to IP for delivery. IP packages the data as an internet datagram and passes it to the local subnetwork protocol for transmission across the local sub- net. If the destination host is on the local subnet, IP sends the datagram through the subnet directly to that host. If the destination host is on a connected subnet, IP sends the datagram to an appropriate gateway. The gateway, in turn, sends the datagram through the next subnet to the destination host, or to another gateway. Thus, datagrams move from one IP module to another through an interconnected set of subnetworks until the destination is reached. The sequence of IP modules handling the datagram in transit is called the gateway route. The gateway route is dis- tinct from the lower level node-to-node route supplied by a par- ticular subnetwork. The gateway route is based on the destina- tion internet address. The IP modules share common rules for interpreting internet addresses to perform internet routing. In transit, datagrams may traverse a subnetwork whose maximum packet size is smaller than the size of the datagram. To handle this, IP provides fragmentation and reassembly mechanisms. The gateway at the smaller-packet subnet fragments the original datagram into pieces, called datagram fragments, small enough for transmission. The IP module in the destination host reassembles System Development Corporation 1 June 1981 -3- IEN 186 the datagram fragments to reproduce the original datagram. IP can support a diverse set of upper layer protocols (ULPs). A transport protocol with real-time requirements, such as the Net- work Voice Protocol (NVP), can make use of IP's datagram service directly. A transport protocol providing ordered reliable delivery, such as TCP, can build additional mechanisms on top of IP's basic datagram service. Also, IP's delivery service can be customized in some ways to suit the special needs of an upper layer protocol. For example, a pre-defined gateway route, called a source route, can be supplied for an individual datagram. Each IP module forwards the datagram according to the source route instead of using only the independent routing mechanism. The Internet Protocol shares a common history with the Transmis- sion Control Protocol, first described in [3]. Later, IP and TCP were separated and specified as two distinct protocols in [4] and [5]. A wide range of technical, legal, and political issues associated with subnetwork interconnection is presented in [6]. Alternative approaches to internetting, including the CCITT Recommendation X.75 and the PUP architecture, are introduced and compared in in [7], [8], and [9]. Certain aspects of fragmenta- tion and routing are are discussed in [10], and [11]. [12] and [13] contain current address mappings and assigned numbers used in network protocol implementations. System Development Corporation 1 June 1981 -4- IEN 186 1.1 Scenario The following scenario illustrates the model of operation for transmitting a datagram from one upper layer protocol to another. The scenario is purposely simple so that IP's basic operation is not obscured by the details of interface parameters or header fields. A ULP in host A is to send data to a peer protocol in host B on another subnetwork. In this case, the source and destination hosts are on subnetworks directly connected by a gateway. HOST A HOST B ---------------- ------------------ | Sending | | Receiving | | Upper Layer | | Upper Layer | | Protocol | GATEWAY | Protocol | | \ | ------------------ | / | | IP Module | | IP Module | | IP Module | | \ | | / \ | | / | | SNP-1 | | SNP-1 SNP-2 | | SNP-2 | ---------------- ------------------ ------------------ \ / \ / Local Subnet 1 Local Subnet 2 Basic Model of Operation a. The sending ULP passes its data to the IP module, along with the destination internet address and other parameters. b. The IP module prepares an IP header and attaches the ULP's data to form an internet datagram. Then, the IP module determines a local subnetwork address from the destination internet address. In this case, it is the address of the gateway to the destination subnetwork. The internet datagram along with the local subnet address is passed to the local subnetwork protocol (abbreviated as SNP). c. The SNP creates a local subnetwork header and attaches it to the datagram forming a subnetwork packet. The SNP then transmits the packet across the local subnet. System Development Corporation 1 June 1981 -5- IEN 186 <========= subnetwork packet =========> +------+---------+---------/ /--------+ | * | * | * | +--:---+----:----+----:---/ /---------+ : : : : : : : : ULP data : IP header : subnetwork header d. The packet arrives at the gateway connecting the first and second subnetworks. The SNP of the first subnet strips off the local subnetwork header and passes the remainder to the IP module. e. The IP module determines from the destination internet address in the IP header that the datagram is intended for a host in the second subnet. The IP module then derives a local subnetwork address for the destination host. That address is passed along with the datagram to the SNP of the second subnetwork for delivery. f. The second subnet's SNP builds a local subnetwork header and appends the datagram to form a packet for the second subnet- work. That packet is transmitted across the second subnet to the destination host. g. The SNP of the destination host strips off the local subnet- work header and hands the remaining datagram to the IP module. h. The IP module determines that the datagram is bound for a ULP within this host. The data portion of the datagram, the source internet address, and other option parameters are passed to the ULP. Delivery of data across the internet is complete. System Development Corporation 1 June 1981 -6- IEN 186 2. DESCRIPTION OF SERVICES PROVIDED TO UPPER LAYERS This section describes the services offered by the Internet Pro- tocol to upper layer protocols (ULPs). The goals of this section are to provide the motivation for protocol mechanisms and a definition of the functions provided by this protocol. The services provided by IP are: o intact internet datagram service o virtual network service o error reporting service A description of each service follows. 2.1 Datagram Service The Internet Protocol shall provide a datagram service between homogeneous upper layer protocols in an internet environment. A datagram service is characterized by data delivery to the desti- nation with non-zero probability; some data may possibly be lost. Also, a datagram service does not necessarily preserve the sequence in which data is supplied by the source upon delivery at the destination. IP shall deliver received data to a destination ULP in the same form as sent by the source ULP. IP shall discard datagrams when insufficient resources are available for processing. IP does not detect datagrams lost or discarded by the subnetwork layer. As part of the delivery service, IP insulates upper layer proto- cols from subnetwork specific characteristics. For example, IP maps internet addresses supplied by ULPs into local addresses used by the local subnetwork. Also, IP hides any packet-size restrictions of subnetworks along the transmission path within the internet. 2.2 Virtual Network Services IP shall provide to upper layer protocols the ability to select virtual network service parameters. IP shall provide a standard command set for the ULPs to indicate the services desired. Thus, the ULPs can tune certain properties of IP and the underlying subnetworks to customize the transmission service according to their needs. The virtual network parameters fall into two categories: service quality parameters and service options. Service quality System Development Corporation 1 June 1981 -7- IEN 186 parameters influence the transmission service provided by the subnetworks; service options are additional functions provided by IP. A brief description of each follows: o Service Quality Parameters - Precedence : attempts preferential treatment for high importance datagrams - Transmission Mode : datagram vs. stream. Stream mode attempts to minimize delay and delay dispersion through reservation of network resources - Reliability : attempts to minimize data loss and error rate - Speed : attempts prompt delivery - Resource Tradeoff : indicates relative importance of speed vs. reliability. o Service Options - Security Labelling : identifies datagram for compart- mented hosts - Source Routing : selects set of gateway IP modules to visit in transit - Route Recording : records gateway IP modules encountered in transit - Stream Identification : names reserved resources used for stream service - Time Stamping : records time information - Don't Fragment : marks a datagram as an indivisible unit 2.3 Error Reporting Service IP shall provide error reports to the upper layer protocols indi- cating errors detected in providing the above services. In addition, certain errors detected by lower layer protocols shall be passed to the ULPs. These reports indicate several classes of errors including invalid arguments, insufficient resources, and transmission errors. The errors that IP must report to ULPs have not been defined. IP's error reporting responsibilities need further examination. System Development Corporation 1 June 1981 -8- IEN 186 3. UPPER LAYER SERVICE/INTERFACE SPECIFICATION This section specifies the IP services provided to upper layer protocols and the interface through which these services are accessed. The first part defines the interaction primitives and interface parameters for the upper interface. The second part contains the abstract machine specification of the upper layer services and interaction discipline. 3.1 Interaction Primitives An interaction primitive defines the purpose and content of information exchanged between two protocol layers. Primitives are grouped into two classes based on the direction of informa- tion flow. Information passed downward, in this case from a ULP to IP, is called a service request primitive. Information passed upward, in this case from IP to a ULP, is called a service response primitive. Interaction primitives need not occur in pairs. That is, a request does not necessarily elicit a "response"; a "response" may occur independently of a request. The information associated with an interaction primitive falls into two categories: parameters and data. The parameters describe the data and indicate how the data is to be treated. The data is not examined or modified. The format of the parame- ters and data is implementation dependent and therefore not specified. A given IP implementation may have slightly different interaction primitives imposed by the execution environment or system design factors. In those cases, the primitives can be modified to include more information or additional primitives can be defined to satisfy system requirements. However, all IPs must provide at least the interaction primitives specified below to guarantee that all IP implementations can support the same protocol hierar- chy. 3.1.1 Service Request Primitives A single service request primitive supports IP's datagram ser- vice, the SEND primitive. 3.1.1.1 SEND The SEND primitive contains complete control information for each unit of data to be delivered. IP accepts in a SEND at least the following information: o source address - internet address of ULP sending data System Development Corporation 1 June 1981 -9- IEN 186 o destination address - internet address of ULP to receive data o protocol - name of the recipient ULP o type of service indicators - relative transmission quality associated with unit of data - precedence - one of five levels : (P1, P2, P3, P4, P5 ) where P1 <= P2 <= P3 <= P4 <= P5 - reliability - one of four levels : (R1, R2, R3, R4) where R1 <= R2 <= R3 <= R4 - speed - one of two levels : (S1, S2) where S1 <= S2 - resource trade-off - speed or reliability : (T1, T2) where T1 = speed, T2 = reliability - transmission mode - stream or datagram : (M1, M2) where M1 = stream, M2 = datagram o identifier - value distinguishing this portion of data from others sent by this ULP. o don't fragment indicator - flag showing whether IP can fragment data to accomplish delivery o time to live - value in seconds indicating maximum lifetime of data within the internet o data length - size of data being transmitted o option data - options requested by ULP from following list: security, source routing, return routing, stream identification, or time stamp. (See section 6.2.14.) o data - present when data length is greater than zero. 3.1.2 Service Response Primitives A single service response primitive supports IP's datagram ser- vice, the DELIVER primitive. 3.1.2.1 DELIVER The DELIVER primitive contains the data passed by a source ULP in a SEND, along with addressing, quality of service, and option information. IP passes in a DELIVER at least the following information: o source address - internet address of sending ULP System Development Corporation 1 June 1981 -10- IEN 186 o destination address - internet address of the recipient ULP o protocol - name of recipient ULP as supplied by the sending ULP o type of service indicators - relative transmission quality associated with unit of data - precedence - one of five levels : (P1, P2, P3, P4, P5 ) where P1 <= P2 <= P3 <= P4 <= P5 - reliability - one of four levels : (R1, R2, R3, R4) where R1 <= R2 <= R3 <= R4 - speed - one of two levels : (S1, S2) where S1 <= S2 - resource trade-off - speed or reliability : (T1, T2) where T1 = speed, T2 = reliability - transmission mode - stream or datagram : (M1, M2) where M1 = stream, M2 = datagram o data length - number of octets of received data (possibly zero) o option data - options requested by source ULP from following list: security, source routing, return routing, stream identifi- cation, or time stamps. (See section 6.2.14.) o data - present when data length is greater than zero. In addition, a DELIVER may contain error reports from IP either together with parameters and data listed above, or, independently of that information. This area needs further examination and definition. 3.2 Abstract Machine Definition of Upper Level Services and Interaction Discipline The abstract machine defines the behavior of the entire service machine from the perspective of the upper layer protocol. An abstract machine definition is composed of a machine identifier, a state diagram, a state vector, a set of data structures, an event list, and an events and actions correspondence. 3.2.1 Machine Identifier Each upper interface state machine is uniquely identified by the four values: o source address o destination address System Development Corporation 1 June 1981 -11- IEN 186 o protocol o identifier 3.2.2 State Diagram The upper interface state machine has a single state which never changes. No diagram is needed. 3.2.3 State Vector The upper interface state machine has a single state which never changes. No state vector is needed. 3.2.4 State Machine Data Structures No data structures are used for the upper interface state machine. However, the following abbreviations are used to refer to parameters of the interaction primitives: S = source internet address D = destination internet address P = protocol identifier TOS = type of service where p(i) = one of the precedence levels (P1, P2, P3, P4, P5) (Note: read p(i) as "p sub i") r(i) = one of the reliability levels (R1, R2, R3, R4) s(i) = one of the speed levels (S1, S2) t(i) = one of the resource trade-offs (T1, T2) m(i) = one of the transmission modes (M1, M2) ID = data identifier TTL = time to live value DF = don't fragment flag Opts = the set of desired options including zero or more of the following: sr = source route rr = return route sl = security labelling sid = stream identifier its = internet timestamp sts = satellite timestamp Data = data unit for delivery L = length of data unit t = time of event initiation N = time elapsed during transmission System Development Corporation 1 June 1981 -12- IEN 186 3.2.5 Event List The events are drawn from the interaction primitives specified in section 3.1 above. An event is composed of a service primitive and an abstract timestamp to indicate the time of event initia- tion. The event list: 1. SEND( S, D, P, TOS(p(i), r(i), s(i), t(i), m(i)), ID, TTL, DF, Opts(sr, rr, sl, sid, its, sts), Data, L) at time t 2. NULL - Although no service request is issued by ULP, certain conditions within IP or lower layers produce a service response. 3.2.6 Events and Actions The following section defines the set of possible actions eli- cited by each event. EVENT = SEND( S, D, P, TOS(p(i), r(i), s(i), t(i), m(i)), ID, TTL, DF, Opt(sr, rr, sl, sid, its, sts), Data, L ) at time t Actions: 1. DELIVER Data at time t+N to protocol P at destination D with all of the following properties: a. The time elapsed during data transmission satisfies the time-to-live limit, i.e. N <= TTL. b. The quality of data transmission is at least equal to the relative levels specified by TOS(p(i), r(i), s(i), t(i), m(i)). c. if (DF = TRUE) then IP fragmentation has not occurred in transit. d. if (Opts contains sr) then Data has visited in transit at least the nodes named by source route provided in SEND. e. if (Opts contains rr) then the list of nodes visited in transit is delivered with Data. f. if (Opts contains sl) then the security label is delivered with Data. g. if (Opts contains sid) System Development Corporation 1 June 1981 -13- IEN 186 then the stream identifier is delivered with Data h. if (Opts contains its) then the internet timestamp is delivered with Data j. if (Opts contains sts) then the satellite timestamp is delivered with Data OR, 2. DELIVER to protocol P at source S indicating one of the following error conditions: a. destination D unreachable b. protocol P unreachable c. if (DF = TRUE) then fragmentation needed but prohibited d. if (Opts contains any option) then parameter problem with option. OR, 3. no action EVENT = NULL Actions: 1. DELIVER to protocol P at source S indicating the following error condition: a. error conditions in subnet layer System Development Corporation 1 June 1981 -14- IEN 186 4. DESCRIPTION OF LOWER LAYER SERVICE REQUIREMENTS This section describes the minimal services required of the sub- network layer. The services required are: o transparent data transfer between hosts within a subnetwork o error reporting A description of each service follows. 4.1 Data Transfer The subnetwork layer must provide a transparent data transfer between hosts within a single subnetwork. Only the data to be delivered, and the necessary control and addressing information should be required as input from IP. Intranet routing and sub- network operation shall be handled by the subnetwork layer itself. The subnetwork need not be a reliable communications medium. Data should arrive with non-zero probability at a destination. Data may not necessarily arrive in the same order as it was sup- plied to the subnetwork layer, nor is data guaranteed to arrive error free. 4.2 Error Reporting The subnetwork layer shall provide reports to IP indicating errors from the subnetwork and lower layers as feasible. The specific error requirements of the subnetwork layer have not been defined. This area needs further examination. System Development Corporation 1 June 1981 -15- IEN 186 5. LOWER LAYER SERVICE/INTERFACE SPECIFICATION This section specifies the minimal subnetwork protocol services required by IP and the interface through which those services are accessed. The first part defines the interaction primitives and their parameters for the lower interface. The second part con- tains the abstract machine specification of the lower layer ser- vices and interaction discipline. 5.1 Interaction Primitives An interaction primitive defines the purpose and contents of information exchanged between two protocol layers. Two kinds of primitives, based on the direction of information flow, are defined. Service requests pass information downward; service responses pass information upward. These primitives need not occur in pairs, nor in a synchronous manner. That is, a request does not necessarily elicit a "response"; a "response" may occur independently of a request. The information associated with an interaction primitive falls into two categories: parameters and data. The parameters describe the data and indicate how the data is to be treated. The data is not examined or modified. The format of interaction primitive information is implementation dependent and so is not specified. A given IP implementation may have slightly different interfaces imposed by the nature of the subnetwork or execution environment. Under such circumstances, the primitives can be modified to include more parameters or include additional primitives can be defined. However, all IPs must provide at least the interface specified below to guarantee that all IP implementations can sup- port the same protocol hierarchy. 5.1.1 Service Request Primitives A single service request primitive is required from the SNP, a SNP_SEND primitive. 5.1.1.1 SNP_SEND The SNP_SEND contains an IP datagram, a destination, and parame- ters describing the desired transmission quality. The SNP receives in an SNP_SEND at least the following information: o local destination address - local subnetwork address of desti- nation host or gateway o type of service indicators - relative transmission quality associated with the datagram System Development Corporation 1 June 1981 -16- IEN 186 - precedence - one of five levels : (P1, P2, P3, P4, P5 ) where P1 <= P2 <= P3 <= P4 <= P5 - reliability - one of four levels : (R1, R2, R3, R4) where R1 <= R2 <= R3 <= R4 - speed - one of two levels : (S1, S2) where S1 <= S2 - resource trade-off - speed or reliability : (T1, T2) where T1 = speed, T2 = reliability - transmission mode - stream or datagram : (M1, M2) where M1 = stream, M2 = datagram o length - size of the datagram o datagram 5.1.2 Service Response Primitives One service request primitive is required to support IP's datagram service, the SNP_DELIVER primitive. 5.1.2.1 SNP_DELIVER The SNP_DELIVER contains only a datagram which is an independent entity containing all the information needed by IP. An IP receives in an SNP_DELIVER at least the following information: o datagram In addition, a SNP_DELIVER may contain error reports from the SNP, either together with a datagram or independently of one. This area needs further examination and definition. 5.2 Abstract Machine Definition of Lower Level Services and Interaction Discipline The abstract state machine defines the behavior of the entire service machine with respect to the lower layer protocol. An abstract machine definition is composed of a machine identifier, a state diagram, a state vector, a set of data structures, an event list, and an events and actions correspondence. 5.2.1 Machine Identifier Each lower interface state machine is uniquely identified by the four values: System Development Corporation 1 June 1981 -17- IEN 186 o source address o destination address o protocol o identification 5.2.2 State Diagram The lower interface state machine has a single state which never changes. No diagram is needed. 5.2.3 State Vector No state vector is needed for the lower interface state machine. 5.2.4 State Machine Data Structures No data structures are used for the lower interface state machine. However, the following abbreviations are used to refer to parameters of the interaction primitives: LD = local subnetwork destination address TOS = type of service where p(i) = one of the precedence levels (P1, P2, P3, P4, P5) (Note: read p(i) as "p sub i") r(i) = one of the reliability levels (R1, R2, R3, R4) s(i) = one of the speed levels (S1, S2) t(i) = one of the resource trade-offs (T1, T2) m(i) = one of the transmission modes (M1, M2) L = datagram length 5.2.5 Event List The events are drawn from the interactions primitives specified in section 5.1 above. An event is composed of a service primi- tive with its parameters and data. 1. SNP_SEND( LD, TOS(p(i), r(i), s(i), t(i), m(i)), L, Datagram) 2. NULL - Although IP issues no service request, certain condi- tions within the subnet layer elicit a service response. System Development Corporation 1 June 1981 -18- IEN 186 5.2.6 Events and Actions The following section defines the set of possible actions eli- cited by each event. EVENT = SNP_SEND( LD, TOS(p(i), r(i), s(i), t(i), m(i)), L, Datagram) ACTIONS: 1. SNP_DELIVER Datagram to IP at local destination LD with all of the following properties: a. The quality of data transmission is at least equal to the relative levels specified by TOS(p(i), r(i), s(i), t(i), m(i)). OR, 2. no action EVENT = NULL ACTIONS: 1. SNP_DELIVER to IP indicating the following error condition: a. error conditions within the subnet layer System Development Corporation 1 June 1981 -19- IEN 186 6. MECHANISM SPECIFICATION This section defines the mechanisms supporting the services offered by IP. The first subsection motivates the specific mechanisms chosen and discusses the underlying philosophy of those choices. The second subsection defines the format and use of the IP header fields. The last subsection specifies the peer protocol interactions with a state machine model. 6.1 Overview of IP Mechanisms The IP mechanisms are motivated by the IP services, described in section 2: o intact datagram delivery service o virtual network service o error reporting service Each service could be supported by any of a set of mechanisms. The selection of mechanisms is guided by design standards includ- ing simplicity, generality, flexibility, and efficiency. The following mechanism descriptions identify the service or services supported, discuss the design criteria used in selection, and explain how the mechanisms work. 6.1.1 Routing Mechanism IP contains an adaptive routing mechanism to support the delivery service. The routing mechanism uses the internet addressing scheme and internet topology data to direct datagrams along the best path between source and destination. The mechanism provides routing options for ULPs needing the flexibility to select or record routes and routing information. A distinction is made between names, addresses, and routes. A name indicates the object sought independently of physical loca- tion. An address indicates where the object is. A route indi- cates how to get there. It is the task of the upper layer proto- cols to map from names to addresses. The internet protocol maps from internet addresses to local subnet addresses to perform routing through the internet. It is the task of lower layer pro- tocols to map from the local subnet addresses to routes through local subnetworks. Internet addresses have a fixed length of four octets (32 bits). An internet address begins with a one octet network number and ends with a three octet REST field. The REST field usually con- tains a local subnetwork address. However, alternate schemes for use of this field can extend the address range to allow more sub- networks on the internet. System Development Corporation 1 June 1981 -20- IEN 186 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+/ /+-+-+-+-+ | NETWORK | REST | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-/ /-+-+-+-+-+ The 24-bit REST field, assigned by each local subnetwork, should allow for a single physical host to act as several distinct internet hosts. That is, there should exist a mapping between internet host addresses and subnetwork/host interfaces that allows several internet addresses to correspond to one interface. A host should be allowed to have several physical interfaces (i.e. multi-homing) and to treat the datagrams from several of them as if they were all addressed to a single host. To route a datagram, an IP module examines the NETWORK field of the internet address indicating the destination for the datagram. If the network number is the same as the IP module's subnetwork, the module uses the REST field of the internet address to derive the local subnet address of the destination host. If the network number doesn't match, the module determines a local subnet address of a gateway on the best path to the destination subnet- work. In turn, the gateway IP module derives the next local sub- net address to either a host or gateway. In this way, the datagram is relayed through the internet to the destination host. In a static environment, the routing algorithm is straightfor- ward. However, internet topology tends to change due to hardware or software failure, host availability, or heavy traffic load conditions. So, each host and gateway IP along the gateway route also uses its current knowledge of internet topology to make routing decisions. 6.1.1.1 Routing Options IP provides a mechanism, called source routing, to override the gateway's independent routing decisions. This mechanism allows an upper layer protocol to influence the gateway route a datagram traverses. The ULP can pass a list of internet addresses, called a source route, along with a datagram. Each address on the list is an intermediate destination. The source IP module uses its normal routing mechanism to transmit the datagram to the first address on the list. At that address, the first entry is removed from the list, and the next address becomes the datagram's desti- nation. When the last entry of the list is removed, the normal destination address field becomes the final destination. For testing or diagnostic purposes, a ULP can acquire a datagram's gateway route by using a mechanism called return rout- ing. The sending ULP indicates that a record of the route is to be accumulated in transit. Then, as gateway IP module on the System Development Corporation 1 June 1981 -21- IEN 186 gateway route relays the datagram, it adds its address to the return list. The destination ULP receives the original datagram along with the return list containing the gateway route. 6.1.2 Fragmentation and Reassembly IP contains a fragmentation mechanism to break a large datagram into smaller datagrams. This is a more general solution for overcoming differences between subnetwork capacity than legislat- ing a restrictive datagram size small enough for every subnetwork on the internet. This mechanism can be overriden using the "don't fragment" option to prevent fragmentation. IP also con- tains a reassembly mechanism which reverses the fragmentation to enable delivery of intact data portions. When an IP module encounters a datagram that is too big to be transmitted through a subnetwork, it applies its fragmentation mechanism. First, the module divides the data portion of the datagram into two or more pieces. The data must be broken on 8- octet boundaries. For each piece, it then builds a datagram header containing the identification, addressing, and options information needed. Fragmentation data is adjusted in the new headers to correspond to the data's relative position within the original datagram. The result is a set of small datagrams, called fragments, each carrying a portion of the data from the original large datagram. Section 6.3.7.8 defines the fragmenta- tion algorithm. Each fragment is handled independently until the destination IP module is reached. The fragments may follow different gateway routes as internet topology and traffic conditions change. They are also subject to further fragmentation if 'smaller-packet' subnetworks are subsequently traversed. Every IP module must be able to forward a datagram of 68 octets without further fragmentation. This size allows for a header length of up to 60 octets and the minimum data length of 8 octets. To reassemble fragments into the original datagram, an IP module combines all those received having the same value for the iden- tification, source address, destination address, and protocol. IP allocates reassembly resources when a "first-to-arrive" frag- ment is recognized. Based on the fragmentation data in the header, the fragment is placed in a reassembly area relative to its position in the original datagram. When all the fragments have been received, the IP module passes the data in its original form to the destination ULP. All hosts must be prepared to accept datagrams of up to 576 octets (whether they arrive whole or in fragments). It is recom- mended that hosts only send datagrams larger than 576 octets if System Development Corporation 1 June 1981 -22- IEN 186 they have assurance that the destination is prepared to accept the larger datagrams. The number 576 is selected to allow a rea- sonable amount of data to be transmitted in addition to the required header information. For example, this size allows a data block of 512 octets plus 64 header octets to fit in a datagram. The maximum internet header size is 60 octets, and a typical internet header is 20 octets, allowing a margin for headers of upper layer protocols. Because the subnetwork may be unreliable, some fragments making up a complete datagram can be lost. IP uses the "time-to-live" data (explained in section 6.1.4 below) to set a timer on the reassembly process. If the timer expires before all the frag- ments have been collected, IP discards the partially reassembled datagram. Only the destination IP module should perform reassembly. This recommendation is intended to reduce gateway overhead and minim- ize the chance of deadlock[3]. However, reassembly by private agreement between gateways is transparent to the rest of the internet and is allowed. A ULP can prevent its data from being broken into smaller pieces during transmission. IP provides an override mechanism to prohi- bit fragmentation called "Don't Fragment." Any internet datagram marked "don't fragment" cannot be fragmented by an IP module along the gateway route under any circumstances. If an IP module cannot deliver such a datagram to its destination without frag- menting it, the module discards the datagram and returns an error to the source IP. (Please note that fragmentation, transmission, and reassembly at the subnetwork layer is transparent to IP and can be used at any time.) 6.1.3 Checksum IP assumes the subnetwork layer to be unreliable regardless of the actual subnetwork protocol present. So, IP provides a check- sum mechanism supporting the delivery service to protect the IP header from transmission errors. The data portion is not covered by the IP checksum. An IP module recomputes the checksum each time the IP header is changed. Changes occur during time-to-live reductions, option updates (both explained below), and fragmentation. The checksum is currently a simple one's complement algorithm, and experimen- tal evidence indicates its adequacy. However, the algorithm is provisional and may be replaced by a CRC procedure, depending on future experience. System Development Corporation 1 June 1981 -23- IEN 186 6.1.4 Time To Live As mentioned in the routing discussion above, a datagram's transmission path is subject to changes in internet topology and traffic conditions. Inadvertently, a datagram might be routed on a circuitous path to arrive at its destination after a consider- able delay. Or, a datagram could loop through the same IP modules without making real progress towards its destination. Such "old datagrams" reduce internet bandwidth and waste process- ing time. To prevent these problems, IP provides a mechanism to limit the lifetime of a datagram, called time-to-live. Along with the other sending parameters, a ULP specifies a maximum datagram lifetime in second units. Each IP module on the gateway route decreases the time-to-live value carried in the IP header. If an IP module receives an expired datagram, it discards the datagram. The lifetime limit is in effect until the datagram's data is delivered to the destination ULP. That is, if a datagram is fragmented during transmission, it can still expire during the reassembly process. Section 6.3.4.3 defines the reassembly algo- rithm use of the time-to-live data. 6.1.5 Type of Service In support of the virtual network service, the type of service mechanism allows upper layer protocols to select the transmission quality. IP passes the type of service (TOS) command set for service quality to the SNP where it is mapped into subnetwork- specific transmission parameters. Not every subnetwork supports all transmission services, but each SNP on the delivery path should make a best effort to match the available subnet services to the desired service quality. The TOS command set includes precedence level, reliability level, speed level, resource trade-off, and transmission mode. Several subnetworks offer a precedence service where treating high pre- cedence traffic is processed before other traffic. A few net- works offer a stream service, whereby one can achieve low delay and constant datagram interarrival time by reserving network resources. Another choice involves a low-delay vs. high relia- bility trade-off. Usually subnetworks invoke more complex and delay producing mechanisms as the need for reliability increases. 6.1.6 Data Options Motivated by the virtual network service, IP provides a mechan- ism, called options, to carry certain identification and timing data in a standard manner through the internet. The use of this mechanism by the ULPs is optional, as the name implies, but all options must be supported by each IP implementation. No perfor- mance penalty is exacted from other services because the option System Development Corporation 1 June 1981 -24- IEN 186 data requires no additional processing by IP; it is simply passed on to the receiving ULP. The data options carry three kinds of information: security, stream identification, and timing. The security data is used by DOD hosts needing to transmit security and TCC (closed user groups) parameters through the internet in a standard manner. The stream identification option provides a way for a SATNET stream identifier to be carried both through stream-oriented sub- networks and subnets not supporting the stream concept. The tim- ing data, useful for testing and diagnostics, includes internet timestamps and satellite timestamps. 6.1.7 Error Report Datagrams The error reporting service motivates a mechanism to generate and process error information. The error mechanism uses the datagram delivery service to transfer the errors between IP modules. An IP module encounters errors from three sources: ULPs, SNPs, and other IP modules. Errors from the first two appear across IP's interfaces and are handled on the same medium. But errors from IP modules are found in or caused by datagrams and are reported to the source IP module in an "error report datagram." An error report datagram is composed of a minimal IP header and a data portion to carry error information. An error report datagram is distinguished from normal datagrams by the protocol field being equal to the Gateway-Gateway Protocol's identif- ier[13]. The error information includes a general error type, an error code, related error information, and portions of the dis- carded or erroneous datagram causing the report. The errors reported include: a. Destination Unreachable - A gateway or host IP cannot deliver a datagram. - subnet unreachable - A gateway IP cannot determine a route to the destination subnetwork. - host unreachable - A gateway IP cannot determine a route to the destination host. - protocol unreachable - The IP module at the destination address cannot deliver to the unknown or inactive pro- tocol. - port unreachable - The IP module at the destination address cannot deliver to the unknown or inactive port. System Development Corporation 1 June 1981 -25- IEN 186 - fragmentation needed but DF set - A host or gateway cannot deliver a datagram because fragmentation is required but is prohibited by the don't fragment flag. b. Time Exceeded - A datagram has exceeded its allowed life- time. - in transit - A gateway or host finds the time to live field in the datagram header is zero. The datagram is discarded. - during reassembly - The destination host cannot com- plete reassembly within the time-to-live time limit due to missing fragments. c. Parameter Problem - A gateway or host cannot deliver the datagram because of some problem with the header parameters. - Problem with an option - An option is either not sup- ported or incorrect. The third octet of the data por- tion contains the option type of the problem option. d. Source Quench - A gateway has discarded a datagram due to congestion. This report request the source host to cut back the rate at which it is sending traffic to that destination. e. Redirect - A gateway has received a datagram from a host on an attached subnet, but must forward it to another gateway on the same subnet. This message requests the source IP to send subsequent datagrams with the same destination to the other gateway. The address of the other gateway appears in octets 4-7. f. Echo - A host or gateway may use this report to establish connectivity. g. Type 0 : Echo Reply - A host or gateway responds to a previ- ous Echo. System Development Corporation 1 June 1981 -26- IEN 186 6.2 Internet Protocol Header Format A summary of the contents of the IP header follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Version| IHL |Type of Service| Total Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identification |Flags| Fragment Offset | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Time to Live | Protocol | Header Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Options | Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ IP Header Format Note that each tick mark represents one bit position. Each field description below includes its name, an abbreviation, and the field size. Where applicable, the units, the legal range of values, and a default value appears. 6.2.1 Version abbrev: VER field size: 4 bits The Version field indicates the format of the IP header. This document describes version 4. 6.2.2 Internet Header Length abbrev: IHL field size: 4 bits units : 4-octets range : 5 - 15 default : 5 Internet Header Length is the length of the IP header in 32-bit words, and thus points to the beginning of the data. Note that the minimum value for a correct header is 5. System Development Corporation 1 June 1981 -27- IEN 186 6.2.3 Type of Service abbrev: TOS field size: 8 bits The Type of Service field contains the IP parameters describing the quality of service desired for this datagram. 0 1 2 3 4 5 6 7 +-----+-----+-----+-----+-----+-----+-----+-----+ | | | | | | | PRECEDENCE | STRM|RELIABILITY| S/R |SPEED| | | | | | | +-----+-----+-----+-----+-----+-----+-----+-----+ Bits 0-2: Precedence. Bit 3: Stream or Datagram. Bits 4-5: Reliability. Bit 6: Speed over Reliability. Bits 7: Speed. PRECEDENCE STRM RELIABILITY S/R SPEED 111-Flash Override 1-STREAM 11-highest 1-speed 1-high 110-Flash 0-DTGRM 10-higher 0-rlblt 0-low 10X-Immediate 01-lower 01X-Priority 00-lowest 00X-Routine 6.2.4 Total Length abbrev: TL field size: 16 bits units: octets range : 20 - 65,535 default: 20 Total Length is the length of the datagram, measured in octets, including header portion and the data portion of the datagram. 6.2.5 Identification abbrev: ID field size : 16 bits A identifying value used to associate fragments of a datagram. This value is usually supplied by the sending ULP as an interface parameter. If not, IP generates datagram identifications which are unique for each sending ULP. System Development Corporation 1 June 1981 -28- IEN 186 6.2.6 Flags abbrev: - field size : 3 bits This field contains the control flags "don't fragment" which prohibits IP fragmentation and "more fragments" which helps to identify fragments. 0 1 2 +---+---+---+ | | D | M | | 0 | F | F | +---+---+---+ Bit 0: reserved, must be zero Bit 1: Don't Fragment This Datagram (DF). Bit 2: More Fragments Flag (MF). 6.2.7 Fragment Offset abbrev: FO field size : 13 bits units : 8-octet groups range : 0 - 8191 default : 0 This field indicates the positions of this fragment's data rela- tive to the beginning of the data carried in the original datagram. Both a complete datagram and a first fragment has this field set to zero. Section 6.1.2 describes the fragmentation mechanism. 6.2.8 Time to Live abbrev : TTL field size : 8 bits units : seconds range : 0 - 255(=4.25 mins) default : 15 This field indicates the maximum time the datagram is allowed to remain in the internet. If the value of this field drops to zero, the datagram should be destroyed. Section 6.1.4 describes the time-to-live mechanism. 6.2.9 Protocol abbrev : PROT field size : 8 bits This field indicates which ULP is to receive the data portion of the datagram. The numbers assigned to common ULPs are specified in [13]. System Development Corporation 1 June 1981 -29- IEN 186 6.2.10 Header Checksum abbrev : - field size : 16 bits This field contains the checksum covering the IP header. The checksum mechanism is described in section 6.1.3. 6.2.11 Source Address abbrev : source field size : 32 bits This field contains the internet address of the datagram's source host. The first octet is the Source Network, and the following three octets are the Source Subnetwork Address. Internet addressing is discussed in section 6.1.1. 6.2.12 Destination Address abbrev : dest field size : 32 bits This field contains the internet address of the datagram's desti- nation host. The first octet is the Destination Network, and the following three octets are the Destination Subnetwork Address. Internet addressing is discussed in section 6.1.1. 6.2.13 Padding abbrev : - field size : variable (8 to 24 bits) The IP header padding is used to ensure that the IP header ends on a 32-bit boundary. The padding field is set to zero. 6.2.14 Options abbrev : - field size : variable The option field is variable in length depending on the number and type of options associated with the datagram. The options mechanisms are discussed in sections 6.1.1 and 6.1.6. Options may have two possible formats: a. a single octet of option-type, or b. a variable length string containing: 1. an option-type octet, System Development Corporation 1 June 1981 -30- IEN 186 2. an option-length octet - counting the option-type octet and option-length octet as well as the option-data octets, and 3. the actual option-data octets. The option-type octet is viewed as having 3 fields: 0 1 2 3 4 5 6 7 +--+--+--+--+--+--+--+--+ |CF|CLASS| NUMBER | +--+--+--+--+--+--+--+--+ bit 0 - copy flag, if set the option is copied into every fragment if fragmentation occurs. bits 1-2 - option class bits 3-7 - option number The option classes are: 0 = control 1 = internet error 2 = debugging and measurement 3 = reserved for future use The following internet options are defined: COPY CLASS NUMBER LENGTH DESCRIPTION ---- ----- ------ ------ ----------- 0 0 0 - End of Option list: This option occupies only 1 octet; it has no length octet. 0 0 1 - No Operation: This option occupies only 1 octet; it has no length octet. 1 0 2 4 Security: Used to carry Security, and user group (TCC) information compatible with DOD requirements. 1 0 3 var. Source Routing: Used to route the datagram based on information supplied by the source. 0 0 7 var. Return Route: Used to record the route a datagram takes. 1 0 8 4 Stream ID: Used to carry the stream identifier. 0 2 4 6 Internet Timestamp. 0 2 5 6 Satellite Timestamp. System Development Corporation 1 June 1981 -31- IEN 186 6.2.15 Specific Option Definitions Each option format is defined below. "Option type" indicates the value of the option-type octet, and "length" indicates the value of the length-octet if appropriate. 6.2.15.1 End of Option List option type : 0 option length : N/A This one octet option marks the end of the option list when it does not coincide with the four-octet boundary indicated by the IP header length. This field is used at the end of all options, not the end of each option, and need only be used if the end of the options would not otherwise coincide with the end of the IP header. This option may be introduced or deleted upon fragmenta- tion as needed. 6.2.15.2 No Operation option type : 1 option length : N/A This option may be used between options, for example, to align the beginning of a subsequent option on a 32 bit boundary. This option may be introduced or deleted upon fragmentation as needed. 6.2.15.3 Security option type : 130 option length : 4 This option provides a way for hosts to send security and TCC (closed user groups) parameters through subnetworks in a standard manner. The format for this option is as follows: System Development Corporation 1 June 1981 -32- IEN 186 0 1 2 3 01234567 89012345 67890123 45678901 +--------+--------+--------+--------+ |Opt.Type| Length |xxxxxxSS| TCC | +--------+--------+--------+--------+ bits 0-7 : Option Type - described above bits 8-15 : Length - described above bits 16-21 : Not Used - must be zero bits 22-23 : SS - security, specifies security level: 11-top secret 10-secret 01-confidential 00-unclassified bits 24-31 : TCC - transmission control code, provides a means to compartmentalize traffic and define controlled communities of interest among subscribers. (This format is subject to change according to DOD requirements.) 6.2.15.4 Source Route option type : 131 option length : variable The source route option provides a means for the source ULP of a datagram to supply routing information to be used by IP modules along the gateway route. The option begins with the option type code. The second octet is the option length which includes the option type octet, the length octet, and the source route list. A source route list is composed of one or more internet addresses. Each internet address is 4 octets long. When the source route list is empty, the option is removed from the datagram and the remaining routing is based on the destination address field. The source route option is described in section 6.1.1. 6.2.15.5 Return Route option type : 7 option length : variable The return route option provides a way to record a datagram's route. The option begins with the option type code. The second octet is the option length which includes the option type code, the length octet, and the return route list. A return route list is com- posed of a series of internet addresses. The return route option is described in section 6.1.1. System Development Corporation 1 June 1981 -33- IEN 186 6.2.15.6 Stream Identifier option type : 136 option length : 4 This option provides a way for 16-bit stream identifier to be carried through the internet for use by subnetworks supporting the stream concept such as the SATNET. 6.2.15.7 Internet Timestamp option type : 68 option length : 10 The internet address of the "stamper" is followed by a 32-bit time measured in milliseconds. Time zero is defined as January 1, 1980, GMT modulo 2^32 (=49.71 days). 6.2.15.8 Satellite Timestamp option type : 69 option length : 10 The internet address of the "stamper" is followed by a 32-bit time measured in milliseconds. Time zero is defined as January 1, 1980, GMT modulo 2^32 (=49.71 days). 6.2.16 Error Report Datagrams An error report datagram informs source IPs of erroneous or dis- carded datagrams. Such a datagram is identified by its protocol field being equal to the GGP identifier[13]. An error report datagram is made up of a minimal IP header and a data portion carrying error information. The first octet of the data portion contains the error type octet. The next two octets hold addi- tional error information which depends on the error type. The fourth octet is not used. Beginning with the fifth octet, the erroneous datagram's header and first 64 data octets may appear. System Development Corporation 1 June 1981 -34- IEN 186 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Code | | Not Used | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | \ Header + 64 data octets from erroneous or discarded datagram \ \ \ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Error Datagram Data Portion The error types and related error information are defined below: Type Code Description ---- ---- ---------- 3 0 Destination Unreachable due to unreachable subnetwork. 3 1 Dest. Unreachable due to unreachable host. 3 2 Dest. Unreachable due to unreachable or unknown protocol. 3 3 Dest. Unreachable due to unreachable or inactive port. 3 5 Dest. Unreachable due to fragmentation needed but prohibited by don't fragment flag. 11 0 Time Exceeded in transit. 11 1 Time Exceeded during reassembly. 12 0 Parameter Problem due to incorrect or unsupported option. 4 - Source Quench due to congestion and discarded datagram in a gateway. 5 - Redirect due to more direct path via alternate gateway. Octets 4-7 carry the address of the alternate gateway. The redirected datagram follows at octet 8. 8 - Echo used to establish internet topology. No erroneous datagram carried in data portion. 0 - Echo Reply responds to previous echo. No erroneous datagram carried in data portion. System Development Corporation 1 June 1981 -35- IEN 186 6.3 Extended State Machine Representation The IP protocol mechanism is defined by a state machine represen- tation made up of a set of states, a set of transitions between states, and a set of input events causing the state transitions. In addition, a state machine has an initial state whose values are assumed at state machine instantiation. 6.3.1 State Machine Identification Each datagram is an independent unit. Therefore, one state machine instance exists for each datagram. Each datagram is uniquely named by the four values: o+ source address o+ destination address o+ protocol o+ identification 6.3.2 State Machine Diagram The following diagram depicts a simplified IP state machine. System Development Corporation 1 June 1981 -36- IEN 186 send or receive a complete datagram __ | | | v * * * * * * * * * INACTIVE * * * * * * * * * | ^ receive | |receive complete datagram, fragment| | or final fragment, | | or reassembly timeout v | * * * * * * * * * REASSEMBLING * * * * * * * * * | ^ |__| receive fragments 6.3.3 State Vector A state vector consists of the following elements : o+ STATE NAME = (inactive, reassembling) o+ REASSEMBLY RESOURCES = control information and storage needed to reassemble fragments into the original datagram, including: - reassembly map : a representation of each 8-octet unit of data and its relative location within the original datagram. - timer : value of the reassembly timer in unit seconds ranging from 0 to 255. - total data length : size of the data carried in datagram being reassembled. - header : storage area for the header portion of the datagram being reassembled. System Development Corporation 1 June 1981 -37- IEN 186 - data : storage area for the data portion of the datagram being reassembled. A state machine's initial state is inactive with unused reassem- bly resources. 6.3.4 State Machine Data Structures The IP state machine references certain data areas corresponding to the state vector, and each interaction primitive : SEND, DELIVER, SNP_SEND, and SNP_DELIVER. For clarity in the events and actions section, data structures are declared in Ada for these data areas. However, a data structure may be partially typed or completely untyped where specific formats or data types are implementation dependent. 6.3.4.1 state_vector The definition of an IP state vector appears section 6.3.1 above. A state_vector structure is declared as: type state_vector_type is record state_name : (INACTIVE, REASSEMBLING); reassembly_map timer total_data_length header data end record; 6.3.4.2 from_ULP The from_ULP structure holds the interface parameters and data associated with the SEND primitive, as specified in section 3.1.1. The from_ULP structure is declared as: type from_ULP_type is record source_addr destination_addr protocol type_of_service identifier time_to_live dont_fragment length data options end record; System Development Corporation 1 June 1981 -38- IEN 186 6.3.4.3 to_ULP The to_ULP structure holds interface parameters and data associ- ated with the DELIVER primitive, as specified in section 3.1.2. The to_ULP structure is declared as: type to_ULP_type is record source_addr destination_addr protocol type_of_service length data options error end record; 6.3.4.4 from_SNP The from_SNP structure holds the interface parameters and datagram associated with the SNP_DELIVER primitive, as specified in section 5.2.2. The from_SNP structure is declared as: type from_SNP_type is record local_destination_addr dtgm: datagram_type; error end record; The dtgm element is itself a structure as specified below. 6.3.4.5 to_SNP The to_SNP structure holds the data and parameters associated with the SNP_SEND primitive specified in section 5.2.1. The to_SNP structure is declared as: type to_SNP_type is record local_destination_addr type_of_service_indicators length dtgm: datagram_type; end record; The dtgm element is itself a structure as specified below. specified below. System Development Corporation 1 June 1981 -39- IEN 186 6.3.4.6 dtgm A dtgm structure holds a datagram made up of a header portion and a data portion as specified in section 6.2. A dtgm structure is declared as: type datagram_type is record version : HALF_OCTET; header_length : HALF_OCTET; type_of_service : OCTET; total_length : TWO_OCTETS; identification : TWO_OCTETS; dont_frag_flag : BOOLEAN; more_frag_flag : BOOLEAN; fragment_offset : ONE_N_FIVE_EIGHTHS_OCTETS; time_to_live : OCTET; protocol : OCTET; header_checksum : TWO_OCTETS; source_addr : FOUR_OCTETS; destination_addr : FOUR_OCTETS; options : option_type; data : array(1..DATA_LENGTH) of INTEGER; end record; subtype HALF_OCTET is INTEGER range 0..15; subtype OCTET is INTEGER range 0..255; subtype ONE_N_FIVE_EIGHTHS_OCTETS is INTEGER range 0..8191; subtype TWO_OCTETS is INTEGER range 0..65535; subtype FOUR_OCTETS is INTEGER range 0..4294967296; 6.3.5 Event List The following list defines the set of possible events in an IP state machine: a. SEND from ULP - A ULP passes interface parameters and data to IP for delivery across the internet. b. SNP_DELIVER from SNP - SNP passes to IP a datagram received from subnetwork protocol. c. TIMEOUT - The timing mechanism provided by the execution environment indicates a previously specified time interval has elapsed. 6.3.6 State Machine Events and Actions This section is organized in three parts. The first part con- tains a decision table representation of state machine events and System Development Corporation 1 June 1981 -40- IEN 186 actions. The decision tables are organized by state; each table corresponds to one event. The second part specifies the decision functions appearing at the top of each column of a decision table. These functions examine attributes of the event and the state vector to return a set of decision results. The results become the elements of each column. A "--" element represents a "don't care" condition where a decision result does not determine the action procedure chosen. The third section specifies action procedures appearing at the right of every row. Each row of the decision table combines the decision results to determine appropriate event processing. These procedures specify event processing algorithms in detail. 6.3.6.1 Events and Actions Decision Tables STATE = INACTIVE ================ EVENT = SEND from ULP ============================= | ULP |where | need | can | |params| to | to | frag | |valid | | frag | | ============================= | NO | -- | -- | -- |error to ULP(PARAM_PROBLEM) --------------------------------------------------------- | YES | ULP | -- | -- |local delivery --------------------------------------------------------- | YES | IP | -- | -- | **illegal --------------------------------------------------------- | YES |REMOTE| NO | -- |build&send --------------------------------------------------------- | YES |REMOTE| YES | NO |error to ULP(CAN'T FRAGMENT) --------------------------------------------------------- | YES |REMOTE| YES | YES |fragment&send --------------------------------------------------------- Comments: A ULP passes data to IP for internet delivery. IP validates the interface parameters, determines the destination, and dispatches the ULP data to its destination. System Development Corporation 1 June 1981 -41- IEN 186 STATE = INACTIVE ================ EVENT = DELIVER from SNP ==================================== |check-| SNP | TTL |where | a | | sum |params|valid | to | frag | |valid |valid | | | | ==================================== | NO | -- | -- | -- | -- |discard ------------------------------------------------------------------ | YES | NO | -- | -- | -- |error to source(PARAM_PROBLEM) ------------------------------------------------------------------ | YES | YES | NO | -- | -- |error to source(EXPIRED_TTL) ------------------------------------------------------------------ | YES | YES | YES | ULP | NO |remote delivery ------------------------------------------------------------------ | YES | YES | YES | ULP | YES |reassemble;STATE:=REASSEMBLING ------------------------------------------------------------------ | YES | YES | YES | IP | NO |analyze ------------------------------------------------------------------ | YES | YES | YES | IP | YES |reassemble;STATE:=REASSEMBLING ------------------------------------------------------------------ | YES | YES | YES |REMOTE| -- |error to source(HOST_UNREACH) ------------------------------------------------------------------ Comments: The SNP has delivered datagram from another IP. IP validates the datagram header, and either delivers the data from a complete datagram to its destination within the host or begins reassembly for a datagram fragment. System Development Corporation 1 June 1981 -42- IEN 186 STATE = REASSEMBLING ==================== EVENT = DELIVER from SNP =========================================== |check-| SNP | TTL |where | a |reass.| | sum |params|valid | to | frag | done | |valid |valid | | | | | =========================================== | NO | -- | -- | -- | -- | -- |discard -------------------------------------------------------------------------- | YES | NO | -- | -- | -- | -- |error to source(PARAM_PROBLEM) -------------------------------------------------------------------------- | YES | YES | NO | -- | -- | -- |error to source(EXPIRED_TTL) -------------------------------------------------------------------------- | YES | YES | YES | ULP | NO | -- |remote delivery;state:=INACTIVE -------------------------------------------------------------------------- | YES | YES | YES | ULP | YES | NO |reassemble -------------------------------------------------------------------------- | YES | YES | YES | ULP | YES | YES |reass delivery;state:=INACTIVE -------------------------------------------------------------------------- | YES | YES | YES | IP | NO | -- |analyze;state:=INACTIVE -------------------------------------------------------------------------- | YES | YES | YES | IP | YES | NO |reassemble -------------------------------------------------------------------------- | YES | YES | YES | IP | YES | YES |analyze;state:=INACTIVE -------------------------------------------------------------------------- | YES | YES | YES |REMOTE| -- | -- |error to source(HOST_UNREACH) -------------------------------------------------------------------------- Comment: The SNP has delivered a datagram associated to an earlier received datagram fragment. IP validates the header and either continues the reassembly process with the datagram fragment or delivers the data from the completed datagram to its destination within the host. EVENT = TIMEOUT reassembly timeout; state:=INACTIVE ----------------------------------- Comment: The time-to-live period of the datagram being reassembled has elapsed. The incomplete datagram is discarded; the source IP is informed. System Development Corporation 1 June 1981 -43- IEN 186 6.3.6.2 Decision Functions The following functions examine information contained in inter- face parameters, interface data, and the state vector to make decisions. These decisions can be thought of as further refine- ments of the event and/or state. The functions return values represent the possible decisions. 6.3.6.2.1 checksum valid The checksum_valid function examines an incoming datagram's header to determine whether it is free from transmission errors. The data effects of this function are: - Data examined only: from_SNP.dtgm.version from_SNP.dtgm.fragment_offset from_SNP.dtgm.header_length from_SNP.dtgm.time_to_live from_SNP.dtgm.type_of_service from_SNP.dtgm.protocol from_SNP.dtgm.total_length from_SNP.dtgm.source_addr from_SNP.dtgm.identification from_SNP.dtgm.destination_addr from_SNP.dtgm.dont_frag_flag from_SNP.dtgm.options from_SNP.dtgm.more_frag_flag from_SNP.dtgm.padding - Return values: NO -- checksum did not check indicating header fields contain errors YES -- checksum was consistent The algorithm: --The checksum algorithm is the 16-bit one's complement --of the one's complement sum of all 16-bit words in --the IP header. For purposes of computing the checksum, --the checksum field is set to zero. --implementation dependent action System Development Corporation 1 June 1981 -44- IEN 186 6.3.6.2.2 ULP_params_valid The ULP_params_valid function examines the interface parameters received from a ULP to see if all values are within legal ranges and desired options are supported. The data effects of this function are: - Data examined only: from_ULP.time_to_live from_ULP.options - Return values: NO - some value is illegal or a desired option is not supported. YES - examine values are within legal ranges and desired options can be supported. The algorithm: if ( --The time-to-live value must be greater than zero to --allow IP to transmit it at least once. (from_ULP.time_to_live < 0 ) or --The options requested should be checked for consistency. --implementation dependent action or --Check other implementation dependent values. ) then return NO else return YES; end if; System Development Corporation 1 June 1981 -45- IEN 186 6.3.6.2.3 SNP_params_valid The SNP_params_valid function examines the interface parameters and the datagram received from the local subnetwork protocol to see if all values are within legal ranges and no errors have occured. The data effects of this function are: - Data examined only: from_SNP.dtgm.version from_SNP.dtgm.source_addr from_SNP.dtgm.header_length from_SNP.dtgm.destination_addr from_SNP.dtgm.total_length from_SNP.dtgm.options from_SNP.dtgm.protocol other information/errors from SNP - Return values: NO - some value or values are illegal or an error has occured YES - examined values are within legal ranges and no errors have occured The algorithm: if ( --The current IP header version number is 4. (from_SNP.dtgm.version /= 4) --The minimal IP header is 5 32-bit units in length. or (from_SNP.dtgm.header_length < 5) --The smallest legal datagram contains only a header and is --20 octets in length. or (from_SNP.dtgm.total_length < 20) --The legal protocol identifiers are provided in [13]. or (from_SNP.dtgm.protocol is not one of the acceptable identifiers) --The legal network address mappings are provided in [12]. or (from_SNP.dtgm.source_addr is not an acceptable address) --The legal network address mappings are provided in [12]. or (from_SNP.dtgm.destination_addr is not an acceptable address) ) then return NO elseif (any implementation dependent values received from the SNP are illegal or indicate error conditions) then return NO else return YES; --Otherwise, all values look good. endif; System Development Corporation 1 June 1981 -46- IEN 186 endif; System Development Corporation 1 June 1981 -47- IEN 186 6.3.6.2.4 where to The where_to function determines the destination of the incoming datagram by examining the address fields and options fields of the datagram header. The data effects of this function are: - Data examined only: from_SNP.dtgm.destination_addr from_SNP.dtgm.protocol from_SNP.dtgm.options - Return values: ULP - destination is an upper layer protocol at this location IP - destination is this IP module REMOTE - destination is some remote location The algorithm: --The source route influences the datagram's gateway route. if ((from_SNP.dtgm.options contains the source routing option) then return REMOTE; endif; --Examine the destination address field of the datagram header. if ((from_SNP.dtgm.destination_addr /= this site's address) then --It's destined for another site. return REMOTE else --It's destined for this site. if (from_SNP.dtgm.protocol = the IP identifier) then return IP else --Verify existence of addressed ULP at this location. if (from_SNP.dtgm.protocol exists here) then return ULP end if; end if; end if; System Development Corporation 1 June 1981 -48- IEN 186 6.3.6.2.5 TTL valid The TTL_valid function examines the IP header time-to-live field of an incoming datagram to determine whether the datagram has exceeded its allowed lifetime. The data effects of this function are: - Data examined only: from_SNP.dtgm.time_to_live - Return values: NO - the datagram has expired YES - the datagram has some life left in it The algorithm: --Decrement from_SNP.dtgm.time_to_live field by the maximum --of either the amount of time elapsed since the last IP module --handled this datagram (if known) or one second. if (( from_SNP.dtgm.time_to_live - maximum(number of seconds elapsed since last IP, 1)) <= 0 ) then return NO else return YES; System Development Corporation 1 June 1981 -49- IEN 186 6.3.6.2.6 a frag The a_frag function examines certain fields in an incoming datagram's header to determine whether the datagram is a fragment of a larger datagram. The data effects of this algorithm are: - Data examined only: from_SNP.dtgm.fragment_offset from_SNP.dtgm.more_frag_flag - Return values: NO - the datagram has not been fragmented YES - the datagram is a part of a larger datagram The algorithm: if ((from_SNP.dtgm.fragment_offset = 0) --contains the beginning and (from_SNP.dtgm.more_frag_flag = 0)) --and the end of the data then return NO --therefore it is an unfragmented datagram else return YES; --otherwise it contains only a portion of the data --and is a fragment. System Development Corporation 1 June 1981 -50- IEN 186 6.3.6.2.7 reassembly done The reassembly_done function examines the incoming datagram and the reassembly resources to determine whether the final fragment has arrived to complete the datagram being reassembled. The data effects of this function are: Data examined only: state_vector.reassembly_map from_SNP.dtgm.more_frag_flag state_vector.total_length from_SNP.dtgm.header_length from_SNP.dtgm.fragment_offset from_SNP.dtgm.total_length - Return values: NO - more fragments are needed to complete reassembly YES - this is the only fragment needed to complete reassembly The algorithm: --The total data length of the original datagram, as computed from --"tail" fragment, must be known before completion is possible. if (state_vector.total_data_length = 0) then --Check incoming datagram for "tail." if (from_SNP.dtgm.more_frag_flag = FALSE) then --Compute total data length and see if data in --this fragment fills out reassembly map. if (reassembly map from 0 to (((from_SNP.dtgm.total_length - --total data (from_SNP.dtgm.header_length*4)+7)/8) -- length +7)/8 is set ) then return YES; end if; else --Reassembly cannot be complete if total data length unknown. return NO; end if; else --Total data length is already known. See if data --in this fragment fills out reassembly map. if ( all reassembly map from 0 to (state_vector.total_data_length+7)/8 is set) then return YES; --final fragment else return NO; --more to come end if; end if; System Development Corporation 1 June 1981 -51- IEN 186 6.3.6.2.8 need to frag The need_to_frag function examines the interface parameters and data from a ULP to determine whether the data can be transmitted as a single datagram or must be transmitted as two or more datagram fragments. The data effects of this function are: - Data examined only: from_ULP.length from_ULP.options - Return values: NO - one datagram is small enough for the subnetwork YES - datagram fragments are needed to carry the data The algorithm: --Compute the datagram's length based on the length of data, --the length of options, and the standard datagram header size. if (( from_ULP.length + (number of bytes of option data) + 20 ) > maximum transmission unit of the local subnetwork ) then return YES else return NO; end if; 6.3.6.2.9 can frag The can_frag function examines the don't fragment flag of the interface parameters allows fragmentation. The data effects of this function are: - Data examined only: from_ULP.dont_fragment - Return values: NO - don't fragment flag is set preventing fragmentation YES -don't fragment flag is NOT set to allow fragmentation The algorithm: if (from_ULP.dont_fragment = TRUE) then return NO else return YES end if; System Development Corporation 1 June 1981 -52- IEN 186 6.3.6.3 Decision Table Actions 6.3.6.3.1 compute_checksum The compute_checksum procedure calculates a checksum value for a datagram header so that transmission errors can be detected by a destination IP. The data effects of this procedure are: - Data examined: to_SNP.dtgm.version to_SNP.dtgm.fragment_offset to_SNP.dtgm.header_length to_SNP.dtgm.time_to_live to_SNP.dtgm.type_of_service to_SNP.dtgm.protocol to_SNP.dtgm.total_length to_SNP.dtgm.source_addr to_SNP.dtgm.identification to_SNP.dtgm.destination_addr to_SNP.dtgm.dont_frag_flag to_SNP.dtgm.options to_SNP.dtgm.more_frag_flag to_SNP.dtgm.padding - Data modified: to_SNP.dtgm.checksum The procedure: --The checksum algorithm is the 16-bit one's complement of --the one's complement sum of all 16-bit words --in the IP header. For purposes of computing the checksum, --the checksum field is set to zero. --implementation dependent action System Development Corporation 1 June 1981 -53- IEN 186 6.3.6.3.2 reassemble The reassemble procedure reconstructs an original datagram from datagram fragments. The data effects of this procedure are: - Data examined: from_SNP.dtgm - Data modified: state_vector.reassembly_map state_vector.header state_vector.timer state_vector.data state_vector.total_data_length The procedure: --A local variable is introduced to make the computations more clear. --data_in_frag equals the number of octets of data in received fragment. data_in_frag := (from_SNP.dtgm.total_length -from_SNP.dtgm.header_length*4); --Put data in its relative position in the data area of the state vector. state_vector.data[from_SNP.dtgm.fragment_offset*8.. from_SNP.dtgm.fragment_offset*8+data_in_frag] := from_SNP.dtgm.data[0..data_in_frag-1]; --Fill in the corresponding entries of the reassembly map representing --each 8-octet unit of received data. for j in (from_SNP.dtgm.fragment_offset).. (from_SNP.dtgm.fragment_offset + data_in_frag + 7)/8) loop state_vector.reassembly_map[j] := 1; end loop; --Compute the total datagram length from the "tail-end" fragment. if (from_SNP.dtgm.more_frag_flag = FALSE) then state_vector.header.total_data_length := from_SNP.dtgm.fragment_offset*8 + data_in_frag; end if; --Record the header of the "head-end" fragment. if (from_SNP.dtgm.fragment_offset = 0) then state_vector.header := from_SNP.dtgm; end if; --Reset the reassembly timer if its current value is less than the --time-to-live field of the received datagram. System Development Corporation 1 June 1981 -54- IEN 186 state_vector.timer := maximum( from_SNP.dtgm.time_to_live, state_vector.timer); A reassembly algorithm may vary according to implementation con- cerns, but each one must meet these requirements: 1. Every destination IP module must have the capacity to receive a datagram 576 octets in length, either in one piece or in fragments to be reassembled. 2. The header of the fragment with from_SNP.dtgm.fragment_offset equal to zero (i.e. the "head-end" fragment) becomes the header of the reassembling datagram. 3. The total length of the reassembling datagram is calculated from the fragment with from_SNP.dtgm.more_frag_flag equal to zero (i.e. the "tail-end" fragment). 4. A reassembly timer is associated with each datagram being reassembled. The current recommendation for the initial timer setting is 15 seconds. Note that the choice of this parameter value is related to the buffer capacity available and the data rate of the subnetwork. That is, data rate mul- tiplied by timer value equals reassembly capacity (e.g.10Kb/s X 15secs = 150Kb). 5. As each fragment arrives, the reassembly timer is reset to the maximum of state_vector.reassembly_resources.timer and from_SNP.dtgm.time_to_live in the incoming fragment. 6. If the reassembly timer expires, the datagram being reassem- bled is discarded. Also, an error datagram is returned to the source IP to report the "time exceeded during reassem- bly" error. System Development Corporation 1 June 1981 -55- IEN 186 6.3.6.3.3 build&send The build&send procedure builds an outbound datagram in the to_SNP structure from the interface parameters and data in from_ULP and passes it to the SNP for transmission across the subnet. The data effects of this procedure are: - Data examined: from_ULP.source_addr from_ULP.time_to_live from_ULP.destination_addr from_ULP.dont_fragment from_ULP.protocol from_ULP.options from_ULP.type_of_service from_ULP.length from_ULP.identifier from_ULP.data - Data modified: to_SNP.dtgm to_SNP.type_of_service_indicator to_SNP.length to_SNP.local_destination_addr The algorithm: --Fill in each IP header field with information from from_ULP or --standard values. to_SNP.dtgm.version := 4; --Current IP version is 4. to_SNP.dtgm.type_of_service := from_ULP.type_of_service; --If ID is not given by ULP, the IP must supply its own. to_SNP.dtgm.identification := from_ULP.identifier; to_SNP.dtgm.dont_frag_flag := from_ULP.dont_fragment; to_SNP.dtgm.more_frags_flag := 0; to_SNP.dtgm.fragment_offset := 0; to_SNP.dtgm.time_to_live := from_ULP.time_to_live; to_SNP.dtgm.protocol := from_ULP.protocol; to_SNP.dtgm.source_addr := from_ULP.source_address; to_SNP.dtgm.destination_addr := from_ULP.destination_address; to_SNP.dtgm.options := from_ULP.options; to_SNP.dtgm.padding := (as needed to end the IP header four octet boundary); to_SNP.dtgm.header_length := 5 + (number of bytes of option data)/4; to_SNP.dtgm.total_length := (to_SNP.dtgm.header_length)*4 + (from_ULP.length); --Call compute_checksum to to compute and set the checksum. compute_checksum; --And, fill in the data portion of the datagram. System Development Corporation 1 June 1981 -56- IEN 186 to_SNP.dtgm.data[0..from_ULP.length -1] := from_ULP.data[0.. from_ULP.length-1]; --Set the type of service and length fields for the SNP. to_SNP.type_of_service_indicator := to_SNP.dtgm.type_of_service; to_SNP.length := to_SNP.dtgm.total_length; --Call the route procedure to determine a local destination --from the internet destination address supplied by the ULP. route; --Request the execution environment to pass the contents of to_SNP --to the local subnetwork protocol for transmission. TRANSFER to_SNP to the SNP. NOTE: The format of the from_ULP elements is unspecified allowing an implementor to assign data types for the interface parameters. If those data types differ from the IP header types, the assignment statements above become type conversions. System Development Corporation 1 June 1981 -57- IEN 186 6.3.6.3.4 route The route procedure examines the destination address and options fields of an outbound datagram in to_SNP to determine a local destination address. The data effects of this procedure are: - Data examined: to_SNP.dtgm.destination_addr to_SNP.dtgm.options - Data modified: to_SNP.local_destination_addr The procedure: --The source routing option influences the path of the datagram. --If that option is present, use the top of the source route list --as the destination; otherwise use the header's destination --address field. if (source routing present in options) then destination := (first address on source route list) else destination := to_SNP.dtgm.destination_addr; endif; if (the network id field of destination matches the network id of the local subnet protocol ) then --Translate the REST field of destination into the subnetwork --address of the destination on this subnet. --implementation dependent action else --Find the appropriate gateway and its subnetwork address --based on the network id field of the destination. --implementation dependent action end if; --Set the local destination interface parameter. to_SNP.local_destination_addr := (subnetwork address found above); System Development Corporation 1 June 1981 -58- IEN 186 6.3.6.3.5 local delivery The local_delivery procedure moves the interface parameters and data in the from_ULP structure to the to_ULP structure and delivers it to an in-host ULP. The data effects of this procedure are: - Data examined: from_ULP.destination_addr from_ULP.length from_ULP.source_addr from_ULP.data from_ULP.protocol from_ULP.options from_ULP.type_of_service - Data modified: to_ULP.source_addr to_ULP.length to_ULP.destination_addr to_ULP.data to_ULP.protocol to_ULP.options to_ULP.type_of_service The procedure: --Move the interface parameters and data from the input --structure, from_ULP, directly to the output structure, to_ULP, --for delivery to a local ULP. from_ULP.destination_addr := to_ULP.destination_addr; from_ULP.source_addr := to_ULP.source_addr; from_ULP.protocol := to_ULP.protocol; from_ULP.type_of_service := to_ULP.type_of_service; from_ULP.length := to_ULP.length; from_ULP.data := to_ULP.data; from_ULP.options := to_ULP.options; --Request the execution environment to pass the contents of to_SNP --to the local subnet protocol for transmission. TRANSFER to_ULP to to_ULP.protocol. System Development Corporation 1 June 1981 -59- IEN 186 6.3.6.3.6 remote delivery The remote_delivery procedure decomposes a datagram arriving from a remote IP into interface parameters and data and delivers them to the destination ULP. The data effects of this procedure are: - Data examined: from_SNP.dtgm.source_addr from_SNP.dtgm.total_length from_SNP.dtgm.destination_addr from_SNP.dtgm.header_length from_SNP.dtgm.protocol from_SNP.dtgm.data from_SNP.dtgm.type_of_service from_SNP.dtgm.options - Data modified: to_ULP.destination_addr to_ULP.length to_ULP.source_addr to_ULP.data to_ULP.protocol to_ULP.options to_ULP.type_of_service The algorithm: to_ULP.destination_addr := from_SNP.dtgm.destination_addr; to_ULP.source_addr := from_SNP.dtgm.source_addr; to_ULP.protocol := from_SNP.dtgm.protocol; to_ULP.type_of_service := from_SNP.dtgm.type_of_service; to_ULP.length := from_SNP.dtgm.total_length - from_SNP.dtgm.header_length*4; to_ULP.data := from_SNP.dtgm.data; to_ULP.options := from_SNP.dtgm.options; NOTE: The format of the to_ULP elements is unspecified allowing an implementor to assign data types for the interface parameters. If those data types differ from the IP header types, the assignment statements above become type conversions. System Development Corporation 1 June 1981 -60- IEN 186 6.3.6.3.7 reassembled delivery The reassembled_delivery procedure decomposes the datagram that has been reassembled in the state vector into interface parame- ters and data, then delivers them to a ULP. The data effects of this procedure are: - Data examined: state_vector.header.destination_addr state_vector.header.source_addr state_vector.header.protocol state_vector.header.type_of_service state_vector.header.header_length state_vector.header.total_length state_vector.header.options state_vector.data - Data modified: to_ULP.destination_addr to_ULP.length to_ULP.source_addr to_ULP.data to_ULP.protocol to_ULP.options to_ULP.type_of_service The procedure: to_ULP.destination_addr := state_vector.header.destination_addr; to_ULP.source_addr := state_vector.header.source_addr; to_ULP.protocol := state_vector.header.protocol; to_ULP.type_of_service := state_vector.header.type_of_service; to_ULP.length := state_vector.header.total_length; - state_vector.header.header_length*4; to_ULP.options := state_vector.header.options; to_ULP.data := state_vector.data; System Development Corporation 1 June 1981 -61- IEN 186 6.3.6.3.8 fragment&send The fragment&send procedure breaks data that is too big to be transmitted through the subnetwork as a single datagram into smaller pieces for transmission in several datagrams. The data effects of the procedure are: - Data examined only: from_ULP.source_addr from_ULP.length from_ULP.destination_addr from_ULP.data from_ULP.protocol from_ULP.options from_ULP.type_of_service - Data modified: to_SNP.dtgm to_SNP.type_of_service_indicators to_SNP.length to_SNP.local_destination_address Some "local variables" are used to make the procedure clearer: number_of_fragments -- number of small datagrams created from user data data_per_fragment -- the number of octets in each small datagram number_frag_blocks -- the number of 8-octet blocks in each small datagram data_in_last_frag -- the number of octets in the last datagram The procedure: --Compute the fragmentation variables. --The amount of data per fragment equals the max datagram size less --the length of the datagram header. data_per_fragment := maximum subnet transmission unit - (20 + number of bytes of option data); number_frag_blocks := data_per_fragment/8; number_of_fragments := (from_ULP.length + (data_per_fragment-1)) / data_per_fragment; data_in_last_frag := from_ULP.length modulo data_per_fragment; --Create the first fragment and transmit it to the SNP. to_SNP.dtgm.version := 4; to_SNP.dtgm.header_length := 5 + (number bytes of option data/4); to_SNP.dtgm.total_length := to_SNP.dtgm.header_length System Development Corporation 1 June 1981 -62- IEN 186 + data_per_fragment; to_SNP.dtgm.identifier := from_ULP.identification; to_SNP.dtgm.dont_frag_flag := from_ULP.dont_fragment; to_SNP.dtgm.more_frag_flag := TRUE; to_SNP.dtgm.fragment_offset := 0; to_SNP.dtgm.time_to_live := from_ULP.time_to_live; to_SNP.dtgm.protocol := from_ULP.protocol; to_SNP.dtgm.source_addr := from_ULP.source_addr; to_SNP.dtgm.destination_addr := from_ULP.destination_addr; to_SNP.dtgm.options := from_ULP.options; to_SNP.dtgm.padding := (as needed to end header on 4-octet boundary); to_SNP.dtgm.data[0..data_per_fragment-1] := from_ULP.data[0..data_per_fragment-1]; --Set the datagram's header checksum field. compute_checksum; --Call route to determine the subnetwork address of the destination. route; --Also set the length and type of service indicators. to_SNP.length := to_SNP.dtgm.total_length; to_SNP.type_of_service_indicators := to_SNP.dtgm.type_of_service; --Request the execution environment to pass the first fragment --to the SNP. TRANSFER to_SNP to the local subnetwork protocol. --Format and transmit successive fragments. for j in 1..number_of_fragments-1 loop --The header fields remain the same as in the first fragment, --EXCEPT for: if ("copy" flag present in any options) then --put ONLY "copy" options into options fields and --adjust length fields accordingly. to_SNP.dtgm.options := (options with "copy" flag); to_SNP.dtgm.header_length := 5 + (number of copy options octets/4); else --only standard datagram header present to_SNP.dtgm.header_length := 5; endif; System Development Corporation 1 June 1981 -63- IEN 186 --Append data and set fragmentation fields. if (j /= number_of_fragments-1) then --middle fragment(s) to_SNP.dtgm.more_frag_flag := TRUE; to_SNP.dtgm.fragment_offset := j*number_frag_blocks; to_SNP.dtgm.total_length := to_SNP.dtgm.header_length + data_per_fragment; to_SNP.dtgm.data[0..data_per_fragment-1] := from_ULP.data[j*data_per_fragment.. (j*data_per_fragment + data_per_fragment-1)]; else --last fragment to_SNP.dtgm.more_frag_flag := FALSE; to_SNP.dtgm.fragment_offset := j*number_frag_blocks; to_SNP.dtgm.total_length := to_SNP.dtgm.header_length*4 + data_in_last_frag; to_SNP.dtgm.data[0..data_in_last_frag-1] := from_ULP[j*data_per_fragment.. (j*data_per_fragment+ data_in_last_frag-1)]; end if; --Call checksum to set the datagram's header checksum field. checksum; --Call route to determine the subnetwork address of the destination. route; --Also set the length and type of service indicators. to_SNP.length := to_SNP.dtgm.total_length; to_SNP.type_of_service_indicators := to_SNP.dtgm.type_of_service; --Request the execution environment to pass this fragment --to the SNP. TRANSFER to_SNP to the local subnetwork protocol. end loop; A fragmentation algorithm may vary according to implementation concerns but every algorithm must meet the following require- ments: 1. A datagram must not be fragmented if dtgm.dont_frag_flag is true. 2. Data must be broken on 8-octet boundaries. System Development Corporation 1 June 1981 -64- IEN 186 3. The minimum fragment size is 68 octets. 4. The first fragment must contain all options carried by the original datagram, except padding and no-op octets. 5. The security, source routing, and stream identification options (i.e. marked with "copy" flag) must be carried by all fragments, if present in the original datagram. 6. The first fragment must have to_SNP.dtgm.fragment_offset set to zero. 7. All fragments, except the last, must have to_SNP.dtgm.more_frag_flag set true. 8. The last fragment must have the to_SNP.dtgm.more_frag_flag set false. System Development Corporation 1 June 1981 -65- IEN 186 6.3.6.3.9 analyze The analyze procedure examines datagrams addressed to IP contain- ing error reports from other IP modules. In general, error han- dling is implementation dependent. However, guidelines are pro- vided to identify classes of errors and suggest appropriate actions. The errors and error formats are defined in section 6.2.15. The data effects of this procedure are: - Data examined: from_SNP.dtgm.protocol from_SNP.data - Data modified: implementation dependent For simplicity, it is assumed that the data area can be accessed as a byte array. The algorithm: --Examine the first and second octets in the data portion --of the error datagram to identify the error reported. case from_SNP.dtgm[1] of when 3 => --Destination Unreachable Message --The errors in the "unreachable" class should --should be passed to the ULP indicating data delivery --to the destination is unlikely if not impossible. case from_SNP.dtgm[2] of when 0 => --net unreachable when 1 => --host unreachable when 2 => --protocol unreachable when 3 => --port unreachable when 5 => --fragmentation needed and don't fragment --flag set end case; when 11 => --Time Exceeded Message System Development Corporation 1 June 1981 -66- IEN 186 --The "time-out" class of errors are usually not passed to the --ULP but should be recorded for network monitoring uses. case from_SNP.dtgm[2] of when 0 => --Time to live exceeded in transit when 1 => --Fragment reassembly time exceeded end case; when 12 => --Parameter Problem Message --This error is generated by a gateway IP to indicate --a problem in the options field of a datagram header. when 4 => --Source Quench Message --This message indicates that a datagram has been --discarded for congestion control. The ULP should --be informed so that traffic can be reduced. when 5 => --Redirect Message --This message should result in a routing table update --by the IP module. It is not passed to the ULP. when 8 => --Echo Datagram --Use of this message is implementation dependent. when 0 => --Echo Reply Datagram --Use of this message is implementation dependent. end case; System Development Corporation 1 June 1981 -67- IEN 186 6.3.6.3.10 error to ULP The error_to_ULP procedure returns an error report to a ULP which has passed invalid parameters or has requested a service that cannot be provided. The data effects of this procedure are: - Parameters: error_param : (PARAM_PROBLEM, CAN'T_FRAGMENT, NET_UNREACH, HOST_UNREACH, PROTOCOL_UNREACH, PORT_UNREACH); - Data examined: implementation dependent - Data modified: to_ULP.error implementation dependent parameters The algorithm: --The format of error reports to a ULP is implementation --dependent. However, included in the report should be --a value indicating the type of error, and some information --to identify the associated data or datagram. to_ULP.error := error_param; --implementation dependent action System Development Corporation 1 June 1981 -68- IEN 186 6.3.6.3.11 error to source The error_to_source procedure formats and returns an error report to the source of an erroneous or expired datagram. The data effects of this procedure are: - Parameters: error_param : (PARAM_PROBLEM, EXPIRED_TTL, HOST_UNREACH, PROTOCOL_UNREACH); - Data examined: from_SNP.dtgm - Data modified: to_SNP.dtgm to_SNP.local_destination_addrs to_SNP.length to_SNP.type_of_service_indicators The algorithm: --Format and transmit an error datagram to the source IP. to_SNP.dtgm.version := 4; --standard IP version to_SNP.dtgm.header_length := 5; --standard header size to_SNP.dtgm.type_of_service := 0; --least quality of service to_SNP.dtgm.identification := select new value; to_SNP.dtgm.more_frag_flag := FALSE; to_SNP.dtgm.dont_frag_flag := FALSE; to_SNP.dtgm.fragment_offset := 0; to_SNP.dtgm.time_to_live := 60; --or value large enough to --allow delivery to_SNP.dtgm.protocol := 3; --Gateway-Gateway Protocol ID to_SNP.dtgm.source_addr := from_SNP.dtgm.destination_addr; to_SNP.dtgm.destination_addr := from_SNP.dtgm.source_addr; --The data section carries the error message in the first four --bytes, and the header and first 64 bytes of data of the --bad datagram. case error_param of where PARAM_PROBLEM => to_SNP.dtgm.data[0] := 12; --Gateway type = Parameter Problem to_SNP.dtgm.data[1] := 0; --Code = problem with option where EXPIRED_TTL => to_SNP.dtgm.data[0] := 11; --Gateway type = Time Exceeded to_SNP.dtgm.data[1] := 0; --Code = TTL exceed in transit System Development Corporation 1 June 1981 -69- IEN 186 where HOST_UNREACH => to_SNP.dtgm.data[0] := 3; --Gateway type = Dest. Unreachable to_SNP.dtgm.data[1] := 1; --Code = host unreachable where PROTOCOL_UNREACH => to_SNP.dtgm.data[0] := 3; --Gateway type = Dest. Unreachable to_SNP.dtgm.data[1] := 2; --Code = protocol unreachable end case; --Below, N is assumed to be the length of the bad datagram's header --plus the first 64 bytes of its data section ( 84 <= N <= 124); to_SNP.dtgm.data[4..N+3] := from_SNP.dtgm[0..N-1]; to_SNP.dtgm.total_length := to_SNP.header_length*4 + N; --Compute checksum, determine the route for the error datagram, --the type of service indicators, and the datagram size for the SNP. compute_checksum; to_SNP.type_of_service_indicators := 0; to_SNP.length := to_SNP.dtgm.total_length; route; --Request the execution environment to pass the contents of to_SNP --to the local subnet protocol for transmission. TRANSFER to_SNP to the SNP. System Development Corporation 1 June 1981 -70- IEN 186 6.3.6.3.12 reassembly timeout The reassembly_timeout procedure generates an error datagram to the source IP informing it of the datagram's expiration during reassembly. The data effects of the procedure are: - Data examined: state_vector.header state_vector.data - Data modified: to_SNP.dtgm to_SNP.length to_SNP.type_of_service_indicators to_SNP.local_destination_addrs The algorithm: --Format and transmit an error datagram to the source IP. to_SNP.dtgm.version := 4; --standard IP version to_SNP.dtgm.header_length := 5; --standard header size to_SNP.dtgm.type_of_service := 0; --least quality of service to_SNP.dtgm.identification := new value selected; to_SNP.dtgm.more_frag_flag := FALSE; to_SNP.dtgm.dont_frag_flag := FALSE; to_SNP.dtgm.fragment_offset := 0; to_SNP.dtgm.time_to_live := 60; to_SNP.dtgm.protocol := 3; --Gateway-Gateway Protocol ID to_SNP.dtgm.source_addr := state_vector.header.destination_addr; to_SNP.dtgm.destination_addr := state_vector.header.source_addr; --The data section carries the error message in the first four --bytes, and the header and first 64 bytes of data of the --timed-out datagram. to_SNP.dtgm.data[0] := 12; --Gateway type = Time Exceeded to_SNP.dtgm.data[1] := 1; --Code = fragment reassembly timeout --Below, N is assumed to be the length of the expired datagram's header --plus the first 64 bytes of its data section ( 84 <= N <= 124 ). to_SNP.dtgm.data[4..N+3] := state_vector.data[0..N-1]; to_SNP.dtgm.total_length := to_SNP.header_length*4 + N; --Compute checksum, determine the route for the error datagram, --the type of service indicators, and the datagram size for the SNP. System Development Corporation 1 June 1981 -71- IEN 186 compute_checksum; to_SNP.type_of_service_indicators := 0; to_SNP.length := to_SNP.dtgm.total_length; route; --Request the execution environment to pass the contents of to_SNP --to the local subnet protocol for transmission. TRANSFER to_SNP to the SNP. System Development Corporation 1 June 1981 -72- IEN 186 7. EXECUTION ENVIRONMENT REQUIREMENTS This section describes the facilities required of an execution environment for proper implementation and operation of the Inter- net Protocol. Throughout this document, the environmental model portrays each protocol as an independent process. Within this model, the execution environment must provide two facilities: inter-process communication and timing. 7.1 Inter-process communication The execution environment must provide an inter-process communi- cation facility to enable independent processes to exchange variable-length units of information, called messages. For IP's purposes, the IPC facility is not required to preserve the order of messages. IP uses the IPC facility to exchange interface parameters and data with upper layer protocols across its upper interface and the subnetwork protocol across the lower interface. Sections 3 and 5 specify these interfaces. 7.2 Timing The execution environment must provide a timing facility that maintains a real-time clock with units no coarser than 1 mil- lisecond. A process must be able to set a timer for a specific time period and be informed by the execution environment when the time period has elapsed. A process must also be able to cancel a previously set timer. Two IP mechanisms use the timing facility. The internet times- tamp carries timing data in millisecond units. The reassembly mechanism uses timers to limit the lifetime of a datagram being reassembled. In the mechanism specification this facility is called TIMEOUT. System Development Corporation 1 June 1981 -73- IEN 186 8. BIBLIOGRAPHY 1. "DCEC Protocols Standardization Program Preliminary Archi- tecture Report" TM-7038/200/00, Contract No. DCA100-80-C- 0044, February 1981. 2. "Protocol Specification Guidelines", TM-7038/204/00, Con- tract No. DCA100-80-C-0044, June 1981. 3. V. Cerf and R. Kahn, "A Protocol for Packet Network Inter- connection", IEEE Transactions on Communications, May 1974. 4. J. Postel (ed.), "DoD Standard Internet Protocol", Defense Advanced Research Projects Agency, Information Processing Techniques Office, RFC760, IEN128, January 1980. 5. J. Postel (ed.), "DoD Standard Transmission Control Proto- col", Defense Advanced Research Projects Agency, Information Processing Techniques Office, RFC761, IEN129, January 1980. 6. V. Cerf and P. Kirstein, "Issues in Packet-Network Intercon- nection", Proceedings of the IEEE, November 1978, pp.1386- 1408. 7. P.T. Kelly, "Public Packet Switched Data Networks, Interna- tional Plans and Standards", Proceedings of the IEEE, November 1978, pp.1539-1549. 8. D. Boggs, J. Shoch, E. Taft, and R. Metcalfe, "Pup: An Internetwork Architecture", IEEE Transactions on Communica- tions, April 1980, pp.612-624. 9. J. Postel, "Internetwork Protocol Approaches", IEEE Transac- tions on Communications, April 1980, pp.604-611. 10. J. Shoch, "Inter-Network Naming, Addressing, and Routing", COMPCON, IEEE Computer Society, Fall 1978. 11. J. Shoch, "Packet Fragmentation in Inter-Network Protocols", Computer Networks, vol.3, no.1, February 1979. 12. J. Postel, "Address Mappings", IEN 115, USC/Information Sci- ences Institute, August 1979. 13. J. Postel, "Assigned Numbers", RFC 762, IEN 127, USC/Information Sciences Institute, January 1980. System Development Corporation 1 June 1981 -74- IEN 186 9. GLOSSARY Destination An IP header field containing an internet address indicating where a datagram is to be sent. datagram A self-contained package of data carrying enough information to be routed from source to destination without reliance on earlier exchanges between source or destination and the transporting sub- network. datagram fragment The result of fragmenting a datagram, also simply referred to as a fragment. A datagram fragment carries a portion of data from the larger original, and a copy of the original datagram header. The header fragmentation fields are adjusted to indicate the fragment's relative position within the original datagram. datagram service A datagram, defined above, delivered in such a way that the receiver can determine the boundaries of the datagram as it was entered by the source. A datagram is delivered with non-zero probability to the desired destination. The sequence in which datagrams are entered into the subnetwork by a source is not necessarily preserved upon delivery at the destination. DF Don't Fragment flag: An IP header field that when set true prohi- bits an IP module from fragmenting a datagram to accomplish delivery. fragmentation The process of breaking the data within a datagram into smaller pieces and attaching new internet headers to form smaller datagrams. Fragment Offset A field in the IP header marking the relative position of a datagram fragment within the larger original datagram. gateway A device, or pair of devices, which interconnect two or more sub- networks enabling the passage of data from one subnetwork to another. In this architecture, a gateway usually contains an IP module, a Gateway-to-Gateway Protocol (GGP) module, and a subnet- work protocol module (SNP) for each connected subnetwork. header Collection of control information transmitted with data between peer entities. System Development Corporation 1 June 1981 -75- IEN 186 host A computer which is a source or destination of messages from the point of view of the communication subnetwork. Identification An IP header field used in reassembling fragments of a datagram. IHL Internet Header Length: an IP header field indicating the number of 32-bit words making up the internet header. Internet address A four octet (32 bit) source or destination address composed of a Network field and a REST field. The latter usually contains a local subnetwork address. internet datagram The package exchanged between a pair of IP modules. It is made up of an IP header and a data portion. local address The address of a host within a subnetwork. The actual mapping of an internet address onto local subnetwork addresses is quite gen- eral, allowing for many to one mappings. local subnetwork The subnetwork directly attached to host or gateway. MF More Fragments flag: an IP header field indicating whether a datagram fragment contains the end of a datagram. module An implementation, usually in software, of a protocol or other procedure. MTU Maximum Transmission Unit: a subnetwork dependent value which indicates the largest datagram that a subnetwork can handle. octet An eight bit byte. Options The optional set of fields at the end of the IP header used to carry control or routing data. An Options field may contain none, one, or several options, and each option may be one to several octets in length. The options allow ULPs to customize IP's services. The options are also useful in testing situations to carry diagnostic data such as timestamps. System Development Corporation 1 June 1981 -76- IEN 186 packet The unit of data transmitted by a packet-switched network. A packet usually contains nested control information and data from the upper layer protocols using the subnetwork. packet network A network based on packet-switching technology. Messages are split into small units (packets) to be routed independently on a store and forward basis. This packetizing pipelines packet transmission to effectively use circuit bandwidth. Padding An IP header field, an octet in length, inserted after the last option field to ensure that the data portion of a datagram begins on a 32-bit word boundary. The Padding field value is zero. Protocol An internet header field used to identify the upper layer proto- col that is the source and destination of the data within an IP datagram. Precedence One of the service quality parameters provided by the type of service mechanism. Precedence is a relative measure of datagram importance. This parameter can be set to one of five levels: routine, priority, immediate, flash, or flash override. It appears as a three bit field within the Type of Service field in the IP header. reassembly The process of piecing together datagram fragments to reproduce the original large datagram. Reassembly is based on fragmentation data carried in their IP headers. Reliability One of the service quality parameters provided by the type of service mechanism. The reliability parameter can be set to one of four levels: lowest, lower, higher, or highest. It appears as a two bit field within the Type of Service field in the IP header. reliability A quality of data transmission defined as guaranteed, ordered delivery. Rest The three octet field of the internet address usually containing a local address. segment The unit of data exchanged by TCP modules. This term may also be used to describe the unit of exchange between any transport System Development Corporation 1 June 1981 -77- IEN 186 protocol modules. Source An IP header field containing the internet address of the datagram's point of origin. stream delivery service The special handling required for a class of volatile periodic traffic typified by voice. The class requires the maximum acceptable delay to be only slightly larger than the minimum pro- pagation time, or requires the allowable variance in packet interarrival time to be small. SNP SubNetwork Protocol: the protocol residing in the subnetwork layer below IP which provides data transfer through the local subnet. In some systems, an adaptor module must be inserted between IP and the subnetwork protocol to reconcile their dis- similar interfaces. TCP Transmission Control Protocol: a transport protocol providing connection-oriented, end-to-end reliable data transmission in packet-switched computer subnetworks and internetworks. TCP segment The unit of data exchanged between TCP modules (including the TCP header). Total Length An IP header field containing the number of octets in an internet datagram, including both the IP header and the data portion. Type of Service An IP header field containing the transmission quality parame- ters: precedence level, reliability level, speed level, resource trade-off (precedence vs. reliability), and transmission mode (datagram vs. stream). This field is used by the type of service mechanism which allows ULPs to select the quality of transmission for a datagram through the internet. ULP Upper Layer Protocol: any protocol above IP in the layered proto- col hierarchy that uses IP. This term includes transport layer protocols, presentation layer protocols, session layer protocols, and application programs. user A generic term identifying a process or person employing a proto- col. In IP's case, this term may describe a transport protocol, a presentation layer protocol, a session layer protocol, or an application program. System Development Corporation 1 June 1981 -78- IEN 186 Version An IP header field indicating the format of the IP header.