Internet DRAFT - draft-bogdanov-ehtp
draft-bogdanov-ehtp
Internet-Draft Alexander Bogdanov
draft-bogdanov-ehtp-00.txt July 2002
Expires: January 2003
End-by-Hop Transmission Protocol
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026 [1].
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Abstract
End-by-Hop Transmission Protocol (EHTP) is the connection-oriented
transport service for the reliable or unreliable delivery of data
packets with possible violation of a sequence. It has the own
address space compatible with Unified Memory Space Protocol (UMSP,
RFC3018 [5]). EHTP includes the gateway protocol, which supports
labels and dynamic resources deallocating. Networks with non-
overlapping or incompatible addresses space may be united at EHTP
layer with end-to-end interaction and with preservation of a
transparency.
Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC-2119 [2].
The options names and the headers fields identifiers written by the
letters in upper case. At that, the words in the options names are
divided by a hyphen, and in the fields identifiers by the underlining
symbol.
Bogdanov Expires: January 2003 [Page 1]
Internet-Draft End-by-Hop Transmission Protocol July 2002
Table of contents
1 Introduction........................................................3
2 Terminology.........................................................4
3 Addressing..........................................................5
3.1 Transport Addresses.............................................5
3.2 Transport Address Formats.......................................6
3.2.1 Immediate IP Addresses.......................................6
3.2.2 Extended IPv4 addresses......................................7
3.2.3 Telephone number.............................................8
3.2.4 Additional Length Format.....................................8
3.2.4.1 Character Address........................................9
3.3 Character Presentation of the Transport Address.................9
4 Format of EHTP Packet..............................................10
4.1 General Format of Packet.......................................10
4.2 Basic Header...................................................11
4.3 The Addresses Header...........................................13
4.4 Options........................................................15
4.5 Data...........................................................16
4.6 Checksum.......................................................16
5 The Endpoints Protocol.............................................17
5.1 Connections control............................................17
5.1.1 Primary Connection Establishment............................17
5.1.1.1 INIT, INIT-ACK..........................................19
5.1.1.2 CONNECT, CONNECT-ACK....................................21
5.1.1.3 Identifiers Exchanging Scheme...........................24
5.1.2 Secondary Connection Establishment..........................25
5.1.3 0 - connection..............................................27
5.1.4 Receiving Window Restriction................................29
5.1.5 Security Parameters Index Changing..........................30
5.1.6 Connection Termination......................................31
5.1.7 Termination Error Codes.....................................32
5.2 User Data Transfer.............................................32
5.2.1 The Packet of Cumulative Data Acknowledgement...............33
5.2.2 CUM-ACK.....................................................34
5.2.3 GAP-ACK.....................................................34
5.3 Congestion Control.............................................35
6 The Gateway Protocol...............................................37
6.1 Gateway Options................................................38
6.1.1 GATEWAY-HEADER..............................................38
6.1.2 LABEL-HEADER................................................40
6.1.3 GENERAL-LABEL...............................................41
6.1.4 LABEL-OPTION................................................41
6.1.5 COOKIE-GATEWAY..............................................42
6.2 Connections Control through Gateways...........................43
6.2.1 Connection Establishment....................................43
6.2.2 Data Transfer...............................................46
6.2.3 Reconnection................................................47
Bogdanov Expires: January 2003 [Page 2]
Internet-Draft End-by-Hop Transmission Protocol July 2002
6.2.3.1 REINIT, REINIT-ACK......................................48
6.2.3.2 RECONNECT, RECONNECT-ACK................................49
6.2.3.3 2-way Handshake.........................................50
6.2.3.4 4-way Handshake.........................................51
6.2.4 Connections Termination through Gateway.....................52
6.3 Use of symbolical addresses....................................53
6.4 DISCARDED-PACKET...............................................53
6.5 NEW-PMTU.......................................................55
6.6 GATEWAY-ERROR..................................................56
6.7 Gateway Error Codes............................................57
6.8 Activity Control...............................................57
7 Security Consideration.............................................59
8 References.........................................................60
9 Author's Address...................................................61
10 Full Copyright Statement.........................................62
1 Introduction
EHTP is the connections-oriented transport service for reliable or
unreliable delivery of data packets with possible violation of a
sequence. It uses the service of unreliable datagram delivery at the
lower layer. EHTP is oriented for working with Unified Memory Space
Protocol [5] at the upper layer. Nevertheless, EHTP is the universal
protocol, with a condition, that the upper layer provides
packetization.
EHTP has the own address space, defined over addresses space of the
network layer. It is stipulated the protocol of gateway. The
endpoint may be connected immediately to global IP network or to work
through a gateway. The protocol of EHTP gateway does not include the
routing protocol. It is supposed, that the basic work on routing is
implemented at a network layer. The definition of EHTP gateways
addresses is beyond the scope of this document. The protocol
requires that the node have known at least the one gateway address.
EHTP does not provide buffering the received data. All received
packets are sending to the upper layer at once. Consequently, the
protocol has no the fragmentation function and does not provide the
ordered data flows. This decision is based on the supposition, that
the allocation of resources, except for minimally necessary for
reliable data exchange, should make at application layer. The
functional purpose of transmitted data is known at this layer, and it
is possible to denial of low-priority traffic service at overloading.
The protocol defines a 4-way handshake establishment of primary
connections. All basic functions of connections control are carried
out at primary connections layer. Primary connections can be used
for the accelerated establishment of 2-way handshaking secondary
connection. Primary connection with indefinite port number is
Bogdanov Expires: January 2003 [Page 3]
Internet-Draft End-by-Hop Transmission Protocol July 2002
stipulated. This connection can be used for sending a connectionless
traffic (for the upper layer). The upper layer traffic of any
connection can request or not request delivery acknowledgement.
The gateway protocol defines the mixed routing based on addresses and
labels. Labels are distributed at a primary connection
establishment. The possibility of a connection establishment through
the explicit route is stipulated. The protocol gives the mechanism
of dynamic resources deallocating on gateways of the explicit route
at absence of traffic during established time. Dynamic resource
redistribution is executed transparent for the upper layer.
The UDP [3] using at lower layer is specified in this document for
EHTP. Allocated IANA port is 1295. The logic, at which UDP is used
only at a connection establishment and by sending the big packets,
can be used. After connection establishment on the fixed hops, the
second layer protocol immediately can be used. The small size of the
service information (8 bytes for unreliable data delivery), allows
immediately using lower layer service with the small packet size.
This document defines UDP using and does not consider other
protocols. Nevertheless, any lower layer protocol if it allows
identifying EHTP packets, can be used on the fixed hops.
EHTP is the new protocol, and it requires to develop new application
programs or to update existing for immediate use of its services. At
the same time, it is possible to develop intermediate sublevels above
EHTP, which emulate the existing standard protocols services, for
example TCP.
Presence of the gateway with state protocol allows to create the
multilevel protected systems and to use EHTP for sending the traffic
with QoS. Besides, the gateway protocol gives a possibility to unite
the switching packets networks with switching channels networks in
any combination. This document contains the description of the base
protocol and does not consider these questions.
2 Terminology
Node - a device that implements EHTP.
Gateway - an intermediate node that forwards EHTP packets. The
gateway always has its own EHTP address.
MTU - maximum packet size in bytes, that can be conveyed between
adjacent EHTP nodes without fragmentation on lower layer.
PMTU - minimum MTU of all path hops between a sender node and a
receiver node.
Bogdanov Expires: January 2003 [Page 4]
Internet-Draft End-by-Hop Transmission Protocol July 2002
Command - an option formed by an endpoint in the EHTP packet, defines
operations at EHTP layer.
Network address - a node address on the network layer, for example
IPv4.
Transport address - a node address at an EHTP layer. The transport
address includes the information about network type and
node address in this network. The transport address may be
two-level and include the gateway address in a global
network and the node address in a local address space of
gateway. The "transport address" term does not include a
port. In this document text, the term "address" (without
type specification) means the transport address.
3 Addressing
3.1 Transport Addresses
Transport addresses are defined over the network addresses. The node
transport address has the globally unique value. It includes the
information about a network in which the node is located, and the
address in this network. One endpoint MUST have only one transport
address. The address MUST NOT change, while it is even one open
connection.
EHTP packet contains the sender and the receiver transport addresses.
Presence of transport addresses allows gateways to realize delivery
of packets between different networks.
The transport address includes three fields:
Bits
0 1 2 3 4 5 6
+----+----+----+----+----+----+----------------//------------------+
| ADDR_LENGTH |NET_TYPE | NODE_ADDR |
+----+----+----+----+----+----+----------------//------------------+
ADDR_LENGTH: 4 bits
The address length. This field contains the number of bytes
in the NODE_ADDR field. Two special values %b0000 and %b1111
is defined. Value %b0000 sets the additional length format
for the addresses up to 255 bytes length (see section 3.2.4).
Value %b1111 set the length of 16 bytes.
NET_TYPE: 2 bits
Bogdanov Expires: January 2003 [Page 5]
Internet-Draft End-by-Hop Transmission Protocol July 2002
The network type. This field in a combination with the
ADDR_LENGTH field defines a global network, to which the
address refers.
NODE_ADDR: 1 - 255 bytes
The node address in the network. This field contains the node
address. This field format and a network in which the node is
located, is defined by a combination of NET_TYPE and
ADDR_LENGTH fields values. There is no the general algorithm
connecting these values with the field format of node address.
For each combination of NET_TYPE and ADDR_LENGTH fields values
the format is defined separately.
Combination of ADDR_LENGTH = 0 and NET_TYPE = 0 values is reserved.
3.2 Transport Address Formats
3.2.1 Immediate IP Addresses
(1) The following transport address fields values are defined for
the node in IPv4 global network:
ADDR_LENGTH = 4
NET_TYPE = %b00,%b01
%b00 - value is defined for the node having the interface
with IPv4 global network and not supporting EHTP.
Use of this address type is described in [5].
%b01 - value is defined for the node having the interface
with IPv4 global network and supporting EHTP.
NODE_ADDR - The field length is equal to 4 bytes. The field
contains the global IPv4 address of the node.
(2) The following fields values of transport address are defined for
the node, which is taking place in IPv6 network:
ADDR_LENGTH = 15. This is the special value of the address
length. The actual field length of NODE_ADDR
is 16 bytes.
NET_TYPE = 0
NODE_ADDR - This field contains the full IPv6 address.
(3) The following transport address fields value is defined for the
node having an interfaces in IPv4 and IPv6 networks
simultaneously through the compatible address:
Bogdanov Expires: January 2003 [Page 6]
Internet-Draft End-by-Hop Transmission Protocol July 2002
ADDR_LENGTH = 4
NET_TYPE = %b10
NODE_ADDR - This field length is equal to 4 bytes. The field
contains the global IPv4 node address.
The nodes of this type optionally represent the gateways. The
used network is fixed in first connection establishment command
and may be changed only at reconnection.
3.2.2 Extended IPv4 addresses
The global IPv4 network is considered in the extended addressing, as
a network of peer-to-peer gateways. Each gateway has the own local
addresses space. The endpoint transport address includes the gateway
address in a global network and the local address. The gateway is
completely responsible for sending the traffic between nodes in a
global network and nodes in a local address space. The local address
space is flat on the part of a global network. The internal
structure and the transport protocol inside a local zone may be
anyone. Compatibility with EHTP at a gateway level is required only.
Nodes from a local zone may be located:
o in a local or virtual gateway network,
o in any addressed point of a global network,
o be connected to gateway by not network communications,
o be virtual devices or application programs of gateway.
The local zone may have several peer gateways, which are named a
gateways group. Consecutive address numbers in global IPv4 network
are reserved for one group of gateways. The group may consist of
four or sixteen gateways. Lower bits of address must contain value
%b00-11 for group of 4 gateways and %b0000-1111 for group of 16
gateways. The upper bits of address must have one value for one
gateways group. Not less than one gateway must work in-group.
Unused addresses from a range must be reserved. Gateways must
coordinate the addressing policy inside a zone. Any protocol may be
used for this. The zone must have only one group of gateways. The
node transport address in local zone does not depend on the gateway
address, through which the packets exchange.
The following transport address fields values are defined for
extended IPv4 addresses:
ADDR_LENGTH = 6, 8, 10, 12
NET_TYPE = %b00,%b01,%b10
Bogdanov Expires: January 2003 [Page 7]
Internet-Draft End-by-Hop Transmission Protocol July 2002
%b00 - for the local zone having one gateway for communication
with a global network.
%b01 - for the local zone having group of 4 gateways for
communication with a global network.
%b10 - for the local zone having group of 16 gateways for
communication with a global network.
NODE_ADDR - The length is equal to 6, 8, 10, 12 bytes. General
NODE_ADDR format for the node from a local zone is the
following:
Bytes
0 1 2 3
+---+---+---+---+--------//---------+
|GATEWAY_ADDRESS| LOCAL_ADDRESS |
+---+---+---+---+--------//---------+
GATEWAY_ADDRESS: 4 bytes
This field contains the global IPv4 gateway address. If the
zone has group of peer gateways, it is the address of the
foreground gateway from group, which should be used for
communication with this node. If this gateway is
inaccessible, the sender from a global network side must
search gateways in increasing order numbers of address,
since zero (with zero values of lower address bits).
LOCAL_ADDRESS: 2, 4, 6, 8 bytes
This field contains the node address inside a local zone.
The protocol does not impose any restrictions on the format
and value of this field.
3.2.3 Telephone number
Value such as network NET_TYPE = %b11 is defined for telephone
numbers. ADDR_LENGTH address length value defines number length and
may be anyone. Full telephone number written in field NODE_ADDR in
the packed decimal format (one decimal number in four bits). If the
number length is odd, the value %xF written in last four bits.
3.2.4 Additional Length Format
The additional length format is set by special field of length value
in transport address ADDR_LENGTH = %b0000. It is intended for
addresses, up to 255 bytes size. The NET_TYPE field values don't
influence a general format of transport address of this type. The
NODE_ADDR field has the following general format:
Bogdanov Expires: January 2003 [Page 8]
Internet-Draft End-by-Hop Transmission Protocol July 2002
Bytes
0 1
+--------+------------//--------------+
| TR_LEN | RA_ADDR |
+--------+------------//--------------+
TR_LEN: 1 byte
Indicates the length of the RA_ADDR in bytes.
RA_ADDR: 1-255 byte
The node address.
3.2.4.1 Character Address
This document defines the transport address containing the node
address as character ASCII string:
ADDR_LENGTH = 0
NET_TYPE = %b01
NODE_ADDR :
TR_LEN - The address length
RA_ADDR - Domain name or character representation of the
transport address or URL.
3.3 Character Presentation of the Transport Address
The combination of ADDR_LENGTH and NET_TYPE values is named the
global network number (or network number) and is represented together
by decimal numbers. Initial zero is omitted. The final zero is
omitted, if the penultimate number is more than 3, i. e. it may not
be considered as a network type. The global network address is
written behind a network number through slash "/" by the rules of
this network. It may be the gateway address or the endpoint address.
For a gateway the local zone node address is written through slash
"/", by the rules of addresses writing for this zone. Transport
addresses in global IPv4 or IPv6 network may be written without
number of a network. For example:
41/198.47.50.3 (or 198.47.50.3) - The endpoint in the IPv4 global
network
8/198.47.50.3/123.100.27.1 - Endpoint in the local IPv4 network,
working through a single gateway of
global IPv4 network.
Bogdanov Expires: January 2003 [Page 9]
Internet-Draft End-by-Hop Transmission Protocol July 2002
This document defines only two rules of the addresses writing in a
local zone. It may be the local IPv4 address, or representation of
any address as decimal number.
The node address may be written down as the domain name or any URL.
In that case, the global network number is not presented. It is
supposed, that this name has globally unique value.
The number of global telephone network is presented in one value 3
irrespective of length. The network number may be absent, if the
telephone number may not be defined as the network number. For
example, the number length exceeds three, or the last number is more
than five, or the number value is more than 153. Blanks and hyphen
digits are ignored. For example: 123 456-7890. Prefixes of an
output in a global telephone system are not included in number. The
telephone system subscriber address may be presented by alphanumeric
line with slash "/" for separating hierarchical components. For
example: 3/Moscow/123-45-67. The protocol of transformation of such
addresses in a binary kind lies beyond the scope of this document.
The transport address in character representation is entered in EHTP
packet in a character address format (see section 3.2.4.1). It is
NOT RECOMMENDED to use the character address, if the node may
transform it to a binary format.
4 Format of EHTP Packet
4.1 General Format of Packet
Packet EHTP has the following structure:
+--------+---------+-------+---------+-------------+-------+--------+
|Gateways|Addresses| Basic |Endpoint | DATA |PADDING|CHECKSUM|
|Options |Header | Header|Options | | | |
+--------+---------+-------+---------+-------------+-------+--------+
Gateways Options
The gateway options are optional headers with a variable length.
Its may be formed by gateways or by an endpoint. On a route of
transmission, gateways options may be added, be deleted from a
packet, or be modified. In EHTP packet, gateways options MUST be
located before the basic header and the addresses header.
Addresses Header
The addresses header is the optional header with variable length.
It contains the transport addresses of the sender and of the
receiver. The addresses header is formed by the endpoint and it
Bogdanov Expires: January 2003 [Page 10]
Internet-Draft End-by-Hop Transmission Protocol July 2002
MUST be located in a packet directly before of the basic header.
The addresses header should not be deleted from a packet on
gateways and its fields values should not be changed.
Basic Header
The basic header is the obligatory header with the fixed length.
It is formed by the endpoint and it contains information,
minimally necessary for delivery and processing of packet by the
receiver. The fields values of the basic header should not be
changed by gateways.
Endpoint Options
The endpoint options are optional headers with variable length.
They are formed by an endpoint. They MUST NOT be added, deleted
from a packet, or modified on a route of sending. The endpoint
options MUST be located after the basic header in EHTP packet.
DATA
It is the optional field, containing the upper layer data. The
field length is 0-65535 bytes.
PADDING
These are bytes, which are padded in the end of data field (if
necessary) to make a multiple of four bytes. Values may be
anyone. At using of the checksum, it is recommended set to 0.
CHECKSUM
The checksum or the data authentication of packet.
All packet headers MUST have a length, which is a multiple of 4
bytes.
One EHTP packet MUST be located in a separate packet of the lower
layer.
All headers and options are identified by the first 4 or 5 bits. If
the node does not know these bits definition, it MUST silently
discard a packet.
4.2 Basic Header
Three formats of base header of 12, 8 and 4 bytes length are defined.
Bogdanov Expires: January 2003 [Page 11]
Internet-Draft End-by-Hop Transmission Protocol July 2002
The basic header with a length of 12 bytes MUST be used in packets
with commands of a connection establishment. It has the following
format:
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 0 0 1 0|E|P|R| SEQUENCE_NUM |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SERVICE_ID | DATA_LENGTH |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CONNECTION_ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
E: 1 bit
Flag of the following option. If it is set, the endpoint
option is located after the basic header. If it is not set,
the upper layer data are located behind the basic header.
P: 1 bit
Push flag. If it is set, the packet must not be deferred in
sending queues. The return packet, containing response of this
packet, also must have PSH=1. Push flag does not change a
sequence of sending packets, sent on separate connection.
R: 1 bit
Reserved. This bit MUST be set to zero by sending. If this
bit is set to 1 on reception, the packet MUST be silently
discard without no further action. This bit MUST NOT is
analyzed by gateways.
SEQUENCE_NUMBER: 24 bits
A packet sequence number. Numbering is conducted for one
connection. It is necessary for calculations to use
arithmetic, given in [11]. Value 0 is reserved and it must be
excluded at consecutive numeration.
SERVICE_ID: 16 bits
The upper layer service identifier (destination port). This
document defines value 2110 for UMSP protocol [5].
DATA_LENGTH: 16 bits
Bogdanov Expires: January 2003 [Page 12]
Internet-Draft End-by-Hop Transmission Protocol July 2002
Indicates the length of DATA field in bytes. A range of
allowable values is 0 - 65535.
CONNECTION_ID: 32 bits
The connection identifier, assigned by a receiver endpoint.
Basic headers with smaller length have the same purpose of fields.
Basic headers of 8 bytes length are using after a connection
establishment, if the receiver endpoint can unequivocally identify
connection by two lower bytes of CONNECTION_ID field. The header has
the following format:
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 0 0 1 1|E|P|R| SEQUENCE_NUM |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CONNECTION_ID | DATA_LENGTH |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Basic headers in length of 4 bytes are used after a connection
establishment at an execution of all following conditions:
o The receiver endpoint can unequivocally identify connection by
two lower bytes of CONNECTION_ID field.
o The data length does not exceed 255 bytes.
o Data of the upper layer does not require delivery
acknowledgement.
The header has the following format:
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 0 1 0 0|E|P|R| DATA_LENGTH | CONNECTION_ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4.3 The Addresses Header
The addresses header contains transport addresses of the sender and
the receiver. Fields values of the transport address are given in
section 3. The addresses header has the following format:
Bogdanov Expires: January 2003 [Page 13]
Internet-Draft End-by-Hop Transmission Protocol July 2002
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1 0 0 0| SAL |STP| RAL |RTP|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ SND_NODE_ADDR ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ RCV_NODE_ADDR ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ ZERO_PADDING ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
SAL: 4 bits
The ADDR_LENGTH field of the sender transport address (see
section 3.1).
STP: 2 bits
The NET_TYPE field of the sender transport address.
RAL: 4 bits
The ADDR_LENGTH field of the receiver transport address.
RTP: 2 bits
The NET_TYPE field of the receiver transport address.
SND_NODE_ADDR: 1-256 bytes
The NODE_ADDR field of the sender transport address.
RCV_NODE_ADDR: 1-256 bytes
The NODE_ADDR field of the receiver transport address.
ZERO_PADDING: 0-3 bytes
Zero addition bytes. They are intended for alignment of the
end of addresses header on four bytes border.
Bogdanov Expires: January 2003 [Page 14]
Internet-Draft End-by-Hop Transmission Protocol July 2002
If SAL = 0 and STP = 0, field SND_NODE_ADDR is absent.
4.4 Options
Options of a gateway and of an endpoint have a equal format, and
differ a position about basic header:
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 0 1 0 1|E|D|G| HEAD_LENGTH | OPCODE | HEADER_DATA1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ HEADER_DATA2 ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
E: 1 bit
The purpose of this bit differs for gateways options and the
endpoint options:
o For the gateway option, it is the flag of preservation in
a stack on the following route hop. If it is not set,
the option must be deleted from a packet after processing
on the next gateway of explicit route. If flag is set,
the option must not be deleted from a packet on gateways.
o For the endpoint option, it is a flag of the following
option. If it is not set, the data are located after
this option. If the flag is set, the following endpoint
option is located after this option.
D: 1 bit
A flag of obligatory processing in the endpoint. It defines
the order of an option processing, if the endpoint does not
know purpose of this option or may not process it because of
any reason. If D = 1, the data transmitted in a packet should
be ignored. If D = 0, the packet is received irrespective of a
possibility of this option processing. The endpoint must
analyze all options of a packet.
G: 1 bit
The flag of obligatory processing on gateways. It defines the
order of option processing, if a gateway does not know the
purpose of this option or may not process it because of any
reason. If G flag is set, the packet must be silently
discarded. The gateway must process only its options. The
Bogdanov Expires: January 2003 [Page 15]
Internet-Draft End-by-Hop Transmission Protocol July 2002
gateway must not analyze the options of other gateways. If G
flag is not set, the packet is forwarded on a route,
irrespective of a possibility of this option processing.
HEAD_LENGTH: 8 bits
Indicates the number of 4-byte words in HEADER_DATA2 field
(HEADER_DATA1 field always is present at header).
OPCODE: 8 bits
This field value defines operation, which is set by an option.
HEADER_DATA1 + HEADER_DATA2: 1 - 1021 bytes
The format of these fields is defined for each OPCODE value
separately.
4.5 Data
DATA field contains the upper layer data. If DATA_LENGTH = 0, the
DATA field is absent.
4.6 Checksum
The packet contains the checksum of 4 bytes length by default. This
sum is calculated with using of CRC-32 algorithm. Gateways options
MUST NOT are included in calculation of the checksum. All other
headers, including addresses header, basic header and endpoint
options MUST be included in calculation. The upper layer data may be
included in calculation not completely. The quantity is defined at a
connection establishment (see section 5.1.1.2).
If the Security Parameters Index (SPI) value is defined at a
connection establishment, the packet contains authentication data
instead of the checksum. The length of authentication data MUST NOT
exceed 1024 bytes and MUST be multiple to 4 bytes. This document
does not impose any other restrictions on a format of authentication
data.
It is supposed, that integrity of data flow is one of the basic upper
layer requirements. It is impossible to create the steady
distributed systems based on a network, which are not carrying out
this requirement. Therefore, the checksum must be used, only if it
is impossible to agree on packets authentication parameters.
Irrespective of SPI, gateway options MUST NOT be included in the
checksum calculation or authentication data, as they may be modified,
added and deleted from a packet on gateways. Thereof, these options
Bogdanov Expires: January 2003 [Page 16]
Internet-Draft End-by-Hop Transmission Protocol July 2002
are not protected from distortion and fake. It should be taken into
account in the logic of packets processing.
After a connection establishment under some conditions, the addresses
header and full basic header may be absent in packets. As the
protocol does not guarantee correct packets routing, the full packet
including addresses header and 12-byte basic header MUST be used for
calculation of the checksum in endpoints. The endpoint of the
receiver MUST store these values in state variables. For calculation
of the authentication data, the addresses header MUST not be included
in calculation, if it is not really sent in a network. The 12-byte
basic header MUST be included in calculation of authentication data,
irrespective of the real format, transmitted through a network.
5 The Endpoints Protocol
5.1 Connections control
5.1.1 Primary Connection Establishment
The purpose of primary connection establishment is:
o Transmission of the upper layer data
o Reservation of resource for the accelerated establishment of
secondary connections,
o Fixing of a route through gateways (see section 6).
o The establishment of initial connection, if there are switching
channels networks in a route.
The endpoints execute during procedure of establishment:
o exchange of connection identifiers (each side appropriates its
identifier to connection ),
o coordinate of initial sequence numbers,
o set a maximum quantity of secondary connections, which may be
in this primary connection,
o coordinate PMTU.
At the description of a connection establishment procedure in this
document, the node that initiates connections is called "initiator".
The node that answers a connection establishment is called
"responder".
The connection establishment consists of 4-way handshake:
(1) The initiator sends INIT command.
(2) The responder confirms the possibility of connection
establishment by sending of INIT-ACK command.
Bogdanov Expires: January 2003 [Page 17]
Internet-Draft End-by-Hop Transmission Protocol July 2002
(3) The initiator sends the CONNECT command. Data of the upper
layer may be transmitted together with this command.
(4) Responder confirms a connection establishment by sending
CONNECT-ACK command to initiator. This command may be
transmitted together with the upper layer data.
All connections identifiers, assigned by the defined node, must have
the unique values for this node at each moment of time. Identifiers,
assigned by different nodes, may coincide. The combination of values
<the connection identifier> + <the node transport address> + <time
(implicit)> is the global unique key of the connection. Under some
conditions, the transport address and/or the full connection
identifier can be absent in a packet. For the control of wrong
routing, the endpoints (the sender and the receiver) must include
globally unique key in calculation of a packet checksum.
Values of connections identifiers must be allocated in view of
necessity to reject the packets, sent on already closed or emergency
broken off connections. Such packets may be in a network after
closing connection for some time. The identifier from the closed
connection may be used repeatedly in the following cases:
o The time passed from the moment of closing connection,
exceeding double maximal lifetime of packets in a network.
o The difference between SEQUENCE_NUMBER for the first sent
packet in the new connection and the last value in the closed
connection guarantees, that the consecutive increase of
sequence numbers in new connection will not achieve the last
value of the closed connection during double maximal lifetime
of packets in a network. The node does not choose initial
sequence number; therefore, this condition may be not executed
always.
The connections identifiers, established right after the emergency
reload of the node, also must take into account these restrictions.
The node is completely responsible for allocated identifiers and may
change or add the given rules. For increase of security from
attacks, it is recommended, that connections identifiers would have
values, which are difficult for predicting.
To use the short-cut format of base header, an endpoint must assigned
connections identifiers with two lower bytes, unique for the node.
In this case, at a connection establishment and at calculation of the
checksum, full 32-bit identifier value is used. Packets after a
connection establishment can include only two low bytes of the
identifier. Right after connection closing, the value of low bytes
can be used in new connection, if higher bytes have the other value.
Bogdanov Expires: January 2003 [Page 18]
Internet-Draft End-by-Hop Transmission Protocol July 2002
5.1.1.1 INIT, INIT-ACK
INIT command is used on a first step of primary connection
establishment. INIT-ACK command is the positive response to INIT
command. These commands MUST be formed as a gateway options. The
packet containing these commands, MUST NOT includes the upper layer
data. Fields of base header must have the following values:
SEQUENCE_NUM - In INIT command, this field is set to zero on
transmit and ignored on receipt. For INIT-ACK
command, the packet sender allocates this field
value. It MUST be copied by the receiver in
SEQUENCE_NUM field of base header of a packet with
CONNECT command. Values 0 and %xFFFFFF are
reserved.
SERVICE_ID - This field contains the service identifier of
established connection.
DATA_LENGTH = 0
CONNECTION_ID - Values 0 and %xFFFFFFFF are reserved. In INIT
command, this field is not used by the protocol
and may contain any value. In INIT-ACK command,
value of this field is copied from
TMP_CONNECTION_ID field of INIT command.
The options of INIT and INIT-ACK commands have an identical format
and differ only in OPCODE value:
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 0 1 0 1|E|D|G| HEAD_LENGTH | OPCODE |RES_VER_FLAGS|F|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|RSV| MIN_HL_PMTU |RSV| PMTU |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TMP_CONNECTION_ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SPI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The fields of general format have the following values:
E = 1
D = 1
G = 1
HEAD_LENGTH = 2/3 (depends on SPI presence)
OPCODE =
1 for INIT
2 for INIT-ACK
Bogdanov Expires: January 2003 [Page 19]
Internet-Draft End-by-Hop Transmission Protocol July 2002
RES_VER_FLAGS: 7 bits
The reserved versions flags. Values of these bits are set to
zero on transmit. If even one of them is set to 1 at
receiving, the packet must be silently rejected. Each new
version of the protocol will use one bit of this field. The
endpoint has a possibility to provide a few protocol versions.
INIT command may contain a several not zero bits of the
version. INIT-ACK command MUST contain only one not zero bit
of the version.
F: 1 bit
Flag of the protocol first version. This bit MUST be set to 1.
It sets the protocol version, which is defined in this
document.
RSV: 2 + 2 bits
Reserved. These fields should be set to zero on transmit and
ignored on receipt.
MIN_HL_PMTU: 14 bits
Indicates the minimal size of upper layer PMTU in 32-bit words.
This value sets the upper layer at request of connection
establishment. Connection PMTU MUST NOT be less than this
value. MIN_HL_PMTU field indicates the payload size.
PMTU: 14 bits
Indicates the real PMTU size in 32-bit words. This value
defines the full EHTP packet size, including all necessary
headers and an authentication data. PMTU value may be reduced
by gateways up to size from MIN_HL_PMTU field in view of EHTP
headers length. If the gateway may not provide the minimally
necessary value, the following variants are possible:
o MTU, which may be provided, is written in packet, and the
packet is sent forward. The INIT receiver forms INIT-ACK
command with changed PMTU. The initiator of connection
establishment may silently discard INIT-ACK, if PMTU does
not arrange it.
o Boundary nodes of a hop, which may not provide PMTU, fix
themselves in connection route (see section 6). All
subsequent connection packets are fragmented and
assembled on these boundary nodes by lower level
Bogdanov Expires: January 2003 [Page 20]
Internet-Draft End-by-Hop Transmission Protocol July 2002
protocol. A fragmentation MUST NOT is for end-to-end
interactions at EHTP layer.
PMTU connection MAY be less, than a size of packets with
connection establishment commands (for example, if connection
requires the small packets size for maintenance of desired
QoS).
TMP_CONNECTION_ID: 32 bits
Indicates the temporary identifier, which assigned the sender
of this packet. It MUST be copied by the receiver in base
header CONNECTION_ID field of a response command.
SPI: 32 bits
This field contains the security parameters index (SPI), which
defines the authentication of this packet at EHTP layer. The
endpoints must agree upon this field values beforehand. The
protocol does not impose any restrictions on SPI values and
does not give any rules of its using. SPI field is present at
an option, if HEAD_LENGTH = 3. Otherwise, it is absent. Value
SPI from INIT and INIT-ACK commands is temporary and may be
changed in the following packets of a connection establishment.
The receiver of INIT command must not save a state of connection and
allocate resources before correct CONNECT command receiving.
The gateway, immediately connected with the endpoint of INIT
receiver, may form INIT-ACK command. For example, if the endpoint is
connected on the switched channel.
5.1.1.2 CONNECT, CONNECT-ACK
CONNECT command is sent by the initiator of connection establishment
after INIT-ACK command reception. CONNECT-ACK command is sent, as
the positive response to CONNECT command on last step of connection
establishment. CONNECT and CONNECT-ACK commands MUST be formed as a
gateway option. The packet containing these commands MAY include the
upper layer data relating to this connection. CONNECT and CONNECT-
ACK commands have an identical format and differ only by OPCODE
value. Fields of base header must have the following values:
SEQUENCE_NUM - For CONNECT command this field contains a sequence
number from SEQUENCE_NUM field of INIT-ACK
command. For command CONNECT-ACK this field
contains a sequence number from FIRST_SEQUENCE_NUM
field of CONNECT command.
Bogdanov Expires: January 2003 [Page 21]
Internet-Draft End-by-Hop Transmission Protocol July 2002
SERVICE_ID - This field contains the service identifier of
established connection. It must coincide with
INIT-ACK command.
DATA_LENGTH = 0-65535
CONNECTION_ID - For CONNECT command, this field value is copied
from TMP_CONNECTION_ID field of INIT-ACK command.
For CONNECT-ACK command, value of this field is
copied from PERM_CONNECTION_ID field of CONNECT
command.
The option of CONNECT and CONNECT-ACK commands has the following
format:
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 0 1 0 1|E|D|G| HEAD_LENGTH | OPCODE | SC_MAX |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|T|V| MIN_HL_PMTU |RSV| PMTU |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| INACTION_TIME | FIRST_SEQUENCE_NUM |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PERM_CONNECTION_ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|RSV| CHK_LEN | RESERVED |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SPI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The fields of general format have the following values:
E = 1
D = 1
G = 1
HEAD_LENGTH = 4/5 (depends on SPI presence)
OPCODE =
3 for CONNECT
4 for CONNECT-ACK
SC_MAX: 8 bits
Indicates the maximal number of secondary connections, which
may be connected with this initial. The zero value forbids
establishing the secondary connections, connected with this
primary connection. Value 255 specifies that the maximum
quantity of secondary connections is not fixed at connection
establishment and may be anyone. When the limit will be
exhausted during work, S-DISCONNECT command with ERROR_CODE = 8
Bogdanov Expires: January 2003 [Page 22]
Internet-Draft End-by-Hop Transmission Protocol July 2002
must be used for the connections restriction. Final value of
SC_MAX field is defined in CONNECT-ACK command.
T: 1 bit
The short connection identifier flag. If it is set, the packet
sender can unequivocally identify connection on lowest two
bytes of the PERM_CONNECTION_ID field. After a connection
establishment to address of this packet sender, the packets
with short base header may be sent.
V: 1 bit
If this bit is set, secondary connections with other SERVICE_ID
value may be connected with this primary connection. If this
bit is not set, secondary connections MUST be only with same
SERVICE_ID value. Final value of the V bit in connection is
set in CONNECT-ACK command.
RSV + RESERVED: 2 + 2 + 24 bits
These fields should be set to zero on transmit and ignored on
receipt.
MIN_HL_PMTU: 14 bits
Indicates the upper layer PMTU minimal size in 32-bit words
(see above section).
PMTU: 14 bits
Indicates the realizable PMTU size in 32-bit words (see above
section).
INACTION_TIME: 8 bits
The reserved inactive time. This field contains time interval
in seconds, at which expiration gateways will deallocate
connection resources at traffic absence (see section 6.8).
FIRST_SEQUENCE_NUM: 24 bits
This field contains the initial sequence number of the
receiver. The consecutive numeration of connection packets,
which will be sent by this command receiver, must be begun from
this number. It is RECOMMENDED, that this field value will be
difficult for predicting. For the receiver of CONNECT command,
this number MUST be copied in a packet with CONNECT-ACK
Bogdanov Expires: January 2003 [Page 23]
Internet-Draft End-by-Hop Transmission Protocol July 2002
command. For the receiver of CONNECT-ACK command, this number
MUST be copied in the first connection data packet.
PERM_CONNECTION_ID: 32 bits
This field contains the permanent identifier, assigned to
connection by this packet sender.
CHK_LEN: 5 bits
Specifies number of the first 4-byte words from DATA field,
which will be included in calculation of the checksum or
authentication data. If this field is set to zero, DATA field
MUST NOT be included in calculation. If value is set to
%b11111, calculation includes full DATA field. Value CHK_LEN
is applied to all packets of new connection, transmitted by the
sender of this command. Headers EHTP are included in
calculation of the checksum irrespective of this field value.
If CHK_LEN value to not multiply required value, conditional
zero addition is used at calculation of the checksum.
SPI: 32 bits
This field contains the security parameters index (SPI), which
defines a packets authentication of this connection at EHTP
layer downstream of this packet. Not all subsequent packets of
connection contain SPI field. Therefore, this value must be
stored, as a state variable of this connection by both
endpoints. SPI value from CONNECT-ACK and CONNECT commands may
differ. If HEAD_LENGTH = 4, SPI field is absent.
V, SC_MAX and INACTION_TIME fields of the CONNECT command MAY be
modified by the gateways fixed in a route. The receiver of the
CONNECT command MUST NOT increase these fields value.
The connection establishment initiator MUST NOT sends data packets
before reception of CONNECT-ACK command. All data packets received
on connection before reception of CONNECT-ACK command MUST be discard
silently. After reception of CONNECT-ACK command connection is
considered established.
After sending CONNECT-ACK command, the sender node considers
connection established. The first data packet received by CONNECT-
ACK sender, MUST have initial sequence number (from
FIRST_SEQUENCE_NUM field of option). Before reception of this
packet, all other packets of connection MUST be discard silently.
5.1.1.3 Identifiers Exchanging Scheme
Bogdanov Expires: January 2003 [Page 24]
Internet-Draft End-by-Hop Transmission Protocol July 2002
The scheme of identifiers exchange in procedure of primary connection
establishment is represent in the following figure:
Initiator Responder
--------- ----------
INIT [ SEQUENCE_NUM = 0,
CONNECTION_ID = any value
TEMP_CONNECTION_ID = TempID1 ] ---------->
<---------- INIT-ACK [ SEQUENCE_NUM = TempNum1,
CONNECTION_ID = TempID1,
TEMP_CONNECTION_ID = TempID2 ]
CONNECT [ SEQUENCE_NUM = TempNum1,
CONNECTION_ID = TempID2,
FIRST_SEQUENCE_NUM = SeqNum1,
PERM_CONNECTION_ID = PermConnID1 ] ---------->
<---------- CONNECT-ACK [ SEQUENCE_NUM = SeqNum1,
CONNECTION_ID = PermConnID1,
FIRST_SEQUENCE_NUM = SeqNum2,
PERM_CONNECTION_ID = PermConnID2 ]
DATA [ SEQUENCE_NUM = SeqNum2,
CONNECTION_ID = PermConnID2 ] ---------->
<---------- DATA [ SEQUENCE_NUM = SeqNum1 + 1,
CONNECTION_ID = PermConnID1 ]
5.1.2 Secondary Connection Establishment
The purpose of a secondary connection establishment is:
o An allocation of a separate data flow within the framework of
the same service of the upper layer,
o The accelerated establishment of new connection with the same
or new service of the upper layer.
For the upper layer the service of primary and secondary connections
not differ.
All secondary connections have the following general procedures with
primary connection:
o One sequence of sequence numbers in SEQUENCE_NUM field and
general congestions control is conducted.
Bogdanov Expires: January 2003 [Page 25]
Internet-Draft End-by-Hop Transmission Protocol July 2002
o Have general SPI and PMTU.
o Use one explicit route (see section 6).
o Closing of primary connection results in closing all secondary
connections related to it.
Procedure of a secondary connection establishment consists of two
steps. The initiator of secondary connection sends BIND command on
primary connection. In reply to it, BIND-ACK command is sent. Both
commands may contain a upper layer data of new connection. The
initiator of secondary connection may be the initiator or the
responder of primary connection.
The packet with BIND command MUST have the ordered sequence number.
If the SEQUENCE_NUM value is not ordered, the packet with the command
is silently discarded.
Packets of secondary connection have the new CONNECTION_ID values and
do not contain the information on primary connection. This
information should be saved in endpoints variable states.
BIND and BIND-ACK commands have an identical format. Difference is
the OPCODE and CONNECTION_ID values of base header. Fields of base
header must have the following values:
SEQUENCE_NUM - The current sequence number of primary connection.
SERVICE_ID - This field contains the service identifier of
establishing secondary connection.
DATA_LENGTH = 0-65535
CONNECTION_ID - For BIND command, it is the identifier of primary
connection assigned by the receiver of this
packet. For BIND-ACK command, it is the
identifier from CONNECTION_ID field of packet with
BIND command.
BIND and BIND-ACK are formed as endpoints options and have the
following format:
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 0 1 0 1|E|D|0| HEAD_LENGTH | OPCODE |T|RSV| CHK_LEN |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SEC_CONNECTION_ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The fields of general format have the following values:
D = 1
HEAD_LENGTH = 1
Bogdanov Expires: January 2003 [Page 26]
Internet-Draft End-by-Hop Transmission Protocol July 2002
OPCODE =
5 for BIND
6 for BIND-ACK
T: 1 bit
The short connection identifier flag. If it is set, all
packets of new connection, sent to address of sender of this
command, must include the base header of 8 or 4 bytes length.
If it is not set, the base header MUST have the length of 12
bytes.
RSV: 2 bits
Reserved. This bits should be set to 0 on transmit and ignored
on receipt.
CHK_LEN: 5 bits
Specifies number of the first 4-byte words from DATA field,
which will be included in calculation of the checksum or
authentication data. If this field is set to zero, DATA field
MUST NOT be included in calculation. If value is set to
%b11111, calculation includes full DATA field. Value CHK_LEN
is applied to all packets of new connection, transmitted by the
sender of this command.
SEC_CONNECTION_ID: 32 bits
This field contains the identifier of secondary connection,
assigned by the sender of this packet.
The initiator sends BIND command. After that, it must wait for BIND-
ACK command up to sending of the following data packet of the new
connection. The disordered data packets of new connection may be
received before BIND-ACK reception. Cumulative acknowledgement
number does not confirm reception of BIND command.
After sending of BIND-ACK positive response, the sender considers
that connection is established. The DISCARDED-PACKET option is sent
as the negative acknowledgement to BIND (see section 6.4).
Data packets of secondary connection have the CONNECTION_ID fields
copied from the SEC_CONNECTION_ID field of the received command.
BIND and BIND-ACK command does not stop data transmission on other
connections.
5.1.3 0 - connection
Bogdanov Expires: January 2003 [Page 27]
Internet-Draft End-by-Hop Transmission Protocol July 2002
The primary connection with zero SERVICE_ID value (0-connection) may
be established between two endpoints. The purpose of 0-connection
establishment may be:
o restriction quantity of connections, which may be
simultaneously open between two nodes,
o grant of connectionless service for the upper layer.
It MUST NOT be established more than one 0-connection, which is not
using an authentication or having one value of an security parameter
index SPI between two nodes. Reservation parameters may be
considered as the additional index, allowing to establish repeated 0-
connections.
0-connection may be established by the following fashions:
(1) The initiator of primary connection set the SERVICE_ID to
zero in INIT command. All other commands of the primary
connection establishment MUST have zero value of this field.
(2) The responder of primary connection establishment makes a
decision on 0-connection independently. In this case it set
SERVICE_ID = 0 in reciprocal INIT-ACK command. The
initiator MUST accept this value and copy it in CONNECT
command.
(3) 0-connection may request a gateway. For this purpose it
must set SERVICE_ID = 0 in INIT command.
Secondary connections are used for upper layer service irrespective
from the 0-connection establishment initiator. BIND command may be
attached to a packet containing CONNECT command of 0-connection.
Receiving of the second request about an establishment 0 - connection
may be examined as an emergency reload of the source node. In this
case, the INIT command receiver MUST execute the following:
(1) To send the INIT-ACK command not saving a state of new
connection.
(2) The node must start activity check on existing connection
after reception of reciprocal CONNECT command (see section
6.8). The CONNECT-ACK command must not be sent before end
of checking. If existing connection is active, the packet
with CONNECT command MUST be silently discard.
Receiving of incorrect INIT-ACK command, CONNECT or CONNECT-ACK with
SERVICE_ID = 0 is examined as a error. Such packet MUST be silently
discarded.
Bogdanov Expires: January 2003 [Page 28]
Internet-Draft End-by-Hop Transmission Protocol July 2002
0-connection may be used for connectionless data transmission (for
upper layer service). For such packets the following conditions MUST
be satisfied:
o CONNECTION_ID has the 0-connections value, assigned by the
packet receiver.
o SERVICE_ID has nonzero value.
o The Packet contains an upper layer data.
o The Packet does not contain BIND command.
All packets of 0-connection MUST contain the base header in length of
12 bytes.
5.1.4 Receiving Window Restriction
RCV-WINDOW option is used to inform an opposite endpoint in
connection the maximal receiving window size for upper layer data.
It is formed as an endpoint option and has the following format:
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 0 1 0 1|E|D|0| HEAD_LENGTH | OPCODE | WINDOW_SIZE1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| WINDOW_SIZE2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The fields of general format have the following values:
D = 1
HEAD_LENGTH = 0/1
OPCODE = 7
WINDOW_SIZE1: 1 byte
If HEAD_LENGTH = 0, this field indicates the window size in 4-
KByte blocks. If HEAD_LENGTH = 1, this field is set to 0.
WINDOW_SIZE2: 4 bytes
If HEAD_LENGTH = 1, this field indicates the window size in
bytes. The value MUST be multiple to four. If HEAD_LENGTH =
0, this field is absent.
The RCV-WINDOW option sets a maximum data quantity of the upper
layer, which are sent and are not confirmed with cumulative
Bogdanov Expires: January 2003 [Page 29]
Internet-Draft End-by-Hop Transmission Protocol July 2002
acknowledgement. The option may be transferred in any connection
packet, starting with CONNECT or BIND command.
The RCV-WINDOW option may be used for primary and secondary
connections. This option concerns only to connection on which it was
transmitted. The window restriction of primary connection does not
influence on secondary connections. The RCV-WINDOW option MUST NOT
be used for 0-connection.
At EHTP layer, the received data is sent to the upper layer without
buffering. Therefore, window restriction is service, which is given
on demand of the upper layer. Thus, RCV-WINDOW option limits a
window at EHTP layer. If the upper layer has its functions of a
window restriction or the ordered data flows is not require to it,
this option is not used.
5.1.5 Security Parameters Index Changing
SPI must be changed, if the sequence numbers counter has passed a
full cycle or if SPI lifetime has expired. The CHG-SPI option is
used for SPI change. It has the following format:
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 0 1 0 1|E|D|0| HEAD_LENGTH | OPCODE | RESERVED |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NEW_SPI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The fields of general format have the following values:
D = 1
HEAD_LENGTH = 1
OPCODE = 8
RESERVED : 8 bits
Reserved. These bits should be set to 0 on transmit and
ignored on receipt.
NEW_SPI : 32 bits
Indicates the new value of SPI connection that will be used by
the sender of this packet.
CHG-SPI option MUST be formed as an endpoint option. It joins any
packet of primary or secondary connection and changes SPI for primary
connection and everything secondary connections connected to it. The
Bogdanov Expires: January 2003 [Page 30]
Internet-Draft End-by-Hop Transmission Protocol July 2002
packet with CHG-SPI option uses old SPI. All packets with following
numbers MUST use new SPI. The option changes SPI only in one
direction.
5.1.6 Connection Termination
All commands of connections termination: DISCONNECT, S-DISCONNECT,
DISCONNECT-ACK and S-DISCONNECT-ACK are formed as an endpoints
options, have an identical format and differ only in OPCODE value:
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 0 1 0 1|E|D|0| HEAD_LENGTH | OPCODE | ERROR_CODE |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The fields of general format have the following values:
D = 1
HEAD_LENGTH = 0
OPCODE =
9 for DISCONNECT
10 for S-DISCONNECT
11 for DISCONNECT-ACK
12 for S-DISCONNECT-ACK
ERROR_CODE: 8 bits
Termination error code. Zero value defines normal end.
Nonzero value defines abend. Error codes are described in
section 5.1.7.
End of primary connection automatically finishes all secondary
connections connected to it. End of secondary connection does not
influence on other connections. For primary connection termination,
DISCONNECT and DISCONNECT-ACK is used. For secondary connection
termination, S-DISCONNECT and S-DISCONNECT-ACK are used. Packets
with DISCONNECT-ACK and S-DISCONNECT-ACK commands MUST NOT include
the payload.
The initiator of primary connection termination sends DISCONNECT
command. After itÆs sending, the endpoint closes primary connection
and all secondary connections connected to it. Incoming packets must
be silently discarded. The addressee of the DISCONNECT command
immediately sends DISCONNECT-ACK command and closes connection.
The initiator of secondary connection termination sends S-DISCONNECT
command. After itÆs sending, the endpoint stops the outgoing traffic
of secondary connection. The DISCARDED-PACKET option is sent instead
Bogdanov Expires: January 2003 [Page 31]
Internet-Draft End-by-Hop Transmission Protocol July 2002
of the packets acknowledgment of this connection, in order not to
stop cumulative sequence number counter. The addressee of DISCONNECT
command immediately sends DISCONNECT-ACK command and closes
connection.
Connection termination may be initiated, since the answer to CONNECT
command. Connection termination always MUST be from two steps.
If the endpoint has received DISCONNECT-ACK and did not send
DISCONNECT on this connection, it is recommended to start
reconnection procedure (see section 6.2.3.3). If the endpoint has
received S-DISCONNECT-ACK and it did not send S-DISCONNECT on this
secondary connection, it is recommended to send S-DISCONNECT-ACK
command and to close connection.
5.1.7 Termination Error Codes
The following error codes are defined for termination commands:
1 - The connection establishment without payload is not supposed.
The endpoint may demand to establish connection only if the
upper level has data for transfer. In this case, the data
must be transferred on the third step of the connection
establishment.
2 - The connection establishment is impossible at the present time
because of temporal network overload or the channel
employment. The repeated establishment MUST begin with INIT
command.
3 - Connection is impossible because of a network steady overload.
4 - The endpoint is temporarily inaccessible.
5 - The expectation time-out of the CONNECT-ACK command is
exceeded.
6 - Inadmissible value of reserved inactive time.
7 - Connection through the not fixed route is not allowed.
8 - the limit of secondary connections is exhausted.
9 - Erroneous request on new 0-connection establishment. Such
connection is already established.
10 - the unknown destination address.
11 - Connection is completed under the initiative of the upper
level.
12 - Connection is completed because of endpoint inactivity.
15 - The non-supported protocol version.
16 - Inadmissible limit of secondary connections.
255 - Unexpected error.
5.2 User Data Transfer
The confirmed packet is identified on a combination of the
CONNECTION_ID, SERVICE_ID and SEQUENCE_NUM fields values. If the
Bogdanov Expires: January 2003 [Page 32]
Internet-Draft End-by-Hop Transmission Protocol July 2002
upper level demands delivery acknowledgement, SEQUENCE_NUM field MUST
have nonzero value. If delivery acknowledgement is not required,
SEQUENCE_NUM field MUST be set to zero.
The destination endpoint does not write received data packets in the
buffer and transfers their to upper level at once. The full size of
a packet must not exceed PMTU connection. The upper level must
implement packing functions. The upper level may set minimal PMTU,
which is required for its work, at a connection establishment.
The SEQUENCE_NUM field value in a combination with P flag of the
basic header operates acknowledgement formation. The following logic
is defined:
SEQUENCE_NUM = 0 & P = 0 - The acknowledgement MUST NOT be formed
on this packet.
SEQUENCE_NUM # 0 & P = 0 - Acknowledgement on this packet MUST be
sent, probably, with a small delay for
traffic optimization.
P = 1 - Acknowledgement MUST be sent. It is NOT RECOMMENDED to
detain itÆs sending. If SEQUENCE_NUM of the received
packet is set to 0, acknowledgement MUST be sent on last
ordered packet. If the upper level data are acknowledged,
the packet with acknowledgement must have P = 1.
For time-outs and repeated transfers number calculation, it is
possible to use the recommendations, given in [20]. If the upper
level does not demand delivery acknowledgement (SEQUENCE_NUM = 0), it
is not transferred repeatedly.
If the received packet has incorrect CONNECTION_ID value, it MUST be
silently discarded. All disordered packets with displacement from
the ordered number, exceeding 65535, MUST be silently discarded.
It is supposed, that acknowledgement occupies essential traffic
volume. Therefore, the protocol defines three variants of
acknowledgement for an opportunity of optimization.
5.2.1 The Packet of Cumulative Data Acknowledgement
The sending of cumulative acknowledgement packet may be optimum if
there is no the upper level data traffic in the necessary direction
on connection. It has the special format of base header:
Bogdanov Expires: January 2003 [Page 33]
Internet-Draft End-by-Hop Transmission Protocol July 2002
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 0 1 1 0|E|P|R| SEQUENCE_NUM |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SERVICE_ID | DATA_LENGTH |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CONNECTION_ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
E, P, R, DATA_LENGTH, SERVICE_ID, CONNECTION_ID
Assignment of these fields is described in section 4.2.
SEQUENCE_NUM: 24 bits
Indicates the cumulative acknowledged sequence number.
The packet of cumulative acknowledgement MUST NOT contains the upper
level data (DATA_LENGTH = 0).
5.2.2 CUM-ACK
CUM-ACK option is used for cumulative acknowledgement. The packet
including this option may contain the payload. CUM-ACK is formed in
a packet as an endpoint option and has the following format (differs
from the general option format):
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 1 0 0 0|E|1|0| CUM_SEQUENCE_NUM |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
E: 1 bit
Flag of the following option (see section 4.4).
CUM_SEQUENCE_NUM: 24 bits
Indicates the cumulative acknowledged sequence number.
5.2.3 GAP-ACK
GAP-ACK is an endpoint option. It contains cumulative
acknowledgement and selective acknowledgement blocks. The packet
Bogdanov Expires: January 2003 [Page 34]
Internet-Draft End-by-Hop Transmission Protocol July 2002
including this option may contain the payload. GAP-ACK option has
the following format:
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 0 1 0 1|E|D|0| HEAD_LENGTH | OPCODE | CUM_SEQ_NUM |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CUM_SEQ_NUM (continuation) | GAP_PACKET |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| GAP_BLOCK_1_START | GAP_BLOCK_1_END |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| GAP_BLOCK_n_START | GAP_BLOCK_n_END |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The fields of general format have the following values:
D = 1
HEAD_LENGTH = 1 - 255
OPCODE = 13
CUM_SEQ_NUM: 24 bits
Indicates the cumulative acknowledged sequence number (all
packets with this and smaller sequence numbers were received).
GAP_PACKET: 16 bits
The acknowledgement of one disordered packet. Value is
positive displacement from CUM_SEQ_NUM of this option. Zero
value means absence of single acknowledgement.
GAP_BLOCK_n_START + GAP_BLOCK_n_END: 16 + 16 bits
These fields contain the beginning and the end (inclusive) of
the selective acknowledgement block. These values are positive
displacement from cumulative acknowledgement CUM_SEQ_NUM value
of this option. The option may contain several selective
acknowledgement blocks.
5.3 Congestion Control
EHTP uses the congestion control determined for TCP [6,15] and SCTP
[7] for endpoint with the one address. EHTP primary connection and
all secondary connections connected to it use common sequence
Bogdanov Expires: January 2003 [Page 35]
Internet-Draft End-by-Hop Transmission Protocol July 2002
numbering packets and the common congestion control. In too time,
EHTP allows establishing a rwnd receiving window separately for
primary connection and for everyone secondary. Besides, the
receiving window can be not established. In this case, it is
considered infinite large. Therefore there are following essential
features:
o At operations with ssthresh and cwnd values, primary connection
and everything connected to it secondary connections are
considered as one stream. Thus, cumulative acknowledgement
value is taken into account only, and selective
acknowledgements are ignored.
o Restriction rwnd is taken into account separately for primary
connection for each secondary connection.
If the data packet does not demand acknowledgement, it has a zero
sequence number. Besides, a cumulative acknowledgement packets (see
section 5.2.1) which also have no the sequence number, may be
transferred on connection. Thus, there may be traffic in connection,
which is taken into account by transfer and has no acknowledgement.
The packet sender without acknowledgement conditionally counts
sequence number of this packet on unit more, than last sent packet
with acknowledgement. The packet without acknowledgement request is
considered delivered to the receiver (in functions of congestion
control) in the following cases:
o If cumulative acknowledgement of the following packet (with
number equal to conditional number of a packet without
acknowledgement) is received.
o In case, if the traffic without request of acknowledgement is
transferred only in connection, the data sender may take
advantage of P pushing flag. If P = 1, acknowledgement is sent
irrespective of SEQUENCE_NUM value. Packets without
acknowledgement request must not be sent no more, than two per
round trip time (RTT) if P flag is not used and there are no
packets with acknowledgement request. Use of P flag for
implicit congestions control is not defined in this document
and left for experiments.
The algorithm of management of congestions is used by endpoints. In
too time gateway with state may supervise a transfer policy of
separate nodes and lower a priority for the data, not sticking to
rules.
EHTP gives a sluice an optional means obviously to inform about the
rejected packets (see section 6.4) except for implicit congestion
control.
Bogdanov Expires: January 2003 [Page 36]
Internet-Draft End-by-Hop Transmission Protocol July 2002
6 The Gateway Protocol
This document supposes that the quantity of global networks is
limited at a network layer, and the typical endpoint has the global
network address or it is connected with a global network through one
EHTP gateway. In such configuration, the basic work on routing
packets is conducted at a network layer. This document does not
include the routing protocol. It is supposed, that EHTP can work at
static routing in such configuration. Besides, the routing protocol
is supposed, as a separate problem.
The protocol includes three routing variants:
(1) Implicit routing based on transport addresses.
(2) The route is explicitly set by sequence of gateways transport
addresses, which are included in a packet.
(3) Explicit routing based on labels [17,19].
The explicit route of packets select at a primary connection
establishment. All three routing ways may be applied to one
connection simultaneously. The packet may contain a route as
sequence of the following address objects:
(1) The gateway address without label. This object contains only
the gateway transport address.
(2) The gateway address with label. In addition to the gateway
transport address, this object includes the label allocated
by this gateway.
(3) Label.
Address objects are formed in gateways options before basic header.
The sequence of address objects in a packet defines sequence in a
route. The first object defines the first hop.
The protocol gives a possibility to deallocate resources of gateways
dynamically at absence of the connection traffic. Therefore, two
labels types are defined:
o The stateless label. This label does not control activity of
connection. It has unlimited or uncertain period of validity.
o The label with state. This label deallocates resources of a
gateway after expiration of the reserved inactive time (see
section 6.8).
In the text of this document, the "label" term means a label of any
type. The label may be allocated by the lower layer or EHTP layer.
The protocol defines the following gateways types:
Bogdanov Expires: January 2003 [Page 37]
Internet-Draft End-by-Hop Transmission Protocol July 2002
(1) The obligatory gateway. Connection MUST be established
through this gateway. If the sequence of obligatory
gateways is defined, it MUST NOT be broken (without
consideration gateways of other types).
(2) The fixed gateway. Direct and return traffic of connection
through such gateway MUST coincide.
(3) The explicit gateway. The gateway is fixed in a route of
connection, but direct and return traffic through these
gateways may differ.
(4) The free gateway. This gateway do not contain in an
explicit route of connection. The traffic through it may be
anyone.
Gateways of first three types contain in an explicit route of a
packet.
It may be any quantity of EHTP gateways in a route. The route of
connection may traverse several MPLS areas; areas with routing based
on addresses and switched channels in any combination.
EHTP does not require from gateways to store a connections state.
Therefore, independent formation of packets is not defined by EHTP
gateway. The gateway may only attach options to endpoints packets or
modify them. If it is necessary to transfer the error message for
packet, the gateway must delete DATA field from this packet and set
to 0 the checksum.
6.1 Gateway Options
6.1.1 GATEWAY-HEADER
GATEWAY-HEADER indicates the gateway of packet explicit route. It
has the special format, which differs from the general option format:
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 0 1 1 1|E|D|G|RSV| GL |GTP|W|B|F|S|I|N| RESV | O_COUNT |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ GTW_NODE_ADDR ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ ZERO_PADDING ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Bogdanov Expires: January 2003 [Page 38]
Internet-Draft End-by-Hop Transmission Protocol July 2002
E, D, G
These bits have assignment that is defined in section 4.4 for
the general option format.
RSV: 2 bits
Reserved. This bit must be set to zero by the sender. If
these bits are not set to 0 on receipt, the packet MUST be
silently discard without no further action.
GL: 4 bits
The ADDR_LENGTH field of the gateway transport address (see
section 3.1).
GTP: 2 bits
The NET_TYPE field of the gateway transport address.
W: 1 bit
The processing flag. If it is not set, this header indicates
not traversed gateway. If it is set, the heading indicates on
traversed gateway. This flag is set by gateway at forwarding.
B: 1 bit
The flag of obligatory gateway. If it is set, the connection
MUST be established through this gateway.
F: 1 bit
The traffic fixing flag. If it is set, all direct and return
connection traffic MUST pass through this gateway.
S: 1 bit
The label with state flag. If it is set, the gateway has
allocated a label with state, which will be deallocated by
gateway after the expiration of reserved inactive time (see
section 6.8). If it is not set, the gateway will not supervise
connection activity. The S flag is used at a connection
establishment only.
I: 1 bit
The immediate hop flag. It is used only at a connection
establishment. Value is set after processing header by the
Bogdanov Expires: January 2003 [Page 39]
Internet-Draft End-by-Hop Transmission Protocol July 2002
gateway. If it is set, the label allocated by the gateway
defines direct hop up to the previous gateway in explicit
route. If it is not set, it can be a free gateway between this
gateway and previous.
N: 1 bit
Flag of preservation of the following label. It is used at a
connection establishment only. Value is set after processing
header by the gateway. If it is set, the label allocated by a
gateway saves the following address object of an explicit
route. If it is not set, the gateway does not save a following
address object.
RESV: 4 bits
These bits should be set to zero on transmit and ignored on
receipt.
O_COUNT: 6 bits
Indicates the options quantity, which concern to this header.
The slave options must be located immediately behind gateway
header in a packet.
GTW_NODE_ADDR : 0-256 bytes
The NODE_ADDR field of the gateway transport address. If GL =
0 and GTP = 0, this field is absent. Zero GTW_NODE_ADDR value
indicates any node of the set network. After processing
header, to zero GTW_NODE_ADDR field the real address must be
assigned.
ZERO_PADDING : 0-3 bytes
Zero bytes for alignment of header end on border four bytes.
Error messages, which are formed by gateways (DISCARDED-PACKET,
GATEWAY-ERROR, NEW-PMTU options (see sections 6.4, 6.5, 6.6), do not
contain the gateway address. In order to inform about the gateway
address, which has generated the option, option may be the
subordinate to gateway header. The gateway MUST set in header E and
W flags at forwarding.
6.1.2 LABEL-HEADER
LABEL-HEADER option contains a gateway label in length of 28 bits and
has a special format which differs from general option format:
Bogdanov Expires: January 2003 [Page 40]
Internet-Draft End-by-Hop Transmission Protocol July 2002
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0|0|0| LABEL_VALUE |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
LABEL_VALUE: 28 bits
The protocol does not impose any restrictions on values of this
field. It is supposed, that the gateway which has allocated
this label, can unequivocally identify its format.
6.1.3 GENERAL-LABEL
The GENERAL-LABEL option is a label, which is defined in General
Switch Management Protocol v3 [18]. This option has a special
format, which differs from general option format:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 1 0 0| Label Type | Label Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Label Value ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Label Type
A 12-bit field indicating the type of label.
Label Length
A 16-bit field indicating the length of the Label Value field
in bytes.
Label Value
A variable length field that is an integer number of 32 bit
words long. The Label Value field is interpreted according to
the Label Type as described in [18].
Stacked Label Indicator is not used, as EHTP has other methods of
calculation of a labels stack end.
6.1.4 LABEL-OPTION
Bogdanov Expires: January 2003 [Page 41]
Internet-Draft End-by-Hop Transmission Protocol July 2002
The LABEL-OPTION contains a label of any format in length up to 1020
bytes. The option has the following format:
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 0 1 0 1|E|D|G| HEAD_LENGTH | OPCODE | RESERVED |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ LABEL_VALUE ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fields of general format have the following values:
E = 0
D = 0
G = 1
HEAD_LENGTH = 1 - 255
OPCODE = 14
RESERVED: 8 bits
This field should be set to zero on transmit and ignored on
receipt.
LABEL_VALUE: 4 - 1020 bytes
The protocol does not impose any restrictions on this field
values. It is supposed, that the gateway which has allocated
this value, can identify a format unequivocally.
6.1.5 COOKIE-GATEWAY
The COOKIE-GATEWAY option is used at a connection establishment for
checking of endpoints. It has the following format:
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 0 1 0 1|E|D|G| HEAD_LENGTH | OPCODE | C_LIFE_TIME |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ COOKIE_VALUE ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fields of general format have the following values:
Bogdanov Expires: January 2003 [Page 42]
Internet-Draft End-by-Hop Transmission Protocol July 2002
E = 1
D = 1
G = 0
HEAD_LENGTH = 1 - 255
OPCODE = 15
C_LIFE_TIME : 8 bits
The lifetime of this COOKIE in minutes. Value 0 indicates
uncertain lifetime value. Value 255 is reserved.
COOKIE_VALUE : 4-1020 bytes
The protocol does not impose any restrictions on a format and
value of this field. It can be hashing function of
unchangeable parameters of primary connection, the endpoint and
time. It is recommended, that this value was difficult for
predicting.
COOKIE-GATEWAY is formed by a gateway as the subordinated option of
gateway header and is sent to endpoints. The endpoint must attach
received GATEWAY-COOKIE to all packets of a connection establishment
if the gateway contains in an explicit route. GATEWAY-COOKIE
formation is recommended. The gateway makes a decision on sending
GATEWAY-COOKIE independently. At various times they can be sent in
both connection sides, only aside the initiator or to not be sent.
Endpoints must save COOKIE value for use in reconnection commands.
New COOKIE-GATEWAY replaces an old. COOKIE-GATEWAY option MUST be
sent only in packets with commands of a connection establishment and
reconnection.
6.2 Connections Control through Gateways
6.2.1 Connection Establishment
Gateways participate only in a primary connections establishment.
Secondary connections use a route and reservation of resources of the
primary connection. The gateways of explicit route participate in a
connections establishment only. If the gateway is free, it does not
participate in a connections establishment.
At a connection establishment the gateway MAY execute the following
procedures:
o checking of COOKIE from the initiator and the responder,
o fixing of a connection route,
o labels assignment and distribution.
Bogdanov Expires: January 2003 [Page 43]
Internet-Draft End-by-Hop Transmission Protocol July 2002
The explicit route is set at a connection establishment and may be
changed only at reconnection. The gateways options defining a route,
MUST follow connection establishment commands in a packet. Gateways
of all types may present at one connection simultaneously. The
gateway, which forms COOKIE in two sides, must be fixed in the direct
and return traffic.
Labels are distributed upstream. Labels allocation for connection is
executed on the third step (CONNECT command from initiator to
responder) for the traffic from responder to initiator and on the
fourth step (CONNECT-ACK command from responder to initiator) for the
traffic from initiator to responder. The label is allocated by a
gateway after its COOKIE checking. For acceleration of a connection
establishment, the protocol allows to distribute initial labels on
the first and second step of a connection establishment.
At a stage of a connection establishment, the explicit route is set
in a packet by sequence of GATEWAY-HEADER options. After a
connection establishment, it is possible to replace gateways headers
with labels. All packets with commands of a connection establishment
must contain addresses header of endpoints and transport addresses of
gateways in GATEWAY-HEADER.
For a gateway, the following processing rules of the explicit routing
information in packets with of a connection establishment commands
(on steps) are defined:
1 step - sending of INIT command from the initiator to the responder:
o If the gateway header does not contain in a packet, it may be
inserted.
o The gateway may allocate a temporary stateless label for the
second step of a connection establishment (from the responder
to the initiator). By forwarding, the gateway header must
contain the transport address and the label.
o It is possible to add gateways in not traversed area of a
route.
o It is possible to add gateways on the traversed area of a route
directly ahead of this gateway, if it is known, that the added
gateway must not send COOKIE aside the responder.
o The responder, at reception of INIT command, forms a return
packet with another or with the same route, having changed the
order of GATEWAY-HEADER options on back.
2 step - sending of INIT-ACK command from the responder to the
initiator:
Bogdanov Expires: January 2003 [Page 44]
Internet-Draft End-by-Hop Transmission Protocol July 2002
o If the gateway header is not contained in a packet, it may be
inserted. In this case, the gateway cannot send COOKIE aside
the responder.
o If the gateway header in the received packet contains a label,
routing of this packet is carried out on this label. By
forwarding, the label must be deleted or replaced with other
temporary label of this gateway allocated for the third step of
a connection establishment (from the initiator to the
responder).
o If there is no gateway label in the received packet, it may be
allocated for the third step of a connection establishment.
o If the temporary label is allocated, the gateway header must
contain the transport address and the label by forwarding.
o It is possible to add gateways on the not traversed area of a
route directly ahead of this gateway, if it is known, that the
added gateway must not send COOKIE aside the responder.
o It is possible to add gateways on the traversed area of a route
directly ahead of this gateway, if it is known, that the added
gateway must not send COOKIE in both sides of connection.
o The initiator may silently refuse a connection establishment,
if it does not accept a route in the received packet with INIT-
ACK command.
3 step - sending of the CONNECT command from the initiator to the
responder:
o If the gateway header does not contain in a packet, it may be
inserted. In this case, the gateway cannot send COOKIE in both
sides of connection.
o If the gateway header in the received packet contains a label,
routing of this packet is carried out on this label.
o On the third step, the gateway allocates a constant label,
which will be used for the traffic of connection from the
responder to the initiator. If the gateway must be fixed in a
connection route without distribution of a label, the packet
must contain header of this gateway with the transport address.
o If the label allocated by this gateway defines direct hop up to
the previous gateway from an explicit route, I flag must be
set.
o If the label allocated by this gateway saves the previous
gateway from a route of this packet, N flag must be set.
o It is possible to add gateways on the traversed area of a route
directly ahead of this gateway if it is known, that the added
gateway must not send COOKIE in both sides of connection and
must not allocate a label.
o The gateway may generate or replace existing COOKIE option.
Value of COOKIE field from this option will be used on the
fourth step and in the following reconnection under the
initiative of the responder (see section 6.2.3.4).
Bogdanov Expires: January 2003 [Page 45]
Internet-Draft End-by-Hop Transmission Protocol July 2002
4 step - sending of CONNECT-ACK command from the responder to the
initiator:
o The third step actions, but for the opposite traffic of
connection are executed. For sending packets, the labels
distributed on the third step can be used.
On any step of connection establishment, the gateway may delete from
an explicit route the addresses of other gateways at observance of
all following rules:
o The deleted gateway MUST NOT is obligatory (B = 0).
o It is possible to delete addresses of gateways on the traversed
area of a route if they are located directly ahead of this
gateway. For example, it can be demanded at label allocation.
o It is possible to delete any gateway on the not traversed area
of a route.
o The gateway may delete its header and send a packet forward.
Temporary labels, which are distributed on the first and second step
of a connection establishment, MUST be stateless labels.
On the third and fourth step, the endpoints must save an explicit
route of the received packets for use at reconnection and in sending
the subsequent traffic of data. The sequence from the received
packet must be changed on back.
One gateway in each direction may delete the transport address of the
sender from addresses header. For this purpose, the gateway must
save in state variables the transport address or a route up to an
endpoint and relate this information with the allocated label. The
endpoint must know about removal of the source address and compute
the packet checksum without it. The interaction question of endpoint
and a gateway, which deletes the address of the sender, is beyond the
scope of this document. At removal of the address, it is necessary
to take into account, that not all services of the upper layer
provide an opaque addressing.
6.2.2 Data Transfer
Packets contain the short-cut routing information after a connection
establishment. Address objects from packets with last connection
establishment commands must be optimized by the following rules:
o The label without the gateway address MUST NOT follows the
gateway address without label (the gateway without label can
forward packets only on the basis of transport addresses)
Bogdanov Expires: January 2003 [Page 46]
Internet-Draft End-by-Hop Transmission Protocol July 2002
o After a label with I = 0 (the label does not define direct hop
up to the following gateway), the object with the transport
address (gateway header or addresses header) must be located.
o If all route consists of labels with I = 1, the packet must not
contain transport addresses of gateways and endpoints.
o If last gateway in a route has set I = 1 (i. e. the label
allocated by it defines direct hop up to the endpoint), the
packet must not contain addresses header. The packet MUST
contain addresses header in all other cases. If the packet
does not contain an explicit route, the sender endpoint is
considered as last gateway of an explicit route. If it sends a
packet immediately to receiver endpoint, the packet MUST NOT
contains addresses header.
o If at current label N = 1 (the gateway saves the following
address object), the following address object deletes from a
stack.
At processing entering packets after a connection establishment, the
gateway must execute the following logic:
o Gateways Options are looked through, since the first.
o If the label is the first unprocessed address object the packet
is forwarded on value of this label.
o If the gateway header with label (without the transport address
or with the address of this gateway) is the first address
object, the label is processed also, as in the previous item.
In addition, the header can contain the subordinated options,
which must be processed.
o If the label has incorrect value or the first unprocessed
object is the label and a gateway does not allocate labels, the
packet is silently discarded.
o If the first unprocessed address object is the header of other
gateway with the transport address (with or without label) or
the address of the endpoint from addresses header, forwarding
will be realized based on transport addresses.
o The processed address object in stack top deletes at
forwarding.
o If the gateway saves address object of the following gateway,
this object must be added in packet front.
o Gateways headers with W = 1 are not processed, if they concern
to other gateway.
6.2.3 Reconnection
The reconnection reason is:
o Route restoration after the long inactivity period of
endpoints.
Bogdanov Expires: January 2003 [Page 47]
Internet-Draft End-by-Hop Transmission Protocol July 2002
o Necessity of change of a route through the gateways fixed in a
route by breakdown one of them.
o Necessity of change of resources reservation parameters.
o Dynamic reduction of PMTU value.
Reinstalled connection MUST have the same constant values of
connection identifiers, as initial. Primary connection is
reinstalled only. Secondary connections begin to use new labels
and/or a route without sending special primitives. Reconnection
commands are formed as gateway options. In a packet, they are
located before options of an explicit route. All packets contain
next sequence number. Reconnection does not change packets numbers
sequence of connection.
Everywhere in the text of this document, the reconnection commands
are equivalent to connection establishment commands if other logic is
not defined separately.
Any endpoint of connection can be the reconnection initiator. In
case of counter reconnection, the initiator of the initial (first)
connection has advantage. Counter packets of reconnection from the
responder are silently discarded.
6.2.3.1 REINIT, REINIT-ACK
The REINIT and REINIT-ACK commands are used for reconnection and
correspond to INIT and INIT-ACK commands of initial primary
connection establishment. They are formed as a gateway options, have
an identical format and differ only in OPCODE value. Packets with
REINIT and REINIT-ACK commands must not include payload. Fields of
base header must have the following values:
SEQUENCE_NUM - Contains the current sequence number of
reinstalled connection.
SERVICE_ID - Contains the service identifier of the initial
primary connection.
DATA_LENGTH = 0
CONNECTION_ID - This field contains the identifier of initial
primary connection allocated by the packet
receiver.
The option of REINIT and REINIT-ACK commands has the following
format:
Bogdanov Expires: January 2003 [Page 48]
Internet-Draft End-by-Hop Transmission Protocol July 2002
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 0 1 0 1|E|D|G| HEAD_LENGTH | OPCODE |RES_VER_FLAGS|F|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|RSV| MIN_HL_PMTU |RSV| PMTU |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fields of general format have the following values:
E = 1
D = 1
G = 1
HEAD_LENGTH = 1
OPCODE =
16 for REINIT
17 for REINIT-ACK
RES_VER_FLAGS: 7 bits
The reserved versions flags. Values of these bits are set to
zero by sending. If at receiving even one of them is set to 1,
the packet must be silently rejected.
F: 1 bit
Flag of the protocol first version. This bit MUST be set to 1.
It sets the protocol version, which is defined in this
document.
RSV: 2 + 2 bits
Reserved. These fields should be set to zero on transmit and
ignored on receipt.
MIN_HL_PMTU: 14 bits
Indicates the upper layer PMTU minimal size in 32-bit words
(see section 5.1.1.1).
PMTU: 14 bits
Indicates PMTU size in 32-bit words (see section 5.1.1.1).
6.2.3.2 RECONNECT, RECONNECT-ACK
Bogdanov Expires: January 2003 [Page 49]
Internet-Draft End-by-Hop Transmission Protocol July 2002
RECONNECT and RECONNECT-ACK commands correspond to CONNECT and
CONNECT-ACK commands of an initial connection establishment. The
packet containing these commands MAY contain an upper layer data.
RECONNECT and RECONNECT-ACK are formed as gateways options, have an
identical format and differ only in OPCODE value. Fields of base
header must have the following values:
SEQUENCE_NUM - Contains the current sequence number of
reinstalled connection.
SERVICE_ID - This field contains the service identifier of the
initial primary connection.
DATA_LENGTH = 0 - 65535
CONNECTION_ID - This field contains the identifier of initial
primary connection allocated by the packet
receiver.
The option of RECONNECT and RECONNECT-ACK commands has the following
format:
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 0 1 0 1|E|D|G| HEAD_LENGTH | OPCODE | INACTION_TIME |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fields of general format have the following values:
E = 1
D = 1
G = 1
HEAD_LENGTH = 0
OPCODE =
18 for RECONNECT
19 for RECONNECT-ACK
INACTION_TIME: 8 bits.
The reserved inactive time. This field contains time interval
in seconds at which expiration gateways will deallocate
connection resources at absence of traffic (see section 6.8).
6.2.3.3 2-way Handshake
2-way handshake reconnection is used, if it is necessary to renew
data transmission after the expiration of reserved inactive time (see
section 6.8) or if it is necessary to change reservation parameters.
The primary goal is redistribution of labels with state. 2-way
handshake reconnection repeats the third and fourth steps of a
primary connection establishment.
Bogdanov Expires: January 2003 [Page 50]
Internet-Draft End-by-Hop Transmission Protocol July 2002
The reconnection initiator sends RECONNECT command. The packet with
this command contains an initial route, which is formed in accordance
with the following rule:
o For the initiator of initial connection, the explicit route
from a packet with CONNECT-ACK command of initial connection
(upside-down) takes.
o For the responder of initial connection, the explicit route
from a packet with CONNECT command of initial connection takes.
o If reconnection is not the first, the explicit route from the
previous accepted reconnection command takes.
o All labels with state delete from options of an explicit route.
o COOKIE-GATEWAY options and stateless labels are saved.
All packets with reconnection commands must contain addresses header.
The packet with RECONNECT command is processed on gateways the same
as packet with CONNECT command. Receiver of RECONNECT processes the
received explicit route the same as a route from a packet with
CONNECT command (see section 6.2.1). For reconnection
acknowledgement the packet with RECONNECT-ACK command is sent. This
command is processed by gateways as CONNECT-ACK command.
The reconnection commands can contain payload. The reconnection
initiator can send the following packets with data before RECONNECT-
ACK reception. These packets must include an initial route and
addresses header. Required QoS cannot be guaranteed before
RECONNECT-ACK reception.
If lifetime even one gateway COOKIE from an explicit route of
connection has expired, reconnection from two steps MUST NOT is used.
In this case, reconnection from four steps is used.
6.2.3.4 4-way Handshake
4-way handshake reconnection is used for a choice of a new connection
explicit route through gateways for which the endpoint does not know
current COOKIE values. 4-way handshake reconnection completely
repeats algorithm of an establishment of starting primary connection.
Commands correspondence are shown in the following table:
Bogdanov Expires: January 2003 [Page 51]
Internet-Draft End-by-Hop Transmission Protocol July 2002
Primary Corresponding
Connection Reconnection
Command Command
------------+-----------------
INIT | REINIT
------------+-----------------
INIT-ACK | REINIT-ACK
------------+-----------------
CONNECT | RECONNECT
------------+-----------------
CONNECT-ACK | RECONNECT-ACK
------------+-----------------
Reconnection packets use current sequence numbers of connection and
current SPI.
6.2.4 Connections Termination through Gateway
If the gateway has allocated to connection a stateless label, it must
not supervise connection closing. If a gateway has allocated a label
with state, it may:
(1) Not trace connections closing and deallocate resources on the
timer of reserved inactive time (see section 6.8). As the
gateway cannot check up the packet authentication data, it is
RECOMMENDED to apply this way to the connections using an
authentication. It allows excluding a fake of connection
closing commands.
(2) The gateway can trace connections termination. Computing
loading at a gateway grows in this case, as connections
termination commands are formed as endpoint options and their
analysis requires viewing of all packet headers. Advantage
is fast free of the resources. If the gateway has allocated
independent labels into everyone sides of connection, it
deallocates resources immediately after reception any of
DISCONNECT or DISCONNECT-ACK commands. If the gateway has
allocated one or the connected labels, resources are
deallocated at reception of DISCONNECT-ACK command.
If connection has ceased to use a gateway because of reconnection
procedure, the gateway deallocates resources on the timer of reserved
inactive time.
At using of initial connection, reconnection is allowed. Endpoints
must not use simultaneously more than four explicit routes in one
connection.
Bogdanov Expires: January 2003 [Page 52]
Internet-Draft End-by-Hop Transmission Protocol July 2002
6.3 Use of symbolical addresses
The transport address in symbolical representation (see section 3.3)
may be written down to destination address only in a packet with the
INIT command (first command of a connection establishment). All
other packets of the connection MUST have the destination address in
a binary format. The source address always MUST be in a binary
format.
Protocols, which allow gateways to define binary addresses from
symbolical representations, lay beyond the scope of this document.
Gateways must not modify packet addresses header. By transferring a
packet with the receiver symbolical address, the following logic MAY
be used:
(1) The packet is sent to address of the defined gateway. It can
be a default gateway or the special gateway responsible for
routing of packets with symbolical addresses.
(2) If the gateway can calculate the address binary format of the
endpoint, it forms a packet explicit route. Last gateway
header contains the endpoint transport address in binary
format.
(3) If the gateway cannot calculate the endpoint address, it adds
its header in a packet and set W flag. Addition is necessary
to exclude routing loops. After that, the packet is sent the
following gateway. If the following gateway address is
unknown, the packet is silently discarded.
At processing entering packets with INIT command, the endpoint must
take into account that its address can be in last gateway header of
an explicit route if the receiver address in addresses header has
symbolical representation.
Use of symbolical addresses in gateways headers is left opened for
discussion.
6.4 DISCARDED-PACKET
There are several reasons on which a gateway or an endpoint may
reject connection packets. As the discarded packet stops advance of
confirmed cumulative sequence number, DISCARDED-PACKET option must be
sent instead of the discarded packet. A gateway or an endpoint may
send this option. A gateway sends an option in the same streamline
in which it was necessary to send the rejected packet. The gateway
forms DISCARDED-PACKET as gateway option. The endpoint must form
DISCARDED-PACKET as endpoint option. The option has the following
format:
Bogdanov Expires: January 2003 [Page 53]
Internet-Draft End-by-Hop Transmission Protocol July 2002
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 0 1 0 1|E|D|G| HEAD_LENGTH | OPCODE | ERRCODE |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DISCARDED_BLOCK_1_START | DISCARDED_BLOCK_1_END |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DISCARDED_BLOCK_n_START | DISCARDED_BLOCK_n_END |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fields of general format have the following values:
E = 1
D = 1
G = 0
HEAD_LENGTH = 0 - 255
OPCODE = 20
ERRCODE: 8 bits
Error code of the discarded packet. This value concerns to all
packets numbers of this option. The following values are
defined:
17 - connection is closed. This error is formed by
endpoint at closing secondary connections. After S-
DISCONNECT sending, the endpoint does not receive
entering packets of secondary connection. Instead of
acknowledgements, DISCARDED-PACKET option is sent.
133 - Packet size exceeds MTU.
134 - SERVICE_ID value is not connected with active service.
Such error may be generated for a packet with BIND
command or by sending through 0 - connection of the
connectionless data. A gateway (firewall) or an
endpoint may form an option with this error.
135 - The packet is deleted because of gateway congestion.
The option with this error code may not contain a
range of the discarded packets. In this case, it is
the warning of a possible congestion or the rejected
packet has not required acknowledgement. The sending
of DISCARDED-PACKET option with this error code is
OPTIONAL. This option NOT RECOMMENDED to be sent more
often, than once during RTT.
Bogdanov Expires: January 2003 [Page 54]
Internet-Draft End-by-Hop Transmission Protocol July 2002
DISCARDED_BLOCK_n_START + DISCARDED_BLOCK_n_END: 16 + 16 bits
These fields contain the beginning and the end (inclusive) the
block of the discarded packets. Their value is negative
displacement from sequence number of the packet to which this
option is attached. Zero value is allowable. If the block
contains number of one packet, both fields MUST have one value.
The receiver endpoint of the discarded packet after reception of
DISCARDED-PACKET option sends this option back to the sender of
rejected packet. Exception is inadmissible SERVICE_ID value in a
packet with BIND command. This command is confirmed by special
packet. Therefore the receiver of DISCARDED-PACKET with ERRCODE =
134 only includes number of the discarded packet in cumulative
acknowledgement number of the following packet.
The sender of the discarded packet must send the same packet
repeatedly after reception of DISCARDED-PACKET option. If repeated
sending is impossible, DISCARDED-PACKET option is ignored. At
reception DISCARDED-PACKET for packets of the closed connection
(ERRCODE = 17), repeated sending is not carried out.
If the message on congestion is received, it is necessary to execute
procedures of congestions control (see section 5.3).
If the data receiver before reception of DISCARDED-PACKET option has
received even one correct packet from a range specified in the
option, option is considered erroneous and is ignored.
6.5 NEW-PMTU
NEW-PMTU option is used for measurement of current PMTU. It is
formed as gateway option and has the following format:
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 0 1 0 1|E|D|G| HEAD_LENGTH | OPCODE | RESERVED |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|RSV| MIN_HL_PMTU |RSV| PMTU |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fields of general format have the following values:
E = 1
D = 1
G = 1
HEAD_LENGTH = 1
Bogdanov Expires: January 2003 [Page 55]
Internet-Draft End-by-Hop Transmission Protocol July 2002
OPCODE = 21
RESERVED + RSV + RSV: 8 + 2 + 2 bits
Set to zero on transmit and ignored on receipt
MIN_HL_PMTU: 14 bits
Indicates the upper layer PMTU minimal size in 32-bit words
(see section 5.1.1.1).
PMTU: 14 bits
Indicates PMTU size in 32-bit words (see section 5.1.1.1).
If the gateway cannot transfer on connection a packet because of
dynamic reduction PMTU, it forms simultaneously two options: NEW-PMTU
and DISCARDED-PACKET with ERRCODE = 133. Then these options will be
sent together as it is described in section 6.4.
6.6 GATEWAY-ERROR
GATEWAY-ERROR option is used by gateways for sending the message on a
critical error by sending of a connection packet. GATEWAY-ERROR is
formed as gateway option and has the following format:
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 0 1 0 1|E|D|G| HEAD_LENGTH | OPCODE | ERRCODE |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fields of general format have the following values:
E = 1
D = 1
G = 0
HEAD_LENGTH = 0
OPCODE = 22
ERRCODE: 8 bits
Contains an error code (see section 6.7).
The gateway must send GATEWAY-ERROR in a direction of sending a
packet, which has caused an error. Back message error sending is not
stipulated. If the gateway cannot send a packet forward, it must
discard it silently.
Bogdanov Expires: January 2003 [Page 56]
Internet-Draft End-by-Hop Transmission Protocol July 2002
GATEWAY-ERROR option concerns to primary connection and everything
connected with it secondary connections. It can be transmitted on
any of these connections.
The gateway at packet receiving with GATEWAY-ERROR option executes
simple forwarding. If the packet contains a connection establishment
command, the gateway must not reserve resources for connection and
allocate a label.
The endpoint at receiving GATEWAY-ERROR option carries out the
following actions:
o If the option is received in a packet with INIT command, the
packet containing INIT-ACK and DISCONNECT commands is sent.
The receiver of the packet with INIT-ACK + DISCONNECT considers
connection not established.
o GATEWAY-ERROR option in a packet with INIT-ACK command does not
finish connection immediately if it is expected, that the
packet with INIT-ACK should contain an authentication data. In
this case, the same packet with INIT command is repeatedly sent
and during the set timeout, INIT-ACK command is expected. If
correct INIT-ACK command is received, the packet with GATEWAY-
ERROR is silently discarded. If the authentication is not
used, connection is closed immediately at reception of GATEWAY-
ERROR option.
o GATEWAY-ERROR option received with any packet since the third
step of connection establishment initiates connection
termination (see section 5.1.6), or reconnection (see section
6.2.3.4).
o If GATEWAY-ERROR is received in the packet duplicate, the
option is not processed and a packet is silently discarded.
6.7 Gateway Error Codes
The following errors codes, which can be contained in ERROR-CODE
field of GATEWAY-ERROR option are defined:
15 - Not supported protocol version.
129 - A gateway label cannot be allocated.
130 - The gateway cannot provide the requested QoS.
131 - Erroneous gateway label.
132 - Erroneous gateway COOKIE.
6.8 Activity Control
Reserved inactive time (RIT) is used for dynamic deallocating of the
network resources allocated for EHTP connections. RIT value is set
by the connection initiator in CONNECT command. The responder can
reduce this time in CONNECT-ACK command. If changed RIT does not
Bogdanov Expires: January 2003 [Page 57]
Internet-Draft End-by-Hop Transmission Protocol July 2002
suit to the initiator, it must begin connection closing procedure
with ERRCODE = 6.
RIT is used only if there is even one gateway in the connection
route, which has allocated a label to this connection and has set S
flag. As direct and back route can differ, endpoints must agree upon
RIT value irrespective of gateways presence. At the activity
control, primary connections and everything connected with it
secondary connections are considered as one connection.
Gateway reset RIT timer at receipt of any connection packet from any
direction. Traffic in everyone side is traced separately, if the
gateway has allocated independent labels in each side of connection.
The endpoint uses the following logic:
(1) The value = RIT - 4 * max (RTT) is used. This value must be corrected at change RTT.
(2) Acknowledgements of packets are taken into account only.
(3) RIT timer is corrected for the time of sending last confirmed
packet.
If RIT timer has expired, the gateway must deallocate resources
occupied with connection. If the allocated label is used only for
this connection, it must be deleted or marked unused. The gateway
can use this label for other connection or a route at once. At
deallocation connection resources, the gateway must not send network
primitives.
If the gateway has allocated a stateless label (S = 0), it MUST NOT
supervise RIT.
The endpoint at end of corrected RIT timer must note the connection
route as closed. At that connection is not terminated and network
primitives are not sent. If it is necessary to send data on
connection in the subsequent, procedure of reconnection (see section
6.2.3.3) should be executed.
The procedures connected with the activity control, resources
deallocating on gateways and reconnection are transparent for the
upper layer and do not result in connections closing.
The endpoint for maintenance of route activity at upper layer traffic
absence sends a packet of cumulative acknowledgement (see section
5.2.1) with the set P pushing flag. The receiver of such packet must
immediately send a cumulative acknowledgement packet with not set P
flag. The connection initiator must respond activity through an time
interval = RIT - 8 * max(RTT), and the responder through an interval = RIT - 6 * RTT.
Bogdanov Expires: January 2003 [Page 58]
Internet-Draft End-by-Hop Transmission Protocol July 2002
It is not recommended to set RIT less, than 16 * RTT. For a global
network, 6-second value is recommended. For best-effort traffic, it
is RECOMMENDED to set minimal RIT value and it is NOT RECOMMENDED to
provide a route in an active state at absence of the upper layer
traffic.
7 Security Consideration
EHTP defines connection establishment with two parameters, which can
have casual value: the connection identifier and the initial sequence
number. To participate in connection, the node should know both
values allocated by other node. It is recommended, that even initial
sequence number have difficultly predicted value.
For security increase from DoS attacks, EHTP does not provide data
buffering at its layer. The decision on denial of service is taken
on the applications layer. Thus, the endpoint can have the increased
stability to refusals for priority-driven connections. Refusal of
buffering does not exclude attacks to gateways. Nevertheless, the
gateway can consider separate connections, as prioritized (for
example, connections with authorization or with QoS). Besides, the
gateway with state can trace a policy of congestions control which
endpoints adhere.
COOKIE mechanism is used for protection an overload of a gateway with
state. If the attacking node can listen the traffic and form packets
with the forged source address, this protection is inefficient.
Presence of the protected channel between a gateway and an endpoint
can be effective only. If the gateway and endpoint have exchanged
with SPI values, they can use it within the frameworks of EHTP
protocol. For this purpose, the protocol should be added with
special gateway header or COOKIE option. This question is not
considered in the document and left opened for discussion.
EHTP does not provide independent formation of packets by gateways.
The gateway can only add unsigned options to the packets generated by
endpoints, and to send these packets only forward. It has the
principle meaning for the connections using an authentication in
networks, where the attacking node can form packets with the forged
source address, but cannot modify packets. It is supposed, that the
correct packet will achieve the receiver earlier, than the forged
duplicate and the duplicate will be rejected. This document defines,
that all duplicates and incorrect packets must be silently discarded
without any further action. Security from attacks is considered as
priority-driven problem in comparison with algorithm optimality.
Primary connection can be used as transit for the forged packets of
secondary connections. The authentication is the protection against
this kind of attacks. In any case, at using of the checksum instead
Bogdanov Expires: January 2003 [Page 59]
Internet-Draft End-by-Hop Transmission Protocol July 2002
of authentication, the protocol has no effective protection against
the attacking node, which is in CSMA network, through which packets
of connection pass.
For protection against "man-in-the-middle" attacks, the following
variants are possible:
o Using authentication at EHTP layer. At that, existing keys
control protocols can be transferred on EHTP transport without
changes. It will give a possibility of end-to-end protection
even if endpoints are located in the networks incompatible at a
network layer.
o Protection at applications layer.
o Using IPsec, if endpoints are in IP network. Application of
EHTP gateway functions, which require modification a packet, is
impossible in this case.
o EHTP can be added with end-to-end enciphering means with
definition of a new format of basic header.
8 References
[1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP
9, RFC 2026, October 1996.
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", RFC 2119, March 1997.
[3] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August
1980.
[4] Postel, J., "Transmission Control Protocol - DARPA Internet
Program Protocol Specification", STD 7, RFC 793, September 1981.
[5] Bogdanov, A., "Unified Memory Space Protocol Specification", RFC
3018, December 2000.
[6] Allman, M., Paxson, V. and W. Stevens, "TCP Congestion Control",
RFC 2581, April 1999.
[7] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer,
H., Taylor, T., Rytina, I., Kalla, M., Zhang, L. and V. Paxson,
"Stream Control Transmission Protocol", RFC 2960, October 2000.
[8] Karn, P. and W. Simpson, "Photuris: Session-Key Management
Protocol", RFC 2522, March 1999.
[9] Mogul, J. and S. Deering, "Path MTU Discovery", RFC 1191,
November 1990.
Bogdanov Expires: January 2003 [Page 60]
Internet-Draft End-by-Hop Transmission Protocol July 2002
[10] McCann, J., Deering, S. and J. Mogul, "Path MTU Discovery for IP
version 6", RFC 1981, August 1996.
[11] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982,
August 1996.
[12] Kent, S. and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998.
[13] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402,
November 1998.
[14] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6)
Specification", RFC 2460, December 1998.
[15] Dawkins, S., Montenegro, G., Kojo, M., Magret, V. and Vaidya,
N., "End-to-end Performance Implications of Links with Errors",
RFC 3155, August 2001.
[16] ITU-T Recommendation V.42, "Error-correcting procedures for DCEs
using asynchronous-to-synchronous conversion", October 1996.
[17] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label
Switching Architecture", RFC 3031, January 2001.
[18] Doria, A., Sundell, K., Hellstrand, F. and T. Worster, "General
Switch Management Protocol (GSMP) V3", RFC 3292, June 2002.
[19] Awduche, et al, "RSVP-TE: Extensions to RSVP for LSP Tunnels",
RFC 3209, December 2001.
[20] Paxson, V. and M. Allman, "Computing TCP's Retransmission
Timer", RFC 2988, November 2000.
[21] Larzon, Lars-Ake, Degermark, Mikael and Pink, Stephen, "The UDP
Lite Protocol", Work in Progress.
9 Author's Address
Alexander Bogdanov
23-126, Generala Kuznetsova St.
Moscow, Russia 109153
RU
Phone: +7 095 706 1002
Email: a_bogdanov@s-mail.com
Bogdanov Expires: January 2003 [Page 61]
Internet-Draft End-by-Hop Transmission Protocol July 2002
10 Full Copyright Statement
Copyright (C) The Internet Society (2002). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Bogdanov Expires: January 2003 [Page 62]
