Intended status: Standards Track A.Eromenko December 2015
draft-eromenko-ipff-udp-00
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Expired".
|
|
|---|---|---|---|
| Author | Alexey Eromenko | ||
| Last updated | 2015-12-10 | ||
| RFC stream | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-eromenko-ipff-udp-00
INTERNET-DRAFT
"Internet Protocol Five Fields - User Datagram Protocol",
Alexey Eromenko, 2015-12-10,
<draft-eromenko-ipff-udp-00.txt>
expiration date: 2016-06-10
Intended status: Standards Track
A.Eromenko
December 2015
User Datagram Protocol
----------------------
for Internet Protocol "Five Fields" (IP-FF)
Specification draft
Abstract
Minor modification of the UDP protocol to reduce overhead by 2 bytes.
Intended to be used with Internet Protocol "Five Fields".
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on December 9, 2014.
Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Introduction
------------
This User Datagram Protocol (UDP) is defined to make available a
datagram mode of packet-switched computer communication in the
environment of an interconnected set of computer networks. This
protocol assumes that the Internet Protocol (IP) [1] is used as the
underlying protocol.
This protocol provides a procedure for application programs to send
messages to other programs with a minimum of protocol mechanism. The
protocol is transaction oriented, and delivery and duplicate protection
are not guaranteed. Applications requiring ordered reliable delivery of
streams of data should use the Transmission Control Protocol (TCP) [2].
Format
------
User Datagram Header Format
0 7 8 15 16 23 24 31
+--------+--------+--------+--------+
| Source | Destination |
| Port | Port |
+--------+--------+--------+--------+
| | |
| Checksum | data... |
+--------+--------+ +
| .
| more data octets ... .
+---------------- ...
Fields
------
Source Port is an optional field, when meaningful, it indicates the port
of the sending process, and may be assumed to be the port to which a
reply should be addressed in the absence of any other information. If
not used, a value of zero is inserted.
Destination Port has a meaning within the context of a particular
internet destination address.
Length of the data is taken from upper level IPFF protocol.
Checksum is the 16-bit one's complement of the one's complement sum of a
pseudo header of information from the IP header, the UDP header, and the
data, padded with zero octets at the end (if necessary) to make a
multiple of two octets.
The pseudo header conceptually prefixed to the UDP header contains the
source address, the destination address, the protocol, and the UDP
length. This information gives protection against misrouted datagrams.
This checksum procedure is the same as is used in TCP.
The header structure must be taken from [IPFF] document RFC.
If the computed checksum is zero, it is transmitted as all ones (the
equivalent in one's complement arithmetic). An all zero transmitted
checksum value means that the transmitter generated no checksum (for
debugging 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.
IP Interface
-------------
The UDP module must be able to determine the source and destination
internet addresses and the protocol field from the internet header. One
possible UDP/IP interface would return the whole internet datagram
including all of the internet header in response to a receive operation.
Such an interface would also allow the UDP to pass a full internet
datagram complete with header to the IP to send. The IP would verify
certain fields for consistency and compute the internet header checksum.
Protocol Application
--------------------
The major uses of this protocol is the Internet Domain Name Server
(DNS), the Trivial File Transfer Protocol (TFTP) and the Dynamic Host
Configuration Protocol (DHCP).
Protocol Number
---------------
This is protocol 17 when used in the Internet Protocol.
Acknowledgement
---------------
Originally written by J.Postel as RFC-768, modified by Alexey Eromenko
for the purposes of Internet Protocol "Five Fields".
Author Contacts
Alexey Eromenko
Israel
Skype: Fenix_NBK_
EMail: al4321@gmail.com
INTERNET-DRAFT
Alexey
expiration date: 2016-06-10