home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / drafts / draft_n_r / draft-riechmann-multicast-mail-00.txt < prev    next >
Text File  |  1997-09-04  |  59KB  |  1,512 lines
  1.  
  2.  
  3. INTERNET-DRAFT                                               P. Copeland
  4. Expires March 1998                                               TNO-FEL
  5.                                                             C. Riechmann
  6.                                                                 FGAN/FFM
  7.                                                          September, 1997
  8.  
  9.  
  10.                                  P_Mul:
  11.           An Application Protocol for the Transfer of Messages
  12.         over Multicast Subnetworks and under EMCON Restrictions
  13.                 (draft-riechmann-multicast-mail-00.txt)
  14.  
  15.  
  16.  
  17. Status of this Memo
  18.  
  19.    This document is an Internet-Draft. Internet-Drafts are working
  20.    documents of the Internet Engineering Task Force (IETF), its areas,
  21.    and its working groups. Note that other groups may also distribute
  22.    working documents as Internet-Drafts.
  23.  
  24.    Internet-Drafts are draft documents valid for a maximum of six months
  25.    and may be updated, replaced, or obsoleted by other documents at any
  26.    time. It is inappropriate to use Internet-Drafts as reference
  27.    material or to cite them other than as ``work in progress.''
  28.  
  29.    To learn the current status of any Internet-Draft, please check the
  30.    ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow
  31.    Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
  32.    munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
  33.    ftp.isi.edu (US West Coast).
  34.  
  35.  
  36. Abstract
  37.  
  38.    P_Mul is a proposal for an application protocol for the transfer of
  39.    messages using a connectionless transport protocol. The objectives of
  40.    this protocol are first to take advantage of the bandwidth saving
  41.    feature of using the multicast service as supported by modern
  42.    computer networks and second to allow message transfer under EMCON
  43.    conditions. EMCON (Emission Control) means that, although receiving
  44.    nodes are able to receive messages, they are not able to acknowledge
  45.    the receipt of messages.
  46.  
  47.    The protocol described below has already been applied to the transfer
  48.    of messages between X.400 Message Transfer Agents (MTA). But it is
  49.    not only restricted to this application and can easily be applied to
  50.    the transfer of RFC822 messages.
  51.  
  52.  
  53.  
  54. Copeland/Riechmann         Expires March 1998                   [Page 1]
  55.  
  56. INTERNET-DRAFT                                            September 1997
  57.  
  58.  
  59. Table of Contents
  60.  
  61.         1. Introduction
  62.         2. Protocol Layering
  63.         3. Protocol Data Units (PDU)
  64.         3.1. Address_PDU
  65.         3.2. Data_PDU
  66.         3.3. Discard_Message_PDU
  67.         3.4. ACK_PDU
  68.         4. Messaging Procedures
  69.         4.1. Transmission and Re-transmission of a Message
  70.         4.2. Reception of a Message
  71.         4.3. Acknowledgement of a Message
  72.         5. Example
  73.         6. References
  74.         A. Appendix
  75.         A.1. Abbreviations
  76.         A.2. Predefined Protocol Parameters
  77.         A.3. Proposed UDP Port Numbers
  78.         A.4. Proposed Algorithm for the Checksum
  79.  
  80.  
  81.  
  82. 1. Introduction
  83.  
  84.    The objective of this protocol is to take advantage of multicast
  85.    communication for the transfer of messages between MTAs (Message
  86.    Transfer Agents) on a single multicast network under normal - which
  87.    means dialogue oriented - communication conditions and under EMCON
  88.    conditions. EMCON condition means that a receiving node is able to
  89.    receive messages, but it cannot - for a relitive long time (hours or
  90.    even days) - acknowledge the received messages.
  91.  
  92.    Figure 1 illustrates a simple multicast scenario, where the same
  93.    message has to be sent from MTA 1 to MTA 2 and to MTA 3.
  94.  
  95.                                          +-------+
  96.                                       /->| MTA 2 |
  97.            +-------+       +-------+ /   +-------+
  98.            | MTA 1 |<----->| Router|<
  99.            +-------+       +-------+ \   +-------+
  100.                                       \->| MTA 3 |
  101.                                          +-------+
  102.  
  103.              Figure 1: Typical MTA Configuration
  104.  
  105.    Using a multicast instead of an unicast communication service in the
  106.    above MTA configuration only one message transmission from MTA 1 to
  107.  
  108.  
  109.  
  110. Copeland/Riechmann         Expires March 1998                   [Page 2]
  111.  
  112. INTERNET-DRAFT                                            September 1997
  113.  
  114.  
  115.    the Router is required, instead of two as required with unicast.
  116.    This saves the transmision of one message and thus network bandwidth
  117.    utilisation.  Depending on the network bandwidth (in some radio
  118.    networks less than 9.6 Kb/s) this saving can be of vital importance.
  119.    The saving in bandwidth utilisation becomes even greater with every
  120.    additional receiving MTA.
  121.  
  122.    As P_Mul employs a connectionless transport protocol to transmit
  123.    messages, the reliable message transfer is guaranteed even in those
  124.    cases, when for a certain period of time one or more of the receiving
  125.    MTAs are not able or allowed to acknowledge completely received
  126.    messages.
  127.  
  128.    The protocol P_Mul has been applied to the communication between
  129.    X.400 MTAs; but it is not constrained to X.400 MTA communication, it
  130.    also can be applied to other kinds of reliable multicast
  131.    transmission, e.g. file transfer or RFC822 messages.
  132.  
  133.    This protocol specification requires fixed multicast groups and a
  134.    well known knowledge at each participating node(MTA) about the group
  135.    memberships to one or more multicast groups of each participating
  136.    node.
  137.  
  138.  
  139. 2. Protocol Layering
  140.  
  141.    As mentioned above this protocol has to be understood as an
  142.    application layer protocol, in the same way as the P1 protocol
  143.    defined in the X.400 Recommendations [CCITT88]. As in the case of P1,
  144.    P_Mul will use the lower layer protocols to transmit its PDUs over
  145.    the multicast network.
  146.  
  147.    Considering the fact that MTAs under EMCON are not allowed to
  148.    exchange any messages with their partner MTAs, it is not possible to
  149.    use a reliable transport protocol like "RMP" [RMP95-1, RMP95-2,
  150.    RMP95-3] or "XTP" [XTP95] for the transfer of messages. Therefore
  151.    P_Mul will be based on the unreliable connectionless transport
  152.    protocol "UDP" [UDP80]. A proposal as to which UDP ports shall be
  153.    used can be found within the Appendix.
  154.  
  155.    In the X.400 context P_Mul is to be implemented within an MTA. A
  156.    sample implementation has been implemented using the X.400 Message
  157.    Handling System package available from ISODE Ltd. In this case two
  158.    channel programs "Multicast_OUT" and "Multicast_IN" have been
  159.    implemented and integrated. "Multicast_OUT" handles the sending of
  160.    messages to the multicast connected neighbour MTAs. "Multicast_IN"
  161.    handles the incoming messages from the multicast connected neighbour
  162.    MTAs.  These channels play the role of the 'Higher Management
  163.  
  164.  
  165.  
  166. Copeland/Riechmann         Expires March 1998                   [Page 3]
  167.  
  168. INTERNET-DRAFT                                            September 1997
  169.  
  170.  
  171.    Functions' mentioned in following chapters.
  172.  
  173.  
  174. 3. Protocol Data Units (PDU)
  175.  
  176.    The number of PDUs used by P_Mul is mainly determined by the fact
  177.    that this protocol should also be suited for communication under
  178.    EMCON condition, which is understood as only one sided communication.
  179.    In this case several nodes are able to receive data and not able or
  180.    allowed to acknowledge them. Such a restriction can exist for a long
  181.    period of time (e.g. hours, days).  This restriction has resulted in,
  182.    that P_Mul uses only four different PDUs ("Address_PDU", "Data_PDU",
  183.    "ACK_PDU" and "Discard_Message_PDU"). Other PDUs for instance as
  184.    defined for RMP like "Recovery Packet" or "Alarm Packet" and others
  185.    are not useful in this context.
  186.  
  187.    All PDUs are sent using the UDP protocol and multicast addressing.
  188.  
  189. 3.1. Address_PDU
  190.  
  191.    This PDU and the ACK_PDU (see below) govern the flow control of P_Mul
  192.    packets. As P_Mul has to observe a maximum PDU_size and as the number
  193.    of Destination_Entries has no maximum value limitation, it is
  194.    necessary to be able to split the total addressing information into
  195.    more than one Address_PDU. To distinguish between the first, middle,
  196.    or last Address_PDU the MAP field ("More Address_PDUs") is used.
  197.  
  198.  
  199.         0                   1                   2                   3
  200.         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
  201.        +-------------------------------+---------------+---+-----------+
  202.        |         Length_of_PDU         |   Priority    |MAP| PDU_Type  |
  203.        +-------------------------------+---------------+---+-----------+
  204.        |     Total_Number_of_PDUs      |            Checksum           |
  205.        +-------------------------------+-------------------------------+
  206.        |                           Source_ID                           |
  207.        +---------------------------------------------------------------+
  208.        |                       Message_ID (MSID)                       |
  209.        +---------------------------------------------------------------+
  210.        |                          Expiry_Time                          |
  211.        +---------------------------------------------------------------+
  212.        |                  Destinations (variable length)               |
  213.        :                                                               :
  214.        |                                                               |
  215.        +---------------------------------------------------------------+
  216.  
  217.  
  218.  
  219.  
  220.  
  221.  
  222. Copeland/Riechmann         Expires March 1998                   [Page 4]
  223.  
  224. INTERNET-DRAFT                                            September 1997
  225.  
  226.  
  227.  
  228.        Destinations:
  229.  
  230.         0                   1                   2                   3
  231.         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
  232.        +-------------------------------+-------------------------------+
  233.        | Count_of_Destination_Entries  |      Length_of_DES_Key        |
  234.        +---------------------------------------------------------------+
  235.        |          List_of_Destination_Entries (variable length)        |
  236.        :                                                               :
  237.        |                                                               |
  238.        +---------------------------------------------------------------+
  239.  
  240.  
  241.        One Destination_Entry:
  242.  
  243.         0                   1                   2                   3
  244.         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
  245.        +---------------------------------------------------------------+
  246.        |                        Destination_ID                         |
  247.        +---------------------------------------------------------------+
  248.        |                    Message_Sequence_Number                    |
  249.        +---------------------------------------------------------------+
  250.        |                   DES_Key (variable length)                   |
  251.        :                                                               :
  252.        |                                                               |
  253.        +---------------------------------------------------------------+
  254.  
  255.  
  256.    Explanations
  257.  
  258.    Length_of_PDU:
  259.         The field (2 octets) indicates the total number of octets within
  260.         this PDU.
  261.  
  262.    Priority:
  263.         This 1-octet field enables the sending MTA to inform the other
  264.         MTAs that at the sending MTA there exists at least one message
  265.         with the denoted priority (for further study). The value 0
  266.         denotes the highest priority.
  267.  
  268.    MAP: This 2-bit field specifies whether this Address_PDU is a first
  269.         or a middle or a last one.
  270.  
  271.         The high order bit is set to
  272.          '0': This is the first one of a set of Address_PDUs.
  273.          '1': This is NOT the first one of a set of Address_PDUs.
  274.  
  275.  
  276.  
  277.  
  278. Copeland/Riechmann         Expires March 1998                   [Page 5]
  279.  
  280. INTERNET-DRAFT                                            September 1997
  281.  
  282.  
  283.         The low order bit is set to
  284.          '0': This is the last one of a set of Address_PDUs.
  285.          '1': This is NOT the last one of a set of Address_PDUs.
  286.  
  287.         In the case both bits are set to zero, only one Address_PDU
  288.         exists.
  289.  
  290.    PDU_Type:
  291.         This 6-bit field specifies the type of the actual PDU. PDU_Type
  292.         x'02' denotes an Address_PDU.
  293.  
  294.    Total_Number_of_PDUs:
  295.         These 2 octets hold the total number of Data_PDUs of the
  296.         message.
  297.  
  298.    Checksum:
  299.         The checksum will be built by using one of the currently
  300.         available checksum algorithms and is calculated over the rest of
  301.         this PDU.  A sample implementation of the Fletcher algorithm can
  302.         be found in the Appendix.
  303.  
  304.    Source_ID:
  305.         This field holds the ID of the sender of this Address_PDU. This
  306.         ID must be unique for the actual multicast network. As an
  307.         example the Internet address of the specific multicast interface
  308.         of the sending MTA node could be used.
  309.  
  310.    Message_ID:
  311.         MSID is a unique identifier built within the scope of Source_ID
  312.         by the transmitter (e.g. seconds since 00:00:00 1.1.1970 - Unix
  313.         Time -).
  314.  
  315.    Expiry_Time:
  316.         This is the expiry time of the message. This value is to be set
  317.         as a number of seconds since 00:00:00 1.1.1970 - Unix Time -,
  318.         which is derived from the Latest_Delivery_Time of the
  319.         corresponding X.400 message and/or by a predefined value. This
  320.         entry gives the chance for transmitters and receivers of a
  321.         message to decide, when a message entry is outdated and can be
  322.         removed from the processing lists.
  323.  
  324.    Destinations:
  325.         This is a variable length field containing all receivers, their
  326.         message sequence information and as an option, if
  327.         confidentiality has been implemented and is needed, a randomly
  328.         chosen DES_Key, which is encrypted with the public key of each
  329.         receiving site.
  330.  
  331.  
  332.  
  333.  
  334. Copeland/Riechmann         Expires March 1998                   [Page 6]
  335.  
  336. INTERNET-DRAFT                                            September 1997
  337.  
  338.  
  339.    Count_of_Destination_Entries:
  340.         The first 2 octets of this "Destinations" substructure of the
  341.         PDU denote the number of destination entries. Each is formed by
  342.         the Destination_ID, a message sequence number and eventually an
  343.         DES_Key being encoded by the public key owned by this
  344.         Destination_ID designated receiver.
  345.  
  346.    Length_of_DES_Key:
  347.         These 2 octets specify the length of the public key encoded
  348.         "DES_Key", which is 0, if confidentiality is not used.
  349.  
  350.    List_of_Destination_Entries:
  351.         This entry is an array of destination entries. Its dimension is
  352.         specified within the above mentioned
  353.         "Count_of_Destination_Entries".
  354.  
  355.    Destination_ID:
  356.         This field holds an identifier uniquely identifying a receiving
  357.         MTA on the actual multicast network. As an example the Internet
  358.         address of the receiving MTA node could be used.
  359.  
  360.    Message_Sequence_Number:
  361.         This entry holds a message sequence number, which is unique for
  362.         the sender/receiver pair denoted by Source_ID and
  363.         Destination_ID. This sequence number will be generated by
  364.         transmitter consecutively with no leaks and is used by each
  365.         receiver to detect message loss.
  366.  
  367.    DES_Key:
  368.         In case of confidential transfer of Data_PDUs the data portions
  369.         will be encoded by a symmetric encryption algorithm. The
  370.         symmetric key, which is the same for all receiving MTAs, will be
  371.         asymmetrically encoded by the public key of each receiving MTA
  372.         and transmitted within this field. Each receiving MTA can decode
  373.         its "own" key information by using its private key. The key for
  374.         the symmetric encryption should be valid for the total
  375.         transmission of one message and will be generated randomly.
  376.  
  377. 3.2. Data_PDU
  378.  
  379.    This PDU holds essential information such as the unique identifier of
  380.    the message, the position of this Data_PDU within the ordered set of
  381.    all Data_PDUs and one fragment of the total message.
  382.  
  383.  
  384.  
  385.  
  386.  
  387.  
  388.  
  389.  
  390. Copeland/Riechmann         Expires March 1998                   [Page 7]
  391.  
  392. INTERNET-DRAFT                                            September 1997
  393.  
  394.  
  395.  
  396.         0                   1                   2                   3
  397.         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
  398.        +-------------------------------+---------------+---+-----------+
  399.        |         Length_of_PDU         |   Priority    |   | PDU_Type  |
  400.        +-------------------------------+---------------+---+-----------+
  401.        |         Number_of_PDU         |            Checksum           |
  402.        +-------------------------------+-------------------------------+
  403.        |                           Source_ID                           |
  404.        +---------------------------------------------------------------+
  405.        |                       Message_ID (MSID)                       |
  406.        +---------------------------------------------------------------+
  407.        |              Fragment of DATA (variable length)               |
  408.        :                                                               :
  409.        |                                                               |
  410.        +---------------------------------------------------------------+
  411.  
  412.  
  413.    Explanations
  414.  
  415.    Length_of_PDU:
  416.         The field (2 octets) indicates the total number of octets within
  417.         this PDU.
  418.  
  419.    Priority:
  420.         This 1-octet field enables the sending MTA to inform the other
  421.         MTAs that at the sending MTA there exists at least one message
  422.         with the denoted priority (for further study). The value 0
  423.         denotes the highest priority.
  424.  
  425.    PDU_Type:
  426.         This 6-bit field specifies the type of the actual PDU. PDU_Type
  427.         x'00' denotes a Data_PDU.
  428.  
  429.    Number_of_PDU:
  430.         This value offers the information where to place this message
  431.         fragment into the whole message.
  432.  
  433.    Checksum:
  434.         The checksum will be built by using one of the currently
  435.         available checksum algorithms and is calculated over the rest of
  436.         this PDU.  A sample implementation of the Fletcher algorithm can
  437.         be found in the Appendix.
  438.  
  439.    Source_ID:
  440.         This field holds the ID of the sender of this Data_PDU and is
  441.         equivalent to the Source_ID within the corresponding
  442.         Address_PDU. This ID must be unique for the actual multicast
  443.  
  444.  
  445.  
  446. Copeland/Riechmann         Expires March 1998                   [Page 8]
  447.  
  448. INTERNET-DRAFT                                            September 1997
  449.  
  450.  
  451.         network. As an example the Internet address of the specific
  452.         multicast interface of the sending MTA node could be used.
  453.  
  454.    Message_ID:
  455.         MSID is a unique identifier built within the scope of Source_ID
  456.         by Multicast_OUT (e.g. seconds since 00:00:00 1.1.1970 - Unix
  457.         Time -).
  458.  
  459.    Fragment
  460.         This portion of the Data_PDU holds the message or only fragments
  461.         of it.
  462.  
  463. 3.3. Discard_Message_PDU
  464.  
  465.    This PDU is used to inform the receiving MTAs, that the transfer of a
  466.    specific message has been terminated and no further PDU of this
  467.    message will be transmitted. Such a situation can occur because of
  468.    different reasons like hardware error or message outdating. Those
  469.    PDUs already received shall be forgotten by the receiving MTAs. In
  470.    this case the sending MTA shall generate a Non-Delivery Report.
  471.  
  472.  
  473.         0                   1                   2                   3
  474.         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
  475.        +-------------------------------+---------------+---+-----------+
  476.        |         Length_of_PDU         |   Priority    |   | PDU_Type  |
  477.        +-------------------------------+---------------+---+-----------+
  478.        |           not_used            |            Checksum           |
  479.        +-------------------------------+-------------------------------+
  480.        |                           Source_ID                           |
  481.        +---------------------------------------------------------------+
  482.        |                       Message_ID (MSID)                       |
  483.        +---------------------------------------------------------------+
  484.  
  485.  
  486.    Explanations
  487.  
  488.    Length_of_PDU:
  489.         The field (2 octets) indicates the total number of octets within
  490.         this PDU.
  491.  
  492.    Priority:
  493.         This 1-octet field enables the sending MTA to inform the other
  494.         MTAs that at the sending MTA there exists at least one message
  495.         with the denoted priority (for further study). The value 0
  496.         denotes the highest priority.
  497.  
  498.    PDU_Type:
  499.  
  500.  
  501.  
  502. Copeland/Riechmann         Expires March 1998                   [Page 9]
  503.  
  504. INTERNET-DRAFT                                            September 1997
  505.  
  506.  
  507.         This 6-bit field specifies the type of the actual PDU. PDU_Type
  508.         x'03' denotes a Discard_Message_PDU.
  509.  
  510.    not_used:
  511.         This field is currently not used (reserved for future use).
  512.  
  513.    Checksum:
  514.         The checksum will be built by using one of the currently
  515.         available checksum algorithms and is calculated over the rest of
  516.         this PDU.  A sample implementation of the Fletcher algorithm can
  517.         be found in the Appendix.
  518.  
  519.    Source_ID:
  520.         This field holds the ID of the sender of this
  521.         Discard_Message_PDU and is equivalent to the Source_ID within
  522.         the corresponding Address_PDU. This ID must be unique for the
  523.         actual multicast network. As an example the Internet address of
  524.         the specific multicast interface of the sending MTA node could
  525.         be used.
  526.  
  527.    Message_ID:
  528.         MSID is a unique identifier built within the scope of Source_ID
  529.         by the transmitter (e.g. seconds since 00:00:00 1.1.1970 - Unix
  530.         Time -).
  531.  
  532. 3.4. ACK_PDU
  533.  
  534.    This PDU is generated by a receiving MTA identified by the
  535.    Source_ID_of_ACK_Sender and is used to inform the sending MTA about
  536.    the receive status of one or more messages. This information is
  537.    composed within one or more entries of the List_of_ACK_Info_Entries.
  538.    Each of these entries holds a message identifier (Source_ID and
  539.    Message_ID) and a List_of_Missing_Data_PDUs, which may contain a list
  540.    of those Data_PDUs not yet received. If this list is empty, the
  541.    message identified by Source_ID and Message_ID has been completely
  542.    received by this receiving MTA.
  543.  
  544.  
  545.  
  546.  
  547.  
  548.  
  549.  
  550.  
  551.  
  552.  
  553.  
  554.  
  555.  
  556.  
  557.  
  558. Copeland/Riechmann         Expires March 1998                  [Page 10]
  559.  
  560. INTERNET-DRAFT                                            September 1997
  561.  
  562.  
  563.  
  564.         0                   1                   2                   3
  565.         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
  566.        +-------------------------------+---------------+---+-----------+
  567.        |         Length_of_PDU         |   Priority    |   | PDU_Type  |
  568.        +-------------------------------+---------------+---+-----------+
  569.        |           not_used            |            Checksum           |
  570.        +-------------------------------+-------------------------------+
  571.        |                     Source_ID_of_ACK_Sender                   |
  572.        +---------------------------------------------------------------+
  573.        |                  Dest_ACK_Info (variable length)              |
  574.        :                                                               :
  575.        |                                                               |
  576.        +---------------------------------------------------------------+
  577.  
  578.  
  579.        Dest_ACK_Info:
  580.  
  581.         0                   1                   2                   3
  582.         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
  583.        +-------------------------------+-------------------------------+
  584.        |   Count_of_ACK_Info_Entries   |   Length_of_ACK_Info_Entry    |
  585.        +-------------------------------+-------------------------------+
  586.        |           List_of_ACK_Info_Entries (variable Length)          |
  587.        :                                                               :
  588.        |                                                               |
  589.        +---------------------------------------------------------------+
  590.  
  591.  
  592.        One ACK_Info_Entry:
  593.  
  594.         0                   1                   2                   3
  595.         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
  596.        +-------------------------------+-------------------------------+
  597.        |                           Source_ID                           |
  598.        +---------------------------------------------------------------+
  599.        |                       Message_ID (MSID)                       |
  600.        +-------------------------------+-------------------------------+
  601.        |   List_of_Missing_Data_PDUs   |
  602.        :                               :
  603.        |                               |
  604.        +-------------------------------+
  605.  
  606.  
  607.  
  608.  
  609.  
  610.  
  611.  
  612.  
  613.  
  614. Copeland/Riechmann         Expires March 1998                  [Page 11]
  615.  
  616. INTERNET-DRAFT                                            September 1997
  617.  
  618.  
  619.    Explanations
  620.  
  621.    Length_of_PDU:
  622.         The field (2 octets) indicates the total number of octets within
  623.         this PDU.
  624.  
  625.    Priority:
  626.         This 1-octet field enables the sending MTA to inform the other
  627.         MTAs that at the sending MTA there exists at least one message
  628.         with the denoted priority (for further study). The value 0
  629.         denotes the highest priority.
  630.  
  631.    PDU_Type:
  632.         This 6-bit field specifies the type of the actual PDU. PDU_Type
  633.         x'01' denotes an ACK_PDU.
  634.  
  635.    not_used:
  636.         This field is currently not used (reserved for future use).
  637.  
  638.    Checksum:
  639.         The checksum will be built by using one of the currently
  640.         available checksum algorithms and is calculated over the rest of
  641.         this PDU.  A sample implementation of the Fletcher algorithm can
  642.         be found in the Appendix.
  643.  
  644.    Source_ID_of_ACK_Sender:
  645.         This field holds the ID of the sender of this ACK_PDU and is
  646.         equivalent to one of the Destination_IDs described for the
  647.         Address_PDU. This ID must be unique for the actual multicast
  648.         network. As an example the Internet address of the specific
  649.         multicast interface of the ACK_PDU sending MTA node could be
  650.         used.
  651.  
  652.    Dest_ACK_Info:
  653.         This is a variable field containing ACK_Info_Entries for one or
  654.         more message sending nodes on the multicast network. Each
  655.         ACK_Info_Entry consists of the corresponding Source_ID of the
  656.         message sending node, the message_ID and the list of those
  657.         Data_PDUs not yet received by the ACK_PDU generating receiver.
  658.  
  659.    Count_of_ACK_Info_Entries:
  660.         This field contains the number of ACK_Info_Entries. As long as
  661.         there is only one active sender, we have only one
  662.         ACK_Info_Entry, but it is assumed, that we can have more than
  663.         one message sending node on the same multicast network.
  664.  
  665.    Length_of_ACK_Info_Entry:
  666.         This field holds the octet length of each ACK_Info_Entry.
  667.  
  668.  
  669.  
  670. Copeland/Riechmann         Expires March 1998                  [Page 12]
  671.  
  672. INTERNET-DRAFT                                            September 1997
  673.  
  674.  
  675.         Having this field, the List_of_Missing_Data_PDUs is adaptable
  676.         (in length) to the quality of the transmission (see
  677.         "List_of_Missing_Data_PDUs" below). The maximum number of
  678.         entries within this list is defined as
  679.                     M = (Length_of_ACK_Info_Entry - 8) / 2.
  680.  
  681.    List_of_ACK_Info_Entries
  682.         This entry is an array of ACK_Info_Entries. Its dimension is
  683.         specified within "Count_of_ACK_Info_Entries".
  684.  
  685.    Source_ID:
  686.         This field holds the identifier of the message sending node. It
  687.         is equivalent to "Source_ID" within the description of the
  688.         Address_PDU, Data_PDU or Discard_Message_PDU.
  689.  
  690.    Message_ID:
  691.         MSID is a unique identifier built by the sender (e.g. seconds
  692.         since 00:00:00 1.1.1970 - Unix Time -). It is equivalent to
  693.         "Message_ID" of the description of the Address_PDU.
  694.  
  695.    List_of_Missing_Data_PDUs:
  696.         This field contains the list of the order numbers of those
  697.         Data_PDUs definitely sent by the sender but not yet received at
  698.         the receiver generating the current ACK_PDU. The maximum number
  699.         of entries in this list is defined by M (see
  700.         "Length_of_ACK_Info_Entry" above).
  701.  
  702.         If the list holds less than M entries, then the first free entry
  703.         has to be set to 0 to mark the end of the list. If all Data_PDUs
  704.         have been acknowledged, the first entry has to be set to 0.
  705.  
  706.    Whereas normally an ACK_PDU will only signal the receiving status
  707.    ("ACK") of one MSID of Destination_ID, especially at the end of an
  708.    EMCON period, one ACK_PDU may contain more "ACKs" to one or more
  709.    MSIDs of one or more Destination_IDs.
  710.  
  711.  
  712. 4. Messaging Procedures
  713.  
  714.    The following describes the messaging procedures to be employed
  715.    between a transmitting MTA and one or more receiving MTAs either in
  716.    the non-EMCON or EMCON mode of operation using the P_Mul multicast
  717.    protocol. The following procedures shall be implemented for every
  718.    message transmitted. The procedures are divided into three main
  719.    areas, namely:
  720.  
  721.        * Transmission and Re-transmission
  722.        * Reception
  723.  
  724.  
  725.  
  726. Copeland/Riechmann         Expires March 1998                  [Page 13]
  727.  
  728. INTERNET-DRAFT                                            September 1997
  729.  
  730.  
  731.        * Acknowledgement
  732.  
  733. 4.1. Transmission and Re-transmission of a Message
  734.  
  735.    An MTA shall initiate the transmission of a message by firstly
  736.    transmitting an Address_PDU containing a list of all the MTAs that
  737.    are to receive the message. The transmitting MTA shall be made aware,
  738.    by a 'Higher Management Function', which of the receiving MTAs are in
  739.    the non-EMCON and EMCON mode of operation. The transmitting MTA
  740.    shall, based on the supplied mode of operation information, create a
  741.    list of non-EMCON receiving MTAs, from which it shall expect to
  742.    receive ACK_PDUs.
  743.  
  744.    On completion of transmission of the Address_PDU the transmitting MTA
  745.    shall proceed with the transmission of the Data_PDU(s), with the
  746.    Message_ID field set equal to the Message_ID field of the associated
  747.    Address_PDU. On completion of transmission of the last Data_PDU of a
  748.    message the transmitting MTA shall initialise a "Transmitter
  749.    Expiry_Time Timer" and an "EMCON Re-transmission Counter"
  750.    (EMCON_RTC), if one or more of the receiving MTAs is in the EMCON
  751.    mode, and enter the non-EMCON or EMCON Re-transmission mode (see
  752.    para. 4.1.3 resp. 4.1.4).
  753.  
  754. 4.1.1. Transmitter Expiry_Time Timer
  755.  
  756.    This timer indicates the time remaining before the contents of the
  757.    transmit message is considered invalid. It shall be initialised in
  758.    accordance with the value transmitted in the Expiry_Time field of the
  759.    Address_PDU.
  760.  
  761.    If, in the event that one or more of the receiving MTAs have not
  762.    acknowledged receipt of the complete message, this timer expires, the
  763.    transmitting MTA shall transmit a Discard_Message_PDU with the
  764.    Message_ID field set equal to the Message_ID field in the associated
  765.    Address_PDU and Data_PDUs.
  766.  
  767.    If, after having transmitted a Discard_Message_PDU, the transmitting
  768.    MTA receives an ACK_PDU indicating only partial receipt of the
  769.    message, it shall re-transmit the Discard_Message_PDU.
  770.  
  771.    If, after having transmitted a Discard_Message_PDU, the transmitting
  772.    MTA receives an ACK_PDU indicating receipt of the complete message,
  773.    it shall disregard the ACK_PDU.
  774.  
  775.    If all the receiving MTAs addressed in the Destination part of the
  776.    Address_PDU acknowledge the receipt of the complete message before
  777.  
  778.  
  779.  
  780.  
  781.  
  782. Copeland/Riechmann         Expires March 1998                  [Page 14]
  783.  
  784. INTERNET-DRAFT                                            September 1997
  785.  
  786.  
  787.    this timer expires, the timer shall be stopped.
  788.  
  789. 4.1.2. EMCON Re-transmission Counter
  790.  
  791.    This counter (EMCON_RTC) indicates the maximum number of times the
  792.    complete message may be re-transmitted while in the EMCON Re-
  793.    transmission mode. It shall be set to a value based on such
  794.    parameters as the priority, etc. of the message.
  795.  
  796. 4.1.3. Non-EMCON Re-transmission
  797.  
  798.    The transmitting MTA shall enter this mode when one or more of the
  799.    receiving MTAs is in the non-EMCON mode. On entering this mode the
  800.    transmitting MTA shall either:
  801.  
  802.    a.   having transmitted the last Data_PDU, initialise the "Ack Re-
  803.         transmission Timer" or
  804.  
  805.    b.   having left the "EMCON Re-transmission" mode, re-transmit all
  806.         the indicated missing Data_PDUs and then initialise the "Ack
  807.         Re-transmission Timer".
  808.  
  809. 4.1.3.1. Ack Re-transmission Timer
  810.  
  811.    This timer shall be initialised when one or more of the receiving
  812.    MTAs are in the non-EMCON mode. The duration of this timer shall be
  813.    derived from the maximum round trip delay plus a safeguard.
  814.  
  815.    If, in the event all the receiving MTAs in the non-EMCON mode respond
  816.    with an ACK_PDU before this timer expires, the transmitting MTA shall
  817.    either:
  818.  
  819.    a.   in the event that one or more of the ACK_PDUs indicate that a
  820.         receiving MTA is missing Data_PDUs, re-transmit all the
  821.         indicated missing Data_PDUs accompanied by a possibly updated
  822.         Address_PDU and re-initialise the timer and remain in the "Non-
  823.         EMCON Re-transmission" mode or
  824.  
  825.    b.   in the event that all the ACK_PDUs indicate that the complete
  826.         message has been received, stop the timer. If, at this stage
  827.         there are receiving MTAs in the EMCON mode the transmitting MTA
  828.         shall enter the EMCON Re-transmission mode.
  829.  
  830.    If one or more of the receiving MTAs in the non-EMCON mode does not
  831.    respond with an ACK_PDU indicating partial or complete reception of
  832.    the message, this timer expires, the transmitting MTA shall either:
  833.  
  834.    a.   in the event that it has not received a previous ACK_PDU from
  835.  
  836.  
  837.  
  838. Copeland/Riechmann         Expires March 1998                  [Page 15]
  839.  
  840. INTERNET-DRAFT                                            September 1997
  841.  
  842.  
  843.         the receiving MTA, re-transmit the complete message and re-
  844.         initialise the timer or
  845.  
  846.    b.   in the event that it has received a previous ACK_PDU from the
  847.         receiving MTA, only re-transmit the possibly updated Address_PDU
  848.         and all the previously indicated missing Data_PDUs and re-
  849.         initialise the timer.
  850.  
  851. 4.1.3.2. Receipt of Message Complete ACK_PDU
  852.  
  853.    When a transmitting MTA receives an ACK_PDU from a non-EMCON or EMCON
  854.    receiving MTA indicating that it has received the complete message,
  855.    it shall transmit an acknowledgement to this message complete
  856.    ACK_PDU. The acknowledgement shall be done in the form of an
  857.    Address_PDU with the destination address of the associated receiving
  858.    MTA removed from the List_of_Destination_Entries field. Any
  859.    subsequent re-transmission of the relevant message will be sent with
  860.    the Destination_Entry of the receiving MTA removed from the
  861.    List_of_Destination_Entries field in the Address_PDU.
  862.  
  863. 4.1.4. EMCON Re-transmission
  864.  
  865.    The transmitting MTA shall enter this mode as soon as all receiving
  866.    MTAs are in the EMCON mode. On entering this mode the transmitting
  867.    MTA shall initialise the "EMCON Re-transmission Timer" (EMCON_RTI).
  868.  
  869. 4.1.4.1. EMCON Re-transmission Timer
  870.  
  871.    This timer (EMCON_RTI) shall be initialised when all the receiving
  872.    MTAs are in the EMCON mode. The duration of this timer will be based
  873.    on such parameters as the priority, etc. of the message.
  874.  
  875.    If this timer expires, which means that since the last EMCON Re-
  876.    transmission none of the receiving MTAs in the EMCON mode has entered
  877.    the non-EMCON mode - by sending one or more ACK_PDUs -, and the
  878.    "EMCON Re-transmission Counter" has not reached its maximum count,
  879.    the transmitting MTA shall re-transmit the Address_PDU and all
  880.    Data_PDUs not already acknowledged. It shall re-initialise this timer
  881.    and increment the "EMCON Re-transmission Counter" and the message
  882.    sending MTA shall wait until either:
  883.  
  884.    a.   one or more of the receiving MTAs in EMCON mode respond with an
  885.         ACK_PDU at which point it shall enter the "Non-EMCON Re-
  886.         transmission" mode or
  887.  
  888.    b.   the "Transmitter Expiry_Time Timer" expires at which point it
  889.         shall transmit a Discard_Message_PDU.
  890.  
  891.  
  892.  
  893.  
  894. Copeland/Riechmann         Expires March 1998                  [Page 16]
  895.  
  896. INTERNET-DRAFT                                            September 1997
  897.  
  898.  
  899.    If, in the event one or more of the receiving MTAs in the EMCON mode
  900.    responds, by entering the non-EMCON mode, with an ACK_PDU indicating
  901.    partial or complete reception of the message, before this timer
  902.    expires, the transmitting MTA shall stop the timer and enter the
  903.    "Non-EMCON Re-transmission" mode (see para. 4.1.3).
  904.  
  905. 4.2. Reception of a Message
  906.  
  907.    The "Reception of a Message" mode shall be initiated when the
  908.    receiving MTA receives either an Address_PDU or Data_PDU.
  909.  
  910. 4.2.1. Receipt of an Address_PDU
  911.  
  912.    On receipt of an Address_PDU the receiving MTA shall first check
  913.    whether the Address_PDU has already been received.
  914.  
  915.    If the Address_PDU has already been received the receiving MTA shall:
  916.  
  917.    a.   if its own ID exists in the List_of_Destination_Entries and it
  918.         has previously sent a message complete ACK_PDU for this message,
  919.         re-transmit the message complete ACK_PDU and discard the
  920.         Address_PDU else
  921.  
  922.    b.   discard the Address_PDU.
  923.  
  924.    If the Address_PDU has not been previously received the receiving MTA
  925.    shall:
  926.  
  927.    a.   if its own ID does not exist in the List_of_Destination_Entries,
  928.         check whether it has previously received any Data_PDUs
  929.         associated with this Address_PDU (i.e. same Source_ID and
  930.         Message_ID) and discard the Address_PDU. If there exists
  931.         Data_PDUs associated with this Address_PDU, the receiving MTA
  932.         shall discard these Data_PDUs.
  933.  
  934.    b.   if its own ID exists in the List_of_Destination_Entries
  935.         determine whether it has previously received any Data_PDUs
  936.         associated with this Address_PDU.
  937.  
  938.    If there exists no Data_PDUs associated with this Address_PDU, the
  939.    receiving MTA shall create a message entry and await reception of the
  940.    associated Data_PDUs.
  941.  
  942.    If there exists Data_PDUs associated with this Address_PDU, the
  943.    receiving MTA shall update the status of the Data_PDU entry (see
  944.    para. 4.2.2) to a message entry. In addition the receiving MTA shall
  945.    stop the "Delete-Data_PDUs Timer" (see para. 4.2.2.1) and initialise
  946.    the "Receiver Expiry_Time Timer". The receiving MTA shall then
  947.  
  948.  
  949.  
  950. Copeland/Riechmann         Expires March 1998                  [Page 17]
  951.  
  952. INTERNET-DRAFT                                            September 1997
  953.  
  954.  
  955.    determine whether to enter the "Acknowledgement of a Message" mode
  956.    (see para. 4.2.3).
  957.  
  958. 4.2.1.1. Receiver Expiry_Time Timer
  959.  
  960.    This timer indicates the time remaining before the contents of the
  961.    received message is considered invalid. It shall be initialised in
  962.    accordance with the value received in the Expiry_Time field of the
  963.    Address_PDU.
  964.  
  965.    If this timer expires and the receiving MTA has not received all the
  966.    Data_PDUs associated with a message, the receiving MTA shall discard
  967.    the associated Data_PDUs and Address_PDU.
  968.  
  969. 4.2.2. Receipt of a Data_PDU
  970.  
  971.    On receipt of a Data_PDU the receiving MTA shall first check whether
  972.    the Data_PDU has already been received.
  973.  
  974.    If the Data_PDU has already been received the receiving MTA shall:
  975.  
  976.    a.   if the receiving MTA has not received a duplicate of the
  977.         associated Address_PDU (see para. 4.2.1) and it has previously
  978.         sent a message complete ACK_PDU for this message, re-transmit
  979.         the message complete ACK_PDU and discard the Data_PDU else
  980.  
  981.    b.   discard the Data_PDU.
  982.  
  983.    If the Data_PDU has not been previously received, the receiving MTA
  984.    shall check whether it has received the associated Address_PDU.
  985.  
  986.    If the associated Address_PDU has been received and a message entry
  987.    exists the receiving MTA shall update the status of the message entry
  988.    and determine whether to enter the "Acknowledgement of a Message"
  989.    mode (see para. 4.2.3). If the associated Address_PDU has been
  990.    received but no message entry exists the receiving MTA shall discard
  991.    the Data_PDU.
  992.  
  993.    If the associated Address_PDU has not been received the receiving MTA
  994.    shall check whether there exists a Data_PDU entry associated with the
  995.    Source_ID and Message_ID contents of the received Data_PDU.
  996.  
  997.    If there exists no Data_PDU entry associated with this Data_PDU, the
  998.    receiving MTA shall create a Data_PDU entry and await reception of
  999.    the associated Address_PDU. In addition the receiving MTA shall
  1000.    initialise a "Delete Data_PDUs Timer". If there exists a Data_PDU
  1001.    entry associated with this Data_PDU, the receiving MTA shall update
  1002.    the status of the Data_PDU entry and await reception of the
  1003.  
  1004.  
  1005.  
  1006. Copeland/Riechmann         Expires March 1998                  [Page 18]
  1007.  
  1008. INTERNET-DRAFT                                            September 1997
  1009.  
  1010.  
  1011.    associated Address_PDU.
  1012.  
  1013. 4.2.2.1. Delete Data_PDUs Timer
  1014.  
  1015.    This timer indicates the time remaining before the Data_PDUs in a
  1016.    Data_PDU entry are considered to be no longer valid and can therefore
  1017.    be discarded. It shall be initialised to a value based on such
  1018.    parameters as TBD.
  1019.  
  1020.    If, in the event the receiving MTA does not receive the Address_PDU
  1021.    or a Discard_Message_PDU associated with the Data_PDUs in the
  1022.    Data_PDU entry, this timer expires, the receiving MTA shall discard
  1023.    all Data_PDUs.
  1024.  
  1025. 4.2.3. Entry to "Acknowledgement of a Message"
  1026.  
  1027.    Having updated the status of a message entry, the receiving MTA
  1028.    shall:
  1029.  
  1030.    a.   if in the non-EMCON mode, check whether the last Data_PDU of the
  1031.         message has been received or there are M (see para. 3.4) missing
  1032.         Data_PDUs. In the event that either is true the receiving MTA
  1033.         shall enter the "Acknowledgement of a Message" mode (see para.
  1034.         4.3). In the event neither of the above is true the receiving
  1035.         MTA shall remain in the "Reception of a Message" mode or
  1036.  
  1037.    b.   if in the EMCON mode, check whether all the Data_PDUs for the
  1038.         message have been received. If there are missing Data_PDUs it
  1039.         shall remain in the "Reception of a Message" mode. If all the
  1040.         Data_PDUs have been received the message shall be tagged as
  1041.         complete and ready for acknowledgement when the non-EMCON mode
  1042.         is entered. The completed message can then be passed up to the
  1043.         'Higher Layer Application'. The receiving MTA shall remain in
  1044.         the "Reception of a Message" mode.
  1045.  
  1046. 4.2.4. Receipt of a Discard_Message_PDU
  1047.  
  1048.    In the event that a receiving MTA receives a Discard_Message_PDU, it
  1049.    shall discard all the PDUs (i.e. data and address) associated with
  1050.    the message identified by the combination of the Source_ID and
  1051.    Message_ID fields in the Discard_Message_PDU. It shall also stop any
  1052.    associated timers.
  1053.  
  1054. 4.3. Acknowledgement of a Message
  1055.  
  1056.    The "Acknowledgement of a Message" mode shall only be entered by a
  1057.    receiving MTA that is in the non-EMCON mode of operation. The
  1058.    "Acknowledgement of a Message" mode procedures shall be dependent on
  1059.  
  1060.  
  1061.  
  1062. Copeland/Riechmann         Expires March 1998                  [Page 19]
  1063.  
  1064. INTERNET-DRAFT                                            September 1997
  1065.  
  1066.  
  1067.    whether the receiving MTA received the messages in the non-EMCON
  1068.    mode, (see para. 4.3.1) or in the EMCON mode, (see para. 4.3.2).
  1069.  
  1070.    To avoid the problem of ACK implosion on the message transmitting
  1071.    site, in the event that the receiving MTA has several ACK_PDUs to
  1072.    transmit, each transmission of an ACK_PDU should be delayed by a
  1073.    randomly determined period of time interval.
  1074.  
  1075. 4.3.1. Receiving MTA in Non-EMCON
  1076.  
  1077.    A receiving MTA shall, if operating in the non-EMCON mode enter the
  1078.    "Acknowledgement of a Message" mode when either the last Data_PDU of
  1079.    a message is received or there are M (see para. 3.4) missing
  1080.    Data_PDUs.
  1081.  
  1082. 4.3.1.1. Last Data_PDU Received
  1083.  
  1084.    If the last Data_PDU of a message has been received, the receiving
  1085.    MTA shall determine whether there are any missing Data_PDUs in the
  1086.    message.
  1087.  
  1088. 4.3.1.2. Missing Data_PDUs
  1089.  
  1090.    If there are missing Data_PDUs the receiving MTA shall:
  1091.  
  1092.    a.   if no ACK_PDU associated with this message has been previously
  1093.         transmitted, transmit an ACK_PDU listing which Data_PDUs are
  1094.         missing and return to the "Reception of a Message" mode or
  1095.  
  1096.    b.   if an ACK_PDU associated with this message had been previously
  1097.         transmitted, the receiving MTA shall return to the "Reception of
  1098.         a Message" mode.
  1099.  
  1100. 4.3.1.3. Received Complete Message
  1101.  
  1102.    If there are no missing Data_PDUs the receiving MTA shall transmit an
  1103.    ACK_PDU indicating that the message is complete. In addition it shall
  1104.    stop the "Receiver Expiry_Time Timer" associated with this message.
  1105.    The complete message shall be passed up to the 'Higher Layer
  1106.    Application'. On completion of transmission of the ACK_PDU the
  1107.    receiving MTA shall return to the "Reception of a Message" mode.
  1108.  
  1109. 4.3.1.4. M Missing Data_PDUs
  1110.  
  1111.    M has been defined as the maximum number of entries within the
  1112.    List_of_Missing_Data_PDUs (see para. 3.4).  It is possible for a
  1113.    message to consists of more than M Data_PDUs, therefore it may be
  1114.    possible for the receiving MTA to be missing M Data_PDUs, without
  1115.  
  1116.  
  1117.  
  1118. Copeland/Riechmann         Expires March 1998                  [Page 20]
  1119.  
  1120. INTERNET-DRAFT                                            September 1997
  1121.  
  1122.  
  1123.    having received the last Data_PDU, therefore:
  1124.  
  1125.    A receiving MTA in the non-EMCON mode shall in the event that it is
  1126.    missing M Data_PDUs from a message, construct and transmit an ACK_PDU
  1127.    listing the M missing Data_PDUs.
  1128.  
  1129.    If the receiving MTA proceeds to miss a further set of M Data_PDUs,
  1130.    it shall transmit a new ACK_PDU listing the further set of M missing
  1131.    Data_PDUs.
  1132.  
  1133.    The receiving MTA shall repeat the procedure of transmitting an
  1134.    ACK_PDU for every further set of M missing Data_PDUs until the last
  1135.    Data_PDU is received.
  1136.  
  1137.    On completion of transmission of every ACK_PDU the receiving MTA
  1138.    shall return to the "Reception of a Message" mode.
  1139.  
  1140. 4.3.2. Receiving MTA leaving EMCON
  1141.  
  1142.    If the receiving MTA is operating in the EMCON mode, it shall enter
  1143.    the "Acknowledgement of a Message" mode, when its mode of operation
  1144.    has changed to the non-EMCON mode. Upon entering the non-EMCON mode
  1145.    it shall determine whether it has received the last Data_PDU of a
  1146.    message.
  1147.  
  1148.    Note: The following procedures are relevant only for those messages
  1149.    (complete or partial) received while in the EMCON mode. All new
  1150.    messages received before the change into the EMCON mode or after the
  1151.    change to the non-EMCON mode of operation shall be acknowledged in
  1152.    accordance with the procedures described in para. 4.3.1.
  1153.  
  1154. 4.3.2.1. Last Data_PDU Received
  1155.  
  1156.    If the last Data_PDU of a message has been received, the receiving
  1157.    MTA shall determine whether there are any missing Data_PDUs in the
  1158.    message.
  1159.  
  1160. 4.3.2.2. Missing Data_PDUs
  1161.  
  1162.    If there are missing Data_PDUs, the receiving MTA shall transmit an
  1163.    ACK_PDU listing denoting, which Data_PDUs are missing, and initialise
  1164.    an associated "ACK_PDU Timer" (see para. 4.3.2.4).
  1165.  
  1166.    If there are N missing Data_PDUs and N > M  the  receiving MTA shall
  1167.    transmit (entier((N-1)/M) + 1) ACK_PDUs in order to indicate the
  1168.    total number of missing Data_PDUs. No ACK_PDU shall indicate more
  1169.    than M missing Data_PDUs,  (see para. 4.3.1.4). The receiving MTA
  1170.    shall initialise an associated "ACK_PDU Timer" with each ACK_PDU
  1171.  
  1172.  
  1173.  
  1174. Copeland/Riechmann         Expires March 1998                  [Page 21]
  1175.  
  1176. INTERNET-DRAFT                                            September 1997
  1177.  
  1178.  
  1179.    transmitted.
  1180.  
  1181.    On completion of transmission of the ACK_PDU(s) the receiving MTA
  1182.    shall then return to the "Reception of a Message" mode.
  1183.  
  1184. 4.3.2.3. Received Complete Message
  1185.  
  1186.    If there are no missing Data_PDUs, (e.g. tagged as complete, see
  1187.    para. 4.2.3), the receiving MTA shall transmit an ACK_PDU indicating
  1188.    that the message is complete and initialise the "ACK_PDU Timer". The
  1189.    receiving MTA shall, if it has not already done so, stop the
  1190.    "Receiver_Expiry_Time Timer" associated with this message and pass
  1191.    the complete message to the 'Higher Layer Application'. The receiving
  1192.    MTA shall return to the "Reception of a Message" mode.
  1193.  
  1194. 4.3.2.4. ACK_PDU Timer
  1195.  
  1196.    The "ACK_PDU Timer" shall be initialised for every ACK_PDU
  1197.    transmitted by a receiving MTA, in the non-EMCON mode, having
  1198.    previously been in the EMCON mode. The duration of the timer shall be
  1199.    derived from the maximum round trip delay plus a safeguard.
  1200.  
  1201.    If the receiving MTA receives a response to a transmitted ACK_PDU
  1202.    from the transmitting MTA in the form of the requested missing
  1203.    Data_PDUs or an Address_PDU, it shall stop the associated "ACK_PDU
  1204.    Timer".
  1205.  
  1206.    If, in the event the receiving MTA does not receive a response to the
  1207.    transmitted ACK_PDU(s) from the transmitting MTA in the form of the
  1208.    requested missing Data_PDUs or an Address_PDU, an "ACK_PDU Timer"
  1209.    expires, the receiving MTA shall re-transmit the associated
  1210.    ACK_PDU(s) and re-initialise the timer.
  1211.  
  1212.  
  1213. 5. Example
  1214.  
  1215.    The following example shall explain, how the PDUs are used between
  1216.    MTAs on a multicast network. This example shall give only an
  1217.    impression, how the protocol works. Therefore the packets are
  1218.    described as a sort of function calls.
  1219.  
  1220.    It is assumed that M0 is the sending MTA, which sends one message to
  1221.    the MTAs M1, M2, M3 and M4. Only M3 and M4 are assumed to be under
  1222.    EMCON. The message length is assumed to be a little larger than the
  1223.    maximum PDU size, which means that the message (DATA) is split into
  1224.    two fragments. Further we assume, that until now M0 had send 99
  1225.    messages to M1, 77 messages to M2, 10 messages to M3 and 14 messages
  1226.    to M4.
  1227.  
  1228.  
  1229.  
  1230. Copeland/Riechmann         Expires March 1998                  [Page 22]
  1231.  
  1232. INTERNET-DRAFT                                            September 1997
  1233.  
  1234.  
  1235.    M0 constructs an Address_PDU and the 2 Data_PDUs. It sends all 3 PDUs
  1236.    to the multicast network.
  1237.  
  1238.      Address_PDU( Source_ID=M0, MSID=9876, TTL=1000, Total_PDUs=2,
  1239.         Dests=( Cnt=4, LDES=0, Dest_ID=((M1,100), (M2,78), (M3,11),
  1240.         (M4,15))))
  1241.  
  1242.      Data_PDU( Source_ID=M0, MSID=9876, PDU_No=1, Data= First N octets
  1243.         of message)
  1244.  
  1245.      Data_PDU( Source_ID=M0, MSID=9876, PDU_No=2, Data= Remaining octets
  1246.         of message)
  1247.  
  1248.    Assuming M1, M2, M3 and M4 will receive the Address_PDU.  M1, M3 and
  1249.    M4 shall receive the Data_PDUs without failures, while M2 shall
  1250.    receive the first Data_PDU incorrectly and the second one correctly.
  1251.    As M3 and M4 are in EMCON mode, they cannot send any ACK_PDU. M1 will
  1252.    send a completion ACK_PDU, while M2 will send an ACK_PDU indicating
  1253.    that the first Data_PDU is missing.
  1254.  
  1255.      ACK_PDU( Source_ID=M1, Dest_ACK_Infos=(Cnt=1, ACK_Info=(M0, 9876,
  1256.         0)))
  1257.  
  1258.      ACK_PDU( Source_ID=M2, Dest_ACK_Infos=(Cnt=1, ACK_Info=(M0, 9876,
  1259.         1,0)))
  1260.  
  1261.    Now M0 has to re-transmit the first part of the message for M2,
  1262.    because M2 marked this PDU as missing. As M0 has received the
  1263.    completion ACK_PDU of M1, M1 is deleted from the Destination_List.
  1264.  
  1265.      Address_PDU( Source_ID=M0, MSID=9876, TTL=1000, Total_PDUs=2,
  1266.         Dests=( Cnt=3, LDES=0, Dest_ID=((M2,78), (M3,11), (M4,15))))
  1267.  
  1268.      Data_PDU( Source_ID=M0, MSID=9876, PDU_No=1, Data= First N octets
  1269.         of message)
  1270.  
  1271.    Assuming that M2 will receive this PDU correctly, it will acknowledge
  1272.    it with the following ACK_PDU.
  1273.  
  1274.      ACK_PDU( Source_ID=M2, Dest_ACK_Infos=(Cnt=1, ACK_Info=(M0, 9876,
  1275.         0)))
  1276.  
  1277.    As M0 has received the completion ACK_PDU of M2, M2 will be deleted
  1278.    from the Destination_List.
  1279.  
  1280.    Supposing that M3 has left the EMCON situation, M3 will send its ACK
  1281.    to M0 as:
  1282.  
  1283.  
  1284.  
  1285.  
  1286. Copeland/Riechmann         Expires March 1998                  [Page 23]
  1287.  
  1288. INTERNET-DRAFT                                            September 1997
  1289.  
  1290.  
  1291.      ACK_PDU( Source_ID=M3, Dest_ACK_Infos=(Cnt=1, ACK_Info=(M0, 9876,
  1292.         0)))
  1293.  
  1294.    Assuming that an EMCON Re-transmission for M4 should take place, M0
  1295.    will re-transmit the total message. As M1, M2 and M3 already have
  1296.    completely acknowledged the message, the Address_PDU will hold only
  1297.    one Destination_ID for M4.
  1298.  
  1299.      Address_PDU( Source_ID=M0, MSID=9876, TTL=1000, Total_PDUs=2,
  1300.         Dests=( Cnt=1, LDES=0, Dest_ID=((M4,15))))
  1301.  
  1302.      Data_PDU( Source_ID=M0, MSID=9876, PDU_No=1, Data= First N octets
  1303.         of message)
  1304.  
  1305.      Data_PDU( Source_ID=M0, MSID=9876, PDU_No=2, Data= Remaining octets
  1306.         of message)
  1307.  
  1308.    Supposing that M4 is still under EMCON and that now the Expiry_Time
  1309.    out of the according Address_PDU has been reached. M0 will send the
  1310.    following sequence of PDUs:
  1311.  
  1312.      Discard_Message_PDU( Source_ID=M0, MSID=9876)
  1313.  
  1314.    After some time M4 may leave EMCON and has to send its ACK_PDU. As
  1315.    assumed M4 has received the total message before the Expiry_Time has
  1316.    been reached, it will send
  1317.  
  1318.      ACK_PDU( Source_ID=M4, Dest_ACK_Infos=(Cnt=1, ACK_Info=(M0, 9876,
  1319.         0)))
  1320.  
  1321.    At this time the Message Transmitter part can hand over the message
  1322.    to Multicast_OUT to update the message queue entry. Now M0 will
  1323.    delete M4 from the Destination_List and will send out an Address_PDU
  1324.    holding an empty List_of_Destination_Entries:
  1325.  
  1326.      Address_PDU( Source_ID=M0, MSID=9876, TTL=1000, Total_PDUs=2,
  1327.         Dests=( Cnt=0, LDES=0, Dest_ID=()))
  1328.  
  1329.    This last Address_PDU sent out by M0 will inform M1, M2, M3 and M4,
  1330.    that M0 received the completion ACK_PDUs of all reveiving MTAs. This
  1331.    means,that all information about the message MSID=9876 of M0 can be
  1332.    deleted.
  1333.  
  1334.  
  1335.  
  1336.  
  1337.  
  1338.  
  1339.  
  1340.  
  1341.  
  1342. Copeland/Riechmann         Expires March 1998                  [Page 24]
  1343.  
  1344. INTERNET-DRAFT                                            September 1997
  1345.  
  1346.  
  1347. 6. References
  1348.  
  1349. [CCITT88]     CCITT, ISO: "Data Communication Networks: Message Handling
  1350.               Systems, Recommendations X.400 - X.420", Blue Book, 1988
  1351.  
  1352. [ISO86]       ISO: "International Standard 8602 - Information Processing
  1353.               Systems - OSI: Connectionless Transport Protocol
  1354.               Specification", December 1986
  1355.  
  1356. [RMP95-1]     T. Montgomery, B. Whetten, J.R. Callahan: "The Reliable
  1357.               Multicast Protocol Specification - Protocol Operation -",
  1358.               Internal Documentation, October 5, 1995
  1359.  
  1360. [RMP95-2]     T. Montgomery, B. Whetten, J.R. Callahan: "The Reliable
  1361.               Multicast Protocol Specification - Protocol Packet
  1362.               Formats -", Internal Documentation, October 5, 1995
  1363.  
  1364. [RMP95-3]     T. Montgomery, B. Whetten, J.R. Callahan: "The Reliable
  1365.               Multicast Protocol Specification - Flow Control and NACK
  1366.               Policy -", Internal Documentation, October 5, 1995
  1367.  
  1368. [UDP80]       J. Postel: "User Datagram Protocol", RFC768, August 1980
  1369.  
  1370. [XTP95]       XTP Forum: "Xpress Transport Protocol Specification - XTP
  1371.               Revision 4.0 -", XTP Forum, 1394 Greenworth Place, Santa
  1372.               Barbara, CA 93108, March 1, 1995
  1373.  
  1374.  
  1375. A. Appendix
  1376.  
  1377. A.1. Abbreviations
  1378.  
  1379.    EMCON      Emission Control
  1380.  
  1381.    MAP        More Address_PDUs
  1382.  
  1383.    MTA        Message Transfer Agent
  1384.  
  1385.    PDU        Protocol Data Unit
  1386.  
  1387.    RMP        Reliable Multicast Protocol
  1388.  
  1389.    UDP        User Datagram Protocol
  1390.  
  1391.    XTP        Xpress Transport Protocol
  1392.  
  1393. A.2. Predefined Protocol Parameters
  1394.  
  1395.  
  1396.  
  1397.  
  1398. Copeland/Riechmann         Expires March 1998                  [Page 25]
  1399.  
  1400. INTERNET-DRAFT                                            September 1997
  1401.  
  1402.  
  1403.    ACK_TIME   Time between the output of two subsequent Data_PDUs.
  1404.  
  1405.    MPDU_SIZE  This is the maximum PDU size used to transmit messages
  1406.               over the multicast network.
  1407.  
  1408.    HOST_ID    This field holds the MTA's own network address (Internet
  1409.               address).
  1410.  
  1411.    EMCON_RTC  Maximum re-transmission counter controlling the number of
  1412.               message re-transmissions for EMCON MTAs.
  1413.  
  1414.    EMCON_RTI  Re-transmission interval controlling the waiting time
  1415.               between successive re-transmissions for EMCON MTAs.
  1416.  
  1417. A.3. Proposed UDP Port Numbers
  1418.  
  1419.    To allow multiplexed multicast communication between all MTAs of a
  1420.    network it is necessary to define 2 UDP port numbers:
  1421.  
  1422.    Port 2753  is used for the data traffic from the Message Transmitter
  1423.               of Multicast_OUT to the Message Receiver of Multicast_IN.
  1424.  
  1425.    Port 2754  is used for the traffic from the Message Receiver of
  1426.               Multicast_IN to the Message Transmitter of Multicast_OUT.
  1427.  
  1428. A.4. Proposed Algorithm for the Checksum
  1429.  
  1430.      #include "includes.h"
  1431.      /* function checksum
  1432.       *
  1433.       * This function computes and sets the checksum (FLETCHER algorithm).
  1434.       * If "offset" is NULL, then the checksum will be calculated but the
  1435.       * checksum bytes will not be set.
  1436.       * If "offset" is non-NULL, the checksum bytes at "offset" will be set
  1437.       * such that the checksum accumulations, when recalculated, will both
  1438.       * be zero.
  1439.       * return : checksum accumulations
  1440.       */
  1441.      int checksum(buffer, len, offset)
  1442.        octet *buffer;
  1443.        int len, offset;
  1444.      {
  1445.        unsigned int c0 c1;
  1446.        int cs;
  1447.        long ctmp, cl0, cl1;
  1448.        octet *hpp, *pls;
  1449.  
  1450.        if (offset) {
  1451.  
  1452.  
  1453.  
  1454. Copeland/Riechmann         Expires March 1998                  [Page 26]
  1455.  
  1456. INTERNET-DRAFT                                            September 1997
  1457.  
  1458.  
  1459.          buffer[offset] = 0;
  1460.          buffer[offset+1] = 0;
  1461.          ctmp = len - offset - 1 ;
  1462.        }
  1463.  
  1464.        pls = buffer + len;
  1465.        c0 = c1 = 0;
  1466.        hpp = buffer;
  1467.  
  1468.        while (hpp < pls) {
  1469.          if ((c0 += *hpp++) > 254) { c0 -= 255; }
  1470.          if ((c1 += c0) > 254) { c1 -= 255; }
  1471.        } /* while */
  1472.  
  1473.        if (offset) {
  1474.          cl0 = c0;
  1475.          cl1 = c1;
  1476.          if ((cs =((ctmp * cl0) - cl1) % 255L) < 0) { cs += 255; }
  1477.          buffer[offset] = cs;
  1478.          if ((cs =(cl1 -((ctmp + 1L) * cl0)) % 255L) < 0) { cs += 255; }
  1479.          buffer[offset+1] = cs;
  1480.        } /* if (offset) */
  1481.  
  1482.        return(c0 | c1);
  1483.      }
  1484.  
  1485.  
  1486.  
  1487. Security Considerations
  1488.  
  1489.    Security considerations are not discussed in this memo.
  1490.  
  1491.  
  1492. Author's Addresses:
  1493.  
  1494.    Phil Copeland                           Christian Riechmann
  1495.    TNO/FEL                                 FGAN/FFM
  1496.    Oude Walsdorperweg 63                   Neuenahrer Strasse 20
  1497.    PO Box 96864                            D-53343 WACHTBERG
  1498.    2509 JG Den Haag                        Germany
  1499.    Netherlands                             Phone: (+49) 228 9435 533
  1500.    Phone: (+31) 70 3740305                 Fax:   (+49) 228 348 953
  1501.    Fax:   (+31) 70 3280961                 Email: riechmann@fgan.de
  1502.    Email: copeland@fel.tno.nl
  1503.  
  1504.  
  1505.  
  1506.  
  1507.  
  1508.  
  1509.  
  1510. Copeland/Riechmann         Expires March 1998                  [Page 27]
  1511.  
  1512.