RFC_791阅读笔记（3部分下）

   关于RFC文档，个人认为还是要看英文版，毕竟很多东西是翻译不过来的，只有读原文才能很好的理解，而实际英语也不是我们想的那么难，只要静下心来，其实很简单！而且读后对你的英语能力提高不是一般的快。

   下边是我的RFC_791（IP）的阅读笔记，暂时还没读完，欢迎大家一起来交流。“//”后的都是自己写的注释

3.3. Interfaces

The functional description of user interfaces to the IP is, at best,  //the requires of interfacesfictional, since every operating system will have differentfacilities. Consequently, we must warn readers that different IPimplementations may have different user interfaces. However, all IPs  //must provide a certain minimum set of servicesmust provide a certain minimum set of services to guarantee that allIP implementations can support the same protocol hierarchy. Thissection specifies the functional interfaces required of all IPimplementations.

Internet protocol interfaces on one side to the local network and on  //C-S module,2 interfacethe other side to either a higher level protocol or an applicationprogram. In the following, the higher level protocol or application[Page 31]

September 1981Internet ProtocolSpecification

program (or even a gateway program) will be called the "user" since itis using the internet module. Since internet protocol is a datagramprotocol, there is minimal memory or state maintained between datagramtransmissions, and each call on the internet protocol module by theuser supplies all information necessary for the IP to perform theservice requested.

An Example Upper Level Interface

The following two example calls satisfy the requirements for the userto internet protocol module communication ("=>" means returns):

SEND (src, dst, prot, TOS, TTL, BufPTR, len, Id, DF, opt => result)   //what the upper level sends to the interface

where:

src = source addressdst = destination addressprot = protocolTOS = type of serviceTTL = time to liveBufPTR = buffer pointerlen = length of bufferId = IdentifierDF = Don't Fragmentopt = option dataresult = responseOK = datagram sent okError = error in arguments or local network error

Note that the precedence is included in the TOS and thesecurity/compartment is passed as an option.

RECV (BufPTR, prot, => result, src, dst, TOS, len, opt)     //what the interface receives from the local network

where:

BufPTR = buffer pointerprot = protocolresult = responseOK = datagram received okError = error in argumentslen = length of buffersrc = source addressdst = destination addressTOS = type of serviceopt = option data

[Page 32] 

September 1981 Internet ProtocolSpecification

When the user sends a datagram, it executes the SEND call supplying     //the working-mechanism of the two interfaceall the arguments. The internet protocol module, on receiving this      //in the case of the IP sending data--SEND callcall, checks the arguments and prepares and sends the message. If thearguments are good and the datagram is accepted by the local network,the call returns successfully. If either the arguments are bad, orthe datagram is not accepted by the local network, the call returnsunsuccessfully. On unsuccessful returns, a reasonable report must bemade as to the cause of the problem, but the details of such reportsare up to individual implementations.

When a datagram arrives at the internet protocol module from the local  //in the case of IP receiving data--REV callnetwork, either there is a pending RECV call from the user addressedor there is not. In the first case, the pending call is satisfied bypassing the information from the datagram to the user. In the secondcase, the user addressed is notified of a pending datagram. If theuser addressed does not exist, an ICMP error message is returned tothe sender, and the data is discarded.

The notification of a user may be via a pseudo interrupt or similarmechanism, as appropriate in the particular operating systemenvironment of the implementation.

A user's RECV call may then either be immediately satisfied by apending datagram, or the call may be pending until a datagram arrives.

The source address is included in the send call in case the sending    //the case of multiple connectionshost has several addresses (multiple physical connections or logicaladdresses). The internet module must check to see that the sourceaddress is one of the legal address for this host.

An implementation may also allow or require a call to the internet    //the exclusive datatramsmodule to indicate interest in or reserve exclusive use of a class ofdatagrams (e.g., all those with a certain value in the protocolfield).

This section functionally characterizes a USER/IP interface. The      //the similar notation in the IP isn't trapping service callsnotation used is similar to most procedure of function calls in highlevel languages, but this usage is not meant to rule out trap typeservice calls (e.g., SVCs, UUOs, EMTs), or any other form ofinterprocess communication.

[Page 33]

September 1981Internet Protocol

APPENDIX A: Examples & Scenarios                                      //the practical examples,rather important!                                                                      //they show the using of options and fragmentsExample 1:

This is an example of the minimal data carrying internet datagram:    //the minimal carrying internet datagram                                                                      //No the "options"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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|Ver= 4 |IHL= 5 |Type of Service| Total Length = 21 |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Identification = 111 |Flg=0| Fragment Offset = 0 |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Time = 123 | Protocol = 1 | header checksum |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| source address |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| destination address |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| data | +-+-+-+-+-+-+-+-+ 

Example Internet Datagram

Figure 5.

Note that each tick mark represents one bit position.

This is a internet datagram in version 4 of internet protocol; theinternet header consists of five 32 bit words, and the total length ofthe datagram is 21 octets. This datagram is a complete datagram (nota fragment).

[Page 34] 

September 1981 Internet Protocol

Example 2:

In this example, we show first a moderate size internet datagram (452data octets), then two internet fragments that might result from thefragmentation of this datagram if the maximum sized transmissionallowed were 280 octets.

0 1 2 3                                                                //the moderate(commonly) datagram0 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|Ver= 4 |IHL= 5 |Type of Service| Total Length = 472 |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Identification = 111 |Flg=0| Fragment Offset = 0 |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Time = 123 | Protocol = 6 | header checksum |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| source address |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| destination address |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| data |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| data |/ // /| data |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| data | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

Example Internet Datagram

Figure 6.

[Page 35]

September 1981Internet Protocol

Now the first fragment that results from splitting the datagram after //the two fragments256 data octets.

0 1 2 3                                                              //fragment 1                                                              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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|Ver= 4 |IHL= 5 |Type of Service| Total Length = 276 |              //TL=276,for it should be in the form of 8*N+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Identification = 111 |Flg=1| Fragment Offset = 0 |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Time = 119 | Protocol = 6 | Header Checksum |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| source address |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| destination address |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| data |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| data |/ // /| data |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| data |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Example Internet Fragment

Figure 7.

[Page 36] 

September 1981 Internet Protocol

And the second fragment.

0 1 2 3                                                               //fragment 1   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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|Ver= 4 |IHL= 5 |Type of Service| Total Length = 216 |                //(276-20)+(216-20)=452,just the length of the original data+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Identification = 111 |Flg=0| Fragment Offset = 32 |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Time = 119 | Protocol = 6 | Header Checksum |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| source address |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| destination address |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| data |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| data |/ // /| data |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| data | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

Example Internet Fragment

Figure 8.

[Page 37]

September 1981Internet Protocol

Example 3:

Here, we show an example of a datagram containing options:        //the datagram containing options

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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|Ver= 4 |IHL= 8 |Type of Service| Total Length = 576 |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Identification = 111 |Flg=0| Fragment Offset = 0 |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Time = 123 | Protocol = 6 | Header Checksum |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| source address |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| destination address |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Opt. Code = x | Opt. Len.= 3 | option value | Opt. Code = x |     //5 options+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Opt. Len. = 4 | option value | Opt. Code = 1 |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Opt. Code = y | Opt. Len. = 3 | option value | Opt. Code = 0 |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| data |/ // /| data |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| data |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Example Internet Datagram

Figure 9.

[Page 38] 

September 1981 Internet Protocol

APPENDIX B: Data Transmission Order

The order of transmission of the header and data described in this     //described in the octet leveldocument is resolved to the octet level. Whenever a diagram shows agroup of octets, the order of transmission of those octets is the normalorder in which they are read in English. For example, in the followingdiagram the octets are transmitted in the order they are numbered.     //transmitt in the normal order 

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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| 1 | 2 | 3 | 4 |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| 5 | 6 | 7 | 8 |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| 9 | 10 | 11 | 12 |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Transmission Order of Bytes

Figure 10.

Whenever an octet represents a numeric quantity the left most bit in the  //the sequence number:0 represents the highest orderdiagram is the high order or most significant bit. That is, the bitlabeled 0 is the most significant bit. For example, the followingdiagram represents the value 170 (decimal).

0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+|1 0 1 0 1 0 1 0|+-+-+-+-+-+-+-+-+

Significance of Bits

Figure 11.

Similarly, whenever a multi-octet field represents a numeric quantity   //first transmitt the most important bitthe left most bit of the whole field is the most significant bit. Whena multi-octet quantity is transmitted the most significant octet istransmitted first.

[Page 39]

September 1981Internet Protocol

[Page 40] 

September 1981 Internet Protocol

GLOSSARY

1822BBN Report 1822, "The Specification of the Interconnection ofa Host and an IMP". The specification of interface between ahost and the ARPANET.

ARPANET leaderThe control information on an ARPANET message at the host-IMPinterface.

ARPANET messageThe unit of transmission between a host and an IMP in theARPANET. The maximum size is about 1012 octets (8096 bits).

ARPANET packetA unit of transmission used internally in the ARPANET betweenIMPs. The maximum size is about 126 octets (1008 bits).

DestinationThe destination address, an internet header field.

DFThe Don't Fragment bit carried in the flags field.

FlagsAn internet header field carrying various control flags.

Fragment OffsetThis internet header field indicates where in the internetdatagram a fragment belongs.

GGPGateway to Gateway Protocol, the protocol used primarilybetween gateways to control routing and other gatewayfunctions.

headerControl information at the beginning of a message, segment,datagram, packet or block of data.

ICMPInternet Control Message Protocol, implemented in the internetmodule, the ICMP is used from gateways to hosts and betweenhosts to report errors and make routing suggestions.

[Page 41]

September 1981Internet ProtocolGlossary

IdentificationAn internet header field carrying the identifying valueassigned by the sender to aid in assembling the fragments of adatagram.

IHLThe internet header field Internet Header Length is the lengthof the internet header measured in 32 bit words.

IMPThe Interface Message Processor, the packet switch of theARPANET.

Internet AddressA four octet (32 bit) source or destination address consistingof a Network field and a Local Address field.

internet datagramThe unit of data exchanged between a pair of internet modules(includes the internet header).

internet fragmentA portion of the data of an internet datagram with an internetheader.

Local AddressThe address of a host within a network. The actual mapping ofan internet local address on to the host addresses in anetwork is quite general, allowing for many to one mappings.

MFThe More-Fragments Flag carried in the internet header flagsfield.

moduleAn implementation, usually in software, of a protocol or otherprocedure.

more-fragments flagA flag indicating whether or not this internet datagramcontains the end of an internet datagram, carried in theinternet header Flags field.

NFBThe Number of Fragment Blocks in a the data portion of aninternet fragment. That is, the length of a portion of datameasured in 8 octet units.

[Page 42] 

September 1981 Internet ProtocolGlossary

octetAn eight bit byte.

OptionsThe internet header Options field may contain several options,and each option may be several octets in length.

PaddingThe internet header Padding field is used to ensure that thedata begins on 32 bit word boundary. The padding is zero.

ProtocolIn this document, the next higher level protocol identifier,an internet header field.

RestThe local address portion of an Internet Address.

SourceThe source address, an internet header field.

TCPTransmission Control Protocol: A host-to-host protocol forreliable communication in internet environments.

TCP SegmentThe unit of data exchanged between TCP modules (including theTCP header).

TFTPTrivial File Transfer Protocol: A simple file transferprotocol built on UDP.

Time to LiveAn internet header field which indicates the upper bound onhow long this internet datagram may exist.

TOSType of Service

Total LengthThe internet header field Total Length is the length of thedatagram in octets including internet header and data.

TTLTime to Live

[Page 43]

September 1981Internet ProtocolGlossary

Type of ServiceAn internet header field which indicates the type (or quality)of service for this internet datagram.

UDPUser Datagram Protocol: A user level protocol for transactionoriented applications.

UserThe user of the internet protocol. This may be a higher levelprotocol module, an application program, or a gateway program.

VersionThe Version field indicates the format of the internet header.

[Page 44] 

September 1981 Internet Protocol

REFERENCES

[1] Cerf, V., "The Catenet Model for Internetworking," InformationProcessing Techniques Office, Defense Advanced Research ProjectsAgency, IEN 48, July 1978.

[2] Bolt Beranek and Newman, "Specification for the Interconnection ofa Host and an IMP," BBN Technical Report 1822, Revised May 1978.

[3] Postel, J., "Internet Control Message Protocol - DARPA InternetProgram Protocol Specification," RFC792, USC/Information SciencesInstitute, September 1981.

[4] Shoch, J., "Inter-Network Naming, Addressing, and Routing,"COMPCON, IEEE Computer Society, Fall 1978.

[5] Postel, J., "Address Mappings," RFC796, USC/Information SciencesInstitute, September 1981.

[6] Shoch, J., "Packet Fragmentation in Inter-Network Protocols,"Computer Networks, v. 3, n. 1, February 1979.

[7] Strazisar, V., "How to Build a Gateway", IEN 109, Bolt Beranek andNewman, August 1979.

[8] Postel, J., "Service Mappings," RFC795, USC/Information SciencesInstitute, September 1981.

[9] Postel, J., "Assigned Numbers," RFC790, USC/Information SciencesInstitute, September 1981.