Movatterモバイル変換
[0]ホーム
[RFC Home] [TEXT|PDF|HTML] [Tracker] [IPR] [Info page]
INTERNET STANDARD
RFC 768 J. Postel ISI 28 August 1980User Datagram Protocol----------------------Introduction------------This User Datagram Protocol (UDP) is defined to make available adatagram mode of packet-switched computer communication in theenvironment of an interconnected set of computer networks. Thisprotocol assumes that the Internet Protocol (IP) [1] is used as theunderlying protocol.This protocol provides a procedure for application programs to sendmessages to other programs with a minimum of protocol mechanism. Theprotocol is transaction oriented, and delivery and duplicate protectionare not guaranteed. Applications requiring ordered reliable delivery ofstreams of data should use the Transmission Control Protocol (TCP) [2].Format------ 0 7 8 15 16 23 24 31 +--------+--------+--------+--------+ | Source | Destination | | Port | Port | +--------+--------+--------+--------+ | | | | Length | Checksum | +--------+--------+--------+--------+ | | data octets ... +---------------- ... User Datagram Header FormatFields------Source Port is an optional field, when meaningful, it indicates the portof the sending process, and may be assumed to be the port to which areply should be addressed in the absence of any other information. Ifnot used, a value of zero is inserted.Postel [page 1]
28 Aug 1980User Datagram ProtocolRFC 768FieldsDestination Port has a meaning within the context of a particularinternet destination address.Length is the length in octets of this user datagram including thisheader and the data. (This means the minimum value of the length iseight.)Checksum is the 16-bit one's complement of the one's complement sum of apseudo header of information from the IP header, the UDP header, and thedata, padded with zero octets at the end (if necessary) to make amultiple of two octets.The pseudo header conceptually prefixed to the UDP header contains thesource address, the destination address, the protocol, and the UDPlength. This information gives protection against misrouted datagrams.This checksum procedure is the same as is used in TCP. 0 7 8 15 16 23 24 31 +--------+--------+--------+--------+ | source address | +--------+--------+--------+--------+ | destination address | +--------+--------+--------+--------+ | zero |protocol| UDP length | +--------+--------+--------+--------+If the computed checksum is zero, it is transmitted as all ones (theequivalent in one's complement arithmetic). An all zero transmittedchecksum value means that the transmitter generated no checksum (fordebugging or for higher level protocols that don't care).User Interface--------------A user interface should allow the creation of new receive ports, receive operations on the receive ports that return the data octets and an indication of source port and source address, and an operation that allows a datagram to be sent, specifying the data, source and destination ports and addresses to be sent.[page 2] Postel
28 Aug 1980RFC 768 User Datagram Protocol IP InterfaceIP Interface-------------The UDP module must be able to determine the source and destinationinternet addresses and the protocol field from the internet header. Onepossible UDP/IP interface would return the whole internet datagramincluding all of the internet header in response to a receive operation.Such an interface would also allow the UDP to pass a full internetdatagram complete with header to the IP to send. The IP would verifycertain fields for consistency and compute the internet header checksum.Protocol Application--------------------The major uses of this protocol is the Internet Name Server [3], and theTrivial File Transfer [4].Protocol Number---------------This is protocol 17 (21 octal) when used in the Internet Protocol.Other protocol numbers are listed in [5].References----------[1] Postel, J., "Internet Protocol,"RFC 760, USC/Information Sciences Institute, January 1980.[2] Postel, J., "Transmission Control Protocol,"RFC 761, USC/Information Sciences Institute, January 1980.[3] Postel, J., "Internet Name Server," USC/Information Sciences Institute, IEN 116, August 1979.[4] Sollins, K., "The TFTP Protocol," Massachusetts Institute of Technology, IEN 133, January 1980.[5] Postel, J., "Assigned Numbers," USC/Information Sciences Institute,RFC 762, January 1980.Postel [page 3]
[8]ページ先頭