draft-ietf-sigtran-mdtp-00.txt   draft-ietf-sigtran-mdtp-01.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 1 Feburary 1999 Expires in six months 15 Feburary 1999
MULTI_NETWORK DATAGRAM TRANSMISSION PROTOCOL MULTI_NETWORK DATAGRAM TRANSMISSION PROTOCOL
<draft-ietf-sigtran-mdtp-00.txt> <draft-sigtran-mdtp-01.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 Internet-Drafts are draft documents valid for a maximum of six months
skipping to change at page 10, line ? skipping to change at page 10, line ?
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...................................5
1.3 Operation of MDTP....................................5 1.3 Operation of MDTP....................................5
2. Design Principles.........................................6 2. Design Principles.........................................6
3. Header Format.............................................6 3. Header Format.............................................7
3.1 MDTP Header Format Description.......................7
3.2 Notes on Multicast Header format....................10
4. Transmission Initialization..............................10 4. Transmission Initialization..............................10
4.1 Normal Initialization...............................10 4.1 Normal Initialization...............................10
4.2 Multiple Network Addresses..........................12 4.2 Multiple Network Addresses..........................12
4.3 Initialization Collision............................13 4.3 Initialization Collision............................13
4.4 Re-initialization...................................14 4.4 Re-initialization...................................14
4.5 Link rotation.......................................14
5. Reliable Transfer Mode...................................14 5. Reliable Transfer Mode...................................14
5.1 Timer Control.......................................16 5.1 Timer Control.......................................16
5.2 Gap Acknowledgments.................................19 5.2 Gap Acknowledgments.................................19
5.3 Congestion Control..................................21 5.3 Congestion Control..................................21
5.4 Sequence Number Reset...............................24 5.4 Sequence Number Reset...............................24
5.5 Retransmission on Multiple Networks.................25 5.5 Retransmission on Multiple Networks.................25
5.5.1 Randomization of the T3-Send timer at resend ...25 5.5.1 Randomization of the T3-Send timer at resend ...25
5.6 Termination of an Endpoint..........................26 5.6 Termination of an Endpoint..........................26
5.7 Endpoint Drain......................................26 5.7 Endpoint Drain......................................26
5.8 Advisory Acknowledgements...........................26 5.8 Advisory Acknowledgements...........................26
5.9 RTT Measurement.....................................26
5.10 Heart Beat Ack.....................................26
6. Unreliable Transfer Mode.................................27 6. Unreliable Transfer Mode.................................27
6.1 Ordered receiption..................................28 6.1 Ordered receiption..................................28
7. Mixed Mode Data Transmission.............................28 7. Mixed Mode Data Transmission.............................28
8. Bundled Messages.........................................29 8. Bundled Messages.........................................29
8.1 Format of Bundled Datagram..........................30 8.1 Format of Bundled Datagram..........................30
8.2 Bundled Transfer....................................31 8.2 Bundled Transfer....................................31
9. Fragmented Messages......................................32 9. Fragmented Messages......................................32
10. Non-protocol Datagrams...................................33 10. Non-protocol Datagrams...................................33
11. Broadcast and Multicast..................................34 11. Broadcast and Multicast..................................34
11.1 Multicast/Broadcast Initialization.................34 11.1 Multicast/Broadcast Initialization.................34
skipping to change at page 10, line ? skipping to change at page 10, line ?
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] Stewart & Xie [Page 6]
MDTP Header Format 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 /
\ \ \ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
MDTP Header Format MDTP Header Format - Multicast Format
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MDTP Protocol Identifier 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MDTP Protocol Identifier 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Acknowledgment Number (Seen) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number (Send) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Size | Part | Of |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Mode | Version | In Queue |
|N N W I F R D A|B S W R R B G U| | |
|O O I S I E A C|R H N E E U A N| | |
|G B N B R S T K|O U R 1 2 N R R| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Multicast To Transmit address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Multicast From - senders base address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ data /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
MDTP Header Format - RTT Ack
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MDTP Protocol Identifier 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MDTP Protocol Identifier 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Acknowledgment Number (Seen) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number (Send) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Size | Part | Of |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Mode | Version | In Queue |
|N N W I F R D A|B S W R R B G U| | |
|O O I S I E A C|R H N E E U A N| | |
|G B N B R S T K|O U R 1 2 N R R| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Transparent Time Int-1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Transparent Time Int-2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3.1 MDTP Header Format Description
MDTP Protocol Identifier 1: 32 bits 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 ?
to '255'. For broadcast and multicast datagrams this value is to '255'. For broadcast and multicast datagrams this value is
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 only in negotiation NOG - No Guaranteed delivery. This bit is used in negotiation
and will be 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
bit should be set to 0, except when responding to a RTT Ack
request.
NOB - No Bundling. This bit is used only 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 (after the initiate sequence) this
bit should be set to 0, except when sending a Heart Beat Ack
at which time this bit must be set to 1.
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
skipping to change at page 10, line ? skipping to change at page 10, line ?
reciever that the sender is requesting a advisitory ACK. This reciever that the sender is requesting a advisitory 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 advisitory 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 reciever
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 is reservered and should always be set to 0 in RE2 - This bit will represent one of two things. If the GAR
transmission. 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
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,
then this datagram is used in a implementation specific way but
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 acknowledgement. This bit should never be set if
either endpoint set the NOG flag during negotiation. either endpoint set the NOG flag during negotiation.
skipping to change at page 10, line ? skipping to change at page 10, line ?
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.
The header format is identical to the standard MDTP header format has
discussed above but adds the following extensions.
Multicast To Transmit address - This is the address, in network byte
order, that the sender transmited the data to. Since a receiver does
not know what address the sender was sending to, the receiver can
use this information for internal tracking purposes.
Multicast From - This is the base address (address 0 in the initiate
message) that is the sender. Since a multicast sender may not have
gone through the initiate procedures this address is the base
reference that the receiver is to use to lookup the sender. This
network byte order address should be used to reference any internal
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
an initialization process. an initialization process.
The initialization process consists of the following steps. The initialization process consists of the following steps.
skipping to change at page 13, line 26 skipping to change at page 13, line 26
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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
are at option to use additional data sent in subsequent locations for
implementation specific data exchanges. No user data, however, is allowed
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:
skipping to change at page 14, line 44 skipping to change at page 14, line 44
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.
4.5 Link Rotation
When multiple networks exist between two communicating endpoints,
every time the application transmits a datagram, the MDTP implementation
MUST keep track of which network the transmission was sent on (if
more than one network exists) in the MDTP protcol variable
'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
be updated to indicate which interface was used last. The MDTP
implementation should consider the rules defined in
"5.5 Retransmission on Multiple Networks" to consider if
a network is "available"
The MDTP implementation MUST allow a user to override this rotation
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.
skipping to change at page 23, line 46 skipping to change at page 23, line 46
----------------------------------------------------------------------- -----------------------------------------------------------------------
Greater than 0 datagrams lost | Adjust down by 1 Greater than 0 datagrams lost | Adjust down by 1
----------------------------------------------------------------------- -----------------------------------------------------------------------
Timeout forces retransmission | Adjust down by 1 Timeout forces retransmission | Adjust down by 1
----------------------------------------------------------------------- -----------------------------------------------------------------------
Window Up sent | Adjust down by 1 Window Up sent | Adjust down by 1
----------------------------------------------------------------------- -----------------------------------------------------------------------
4 or more consecutive datagrams | Adjust up by 1 4 or more consecutive datagrams | Adjust up by 1
acknowledged (window length > 4) | acknowledged (window length > 4) |
----------------------------------------------------------------------- -----------------------------------------------------------------------
Window length or more acked | Adjust up by 1 1/2 Window length or more acked | Adjust up by 1
(window length <=4) | (window length <=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.
skipping to change at page 24, line 36 skipping to change at page 24, line 36
1) sending a Window Up message to force the peer to acknowledge all 1) sending a Window Up message to force the peer to acknowledge all
received datagrams which have not been acknowledged, and received datagrams which have not been acknowledged, and
2) sending the next datagram with RES bit set in the Flags field. 2) sending the next datagram with RES bit set in the Flags field.
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
after reaching 0x7ff05ff.
Note: This section will be obsoleted in a future version of the
draft and be replaced by a deterministic rollover 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
Part=0,Of=1 Part=0,Of=1
skipping to change at page 27, line 50 skipping to change at page 27, line 50
Part=0,Of=1 Part=0,Of=1
Seen=1,Send=201,Size=100]-----------> Seen=1,Send=201,Size=100]----------->
(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
On occasion either end may wish to do a Round Trip Time measurment of
a network. There are two methods of measuring Round Trip Time.
Method 1 envolves a pingpong using a special ACK, Method 2 envolves
a rider on top of a datagram. If Method 2 is invoked then the Round
Trip Time includes the T2-Receive timer (this actually may be more
useful then pure RTT time since each endpoint may have a different
T2-Receive timer value).
Method 1:
When a endpoint wishes a RTT measurement it shall send a
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 time of
day in seconds/microseconds.
Upon receipt of a datagram with RE2 set to 1, GAR set to 1 and DAT set to
0, the recepient should return the datagram to the sender over 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.
Endpoint A Endpoint Z
RTT - Request Now=x.y
[Header Flags=ACK
Mode=GAR|RE2
Part=0,Of=1
Seen=1,Send=301,Size=0
Time-Int1=x
Time-Int2=y]------------->
<---------------------------- [Header Flags=ACK|NOG
Mode=0
Part=0,Of=0
Seen=301,Send=1
Time-Int1=x
Time-Int2=y]
Endpoint A uses
current time subtracted from
X.y (in arriving Datagram) to
calculate the RTT.
Method 2:
If a endpoint wishes to piggyback a RTT test including the T2-Timer at
the remote endpoint the sending endpoint fills out the datagram in the
normal way for reliable communication but also sets the RE2 flag, and
places at the end of the datagram (outside the length of the data) two
long integers has a trailer.
When the receiving endpoint recognizes the RE2 flag, it should extract
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
T2-Recv timer). If the The T2-Recv timer expires the receiving
endpoint should send the acknowledgement as above with the addition
of the NOB flag as well. If the receiving endpoints upper layer sends
a datagram causing the T2-Recv timer to be canceled then the datagram
should include the Trailing integers and have the NOB flag set.
In cases where a intervening Window UP is received the receiving endpoint
should respond with a window Up Response (per the window up procedure)
but NOT cancel its T2-Recv timer.
Example 1 - T2-Recv timer expires
Endpoint A Endpoint Z
RTT - Request Now=x.y
[Header Flags=ACK|DAT
Mode=GAR|RE2
Part=0,Of=1
Seen=1,Send=301,Size=100
{data of 100 octets}
Time-Int1=x
Time-Int2=y]-------------> (started T2-Recv)
{T2-Recv Expires }
<---------------------------- [Header Flags=ACK|NOG|NOB
Mode=0
Part=0,Of=0
Seen=301,Send=1
Time-Int1=x
Time-Int2=y]
Example 2 - Datagram causes T2-Recv timer cancel
Endpoint A Endpoint Z
RTT - Request Now=x.y
[Header Flags=ACK|DAT
Mode=GAR|RE2
Part=0,Of=1
Seen=1,Send=301,Size=100
{data of 100 octets}
Time-Int1=x
Time-Int2=y]-------------> (started T2-Recv)
{datagram sent by application}
(cancel T2-Recv)
<---------------------------- [Header Flags=DAT|ACK|NOG
Mode=GAR
Part=0,Of=1,Size=100
Seen=401,Send=1
{data of 100 octets}
Time-Int1=x
Time-Int2=y]
5.10 Heart Beat Ack
At request by the application, the user may wish a Heart Beat acknowledgement
sent. The Heart Beat should only be allowed to be enabled if the senders
Mod is Gar (reliable delivery). Once enabled when no datagrams are being
transmitted, a T5-Heart Beat timer should be started. When the
T5 timer expires a ACK should be sent using the next available link, following
the link rotation procedure outlined in "4.5 Link Rotation". After sending
the Ack another T5-Heart Beat timer should be started. If, before the
expiration of T5-Heart Beat, a datagram is transmitted or recieved, the
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 identical to that of
a standard ACK with the exception that the NOB bit should be set. The reciever
should use the case of the NOB bit being set to NOT calculate any changes
to its sending window, but still treat the value has a ACK freeing up
window space if applicable.
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.
Endpoint A Endpoint Z Endpoint A Endpoint Z
skipping to change at page 34, line 29 skipping to change at page 34, line 29
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
the number of multicast datagrams transmitted by the sender. This the number of multicast datagrams transmitted by the sender. This
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. multicast datagrams. A multicast datagram transmission MUST use
the alternate multicast header filling in both the multicast transmit
to address as well as its lowest network address in the multicast
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. 11.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
skipping to change at page 37, line 34 skipping to change at page 37, line 34
(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. 12. 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
The following protocol parameters are recommended: The following protocol parameters are recommended:
Min.Bundle - 1792 octets Min.Bundle - 1000 octets
Max.Bundle - 4096 octets Max.Bundle - 1432 octets
Max.Retransmit - 10 attempts Max.Retransmit - 10 attempts
Max.Init.Retransmit - 10 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 13. Further Study
Currently the authors are benchmarking and analyzing the MDTP Currently the authors are benchmarking and analyzing the MDTP
performance in a redundant distributed processing environment. Some of performance in a redundant distributed processing environment. Some of
the items which have been planned to investigate are: the items which have been planned to investigate are:
A) Use random timers instead of fixed timers. A) Use random timers instead of fixed timers.
 End of changes. 

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