draft-ietf-sigtran-mdtp-05.txt   draft-ietf-sigtran-mdtp-06.txt 
Network Working Group R. R. Stewart Network Working Group R. R. Stewart
INTERNET-DRAFT Q. Xie INTERNET-DRAFT Q. Xie
Motorola Motorola
S. Hussain K. Morneau
C. Sharp C. Sharp
Cisco Cisco
H. J. Schwarzbauer H. J. Schwarzbauer
Siemens Siemens
T. Taylor T. Taylor
Nortel Networks Nortel Networks
I. Rytina I. Rytina
Ericsson Ericsson
expires in six months June 2, 1999 expires in six months June 25,1999
MULTI_NETWORK DATAGRAM TRANSMISSION PROTOCOL MULTI_NETWORK DATAGRAM TRANSMISSION PROTOCOL
<draft-ietf-sigtran-mdtp-05.txt> <draft-ietf-sigtran-mdtp-06.txt>
Status of This Memo Status of This Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. Internet-Drafts are working 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.
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
skipping to change at page 10, line ? skipping to change at page 10, line ?
1. Introduction.......................................................3 1. Introduction.......................................................3
1.1 Terminology......................................................3 1.1 Terminology......................................................3
1.2 Design Requirements of MDTP......................................4 1.2 Design Requirements of MDTP......................................4
1.3 Interface to MDTP................................................5 1.3 Interface to MDTP................................................5
2. MDTP Datagram Format...............................................5 2. MDTP Datagram Format...............................................5
2.1 MDTP Common Header Field Descriptions............................6 2.1 MDTP Common Header Field Descriptions............................6
2.2 MDTP Control Parameter Part Definitions..........................7 2.2 MDTP Control Parameter Part Definitions..........................7
2.3 MDTP Data Part Definitions......................................11 2.3 MDTP Data Part Definitions......................................11
3. Endpoint Association Initialization...............................12 3. Endpoint Association Initialization...............................12
3.1 Initiation Message and Tag Lock.................................12 3.1 Initiation Message and Tag Lock.................................12
3.1.1 Passing Initiation Parameters ................................12
3.2 Tag Unlock and TSN Initialization...............................13 3.2 Tag Unlock and TSN Initialization...............................13
3.3 Datagram Processing during Tag Lock ............................14 3.3 Datagram Processing during Tag Lock ............................14
3.4 An Example of Association Initialization .......................14 3.4 An Example of Association Initialization .......................14
3.5 Other Initiation Issues.........................................15 3.5 Other Initiation Issues.........................................15
3.5.1 Selection of Tag Value......................................15 3.5.1 Selection of Tag Value......................................15
3.5.2 Initiation from behind a NAT................................15 3.5.2 Initiation from behind a NAT................................15
3.5.3 Initialization Collision....................................16 3.5.3 Initialization Collision....................................16
3.5.4 Association Re-initialization...............................16 3.5.4 Association Re-initialization...............................16
4. Transfer User Datagram............................................16 4. Transfer User Datagram............................................16
4.1 Timer Management Rules..........................................17 4.1 Timer Management Rules..........................................17
4.1.1 T3-send Timer Adjustment with RTT...........................18 4.1.1 T3-send Timer Adjustment with RTT...........................18
4.2 Multihoming Rotation............................................18 4.2 Multihoming Rotation............................................18
4.2.1 Remote Multihoming Rotation.................................18 4.2.1 Remote Multihoming Rotation.................................18
4.2.2 Local Multihoming Rotation..................................19 4.2.2 Local Multihoming Rotation..................................19
4.3 Stream Sequence Number..........................................19 4.3 Stream Sequence Number..........................................19
4.4 Ordered and Un-ordered Delivery.................................19 4.4 Ordered and Un-ordered Delivery.................................19
4.5 Report Missing Datagrams........................................20 4.5 Report Missing Datagrams........................................20
4.6 Range Check on TSN .............................................21 4.6 Range Check on TSN .............................................21
4.7 Advisory Ack Request............................................21 4.7 Advisory Ack Request............................................21
4.8 CRC utilization.................................................21
5 Congestion Controls...............................................22 5 Congestion Controls...............................................22
5.1 Send with Window Control........................................22 5.1 Send with Window Control........................................22
5.1.1 Window Length Adjustment....................................23 5.1.1 Window Length Adjustment....................................23
5.2 Send Timer Back-off at Re-transmission..........................24 5.2 Send Timer Back-off at Re-transmission..........................24
6. Network Management................................................25 6. Network Management................................................25
6.1 Failure Detection in Redundant Networks.........................25 6.1 Failure Detection in Redundant Networks.........................25
6.2 RTT Measurement.................................................26 6.2 RTT Measurement.................................................26
6.3 Network Heart Beat .............................................26 6.3 Network Heart Beat .............................................26
7. Termination of Association........................................27 7. Termination of Association........................................27
7.1 Graceful Shutdown of an Association.............................28 7.1 Graceful Shutdown of an Association.............................28
8. Stream Operations.................................................29 8. Stream Operations.................................................29
8.1 Stream Initiation...............................................29 8.1 Stream Initiation...............................................29
8.2 Stream Termination..............................................29 8.2 Stream Termination..............................................29
8.3 Other Issues with Stream Operations.............................30 8.3 Other Issues with Stream Operations.............................30
9. Interface with Upper Layer........................................30 9. Interface with Upper Layer........................................30
10. Suggested MDTP Timer and Protocol Parameter Values................34 10. Suggested MDTP Timer and Protocol Parameter Values................34
11. Acknowledgments...................................................34 11. Abbreviations.....................................................34
12. Authors' Addresses................................................34 12. Acknowledgments...................................................34
13. References........................................................35 13. Authors' Addresses................................................34
14. References........................................................35
Stewart, et al [Page 2] Stewart, et al [Page 2]
1. Introduction 1. Introduction
This Internet Draft discusses a new protocol, namely the Multi-network This Internet Draft discusses a new protocol, namely the Multi-network
Datagram Transmission Protocol (MDTP). The intention of developing Datagram Transmission Protocol (MDTP). The intention of developing
MDTP is to provide a fault-tolerant, real-time reliable data transfer MDTP is to provide a fault-tolerant, real-time reliable data transfer
mechanism between communicating endpoints over IP networks [1]. mechanism between communicating endpoints over IP networks [1].
skipping to change at page 10, line ? skipping to change at page 10, line ?
protocol are reused in MDTP, and some of the advantages of UDP are protocol are reused in MDTP, and some of the advantages of UDP are
also merged into the design. also merged into the design.
1.1 Terminology 1.1 Terminology
The following terms are defined and used in this document: The following terms are defined and used in this document:
- Redundant networks: - Redundant networks:
An endpoint may be able to transmit or receive on more than one IP An endpoint may be able to transmit or receive on more than one IP
address/UDP port. RFC 1122 refers to this as multihoming. This address/UDP port. RFC 1122 refers to this as multi-homing. This
constitutes a redundant local network (for MDTP) relative to the constitutes a redundant local network (for MDTP) relative to the
endpoint. MDTP makes no attempt to assure routing diversity within endpoint. MDTP makes no attempt to assure routing diversity within
the internet connecting two endpoints. Each endpoint attempts to the Internet connecting two endpoints. Each endpoint attempts to
send to its peer endpoint using all the IP addresses and UDP ports send to its peer endpoint using all the IP addresses and UDP ports
its peer has open (within the constraints of any application its peer has open (within the constraints of any application
specified restrictions). The choice of which local socket to send specified restrictions). The choice of which local socket to send
upon is an implementation detail (it is possible only one socket is upon is an implementation detail (it is possible only one socket is
available and bound to all of the local networks to which the machine is available and bound to all of the local networks to which the machine is
connected). The O/S also will play a role in the multihoming/redundancy. connected). The O/S also will play a role in the multi-homing/redundancy.
MDTP attempts a best effort at spreading the traffic across a MDTP attempts a best effort at spreading the traffic across a
Stewart, et al [Page 3] Stewart, et al [Page 3]
destination's available interfaces. It is assumed by MDTP that the destination's available interfaces. It is assumed by MDTP that the
network (if fault tolerance is desired) is engineered for diversity network (if fault tolerance is desired) is engineered for diversity
and MDTP's best effort will play only a small role in that diversity. and MDTP's best effort will play only a small role in that diversity.
- Endpoint: - Endpoint:
Representation of the logical point where MDTP datagrams can be sent Representation of the logical point where MDTP datagrams can be sent
to or received from. Moreover, an MDTP endpoint shall be defined as to or received from. Moreover, an MDTP endpoint shall be defined as
a set of IP address/port combinations in order to support redundant a set of IP address/port combinations in order to support redundant
networks. For example, an endpoint on a multi-homed host connected networks. For example, an endpoint on a multi-homed host connected
with N IP networks can be represented as: with N IP networks can be represented as:
[IP addr1/port1, [IP addr1/port1,
... ...
IP addrN/portN] IP addrN/portN]
where the port numbers or IP addresses may not be unique, but their where the port numbers or IP addresses may not be unique, but their
combinations shall be guaranteed to be unique by the underneath IP combinations shall be guaranteed unique by the underneath IP
networks. networks.
- Association: - Association:
Representation of an ongoing communication channel between two MDTP Representation of an ongoing logical communication channel between
endpoints. two MDTP endpoints.
- Sub-layering:
Conceptually MDTP is subdivided into two sub-layers, as shown below:
+--------------------------+
| Sequencing Sub-layer |
+--------------------------+
| Reliability Sub-layer |
+--------------------------+
This is introduced to achieve a clear separation between:
1) the reliable transport on a per association basis, and
2) the in-sequence delivery on a per stream basis to avoid blocking
between independent streams.
- Reliability Sub-layer:
This Sub-layer copes only with functions to guarantee the
delivery of a datagram at its peer. At this sub-layer there
is no subdivision into different streams.
- Transmission Sequence Number (TSN):
A TSN is assigned to every datagram sent that transports user
data. The TSN is used by the peer Reliability Sub-layer to detect any
missing or duplicate user data. The TSN is processed by the
Reliability Sub-layer only. Its value and presence is not known by
the Sequencing Sub-layer
- Sequencing Sub-layer
This sub-layer copes only with ordered delivery of datagrams
belonging to a certain stream. It is based on the fact that
the Reliability Sub-layer has ensured the guaranteed delivery
of datagrams.
- Stream: - Stream:
Defines a sub-channel within an association. Datagrams sent through Defined as a unidirectional logical sub-channel within an existing
a stream shall be reliably transmitted and delivered independent to association (see the example below).
datagrams from other streams.
Each stream shall be identified by a stream number that is unique Each stream shall be identified by a stream ID that is unique
within the association. Stream 0xffff is reserved and shall not be within the association and with regard to the endpoint that opens
used. the stream.
Endpoint "A" Endpoint "Z"
------- association -------
|===========================|
Stream ID | |
0 ----------------------------> |
1 ----------------------------> |
2 ----------------------------> |
| | Stream ID
| <---------------------------- 0
| <---------------------------- 1
| <---------------------------- 2
| <---------------------------- 3
| |
|===========================|
------- -------
Datagrams sent through a stream shall be reliably transmitted and
delivered independent to datagrams from other streams.
As an implementation consideration, both the sender and receiver
sides may need to dedicate resources, e.g., data queues, for each
existing stream.
- Stream Sequence Number (SSN):
A Stream Sequence Number is associated with every datagram
having a TSN. The SSN is valid only within the stream where the
datagram belongs to. The SSN is processed by the Sequencing
Sub-layer on a per stream basis.
Stream 0xffff is reserved and shall not be used. Stream 0x0 is
open per default upon initiating an association and is not to be
terminated.
- Sequence-number Attack:
As defined in RFC 1948 [10].
- CRC Usage Policy:
The minimum level of data integrity is provided using the checksum
mechanism of the underlying transport protocol. It is therefore
required that this mechanism is always enabled when transferring
MDTP datagrams.
In order to meet higher data integrity, as required for transporting
of certain SCN signaling protocols, an additional 16 bit CRC value
can optionally be carried in an MDTP datagram.
See ITU-T Recommendation Q.703 [11] for details of how to calculate
a 16 bit CRC.
1.2 Design Requirements of MDTP 1.2 Design Requirements of MDTP
The following are some of the design requirements of MDTP to The following are some of the design requirements of MDTP to
make MDTP capable of supporting real-time call control environments make MDTP capable of supporting real-time call control environments
that may employ redundant networks: that may employ redundant networks:
A) High communication fan-out: an endpoint may need to be in A) High communication fan-out: an endpoint may need to be in
simultaneous communication with hundreds or thousands of endpoints simultaneous communication with hundreds or thousands of endpoints
performing various call processing functions. These endpoints may performing various call processing functions. These endpoints may
skipping to change at page 10, line ? skipping to change at page 10, line ?
B) Stringent timer control: an endpoint needs to have a very fine B) Stringent timer control: an endpoint needs to have a very fine
control over the timing for delivering a datagram. The timing control over the timing for delivering a datagram. The timing
should be easily adjusted depending on the message type and the should be easily adjusted depending on the message type and the
destination. For example, after a few seconds of non-delivery the destination. For example, after a few seconds of non-delivery the
call which the message is about may not exist anymore. call which the message is about may not exist anymore.
Stewart, et al [Page 4] Stewart, et al [Page 4]
C) Support multiple network paths: an endpoint communicating with a peer C) Support multiple network paths: an endpoint communicating with a peer
should be able to take advantage of the multiple network paths and should be able to take advantage of the multiple network paths and
multihoming in a transparent way. Therefore, the protocol must multi-homing in a transparent way. Therefore, the protocol must
be able to take advantage of local multi-homed hosts and remote be able to take advantage of local multi-homed hosts and remote
multi-homed hosts to provide resilient data delivery. This means multi-homed hosts to provide resilient data delivery. This means
that the application or upper layer protocols need not to be involved that the application or upper layer protocols need not to be involved
in the network fault management. Instead, when network failure occurs in the network fault management. Instead, when network failure occurs
MDTP should be able to automatically transmit out-bound datagrams to an MDTP should be able to automatically transmit out-bound datagrams to an
alternate destination network interface (if one exists) without alternate destination network interface (if one exists) without
intervention from the application. intervention from the application.
D) Reliable transport: datagrams might be lost or discarded while D) Reliable transport: datagrams might be lost or discarded while
traveling in the IP network towards the destination. The protocol traveling in the IP network towards the destination. The protocol
must handle the re-transmission of lost messages in an autonomous must handle the re-transmission of lost messages in an autonomous
way without any intervention from the upper layer. Also, sometimes way without any intervention from the upper layer. Also, sometimes
datagrams may arrive in duplicate copies, in such cases MDTP must datagrams may arrive in duplicate copies, in such cases MDTP must
be able to detect and remove the duplicates automatically. be able to detect and remove the duplicates automatically.
E) Support both ordered and un-ordered delivery: MDTP must support E) Support both ordered and unordered delivery: MDTP must support
both ordered and un-ordered delivery. In the case of ordered both ordered and unordered delivery. In the case of ordered
delivery, the receiver shall detect out-of-order datagrams and delivery, the receiver shall detect out-of-order datagrams and
re-order them before dispatching them to the upper layer. In the re-order them before dispatching them to the upper layer. In the
un-ordered case, received datagrams shall be dispatched without any unordered case, received datagrams shall be dispatched without any
effort of re-ordering. effort of re-ordering.
F) Support stream sequencing: on the demand of the upper layer F) Support stream sequencing: on the demand of the upper layer
protocols or applications, MDTP should be able to support sequenced protocols or applications, MDTP should be able to support sequenced
delivery with regard to each individual stream, i.e., the delay caused delivery with regard to each individual stream, i.e., the delay caused
by the loss and retransmission of a datagram should be isolated to by the loss and retransmission of a datagram should be isolated to
only the stream to which the datagram belongs. This is particularly only the stream to which the datagram belongs. This is particularly
important in some call control applications, where a loss of a important in some call control applications, where a loss of a
message should only affect the call whom the message belongs to. message should only affect the call whom the message belongs to.
skipping to change at page 10, line ? skipping to change at page 10, line ?
A MDTP datagram consists of a common header and possibly a control A MDTP datagram consists of a common header and possibly a control
parameter part, a data part, or both. parameter part, a data part, or both.
Stewart, et al [Page 5] Stewart, et al [Page 5]
MDTP Datagram Format MDTP Datagram 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 | Vers | | CRC-16/MDTP Protocol Identifier | Vers |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|C/D| Msg Type | Reserved | Data Size | | Msg Type | Reserved |C| Data Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \ \ \
/ Control Parameter Part / / Control Parameter Part /
\ \ \ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \ \ \
/ Data Part / / Data Part /
\ \ \ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Note: integers in the header of MDTP datagrams MUST be transmitted in Note: Message Type and Data Size in the common header MUST be
network byte-order. transmitted in network byte-order.
Note: when both the control part and data part are present in an MDTP Note: when both the control part and data part are present in an MDTP
datagram, the control part MUST be processed first. datagram, the control part MUST be processed first.
2.1 MDTP Common Header Field Descriptions 2.1 MDTP Common Header Field Descriptions
MDTP Protocol Identifier: 28 bits CRC-16/MDTP Protocol Identifier: 28 bits
This shall be a fixed value of 0xf787307. The receiver shall When the C Bit is NOT set, this field shall contain the 28 bit
always verify this Protocol Identifier before it proceeds any MDTP Protocol Identifier with a fixed value of 0xf787307. The
further in interpreting the header fields. receiver shall verify this Protocol Identifier before it
consider the received datagram is a valid MDTP datagram.
When the C Bit is set, the most significant 16 bits of this
field shall contain a CRC-16 value, and the other 12 bits shall
be filled with '0' by the sender and ignored by the receiver, as
illustrated below:
0 1 2
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CRC-16 |0 0 0 0 0 0 0 0 0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Version: 4 bits Version: 4 bits
This field represents the version number of the MDTP protocol, This field represents the version number of the MDTP protocol,
and shall be set to 0x3. and shall be set to 0x3.
C/D Bits: 2 bits Message Type: 8 bits
This field indicates whether the Message Type and Data Size fields
are filled in the present datagram:
00 - reserved, shall not be used. The receiver shall silently
discard any datagram with C/D bits set to 00.
01 - Data Size only
10 - Message Type only
11 - Message Type and Data Size
Message Type: 6 bits
This shall indicate the type of control message. Its value is valid When the value is non-zero, this shall indicate the type of
only when the C/D bits are set to either "10" or "11". Otherwise it control message present in the current MDTP datagram. A value of
0x0 indicates the control part is NOT present in the current
datagram.
Stewart, et al [Page 6] Stewart, et al [Page 6]
shall be set to 0x0 and ignored by the receiver.
Message Type determines whether the control part is present in
the current datagram.
The value of Message Type is defined as the follows: The value of Message Type is defined as the follows:
0x0 - reserved and shall not be used 0x0 - indicating control part is NOT present
0x1 - Initiation 0x1 - Initiation
0x2 - Initiation Ack 0x2 - Initiation Ack
0x3 - Extended Data Ack 0x3 - Extended Data Ack
0x4 - Advisory Ack Request 0x4 - Advisory Ack Request
0x5 - Window-up 0x5 - Window-up
0x6 - Window-up Ack 0x6 - Window-up Ack
0x7 - RTT-request 0x7 - RTT-request
0x8 - RTT-ack 0x8 - RTT-ack
0x9 - Abort 0x9 - Abort
0xa - Graceful Shutdown 0xa - Graceful Shutdown
0xb - Graceful Shutdown Ack 0xb - Graceful Shutdown Ack
0xc - Stream Initiation 0xc - Stream Initiation
0xd - Stream Initiation Ack 0xd - Stream Initiation Ack
0x10 - Stream Initiation Nack
0xe - Stream Termination 0xe - Stream Termination
0xf - Stream Termination Ack 0xf - Stream Termination Ack
0x10 to 0x3f - reserved and shall not be used 0x11 to 0xff - reserved and MUST NOT be used
Reserved: 8 bits Reserved: 7 bits
These bits are reserved for future use. The sender shall always These bits are reserved for future use. The sender shall always
set these bits to '0', and the receiver shall ignore there set these bits to '0', and the receiver shall ignore there
values. values.
C Bit: 1 bit
The CRC flag to indicate whether a CRC-16 value or the MDTP
protocol identifier is present in the header, as described
above.
Data Size: 16 bits Data Size: 16 bits
This value represents, in number of octets, the size of the user This value represents, in number of octets, the size of the user
data present in the Data Part of the current datagram. Its value data present in the Data Part of the current datagram. If the
is only valid when C/D bits are set to either "01" or "11". Data Part is not present in the current datagram, it MUST be set
Otherwise it shall be set to 0x0 and ignored by the receiver. to 0x0. This implies that no Data Part with zero size user data
shall be allowed.
2.2 MDTP Control Parameter Part Definitions 2.2 MDTP Control Parameter Part Definitions
This section defines whether a control parameter part is present for This section defines whether a control parameter part is present for
each message type, and its format if a control parameter part is each message type, and its format if a control parameter part is
present. present.
Note: integers in the control parameter part MUST be transmitted in
network byte-order.
2.2.1 Initiation (0x1) and Initiation Ack (0x2): 2.2.1 Initiation (0x1) and Initiation Ack (0x2):
The parameter field of the Initiation and Initiation Ack messages The parameter field of the Initiation and Initiation Ack messages
shall carry two initiation Tags, the maximum window length and the shall carry two initiation Tags, the maximal window length of the
sender's local network information. Note that the endpoint MAY sender, the sender's T2-Receive timer value in microseconds, the
be multi-homed. number of pre-open outbound streams (P), the number of maximal
inbound streams (M), and the sender's local network
information. The network information informs the receiver the
addresses that may be the source of datagrams for this association
and are valid addresses that the receiver can use as a destination
address. Note that the endpoint MAY be multi-homed.
Stewart, et al [Page 7] Stewart, et al [Page 7]
The following defines the parameter format for carrying N IPv4 The following defines the parameter format for carrying N IPv4
Network addresses (other network address formats can be carried by Network addresses (other network address formats can be carried by
setting the size and type fields accordingly): setting the size and type fields accordingly):
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag Value 1 (Seen) | | Tag Value 1 (Seen) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag Value 2 (Send) | | Tag Value 2 (Send) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Max Window Length | | Max Window Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| My T2-Recv Timer value in microseconds |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of Pre-open Streams (P) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of Max Streams (M) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of Networks = N | | Number of Networks = N |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Size of address=8 | Type of Address=2 | | Size of address=8 | Type of Address=2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP Address of Network 1 | | IP Address of Network 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Port # 1 | Padding = 0 | | Port # 1 | Padding = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ / / /
\ ... \ \ ... \
skipping to change at page 10, line ? skipping to change at page 10, line ?
If there is any implementation-specific data needed to be If there is any implementation-specific data needed to be
exchanged at the setup of the association, it should be appended exchanged at the setup of the association, it should be appended
to the end of the above data structure. The format of the to the end of the above data structure. The format of the
implementation-specific data should follow "Size/Type/Data Field" implementation-specific data should follow "Size/Type/Data Field"
format as defined above. In case an endpoint does not support the format as defined above. In case an endpoint does not support the
implementation-specific data received, it shall ignore the implementation-specific data received, it shall ignore the
additional fields. additional fields.
2.2.2 Extended Data Ack (0x3): 2.2.2 Extended Data Ack (0x3):
The parameter field contains 0 or more gap reports and the The parameter field contains 0 or more segment reports and the
highest transmission sequence number (TSN) received. highest consecutive TSN received.
Stewart, et al [Page 8] Stewart, et al [Page 8]
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of Gaps = N | | Number of Segments = N |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Gap #1 Start TSN | | Segment #1 Start TSN |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Gap #1 End TSN | | Segment #1 End TSN |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ / / /
\ ... \ \ ... \
/ / / /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Gap #N Start TSN | | Segment #N Start TSN |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Gap #N End TSN | | Segment #N End TSN |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Last TSN Seen | | Highest Consecutive TSN Seen |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
For example, assume the receiver has the following datagrams newly
arrived at the time when it decides to send an Extended Data Ack,
----------
| TSN=17 |
----------
| | <- still missing
----------
| TSN=15 |
----------
| TSN=14 |
----------
| | <- still missing
----------
| TSN=12 |
----------
| TSN=11 |
----------
| TSN=10 |
----------
the control parameter part of the Extended Data Ack shall be
constructed as follows:
--------------------------------
| number of seg = 2 |
--------------------------------
| seg #1 start = 17 |
--------------------------------
| seg #1 end = 17 |
--------------------------------
| seg #2 start = 14 |
--------------------------------
| seg #2 end = 15 |
--------------------------------
| highest consecutive TSN = 12 |
--------------------------------
Note: when multiple segments are reported in a single Extended
Data Ack, the order of the segments in the Extended Data Ack is
not specified.
2.2.3 Advisory Ack Request (0x4): 2.2.3 Advisory Ack Request (0x4):
No parameter field. No parameter field.
2.2.4 Window-up (0x5): 2.2.4 Window-up (0x5):
No parameter field. No parameter field.
2.2.5 Window-up Ack (0x6): 2.2.5 Window-up Ack (0x6):
skipping to change at page 10, line ? skipping to change at page 10, line ?
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Init-Tag | | Init-Tag |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TSN Seen | | TSN Seen |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2.2.9 Graceful Shutdown Ack (0xb): 2.2.9 Graceful Shutdown Ack (0xb):
Same as that of Abort. No parameter field.
2.2.10 Stream Initiation (0xc): 2.2.10 Stream Initiation (0xc):
The parameter field shall contain the initiation Tag of the The parameter field shall contain the initiation Tag of the
destination endpoint (see section 3.1), the Stream Identifier, destination endpoint (see section 3.1) and the Stream Identifier.
and the Initial Sequence Number of this stream. Also, there shall Also, there shall be a "Size of Stream Info" and "Stream
be a "Size of Stream Info" and "Stream Information" fields that Information" fields that may contain an opaque user data structure
may contain an opaque user data structure specific to the stream specific to the stream being opened. The "Stream Information"
being opened. The "Stream Information" field should be padded with field should be padded with '0's to 32 bit word boundary before
'0's to 32 bit word boundary before transmission. transmission.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Init-Tag | | Init-Tag |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Stream Identifier | Reserved (set to 0) | | Stream Identifier | Reserved (set to 0) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Size of Stream Info = N | | Size of Stream Info = N |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 11, line 11 skipping to change at page 11, line 11
2.2.11 Stream Initiation Ack (0xd): 2.2.11 Stream Initiation Ack (0xd):
The parameter field shall contain the Stream Identifier. The parameter field shall contain the Stream Identifier.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Stream Identifier | Reserved (set to 0) | | Stream Identifier | Reserved (set to 0) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2.2.12 Stream Termination (0xe): 2.2.12 Stream Initiation Nack (0x10):
Same as that of Stream Initiation Ack.
2.2.13 Stream Termination (0xe):
The parameter field shall contain the initiation Tag value (see The parameter field shall contain the initiation Tag value (see
section 3.1) and the Stream Identification section 3.1) and the Stream Identification
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Init-Tag | | Init-Tag |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Stream Identifier | Reserved (set to 0) | | Stream Identifier | Reserved (set to 0) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2.2.13 Stream Termination Ack (0xf): 2.2.14 Stream Termination Ack (0xf):
Same has that of Stream Initiation Ack. Same as that of Stream Initiation Ack.
2.3 MDTP Data Part Definitions 2.3 MDTP Data Part Definitions
The following format shall be used for MDTP datagram Data Part: The following format shall be used for MDTP datagram Data Part:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TSN Seen | | TSN Seen |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TSN Send | | TSN Send |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Stream Identifier N | Sequence Number n | | Stream Identifier S | Sequence Number n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \ \ \
/ User Data (seq n of Stream N) / / User Data (seq n of Stream S) /
\ \ \ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Note: TSN Seen, TSN Send, Stream Identifier, and Sequence Number MUST
be transmitted in network byte-order.
TSN Seen: 32 bits TSN Seen: 32 bits
This is a piggy-backed acknowledgment, indicating the reception This is a piggy-backed acknowledgment, indicating the reception
of datagrams up to this TSN. of datagrams up to this TSN.
TSN Send: 32 bits TSN Send: 32 bits
This value represents the TSN of the user data carried in this This value represents the TSN of the user data carried in this
datagram. datagram.
Stream Number: 16 bits Stream Identifier S: 16 bits
Identify the stream to which the following user date belongs. Identify the stream to which the following user date belongs.
Sequence Number: 16 bits Sequence Number n: 16 bits
This value presents the sequence number of the following user This value presents the sequence number of the following user
data within the stream. data within the stream.
Sequence number 0x0 indicates that the following user data shall Sequence number 0x0 indicates that the following user data shall
be treated as un-ordered, and shall be dispatched to the upper be treated as unordered, and shall be dispatched to the upper
layer by the receiver without any attempt of re-ordering. layer by the receiver without any attempt of re-ordering.
User Data: variable length User Data: variable length
This is the payload user data. The size of the user data shall This is the payload user data. The size of the user data shall
be specified in the Data Size field. The implementation may be specified in the Data Size field. The implementation may
optionally have some '0' padded at the end of User Data field. optionally have some '0' padded at the end of User Data field.
3. Endpoint Association Initialization 3. Endpoint Association 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 must complete an ("A") to another endpoint ("Z"), the two endpoints must complete an
initialization process in order to set up an association between them. initialization process in order to set up an association between them.
The upper layer may explicitly request MDTP to initialize an The upper layer may explicitly request MDTP to initialize an
association to an endpoint, or implicitly open the association by association to an endpoint, or implicitly open the association by
sending the first datagram to that endpoint on stream 0. sending the first datagram to that endpoint on stream 0.
Once the association is established, the global stream, i.e., stream Once the association is established, stream 0 is automatically opened
0, is automatically open and ready for datagram transmission. Other and ready for datagram transmission in both directions. Moreover, if
streams must be explicitly opened before data transmission can occur. there are any pre-open streams specified by either side, they shall
also be opened and ready for transmission from that side.
Other streams must be explicitly opened before data transmission can
occur.
A tag-and-lock mechanism must be employed during the initialization A tag-and-lock mechanism must be employed during the initialization
in order to guard against security attacks as well as erroneous in order to guard against security attacks as well as erroneous
datagrams. datagrams.
3.1 Initiation Message and Tag Lock 3.1 Initiation Message and Tag Lock
The initialization process consists of the following steps (assuming The initialization process consists of the following steps (assuming
that MDTP endpoint "A" tries to set up an association with MDTP that MDTP endpoint "A" tries to set up an association with MDTP
endpoint "Z"): endpoint "Z"):
skipping to change at page 13, line 15 skipping to change at page 13, line 15
At this point, "Z" is ready to send user datagrams to "A" in stream At this point, "Z" is ready to send user datagrams to "A" in stream
0. And upon the reception of the above Initiation Ack from "Z", "A" 0. And upon the reception of the above Initiation Ack from "Z", "A"
also becomes ready to send user datagrams to "Z" in stream 0. also becomes ready to send user datagrams to "Z" in stream 0.
Note: user data in other streams can not be sent until the Note: user data in other streams can not be sent until the
respective streams are opened. respective streams are opened.
C) "Z" shall leave Tag-lock-new mode and enter Tag-lock mode only if a C) "Z" shall leave Tag-lock-new mode and enter Tag-lock mode only if a
user datagram has been sent out from "Z" to "A". user datagram has been sent out from "Z" to "A".
Note: to guard against "man in the middle" attacks, a limit should Note: to guard against "man in the middle" attacks, an endpoint
be imposed on the number of associations in the Tag-lock-new mode should impose a limit on the number of associations allowed to be
at any given endpoint; whenever that limit is reached, any further in the Tag-lock-new mode; whenever this limit is reached, any
association Initiations received by the endpoint shall be silently further association Initiations received by the endpoint shall be
discarded. Also, a timer shall be used on each association that is silently discarded. Also, a timer shall be used on each association
in the Tag-lock-new mode; at the expiration of that timer, that that is in the Tag-lock-new state; at the expiration of that timer,
association shall be shutdown by the endpoint. that association shall be shutdown by the endpoint by sending an
Abort to the peer of that association.
Note: no user data shall be carried in both the Initiation and Note: no user data shall be carried in both the Initiation and
Initiation Ack messages, i.e., the C/D bits must be set to 10. Initiation Ack messages, i.e. the Data Size field in the MDTP common
header must be set to 0x0.
Note: both side must exchange their local network information and Note: if an endpoint receives an Initiation but decides not to
their maximal window length in the Initiation and Initiation Ack establish the new association due to lack of resources, etc.,
messages. it shall respond to the Initiation with an Abort message.
3.1.1 Passing Initiation Parameters
In addition to the Tags, both side must exchange their local network
information, maximal window length, the sender's T2-Receive timer
value in microseconds, number of pre-open outbound streams (P), and
number of maximal inbound streams (M), in the Initiation and
Initiation Ack messages. And the receiver shall process and store
these initiation parameters.
The maximal window length from the peer will be used to validate the
TSN range of the received datagrams (see section 4.6).
The sender's T2-receive timer will be used to adjust the T3-send timer
(see section 4.1.1).
The number of maximal inbound streams (M) shall indicate the maximal
number of concurrent streams the sender will accept from its peer
(excluding stream 0). The sender will reject any new Stream Initiation
request from its peer if this number is reached, unless some of the
currently open streams are closed first by the peer.
The sender shall use the number of pre-open outbound streams (P) to
indicate to its peer that, in addition to the stream 0, the sender
wants to have that many more streams (from stream 1 to stream P)
implicitly opened from the sender's side at the onset of the
association. This allows the receiver to allocate and initialize
necessary resources for the additional P inbound streams.
However, if the sender's P is greater than, or equal to, the
receiver's M, the receiver shall replace the sender's P with M, and
then only pre-open M inbound streams (from stream 1 to stream M). At
the same time, the sender also must either settle with M, instead of
P, pre-open outbound streams, or abort the association and report the
resources shortage.
3.2 Tag Unlock and TSN Initialization 3.2 Tag Unlock and TSN Initialization
The first user datagram transmitted by "A" to "Z" shall have the TSN The first user datagram transmitted by "A" to "Z" shall have the TSN
Seen value set to Tag_Z in the Data Part (see 2.3). Seen value set to Tag_Z in the Data Part (see 2.3).
Similarly, the first user datagram transmitted by "Z" to "A" shall Similarly, the first user datagram transmitted by "Z" to "A" shall
have the TSN Seen value set to Tag_A. have the TSN Seen value set to Tag_A.
The reception of this first datagram with user data and with the The reception of this first datagram with user data and with the
skipping to change at page 13, line 53 skipping to change at page 13, line 90
acknowledge the reception of this first user datagram. acknowledge the reception of this first user datagram.
The TSN Send value carried in this first datagram with user data shall The TSN Send value carried in this first datagram with user data shall
be used to establish the initial TSN of this peer, i.e., the sender of be used to establish the initial TSN of this peer, i.e., the sender of
this datagram. this datagram.
To strengthen the security, this initial TSN shall be randomly To strengthen the security, this initial TSN shall be randomly
selected from the range between 0x1 and 0x7fffffff by the sender, by selected from the range between 0x1 and 0x7fffffff by the sender, by
means such as those suggested in RFC 1750 [9]. means such as those suggested in RFC 1750 [9].
Note: if there exists any un-acked datagram(s) when an endpoint is to Note: When an endpoint receives the first user datagram that causes it
send its first user datagram to its peer, the endpoint MUST send a to leave the the Tag-lock or Tag-lock-new mode, it shall immediately
stand-alone Extended Data Ack to acknowledge the un-acked datagram(s) send an Extended Data Ack to acknowledge the reception of this user
it has received from that peer before it sends out its first user datagram and shall NOT start a T2-recv timer. For all the subsequent
datagram. This is because the TSN Seen field in the first out-bound user datagram receptions, the receiver shall follow the normal timer
rules.
user datagram can not be used as a TSN ack, instead it is used to
carried the peer's Tag.
3.3 Datagram Processing during Tag Lock 3.3 Datagram Processing during Tag Lock
In Tag-lock or Tag-lock-new mode, an endpoint shall silently discard In Tag-lock or Tag-lock-new mode, an endpoint shall silently discard
any user datagrams from the peer endpoint that does not carried the any user datagrams from the peer endpoint that does not carry the
correct Tag value. correct Tag value.
However, if there is a control part present in a discarded user However, if there is a control part present in a discarded user
datagram (i.e., C/D = 0x11), the endpoint shall always process the datagram, the endpoint shall always process the
control part even when the data part is being discarded. control part even when the data part is being discarded.
If another Initiation from "A" is received by "Z" after "Z" sent out If another Initiation from "A" is received by "Z" after "Z" sent out
its Initiation Ack, "Z" shall respond to this second Initiation by its Initiation Ack, "Z" shall respond to this second Initiation by
re-sending the Initiation Ack if the Tag Send field of this second re-sending the Initiation Ack if the Tag Send field of this second
Initiation has the same value as that of the original Initiation. Initiation has the same value as that of the original Initiation.
Otherwise, "Z" shall respond by sending an Initiation of its own, with Otherwise, "Z" shall respond by sending an Initiation of its own, with
Tag Send field set to Tag_Z, so as to elicit an Initiation Ack from Tag Send field set to Tag_Z, so as to elicit an Initiation Ack from
"A". "A".
3.4 An Example of Association Initialization 3.4 An Example of Association Initialization
In the following example, "A" initiates the association first and then In the following example, "A" initiates the association first and then
sends a user datagram to "Z", then "Z" sends two user datagrams sends a user datagram to "Z", then "Z" sends two user datagrams
sometimes later: sometimes later:
Endpoint A Endpoint Z Endpoint A Endpoint Z
{app sets association with Z} {app sets association with Z}
Initiation(C/D = 10) Initiation
[Tag Seen=0,Tag Send=Tag_A [Tag Seen=0,Tag Send=Tag_A
& net addr info] --------\ & net addr info] --------\
(Start T1-init timer) \ (Start T1-init timer) \
(Enter Tag_A-lock mode) \---->Initiation Ack(C/D = 10) (Enter Tag_A-lock mode) \---->Initiation Ack
[Tag Seen=Tag_A,Tag Send=Tag_Z [Tag Seen=Tag_A,Tag Send=Tag_Z
/---- & net addr info] /---- & net addr info]
/ (Enter Tag_Z-lock-new mode) / (Enter Tag_Z-lock-new mode)
(Cancel T1-init timer)<-------/ (Cancel T1-init timer)<-------/
{app sends 1st user data; strm 0} {app sends 1st user data; strm 0}
U-Data(C/D = 01) U-Data
[Seen=Tag_Z,Send=init TSN-A [Seen=Tag_Z,Send=init TSN-A
Strm=0,Seq=1, Strm=0,Seq=1,
& user data] -------\ & user data] -------\
(Start T3-send timer) \ (Start T3-send timer) \
\---->(Leave Tag_Z-lock-new mode) \---->(Leave Tag_Z-lock-new mode)
------Ext Data Ack(C/D = 10) ------Ext Data Ack
/ [Gap=0,TSN Seen=init TSN-A] / [Seg=0,TSN Seen=init TSN-A]
(Cancel T3-send timer) <-----/ (Cancel T3-send timer) <-----/
.. ..
.. ..
{app sends 2 datagrams;strm 0} {app sends 2 datagrams;strm 0}
/---- U-data(C/D = 01) /---- U-data
/ [Seen=Tag_A,Send=init TSN-Z / [Seen=Tag_A,Send=init TSN-Z
(Leave Tag_A-lock mode) <----/ Strm=0,Seq=1, (Leave Tag_A-lock mode) <----/ Strm=0,Seq=1,
(Start T2-receive timer) & user data 1] Ext Data Ack & user data 1]
/---- U-data(C/D = 01) [Seg=0,TSN Seen=init TSN-Z] /---- U-data
/ [Seen=init TSN-A, --------\ / [Seen=init TSN-A,
/ Send=init TSN-Z +1, \/ Send=init TSN-Z +1,
<---/ Strm=0,Seq=1, (Start T2-receive timer)<---/\ Strm=0,Seq=1, & user data 2]
& user data 2] \
\------>
If T1-init timer expires at "A" after the Initiation is sent, the same If T1-init timer expires at "A" after the Initiation is sent, the same
Initiation message with the same Tag_A value shall be retransmitted and Initiation message with the same Tag_A value shall be retransmitted and
the timer restarted. This shall be repeated Max.Init.Retransmit times the timer restarted. This shall be repeated Max.Init.Retransmit times
before "A" considers "Z" unreachable and optionally reports the before "A" considers "Z" unreachable and optionally reports the
failure. failure.
3.5 Other Initiation Issues 3.5 Other Initiation Issues
3.5.1 Selection of Tag Value 3.5.1 Selection of Tag Value
skipping to change at page 15, line 42 skipping to change at page 15, line 43
3.5.2 Initiation from behind a NAT 3.5.2 Initiation from behind a NAT
When a NAT is present between two endpoints, the endpoint that is When a NAT is present between two endpoints, the endpoint that is
behind the NAT, i.e., one that does not have a publicly available behind the NAT, i.e., one that does not have a publicly available
network address, shall take one of the following options: network address, shall take one of the following options:
A) Indicate that it has only one network by setting the 'Number of A) Indicate that it has only one network by setting the 'Number of
networks' field in the Initiation message to 0. This will make the networks' field in the Initiation message to 0. This will make the
endpoint that receives this Initiation message to consider the sender endpoint that receives this Initiation message to consider the sender
as only having that one address. This method can be used for a dynamic as only having that one address. This method can be used for a dynamic
NAT, but any multihoming configuration at the endpoint that is behind NAT, but any multi-homing configuration at the endpoint that is behind
the NAT will not be visible to its peer, and thus not be taken the NAT will not be visible to its peer, and thus not be taken
advantage of. advantage of.
B) Indicate all of its networks in the Initiation by specifying all B) Indicate all of its networks in the Initiation by specifying all
the actual IP addresses and ports that the NAT will substitute for the the actual IP addresses and ports that the NAT will substitute for the
endpoint. This method requires that the endpoint behind the NAT must endpoint. This method requires that the endpoint behind the NAT must
have pre-knowledge of all the IP addresses and ports that the NAT will have pre-knowledge of all the IP addresses and ports that the NAT will
assign. assign.
3.5.3 Initialization Collision 3.5.3 Initialization Collision
skipping to change at page 16, line 25 skipping to change at page 16, line 25
An endpoint shall be allowed to re-initialize an established An endpoint shall be allowed to re-initialize an established
association with the other endpoint. association with the other endpoint.
Once an endpoint has left the Tag-lock or Tag-lock-new mode of the Once an endpoint has left the Tag-lock or Tag-lock-new mode of the
previous association initialization process, it shall treat any new previous association initialization process, it shall treat any new
Initiation message from its peer as a re-initialization event. Initiation message from its peer as a re-initialization event.
During a re-initialization, both endpoint shall follow the same During a re-initialization, both endpoint shall follow the same
procedure as defined in section 3.1. And a new Init-Tag must be used procedure as defined in section 3.1. And a new Init-Tag must be used
by the endpoint that receives the Initiation message if it has already by the endpoint that receives the Initiation message, if it has already
left the previous Tag-lock or Tag-lock-new mode. left the previous Tag-lock or Tag-lock-new mode.
Association re-initialization affects ongoing transmission and
their resources. The receiver of the new Initiation may need to
perform garbage-collection on its resources, including:
A) automatically terminating all existing streams within the current
association and releasing the resources,
B) cancelling any running timers,
C) removing all outstanding datagrams of the current association
from its retransmission queue, and
D) optionally, notifying the upper layer about the re-initialization.
4. Transfer User Datagram 4. Transfer User Datagram
The receiver of a user datagram shall always acknowledge the reception The receiver of a user datagram shall always acknowledge the reception
to the sender of the datagram. Normally, delayed acknowledgment shall to the sender of the datagram. Normally, delayed acknowledgment shall
be used. The delay shall be controlled by a T2-receive timer. be used. The delay shall be controlled by a T2-receive timer.
At the expiration of T2-receive timer, if there is out-bound user data, At the expiration of T2-receive timer, if there is out-bound user data,
the ack should be piggy-backed on the data part of the out-bound user the ack should be piggy-backed on the data part of the out-bound user
datagram, occupying the TSN Seen field (see section 2.3). Otherwise, a datagram, occupying the TSN Seen field (see section 2.3). Otherwise, a
stand-alone Extended Data Ack shall be used to carry the stand-alone Extended Data Ack shall be used to carry the
acknowledgment. acknowledgment.
When Extended Data Ack is used, the sender shall fill the Last TSN When Extended Data Ack is used, the sender shall fill the Highest
Seen field to indicate the highest TSN Send number it has received Consecutive TSN Seen field to indicate the highest TSN Send number it
from the peer. Any detected gaps must also be reported has received from the peer. Any received segments must also be
(see section 4.5). reported (see sections 2.2.2 and 4.5).
The following example illustrates both stand-alone and piggy-backed The following example illustrates both stand-alone and piggy-backed
acknowledgments: acknowledgments:
Endpoint A Endpoint Z Endpoint A Endpoint Z
{App sends 3 messages in strm 0} {App sends 3 messages in strm 0}
U-Data(C/D = 01) U-Data
[Seen=5,Send=7,Strm=0,Seq=3]--------> (Start T2-receive timer) [Seen=5,Send=7,Strm=0,Seq=3]--------> (Start T2-receive timer)
(Start T3-send timer) (Start T3-send timer)
U-Data(C/D = 01) U-Data
[Seen=5,Send=8,Strm=0,Seq=4]--------> [Seen=5,Send=8,Strm=0,Seq=4]-------->
U-Data(C/D = 01) U-Data
[Seen=5,Send=9,Strm=0,Seq=5]--------> [Seen=5,Send=9,Strm=0,Seq=5]-------->
... ...
{Timer T2 expires} {Timer T2 expires}
/--------- Extended Data Ack(C/D=10) /--------- Extended Data Ack
/ [Gap=0,Seen=9] / [Seg=0,Seen=9]
(cancel T3-send timer) <----/ (cancel T3-send timer) <----/
... ...
... ...
{App sends 1 message; strm 0} {App sends 1 message; strm 0}
U-Data(C/D = 01) U-Data
[Seen=5,Send=10,Strm=0,Seq=6]-------> (Start T2-receive timer) [Seen=5,Send=10,Strm=0,Seq=6]-------> (Start T2-receive timer)
(Start T3-send timer) (Start T3-send timer)
... ...
{App sends 1 message; strm 1} {App sends 1 message; strm 1}
(cancel T2-receive timer) (cancel T2-receive timer)
/------ U-Data (C/D=01) /------ U-Data
/ [Seen=10,Send=6,Strm=1,Seq=2] / [Seen=10,Send=6,Strm=1,Seq=2]
/ (Start T3-send timer) / (Start T3-send timer)
(cancel T3-send timer) <------/ (cancel T3-send timer) <------/
(Start T2-receive timer) (Start T2-receive timer)
.. ..
{Timer T2 Expires} {Timer T2 Expires}
Extended Data Ack(C/D=10) Extended Data Ack
[Gap=0,Seen=6]----------------------> (cancel T3-send timer) [Seg=0,Seen=6]----------------------> (cancel T3-send timer)
4.1 Timer Management Rules 4.1 Timer Management Rules
The the following rules shall be used to manage the timers during The the following rules shall be used to manage the timers during
normal datagram transfer, unless otherwise stated for some special normal datagram transfer, unless otherwise stated for some special
cases: cases:
A) When a user datagram is received, the endpoint shall start a A) When a user datagram is received, the endpoint shall start a
T2-receive timer if no T2-receive timer is currently running. Upon T2-receive timer if no T2-receive timer is currently running. Upon
the expiration of the T2-receive timer, the endpoint shall the expiration of the T2-receive timer, the endpoint shall
acknowledge to the sender all the un-acked user datagrams it has acknowledge to the sender all the un-acked user datagrams it has
received. received.
B) When a user datagram is sent out, the sending endpoint shall start B) When a user datagram is sent out, the sending endpoint shall start
a T3-send timer if no T3-send timer is currently running. a T3-send timer if no T3-send timer is currently running.
If the T2-receive timer is running, the endpoint shall first stop If the T2-receive timer is running, the endpoint shall first stop
the T2 timer, piggy-back an ack (or Extended Data Ack) unto the the T2 timer, piggy-back an ack (or Extended Data Ack) onto the
out-bound datagram, and then start a T3-send timer. out-bound datagram, and then start a T3-send timer.
If the T3-send timer expires, the endpoint shall follow the rules If the T3-send timer expires, the endpoint shall follow the rules
described in 4.6 for possible re-transmission of the un-acked described in 4.6 for possible re-transmission of the un-acked
datagrams. datagrams.
Moreover, whenever the T3-send timer is started the RTT estimate Moreover, whenever the T3-send timer is started the RTT estimate
last calculated for that remote network address should be added to last calculated for that remote network address should be added to
the base T3-send timer value (see sections 6.2 and 6.3 for RTT). the base T3-send timer value (see sections 6.2 and 6.3 for RTT).
C) When all outstanding datagrams are acknowledged, the T3-send timer C) When all outstanding datagrams are acknowledged, the T3-send timer
shall be stopped if one is still running. shall be stopped if one is still running.
D) If an endpoint has a T3-send timer running and receives a partial D) If an endpoint has a T3-send timer running and receives a partial
acknowledgment (one that acknowledges some of the outstanding acknowledgment (one that acknowledges some of the outstanding
datagrams) then the endpoint shall restart the T3-send timer. datagrams), the endpoint shall restart the T3-send timer.
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; strm 0} {App sends 2 messages; strm 0}
U-Data (C/D=01) U-Data
[Seen=5,Send=7,Strm=0,Seq=3] ---------> (Start T2-receive timer) [Seen=5,Send=7,Strm=0,Seq=3] ---------> (Start T2-receive timer)
(Start T3-send timer) (Start T3-send timer)
U-Data (C/D=01) {App sends 1 message; strm 1} U-Data {App sends 1 message; strm 1}
[Seen=5,Send=8,Strm=0,Seq=4] -\ /-- (cancel T2-receive timer) [Seen=5,Send=8,Strm=0,Seq=4] -\ /-- (cancel T2-receive timer)
\ / U-Data (C/D=01) \ / U-Data
\ / [Seen=7,Send=6,Strm=1,Seq=2] \ / [Seen=7,Send=6,Strm=1,Seq=2]
\ (Start T3-send timer) \ (Start T3-send timer)
/ \ / \
(Re-start T3-send timer) <-------/ \ (Re-start T3-send timer) <-------/ \
(Start T2-receive timer) \ (Start T2-receive timer) \
... -> (Start T2-receive timer) ... -> (Start T2-receive timer)
... ...
{T2-receive timer expires} {T2-receive timer expires}
Extended Data Ack(C/D=10) Extended Data Ack
[Gap=0,Seen=6] -----------------------> (Cancel T3-send timer) [Seg=0,Seen=6] -----------------------> (Cancel T3-send timer)
.. ..
{T2-receive timer expires} {T2-receive timer expires}
(Cancel T3-send timer) <---------------- Extended Data Ack(C/D=10) (Cancel T3-send timer) <---------------- Extended Data Ack
[Gap=0,Seen=8] [Seg=0,Seen=8]
4.1.1 T3-send Timer Adjustment with RTT 4.1.1 T3-send Timer Adjustment with RTT
If the RTT measurement is available to a remote IP address, the sender The sender shall keep track of the latest RTT measurement for the
shall adjust the T3-send timer each time when sending datagrams to destination IP address (or addresses if the remote host is
that IP address. The calculation and adjustment of the timer should multi-homed) of its peer. Three procedures for obtaining RTT
follow the method described in [4]. RTT measurement shall be tracked measurements are defined in sections 4.7, 6.2, and 6.3,
for each destination IP address if the remote host is multi-homed. respectively. And the calculation of RTT should follow the method
described in [4].
MDTP defines three methods to obtain RTT measurements, see sections Every time when a new datagram is sent for the first time (i.e., not
4.7, 6.2, and 6.3. for re-transmission), the following procedure shall be applied to
determine the T3-send timer value:
1. TL3-value = 'TL3-default'
2. if TL3-value <= Receiver's T2-Recv + highest-RTT,
TL3-value = TL3-value + highest-RTT
end-if
3. T3-send = TL3-value + network-RTT
where, 'TL3-default' is a protocol parameter configurable by the
endpoint, receiver's T2-Recv timer value is known during the
association initiation (see section 3.1.1), the highest-RTT is the
current highest RTT measurement across all the destination IP
addresses available for transmission, and, the network-RTT is the
current RTT measurement of the destination IP address this
transmission is to take place (see section 4.2.1 for the determining
of destination IP address).
However, if the previous T3-send timer expired and is being re-started
for a re-transmission, the timer back-off rules defined in section 5.2
shall be used instead.
4.2 Multihoming Rotation 4.2 Multihoming Rotation
4.2.1 Remote Multihoming Rotation 4.2.1 Remote Multihoming Rotation
When an endpoint is transmitting to a remote multi-homed endpoint, the When an endpoint is transmitting to a remote multi-homed endpoint, the
transmitting endpoint shall rotate between destination IP addresses. transmitting endpoint shall rotate between destination IP addresses.
Every time the application transmits a datagram, MDTP MUST keep track Every time the application transmits a datagram, MDTP MUST keep track
of the remote IP address to which it sent the datagram in the MDTP of the remote IP address to which it sent the datagram in the MDTP
skipping to change at page 20, line 20 skipping to change at page 20, line 20
simply setting the stream sequence number of each out-bound user simply setting the stream sequence number of each out-bound user
datagram to 0. datagram to 0.
4.5 Report Missing Datagrams 4.5 Report Missing Datagrams
MDTP uses a receiver-based retransmission policy, where the sender MDTP uses a receiver-based retransmission policy, where the sender
attempts to elicit from the receiver information on the missing attempts to elicit from the receiver information on the missing
datagrams before the retransmission. datagrams before the retransmission.
If a receiver detects holes in the received user datagram sequence (by If a receiver detects holes in the received user datagram sequence (by
examining TSN Send numbers), an Extended Data Ack with gap reports examining TSN Send numbers), an Extended Data Ack with segment reports
shall be sent back to inform the sender so that the missing datagrams shall be sent back to inform the sender so that the sender can
can be re-transmitted. calculate and re-transmit the missing datagrams.
Multiple gaps can be indicated in one single Extended Data Ack. Multiple segments can be indicated in one single Extended Data Ack
(see section 2.2.2).
If there is out-bound user data, the endpoint shall piggy-back the If there is outbound user data, the endpoint shall piggy-back the
Extended Data Ack with the user data in the same MDTP datagram, by Extended Data Ack with the user data in the same MDTP datagram, and
setting the C/D bits to '11'. And the TSN Seen field in the data part the TSN Seen field in the data part shall not be used, i.e., the
shall not be used, i.e., the sender shall set the field to 0x0 and the sender shall set the field to 0x0 and the receiver shall ignore it.
receiver shall ignore it.
The following example shows the use of gap report in an Extended Data The following example shows the use of segment report in an Extended
Ack. Data Ack.
Endpoint A Endpoint Z Endpoint A Endpoint Z
{App sends 3 messages; strm 0} {App sends 3 messages; strm 0}
U-Data (C/D=01) U-Data
[Seen=3,Send=6,Strm=0,Seq=2]-------> (Start T2-receive timer) [Seen=3,Send=6,Strm=0,Seq=2]-------> (Start T2-receive timer)
(Start T3-send timer) (Start T3-send timer)
U-Data (C/D=01) U-Data
[Seen=3,Send=7,Strm=0,Seq=3]-----X (lost) [Seen=3,Send=7,Strm=0,Seq=3]-----X (lost)
U-Data (C/D=01) U-Data
[Seen=3,Send=8,Strm=0,Seq=4]-------> (A gap detected in data) [Seen=3,Send=8,Strm=0,Seq=4]-------> (A seg detected in data)
.. ..
{T2-receive timer expires} {T2-receive timer expires}
/------ Extended Data Ack (C/D = 10) /------ Extended Data Ack
/ [Gap=1,Strt=7,End=7,Seen=8] / [Seg=1,Strt=8,End=8,Seen=6]
(Prepare retransmission) <----/ (Prepare retransmission) <----/
In this example, when "Z" receives the third datagram from "A" it In this example, when "Z" receives the third datagram from "A" it
realizes that a gap exists in the received data. At the expiration of realizes that a gap exists in the received data. At the expiration of
T2-receive timer, "Z" sends an Extended Data Ack with a gap report to T2-receive timer, "Z" sends an Extended Data Ack with a segment report
"A" to indicate the missing datagram. Note that the Start and End to "A" to indicate the missing datagram.
fields in the gap report specify the edges of the gap, i.e., the TSN
numbers between Start and End are missing.
When the peer endpoint is multi-homed, the Extended Data Ack should be When the peer endpoint is multi-homed, the Extended Data Ack should be
sent out to the destination IP address specified in the MDTP protocol sent out to the destination IP address specified in the MDTP protocol
variable 'last.good.intf'. The value of 'last.good.intf' is always variable 'last.good.intf'. The value of 'last.good.intf' is always
updated to point to the source IP address from which the last datagram updated to point to the source IP address from which the last datagram
from the peer endpoint arrived. from the peer endpoint arrived.
4.6 Range Check on TSN 4.6 Range Check on TSN
For security reasons, the receiver must check the range of the TSN For security reasons, the receiver must check the range of the TSN
skipping to change at page 21, line 28 skipping to change at page 21, line 26
Assume that the highest TSN received from a peer is T and the maximal Assume that the highest TSN received from a peer is T and the maximal
window length of the same peer is W (exchanged during association window length of the same peer is W (exchanged during association
initiation, see section 3.1). When the next user datagram arrives from initiation, see section 3.1). When the next user datagram arrives from
this peer, the receiver shall silently discard the datagram if the TSN this peer, the receiver shall silently discard the datagram if the TSN
Send value carried in the datagram is greater than T+W (calculation Send value carried in the datagram is greater than T+W (calculation
rounds up at 0x7fffffff to 0x1). rounds up at 0x7fffffff to 0x1).
4.7 Advisory Ack Request 4.7 Advisory Ack Request
An endpoint may use Advisory Ack Requests to improve bandwidth An endpoint may use Advisory Ack Requests to improve bandwidth
utilization. utilization, in combination of the window control (see section 5.1).
The endpoint should send an Advisory Ack Request to its peer when it Advisory Ack Request shall always be piggy-backed on an outbound user
reaches half of its current window length, and also when it detects datagram.
that the next send will reach the full window length (see section 5.1
for window control).
Upon the reception of an Advisory Ack Request, when it is not under The endpoint should send an Advisory Ack Request to its peer when:
flow control condition the peer endpoint should immediately
acknowledge all the datagrams it has received but not yet
acknowledged, and then cancel the T2-receive timer if one is still
running. Otherwise, the peer endpoint shall take no action and ignore
the Advisory Ack Request.
The following shows an example of using Advisory Ack Request: A) it reaches half of its window length with the sending of the
current user datagram, or
B) it detects that the next send will reach the full window length
with the sending of the current user datagram.
After the receiver detects the Advisory Ack Request in the control
part of the datagram, it should handle it with the following rules:
A) The receiver may choose to ignore the peer's Advisory Ack Request
for any reasons, such as flow control, etc, and move on to
process the data part.
B) If the receiver chooses to respond, it should, at the end of
processing the data part, immediately send an Extended Data Ack
to acknowledge all the un-acked datagrams (including the one it
just processed), and cancel its T2-receive timer if one is still
running.
The following diagram shows an example of using Advisory Ack Request:
Endpoint A Endpoint Z Endpoint A Endpoint Z
{App sends 3 messages; strm 0} {App sends 3 messages; strm 0}
U-Data(C/D = 01) U-Data
[Seen=5,Send=7,Strm=0,Seq=3]-------------> (Start T2-recv timer) [Seen=5,Send=7,Strm=0,Seq=3]-------------> (Start T2-recv timer)
(Start T3-send timer) (Start T3-send timer)
U-Data(C/D = 01) U-Data
[Seen=5,Send=8,Strm=0,Seq=4]-----------> [Seen=5,Send=8,Strm=0,Seq=4]----------->
{detects window half full, use Advisory Ack Req} {detects window half full, use Advisory Ack Req}
Adv Ack Request(C/D=11) Adv Ack Request/U-data
[Seen=5,Send=9,Strm=0,Seq=5]------\ [Seen=5,Send=9,Strm=0,Seq=5]------\
\ \
\----> (cancel T2-receive timer) \----> (cancel T2-receive timer)
<---------------- Extended Data Ack(C/D=10) <---------------- Extended Data Ack
[Gap=0,Seen=9] [Seg=0,Seen=9]
An endpoint sending an Advisory Ack Request may also use this request An endpoint sending an Advisory Ack Request may also use this request
for its RTT calculation. The sending endpoint may note the time mark for its RTT calculation. The sending endpoint may note the time mark
when sending the datagram with the Advisory Ack Request. When the when sending the datagram with the Advisory Ack Request. When the
peer endpoint responds with an Extended Data Ack, the sender of the peer endpoint responds with an Extended Data Ack, the sender of the
Advisory Ack Request may use the time mark of the arriving Extend Data Advisory Ack Request may use the time mark of the arriving Extend Data
Ack and the stored time mark to calculate the RTT as defined in Ack and the stored time mark to calculate the RTT as defined in
[4]. However, the sender of the Advisory Ack Request shall abandon the [4]. However, the sender of the Advisory Ack Request shall abandon the
RTT calculation if more datagrams are sent to its peer and no Extended RTT calculation if more datagrams are sent to its peer and no Extended
Data Ack is received. Data Ack is received.
4.8 CRC-16 Utilization
When sending a datagram, the sender can choose to strengthen the data
integrity
of the transmission by including a CRC-16 value of the datagram.
After the datagram is constructed, the sender shall:
1) set the C Bit to '1' and fill the 28 bit CRC-16/MDTP Protocol
Identifier field with '0', and the 4 bit Version field to the
current MDTP version number (binary 0011).
2) calculate a CRC-16 value of the whole datagram, including the
MDTP common header, the Control Parameter Part if present, and
the Data Part if present,
3) put the resultant CRC-16 value into the most significant 16 bits
of the CRC-16/MDTP Protocol Identifier, and leave the rest of the
bits unchanged.
When a datagram is received, the receiver must first check the C
Bit. If the C Bit is set, the receiver shall:
1) store the received CRC-16 value (the most significant 16 bits of
the first word of the datagram),
2) replace the 16 bit CRC-16/MDTP Protocol Identifier field with '0'
and calculate a CRC-16 value of the whole received datagram,
3) verify that the calculated CRC-16 value is the same as the
received CRC-16 value, and
4) handle the datagram as an invalid MDTP datagram if the CRC-16
values mismatch .
If the C Bit is not set, the receiver shall check the MDTP Protocol
Identifier instead, and handle the datagram as an invalid MDTP
datagram if the check fails.
The default procedure of handling invalid MDTP datagrams is to
silently discard them.
5 Congestion Controls 5 Congestion Controls
Several different mechanisms shall be used jointly to achieve Several different mechanisms shall be used jointly to achieve
congestion control in MDTP. These mechanisms are always used in regard congestion control in MDTP. These mechanisms are always used in regard
to the association, not a individual stream. to the association, not a individual stream.
5.1 Send with Window Control 5.1 Send with Window Control
The sending endpoint shall use a transmission window to control the The sending endpoint shall use a transmission window to control the
number of outstanding datagrams, i.e., datagrams that have been sent, number of outstanding datagrams, i.e., datagrams that have been sent,
skipping to change at page 23, line 7 skipping to change at page 23, line 7
shall return an error to its upper layer. shall return an error to its upper layer.
Moreover, when the window length is reached, the next send request Moreover, when the window length is reached, the next send request
from the upper layer will trigger a Window-up message to be from the upper layer will trigger a Window-up message to be
transmitted. Upon receiving this Window-up the receiver must respond transmitted. Upon receiving this Window-up the receiver must respond
with a Window-up Ack, as illustrated by the following example with a Window-up Ack, as illustrated by the following example
(assuming current window length is 3): (assuming current window length is 3):
Endpoint A Endpoint Z Endpoint A Endpoint Z
{App sends 3 messages, strm 0} {App sends 3 messages, strm 0}
U-Data(C/D = 01) U-Data
[Seen=5,Send=7,Strm=0,Seq=3]--------> (Start T2-receive timer) [Seen=5,Send=7,Strm=0,Seq=3]--------> (Start T2-receive timer)
(Start T3-send timer) (Start T3-send timer)
U-Data(C/D = 01) U-Data
[Seen=5,Send=8,Strm=0,Seq=4]--------> [Seen=5,Send=8,Strm=0,Seq=4]-------->
U-Data(C/D = 01) U-Data
[Seen=5,Send=9,Strm=0,Seq=5]--------> [Seen=5,Send=9,Strm=0,Seq=5]-------->
{App sends a new message, strm 1} {App sends a new message, strm 1}
(queue new message and send Win-up) (queue new message and send Win-up)
Window-up(C/D = 10) ---------------> (cancel T2-recv timer) Window-up ---------------> (cancel T2-recv timer)
/---- Window-up Ack(C/D = 10) /---- Window-up Ack
/ [Gap=0,Seen=9] / [Seg=0,Seen=9]
(Cancel T3-send timer) <--------/ (Cancel T3-send timer) <--------/
U-Data(C/D = 01) U-Data
[Seen=5,Send=10,Strm=1,Seq=2]-------> (Start T2-receive timer) [Seen=5,Send=10,Strm=1,Seq=2]-------> (Start T2-receive timer)
(Start T3-send timer) (Start T3-send timer)
In the above example, after the transmission of the first three In the above example, after the transmission of the first three
datagrams, "A" reached its window length. The next message from the datagrams, "A" reached its window length. The next message from the
user triggered a Window-up that was sent to "Z". The Window-up shall user triggered a Window-up that was sent to "Z". The Window-up shall
contain no user data. In response, "Z" cancelled timer T2 and contain no user data. In response, "Z" cancelled timer T2 and
immediately sent a Window-up Ack. The arrival of this Window-up Ack immediately sent a Window-up Ack. The arrival of this Window-up Ack
effectively resolved all the outstanding datagrams at "A", thus effectively resolved all the outstanding datagrams at "A", thus
allowing "A" to send out the next datagram. allowing "A" to send out the next datagram.
5.1.1 Window Length Adjustment 5.1.1 Window Length Adjustment
The window length shall be initially set to 2, and shall then be The window length shall be initially set to 2, and shall then be
dynamically adjusted based on datagram loss and acknowledgment. dynamically adjusted based on datagram loss and acknowledgment.
If the current window length is less than or equal to 4, every time If the current window length is less than or equal to 4, every time
the number of consecutive outstanding datagrams acknowledged in a when the number of consecutive outstanding datagrams acknowledged in a
single ack is equal to or greater than half the current window length, single ack is equal to or greater than half the current window length,
the sender's window length shall be raised by 1, until it reaches the sender's window length shall be raised by 1, until it reaches
'Max.Outstanding.dg'(which should be a user configurable parameter). 'Max.Outstanding.dg'(which should be a user configurable parameter).
If the current window length is greater than 4, every time the number If the current window length is greater than 4, every time when the number
of consecutive outstanding datagrams acknowledged in a single ack is of consecutive outstanding datagrams acknowledged in a single ack is
equal to or greater than 4, the sender's window length shall be raised equal to or greater than 4, the sender's window length shall be raised
by 1, until it reaches 'Max.Outstanding.dg'. by 1, until it reaches 'Max.Outstanding.dg'.
In the following circumstances, the sender's window length shall be In the following circumstances, the sender's window length shall be
decreased. However, when the window length reaches 2 it shall not be decreased. However, when the window length reaches 2 it shall not be
decreased any further. decreased any further.
Firstly, if the sender receives a stand-alone Extended Data Ack with a
Seen TSN that equals to the highest consecutive acked TSN, the sender
should consider this as a duplicate ack and lower its window size
by 4.
The peer endpoint may report reception gaps which may correspond to The peer endpoint may report reception gaps which may correspond to
multiple datagram losses (indicated by an Extended Data Ack or multiple datagram losses (indicated by an Extended Data Ack or
Window-up Ack). If between 1 to 3 datagrams are lost, the window Window-up Ack). If between 1 to 3 datagrams are lost, the window
length shall be decreased by 1. If between 4 to 7 datagrams are lost, length shall be decreased by 1. If between 4 to 7 datagrams are lost,
the window length shall be decreased by 2. If 8 or more datagrams are the window length shall be decreased by 2. If 8 or more datagrams are
lost, the window length shall be decreased by 4. lost, the window length shall be decreased by 4.
Any time a Window Up is sent to the receiving endpoint the sender's Any time a Window-up Ack is received by an endpoint, as a response to
window length shall be decreased by 1. Also, if a timeout forces a a previous Window-up it sent, the endpoint shall decrease its window
retransmission the sender's window length shall be reduced to half of by 1 if the window has not advanced from the time at which the
its currently value. Window-up was sent out.
Also, if a timeout forces a retransmission the sender's window length
shall be reduced to half of its currently value.
The following table summarizes these rules: The following table summarizes these rules:
----------------------------------------------------------------- -----------------------------------------------------------------
duplicate ack received by sender | Adjust down by 4 duplicate ack received by sender | Adjust down by 4
----------------------------------------------------------------- -----------------------------------------------------------------
8 or more datagrams lost | Adjust down by 4 8 or more datagrams lost | Adjust down by 4
----------------------------------------------------------------- -----------------------------------------------------------------
4 to 7 datagrams lost | Adjust down by 2 4 to 7 datagrams lost | Adjust down by 2
----------------------------------------------------------------- -----------------------------------------------------------------
1 to 3 datagrams lost | Adjust down by 1 1 to 3 datagrams lost | Adjust down by 1
----------------------------------------------------------------- -----------------------------------------------------------------
Timeout forced retransmission | Adjust down by 1/2 of the Timeout forced retransmission | Adjust down by 1/2 of the
| current window. | current window.
----------------------------------------------------------------- -----------------------------------------------------------------
Window up sent | Adjust down by 1 Window-up Ack received and the | Adjust down by 1
window has not advanced. |
----------------------------------------------------------------- -----------------------------------------------------------------
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) |
----------------------------------------------------------------- -----------------------------------------------------------------
1/2 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) |
----------------------------------------------------------------- -----------------------------------------------------------------
5.2 Send Timer Back-off at Re-transmission 5.2 Send Timer Back-off at Re-transmission
Whenever a T3-send timer expires, the endpoint shall re-transmit the Whenever a T3-send timer expires, the endpoint shall re-transmit the
un-acked datagram that has the highest TSN Send value in that and un-acked datagram that has the highest TSN Send value and re-start the
re-start the T3-send timer, unless: T3-send timer, unless:
A) If the current window length is reached, a Window-up message shall A) If the current window length is reached, a Window-up message shall
be sent out (see section 5.1), or be sent out (see section 5.1), or
B) If the current window length is not reached and there is still user B) If the current window length is not reached and there is still user
data pending for transmission, a new datagram with user data shall data pending for transmission, a new datagram with user data shall
be sent out and T3-send timer shall be restarted. be sent out and T3-send timer shall be restarted.
When the T3-send timer is re-started at a retransmission, the length When the T3-send timer is re-started at a retransmission, the
of the timer shall be doubled from its previous value. Also, the following back-off rules shall be applied to determine the value of
latest estimated RTT value for that network should be added to the new the new timer:
timer value. The following shows the calculation of T3-send timer
value, where 'TL3-default' is a configurable protocol parameter.
<at normal transmission>
1. TL3-value = 'TL3-default'
2. T3-send = TL3-value + RTT
<at re-transmissions>
1. TL3-value = TL3-value * 2 1. TL3-value = TL3-value * 2
2. T3-send = TL3-value + RTT
The T3-send timer at the sender shall be restored to its default value 2. T3-send = TL3-value + network-RTT
when a datagram is received from the peer endpoint.
where, TL3-value is the protocol variable keeping the previous and
current T3-send timer base value, and the network-RTT is the current
RTT measurement of the destination IP address the re-transmission is
to be sent to.
Note: the T3-send timer base value shall be restored to its default
value 'TL3-default' when a datagram is received from the peer
endpoint.
The total number of consecutive re-transmissions to all destination IP The total number of consecutive re-transmissions to all destination IP
addresses in an association shall be recorded. If this value exceeds addresses in an association shall be recorded. If this value exceeds
the limit defined in 'Max.Retransmit', the sending endpoint shall the limit defined in 'Max.Retransmit', the sending endpoint shall
consider the peer endpoint unreachable and shall stop transmitting any consider the peer endpoint unreachable and shall stop transmitting any
more data to it. The sending endpoint MAY report the failure to the more data to it. The sending endpoint MAY report the failure to the
upper layer, including all datagrams in its out-bound buffer which upper layer, including all datagrams in its out-bound buffer which
have not been acknowledged. Whenever a datagram is received from a have not been acknowledged. Whenever a datagram is received from a
peer endpoint the total number of retransmissions shall be cleared. peer endpoint the total number of retransmissions shall be cleared.
skipping to change at page 26, line 32 skipping to change at page 26, line 32
network on which the RTT-request arrives if the recipient is network on which the RTT-request arrives if the recipient is
multi-homed), with the time mark carried in the original RTT-request multi-homed), with the time mark carried in the original RTT-request
copied into its own Time value fields. copied into its own Time value fields.
Upon the reception of this reply, the sender shall use the time mark Upon the reception of this reply, the sender shall use the time mark
in the reply RTT-ack to calculate the RTT (to the specific destination in the reply RTT-ack to calculate the RTT (to the specific destination
IP address if redundant networks exist) as defined in [4]. IP address if redundant networks exist) as defined in [4].
Endpoint A Endpoint Z Endpoint A Endpoint Z
{RTT - Request Now=x.y} {RTT - Request Now=x.y}
RTT-request (C/D=10) RTT-request
[Time-value1=x, [Time-value1=x,
Time-value2=y, Time-value2=y,
Seen=81] -----------------------> Seen=81] ----------------------->
/------- RTT-ack (C/D=10) /------- RTT-ack
/ [Time-value1=x, / [Time-value1=x,
/ Time-value2=y, / Time-value2=y,
/ Seen=3] / Seen=3]
(Endpoint A uses <----------/ (Endpoint A uses <----------/
x.y to calculate RTT) x.y to calculate RTT)
6.3 Network Heart Beat 6.3 Network Heart Beat
At the request of its upper layer, an endpoint shall enable heart beat At the request of its upper layer, an endpoint shall enable heart beat
to a specific peer with which it has an established association. to a specific peer with which it has an established association.
skipping to change at page 27, line 13 skipping to change at page 27, line 13
well as the new RTT measurement, shall be stored by the endpoint. well as the new RTT measurement, shall be stored by the endpoint.
When the T5-heartBeat timer expires, the endpoint shall first check if When the T5-heartBeat timer expires, the endpoint shall first check if
the previous heart beat has been responded to (on the same network it the previous heart beat has been responded to (on the same network it
was sent in the case of multi-homed hosts). If not, the destination IP was sent in the case of multi-homed hosts). If not, the destination IP
address to which the last heart beat was sent shall have the address to which the last heart beat was sent shall have the
'retran.count' incremented and checked following the rules described 'retran.count' incremented and checked following the rules described
in section 6.1. Then, the endpoint shall send another heart beat and in section 6.1. Then, the endpoint shall send another heart beat and
re-start the T5-heartBeat timer. re-start the T5-heartBeat timer.
In the case where one or both endpoints are multi-homed, the sending of In the case where one or both endpoints are multi-homed, the sending
Heart beats shall follow the network rotation rules outlined in of Heart beats shall follow the network rotation rules outlined in
section 4.2. section 4.2.
If, before the expiration of T5-heartBeat timer, a datagram is If, before the expiration of T5-heartBeat timer, a datagram is
received by the endpoint, the T5-heartBeat timer shall be stopped and received by the endpoint, the T5-heartBeat timer shall be stopped and
the appropriate T2-receive timer shall be started. In other words, the restarted.
T5-heartBeat timer has the lower precedence than the T2-receive timer.
When there are no datagrams to send and no other timers are running,
the T5-heartBeat timer shall be started and the above procedure shall
continue.
The suggested interval for T5-heartBeat timer is 4000 ms, and may be The suggested interval for T5-heartBeat timer is 4000 ms, and may be
dynamically adjusted by adding the current RTT measurement if it is dynamically adjusted by adding the current RTT measurement if it is
available. available.
7. Termination of Association 7. Termination of Association
Before an endpoint terminates itself, it shall send an Abort message Before an endpoint terminates itself, it shall send an Abort message
to each of its peer endpoints in all existing associations. The Abort to each of its peer endpoints in all existing associations. The Abort
shall be sent without requiring an acknowledgment from the peer shall be sent without requiring an acknowledgment from the peer
skipping to change at page 27, line 48 skipping to change at page 27, line 43
When the peer endpoint receives the Abort, after verifying the Tag, When the peer endpoint receives the Abort, after verifying the Tag,
the peer shall remove the sender from its record, and optionally the peer shall remove the sender from its record, and optionally
report the termination of the sender to its upper layer. However if report the termination of the sender to its upper layer. However if
the Tag sent with the Abort message is incorrect, the peer must the Tag sent with the Abort message is incorrect, the peer must
silently discard the Abort message. silently discard the Abort message.
The following shows an example of the termination of Endpoint A: The following shows an example of the termination of Endpoint A:
Endpoint A Endpoint A
{App indicates termination} {App indicates termination}
Abort (C/D = 10) Abort
[Tag-X] --------------------------------> to Endpoint X [Tag-X] --------------------------------> to Endpoint X
Abort (C/D = 10) Abort
[Tag-Y] --------------------------------> to Endpoint Y [Tag-Y] --------------------------------> to Endpoint Y
Abort (C/D = 10) Abort
[Tag-Z] --------------------------------> to Endpoint Z [Tag-Z] --------------------------------> to Endpoint Z
7.1 Graceful Shutdown of an Association 7.1 Graceful Shutdown of an Association
An endpoint in an association may decide to "graceful shutdown" the An endpoint in an association may decide to "graceful shutdown" the
association without completely closing it down. With graceful association without completely closing it down. With graceful
shutdown, both endpoints shall remove any record and pending datagrams shutdown, both endpoints shall remove any record and pending datagrams
associated with the association. Further communications between the associated with the association. Further communications between the
two endpoints can be resumed by going through a re-initialization two endpoints can be resumed by going through a re-initialization
procedure (see section 3.5.4). procedure (see section 3.5.4).
skipping to change at page 28, line 49 skipping to change at page 28, line 49
datagrams are acknowledged, then start a T4-shutdown timer. The datagrams are acknowledged, then start a T4-shutdown timer. The
endpoint, after receiving the Graceful Shutdown Ack, must also endpoint, after receiving the Graceful Shutdown Ack, must also
validate the Tag value contained in the message. If it does not match validate the Tag value contained in the message. If it does not match
the Tag value that unlocked the association, the message should be the Tag value that unlocked the association, the message should be
silently discarded. silently discarded.
The following sequence shows an example of Graceful Shutdown: The following sequence shows an example of Graceful Shutdown:
Endpoint A Endpoint X Endpoint A Endpoint X
{App indicates graceful shutdown} {App indicates graceful shutdown}
Graceful Shutdown (C/D=10) Graceful Shutdown
[Tag-X, Seen=10] ---------------------> (all datagrams resolved) [Tag-X, Seen=10] ---------------------> (all datagrams resolved)
(start T3-send timer) /-------- Graceful Shutdown Ack (C/D=10) (start T3-send timer) /-------- Graceful Shutdown Ack
/ [Tag-A] / [Tag-A]
/ (start T4-shutdown timer) / (start T4-shutdown timer)
(cancel T3-send timer) <------/ ... (cancel T3-send timer) <------/ ...
(clean-up the association) (T4-shutdown expires) (clean-up the association) (T4-shutdown expires)
(clean-up the association) (clean-up the association)
Both endpoints shall reject any new data request from their upper layers Both endpoints shall reject any new data request from their upper layers
while the graceful shutdown procedure is in progress. while the graceful shutdown procedure is in progress.
8. Stream Operations 8. Stream Operations
8.1 Stream Initiation 8.1 Stream Initiation
An MDTP association between the two endpoints must be established An MDTP association between the two endpoints must be established
before any stream operation. before any stream operation.
Except for the global stream (i.e, stream id 0), a stream shall be Except for the global stream (i.e, stream 0) and the pre-opened
initiated (opened) by the sender before any datagrams can be sent in streams (see section 3.1.1), a stream shall be initiated (opened) by
that stream. When a stream is no longer used, it shall be terminated the sender before datagrams can be passed in that stream. When a
(closed) by the user. Moreover, both sides of the association shall be stream is no longer used, it shall be terminated (closed) by the
able to initiate or terminate streams independently. endpoint that opened the stream. Moreover, both sides of the
association shall be able to initiate or terminate streams
independently. Streams are unidirectional.
The sender initiates a stream by sending a Stream Initiation. In The sender initiates a stream by sending a Stream Initiation. In
addition to specifying the Stream Identifier, the sender must set the addition to specifying the Stream Identifier, the sender must set the
Init-Tag field of the Stream Initiation to the Tag value of the peer Init-Tag field of the Stream Initiation to the Tag value of the peer
endpoint. endpoint.
The sender shall also attach the stream-specific data, if any (usually The sender shall also attach the stream-specific data if any (usually
provided by the upper layer), with the Stream Initiation. Otherwise, provided by the upper layer), with the Stream Initiation. Otherwise,
the Size of Stream Info shall be set to 0x0. the Size of Stream Info field shall be set to 0x0.
Then, the sender shall start a T3-send timer. If the T3-send timer After sending out the Stream Initiation, the sender shall start a
expires, the sender shall re-transmit the Stream Initiation. T6-streamInit timer. If this timer expires, the sender shall
re-transmit the Stream Initiation. The value and adjustment rules of
T6-streamInit timer is the same as that of the T3-send timer (see
sections 4.1.1 and 5.2).
Upon the reception of the Stream Initiation, the peer must first Upon the reception of the Stream Initiation, the peer must first
verify that the correct Tag value is carried in the Init-Tag field of verify that the correct Tag value is carried in the Init-Tag field of
the Stream Initiation. If so, the peer shall respond immediately with the Stream Initiation. The peer must silently discard the Stream
a Stream Initiation Ack. Otherwise, the peer must silently discard the Initiation if the tag value is found incorrect.
Stream Initiation.
Then, the peer shall respond immediately with either a Stream
Initiation Ack if it chooses to establish the requested stream, or a
Stream Initiation Nack if it chooses to reject the request for reasons
such as lack of resources.
The arrival of the Stream Initiation Ack or Nack shall cause the
sender to cancel its T6-streamInit timer.
The following example shows the opening of stream 5 by "A": The following example shows the opening of stream 5 by "A":
Endpoint A Endpoint Z Endpoint A Endpoint Z
{App Initiates stream 5} {App Initiates stream 5}
Stream Initiation (C/D=10) Stream Initiation
[Tag=Tag-Z,Strm=5] -----------------> [Tag=Tag-Z,Strm=5] -------------\
(Start T3-send timer) (Start T6-streamInit timer) \
(Cancel T3-send timer) <----------------- Stream Initiation Ack \------>
(C/D=10) [Strm=5] (Cancel T6-streamInit timer) <----------------- Stream Initiation Ack
[Strm=5]
8.2 Stream Termination 8.2 Stream Termination
An endpoint shall be allowed to terminate one of its streams by An endpoint shall be allowed to terminate any one of the streams it
sending a Stream Termination to the other side. opened, by sending a Stream Termination to its peer. However,
stream 0 is not allowed to be terminated, and if an endpoint receives a
termination message for stream 0 it must silently discard the message.
The same Tag verification process used for stream initiation shall The same Tag verification process and timer rules used for stream
be applied to stream termination. initiation shall be applied to stream termination.
The peer shall send a Stream Termination Ack in response to the Stream The peer shall immediately send a Stream Termination Ack in response
Termination. to the Stream Termination.
The following example shows the termination of stream 5 by "A": The following example shows the termination of stream 5 by "A":
Endpoint A Endpoint Z Endpoint A Endpoint Z
{App closes stream 5} {App closes stream 5}
Stream Termination (C/D=10) Stream Termination
[Tag=Tag-Z,Strm=5] -------------------> [Tag=Tag-Z,Strm=5] ---------------\
(Start T3-send timer) (Start T6-streamInit timer) \
(Cancel T3-send timer) <------------------ Stream Termination Ack \------>
(C/D=10) [Strm=5] (Cancel T6-streamInit timer) <------------------ Stream Termination Ack
[Strm=5]
Received datagrams associated with a terminated stream shall be Received datagrams associated with a terminated stream shall be
silently discarded. It is up to the endpoint to assure that all silently discarded. It is up to the endpoint to assure that all
outstanding user datagrams in the stream are acknowledged before the outstanding user datagrams in the stream are acknowledged before the
stream termination. stream termination.
8.3 Other Issues with Stream Operations 8.3 Other Issues with Stream Operations
When an association is re-initialized (see section 3.5.4), all existing When an association is re-initialized (see section 3.5.4), all existing
streams within that association will be automatically terminated. streams within that association will be automatically terminated.
skipping to change at page 32, line 23 skipping to change at page 32, line 23
This primitive shall return the first datagram in the MDTP in-queue to 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 ULP, if there is one available. It may, depending on the specific
implementation, also return other informations such as the sender's implementation, also return other informations such as the sender's
address, whether there are more datagrams available for retrieval, address, whether there are more datagrams available for retrieval,
etc. The behavior is undefined if no datagram is available when this etc. The behavior is undefined if no datagram is available when this
primitive is invoked. primitive is invoked.
Mandatory attributes: Mandatory attributes:
o buffer - the memory location indicated by the ULP to store the o buffer - the memory location indicated by the ULP to store the
received datagram and other information. received datagram.
Optional attributes: Optional attributes:
None. o associationID - the storage to be filled with one of the IP
address/port pair of the peer endpoint that sent this datagram.
F) Data.Arrive notification F) Data.Arrive notification
MDTP shall invoke this notification on the ULP when a datagram is MDTP shall invoke this notification on the ULP when a datagram is
successfully received and ready for retrieval. successfully received and ready for retrieval.
G) Send.Failure notification G) Send.Failure notification
If a datagram can not be delivered MDTP shall invoke this notification If a datagram can not be delivered MDTP shall invoke this notification
on the ULP. on the ULP.
The following may be optionally be passed with the notification: The following may be optionally be passed with the notification:
o data - the location ULP can find the un-delivered datagram. o data - the location ULP can find the un-delivered datagram.
o context - optional information associated with this datagram (see o context - optional information associated with this datagram (see
D). D).
o associationID - One of the IP address/port pair of the peer this
datagram was attempted to be sent to.
H) Network.Status.Change notification H) Network.Status.Change notification
When a endpoint-id is marked down (e.g., when MDTP detects a failure), When a endpoint-id is marked down (e.g., when MDTP detects a failure),
or marked up (e.g., when MDTP detects a recovery), MDTP shall or marked up (e.g., when MDTP detects a recovery), MDTP shall
invoke this notification on the ULP. invoke this notification on the ULP.
The following shall be passed with the notification: The following shall be passed with the notification:
o endpoint-id - This indicates the IP address/port of the o endpoint-id - This indicates the IP address/port of the
skipping to change at page 33, line 26 skipping to change at page 33, line 26
When MDTP loses communication to an endpoint completely or detects When MDTP loses communication to an endpoint completely or detects
that the endpoint has performed a abort or graceful shutdown that the endpoint has performed a abort or graceful shutdown
operation, it shall invoke this notification on the ULP. operation, it shall invoke this notification on the ULP.
The following shall be passed with the notification: The following shall be passed with the notification:
o status - This indicates what type of event that has occurred; o status - This indicates what type of event that has occurred;
o associationID - An IP address/port number to identify the peer o associationID - An IP address/port number to identify the peer
endpoint; endpoint;
The following may be optionally passed with the notification:
o packets-enqueue - The number and location of un-sent datagrams o packets-enqueue - The number and location of un-sent datagrams
still holding by MDTP; still holding by MDTP;
o last-acked - the sequence number last acked by that peer endpoint; o last-acked - the sequence number last acked by that peer endpoint;
o last-sent - the sequence number last sent to that peer endpoint; o last-sent - the sequence number last sent to that peer endpoint;
K) Change.Network.Rotation primitive K) Change.Network.Rotation primitive
When the upper layer wants to inform MDTP to make a specific network When the upper layer wants to inform MDTP to make a specific network
eligible or ineligible for in network rotation, the upper layer will send eligible or ineligible for in network rotation, the upper layer will send
this primitive to MDTP. this primitive to MDTP.
Mandatory attributes: Mandatory attributes:
o action - This indicates if the network is to be made eligible or o action - This indicates if the network is to be made eligible or
ineligible for network rotation. ineligible for network rotation.
o network-id - This is the IP address/port of the peer endpoint to o network-id - This is the IP address/port of the peer endpoint to
be added or removed from network rotation consideration. be added or removed from network rotation consideration.
L) Open.Stream primitive L) Open.Stream primitive
This should be used by the upper layer to open a new stream. This should be used by the upper layer to open a new outbound stream.
Mandatory attributes: Mandatory attributes:
o associationID - One of the IP address/port to identify the peer o associationID - One of the IP address/port to identify the peer
endpoint of the association to which the stream is to be opened. An endpoint of the association to which the stream is to be opened. An
association must have existed at the time of stream open. association must have existed at the time of stream open.
Optional attributes: Optional attributes:
streamInfo - The upper layer should use this field to pass any o streamInfo - The upper layer should use this field to pass any
stream-specific data to the other endpoint of the association. stream-specific data to the other endpoint of the association.
Returned attributes: M) Open.Stream.Succeed notification
o The stream number that is opened. This should be used to report the successful opening of an new outbound
stream.
M) Close.Stream primitive Mandatory attributes:
This shall be used by the upper layer to request to close a stream. o associationID - One of the IP address/port to identify the peer
endpoint of the association to which the outbound stream has been
successfully opened.
o streamID - The stream number of the outbound stream assigned by
MDTP.
Optional attributes:
o streamInfo - The streamInfo used for opening this outbound stream.
N) Open.Stream.Rejected notification
This reports to the ULP that the open of an outbound stream is
rejected by the peer endpoint.
Mandatory attributes: Mandatory attributes:
o associationID - One of the IP address/port to identify the peer o associationID - One of the IP address/port to identify the peer
endpoint of the association to which the stream is to be closed. endpoint of the association by which the stream open is rejected.
o stream number - The stream number to identify the stream to be Optional attributes:
o streamInfo - The info used in the failed attempt of the stream
open.
O) Close.Stream notification
This should be used to report the successful closing of an outbound
stream.
Mandatory attributes:
o associationID - One of the IP address/port to identify the peer
endpoint of the association with which the stream is closed.
o streamID - The stream number of the closed stream.
P) Peer.Open.Stream notification
This notifies the ULP that a new inbound steam is opened by a peer
endpoint.
Mandatory attributes:
o associationID - One of the IP address/port to identify the peer
endpoint of the association to which the stream is opened.
o streamID - The stream number of the new inbound stream assigned
by the peer.
Optional attributes:
o streamInfo - The stream-specific Information passed from the peer
endpoint.
Q) Peer.Close.Stream notification
This reports to the ULP the closing by a remote peer of an inbound
stream.
Mandatory attributes:
o associationID - One of the IP address/port to identify the peer
endpoint of the association by which the inbound stream is closed.
o streamID - The stream number of the closed inbound stream.
R) Close.Stream primitive
This shall be used by the upper layer to close an outbound stream.
Mandatory attributes:
o associationID - One of the IP address/port to identify the peer
endpoint of the association to which the outbound stream is to be
closed.
o streamID - The stream identifier to identify the stream to be
closed (this should be the number returned by the Stream.Open closed (this should be the number returned by the Stream.Open
primitive on this stream). primitive on this stream).
10. Suggested MDTP Timer and Protocol Parameter Values 10. Suggested MDTP Timer and Protocol Parameter 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 (TL3-default) T3-send Timer - 160 ms (TL3-default)
T4-shutdown Timer - 300 ms T4-shutdown Timer - 300 ms
T5-heartBeat timer - 4000 ms (TL5-default) T5-heartBeat timer - 4000 ms (TL5-default)
T6-streamInit timer - same as T3-send
The following protocol parameters are recommended: The following protocol parameters are recommended:
Max.Outstanding.dg - 20 messages Max.Outstanding.dg - 20 messages
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
Num.Of.Mcast.Reset.Msg - 5 messages
11. Acknowledgments 11. Abbreviations
MDTP - Multi-network Datagram Transmission Protocol.
NAT - Network Address Translation
RTT - Round Trip Time
TSN - Transport Sequence Number
ULP - Upper Layer Protocol
12. Acknowledgments
The authors wish to thank Brian Wyld, A. Sankar, Henry Houh, Gary The authors wish to thank Brian Wyld, A. Sankar, Henry Houh, Gary
Lehecka, Ken Morneault, Lyndon Ong, Greg Sidebottom and others for Lehecka, Lyndon Ong, Greg Sidebottom, Lixia Zhang, Jarno Rajahalme,
their very valuable comments. Heinz Prantner, Matt Holdrege, Kelvin Porter, Richard Band, and many
others for their invaluable comments.
12. Authors' Addresses 13. Authors' 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
Suheel Hussain Tel: +1-919-472-2312 Ken Morneau Tel: +1-703-484-3323
Cisco Systems Inc. EMail:ssh@cisco.com Cisco Systems Inc. EMail:kmorneau@cisco.com
7025 Kit Creek Road 13615 Dulles Technology Drive
Research Triangle Park, NC 27709 Herndon, VA. 20171
Chip Sharp Tel: +1-919-851-2085 Chip Sharp Tel: +1-919-851-2085
Cisco Systems Inc. EMail:chsharp@cisco.com Cisco Systems Inc. EMail:chsharp@cisco.com
7025 Kit Creek Road 7025 Kit Creek Road
Research Triangle Park, NC 27709 Research Triangle Park, NC 27709
Hanns Juergen Schwarzbauer Tel: +49-89-722-24236 Hanns Juergen Schwarzbauer Tel: +49-89-722-24236
SIEMENS AG SIEMENS AG
Hofmannstr. 51 Hofmannstr. 51
81359 Munich, Germany 81359 Munich, Germany
skipping to change at page 35, line 39 skipping to change at page 35, line 39
Nortel Networks EMail:taylor@nortelnetworks.com Nortel Networks EMail:taylor@nortelnetworks.com
1852 Lorraine Ave. 1852 Lorraine Ave.
Ottawa Ontario Canada Ottawa Ontario Canada
K1H6Z8 K1H6Z8
Ian Rytina Tel: Ian Rytina Tel:
Ericsson Australia EMail:ian.rytina@ericsson.com Ericsson Australia EMail:ian.rytina@ericsson.com
37/360 Elizabeth Street 37/360 Elizabeth Street
Melbourne, Victoria 3000, Australia Melbourne, Victoria 3000, Australia
13. References 14. 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.
skipping to change at page 36, line 14 skipping to change at page 36, line 14
[6] Rytina, I., "Framework for Generic Common Signaling Transport [6] Rytina, I., "Framework for Generic Common Signaling Transport
Protocol", draft-rytina-sigtran-generic-framework-00.txt>, Feb. 1999. Protocol", draft-rytina-sigtran-generic-framework-00.txt>, Feb. 1999.
[7] Ashworth, J., "The Naming of Hosts", RFC 2100, April 1997. [7] Ashworth, J., "The Naming of Hosts", RFC 2100, April 1997.
[8] Braden, R., "Requirements for Internet hosts - Application and [8] Braden, R., "Requirements for Internet hosts - Application and
Support", RFC 1122, October 1989. Support", RFC 1122, October 1989.
[9] Eastlake 3rd, D., Crocker, S., and Schiller, J., "Randomness [9] Eastlake 3rd, D., Crocker, S., and Schiller, J., "Randomness
Recommendations for Security", December 1994. Recommendations for Security", RFC 1750, December 1994.
[10] Bellovin, S., "Defending Against Sequence Number Attacks",
[11] ITU-T Recommendation Q.703 "Q.703 - Signaling link", July 1996.
This Internet Draft expires in 6 months from June 1999. This Internet Draft expires in 6 months from June 1999.
 End of changes. 

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