INTERNET-DRAFT P. Copeland
Expires March 1998 TNO-FEL
C. Riechmann
FGAN/FFM
September, 1997
P_Mul:
An Application Protocol for the Transfer of Messages
over Multicast Subnetworks and under EMCON Restrictions
(draft-riechmann-multicast-mail-00.txt)
Status of this Memo
This document is an Internet-Draft. 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.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as ``work in progress.''
To learn the current status of any Internet-Draft, please check the
``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow
Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
ftp.isi.edu (US West Coast).
Abstract
P_Mul is a proposal for an application protocol for the transfer of
messages using a connectionless transport protocol. The objectives of
this protocol are first to take advantage of the bandwidth saving
feature of using the multicast service as supported by modern
computer networks and second to allow message transfer under EMCON
conditions. EMCON (Emission Control) means that, although receiving
nodes are able to receive messages, they are not able to acknowledge
the receipt of messages.
The protocol described below has already been applied to the transfer
of messages between X.400 Message Transfer Agents (MTA). But it is
not only restricted to this application and can easily be applied to
the transfer of RFC822 messages.
Copeland/Riechmann Expires March 1998 [Page 1]
INTERNET-DRAFT September 1997
Table of Contents
1. Introduction
2. Protocol Layering
3. Protocol Data Units (PDU)
3.1. Address_PDU
3.2. Data_PDU
3.3. Discard_Message_PDU
3.4. ACK_PDU
4. Messaging Procedures
4.1. Transmission and Re-transmission of a Message
4.2. Reception of a Message
4.3. Acknowledgement of a Message
5. Example
6. References
A. Appendix
A.1. Abbreviations
A.2. Predefined Protocol Parameters
A.3. Proposed UDP Port Numbers
A.4. Proposed Algorithm for the Checksum
1. Introduction
The objective of this protocol is to take advantage of multicast
communication for the transfer of messages between MTAs (Message
Transfer Agents) on a single multicast network under normal - which
means dialogue oriented - communication conditions and under EMCON
conditions. EMCON condition means that a receiving node is able to
receive messages, but it cannot - for a relitive long time (hours or
even days) - acknowledge the received messages.
Figure 1 illustrates a simple multicast scenario, where the same
message has to be sent from MTA 1 to MTA 2 and to MTA 3.
+-------+
/->| MTA 2 |
+-------+ +-------+ / +-------+
| MTA 1 |<----->| Router|<
+-------+ +-------+ \ +-------+
\->| MTA 3 |
+-------+
Figure 1: Typical MTA Configuration
Using a multicast instead of an unicast communication service in the
above MTA configuration only one message transmission from MTA 1 to
Copeland/Riechmann Expires March 1998 [Page 2]
INTERNET-DRAFT September 1997
the Router is required, instead of two as required with unicast.
This saves the transmision of one message and thus network bandwidth
utilisation. Depending on the network bandwidth (in some radio
networks less than 9.6 Kb/s) this saving can be of vital importance.
The saving in bandwidth utilisation becomes even greater with every
additional receiving MTA.
As P_Mul employs a connectionless transport protocol to transmit
messages, the reliable message transfer is guaranteed even in those
cases, when for a certain period of time one or more of the receiving
MTAs are not able or allowed to acknowledge completely received
messages.
The protocol P_Mul has been applied to the communication between
X.400 MTAs; but it is not constrained to X.400 MTA communication, it
also can be applied to other kinds of reliable multicast
transmission, e.g. file transfer or RFC822 messages.
This protocol specification requires fixed multicast groups and a
well known knowledge at each participating node(MTA) about the group
memberships to one or more multicast groups of each participating
node.
2. Protocol Layering
As mentioned above this protocol has to be understood as an
application layer protocol, in the same way as the P1 protocol
defined in the X.400 Recommendations [CCITT88]. As in the case of P1,
P_Mul will use the lower layer protocols to transmit its PDUs over
the multicast network.
Considering the fact that MTAs under EMCON are not allowed to
exchange any messages with their partner MTAs, it is not possible to
use a reliable transport protocol like "RMP" [RMP95-1, RMP95-2,
RMP95-3] or "XTP" [XTP95] for the transfer of messages. Therefore
P_Mul will be based on the unreliable connectionless transport
protocol "UDP" [UDP80]. A proposal as to which UDP ports shall be
used can be found within the Appendix.
In the X.400 context P_Mul is to be implemented within an MTA. A
sample implementation has been implemented using the X.400 Message
Handling System package available from ISODE Ltd. In this case two
channel programs "Multicast_OUT" and "Multicast_IN" have been
implemented and integrated. "Multicast_OUT" handles the sending of
messages to the multicast connected neighbour MTAs. "Multicast_IN"
handles the incoming messages from the multicast connected neighbour
MTAs. These channels play the role of the 'Higher Management
Copeland/Riechmann Expires March 1998 [Page 3]
INTERNET-DRAFT September 1997
Functions' mentioned in following chapters.
3. Protocol Data Units (PDU)
The number of PDUs used by P_Mul is mainly determined by the fact
that this protocol should also be suited for communication under
EMCON condition, which is understood as only one sided communication.
In this case several nodes are able to receive data and not able or
allowed to acknowledge them. Such a restriction can exist for a long
period of time (e.g. hours, days). This restriction has resulted in,
that P_Mul uses only four different PDUs ("Address_PDU", "Data_PDU",
"ACK_PDU" and "Discard_Message_PDU"). Other PDUs for instance as
defined for RMP like "Recovery Packet" or "Alarm Packet" and others
are not useful in this context.
All PDUs are sent using the UDP protocol and multicast addressing.
3.1. Address_PDU
This PDU and the ACK_PDU (see below) govern the flow control of P_Mul
packets. As P_Mul has to observe a maximum PDU_size and as the number
of Destination_Entries has no maximum value limitation, it is
necessary to be able to split the total addressing information into
more than one Address_PDU. To distinguish between the first, middle,
or last Address_PDU the MAP field ("More Address_PDUs") is used.
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
+-------------------------------+---------------+---+-----------+
| Length_of_PDU | Priority |MAP| PDU_Type |
+-------------------------------+---------------+---+-----------+
| Total_Number_of_PDUs | Checksum |
+-------------------------------+-------------------------------+
| Source_ID |
+---------------------------------------------------------------+
| Message_ID (MSID) |
+---------------------------------------------------------------+
| Expiry_Time |
+---------------------------------------------------------------+
| Destinations (variable length) |
: :
| |
+---------------------------------------------------------------+
Copeland/Riechmann Expires March 1998 [Page 4]
INTERNET-DRAFT September 1997
Destinations:
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
+-------------------------------+-------------------------------+
| Count_of_Destination_Entries | Length_of_DES_Key |
+---------------------------------------------------------------+
| List_of_Destination_Entries (variable length) |
: :
| |
+---------------------------------------------------------------+
One Destination_Entry:
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
+---------------------------------------------------------------+
| Destination_ID |
+---------------------------------------------------------------+
| Message_Sequence_Number |
+---------------------------------------------------------------+
| DES_Key (variable length) |
: :
| |
+---------------------------------------------------------------+
Explanations
Length_of_PDU:
The field (2 octets) indicates the total number of octets within
this PDU.
Priority:
This 1-octet field enables the sending MTA to inform the other
MTAs that at the sending MTA there exists at least one message
with the denoted priority (for further study). The value 0
denotes the highest priority.
MAP: This 2-bit field specifies whether this Address_PDU is a first
or a middle or a last one.
The high order bit is set to
'0': This is the first one of a set of Address_PDUs.
'1': This is NOT the first one of a set of Address_PDUs.
Copeland/Riechmann Expires March 1998 [Page 5]
INTERNET-DRAFT September 1997
The low order bit is set to
'0': This is the last one of a set of Address_PDUs.
'1': This is NOT the last one of a set of Address_PDUs.
In the case both bits are set to zero, only one Address_PDU
exists.
PDU_Type:
This 6-bit field specifies the type of the actual PDU. PDU_Type
x'02' denotes an Address_PDU.
Total_Number_of_PDUs:
These 2 octets hold the total number of Data_PDUs of the
message.
Checksum:
The checksum will be built by using one of the currently
available checksum algorithms and is calculated over the rest of
this PDU. A sample implementation of the Fletcher algorithm can
be found in the Appendix.
Source_ID:
This field holds the ID of the sender of this Address_PDU. This
ID must be unique for the actual multicast network. As an
example the Internet address of the specific multicast interface
of the sending MTA node could be used.
Message_ID:
MSID is a unique identifier built within the scope of Source_ID
by the transmitter (e.g. seconds since 00:00:00 1.1.1970 - Unix
Time -).
Expiry_Time:
This is the expiry time of the message. This value is to be set
as a number of seconds since 00:00:00 1.1.1970 - Unix Time -,
which is derived from the Latest_Delivery_Time of the
corresponding X.400 message and/or by a predefined value. This
entry gives the chance for transmitters and receivers of a
message to decide, when a message entry is outdated and can be
removed from the processing lists.
Destinations:
This is a variable length field containing all receivers, their
message sequence information and as an option, if
confidentiality has been implemented and is needed, a randomly
chosen DES_Key, which is encrypted with the public key of each
receiving site.
Copeland/Riechmann Expires March 1998 [Page 6]
INTERNET-DRAFT September 1997
Count_of_Destination_Entries:
The first 2 octets of this "Destinations" substructure of the
PDU denote the number of destination entries. Each is formed by
the Destination_ID, a message sequence number and eventually an
DES_Key being encoded by the public key owned by this
Destination_ID designated receiver.
Length_of_DES_Key:
These 2 octets specify the length of the public key encoded
"DES_Key", which is 0, if confidentiality is not used.
List_of_Destination_Entries:
This entry is an array of destination entries. Its dimension is
specified within the above mentioned
"Count_of_Destination_Entries".
Destination_ID:
This field holds an identifier uniquely identifying a receiving
MTA on the actual multicast network. As an example the Internet
address of the receiving MTA node could be used.
Message_Sequence_Number:
This entry holds a message sequence number, which is unique for
the sender/receiver pair denoted by Source_ID and
Destination_ID. This sequence number will be generated by
transmitter consecutively with no leaks and is used by each
receiver to detect message loss.
DES_Key:
In case of confidential transfer of Data_PDUs the data portions
will be encoded by a symmetric encryption algorithm. The
symmetric key, which is the same for all receiving MTAs, will be
asymmetrically encoded by the public key of each receiving MTA
and transmitted within this field. Each receiving MTA can decode
its "own" key information by using its private key. The key for
the symmetric encryption should be valid for the total
transmission of one message and will be generated randomly.
3.2. Data_PDU
This PDU holds essential information such as the unique identifier of
the message, the position of this Data_PDU within the ordered set of
all Data_PDUs and one fragment of the total message.
Copeland/Riechmann Expires March 1998 [Page 7]
INTERNET-DRAFT September 1997
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
+-------------------------------+---------------+---+-----------+
| Length_of_PDU | Priority | | PDU_Type |
+-------------------------------+---------------+---+-----------+
| Number_of_PDU | Checksum |
+-------------------------------+-------------------------------+
| Source_ID |
+---------------------------------------------------------------+
| Message_ID (MSID) |
+---------------------------------------------------------------+
| Fragment of DATA (variable length) |
: :
| |
+---------------------------------------------------------------+
Explanations
Length_of_PDU:
The field (2 octets) indicates the total number of octets within
this PDU.
Priority:
This 1-octet field enables the sending MTA to inform the other
MTAs that at the sending MTA there exists at least one message
with the denoted priority (for further study). The value 0
denotes the highest priority.
PDU_Type:
This 6-bit field specifies the type of the actual PDU. PDU_Type
x'00' denotes a Data_PDU.
Number_of_PDU:
This value offers the information where to place this message
fragment into the whole message.
Checksum:
The checksum will be built by using one of the currently
available checksum algorithms and is calculated over the rest of
this PDU. A sample implementation of the Fletcher algorithm can
be found in the Appendix.
Source_ID:
This field holds the ID of the sender of this Data_PDU and is
equivalent to the Source_ID within the corresponding
Address_PDU. This ID must be unique for the actual multicast
Copeland/Riechmann Expires March 1998 [Page 8]
INTERNET-DRAFT September 1997
network. As an example the Internet address of the specific
multicast interface of the sending MTA node could be used.
Message_ID:
MSID is a unique identifier built within the scope of Source_ID
by Multicast_OUT (e.g. seconds since 00:00:00 1.1.1970 - Unix
Time -).
Fragment
This portion of the Data_PDU holds the message or only fragments
of it.
3.3. Discard_Message_PDU
This PDU is used to inform the receiving MTAs, that the transfer of a
specific message has been terminated and no further PDU of this
message will be transmitted. Such a situation can occur because of
different reasons like hardware error or message outdating. Those
PDUs already received shall be forgotten by the receiving MTAs. In
this case the sending MTA shall generate a Non-Delivery Report.
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
+-------------------------------+---------------+---+-----------+
| Length_of_PDU | Priority | | PDU_Type |
+-------------------------------+---------------+---+-----------+
| not_used | Checksum |
+-------------------------------+-------------------------------+
| Source_ID |
+---------------------------------------------------------------+
| Message_ID (MSID) |
+---------------------------------------------------------------+
Explanations
Length_of_PDU:
The field (2 octets) indicates the total number of octets within
this PDU.
Priority:
This 1-octet field enables the sending MTA to inform the other
MTAs that at the sending MTA there exists at least one message
with the denoted priority (for further study). The value 0
denotes the highest priority.
PDU_Type:
Copeland/Riechmann Expires March 1998 [Page 9]
INTERNET-DRAFT September 1997
This 6-bit field specifies the type of the actual PDU. PDU_Type
x'03' denotes a Discard_Message_PDU.
not_used:
This field is currently not used (reserved for future use).
Checksum:
The checksum will be built by using one of the currently
available checksum algorithms and is calculated over the rest of
this PDU. A sample implementation of the Fletcher algorithm can
be found in the Appendix.
Source_ID:
This field holds the ID of the sender of this
Discard_Message_PDU and is equivalent to the Source_ID within
the corresponding Address_PDU. This ID must be unique for the
actual multicast network. As an example the Internet address of
the specific multicast interface of the sending MTA node could
be used.
Message_ID:
MSID is a unique identifier built within the scope of Source_ID
by the transmitter (e.g. seconds since 00:00:00 1.1.1970 - Unix
Time -).
3.4. ACK_PDU
This PDU is generated by a receiving MTA identified by the
Source_ID_of_ACK_Sender and is used to inform the sending MTA about
the receive status of one or more messages. This information is
composed within one or more entries of the List_of_ACK_Info_Entries.
Each of these entries holds a message identifier (Source_ID and
Message_ID) and a List_of_Missing_Data_PDUs, which may contain a list
of those Data_PDUs not yet received. If this list is empty, the
message identified by Source_ID and Message_ID has been completely
received by this receiving MTA.
Copeland/Riechmann Expires March 1998 [Page 10]
INTERNET-DRAFT September 1997
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
+-------------------------------+---------------+---+-----------+
| Length_of_PDU | Priority | | PDU_Type |
+-------------------------------+---------------+---+-----------+
| not_used | Checksum |
+-------------------------------+-------------------------------+
| Source_ID_of_ACK_Sender |
+---------------------------------------------------------------+
| Dest_ACK_Info (variable length) |
: :
| |
+---------------------------------------------------------------+
Dest_ACK_Info:
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
+-------------------------------+-------------------------------+
| Count_of_ACK_Info_Entries | Length_of_ACK_Info_Entry |
+-------------------------------+-------------------------------+
| List_of_ACK_Info_Entries (variable Length) |
: :
| |
+---------------------------------------------------------------+
One ACK_Info_Entry:
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
+-------------------------------+-------------------------------+
| Source_ID |
+---------------------------------------------------------------+
| Message_ID (MSID) |
+-------------------------------+-------------------------------+
| List_of_Missing_Data_PDUs |
: :
| |
+-------------------------------+
Copeland/Riechmann Expires March 1998 [Page 11]
INTERNET-DRAFT September 1997
Explanations
Length_of_PDU:
The field (2 octets) indicates the total number of octets within
this PDU.
Priority:
This 1-octet field enables the sending MTA to inform the other
MTAs that at the sending MTA there exists at least one message
with the denoted priority (for further study). The value 0
denotes the highest priority.
PDU_Type:
This 6-bit field specifies the type of the actual PDU. PDU_Type
x'01' denotes an ACK_PDU.
not_used:
This field is currently not used (reserved for future use).
Checksum:
The checksum will be built by using one of the currently
available checksum algorithms and is calculated over the rest of
this PDU. A sample implementation of the Fletcher algorithm can
be found in the Appendix.
Source_ID_of_ACK_Sender:
This field holds the ID of the sender of this ACK_PDU and is
equivalent to one of the Destination_IDs described for the
Address_PDU. This ID must be unique for the actual multicast
network. As an example the Internet address of the specific
multicast interface of the ACK_PDU sending MTA node could be
used.
Dest_ACK_Info:
This is a variable field containing ACK_Info_Entries for one or
more message sending nodes on the multicast network. Each
ACK_Info_Entry consists of the corresponding Source_ID of the
message sending node, the message_ID and the list of those
Data_PDUs not yet received by the ACK_PDU generating receiver.
Count_of_ACK_Info_Entries:
This field contains the number of ACK_Info_Entries. As long as
there is only one active sender, we have only one
ACK_Info_Entry, but it is assumed, that we can have more than
one message sending node on the same multicast network.
Length_of_ACK_Info_Entry:
This field holds the octet length of each ACK_Info_Entry.
Copeland/Riechmann Expires March 1998 [Page 12]
INTERNET-DRAFT September 1997
Having this field, the List_of_Missing_Data_PDUs is adaptable
(in length) to the quality of the transmission (see
"List_of_Missing_Data_PDUs" below). The maximum number of
entries within this list is defined as
M = (Length_of_ACK_Info_Entry - 8) / 2.
List_of_ACK_Info_Entries
This entry is an array of ACK_Info_Entries. Its dimension is
specified within "Count_of_ACK_Info_Entries".
Source_ID:
This field holds the identifier of the message sending node. It
is equivalent to "Source_ID" within the description of the
Address_PDU, Data_PDU or Discard_Message_PDU.
Message_ID:
MSID is a unique identifier built by the sender (e.g. seconds
since 00:00:00 1.1.1970 - Unix Time -). It is equivalent to
"Message_ID" of the description of the Address_PDU.
List_of_Missing_Data_PDUs:
This field contains the list of the order numbers of those
Data_PDUs definitely sent by the sender but not yet received at
the receiver generating the current ACK_PDU. The maximum number
of entries in this list is defined by M (see
"Length_of_ACK_Info_Entry" above).
If the list holds less than M entries, then the first free entry
has to be set to 0 to mark the end of the list. If all Data_PDUs
have been acknowledged, the first entry has to be set to 0.
Whereas normally an ACK_PDU will only signal the receiving status
("ACK") of one MSID of Destination_ID, especially at the end of an
EMCON period, one ACK_PDU may contain more "ACKs" to one or more
MSIDs of one or more Destination_IDs.
4. Messaging Procedures
The following describes the messaging procedures to be employed
between a transmitting MTA and one or more receiving MTAs either in
the non-EMCON or EMCON mode of operation using the P_Mul multicast
protocol. The following procedures shall be implemented for every
message transmitted. The procedures are divided into three main
areas, namely:
* Transmission and Re-transmission
* Reception
Copeland/Riechmann Expires March 1998 [Page 13]
INTERNET-DRAFT September 1997
* Acknowledgement
4.1. Transmission and Re-transmission of a Message
An MTA shall initiate the transmission of a message by firstly
transmitting an Address_PDU containing a list of all the MTAs that
are to receive the message. The transmitting MTA shall be made aware,
by a 'Higher Management Function', which of the receiving MTAs are in
the non-EMCON and EMCON mode of operation. The transmitting MTA
shall, based on the supplied mode of operation information, create a
list of non-EMCON receiving MTAs, from which it shall expect to
receive ACK_PDUs.
On completion of transmission of the Address_PDU the transmitting MTA
shall proceed with the transmission of the Data_PDU(s), with the
Message_ID field set equal to the Message_ID field of the associated
Address_PDU. On completion of transmission of the last Data_PDU of a
message the transmitting MTA shall initialise a "Transmitter
Expiry_Time Timer" and an "EMCON Re-transmission Counter"
(EMCON_RTC), if one or more of the receiving MTAs is in the EMCON
mode, and enter the non-EMCON or EMCON Re-transmission mode (see
para. 4.1.3 resp. 4.1.4).
4.1.1. Transmitter Expiry_Time Timer
This timer indicates the time remaining before the contents of the
transmit message is considered invalid. It shall be initialised in
accordance with the value transmitted in the Expiry_Time field of the
Address_PDU.
If, in the event that one or more of the receiving MTAs have not
acknowledged receipt of the complete message, this timer expires, the
transmitting MTA shall transmit a Discard_Message_PDU with the
Message_ID field set equal to the Message_ID field in the associated
Address_PDU and Data_PDUs.
If, after having transmitted a Discard_Message_PDU, the transmitting
MTA receives an ACK_PDU indicating only partial receipt of the
message, it shall re-transmit the Discard_Message_PDU.
If, after having transmitted a Discard_Message_PDU, the transmitting
MTA receives an ACK_PDU indicating receipt of the complete message,
it shall disregard the ACK_PDU.
If all the receiving MTAs addressed in the Destination part of the
Address_PDU acknowledge the receipt of the complete message before
Copeland/Riechmann Expires March 1998 [Page 14]
INTERNET-DRAFT September 1997
this timer expires, the timer shall be stopped.
4.1.2. EMCON Re-transmission Counter
This counter (EMCON_RTC) indicates the maximum number of times the
complete message may be re-transmitted while in the EMCON Re-
transmission mode. It shall be set to a value based on such
parameters as the priority, etc. of the message.
4.1.3. Non-EMCON Re-transmission
The transmitting MTA shall enter this mode when one or more of the
receiving MTAs is in the non-EMCON mode. On entering this mode the
transmitting MTA shall either:
a. having transmitted the last Data_PDU, initialise the "Ack Re-
transmission Timer" or
b. having left the "EMCON Re-transmission" mode, re-transmit all
the indicated missing Data_PDUs and then initialise the "Ack
Re-transmission Timer".
4.1.3.1. Ack Re-transmission Timer
This timer shall be initialised when one or more of the receiving
MTAs are in the non-EMCON mode. The duration of this timer shall be
derived from the maximum round trip delay plus a safeguard.
If, in the event all the receiving MTAs in the non-EMCON mode respond
with an ACK_PDU before this timer expires, the transmitting MTA shall
either:
a. in the event that one or more of the ACK_PDUs indicate that a
receiving MTA is missing Data_PDUs, re-transmit all the
indicated missing Data_PDUs accompanied by a possibly updated
Address_PDU and re-initialise the timer and remain in the "Non-
EMCON Re-transmission" mode or
b. in the event that all the ACK_PDUs indicate that the complete
message has been received, stop the timer. If, at this stage
there are receiving MTAs in the EMCON mode the transmitting MTA
shall enter the EMCON Re-transmission mode.
If one or more of the receiving MTAs in the non-EMCON mode does not
respond with an ACK_PDU indicating partial or complete reception of
the message, this timer expires, the transmitting MTA shall either:
a. in the event that it has not received a previous ACK_PDU from
Copeland/Riechmann Expires March 1998 [Page 15]
INTERNET-DRAFT September 1997
the receiving MTA, re-transmit the complete message and re-
initialise the timer or
b. in the event that it has received a previous ACK_PDU from the
receiving MTA, only re-transmit the possibly updated Address_PDU
and all the previously indicated missing Data_PDUs and re-
initialise the timer.
4.1.3.2. Receipt of Message Complete ACK_PDU
When a transmitting MTA receives an ACK_PDU from a non-EMCON or EMCON
receiving MTA indicating that it has received the complete message,
it shall transmit an acknowledgement to this message complete
ACK_PDU. The acknowledgement shall be done in the form of an
Address_PDU with the destination address of the associated receiving
MTA removed from the List_of_Destination_Entries field. Any
subsequent re-transmission of the relevant message will be sent with
the Destination_Entry of the receiving MTA removed from the
List_of_Destination_Entries field in the Address_PDU.
4.1.4. EMCON Re-transmission
The transmitting MTA shall enter this mode as soon as all receiving
MTAs are in the EMCON mode. On entering this mode the transmitting
MTA shall initialise the "EMCON Re-transmission Timer" (EMCON_RTI).
4.1.4.1. EMCON Re-transmission Timer
This timer (EMCON_RTI) shall be initialised when all the receiving
MTAs are in the EMCON mode. The duration of this timer will be based
on such parameters as the priority, etc. of the message.
If this timer expires, which means that since the last EMCON Re-
transmission none of the receiving MTAs in the EMCON mode has entered
the non-EMCON mode - by sending one or more ACK_PDUs -, and the
"EMCON Re-transmission Counter" has not reached its maximum count,
the transmitting MTA shall re-transmit the Address_PDU and all
Data_PDUs not already acknowledged. It shall re-initialise this timer
and increment the "EMCON Re-transmission Counter" and the message
sending MTA shall wait until either:
a. one or more of the receiving MTAs in EMCON mode respond with an
ACK_PDU at which point it shall enter the "Non-EMCON Re-
transmission" mode or
b. the "Transmitter Expiry_Time Timer" expires at which point it
shall transmit a Discard_Message_PDU.
Copeland/Riechmann Expires March 1998 [Page 16]
INTERNET-DRAFT September 1997
If, in the event one or more of the receiving MTAs in the EMCON mode
responds, by entering the non-EMCON mode, with an ACK_PDU indicating
partial or complete reception of the message, before this timer
expires, the transmitting MTA shall stop the timer and enter the
"Non-EMCON Re-transmission" mode (see para. 4.1.3).
4.2. Reception of a Message
The "Reception of a Message" mode shall be initiated when the
receiving MTA receives either an Address_PDU or Data_PDU.
4.2.1. Receipt of an Address_PDU
On receipt of an Address_PDU the receiving MTA shall first check
whether the Address_PDU has already been received.
If the Address_PDU has already been received the receiving MTA shall:
a. if its own ID exists in the List_of_Destination_Entries and it
has previously sent a message complete ACK_PDU for this message,
re-transmit the message complete ACK_PDU and discard the
Address_PDU else
b. discard the Address_PDU.
If the Address_PDU has not been previously received the receiving MTA
shall:
a. if its own ID does not exist in the List_of_Destination_Entries,
check whether it has previously received any Data_PDUs
associated with this Address_PDU (i.e. same Source_ID and
Message_ID) and discard the Address_PDU. If there exists
Data_PDUs associated with this Address_PDU, the receiving MTA
shall discard these Data_PDUs.
b. if its own ID exists in the List_of_Destination_Entries
determine whether it has previously received any Data_PDUs
associated with this Address_PDU.
If there exists no Data_PDUs associated with this Address_PDU, the
receiving MTA shall create a message entry and await reception of the
associated Data_PDUs.
If there exists Data_PDUs associated with this Address_PDU, the
receiving MTA shall update the status of the Data_PDU entry (see
para. 4.2.2) to a message entry. In addition the receiving MTA shall
stop the "Delete-Data_PDUs Timer" (see para. 4.2.2.1) and initialise
the "Receiver Expiry_Time Timer". The receiving MTA shall then
Copeland/Riechmann Expires March 1998 [Page 17]
INTERNET-DRAFT September 1997
determine whether to enter the "Acknowledgement of a Message" mode
(see para. 4.2.3).
4.2.1.1. Receiver Expiry_Time Timer
This timer indicates the time remaining before the contents of the
received message is considered invalid. It shall be initialised in
accordance with the value received in the Expiry_Time field of the
Address_PDU.
If this timer expires and the receiving MTA has not received all the
Data_PDUs associated with a message, the receiving MTA shall discard
the associated Data_PDUs and Address_PDU.
4.2.2. Receipt of a Data_PDU
On receipt of a Data_PDU the receiving MTA shall first check whether
the Data_PDU has already been received.
If the Data_PDU has already been received the receiving MTA shall:
a. if the receiving MTA has not received a duplicate of the
associated Address_PDU (see para. 4.2.1) and it has previously
sent a message complete ACK_PDU for this message, re-transmit
the message complete ACK_PDU and discard the Data_PDU else
b. discard the Data_PDU.
If the Data_PDU has not been previously received, the receiving MTA
shall check whether it has received the associated Address_PDU.
If the associated Address_PDU has been received and a message entry
exists the receiving MTA shall update the status of the message entry
and determine whether to enter the "Acknowledgement of a Message"
mode (see para. 4.2.3). If the associated Address_PDU has been
received but no message entry exists the receiving MTA shall discard
the Data_PDU.
If the associated Address_PDU has not been received the receiving MTA
shall check whether there exists a Data_PDU entry associated with the
Source_ID and Message_ID contents of the received Data_PDU.
If there exists no Data_PDU entry associated with this Data_PDU, the
receiving MTA shall create a Data_PDU entry and await reception of
the associated Address_PDU. In addition the receiving MTA shall
initialise a "Delete Data_PDUs Timer". If there exists a Data_PDU
entry associated with this Data_PDU, the receiving MTA shall update
the status of the Data_PDU entry and await reception of the
Copeland/Riechmann Expires March 1998 [Page 18]
INTERNET-DRAFT September 1997
associated Address_PDU.
4.2.2.1. Delete Data_PDUs Timer
This timer indicates the time remaining before the Data_PDUs in a
Data_PDU entry are considered to be no longer valid and can therefore
be discarded. It shall be initialised to a value based on such
parameters as TBD.
If, in the event the receiving MTA does not receive the Address_PDU
or a Discard_Message_PDU associated with the Data_PDUs in the
Data_PDU entry, this timer expires, the receiving MTA shall discard
all Data_PDUs.
4.2.3. Entry to "Acknowledgement of a Message"
Having updated the status of a message entry, the receiving MTA
shall:
a. if in the non-EMCON mode, check whether the last Data_PDU of the
message has been received or there are M (see para. 3.4) missing
Data_PDUs. In the event that either is true the receiving MTA
shall enter the "Acknowledgement of a Message" mode (see para.
4.3). In the event neither of the above is true the receiving
MTA shall remain in the "Reception of a Message" mode or
b. if in the EMCON mode, check whether all the Data_PDUs for the
message have been received. If there are missing Data_PDUs it
shall remain in the "Reception of a Message" mode. If all the
Data_PDUs have been received the message shall be tagged as
complete and ready for acknowledgement when the non-EMCON mode
is entered. The completed message can then be passed up to the
'Higher Layer Application'. The receiving MTA shall remain in
the "Reception of a Message" mode.
4.2.4. Receipt of a Discard_Message_PDU
In the event that a receiving MTA receives a Discard_Message_PDU, it
shall discard all the PDUs (i.e. data and address) associated with
the message identified by the combination of the Source_ID and
Message_ID fields in the Discard_Message_PDU. It shall also stop any
associated timers.
4.3. Acknowledgement of a Message
The "Acknowledgement of a Message" mode shall only be entered by a
receiving MTA that is in the non-EMCON mode of operation. The
"Acknowledgement of a Message" mode procedures shall be dependent on
Copeland/Riechmann Expires March 1998 [Page 19]
INTERNET-DRAFT September 1997
whether the receiving MTA received the messages in the non-EMCON
mode, (see para. 4.3.1) or in the EMCON mode, (see para. 4.3.2).
To avoid the problem of ACK implosion on the message transmitting
site, in the event that the receiving MTA has several ACK_PDUs to
transmit, each transmission of an ACK_PDU should be delayed by a
randomly determined period of time interval.
4.3.1. Receiving MTA in Non-EMCON
A receiving MTA shall, if operating in the non-EMCON mode enter the
"Acknowledgement of a Message" mode when either the last Data_PDU of
a message is received or there are M (see para. 3.4) missing
Data_PDUs.
4.3.1.1. Last Data_PDU Received
If the last Data_PDU of a message has been received, the receiving
MTA shall determine whether there are any missing Data_PDUs in the
message.
4.3.1.2. Missing Data_PDUs
If there are missing Data_PDUs the receiving MTA shall:
a. if no ACK_PDU associated with this message has been previously
transmitted, transmit an ACK_PDU listing which Data_PDUs are
missing and return to the "Reception of a Message" mode or
b. if an ACK_PDU associated with this message had been previously
transmitted, the receiving MTA shall return to the "Reception of
a Message" mode.
4.3.1.3. Received Complete Message
If there are no missing Data_PDUs the receiving MTA shall transmit an
ACK_PDU indicating that the message is complete. In addition it shall
stop the "Receiver Expiry_Time Timer" associated with this message.
The complete message shall be passed up to the 'Higher Layer
Application'. On completion of transmission of the ACK_PDU the
receiving MTA shall return to the "Reception of a Message" mode.
4.3.1.4. M Missing Data_PDUs
M has been defined as the maximum number of entries within the
List_of_Missing_Data_PDUs (see para. 3.4). It is possible for a
message to consists of more than M Data_PDUs, therefore it may be
possible for the receiving MTA to be missing M Data_PDUs, without
Copeland/Riechmann Expires March 1998 [Page 20]
INTERNET-DRAFT September 1997
having received the last Data_PDU, therefore:
A receiving MTA in the non-EMCON mode shall in the event that it is
missing M Data_PDUs from a message, construct and transmit an ACK_PDU
listing the M missing Data_PDUs.
If the receiving MTA proceeds to miss a further set of M Data_PDUs,
it shall transmit a new ACK_PDU listing the further set of M missing
Data_PDUs.
The receiving MTA shall repeat the procedure of transmitting an
ACK_PDU for every further set of M missing Data_PDUs until the last
Data_PDU is received.
On completion of transmission of every ACK_PDU the receiving MTA
shall return to the "Reception of a Message" mode.
4.3.2. Receiving MTA leaving EMCON
If the receiving MTA is operating in the EMCON mode, it shall enter
the "Acknowledgement of a Message" mode, when its mode of operation
has changed to the non-EMCON mode. Upon entering the non-EMCON mode
it shall determine whether it has received the last Data_PDU of a
message.
Note: The following procedures are relevant only for those messages
(complete or partial) received while in the EMCON mode. All new
messages received before the change into the EMCON mode or after the
change to the non-EMCON mode of operation shall be acknowledged in
accordance with the procedures described in para. 4.3.1.
4.3.2.1. Last Data_PDU Received
If the last Data_PDU of a message has been received, the receiving
MTA shall determine whether there are any missing Data_PDUs in the
message.
4.3.2.2. Missing Data_PDUs
If there are missing Data_PDUs, the receiving MTA shall transmit an
ACK_PDU listing denoting, which Data_PDUs are missing, and initialise
an associated "ACK_PDU Timer" (see para. 4.3.2.4).
If there are N missing Data_PDUs and N > M the receiving MTA shall
transmit (entier((N-1)/M) + 1) ACK_PDUs in order to indicate the
total number of missing Data_PDUs. No ACK_PDU shall indicate more
than M missing Data_PDUs, (see para. 4.3.1.4). The receiving MTA
shall initialise an associated "ACK_PDU Timer" with each ACK_PDU
Copeland/Riechmann Expires March 1998 [Page 21]
INTERNET-DRAFT September 1997
transmitted.
On completion of transmission of the ACK_PDU(s) the receiving MTA
shall then return to the "Reception of a Message" mode.
4.3.2.3. Received Complete Message
If there are no missing Data_PDUs, (e.g. tagged as complete, see
para. 4.2.3), the receiving MTA shall transmit an ACK_PDU indicating
that the message is complete and initialise the "ACK_PDU Timer". The
receiving MTA shall, if it has not already done so, stop the
"Receiver_Expiry_Time Timer" associated with this message and pass
the complete message to the 'Higher Layer Application'. The receiving
MTA shall return to the "Reception of a Message" mode.
4.3.2.4. ACK_PDU Timer
The "ACK_PDU Timer" shall be initialised for every ACK_PDU
transmitted by a receiving MTA, in the non-EMCON mode, having
previously been in the EMCON mode. The duration of the timer shall be
derived from the maximum round trip delay plus a safeguard.
If the receiving MTA receives a response to a transmitted ACK_PDU
from the transmitting MTA in the form of the requested missing
Data_PDUs or an Address_PDU, it shall stop the associated "ACK_PDU
Timer".
If, in the event the receiving MTA does not receive a response to the
transmitted ACK_PDU(s) from the transmitting MTA in the form of the
requested missing Data_PDUs or an Address_PDU, an "ACK_PDU Timer"
expires, the receiving MTA shall re-transmit the associated
ACK_PDU(s) and re-initialise the timer.
5. Example
The following example shall explain, how the PDUs are used between
MTAs on a multicast network. This example shall give only an
impression, how the protocol works. Therefore the packets are
described as a sort of function calls.
It is assumed that M0 is the sending MTA, which sends one message to
the MTAs M1, M2, M3 and M4. Only M3 and M4 are assumed to be under
EMCON. The message length is assumed to be a little larger than the
maximum PDU size, which means that the message (DATA) is split into
two fragments. Further we assume, that until now M0 had send 99
messages to M1, 77 messages to M2, 10 messages to M3 and 14 messages
to M4.
Copeland/Riechmann Expires March 1998 [Page 22]
INTERNET-DRAFT September 1997
M0 constructs an Address_PDU and the 2 Data_PDUs. It sends all 3 PDUs
to the multicast network.
Address_PDU( Source_ID=M0, MSID=9876, TTL=1000, Total_PDUs=2,
Dests=( Cnt=4, LDES=0, Dest_ID=((M1,100), (M2,78), (M3,11),
(M4,15))))
Data_PDU( Source_ID=M0, MSID=9876, PDU_No=1, Data= First N octets
of message)
Data_PDU( Source_ID=M0, MSID=9876, PDU_No=2, Data= Remaining octets
of message)
Assuming M1, M2, M3 and M4 will receive the Address_PDU. M1, M3 and
M4 shall receive the Data_PDUs without failures, while M2 shall
receive the first Data_PDU incorrectly and the second one correctly.
As M3 and M4 are in EMCON mode, they cannot send any ACK_PDU. M1 will
send a completion ACK_PDU, while M2 will send an ACK_PDU indicating
that the first Data_PDU is missing.
ACK_PDU( Source_ID=M1, Dest_ACK_Infos=(Cnt=1, ACK_Info=(M0, 9876,
0)))
ACK_PDU( Source_ID=M2, Dest_ACK_Infos=(Cnt=1, ACK_Info=(M0, 9876,
1,0)))
Now M0 has to re-transmit the first part of the message for M2,
because M2 marked this PDU as missing. As M0 has received the
completion ACK_PDU of M1, M1 is deleted from the Destination_List.
Address_PDU( Source_ID=M0, MSID=9876, TTL=1000, Total_PDUs=2,
Dests=( Cnt=3, LDES=0, Dest_ID=((M2,78), (M3,11), (M4,15))))
Data_PDU( Source_ID=M0, MSID=9876, PDU_No=1, Data= First N octets
of message)
Assuming that M2 will receive this PDU correctly, it will acknowledge
it with the following ACK_PDU.
ACK_PDU( Source_ID=M2, Dest_ACK_Infos=(Cnt=1, ACK_Info=(M0, 9876,
0)))
As M0 has received the completion ACK_PDU of M2, M2 will be deleted
from the Destination_List.
Supposing that M3 has left the EMCON situation, M3 will send its ACK
to M0 as:
Copeland/Riechmann Expires March 1998 [Page 23]
INTERNET-DRAFT September 1997
ACK_PDU( Source_ID=M3, Dest_ACK_Infos=(Cnt=1, ACK_Info=(M0, 9876,
0)))
Assuming that an EMCON Re-transmission for M4 should take place, M0
will re-transmit the total message. As M1, M2 and M3 already have
completely acknowledged the message, the Address_PDU will hold only
one Destination_ID for M4.
Address_PDU( Source_ID=M0, MSID=9876, TTL=1000, Total_PDUs=2,
Dests=( Cnt=1, LDES=0, Dest_ID=((M4,15))))
Data_PDU( Source_ID=M0, MSID=9876, PDU_No=1, Data= First N octets
of message)
Data_PDU( Source_ID=M0, MSID=9876, PDU_No=2, Data= Remaining octets
of message)
Supposing that M4 is still under EMCON and that now the Expiry_Time
out of the according Address_PDU has been reached. M0 will send the
following sequence of PDUs:
Discard_Message_PDU( Source_ID=M0, MSID=9876)
After some time M4 may leave EMCON and has to send its ACK_PDU. As
assumed M4 has received the total message before the Expiry_Time has
been reached, it will send
ACK_PDU( Source_ID=M4, Dest_ACK_Infos=(Cnt=1, ACK_Info=(M0, 9876,
0)))
At this time the Message Transmitter part can hand over the message
to Multicast_OUT to update the message queue entry. Now M0 will
delete M4 from the Destination_List and will send out an Address_PDU
holding an empty List_of_Destination_Entries:
Address_PDU( Source_ID=M0, MSID=9876, TTL=1000, Total_PDUs=2,
Dests=( Cnt=0, LDES=0, Dest_ID=()))
This last Address_PDU sent out by M0 will inform M1, M2, M3 and M4,
that M0 received the completion ACK_PDUs of all reveiving MTAs. This
means,that all information about the message MSID=9876 of M0 can be
deleted.
Copeland/Riechmann Expires March 1998 [Page 24]
INTERNET-DRAFT September 1997
6. References
[CCITT88] CCITT, ISO: "Data Communication Networks: Message Handling
Systems, Recommendations X.400 - X.420", Blue Book, 1988
[ISO86] ISO: "International Standard 8602 - Information Processing
Systems - OSI: Connectionless Transport Protocol
Specification", December 1986
[RMP95-1] T. Montgomery, B. Whetten, J.R. Callahan: "The Reliable
Multicast Protocol Specification - Protocol Operation -",
Internal Documentation, October 5, 1995
[RMP95-2] T. Montgomery, B. Whetten, J.R. Callahan: "The Reliable
Multicast Protocol Specification - Protocol Packet
Formats -", Internal Documentation, October 5, 1995
[RMP95-3] T. Montgomery, B. Whetten, J.R. Callahan: "The Reliable
Multicast Protocol Specification - Flow Control and NACK
Policy -", Internal Documentation, October 5, 1995
[UDP80] J. Postel: "User Datagram Protocol", RFC768, August 1980
[XTP95] XTP Forum: "Xpress Transport Protocol Specification - XTP
Revision 4.0 -", XTP Forum, 1394 Greenworth Place, Santa
Barbara, CA 93108, March 1, 1995
A. Appendix
A.1. Abbreviations
EMCON Emission Control
MAP More Address_PDUs
MTA Message Transfer Agent
PDU Protocol Data Unit
RMP Reliable Multicast Protocol
UDP User Datagram Protocol
XTP Xpress Transport Protocol
A.2. Predefined Protocol Parameters
Copeland/Riechmann Expires March 1998 [Page 25]
INTERNET-DRAFT September 1997
ACK_TIME Time between the output of two subsequent Data_PDUs.
MPDU_SIZE This is the maximum PDU size used to transmit messages
over the multicast network.
HOST_ID This field holds the MTA's own network address (Internet
address).
EMCON_RTC Maximum re-transmission counter controlling the number of
message re-transmissions for EMCON MTAs.
EMCON_RTI Re-transmission interval controlling the waiting time
between successive re-transmissions for EMCON MTAs.
A.3. Proposed UDP Port Numbers
To allow multiplexed multicast communication between all MTAs of a
network it is necessary to define 2 UDP port numbers:
Port 2753 is used for the data traffic from the Message Transmitter
of Multicast_OUT to the Message Receiver of Multicast_IN.
Port 2754 is used for the traffic from the Message Receiver of
Multicast_IN to the Message Transmitter of Multicast_OUT.
A.4. Proposed Algorithm for the Checksum
#include "includes.h"
/* function checksum
*
* This function computes and sets the checksum (FLETCHER algorithm).
* If "offset" is NULL, then the checksum will be calculated but the
* checksum bytes will not be set.
* If "offset" is non-NULL, the checksum bytes at "offset" will be set
* such that the checksum accumulations, when recalculated, will both
* be zero.
* return : checksum accumulations
*/
int checksum(buffer, len, offset)
octet *buffer;
int len, offset;
{
unsigned int c0 c1;
int cs;
long ctmp, cl0, cl1;
octet *hpp, *pls;
if (offset) {
Copeland/Riechmann Expires March 1998 [Page 26]
INTERNET-DRAFT September 1997
buffer[offset] = 0;
buffer[offset+1] = 0;
ctmp = len - offset - 1 ;
}
pls = buffer + len;
c0 = c1 = 0;
hpp = buffer;
while (hpp < pls) {
if ((c0 += *hpp++) > 254) { c0 -= 255; }
if ((c1 += c0) > 254) { c1 -= 255; }
} /* while */
if (offset) {
cl0 = c0;
cl1 = c1;
if ((cs =((ctmp * cl0) - cl1) % 255L) < 0) { cs += 255; }
buffer[offset] = cs;
if ((cs =(cl1 -((ctmp + 1L) * cl0)) % 255L) < 0) { cs += 255; }
buffer[offset+1] = cs;
} /* if (offset) */
return(c0 | c1);
}
Security Considerations
Security considerations are not discussed in this memo.
Author's Addresses:
Phil Copeland Christian Riechmann
TNO/FEL FGAN/FFM
Oude Walsdorperweg 63 Neuenahrer Strasse 20
PO Box 96864 D-53343 WACHTBERG
2509 JG Den Haag Germany
Netherlands Phone: (+49) 228 9435 533
Phone: (+31) 70 3740305 Fax: (+49) 228 348 953
Fax: (+31) 70 3280961 Email: riechmann@fgan.de
Email: copeland@fel.tno.nl
Copeland/Riechmann Expires March 1998 [Page 27]