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

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/