view Side-By-Side changes

INTERNET-DRAFT                                                  Motorola                                                    Q. Xie
                                                                Motorola
Expires
                                                                 T. Bova
                                                               S Hussain
                                                           T Krivoruchka
                                                                R. Revis
                                                                   Cisco

expires in six months                                       1                                      April 19 1999

           MULTI_NETWORK DATAGRAM TRANSMISSION PROTOCOL
                 <draft-ietf-sigtran-mdtp-03.txt>
                <draft-ietf-sigtran-mdtp-04.txt>

Status of This Memo

This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups.  Note that other groups may also distribute
working documents as Internet-Drafts.

The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt

The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.

Abstract

This Internet Draft discusses an experimental call control signaling
transport protocol, namely the Multi-network Datagram Transmission
Protocol (MDTP), that is intended to provide fault-tolerant reliable/unreliable reliable
data transfer between communicating processes entities over IP networks [1].

MDTP is proposed as an application-level protocol which is designed
with a high emphasis on supporting redundant networks and transparent
fault management. MDTP also gives the application user a great degree of timing
control and configuration flexibilities. flexibilities in order to meet the stringent
time constraints often found in telephony signaling protocols. The
motivation of developing MDTP is to establish a framework for
supporting Internet-based high reliability real-time commercial
applications such as signaling and call control for Internet
telephony.








Stewart & Xie                                                  [Page  1]

Internet Draft   Multi-network Datagram Transmission Protocol   Apr 1999

                        TABLE OF CONTENTS

1.  Introduction..............................................3  Introduction
     1.1 Multi-network Datagram Transmission Protocol.........3 Design Requirements of MDTP
     1.2 Interfaces to MDTP...................................4
     1.3 Operation of MDTP....................................5 MDTP
2.  Design Principles.........................................5
3.  Header Format.............................................6
     3.1  MDTP Header Datagram Format Description.......................9
     3.2 Notes on Multicast
     2.1 Header format....................12
4. Field Descriptions
     2.2 Data Field
3.  Transmission Initialization..............................12
     4.1 Normal Initialization...............................12
     4.2 Multiple Network Addresses..........................14
     4.3 Initialization Collision............................15
     4.4 Re-initialization...................................16
     4.5 Link rotation.......................................16
5.
     3.1 Endpoint Association Initialization
       3.1.1 Choice of Tag Value
     3.2 Data Field Format of Initiation Datagrams
     3.3 Initialization Collision
     3.4 Association Re-initialization
4.  Reliable Transfer Mode...................................17
     5.1 of Datagrams
     4.1 Timer Control.......................................19
     5.2 Management Rules
       4.1.1 Link Rotation
     4.2 Gap Acknowledgments.................................21
     5.3 Acknowledgment for Missing Datagrams
     4.3 Congestion Control..................................23
     5.4 Control
       4.3.1 Sending with Window Control
       4.3.2 Window Length Adjustment
       4.3.3 Flow Control using In-Queue Information
       4.3.4 T3-send Timer Adjustment with RTT
     4.4 Sequence Number Reset...............................26
     5.5 Retransmission Reset
     4.5 Datagram Re-transmission
       4.5.1 Re-transmission on Multiple Networks.................27
       5.5.1 Randomization of the T3-Send timer at resend ...28
     5.6 Termination of an Endpoint..........................28
     5.7 Endpoint Drain......................................29
     5.8 Advisory Acknowledgments...........................29
     5.9 Redundant networks
     4.6 RTT Measurement
       4.6.1 RTT Datagram Header Format
       4.6.2 Measure RTT Measurement.....................................30
     5.10
     4.7 Link Heart Beat Ack.....................................32
     4.8 Advisory Acknowledgment
     4.9 Termination of an Association
     4.10 Draining of an Association
5. Interface with upper level protocols
6.  Unreliable Transfer Mode.................................33
     6.1 Ordered reception..................................34 Suggested MDTP Protocol Parameter Values
7.  Reliable flows...........................................35
     7.1 Initiating a flow...................................36
     7.2 Flow acknowledgments................................37
     7.3 Flow session closing................................41 Acknowledgments
8.  Mixed Mode Data Transmission.............................42 Author's Addresses
9. References
Appendix A: Stream-based Reliable and Ordered Delivery
     A.1 Stream Initiation
     A.2 Stream Termination
     A.3 Stream Datagram Transfer
       A.3.1 Header Format in Stream Datagrams with User Data
       A.3.2 Transmission of Stream Datagrams
       A.3.3 Extended Stream Ack
     A.4 Other Issues with Stream Transfer
Appendix B: Bundled Messages.........................................43
     9.1 Message Transfer
     B.1 Format of Bundled Datagram..........................44
     9.2 Datagram
     B.2 Bundled Transfer....................................45
10. Datagram Transfer
Appendix C: Fragmented Messages......................................46
11. Non-protocol Datagrams...................................47
12. Broadcast and Multicast..................................48
     12.1 Multicast/Broadcast Initialization.................48
     12.2 Transmission of Broadcast Datagrams................48
     12.3 Transmission of Multicast Datagrams................49
     12.4 Reset of the Message Transfer
Appendix D: Multicast Datagram Sequence Number....50
13. Interface with upper level protocols.....................51
13.1 Init.MDTP primitive.....................................52
13.2 Send.Data primitive.....................................52
13.3 Receive.Data primitive..................................52
13.4 Data.Arrive notification................................53
13.5 Send.Failure notification...............................53
13.5 Link.Status.Change notification.........................53



Stewart & Xie                                                  [Page  2]

Internet Draft   Multi-network Transfer
     D.1 Multicast Datagram Header Format
     D.2 Transmission Protocol   Apr 1999


13.6 Communication.Lost notification.........................53
14. Suggested Timer and Protocol Parameter Values............54
15. Acknowledgments.........................................54
16. Author's Addresses.......................................54
17. References...............................................55 of Multicast Datagrams
Appendix E: Unreliable Delivery
     E.1 Ordered Unreliable Delivery

1.  Introduction

This Internet Draft discusses an experimental protocol, namely the
Multi-network Datagram Transmission Protocol (MDTP), that (MDTP). The intention of
developing MDTP is intended to provide fault-tolerant reliable/unreliable a fault-tolerant, real-time reliable
data transfer mechanism between communicating processes endpoints over IP
networks [1].

MDTP is proposed as an application-level protocol which is designed
with a high emphasis on supporting redundant networks and transparent
fault management. MDTP also gives the application user a great degree of timing
control and configuration flexibilities. flexibilities in order to meet the stringent
time constraints often found in telephony signaling protocols. The
motivation of developing MDTP is to establish a framework for
supporting Internet-based high reliability real-time commercial
applications such as signaling and call control for Internet
telephony.

This document describes the functional interface and the details
necessary

MDTP is also designed to implement be scalable in order to support different
signaling transport requirements for different interfaces in a
telephony network.

For example, the transportation of signaling protocols such as PRI
ISDN may not require redundant links, and hence only a subset of MDTP
will need to be implemented.  On the other hand, redundant networks
may be mandated when transporting SS7 signaling messages amongst
different components in a carrier-grade telephony core network.  In
such cases, the transparent support for redundant networks, load
sharing, and fault management defined in MDTP become essential and
likely need to be fully supported in an implementation.

Many of the fundamental concepts that have made TCP such a useful
protocol are reused in MDTP, and some of the advantages of UDP are
also merged into the design. This has lead to a highly effective,
robust protocol for fault tolerant data communications.

This document describes the functional interface and the details
necessary for implementing MDTP.


1.1 Multi-network Datagram Transmission Protocol (MDTP) The Multi-network Datagram Transmission Protocol (MDTP) presented in main body of this Internet Draft is designed to meet document
contains the minimal set of functionalities of MDTP that must be
implemented. In the Appendices, a set of additional MDTP functions,
such as reliable stream, multicast, message bundling, message
fragmentation, are defined. Those additional functionalities are
optional to implementation.

1.1 Design Requirements of MDTP

The following critical are some of the design requirements common of MDTP, in order to
make MDTP capable of supporting real-time call control environments employing
which potentially may employ redundant networks:

A) A process High communication fan-out: an endpoint may need to be in
   simultaneous communication with hundreds or thousands of endpoints
   performing various call processing functions. These endpoints may
   be codec converters, SS7 to IP translation applications, or, in the
   case of mobile networks, data selector and combiner applications.

B) A process Stringent timer control: an endpoint needs to have a very fine
   control over the timing for delivering a datagram. The timing
   should be easily adjusted depending on the message type and the
   destination. For example, after a few seconds of non-delivery the
   call which the message is about may not exist anymore.

C) A process Support redundant links: an endpoint communicating with a peer
   should be able to take advantage of the redundant networks in a
   transparent way. This means that the application or upper level layer
   protocols need not to be involved in the network fault
   management. Instead, when network failure occurs the transmission protocol MDTP should be
   able to automatically re-route the out-bound datagram to the
   alternate

Stewart & Xie                                                  [Page  3]

Internet Draft   Multi-network Datagram Transmission Protocol   Apr 1999 network (if one exists) without intervention from the
   application.

D) Datagrams Orderly delivery: datagrams may arrive out of order, or may arrive
   in duplicate copies. This is especially true in a if redundant network
   environment. The transmission protocol networks
   are used. MDTP should be strong enough to properly handle both
   situations with little intervention from the upper level protocol layer protocols
   or application.

To accomplish applications.

F) Support stream sequencing: on the above objectives we have defined MDTP to reside in
user-space, i.e., it is not intended to be implemented as a module in
an operating system. This gives demand of the application or upper level layer
   protocols that use MDTP outstanding flexibility in controlling the
timing and other operational characteristics for the data
transmissions.

MDTP is also made multi-network aware. This means that if more than
one path exists between two endpoints (such as redundant LANs), or applications, MDTP
will take advantage of the multiple networks by automatically
switching should be able to the alternate LAN if the datagram support sequenced
   delivery becomes
unavailable or inefficient (e.g., too many re-transmissions) on the
current LAN. The ability with regard to handle multiple networks by MDTP can also
greatly facilitate the implementation of various traffic balancing
schemes in each individual stream, i.e., the application or upper level protocols.

In delay caused
   by the redundant network setting, out-of-order or duplicate datagrams
are proven to be most harmful during MDTP transmission initiations loss and
re-initiations. To cope with the problem, MDTP utilizes retransmission of a very
efficient tag mechanism datagram should be isolated to guard against out-of-order or duplicate
datagrams.

MDTP assumes that a UDP-like [2] transport protocol is available at
   only the
operating system level for data transport. We have successfully 
implemented and tested MDTP over UDP and Sun Microsystem's CLTS
transport layers.

Comparing stream to traditional TCP [3], MDTP design which the datagram belongs. This is more tuned towards particularly
   important in some call control applications, where a
special set loss of applications, that is the time critical fault tolerant
applications using redundant LANs. It is not designed to replace TCP
as a general purpose transmission protocol.
   message should only affect the call whom the message belongs to.

1.2 Interfaces to MDTP

MDTP interfaces with the

The application programs or higher level upper layer protocols interface with MDTP
through a set of function calls. Due to primitives (see section 5. for details).

Towards the fact networks, it is assumed that a UDP-like data transport
protocol will provide the interface between MDTP
is an application level protocol, these calls and the operating
system. No special interfaces or changes are not executed within
the operating system, but within the user process (i.e., in the user
space). The application or higher level protocols pass data to MDTP by
making calls to MDTP, which then enqueues the data for transmission. 
When data arrives, MDTP will distribute the data to the application or
higher level protocols via mechanisms predefined by the application. 
The application also has an interface to change the operational mode
of an MDTP endpoint and the default operational mode of the MDTP
endpoint. The default operational mode is used in the absence of any

Stewart & Xie                                                  [Page  4]

Internet Draft   Multi-network Datagram Transmission Protocol   Apr 1999

specific direction from the application. More details on the MDTP
interface to the upper level protocol/application can be found in
section 13.

As noted above, it is assumed that a UDP-like data transport protocol
will provide the interface between MDTP and the operating system. No
other special interfaces or changes are assumed assumed within the
operating system, all queuing and internal pseudo-connection endpoint association information is are
maintained inside MDTP endpoint.


1.3 Operation of layer.

2.  MDTP Datagram Format

MDTP operates in three different modes. 

   A) Reliable transfer mode
   B) Unreliable transfer mode
   C) Raw UDP transfer mode

The two ends in a communication connection can operate in different
modes with respect to each other, with the exception of inserts the raw UDP
mode. For example, if two endpoints A and B are communicating with
each other. Endpoint A may be sending information to B in reliable
transfer mode, while B, on following protocol header at the other hand, may be sending information
to A in unreliable transfer mode. All communications from A to B will
be acknowledged by B, but A will not need to acknowledge data received
from B.

Raw UDP transfer is used when one beginning of the endpoints in communication
does not support MDTP. This allows compatibility with non-MDTP
endpoints. Two MDTP capable endpoints are also allowed to engage in
communications in raw UDP transfer mode. However, both sides will have
to be in raw UDP mode once one of them indicates to use raw UDP
transfer mode.

MDTP also provides a bundling option for both the reliable and
unreliable transfer modes. This allows each side to hold the data
before transmission for some period of time, so that small datagrams
can be combined and sent in a single larger datagram to improve
network utilization efficiency.


2.  Design Principles

One of the major objectives which dictates the design of MDTP is to
provide a data transmission protocol that transparently supports highly
fault tolerant implementations. To accomplish this, provisions for two
endpoints engaging in communication to use multiple networks is
essential. MDTP is therefore designed to yield the best fault
tolerance when the application shares the load over multiple network
connections.

In cases of failed original transmission, MDTP provides the ability of
attempting retransmissions using an alternate network connection even

Stewart & Xie                                                  [Page  5]

Internet Draft   Multi-network Datagram Transmission Protocol   Apr 1999

when the upper level protocol or the application is completely
ignorant of the existence of the alternate route.

Many of the fundamental concepts that have made TCP such a useful
protocol are reused, and some of the advantages of UDP are also merged
into the design of MDTP. This has lead to a highly effective, robust
protocol for fault tolerant data communications.

3.  Header Format

MDTP inserts at the beginning of every datagram a header. This header
is composed of various flags and integers. The integers are always kept every
user datagram. The integer fields shall be transmitted in network byte
order. The following table illustrates the common
MDTP header overlay. Note that one tick mark represents one bit 
position.

                         MDTP Header Format - Non Multicast

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  MDTP Protocol Identifier 1                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 MDTP Protocol Identifier 2   Version     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Acknowledgment Number (Seen)              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Sequence Number (Send)                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        Data Size              |    Part       |      Of       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Flags      |     Mode      |   Version              Flags            |   In Queue    |
   |               |N N W I F R D A|B A M S W R R B F G U|               |
   |               |O O I S I E T A C|R C U H N E E U T L A N|               |
   |
   |G               |M B N B R S M T K|O K L U R 1 2 N C O R R|               |               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   \                                                               \
   /                             data                              /
   \                                                               \
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+















Stewart & Xie                                                  [Page  6]

Internet Draft   Multi-network Datagram Transmission Protocol   Apr 1999

                 MDTP Header Format - Multicast Format
                                    
    0                   1                   2                   3   
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 MDTP Protocol Identifier 1                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 MDTP Protocol Identifier 2                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                Acknowledgment Number (Seen)                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   Sequence Number (Send)                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        Data Size              |    Part       |      Of       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Flags      |     Mode      |   Version     |   In Queue    |
   |N N W I F R D A|B S W R R B G U|               |               |
   |O O I S I E A C|R H N E E U A N|               |               |
   |G B N B R S T K|O U R 1 2 N R R|               |               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  Multicast To Transmit address                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |             Multicast From - senders base address             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   \                                                               \
   /                             data                              /
   \                                                               \
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                   MDTP

2.1 Header Format - RTT Ack
                                    
    0                   1                   2                   3   
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Field Descriptions

    MDTP Protocol Identifier 1                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 MDTP Identifier: 32 bits

      This shall be a fixed long value of 0xf7873072. The receiver
      shall always verify this Protocol Identifier 2                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Acknowledgment Number (Seen)              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Sequence Number (Send)                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        Data Size              |    Part       |      Of       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Flags      |     Mode      |   Version     |   In Queue    |
   |N N W I F R D A|B S W R R B G U|               |               |
   |O O I S I E A C|R H N E E U A N|               |               |
   |G B N B R S T K|O U R 1 2 N R R|               |               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  Transparent Time Int-1                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  Transparent Time Int-2                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


Stewart & Xie                                                  [Page  7]

Internet Draft   Multi-network Datagram Transmission Protocol   Apr 1999


                   Flow Initiate/Close Message
                                    
    0                   1                   2                   3   
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 MDTP Protocol Identifier 1                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 MDTP Protocol Identifier 2                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Acknowledgment Number (Seen/flow num)       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Sequence Number (Send)                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        Data Size              |    Part       |      Of       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Flags      |     Mode      |   Version     |   In Queue    |
   |N N W I F R D A|B S W R R B G U|               |               |
   |O O I S I E A C|R H N E E U A N|               |               |
   |G B N B R S T K|O U R 1 2 N R R|               |               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Ack Flow (opening)  |        Ack datagram number    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                   Flow Extended Acknowledgment
                                    
    0                   1                   2                   3   
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 MDTP Protocol Identifier 1                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 MDTP Protocol Identifier 2                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Ack Flow (Seen)     |        Ack datagram number    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Number of flow Acks                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        Data Size              |    Part       |      Of       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Flags      |     Mode      |   Version     |   In Queue    |
   |N N W I F R D A|B S W R R B G U|               |               |
   |O O I S I E A C|R H N E E U A N|               |               |
   |G B N B R S T K|O U R 1 2 N R R|               |               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Ack Flow (Seen)     |        Ack datagram number    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   \                                                               /
   /                 one for each 'Number of flow Acks'            \
   \                                                               /
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Ack Flow (Seen)     |        Ack datagram number    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



Stewart & Xie                                                  [Page  8]

Internet Draft   Multi-network Datagram Transmission Protocol   Apr 1999


3.1 MDTP Header Format

    MDTP Protocol Identifier 1: 32 bits

      This is a fixed long value of 0xf7873072. 

    MDTP Protocol Identifier 2: 32 bits

      This is a fixed long value of 0x17074012. MDTP Protocol 
      Identifier 1 and 2 are jointly examined to determine a received 
      datagram is an MDTP protocol datagram.

    Acknowledgment Number (or Seen): 32 bits

      If the flag ACK is set this value is the next sequence number
      that the sender of this datagram expects to receive from the 
      receiver of this datagram. 

      However, during initialization negotiation, multicast and
      broadcast transmissions, this field will have special meanings
      (see 4 and 11).

    Sequence Number (or Send): 32 bits

      If DAT flag is set, this value represents the sequence number of 
      the first data octet that follows this header. Otherwise, this 
      value will be the sequence number of the first octet of the next 
      data unit that will be sent. 

      However, during initialization negotiation, multicast and
      broadcast transmissions, this field will have special meanings
      (see 4 and 11).

    Part: 8 bits

      This value represents the Part number of a fragmented message. The
      first fragment of a message is always part '0'. 

    Of: 8 bits

      This value represents the total number of fragments in a 
      fragmented message. The valid range for this value is from '1' 
      to '255'. For broadcast and multicast datagrams this value is 
      set to '1' to indicate that no fragmentation should occur.

    Data Size: 16 bits

      This value represents, in number of octets, the size of the data
      field that follows this header in the current datagram. 

    Flags: 8 bits

      NOG - No Guaranteed delivery. This bit is used in negotiation

Stewart & Xie                                                  [Page  9]

Internet Draft   Multi-network Datagram Transmission Protocol   Apr 1999


      and is set to indicate that the sender does not wish to use
      reliable delivery. When this bit has been set in negotiation, 
      the receiver should prevent its application from putting 
      communication with this endpoint in reliable mode.
      In normal data transfer (after the initiate sequence) this
      bit should be set to 0, except when responding to a  RTT Ack
      request.

      NOB - No Bundling. This bit is used  in negotiation and
      is set to indicate that the sender does not wish to perform of 
      bundling or un-bundling of datagrams. When this bit has been set 
      in negotiation, the receiver should prevent its application from 
      putting communication with this endpoint in bundled mode.
      In normal data transfer this bit should be set to 0, if this
      bit is set to 1 then this message is part of a flow.

      WIN - Window Up. This bit is set by the sender of this datagram 
      to indicate that the sender needs the receiver to acknowledge on 
      previously received datagrams before it can send more datagrams.

      ISB - Is Bundled. This bit is set by the sender to indicate that 
      this datagram is bundled. This bit should never be set if during 
      negotiation either end set the NOB bit.

      FIR - First Datagram. This flag is set to indicate that this is a 
      negotiation datagram.

      RES - Reset Sequence Number. This bit is set to indicate that the 
      sequence number is being reset. The sequence number should be reset
      whenever the sending count is greater than 0x7fffffff.

      DAT - Data Present. This bit is set to indicate that, following 
      this header, application data is present in this datagram.

      ACK - Acknowledge. This bit is set to indicate that the sender is
      acknowledging receipt of the specified Acknowledgment Number.
    
    Mode: 8 bits

      BRO - Broadcast. This bit is set to indicate a broadcast or 
      multicast datagram. When this bit is set, bit SHU, WNR, BUN, and 
      GAR are not used and should be set to '0'. This datagram is a 
      multicast datagram if the UNR bit is also set. Otherwise, this 
      datagram is a broadcast datagram.

      SHU - Shutdown. This bit is set when the sender initiates its
      closing procedure and indicates to the receiver that the sender
      is no longer a valid destination.	If the UNR bit is set in 
      conjunction with the SHU bit, an incomplete shutdown is 
      specified. After an incomplete shutdown, the receiver can still 
      re-establish the communication with the sender by re-initiating 
      with the sender (see 5.7).


Stewart & Xie                                                  [Page 10]

Internet Draft   Multi-network Datagram Transmission Protocol   Apr 1999


      WNR - Window Up Response. This bit is set in the acknowledgment 
      reply to a Window Up flag.

      RE1 - This bit will represent one of two things. If the GAR
      bit is set to one, then setting the RE1 bit indicates to the
      receiver that the sender is requesting a advisory ACK. This
      is normally sent in a datagram when 1/2 of the current window
      has been sent. If this bit is set to 0 (when the GAR bit is
      set) then the sender is NOT requesting a advisory ACK. 
      If the UNR bit is set then the RE1 bit is set than the receiver 
      is requested to order the datagrams (if more than one have
      not been read). If the receiver has already delivered a datagram
      of higher sequence, then the receiver should discard lower number
      sequence datagrams that arrive late.

      RE2 - This bit will represent one of two things. If the GAR
      bit is set to one, the DAT bit is set to 0 and the ACK bit is
      set to 1 then this is a ACK with a Round Trip Time Request 
      format. This also identifies the RTT Ack header format it
      in place. If the UNR bit is set to 1 and DAT bit is set to 0,
      then this datagram is used in a implementation specific way but
      carries no data. The datagram can be safely ignored and discarded.

      BUN - Bundled Mode. This bit is set to indicate that bundled 
      mode is in effect for the sender. This bit should never be set 
      if during negotiation either endpoint set the NOB flag.

      GAR - Guaranteed Mode. This bit is set to indicate that the 
      reliable mode is in effect for the sender, i.e., the sender 
      expects an acknowledgment. This bit should never be set if 
      either endpoint set the NOG flag during negotiation.

      UNR - Unreliable Mode. This bit is set to indicate that 
      unreliable mode is in effect for the sender and the sender does 
      not expect an acknowledgment. This bit has special meanings if 
      BRO or SHU bit is set (see above).

    Version: 8 bits

      This field represents the version number of the MDTP
      protocol. If these bits are set to 1, then the sender does
      not support Round Trip Time (RTT) calculation or Heart
      Beat of reliable protocol. If these bits are set to 2 then
      this version does support RTT and Heartbeat. If the Version
      is set to 3 then the sender/receiver supports reliable flows.

    In Queue: 8 bits

      This field contains the number of messages the sender has on its 
      incoming queue, waiting to be read by the application. This gives
      the receiver an indication of the flow control conditions within 
      the sender.


Stewart & Xie                                                  [Page 11]

Internet Draft   Multi-network Datagram Transmission Protocol   Apr 1999


The message header is always followed by the data field. If there is
less than 4 octets of application data to send with the datagram, the
data field of the datagram should be padded with all '0' to make it
four (4) octets.  The padded all '0' octets, if there is any, are not
counted in the Data Size.

The maximal Data Size for a single MDTP datagram is the MTU size of
the underlying transport protocol (e.g., UDP) minus the MDTP header
size that is twenty four (24) octets. The combination of the maximal
'Of' value, which is 255, and the maximal Data Size will determined
the maximal size of a single message that the MDTP can send or
receive.

3.2 MDTP Multicast Header Format

The multicast header format is identical to the standard MDTP header
format, as discussed above, except for the following extensions.

Multicast To Transmit address - This is the multicast address, in
network byte order, that the sender transmitted the data to. The
receiver can use this information for internal tracking purposes.

Multicast From - This is the base address (address 0 in the initiate
message, see below) of the sender. Since a multicast sender may not
have gone through the initiate procedures this address is the base
reference that the receiver is to use to lookup the sender. This
network byte order address should be used to reference any internal
cache rather than the arriving network from address.

4.  Transmission Initialization

4.1 Normal Initialization

Before the first data transmission can take place from one endpoint
(A) to another endpoint (Z), the two endpoints will need to complete
an initialization process.

The initialization process consists of the following steps.

A) Endpoint A should first send an initiation datagram, while
   withholding the application data from transmission.

   Endpoint A                                          Endpoint Z
   [Header Flags=FIR|RES
	   Mode=options
	   Seen=0,Send=Tag_A] ----------------------->
   (Start T1-init timer)
   (Enter Tag_A-lock mode)


   The initiation datagram is identified by setting FIR and RES bits in
   the Flags field. No user data should be carried in the initiation 
   datagram.

Stewart & Xie                                                  [Page 12]

Internet Draft   Multi-network Datagram Transmission Protocol   Apr 1999



   The Endpoint A should fill in the appropriate options, e.g., BUN,
   GAR, or UNR, in the Mode field to indicate the transmission type it
   has chosen. It may also use NOB and NOG bits in the Flags field to
   specify to whether or not its peer is allowed for bundling or 
   reliable transfer mode.

   The Seen field will be set to '0', but an initiation tag, Tag_A,
   generated by Endpoint A, will be carried in the Send field, as 
   shown in the above diagram. If re-initializations are needed 
   between two endpoints subsequently (see 4.3), a different tag with 
   a unique value should be used for each re-initialization.

   After sending the initiation datagram, Endpoint A shall start T1-init
   timer and enter a Tag_A-lock mode. 

   During the Tag_A-lock mode, Endpoint A will wait for the initiation
   Ack datagram with the Seen value set to Tag_A. Any other incoming
   datagrams from Endpoint Z, except for new initiation datagrams, 
   will be discarded. The arrival of new initiation datagrams during the
   Tag_A-lock mode indicates an initialization collision that will be
   discussed in 4.3.

   If T1-init timer expires, the same initiation datagram will be
   retransmitted and the timer restarted. This will be repeated
   Max.Init.Retransmit times before Endpoint A considers Endpoint Z
   unreachable and optionally reports the failure.

B) Upon the receipt of the above initiation datagram from Endpoint A,
   Endpoint Z should respond immediately with an initiation Ack as shown
   below: 

   Endpoint A                                 Endpoint Z
                                              [Header Flags=FIR|RES|ACK
					       Mode=Options
				   /---------- Seen=Tag_A,Send=Tag_Z]
				  /           (Enter Tag_Z-lock mode)
   (Cancel T1-init timer)<-------/

   The initiation Ack datagram is specified with FIR, RES, ACK bits set
   to '1' in the Mode field. Similarly, Endpoint Z will specify its
   preferred transmission mode and type by setting proper bits in the
   Mode and Flags fields.

   In addition, in the out-bound initiation Ack datagram, Endpoint Z
   should set the Seen field to Tag_A and supply its own initiation
   tag, Tag_Z, in the Send field. 

   Once the initiation Ack is transmitted, Endpoint Z should enter the
   Tag_Z-lock mode. In the Tag_Z-lock mode Endpoint Z will ignore any
   incoming initiation Ack datagrams and also discard any other incoming
   datagram whose Seen field is not equal to Tag_Z, except for new
   initiation datagrams. 

Stewart & Xie                                                  [Page 13]

Internet Draft   Multi-network Datagram Transmission Protocol   Apr 1999



   If a new initiation datagram is received when Endpoint Z is in
   Tag_Z-lock mode, Endpoint Z will acknowledged the initiation datagram
   only when the tag carried in the Send field matches Tag_A previously
   recorded by Endpoint Z. Otherwise, Endpoint Z will send an initiation
   datagram with Send field set to Tag_Z back to Endpoint A to elicit an
   initiation Ack.

C) After transmitted the initiation Ack, Endpoint Z can start
   transmitting datagrams with user data. However, the Seen field it proceeds
      any further in interpreting the




   first out-bound datagram with user data must be set to Tag_A. 

D) Upon header fields.

    Version: 8 bits

      This field represents the receipt version number of the initiation Ack with Seen equal MDTP protocol
      (value TBD).

    Flags: 16 bits

      NOM - shall be set to Tag_A, 
   Endpoint A can start transmitting datagrams with user data. However,
   the first datagram with application data transmitted by Endpoint A
   should have the Seen value 1 (reserved for fragmentation, see
      Appendix C)

      NOB - shall be set to Tag_Z, which 1 (reserved for bundling, see Appendix B)

      WIN - Window Up. This bit is obtained from the
   initiation Ack. 

   Endpoint A                                     Endpoint Z
   {first app message}
   [Header Flags=ACK|DAT
	   Mode=options
	   Seen=Tag_Z,Send=1]
	   [data field]   -----------\               
				      \               
				       \-------> (Leave Tag_Z-lock mode)

E) Upon set by the receipt sender of the first this datagram with user data from Endpoint
   A and with the Seen value set
      to Tag_Z, Endpoint Z should leave the
   Tag_Z-lock mode.

F) Similarly, upon the receipt of indicate that the first datagram with user data
   and sender needs the Seen value set receiver to Tag_A from Endpoint Z, Endpoint A
   should leave the Tag_A-lock mode.
 
The upper level protocol or application acknowledge on
      previously received datagrams before it can predefine a send more datagrams.

      ISB - shall set of default
transmission modes, which will be used by the endpoint to 0 (reserved for
initialization. However, it should be pointed out that the
transmission modes between two endpoints are allowed bundling, see Appendix B)

      FIR - First Datagram. This flag is set to change on indicate that this is a
datagram by datagram basis, as been illustrated in later chapters.

4.2 Multiple Network Addresses

In order to support multiple networks, both endpoints need to have
knowledge of all network addresses available
      Initiation datagram.

      RTM - normally set to each other. 0 (used for Link Heart Beat and RTT
      measurement, see sections 4.6 and 4.7)

      DAT - Data Present. This
information needs bit is set to be passed indicate that, following
      this header, application data is present in this datagram.

      ACK - Acknowledge. This bit is set to indicate that the other end during sender is
      acknowledging the
initialization. The data field reception of the initiation and initiation Ack
datagrams is used specified Acknowledgment Number.

      MUL - shall be set to 0 (reserved for this purpose.


Stewart & Xie                                                  [Page 14]

Internet Draft   Multi-network Datagram Transmission Protocol   Apr 1999


Depending on multicast, see Appendix D)

      SHU - Shutdown. This bit is set when the underlying network configuration, sender initiates its
      closing procedure and indicates to the data field will
be filled in one of receiver that the two following ways:

A) sender
      is no longer a valid destination. If the sending endpoint of UNR bit is set in
      conjunction with the initiation or initiation Ack
datagram does not have access to multiple networks, SHU bit, an incomplete shutdown is
      specified. After an incomplete shutdown, the data field
will receiver can still
      re-establish the communication with the sender by re-initiating
      with the sender (see 4.7).

      WNR - Window Up Response. This bit is set in the acknowledgment
      reply to a Window Up flag.

      RE1 - normally set to 0 (used for advisory ACK, see section 4.8)

      RTC - normally set to 0, (used for RTT, see section 4.6)

      FLO - shall be set to the pad value of 4 octets of '0's.

B) If the sending endpoint has access 0 (reserved for reliable stream, see
      Appendix A)

      GAR - shall be set to multiple networks (for
example two redundant LANs), 1 (reserved for unreliable mode, see
      Appendix E)

      UNR - shall be set to 0 (reserved for unreliable mode see
      Appendix E)

    In Queue: 8 bits

      This field contains the first 4 octets number of messages the data field will
be an unsigned long integer (in network order) specifying how many
networks the endpoint sender has access to. Following these 4 octets will on its
      incoming queue, waiting to be
a list of network addresses. Each address begins with a header of 4
octets followed read by the actual address. The first 2 octets of application. This
      gives the
header is receiver an unsigned integer indicating the size of the actual
address. The next 2 octets of the header is the type indication of the address.

For an IPv4 address, the address header will have flow control conditions
      within the size set to 8
and sender.

    Acknowledgment Number (or Seen): 32 bits

      If the type flag ACK is set to AF_INET (2). Of the 8 octets used by the actual
IPv4 address, the first 4 octets will contain the IP address (in
network order) of the path. The next two octets will contain this value is the UDP
port number (in network byte order). The last two octets will be
padded with 0's.

The data field of the initiation or initiation Ack datagram from an
endpoint with access to two IPv4 networks would look sequence number
      that the following:

    0                   1                   2                   3   
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Number of Networks = 2                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       Size of address=8       |    Type of Address=AF_INET (2)|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |             IP Address of Network 1 = 0x88b68108              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         Port = 52212          |      Padding = 0              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       Size sender of address=8       |    Type this datagram received from the
      receiver of Address=AF_INET (2)|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |             IP Address this datagram.

    Sequence Number (or Send): 32 bits

      If DAT flag is set, this value represents the sequence number of Network 2 = 0x0a100001              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         Port = 52212          |      Padding = 0              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Any
      the current data unit following this header. Otherwise, this
      value will be the initiate network list can sequence number of the next data unit that
      will be ignored. Implementations
are at option to use additional sent.

    Data Size: 16 bits

      This value represents, in number of octets, the size of the data sent
      field that follows this header in subsequent locations the current datagram.

    Part: 8 bits

      shall have value '0' (reserved for fragmentation, see Appendix C)

    Of: 8 bits

      shall have value '1' (reserved for fragmentation, see Appendix C)

2.2 Data Field

When the DAT flag is set to 1, the MDTP datagram header will be
followed by a data field. An implementation specific may choose to pad some
'0's at the end of the data exchanges. No user data, however, is allowed field so as to align with certain memory
boundaries. However, the padded '0' octets, if there are any, shall
not be transported counted in this datagram.


4.3 the Data Size.

The maximal Data Size for a single MDTP datagram is the MTU size of
the underlying transport protocol (e.g., UDP) minus the MDTP header
size.

3.  Transmission Initialization Collision

If both

3.1 Endpoint Association Initialization

Before the first data transmission can take place from one endpoint
("A") to another endpoint ("Z"), the two endpoints attempt will need to
complete an initialization process in order to set up an association
between them.

The initialization procedure should be made transparent to initialize the communication at about upper
layer protocol, i.e., it should take place automatically whenever the

Stewart & Xie                                                  [Page 15]

Internet Draft   Multi-network Datagram Transmission Protocol   Apr 1999


same instance, a collision will occur. In
upper layer tries to send a collision each endpoint
will receive datagram to an initiation endpoint which has never
been sent to before. The user datagram shall be withheld by MDTP from
transmission till the other side after it
transmitted its own. Both sides must acknowledge completion of the initiation
datagram in initialization.

A tag-and-lock mechanism is employed during the normal procedure as described initialization in 4.1

The following
order to guard against erroneous or stale datagrams (this is an example of
especially true if redundant networks are deployed).

The initialization collision:

Endpoint A                                          Endpoint Z
[Header Flags=FIR|RES                          [Header Flags=FIR|RES
	Mode=options                            Mode=options
        Seen=0,Send=Tag_A] --------\   /-----   Seen=0, Send=Tag_Z]
(Start T1-init timer)               \ /        (Start T1-init timer)
                                     /
                                    / \
                                   /   \
[Header Flags=FIR|RES|ACK  <------/     \
        Mode=options		         \---> [Header Flags=FIR|RES|ACK
        Seen=Tag_Z,Send=Tag_A]----\             Mode=options          
                                   \ /-------   Seen=Tag_A,Send=Tag_Z]
                                    \ 
                                   / \-------> (Cancel T1-init timer)
(Cancel T1-init timer)     <------/

..
[Header Flags=ACK|DAT                              
	Mode=options                               
        Seen=Tag_Z,Send=1] ------------------> 
                                               ..
                                               [Header Flags=ACK|DAT  
                                                Mode=options   
			   <-----------------   Seen=Tag_A,Send=1]

4.4 Re-initialization

An endpoint is allowed to re-initialize an established communication.

In the case process consists of re-initialization, the endpoint which initiates following steps (assuming
the
re-initialization (i.e, upper layer at "A" tries to send data to "Z" for the initiator) should use a tag different
from first time):

A) "A" first sends an Initiation (FIR) to "Z", with Seen field set
   to 0 and Send field set to Tag_A, and then enters the one used in Tag-lock mode
   (see below).

B) "Z" responds immediately with an Initiation Ack (FIR|ACK), with
   Seen set to Tag_A and Send set to Tag_Z, and then enters the previous initialization. The initiator
   Tag-lock mode, too (see below).

Note that no user data should
follow the standard initialization procedure as stated be carried in 4.1.

Upon the arrival of the initiation datagram, Initiation or
Initiation Ack datagram.

At this point "Z" is ready to send user data to "A". And upon the peer
receipt of the initiator
should above Initiation Ack from "Z", "A" can also follow the procedure stated in 4.1 start
sending user data to respond. Note that
any outstanding flows that were open are considered closed once 
re-initialized.

4.5 Link Rotation

When multiple networks exist between two communicating endpoints,
every time "Z".

However, the application transmits a datagram, first datagram with user data transmitted by "A" to "Z"
shall have the MDTP
implementation MUST keep track of Seen value set to Tag_Z, which network the transmission was
sent on (if more than one network exists) in is obtained from the MDTP protocol variable
'last.sent.intf'. If
Initiation Ack. And similarly, the first datagram with user does not specifically override rotation,

Stewart & Xie                                                  [Page 16]

Internet Draft   Multi-network Datagram Transmission Protocol   Apr 1999


each send should be rotated in a round robin fashion amongst all
available networks and data
transmitted by "Z" to "A" shall have the protocol variable 'last.sent.intf' should
be updated Seen value set to indicate Tag_A,
which interface was used last. The MDTP
implementation should consider comes from the rules defined in "5.5
Retransmission on Multiple Networks" to consider if Initiation datagram.

In the Tag-lock mode, each side will silently discard any datagrams
with user data from the other side until it receives the first
datagram with user data and with a network Seen value that matches its own
Tag. Once that datagram is
"available"

The MDTP implementation MUST allow received, that endpoint will leave the
Tag-lock mode and immediately send back a user data acknowledgment, and
start using the sequence numbers to override this rotation
defeating MDTP's rotation upon each send.


5.  Reliable Transfer Mode

Reliable transfer mode filter out missing and duplicate
datagrams.

If another Initiation from "A" is indicated if received by "Z" after it sent out
the sending endpoint sets Initiation Ack, "Z" will acknowledge this Initiation by re-sending
the
GAR option on Initiation Ack only when the current datagram. 

If Send field of this new Initiation has
the sending endpoint was previously transmitting in unreliable mode
(by setting UNR bit in each previous datagram), same tag as that of the receiver must
reset original Initiation.  Otherwise, "Z" will
send an Initiation of its Seen counter own with Send field set to Tag_Z back to "A"
to elicit an Initiation Ack from "A".

In the Send value of this current datagram
upon receiving it.

The following example illustrates both piggy-backed example, "A" initiates the association first and non-piggy-backed
acknowledgments then
sends a datagram with both ends transmitting in reliable mode: user data to "Z":

   Endpoint A                                          Endpoint Z
{App sends 3 messages}

   {first app message to Z}
   [Header Flags=DAT|ACK
	Mode=GAR
	Part=0,Of=1
        Seen=1,Send=1,Size=100]-------------> (Start T2-receive timer) Flags=FIR
             & other options
           Seen=0,Send=Tag_A] ----------------------->
   (Start T3-send timer)

[Header Flags=DAT|ACK
	Mode=GAR
	Part=0,Of=1
        Seen=1,Send=101,Size=100]----------->
(Restart T3-send timer)

[Header Flags=DAT|ACK
	Mode=GAR
	Part=0,Of=1
        Seen=1,Send=201,Size=100]----------->
(Stop and restart T3-send T1-init timer)

                                              {Timer T2 expires}
                <----------------------------
   (Enter Tag_A-lock mode)
                                              [Header Flags=ACK
                                              Mode=0
                                              Part=0,Of=0
                                              Seen=301,Send=1]





Stewart Flags=FIR|ACK
                                                        & Xie                                                  [Page 17]

Internet Draft   Multi-network Datagram Transmission Protocol   Apr 1999


(cancel T3-send timer)
..
{App sends 1 message}
[Header Flags=DAT|ACK
	Mode=GAR
	Part=0,Of=1
        Seen=1,Send=301,Size=100]-----------> (Start T2-receive timer)
(Start T3-send timer)

                                              {App sends 1 message}
                                              (cancel T2-receive timer)
                <---------------------------- other options
                                   /---------- Seen=Tag_A,Send=Tag_Z]
                                  /           (Enter Tag_Z-lock mode)
   (Cancel T1-init timer)<-------/

   [Header Flags=DAT|ACK
                                               Mode=GAR
                                               Part=0,Of=1
                                               Seen=401,Send=1,Size=45]
                                               (Start T3-send timer)
(cancel T3-send timer) Flags=ACK|DAT
             & other options
           Seen=Tag_Z,Send=1]
           [data field]   -----------\
   (Start T2-receive timer)
..
{Timer T2 Expires}
[Header Flags=ACK
Part=0,Of=0
        Seen=46,Send=401]------------------> (cancel T3-send timer)


In the above example, the first series of 3 messages of 100 octets each
are sent by Endpoint A. The messages are unbundled in this example,
i.e., each message will be transmitted in a single datagram. Endpoint
A starts its send timer T3 after sending the first datagram, and each
subsequent send will stop and restart the send              \
                                       \----> (Leave Tag_Z-lock mode)

If T1-init timer T3, extending the
life of expires at "A" after the send timer. Endpoint Z upon receiving Initiation sent, the first same
Initiation datagram
starts with the receive timer T2. When timer T2 in Endpoint Z expires,
Endpoint Z transmits an Ack. Upon receipt of this Ack by Endpoint A,
it stops timer T3 same Tag_A value will be retransmitted
and discards the first 3 datagrams (held for
possible retransmissions).

After timer restarted. This will be repeated Max.Init.Retransmit
times before "A" considers "Z" unreachable and optionally reports the first three messages were transmitted successfully,
failure.

3.1.1 Choice of Tag Value

Tag values should be selected from the
application at Endpoint A sends another message range of 100 octets.  After
sending this datagram, Endpoint A starts timer T3 again.  Upon
receipt 0x80000000 to
0xffffffff.

3.2 Data Field Format of Initiation Datagrams

If redundant networks exist between two endpoints, the datagram, Endpoint Z starts Timer T2.  Before
Endpoint Z's T2 timer expires, the application at Endpoint Z sends a
message data field of 45 octets to Endpoint A.  This causes Endpoint Z to cancel
the T2 timer Initiation and to piggyback an Initiation Ack on datagrams will carry the out-bound datagram being
transmitted to Endpoint A. After redundant
network information.

The following shows the transmission, Endpoint Z then
starts its T3 timer.  Upon receipt data field format carrying N IPv4 redundant
network information:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Number of Networks = N                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       Size of address=8       |    Type of Address=AF_INET (2)|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |             IP Address of Network 1                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         Port # 1              |      Padding = 0              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   /                                                               /
   \                              ...                              \
   /                                                               /
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       Size of this datagram Endpoint A
cancels its T3 timer (since all data it has sent is acknowledged), and
starts a receive timer T2. At the expiration address=8       |    Type of the T2 timer Endpoint
A acks the receipt Address=AF_INET (2)|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |             IP Address of the last datagram from Endpoint Z.  This Ack
causes Endpoint Z to cancel its T3-send timer.

It Network N                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         Port # N              |      Padding = 0              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Additional implementation-specific data is very important to notice in the above example that the
acknowledgments to the received datagrams are always delayed by timer
T2. This delay gives the receiving endpoint a window to piggyback the

Stewart & Xie                                                  [Page 18]

Internet Draft   Multi-network Datagram Transmission Protocol   Apr 1999


Acks onto subsequent datagrams traveling in allowed after the opposite direction,
thus redundant
network information. No user data, however, is allowed to avoid sending the Acks be
transported in separate Initiation or Initiation Ack datagrams.

5.1 Timer Control

The basic rules for timer control are as follows:

A) When all outstanding datagrams are acknowledged, the T3-send timer
   shall be stopped, if one is running.

B) When a datagram with application data (i.e.,

3.3 Initialization Collision

If two endpoints attempt to initialize an association with DAT flag set) is
   received, each other
at about the endpoint shall start same instance, a T2-receive timer if no timer is
   running. 

C) Upon the expiration of the T2-receive timer, the endpoint shall
   ack to the sender all collision will occur, i.e., each side
will receive an Initiation datagram from the un-acked data other side after it has received.

D) When
transmitted its own. In such a datagram with application data is sent out, the sending
   endpoint case, both sides shall start a T3-send timer. If acknowledge the T3-send timer is already
   running,
Initiation datagram of the other side in the normal procedure as
described above.

3.4 Association Re-initialization

An endpoint shall first stop the old T3 timer and then 
   start be allowed to re-initialize an established
association with another endpoint.

In such a new one. If the T2-receive timer is running, case, the endpoint 
   shall first stop that initiates the T2 timer, piggyback an Ack unto re-initialization
(i.e, the out-bound 
   datagram, and then start initiator) shall use a T3-send timer.

E) If tag different from the T3-send timer expires, one used in
the endpoint previous initialization. And the initiator shall attempt
   re-transmission according to follow the rules described normal
initialization procedure as stated in 5.5.

F) No more than one timer section 3.1.

Once left the Tag-lock mode of any type should be running on the current association initialization,
an endpoint at any given moment.

G) When a T2-receive timer expires, shall treat any bundled data waiting to be
   transmitted should be sent immediately with a piggy-backed Ack to
   acknowledge all un-acked data previously received.

H) Whenever new incoming Initiation from its peer as a T3-send timer is to be started, any running timer should
   be stopped and supplanted by the T3-send timer.

I) In bundling mode, if
re-initialization event. Upon the total size arrival of all application messages
   pending to be sent is less than the bundle size, new Initiation
datagram from the messages should
   be withheld and peer, the T4-bundle timer should be started.

J) If receiving endpoint shall also follow the total size of all application messages pending
procedure stated in section 3.1 to be sent
   exceeds the bundle size, the T4-bundle timer should be stopped and 
   the message(s) should be immediately sent.

K) If a T4-bundle timer respond.

4.  Reliable Transfer of Datagrams

Reliable transfer is running and data arrives, indicated if the T2-receive
   timer should not be started.

L) A T4-bundle timer should never be canceled unless it is datagram being
   supplanted by a T3-send timer.

M) When transferred has
GAR bit set to 1 and the first UNR bit set to 0. The receiver of a
reliable datagram with the Tag which unlocks shall always acknowledgment the initiation sender.

Normally, delayed acknowledgment is received, no T2-receive timer should be started, instead an

Stewart & Xie                                                  [Page 19]

Internet Draft   Multi-network Datagram Transmission Protocol   Apr 1999 used, and the acknowledgment must can
either be sent without delay. separately or piggy-backed on a datagram traveling
in the opposite direction.

The following example shows the use of various timers. illustrates both separate and piggy-backed
acknowledgments with both ends transmitting in reliable mode:

Endpoint A                                      Endpoint Z
{App sends 2 3 messages}
[Header Flags=DAT|ACK
	Mode=GAR Flags=DAT|ACK|GAR
        Part=0,Of=1
        Seen=1,Send=501,Size=100]----------->
        Seen=0,Send=1,Size=100]-------------> (Start T2-receive timer)
(Start T3-send timer)

[Header Flags=DAT|ACK
	Mode=GAR Flags=DAT|ACK|GAR
        Part=0,Of=1
        Seen=0,Send=2,Size=100]----------->
(Restart T3-send timer)

[Header Flags=DAT|ACK|GAR
        Part=0,Of=1
        Seen=0,Send=3,Size=100]----------->
(Restart T3-send timer)
                                              ...
                                              {Timer T2 expires}
                                 /----------- [Header Flags=ACK
                                /              Part=0,Of=0
                               /               Seen=3,Send=1]
                              /
(cancel T3-send timer) <------
...
...
{App sends 1 message}
        Seen=1,Send=601,Size=100]-\       /-- (cancel
[Header Flags=DAT|ACK|GAR
        Part=0,Of=1
        Seen=1,Send=4,Size=100]-----------> (Start T2-receive timer)
(stop and restart
(Start T3-send timer)   \     /
                                              ...
                                              {App sends 1 message}
                                              (cancel T2-receive timer)
                                 /----------- [Header Flags=DAT|ACK
                                    \   /      Mode=GAR
                                     \ Flags=DAT|ACK|GAR
                                /              Part=0,Of=1
                                      \        Seen=601,Send=1,Size=100]
                               / \       (Start T3-send timer)               Seen=4,Send=1,Size=45]
                              /   \
                              <----/     \--> 
..
{T3-send timer expires}
[Header Flags=DAT|ACK
	Mode=GAR
	Part=0,Of=1
        Seen=101,Send=601,Size=100]---------> (Cancel               (Start T3-send timer)
(Restart
(cancel T3-send timer) <------
(Start T2-receive timer)
..
{Timer T2 expires}
(Cancel T3-send timer)        <-------------- Expires}
[Header Flags=ACK
                                               Mode=0
        Part=0,Of=0
                                               Seen=701,Send=101]


In this example,
        Seen=1,Send=5]------------------> (cancel T3-send timer)

Note that if the application at Endpoint A sends 2 messages datagrams previously received from the same sending
endpoint was transmitted in Unreliable transfer mode (see Appendix E
for details on Unreliable transfer), the receiving endpoint must
reset its Seen counter to
Endpoint Z. Both messages are 100 octets the value of the Send field in length. Before the second current
reliable datagram.

4.1 Timer Management Rules

The the following rules shall be used to manage the timers during
normal Reliable transfer, unless otherwise stated for some special
cases:

A) When a reliable datagram arrives at Endpoint Z, Endpoint Z's application sends with user data (i.e., with DAT flag set) is
   received, the endpoint shall start a
message to Endpoint A. This causes Endpoint Z to cancel its T2-receive timer if no other
   timer is running, and piggyback upon the Ack to expiration of the first received datagram on T2-receive timer,
   the
out-bound datagram destined endpoint shall ack to Endpoint A. After transmitting the
datagram Endpoint Z starts its T3-send timer. When sender all the T3-send timer
at Endpoint A expires, un-acked datagrams
   it will re-send its earlier datagram. The
retransmitted has received.

B) When a reliable datagram with user data is sent out, the same except for now it acknowledges all
outstanding packets that Endpoint Z has sent. After retransmitting the
datagram Endpoint A restarts its sending
   endpoint shall start a T3-send timer.

The arrival of If the retransmitted datagram causes Endpoint Z to cancel
its T3-send timer is
   already running, the endpoint shall first stop the old T3 timer
   and discard then start a new one. If the duplicate T2-receive timer is running, the
   endpoint shall first stop the T2 timer, piggyback an Ack unto the
   out-bound datagram, and it now

Stewart & Xie                                                  [Page 20]

Internet Draft   Multi-network Datagram Transmission Protocol   Apr 1999


starts its T2-receive then start a T3-send timer. At Upon the
   expiration of the T2-receive timer
Endpoint Z sends T3-send timer, the Ack to Endpoint A. Endpoint A upon receipt of endpoint shall follow the
Ack Cancels its T3 timer.

5.2 Gap Acknowledgments

If a datagram becomes missing during a series of transmissions, a
special type rules
   described in 4.5 for possible re-transmission of acknowledgment known as the gap Ack will be sent. The
gap Ack tells un-acked
   datagrams. Whenever the sender of T3-send timer is started the missing datagram RTT estimate
   last calculated for that retransmission network should be added to the base
   T3-send timer value (if a RTT value is measured, see section 4.6).

C) When all outstanding datagrams are acknowledged, the T3-send timer
   shall be stopped if one is needed. still running.

The following example shows the use of gap Ack. various timers.

Endpoint A                                         Endpoint Z
{App sends 3 2 messages}
[Header Flags=DAT|ACK
	Mode=GAR Flags=DAT|ACK|GAR
        Part=0,Of=1
        Seen=146,Send=701,Size=100]-------->
        Seen=1,Send=6,Size=100]-----------> (Start T2-receive timer)
(Start T3-send timer)

[Header Flags=DAT|ACK
	Mode=GAR Flags=DAT|ACK|GAR
        Part=0,Of=1
        Seen=146,Send=801,Size=100]-----X (lost)                           {App sends 1 message}
        Seen=1,Send=7,Size=100]---\      /--- (cancel T2-receive timer)
(Restart T3-send timer)            \    /     [Header Flags=DAT|ACK|GAR
                                    \  /       Part=0,Of=1
                                     \/        Seen=6,Send=2,Size=100]
                                     /\       (Start T3-send timer)
                                    /  \
                              <----/    ---->
...
...
{T3-send timer expires}
(re-transmit 2nd datagram)
[Header Flags=DAT|ACK
	Mode=GAR Flags=DAT|ACK|GAR
        Part=0,Of=1
        Seen=146,Send=901,Size=100]--------> (A gap detected in data)
        Seen=2,Send=7,Size=100]---------> (Cancel T3-send timer)
(Restart T3-send timer)                       (Start T2-receive timer)

                                              ..
                                             {T2-receive timer
                                              {Timer T2 expires} 
                                     /------
(Cancel T3-send timer)        <-------------- [Header Flags=ACK
                                    /         Mode=0
                                   /          Seen=801,Send=146,
                                  /           Part=1,Of=1
                                 /            data=(long integer)901]
(Prepare retransmit)   <--------/


In this example, when Endpoint Z received
                                               Part=0,Of=0
                                               Seen=7,Send=3]

4.1.1 Link Rotation

When multiple networks exist between two communicating endpoints,
every time the third datagram from
Endpoint A it realizes that application transmits a gap exists datagram, the MDTP
implementation MUST keep track of which network the transmission was
sent on (if more than one network exists) in the received data.  At MDTP protocol variable
'last.sent.intf'. If the
expiration of T2-receive timer, Endpoint Z sends a gap Ack, user does not specifically override rotation,
each send should be rotated in place
of a normal Ack, to Endpoint A round robin fashion amongst all
available networks and the protocol variable 'last.sent.intf' should
be updated to indicate the missing data.

In the gap Ack, the Part and Of fields are both set which interface was used last.

The MDTP implementation MUST allow a user to '1', as opposed override this rotation
defeating MDTP's rotation upon each send. The implementation must also
provide a interface to '0' as in add and remove a normal Ack. The data field of the gap Ack is link from rotation eligibility.

4.2 Gap Acknowledgment for Missing Datagrams

If reliable datagrams become missing during a four (4)
octet long integer containing the sequence number series of the last octet transmissions,
a special type of acknowledgment known as the gap (which is 901 in this example).  The Seen field in the gap Gap Ack will contain the sequence number of the first octet of the gap.

Stewart & Xie                                                  [Page 21]

Internet Draft   Multi-network Datagram Transmission Protocol   Apr 1999



Using these two values, Endpoint A should be able sent
back to calculate inform the
position and size of sender to re-transmit the missing data (which is 801-900 in this
example) and thus determine which datagrams will need to be
retransmitted.

Gap Acks cannot be piggy-backed with application data. datagrams.

The following is
another example shows the use of using gap Ack: Gap Ack.

Endpoint A                                    Endpoint Z
{App sends 3 messages}
[Header Flags=DAT|ACK
	Mode=GAR Flags=DAT|ACK|GAR
        Part=0,Of=1
        Seen=146,Send=701,Size=100]-------->
        Seen=3,Send=8,Size=100]-----------> (Start T2-receive timer)
(Start T3-send timer)

[Header Flags=DAT|ACK
	Mode=GAR Flags=DAT|ACK|GAR
        Part=0,Of=1
        Seen=146,Send=801,Size=100]-----X
        Seen=3,Send=9,Size=100]-----X (lost)
(Restart T3-send timer)

[Header Flags=DAT|ACK
	Mode=GAR Flags=DAT|ACK|GAR
        Part=0,Of=1
        Seen=146,Send=901,Size=100]-------->
        Seen=3,Send=10,Size=100]-----------> (A gap is detected)
(Restart T3-send timer)
                                             ..
                                             {App sends a message}
                                             (Cancel T2-receive timer)
                                     /------ [Header Flags=ACK
                                    /         Mode=0
                                   /          Seen=801,Send=146,
                                  /           Part=1,Of=1
                                 /            data=(network long)901]
(Retransmit missing data) <-----/                
[Header Flags=DAT|ACK                      - [Header Flags=DAT|ACK
        Mode=GAR                          /  Mode=GAR
        Part=0,Of=1                      /   Part=0,Of=1
        Seen=146,Send=801,Size=100]-    /    Seen=801,Send=146,Size=100]
(Restart T3-send timer)             \  /     (Start T3-send timer)
                                     \/          
                                     /\          
                          <---------/  \         
                                        \        







Stewart & Xie                                                  [Page 22]

Internet Draft   Multi-network Datagram Transmission Protocol   Apr 1999


                                         \-->
                                             ..
                                             {T3-Send timer expires}
                                             (Retransmit app detected in data)
(Cancel T3-send timer)    <--------------- [Header Flags=DAT|ACK
(Start T2-receive timer)                    Mode=GAR
                                            Part=0,Of=1
                                            Seen=1001,Send=146,Size=100]
(Restart T3-send timer)
                                             ..
                                             {T2-receive timer expires}
                                    /------- [Header Flags=ACK
        Part=0,Of=0
        Seen=246,Send=1001]----------------> (Cancel T3-send timer)
                                   /          Seen=9,Send=3,
                                  /           Part=1,Of=1
                                 /            data=(long integer)10]
(Prepare retransmit)   <--------/

In this example, Endpoint Z detected when "Z" receives the third datagram from "A" it
realizes that a gap exists in the received data.  At the expiration of
T2-receive timer, "Z" sends a Gap Ack, in place of a normal Ack, to
"A" to indicate the missing data when it received
the second datagram. However, before

In the T2-receive timer expired, Gap Ack, the
application at Endpoint Z requested Part and Of fields are both set to send a message (of 100 octets
in length). This caused Endpoint Z '1', as opposed
to cancel its T2-receive timer and
send '0' as in a normal Ack. The data field of the gap Gap Ack before it sent out the datagram is a four (4)
octet long integer containing the
application message. After transmitting the application message
Endpoint Z started its T3-send timer. When Endpoint Z's T3-send timer
expired it retransmitted sequence number of the previous next datagram and at the same time
acked all of Endpoint A's outstanding datagrams. Upon
after the receipt of Gap (which is 10 in this example).  The Seen field in
the retransmission from Endpoint Z, Endpoint A started its own
T2-receive timer. At Gap Ack will contain the expiration sequence number of its T2-receive timer Endpoint A
sent an Ack to Endpoint Z and resolved the outstanding datagram at
Endpoint Z.


5.3 Congestion Control

Three different mechanisms of the
gap.  Using these two values, "A" should be used jointly able to achieve flow 
and congestion control in MDTP.

First, a limit should be set on calculate the number of out-bound messages
queued up at an endpoint. If
the limit missing datagram numbers (which is reached, new send requests
from 9 in this
example) and thus determine which datagrams will need to be
retransmitted.

Note that Gap Acks cannot be piggy-backed with user data; if there is
user data to be sent when a gap is detected, the application should Gap Ack must be sent
out first before the datagram carrying user data can be sent.

4.3 Flow and Congestion Controls

Several different mechanisms shall be rejected until the number of messages used jointly to achieve
flow and congestion controls in the queue drops back.

Secondly, MDTP uses MDTP.

4.3.1 Sending with Window Control

The sending endpoint shall use a transmission window to control the
number of outstanding datagrams, i.e., datagrams that have been sent,
but yet to be acknowledged. The length of the window is defined as the
maximal number of outstanding datagrams a sending endpoint can
allow. This length is adjusted dynamically, depending on the current
number of successful transmissions as well as the number of lost
datagrams.

When the number of outstanding datagrams reaches the current window
length, the endpoint may shall still accept send requests from the
application, its upper
layer, but will shall transmit no more datagram datagrams until an Ack is received.

Also,

Moreover, when the window length is reached, the next send request
from the

Stewart & Xie                                                  [Page 23]

Internet Draft   Multi-network Datagram Transmission Protocol   Apr 1999


application upper layer will trigger the sending endpoint to transmit a
special Window Up message. Upon receiving this Window Up message (WIN|ACK) the
receiver must respond with a Window Up Response message, (WNR|ACK), as
illustrated by the following diagram (assume example (assuming current window length
is 3):

Endpoint A                                      Endpoint Z
{App sends 3 messages}
[Header Flags=DAT|ACK
	Mode=GAR Flags=DAT|GAR|ACK
        Part=0,Of=1
        Seen=146,Send=1001,Size=100]-------->
        Seen=0,Send=11,Size=100]-----------> (Start T2-receive T2-recv timer)
(Start T3-send timer)

[Header Flags=DAT|ACK
	Mode=GAR Flags=DAT|GAR|ACK
        Part=0,Of=1
        Seen=146,Send=1101,Size=100]-------->
        Seen=0,Send=12,Size=100]----------->
(Restart T3-send timer)

[Header Flags=DAT|ACK
	Mode=GAR Flags=DAT|GAR|ACK
        Part=0,Of=1
        Seen=146,Send=1201,Size=100]-------->
        Seen=0,Send=13,Size=100]----------->
(Restart T3-send timer)

{App sends 1 messages}
{ queue 100 byte a new message}
(queue new message } and send Win Up)
[Header Flags=WIN|ACK
        Seen=146,Send=1301]----------------->
        Seen=0,Send=14]--------------------> (cancel T2-receive T2-recv timer)
                                         /---
                                      /----- [Header Flags=ACK
                                        /       Mode=WNR Flags=WNR|ACK
                                     /        Part=0,Of=0
                                    /         Seen=1301,Send=146]         Seen=14,Send=0]
[Header Flags=DAT|ACK      <---------/
	Mode=GAR Flags=DAT|GAR|ACK <--------/
        Part=0,Of=1
        Seen=146,Send=1301,Size=100]-------->
        Seen=0,Send=15,Size=100]-----------> (Start T2-receive T2-recv timer)
(Restart T3-send timer)

In this the above example, after the transmission of the first three
datagrams,
Endpoint A "A" reached its window length. The next message from the
application
user triggered a Window Up message that was sent to Endpoint
Z. "Z". The Window Up message always contains shall
contain no data and has its WIN flag
set. user data. In response, Endpoint Z "Z" cancelled timer T2 and
immediately sent
an Ack with the WNR set in the Mode field. a Window Up Response. The arrival of this Ack
from Endpoint Z Window Up
Response effectively resolved all the outstanding datagrams at
Endpoint A, "A",
thus allowed Endpoint A "A" to send out the next datagram.

4.3.2 Window Length Adjustment

The window length is shall be initially set to 2, and is shall then be
dynamically adjusted based on the performance datagram loss and acknowledgment
conditions of the underlying networks.

If the current window length is equal to or greater than 4, every time

Stewart & Xie                                                  [Page 24]

Internet Draft   Multi-network Datagram Transmission Protocol   Apr 1999


when network.

When 4 consecutive outstanding datagrams are acknowledged at once by
the receiver, the sender's window length will be raised by 1 until it
reaches 20. the protocol parameter 'Max.Outstanding.dg' (which should be a
user configurable parameter).

If the current window length is less than 4, every time when the
number of consecutively acknowledged outstanding datagrams acknowledged in a single
Ack is equal to or greater than the current window length, the
sender's window will length shall be raised by 1 1, until it reaches 20.

The
'Max.Outstanding.dg'.

In the following circumstances, the sender's window length will shall be
decreased. However, when the window length reaches 2 it shall not be
decreased if datagram loss
occurs. any further.

If between 1 to 3 consecutive datagrams are lost, the window length
will be decreased by 1. If between 4 to 7 datagrams are lost, the
window length will be decreased by 2. If 8 or more datagrams are lost,
the window length will be decreased by 4. When the window length
reaches 2 it will not be decreased any further.

Moreover, any time a Window Up is sent to the receiving endpoint the
sender's window length will be decreased by 1. Also, if a timeout
forces a retransmission the sender's window length will be decreased
by 1. Moreover if a duplicate Ack is received by a sender, this should
indicate a network congestion situation and the number reduced
to half of outstanding
packets allowed should be decreased by 4. its currently value.

The following table summarizes these rules:
- -----------------------------------------------------------------------
  Duplicate Ack received by sender  | Adjust down by 4
- -----------------------------------------------------------------------
  Greater than 8 datagrams lost     | Adjust down by 4
- -----------------------------------------------------------------------
  Greater than 4 datagrams lost     | Adjust down by 2
- -----------------------------------------------------------------------
  Greater than 0 datagrams lost     | Adjust down by 1
- -----------------------------------------------------------------------
  Timeout forces retransmission     | Adjust down by 1 1/2 of the current
                                    | window.
- -----------------------------------------------------------------------
  Window Up sent                    | Adjust down by 1
- -----------------------------------------------------------------------
  4 or more consecutive datagrams   | Adjust up by 1
  acknowledged (window length > 4)  |
- -----------------------------------------------------------------------
  1/2 Window length or more acked   | Adjust up by 1
  (window length <=4)               |
-----------------------------------------------------------------------


Finally, the third flow control mechanism is to exchange incoming
queue information between the two communicating endpoints. By using the
In Queue field in the MDTP header, the sender can inform the receiver
the number of pending datagrams which the sender has received, but yet
to deliver to its application. The following example shows how the
endpoints use In Queue value to accomplish flow control.

Assume that Endpoint A sent Endpoint Z 20 datagrams, and when Endpoint

Stewart & Xie                                                  [Page 25]

Internet Draft   Multi-network Datagram Transmission Protocol   Apr 1999


Z acked the receipt of all the 20 datagrams, only the first one of
the 20 datagrams was delivered to the application at Endpoint Z.  In
the last Ack sent by Endpoint Z, the In Queue field would then have a
value of 19, indicating the number of datagrams pending for delivery
to its application. This value would be checked by Endpoint A before
it sent the next datagram to Endpoint Z. If this value was found to be
greater than its current window length, Endpoint A would not send the
next datagram. Instead, Endpoint A would start its T3-send timer and
send a Window Up message to Endpoint Z at the expiration of the timer.
This would force Endpoint Z to send an Ack with an updated In Queue
value. If the new In Queue value was still greater than its window
length, Endpoint A would restart its T3-send timer, repeating this
procedure until <=4)               |
- -----------------------------------------------------------------------

4.3.3 Flow Control using In-Queue Information

By using the In Queue value of Endpoint Z dropped below the
current window length of Endpoint A.  Then, the transmission at
Endpoint A would resume.


5.4 Sequence Number Reset

It may become necessary for an endpoint to reset field in the sequence number
while it is sending data to a peer. However, MDTP header, the endpoint must sender can inform
the peer about this event by:

1) sending a Window Up message to force receiver the peer to acknowledge all
   received number of pending datagrams which have not been acknowledged, and

2) sending the next datagram with RES bit set in the Flags field.

3) A sending endpoint should always reset it sequence counter before
   the counter reaches 0x7fffffff. When the counter reaches this
   value the sending endpoint is required sender has
received, but yet to deliver to reset its sequence 
   counter.

4) A sending endpoint should never reset its sequence counter until
   after reaching 0x7fff05ff.

Note: This section will be obsoleted in a future version of the
draft and be replaced by a deterministic roll-over algorithm. application. The following example illustrates
shows how the sequence number reset procedure
(assume endpoints use In Queue value to accomplish Flow control.

Assume that Endpoint A opts to do a reset when the data sequence
number becomes greater than 0x7fffff000).












Stewart & Xie                                                  [Page 26]

Internet Draft   Multi-network Datagram Transmission Protocol   Apr 1999 has sent Endpoint A Z 20 datagrams, and when
Endpoint Z

{App sends 2 messages}
[Header Flags=DAT|ACK
	Mode=GAR
	Part=0,Of=1
        Seen=46,Send=0x7ffff000,Size=100]----> (Start T2-receive timer)
(Start T3-send timer)
(Reset sequence number)
[Header Flags=WIN|ACK
        Seen=146,Send=0x7ffff100]------------> (cancel T2-receive timer)
                                      /------- [Header Flags=ACK
                                     /          Mode=WNR
                                    /           Part=0,Of=0
                                   /            Seen=7fffff100,Send=46]
(Cancel T3-send timer)     <------/
[Header Flags=DAT|ACK|RES
	Mode=GAR
	Part=0,Of=1
        Seen=46,Send=2,Size=100]-------------> (Start T2-receive timer)
(Restart T3-send timer)

                                               ..
                                               {App sends 1 message}
                                               (cancel T2-receive timer)
(Cancel T3-send timer)     <---------------- [Header Flags=DAT|ACK
(Start T2-receive timer)                      Mode=GAR
                                              Part=0,Of=1
                                              Seen=102,Send=46,Size=100]
                                               (Start T3-send timer)

In sends an Ack on the above example, after transmitting reception of these 20 datagrams, only
the first datagram one of them has been delivered to the upper layer at
Endpoint A
determines that its data sequence Z.

In the Ack sent by Endpoint Z, the In Queue field would then have a
value of 19, indicating the number needs of datagrams pending for delivery
to its upper layer. This value would be reset checked by Endpoint A before
it
transmits sent the next datagram to Endpoint Z. If this value was found to be
greater than its current window length, Endpoint A would not send the
next datagram. It first sends out Instead, Endpoint A would start its T3-send timer and
send a Window Up message to Endpoint Z at the expiration of the timer.
This would force Endpoint Z to send back a Window Up Response to ack all another Ack with an updated In
Queue value. If the
outstanding received data. new In Queue value was still greater than its
window length, Endpoint A would re-start its T3-send timer, and repeat
this procedure until the In Queue value of Endpoint Z dropped below
the current window length of Endpoint A.  Then, it transmits the datagram
it has been withholding, transmission at
Endpoint A would resume.

4.3.4 T3-send Timer Adjustment with RTT

If the new sequence number RTT measurement is available on a specific network, the sender
shall adjust the T3-send timer each time when sending datagram using
this network. The calculation and adjustment of the RES flag 
set. Upon detecting timer should
follow the RES flag method described in [4]. RTT measurement shall be tracked
for each network if redundant networks are in use.

MDTP defines two optional methods to obtain RTT measurements, see
sections 4.6 and 4.7.

4.4 Sequence Number Reset

When the datagram sequence number reaches the header of value 0x7fffffff the incoming datagram,
Endpoint Z resets its data
next sequence counter on Endpoint A.


5.5 Retransmission on Multiple Networks number shall be set to 1.

4.5 Datagram Re-transmission

Whenever a T3-send timer expires, the endpoint will take one of the
following three actions:

A) If shall re-transmit the current window length is not reached (see 5.3) and there is
   application data pending, a new
un-acked datagram will be sent out.

B) that has the lowest Send value, unless:

A) If the current window length is reached, a Window Up message will
   be sent out.

C) out (see 4.3 Congestion Control), or

B) If the current window length is not reached, but there is no pending

Stewart & Xie                                                  [Page 27]

Internet Draft   Multi-network Datagram Transmission Protocol   Apr 1999


   application data to send, The datagram with the lowest Send value 
   that is still outstanding (i.e., not been acked) will be 
   retransmitted.

When multiple networks exist between two communicating endpoints, the
re-transmission should be attempted on the network specified
in the MDTP protocol variable 'last.good.intf'. The value of
'last.good.intf' is always updated to refer to the network on which
the last datagram from the peer endpoint arrived.

Moreover, the number of consecutive re-transmissions is also recorded
in a variable 'retran.count' for each network. Every time a datagram is
received from a network, the corresponding retran.count is reset to '0'.

If the value in the retran.count of the current network exceeds a half
of the value of the protocol parameter 'Max.Retransmit', the
'last.good.intf' will be changed, so as to force the next
re-transmission to be directed to an alternate network. 

The total number of consecutive re-transmissions across all the
networks is also recorded. If this value exceeds the limit defined by
'Max.Retransmit', the sending endpoint should consider the peer
endpoint unreachable reached and stop transmitting there is still
   user data to it, pending for transmission, a new datagram with user data
   shall be sent out and optionally
report the failure.

5.5.1 Randomization of the T3-send timer at retransmission shall be restarted.

When a T3-send timer is started after retransmitting at a packet, re-transmission, the
value length of
the next T3-send timer for this destination should be
extended by a random amount. The amount must be bounded so that the
application can predict with some reasonable degree of precision when
the destination endpoint is declared unreachable.

For performance considerations, this can be implemented by
pre-calculating a set of random values doubled and then using a different
value to extend the T3-send timer
last estimated RTT value for each re-transmission to the
same destination endpoint.


5.6 Termination of an Endpoint

When an endpoint terminates, it that network should send a shutdown message
to each of the peer endpoints it has ever initiated for a
communication. The shutdown message is sent in unreliable transfer
mode and need not to be acknowledged. When an endpoint receives a
shutdown message from its peer, it will remove the sender from its
record, and optionally report the termination of that peer.

The following sequence shows an example of the termination of an
endpoint (Endpoint A). 

Endpoint A                                     


Stewart & Xie                                                  [Page 28]

Internet Draft   Multi-network Datagram Transmission Protocol   Apr 1999


{App indicates termination}
[Header Flags=FIR
	Mode=SHU
        Seen=146,Send=1301,------------------------> to Endpoint X

[Header Flags=FIR
	Mode=SHU
        Seen=1496,Send=101,------------------------> to Endpoint Y

[Header Flags=FIR
	Mode=SHU
        Seen=1460,Send=201-------------------------> to Endpoint Z

As shown in this example, the shutdown message is indicated by having
both FIR flag and SHU mode bit set. Also, notice that no
acknowledgment is sent back by Endpoint X, Y, or X.


5.7 Endpoint Drain

An endpoint may decide added to "drain" a connection without completely
shutting it down. By draining a connection, both endpoints will remove
any record and pending datagrams associated with the connection.
Further communications timer.

4.5.1 Re-transmission on Redundant networks

When redundant networks exist between the two endpoints can communicating endpoints, the
re-transmission shall be resumed by
going through a re-initialization procedure.

A "drain" message is specified with attempted on the UNR bit set network specified in a shutdown
message. No Ack is required for a "drain" message. the
MDTP protocol variable 'last.good.intf'. The following sequence shows an example.

Endpoint A                                     

{App indicates termination}
[Header Flags=FIR|UNR
	Mode=SHU
        Seen=146,Send=1301]------------------------> to Endpoint X

5.8 Advisory Acknowledgments.

To increase bandwidth utilization a sending endpoint may (at its option)
request an advisory acknowledgment. A endpoint would typically do this
when 1/2 value of its window 'last.good.intf'
is unacknowledged and upon its always updated to refer to the network on which the last datagram
that will fill its window. Upon reception
from the peer endpoint arrived.

Moreover, the number of consecutive re-transmissions is also recorded
in a advisory Acknowledgment
request variable 'retran.count' for each network. Every time a datagram
is received on a network, the receiver corresponding 'retran.count' shall with no delay transmit an acknowledgment be
reset to 0.

If the value in the 'retran.count' of
all received packets canceling any T2-Receive timer that may the current network exceeds
half of the value of the protocol parameter 'Max.Retransmit', the
'last.good.intf' will be running.
The sequence would look changed, so as follows:







Stewart & Xie                                                  [Page 29]

Internet Draft   Multi-network Datagram Transmission Protocol   Apr 1999


Endpoint A                                      Endpoint Z
{App sends 3 messages}
[Header Flags=DAT|ACK
	Mode=GAR
	Part=0,Of=1
        Seen=1,Send=1,Size=100]-------------> (Start T2-receive timer)
(Start T3-send timer)

[Header Flags=DAT|ACK
	Mode=GAR
	Part=0,Of=1
        Seen=1,Send=101,Size=100]----------->
(Restart T3-send timer)

[Header Flags=DAT|ACK
	Mode=GAR|RE1
	Part=0,Of=1
        Seen=1,Send=201,Size=100]----------->
(Stop to force the next
re-transmission to be directed to an alternate network and
optionally report a failure condition.

The total number of consecutive re-transmissions across all the
networks in an association is also recorded. If this value exceeds the
limit defined by 'Max.Retransmit', the sending endpoint shall consider
the peer endpoint unreachable and restart T3-send timer)

                                              (cancel T2-receive timer)
                <---------------------------- [Header Flags=ACK
                                              Mode=0
                                              Part=0,Of=0
                                              Seen=301,Send=1]


5.9 stop transmitting data to it, and
optionally report the failure.

4.6 RTT Measurement

This defines the mechanism for round-trip-time (RTT) measurement in
MDTP.

On occasion occasions either end side of an association may wish need to do a Round Trip Time perform an RTT
measurement of
a network.  There are two methods the network (or one of measuring Round Trip Time.
Method the redundant networks) between
them.

4.6.1 RTT Datagram Header Format

The following shows the header format an endpoint shall use for RTT
measurement:

                   MDTP Header Format - RTT measurement

    0                   1 involves a ping-pong using a special ACK, Method                   2 involves a
rider on top of a datagram. If Method                   3
    0 1 2 is invoked then the Round Trip 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                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Version     |           Flags               |   In Queue    |
   |               |N N W I F R D A M S W R R F G U|               |
   |               |O O I S I T A C U H N E T L A N|               |
   |               |M B N B R M T K L U R 1 C O R R|               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 Acknowledgment Number (Seen)                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   Sequence Number (Send)                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        Data Size              |    Part       |      Of       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  Transparent Time Int-1                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  Transparent Time includes Int-2                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Two long integers are used in the data field to carry the T2-Receive timer (this actually may be more useful
then pure RTT time since each endpoint may have a different T2-Receive
timer value).

Method 1: When a value.
The RTT datagram is identified by setting the RTC or RTM bit to 1.

4.6.2 Measure RTT

AT the request of its upper layer, an endpoint wishes a shall initiate an RTT
measurement it shall send a ACK by sending an RTT datagram with RE2 set to 1, GAR set to 1 GAR, ACK, and DAT RTC bits set
to 0. 1 (to a specific network if redundant networks exist). No
user data shall be carried. The sender
should shall also place in Time Int 1 Int-1
and Time int 2 Int-2 the value of the current time of day in seconds/microseconds. seconds and
microseconds.

Upon receipt the reception of a datagram with RE2 set to 1, GAR set to 1 and DAT set
to 0, this RTT datagram, the recipient should shall
immediately return the datagram to the sender over (over the
arriving same network with the NOG bit set. The sender can then use the
Time Int 1 and Time Int 2 to calculate the current RTT.








Stewart & Xie                                                  [Page 30]

Internet Draft   Multi-network Datagram Transmission Protocol   Apr 1999


Endpoint A                                      Endpoint Z
RTT - Request Now=x.y
[Header Flags=ACK
	Mode=GAR|RE2
	Part=0,Of=1
        Seen=1,Send=301,Size=0
        Time-Int1=x
        Time-Int2=y]------------->
                <---------------------------- [Header Flags=ACK|NOG
                                              Mode=0
                                              Part=0,Of=0
                                              Seen=301,Send=1
                                              Time-Int1=x
                                              Time-Int2=y]

Endpoint A uses
current time subtracted from
X.y (in arriving Datagram) to
calculate the RTT.


Method 2:

If a endpoint wishes to piggyback a RTT test including the T2-Timer at
the remote endpoint the sending endpoint fills out the datagram in the
normal way for reliable communication but also sets the RE2 flag, and
places at the end of
on which the datagram (outside the length of the data) two
long integers has a trailer.

When the receiving endpoint recognizes the RE2 flag, it should extract arrives if redundant networks exist), with the two integers
RTM and place them in internal storage until the next
datagram is scheduled ACK bits set to be returned (i.e. at the expiration of the
T2-Recv timer). If the The T2-Recv timer expires the receiving
endpoint should send the acknowledgment as above with the addition of
the NOB flag as well.  If the receiving endpoints upper layer sends a
datagram causing 1.

Upon the T2-Recv timer to be canceled then reception of this reply, the datagram
should include sender shall use the Trailing integers Time Int-1
and have Time Int-2 in the NOB flag set.  In
cases where a intervening Window UP is received reply datagram to calculate the receiving endpoint
should respond with a window Up Response (per RTT (of the window up procedure)
but NOT cancel its T2-Recv timer.














Stewart & Xie                                                  [Page 31]

Internet Draft   Multi-network Datagram Transmission Protocol   Apr 1999


Example 1 - T2-Recv timer expires
specific network if redundant networks exist).

Endpoint A                                      Endpoint Z
RTT - Request Now=x.y
[Header Flags=ACK|DAT
	Mode=GAR|RE2 Flags=ACK|GAR|RTC
        Part=0,Of=1
        Seen=1,Send=301,Size=100
	{data of 100 octets}
        Seen=1,Send=31,Size=0
        Time-Int1=x
        Time-Int2=y]------------->            (started T2-Recv)
		                              {T2-Recv Expires }
                <----------------------------
        Time-Int2=y] ----------------------->
                                      ------ [Header Flags=ACK|NOG|NOB
                                              Mode=0 Flags=ACK|RTM
                                     /        Part=0,Of=0
                                              Seen=301,Send=1
                                    /         Seen=31,Send=1
                                   /          Time-Int1=x
                                  /           Time-Int2=y]
Example 2 - Datagram causes T2-Recv timer cancel

Endpoint
                                 /
(Endpoint A                                      Endpoint Z
RTT - Request Now=x.y
[Header Flags=ACK|DAT
	Mode=GAR|RE2
	Part=0,Of=1
        Seen=1,Send=301,Size=100
	{data of 100 octets}
        Time-Int1=x
        Time-Int2=y]------------->            (started T2-Recv)
		                              {datagram sent by application}
			                      (cancel T2-Recv)
                <---------------------------- [Header Flags=DAT|ACK|NOG
                                              Mode=GAR
                                              Part=0,Of=1,Size=100
                                              Seen=401,Send=1
                                              {data of 100 octets}
                                              Time-Int1=x
                                              Time-Int2=y]




5.10 uses     <-----------
 current time subtracted from
 x.y to calculate RTT)

4.7 Link Heart Beat Ack

This defines the mechanism for activating and transmitting of link
heart beats in MDTP.

At request by the application, the user may wish a Heart Beat
acknowledgment sent. The Heart Beat should only be allowed to be
enabled if the senders Mod is Gar (reliable delivery) and version is
2. Once enabled when no datagrams are being transmitted, a T5-Heart
Beat timer should be started. When the T5 timer expires its upper layer, an endpoint shall enable heart beat on
a ACK should
be sent using the next available link, following the link rotation
procedure outlined specific peer with which it has an established association in "4.5 Link Rotation". After sending the Ack
another T5-Heart Beat timer should be started. If, before the
expiration of T5-Heart Beat, a
Reliable transfer mode.

The RTT datagram is transmitted or received,

Stewart & Xie                                                  [Page 32]

Internet Draft   Multi-network Datagram Transmission Protocol   Apr 1999


the T5 timer should be stopped and the appropriate T2-T4 timer should defined in section 4.6.1 shall be started.  The T5 timer has used as the lowest precedence of all timers.

When sending Heart
Beat.

After having heart beat enabled, the endpoint shall transmit a Heart
Beat Ack, the format should be to that of specific peer and start a T5-heartBeat timer. The peer
shall immediately respond to the Heart Beat in the same manner as an
RTT time
test. as described in section 4.6.  This will require response shall be stored by the receiver
first endpoint (also can be used to respond on update its RTT measurement).

When the network. If T5-heartBeat timer expires, the sender does not get a response on endpoint shall first check if
the network previous heart beat has been responded (on the heartbeat
arrived on by same network it was
sent in the time a next heartbeat is to be sent, then case of redundant network). If not, the network that the
last heartbeat Heart Beat was sent upon should shall be counted as a transmission failure has
failure, and be handled following the rules described in section "5.5 Retransmission on
Multiple Networks", and should counted against 4.5.
Then, the 'retran.count' and
protocol parameter 'Max.Retransmit'.


6.  Unreliable Transfer Mode

The unreliable transfer mode allows two endpoints to endpoint shall send to each
other without acknowledging the receiving. This can usually achieve
higher data throughput than the reliable transfer mode. To indicate the
unreliable transfer mode the sender of a datagram simply sets the UNR
in another Heart Beat and re-start the mode field. The following sequence illustrates unreliable data
transfer.

Endpoint A                                      Endpoint Z
{App sends 2 messages}
[Header Flags=DAT|ACK
	Mode=UNR
	Part=0,Of=1
        Seen=1,Send=11001,Size=100]-------->

[Header Flags=DAT|ACK
	Mode=UNR
	Part=0,Of=1
        Seen=1,Send=11101,Size=100]-------->

                                             {App sends 1 message}
                                   <------- [Header Flags=DAT|ACK
                                             Mode=UNR
                                             Part=0,Of=1
                                             Seen=11201,Send=1,Size=450]

{App sends 2 more messages}
[Header Flags=DAT|ACK
	Mode=UNR
	Part=0,Of=1
        Seen=451,Send=11201,Size=100]------>

[Header Flags=DAT|ACK
	Mode=UNR
	Part=0,Of=1
        Seen=451,Send=11301,Size=100]------>


Note that no timers are started by either end. Also note that even

Stewart & Xie                                                  [Page 33]

Internet Draft   Multi-network Datagram Transmission Protocol   Apr 1999


though both ends are in UNR mode,
T5-heartBeat timer.

In the ACK flag is still set by case where redundant networks exist, the
sender sending of Heart beats
shall follow the datagram. This means that the Seen field link rotation rules outlined in section 4.1.1.

If, before the expiration of T5-heartBeat timer, a datagram
header is still valid to indicating the sequence number of the last
octet
transmitted or received by the sender. However, endpoint, the sender makes T5-heartBeat timer shall
be stopped and the appropriate T2-T4 timer shall be started. In other
words, the T5-heartBeat timer has the lowest precedence.

When no claim as datagram to
whether pieces of data send and no other timers are missing. running, the
T5-heartBeat timer shall be start and the above procedure shall
continue.

The upper application can suggested interval for T5-heartBeat timer is 4000 ms.

4.8 Advisory Acknowledgment

This defines the mechanism for sending and handling of the Advisory
Acknowledgments in MDTP.

An endpoint may use this
information to help detecting missing or duplicated pieces. In
unreliable mode, MDTP makes no effort Advisory Acks to re-transmit missing data or increase bandwidth utilization
when transmitting over a reliable association.

An Advisory Ack shall be indicated by setting RE1 flag to screen out duplicated datagrams.

6.1 Ordered reception

In unreliable transfer if 1 in the sender sets
datagram.

The endpoint shall send an Advisory Ack to its peer when it reaches
half of its current window length, and also when it detects that the RE1 bit
next send will reach the receiver
should order full window length.

Upon the datagrams upon arrival. Any datagrams that have not
been read by reception of an Advisory Ack, the receivers application should be ordered so that peer endpoint shall
immediately acknowledge all the datagrams will be it has received in order the datagrams were transmitted 
(using the sendStartsAt field). If a datagram arrives after a
new datagram but yet
acked upon, and then cancel the datagram should be discarded. The sequence would
look as follows: T2-recv timer if one is still
running.

The following shows an example of using Advisory Ack:

Endpoint A                                      Endpoint Z
{App sends 4 3 messages}
[Header Flags=DAT|ACK
	Mode=UNR|RE1
	Part=0,Of=1
        Seen=1,Send=11001,Size=100]-------->

[Header Flags=DAT|ACK
	Mode=UNR|RE1 Flags=DAT|GAR|ACK
        Part=0,Of=1
        Seen=1,Send=11101,Size=100]\       /-->
                                    \     /
                                     \   /   (User reads/Receives all
        Seen=0,Send=1,Size=100]-------------> (Start T2-recv timer)
(Start T3-send timer)

[Header Flags=DAT|ACK                 \ /     datagrams 11001 & 11201)
	Mode=UNR|RE1                   \ Flags=DAT|GAR|ACK
        Part=0,Of=1                   / \ 
        Seen=451,Send=11201,Size=100]/   \---> { Datagram is discarded }
        Seen=0,Send=2,Size=100]----------->
(Restart T3-send timer)
{detects window half full, use Advisory Ack}
[Header Flags=DAT|ACK
	Mode=UNR|RE1 Flags=DAT|GAR|ACK|RE1
        Part=0,Of=1
        Seen=1,Send=11301,Size=100]\       /-->
                                    \     /
        Seen=0,Send=3,Size=100]------\
(Stop and restart T3-send timer)      \   /
                                       \----> (cancel T2-receive timer)
                      <---------------------- [Header Flags=DAT|ACK                 \ /     
	Mode=UNR|RE1                   \  
	Part=0,Of=1                   / \ 
        Seen=451,Send=11401,Size=100]/   \--->(User reads/Receives all 
                                               datagrams in order
                                               11301 & 11401)




Stewart & Xie                                                  [Page 34]

Internet Draft   Multi-network Datagram Transmission Protocol   Apr 1999

7.  Reliable flows

A flow is a ordered reliable sequence Flags=ACK
                                               Part=0,Of=0
                                               Seen=3,Send=1]

4.9 Termination of datagrams that is delivered an Association

When an endpoint terminates, it shall send a Shutdown datagram
(FIR|SHU) to each of the receiver peer endpoints in order without constraint to other flows. There all its existing
associations.  The Shutdown datagram itself is a
set way to initiate (open) a flow sent in unreliable
transfer mode and close a flow. Each flow is
initiated by the sender. Multiple flows may thus needs not to be initiated between two
endpoints at the same time. Once initiated acknowledged.

When a flow peer endpoint receives the Shutdown, it will follow remove the same
retransmission sender
from its record, and link rotation schema's has optionally report the rest termination of MDTP. However
each flow is independent the sender
to the upper layer.

The following shows an example of the termination of Endpoint A:

Endpoint A
{App indicates termination}
[Header Flags=FIR|SHU
        Seen=3,Send=14,    ------------------------> to Endpoint X

[Header Flags=FIR|SHU
        Seen=1496,Send=101,------------------------> to Endpoint Y

[Header Flags=FIR|SHU
        Seen=14,Send=2    -------------------------> to Endpoint Z

4.10 Draining of an Association

An endpoint in a association may decide to "drain" the association
without completely shutting it down. By draining an association, both
endpoints will remove any other flow, so if datagram 1 record and 2 of
flow 5 arrives, but pending datagrams associated with
the association.  Further communications between the two endpoints can
be resumed by going through a re-initialization procedure (see
section 3).

In such a case, a Drain datagram 1 of flow 4 (FIR|SHU|UNR) is lost (having been sent
ahead of flow 5's datagrams), flow 5's datagrams are delivered to the
application without blocking for retransmission peer
endpoint of the lost datagram
from flow 4 (datagram 1 association, and no Ack is required.

The following sequence shows an example of flow 4).  All flow related datagrams will
have the NOB bit set. Each flow will also have a separate timer
associated Draining:

Endpoint A
{App indicates draining}
[Header Flags=FIR|SHU|UNR
        Seen=146,Send=1301]------------------------> to Endpoint X

5. Interface with it that is unique upper level protocols

The upper layer protocols (ULP) shall request for services by passing
primitives to MDTP and different shall receive notifications from any non-flow
related timers that are running. MDTP for
various events.

The Seen and Send fields will be
broken down primitives and interpreted in the following manner.


    0                   1                   2                   3   
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         Flow Number           |    Datagram number in flow    | (Seen)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         Flow Number           |    Datagram number notifications described in flow    | (Send)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The Send field will contain the flow number of this datagram, flow 0
is always reserved section should be
used as a guideline for implementing MDTP.

A) Init.MDTP primitive

This primitive allows MDTP to initialize its internal data structures
and allocate necessary resources for setting up its operation
environment. Note that once MDTP is NOT used. The datagram number is the
sequential number initialized, ULP can communicate
directly with any other endpoints without re-invoking this primitive.

Mandatory attributes:

None.

Optional attributes:

The following types of attributes may be passed along with
the datagram. The Seen field is used primitive:

 o Timer selection and its operation syntax -- to
acknowledge receipt of indicate to MDTP
   an alternative timer the indicated datagram MDTP should use for the specified
flow. The flow number in the acknowledgment does NOT need its operation.
 o Initial MDTP operation mode;
 o IP port number, if ULP wants it to be the
same as the flow number in the Send field. specified;

B) Send.Data primitive

This format is only used
for flow datagrams.

A flow can have bundled the main method to send datagrams via MDTP.

Mandatory attributes:

 o data (see section 9) but cannot have
fragmented messages. The reason fragmented messages are not supported - This is two fold, to attempt the payload ULP wants to simplify transmit;
 o size - The size of the flows a little bit. And flows
are thought payload in number of has call control related limiting there size to be no
larger than one datagram per message.

If a flow packet octets;
 o to-address - The IP address and port number reaches 0xffff, then of the next packet number
should wrap to 1.

Before a flow intended
   receiver. In case of redundant networks, to-address can be used it must be initiated, after any one
   of the flow is
complete it should multiple IP addresses of the receiver. The network which the
   datagram will actually be closed. Note it is assumed that before any flows
can sent through will be opened determined by MDTP due
   to the link rotation, unless the current mode prohibits MDTP initiate sequence has taken place link
   rotation; in such case the datagram will be sent through the network
   specified by to-address (see section
4). When 4.5).

Optional attributes:

 o mode-flags - This indicates a new MDTP initiate sequence occurs, any endpoint being
re-initialized will cause a closing of all outstanding flows during
that re-initialization. Before opening a flow operation mode, taking effect
   immediately including the opening end should
verify current datagram send;

 o context - optional information that will be carried in the version number
   Send.Failure notification to the ULP if the transportation of
   this datagram fails.

C) Receive.Data primitive

This primitive shall return the first datagram in the receiving MDTP endpoint in-queue to
ULP, if there is at
least 3. If one available. It may, depending on the version number is less than 3 then specific
implementation, also return other informations such as the MDTP endpoint
must NOT attempt to open a flow.


Stewart & Xie                                                  [Page 35]

Internet Draft   Multi-network Datagram Transmission Protocol   Apr 1999


7.1 Initiating a flow.

A flow sender's
address, whether there are more datagrams available for retrieval,
etc. The behavior is initiated by sending a Flow Initiate/Close Message. In all
flow undefined if no datagram the NOB bit is set. For available when this
primitive is invoked.

Mandatory attributes:

 o buffer - the Flow Initiate Message memory location indicated by the
UNR mode bit set as well. The Acknowledgment number (Seen) ULP to store the
   received datagram and other information.

Optional attributes:

   None.

D) Data.Arrive notification

MDTP shall invoke this notification on the
Sequence Number (Send) ULP when a datagram is set to 0 unless
successfully received and ready for retrieval.

E) Send.Failure notification

If a datagram can not be delivered MDTP shall invoke this is notification
on the first message in
which case ULP.

The following may be optionally passed with the TAG unlock value is set in notification:

 o data - the Send location ULP can find the un-delivered datagram.
 o context - optional information associated with this datagram (see section 4.1).

Until
   13.2).

F) Link.Status.Change notification

When a flow link is open successfully a receiver of a non-opened flow
datagram will silently discard the datagram. Upon sending marked down (e.g., when MDTP detects a flow
initiation link failure),
or marked up (e.g., when MDTP detects a T3-Send timer will be started link recovery), MDTP shall
invoke this notification on flow 0. The timer will
follow the same rules for retransmission and timing as outlined in
section 5. ULP.

The following illustration demonstrates shall be passed with the opening notification:

 o link-address - This indicates the IP address of flow 5:



Endpoint A                                      Endpoint Z
{App Initiates flow 5}
[Header Flags=NOB
	Mode=UNR
	Part=0,Of=1
        Seen=00000000,Send=0x0000 0000,Size=0,
	flow=0x0005 dg=0000	]------>
(Start T3-send timer f=5)
(Cancel T3-send timer f=5) <----------------- [Header Flags=NOB|ACK
                                               Mode=UNR
                                               Part=0,Of=1
                                               Seen=0x00000005,Send=0x00000000,
                                               Size=0, flow=0000 dg=0000]

In the above example note that for flow 0, unlike all others, no T2-Recv
timer is ever started. Each flow open/close must be independently 
acknowledged. Note also that in affected link;
 o new-status - This indicates the reply acknowledgment new status of the ACK bit link;

G) Communication.Up notification

This notification is 
set. If unlikely event that Endpoint-Z wished used when MDTP becomes ready to piggy back the open of 
flow 5 with send or receive
datagrams, or when a flow open of its own lost communication to an endpoint is restored.

The following shall be passed with the sequence would look as follows:

















Stewart & Xie                                                  [Page 36]

Internet Draft   Multi-network Datagram Transmission Protocol   Apr 1999



Endpoint A                                      Endpoint Z
{App Initiates flow 5}
[Header Flags=NOB
	Mode=UNR
	Part=0,Of=1
        Seen=0,Send=0,
	Size=0,
	flow=5, dg=0 ]------>
(Start T3-send timer f-5)                       {App Initiates flow 8}
(Cancel T3-send timer f-5)   <----------------- [Header Flags=NOB|ACK
                                                 Mode=UNR
                                                 Part=0,Of=1
                                                 Seen=5,
                                                 Send=0,
                                                 Size=0,flow=0008 dg=0000]
	                                         (Start T3-send timer notification:

 o status - f8)
[Header Flags=NOB|ACK
   Mode=0
   Part=0,Of=1
   Seen=8,Send=0,Size=0,
   flow=0, dg=0]-------------------------------->(Cancel T3-send timer This indicates what type of event that has occurred;
 o endpoint-id - f8)

Note The IP address and port number to identify the
   endpoint;

H) Communication.Lost notification

When MDTP loses communication to an endpoint completely or detects
that at the initiate of endpoint has performed a flow, the timer started is considered
the first timer for the flow, but shut-down operation, it is sent over flow 0. Note also
that a piggyback open is not allowed if shall invoke
this notification on the TAG sequences have not
been exchanged.

7.2 Flow acknowledgments

Normal dataflow's follow ULP.

The following shall be passed with the normal MDTP transmission formats (see
section 5) Acknowledgments when possible are piggy-backed on
datagrams.  Each flow maintains its own send timer. When no piggyback notification:

 o status - This indicates what type of data event that has occurred;
 o endpoint-id - The IP address and acknowledgments is possible, more than one flow can be be
acknowledged at the same time by using port number to identify the Flow Extend Acknowledgment
format.
   endpoint;
 o packets-enqueue - The Send field (now considered the number and location of extended
acknowledgments) will contain un-sent datagrams
   still holding by MDTP;
 o last-acked - the sequence number of acknowledgments in the
array.

During data transfer if the when last acked by that peer endpoint;
 o last-sent - the datagram sequence number reaches 0xffff last sent to that peer endpoint;

I) Change.Link.Rotation primitive

When the next packet should be labeled 1. Pkt 0 is never used upper layer wants to inform MDTP to make a specific network
eligible or ineligible for datagram
transfer.

One T2-Recv timer in link rotation, the upper layer will send
this primitive to MDTP.

Mandatory attributes:

 o  action - This indicates if the network is maintained to be made eligible or
             ineligible for all flows. If more than one flow link rotation.
 o  network-id - This is being timed the IP address and a datagram is to be transmitted then one port of the
flows will network to be acknowledged
    added or removed from link rotation consideration.

J) Open.Stream primitive

This shall be used by the upper layer to open a new stream.

Mandatory attributes:

 o endpoint-id - The IP address and port number to identify the T2-Recv timer will be left running
until expiration,
   peer endpoint to which will then cause the Flow Extended
Acknowledgment stream is to be sent, acknowledging all remaining flows.  The
following examples illustrate examples opened. An association
   must have existed at the time of flow acknowledgments. For
this example we assume stream open.

Returned attributes:

 o The stream number that Endpoint A has 3 flows open 5,7 and
9. Endpoint Z has 4 flows open 0x11, 8 4 and 1.



Stewart & Xie                                                  [Page 37]

Internet Draft   Multi-network Datagram Transmission Protocol   Apr 1999


Example 1: Endpoint A sends to Endpoint Z T2-Recv timer expires

Endpoint A                                      Endpoint Z
{ App sends first datagram on flow 5} 
[Header Flags=NOB|DAT
	Mode=REL
	Part=0,Of=1
        Seen=0x0000 0000,Send=0x0005 0001,Size=20]------>(Start T2-Recv)
(Start T3-send timer-f5)                         
                                            { T2-Recv Timer Expires }
(Cancel T3-send timer)     <--------------- [Header Flags=NOB|ACK
                                             Mode=REL
                                             Part=0,Of=1
                                             Seen=0x00050001,Send=0x00000000,
                                             Size=0]
	                                     (Start T3-send timer)

Example 1: Endpoint A sends to Endpoint Z T2-Recv timer expires

Endpoint A                                      Endpoint Z
{ App sends first datagram on flow 5} 
[Header Flags=NOB|DAT
	Mode=REL
	Part=0,Of=1
        Seen=0x0000 0000,Send=0x0005 0001,Size=20]------>(Start T2-Recv)
(Start T3-send timer-f5)                         
                                            { T2-Recv Timer Expires }
(Cancel T3-send timer)     <--------------- [Header Flags=NOB|ACK
                                             Mode=REL
                                             Part=0,Of=1
                                             Seen=0x00050001,Send=0x00000000,
                                             Size=0]
                                      (Start T3-send timer)





















Stewart & Xie                                                  [Page 38]

Internet Draft   Multi-network Datagram Transmission Protocol   Apr 1999


Example 2: Endpoint A sends multiple messages is opened.

K) Close.Stream primitive

This shall be used by the upper layer to Endpoint Z and 
           T2-Recv timer expires

Endpoint A                                      Endpoint Z
{ App sends 1 datagram on flow 5} 
[Header Flags=NOB|DAT
	Mode=REL
	Part=0,Of=1
        Seen=0x0000 0000,Send=0x0005 0002,Size=20]------>(Start T2-Recv)
(Start T3-send timer-f5)                         
{ App sends 1 datagram on flow 9} 
[Header Flags=NOB|DAT
	Mode=REL
	Part=0,Of=1
        Seen=0x0000 0000,Send=0x0009 0004,Size=20]------>
(Start T3-send timer-f9)                         
{ App sends 1 datagram on flow 5} 
[Header Flags=NOB|DAT
	Mode=REL
	Part=0,Of=1
        Seen=0x0000 0000,Send=0x0005 0003,Size=20]------>
{ App sends 1 datagram on flow 7} 
[Header Flags=NOB|DAT
	Mode=REL
	Part=0,Of=1
        Seen=0x0000 0000,Send=0x0007 0011,Size=20]------>

                                              { T2-Recv Timer Expires }
(Cancel T3-send timer-f5)     <-------------- [Header Flags=NOB|ACK
(Cancel T3-send timer-f9)                      Mode=REL
(Cancel T3-send timer-f7)                      Part=0,Of=1
                                               Seen=0x00050003,
	                                       Send=0x00000002,
                                               Size=0,
	                                       ex[0]=0x00090004,
	                                       ex[1]=0x00070011
                                               ]

















Stewart & Xie                                                  [Page 39]

Internet Draft   Multi-network Datagram Transmission Protocol   Apr 1999


Example 3: Endpoint A sends a message request to Endpoint Z, Endpoint Z
           piggy-backs close a ack.

{ App sends 1 datagram stream.

Mandatory attributes:

 o endpoint-id - The IP address and port number to identify the
   peer endpoint to which the stream is to be closed.

 o stream number - The stream number to identify the stream to be
   closed (this should be the number returned by the Stream.Open
   primitive on flow 5} 
[Header Flags=NOB|DAT
	Mode=REL
	Part=0,Of=1
        Seen=0x0000 0000,Send=0x0005 0004,Size=20]------>(Start T2-Recv)
(Start T3-send timer-f5)                      { App sends 1 message flow 0x11}
                                              ( cancel T2-Recv this stream).

6. Suggested MDTP Protocol Parameter Values

The following are suggested timer values for MDTP:

T1-init Timer )
(Cancel T3-send timer-f5)  <----------------- [Header Flags=NOB|DAT|ACK
(Start T2-Recv timer)                          Mode=REL
                                               Part=0,Of=1
                                               Seen=0x0005 0004,
                                               Send=0x0011 0008,
                                               Size=10]
	                                       (Start    -  160 ms
T2-receive Timer -   20 ms
T3-send timer-f0x11)
{ T2-Recv Timer Expires }
[Header Flags=NOB|ACK
	Mode=REL
	Part=0,Of=1
        Seen=0x0000 0000,Send=0x0011 0008,Size=0]------>(Cancel T3-send-f0x11)    -  160 ms + Last calculated RTT for that network.

The following protocol parameters are recommended:

Max.Outstanding.dg      - 20 messages
Max.Retransmit          - 10 attempts
Max.Init.Retransmit     - 8  attempts
Min.Mcast.Time.To.Reset - 5 seconds
Num.Of.Mcast.Reset.Msg  - 5 messages

7. Acknowledgments

The authors wish to thank Brian Wyld, A. Sankar, Henry Houh, Gary
Lehecka, Ken Morneault, Lyndon Ong, and others for their very valuable
comments.

8.  Author's Addresses

Randall R. Stewart &                          Tel: +1-847-632-7438
Cellular Infrastructure Group               EMail: stewrtrs@cig.mot.com
Motorola, Inc.
1475 W. Shure Drive, #2C-6
Arlington Heights, IL 60004
USA

Qiaobing Xie                                                  [Page 40]                                Tel: +1-847-632-3028
Cellular Infrastructure Group               EMail: xieqb@cig.mot.com
Motorola, Inc.
1501 W. Shure Drive, #2309
Arlington Heights, IL 60004
USA

Tom Bova                                    Tel: +1-703-484-3331
Cisco Systems Inc.                          EMail: tbova@cisco.com
13615 Dulles Technology Drive
Herndon, VA  20171

Suheel Hussain                              Tel: +1-919-472-2312
Cisco Systems Inc.                          EMail:ssh@cisco.com
7025 Kit Creek Road
Research Triangle Park, NC  27709

Ted Krivoruchka                             Tel: +1-703-484-3331
Cisco Systems Inc.                          EMail: tedk@cisco.com
13615 Dulles Technology Drive
Herndon, VA  20171

Renee Revis                                 Tel: +1-703-472-5681
Cisco Systems Inc.                          EMail: drrevis@cisco.com
7025 Kit Creek Road
Research Triangle Park, NC  27709

9. References

[1] Postel, J. (ed.), "Internet Protocol - DARPA Internet Program
Protocol Specification", RFC 791, USC/Information Sciences Institute,
September 1981.

[2] Postel, J., "User Datagram Protocol", RFC 768, USC/Information Sciences
Institute, August 1980.

[3] Postel, J. (ed.), "Transmission Control Protocol", RFC 793, USC/
Information Sciences Institute, September 1981.

[4] Jacobson V., "Congestion Avoidance and Control", Proceedings of
SIGCOMM '88, pp 314-329, August, 1988.

[5] Seth, T., etc. "Performance Requirements for Signaling in Internet Draft   Multi-network Datagram Transmission Protocol   Apr 1999


Example 4: Endpoint A sends a multiple message to Endpoint Z, Endpoint Z
           piggy-backs a ack
Telephony", Internet-Draft <draft-seth-sigtran-req-00.txt>, May, 1999.

Appendix A: Stream-based Reliable and sends Ordered Delivery

This defines a Extended flow Ack.

{ App sends 1 datagram on flow 5} 
[Header Flags=NOB|DAT
	Mode=REL
	Part=0,Of=1
        Seen=0x0000 0000,Send=0x0005 0005,Size=20]------>(Start T2-Recv)
(Start T3-send timer-f5)
{ App sends 1 datagram on flow 9} 
[Header Flags=NOB|DAT
	Mode=REL
	Part=0,Of=1
        Seen=0x0000 0000,Send=0x0009 0004,Size=20]------>
(Start T3-send timer-f9)                         
                                           { App sends 1 message flow 0x4}
(Cancel T3-send timer-f5)  <-------------- [Header Flags=NOB|DAT|ACK
(Start T2-Recv timer)                       Mode=REL
                                            Part=0,Of=1
                                            Seen=0x00050005,Send=0x00040004,
                                            Size=10]
	                                    (Start T3-send timer-f0x4)
                                            { T2-Recv Timer Expires }
	                                    (Start T3-send timer)
(Cancel T3-send timer)     <-------------- [Header Flags=NOB|ACK
                                            Mode=REL
                                            Part=0,Of=1
                                            Seen=0x00090004,Send=0x00000000,
                                            Size=0]
{ T2-Recv Timer Expires }
[Header Flags=NOB|ACK
	Mode=REL
	Part=0,Of=1
        Seen=0x0000 0000,Send=0x0004 0004,Size=0]------>(Cancel T3-send-f0x4)

Retransmissions reliable and resends are handled per section 5 but using the
flow formats (i.e. the NOB bit set) as described above. The rules ordered stream mechanism for
retransmission, windowing, flow control and declaration of endpoint
death are applied has defined MDTP. It is
optional for implementation.

A stream in section 5.

Note MDTP is defined as a sequence of user datagrams that messages needs
to the different flows are handed up ordered
correctly within the flow but not delayed be reliably delivered with respect to any sequence preservation of its own. In
other
flows transmission or retransmission.

7.3 Flow session closing

The application may signal a closing words, the delivery of a flow. If this occurs the
implementation will inform its peer stream shall not be delayed because of
the closing so that resources
used to track and maintain the flow can be reused/freed. The following
sequence is used to release a flow losses or re-transmissions occurred in this example we see other streams within the closing
of flow 5. Note it
same MDTP association. This capability is up to the sender to assure that all outstanding
datagrams are acknowledged before closing a flow:


Stewart & Xie                                                  [Page 41]

Internet Draft   Multi-network Datagram Transmission Protocol   Apr 1999


Endpoint A                                      Endpoint Z
{App Initiates flow 5}
[Header Flags=NOB|RES
	Mode=UNR
	Part=0,Of=1
        Seen=0,Send=0,Size=0,
	flow=5, dg=0 ]------>
(Start T3-send timer f-5)
(Cancel T3-send timer f-5) <----------------- [Header Flags=NOB|ACK|RES
                                               Mode=UNR
                                               Part=0,Of=1
                                               Seen=5,Send=0,
                                               Size=0,
                                               flow=0, dg=0]


Datagrams received critical requirement of
some telephony call signaling protocols [5].

Stream datagrams are identified by a endpoint directed setting FLO bit to a closed flow should be
silently discarded.

8. Mixed Mode Data Transmission

An endpoint can switch 1.

A.1 Stream Initiation

First, an MDTP association between reliable and unreliable transfer modes
at the two endpoints must be initiated
before any time during stream operation.

A stream shall be initiated (opened) by the data transfer.

The following sequence illustrates such a transfer mode change, sender before datagrams
can be sent in
which both endpoints starts with the unreliable transfer mode, stream, and
then Endpoint A switches after the stream is complete it shall
be terminated (closed) by the user. Also, both sides of the
association shall be able to reliable transfer mode.

Endpoint A                                  Endpoint Z
                                            {App send initiate or terminate streams
independently.

The sender initiates a stream by sending a Stream Initiation
(NOB|UNR), using the following header format:

                          Stream Initiation

    0                   1 message}
                        <------------------ [Header Flags=DAT|ACK
                                             Mode=UNR
                                             Part=0,Of=1
                                             Seen=11201,Send=1,Size=450]
..
{App send                   2                   3
    0 1 message}
[Header Flags=DAT|ACK
	Mode=UNR
	Part=0,Of=1
        Seen=451,Send=11201,Size=100]------>














Stewart & Xie                                                  [Page 42]

Internet Draft   Multi-network Datagram Transmission Protocol   Apr 1999


..
{App send 2 3 4 5 6 7 8 9 0 1 message}
[Header Flags=DAT|ACK
	Mode=GAR
	Part=0,Of=1
        Seen=451,Send=11301,Size=100]------> (Start T2-receive timer)
(Start T3-send timer)
                                             {App sends 2 3 4 5 6 7 8 9 0 1 message}
                                             (Cancel T2-receive timer)
                                    /------- [Header Flags=DAT|ACK
                                   /         Mode=UNR
                                  /          Part=0,Of=1
                                 /           Seen=11401,Send=1,Size=450]
(Cancel T3-send timer)  <-------/

..
{App sends 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 MDTP Protocol Identifier                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Version     |              Flags            |   In Queue    |
   |               |N N W I F R D A M S W R R F G U|               |
   |               |O O I S I T A C U H N E T L A N|               |
   |               |M B N B R M T K L U R 1 message}
[Header Flags=DAT|ACK
	Mode=GAR
	Part=0,Of=1
        Seen=451,Send=11401,Size=100]------> (Start T2-receive timer)
(Start T3-send timer)





                                             ..
                                             {Timer T2 Expires}
(Cancel T3-send timer)  <------------------- [Header Flags=ACK
                                              Mode=0
                                              Part=0,Of=0
                                              Seen=11501,Send=146] C O R R|               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Seen = 0x0 (or Tag)                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           Send = 0x0                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        Data Size              |    Part       |      Of       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        New Stream Number      |              0x0              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Note that in the second datagram sent by Endpoint A the mode is
switched to reliable transfer mode (with GAR bit set). This causes
Endpoint A to start its T3-send timer. When Endpoint Z receives the
datagram and realizes Stream Initiation, the mode change, it starts its T2-receive timer.
At this point, Endpoint Z also must update its Seen value to 11301. 
This will allow Endpoint Z to align its Seen counter and Send shall be set to 0,
and the Seen value number of this the new stream being initiated shall be indicated
in the first reliable datagram from Endpoint
A. This prevents Endpoint Z from requesting retransmission two octets of the data
that Endpoint A may not have.


9.  Bundled Messages

In order to increase network utilization, MDTP allows an endpoint to
bundle small application messages into one single datagram for
transmission. This bundled mode can be applied to both reliable and
unreliable datagrams.

An endpoint indicates to its peer that it field.

However, if this is currently in bundled

Stewart & Xie                                                  [Page 43]

Internet Draft   Multi-network Datagram Transmission Protocol   Apr 1999


mode by setting the BUN bit in first datagram sent out after receiving the mode field. 


9.1 Format of Bundled Datagram

The ISB bit in
Initiation Ack from the flag peer (see section 3.1), the Seen field is of
above Stream Initiation shall be set to indicate the current datagram is
bundled, i.e., it contains multiple messages. The format Tag value carried in the
Initiation Ack.

Upon the reception of the Stream Initiation, the peer shall respond
immediately with a bundled
datagram is defined as follow: Stream Initiation Ack (NOB|UNR|ACK), using the
following header format:

                        Stream Initiation Ack

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 MDTP Protocol Identifier 1                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 MDTP Protocol Identifier 2                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 Acknowledgment Number (Seen)                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Sequence Number (Send)                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        Data Size              |    Part       |      Of       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   Version     |              Flags            |     Mode      |   Version     | Num On   In Queue    |
   |               |N N W I F R D A|B A M S W R R B F G U|               |
   |               |O O I S I E T A C|R C U H N E E U T L A N|               |
   |
   |G               |M B N B R S M T K|O K L U R 1 2 N C O R R|               |               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Seen = Stream Number Of Messages        |   Size of first message B1    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   |                     B1 octets of data                         |
   |                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Size of second message B2  |                               | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
   |                     B2 octets of data                         |
   |                           Send = 0x0                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   \                                                               \
   /                                                               /
   \                                                               \
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        Data Size of last message BL    |                               | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
   |                     BL octets of data              |    Part       |      Of       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


Data Size in a bundled datagram indicates the actually size of the
data field of the datagram, including both the bundling overhead and
the actually application data. Since no fragmentation is allowed in a
bundled datagram, the Part field will always be '0' and the Of field
always be '1'.

Stewart & Xie                                                  [Page 44]

Internet Draft   Multi-network Datagram Transmission Protocol   Apr 1999

The first two octets of the data field is a 16 bit integer indicating following example shows the number opening of messages bundled in the datagram. This is followed
immediately stream 5 by a list of bundled messages. Each bundled message starts
with an integer of two octets indicating the size of the data in "A":

Endpoint A                                      Endpoint Z
{App Initiates stream 5}
[Header Flags=FLO|UNR
        Part=0,Of=1
        Seen=0,Send=0,Size=0,
        Stream=5 ]--------------------------->
(Start T3-send timer)
(Cancel T3-send timer) <--------------------- [Header Flags=FLO|UNR|ACK
                                               Mode=UNR
                                               Part=0,Of=1
                                               Seen=5,Send=0]

A.2 Stream Termination

For an existing stream, either side shall be allowed to terminate the
message, followed
stream by sending a Stream Termination (FLO|UNR|SHU) to the data itself.

All integers in other side.

Besides flag RES, The Stream Termination shall use the same header
format as that used in Stream Initiation datagram should (see A.2)

A Stream Termination Ack (FLO|UNR|SHU|ACK) shall be transmitted in the network byte
order.


9.2 Bundled Transfer

Two protocol parameters, namely the Min.Bundle and Max.Bundle, are
used to control sent by the assembly of bundled datagrams. If peer
endpoint in response.

The following example shows the current size termination of stream 5 by "A":

Endpoint A                                      Endpoint Z
{App terminates stream 5}
[Header Flags=FLO|UNR|SHU
        Part=0,Of=1
        Seen=0,Send=0,Size=0,
        Stream=5 ]--------------------->
(Start T3-send timer s-5)
(Cancel T3-send timer s-5) <------------ [Header Flags=FLO|UNR|SHU|ACK
                                          Part=0,Of=1
                                          Seen=5,Send=0]

Datagrams associated to a bundled datagram terminated stream received by either side
should be silently discarded. It is smaller than Min.Bundle, the endpoint will
withhold up to the datagram from transmission and start T4-bundle timer. If
new out-bound data becomes available for transmission, side which terminates
the endpoint
will attempt stream to bundle assure that all outstanding user datagrams in the new data with stream
are acknowledged before the current withheld termination.

A.3 Stream Datagram Transfer

A.3.1 Header Format in Stream Datagrams with User Data

The MDTP header in a stream datagram
by using with user data shall have the
following rules:

A) If the size of the new format:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  MDTP Protocol Identifier                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Version     |              Flags            |   In Queue    |
   |               |N N W I F R D A M S W R R F G U|               |
   |               |O O I S I T A C U H N E T L A N|               |
   |               |M B N B R M T K L U R 1 C O R R|               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                             Seen                              |
   |         Stream Number         |    Sequence Number            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                             Send                              |
   |         Stream Number         |    Sequence Number            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        Data Size              |    Part       |      Of       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   \                                                               \
   /                             data is greater than or equal to
   Min.Bundle, the current withheld datagram will be transmitted                              /
   \                                                               \
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The stream number and
   T4-bundle timer will be canceled. Then, the new data will be
   transmitted sequence number in a separate datagram.

B) If the size of the new data is less than Min.Bundle, but the
   combined size of the current datagram and the new data is greater 
   than or equal to Max.Bundle, the current datagram will Send field shall be sent and used
by the new data will be withheld as sender to identify the new current stream datagram.

C) If the size of the new data is less than Min.Bundle, and the
   combined size of the current datagram and the new data is less than
   Max.Bundle, the new data will be bundled into And, the current
   datagram
stream number and sequence number in the bundled datagram will Seen field shall be immediately transmitted.

D) If used
by the size sender to acknowledgment of the new data is less than Min.Bundle, stream datagrams it has received.

Stream number 0 and the
   combined size of the current datagram sequence number 0 are reserved for special
purposes and are not valid stream number or sequence number.

A.3.2 Transmission of Stream Datagrams

The rules of using the new data is less than
   Min.Bundle, the new data will be bundled into the current
   datagram. And Seen Sequence Number and Send Sequence Number
are similar to those defined for normal MDTP non-stream datagram
transmissions (see section 4), except that for stream transfer the T4-bundle timer will be restarted.

E) If T4-bundle
sequence numbers shall roll-over to 1 after 0xFFFF.

Moreover, each stream maintains its individual T3-send timer, but only
one global T2-receive timer expires, the current is maintained for all existing streams.

Acknowledgment to a stream datagram will shall either be sent
   immediately.

F) If the size of the new data is greater than separately
or be piggy-backed with a stream datagram (not necessarily belonging
to the Max.Bundle, same stream) traveling in the
   current datagram will be sent. Then, opposite direction. For a
separate Stream Ack, the new data Send field will be fragmented
   for transmission (see 9).







Stewart & Xie                                                  [Page 45]

Internet Draft   Multi-network Datagram Transmission Protocol   Apr 1999 set to 0000:0000.

The following is shows an example of bundled data transfer, assuming
Max.Bundle=4096 transmitting a stream datagram
(FLO|REL|DAT) and Min.Bundle=1700: a separate Stream Ack (FLO|REL|ACK):

Endpoint A                                      Endpoint Z
{App sends 1 messages first data on stream 5}
[Header Flags=FLO|REL|DAT
        Part=0,Of=1
        Seen=0-0,Send=5-1,Size=20]----\
(Start T3-send timer-s5)               \--->(Start T2-recv)
                                            ...
                                            {T2-recv Timer Expires}
(Cancel T3-send timer-s5)   <--------------- [Header Flags=FLO|REL|ACK
                                             Part=0,Of=1
                                             Seen=5-1,Send=0-0,Size=0]

The following example shows the use of 100 octets}
(withhold and Start T4-Bundle timer)

.. a piggy-backed Stream Ack.

{App sends 1 messages of 100 octets}
(bundling into current datagram)

.. new data on stream 5}
[Header Flags=FLO|REL|DAT
        Part=0,Of=1
        Seen=0-0,Send=5-4,Size=20]--------->(Start T2-recv)
(Start T3-send timer-s5)                    ...
                                            {App sends 1 messages of 100 octets}
(bundling into current datagram)

..
{T4-bundle timer expires} data on stream 11}
                                            (cancel T2-recv Timer)
                                     /----- [Header Flags=DAT|ACK
	Mode=GAR|BUN Flags=FLO|REL|DAT|ACK
                                    /        Part=0,Of=1
        Seen=146,Send=1001,Size=308]-------->
                                   /         Seen=5-4,Send=11-8,Size=10]
                                  /         (Start T2-receive T3-send timer-s11)
(Cancel T3-send timer-s5)  <-----/
(Start T2-recv timer)
(T3-send timer starts)
                                              ..
                                              {Timer T2
...
{T2-recv Timer Expires}
(cancel T3-send)            <----------------
[Header Flags=ACK
                                               Mode=0
                                               Part=0,Of=0
                                               Seen=1309,Send=146]

Notice Flags=FLO|REL|ACK
        Part=0,Of=1
        Seen=11-8,Send=0-0,Size=0]--------->(Cancel T3-send-s11)

Note that the Data Size in the when piggy-back a Stream Ack with an out-bound stream
datagram sent by Endpoint A is not
300 but 308. This is due to the fact that this size reflects the
size of when more than one streams have un-acked datagrams, the data field
endpoint shall choose one stream and piggy-back a Stream Ack on one of
the datagram including the bundling overhead.

When the bundled datagram arrives at the receiving endpoint, each
message is unbundled datagrams, and delivered separately to shall leave the upper level
application.


10. Fragmented Messages

When T2-recv timer running.

A.3.3 Extended Stream Ack

Upon the size expiration of an out-bound message exceeds the value defined in T2-recv timer, if there are more than one
stream datagrams received but yet acked upon by the
protocol parameter Max.Bundle, endpoint, an
Extended Stream Ack shall be used.

The following defines the endpoint will fragment header format of the message
into smaller pieces Extended Stream Ack
that acknowledges N stream datagrams received:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  MDTP Protocol Identifier                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Version     |              Flags            |   In Queue    |
   |               |N N W I F R D A M S W R R F G U|               |
   |               |O O I S I T A C U H N E T L A N|               |
   |               |M B N B R M T K L U R 1 C O R R|               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                             Seen                              |
   |         Stream Number #0      |    Sequence Number #0         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  Number of sizes equal to or smaller than Max.Bundle and
send each piece out in a separate datagram.

The Extra Acks = N-1                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        Data Size              |    Part and       |      Of fields are used       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         Stream Number #1      |    Sequence Number #1         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   \                                                               /
   /                                                               \
   \                                                               /
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         Stream Number #N-1    |    Sequence Number #N-1       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Note that an Extended Stream Ack is identified by setting the Seen
field to disassemble and reassemble the 
fragmented message. number of extra acks carried in its data field, as shown
above. Also, Extended Stream Acks shall not be piggy-backed.

The following example shows the transmission using of a fragmented message 
(assuming Max.Bundle=4096, Min.Bundle=1700):




Stewart & Xie                                                  [Page 46]

Internet Draft   Multi-network Datagram Transmission Protocol   Apr 1999 an Extended Stream Ack
(NOB|REL|ACK) by "Z":

Endpoint A                                      Endpoint Z
{App sends 1 messages 8544 octets long} data on stream 5}
[Header Flags=DAT|ACK
	Mode=GAR|BUN
	Part=0,Of=3
        Seen=146,Send=1001,Size=4072]-------> Flags=FLO|REL|DAT
        Part=0,Of=1
        Seen=0-0,Send=5-2,Size=20]----------> (Start T2-receive timer) T2-recv)
(Start T3-send timer-s5)
{App sends data on stream 9}
[Header Flags=DAT|ACK
	Mode=GAR|BUN
	Part=1,Of=3
        Seen=146,Send=5073,Size=4072]-------> Flags=FLO|REL|DAT
        Part=0,Of=1
        Seen=0-0,Send=9-4,Size=20]---------->
(Start T3-send timer-s9)
{App sends more data on stream 5}
[Header Flags=DAT|ACK
	Mode=GAR|BUN
	Part=2,Of=3
        Seen=146,Send=9145,Size=400]--------> Flags=FLO|REL|DAT
        Part=0,Of=1
        Seen=0-0,Send=5-3,Size=20]---------->
(Restart T3-send timer-s5)
{App sends data on stream 7}
[Header Flags=FLO|REL|DAT
        Part=0,Of=1
        Seen=0-0,Send=7-11,Size=20]--------->
(Start T3-send timer)
                                              ..
                                              {Timer T2 timer-s7)
                                              ...
                                              {T2-recv Timer Expires}
                                 /-----------
(Cancel T3-send timer-s5)     <-------------- [Header Flags=ACK
                                /              Mode=0
                               /               Part=0,Of=0
(cancel timer T3) <-----------/                Seen=9545,Send=146]

Notice that Endpoint A is using the reliable transfer mode to send the
fragmented message. In this mode, Endpoint Z will hold the fragments
and request retransmission if a fragment is found missing, i.e., a gap
is found in the received data (see 5). When all the parts of the
fragmented message are received, the endpoint will re-assemble the
message and dispatch it to the upper level application.

It is also allowed in MDTP to send fragmented message using unreliable
transfer mode. However, in unreliable mode, each fragment datagram
will be dispatch to the application upon its arrival, and no
retransmission will be requested even if a fragment is found missing.

Bundling is prohibited if the current datagram contains a fragment of
a fragmented message.


11. Non-protocol Datagrams

The MDTP protocol allows an endpoint to send and receive non-protocol
datagrams such as the traditional UDP datagrams. Non-protocol
datagrams are detected by the absence of the MDTP protocol
identifiers at Flags=FLO|REL|ACK
(Cancel T3-send timer-s7)                      Part=0,Of=1
(Cancel T3-send timer-s9)                      Seen=5-3,NumExtAck=2,
                                               Size=0,
                                               ext[0]=9-4,
                                               ext[1]=7-11]

A.4 Other Issues with Stream Transfer

- -- Congestion control, including the beginning of rules for timer management and window
management, shall apply to Stream Transfer the datagram. A non-protocol
transmission received by an MDTP endpoint is termed same way as a "raw"
datagram. When a raw datagram arrives, the receiving endpoint will set
itself into raw mode and start sending back it does to its peer in raw mode
non-Stream based transfer, as well.

Once defined in section 4.3.

- -- When an endpoint association is in raw mode re-initialized (see section 3.4), all existing
stream within that association will be automatically terminated.

- -- The receiver shall silently discard any datagrams associated
with a peer, only a change of
operational mode by the application stream which has not been initiated or a reception of a MDTP has already been
terminated.

- -- The same re-transmission and link rotation rules as defined in
section 4 shall apply to Stream Transfer.

- -- Bundled Message (see Appendix B) may be allowed in Stream Transfer,
but fragmentation (see Appendix C) shall not be allowed.

Appendix B: Bundled Message Transfer

This defines the mechanism for bundled datagram
will bring transport in MDTP. It
is optional for implementation.

Bundling is sometimes desired by the endpoint out user when transferring small
datagrams, as a way of raw mode. improving network utilization.

In the latter case, the

Stewart & Xie                                                  [Page 47]

Internet Draft   Multi-network Datagram Transmission Protocol   Apr 1999


endpoint will use the default MDTP operational mode predefined by the
application for bundled transfer, MDTP transmissions. When allows an endpoint changes from raw
mode into MDTP mode, the normal MDTP initiation to bundle small
application messages must be
exchanged between the two endpoints, as described in 4.


12. Broadcast and Multicast

Broadcast and multicast are supported by MDTP when the underlying
transport layer supports them. Both types of transmissions are carried
out in unreliable transfer mode.

For broadcast datagrams, the BRO bit will into one single datagram for transmission. This
bundled mode can be set applied to '1' both reliable and the UNR unreliable datagrams
(see Appendix E for Unreliable Delivery).

Note that an endpoint shall never send bundled messages to a peer if
that peer endpoint set NOB bit will be to 1 during their association
initialization (see section 3).

B.1 Format of Bundled Datagram

The ISB bit in the flag field is set to '0' indicate the current datagram
is bundled, i.e., it contains multiple messages. The format of a
bundled datagram is defined as follows:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  MDTP Protocol Identifier                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Version     |              Flags            |   In Queue    |
   |               |N N W I F R D A M S W R R F G U|               |
   |               |O O I S I T A C U H N E T L A N|               |
   |               |M B N B R M T K L U R 1 C O R R|               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 Acknowledgment Number (Seen)                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Sequence Number (Send)                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        Data Size              |    Part       |      Of       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Total Number Of Messages=N   |   Message #1 Size = B1        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   |                     B1 octets of data                         |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Message #2 Size = B2        |                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
   |                     B2 octets of data                         |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   \                                                               \
   /                                                               /
   \                                                               \
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Message #N Size = BN        |                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
   |                     BN octets of data                         |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Data_Size in a bundled datagram indicates the mode field. For multicast datagrams, actually size of the
data field of the datagram, including both the BRO bit bundling overhead and
the UNR bit will be set to '1'.

For multicast datagrams, the value actually user data. Since no fragmentation is allowed in a bundled
datagram, the Send Part field will indicate always be '0' and the number Of field always be
'1'.

The first two octets of multicast datagrams transmitted by the sender. This
information makes it possible for data field is a 16 bit integer indicating
the receiver number of the multicast to
detect duplicated multicast datagrams and also to detect lost
multicast datagrams. A multicast datagram transmission MUST use
the alternate multicast header filling in both the multicast transmit
to address as well as its lowest network address messages bundled in the multicast
from address.

Bundling and fragmentation are not allowed in either multicast or
broadcast datagrams.


12.1 Multicast/Broadcast initialization.

No initiation is needed for an endpoint to transmit multicast or
broadcast datagrams. However, caution should be taken when
transmitting non-protocol datagrams (i.e., datagrams with no MDTP
protocol header) in multicast or broadcast transmission. current datagram. This is
because the non-protocol datagrams may inadvertently force all the
receiving endpoints of the multicast or broadcast transmission into
raw mode (see 10).


12.2 Transmission of Broadcast Datagrams.

When sending
followed immediately by a broadcast datagram, the endpoint will not take effort
to prevent duplicate transmissions (this is likely to occur
especially when multiple networks exist). The application at the
receiving end must be prepared to handle duplicate
broadcast list of bundled messages. 







Stewart & Xie                                                  [Page 48]

Internet Draft   Multi-network Datagram Transmission Protocol   Apr 1999

The following is Each bundled
message starts with an example integer of broadcast datagram transmission:

Endpoint A                                               Endpoint Z
{application sends 2 messages }
[Header Flags=DAT
	Mode=BRO
	Part=0,Of=1
        Seen=0,Send=0,Size=200]--------------> (Datagram may appear
                                                more than once.)
[Header Flags=DAT
	Mode=BRO
	Part=0,Of=1
        Seen=0,Send=0,Size=100]-------------->

Notice that no timers are used on either end, and Seen and Send values
in two octets indicating the datagrams are always '0'.


12.3 Transmission size of Multicast Datagrams.

Unlike
the broadcast transmission, when multicast datagrams are
transmitted data in the receiving endpoints message, followed by the data itself.

All integers in the datagram should take effort be transmitted in the network byte
order.

B.2 Bundled Datagram Transfer

The T4-bundling timer and two protocol parameters, namely the
Min.Bundle and Max.Bundle, are used to prevent
duplicate copies control the bundling of datagrams from being distributed to their
applications. 

This is possible because user
datagrams.

The endpoint will withhold the datagram from transmission and start
T4-bundle timer, if the combined size of multicast all user datagrams currently
pending for transmission in the out-bound buffer is
usually addressed to smaller than
'Min.Bundle'.

Each time a special multicast network address. The receiving
endpoints can thus use this multicast address in combination with new out-bound user data becomes available for
transmission, the
sender's address endpoint will attempt to detect duplicate transmissions of a multicast 
datagram.

The bundle the new data with
the current withheld datagram by using the following example illustrates multicast transmissions between two
endpoints. 

Endpoint A                                               Endpoint Z
{app multicasts a message}
[Header Flags=DAT
	Mode=BRO|UNR
	Part=0,Of=1
        Seen=0,Send=5,Size=250]--------------> (may receive more rules:

A) If the size of the new data is greater than one copy)
..

{app multicasts or equal to
   'Min.Bundle', the current withheld datagram will be transmitted and
   T4-bundle timer will be canceled. Then, the new data will be
   transmitted in a message}
[Header Flags=DAT
	Mode=BRO|UNR
	Part=0,Of=1
        Seen=0,Send=6,Size=500]--------------> (may receive more separate datagram.

B) If the size of the new data is less than one copy)


Notice 'Min.Bundle', but the values
   combined size of the Send field in current datagram and the multicast datagrams (which
are 5 new data is greater
   than or equal to 'Max.Bundle', the current datagram will be sent and 6, respectively). They represent
   the sequence numbers new data will be withheld as the new current datagram.

C) If the size of the
multicast datagrams Endpoint A has sent out. Endpoint Z should use new data is less than 'Min.Bundle', and the

Stewart & Xie                                                  [Page 49]

Internet Draft   Multi-network Datagram Transmission Protocol   Apr 1999


Send value found in
   combined size of the incoming multicast datagrams to detect any
missing or duplicate datagrams.

Duplicate datagrams current datagram and the new data is greater
   than 'Min.Bundle', but less than 'Max.Bundle', the new data will be discarded
   bundled into the current datagram and no effort the bundled datagram will be made to
retransmit lost multicast datagrams.

For example, each endpoint can track
   immediately transmitted. and T4-bundle timer will be canceled.

D) If the last 32 datagrams received by
using a sliding window size of 32 bits. Each time a the new datagram with a
sequence number higher data is less than 'Min.Bundle', and the
   combined size of the current window head datagram and the new data is received, less than
   Min.Bundle, the
window can new data will be moved up. If a datagram received has a sequence number
below bundled into the current window head, then a check of
   datagram. And the last 32 received
datagrams' sequence numbers can determine whether T4-bundle timer will be restarted.

E) If T4-bundle timer expires, the new current datagram is will be sent
   immediately.

F) When a T2-receive timer expires, any bundled data waiting to be
   transmitted should be sent immediately with a
duplicate. piggy-backed Ack to
   acknowledge all un-acked data previously received.

G) If the sequence number of the new datagram a T4-bundle timer is below the
current window tail then running and data arrives, the datagram T2-receive
   timer should not be started.

H) A T4-bundle timer should never be considered canceled unless it is being
   supplanted by a duplicate
and discarded.


12.4 Reset of the Multicast Datagram Sequence Number

If the Seen field in T3-send timer.

When a multicast bundled datagram arrives at the receiving endpoint, each
message is set unbundled and delivered separately to '1', it is an
indication that the sender has reset its multicast datagram sequence
number. upper layer.

The receiving endpoint, upon detecting this reset indicator in following are the incoming multicast datagram, should start a procedure to adopt suggested protocol parameter values for bundled
datagram transfer:

T4-bundle Timer  -   40 ms
Min.Bundle       - 1000 octets
Max.Bundle       - 1432 octets

Appendix C: Fragmented Message Transfer

This defines the
new sequence number mechanism for error detection. However, caution
should be taken to prevent false resets due to duplicated datagrams
with reset indicator propagating through multiple networks. 

To guarantee that all receivers fragmented datagram transport in
MDTP. It is optional for implementation.

When the size of an out-bound user message exceeds the multicast group adopt value defined
in the new
sequence number, protocol parameter Max.Bundle, the reset indicator should be repeated within endpoint shall fragment the
first N multicast datagrams sent
message into smaller pieces of size equal to or smaller than
'Max.Bundle' and send each piece out after the reset. N is predefined
by the protocol parameter Num.Of.Mcast.Reset.Msg.

At in a separate datagram.

The "Part" and "Of" fields are used to disassemble and reassemble the receiving endpoint, when
fragmented message. The combination of the reset indicator maximal 'Of' value, which
is detected 255, and the
new sequence number maximal Data Size (see section 2.2) will be adopted. determined
the maximal size of a single user message that the MDTP can send or
receive in fragmented message transfer mode.

However, if two reset events are
detected within an endoint shall never send fragmented datagrams to a predefined time interval (Min.Mcast.Time.To.Reset), peer if
that peer set the second reset indicator will be ignored.


















Stewart & Xie                                                  [Page 50]

Internet Draft   Multi-network Datagram Transmission Protocol   Apr 1999 NOM bit to 1 during their association
initialization.

The following is an example shows the transmission of a fragmented message
(assuming Num.Of.Mcast.Reset.Msg = 4): Max.Bundle=1432, Min.Bundle=1000):

Endpoint A                                      Endpoint Z

[Header Flags=DAT
	Mode=BRO|UNR
	Part=0,Of=1
        Seen=0,Send=17859,Size=300]---------->
`<
{reset
{App sends message sequence number indicated}

[Header Flags=DAT
	Mode=BRO|UNR
	Part=0,Of=1
        Seen=1,Send=1,Size=250]--------------> (record new sequence
                                                number, datagram may
                                                appear more than once) size=3300 octets}
[Header Flags=DAT
	Mode=BRO|UNR
	Part=0,Of=1
        Seen=1,Send=2,Size=250]--------------> (may appear more than
                                                once) Flags=DAT|ACK|GAR
        Part=0,Of=3
        Seen=3,Send=16,Size=1432]-------> (Start T2-receive timer)
[Header Flags=DAT
	Mode=BRO|UNR
	Part=0,Of=1
        Seen=1,Send=3,Size=500]--------------> (may appear more than
                                                once) Flags=DAT|ACK|GAR
        Part=1,Of=3
        Seen=3,Send=17,Size=1432]------->
[Header Flags=DAT
	Mode=BRO|UNR
	Part=0,Of=1
        Seen=1,Send=4,Size=500]--------------> (may appear more than
                                                once) Flags=DAT|ACK|GAR
        Part=2,Of=3
        Seen=3,Send=18,Size=436]-------->
(Start T3-send timer)
                                              ..
                                              {Timer T2 Expires}
                                 /----------- [Header Flags=DAT
	Mode=BRO|UNR
	Part=0,Of=1
        Seen=0,Send=5,Size=100]--------------> (may appear more than
                                                once)


In Flags=ACK
                                /              Mode=0
                               /               Part=0,Of=0
(cancel timer T3) <-----------/                Seen=18,Send=4]

Notice that "A" is using the above example Endpoint Z would detect reliable transfer mode to send the reset indicator in
fragmented message, therefore "Z" will hold the second multicast datagram fragments and adopt the new sequence number which request
retransmission if a fragment is 1. Then, it would ignore the reset indicator found missing, i.e., if a gap is found
in the subsequent three
(3) datagrams since they arrived within a very short time interval. 


13. Interface with upper level protocols

The upper level protocols (ULP) shall request for services by passing
primitives to MDTP and shall receive notifications from MDTP for
various events. 

The primitives received data (see ). When all the parts of the fragmented
message are received, the receiving endpoint will re-assemble the
message and notifications described dispatch it to the upper layer.

It is also allowed in this MDTP to send fragmented message using Unreliable
Transfer mode (see section should 4.5). However, in unreliable mode, each
fragment will be

Stewart & Xie                                                  [Page 51]

Internet Draft   Multi-network Datagram Transmission Protocol   Apr 1999


used as a guideline for implementing MDTP.

13.1 Init.MDTP primitive

This primitive allows MDTP dispatch to initialize the application upon its internal data structures arrival, and allocate necessary resources for setting up its operation
environment. Note that once MDTP no
retransmission will be requested even if a fragment is initialized, ULP can communicate
directly with any other endpoints without re-invoking this primitive.

Mandatory attributes:

None.

Optional attributes:

The following types found missing.

Bundling is prohibited if the current datagram contains a fragment of attributes may be passed along with
a fragmented message.

Appendix D: Multicast Datagram Transfer

This defines the primitive:

 o Timer selection mechanism for unreliable transportation of multicast
datagrams in MDTP. It is optional for implementation.

D.1 Multicast Datagram Header Format

Multicast datagrams are identified by setting MUL, UNR, and its operation syntax -- DAT bits
to indicate 1.

Two new fields are added to MDTP
   an alternative timer the standard MDTP should use for its operation.
 o Initial MDTP operation mode;
 o IP port number, if ULP wants it to be specified;

13.2 Send.Data primitive

This is the main method datagram header to send datagrams via MDTP.

Mandatory attributes:

 o data
support multicast:

Multicast To Transmit address - This is the payload ULP wants to transmit;
 o size - The size of the payload multicast address, in number of octets;
 o to-address
network byte order, that the sender transmitted the data to. The
receiver can use this information for internal tracking purposes.

Multicast From - The IP This is the network address and port number of (or the intended
   receiver. In case IP Address of
Network 1 as described in 3.2, if redundant networks, to-address can be any one 
   of the multiple IP addresses networks exist) of the receiver. The network which the
   datagram will actually be sent through will be determined by MDTP due
   to the link rotation, unless the current mode prohibits MDTP link
   rotation;
sender, in such case the datagram will be sent through the network
   specified by to-address (see section 4.5).

Optional attributes:

 o mode-flags byte order.

                 MDTP Header Format - This indicates a new Multicast Format

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  MDTP operation mode, taking effect
   immediately including the current datagram send;

 o context Protocol Identifier                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Version     |              Flags            |   In Queue    |
   |               |N N W I F R D A M S W R R F G U|               |
   |               |O O I S I T A C U H N E T L A N|               |
   |               |M B N B R M T K L U R 1 C O R R|               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 Acknowledgment Number (Seen)                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Sequence Number (Send)                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        Data Size              |    Part       |      Of       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  Multicast To Transmit address                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |             Multicast From - optional information that will be carried in senders base address             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   \                                                               \
   /                             data                              /
   \                                                               \
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

For multicast datagrams, the
   Send.Failure notification to value in the ULP if Send field shall indicate
the transportation sequence number of
   this datagram fails. 

13.3 Receive.Data primitive multicast datagrams transmitted by the
sender. This primitive shall return information helps the first datagram in receiver of the MDTP in-queue multicast to
ULP, if there is one available. It may, depending on the specific
implementation, detect
duplicated multicast datagrams and also return other informations such as to detect lost multicast
datagrams from the sender's

Stewart & Xie                                                  [Page 52]

Internet Draft   Multi-network Datagram Transmission Protocol   Apr 1999


address, whether there same sender. The Seen field shall normally be
set to 0, unless in some special cases stated below.

Bundling and fragmentation are more datagrams available not allowed in either multicast or
broadcast datagrams.

No initiation shall be needed for retrieval,
etc. an endpoint to transmit to a
multicast address.

D.2 Transmission of Multicast Datagrams

The behavior is undefined if no datagram is available when this
primitive is invoked.

Mandatory attributes:

 o buffer - following example illustrates multicast transmissions between two
endpoints.

Endpoint A                                               Endpoint Z
{App multicasts a message}
[Header Flags=MUL|UNR|DAT
        Part=0,Of=1
        Seen=0,Send=5,Size=250]--------------> (no Ack necessary)

...
{App multicasts a message}
[Header Flags=MUL|UNR|DAT
        Part=0,Of=1
        Seen=0,Send=6,Size=500]--------------> (no Ack necessary)


Notice that the memory location indicated by values of the ULP to store Send field in the 
   received datagram multicast datagrams
(which are 5 and other information.

Optional attributes:

   None.

13.4 Data.Arrive notification

MDTP shall invoke this notification on 6, respectively). They represent the ULP when a datagram is
successfully received sequence numbers
of the multicast datagrams "A" has sent out. Endpoint Z should use
this value to detect missing or duplicate datagrams.

Duplicate datagrams will be discarded and ready for retrieval.

13.5 Send.Failure notification no effort will be made to
retransmit lost multicast datagrams.

D.3 Reset of the Multicast Datagram Sequence Number

If the Seen field of a received multicast datagram can not be delivered MDTP shall invoke equals to '1', this notification
on
indicates that the ULP. sender has reset its multicast datagram sequence
number. The following may receiving endpoint, upon detecting this reset indicator in
the incoming multicast datagram, should start a procedure to adopt the
new sequence number for error detection. However, caution
should be optionally passed taken to prevent false resets due to duplicated datagrams
with reset indicator propagating through multiple networks.

To guarantee that all receivers of the notification:

 o data - multicast group adopt the location ULP can find new
sequence number, the un-delivered datagram.
 o context - optional information associated with this datagram (see
   13.2).

13.5 Link.Status.Change notification

When a link reset indicator should be repeated within the
first N multicast datagrams sent out after the reset. N is marked down (e.g., when MDTP detects a link failure),
or marked up (r.g., predefined
by the protocol parameter 'Num.Of.Mcast.Reset.Msg'.

At the receiving endpoint, when MDTP detects the reset indicator is detected the
new sequence number will be adopted. However, if two reset events are
detected within a link recovery), MDTP shall
invoke this notification on predefined time interval (Min.Mcast.Time.To.Reset),
the ULP. 

The following shall second reset indicator will be passed with ignored.

The suggested values for these two protocol parameters are:
   Min.Mcast.Time.To.Reset - 5 seconds
   Num.Of.Mcast.Reset.Msg  - 5 messages

Appendix E: Unreliable Delivery

This defines the support for sending Unreliable datagrams in MDTP.  It
is optional for implementation.

The unreliable transfer mode allows two endpoints to send to each
other without acknowledging the notification:

 o link-address - receiving. This indicates can usually achieve
higher data throughput than the IP address of reliable transfer mode. To indicate
the affected link;
 o new-status - This indicates unreliable transfer mode the new status sender of the link;

13.6 Communication.Lost notification

When MDTP loses communication to an endpoint completely or detects
that the endpoint has performed a shut-down operation, it shall invoke
this notification on datagram with user data
simply sets the ULP. UNR flag to 1. The following sequence illustrates
unreliable data transfer.

Endpoint A                                      Endpoint Z
{App sends 2 messages}
[Header Flags=UNR|DAT|ACK
        Part=0,Of=1
        Seen=0,Send=4,Size=100]-------->
[Header Flags=UNR|DAT|ACK
        Part=0,Of=1
        Seen=0,Send=5,Size=100]-------->

                                             {App sends 1 message}
                                   <------- [Header Flags=UNR|DAT|ACK
                                             Part=0,Of=1
                                             Seen=5,Send=1,Size=450]
...
{App sends 2 more messages}
[Header Flags=UNR|DAT|ACK
        Part=0,Of=1
        Seen=1,Send=6,Size=100]------>

[Header Flags=UNR|DAT|ACK
        Part=0,Of=1
        Seen=451,Send=7,Size=100]------>

Note that no timers shall be passed with started by either end, and that even
though both ends are in Unreliable transfer mode, the notification:

 o status - This indicates what type ACK flag is
still set by the sender of event the datagram. This means that has occurred;
 o endpoint-id - The IP address and port number to identify the
   endpoint;
 o packets-enqueue - The number and location of un-sent datagrams Seen
field in the datagram header is still holding by MDTP;

Stewart & Xie                                                  [Page 53]

Internet Draft   Multi-network Datagram Transmission Protocol   Apr 1999


 o last-acked - valid to indicating the sequence
number of the last acked datagram received by the sender.  The upper layer
can use this information to help detecting missing or duplicated
datagrams. However, MDTP shall make no effort to detect or retransmit
missing data or to screen out duplicated datagrams.

E.1 Ordered Unreliable Delivery

In unreliable transfer, the sender should be allowed to request
ordered delivery by that peer endpoint;
 o last-sent - setting the RE1 flag to 1.

When Ordered Unreliable Delivery is indicated, the receiver shall
order the newly arrived datagram with any datagrams it has received
but yet passed to its upper layer.

If it receives a datagram which is older than the sequence number last sent datagram it has
passed to the upper layer, that peer endpoint;

14. Suggested timer and MTU values.

The following are suggested timer values for MDTP:

T1-init Timer    -  160 ms
T2-receive Timer -   20 ms
T3-send Timer    -  160 ms
T4-bundle Timer  -   40 ms
T5-Heart Beat    - 4000 ms

The following protocol parameters are recommended:

Min.Bundle              - 1000 octets
Max.Bundle              - 1432 octets
Max.Retransmit          - 10 attempts
Max.Init.Retransmit     - 8  attempts
Min.Mcast.Time.To.Reset - 5 seconds
Num.Of.Mcast.Reset.Msg  - 5 messages


15. Acknowledgments

The authors wish to thank Brian Wyld, Sankar A, Henry Houh, Gary
Lehecka, Ken Morneault, Lyndon Ong, and others for their very valuable 
comments.


16.  Author's Addresses

Randall R. Stewart                          Tel: +1-847-632-7438
Cellular Infrastructure Group               EMail: stewrtrs@cig.mot.com
Motorola, Inc.                              
1475 W. Shure Drive, #2C-6                  
Arlington Heights, IL 60004
USA

Qiaobing Xie                                Tel: +1-847-632-3028
Cellular Infrastructure Group               EMail: xieqb@cig.mot.com
Motorola, Inc.                              
1501 W. Shure Drive, #2309
Arlington Heights, IL 60004
USA









Stewart & Xie                                                  [Page 54]

Internet Draft   Multi-network Datagram Transmission Protocol   Apr 1999


17. References

[1] Postel, J. (ed.), "Internet Protocol - DARPA Internet Program
Protocol Specification", RFC 791, USC/Information Sciences Institute,
September 1981. 

[2] Postel, J., "User Datagram Protocol", RFC 768, USC/Information Sciences 
Institute, August 1980. 

[3] Postel, J. (ed.), "Transmission Control Protocol", RFC 793, USC/ 
Information Sciences Institute, September 1981. datagram shall be silently discarded.

      This Internet Draft expires in 6 months from April 1999.




































Stewart & Xie                                                  [Page 55]

----