Movatterモバイル変換
[0]ホーム
[RFC Home] [TEXT|PDF|HTML] [Tracker] [IPR] [Info page]
Obsoleted by:851 UNKNOWN
RFC 802: The ARPANET 1822L Host Access Protocol Andrew G. Malis Netmail: malis@bbn-unix Bolt Beranek and Newman Inc. November 1981
RFC 802 Andrew G. Malis Table of Contents1 INTRODUCTION..........................................12 THE ARPANET 1822L HOST ACCESS PROTOCOL................42.1 Addresses and Names.................................62.2 Name Authorization and Effectiveness................82.3 Uncontrolled Messages..............................142.4 The Short-Blocking Feature.........................152.4.1 Host Blocking....................................162.4.2 Reasons for Host Blockage........................192.5 Establishing Host-IMP Communications...............223 1822L LEADER FORMATS.................................253.1 Host-to-IMP 1822L Leader Format....................263.2 IMP-to-Host 1822L Leader Format....................344 REFERENCES...........................................42 - i -
RFC 802 Andrew G. Malis FIGURES1822 Address Format.......................................61822L Name Format.........................................71822L Address Format......................................7Communications between different host types..............13Host-to-IMP 1822L Leader Format..........................27NDM Message Format.......................................30IMP-to-Host 1822L Leader Format..........................35 - ii -
RFC 802 Andrew G. Malis1 INTRODUCTIONThis document proposes two major changes to the current ARPANEThost access protocol. The first change will allow hosts to uselogical addressing (i.e., host addresses that are independent oftheir physical location on the ARPANET) to communicate with eachother, and the second will allow a host to shorten the amount oftime that it may be blocked by its IMP after it presents amessage to the network (currently, the IMP can block furtherinput from a host for up to 15 seconds).The new host access protocol is known as the ARPANET 1822L (forLogical) Host Access Protocol, and it represents an addition tothe current ARPANET 1822 Host Access Protocol, which is describedin sections 3.3 and 3.4 of BBN Report 1822 [1]. Although the1822L protocol uses different Host-IMP leaders than the 1822protocol, hosts using either protocol can readily communicatewith each other (the IMPs handle the translation automatically).The new option for shortening the host blocking timeout is calledthe short-blocking feature, and it replaces the non-blocking hostinterface described insection 3.7 of Report 1822. This featurewill be available to all hosts on C/30 IMPs (see the nextparagraph), regardless of whether they use the 1822 or 1822Lprotocol. - 1 -
RFC 802 Andrew G. MalisThere is one major restriction to the new capabilities beingdescribed. Both the 1822L protocol and the short-blockingfeature will be implemented on C/30 IMPs only, and will thereforeonly be useable by hosts connected to C/30 IMPs, as the Honeywelland Pluribus IMPs do not have sufficient memory to hold the newprograms and tables. This restriction also means that logicaladdressing cannot be used to address a host on a non-C/30 IMP.However, the ARPANET will shortly be completely converted to C/30IMPs, and at that time this restriction will no longer be aproblem.I will try to keep my terminology consistent with that used inReport 1822, and will define new terms when they are first used.Of course, familiarity with Report 1822 (section 3 in particular)is assumed.This document makes many references to Report 1822. As aconvenient abbreviation, I will use "see 1822(x)" instead of"please refer to Report 1822, section x, for further details".This document is a proposal, not a description of an implementedsystem. Thus, described features are subject to change basedupon responses to this document and restrictions that becomeevident during implementation. However, any such changes areexpected to be minor. A new RFC will be made available once the - 2 -
RFC 802 Andrew G. Malisimplementation is complete containing the actual as-implementeddescription.Finally, I would like to thank Dr. Eric C. Rosen, who wrote mostofsection 2.4, and James G. Herman, Dr. Paul J. Santos Jr., JohnF. Haverty, and Robert M. Hinden, all of BBN, who contributedmany of the ideas found herein. - 3 -
RFC 802 Andrew G. Malis2 THE ARPANET 1822L HOST ACCESS PROTOCOLThe ARPANET 1822L Host Access Protocol, which replaces theARPANET 1822 Host Access Protocol described in Report 1822,sections3.3 and3.4, allows a host to use logical addressing tocommunicate with other hosts on the ARPANET. Basically, logicaladdressing allows hosts to refer to each other using an 1822Lname (seesection 2.1) which is independent of a host's physicallocation in the network. IEN 183 (also published as BBN Report4473) [2] gives the use of logical addressing considerablejustification. Among the advantages it cites are:o The ability to refer to each host on the network by a name independent of its location on the network.o Allowing different hosts to share the same host port on a time-division basis.o Allowing a host to use multi-homing (where a single host uses more than one port to communicate with the network).o And allowing several hosts that provide the same service to share the same name.The main differences between the 1822 and 1822L protocols are theformat of the leaders that are used to introduce messages between - 4 -
RFC 802 Andrew G. Malisa host and an IMP, and the specification in those leaders of thesource and/or destination host(s). Hosts have the choice ofusing the 1822 or the 1822L protocol. When a host comes up on anIMP, it declares itself to be an 1822 host or an 1822L host hostby the type of NOP message (seesection 3.1) it uses. Once up,hosts can switch from one protocol to the other by issuing anappropriate NOP. Hosts that do not use the 1822L protocol willstill be addressable by and can communicate with hosts that do,and vice-versa.Another difference between the two protocols is that the 1822leaders are symmetric, while the 1822L leaders are not. The termsymmetric means that in the 1822 protocol, the exact same leaderformat is used for messages in both directions between the hostsand IMPs. For example, a leader sent from a host over a cablethat was looped back onto itself (via a looping plug or faultyhardware) would arrive back at the host and appear to be a legalmessage from a real host (the destination host of the originalmessage). In contrast, the 1822L headers are not symmetric, anda host can detect if the connection to its IMP is looped byreceiving a message with the wrong leader format. This allowsthe host to take appropriate action upon detection of the loop. - 5 -
RFC 802 Andrew G. Malis2.1 Addresses and NamesThe 1822 protocol defines one form of host specification, and the1822L protocol defines two additional ways to identify networkhosts. These three forms are 1822 addresses, 1822L names, and1822L addresses.1822 addresses arethe 24-bit host addresses found in 1822leaders. They have the following format: 1 8 9 24 +----------------+---------------------------------+ | | | | Host number | IMP number | | | | +----------------+---------------------------------+ Figure 1. 1822 Address FormatThese fields are quite large, and the ARPANET will never use morethan a fraction of the available address space. 1822 addressesare used in 1822 leaders only.1822L names are 16-bit unsigned numbers that serve as a logicalidentifier for one or more hosts. 1822L names have a muchsimpler format: - 6 -
RFC 802 Andrew G. Malis 1 16 +--------------------------------+ | | | 1822L name | | | +--------------------------------+ Figure 2. 1822L Name FormatThe 1822L names are just 16-bit unsigned numbers, except thatbits 1 and 2 are not both zeros (see below). This allows over49,000 hosts to be specified.1822 addresses cannot be used in 1822L leaders, but there maybea requirement for an 1822L host to be able to address a specificphysical host port or IMP fake host. 1822L addresses are usedfor this function. 1822L addresses form a subset of the 1822Lname space, and have both bits 1 and 2 off. 1 2 3 8 9 16 +---+---+------------+----------------+ | | | | | | 0 | 0 | host # | IMP number | | | | | | +---+---+------------+----------------+ Figure 3. 1822L Address Format - 7 -
RFC 802 Andrew G. MalisThis format gives 1822L hosts the ability to directly addresshosts 0-59 at IMPs 1-255 (IMP 0 does not exist). Host numbers60-63 are reserved for addressing the four fake hosts at eachIMP.2.2 Name Authorization and EffectivenessEvery host on a C/30 IMP, regardless of whether it is using the1822 or 1822L protocol to access the network, will be assigned atleast one 1822L name (logical address). Other 1822L hosts willuse this name to address the host, wherever it may be physicallylocated. Because of the implementation constraints mentioned inthe introduction, hosts on non-C/30 IMPs cannot be assigned 1822Lnames. To circumvent this restriction, however, 1822L hosts canuse 1822L addresses to access all other hosts on the network, nomatter where they reside.At this point, several questions arise: How are these namesassigned, how do they become known to the IMPs (so thattranslations to physical addresses can be made), and how do theIMPs know which host is currently using a shared port? To answereach question in order: - 8 -
RFC 802 Andrew G. MalisNames are assigned by a central network administrator. When eachname is created, it is assigned to a host (or a group of hosts)at one or more specific host ports. The host(s) are allowed toreside at those specific host ports, and nowhere else. If a hostmoves, it will keep the same name, but the administrator has toupdate the central database to reflect the new host port.Changes to this database are distributed to the IMPs by theNetwork Operations Center (NOC) at BBN. For a while, the hostmay be allowed to reside at either of (or both) the new and oldports. Once the correspondence between a name and one or morehosts ports where it may be used has been made official by theadministrator, that name is said to be authorized. 1822Laddresses, which actually refer to physical host ports, arealways authorized in this sense.Once a host has been assigned one or more names, it has to letthe IMPs know where it is and what name(s) it is using. Thereare two cases to consider, one for 1822L hosts and another for1822 hosts. The following discussion only pertains to hosts onC/30 IMPs.When an IMP sees an 1822L host come up on a host port, the IMPhas no way of knowing which host has just come up (several hostsmay share the same port, or one host may prefer to be known by - 9 -
RFC 802 Andrew G. Malisdifferent names at different times). This requires the host tolet the IMP know what is happening before it can actually sendand receive messages. This function is performed by a new host-to-IMP message, the Name Declaration Message (NDM), which liststhe names that the host would like to be known by. The IMPchecks its tables to see if each of the names is authorized, andsends an NDM Reply to the host saying which names in the list canbe used for sending and receiving messages (i.e., which names areeffective). A host can also use an NDM message to change its listof effective addresses (it can add to and delete from the list)at any time. The only constraint on the host is that any namesit wishes to use can become effective only if they areauthorized.In the second case, if a host comes up on a C/30 IMP using the1822 protocol, the IMP automatically makes the first name the IMPfinds in its tables for that host become effective. Thus, eventhough the host is using the 1822 protocol, it can still receivemessages from 1822L hosts via its 1822L name. Of course, it canalso receive messages from an 1822L host via its 1822L address aswell. (Remember, the distinction between 1822L names andaddresses is that the addresses correspond to physical locationson the network, while the names are strictly logicalidentifiers). The IMPs translate between the different leaders - 10 -
RFC 802 Andrew G. Malisand send the proper leader in each case (more on this below).The third question above has by now already been answered. Whenan 1822L host comes up, it uses the NDM message to tell the IMPwhich host it is (which names it is known by). Even if this is ashared port, the IMP knows which host is currently connected.Whenever a host goes down, its names automatically become non-effective. When it comes back up, it has to make them effectiveagain.Several hosts can share the same 1822L name. If more than one ofthese hosts is up at the same time, any messages sent to that1822L name will be delivered to just one of the hosts sharingthat name, and a RFNM will be returned as usual. However, thesending host will not receive any indication of which hostreceived the message, and subsequent messages to that name arenot guaranteed to be sent to the same host. Typically, hostsproviding exactly the same service could share the same 1822Lname in this manner.Similarly, when a host is multi-homed, the same 1822L name mayrefer to more than one host port (all connected to the samehost). If the host is up on only one of those ports, that portwill be used for all messages addressed to it. However, if the - 11 -
RFC 802 Andrew G. Malishost were up on more than one port, the message would bedelivered over just one of those ports, and the subnet wouldchoose which port to use. This port selection could change frommessage to message. If a host wanted to insure that certainmessages were delivered to it on specific ports, these messagescould use either the port's 1822L address or a specific 1822Lname that referred to that port alone.Some further details are required on communications between 1822and 1822L hosts. Obviously, when 1822 hosts converse, or when1822L hosts converse, no conversions between leaders and addressformats are required. However, this becomes more complicatedwhen 1822 and 1822L hosts converse with each other.The following figure illustrates how these addressingcombinations are handled, showing how each type of host canaccess every other type of host. There are three types of hosts:"1822 on C/30" signifies an 1822 host that is on a C/30 IMP,"1822L" signifies an 1822L host (on a C/30 IMP), and "1822 onnon-C/30" signifies a host on an non-C/30 IMP (which cannotsupport the 1822L protocol). The table entry shows the protocoland host address format(s) that the source host can use to reachthe destination host. - 12 -
RFC 802 Andrew G. Malis Destination Host Source Host | 1822 on C/30 | 1822L | 1822 on non-C/30 --------+----------------+----------------+----------------- | | | 1822 on | 1822 | 1822 | 1822 C/30 | | (note 1) | | | | --------+----------------+----------------+----------------- | | | | 1822L, using | 1822L, using | 1822L, using 1822L | 1822L name or | 1822L name or | 1822L address |address (note 2)| address | only (note 2) | | | --------+----------------+----------------+----------------- | | | 1822 on | 1822 | 1822 | 1822 non-C/30| | (note 1) | | | | --------+----------------+----------------+----------------- Note 1: The message is presented to the destination host with an 1822L leader containing the 1822L addresses of the source and destination hosts. If either address cannot be encoded as an 1822L address, then the message is not delivered and and error message is sent to the source host. Note 2: The message is presented to the destination host with an 1822 leader containing the 1822 address of the source host. Figure 4. Communications between different host types - 13 -
RFC 802 Andrew G. Malis2.3 Uncontrolled MessagesUncontrolled messages (see 1822(3.6)) present a unique problemfor the 1822L protocol. Uncontrolled messages use none of thenormal ordering and error-control mechanisms in the IMP, and donot use the normal subnetwork connection facilities. As aresult, uncontrolled messages need to carry all of their overheadwith them, including source and destination addresses. If 1822Laddresses are used when sending an uncontrolled message,additional information is now required by the subnetwork when themessage is transferred to the destination IMP. This means thatless host-to-host data can be contained in the message than ispossible between 1822 hosts.Uncontrolled messages that are sent between 1822 hosts maycontain not more than 991 bits of data. Uncontrolled messagesthat are sent to and/or from 1822L hosts are limited to 32 bitsless, or not more than 959 bits. Messages that exceed thislength will result in an error indication to the host, and themessage will not be sent. This error indication represents anenhancement to the previous level of service provided by the IMP,which would simply discard an overly long uncontrolled messagewithout notification. - 14 -
RFC 802 Andrew G. MalisOther enhancements that are provided for uncontrolled messageservice are a notification to the host of any message-relatederrors that are detected by the host's IMP when it receives themessage. A host will be notified if an uncontrolled messagecontains an error in the 1822L name specification, such as thename not being authorized or effective, or if the remote host isunreachable (which is indicated by none of its names beingeffective), or if network congestion control throttled themessage before it left the source IMP. The host will not benotified if the uncontrolled message was lost for some reasononce it was transmitted by the source IMP.2.4 The Short-Blocking FeatureThe short-blocking feature of the 1822 and 1822L protocols isdesigned to allow a host to present messages to the IMP withoutcausing the IMP to not accept further messages from the host forlong amounts of time (up to 15 seconds). It is a replacement forthe non-blocking host interface described in 1822(3.7), and thatdescription should be ignored. - 15 -
RFC 802 Andrew G. Malis2.4.1 Host BlockingMost commonly, when a source host submits a message to an IMP,the IMP immediately processes that message and sends it on itsway to its destination host. Sometimes, however, the IMP is notable to process the message immediately. Processing a messagerequires a significant number of resources, and when the networkis heavily loaded, there can sometimes be a long delay before thenecessary resources become available. In such cases, the IMPmust make a decision as to what to do while it is attempting togather the resources.One possibility is for the IMP to stop accepting messages fromthe source host until it has gathered the resources needed toprocess the message just submitted. This strategy is known asblocking the host, and is basically the strategy that has beenused in the ARPANET up to the present. When a host submits amessage to an IMP, all further transmissions from that host tothat IMP are blocked until the message can be processed.It is important to note, however, that not all messages requirethe same set of resources in order to be processed by the IMP.The particular set of resources needed will depend on the messagetype, the message length, and the destination host of the message(see below). Therefore, although it might take a long time to - 16 -
RFC 802 Andrew G. Malisgather the resources needed to process some particular message,it might take only a short time to gather the resources needed toprocess some other message. This fact exposes a significantdisadvantage in the strategy of blocking the host. A host whichis blocked may have many other messages to submit which, if onlythey could be submitted, could be processed immediately. It is"unfair" for the IMP to refuse to accept these message until ithas gathered the resources for some other, unrelated message.Why should messages for which the IMP has plenty of resources bedelayed for an arbitrarily long amount of time just because theIMP lacks the resources needed for some other message?A simple way to alleviate the problem would be to place a limiton the amount of time during which a host can be blocked. Thisamount of time should be long enough so that, in mostcircumstances, the IMP will be able to gather the resourcesneeded to process the message within the given time period. If,however, the resources cannot be gathered in this period of time,the IMP will flush the message, sending a reply to the sourcehost indicating that the message was not processed, andspecifying the reason that it could not be processed. However,the resource gathering process would continue. The intention isthat the host resubmit the message in a short time, when,hopefully, the resource gathering process has concluded - 17 -
RFC 802 Andrew G. Malissuccessfully. In the meantime, the host can submit othermessages, which may be processed sooner. This strategy does noteliminate the phenomenon of host blocking, but only limits thetime during which a host is blocked. This shorter time limitwill generally fall somewhere in the range of 100 milliseconds to2 seconds,with its value possibly depending on the reason forthe blocking.Note, however, that there is a disadvantage to having shortblocking times. Let us say that the IMP accepts a message if ithas all the resources needed to process it. The ARPANET providesa sequential delivery service, whereby messages with the samepriority, source host, and destination host are delivered to thedestination host in the same order as they are accepted from thesource host. With short blocking times, however, the order inwhich the IMP accepts messages from the source host need not bethe same as the order in which the source host originallysubmitted the messages. Since the two data streams (one in eachdirection) between the host and the IMP are not synchronized, thehost may not receive the reply to a rejected message before itsubmits subsequent messages of the same priority for the samedestination host. If a subsequent message is accepted, the orderof acceptance differs from the order of original submission, andthe ARPANET will not provide the same type of sequential delivery - 18 -
RFC 802 Andrew G. Malisthat it has in the past.Up to now, type 0 (regular) messages have only had sub-typesavailable to request the standard blocking timeout. The short-blocking feature makes available new sub-types that allow thehost to request messages to be short-blocking, i.e. only causethe host to be blocked for a short amount of time if the messagecannot be immediately processed. Seesection 3.1 for a completelist of the available sub-types.If sequential delivery by the subnet is a strict requirement, aswould be the case for messages produced by NCP, the short-blocking feature cannot be used. For messages produced by TCP,however, the use of the short-blocking feature is allowed andrecommended.2.4.2 Reasons for Host BlockageThere are a number of reasons why a message could cause a longblockage in the IMP, which would result in the rejection of ashort-blocking message. The IMP signals this rejection of ashort-blocking message by using the Incomplete Transmission (Type9) message, using the sub-type field to indicate which of theabove reasons caused the rejection of the message. See section - 19 -
RFC 802 Andrew G. Malis3.2 for a summary of the Incomplete Transmissionmessage and acomplete list of its sub-types. The sub-types that apply to theshort-blocking feature are:6. Connection setup-delay: Although the IMPpresents a simple message-at-a-time interface to the host, it provides an internal connection-oriented (virtual circuit) service, except in the case of uncontrolled messages (seesection2.3). Two messages are considered to be on the same connection if they have the same source host (i.e., they are submitted to the same IMP over the same host interface), the same priority, and the same destination host name or address. The subnet maintains internal connection set-up and tear-down procedures. Connections are set up as needed, and are torn down only after a period of inactivity. Occasionally, network congestion or resource shortage will cause a lengthy delay in connection set-up. During this period, no messages for that connection can be accepted, but other messages can be accepted.7. End-to-end flowcontrol: For every message that a host submits to an IMP (except uncontrolled messages) the IMP eventually returns a reply to the host indicating the disposition of the message. Between the time that the - 20 -
RFC 802 Andrew G. Malis message is submitted and the time the host receives the reply, the message is said to be outstanding. The ARPANET allows only eight outstanding messages on any given connection. If there are eight outstanding messages on a given connection, and a ninth is submitted, it cannot the accepted. If a message is refused because its connection is blocked due to flow control, messages on other connections can still be accepted. End-to-end flow control is the most common cause of host blocking in the ARPANET at present.8. Destination IMP buffer space shortage: If the host submitsa message of more than 1008 bits (exclusive of the 96-bit leader), buffer space at the destination IMP must be reserved before the message can be accepted. Buffer space at the destination IMP is always reserved on a per-connection basis. If the destination IMP is heavily loaded, there may be a lengthy wait for the buffer space; this is another common cause of blocking in the present ARPANET. Messages are rejected for this reason based on their length and connection; messages of 1008 or fewer bits or messages for other connections may still be acceptable. - 21 -
RFC 802 Andrew G. Malis9. Congestion control: A message may be refused forreasons of congestion control if the path via the intermediate IMPs and lines to the destination IMP is too heavily loaded to handle additional traffic. Messages to other destinations may be acceptable, however.10. Local resource shortage: Sometimes the source IMP itselfis short of buffer space, table entries, or some other resource that it needs to accept a message. Unlike the other reasons for message rejection, this resource shortage will affect all messages equally, except for uncontrolled messages. The message's size or connection is not relevant.The short-blocking feature is available to all hosts on C/30IMPs, whether they are using the 1822 or 1822L protocol, throughthe use of Type 0, sub-type 1 and 2 messages. A host using thesesub-types should be prepared to correctly handle IncompleteTransmission messages from the IMP.2.5 Establishing Host-IMP CommunicationsWhen a host comes up on an IMP, or after there has been a breakin the communications between the host and its IMP (see1822(3.2)), the orderly flow of messages between the host and the - 22 -
RFC 802 Andrew G. MalisIMP needs to be properly (re)established. This allows the IMPand host to recover from most any failure in the other or intheir communications path, including a break in mid-message.The first messages that a host should send to its IMP are threeNOP messages. Three messages are required to insure that atleast one message will be properly read by the IMP (the first NOPcould be concatenated to a previous message if communications hadbeen broken in mid-stream, and the third provides redundancy forthe second). These NOPs serve several functions: theysynchronize the IMP with the host, they tell the IMP how muchpadding the host requires between the message leader and itsbody, and they also tell the IMP whether the host will be using1822 or 1822L leaders.Similarly, the IMP will send three NOPs to the host when itdetects that the host has come up. Actually, the IMP will sendsix NOPs, alternating three 1822 NOPs with three 1822L NOPs.Thus, the host will see three NOPs no matter which protocol it isusing. The NOPs will be followed by two Interface Resetmessages, one of each style. If the IMP receives a NOP from thehost while the above sequence is occurring, the IMP will onlysend the remainder of the NOPs and the Interface Reset in theproper style. The 1822 NOPs will contain the 1822 address of the - 23 -
RFC 802 Andrew G. Malishost interface, and the 1822L NOPs will contain the corresponding1822L address.Once the IMP and the host have sent each other the abovemessages, regular communications can commence. See 1822(3.2) forfurther details concerning the ready line, host tardiness, andother issues. - 24 -
RFC 802 Andrew G. Malis3 1822L LEADER FORMATSThe following sections describe the formats of the leaders thatprecede messages between an 1822L host and its IMP. They weredesigned to be as compatible with the 1822 leaders as possible.The second, fifth, and sixth words are identical in the twoleaders, and all of the existing functionality of the 1822leaders has been retained. The first difference one will note isin the first word. The 1822 New Format Flag is now also used toidentify the two types of 1822L leaders, and the Handling Typehas been moved to the second byte. The third and fourth wordscontain the Source and Destination 1822L Name, respectively. - 25 -
RFC 802 Andrew G. Malis3.1 Host-to-IMP 1822L Leader Format 1 4 5 8 9 16 +--------+--------+----------------+ | | 1822L | | | Unused | H2I | Handling Type | | | Flag | | +--------+--------+----------------+ 17 20 21 22 24 25 32 +--------+-+------+----------------+ | |T|Leader| | | Unused |R|Flags | Message Type | | |C| | | +--------+-+------+----------------+ 33 48 +----------------------------------+ | | | Source Host | | | +----------------------------------+ 49 64 +----------------------------------+ | | | Destination Host | | | +----------------------------------+ 65 76 77 80 +-------------------------+--------+ | | | | Message ID |Sub-type| | | | +-------------------------+--------+ 81 96 +----------------------------------+ | | | Unused | | | +----------------------------------+ Figure 5. Host-to-IMP 1822L Leader Format - 26 -
RFC 802 Andrew G. MalisBits 1-4: Unused, must be set to zero.Bits 5-8: 1822L Host-to-IMP Flag: This field is set to decimal 13 (1101 in binary).Bits 9-16: Handling Type: This field is bit-coded to indicate the transmission characteristics of the connection desired by the host. See 1822(3.3). Bit 9: Priority Bit: Messages with this bit on will be treated as priority messages. Bits 10-16: Unused, must be zero.Bits 17-20: Unused, must be zero.Bit 21: Trace Bit: If equal to one, this message is designated for tracing as it proceeds through the network. See 1822(5.5).Bits 22-24: Leader Flags: Bit 22: A flag available for use by the destination host. See 1822(3.3) for a description of its use by the IMP's TTY fake host. Bits 23-24: Reserved for future use, must be zero. - 27 -
RFC 802 Andrew G. MalisBits 25-32: Message Type: Type 0: Regular Message - All host-to-host communication occurs via regular messages, which have several sub- types, found in bits 77-80. These sub-types are: 0: Standard - The IMP uses its full message and error control facilities, and host blocking (seesection2.4) may occur. 1: Standard, short-blocking - Seesection 2.4. 2: Uncontrolled, short-blocking - Seesection 2.4. 3: Uncontrolled - The IMP will perform no message- control functions for this type of message, and network flow and congestion control (seesection2.4) may cause loss of the message. Also see 1822(3.6) andsection 2.3. 4-15: Unassigned. Type 1: Error Without Message ID - See 1822(3.3). Type 2: Host Going Down - see 1822(3.3). Type 3: Name Declaration Message (NDM) - This message is used by the host to declare which of its 1822L names is or is not effective (seesection 2.2), or to make all of its names non-effective. The first 16 bits of the data portion of the NDM message, following the leader and any padding, contains the number of 1822L name - 28 -
RFC 802 Andrew G. Malis entries contained in the message. This is followed by the 1822L name entries, each 32 bits long, of which the first 16 bits is a 1822L name and the second 16 bits contains either of the integers zero or one. Zero indicates that the name should not be effective, and one indicates that the name should be effective. The IMP will reply with a NDM Reply message (seesection3.2) indicating which of the names are now effective and which are not. Pictorially, a NDM message has the following format (including the leader, which is printed in hexadecimal): - 29 -
RFC 802 Andrew G. Malis 1 16 17 32 33 48 +----------------+----------------+----------------+ | | | | | 0D00 | 0003 | 0000 | | | | | +----------------+----------------+----------------+ 49 64 65 80 81 96 +----------------+----------------+----------------+ | | | | | 0000 | 0000 | 0000 | | | | | +----------------+----------------+----------------+ 97 112 113 128 129 144 +----------------+----------------+----------------+ | | | | | # of entries | 1822L name #1 | 0 or 1 | | | | | +----------------+----------------+----------------+ 145 160 161 176 +----------------+----------------+ | | | | 1822L name #2 | 0 or 1 | etc. | | | +----------------+----------------+ Figure 6. NDM Message Format An NDM with zero entries will cause all current effective names for the host to become non-effective. Type 4: NOP - This allows the IMP to know which style of leader the host wishes to use. A 1822L NOP signifies that the host wishes to use 1822L leaders, and an 1822 NOP signifies that the host wishes to use 1822 leaders. All of the other remarks concerning the NOP message in - 30 -
RFC 802 Andrew G. Malis 1822(3.3) still hold. The host should always issue NOPs in groups of three to insure proper reception by the IMP. Also seesection 2.5 for a further discussion on the use of the NOP message. Type 8: Error with Message ID - see 1822(3.3). Types 5-7,9-255: Unassigned.Bits 33-48: Source Host: This field contains one of the source host's 1822L names (or, alternatively, the 1822L address of the host port the message is being sent over). This field is not automatically filled in by the IMP, as in the 1822 protocol, because the host may be known by several names and may wish to use a particular name as the source of this message. All messages from the same host need not use the same name in this field. Each source name, when used, is checked for authorization, effectiveness, and actually belonging to this host. Messages using names that do not satisfy all of these requirements will not be delivered, and will instead result in an error message being sent back into the source host. If the host places its 1822L Address in this field, the address is checked to insure that it actually represents the host port where the message originated. If the message is destined for an 1822 host on a non-C/30 IMP, this field MUST - 31 -
RFC 802 Andrew G. Malis contain the source host's 1822L address (see Figure 4 insection 2.2).Bits 49-64: Destination Host: This field contains the 1822L name or address of the destination host. If it contains a name, the name will be checked for effectiveness, with an error message returned to the source host if the name is not effective. If the message is destined for an 1822 host on a non-C/30 IMP, this field MUST contain the destination host's 1822L address (see Figure 4 insection 2.2).Bits 65-76: Message ID: This is a host-specified identification used in all type 0 and type 8 messages, and is also used in type 2 messages. When used in type 0 messages, bits 65-72 are also known as the Link Field, and should contain values specified in Assigned Numbers [3] appropriate for the host-to-host protocol being used.Bits 77-80: Sub-type: This field is used as a modifier by message types 0, 2, 4, and 8. - 32 -
RFC 802 Andrew G. MalisBits 81-96: Unused, must be zero. - 33 -
RFC 802 Andrew G. Malis3.2 IMP-to-Host 1822L Leader Format 1 4 5 8 9 16 +--------+--------+----------------+ | | 1822L | | | Unused | I2H | Handling Type | | | Flag | | +--------+--------+----------------+ 17 20 21 22 24 25 32 +--------+-+------+----------------+ | |T|Leader| | | Unused |R|Flags | Message Type | | |C| | | +--------+-+------+----------------+ 33 48 +----------------------------------+ | | | Source Host | | | +----------------------------------+ 49 64 +----------------------------------+ | | | Destination Host | | | +----------------------------------+ 65 76 77 80 +-------------------------+--------+ | | | | Message ID |Sub-type| | | | +-------------------------+--------+ 81 96 +----------------------------------+ | | | Message Length | | | +----------------------------------+ Figure 7. IMP-to-Host 1822L Leader Format - 34 -
RFC 802 Andrew G. MalisBits 1-4: Unused and set to zero.Bits 5-8: 1822L IMP-to-Host Flag: This field is set to decimal 14 (1110 in binary).Bits 9-16: Handling Type: This has the value assigned by the source host (seesection3.1). This field is only used in message types 0, 5-9, 11 and 15.Bits 17-20: Unused and set to zero.Bit 21: Trace Bit: If equal to one, the source host designated this message for tracing as it proceeds through the network. See 1822(5.5).Bits 22-24: Leader Flags: Bit 22: Available as a destination host flag. Bits 23-24: Reserved for future use, set to zero.Bits 25-32: Message Type: Type 0: Regular Message - All host-to-host communication occurs via regular messages, which have several sub- types. The sub-type field (bits 77-80) is the same as sent in the host-to-IMP leader (seesection 3.1). Type 1: Error in Leader - See 1822(3.4). - 35 -
RFC 802 Andrew G. Malis Type 2: IMP Going Down - See 1822(3.4). Type 3: NDM Reply - This is a reply to the NDM host-to-IMP message (see section 3.1). It will have the same number of entries as the NDM message that is being replying to, and each listed 1822L name will be accompanied by a zero or a one. A zero signifies that the name is not effective, and a one means that the name is now effective. Type 4: NOP - The host should discard this message. It is used during initialization of the IMP/host communication. The Destination Host field will contain the 1822L Address of the host port over which the NOP is being sent. All other fields are unused. Type 5: Ready for Next Message (RFNM) - See 1822(3.4). Type 6: Dead Host Status - See 1822(3.4). Type 7: Destination Host or IMP Dead (or unknown) - This message is sent in response to a message for a destination which the IMP cannot reach. The message to the "dead" destination is discarded. See 1822(3.4) for a complete list of the applicable sub-types. If this message is in response to a standard (type 0, sub-type 0 or 1) message, it will be followed by a Dead Host Status message, which gives further information about - 36 -
RFC 802 Andrew G. Malis the status of the dead host. If this message is in response to an uncontrolled (type 0, sub-type 2 or 3) message, only sub-type 1 (The destination host is not up) will be used, and it will not be followed by a Dead Host Status message. Type 8: Error in Data - See 1822(3.4). Type 9: Incomplete Transmission - The transmission of the named message was incomplete for some reason. An incomplete transmission message is similar to a RFNM, but is a failure indication rather than a success indication. This message is also used by the short- blocking feature to indicate that the named message was rejected because it would have caused to IMP to block the host for a long amount of time. Seesection 2.4 for more details concerning the short-blocking feature. The message's sub-types are: 0: The destination host did not accept the message quickly enough. 1: The message was too long. 2: The host took more than 15 seconds to transmit the message to the IMP. This time is measured from the last bit of the leader through the last bit of the message. - 37 -
RFC 802 Andrew G. Malis 3: The message was lost in the network due to IMP or circuit failures. 4: The IMP could not accept the entire message within 15 seconds because of unavailable resources. This sub-type is only used in response to non-short- blocking messages. If a short-blocking message timed out, it will be responded to with one of the sub-types 6-10. 5: Source IMP I/O failure occurred during receipt of this message. Sub-types 6-10 are all issued in response to a short- blocking message that timed out (would have caused the host to become blocked for a long amount of time). The sub-types are designed to give the host some indication of why it timed out and what other messages would also time out. See section 2.4.2 for further details concerning each of these sub-types. 6: The message timed out because of connection set-up delay. Further messages to the same host (if on the same connection) may also be affected. 7: The message timed out because of end-to-end flow control. Further messages to the same host on the same connection will also be affected. - 38 -
RFC 802 Andrew G. Malis 8: Destination IMP buffer shortage caused the message to time out. This affects multi-packet standard messages to the specified host, but shorter messages or messages to hosts on other IMPs may not be affected. 9: Network congestion control caused the message to be rejected. Messages to hosts on other IMPs may not be affected, however. 10: Local resource shortage kept the IMP from being able to accept the message within the short- blocking timeout period. 11-15: Unassigned. Type 10: Interface Reset - See 1822(3.4). Type 15: 1822L Name or Address Error - This message is sent in response to a type 0 message from a host that contained an erroneous Source Host or Destination Host field. Its sub-types are: 0: The Source Host 1822L name is not authorized or not effective. 1: The Source Host 1822L address does not match the host port used to send the message. 2: The Destination Host 1822L name is not authorized. 3: The Destination Host 1822L name is authorized but - 39 -
RFC 802 Andrew G. Malis not effective, even though the named host is up. If the host were actually down, a type 7 message would be returned, not a type 15. 4: The Source or Destination Host field contains a 1822L name, but the host being addressed is on a non-C/30 IMP (see Figure 4 insection 2.2). 5-15: Unassigned. Types 11-14,16-255: Unassigned.Bits 33-48: Source Host: For type 0 messages, this field contains the 1822L name or address of the host that originated the message. All replies to the message should be sent to the host specified herein. For message types 5-9, 11 and 15, this field contains the source host field used in a previous type 0 message sent by this host.Bits 49-64: Destination Host: For type 0 messages, this field contains the 1822L name or address that the message was sent to. This allows the destination host to detect how it was specified by the source host. For message types 5-9, 11 and 15, this field contains the destination host field used in a previous type 0 message sent by this host. - 40 -
RFC 802 Andrew G. MalisBits 65-76: Message ID: For message types 0, 5, 7-9, 11 and 15, this is the value assigned by the source host to identify the message (seesection 3.1). This field is also used by message types 2 and 6.Bits 77-80: Sub-type: This field is used as a modifier by message types 0-2, 4-7, 9, 11 and 15.Bits 81-96: Message Length: This field is contained in type 0 and type 3 messages only, and is the actual length in bits of the message (exclusive of leader, leader padding, and hardware padding) as computed by the IMP. - 41 -
RFC 802 Andrew G. Malis4 REFERENCES[1] Specifications for the Interconnection of a Host and an IMP, BBN Report 1822, May 1978 Revision.[2] E. C. Rosen et. al., ARPANET Routing Algorithm Improvements, IEN 183 (also published as BBN Report 4473, Vol. 1), August 1980, pp. 55-107.[3] J. Postel, Assigned Numbers,RFC 790, September 1981, p. 10. - 42 -
RFC 802 Andrew G. Malis INDEX1822......................................................41822 address..............................................61822 host.................................................51822L.....................................................41822L address.............................................71822L host................................................51822L name................................................6authorized................................................9blocking.................................................16congestion control................................... 22, 39connection........................................... 20, 38destination host..................................... 32, 40effective................................................10flow control......................................... 20, 38handing type......................................... 27, 35incomplete transmission message...................... 19, 37leader flags......................................... 27, 35link field...............................................32logical addressing........................................4message ID........................................... 32, 41message length...........................................41message type......................................... 28, 35multi-homing..............................................4NDM.................................................. 10, 28NDM reply............................................ 10, 36NOC.......................................................9NOP........................................... 5, 22, 30, 36outstanding..............................................21priority bit.............................................27regular message...................................... 28, 35RFNM.....................................................36short-blocking feature...................................15short-blocking message............................... 19, 28source host.......................................... 31, 40standard message.........................................28sub-type............................................. 32, 41symmetric.................................................5trace bit............................................ 27, 35uncontrolled message................................. 14, 28 - 43 -
[8]ページ先頭