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 + +