Network Working Group                                     R. R. Stewart
INTERNET-DRAFT                                                   Q. Xie
                                                               Motorola
                                                                 T. Bova
                                                               S
	                                                     S. Hussain
                                                           T Krivoruchka
                                                                R. Revis
                                                               C. Sharp
	                                                          Cisco
                                                     H. J. Schwarzbauer
                                                                Siemens
                                                              T. Taylor
                                                        Nortel Networks
                                                              I. Rytina
                                                               Ericsson

expires in six months                                      April 19                                      June 2, 1999

           MULTI_NETWORK DATAGRAM TRANSMISSION PROTOCOL
                <draft-ietf-sigtran-mdtp-04.txt>
                <draft-ietf-sigtran-mdtp-05.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 a new protocol, namely the Multi-network
Datagram Transmission Protocol (MDTP), that is intended to provide
fault-tolerant reliable data transfer between communicating entities
over IP networks [1].

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

Stewart, et al                                                  [Page  1]
                        TABLE OF CONTENTS

1.  Introduction  Introduction.......................................................3
  1.1 Terminology......................................................3
  1.2 Design Requirements of MDTP
     1.2 Interfaces MDTP......................................4
  1.3 Interface to MDTP MDTP................................................5
2.  MDTP Datagram Format Format...............................................5
  2.1 MDTP Common Header Field Descriptions Descriptions............................6
  2.2 MDTP Control Parameter Part Definitions..........................7
  2.3 MDTP Data Field Part Definitions......................................11
3.  Transmission Initialization
     3.1  Endpoint Association Initialization
       3.1.1 Choice of Initialization...............................12
  3.1 Initiation Message and Tag Value Lock.................................12
  3.2 Data Field Format Tag Unlock and TSN Initialization...............................13
  3.3 Datagram Processing during Tag Lock ............................14
  3.4 An Example of Association Initialization .......................14
  3.5 Other Initiation Issues.........................................15
    3.5.1 Selection of Tag Value......................................15
    3.5.2 Initiation Datagrams
     3.3 from behind a NAT................................15
    3.5.3 Initialization Collision
     3.4 Collision....................................16
    3.5.4 Association Re-initialization Re-initialization...............................16
4.  Reliable  Transfer of Datagrams User Datagram............................................16
  4.1 Timer Management Rules Rules..........................................17
    4.1.1 Link Rotation T3-send Timer Adjustment with RTT...........................18
  4.2 Gap Acknowledgment for Missing Datagrams Multihoming Rotation............................................18
    4.2.1 Remote Multihoming Rotation.................................18
    4.2.2 Local Multihoming Rotation..................................19
  4.3 Stream Sequence Number..........................................19
  4.4 Ordered and Un-ordered Delivery.................................19
  4.5 Report Missing Datagrams........................................20
  4.6 Range Check on TSN .............................................21
  4.7 Advisory Ack Request............................................21
5   Congestion Control
       4.3.1 Sending Controls...............................................22
  5.1 Send with Window Control
       4.3.2 Control........................................22
    5.1.1 Window Length Adjustment
       4.3.3 Flow Control using In-Queue Information
       4.3.4 T3-send Adjustment....................................23
  5.2 Send Timer Adjustment with RTT
     4.4 Sequence Number Reset
     4.5 Datagram Re-transmission
       4.5.1 Re-transmission on Back-off at Re-transmission..........................24
6.  Network Management................................................25
  6.1 Failure Detection in Redundant networks
     4.6 RTT Measurement
       4.6.1 RTT Datagram Header Format
       4.6.2 Measure Networks.........................25
  6.2 RTT
     4.7 Link Measurement.................................................26
  6.3 Network Heart Beat
     4.8 Advisory Acknowledgment
     4.9 .............................................26
7.  Termination of an Association
     4.10 Draining Association........................................27
  7.1 Graceful Shutdown of an Association
5. Interface with upper level protocols
6. Suggested MDTP Protocol Parameter Values
7. Acknowledgments Association.............................28
8. 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 Operations.................................................29
  8.1 Stream Datagrams
       A.3.3 Extended Initiation...............................................29
  8.2 Stream Ack
     A.4 Termination..............................................29
  8.3 Other Issues with Stream Transfer
Appendix B: Bundled Message Transfer
     B.1 Format of Bundled Datagram
     B.2 Bundled Datagram Transfer
Appendix C: Fragmented Message Transfer
Appendix D: Multicast Datagram Transfer
     D.1 Multicast Datagram Header Format
     D.2 Transmission of Multicast Datagrams
Appendix E: Unreliable Delivery
     E.1 Ordered Unreliable Delivery Operations.............................30
9.  Interface with Upper Layer........................................30
10. Suggested MDTP Timer and Protocol Parameter Values................34
11. Acknowledgments...................................................34
12. Authors' Addresses................................................34
13. References........................................................35

Stewart, et al                                                  [Page  2]

1.  Introduction

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

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

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

For example, the transportation of signaling protocols such as PRI ISDN
PRI may not require redundant links, networks, 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.
essential.

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

1.1 Terminology

The following terms are defined and used in this document:

- Redundant networks:

  An endpoint may be able to a highly effective,
robust protocol for fault tolerant data communications. transmit or receive on more than one IP
  address/UDP port. RFC 1122 refers to this as multihoming. This document describes
  constitutes a redundant local network (for MDTP) relative to the functional interface
  endpoint. MDTP makes no attempt to assure routing diversity within
  the internet connecting two endpoints. Each endpoint attempts to
  send to its peer endpoint using all the IP addresses and UDP ports
  its peer has open (within the details
necessary for implementing MDTP. The main body constraints of this document
contains the minimal set any application
  specified restrictions). The choice of functionalities which local socket to send
  upon is an implementation detail (it is possible only one socket is
  available and bound to all of the local networks to which the machine is
  connected). The O/S also will play a role in the multihoming/redundancy.
  MDTP attempts a best effort at spreading the traffic across a

Stewart, et al                                                  [Page  3]
  destination's available interfaces. It is assumed by MDTP that must be
implemented. In the Appendices,
  network (if fault tolerance is desired) is engineered for diversity
  and MDTP's best effort will play only a set small role in that diversity.

- Endpoint:

  Representation of additional the logical point where MDTP functions,
such as reliable stream, multicast, message bundling, message
fragmentation, are defined. Those additional functionalities are
optional datagrams can be sent
  to implementation.

1.1 Design Requirements of or received from. Moreover, an MDTP

The following are some of the design requirements endpoint shall be defined as
  a set of MDTP, IP address/port combinations in order to
make MDTP capable of supporting real-time call control environments
which potentially may employ support redundant networks:

A) High communication fan-out:
  networks. For example, an endpoint may need to be in
   simultaneous communication on a multi-homed host connected
  with hundreds N IP networks can be represented as:

     [IP addr1/port1,
       ...
      IP addrN/portN]

  where the port numbers or thousands of endpoints
   performing various call processing functions. These endpoints IP addresses may not be codec unique, but their
  combinations shall be guaranteed to be unique by the underneath IP
  networks.

- Association:

  Representation of an ongoing communication channel between two MDTP
  endpoints.

- Stream:

  Defines a sub-channel within an association. Datagrams sent through
  a stream shall be reliably transmitted and delivered independent to
  datagrams from other streams.

  Each stream shall be identified by a stream number that is unique
  within the association. Stream 0xffff is reserved and shall not be
  used.

1.2 Design Requirements of MDTP

The following are some of the design requirements of MDTP to
make MDTP capable of supporting real-time call control environments
that may employ redundant networks:

A) 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) 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.

Stewart, et al                                                  [Page  4]

C) Support redundant links: multiple network paths: an endpoint communicating with a peer
   should be able to take advantage of the redundant networks multiple network paths and
   multihoming in a transparent way. Therefore, the protocol must
   be able to take advantage of local multi-homed hosts and remote
   multi-homed hosts to provide resilient data delivery. This means
   that the application or upper layer protocols need not to be involved
   in the network fault management. Instead, when network failure occurs
   MDTP should be able to automatically re-route the transmit out-bound datagram datagrams to the an
   alternate destination network interface (if one exists) without
   intervention from the application.

D) Orderly delivery: Reliable transport: datagrams may arrive out of order, might be lost or discarded while
   traveling in the IP network towards the destination. The protocol
   must handle the re-transmission of lost messages in an autonomous
   way without any intervention from the upper layer. Also, sometimes
   datagrams may arrive in duplicate copies. This is especially true if redundant networks
   are used. copies, in such cases MDTP should must
   be strong enough able to properly handle detect and remove the duplicates automatically.

E) Support both
   situations with little intervention from ordered and un-ordered delivery: MDTP must support
   both ordered and un-ordered delivery. In the case of ordered
   delivery, the receiver shall detect out-of-order datagrams and
   re-order them before dispatching them to the upper layer protocols
   or applications. layer. In the
   un-ordered case, received datagrams shall be dispatched without any
   effort of re-ordering.

F) Support stream sequencing: on the demand of the upper layer
   protocols or applications, MDTP should be able to support sequenced
   delivery with regard to each individual stream, i.e., the delay caused
   by the loss and retransmission of a datagram should be isolated to
   only the stream to which the datagram belongs. This is particularly
   important in some call control applications, where a loss of a
   message should only affect the call whom the message belongs to.

1.2 Interfaces

1.3 Interface to MDTP

The application programs or upper layer protocols interface with MDTP
through a set of primitives (see section 5. for details). 9).

Towards the IP networks, it is assumed that a UDP-like data transport
protocol will provide the interface between MDTP and UDP is used for the operating
system.
transport layer. No special interfaces or changes are assumed within
UDP or at the
operating system, all UDP/MDTP interface.  MDTP maintains its own queuing and
endpoint association information are
maintained inside association.  When MDTP layer. runs on a router or on a
gateway-enabled host, it will place no special constraints on the
lower layer protocol implementations other than those described in the
Router Requirements and Host Requirements RFCs.

2.  MDTP Datagram Format

A MDTP inserts the following protocol header at the beginning datagram consists of every
user datagram. The integer fields shall be transmitted in network byte
order. a common header and possibly a control
parameter part, a data part, or both.

Stewart, et al                                                  [Page  5]
                      MDTP Header Datagram 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|               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                Acknowledgment Number (Seen) Vers  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |C/D| Msg Type  |                   Sequence Number (Send)                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   Reserved    |         Data Size             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   \                                                               \
   /                    Control Parameter Part       |      Of       |                     /
   \                                                               \
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   \                                                               \
   /                             data                          Data Part                            /
   \                                                               \
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Note: integers in the header of MDTP datagrams MUST be transmitted in
network byte-order.

Note: when both the control part and data part are present in an MDTP
datagram, the control part MUST be processed first.

2.1 MDTP Common Header Field Descriptions

    MDTP Protocol Identifier: 32 28 bits

      This shall be a fixed long value of 0xf7873072. 0xf787307. The receiver shall
      always verify this Protocol Identifier before it proceeds any
      further in interpreting the header fields.

    Version: 8 4 bits

      This field represents the version number of the MDTP protocol
      (value TBD).

    Flags: 16 bits

      NOM - protocol,
      and shall be set to 1 (reserved for fragmentation, see
      Appendix C)

      NOB 0x3.

    C/D Bits: 2 bits

      This field indicates whether the Message Type and Data Size fields
      are filled in the present datagram:

         00 - reserved, shall not be used. The receiver shall silently
              discard any datagram with C/D bits set to 1 (reserved for bundling, see Appendix B)

      WIN 00.
         01 - Window Up. Data Size only
         10 - Message Type only
         11 - Message Type and Data Size

    Message Type: 6 bits

      This bit is set by the sender of this datagram
      to shall indicate that the sender needs type of control message. Its value is valid
      only when the receiver C/D bits are set to acknowledge on
      previously received datagrams before it can send more datagrams.

      ISB - either "10" or "11". Otherwise it

Stewart, et al                                                  [Page  6]
      shall be set to 0 (reserved for bundling, see Appendix B)

      FIR - First Datagram. This flag 0x0 and ignored by the receiver.

      Message Type determines whether the control part is set to indicate that this present in
      the current datagram.

      The value of Message Type is a defined as the follows:

      0x0  - reserved and shall not be used

      0x1  - Initiation datagram.

      RTM
      0x2  - normally set Initiation Ack
      0x3  - Extended Data Ack
      0x4  - Advisory Ack Request
      0x5  - Window-up
      0x6  - Window-up Ack
      0x7  - RTT-request
      0x8  - RTT-ack
      0x9  - Abort
      0xa  - Graceful Shutdown
      0xb  - Graceful Shutdown Ack
      0xc  - Stream Initiation
      0xd  - Stream Initiation Ack
      0xe  - Stream Termination
      0xf  - Stream Termination Ack

      0x10 to 0 (used for Link Heart Beat 0x3f - reserved and RTT
      measurement, see sections 4.6 shall not be used

    Reserved: 8 bits

      These bits are reserved for future use. The sender shall always
      set these bits to '0', and 4.7)

      DAT - the receiver shall ignore there
      values.

    Data Present. Size: 16 bits

      This bit is set to indicate that, following
      this header, application value represents, in number of octets, the size of the user
      data is present in this the Data Part of the current datagram.

      ACK - Acknowledge. This bit Its value
      is only valid when C/D bits are set to indicate that the sender is
      acknowledging the reception of the specified Acknowledgment Number.

      MUL - either "01" or "11".
      Otherwise it shall be set to 0 (reserved for multicast, see Appendix D)

      SHU - Shutdown. 0x0 and ignored by the receiver.

2.2 MDTP Control Parameter Part Definitions

This bit section defines whether a control parameter part is set when the sender initiates present for
each message type, and its
      closing procedure format if a control parameter part is
present.

2.2.1 Initiation (0x1) and indicates to Initiation Ack (0x2):

    The parameter field of the receiver that Initiation and Initiation Ack messages
    shall carry two initiation Tags, the sender
      is no longer a valid destination. If maximum window length and the UNR bit is set in
      conjunction with
    sender's local network information. Note that the SHU bit, an incomplete shutdown is
      specified. After an incomplete shutdown, endpoint MAY
    be multi-homed.

Stewart, et al                                                  [Page  7]
    The following defines the receiver parameter format for carrying N IPv4
    Network addresses (other network address formats can still
      re-establish the communication with the sender be carried by re-initiating
      with the sender (see 4.7).

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

      RE1 - normally set to size and type fields accordingly):

     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                   1                   2                   3
     0 (reserved for reliable stream, see
      Appendix A)

      GAR - shall be set to 1 (reserved for unreliable mode, see
      Appendix E)

      UNR - shall be set to 2 3 4 5 6 7 8 9 0 (reserved for unreliable mode see
      Appendix E)

    In Queue: 1 2 3 4 5 6 7 8 bits

      This field contains the number 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                       Tag Value 1 (Seen)                      |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                       Tag Value 2 (Send)                      |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                       Max Window Length                       |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                    Number of messages the sender has on its
      incoming queue, waiting Networks = N                     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |       Size of address=8       |    Type of Address=2          |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                   IP Address of Network 1                     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |         Port # 1              |      Padding = 0              |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    /                                                               /
    \                              ...                              \
    /                                                               /
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |       Size of address=8       |    Type of Address=2          |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                   IP Address of Network N                     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |         Port # N              |      Padding = 0              |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    If there is any implementation-specific data needed to be read by the application. This
      gives
    exchanged at the receiver an indication setup of the flow control conditions
      within association, it should be appended
    to the sender.

    Acknowledgment Number (or Seen): 32 bits

      If the flag ACK is set this value is the last sequence number
      that the sender end of this datagram received from the
      receiver above data structure. The format of this datagram.

    Sequence Number (or Send): 32 bits

      If DAT flag is set, this value represents the sequence number of
    implementation-specific data should follow "Size/Type/Data Field"
    format as defined above. In case an endpoint does not support the current
    implementation-specific data unit following this header. Otherwise, this
      value will be received, it shall ignore the
    additional fields.

2.2.2 Extended Data Ack (0x3):

    The parameter field contains 0 or more gap reports and the
    highest transmission sequence number (TSN) received.

Stewart, et al                                                  [Page  8]
     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 the next data unit Gaps = N                     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                         Gap #1 Start TSN                      |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                          Gap #1 End TSN                       |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    /                                                               /
    \                              ...                              \
    /                                                               /
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                         Gap #N Start TSN                      |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                          Gap #N End TSN                       |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                        Last TSN Seen                          |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

2.2.3 Advisory Ack Request (0x4):

    No parameter field.

2.2.4 Window-up (0x5):

    No parameter field.

2.2.5 Window-up Ack (0x6):

    Same as that
      will be sent.

    Data Size: 16 bits

      This value represents, in number of octets, the size of the data Extended Data Ack.

2.2.6 RTT-request (0x7) and RTT-ack (0x8):

    The parameter field that follows this header in the current datagram.

    Part: 8 bits shall have contain the time value '0' (reserved that is used for fragmentation, see Appendix C)

    Of:
    RTT calculation (see section 6.2), and optionally an
    acknowledgment Seen value.

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 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 may choose to pad some
'0's at 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                         Time Value 1                          |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                         Time Value 2                          |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                       0x0 or TSN Seen                         |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

2.2.7 Abort (0x9):

    The Abort message shall carry the end initiation Tag of the data field so
    destination endpoint as to align with certain memory
boundaries. However, the padded '0' octets, if there are any, a measure of security.

Stewart, et al                                                  [Page  9]
     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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                        Init-Tag                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

2.2.8 Graceful Shutdown (0xa):

    The destination endpoint initiation Tag shall
not be counted in the Data Size.

The maximal Data Size for carried as a single MDTP datagram is
    measure of security.

     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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                            Init-Tag                           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                            TSN Seen                           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

2.2.9 Graceful Shutdown Ack (0xb):

    Same as that of Abort.

2.2.10 Stream Initiation (0xc):

    The parameter field shall contain the MTU size initiation Tag of the underlying transport protocol (e.g., UDP) minus
    destination endpoint (see section 3.1), the MDTP header
size.

3.  Transmission Initialization

3.1 Endpoint Association Initialization

Before Stream Identifier,
    and the first Initial Sequence Number of this stream. Also, there shall
    be a "Size of Stream Info" and "Stream Information" fields that
    may contain an opaque user data transmission can take place from one endpoint
("A") structure specific to another endpoint ("Z"), the two endpoints will need to
complete an initialization process in order to set up an association
between them. stream
    being opened. The initialization procedure "Stream Information" field should be made transparent to the upper
layer protocol, i.e., it should take place automatically whenever the
upper layer tries to send a datagram padded with
    '0's to an endpoint which has never
been sent 32 bit word boundary before transmission.

     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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                           Init-Tag                            |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |         Stream Identifier     |       Reserved (set to before. 0)     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                 Size of Stream Info = N                       |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    /                                                               /
    \                Stream Information (N octets)                  \
    /                                                               /
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

2.2.11 Stream Initiation Ack (0xd):

    The user datagram parameter field shall be withheld by MDTP from
transmission till the completion of the initialization.

A tag-and-lock mechanism is employed during contain the initialization in
order Stream Identifier.

     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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |         Stream Identifier   |       Reserved (set to guard against erroneous or stale datagrams (this is
especially true if redundant networks are deployed). 0)       |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

2.2.12 Stream Termination (0xe):

    The initialization process consists of the following steps (assuming parameter field shall contain the upper layer at "A" tries to send data to "Z" for initiation Tag value (see
    section 3.1) and the first time):

A) "A" first sends an Initiation (FIR) to "Z", with Seen field set
   to Stream Identification

     0 and Send field set                   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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                        Init-Tag                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |         Stream Identifier   |       Reserved (set to Tag_A, and then enters the Tag-lock mode
   (see below).

B) "Z" responds immediately with an Initiation 0)       |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

2.2.13 Stream Termination Ack (FIR|ACK), with (0xf):

    Same has that of Stream Initiation Ack.

2.3 MDTP Data Part Definitions

The following format shall be used for MDTP datagram Data Part:

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           TSN Seen set to Tag_A and                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           TSN Send set                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      Stream Identifier N      |    Sequence Number n          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   \                                                               \
   /                 User Data (seq n of Stream N)                 /
   \                                                               \
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    TSN Seen: 32 bits

      This is a piggy-backed acknowledgment, indicating the reception
      of datagrams up to Tag_Z, and then enters this TSN.

    TSN Send: 32 bits

      This value represents the TSN of the
   Tag-lock mode, too (see below).

Note that no user data should be carried in the Initiation or
Initiation Ack datagram.

At this point "Z" is ready
      datagram.

    Stream Number: 16 bits

      Identify the stream to send which the following user data to "A". And upon date belongs.

    Sequence Number: 16 bits

      This value presents the
receipt sequence number of the above Initiation Ack from "Z", "A" can also start
sending following user
      data to "Z".

However, within the first datagram with stream.

      Sequence number 0x0 indicates that the following user data transmitted by "A" to "Z" shall have
      be treated as un-ordered, and shall be dispatched to the Seen value set to Tag_Z, which upper
      layer by the receiver without any attempt of re-ordering.

    User Data: variable length

      This is obtained from the
Initiation Ack. And similarly, payload user data. The size of the first datagram with user data
transmitted by "Z" to "A" shall have
      be specified in the Seen value set to Tag_A,
which comes from Data Size field. The implementation may
      optionally have some '0' padded at the Initiation datagram.

In end of User Data field.

3. Endpoint Association Initialization

Before the Tag-lock mode, each side will silently discard any datagrams
with user first data transmission can take place from one endpoint
("A") to another endpoint ("Z"), the other side until it receives two endpoints must complete an
initialization process in order to set up an association between them.

The upper layer may explicitly request MDTP to initialize an
association to an endpoint, or implicitly open the association by
sending the first datagram with user data and with a Seen value to that matches its own
Tag. endpoint on stream 0.

Once that datagram the association is received, that endpoint will leave established, the
Tag-lock mode global stream, i.e., stream
0, is automatically open and immediately send back a ready for datagram transmission. Other
streams must be explicitly opened before data acknowledgment, and
start using transmission can occur.

A tag-and-lock mechanism must be employed during the sequence numbers initialization
in order to filter out missing and duplicate guard against security attacks as well as erroneous
datagrams.

If another Initiation from "A" is received by "Z" after it sent out
the Initiation Ack, "Z" will acknowledge this Initiation by re-sending
the

3.1 Initiation Ack only when the Send field Message and Tag Lock

The initialization process consists of this new Initiation has the same tag as that of the original Initiation.  Otherwise, "Z" will following steps (assuming
that MDTP endpoint "A" tries to set up an association with MDTP
endpoint "Z"):

A) "A" shall first send an Initiation of its own message to "Z", with Send Tag Seen
   field set to Tag_Z back 0x0 and Tag Send field set to "A" Tag_A, where Tag_A shall
   be a random number in the range of 0x80000000 to elicit 0xffffffff (see
   3.1.4 for Tag value selection), and enter the Tag-lock mode.

B) "Z" shall respond immediately with an Initiation Ack from "A".

In the following example, "A" initiates the association first and then
sends a datagram message, with user data
   Seen set to "Z":

   Endpoint A                                          Endpoint Z

   {first app message Tag_A and Send set to Tag_Z (same range as Tag_A), and
   enter the Tag-lock-new mode.

   At this point, "Z" is ready to send user datagrams to Z}
   [Header Flags=FIR
             & other options
           Seen=0,Send=Tag_A] ----------------------->
   (Start T1-init timer)
   (Enter Tag_A-lock mode)
                                              [Header Flags=FIR|ACK
                                                        & other options
                                   /---------- Seen=Tag_A,Send=Tag_Z]
                                  /           (Enter Tag_Z-lock mode)
   (Cancel T1-init timer)<-------/

   [Header Flags=ACK|DAT
             & other options
           Seen=Tag_Z,Send=1]
           [data field]   -----------\
   (Start T3-send timer)              \
                                       \----> (Leave Tag_Z-lock mode)

If T1-init timer expires at "A" after in stream
   0. And upon the Initiation sent, reception of the same above Initiation datagram with the same Tag_A value will Ack from "Z", "A"
   also becomes ready to send user datagrams to "Z" in stream 0.

   Note: user data in other streams can not be retransmitted
and sent until the timer restarted. This will be repeated Max.Init.Retransmit
times before "A" considers
   respective streams are opened.

C) "Z" unreachable shall leave Tag-lock-new mode and optionally reports enter Tag-lock mode only if a
   user datagram has been sent out from "Z" to "A".

   Note: to guard against "man in the
failure.

3.1.1 Choice of Tag Value

Tag values middle" attacks, a limit should
   be selected from imposed on the range of 0x80000000 to
0xffffffff.

3.2 Data Field Format number of Initiation Datagrams

If redundant networks exist between two endpoints, associations in the data field Tag-lock-new mode
   at any given endpoint; whenever that limit is reached, any further
   association Initiations received by the endpoint shall be silently
   discarded. Also, a timer shall be used on each association that is
   in the Tag-lock-new mode; at the expiration of that timer, that
   association shall be shutdown by the endpoint.

Note: no user data shall be carried in both the Initiation and
Initiation Ack datagrams will carry the redundant
network information.

The following shows the 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 address=8       |    Type of Address=AF_INET (2)|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |             IP Address of Network N                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         Port # N              |      Padding = 0              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Additional implementation-specific data is allowed after messages, i.e., the redundant
network information. No user data, however, is allowed to C/D bits must be
transported set to 10.

Note: both side must exchange their local network information and
their maximal window length in the Initiation or and Initiation Ack datagrams.

3.3
messages.

3.2 Tag Unlock and TSN Initialization Collision

If two endpoints attempt

The first user datagram transmitted by "A" to initialize an association with each other
at about "Z" shall have the same instance, a collision will occur, i.e., each side
will receive an Initiation datagram from TSN
Seen value set to Tag_Z in the other side after it Data Part (see 2.3).

Similarly, the first user datagram transmitted its own. In such a case, both sides by "Z" to "A" shall acknowledge
have the
Initiation datagram TSN Seen value set to Tag_A.

The reception of this first datagram with user data and with the other side
correct Tag value in the normal procedure as
described above.

3.4 Association Re-initialization

An endpoint TSN Seen field from its peer shall be allowed to re-initialize an established
association with another endpoint.

In such a case, unlock the endpoint that initiates
Tag and cause the re-initialization
(i.e, endpoint to leave the initiator) Tag-lock or Tag-lock-new mode.

The receiver shall use a tag different from immediately send back an Extended Data Ack to
acknowledge the one used reception of this first user datagram.

The TSN Send value carried in
the previous initialization. And the initiator this first datagram with user data shall follow
be used to establish the normal
initialization procedure as stated in section 3.1.

Once left initial TSN of this peer, i.e., the Tag-lock mode sender of
this datagram.

To strengthen the current association initialization,
an endpoint security, this initial TSN shall treat any new incoming Initiation be randomly
selected from its peer as a
re-initialization event. Upon the arrival of range between 0x1 and 0x7fffffff by the new Initiation sender, by
means such as those suggested in RFC 1750 [9].

Note: if there exists any un-acked datagram(s) when an endpoint is to
send its first user datagram from the to its peer, the receiving endpoint shall also follow the
procedure stated in section 3.1 MUST send a
stand-alone Extended Data Ack to respond.

4.  Reliable Transfer of Datagrams

Reliable transfer is indicated if acknowledge the datagram being transferred un-acked datagram(s)
it has
GAR bit set to 1 and received from that peer before it sends out its first user
datagram. This is because the UNR bit set TSN Seen field in the first out-bound

user datagram can not be used as a TSN ack, instead it is used to 0. The receiver of
carried the peer's Tag.

3.3 Datagram Processing during Tag Lock

In Tag-lock or Tag-lock-new mode, an endpoint shall silently discard
any user datagrams from the peer endpoint that does not carried the
correct Tag value.

However, if there is a
reliable control part present in a discarded user
datagram (i.e., C/D = 0x11), the endpoint shall always acknowledgment process the sender.

Normally, delayed acknowledgment is used, and
control part even when the acknowledgment can
either be data part is being discarded.

If another Initiation from "A" is received by "Z" after "Z" sent separately or piggy-backed on a datagram traveling
in out
its Initiation Ack, "Z" shall respond to this second Initiation by
re-sending the Initiation Ack if the Tag Send field of this second
Initiation has the same value as that of the original Initiation.
Otherwise, "Z" shall respond by sending an Initiation of its own, with
Tag Send field set to Tag_Z, so as to elicit an Initiation Ack from
"A".

3.4 An Example of Association Initialization

In the opposite direction.

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

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

{app sets association with Z}
Initiation(C/D = 10)
   [Tag Seen=0,Tag Send=Tag_A
    & net addr info] --------\
(Start T2-receive T1-init timer)         \
(Enter Tag_A-lock mode)	       \---->Initiation Ack(C/D = 10)
                                       [Tag Seen=Tag_A,Tag Send=Tag_Z
                                /----   & net addr info]
                               /     (Enter Tag_Z-lock-new mode)
(Cancel T1-init timer)<-------/

{app sends 1st user data; strm 0}
U-Data(C/D = 01)
   [Seen=Tag_Z,Send=init TSN-A
    Strm=0,Seq=1,
    & user data]      -------\
(Start T3-send timer)

[Header 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         \
                               \---->(Leave Tag_Z-lock-new mode)
                               ------Ext Data Ack(C/D = 10)
                              /        [Gap=0,TSN Seen=init TSN-A]
(Cancel T3-send timer)
                                              ...
                                              {Timer T2 expires}
                                 /----------- [Header Flags=ACK
                                /              Part=0,Of=0
                               /               Seen=3,Send=1]
                              /
(cancel T3-send timer) <------
...
...
{App <-----/
..

                                     ..
                                     {app sends 1 message}
[Header Flags=DAT|ACK|GAR
        Part=0,Of=1
        Seen=1,Send=4,Size=100]-----------> (Start T2-receive timer) 2 datagrams;strm 0}
                               /---- U-data(C/D = 01)
                              /        [Seen=Tag_A,Send=init TSN-Z
(Leave Tag_A-lock mode) <----/          Strm=0,Seq=1,
(Start T3-send timer)
                                              ...
                                              {App sends 1 message}
                                              (cancel T2-receive timer)
                                 /----------- [Header Flags=DAT|ACK|GAR
                                /              Part=0,Of=1                & user data 1]
                               /---- U-data(C/D = 01)
                              /               Seen=4,Send=1,Size=45]        [Seen=init TSN-A,
                             /               (Start T3-send timer)
(cancel T3-send timer) <------
(Start T2-receive timer)
..
{Timer T2 Expires}
[Header Flags=ACK
        Part=0,Of=0
        Seen=1,Send=5]------------------> (cancel T3-send timer)

Note that if          Send=init TSN-Z +1,
                        <---/           Strm=0,Seq=1,
                                        & user data 2]

If T1-init timer expires at "A" after the datagrams previously received from Initiation is sent, 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
Initiation message with the same Tag_A value of the Send field in the 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 with user data (i.e., with DAT flag set) is
   received, retransmitted and
the endpoint shall start a T2-receive timer if no other timer is running, restarted. This shall be repeated Max.Init.Retransmit times
before "A" considers "Z" unreachable and upon optionally reports the expiration
failure.

3.5 Other Initiation Issues

3.5.1 Selection of Tag Value

Tag values should be selected from the T2-receive timer, range of 0x80000000 to
0xffffffff. It is very important that the endpoint shall ack Tag value be randomized to
guard against "man in the sender all middle" and "sequence number" attacks. It is
suggested that RFC 1750 [9] be used for the un-acked datagrams
   it has received.

B) Tag randomization.

3.5.2 Initiation from behind a NAT

When a reliable datagram with user data NAT is sent out, present between two endpoints, the sending endpoint shall start a T3-send timer. If the T3-send timer that is
   already running,
behind the endpoint shall first stop the old T3 timer
   and then start NAT, i.e., one that does not have a new one. If the T2-receive timer is running, the
   endpoint publicly available
network address, shall first stop the T2 timer, piggyback an Ack unto take one of the
   out-bound datagram, and then start a T3-send timer. Upon following options:

A) Indicate that it has only one network by setting the
   expiration 'Number of
   networks' field in the T3-send timer, Initiation message to 0. This will make the
   endpoint shall follow that receives this Initiation message to consider the rules
   described in 4.5 sender
   as only having that one address. This method can be used for possible re-transmission of the un-acked
   datagrams. Whenever a dynamic
   NAT, but any multihoming configuration at the T3-send timer endpoint that is started behind
   the RTT estimate
   last calculated for that network should NAT will not be added visible to its peer, and thus not be taken
   advantage of.

B) Indicate all of its networks in the base
   T3-send timer value (if a RTT value is measured, see section 4.6).

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

The following example shows actual IP addresses and ports that the use of various timers.

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

[Header Flags=DAT|ACK|GAR
        Part=0,Of=1                           {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|GAR
        Part=0,Of=1
        Seen=2,Send=7,Size=100]---------> (Cancel T3-send timer)
(Restart T3-send timer)                       (Start T2-receive timer)

                                              ..
                                              {Timer T2 expires}
(Cancel T3-send timer)        <-------------- [Header Flags=ACK
                                               Part=0,Of=0
                                               Seen=7,Send=3]

4.1.1 Link Rotation

When multiple networks exist between two communicating endpoints,
every time NAT will substitute for the application transmits a datagram,
   endpoint. This method requires that the MDTP
implementation MUST keep track endpoint behind the NAT must
   have pre-knowledge of which network all the transmission was
sent on (if more than one network exists) in the MDTP protocol variable
'last.sent.intf'. If the user does not specifically override rotation,
each send should be rotated in a round robin fashion amongst all
available networks IP addresses and ports that the protocol variable 'last.sent.intf' should
be updated to indicate which interface was used last.

The MDTP implementation MUST allow a user NAT will
   assign.

3.5.3 Initialization Collision

If two endpoints attempt to override this rotation
defeating MDTP's rotation upon initialize an association with each send. The implementation must also
provide other
at about the same instance, a interface to add and remove collision will occur. As a link result, each
side will receive an Initiation datagram from rotation eligibility.

4.2 Gap Acknowledgment for Missing Datagrams

If reliable datagrams become missing during a series of transmissions,
a special type of acknowledgment known as the Gap other side after it
transmitted its own. In such a case, both sides shall send an
Initiation Ack will be sent
back datagram to inform the sender other side using the procedure
described above.

3.5.4 Association Re-initialization

An endpoint shall be allowed to re-transmit re-initialize an established
association with the missing datagrams.

The following example shows other endpoint.

Once an endpoint has left the use Tag-lock or Tag-lock-new mode of Gap Ack.

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

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

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

In this example, when "Z" receives the third datagram from "A"
previous association initialization process, it
realizes that shall treat any new
Initiation message from its peer as a gap exists in the received data.  At the expiration of
T2-receive timer, "Z" sends re-initialization event.

During a Gap Ack, in place of a normal Ack, to
"A" to indicate the missing datagram.

In the Gap Ack, the Part and Of fields are re-initialization, both set to '1', as opposed
to '0' endpoint shall follow the same
procedure as defined in section 3.1. And a normal Ack. The data field of the Gap Ack is a four (4)
octet long integer containing new Init-Tag must be used
by the sequence number of endpoint that receives the next datagram
after Initiation message if it has already
left the Gap (which is 10 in this example). previous Tag-lock or Tag-lock-new mode.

4.  Transfer User Datagram

The Seen field in
the Gap Ack will contain the sequence number receiver of the a user datagram of shall always acknowledge the
gap.  Using these two values, "A" should be able reception
to calculate the sender of the missing datagram numbers (which is 9 in this
example) and thus determine which datagrams will need to datagram. Normally, delayed acknowledgment shall
be
retransmitted.

Note that Gap Acks cannot used. The delay shall be piggy-backed with user data; controlled by a T2-receive timer.

At the expiration of T2-receive timer, if there is out-bound user data to be sent when a gap is detected, data,
the Gap Ack must ack should be sent
out first before piggy-backed on the datagram carrying user data can be sent.

4.3 Flow and Congestion Controls

Several different mechanisms part of the out-bound user
datagram, occupying the TSN Seen field (see section 2.3). Otherwise, a
stand-alone Extended Data Ack shall be used jointly to achieve
flow and congestion controls in MDTP.

4.3.1 Sending with Window Control

The sending endpoint carry the
acknowledgment.

When Extended Data Ack is used, the sender shall use a transmission window fill the Last TSN
Seen field to control indicate the highest TSN Send number of outstanding datagrams, i.e., datagrams that have been sent,
but yet to it has received
from the peer. Any detected gaps must also be acknowledged. reported
(see section 4.5).

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 shall still accept send requests from its upper
layer, but shall transmit no more datagrams until an Ack is received.

Moreover, when the window length is reached, the next send request
from the upper layer will trigger the sending endpoint to transmit a
special Window Up message. Upon receiving this Window Up (WIN|ACK) the
receiver must respond with a Window Up Response (WNR|ACK), as
illustrated by the following example (assuming current window length
is 3): illustrates both stand-alone and piggy-backed
acknowledgments:

Endpoint A                                      Endpoint Z
{App sends 3 messages}
[Header Flags=DAT|GAR|ACK
        Part=0,Of=1
        Seen=0,Send=11,Size=100]-----------> messages in strm 0}
U-Data(C/D = 01)
   [Seen=5,Send=7,Strm=0,Seq=3]--------> (Start T2-recv T2-receive timer)
(Start T3-send timer)

[Header Flags=DAT|GAR|ACK
        Part=0,Of=1
        Seen=0,Send=12,Size=100]----------->
(Restart

U-Data(C/D = 01)
   [Seen=5,Send=8,Strm=0,Seq=4]-------->

U-Data(C/D = 01)
   [Seen=5,Send=9,Strm=0,Seq=5]-------->
                                         ...
                                         {Timer T2 expires}
                              /--------- Extended Data Ack(C/D=10)
                             /             [Gap=0,Seen=9]
(cancel T3-send timer)

[Header Flags=DAT|GAR|ACK
        Part=0,Of=1
        Seen=0,Send=13,Size=100]----------->
(Restart <----/
...
...
{App sends 1 message; strm 0}
U-Data(C/D = 01)
   [Seen=5,Send=10,Strm=0,Seq=6]-------> (Start T2-receive timer)
(Start T3-send timer)
                                         ...
                                         {App sends a new message}
(queue new message and send Win Up)
[Header Flags=WIN|ACK
        Seen=0,Send=14]--------------------> 1 message; strm 1}
                                         (cancel T2-recv T2-receive timer)
                                      /----- [Header Flags=WNR|ACK
                                 /------ U-Data (C/D=01)
                                /        Part=0,Of=0          [Seen=10,Send=6,Strm=1,Seq=2]
                               /         Seen=14,Send=0]
[Header Flags=DAT|GAR|ACK <--------/
        Part=0,Of=1
        Seen=0,Send=15,Size=100]----------->         (Start T2-recv T3-send timer)
(Restart
(cancel T3-send timer)

In the above example, after the transmission of the first three
datagrams, "A" reached its window length. <------/
(Start T2-receive timer)
..
{Timer T2 Expires}
Extended Data Ack(C/D=10)
   [Gap=0,Seen=6]----------------------> (cancel T3-send timer)

4.1 Timer Management Rules

The next message from the
user triggered a Window Up that was sent following rules shall be used to "Z". The Window Up manage the timers during
normal datagram transfer, unless otherwise stated for some special
cases:

A) When a user datagram is received, the endpoint shall
contain start a
   T2-receive timer if no user data. In response, "Z" cancelled T2-receive timer T2 and
immediately sent a Window Up Response. The arrival is currently running. Upon
   the expiration of this Window Up
Response effectively resolved all the outstanding datagrams at "A",
thus allowed "A" to send out T2-receive timer, the next datagram.

4.3.2 Window Length Adjustment

The window length endpoint shall be initially set
   acknowledge to 2, and shall then be
dynamically adjusted based on the datagram loss and acknowledgment
conditions of sender all the underlying network.

When 4 consecutive outstanding un-acked user datagrams are acknowledged at once by
the receiver, the sender's window length will be raised by 1 until it
reaches the protocol parameter 'Max.Outstanding.dg' (which should be has
   received.

B) When a user configurable parameter).

If the current window length datagram is less than 4, every time when sent out, the
number of consecutively outstanding datagrams acknowledged in sending endpoint shall start
   a single
Ack T3-send timer if no T3-send timer is equal to or greater than currently running.

   If the current window length, T2-receive timer is running, the
sender's window length endpoint shall be raised by 1, until it reaches
'Max.Outstanding.dg'.

In first stop
   the following circumstances, T2 timer, piggy-back an ack (or Extended Data Ack) unto the sender's window length shall be
decreased. However, when
   out-bound datagram, and then start a T3-send timer.

   If the window length reaches 2 it T3-send timer expires, the endpoint shall not follow the rules
   described in 4.6 for possible re-transmission of the un-acked
   datagrams.

   Moreover, whenever the T3-send timer is started the RTT estimate
   last calculated for that remote network address should be
decreased any further.

If between 1 added to 3 consecutive
   the base T3-send timer value (see sections 6.2 and 6.3 for RTT).

C) When all outstanding datagrams are lost, acknowledged, 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 T3-send timer
   shall be decreased by 4.

Moreover, any time a Window Up stopped if one is sent to the receiving still running.

D) If an endpoint the
sender's window length will be decreased by 1. Also, if has a timeout
forces T3-send timer running and receives a retransmission the sender's window length will be reduced
to half of 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/2 partial
   acknowledgment (one that acknowledges some 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)               |
- -----------------------------------------------------------------------

4.3.3 Flow Control using In-Queue Information

By using the In Queue field in the MDTP header, the sender can inform
the receiver outstanding
   datagrams) then the number of pending datagrams which endpoint shall restart the sender has
received, but yet to deliver to its application. T3-send timer.

The following example shows how the endpoints use In Queue value to accomplish Flow control.

Assume that of various timers.

Endpoint A has sent Endpoint Z 20 datagrams, and when                                         Endpoint Z
{App sends an Ack on the reception of these 20 datagrams, only
the first one of them has been delivered to the upper layer at
Endpoint Z.

In the 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 upper layer. 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 2 messages; strm 0}
U-Data (C/D=01)
  [Seen=5,Send=7,Strm=0,Seq=3] ---------> (Start T2-receive timer)
(Start T3-send timer)

U-Data (C/D=01)                           {App sends 1 message; strm 1}
  [Seen=5,Send=8,Strm=0,Seq=4] -\     /-- (cancel T2-receive timer)
                                 \   /    U-Data (C/D=01)
                                  \ /       [Seen=7,Send=6,Strm=1,Seq=2]
                                   \      (Start T3-send timer)
                                  / \
(Re-start T3-send timer) <-------/   \
(Start T2-receive timer)              \
...                                    -> (Start T2-receive timer)
...
{T2-receive timer and
send a Window Up message to Endpoint Z at the expiration of the timer.
This would force Endpoint Z to send another Ack with an updated In
Queue value. If the new In Queue value was still greater than its
window length, Endpoint A would re-start its expires}
Extended Data Ack(C/D=10)
  [Gap=0,Seen=6] -----------------------> (Cancel 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, the transmission at
Endpoint A would resume.

4.3.4 timer)
                                          ..
                                          {T2-receive timer expires}
(Cancel T3-send timer)  <---------------- Extended Data Ack(C/D=10)
                                            [Gap=0,Seen=8]

4.1.1 T3-send Timer Adjustment with RTT

If the RTT measurement is available on to a specific network, remote IP address, the sender
shall adjust the T3-send timer each time when sending datagram using
this network. datagrams to
that IP address. The calculation and adjustment of the timer should
follow the method described in [4]. RTT measurement shall be tracked
for each network destination IP address if redundant networks are in use. the remote host is multi-homed.

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

4.4 Sequence Number Reset 6.3.

4.2 Multihoming Rotation

4.2.1 Remote Multihoming Rotation

When an endpoint is transmitting to a remote multi-homed endpoint, the datagram sequence number reaches the value 0x7fffffff the
next sequence number shall be set to 1.

4.5 Datagram Re-transmission

Whenever a T3-send timer expires, the
transmitting endpoint shall re-transmit the
un-acked datagram that has the lowest Send value, unless:

A) If rotate between destination IP addresses.
Every time the current window length is reached, application transmits a Window Up message will
   be sent out (see 4.3 Congestion Control), or

B) If datagram, MDTP MUST keep track
of the current window length is not reached and there is still
   user data pending for transmission, a new datagram with user data
   shall be remote IP address to which it sent out and T3-send timer shall be restarted.

When a T3-send timer is started at a re-transmission, the length of datagram in the next T3-send timer for this destination MDTP

protocol variable 'last.sent.intf'. MDTP should be doubled rotate each send in a
round robin fashion amongst all available destination IP addresses on
the remote multi-homed host and should update the protocol variable
'last.sent.intf' to indicate which destination IP address it last estimated RTT value for that network
used.

If possible, acks should be added transmitted to the timer.

4.5.1 Re-transmission on Redundant networks

When redundant networks exist between two communicating endpoints, same IP address from
which the
re-transmission shall acked messages were received.  When acknowledging multiple
messages, this may not be attempted on the network specified in possible.  In the latter case, MDTP protocol variable 'last.good.intf'. The value SHOULD
rotate the transmission of 'last.good.intf'
is always updated acknowledgments to refer all remote IP addresses.

The MDTP implementation MUST allow an application to override this
rotation by specifying the network on destination IP address to which the last datagram
from the peer endpoint arrived.

Moreover, the number of consecutive re-transmissions is to send a
datagram.  The implementation must also recorded
in provide an interface to add
and remove a variable 'retran.count' for each network. Every time a datagram
is received on a network, the corresponding 'retran.count' shall be
reset to 0.

If the value remote IP address from rotation eligibility.

4.2.2 Local Multihoming Rotation

As discussed in the 'retran.count' section 3.3.4 of the current RFC 1122, an endpoint MAY rotate
transmitted messages amongst all local network exceeds
half of interfaces by
specifying the value of local IP address and UDP port or it may allow the
networking protocol parameter 'Max.Retransmit', the
'last.good.intf' will be changed, so as to force the next
re-transmission decide which local IP address (and network
interface) to be directed use to an alternate network and
optionally report transmit a failure condition.

The total number datagram..

If possible, acks should be transmitted from the same IP address over
which the acked messages were received. When acknowledging multiple
messages, this may not be possible. In the latter case, MDTP SHOULD
rotate the transmission of consecutive re-transmissions across acknowledgments from all configured IP
address/port pairs.

4.3 Stream Sequence Number

The datagram stream sequence number shall always be set to 1 when the
networks in an association
stream is also recorded. If this opened.

Also, when the stream sequence number reaches the value exceeds 0xffff the
limit defined by 'Max.Retransmit',
next sequence number shall be set to 1. Sequence number '0' has
special meaning (see section 4.4) and shall not be used in normal
sequence number rotation..

4.4 Ordered and Un-ordered Delivery

Normally, the sending endpoint receiver shall consider ensure the peer endpoint unreachable and stop transmitting data user datagrams within any
given stream be delivered to it, and
optionally report the failure.

4.6 RTT Measurement

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

On occasions either side order of an association may need to perform an RTT
measurement
their stream sequence number. If there are datagram arrived out of the network (or one
order of their stream sequence number, 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                   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       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  Transparent Time Int-1                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  Transparent Time Int-2                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Two long integers are used in the data field to carry the time value.
The RTT datagram is identified by setting receiver must hold the RTC or RTM bit to 1.

4.6.2 Measure RTT

AT
received datagrams from delivery until they are re-ordered.

However, a sender can set the request stream sequence number of its upper layer, an endpoint shall initiate an RTT
measurement by sending an RTT datagram with GAR, ACK, and RTC bits set
to 1 (to a specific network if redundant networks exist). No user data
datagram to 0, to indicate that no ordering shall be carried. The sender shall also place in Time Int-1
and Time Int-2 the value of the current time of day in seconds and
microseconds. performed on that
datagram within that stream. Upon the reception of this RTT the datagram, the recipient shall

receiver must by-pass the ordering mechanism and immediately return delivery
the datagram to the sender (over the same network
on which the datagram arrives if redundant networks exist), with the
RTM and ACK bits set upper layer.

This provides an effective way to 1.

Upon the reception of this reply, the sender shall use the Time Int-1
and Time Int-2 transmit "out-of-band" data in any
given stream. Also, a stream can be used as an "un-ordered" stream by
simply setting the reply stream sequence number of each out-bound user
datagram to calculate the RTT (of the
specific network if redundant networks exist).

Endpoint A                                      Endpoint Z
RTT - Request Now=x.y
[Header Flags=ACK|GAR|RTC
        Part=0,Of=1
        Seen=1,Send=31,Size=0
        Time-Int1=x
        Time-Int2=y] ----------------------->
                                      ------ [Header Flags=ACK|RTM
                                     /        Part=0,Of=0
                                    /         Seen=31,Send=1
                                   /          Time-Int1=x
                                  /           Time-Int2=y]
                                 /
(Endpoint A 0.

4.5 Report Missing Datagrams

MDTP uses     <-----------
 current time subtracted from
 x.y a receiver-based retransmission policy, where the sender
attempts to calculate RTT)

4.7 Link Heart Beat

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

At request by its upper layer, an endpoint shall enable heart beat receiver information on the missing
datagrams before the retransmission.

If a specific peer with which it has an established association receiver detects holes in the
Reliable transfer mode.

The RTT received user datagram defined in section 4.6.1 sequence (by
examining TSN Send numbers), an Extended Data Ack with gap reports
shall be used as sent back to inform the Heart
Beat.

After having heart beat enabled, sender so that the missing datagrams
can be re-transmitted.

Multiple gaps can be indicated in one single Extended Data Ack.

If there is out-bound user data, the endpoint shall transmit a Heart
Beat to that specific peer and start a T5-heartBeat timer. The peer
shall immediately respond to piggy-back the Heart Beat
Extended Data Ack with the user data in the same manner as an
RTT as described in section 4.6.  This response shall be stored MDTP datagram, by
setting the
first endpoint (also can be used C/D bits to update its RTT measurement).

When '11'. And the T5-heartBeat timer expires, TSN Seen field in the endpoint data part
shall first check if
the previous heart beat has been responded (on the same network it was
sent in not be used, i.e., the case of redundant network). If not, sender shall set the network that field to 0x0 and the
last Heart Beat was sent upon
receiver shall be counted as a transmission
failure, and be handled ignore it.

The following example shows the rules described use of gap report in section 4.5.
Then, the endpoint shall send another Heart Beat and re-start the
T5-heartBeat timer. an Extended Data
Ack.

Endpoint A                                    Endpoint Z
{App sends 3 messages; strm 0}
U-Data (C/D=01)
   [Seen=3,Send=6,Strm=0,Seq=2]-------> (Start T2-receive timer)
(Start T3-send timer)

U-Data (C/D=01)
   [Seen=3,Send=7,Strm=0,Seq=3]-----X (lost)

U-Data (C/D=01)
   [Seen=3,Send=8,Strm=0,Seq=4]-------> (A gap detected in data)
                                        ..
                                        {T2-receive timer expires}
                                /------ Extended Data Ack (C/D = 10)
                               /          [Gap=1,Strt=7,End=7,Seen=8]
(Prepare retransmission) <----/

In this example, when "Z" receives the case where redundant networks exist, the sending of Heart beats
shall follow the link rotation rules outlined third datagram from "A" it
realizes that a gap exists in section 4.1.1.

If, before the received data. At the expiration of T5-heartBeat
T2-receive timer, "Z" sends an Extended Data Ack with a datagram is
transmitted or received by gap report to
"A" to indicate the endpoint, missing datagram. Note that the T5-heartBeat timer shall
be stopped Start and End
fields in the appropriate T2-T4 timer shall be started. In other
words, gap report specify the T5-heartBeat timer has edges of the lowest precedence.

When no datagram to send gap, i.e., the TSN

numbers between Start and no other timers End are running, missing.

When the
T5-heartBeat timer shall peer endpoint is multi-homed, the Extended Data Ack should be start and
sent out to the above procedure shall
continue.

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

4.8 Advisory Acknowledgment

This defines destination IP address specified in the mechanism for sending and handling MDTP protocol
variable 'last.good.intf'. The value of 'last.good.intf' is always
updated to point to the Advisory
Acknowledgments source IP address from which the last datagram
from the peer endpoint arrived.

4.6 Range Check on TSN

For security reasons, the receiver must check the range of the TSN
Send value in MDTP. each received user datagrams.

Assume that the highest TSN received from a peer is T and the maximal
window length of the same peer is W (exchanged during association
initiation, see section 3.1). When the next user datagram arrives from
this peer, the receiver shall silently discard the datagram if the TSN
Send value carried in the datagram is greater than T+W (calculation
rounds up at 0x7fffffff to 0x1).

4.7 Advisory Ack Request

An endpoint may use Advisory Acks to increase bandwidth utilization
when transmitting over a reliable association.

An Advisory Ack shall be indicated by setting RE1 flag Requests to 1 in the
datagram. improve bandwidth
utilization.

The endpoint shall should send an Advisory Ack Request to its peer when it
reaches half of its current window length, and also when it detects
that the next send will reach the full window length. length (see section 5.1
for window control).

Upon the reception of an Advisory Ack, Ack Request, when it is not under
flow control condition the peer endpoint shall should immediately
acknowledge all the datagrams it has received but not yet
acked upon,
acknowledged, and then cancel the T2-recv T2-receive timer if one is still
running. Otherwise, the peer endpoint shall take no action and ignore
the Advisory Ack Request.

The following shows an example of using Advisory Ack: Ack Request:

Endpoint A                                      Endpoint Z
{App sends 3 messages}
[Header Flags=DAT|GAR|ACK
        Part=0,Of=1
        Seen=0,Send=1,Size=100]-------------> messages; strm 0}
U-Data(C/D = 01)
   [Seen=5,Send=7,Strm=0,Seq=3]-------------> (Start T2-recv timer)
(Start T3-send timer)

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

U-Data(C/D = 01)
   [Seen=5,Send=8,Strm=0,Seq=4]----------->

{detects window half full, use Advisory Ack}
[Header Flags=DAT|GAR|ACK|RE1
        Part=0,Of=1
        Seen=0,Send=3,Size=100]------\
(Stop and restart T3-send timer) Ack Req}
Adv Ack Request(C/D=11)
   [Seen=5,Send=9,Strm=0,Seq=5]------\
                                      \
                                       \----> (cancel T2-receive timer)
                      <---------------------- [Header Flags=ACK
                                               Part=0,Of=0
                                               Seen=3,Send=1]

4.9 Termination of an Association

When an
                            <---------------- Extended Data Ack(C/D=10)
                                                 [Gap=0,Seen=9]

An endpoint terminates, it shall send a Shutdown datagram
(FIR|SHU) to each of the peer endpoints in all sending an Advisory Ack Request may also use this request
for its existing
associations. RTT calculation. The Shutdown sending endpoint may note the time mark
when sending the datagram itself is sent in unreliable
transfer mode and thus needs not to be acknowledged. with the Advisory Ack Request.  When a the
peer endpoint receives the Shutdown, it will remove responds with an Extended Data Ack, the sender
from its record, and optionally report of the termination
Advisory Ack Request may use the time mark of the sender
to arriving Extend Data
Ack and 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    -------------------------> stored time mark to Endpoint Z

4.10 Draining of an Association

An endpoint calculate the RTT as defined in a association may decide to "drain"
[4]. However, the association
without completely shutting it down. By draining an association, both
endpoints will remove any record and pending datagrams associated with sender of the association.  Further communications between Advisory Ack Request shall abandon the two endpoints can
be resumed by going through a re-initialization procedure (see
section 3).

In such a case, a Drain datagram (FIR|SHU|UNR) is
RTT calculation if more datagrams are sent to the its peer
endpoint of the association, and no Extended
Data Ack is required.

The following sequence shows an example of Draining:

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

5   Congestion Controls

Several different mechanisms shall be used jointly to Endpoint X

5. Interface achieve
congestion control in MDTP. These mechanisms are always used in regard
to the association, not a individual stream.

5.1 Send with upper level protocols Window Control

The upper layer protocols (ULP) sending endpoint shall request for services by passing
primitives use a transmission window to control the
number of outstanding datagrams, i.e., datagrams that have been sent,
but yet to MDTP and shall receive notifications from MDTP for
various events.

The primitives and notifications described in this section should be
used acknowledged. The length of the window is defined as the
maximal number of outstanding datagrams a guideline for implementing MDTP.

A) Init.MDTP primitive sending endpoint can
allow. This primitive allows MDTP to initialize its internal data structures
and allocate necessary resources for setting up its operation
environment. Note that once MDTP length is initialized, ULP can communicate
directly with any other endpoints without re-invoking this primitive.

Mandatory attributes:

None.

Optional attributes:

The following types adjusted dynamically, depending on the current
number of attributes may be passed along with successful transmissions as well as the primitive:

 o Timer selection and its operation syntax -- to indicate to MDTP
   an alternative timer number of lost
datagrams or retransmissions.

When the MDTP should use for its operation.
 o Initial MDTP operation mode;
 o IP port number, if ULP wants it to be specified;

B) Send.Data primitive

This is number of outstanding datagrams reaches the main method to current window
length, the endpoint shall still accept send requests from its upper
layer, but shall transmit no more datagrams via MDTP.

Mandatory attributes:

 o data - This is the payload ULP wants to transmit;
 o size - The size until some or all of the payload in number of octets;
 o to-address -
outstanding datagrams are acknowledged. The IP address and port endpoint may also elect
to queue only a specified number of datagram when the intended
   receiver. In case of redundant networks, to-address can be any one
   of the multiple IP addresses window is full.
When this maximal number of queued datagrams is reached the receiver. The network which the
   datagram will actually be sent through will be determined by MDTP due endpoint
shall return an error to its upper layer.

Moreover, when the link rotation, unless window length is reached, the current mode prohibits MDTP link
   rotation; in such case next send request
from the datagram upper layer will trigger a Window-up message to be sent through
transmitted. Upon receiving this Window-up the network
   specified receiver must respond
with a Window-up Ack, as illustrated by to-address (see section 4.5).

Optional attributes:

 o mode-flags - This indicates a new MDTP operation mode, taking effect
   immediately including the following example
(assuming current datagram send;

 o context - optional information that will be carried in the
   Send.Failure notification to window length is 3):

Endpoint A                                      Endpoint Z
{App sends 3 messages, strm 0}
U-Data(C/D = 01)
   [Seen=5,Send=7,Strm=0,Seq=3]--------> (Start T2-receive timer)
(Start T3-send timer)

U-Data(C/D = 01)
   [Seen=5,Send=8,Strm=0,Seq=4]-------->

U-Data(C/D = 01)
   [Seen=5,Send=9,Strm=0,Seq=5]-------->

{App sends a new message, strm 1}
(queue new message and send Win-up)
Window-up(C/D = 10)     ---------------> (cancel T2-recv timer)
                                   /---- Window-up Ack(C/D = 10)
                                  /         [Gap=0,Seen=9]
(Cancel T3-send timer)  <--------/
U-Data(C/D = 01)
   [Seen=5,Send=10,Strm=1,Seq=2]-------> (Start T2-receive timer)
(Start T3-send timer)

In the ULP if above example, after the transportation transmission of
   this datagram fails.

C) Receive.Data primitive

This primitive shall return the first datagram in the MDTP in-queue to
ULP, if there is one available. It may, depending on the specific
implementation, also return other informations such as the sender's
address, whether there are more datagrams available for retrieval,
etc. three
datagrams, "A" reached its window length. The behavior is undefined if no datagram is available when this
primitive is invoked.

Mandatory attributes:

 o buffer - the memory location indicated by next message from the ULP
user triggered a Window-up that was sent to store the
   received datagram and other information.

Optional attributes:

   None.

D) Data.Arrive notification

MDTP "Z". The Window-up shall invoke this notification on the ULP when a datagram is
successfully received
contain no user data. In response, "Z" cancelled timer T2 and ready for retrieval.

E) Send.Failure notification

If
immediately sent a datagram can not be delivered MDTP shall invoke this notification
on the ULP. Window-up Ack. The following may be optionally passed with arrival of this Window-up Ack
effectively resolved all the notification:

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

F) Link.Status.Change notification

When a link is marked down (e.g., when MDTP detects a link failure),
or marked up (e.g., when MDTP detects a link recovery), MDTP shall
invoke this notification on the ULP.

The following shall be passed with the notification:

 o link-address - This indicates the IP address of the affected link;
 o new-status - This indicates the new status of the link;

G) Communication.Up notification

This notification is used when MDTP becomes ready to send or receive
datagrams, or when a lost communication to an endpoint is restored.

The following shall be passed with the notification:

 o status - This indicates what type of event that has occurred;
 o endpoint-id - The IP address and port number to identify the
   endpoint;

H) Communication.Lost notification

When MDTP loses communication to an endpoint completely or detects
that the endpoint has performed a shut-down operation, it shall invoke
this notification on the ULP.

The following shall be passed with the notification:

 o status - This indicates what type of event that has occurred;
 o endpoint-id - The IP address and port number to identify the
   endpoint;
 o packets-enqueue - The number and location of un-sent outstanding datagrams
   still holding by MDTP;
 o last-acked - the sequence number last acked by that peer endpoint;
 o last-sent - the sequence number last sent at "A", thus
allowing "A" to that peer endpoint;

I) Change.Link.Rotation primitive

When send out the upper layer wants to inform MDTP to make a specific network
eligible or ineligible for in link rotation, the upper layer will send
this primitive to MDTP.

Mandatory attributes:

 o  action - This indicates if the network is to be made eligible or
             ineligible for link rotation.
 o  network-id - This is the IP address and port of the network to be
    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
   peer endpoint to which the stream is to be opened. An association
   must have existed at the time of stream open.

Returned attributes:

 o The stream number that is opened.

K) Close.Stream primitive

This shall be used by the upper layer to request to close a 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 this stream).

6. Suggested MDTP Protocol Parameter Values

The following are suggested timer values for MDTP:

T1-init Timer    -  160 ms
T2-receive Timer -   20 ms
T3-send Timer    -  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                                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
Telephony", Internet-Draft <draft-seth-sigtran-req-00.txt>, May, 1999.

Appendix A: Stream-based Reliable next datagram.

5.1.1 Window Length Adjustment

The window length shall be initially set to 2, and Ordered Delivery

This defines a reliable shall then be
dynamically adjusted based on datagram loss and ordered stream mechanism for MDTP. It acknowledgment.

If the current window length is
optional for implementation.

A stream less than or equal to 4, every time
the number of consecutive outstanding datagrams acknowledged in MDTP a
single ack is defined as equal to or greater than half the current window length,
the sender's window length shall be raised by 1, until it reaches
'Max.Outstanding.dg'(which should be a sequence of user configurable parameter).

If the current window length is greater than 4, every time the number
of consecutive outstanding datagrams that needs acknowledged in a single ack is
equal to or greater than 4, the sender's window length shall be reliably delivered with sequence preservation of its own. raised
by 1, until it reaches 'Max.Outstanding.dg'.

In
other words, the delivery of a stream following circumstances, the sender's window length shall not be delayed because of
decreased. However, when the window length reaches 2 it shall not be
decreased any further.

The peer endpoint may report reception gaps which may correspond to
multiple datagram losses (indicated by an Extended Data Ack or re-transmissions occurred in other streams within the
same MDTP association. This capability is a critical requirement of
some telephony call signaling protocols [5].

Stream

Window-up Ack). If between 1 to 3 datagrams are identified lost, the window
length shall be decreased by setting FLO bit to 1.

A.1 Stream Initiation

First, an MDTP association If between 4 to 7 datagrams are lost,
the two endpoints must window length shall be initiated
before any stream operation.

A stream decreased by 2. If 8 or more datagrams are
lost, the window length shall be initiated (opened) decreased by the sender before datagrams
can be 4.

Any time a Window Up is sent in to the stream, and after receiving endpoint the stream is complete it sender's
window length shall be terminated (closed) decreased by the user. 1. Also, both sides of if a timeout forces a
retransmission the
association sender's window length shall be able reduced to initiate or terminate streams
independently. half of
its currently value.

The following table summarizes these rules:

-----------------------------------------------------------------
  duplicate ack received by sender initiates a stream  | Adjust down by sending a Stream Initiation
(NOB|UNR), using the following header format:

                          Stream Initiation

    0                   1                   2                   3
    0 1 2 3 4 5 6 7
-----------------------------------------------------------------
  8 9 0 1 2 3 or more datagrams lost          | Adjust down by 4 5 6 7 8 9 0 1 2 3
-----------------------------------------------------------------
  4 5 6 to 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 MDTP Protocol Identifier                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Version     |              Flags            |   In Queue    | datagrams lost             |               |N N W I F R D A M S W R R F G U| Adjust down by 2
-----------------------------------------------------------------
  1 to 3 datagrams lost             | Adjust down by 1
-----------------------------------------------------------------
  Timeout forced retransmission     |               |O O I S I T A C U H N E T L A N| Adjust down by 1/2 of the
                                    | current window.
-----------------------------------------------------------------
  Window up sent                    |               |M B N B R M T K L U R 1 C O R R| Adjust down by 1
-----------------------------------------------------------------
  4 or more consecutive datagrams   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Adjust up by 1
  acknowledged (window length > 4)  |                         Seen = 0x0 (or Tag)
-----------------------------------------------------------------
  1/2 Window length or more acked   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Adjust up by 1
  (window length <=4)               |
-----------------------------------------------------------------

5.2 Send = 0x0                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        Data Size              |    Part       |      Of       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        New Stream Number      |              0x0              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Note that in the Stream Initiation, Timer Back-off at Re-transmission

Whenever a T3-send timer expires, the Seen and Send endpoint shall be set to 0,
and re-transmit the number of
un-acked datagram that has the new stream being initiated shall be indicated highest TSN Send value in that and
re-start the first two octets of T3-send timer, unless:

A) If the data field.

However, if this current window length is the first datagram reached, a Window-up message shall
   be sent out after receiving the
Initiation Ack from the peer (see section 3.1), 5.1), or

B) If the Seen field of
above Stream Initiation current window length is not reached and there is still user
   data pending for transmission, a new datagram with user data shall
   be set to the Tag value carried in sent out and T3-send timer shall be restarted.

When the
Initiation Ack.

Upon T3-send timer is re-started at a retransmission, the reception length
of the Stream Initiation, the peer timer shall respond
immediately with a Stream Initiation Ack (NOB|UNR|ACK), using be doubled from its previous value. Also, 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                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   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                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           Send = 0x0                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        Data Size              |    Part       |      Of       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
latest estimated RTT value for that network should be added to the new
timer value. The following example shows the opening calculation of stream 5 by "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 timer
value, where 'TL3-default' is a configurable protocol parameter.

<at normal transmission>
  1. TL3-value = 'TL3-default'
  2. T3-send = TL3-value + RTT

<at re-transmissions>
  1. TL3-value = TL3-value * 2
  2. 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 = TL3-value + RTT

The T3-send timer at the sender shall be allowed restored to terminate the
stream by sending its default value
when a Stream Termination (FLO|UNR|SHU) to datagram is received from the other side.

Besides flag RES, peer endpoint.

The Stream Termination total number of consecutive re-transmissions to all destination IP
addresses in an association shall use be recorded. If this value exceeds
the same header
format as that used limit defined in Stream Initiation 'Max.Retransmit', the sending endpoint shall
consider the peer endpoint unreachable and shall stop transmitting any
more data to it. The sending endpoint MAY report the failure to the
upper layer, including all datagrams in its out-bound buffer which
have not been acknowledged. Whenever a datagram (see A.2)

A Stream Termination Ack (FLO|UNR|SHU|ACK) is received from a
peer endpoint the total number of retransmissions shall be sent by cleared.

6.  Network Management

6.1 Failure Detection in Redundant Networks

When the peer endpoint is multi-homed, the re-transmission of a
datagram should be attempted to the destination IP address specified
in response. the MDTP protocol variable 'last.good.intf'. The following example shows value of
'last.good.intf' is always updated to point to the termination source IP address
from which the last datagram from the peer endpoint arrived.

The number 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 consecutive T3-send timer s-5) <------------ [Header Flags=FLO|UNR|SHU|ACK
                                          Part=0,Of=1
                                          Seen=5,Send=0]

Datagrams associated to timeout events is also recorded in
a terminated stream received by either side variable 'retran.count' for each destination IP address. This count
should be silently discarded. It incremented when a T3-send time-out event occurs for that
destination IP address. Every time a datagram is up to received from a peer
endpoint, the side which terminates receiving endpoint shall reset to 0 the stream 'retran.count'
corresponding to assure that all outstanding user datagrams in the stream
are acknowledged before source IP address .

If the termination.

A.3 Stream Datagram Transfer

A.3.1 Header Format in Stream Datagrams with User Data

The MDTP header value in a stream datagram with user data 'retran.count' exceeds half of the value of the
protocol parameter 'Max.Retransmit', the destination IP address shall have
be reported to the
following 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                              /
   \                                                               \
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The stream number upper layer as out-of-service and sequence number in the Send field shall be used
by removed
from eligibility for rotation.  When re-transmitting a datagram, the sender
re-transmission should use 'last.good.intf' as the preferred
destination IP address to which to re-transmit, unless 'last.good.intf'
points to identify the current stream datagram. And, destination IP address on which the
stream number and sequence number in original T3-send
time-out event occurred.

In the Seen field event that a datagram is received from an IP address that has
been reported as out-of-service, the 'retran.count' shall be cleared
as specified above, the destination IP address shall be used
by the sender reported as
in-service to acknowledgment of stream datagrams it has received.

Stream number 0 and sequence number 0 are reserved for special
purposes the upper layer, and are not the destination IP address shall be
considered valid stream number or sequence number.

A.3.2 Transmission for rotation.

6.2 RTT Measurement

On occasions an endpoint of Stream Datagrams

The rules an association may need to perform an RTT
measurement of using the 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 network (or one of the
sequence numbers shall roll-over to 1 after 0xFFFF.

Moreover, each stream maintains redundant networks) between
itself and its individual T3-send timer, but only
one global T2-receive timer is maintained for all existing streams.

Acknowledgment to a stream datagram peer.

RTT-request and RTT-ack messages shall either be sent separately
or be piggy-backed with a stream datagram (not necessarily belonging used to perform the same stream) traveling in RTT
measurement. In the opposite direction. For a
separate Stream Ack, messages, two 32 bit long opaque integers are used
in the Send control parameter field will be set to 0000:0000.

The following shows an example of transmitting a stream datagram
(FLO|REL|DAT) and a separate Stream Ack (FLO|REL|ACK):

Endpoint A                                      Endpoint Z
{App sends 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 carry the use of a piggy-backed Stream Ack.

{App sends 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 data on stream 11}
                                            (cancel T2-recv Timer)
                                     /----- [Header Flags=FLO|REL|DAT|ACK
                                    /        Part=0,Of=1
                                   /         Seen=5-4,Send=11-8,Size=10]
                                  /         (Start T3-send timer-s11)
(Cancel T3-send timer-s5)  <-----/
(Start T2-recv timer)
...
{T2-recv Timer Expires}
[Header Flags=FLO|REL|ACK
        Part=0,Of=1
        Seen=11-8,Send=0-0,Size=0]--------->(Cancel T3-send-s11)

Note that when piggy-back a Stream Ack with an out-bound stream
datagram when more than one streams have un-acked datagrams, time value.

At the request of its upper layer, an endpoint shall choose one stream and piggy-back initiate an RTT
measurement by sending an RTT-request (to a Stream Ack on one specific network if
redundant networks exist). The sender shall also place in Time value 1
and Time value 2 the value of the datagrams, and current time mark.

Upon the reception of this RTT-request message, the recipient shall leave
immediately respond with a RTT-ack to the T2-recv timer running.

A.3.3 Extended Stream Ack sender (over the same
network on which the RTT-request arrives if the recipient is
multi-homed), with the time mark carried in the original RTT-request
copied into its own Time value fields.

Upon the expiration reception of T2-recv timer, if there are more than one
stream datagrams received but yet acked upon by this reply, the endpoint, an
Extended Stream Ack sender shall be used.

The following defines use the header format of time mark
in the 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 Extra Acks = N-1                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        Data Size              |    Part       |      Of       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         Stream Number #1      |    Sequence Number #1         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   \ reply RTT-ack to calculate the RTT (to the specific destination
IP address if redundant networks exist) as defined in [4].

Endpoint A                                      Endpoint Z
{RTT - Request Now=x.y}
RTT-request (C/D=10)
   [Time-value1=x,
    Time-value2=y,
    Seen=81]       ----------------------->
                                    /------- RTT-ack (C/D=10)
                                   /            [Time-value1=x,
                                  /                                                               \
   \              Time-value2=y,
                                 /
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         Stream Number #N-1    |    Sequence Number #N-1       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Note that an Extended Stream Ack is identified by setting the Seen
field               Seen=3]
(Endpoint A uses     <----------/
 x.y to calculate RTT)

6.3 Network Heart Beat

At the number request of extra acks carried in its data field, upper layer, an endpoint shall enable heart beat
to a specific peer with which it has an established association.

The RTT-request message defined in section 2.2 shall be used as shown
above. Also, Extended Stream Acks
the heart beat while the RTT-ack shall not be piggy-backed. used as the heart beat
response.

After having heart beat enabled, the endpoint shall transmit a heart
beat to that specific peer and start a T5-heartBeat timer. The following example shows peer
shall immediately respond to the using of an Extended Stream Ack
(NOB|REL|ACK) heart beat in the same manner as the
RTT measurement procedure described in section 6.2. This response, as
well as the new RTT measurement, shall be stored by "Z":

Endpoint A                                      Endpoint Z
{App sends data on stream 5}
[Header Flags=FLO|REL|DAT
        Part=0,Of=1
        Seen=0-0,Send=5-2,Size=20]----------> (Start T2-recv)
(Start T3-send timer-s5)
{App sends data on stream 9}
[Header 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=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-s7)
                                              ...
                                              {T2-recv Timer Expires}
(Cancel T3-send timer-s5)     <-------------- [Header 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 rules for timer management endpoint.

When the T5-heartBeat timer expires, the endpoint shall first check if
the previous heart beat has been responded to (on the same network it
was sent in the case of multi-homed hosts). If not, the destination IP
address to which the last heart beat was sent shall have the
'retran.count' incremented and window
management, shall apply to Stream Transfer checked following the same way as it does to
non-Stream based transfer, as defined rules described
in section 4.3.

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

- -- The receiver 6.1. Then, the endpoint shall silently discard any datagrams associated
with a stream which has not been initiated or has already been
terminated.

- -- The same re-transmission send another heart beat and link
re-start the T5-heartBeat timer.

In the case where one or both endpoints are multi-homed, the sending of
Heart beats shall follow the network rotation rules as defined outlined 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 4.2.

If, before the mechanism for bundled expiration of T5-heartBeat timer, a datagram transport in MDTP. It is optional for implementation.

Bundling is sometimes desired
received by the user when transferring small
datagrams, as a way of improving network utilization. endpoint, the T5-heartBeat timer shall be stopped and
the appropriate T2-receive timer shall be started. In bundled transfer, MDTP allows an endpoint other words, the
T5-heartBeat timer has the lower precedence than the T2-receive timer.

When there are no datagrams to bundle small
application messages into one single datagram for transmission. This
bundled mode can send and no other timers are running,
the T5-heartBeat timer shall be applied to both reliable started and unreliable datagrams
(see Appendix E the above procedure shall
continue.

The suggested interval for Unreliable Delivery).

Note that T5-heartBeat timer is 4000 ms, and may be
dynamically adjusted by adding the current RTT measurement if it is
available.

7.  Termination of Association

Before an endpoint terminates itself, it shall never send bundled messages an Abort message
to a each of its peer if
that endpoints in all existing associations. The Abort
shall be sent without requiring an acknowledgment from the peer endpoint set NOB bit to 1 during their association
initialization (see section 3).

B.1 Format
endpoint. However, the sender of Bundled Datagram

The ISB bit the Abort message MUST fill in the flag field is set
peer's Init-Tag.

When the peer endpoint receives the Abort, after verifying the Tag,
the peer shall remove the sender from its record, and optionally
report the termination of the sender to indicate its upper layer. However if
the current datagram Tag sent with the Abort message is bundled, i.e., it contains multiple messages. incorrect, the peer must
silently discard the Abort message.

The format following shows an example 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 the termination of Endpoint A:

Endpoint 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
{App indicates termination}
Abort (C/D = B1        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   |                     B1 octets of data                         |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Message #2 Size 10)
    [Tag-X]   --------------------------------> to Endpoint X

Abort (C/D = B2        |                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
   |                     B2 octets of data                         |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   \                                                               \
   /                                                               /
   \                                                               \
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Message #N Size 10)
    [Tag-Y]   --------------------------------> to Endpoint Y

Abort (C/D = BN        |                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
   |                     BN octets 10)
    [Tag-Z]   --------------------------------> to Endpoint Z

7.1 Graceful Shutdown of data                         |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Data_Size an Association

An endpoint in an association may decide to "graceful shutdown" the
association without completely closing it down. With graceful
shutdown, both endpoints shall remove any record and pending datagrams
associated with the association. Further communications between the
two endpoints can be resumed by going through a bundled datagram indicates re-initialization
procedure (see section 3.5.4).

A Graceful Shutdown message shall be sent to the actually size peer endpoint of the
data field
association, and the peer shall send back an acknowledgment.  Note
that it shall be the responsibility of the datagram, including both endpoint that sends the bundling overhead and
Graceful Shutdown message to assure that all the actually user data. Since no fragmentation is allowed in a bundled
datagram, outstanding datagrams
from its side have been resolved before it initiates the Part field will always be '0' and graceful
shutdown procedure.

In the Of field always be
'1'.

The first two octets Graceful Shutdown message, the sender shall indicate the
highest TSN Seen it has received from the peer, as well as the
Init-Tag of the data field is a 16 bit integer indicating peer.

Upon the number reception of messages bundled the Graceful Shutdown, the peer shall first
verify that Tag value contained in the current datagram. This Graceful Shutdown message is
followed immediately by a list of bundled messages. Each bundled
valid. If the Tag is invalid, the message starts must be silently discarded.

The peer then shall verify, by checking the Seen numbers from the
Graceful Shutdown message, that all the out-bound datagrams have
reached the destination.  Otherwise, the peer shall re-transmit all
lost datagrams.

After sending the Graceful Shutdown, if the endpoint receives any new
user datagram it shall immediately respond with an integer of two octets indicating Extended Data Ack
and re-start its T3-send timer.

The peer shall send a Graceful Shutdown Ack when all the outstanding
datagrams are acknowledged, then start a T4-shutdown timer. The
endpoint, after receiving the size of Graceful Shutdown Ack, must also
validate the data Tag value contained in the message, followed by message. If it does not match
the data itself.

All integers in Tag value that unlocked the datagram association, the message should 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 control the bundling of user
datagrams.
silently discarded.

The endpoint will withhold the datagram from transmission and start
T4-bundle timer, if the combined size following sequence shows an example of all user Graceful Shutdown:

    Endpoint A                                  Endpoint X
{App indicates graceful shutdown}
Graceful Shutdown (C/D=10)
   [Tag-X, Seen=10] ---------------------> (all datagrams currently
pending for transmission in resolved)
(start T3-send timer)            /-------- Graceful Shutdown Ack (C/D=10)
                                /             [Tag-A]
                               /           (start T4-shutdown timer)
(cancel T3-send timer) <------/            ...
(clean-up the out-bound buffer is smaller than
'Min.Bundle'.

Each time a association)                 (T4-shutdown expires)
                                           (clean-up the association)

Both endpoints shall reject any new out-bound user data becomes available for
transmission, request from their upper layers
while the endpoint will attempt to bundle graceful shutdown procedure is in progress.

8.  Stream Operations

8.1 Stream Initiation

An MDTP association between the new data with two endpoints must be established
before any stream operation.

Except for the current withheld datagram global stream (i.e, stream id 0), a stream shall be
initiated (opened) by using the following rules:

A) If sender before any datagrams can be sent in
that stream. When a stream is no longer used, it shall be terminated
(closed) by the size user. Moreover, both sides of the new data is greater than association shall be
able to initiate or equal terminate streams independently.

The sender initiates a stream by sending a Stream Initiation. In
addition to
   'Min.Bundle', specifying the current withheld datagram will be transmitted and
   T4-bundle timer will be canceled. Then, Stream Identifier, the new data will be
   transmitted in a separate datagram.

B) If sender must set the size
Init-Tag field of the new data is less than 'Min.Bundle', but Stream Initiation to the
   combined size Tag value of the current datagram and peer
endpoint.

The sender shall also attach the new data is greater
   than or equal to 'Max.Bundle', stream-specific data, if any (usually
provided by the current datagram will be sent and upper layer), with the new data will Stream Initiation. Otherwise,
the Size of Stream Info shall be withheld as set to 0x0.

Then, the new current datagram.

C) sender shall start a T3-send timer. If the size of T3-send timer
expires, the new data is less than 'Min.Bundle', and sender shall re-transmit the
   combined size Stream Initiation.

Upon the reception of the current datagram and Stream Initiation, the new data peer must first
verify that the correct Tag value is greater
   than 'Min.Bundle', but less than 'Max.Bundle', carried in the new data will be
   bundled into Init-Tag field of
the current datagram and Stream Initiation. If so, the bundled datagram will be peer shall respond immediately transmitted. and T4-bundle timer will be canceled.

D) If with
a Stream Initiation Ack. Otherwise, the size of peer must silently discard the new data is less than 'Min.Bundle', and
Stream Initiation.

The following example shows the
   combined size opening of stream 5 by "A":

    Endpoint A                                   Endpoint Z
{App Initiates stream 5}
Stream Initiation (C/D=10)
   [Tag=Tag-Z,Strm=5]   ----------------->
(Start T3-send timer)
(Cancel T3-send timer)  <----------------- Stream Initiation Ack
                                             (C/D=10) [Strm=5]

8.2 Stream Termination

An endpoint shall be allowed to terminate one of its streams by
sending a Stream Termination to the current datagram and other side.

The same Tag verification process used for stream initiation shall
be applied to stream termination.

The peer shall send a Stream Termination Ack in response to the new data is less than
   Min.Bundle, Stream
Termination.

The following example shows the new data will termination of stream 5 by "A":

    Endpoint A                                  Endpoint Z
{App closes stream 5}
Stream Termination (C/D=10)
   [Tag=Tag-Z,Strm=5] ------------------->
(Start T3-send timer)
(Cancel T3-send timer) <------------------ Stream Termination Ack
                                             (C/D=10) [Strm=5]

Received datagrams associated with a terminated stream shall be bundled into
silently discarded. It is up to the current
   datagram. And endpoint to assure that all
outstanding user datagrams in the T4-bundle timer will be restarted.

E) If T4-bundle timer expires, stream are acknowledged before the current datagram
stream termination.

8.3 Other Issues with Stream Operations

When an association is re-initialized (see section 3.5.4), all existing
streams within that association will be sent
   immediately.

F) When a T2-receive timer expires, automatically terminated.

The receiver shall silently discard any bundled data waiting to be
   transmitted should be sent immediately datagrams associated with a piggy-backed Ack
stream which has not yet been opened or has already been terminated.

9.  Interface with Upper Layer

The upper layer protocols (ULP) shall request for services by passing
primitives to
   acknowledge all un-acked data previously received.

G) If a T4-bundle timer is running MDTP and data arrives, the T2-receive
   timer should not be started.

H) A T4-bundle timer shall receive notifications from MDTP for
various events.

The primitives and notifications described in this section should never be canceled unless it is being
   supplanted by a T3-send timer.

When
used as a bundled datagram arrives at the receiving endpoint, each
message is unbundled and delivered separately to the upper layer.

The following are the suggested protocol parameter values guideline for bundled
datagram transfer:

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

Appendix C: Fragmented Message Transfer implementing MDTP.

A) Init.MDTP primitive

This defines the mechanism primitive allows MDTP to initialize its internal data structures
and allocate necessary resources for fragmented datagram transport in
MDTP. It setting up its operation
environment. Note that once MDTP is optional for implementation.

When the size initialized, ULP can communicate
directly with any other endpoints without re-invoking this primitive.

Mandatory attributes:

None.

Optional attributes:

The following types of an out-bound user message exceeds the value defined
in attributes may be passed along with
the protocol parameter Max.Bundle, primitive:

 o Timer selection and its operation syntax -- to indicate to MDTP
   an alternative timer the endpoint shall fragment MDTP should use for its operation.
 o Initial MDTP operation mode;
 o IP port number, if ULP wants it to be specified;

B) Init.Association

This primitive allows the
message into smaller pieces of size equal upper layer to or smaller than
'Max.Bundle' and send each piece out in a separate datagram.

The "Part" and "Of" fields are used initiate an association to disassemble and reassemble the
fragmented message. a
specific peer endpoint. The combination peer endpoint shall be specified by one of
the maximal 'Of' value, IP address/port pairs which
is 255, and define the maximal Data Size endpoint (see section 2.2) will determined 1.1).

Mandatory attributes:

 o associationID - specified as one of the maximal size IP address/port pairs of
   the peer endpoint with which the association is to be established.

Optional attributes:

 o eligibleNetList - a single user message list of destination IP address/port pairs that
   the MDTP can send or
receive in fragmented message transfer mode.

However, an endoint shall never send fragmented datagrams peer endpoint is allowed to a use in its network rotation. By
   default, all destination IP address/port pairs on the peer if
that are
   available.

C) Term.Association

Terminating an association.

Mandatory attributes:

 o associationID - specified as one of the IP address/port pairs of
   the peer set endpoint with which the NOM bit to 1 during their association
initialization.

The following example shows is to be terminated.

Optional attributes:

None.

D) Send.Data primitive

This is the transmission of a fragmented message
(assuming Max.Bundle=1432, Min.Bundle=1000):

Endpoint A                                      Endpoint Z
{App sends message size=3300 octets}
[Header Flags=DAT|ACK|GAR
        Part=0,Of=3
        Seen=3,Send=16,Size=1432]-------> (Start T2-receive timer)
[Header Flags=DAT|ACK|GAR
        Part=1,Of=3
        Seen=3,Send=17,Size=1432]------->
[Header Flags=DAT|ACK|GAR
        Part=2,Of=3
        Seen=3,Send=18,Size=436]-------->
(Start T3-send timer)
                                              ..
                                              {Timer T2 Expires}
                                 /----------- [Header Flags=ACK
                                /              Mode=0
                               /               Part=0,Of=0
(cancel timer T3) <-----------/                Seen=18,Send=4]

Notice that "A" main method to send datagrams via MDTP.

Mandatory attributes:

 o data - This is using the reliable transfer mode payload ULP wants to send the
fragmented message, therefore "Z" will hold transmit;
 o size - The size of the fragments and request
retransmission if a fragment is found missing, i.e., if a gap is found payload in the received data (see ). When all the parts number of octets;
 o associationID - One of the fragmented
message are received, IP address/port pair of the receiving endpoint will re-assemble peer endpoint.
   Note that the
message and dispatch it actual destination address sent to the upper layer.

It is also allowed in will be determined
   by MDTP due to send fragmented message using Unreliable
Transfer the network rotation, unless the current mode (see section 4.5). However,
   prohibits MDTP network rotation; in unreliable mode, each
fragment such a case the datagram will
   be dispatch sent to the application upon its arrival, and no
retransmission will be requested even if IP address/port specified by associationID.

Optional attributes:

 o mode-flags - This indicates a fragment is found missing.

Bundling is prohibited if new MDTP operation mode, taking effect
   immediately including the current datagram contains a fragment of
a fragmented message.

Appendix D: Multicast Datagram Transfer

This defines send;
 o context - optional information that will be carried in the
   Send.Failure notification to the ULP if the mechanism for unreliable transportation of multicast
datagrams
   this datagram fails.

 o streamID - to indicate which stream to send the data on. By
   default, the global stream will be used.

E) Receive.Data primitive

This primitive shall return the first datagram in MDTP. It the MDTP in-queue to
ULP, if there is optional for implementation.

D.1 Multicast Datagram Header Format

Multicast datagrams one available. It may, depending on the specific
implementation, also return other informations such as the sender's
address, whether there are identified more datagrams available for retrieval,
etc. The behavior is undefined if no datagram is available when this
primitive is invoked.

Mandatory attributes:

 o buffer - the memory location indicated by setting MUL, UNR, and DAT bits
to 1.

Two new fields are added the ULP to store the standard
   received datagram and other information.

Optional attributes:

   None.

F) Data.Arrive notification

MDTP shall invoke this notification on the ULP when a datagram header to
support multicast:

Multicast To Transmit address - This is
successfully received and ready for retrieval.

G) Send.Failure notification

If a datagram can not be delivered MDTP shall invoke this notification
on the multicast address, in
network byte order, that the sender transmitted ULP.

The following may be optionally be passed with the notification:

 o data to. The
receiver can use this information for internal tracking purposes.

Multicast From - This is the network address (or the IP Address of
Network 1 as described in 3.2, if redundant networks exist) of location ULP can find the
sender, in network byte order.

                 MDTP Header Format un-delivered datagram.
 o context - 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | optional information associated with this datagram (see
   D).

H) Network.Status.Change notification

When a endpoint-id is marked down (e.g., when 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       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  Multicast To Transmit address                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |             Multicast From - senders base address             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   \                                                               \
   /                             data                              /
   \                                                               \
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

For multicast datagrams, the value in detects a failure),
or marked up (e.g., when MDTP detects a recovery), MDTP shall
invoke this notification on the Send field ULP.

The following shall indicate be passed with the sequence number notification:

 o endpoint-id - This indicates the IP address/port of multicast datagrams transmitted the
   peer endpoint affected by the
sender. change;
 o new-status - This information helps indicates the receiver of new status.

I) Communication.Up notification

This notification is used when MDTP becomes ready to send or receive
datagrams, or when a lost communication to an endpoint is restored.

The following shall be passed with the multicast notification:

 o status - This indicates what type of event that has occurred;
 o associationID - An IP address/port to detect
duplicated multicast datagrams and also identify the peer endpoint;

J) Communication.Lost notification

When MDTP loses communication to detect lost multicast
datagrams from an endpoint completely or detects
that the same sender. endpoint has performed a abort or graceful shutdown
operation, it shall invoke this notification on the ULP.

The Seen field following shall normally be
set passed with the notification:

 o status - This indicates what type of event that has occurred;
 o associationID - An IP address/port number to 0, unless in some special cases stated below.

Bundling identify the peer
   endpoint;
 o packets-enqueue - The number and fragmentation are not allowed in either multicast location of un-sent datagrams
   still holding by MDTP;
 o last-acked - the sequence number last acked by that peer endpoint;
 o last-sent - the sequence number last sent to that peer endpoint;

K) Change.Network.Rotation primitive

When the upper layer wants to inform MDTP to make a specific network
eligible or
broadcast datagrams.

No initiation shall ineligible for in network rotation, the upper layer will send
this primitive to MDTP.

Mandatory attributes:

 o  action - This indicates if the network is to be needed made eligible or
             ineligible for an network rotation.
 o  network-id - This is the IP address/port of the peer endpoint to transmit
    be added or removed from network rotation consideration.

L) Open.Stream primitive

This should be used by the upper layer to open a
multicast address.

D.2 Transmission new stream.

Mandatory attributes:

 o associationID - One of Multicast Datagrams

The 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 values IP address/port to identify the peer
   endpoint of the Send field in association to which the multicast datagrams
(which are 5 and 6, respectively). They represent stream is to be opened. An
   association must have existed at the sequence numbers time of the multicast datagrams "A" has sent out. Endpoint Z stream open.

Optional attributes:

   streamInfo - The upper layer should use this value field to detect missing or duplicate datagrams.

Duplicate datagrams will be discarded and no effort will be made pass any
   stream-specific data to
retransmit lost multicast datagrams.

D.3 Reset of the Multicast Datagram Sequence Number

If the Seen field other endpoint of a received multicast datagram equals to '1', this
indicates that the sender has reset its multicast datagram sequence
number. association.

Returned attributes:

 o The receiving endpoint, upon detecting this reset indicator in
the incoming multicast datagram, should start a procedure to adopt the
new sequence stream number for error detection. However, caution
should that is opened.

M) Close.Stream primitive

This shall be taken used by the upper layer to prevent false resets due request to duplicated datagrams
with reset indicator propagating through multiple networks.

To guarantee that all receivers close a stream.

Mandatory attributes:

 o associationID - One of the multicast group adopt the new
sequence number, the reset indicator should be repeated within the
first N multicast datagrams sent out after the reset. N is predefined
by IP address/port to identify the protocol parameter 'Num.Of.Mcast.Reset.Msg'.

At peer
   endpoint of the receiving endpoint, when association to which the reset indicator stream is detected the
new sequence number will to be adopted. However, if two reset events are
detected within a predefined time interval (Min.Mcast.Time.To.Reset), closed.

 o stream number - The stream number to identify the second reset indicator will stream to be
   closed (this should be ignored. the number returned by the Stream.Open
   primitive on this stream).

10. Suggested MDTP Timer and Protocol Parameter Values

The following are suggested timer values for these two MDTP:

T1-init Timer       -   160 ms
T2-receive Timer    -    20 ms
T3-send Timer       -   160 ms (TL3-default)
T4-shutdown Timer   -   300 ms
T5-heartBeat timer  -  4000 ms (TL5-default)

The following protocol parameters are: 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

Appendix E: Unreliable Delivery

This defines the support

11. Acknowledgments

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

12.  Authors' 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

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

Chip Sharp                                  Tel: +1-919-851-2085
Cisco Systems Inc.                          EMail:chsharp@cisco.com
7025 Kit Creek Road
Research Triangle Park, NC  27709

Hanns Juergen Schwarzbauer                  Tel: +49-89-722-24236
SIEMENS AG
Hofmannstr. 51
81359 Munich,  Germany
EMail: HannsJuergen.Schwarzbauer@icn.siemens.de

Tom Taylor                                  Tel: +1-613-736-0961
Nortel Networks                             EMail:taylor@nortelnetworks.com
1852 Lorraine Ave.
Ottawa Ontario Canada
K1H6Z8

Ian Rytina                                  Tel:
Ericsson Australia                          EMail:ian.rytina@ericsson.com
37/360 Elizabeth Street
Melbourne, Victoria 3000, Australia

13. 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 sending Unreliable datagrams Signaling in MDTP.  It
is optional Internet
Telephony", Internet-Draft <draft-seth-sigtran-req-00.txt>, May 1999.

[6] Rytina, I., "Framework for implementation.

The unreliable transfer mode allows two endpoints to 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 Generic Common Signaling Transport
Protocol", draft-rytina-sigtran-generic-framework-00.txt>, Feb. 1999.

[7] Ashworth, J., "The Naming of a datagram with user data
simply sets the 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 started by either end, Hosts", RFC 2100, April 1997.

[8] Braden, R., "Requirements for Internet hosts - Application and that even
though both ends are in Unreliable transfer mode, the ACK flag is
still set by the sender of the datagram. This means that the Seen
field in the datagram header is still valid to indicating the sequence
number of the last 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 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 last datagram it has
passed to the upper layer, that datagram shall be silently discarded.
Support", RFC 1122, October 1989.

[9] Eastlake 3rd, D., Crocker, S., and Schiller, J., "Randomness
Recommendations for Security", December 1994.

      This Internet Draft expires in 6 months from April June 1999.