view Side-By-Side changes
Network Working Group R. R. Stewart
INTERNET-DRAFT Motorola
Q. Xie
Motorola
Expires in six months 22 March 1 April 1999
MULTI_NETWORK DATAGRAM TRANSMISSION PROTOCOL
<draft-ietf-sigtran-mdtp-02.txt>
<draft-ietf-sigtran-mdtp-03.txt>
Status of This Memo
This document is an Internet-Draft and is in full conformance
with all provisions of Section 10 of RFC2026. 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
The list of six months
and may current Internet-Drafts can be updated, replaced, or obsoleted by other documents accessed at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
To learn the current status
http://www.ietf.org/ietf/1id-abstracts.txt
The list of any Internet-Draft, please check the
"1id-abstracts.txt" listing contained in the Internet- Drafts Internet-Draft Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or
ftp.isi.edu (US West Coast). can be accessed at
http://www.ietf.org/shadow.html.
Abstract
This Internet Draft discusses an experimental call control protocol,
namely the Multi-network Datagram Transmission Protocol (MDTP), that is
intended to provide fault-tolerant reliable/unreliable data transfer
between communicating processes over IP networks [1]. MDTP is proposed
as an application-level protocol which is designed with a high emphasis
on supporting redundant networks and transparent fault management. MDTP
also gives the application a great degree of timing control and
configuration flexibilities. The motivation of developing MDTP is to
establish a framework for supporting Internet-based high reliability
real-time commercial applications such as signaling and call control
for Internet telephony.
Stewart & Xie [Page 1]
Internet Draft Multi-network Datagram Transmission Protocol Feb Apr 1999
TABLE OF CONTENTS
1. Introduction..............................................3
1.1 Multi-network Datagram Transmission Protocol.........3
1.2 Interfaces to MDTP...................................5 MDTP...................................4
1.3 Operation of MDTP....................................5
2. Design Principles.........................................6 Principles.........................................5
3. Header Format.............................................7 Format.............................................6
3.1 MDTP Header Format Description.......................7 Description.......................9
3.2 Notes on Multicast Header format....................10 format....................12
4. Transmission Initialization..............................10 Initialization..............................12
4.1 Normal Initialization...............................10 Initialization...............................12
4.2 Multiple Network Addresses..........................12 Addresses..........................14
4.3 Initialization Collision............................13 Collision............................15
4.4 Re-initialization...................................14 Re-initialization...................................16
4.5 Link rotation.......................................14 rotation.......................................16
5. Reliable Transfer Mode...................................14 Mode...................................17
5.1 Timer Control.......................................16 Control.......................................19
5.2 Gap Acknowledgments.................................19 Acknowledgments.................................21
5.3 Congestion Control..................................21 Control..................................23
5.4 Sequence Number Reset...............................24 Reset...............................26
5.5 Retransmission on Multiple Networks.................25 Networks.................27
5.5.1 Randomization of the T3-Send timer at resend ...25 ...28
5.6 Termination of an Endpoint..........................26 Endpoint..........................28
5.7 Endpoint Drain......................................26 Drain......................................29
5.8 Advisory Acknowledgements...........................26 Acknowledgments...........................29
5.9 RTT Measurement.....................................26 Measurement.....................................30
5.10 Heart Beat Ack.....................................26 Ack.....................................32
6. Unreliable Transfer Mode.................................27 Mode.................................33
6.1 Ordered receiption..................................28 reception..................................34
7. Reliable flows...........................................35
7.1 Initiating a flow...................................36
7.2 Flow acknowledgments................................37
7.3 Flow session closing................................41
8. Mixed Mode Data Transmission.............................28
8. Transmission.............................42
9. Bundled Messages.........................................29
8.1 Messages.........................................43
9.1 Format of Bundled Datagram..........................30
8.2 Datagram..........................44
9.2 Bundled Transfer....................................31
9. Fragmented Messages......................................32 Transfer....................................45
10. Non-protocol Datagrams...................................33 Fragmented Messages......................................46
11. Non-protocol Datagrams...................................47
12. Broadcast and Multicast..................................34
11.1 Multicast..................................48
12.1 Multicast/Broadcast Initialization.................34
11.2 Initialization.................48
12.2 Transmission of Broadcast Datagrams................34
11.3 Datagrams................48
12.3 Transmission of Multicast Datagrams................35
11.4 Datagrams................49
12.4 Reset of the Multicast Datagram Sequence Number....36
12. Suggested Timer and Protocol Parameter Values............37 Number....50
13. Further Study............................................37
14. Author's Addresses.......................................38
15. References...............................................38 Interface with upper level protocols.....................51
13.1 Init.MDTP primitive.....................................52
13.2 Send.Data primitive.....................................52
13.3 Receive.Data primitive..................................52
13.4 Data.Arrive notification................................53
13.5 Send.Failure notification...............................53
13.5 Link.Status.Change notification.........................53
Stewart & Xie [Page 2]
Internet Draft Multi-network Datagram Transmission Protocol Feb Apr 1999
13.6 Communication.Lost notification.........................53
14. Suggested Timer and Protocol Parameter Values............54
15. Acknowledgments.........................................54
16. Author's Addresses.......................................54
17. References...............................................55
1. Introduction
This Internet Draft discusses an experimental protocol, namely the
Multi-network Datagram Transmission Protocol (MDTP), that is intended
to provide fault-tolerant reliable/unreliable data transfer between
communicating processes over IP networks [1].
MDTP is proposed as an application-level protocol which is designed
with a high emphasis on supporting redundant networks and transparent
fault management. MDTP also gives the application a great degree of
timing control and configuration flexibilities. The motivation of
developing MDTP is to establish a framework for supporting
Internet-based high reliability real-time commercial applications
such as signaling and call control for Internet telephony.
This document describes the functional interface and the details
necessary to implement MDTP.
1.1 Propose of Multi-network Datagram Transmission Protocol (MDTP)
The Multi-network Datagram Transmission Protocol (MDTP) presented in
this Internet Draft is designed to meet the following critical
requirements common to real-time call control environments employing
redundant networks:
A) A process may need to be in simultaneous communication with
thousands of endpoints performing various call processing
functions. These endpoints may be codec converters, SS7 to IP
translation applications, or, in the case of mobile networks, data
selector and combiner applications.
B) A process needs to have a very fine control over the timing for
delivering a datagram. The timing should be easily adjusted
depending on the message type and the destination. For example,
after a few seconds of non-delivery the call which the message
is about may not exist anymore.
C) A process communicating with a peer should be able to take
advantage of the redundant networks in a transparent way. This
means that the application or upper level protocols need not to be
involved in the network fault management. Instead, when network
failure occurs the transmission protocol should be able to
automatically re-route the outbound out-bound datagram to the alternate
Stewart & Xie [Page 3]
Internet Draft Multi-network Datagram Transmission Protocol Apr 1999
network without intervention from the application.
D) Datagrams may arrive out of order, or may arrive in duplicate
copies. This is especially true in a redundant network
environment. The transmission protocol should be strong enough to
properly handle both situations with little intervention from the
upper level protocol or application.
To accomplish the above objectives we have defined MDTP to reside in
user-space, i.e., it is not intended to be implemented as a module in
an operating system. This gives the application or upper level
protocols that use MDTP outstanding flexibility in controlling the
timing and other operational characteristics for the data
transmissions.
Stewart & Xie [Page 3]
Internet Draft Multi-network Datagram Transmission Protocol Feb 1999
MDTP is also made multi-network aware. This means that if more than
one path exists between two endpoints (such as redundant LANs), MDTP
will take advantage of the multiple networks by automatically
switching to the alternate LAN if the datagram delivery becomes
unavailable or inefficient (e.g., too many re-transmissions) on the
current LAN. The ability to handle multiple networks by MDTP can also
greatly facilitate the implementation of various traffic balancing
schemes in the application or upper level protocols.
In the redundant network setting, out-of-order or duplicate datagrams
are proven to be most harmful during MDTP transmission initiations and
re-initiations. To cope with the problem, MDTP utilizes a very
efficient tag mechanism to guard against out-of-order or duplicate
datagrams.
MDTP assumes that a UDP-like [2] transport protocol is available at the
operating system level for data transport. We have successfully
implemented and tested MDTP over UDP and Sun Microsystem's CLTS
transport layers.
Comparing to traditional TCP [3], MDTP design is more tuned towards a
special set of applications, that is the time critical fault tolerant
applications using redundant LANs. It is not designed to replace TCP
as a general purpose transmission protocol.
Stewart & Xie [Page 4]
Internet Draft Multi-network Datagram Transmission Protocol Feb 1999
1.3
1.2 Interfaces to MDTP
MDTP interfaces with the application programs or higher level
protocols through a set of function calls. Due to the fact that MDTP
is an application level protocol, these calls are not executed within
the operating system, but within the user process (i.e., in the user
space). The application or higher level protocols pass data to MDTP by
making calls to MDTP, which then enqueues the data for transmission.
When data arrives, MDTP will distribute the data to the application or
higher level protocols via mechanisms predefined by the application.
The application also has an interface to change the operational mode
of an MDTP endpoint and the default operational mode of the MDTP
endpoint. The default operational mode is used in the absence of any
Stewart & Xie [Page 4]
Internet Draft Multi-network Datagram Transmission Protocol Apr 1999
specific direction from the application. More details on the MDTP
interface to the upper level protocol/application can be found in
section 13.
As noted above, it is assumed that a UDP-like data transport protocol
will provide the interface between MDTP and the operating system. No
other special interfaces or changes are assumed within the operating
system, all queuing and internal pseudo-connection information is
maintained inside MDTP endpoint.
1.4
1.3 Operation of MDTP
MDTP operates in three different modes.
A) Reliable transfer mode
B) Unreliable transfer mode
C) Raw UDP transfer mode
The two ends in a communication connection can operate in different
modes with respect to each other, with the exception of the raw UDP
mode. For example, if two endpoints A and B are communicating with
each other. Endpoint A may be sending information to B in reliable
transfer mode, while B, on the other hand, may be sending information
to A in unreliable transfer mode. All communications from A to B will
be acknowledged by B, but A will not need to acknowledge data received
from B.
Raw UDP transfer is used when one of the endpoints in communication
does not support MDTP. This allows compatibility with non-MDTP
endpoints. Two MDTP capable endpoints are also allowed to engage in
communications in raw UDP transfer mode. However, both sides will have
to be in raw UDP mode once one of them indicates to use raw UDP
transfer mode.
Stewart & Xie [Page 5]
Internet Draft Multi-network Datagram Transmission Protocol Feb 1999
MDTP also provides a bundling option for both the reliable and
unreliable transfer modes. This allows each side to hold the data
before transmission for some period of time, so that small datagrams
can be combined and sent in a single larger datagram to improve
network utilization efficiency.
2. Design Principles
One of the major objectives which dictates the design of MDTP is to
provide a data transmission protocol that transparently supports highly
fault tolerant implementations. To accomplish this, provisions for two
endpoints engaging in communication to use multiple networks is
essential. MDTP is therefore designed to yield the best fault
tolerance when the application shares the load over multiple network
connections.
In cases of failed original transmission, MDTP provides the ability of
attempting retransmissions using an alternate network connection even
Stewart & Xie [Page 5]
Internet Draft Multi-network Datagram Transmission Protocol Apr 1999
when the upper level protocol or the application is completely
ignorant of the existence of the alternate route.
Many of the fundamental concepts that have made TCP such a useful
protocol are reused, and some of the advantages of UDP are also merged
into the design of MDTP. This has lead to a highly effective, robust
protocol for fault tolerant data communications.
3. Header Format
MDTP inserts at the beginning of every datagram a header. This header
is composed of various flags and integers. The integers are always kept
in network byte order. The following table illustrates the common
MDTP header overlay. Note that one tick mark represents one bit
position.
Stewart & Xie [Page 6]
Internet Draft Multi-network Datagram Transmission Protocol Feb 1999
MDTP Header Format - Non Multicast
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MDTP Protocol Identifier 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MDTP Protocol Identifier 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Acknowledgment Number (Seen) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number (Send) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Size | Part | Of |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Mode | Version | In Queue |
|N N W I F R D A|B S W R R B G U| | |
|O O I S I E A C|R H N E E U A N| | |
|G B N B R S T K|O U R 1 2 N R R| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ data /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Stewart & Xie [Page 6]
Internet Draft Multi-network Datagram Transmission Protocol Apr 1999
MDTP Header Format - Multicast 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MDTP Protocol Identifier 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MDTP Protocol Identifier 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Acknowledgment Number (Seen) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number (Send) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Size | Part | Of |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Mode | Version | In Queue |
|N N W I F R D A|B S W R R B G U| | |
|O O I S I E A C|R H N E E U A N| | |
|G B N B R S T K|O U R 1 2 N R R| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Multicast To Transmit address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Multicast From - senders base address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ data /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
MDTP Header Format - RTT Ack
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MDTP Protocol Identifier 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MDTP Protocol Identifier 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Acknowledgment Number (Seen) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number (Send) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Size | Part | Of |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Mode | Version | In Queue |
|N N W I F R D A|B S W R R B G U| | |
|O O I S I E A C|R H N E E U A N| | |
|G B N B R S T K|O U R 1 2 N R R| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Transparent Time Int-1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Transparent Time Int-2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3.1 MDTP Header Format Description
MDTP Protocol Identifier 1: 32 bits
This is a fixed long value of 0xf7873072.
MDTP Protocol Identifier 2: 32 bits
This is a fixed long value of 0x17074012. MDTP
Stewart & Xie [Page 7]
Internet Draft Multi-network Datagram Transmission Protocol
Identifier Apr 1999
Flow Initiate/Close Message
0 1 and 2 are jointly examined to determine a 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MDTP Protocol Identifier 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MDTP Protocol Identifier 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Acknowledgment Number (Seen/flow num) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number (Send) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Size | Part | Of |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Mode | Version | In Queue |
|N N W I F R D A|B S W R R B G U| | |
|O O I S I E A C|R H N E E U A N| | |
|G B N B R S T K|O U R 1 2 N R R| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ack Flow (opening) | Ack datagram number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Flow Extended Acknowledgment
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MDTP Protocol Identifier 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MDTP Protocol Identifier 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ack Flow (Seen) | Ack datagram number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of flow Acks |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Size | Part | Of |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Mode | Version | In Queue |
|N N W I F R D A|B S W R R B G U| | |
|O O I S I E A C|R H N E E U A N| | |
|G B N B R S T K|O U R 1 2 N R R| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ack Flow (Seen) | Ack datagram number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ /
/ one for each 'Number of flow Acks' \
\ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ack Flow (Seen) | Ack datagram number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Stewart & Xie [Page 8]
Internet Draft Multi-network Datagram Transmission Protocol Apr 1999
3.1 MDTP Header Format
MDTP Protocol Identifier 1: 32 bits
This is a fixed long value of 0xf7873072.
MDTP Protocol Identifier 2: 32 bits
This is a fixed long value of 0x17074012. MDTP Protocol
Identifier 1 and 2 are jointly examined to determine a received
datagram is an MDTP protocol datagram.
Acknowledgment Number (or Seen): 32 bits
If the flag ACK is set this value is value is the next sequence number
that the sender of this datagram expects to receive from the
receiver of this datagram.
However, during initialization negotiation, multicast and
broadcast transmissions, this field will have special meanings
(see 4 and 11).
Sequence Number (or Send): 32 bits
If DAT flag is set, this value represents the sequence number of
the first data octet that follows this header. Otherwise, this
value will be the sequence number of the first octet of the next
data unit that will be sent.
However, during initialization negotiation, multicast and
broadcast transmissions, this field will have special meanings
(see 4 and 11).
Part: 8 bits
This value represents the Part number of a fragmented message. The
first fragment of a message is always part '0'.
Of: 8 bits
This value represents the total number of fragments in a
fragmented message. The valid range for this value is from '1'
to '255'. For broadcast and multicast datagrams this value is
set to '1' to indicate that no fragmentation should occur.
Data Size: 16 bits
This value represents, in number of octets, the size of the data
field that follows this header in the current datagram.
Flags: 8 bits
NOG - No Guaranteed delivery. This bit is used in negotiation
Stewart & Xie [Page 9]
Internet Draft Multi-network Datagram Transmission Protocol Apr 1999
and is set to indicate that the sender does not wish to use
reliable delivery. When this bit has been set in negotiation,
the receiver should prevent its application from putting
communication with this endpoint in reliable mode.
In normal data transfer (after the next sequence number initiate sequence) this
bit should be set to 0, except when responding to a RTT Ack
request.
NOB - No Bundling. This bit is used in negotiation and
is set to indicate that the sender does not wish to perform of
bundling or un-bundling of datagrams. When this datagram expects to receive from bit has been set
in negotiation, the receiver of should prevent its application from
putting communication with this datagram.
However, during initialization negotiation, multicast and
broadcast transmissions, endpoint in bundled mode.
In normal data transfer this field will have special meanings
(see 4 and 11).
Sequence Number (or Send): 32 bits
If DAT flag bit should be set to 0, if this
bit is set, set to 1 then this value represents message is part of a flow.
WIN - Window Up. This bit is set by the sequence number sender of this datagram
to indicate that the first data octet sender needs the receiver to acknowledge on
previously received datagrams before it can send more datagrams.
ISB - Is Bundled. This bit is set by the sender to indicate that follows this header. Otherwise,
this
Stewart & Xie [Page 7]
Internet Draft Multi-network Datagram Transmission Protocol Feb 1999
value will datagram is bundled. This bit should never be set if during
negotiation either end set the NOB bit.
FIR - First Datagram. This flag is set to indicate that this is a
negotiation datagram.
RES - Reset Sequence Number. This bit is set to indicate that the
sequence number of the first octet of is being reset. The sequence number should be reset
whenever the next sending count is greater than 0x7fffffff.
DAT - Data Present. This bit is set to indicate that, following
this header, application data unit that will be sent.
However, during initialization negotiation, multicast and
broadcast transmissions, is present in this field will have special meanings
(see 4 and 11).
Part: 8 bits datagram.
ACK - Acknowledge. This value represents bit is set to indicate that the Part number of a fragmented message. The
first fragment of a message sender is always part '0'.
Of:
acknowledging receipt of the specified Acknowledgment Number.
Mode: 8 bits
BRO - Broadcast. This value represents the total number of fragments in a
fragmented message. The valid range for this value bit is from '1' set to '255'. For indicate a broadcast and or
multicast datagrams datagram. When this value bit is set, bit SHU, WNR, BUN, and
GAR are not used and should be set to '1' '0'. This datagram is a
multicast datagram if the UNR bit is also set. Otherwise, this
datagram is a broadcast datagram.
SHU - Shutdown. This bit is set when the sender initiates its
closing procedure and indicates to indicate the receiver that the sender
is no fragmentation should occur.
Data Size: 16 bits
This value represents, longer a valid destination. If the UNR bit is set in number of octets,
conjunction with the size of SHU bit, an incomplete shutdown is
specified. After an incomplete shutdown, the data
field that follows this header in receiver can still
re-establish the communication with the sender by re-initiating
with the current datagram.
Flags: 8 bits
NOG sender (see 5.7).
Stewart & Xie [Page 10]
Internet Draft Multi-network Datagram Transmission Protocol Apr 1999
WNR - No Guaranteed delivery. Window Up Response. This bit is used set in negotiation
and the acknowledgment
reply to a Window Up flag.
RE1 - This bit will represent one of two things. If the GAR
bit is set to indicate that one, then setting the sender does not wish to use
reliable delivery. When this RE1 bit has been set in negotiation, indicates to the
receiver should prevent its application from putting
communication with this endpoint that the sender is requesting a advisory ACK. This
is normally sent in reliable mode.
In normal data transfer (after a datagram when 1/2 of the initiate sequence) current window
has been sent. If this bit should be is set to 0, except when responding to 0 (when the GAR bit is
set) then the sender is NOT requesting a RTT Ack
request.
NOB - No Bundling. This advisory ACK.
If the UNR bit is used in negotiation and set then the RE1 bit is set than the receiver
is requested to indicate that order the sender does datagrams (if more than one have
not wish to perform of
bundling or un-bundling of datagrams. When this bit has been set
in negotiation, read). If the receiver has already delivered a datagram
of higher sequence, then the receiver should prevent its application from
putting communication with this endpoint in bundled mode.
WIN discard lower number
sequence datagrams that arrive late.
RE2 - Window Up. This bit will represent one of two things. If the GAR
bit is set to one, the DAT bit is set to 0 and the ACK bit is
set by the sender of this datagram to indicate that 1 then this is a ACK with a Round Trip Time Request
format. This also identifies the sender needs RTT Ack header format it
in place. If the receiver UNR bit is set to acknowledge on
previously received datagrams before it 1 and DAT bit is set to 0,
then this datagram is used in a implementation specific way but
carries no data. The datagram can send more datagrams.
ISB be safely ignored and discarded.
BUN - Is Bundled. Bundled Mode. This bit is set by the sender to indicate that
this datagram bundled
mode is bundled. in effect for the sender. This bit should never be set
if during negotiation either end endpoint set the NOB bit.
FIR flag.
GAR - First Datagram. Guaranteed Mode. This flag bit is set to indicate that this the
reliable mode is a
negotiation datagram.
RES in effect for the sender, i.e., the sender
expects an acknowledgment. This bit should never be set if
either endpoint set the NOG flag during negotiation.
UNR - Reset Sequence Number. Unreliable Mode. This bit is set to indicate that
unreliable mode is in effect for the
sequence sender and the sender does
not expect an acknowledgment. This bit has special meanings if
BRO or SHU bit is set (see above).
Version: 8 bits
This field represents the version number of the MDTP
protocol. If these bits are set to 1, then the sender does
not support Round Trip Time (RTT) calculation or Heart
Beat of reliable protocol. If these bits are set to 2 then
this version does support RTT and Heartbeat. If the Version
is being reset. The sequence set to 3 then the sender/receiver supports reliable flows.
In Queue: 8 bits
This field contains the number should of messages the sender has on its
incoming queue, waiting to be reset
whenever read by the sending count is greater than 0x7fffffff. application. This gives
the receiver an indication of the flow control conditions within
the sender.
Stewart & Xie [Page 8] 11]
Internet Draft Multi-network Datagram Transmission Protocol Feb Apr 1999
DAT - Data Present. This bit
The message header is set to indicate that, following
this header, application always followed by the data field. If there is present in this datagram.
ACK - Acknowledge. This bit is set
less than 4 octets of application data to indicate that send with the sender is
acknowledging receipt datagram, the
data field of the specified Acknowledgment Number.
Mode: 8 bits
BRO - Broadcast. This bit is set to indicate a broadcast or
multicast datagram. When this bit is set, bit SHU, WNR, BUN, and
GAR are not used and datagram should be set padded with all '0' to '0'. This datagram is a
multicast datagram make it
four (4) octets. The padded all '0' octets, if the UNR bit there is also set. Otherwise, this any, are not
counted in the Data Size.
The maximal Data Size for a single MDTP datagram is a broadcast datagram.
SHU - Shutdown. This bit the MTU size of
the underlying transport protocol (e.g., UDP) minus the MDTP header
size that is set when twenty four (24) octets. The combination of the sender initiates its
closing procedure maximal
'Of' value, which is 255, and indicates to the receiver maximal Data Size will determined
the maximal size of a single message that the sender MDTP can send or
receive.
3.2 MDTP Multicast Header Format
The multicast header format is no longer a valid destination. If identical to the standard MDTP header
format, as discussed above, except for the UNR bit following extensions.
Multicast To Transmit address - This is set the multicast address, in
conjunction with
network byte order, that the SHU bit, an incomplete shutdown is
specified. After an incomplete shutdown, sender transmitted the data to. The
receiver can still
re-establish the communication with the sender by re-initiating
with the sender (see 5.7).
WNR use this information for internal tracking purposes.
Multicast From - Window Up Response. This bit is set the base address (address 0 in the acknowledgement
reply to a Window Up flag.
RE1 - This bit will represent one initiate
message, see below) of two things. If the GAR
bit is set to one, then setting sender. Since a multicast sender may not
have gone through the RE1 bit indicates to initiate procedures this address is the
reciever base
reference that the sender receiver is requesting a advisitory ACK. to use to lookup the sender. This
is normally sent in a datagram when 1/2 of
network byte order address should be used to reference any internal
cache rather than the current window
has been sent. If this bit is set arriving network from address.
4. Transmission Initialization
4.1 Normal Initialization
Before the first data transmission can take place from one endpoint
(A) to 0 (when another endpoint (Z), the GAR bit two endpoints will need to complete
an initialization process.
The initialization process consists of the following steps.
A) Endpoint A should first send an initiation datagram, while
withholding the application data from transmission.
Endpoint A Endpoint Z
[Header Flags=FIR|RES
Mode=options
Seen=0,Send=Tag_A] ----------------------->
(Start T1-init timer)
(Enter Tag_A-lock mode)
The initiation datagram is
set) then identified by setting FIR and RES bits in
the sender is NOT requesting a advisitory ACK.
If Flags field. No user data should be carried in the UNR bit is set then initiation
datagram.
Stewart & Xie [Page 12]
Internet Draft Multi-network Datagram Transmission Protocol Apr 1999
The Endpoint A should fill in the RE1 bit is set than appropriate options, e.g., BUN,
GAR, or UNR, in the reciever
is requested Mode field to order the datagrams (if more than one have
not been read). If indicate the receiver transmission type it
has already delivered a datagram
of higher sequence, then the receiver should discard lower number
sequence datagrams that arrive late.
RE2 - This bit will represent one of two things. If chosen. It may also use NOB and NOG bits in the GAR
bit is set Flags field to one, the DAT bit is set
specify to 0 and the ACK bit whether or not its peer is allowed for bundling or
reliable transfer mode.
The Seen field will be set to 1 then this is a ACK with a Round Trip Time Request
format. This also identifies '0', but an initiation tag, Tag_A,
generated by Endpoint A, will be carried in the RTT Ack header format it Send field, as
shown in place. the above diagram. If re-initializations are needed
between two endpoints subsequently (see 4.3), a different tag with
a unique value should be used for each re-initialization.
After sending the UNR bit is set to 1 initiation datagram, Endpoint A shall start T1-init
timer and DAT bit is set to 0,
then this datagram is used in enter a implementation specific way but
carries no data. The Tag_A-lock mode.
During the Tag_A-lock mode, Endpoint A will wait for the initiation
Ack datagram can be safely ignored and discarded.
BUN - Bundled Mode. This bit is with the Seen value set to indicate that bundled
mode is in effect Tag_A. Any other incoming
datagrams from Endpoint Z, except for the sender. This bit should never new initiation datagrams,
will be set
if discarded. The arrival of new initiation datagrams during negotiation either endpoint set the NOB flag.
GAR - Guaranteed Mode. This bit is set to indicate that the
reliable
Tag_A-lock mode is indicates an initialization collision that will be
discussed in effect for 4.3.
If T1-init timer expires, the sender, i.e., same initiation datagram will be
retransmitted and the sender
expects an acknowledgement. timer restarted. This bit should never will be set if
either endpoint set repeated
Max.Init.Retransmit times before Endpoint A considers Endpoint Z
unreachable and optionally reports the NOG flag during negotiation.
UNR - Unreliable Mode. This bit failure.
B) Upon the receipt of the above initiation datagram from Endpoint A,
Endpoint Z should respond immediately with an initiation Ack as shown
below:
Endpoint A Endpoint Z
[Header Flags=FIR|RES|ACK
Mode=Options
/---------- Seen=Tag_A,Send=Tag_Z]
/ (Enter Tag_Z-lock mode)
(Cancel T1-init timer)<-------/
The initiation Ack datagram is specified with FIR, RES, ACK bits set
to indicate that
unreliable '1' in the Mode field. Similarly, Endpoint Z will specify its
preferred transmission mode is and type by setting proper bits in effect for the sender
Mode and Flags fields.
In addition, in the sender does
not expect an acknowledgement. This bit has special meanings if
BRO or SHU bit is set (see above).
Version: 8 bits
This out-bound initiation Ack datagram, Endpoint Z
should set the Seen field represents to Tag_A and supply its own initiation
tag, Tag_Z, in the version number of Send field.
Once the MDTP
protocol. If these bits are set to 1, then initiation Ack is transmitted, Endpoint Z should enter the sender does
Tag_Z-lock mode. In the Tag_Z-lock mode Endpoint Z will ignore any
incoming initiation Ack datagrams and also discard any other incoming
datagram whose Seen field is not support Round Trip Time (RTT) caclulation or Heart
Beat of reliable protcol. If these bits are set equal to 2 then
this version does support RTT and Heartbeat.
In Queue: 8 bits Tag_Z, except for new
initiation datagrams.
Stewart & Xie [Page 9] 13]
Internet Draft Multi-network Datagram Transmission Protocol Feb Apr 1999
This field contains
If a new initiation datagram is received when Endpoint Z is in
Tag_Z-lock mode, Endpoint Z will acknowledged the number of messages initiation datagram
only when the sender has on its
incoming queue, waiting to be read tag carried in the Send field matches Tag_A previously
recorded by Endpoint Z. Otherwise, Endpoint Z will send an initiation
datagram with Send field set to Tag_Z back to Endpoint A to elicit an
initiation Ack.
C) After transmitted the application. This gives initiation Ack, Endpoint Z can start
transmitting datagrams with user data. However, the receiver an indication Seen field in the
first out-bound datagram with user data must be set to Tag_A.
D) Upon the receipt of the flow control conditions within initiation Ack with Seen equal to Tag_A,
Endpoint A can start transmitting datagrams with user data. However,
the sender.
The message header first datagram with application data transmitted by Endpoint A
should have the Seen value set to Tag_Z, which is always followed by obtained from the data field. If there is
less than 4 octets
initiation Ack.
Endpoint A Endpoint Z
{first app message}
[Header Flags=ACK|DAT
Mode=options
Seen=Tag_Z,Send=1]
[data field] -----------\
\
\-------> (Leave Tag_Z-lock mode)
E) Upon the receipt of application the first datagram with user data to send from Endpoint
A and with the datagram, Seen value set to Tag_Z, Endpoint Z should leave the
data field
Tag_Z-lock mode.
F) Similarly, upon the receipt of the first datagram should be padded with all '0' user data
and the Seen value set to make it
four (4) octets. The padded all '0' octets, if there is any, are not
counted in Tag_A from Endpoint Z, Endpoint A
should leave the Data Size. Tag_A-lock mode.
The maximal Data Size upper level protocol or application can predefine a set of default
transmission modes, which will be used by the endpoint for
initialization. However, it should be pointed out that the
transmission modes between two endpoints are allowed to change on a single MDTP
datagram is the MTU size by datagram basis, as been illustrated in later chapters.
4.2 Multiple Network Addresses
In order to support multiple networks, both endpoints need to have
knowledge of all network addresses available to each other. This
information needs to be passed to the underlying transport protocol (e.g., UDP) minus other end during the MDTP header
size that is twenty four (24) octets.
initialization. The combination data field of the maximal
'Of' value, which is 255, initiation and initiation Ack
datagrams is used for this purpose.
Stewart & Xie [Page 14]
Internet Draft Multi-network Datagram Transmission Protocol Apr 1999
Depending on the underlying network configuration, the maximal Data Size data field will determined
be filled in one of the maximal size two following ways:
A) If the sending endpoint of a single message that the MDTP can send initiation or
receive.
3.2 Notes on Multicast Header format.
The header format is identical initiation Ack
datagram does not have access to multiple networks, the standard MDTP header format has
discussed above but adds data field
will be set to the following extensions.
Multicast To Transmit address - This is pad value of 4 octets of '0's.
B) If the address, in network byte
order, that sending endpoint has access to multiple networks (for
example two redundant LANs), the sender transmited first 4 octets of the data field will
be an unsigned long integer (in network order) specifying how many
networks the endpoint has access to. Since Following these 4 octets will be
a receiver does
not know what list of network addresses. Each address begins with a header of 4
octets followed by the sender was sending to, actual address. The first 2 octets of the receiver can
use this information for internal tracking purposes.
Multicast From - This
header is an unsigned integer indicating the base address (address 0 in size of the initiate
message) that actual
address. The next 2 octets of the header is the sender. Since a multicast sender may not have
gone through type of the initiate procedures this address is address.
For an IPv4 address, the base
reference that address header will have the receiver is to use size set to lookup 8
and the sender. This
network byte order address should be used type set to reference any internal
cache rather than AF_INET (2). Of the 8 octets used by the arriving network from address.
4. Transmission Initialization
4.1 Normal Initialization
Before actual
IPv4 address, the first data transmission can take place from one endpoint
(A) to another endpoint (Z), 4 octets will contain the IP address (in
network order) of the path. The next two endpoints octets will need to complete
an initialization process. contain the UDP
port number (in network byte order). The initialization process consists last two octets will be
padded with 0's.
The data field of the following steps.
A) Endpoint A should first send an initiation datagram, while
withholding the application data from transmission.
Endpoint A Endpoint Z
[Header Flags=FIR|RES
Mode=options
Seen=0,Send=Tag_A] ----------------------->
(Start T1-init timer)
(Enter Tag_A-lock mode)
The or initiation Ack datagram is identified by setting FIR and RES bits in
the Flags field. No user data should be carried in the initiation
datagram.
The Endpoint A should fill in from an
endpoint with access to two IPv4 networks would look the appropriate options, e.g., BUN,
GAR, or UNR, in following:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of Networks = 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Size of address=8 | Type of Address=AF_INET (2)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP Address of Network 1 = 0x88b68108 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Port = 52212 | Padding = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Size of address=8 | Type of Address=AF_INET (2)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP Address of Network 2 = 0x0a100001 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Port = 52212 | Padding = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Any data following the Mode field initiate network list can be ignored. Implementations
are at option to indicate the transmission type it
has chosen. It may also use NOB and NOG bits additional data sent in the Flags field to
specify to whether or not its peer subsequent locations for
implementation specific data exchanges. No user data, however, is allowed for bundling or
reliable transfer mode.
The Seen field will be set
to '0', but an initiation tag, Tag_A,
generated by Endpoint A, will be carried in the Send field, as
shown transported in the above diagram. this datagram.
4.3 Initialization Collision
If re-initializations are needed
between two both endpoints subsequently (see 4.3), a different tag with attempt to initialize the communication at about the
Stewart & Xie [Page 10] 15]
Internet Draft Multi-network Datagram Transmission Protocol Feb Apr 1999
same instance, a unique value should be used for each re-initialization.
After sending the initiation datagram, Endpoint A shall start T1-init
timer and enter a Tag_A-lock mode.
During the Tag_A-lock mode, Endpoint A will wait for the initiation
Ack datagram with the Seen value set to Tag_A. Any other incoming
datagrams from Endpoint Z, except for new initiation datagrams, collision will be discarded. The arrival of new initiation datagrams during the
Tag_A-lock mode indicates an initialization occur. In a collision that each endpoint
will be
discussed in 4.3.
If T1-init timer expires, the same receive an initiation datagram will be
retransmitted and the timer restarted. This will be repeated
Max.Init.Retransmit times before Endpoint A considers Endpoint Z
unreachable and optionally reports the failure.
B) Upon from the receipt of other side after it
transmitted its own. Both sides must acknowledge the above initiation
datagram from Endpoint A,
Endpoint Z should respond immediately with an initiation Ack in the normal procedure as shown
below: described in 4.1
The following is an example of initialization collision:
Endpoint A Endpoint Z
[Header Flags=FIR|RES [Header Flags=FIR|RES
Mode=options Mode=options
Seen=0,Send=Tag_A] --------\ /----- Seen=0, Send=Tag_Z]
(Start T1-init timer) \ / (Start T1-init timer)
/
/ \
/ \
[Header Flags=FIR|RES|ACK
Mode=Options
/---------- <------/ \
Mode=options \---> [Header Flags=FIR|RES|ACK
Seen=Tag_Z,Send=Tag_A]----\ Mode=options
\ /------- Seen=Tag_A,Send=Tag_Z]
\
/ (Enter Tag_Z-lock mode) \-------> (Cancel T1-init timer)<-------/
The initiation Ack datagram timer)
(Cancel T1-init timer) <------/
..
[Header Flags=ACK|DAT
Mode=options
Seen=Tag_Z,Send=1] ------------------>
..
[Header Flags=ACK|DAT
Mode=options
<----------------- Seen=Tag_A,Send=1]
4.4 Re-initialization
An endpoint is specified with FIR, RES, ACK bits set allowed to '1' re-initialize an established communication.
In the case of re-initialization, the endpoint which initiates the
re-initialization (i.e, the initiator) should use a tag different
from the one used in the Mode field. Similarly, Endpoint Z will specify its
preferred previous initialization. The initiator should
follow the standard initialization procedure as stated in 4.1.
Upon the arrival of the initiation datagram, the peer of the initiator
should also follow the procedure stated in 4.1 to respond. Note that
any outstanding flows that were open are considered closed once
re-initialized.
4.5 Link Rotation
When multiple networks exist between two communicating endpoints,
every time the application transmits a datagram, the MDTP
implementation MUST keep track of which network the transmission mode and type by setting proper bits was
sent on (if more than one network exists) in the MDTP protocol variable
'last.sent.intf'. If the user does not specifically override rotation,
Stewart & Xie [Page 16]
Internet Draft Multi-network Datagram Transmission Protocol Apr 1999
each send should be rotated in the
Mode a round robin fashion amongst all
available networks and Flags fields.
In addition, in the outbound initiation Ack datagram, Endpoint Z protocol variable 'last.sent.intf' should set the Seen field
be updated to Tag_A and supply its own initiation
tag, Tag_Z, in the Send field.
Once the initiation Ack is transmitted, Endpoint Z indicate which interface was used last. The MDTP
implementation should enter the
Tag_Z-lock mode. In consider the Tag_Z-lock mode Endpoint Z will ignore any
incoming initiation Ack datagrams and also discard any other incoming
datagram whose Seen field is not equal rules defined in "5.5
Retransmission on Multiple Networks" to Tag_Z, except for new
initiation datagrams.
If consider if a new initiation datagram network is received when Endpoint Z
"available"
The MDTP implementation MUST allow a user to override this rotation
defeating MDTP's rotation upon each send.
5. Reliable Transfer Mode
Reliable transfer mode is in
Tag_Z-lock mode, Endpoint Z will acknowledged indicated if the initiation datagram
only when sending endpoint sets the tag carried in
GAR option on the Send field matches Tag_A previously
recorded by Endpoint Z. Otherwise, Endpoint Z will send an initiation
datagram with Send field set to Tag_Z back to Endpoint A to elicit an
initiation Ack.
C) After transmitted current datagram.
If the initiation Ack, Endpoint Z can start sending endpoint was previously transmitting datagrams with user data. However, in unreliable mode
(by setting UNR bit in each previous datagram), the receiver must
reset its Seen field counter to the Send value of this current datagram
upon receiving it.
The following example illustrates both piggy-backed and non-piggy-backed
acknowledgments with both ends transmitting in the reliable mode:
Endpoint A Endpoint Z
{App sends 3 messages}
[Header Flags=DAT|ACK
Mode=GAR
Part=0,Of=1
Seen=1,Send=1,Size=100]-------------> (Start T2-receive timer)
(Start T3-send timer)
[Header Flags=DAT|ACK
Mode=GAR
Part=0,Of=1
Seen=1,Send=101,Size=100]----------->
(Restart T3-send timer)
[Header Flags=DAT|ACK
Mode=GAR
Part=0,Of=1
Seen=1,Send=201,Size=100]----------->
(Stop and restart T3-send timer)
{Timer T2 expires}
<---------------------------- [Header Flags=ACK
Mode=0
Part=0,Of=0
Seen=301,Send=1]
Stewart & Xie [Page 11] 17]
Internet Draft Multi-network Datagram Transmission Protocol Feb Apr 1999
first outbound datagram with user data must be set to Tag_A.
D) Upon the receipt of
(cancel T3-send timer)
..
{App sends 1 message}
[Header Flags=DAT|ACK
Mode=GAR
Part=0,Of=1
Seen=1,Send=301,Size=100]-----------> (Start T2-receive timer)
(Start T3-send timer)
{App sends 1 message}
(cancel T2-receive timer)
<---------------------------- [Header Flags=DAT|ACK
Mode=GAR
Part=0,Of=1
Seen=401,Send=1,Size=45]
(Start T3-send timer)
(cancel T3-send timer)
(Start T2-receive timer)
..
{Timer T2 Expires}
[Header Flags=ACK
Part=0,Of=0
Seen=46,Send=401]------------------> (cancel T3-send timer)
In the initiation Ack with Seen equal to Tag_A,
Endpoint A can start transmitting datagrams with user data. However, above example, the first datagram with application data transmitted series of 3 messages of 100 octets each
are sent by Endpoint A
should have the Seen value set to Tag_Z, which is obtained from the
initiation Ack. A. The messages are unbundled in this example,
i.e., each message will be transmitted in a single datagram. Endpoint
A Endpoint Z
{first app message}
[Header Flags=ACK|DAT
Mode=options
Seen=Tag_Z,Send=1]
[data field] -----------\
\
\-------> (Leave Tag_Z-lock mode)
E) Upon the receipt of starts its send timer T3 after sending the first datagram with user data from Endpoint
A datagram, and with each
subsequent send will stop and restart the Seen value set to Tag_Z, Endpoint Z should leave send timer T3, extending the
Tag_Z-lock mode.
F) Similarly,
life of the send timer. Endpoint Z upon receiving the first datagram
starts the receive timer T2. When timer T2 in Endpoint Z expires,
Endpoint Z transmits an Ack. Upon receipt of this Ack by Endpoint A,
it stops timer T3 and discards the first datagram with user data
and 3 datagrams (held for
possible retransmissions).
After the Seen value set to Tag_A from first three messages were transmitted successfully, the
application at Endpoint Z, A sends another message of 100 octets. After
sending this datagram, Endpoint A
should leave the Tag_A-lock mode.
The upper level protocol or application can predefine a set starts timer T3 again. Upon
receipt of default
transmission modes, which will be used by the endpoint for
initialization. However, it should be pointed out that datagram, Endpoint Z starts Timer T2. Before
Endpoint Z's T2 timer expires, the
transmission modes between two endpoints are allowed to change on application at Endpoint Z sends a
datagram by datagram basis, as been illustrated in later chapters.
4.2 Multiple Addresses
In order to support multiple networks, both endpoints need to have
knowledge
message of all network addresses available 45 octets to each other. Endpoint A. This
information needs to be passed causes Endpoint Z to cancel
the other end during the
initialization. The data field of the initiation T2 timer and initiation to piggyback an Ack
datagrams is used for this purpose.
Depending on the underlying network configuration, out-bound datagram being
transmitted to Endpoint A. After the transmission, Endpoint Z then
starts its T3 timer. Upon receipt of this datagram Endpoint A
cancels its T3 timer (since all data field will
be filled in one it has sent is acknowledged), and
starts a receive timer T2. At the expiration of the two following ways:
A) If T2 timer Endpoint
A acks the sending endpoint receipt of the initiation or initiation Ack last datagram does not have access from Endpoint Z. This Ack
causes Endpoint Z to multiple networks, cancel its T3-send timer.
It is very important to notice in the data field
will be set above example that the
acknowledgments to the pad value of 4 octets of '0's.
B) If received datagrams are always delayed by timer
T2. This delay gives the sending receiving endpoint has access a window to multiple networks (for
example two redundant LANs), piggyback the first 4 octets of
Stewart & Xie [Page 18]
Internet Draft Multi-network Datagram Transmission Protocol Apr 1999
Acks onto subsequent datagrams traveling in the data field will
be an unsigned long integer (in network order) specifying how many
networks opposite direction,
thus to avoid sending the endpoint has access to. Following these 4 octets will Acks in separate datagrams.
5.1 Timer Control
The basic rules for timer control are as follows:
A) When all outstanding datagrams are acknowledged, the T3-send timer
shall be stopped, if one is running.
B) When a list of network addresses. Each address begins datagram with application data (i.e., with DAT flag set) is
received, the endpoint shall start a header of 4
octets followed by T2-receive timer if no timer is
running.
C) Upon the actual address. The first 2 octets expiration of the
header is an unsigned integer indicating T2-receive timer, the size of endpoint shall
ack to the actual
address. The next 2 octets of sender all the header un-acked data it has received.
D) When a datagram with application data is sent out, the type of sending
endpoint shall start a T3-send timer. If the address.
For an IPv4 address, T3-send timer is already
running, the address header will have endpoint shall first stop the size set to 8 old T3 timer and then
start a new one. If the type set to AF_INET (2). Of the 8 octets used by the actual
IPv4 address, T2-receive timer is running, the endpoint
shall first 4 octets will contain stop the IP address (in
network order) of T2 timer, piggyback an Ack unto the path. The next two octets will contain out-bound
datagram, and then start a T3-send timer.
E) If the UDP
port number (in network byte order). The last two octets will be
padded with 0's.
Stewart & Xie [Page 12]
Internet Draft Multi-network Datagram Transmission Protocol Feb 1999
The data field of T3-send timer expires, the initiation or initiation Ack datagram from an endpoint with access to two IPv4 networks would look the following:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of Networks = 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Size of address=8 | Type of Address=AF_INET (2)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP Address of Network 1 = 0x88b68108 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Port = 52212 | Padding = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Size of address=8 | Type of Address=AF_INET (2)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP Address of Network 2 = 0x0a100001 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Port = 52212 | Padding = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Any data following shall attempt
re-transmission according to the initate network list can rules described in 5.5.
F) No more than one timer of any type should be ignored. Implementations
are running on an
endpoint at option to use additional any given moment.
G) When a T2-receive timer expires, any bundled data waiting to be
transmitted should be sent in subsequent locations for
implementation specific immediately with a piggy-backed Ack to
acknowledge all un-acked data exchanges. No user data, however, previously received.
H) Whenever a T3-send timer is allowed to be transported in this datagram.
4.3 Initialization Collision started, any running timer should
be stopped and supplanted by the T3-send timer.
I) In bundling mode, if the total size of all application messages
pending to be sent is less than the bundle size, the messages should
be withheld and the T4-bundle timer should be started.
J) If both endpoints attempt the total size of all application messages pending to initialize be sent
exceeds the communication at about bundle size, the
same instance, a collision will occur. In T4-bundle timer should be stopped and
the message(s) should be immediately sent.
K) If a collision each endpoint
will receive an initiation datagram from T4-bundle timer is running and data arrives, the other side after T2-receive
timer should not be started.
L) A T4-bundle timer should never be canceled unless it
transmitted its own. Both sides must acknowledge is being
supplanted by a T3-send timer.
M) When the initiation first datagram in with the normal procedure as described in 4.1 Tag which unlocks the initiation
is received, no T2-receive timer should be started, instead an
Stewart & Xie [Page 13] 19]
Internet Draft Multi-network Datagram Transmission Protocol Feb Apr 1999
acknowledgment must be sent without delay.
The following is an example shows the use of initialization collision: various timers.
Endpoint A Endpoint Z
{App sends 2 messages}
[Header Flags=FIR|RES [Header Flags=FIR|RES
Mode=options Mode=options
Seen=0,Send=Tag_A] --------\ /----- Seen=0, Send=Tag_Z] Flags=DAT|ACK
Mode=GAR
Part=0,Of=1
Seen=1,Send=501,Size=100]-----------> (Start T1-init T2-receive timer) \ /
(Start T1-init T3-send timer)
[Header Flags=DAT|ACK
Mode=GAR
Part=0,Of=1 {App sends 1 message}
Seen=1,Send=601,Size=100]-\ /-- (cancel T2-receive timer)
(stop and restart T3-send timer)
/
/ \ / \ [Header Flags=FIR|RES|ACK <------/ Flags=DAT|ACK
\
Mode=options \---> [Header Flags=FIR|RES|ACK
Seen=Tag_Z,Send=Tag_A]----\ Mode=options / Mode=GAR
\ /------- Seen=Tag_A,Send=Tag_Z] / Part=0,Of=1
\ Seen=601,Send=1,Size=100]
/ \-------> (Cancel T1-init timer)
(Cancel T1-init \ (Start T3-send timer) <------/
/ \
<----/ \-->
..
{T3-send timer expires}
[Header Flags=ACK|DAT
Mode=options
Seen=Tag_Z,Send=1] ------------------> Flags=DAT|ACK
Mode=GAR
Part=0,Of=1
Seen=101,Send=601,Size=100]---------> (Cancel T3-send timer)
(Restart T3-send timer) (Start T2-receive timer)
..
{Timer T2 expires}
(Cancel T3-send timer) <-------------- [Header Flags=ACK|DAT
Mode=options
<----------------- Seen=Tag_A,Send=1]
4.4 Re-initialization
An endpoint is allowed to re-initialize an established communication. Flags=ACK
Mode=0
Part=0,Of=0
Seen=701,Send=101]
In this example, the case of re-initialization, application at Endpoint A sends 2 messages to
Endpoint Z. Both messages are 100 octets in length. Before the endpoint which initiates second
datagram arrives at Endpoint Z, Endpoint Z's application sends a
message to Endpoint A. This causes Endpoint Z to cancel its T2-receive
timer and piggyback the
re-initialization (i.e, Ack to the initiator) should use a tag different
from first received datagram on the one used in
out-bound datagram destined to Endpoint A. After transmitting the previous initialization.
datagram Endpoint Z starts its T3-send timer. When the T3-send timer
at Endpoint A expires, it will re-send its earlier datagram. The initiator should
follow
retransmitted datagram is the standard initialization procedure as stated in 4.1.
Upon same except for now it acknowledges all
outstanding packets that Endpoint Z has sent. After retransmitting the
datagram Endpoint A restarts its T3-send timer.
The arrival of the initiation retransmitted datagram causes Endpoint Z to cancel
its T3-send timer and discard the duplicate datagram, and it now
Stewart & Xie [Page 20]
Internet Draft Multi-network Datagram Transmission Protocol Apr 1999
starts its T2-receive timer. At the peer expiration of the initiator
should also follow T2-receive timer
Endpoint Z sends the procedure stated in 4.1 Ack to respond.
4.5 Link Rotation
When multiple networks exist between two communicating endpoints,
every time the application transmits a datagram, the MDTP implementation
MUST keep track Endpoint A. Endpoint A upon receipt of which network the transmission was sent on (if
more than one network exists) in the MDTP protcol variable
'last.sent.intf'.
Ack Cancels its T3 timer.
5.2 Gap Acknowledgments
If the user does not specifically override rotation,
each send should be rotated in a round robin fashion amongst
all available networks and datagram becomes missing during a series of transmissions, a
special type of acknowledgment known as the protocol variable 'last.sent.intf' should gap Ack will be updated to indicate which interface was used last. sent. The MDTP
implementation should consider
gap Ack tells the sender of the missing datagram that retransmission
is needed.
The following example shows the use of gap Ack.
Endpoint A Endpoint Z
{App sends 3 messages}
[Header Flags=DAT|ACK
Mode=GAR
Part=0,Of=1
Seen=146,Send=701,Size=100]--------> (Start T2-receive timer)
(Start T3-send timer)
[Header Flags=DAT|ACK
Mode=GAR
Part=0,Of=1
Seen=146,Send=801,Size=100]-----X (lost)
(Restart T3-send timer)
[Header Flags=DAT|ACK
Mode=GAR
Part=0,Of=1
Seen=146,Send=901,Size=100]--------> (A gap detected in data)
(Restart T3-send timer)
..
{T2-receive timer expires}
/------ [Header Flags=ACK
/ Mode=0
/ Seen=801,Send=146,
/ Part=1,Of=1
/ data=(long integer)901]
(Prepare retransmit) <--------/
In this example, when Endpoint Z received the rules defined third datagram from
Endpoint A it realizes that a gap exists in
"5.5 Retransmission on Multiple Networks" to consider if the received data. At the
expiration of T2-receive timer, Endpoint Z sends a network is "available"
The MDTP implementation MUST allow gap Ack, in place
of a user normal Ack, to override this rotation
defeating MDTP's rotation upon each send.
Stewart & Xie [Page 25]
Internet Draft Multi-network Datagram Transmission Protocol Feb 1999
'Max.Retransmit', Endpoint A to indicate the sending endpoint should consider missing data.
In the peer
endpoint unreachable gap Ack, the Part and stop transmitting data Of fields are both set to it, and optionally
report '1', as opposed
to '0' as in a normal Ack. The data field of the failure.
5. Reliable Transfer Mode
Reliable transfer mode gap Ack is indicated if the sending endpoint sets a four (4)
octet long integer containing the
GAR option on sequence number of the current datagram.
If last octet of
the sending endpoint was previously transmitting gap (which is 901 in unreliable mode
(by setting UNR bit this example). The Seen field in each previous datagram), the receiver must
reset its Seen counter to gap Ack
will contain the Send value sequence number of this current datagram
upon receiving it. the first octet of the gap.
Stewart & Xie [Page 14] 21]
Internet Draft Multi-network Datagram Transmission Protocol Feb Apr 1999
The following example illustrates both piggybacked
Using these two values, Endpoint A should be able to calculate the
position and non-piggybacked
acknowledgments with both ends transmitting size of the missing data (which is 801-900 in reliable mode: this
example) and thus determine which datagrams will need to be
retransmitted.
Gap Acks cannot be piggy-backed with application data. The following is
another example of using gap Ack:
Endpoint A Endpoint Z
{App sends 3 messages}
[Header Flags=DAT|ACK
Mode=GAR
Part=0,Of=1
Seen=1,Send=1,Size=100]------------->
Seen=146,Send=701,Size=100]--------> (Start T2-receive timer)
(Start T3-send timer)
[Header Flags=DAT|ACK
Mode=GAR
Part=0,Of=1
Seen=1,Send=101,Size=100]----------->
Seen=146,Send=801,Size=100]-----X (lost)
(Restart T3-send timer)
[Header Flags=DAT|ACK
Mode=GAR
Part=0,Of=1
Seen=1,Send=201,Size=100]----------->
(Stop and restart T3-send timer)
{Timer T2 expires}
<---------------------------- [Header Flags=ACK
Mode=0
Part=0,Of=0
Seen=301,Send=1]
(cancel
Seen=146,Send=901,Size=100]--------> (A gap is detected)
(Restart T3-send timer)
..
{App sends 1 message}
[Header Flags=DAT|ACK
Mode=GAR
Part=0,Of=1
Seen=1,Send=301,Size=100]-----------> (Start T2-receive timer)
(Start T3-send timer)
{App sends 1 a message}
(cancel
(Cancel T2-receive timer)
<----------------------------
/------ [Header Flags=ACK
/ Mode=0
/ Seen=801,Send=146,
/ Part=1,Of=1
/ data=(network long)901]
(Retransmit missing data) <-----/
[Header Flags=DAT|ACK - [Header Flags=DAT|ACK
Mode=GAR / Mode=GAR
Part=0,Of=1
Seen=401,Send=1,Size=45]
(Start T3-send timer)
(cancel / Part=0,Of=1
Seen=146,Send=801,Size=100]- / Seen=801,Send=146,Size=100]
(Restart T3-send timer) \ / (Start T2-receive timer)
..
{Timer T2 Expires}
[Header Flags=ACK
Part=0,Of=0
Seen=46,Send=401]------------------> (cancel T3-send timer)
\/
/\
<---------/ \
\
Stewart & Xie [Page 15] 22]
Internet Draft Multi-network Datagram Transmission Protocol Feb Apr 1999
\-->
..
{T3-Send timer expires}
(Retransmit app data)
(Cancel T3-send timer) <--------------- [Header Flags=DAT|ACK
(Start T2-receive timer) Mode=GAR
Part=0,Of=1
Seen=1001,Send=146,Size=100]
(Restart T3-send timer)
..
{T2-receive timer expires}
[Header Flags=ACK
Part=0,Of=0
Seen=246,Send=1001]----------------> (Cancel T3-send timer)
In the above this example, Endpoint Z detected the first series of 3 messages of 100 octets each
are sent by missing data when it received
the second datagram. However, before the T2-receive timer expired, the
application at Endpoint A. The messages are unbundled in this example,
i.e., each Z requested to send a message will be transmitted (of 100 octets
in a single datagram. length). This caused Endpoint
A starts Z to cancel its send T2-receive timer T3 after sending the first datagram, and each
subsequent
send will stop the gap Ack before it sent out the datagram containing the
application message. After transmitting the application message
Endpoint Z started its T3-send timer. When Endpoint Z's T3-send timer
expired it retransmitted the previous datagram and restart at the send timer T3, extending same time
acked all of Endpoint A's outstanding datagrams. Upon the
life receipt of
the send timer. retransmission from Endpoint Z upon receiving the first datagram
starts Z, Endpoint A started its own
T2-receive timer. At the receive timer T2. When expiration of its T2-receive timer T2 in Endpoint Z expires, Endpoint Z transmits A
sent an Ack. Upon receipt of this Ack by to Endpoint A,
it stops timer T3 Z and discards resolved the first 3 datagrams (held for
possible retransmissions).
After outstanding datagram at
Endpoint Z.
5.3 Congestion Control
Three different mechanisms should be used jointly to achieve flow
and congestion control in MDTP.
First, a limit should be set on the first three number of out-bound messages were transmitted successfully,
queued up at an endpoint. If the limit is reached, new send requests
from the application at Endpoint A sends another message should be rejected until the number of 100 octets. After messages
in the queue drops back.
Secondly, MDTP uses a transmission window to control the number of
outstanding datagrams, i.e., datagrams that have been sent, but yet to
be acknowledged. The length of the window is defined as the maximal
number of outstanding datagrams a sending this datagram, Endpoint A starts timer T3 again. Upon
receipt endpoint can allow. This
length is adjusted dynamically, depending on the current number of
successful transmissions as well as the number of lost datagrams.
When the number of outstanding datagrams reaches the current window
length, the endpoint may still accept send requests from the
application, but will transmit no more datagram until an Ack is
received.
Also, when the datagram, Endpoint Z starts Timer T2. Before
Endpoint Z's T2 timer expires, window length is reached, the next send request from the
Stewart & Xie [Page 23]
Internet Draft Multi-network Datagram Transmission Protocol Apr 1999
application at Endpoint Z sends will trigger the sending endpoint to transmit a special
Window Up message. Upon receiving this Window Up message of 45 octets to Endpoint A. This causes Endpoint Z to cancel the T2 timer and to piggyback an Ack on receiver
must respond with a Window Up Response message, as illustrated by the outbound datagram being
transmitted to
following diagram (assume current window length is 3):
Endpoint A. After the transmission, A Endpoint Z then
starts its T3 timer. Upon receipt of
{App sends 3 messages}
[Header Flags=DAT|ACK
Mode=GAR
Part=0,Of=1
Seen=146,Send=1001,Size=100]--------> (Start T2-receive timer)
(Start T3-send timer)
[Header Flags=DAT|ACK
Mode=GAR
Part=0,Of=1
Seen=146,Send=1101,Size=100]-------->
(Restart T3-send timer)
[Header Flags=DAT|ACK
Mode=GAR
Part=0,Of=1
Seen=146,Send=1201,Size=100]-------->
(Restart T3-send timer)
{App sends 1 messages}
{ queue 100 byte message }
[Header Flags=WIN|ACK
Seen=146,Send=1301]-----------------> (cancel T2-receive timer)
/--- [Header Flags=ACK
/ Mode=WNR
/ Part=0,Of=0
/ Seen=1301,Send=146]
[Header Flags=DAT|ACK <---------/
Mode=GAR
Part=0,Of=1
Seen=146,Send=1301,Size=100]--------> (Start T2-receive timer)
In this datagram Endpoint A
cancels its T3 timer (since all data it has sent is acknowledged), and
starts a receive timer T2. At example, after the expiration transmission of the T2 timer first three datagrams,
Endpoint A acks the receipt of the last datagram from Endpoint Z. This Ack
causes Endpoint Z to cancel reached its T3-send timer.
It is very important to notice in the above example that the
acknowledgements to the received datagrams are always delayed by timer
T2. This delay gives window length. The next message from the receiving endpoint
application triggered a window Window Up message that was sent to piggyback Endpoint
Z. The Window Up message always contains no data and has its WIN flag
set. In response, Endpoint Z cancelled timer T2 and immediately sent
an Ack with the
Acks onto subsequent datagrams traveling WNR set in the opposite direction,
thus to avoid sending the Acks in separate datagrams.
5.1 Timer Control Mode field. The basic rules for timer control are as follows:
A) When arrival of this Ack
from Endpoint Z effectively resolved all the outstanding datagrams are acknowledged, at
Endpoint A, thus allowed Endpoint A to send out the T3-send timer
shall be stopped, if one is running.
B) When a datagram with application data (i.e., with DAT flag set) next datagram.
The window length is
received, the endpoint shall start a T2-receive timer if no timer initially set to 2, and is
running.
C) Upon then dynamically
adjusted based on the expiration performance of the T2-receive timer, underlying networks.
If the endpoint shall
ack current window length is equal to or greater than 4, every time
Stewart & Xie [Page 24]
Internet Draft Multi-network Datagram Transmission Protocol Apr 1999
when 4 consecutive outstanding datagrams are acknowledged at once by
the sender all receiver, the un-acked data sender's window length will be raised by 1 until it has received.
D) When a datagram with application data is sent out, the sending
endpoint shall start a T3-send timer.
reaches 20.
If the T3-send timer length is already
running, the endpoint shall first stop the old T3 timer and then
start a new one. If less than 4, every time when the T2-receive timer number of
consecutively acknowledged outstanding datagrams is running, the endpoint
shall first stop equal to or
greater than the T2 timer, piggyback an Ack unto current window length, the outbound
datagram, and then start a T3-send timer.
Stewart & Xie [Page 16]
Internet Draft Multi-network Datagram Transmission Protocol Feb 1999
E) sender's window will be
raised by 1 until it reaches 20.
The sender's window length will be decreased if datagram loss
occurs. If between 1 to 3 consecutive datagrams are lost, the T3-send timer expires, the endpoint shall attempt
re-transmission according window
length will be decreased by 1. If between 4 to 7 datagrams are lost,
the rules described in 5.5.
F) No window length will be decreased by 2. If 8 or more than one timer of any type should datagrams are
lost, the window length will be running on an
endpoint at any given moment.
G) decreased by 4. When a T2-receive timer expires, any bundled data waiting to be
transmitted should the window length
reaches 2 it will not be sent immediately with a piggybacked Ack to
acknowledge all un-acked data previously received.
H) Whenever decreased any further.
Moreover, any time a T3-send timer Window Up is sent to the receiving endpoint the
sender's window length will be started, any running timer should
be stopped and supplanted decreased by the T3-send timer.
I) In bundling mode, 1. Also, if a timeout
forces a retransmission the total size of all application messages
pending to sender's window length will be sent decreased
by 1. Moreover if a duplicate Ack is less than the bundle size, the messages received by a sender, this should
be withheld
indicate a network congestion situation and the T4-bundle timer number of outstanding
packets allowed should be started.
J) If decreased by 4.
The following table summarizes these rules:
-----------------------------------------------------------------------
Duplicate Ack received by sender | Adjust down by 4
-----------------------------------------------------------------------
Greater than 8 datagrams lost | Adjust down by 4
-----------------------------------------------------------------------
Greater than 4 datagrams lost | Adjust down by 2
-----------------------------------------------------------------------
Greater than 0 datagrams lost | Adjust down by 1
-----------------------------------------------------------------------
Timeout forces retransmission | Adjust down by 1
-----------------------------------------------------------------------
Window Up sent | Adjust down by 1
-----------------------------------------------------------------------
4 or more consecutive datagrams | Adjust up by 1
acknowledged (window length > 4) |
-----------------------------------------------------------------------
1/2 Window length or more acked | Adjust up by 1
(window length <=4) |
-----------------------------------------------------------------------
Finally, the total size of all application messages pending third flow control mechanism is to be sent
exceeds exchange incoming
queue information between the bundle size, two communicating endpoints. By using the T4-bundle timer should be stopped and
In Queue field in the message(s) should be immediately sent.
K) If a T4-bundle timer is running and data arrives, MDTP header, the T2-receive
timer should not be started.
L) A T4-bundle timer should never be canceled unless it is being
supplanted by a T3-send timer.
M) When sender can inform the first datagram with receiver
the Tag number of pending datagrams which unlocks the initiation
is sender has received, no T2-receive timer should be started, instead an
acknowledgement must be sent without delay. but yet
to deliver to its application. The following example shows how the
endpoints use In Queue value to accomplish flow control.
Assume that Endpoint A sent Endpoint Z 20 datagrams, and when Endpoint
Stewart & Xie [Page 17] 25]
Internet Draft Multi-network Datagram Transmission Protocol Feb Apr 1999
The following example shows
Z acked the use receipt of various timers.
Endpoint A Endpoint Z
{App sends 2 messages}
[Header Flags=DAT|ACK
Mode=GAR
Part=0,Of=1
Seen=1,Send=501,Size=100]-----------> (Start T2-receive timer)
(Start T3-send timer)
[Header Flags=DAT|ACK
Mode=GAR
Part=0,Of=1 {App sends 1 message}
Seen=1,Send=601,Size=100]-\ /-- (cancel T2-receive timer)
(stop and restart T3-send timer) \ / [Header Flags=DAT|ACK
\ / Mode=GAR
\ / Part=0,Of=1
\ Seen=601,Send=1,Size=100]
/ \ (Start T3-send timer)
/ \
<----/ \-->
..
{T3-send timer expires}
[Header Flags=DAT|ACK
Mode=GAR
Part=0,Of=1
Seen=101,Send=601,Size=100]---------> (Cancel T3-send timer)
(Restart T3-send timer) (Start T2-receive timer)
..
{Timer T2 expires}
(Cancel T3-send timer) <-------------- [Header Flags=ACK
Mode=0
Part=0,Of=0
Seen=701,Send=101]
In this example, all the 20 datagrams, only the first one of
the 20 datagrams was delivered to the application at Endpoint A sends 2 messages to
Endpoint Z. Both messages are 100 octets in length. Before In
the second
datagram arrives at last Ack sent by Endpoint Z, Endpoint Z's application sends a
message to Endpoint A. This causes Endpoint Z to cancel its T2-receive
timer and piggyback the Ack to the first received datagram on In Queue field would then have a
value of 19, indicating the
outbound datagram destined number of datagrams pending for delivery
to Endpoint A. After transmitting the
datagram Endpoint Z starts its T3-send timer. When the T3-send timer
at application. This value would be checked by Endpoint A expires, it will re-send its earlier datagram. The
retransmitted datagram is the same except for now before
it acknowledges all
outstanding packets that Endpoint Z has sent. After retransmitting sent the next datagram to Endpoint Z. If this value was found to be
greater than its current window length, Endpoint A restarts its T3-send timer.
The arrival of would not send the retransmitted datagram causes
next datagram. Instead, Endpoint Z to cancel A would start its T3-send timer and discard the duplicate datagram, and it now
starts its T2-receive timer. At
send a Window Up message to Endpoint Z at the expiration of the T2-receive timer
Stewart & Xie [Page 18]
Internet Draft Multi-network Datagram Transmission Protocol Feb 1999 timer.
This would force Endpoint Z sends the Ack to Endpoint A. Endpoint A upon receipt of the send an Ack Cancels its T3 timer.
5.2 Gap Acknowledgments with an updated In Queue
value. If a datagram becomes missing during a series of transmissions, a
special type of acknowledgement known as the gap Ack will be sent. The
gap Ack tells the sender of the missing datagram that retransmission
is needed.
The following example shows the use of gap Ack. new In Queue value was still greater than its window
length, Endpoint A Endpoint Z
{App sends 3 messages}
[Header Flags=DAT|ACK
Mode=GAR
Part=0,Of=1
Seen=146,Send=701,Size=100]--------> (Start T2-receive timer)
(Start T3-send timer)
[Header Flags=DAT|ACK
Mode=GAR
Part=0,Of=1
Seen=146,Send=801,Size=100]-----X (lost)
(Restart T3-send timer)
[Header Flags=DAT|ACK
Mode=GAR
Part=0,Of=1
Seen=146,Send=901,Size=100]--------> (A gap detected in data)
(Restart would restart its T3-send timer)
..
{T2-receive timer expires}
/------ [Header Flags=ACK
/ Mode=0
/ Seen=801,Send=146,
/ Part=1,Of=1
/ data=(long integer)901]
(Prepare retransmit) <--------/
In timer, repeating this example, when
procedure until the In Queue value of Endpoint Z received dropped below the third datagram from
current window length of Endpoint A. Then, the transmission at
Endpoint A would resume.
5.4 Sequence Number Reset
It may become necessary for an endpoint to reset the sequence number
while it realizes that is sending data to a gap exists in peer. However, the received data. At endpoint must inform
the
expiration of T2-receive timer, Endpoint Z sends a gap Ack, in place
of peer about this event by:
1) sending a normal Ack, to Endpoint A Window Up message to indicate the missing data.
In the gap Ack, force the Part peer to acknowledge all
received datagrams which have not been acknowledged, and Of fields are both
2) sending the next datagram with RES bit set to '1', as opposed
to '0' as in a normal Ack. The data field of the gap Ack is a four (4)
octet long integer containing the Flags field.
3) A sending endpoint should always reset it sequence number of counter before
the last octet of counter reaches 0x7fffffff. When the gap (which is 901 in counter reaches this example). The Seen field in the gap Ack
will contain
value the sending endpoint is required to reset its sequence number of the first octet of the gap.
Stewart & Xie [Page 19]
Internet Draft Multi-network Datagram Transmission Protocol Feb 1999
Using these two values, Endpoint
counter.
4) A sending endpoint should never reset its sequence counter until
after reaching 0x7fff05ff.
Note: This section will be able to calculate the
position and size obsoleted in a future version of the missing data (which is 801-900 in this
example)
draft and thus determine which datagrams will need to be
retransmitted.
Gap Acks cannot be piggybacked with application data. replaced by a deterministic roll-over algorithm.
The following is
another example of using gap Ack: illustrates the sequence number reset procedure
(assume that Endpoint A opts to do a reset when the data sequence
number becomes greater than 0x7fffff000).
Stewart & Xie [Page 26]
Internet Draft Multi-network Datagram Transmission Protocol Apr 1999
Endpoint A Endpoint Z
{App sends 3 2 messages}
[Header Flags=DAT|ACK
Mode=GAR
Part=0,Of=1
Seen=146,Send=701,Size=100]-------->
Seen=46,Send=0x7ffff000,Size=100]----> (Start T2-receive timer)
(Start T3-send timer)
(Reset sequence number)
[Header Flags=DAT|ACK
Mode=GAR
Part=0,Of=1
Seen=146,Send=801,Size=100]-----X (lost)
(Restart T3-send timer)
[Header Flags=DAT|ACK
Mode=GAR
Part=0,Of=1
Seen=146,Send=901,Size=100]--------> (A gap is detected)
(Restart T3-send timer)
..
{App sends a message}
(Cancel Flags=WIN|ACK
Seen=146,Send=0x7ffff100]------------> (cancel T2-receive timer)
/------
/------- [Header Flags=ACK
/ Mode=0
/ Seen=801,Send=146, Mode=WNR
/ Part=1,Of=1 Part=0,Of=0
/ data=(network long)901]
(Retransmit missing data) <-----/
[Header Flags=DAT|ACK - Seen=7fffff100,Send=46]
(Cancel T3-send timer) <------/
[Header Flags=DAT|ACK
Mode=GAR / Flags=DAT|ACK|RES
Mode=GAR
Part=0,Of=1 / Part=0,Of=1
Seen=146,Send=801,Size=100]- / Seen=801,Send=146,Size=100]
(Restart T3-send timer) \ /
Seen=46,Send=2,Size=100]-------------> (Start T2-receive timer)
(Restart T3-send timer)
\/
/\
<---------/ \
\
\-->
Stewart & Xie [Page 20]
Internet Draft Multi-network Datagram Transmission Protocol Feb 1999
..
{T3-Send timer expires}
(Retransmit app data)
{App sends 1 message}
(cancel T2-receive timer)
(Cancel T3-send timer) <--------------- <---------------- [Header Flags=DAT|ACK
(Start T2-receive timer) Mode=GAR
Part=0,Of=1
Seen=1001,Send=146,Size=100]
(Restart T3-send timer)
..
{T2-receive timer expires}
[Header Flags=ACK
Part=0,Of=0
Seen=246,Send=1001]----------------> (Cancel
Seen=102,Send=46,Size=100]
(Start T3-send timer)
In this example, Endpoint Z detected the missing data when it received
the second datagram. However, before the T2-receive timer expired, the
application at Endpoint Z requested to send a message (of 100 octets
in length). This caused Endpoint Z to cancel its T2-receive timer and
send the gap Ack before it sent out the datagram containing the
application message. After above example, after transmitting the application message
Endpoint Z started its T3-send timer. When Endpoint Z's T3-send timer
expired it retransmitted the previous first datagram and at the same time
acked all of Endpoint A's outstanding datagrams. Upon the receipt of
the retransmission from Endpoint Z, Endpoint A started
determines that its own
T2-receive timer. At data sequence number needs to be reset before it
transmits the expiration of its T2-receive timer Endpoint A
sent an Ack next datagram. It first sends out a Window Up message to
force Endpoint Z and resolved to send back a Window Up Response to ack all the
outstanding received data. Then, it transmits the datagram at
Endpoint Z.
5.3 Congestion Control
Three different mechanisms should be used jointly to achieve flow
and congestion control in MDTP.
First, a limit should be set on
it has been withholding, with the new sequence number of outbound messages
queued up at an endpoint. If and the limit is reached, new send requests
from RES flag
set. Upon detecting the application should be rejected until RES flag in the number header of messages
in the queue drops back.
Secondly, MDTP uses incoming datagram,
Endpoint Z resets its data sequence counter on Endpoint A.
5.5 Retransmission on Multiple Networks
Whenever a transmission window to control T3-send timer expires, the number of
outstanding datagrams, i.e., datagrams that have been sent, but yet to
be acknowledged. The length endpoint will take one of the window is defined as
following three actions:
A) If the maximal
number of outstanding datagrams a sending endpoint can allow. This current window length is adjusted dynamically, depending on the current number of
successful transmissions as well as the number of lost datagrams.
When the number of outstanding datagrams reaches not reached (see 5.3) and there is
application data pending, a new datagram will be sent out.
B) If the current window
length, the endpoint may still accept send requests from the
application, but will transmit no more datagram until an Ack is
received.
Also, when length is reached, a Window Up message will
be sent out.
C) If the window length is not reached, the next send request from the but there is no pending
Stewart & Xie [Page 21] 27]
Internet Draft Multi-network Datagram Transmission Protocol Feb Apr 1999
application data to send, The datagram with the lowest Send value
that is still outstanding (i.e., not been acked) will trigger be
retransmitted.
When multiple networks exist between two communicating endpoints, the sending endpoint
re-transmission should be attempted on the network specified
in the MDTP protocol variable 'last.good.intf'. The value of
'last.good.intf' is always updated to transmit refer to the network on which
the last datagram from the peer endpoint arrived.
Moreover, the number of consecutive re-transmissions is also recorded
in a special
Window Up message. Upon receiving this Window Up message variable 'retran.count' for each network. Every time a datagram is
received from a network, the receiver
must respond with corresponding retran.count is reset to '0'.
If the value in the retran.count of the current network exceeds a Window Up Response message, half
of the value of the protocol parameter 'Max.Retransmit', the
'last.good.intf' will be changed, so as illustrated by to force the
following diagram (assume current window length next
re-transmission to be directed to an alternate network.
The total number of consecutive re-transmissions across all the
networks is 3):
Endpoint A Endpoint Z
{App sends 3 messages}
[Header Flags=DAT|ACK
Mode=GAR
Part=0,Of=1
Seen=146,Send=1001,Size=100]--------> (Start T2-receive timer)
(Start T3-send timer)
[Header Flags=DAT|ACK
Mode=GAR
Part=0,Of=1
Seen=146,Send=1101,Size=100]-------->
(Restart also recorded. If this value exceeds the limit defined by
'Max.Retransmit', the sending endpoint should consider the peer
endpoint unreachable and stop transmitting data to it, and optionally
report the failure.
5.5.1 Randomization of the T3-send timer)
[Header Flags=DAT|ACK
Mode=GAR
Part=0,Of=1
Seen=146,Send=1201,Size=100]-------->
(Restart timer at retransmission
When a T3-send timer)
{App sends 1 messages}
{ queue 100 byte message }
[Header Flags=WIN|ACK
Seen=146,Send=1301]-----------------> (cancel T2-receive timer)
/--- [Header Flags=ACK
/ Mode=WNR
/ Part=0,Of=0
/ Seen=1301,Send=146]
[Header Flags=DAT|ACK <---------/
Mode=GAR
Part=0,Of=1
Seen=146,Send=1301,Size=100]--------> (Start T2-receive timer)
In this example, timer is started after retransmitting a packet, the transmission
value of the first three datagrams,
Endpoint A reached its window length. The next message from the
application triggered T3-send timer for this destination should be
extended by a Window Up message that was sent to Endpoint
Z. random amount. The Window Up message always contains no data and has its WIN flag
set. In response, Endpoint Z cancelled timer T2 and immediately sent
an Ack amount must be bounded so that the
application can predict with some reasonable degree of precision when
the WNR destination endpoint is declared unreachable.
For performance considerations, this can be implemented by
pre-calculating a set in the Mode field. The arrival of this Ack
from Endpoint Z effectively resolved all random values and then using a different
value to extend the outstanding datagrams at
Endpoint A, thus allowed Endpoint A T3-send timer for each re-transmission to the
same destination endpoint.
5.6 Termination of an Endpoint
When an endpoint terminates, it should send out a shutdown message
to each of the next datagram. peer endpoints it has ever initiated for a
communication. The window length shutdown message is initially set sent in unreliable transfer
mode and need not to 2, be acknowledged. When an endpoint receives a
shutdown message from its peer, it will remove the sender from its
record, and is then dynamically
adjusted based on optionally report the performance termination of that peer.
The following sequence shows an example of the underlying networks. termination of an
endpoint (Endpoint A).
Endpoint A
Stewart & Xie [Page 22] 28]
Internet Draft Multi-network Datagram Transmission Protocol Feb Apr 1999
If the current window length is equal to or greater than 4, every time
when 4 consecutive outstanding datagrams are acknowledged at once by
the receiver, the sender's window length will be raised by 1 until it
reaches 20.
If the length is less than 4, every time when the number of
consecutively acknowledged outstanding datagrams is equal to or
greater than the current window length, the sender's window will be
raised by 1 until it reaches 20.
The sender's window length will be decreased if datagram loss
occurs. If between 1
{App indicates termination}
[Header Flags=FIR
Mode=SHU
Seen=146,Send=1301,------------------------> to 3 consecutive datagrams are lost, the window
length will be decreased by 1. If between 4 Endpoint X
[Header Flags=FIR
Mode=SHU
Seen=1496,Send=101,------------------------> to 7 datagrams are lost,
the window length will be decreased by 2. If 8 or more datagrams are
lost, the window length will be decreased by 4. When the window length
reaches 2 it will not be decreased any further.
Moreover, any time a Window Up is sent Endpoint Y
[Header Flags=FIR
Mode=SHU
Seen=1460,Send=201-------------------------> to Endpoint Z
As shown in this example, the receiving endpoint the
sender's window length will be decreased by 1. Also, if a timeout
forces a retransmission the sender's window length will be decreased
by 1. Moreover if a duplicate Ack is received by a sender, this should
indicate a network congestion situation and the number of outstanding
packets allowed should be decreased by 4.
The following table summarizes these rules:
-----------------------------------------------------------------------
Duplicate Ack received by sender | Adjust down by 4
-----------------------------------------------------------------------
Greater than 8 datagrams lost | Adjust down by 4
-----------------------------------------------------------------------
Greater than 4 datagrams lost | Adjust down by 2
-----------------------------------------------------------------------
Greater than 0 datagrams lost | Adjust down by 1
-----------------------------------------------------------------------
Timeout forces retransmission | Adjust down shutdown message is indicated by 1
-----------------------------------------------------------------------
Window Up having
both FIR flag and SHU mode bit set. Also, notice that no
acknowledgment is sent | Adjust down back by 1
-----------------------------------------------------------------------
4 Endpoint X, Y, or more consecutive X.
5.7 Endpoint Drain
An endpoint may decide to "drain" a connection without completely
shutting it down. By draining a connection, both endpoints will remove
any record and pending datagrams | Adjust up by 1
acknowledged (window length > 4) |
-----------------------------------------------------------------------
1/2 Window length or more acked | Adjust up by 1
(window length <=4) |
-----------------------------------------------------------------------
Finally, associated with the third flow control mechanism is to exchange incoming
queue information connection.
Further communications between the two communicating endpoints. By using the
In Queue field in the MDTP header, the sender endpoints can inform the receiver
the number of pending datagrams which be resumed by
going through a re-initialization procedure.
A "drain" message is specified with the sender has received, but yet
to deliver to its application. UNR bit set in a shutdown
message. No Ack is required for a "drain" message.
The following example shows how the
endpoints use In Queue value to accomplish flow control.
Assume that sequence shows an example.
Endpoint A sent
{App indicates termination}
[Header Flags=FIR|UNR
Mode=SHU
Seen=146,Send=1301]------------------------> to Endpoint Z 20 datagrams, and X
5.8 Advisory Acknowledgments.
To increase bandwidth utilization a sending endpoint may (at its option)
request an advisory acknowledgment. A endpoint would typically do this
when Endpoint
Z acked the receipt 1/2 of all the 20 datagrams, only its window is unacknowledged and upon its last datagram
that will fill its window. Upon reception of a advisory Acknowledgment
request the first one receiver shall with no delay transmit an acknowledgment of
all received packets canceling any T2-Receive timer that may be running.
The sequence would look as follows:
Stewart & Xie [Page 23] 29]
Internet Draft Multi-network Datagram Transmission Protocol Feb Apr 1999
the 20 datagrams was delivered to the application at Endpoint Z. In
the last Ack sent by Endpoint Z, the In Queue field would then have a
value of 19, indicating the number of datagrams pending for delivery
to its application. This value would be checked by Endpoint A before
it sent the next datagram to Endpoint Z. If this value was found to be
greater than its current window length, Endpoint A would not send the
next datagram. Instead,
Endpoint A would start its T3-send timer and
send a Window Up message to Endpoint Z at the expiration of the timer.
This would force Endpoint Z to send an Ack with an updated In Queue
value. If the new In Queue value was still greater than its window
length, Endpoint A would
{App sends 3 messages}
[Header Flags=DAT|ACK
Mode=GAR
Part=0,Of=1
Seen=1,Send=1,Size=100]-------------> (Start T2-receive timer)
(Start T3-send timer)
[Header Flags=DAT|ACK
Mode=GAR
Part=0,Of=1
Seen=1,Send=101,Size=100]----------->
(Restart T3-send timer)
[Header Flags=DAT|ACK
Mode=GAR|RE1
Part=0,Of=1
Seen=1,Send=201,Size=100]----------->
(Stop and restart its T3-send timer, repeating this
procedure until the In Queue value timer)
(cancel T2-receive timer)
<---------------------------- [Header Flags=ACK
Mode=0
Part=0,Of=0
Seen=301,Send=1]
5.9 RTT Measurement
On occasion either end may wish to do a Round Trip Time measurement of Endpoint Z dropped below the
current window length
a network. There are two methods of Endpoint A. Then, measuring Round Trip Time.
Method 1 involves a ping-pong using a special ACK, Method 2 involves a
rider on top of a datagram. If Method 2 is invoked then the transmission at
Endpoint A would resume.
5.4 Sequence Number Reset
It Round Trip
Time includes the T2-Receive timer (this actually may become necessary for an be more useful
then pure RTT time since each endpoint to reset the sequence number
while it is sending data to may have a different T2-Receive
timer value).
Method 1: When a peer. However, the endpoint must inform
the peer about this event by:
1) sending wishes a Window Up message RTT measurement it shall send a ACK
datagram with RE2 set to force the peer 1, GAR set to acknowledge all
received datagrams which have not been acknowledged, 1 and
2) sending the next datagram with RES bit DAT set in the Flags field.
3) A sending endpoint should always reset it sequence counter before
the counter reaches 0x7fffffff. When the counter reaches this
value the sending endpoint is required to reset its sequence
counter.
4) A sending endpoint 0. The sender
should never reset its sequence counter until
after reaching 0x7fff05ff.
Note: This section will be obsoleted place in a future version Time Int 1 and Time int 2 the value of the
draft and be replaced by current
time of day in seconds/microseconds.
Upon receipt of a deterministic rollover algorithm.
The following example illustrates datagram with RE2 set to 1, GAR set to 1 and DAT set
to 0, the sequence number reset procedure
(assume that Endpoint A opts recipient should return the datagram to do a reset when the data sequence
number becomes greater than 0x7fffff000).
Endpoint A Endpoint Z
{App sends sender over the
arriving network with the NOG bit set. The sender can then use the
Time Int 1 and Time Int 2 messages}
[Header Flags=DAT|ACK
Mode=GAR
Part=0,Of=1
Seen=46,Send=0x7ffff000,Size=100]----> (Start T2-receive timer)
(Start T3-send timer)
(Reset sequence number)
[Header Flags=WIN|ACK
Seen=146,Send=0x7ffff100]------------> (cancel T2-receive timer)
/------- [Header Flags=ACK
/ Mode=WNR
/ Part=0,Of=0
/ Seen=7fffff100,Send=46]
(Cancel T3-send timer) <------/
[Header Flags=DAT|ACK|RES
Mode=GAR
Part=0,Of=1
Seen=46,Send=2,Size=100]-------------> (Start T2-receive timer)
(Restart T3-send timer) to calculate the current RTT.
Stewart & Xie [Page 24] 30]
Internet Draft Multi-network Datagram Transmission Protocol Feb Apr 1999
..
{App sends 1 message}
(cancel T2-receive timer)
(Cancel T3-send timer) <----------------
Endpoint A Endpoint Z
RTT - Request Now=x.y
[Header Flags=DAT|ACK
(Start T2-receive timer) Mode=GAR Flags=ACK
Mode=GAR|RE2
Part=0,Of=1
Seen=102,Send=46,Size=100]
(Start T3-send timer)
In
Seen=1,Send=301,Size=0
Time-Int1=x
Time-Int2=y]------------->
<---------------------------- [Header Flags=ACK|NOG
Mode=0
Part=0,Of=0
Seen=301,Send=1
Time-Int1=x
Time-Int2=y]
Endpoint A uses
current time subtracted from
X.y (in arriving Datagram) to
calculate the RTT.
Method 2:
If a endpoint wishes to piggyback a RTT test including the T2-Timer at
the remote endpoint the sending endpoint fills out the datagram in the
normal way for reliable communication but also sets the RE2 flag, and
places at the end of the datagram (outside the length of the data) two
long integers has a trailer.
When the above example, after transmitting receiving endpoint recognizes the first datagram Endpoint A
determines that its data sequence number needs to be reset before RE2 flag, it
transmits should extract
the two integers and place them in internal storage until the next datagram. It first sends out a Window Up message to
force Endpoint Z
datagram is scheduled to be returned (i.e. at the expiration of the
T2-Recv timer). If the The T2-Recv timer expires the receiving
endpoint should send back the acknowledgment as above with the addition of
the NOB flag as well. If the receiving endpoints upper layer sends a Window Up Response to ack all
datagram causing the
outstanding received data. Then, it transmits T2-Recv timer to be canceled then the datagram
it has been withholding, with
should include the new sequence number Trailing integers and have the RES NOB flag set. Upon detecting the RES flag in In
cases where a intervening Window UP is received the header of receiving endpoint
should respond with a window Up Response (per the incoming datagram,
Endpoint Z resets window up procedure)
but NOT cancel its data sequence counter on T2-Recv timer.
Stewart & Xie [Page 31]
Internet Draft Multi-network Datagram Transmission Protocol Apr 1999
Example 1 - T2-Recv timer expires
Endpoint A.
5.5 Retransmission on Multiple Networks
Whenever a T3-send A Endpoint Z
RTT - Request Now=x.y
[Header Flags=ACK|DAT
Mode=GAR|RE2
Part=0,Of=1
Seen=1,Send=301,Size=100
{data of 100 octets}
Time-Int1=x
Time-Int2=y]-------------> (started T2-Recv)
{T2-Recv Expires }
<---------------------------- [Header Flags=ACK|NOG|NOB
Mode=0
Part=0,Of=0
Seen=301,Send=1
Time-Int1=x
Time-Int2=y]
Example 2 - Datagram causes T2-Recv timer expires, the endpoint will take one cancel
Endpoint A Endpoint Z
RTT - Request Now=x.y
[Header Flags=ACK|DAT
Mode=GAR|RE2
Part=0,Of=1
Seen=1,Send=301,Size=100
{data of 100 octets}
Time-Int1=x
Time-Int2=y]-------------> (started T2-Recv)
{datagram sent by application}
(cancel T2-Recv)
<---------------------------- [Header Flags=DAT|ACK|NOG
Mode=GAR
Part=0,Of=1,Size=100
Seen=401,Send=1
{data of 100 octets}
Time-Int1=x
Time-Int2=y]
5.10 Heart Beat Ack
At request by the
following three actions:
A) If application, the current window length is not reached (see 5.3) and there is
application data pending, user may wish a new datagram will Heart Beat
acknowledgment sent. The Heart Beat should only be sent out.
B) If the current window length is reached, a Window Up message will allowed to be sent out.
C) If
enabled if the window length senders Mod is not reached, but there Gar (reliable delivery) and version is
2. Once enabled when no pending
application data to send, The datagram with the lowest Send value
that is still outstanding (i.e., not been acked) will datagrams are being transmitted, a T5-Heart
Beat timer should be
retransmitted. started. When multiple networks exist between two communicating endpoints, the
re-transmission T5 timer expires a ACK should
be attempted on the network specified
in the MDTP protocol variable 'last.good.intf'. The value of
'last.good.intf' is always updated to refer to the network on which
the last datagram from the peer endpoint arrived.
Moreover, the number of consecutive re-transmissions is also recorded
in a variable 'retran.count' for each network. Every time a datagram is
received from a network, sent using the corresponding retran.count is reset to '0'.
If next available link, following the value link rotation
procedure outlined in "4.5 Link Rotation". After sending the retran.count of the current network exceeds a half
of the value of the protocol parameter 'Max.Retransmit', the
'last.good.intf' will be changed, so as to force the next
re-transmission to Ack
another T5-Heart Beat timer should be directed to an alternate network.
The total number of consecutive re-transmissions across all started. If, before the
networks
expiration of T5-Heart Beat, a datagram is also recorded. If this value exceeds the limit defined by transmitted or received,
Stewart & Xie [Page 25] 32]
Internet Draft Multi-network Datagram Transmission Protocol Feb Apr 1999
'Max.Retransmit',
the sending endpoint T5 timer should consider the peer
endpoint unreachable and stop transmitting data to it, be stopped and optionally
report the failure.
5.5.1 Randomization of the T3-send appropriate T2-T4 timer at retransmission
When a T3-send should
be started. The T5 timer is started after retransmitting a packet, has the
value lowest precedence of all timers.
When sending a Heart Beat Ack, the next T3-send timer for this destination format should be
extended by a random amount. The amount must be bounded so that the
application can predict with some reasonable degree of precision when a RTT time
test. This will require the destination endpoint is declared unreachable.
For performance considerations, this can be implemented by
pre-calculating receiver to respond on the network. If
the sender does not get a set of random values and then using response on the network the heartbeat
arrived on by the time a different
value next heartbeat is to extend be sent, then the T3-send timer for each re-transmission to
network that the
same destination endpoint.
5.6 Termination of an Endpoint
When an endpoint terminates, it last heartbeat was sent upon should be counted as a
transmission failure has described in section "5.5 Retransmission on
Multiple Networks", and should counted against the 'retran.count' and
protocol parameter 'Max.Retransmit'.
6. Unreliable Transfer Mode
The unreliable transfer mode allows two endpoints to send a shutdown message to each of
other without acknowledging the receiving. This can usually achieve
higher data throughput than the reliable transfer mode. To indicate the peer endpoints it has ever initiated for a
communication. The shutdown message is sent in
unreliable transfer mode and need not to be acknowledged. When an endpoint receives a
shutdown message from its peer, it will remove the sender from its
record, and optionally report the termination of that peer. a datagram simply sets the UNR
in the mode field. The following sequence shows an example of the termination of an
endpoint (Endpoint A). illustrates unreliable data
transfer.
Endpoint A Endpoint Z
{App indicates termination} sends 2 messages}
[Header Flags=FIR
Mode=SHU
Seen=146,Send=1301,------------------------> to Endpoint X Flags=DAT|ACK
Mode=UNR
Part=0,Of=1
Seen=1,Send=11001,Size=100]-------->
[Header Flags=FIR
Mode=SHU
Seen=1496,Send=101,------------------------> to Endpoint Y Flags=DAT|ACK
Mode=UNR
Part=0,Of=1
Seen=1,Send=11101,Size=100]-------->
{App sends 1 message}
<------- [Header Flags=FIR
Mode=SHU
Seen=1460,Send=201-------------------------> to Endpoint Z
As shown in this example, the shutdown message is indicated by having
both FIR flag and SHU mode bit set. Also, notice Flags=DAT|ACK
Mode=UNR
Part=0,Of=1
Seen=11201,Send=1,Size=450]
{App sends 2 more messages}
[Header Flags=DAT|ACK
Mode=UNR
Part=0,Of=1
Seen=451,Send=11201,Size=100]------>
[Header Flags=DAT|ACK
Mode=UNR
Part=0,Of=1
Seen=451,Send=11301,Size=100]------>
Note that no
acknowledgement is sent back by Endpoint X, Y, or X.
5.7 Endpoint Drain
An endpoint may decide to "drain" a connection without completely
shutting it down. By draining a connection, both endpoints will remove
any record and pending datagrams associated with the connection.
Further communications between the two endpoints can be resumed timers are started by
going through a re-initialization procedure.
A "drain" message is specified with the UNR bit set in a shutdown
message. No Ack is required for a "drain" message. either end. Also note that even
Stewart & Xie [Page 26] 33]
Internet Draft Multi-network Datagram Transmission Protocol Feb Apr 1999
The following
though both ends are in UNR mode, the ACK flag is still set by the
sender of the datagram. This means that the Seen field in the datagram
header is still valid to indicating the sequence shows an example.
Endpoint A
{App indicates termination}
[Header Flags=FIR|UNR
Mode=SHU
Seen=146,Send=1301]------------------------> number of the last
octet received by the sender. However, the sender makes no claim as to Endpoint X
5.8 Advisory Acknowledgements.
To increase bandwidth utilization a sending endpoint may (at its option)
request an advisory acknowledgement. A endpoint would typically do this
when 1/2
whether pieces of its window is unacknowledged and data are missing. The upper application can use this
information to help detecting missing or duplicated pieces. In
unreliable mode, MDTP makes no effort to re-transmit missing data or
to screen out duplicated datagrams.
6.1 Ordered reception
In unreliable transfer if the sender sets the RE1 bit the receiver
should order the datagrams upon its last datagram arrival. Any datagrams that have not
been read by the receivers application should be ordered so that the
datagrams will fill its window. Upon reception of be received in order the datagrams were transmitted
(using the sendStartsAt field). If a adivsory Acknowledgedment
request datagram arrives after a
new datagram then the receiver shall with no delay transmit an acknowledgement of
all recieved packets canceling any T2-Receive timer that may datagram should be running. discarded. The sequence would
look as follows:
Endpoint A Endpoint Z
{App sends 3 4 messages}
[Header Flags=DAT|ACK
Mode=GAR
Mode=UNR|RE1
Part=0,Of=1
Seen=1,Send=1,Size=100]-------------> (Start T2-receive timer)
(Start T3-send timer)
Seen=1,Send=11001,Size=100]-------->
[Header Flags=DAT|ACK
Mode=UNR|RE1
Part=0,Of=1
Seen=1,Send=11101,Size=100]\ /-->
\ /
\ / (User reads/Receives all
[Header Flags=DAT|ACK \ / datagrams 11001 & 11201)
Mode=UNR|RE1 \
Part=0,Of=1 / \
Seen=451,Send=11201,Size=100]/ \---> { Datagram is discarded }
[Header Flags=DAT|ACK
Mode=GAR
Mode=UNR|RE1
Part=0,Of=1
Seen=1,Send=101,Size=100]----------->
(Restart T3-send timer)
Seen=1,Send=11301,Size=100]\ /-->
\ /
\ /
[Header Flags=DAT|ACK
Mode=GAR|RE1 \ /
Mode=UNR|RE1 \
Part=0,Of=1
Seen=1,Send=201,Size=100]----------->
(Stop and restart T3-send timer)
(cancel T2-receive timer)
<---------------------------- [Header Flags=ACK
Mode=0
Part=0,Of=0
Seen=301,Send=1]
5.9 RTT Measurement
On occasion either end may wish to do / \
Seen=451,Send=11401,Size=100]/ \--->(User reads/Receives all
datagrams in order
11301 & 11401)
Stewart & Xie [Page 34]
Internet Draft Multi-network Datagram Transmission Protocol Apr 1999
7. Reliable flows
A flow is a Round Trip Time measurment ordered reliable sequence of
a network. datagrams that is delivered
to the receiver in order without constraint to other flows. There are two methods of measuring Round Trip Time.
Method 1 envolves a pingpong using is a special ACK, Method 2 envolves
set way to initiate (open) a rider on top of flow and close a datagram. If Method 2 flow. Each flow is invoked then the Round
Trip Time includes
initiated by the T2-Receive timer (this actually sender. Multiple flows may be more
useful then pure RTT time since each endpoint may have a different
T2-Receive timer value).
Method 1:
When a endpoint wishes initiated between two
endpoints at the same time. Once initiated a RTT measurement it shall send flow will follow the same
retransmission and link rotation schema's has the rest of MDTP. However
each flow is independent of any other flow, so if datagram 1 and 2 of
flow 5 arrives, but datagram 1 of flow 4 is lost (having been sent
ahead of flow 5's datagrams), flow 5's datagrams are delivered to the
application without blocking for retransmission of the lost datagram
from flow 4 (datagram 1 of flow 4). All flow related datagrams will
have the NOB bit set. Each flow will also have a
ACK datagram separate timer
associated with RE2 set to 1, GAR set to 1 it that is unique and DAT set to 0. different from any non-flow
related timers that are running. The sender
should place Seen and Send fields will be
broken down and interpreted in Time Int the following manner.
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 and Time int 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flow Number | Datagram number in flow | (Seen)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flow Number | Datagram number in flow | (Send)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Send field will contain the value flow number of this datagram, flow 0
is always reserved and is NOT used. The datagram number is the current time
sequential number of
day in seconds/microseconds.
Upon the datagram. The Seen field is used to
acknowledge receipt of a datagram with RE2 set to 1, GAR set to 1 and DAT set to
0, the recepient should return the indicated datagram to the sender over the
arriving network with for the NOG bit set. specified
flow. The sender can then use flow number in the
Time Int 1 and Time Int 2 acknowledgment does NOT need to caclulate be the current RTT.
Endpoint A Endpoint Z
RTT - Request Now=x.y
[Header Flags=ACK
Mode=GAR|RE2
Part=0,Of=1
Seen=1,Send=301,Size=0
Time-Int1=x
Time-Int2=y]------------->
<---------------------------- [Header Flags=ACK|NOG
Mode=0
Part=0,Of=0
Seen=301,Send=1
Time-Int1=x
Time-Int2=y]
Endpoint
same as the flow number in the Send field. This format is only used
for flow datagrams.
A uses
current time subtracted from
X.y (in arriving Datagram) flow can have bundled data (see section 9) but cannot have
fragmented messages. The reason fragmented messages are not supported
is two fold, to
calculate attempt to simplify the RTT.
Method 2:
If flows a endpoint wishes little bit. And flows
are thought of has call control related limiting there size to piggyback be no
larger than one datagram per message.
If a RTT test including flow packet number reaches 0xffff, then the T2-Timer at next packet number
should wrap to 1.
Before a flow can be used it must be initiated, after the remote endpoint flow is
complete it should be closed. Note it is assumed that before any flows
can be opened the sending MDTP initiate sequence has taken place (see section
4). When a MDTP initiate sequence occurs, any endpoint fills out being
re-initialized will cause a closing of all outstanding flows during
that re-initialization. Before opening a flow the datagram in opening end should
verify that the
normal way for reliable communication but also sets version number of the RE2 flag, and
places receiving MDTP endpoint is at
least 3. If the end of version number is less than 3 then the MDTP endpoint
must NOT attempt to open a flow.
Stewart & Xie [Page 35]
Internet Draft Multi-network Datagram Transmission Protocol Apr 1999
7.1 Initiating a flow.
A flow is initiated by sending a Flow Initiate/Close Message. In all
flow datagram (outside the length of NOB bit is set. For the data) two
long integers has a trailer.
When Flow Initiate Message the receiving endpoint recognizes
UNR mode bit set as well. The Acknowledgment number (Seen) and the RE2 flag, it should extract
Sequence Number (Send) is set to 0 unless this is the two integers and place them first message in internal storage until
which case the next
datagram TAG unlock value is scheduled to be returned (i.e. at set in the expiration Send (see section 4.1).
Until a flow is open successfully a receiver of a non-opened flow
datagram will silently discard the
T2-Recv timer). If the datagram. Upon sending a flow
initiation a T3-Send timer will be started on flow 0. The T2-Recv timer expires the receiving
endpoint should send will
follow the acknowledgement same rules for retransmission and timing as above with outlined in
section 5.
The following illustration demonstrates the addition opening of flow 5:
Endpoint A Endpoint Z
{App Initiates flow 5}
[Header Flags=NOB
Mode=UNR
Part=0,Of=1
Seen=00000000,Send=0x0000 0000,Size=0,
flow=0x0005 dg=0000 ]------>
(Start T3-send timer f=5)
(Cancel T3-send timer f=5) <----------------- [Header Flags=NOB|ACK
Mode=UNR
Part=0,Of=1
Seen=0x00000005,Send=0x00000000,
Size=0, flow=0000 dg=0000]
In the NOB flag as well. If the receiving endpoints upper layer sends
a datagram causing the above example note that for flow 0, unlike all others, no T2-Recv
timer to is ever started. Each flow open/close must be canceled then the datagram
should include independently
acknowledged. Note also that in the Trailing integers and have reply acknowledgment the NOB flag set.
In cases where a intervening Window UP ACK bit is received
set. If unlikely event that Endpoint-Z wished to piggy back the receiving endpoint
should respond open of
flow 5 with a window Up Response (per the window up procedure)
but NOT cancel flow open of its T2-Recv timer.
Example 1 - T2-Recv timer expires own the sequence would look as follows:
Stewart & Xie [Page 36]
Internet Draft Multi-network Datagram Transmission Protocol Apr 1999
Endpoint A Endpoint Z
RTT - Request Now=x.y
{App Initiates flow 5}
[Header Flags=ACK|DAT
Mode=GAR|RE2 Flags=NOB
Mode=UNR
Part=0,Of=1
Seen=1,Send=301,Size=100
{data of 100 octets}
Time-Int1=x
Time-Int2=y]-------------> (started T2-Recv)
{T2-Recv Expires }
<---------------------------- [Header Flags=ACK|NOG|NOB
Mode=0
Part=0,Of=0
Seen=301,Send=1
Time-Int1=x
Time-Int2=y]
Example 2 - Datagram causes T2-Recv
Seen=0,Send=0,
Size=0,
flow=5, dg=0 ]------>
(Start T3-send timer cancel
Endpoint A Endpoint Z
RTT - Request Now=x.y f-5) {App Initiates flow 8}
(Cancel T3-send timer f-5) <----------------- [Header Flags=ACK|DAT
Mode=GAR|RE2 Flags=NOB|ACK
Mode=UNR
Part=0,Of=1
Seen=1,Send=301,Size=100
{data of 100 octets}
Time-Int1=x
Time-Int2=y]-------------> (started T2-Recv)
{datagram sent by application}
(cancel T2-Recv)
<----------------------------
Seen=5,
Send=0,
Size=0,flow=0008 dg=0000]
(Start T3-send timer - f8)
[Header Flags=DAT|ACK|NOG
Mode=GAR
Part=0,Of=1,Size=100
Seen=401,Send=1
{data Flags=NOB|ACK
Mode=0
Part=0,Of=1
Seen=8,Send=0,Size=0,
flow=0, dg=0]-------------------------------->(Cancel T3-send timer - f8)
Note that at the initiate of 100 octets}
Time-Int1=x
Time-Int2=y]
5.10 Heart Beat Ack
At request by a flow, the application, timer started is considered
the user may wish first timer for the flow, but it is sent over flow 0. Note also
that a Heart Beat acknowledgement
sent. The Heart Beat should only be piggyback open is not allowed to be enabled if the senders
Mod is Gar (reliable delivery) and version is 2. Once enabled TAG sequences have not
been exchanged.
7.2 Flow acknowledgments
Normal dataflow's follow the normal MDTP transmission formats (see
section 5) Acknowledgments when no
datagrams possible are being
transmitted, a T5-Heart Beat timer should be started. piggy-backed on
datagrams. Each flow maintains its own send timer. When the
T5 timer expires a ACK should be sent using the next available link, following
the link rotation procedure outlined in "4.5 Link Rotation". After sending
the Ack another T5-Heart Beat timer should be started. If, before the
expiration no piggyback
of T5-Heart Beat, a datagram data and acknowledgments is transmitted or recieved, the
T5 timer should possible, more than one flow can be stopped and the appropriate T2-T4 timer should be started.
The T5 timer has
acknowledged at the lowest precedence of all timers.
When sending a Heart Beat Ack, same time by using the format should be that Flow Extend Acknowledgment
format. The Send field (now considered the number of a RTT time test.
This extended
acknowledgments) will require the reciever to respond on contain the network. If number of acknowledgments in the sender
does not get a response on
array.
During data transfer if the network when the heartbeat arrived on by datagram number reaches 0xffff
the
time next packet should be labeled 1. Pkt 0 is never used for datagram
transfer.
One T2-Recv timer is maintained for all flows. If more than one flow
is being timed and a next heartbeat datagram is to be sent, transmitted then one of the network that
flows will be acknowledged and the last
heartbeat was sent upon should T2-Recv timer will be counted as left running
until expiration, which will then cause the Flow Extended
Acknowledgment to be sent, acknowledging all remaining flows. The
following examples illustrate examples of flow acknowledgments. For
this example we assume that Endpoint A has 3 flows open 5,7 and
9. Endpoint Z has 4 flows open 0x11, 8 4 and 1.
Stewart & Xie [Page 37]
Internet Draft Multi-network Datagram Transmission Protocol Apr 1999
Example 1: Endpoint A sends to Endpoint Z T2-Recv timer expires
Endpoint A Endpoint Z
{ App sends first datagram on flow 5}
[Header Flags=NOB|DAT
Mode=REL
Part=0,Of=1
Seen=0x0000 0000,Send=0x0005 0001,Size=20]------>(Start T2-Recv)
(Start T3-send timer-f5)
{ T2-Recv Timer Expires }
(Cancel T3-send timer) <--------------- [Header Flags=NOB|ACK
Mode=REL
Part=0,Of=1
Seen=0x00050001,Send=0x00000000,
Size=0]
(Start T3-send timer)
Example 1: Endpoint A sends to Endpoint Z T2-Recv timer expires
Endpoint A Endpoint Z
{ App sends first datagram on flow 5}
[Header Flags=NOB|DAT
Mode=REL
Part=0,Of=1
Seen=0x0000 0000,Send=0x0005 0001,Size=20]------>(Start T2-Recv)
(Start T3-send timer-f5)
{ T2-Recv Timer Expires }
(Cancel T3-send timer) <--------------- [Header Flags=NOB|ACK
Mode=REL
Part=0,Of=1
Seen=0x00050001,Send=0x00000000,
Size=0]
(Start T3-send timer)
Stewart & Xie [Page 38]
Internet Draft Multi-network Datagram Transmission Protocol Apr 1999
Example 2: Endpoint A sends multiple messages to Endpoint Z and
T2-Recv timer expires
Endpoint A Endpoint Z
{ App sends 1 datagram on flow 5}
[Header Flags=NOB|DAT
Mode=REL
Part=0,Of=1
Seen=0x0000 0000,Send=0x0005 0002,Size=20]------>(Start T2-Recv)
(Start T3-send timer-f5)
{ App sends 1 datagram on flow 9}
[Header Flags=NOB|DAT
Mode=REL
Part=0,Of=1
Seen=0x0000 0000,Send=0x0009 0004,Size=20]------>
(Start T3-send timer-f9)
{ App sends 1 datagram on flow 5}
[Header Flags=NOB|DAT
Mode=REL
Part=0,Of=1
Seen=0x0000 0000,Send=0x0005 0003,Size=20]------>
{ App sends 1 datagram on flow 7}
[Header Flags=NOB|DAT
Mode=REL
Part=0,Of=1
Seen=0x0000 0000,Send=0x0007 0011,Size=20]------>
{ T2-Recv Timer Expires }
(Cancel T3-send timer-f5) <-------------- [Header Flags=NOB|ACK
(Cancel T3-send timer-f9) Mode=REL
(Cancel T3-send timer-f7) Part=0,Of=1
Seen=0x00050003,
Send=0x00000002,
Size=0,
ex[0]=0x00090004,
ex[1]=0x00070011
]
Stewart & Xie [Page 39]
Internet Draft Multi-network Datagram Transmission Protocol Apr 1999
Example 3: Endpoint A sends a transmission failure has
described in section "5.5 Retransmission on Multiple Networks", and
should counted against the 'retran.count' and protocol parameter 'Max.Retransmit'.
6. Unreliable Transfer Mode
The unreliable transfer mode allows two endpoints to send message to each
other without acknowledging the receiving. This can usually achieve
higher data throughput than the reliable transfer mode. To indicate the
unreliable transfer mode the sender of Endpoint Z, Endpoint Z
piggy-backs a ack.
{ App sends 1 datagram simply sets the UNR
in the mode field. The following sequence illustrates unreliable data
transfer. on flow 5}
[Header Flags=NOB|DAT
Mode=REL
Part=0,Of=1
Seen=0x0000 0000,Send=0x0005 0004,Size=20]------>(Start T2-Recv)
(Start T3-send timer-f5) { App sends 1 message flow 0x11}
( cancel T2-Recv Timer )
(Cancel T3-send timer-f5) <----------------- [Header Flags=NOB|DAT|ACK
(Start T2-Recv timer) Mode=REL
Part=0,Of=1
Seen=0x0005 0004,
Send=0x0011 0008,
Size=10]
(Start T3-send timer-f0x11)
{ T2-Recv Timer Expires }
[Header Flags=NOB|ACK
Mode=REL
Part=0,Of=1
Seen=0x0000 0000,Send=0x0011 0008,Size=0]------>(Cancel T3-send-f0x11)
Stewart & Xie [Page 40]
Internet Draft Multi-network Datagram Transmission Protocol Apr 1999
Example 4: Endpoint A sends a multiple message to Endpoint Z, Endpoint Z
{App
piggy-backs a ack and sends 2 messages} a Extended flow Ack.
{ App sends 1 datagram on flow 5}
[Header Flags=DAT|ACK
Mode=UNR Flags=NOB|DAT
Mode=REL
Part=0,Of=1
Seen=1,Send=11001,Size=100]-------->
Seen=0x0000 0000,Send=0x0005 0005,Size=20]------>(Start T2-Recv)
(Start T3-send timer-f5)
{ App sends 1 datagram on flow 9}
[Header Flags=DAT|ACK
Mode=UNR Flags=NOB|DAT
Mode=REL
Part=0,Of=1
Seen=1,Send=11101,Size=100]-------->
{App
Seen=0x0000 0000,Send=0x0009 0004,Size=20]------>
(Start T3-send timer-f9)
{ App sends 1 message}
<------- message flow 0x4}
(Cancel T3-send timer-f5) <-------------- [Header Flags=DAT|ACK
Mode=UNR Flags=NOB|DAT|ACK
(Start T2-Recv timer) Mode=REL
Part=0,Of=1
Seen=11201,Send=1,Size=450]
{App sends 2 more messages}
Seen=0x00050005,Send=0x00040004,
Size=10]
(Start T3-send timer-f0x4)
{ T2-Recv Timer Expires }
(Start T3-send timer)
(Cancel T3-send timer) <-------------- [Header Flags=DAT|ACK
Mode=UNR Flags=NOB|ACK
Mode=REL
Part=0,Of=1
Seen=451,Send=11201,Size=100]------>
Seen=0x00090004,Send=0x00000000,
Size=0]
{ T2-Recv Timer Expires }
[Header Flags=DAT|ACK
Mode=UNR Flags=NOB|ACK
Mode=REL
Part=0,Of=1
Seen=451,Send=11301,Size=100]------>
Note that no timers are started by either end. Also note that even
though both ends
Seen=0x0000 0000,Send=0x0004 0004,Size=0]------>(Cancel T3-send-f0x4)
Retransmissions and resends are in UNR mode, the ACK flag is still set by the
sender of handled per section 5 but using the datagram. This means that
flow formats (i.e. the Seen field NOB bit set) as described above. The rules for
retransmission, windowing, flow control and declaration of endpoint
death are applied has defined in the datagram
header is still valid section 5.
Note that messages to indicating the sequence number of the last
Stewart & Xie [Page 27]
Internet Draft Multi-network Datagram Transmission Protocol Feb 1999
octet received by the sender. However, different flows are handed up ordered
correctly within the sender makes no claim as flow but not delayed with respect to
whether pieces of data are missing. any other
flows transmission or retransmission.
7.3 Flow session closing
The upper application can use may signal a closing of a flow. If this
information to help detecting missing or duplicated pieces. In
unreliable mode, MDTP makes no effort to re-transmit missing data or
to screen out duplicated datagrams.
6.1 Ordered receiption
In unreliable transfer if the sender sets the RE1 bit the reciever
should order occurs the datagrams upon arrival. Any datagrams that have not
been read by
implementation will inform its peer of the receivers application should be ordered closing so that resources
used to track and maintain the
datagrams will flow can be received reused/freed. The following
sequence is used to release a flow in order the datagrams were transmited
(using this example we see the sendStartsAt field). If a datagram arrives after a
new datagram then closing
of flow 5. Note it is up to the datagram should be discarded. The sequence would
look as follows:
Endpoint A Endpoint Z
{App sends 4 messages}
[Header Flags=DAT|ACK
Mode=UNR|RE1
Part=0,Of=1
Seen=1,Send=11001,Size=100]-------->
[Header Flags=DAT|ACK
Mode=UNR|RE1
Part=0,Of=1
Seen=1,Send=11101,Size=100]\ /-->
\ /
\ / (User reads/Receives sender to assure that all
[Header Flags=DAT|ACK \ / outstanding
datagrams 11001 are acknowledged before closing a flow:
Stewart & 11201)
Mode=UNR|RE1 \
Part=0,Of=1 / \
Seen=451,Send=11201,Size=100]/ \---> { Xie [Page 41]
Internet Draft Multi-network Datagram is discarded } Transmission Protocol Apr 1999
Endpoint A Endpoint Z
{App Initiates flow 5}
[Header Flags=DAT|ACK
Mode=UNR|RE1 Flags=NOB|RES
Mode=UNR
Part=0,Of=1
Seen=1,Send=11301,Size=100]\ /-->
\ /
\ /
Seen=0,Send=0,Size=0,
flow=5, dg=0 ]------>
(Start T3-send timer f-5)
(Cancel T3-send timer f-5) <----------------- [Header Flags=DAT|ACK \ /
Mode=UNR|RE1 \ Flags=NOB|ACK|RES
Mode=UNR
Part=0,Of=1 / \
Seen=451,Send=11401,Size=100]/ \--->(User reads/Receives all
datagrams in order
11301 & 11401)
7.
Seen=5,Send=0,
Size=0,
flow=0, dg=0]
Datagrams received by a endpoint directed to a closed flow should be
silently discarded.
8. Mixed Mode Data Transmission
An endpoint can switch between reliable and unreliable transfer modes
at any time during the data transfer.
The following sequence illustrates such a transfer mode change, in
which both endpoints starts with the unreliable transfer mode, and
then Endpoint A switches to reliable transfer mode.
Endpoint A Endpoint Z
{App send 1 message}
<------------------ [Header Flags=DAT|ACK
Mode=UNR
Part=0,Of=1
Seen=11201,Send=1,Size=450]
..
{App send 1 message}
[Header Flags=DAT|ACK
Mode=UNR
Part=0,Of=1
Seen=451,Send=11201,Size=100]------>
Stewart & Xie [Page 42]
Internet Draft Multi-network Datagram Transmission Protocol Apr 1999
..
{App send 1 message}
[Header Flags=DAT|ACK
Mode=GAR
Part=0,Of=1
Seen=451,Send=11301,Size=100]------> (Start T2-receive timer)
(Start T3-send timer)
{App sends 1 message}
(Cancel T2-receive timer)
/------- [Header Flags=DAT|ACK
/ Mode=UNR
/ Part=0,Of=1
/ Seen=11401,Send=1,Size=450]
(Cancel T3-send timer) <-------/
..
{App sends 1 message}
[Header Flags=DAT|ACK
Mode=GAR
Part=0,Of=1
Seen=451,Send=11401,Size=100]------> (Start T2-receive timer)
(Start T3-send timer)
Stewart & Xie [Page 28]
Internet Draft Multi-network Datagram Transmission Protocol Feb 1999
..
{Timer T2 Expires}
(Cancel T3-send timer) <------------------- [Header Flags=ACK
Mode=0
Part=0,Of=0
Seen=11501,Send=146]
Note that in the second datagram sent by Endpoint A the mode is
switched to reliable transfer mode (with GAR bit set). This causes
Endpoint A to start its T3-send timer. When Endpoint Z receives the
datagram and realizes the mode change, it starts its T2-receive timer.
At this point, Endpoint Z also must update its Seen value to 11301.
This will allow Endpoint Z to align its Seen counter
to the Seen value of this first reliable datagram from Endpoint
A. This prevents Endpoint Z from requesting retransmission of data
that Endpoint A may not have.
8.
9. Bundled Messages
In order to increase network utilization, MDTP allows an endpoint to
bundle small application messages into one single datagram for
transmission. This bundled mode can be applied to both reliable and
unreliable datagrams.
An endpoint indicates to its peer that it is currently in bundled
mode by setting the BUN bit in the mode field.
Stewart & Xie [Page 29] 43]
Internet Draft Multi-network Datagram Transmission Protocol Feb Apr 1999
8.1
mode by setting the BUN bit in the mode field.
9.1 Format of Bundled Datagram
The ISB bit in the flag field is set to indicate the current datagram is
bundled, i.e., it contains multiple messages. The format of a bundled
datagram is defined as follow:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MDTP Protocol Identifier 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MDTP Protocol Identifier 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Acknowledgment Number (Seen) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number (Send) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Size | Part | Of |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Mode | Version | Num On Queue |
|N N W I F R D A|B S W R R B G U| | |
|O O I S I E A C|R H N E E U A N| | |
|G B N B R S T K|O U R 1 2 N R R| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number Of Messages | Size of first message B1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| B1 octets of data |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Size of second second message B2 | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| B2 octets of data |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Size of last message BL | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| BL octets of data |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Data Size in a bundled datagram indicates the actually size of the
data field of the datagram, including both the bundling overhead and
the actually application data. Since no fragmentation is allowed in a
bundled datagram, the Part field will always be '0' and the Of field
always be '1'.
Stewart & Xie [Page 44]
Internet Draft Multi-network Datagram Transmission Protocol Apr 1999
The first two octets of the data field is a 16 bit integer indicating
the number of messages bundled in the datagram. This is followed
immediately by a list of bundled messages. Each bundled message B2 | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| B2 starts
with an integer of two octets indicating the size of the data |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Size in the
message, followed by the data itself.
All integers in the datagram should be transmitted in the network byte
order.
9.2 Bundled Transfer
Two protocol parameters, namely the Min.Bundle and Max.Bundle, are
used to control the assembly of last message BL | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| BL octets bundled datagrams. If the current size
of a bundled datagram is smaller than Min.Bundle, the endpoint will
withhold the datagram from transmission and start T4-bundle timer. If
new out-bound data |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Data Size becomes available for transmission, the endpoint
will attempt to bundle the new data with the current withheld datagram
by using the following rules:
A) If the size of the new data is greater than or equal to
Min.Bundle, the current withheld datagram will be transmitted and
T4-bundle timer will be canceled. Then, the new data will be
transmitted in a separate datagram.
B) If the size of the new data is less than Min.Bundle, but the
combined size of the current datagram and the new data is greater
than or equal to Max.Bundle, the current datagram will be sent and
the new data will be withheld as the new current datagram.
C) If the size of the new data is less than Min.Bundle, and the
combined size of the current datagram and the new data is less than
Max.Bundle, the new data will be bundled into the current
datagram indicates and the bundled datagram will be immediately transmitted.
D) If the actually size of the new data field of is less than Min.Bundle, and the datagram, including both
combined size of the bundling overhead current datagram and the actually application data. Since no fragmentation new data is allowed in a less than
Min.Bundle, the new data will be bundled datagram, into the Part field current
datagram. And the T4-bundle timer will always be '0' and restarted.
E) If T4-bundle timer expires, the Of field
always current datagram will be '1'. sent
immediately.
F) If the size of the new data is greater than the Max.Bundle, the
current datagram will be sent. Then, the new data will be fragmented
for transmission (see 9).
Stewart & Xie [Page 30] 45]
Internet Draft Multi-network Datagram Transmission Protocol Feb Apr 1999
The first two octets of the data field following is a 16 bit integer indicating
the number an example of messages bundled in the datagram. This is followed
immediately by a list data transfer, assuming
Max.Bundle=4096 and Min.Bundle=1700:
Endpoint A Endpoint Z
{App sends 1 messages of bundled messages. Each bundled message starts
with an integer 100 octets}
(withhold and Start T4-Bundle timer)
..
{App sends 1 messages of two octets indicating the size 100 octets}
(bundling into current datagram)
..
{App sends 1 messages of 100 octets}
(bundling into current datagram)
..
{T4-bundle timer expires}
[Header Flags=DAT|ACK
Mode=GAR|BUN
Part=0,Of=1
Seen=146,Send=1001,Size=308]--------> (Start T2-receive timer)
(T3-send timer starts)
..
{Timer T2 Expires}
(cancel T3-send) <---------------- [Header Flags=ACK
Mode=0
Part=0,Of=0
Seen=1309,Send=146]
Notice that the data Data Size in the
message, followed datagram sent by Endpoint A is not
300 but 308. This is due to the data itself.
All integers in fact that this size reflects the
size of the data field of the datagram should be transmitted in including the network byte
order.
8.2 Bundled Transfer
Two protocol parameters, namely bundling overhead.
When the Min.Bundle bundled datagram arrives at the receiving endpoint, each
message is unbundled and Max.Bundle, are
used delivered separately to control the assembly of bundled datagrams. If upper level
application.
10. Fragmented Messages
When the current size of a bundled datagram is smaller than Min.Bundle, an out-bound message exceeds the endpoint will
withhold value defined in the datagram from transmission and start T4-bundle timer. If
new outbound data becomes available for transmission,
protocol parameter Max.Bundle, the endpoint will attempt to bundle the new data with fragment the current withheld datagram
by using message
into smaller pieces of sizes equal to or smaller than Max.Bundle and
send each piece out in a separate datagram.
The Part and Of fields are used to disassemble and reassemble the
fragmented message.
The following rules:
A) If example shows the size transmission of the new data a fragmented message
(assuming Max.Bundle=4096, Min.Bundle=1700):
Stewart & Xie [Page 46]
Internet Draft Multi-network Datagram Transmission Protocol Apr 1999
Endpoint A Endpoint Z
{App sends 1 messages 8544 octets long}
[Header Flags=DAT|ACK
Mode=GAR|BUN
Part=0,Of=3
Seen=146,Send=1001,Size=4072]-------> (Start T2-receive timer)
[Header Flags=DAT|ACK
Mode=GAR|BUN
Part=1,Of=3
Seen=146,Send=5073,Size=4072]------->
[Header Flags=DAT|ACK
Mode=GAR|BUN
Part=2,Of=3
Seen=146,Send=9145,Size=400]-------->
(Start T3-send timer)
..
{Timer T2 Expires}
/----------- [Header Flags=ACK
/ Mode=0
/ Part=0,Of=0
(cancel timer T3) <-----------/ Seen=9545,Send=146]
Notice that Endpoint A is greater than or equal using the reliable transfer mode to
Min.Bundle, send the current withheld datagram
fragmented message. In this mode, Endpoint Z will be transmitted hold the fragments
and
T4-bundle timer will be canceled. Then, request retransmission if a fragment is found missing, i.e., a gap
is found in the new received data will be
transmitted in a separate datagram.
B) If (see 5). When all the size parts of the new data is less than Min.Bundle, but
fragmented message are received, the
combined size of endpoint will re-assemble the current datagram
message and dispatch it to the new data upper level application.
It is greater
than or equal also allowed in MDTP to Max.Bundle, the current send fragmented message using unreliable
transfer mode. However, in unreliable mode, each fragment datagram
will be sent and dispatch to the new data application upon its arrival, and no
retransmission will be withheld as the new current datagram.
C) If the size of the new data requested even if a fragment is less than Min.Bundle, and the
combined size of the current datagram and the new data found missing.
Bundling is less than
Max.Bundle, the new data will be bundled into prohibited if the current datagram contains a fragment of
a fragmented message.
11. Non-protocol Datagrams
The MDTP protocol allows an endpoint to send and receive non-protocol
datagrams such as the bundled datagram will be immediately transmitted.
D) If traditional UDP datagrams. Non-protocol
datagrams are detected by the size absence of the new data is less than Min.Bundle, and MDTP protocol
identifiers at the
combined size beginning of the current datagram and the new data datagram. A non-protocol
transmission received by an MDTP endpoint is less than
Min.Bundle, the new data will be bundled into the current termed as a "raw"
datagram. And When a raw datagram arrives, the T4-bundle timer receiving endpoint will be restarted.
E) If T4-bundle timer expires, set
itself into raw mode and start sending back to its peer in raw mode
as well.
Once an endpoint is in raw mode with a peer, only a change of
operational mode by the current application or a reception of a MDTP datagram
will be sent
immediately.
F) If bring the size endpoint out of raw mode. In the new data is greater than the Max.Bundle, the
current datagram will be sent. Then, latter case, the new data will be fragmented
for transmission (see 9).
Stewart & Xie [Page 31] 47]
Internet Draft Multi-network Datagram Transmission Protocol Feb Apr 1999
The following is
endpoint will use the default MDTP operational mode predefined by the
application for MDTP transmissions. When an example of bundled data transfer, assuming
Max.Bundle=4096 and Min.Bundle=1700:
Endpoint A Endpoint Z
{App sends 1 messages of 100 octets}
(withhold and Start T4-Bundle timer)
..
{App sends 1 messages of 100 octets}
(bundling endpoint changes from raw
mode into current datagram)
..
{App sends 1 MDTP mode, the normal MDTP initiation messages must be
exchanged between the two endpoints, as described in 4.
12. Broadcast and Multicast
Broadcast and multicast are supported by MDTP when the underlying
transport layer supports them. Both types of 100 octets}
(bundling into current datagram)
..
{T4-bundle timer expires}
[Header Flags=DAT|ACK
Mode=GAR|BUN
Part=0,Of=1
Seen=146,Send=1001,Size=308]--------> (Start T2-receive timer)
(T3-send timer starts)
..
{Timer T2 Expires}
(cancel T3-send) <---------------- [Header Flags=ACK
Mode=0
Part=0,Of=0
Seen=1309,Send=146]
Notice that transmissions are carried
out in unreliable transfer mode.
For broadcast datagrams, the Data Size BRO bit will be set to '1' and the UNR
bit will be set to '0' in the datagram sent by Endpoint A is not
300 but 308. This is due mode field. For multicast datagrams,
both the BRO bit and the UNR bit will be set to '1'.
For multicast datagrams, the fact that this size reflects value in the
size Send field will indicate
the number of multicast datagrams transmitted by the data field sender. This
information makes it possible for the receiver of the multicast to
detect duplicated multicast datagrams and also to detect lost
multicast datagrams. A multicast datagram including transmission MUST use
the bundling overhead.
When alternate multicast header filling in both the bundled datagram arrives at multicast transmit
to address as well as its lowest network address in the receiving endpoint, each
message is unbundled multicast
from address.
Bundling and delivered separately fragmentation are not allowed in either multicast or
broadcast datagrams.
12.1 Multicast/Broadcast initialization.
No initiation is needed for an endpoint to transmit multicast or
broadcast datagrams. However, caution should be taken when
transmitting non-protocol datagrams (i.e., datagrams with no MDTP
protocol header) in multicast or broadcast transmission. This is
because the upper level
application.
9. Fragmented Messages
When non-protocol datagrams may inadvertently force all the size
receiving endpoints of an outbound message exceeds the value defined in the
protocol parameter Max.Bundle, multicast or broadcast transmission into
raw mode (see 10).
12.2 Transmission of Broadcast Datagrams.
When sending a broadcast datagram, the endpoint will fragment the message
into smaller pieces of sizes equal not take effort
to or smaller than Max.Bundle and
send each piece out in a separate datagram.
The Part and Of fields are used prevent duplicate transmissions (this is likely to disassemble and reassemble occur
especially when multiple networks exist). The application at the
fragmented message.
receiving end must be prepared to handle duplicate
broadcast messages.
Stewart & Xie [Page 32] 48]
Internet Draft Multi-network Datagram Transmission Protocol Feb Apr 1999
The following example shows the transmission of a fragmented message
(assuming Max.Bundle=4096, Min.Bundle=1700): following is an example of broadcast datagram transmission:
Endpoint A Endpoint Z
{App
{application sends 1 2 messages 8544 octets long}
[Header Flags=DAT|ACK
Mode=GAR|BUN
Part=0,Of=3
Seen=146,Send=1001,Size=4072]-------> (Start T2-receive timer)
[Header Flags=DAT|ACK
Mode=GAR|BUN
Part=1,Of=3
Seen=146,Send=5073,Size=4072]-------> }
[Header Flags=DAT|ACK
Mode=GAR|BUN
Part=2,Of=3
Seen=146,Send=9145,Size=400]-------->
(Start T3-send timer)
..
{Timer T2 Expires}
/----------- Flags=DAT
Mode=BRO
Part=0,Of=1
Seen=0,Send=0,Size=200]--------------> (Datagram may appear
more than once.)
[Header Flags=ACK
/ Mode=0
/ Part=0,Of=0
(cancel timer T3) <-----------/ Seen=9545,Send=146] Flags=DAT
Mode=BRO
Part=0,Of=1
Seen=0,Send=0,Size=100]-------------->
Notice that Endpoint A is using the reliable transfer mode to send the
fragmented message. In this mode, Endpoint Z will hold the fragments no timers are used on either end, and request retransmission if a fragment is found missing, i.e., a gap
is found Seen and Send values
in the received data (see 5). When all the parts datagrams are always '0'.
12.3 Transmission of Multicast Datagrams.
Unlike the
fragmented message broadcast transmission, when multicast datagrams are received, the endpoint will re-assemble
transmitted the
message and dispatch it receiving endpoints should take effort to prevent
duplicate copies of datagrams from being distributed to their
applications.
This is possible because the upper level application.
It transmission of multicast datagrams is also allowed in MDTP
usually addressed to send fragmented message using unreliable
transfer mode. However, a special multicast network address. The receiving
endpoints can thus use this multicast address in unreliable mode, each fragment datagram
will be dispatch to combination with the application upon its arrival, and no
retransmission will be requested even if
sender's address to detect duplicate transmissions of a fragment is found missing.
Bundling is prohibited if the current datagram contains multicast
datagram.
The following example illustrates multicast transmissions between two
endpoints.
Endpoint A Endpoint Z
{app multicasts a fragment of message}
[Header Flags=DAT
Mode=BRO|UNR
Part=0,Of=1
Seen=0,Send=5,Size=250]--------------> (may receive more
than one copy)
..
{app multicasts a fragmented message.
10. Non-protocol Datagrams
The MDTP protocol allows an endpoint to send and message}
[Header Flags=DAT
Mode=BRO|UNR
Part=0,Of=1
Seen=0,Send=6,Size=500]--------------> (may receive non-protocol
datagrams such as the traditional UDP datagrams. Non-protocol
datagrams are detected by more
than one copy)
Notice the absence values of the MDTP protocol
identifiers at Send field in the beginning multicast datagrams (which
are 5 and 6, respectively). They represent the sequence numbers of the datagram.
multicast datagrams Endpoint A non-protocol
transmission received by an MDTP endpoint is termed as a "raw"
datagram. When a raw datagram arrives, has sent out. Endpoint Z should use the receiving endpoint will set
itself into raw mode and start sending back to its peer in raw mode
Stewart & Xie [Page 33] 49]
Internet Draft Multi-network Datagram Transmission Protocol Feb Apr 1999
as well.
Once an endpoint is
Send value found in raw mode with a peer, only a change of
operational mode by the application incoming multicast datagrams to detect any
missing or duplicate datagrams.
Duplicate datagrams will be discarded and no effort will be made to
retransmit lost multicast datagrams.
For example, each endpoint can track the last 32 datagrams received by
using a reception sliding window of 32 bits. Each time a MDTP new datagram
will bring with a
sequence number higher than the endpoint out current window head is received, the
window can be moved up. If a datagram received has a sequence number
below the current window head, then a check of raw mode. In the latter case, last 32 received
datagrams' sequence numbers can determine whether the new datagram is a
duplicate. If the
endpoint will use sequence number of the default MDTP operational mode predefined by new datagram is below the
application for MDTP transmissions. When an endpoint changes from raw
mode into MDTP mode,
current window tail then the normal MDTP initiation messages must datagram should be
exchanged between the two endpoints, as described in 4.
11. Broadcast considered a duplicate
and discarded.
12.4 Reset of the Multicast
Broadcast and multicast are supported by MDTP when Datagram Sequence Number
If the underlying
transport layer supports them. Both types of transmissions are carried
out Seen field in unreliable transfer mode.
For broadcast datagrams, the BRO bit will be a multicast datagram is set to '1' and '1', it is an
indication that the UNR
bit will be set to '0' sender has reset its multicast datagram sequence
number. The receiving endpoint, upon detecting this reset indicator in
the mode field. For incoming multicast datagrams,
both the BRO bit and datagram, should start a procedure to adopt the UNR bit will
new sequence number for error detection. However, caution
should be set taken to '1'.
For prevent false resets due to duplicated datagrams
with reset indicator propagating through multiple networks.
To guarantee that all receivers of the multicast datagrams, group adopt the value in new
sequence number, the Send field will indicate reset indicator should be repeated within the number of
first N multicast datagrams transmitted sent out after the reset. N is predefined
by the sender. This
information makes it possible for protocol parameter Num.Of.Mcast.Reset.Msg.
At the receiver of receiving endpoint, when the reset indicator is detected the
new sequence number will be adopted. However, if two reset events are
detected within a predefined time interval (Min.Mcast.Time.To.Reset),
the multicast to
detect duplicated multicast datagrams and also to detect lost
multicast datagrams. second reset indicator will be ignored.
Stewart & Xie [Page 50]
Internet Draft Multi-network Datagram Transmission Protocol Apr 1999
The following is an example (assuming Num.Of.Mcast.Reset.Msg = 4):
Endpoint A multicast Endpoint Z
[Header Flags=DAT
Mode=BRO|UNR
Part=0,Of=1
Seen=0,Send=17859,Size=300]---------->
`<
{reset message sequence number indicated}
[Header Flags=DAT
Mode=BRO|UNR
Part=0,Of=1
Seen=1,Send=1,Size=250]--------------> (record new sequence
number, datagram transmission MUST use may
appear more than once)
[Header Flags=DAT
Mode=BRO|UNR
Part=0,Of=1
Seen=1,Send=2,Size=250]--------------> (may appear more than
once)
[Header Flags=DAT
Mode=BRO|UNR
Part=0,Of=1
Seen=1,Send=3,Size=500]--------------> (may appear more than
once)
[Header Flags=DAT
Mode=BRO|UNR
Part=0,Of=1
Seen=1,Send=4,Size=500]--------------> (may appear more than
once)
[Header Flags=DAT
Mode=BRO|UNR
Part=0,Of=1
Seen=0,Send=5,Size=100]--------------> (may appear more than
once)
In the alternate multicast header filling in both above example Endpoint Z would detect the multicast transmit
to address as well as its lowest network address reset indicator in
the second multicast
from address.
Bundling datagram and fragmentation are not allowed in either multicast or
broadcast datagrams.
11.1 Multicast/Broadcast initialization.
No initiation adopt the new sequence number which
is needed for an endpoint to transmit multicast or
broadcast datagrams. However, caution should be taken when
transmitting non-protocol datagrams (i.e., datagrams with no MDTP
protocol header) 1. Then, it would ignore the reset indicator in multicast or broadcast transmission. This is
because the non-protocol subsequent three
(3) datagrams may inadvertently force all the
receiving endpoints of the multicast or broadcast transmission into
raw mode (see 10).
11.2 Transmission of Broadcast Datagrams.
When sending since they arrived within a broadcast datagram, the endpoint will not take effort
to prevent duplicate transmissions (this is likely very short time interval.
13. Interface with upper level protocols
The upper level protocols (ULP) shall request for services by passing
primitives to occur
especially when multiple networks exist). MDTP and shall receive notifications from MDTP for
various events.
The application at the
receiving end must primitives and notifications described in this section should be prepared to handle duplicate
broadcast messages.
Stewart & Xie [Page 34] 51]
Internet Draft Multi-network Datagram Transmission Protocol Feb Apr 1999
used as a guideline for implementing MDTP.
13.1 Init.MDTP primitive
This primitive allows MDTP to initialize its internal data structures
and allocate necessary resources for setting up its operation
environment. Note that once MDTP is initialized, ULP can communicate
directly with any other endpoints without re-invoking this primitive.
Mandatory attributes:
None.
Optional attributes:
The following is an example types of broadcast datagram transmission:
Endpoint A Endpoint Z
{application sends 2 messages }
[Header Flags=DAT
Mode=BRO
Part=0,Of=1
Seen=0,Send=0,Size=200]--------------> (Datagram attributes may appear
more than once.)
[Header Flags=DAT
Mode=BRO
Part=0,Of=1
Seen=0,Send=0,Size=100]-------------->
Notice that no timers are used on either end, and Seen and Send values
in the datagrams are always '0'.
11.3 Transmission of Multicast Datagrams.
Unlike the broadcast transmission, when multicast datagrams are
transmitted be passed along with
the receiving endpoints should take effort primitive:
o Timer selection and its operation syntax -- to prevent
duplicate copies of datagrams from being distributed indicate to their
applications.
This is possible because MDTP
an alternative timer the transmission of multicast datagrams is
usually addressed to a special multicast network address. The receiving
endpoints can thus MDTP should use this multicast address in combination with the
sender's address to detect duplicate transmissions of a multicast
datagram.
The following example illustrates multicast transmissions between two
endpoints.
Endpoint A Endpoint Z
{app multicasts a message}
[Header Flags=DAT
Mode=BRO|UNR
Part=0,Of=1
Seen=0,Send=5,Size=250]--------------> (may receive more
than one copy)
..
{app multicasts a message}
[Header Flags=DAT
Mode=BRO|UNR
Part=0,Of=1
Seen=0,Send=6,Size=500]--------------> (may receive more
than one copy)
Notice for its operation.
o Initial MDTP operation mode;
o IP port number, if ULP wants it to be specified;
13.2 Send.Data primitive
This is the values main method to send datagrams via MDTP.
Mandatory attributes:
o data - This is the payload ULP wants to transmit;
o size - The size of the Send field payload in the multicast datagrams (which
Stewart & Xie [Page 35]
Internet Draft Multi-network Datagram Transmission Protocol Feb 1999
are 5 number of octets;
o to-address - The IP address and 6, respectively). They represent port number of the sequence numbers intended
receiver. In case of redundant networks, to-address can be any one
of the
multicast datagrams Endpoint A has sent out. Endpoint Z should use multiple IP addresses of the
Send value found in receiver. The network which the incoming multicast datagrams to detect any
missing or duplicate datagrams.
Duplicate datagrams
datagram will actually be discarded and no effort sent through will be made determined by MDTP due
to
retransmit lost multicast datagrams.
For example, each endpoint can track the last 32 datagrams received by
using a sliding window of 32 bits. Each time a new datagram with a
sequence number higher than link rotation, unless the current window head is received, mode prohibits MDTP link
rotation; in such case the
window can be moved up. If a datagram received has will be sent through the network
specified by to-address (see section 4.5).
Optional attributes:
o mode-flags - This indicates a sequence number
below new MDTP operation mode, taking effect
immediately including the current window head, then a check datagram send;
o context - optional information that will be carried in the
Send.Failure notification to the ULP if the transportation of
this datagram fails.
13.3 Receive.Data primitive
This primitive shall return the last 32 received
datagrams' sequence numbers can determine first datagram in the MDTP in-queue to
ULP, if there is one available. It may, depending on the specific
implementation, also return other informations such as the sender's
Stewart & Xie [Page 52]
Internet Draft Multi-network Datagram Transmission Protocol Apr 1999
address, whether the new datagram there are more datagrams available for retrieval,
etc. The behavior is a
duplicate. If the sequence number of the new undefined if no datagram is below available when this
primitive is invoked.
Mandatory attributes:
o buffer - the
current window tail then memory location indicated by the ULP to store the
received datagram should be considered a duplicate and discarded.
11.4 Reset of the Multicast Datagram Sequence Number
If other information.
Optional attributes:
None.
13.4 Data.Arrive notification
MDTP shall invoke this notification on the Seen field in ULP when a multicast datagram is set to '1', it is an
indication that the sender has reset its multicast
successfully received and ready for retrieval.
13.5 Send.Failure notification
If a datagram sequence
number. The receiving endpoint, upon detecting can not be delivered MDTP shall invoke this reset indicator in
the incoming multicast datagram, should start a procedure to adopt notification
on the
new sequence number for error detection. However, caution
should ULP.
The following may be taken to prevent false resets due to duplicated datagrams optionally passed with reset indicator propagating through multiple networks.
To guarantee that all receivers of the multicast group adopt notification:
o data - the new
sequence number, location ULP can find the reset indicator should un-delivered datagram.
o context - optional information associated with this datagram (see
13.2).
13.5 Link.Status.Change notification
When a link is marked down (e.g., when MDTP detects a link failure),
or marked up (r.g., when MDTP detects a link recovery), MDTP shall
invoke this notification on the ULP.
The following shall be repeated within passed with the
first N multicast datagrams sent out after notification:
o link-address - This indicates the reset. N is predefined
by IP address of the protocol parameter Num.Of.Mcast.Reset.Msg.
At affected link;
o new-status - This indicates the receiving endpoint, when new status of the reset indicator is detected link;
13.6 Communication.Lost notification
When MDTP loses communication to an endpoint completely or detects
that the
new sequence number will be adopted. However, if two reset events are
detected within endpoint has performed a predefined time interval (Min.Mcast.Time.To.Reset), shut-down operation, it shall invoke
this notification on the second reset indicator will be ignored. ULP.
The following is an example (assuming Num.Of.Mcast.Reset.Msg = 4):
Endpoint A Endpoint Z
[Header Flags=DAT
Mode=BRO|UNR
Part=0,Of=1
Seen=0,Send=17859,Size=300]---------->
{reset message sequence shall be passed with the notification:
o status - This indicates what type of event that has occurred;
o endpoint-id - The IP address and port number indicated}
[Header Flags=DAT
Mode=BRO|UNR
Part=0,Of=1
Seen=1,Send=1,Size=250]--------------> (record new sequence
number, datagram may
appear more than once)
[Header Flags=DAT
Mode=BRO|UNR
Part=0,Of=1
Seen=1,Send=2,Size=250]--------------> (may appear more than
once) to identify the
endpoint;
o packets-enqueue - The number and location of un-sent datagrams
still holding by MDTP;
Stewart & Xie [Page 36] 53]
Internet Draft Multi-network Datagram Transmission Protocol Feb Apr 1999
[Header Flags=DAT
Mode=BRO|UNR
Part=0,Of=1
Seen=1,Send=3,Size=500]--------------> (may appear more than
once)
[Header Flags=DAT
Mode=BRO|UNR
Part=0,Of=1
Seen=1,Send=4,Size=500]--------------> (may appear more than
once)
[Header Flags=DAT
Mode=BRO|UNR
Part=0,Of=1
Seen=0,Send=5,Size=100]--------------> (may appear more than
once)
In the above example Endpoint Z would detect the reset indicator in
the second multicast datagram and adopt
o last-acked - the new sequence number which
is 1. Then, it would ignore the reset indicator in last acked by that peer endpoint;
o last-sent - the subsequent three
(3) datagrams since they arrived within a very short time interval.
12. sequence number last sent to that peer endpoint;
14. Suggested timer and MTU values.
The following are suggested timer values for MDTP:
T1-init Timer - 160 ms
T2-receive Timer - 20 ms
T3-send Timer - 160 ms
T4-bundle Timer - 40 ms
T5-Heart Beat - 4000 ms
The following protocol parameters are recommended:
Min.Bundle - 1000 octets
Max.Bundle - 1432 octets
Max.Retransmit - 10 attempts
Max.Init.Retransmit - 8 attempts
Min.Mcast.Time.To.Reset - 5 seconds
Num.Of.Mcast.Reset.Msg - 5 messages
13. Further Study
Currently the
15. Acknowledgments
The authors are benchmarking and analyzing the MDTP
performance in a redundant distributed processing environment. Some of
the items which have been planned to investigate are:
A) Use random timers instead of fixed timers.
B) Change the way inbound flow control is transmitted back wish to the
sender.
C) Experiment on load-related variable timers on a per endpoint basis.
Stewart & Xie [Page 37]
Internet Draft Multi-network Datagram Transmission Protocol Feb 1999
14. thank Brian Wyld, Sankar A, Henry Houh, Gary
Lehecka, Ken Morneault, Lyndon Ong, and others for their very valuable
comments.
16. Author's Addresses
Randall R. Stewart Tel: +1-847-632-7438
Cellular Infrastructure Group EMail: stewrtrs@cig.mot.com
Motorola, Inc.
1475 W. Shure Drive, #2C-6
Arlington Heights, IL 60004
USA
Qiaobing Xie Tel: +1-847-632-3028
Cellular Infrastructure Group EMail: xieqb@cig.mot.com
Motorola, Inc.
1501 W. Shure Drive, #2309
Arlington Heights, IL 60004
USA
15.
Stewart & Xie [Page 54]
Internet Draft Multi-network Datagram Transmission Protocol Apr 1999
17. References
[1] Postel, J. (ed.), "Internet Protocol - DARPA Internet Program
Protocol Specification", RFC 791, USC/Information Sciences Institute,
September 1981.
[2] Postel, J., "User Datagram Protocol", RFC 768, USC/Information Sciences
Institute, August 1980.
[3] Postel, J. (ed.), "Transmission Control Protocol", RFC 793, USC/
Information Sciences Institute, September 1981.
This Internet Draft expires in 6 months from August 1998. April 1999.
Stewart & Xie [Page 38] 55]
----