INTERNET-DRAFT P_MUL C. Riechmann Expires October 1999 FGAN/FKIE April, 1999 P_Mul: An Application Protocol for the Reliable Data Transfer over Multicast Subnetworks and under EMCON Restrictions (draft-riechmann-multicast-emcon-00.txt) Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract P_Mul is a proposal for an application protocol for the transfer of messages (e.g. email, files) 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) or "Radio Silence" means that, although receiving nodes are able to receive messages, they are not able to acknowledge the reception of these messages. P_Mul does not require any further multicast features except those of a "simple" multicast routing protocol (DVMRP, MOSPF Riechmann Expires October 1999 [Page 1] INTERNET-DRAFT P_MUL April 1999 or PIM). The protocol described below has already been applied to the transfer of messages between X.400 Message Transfer Agents (MTA) and for the transfer system for RFC822 messages (sendmail). It has also been applied to other tasks (e.g. file distribution) taking profit from the multicast communication service. This Internet Draft is a revised and extended version of "draft- riechmann-multicast-mail-00.txt" written by P. Copeland and C. Riechmann and published in Sept. 1997. The main difference from the former version is the description of new data structures and procedures to be used for forming dynamically recipient specific multicast groups. Table of Contents 1. Introduction 2. Protocol Layering 3. Protocol Data Units (PDU) 3.1. PDUs to Agree Dynamically about New Multicast Groups 3.1.1. Request_/Reject_/Release_PDU 3.1.2. Announcement_PDU 3.2. PDUs for Data Transfer 3.2.1. Address_PDU 3.2.2. Data_PDU 3.2.3. Discard_Message_PDU 3.2.4. ACK_PDU 4. Multicast Group forming Procedure 4.1. Request of a Multicast Group 4.2. Reject of a Multicast Group 4.3. Release of a Multicast Group 4.4. Announcement to join a Multicast Group 5. Messaging Procedures 5.1. Transmission and Re-transmission of a Message 5.2. Reception of a Message 5.3. Acknowledgement of a Message 6. Examples 6.1. Example for the Agreement about New Multicast Groups 6.2. Example for Data Transfer 7. References A. Appendix A.1. Abbreviations A.2. Predefined Protocol Parameters A.3. Proposed Multicast Group Addresses (for organisational purposes) A.4. Proposed UDP Port Numbers A.5. Proposed Algorithm for the Checksum Riechmann Expires October 1999 [Page 2] INTERNET-DRAFT P_MUL April 1999 1. Introduction Within this proposal the word "message" shall be understood as a data object like an email, a X.400 P1 information structure or simply a file etc. The objective of this protocol is to take advantage of multicast communication service for the transfer of messages between different nodes on a single multicast network under normal - which means dialogue oriented - communication conditions and under EMCON conditions. EMCON or "Radio Silence" condition means that a receiving node is able to receive messages, but it cannot - for a relative 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 transmitting NODE 1 to receiving NODE 2 and to receiving NODE 3. +--------+ /->| NODE 2 | +--------+ +-------+ / +--------+ | NODE 1 |<----->| Router|< +--------+ +-------+ \ +--------+ \->| NODE 3 | +--------+ Figure 1: Typical Messaging or File Distribution Configuration Using the multicast communication service instead of the unicast communication service in the above multicast configuration (Figure 1) only one message transmission from NODE 1 to 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 reduction in bandwidth utilisation becomes even greater with every additional receiving node. Althugh P_Mul is based on a connectionless transport protocol to transmit messages, it offers that kind of reliability to the requesting applications, they need to be sure that their receiving partner applications have received the data and have taken the control for any further processing. This reliable message transfer is supported even in those cases, when for a certain period of time one or more of the receiving nodes are not able or allowed to acknowledge completely received messages. In such a case the message transfer will be continued after the the Riechmann Expires October 1999 [Page 3] INTERNET-DRAFT P_MUL April 1999 communication link has been reset into normal (bi-directional) communication mode. It should be mentioned that if a message has totally been received during the stated EMCON mode, this message can be processed as required, while the P_Mul implementation will take care for a postponed acknowledgement. The protocol P_Mul has been applied to the communication between X.400 MTAs and between RFC822 mailservers, but it is not constrained to these applications; it has also been applied to other kinds of reliable multicast transmission, e.g. file distribution. P_Mul does not require any further multicast features except those of a "simple" multicast routing protocol (DVMRP, MOSPF or PIM). The application scenario of P_Mul should be understood as a network environment consisting of hundreds of nodes but not of thousands or more. Additionally in this scenario a reliable and provable message transfer is requested. This protocol P_Mul does not only work under the assumption of well defined fixed multicast groups and a wellknown knowledge within each participating node about the group memberships to one or more multicast groups of all other participating nodes. It also has a feature to request dynamically the formation of adhoc multicast groups just for the transmission of a single message. In the latter case such a dynamically formed multicast group covers just the intended set of receiving nodes. 2. Protocol Layering As mentioned above this protocol may be understood as an application layer protocol, in the same way as the P1 protocol defined in the X.400 Recommendations [CCITT88] or the SMTP protocol [SMTP82-1]. As in the case of these protocols, P_Mul will use the lower layer protocols to transmit its PDUs (Protocol Data Units) over the multicast network. As P_Mul is to a certain extent "self-contained", it does not use additional multicast router functions as they are required for some recently published multicast protocols. Considering the fact that nodes under EMCON are not allowed to exchange any messages with their partner nodes, they are not able to use a reliable transport protocol like "RMP" [RMP95-1, RMP95-2, RMP95-3] or "XTP" [XTP95] for the transfer of messages. To support this fact P_Mul is based on the unreliable connectionless transport protocol "UDP" [UDP80]. Riechmann Expires October 1999 [Page 4] INTERNET-DRAFT P_MUL April 1999 For X.400 systems P_Mul is implemented within an MTA. A sample implementation has been done using the X.400 Message Handling System package available from Isode Limited, UK. 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 Functions' mentioned in following chapters. For the RFC822 mail application [SMTP82-2] P_Mul is implemented on behalf of a special mailer replacing the conventional SMTP mailer. A prototype implementation has been done for the sendmail system (sendmail version 8.8.x). A further application using P_Mul as transfer protocol is "Multicast File Distribution". In this case the application allows one user to distribute one file simultaneously to a set of receiving nodes e.g. distribution of software or weather maps. Because this was not an already existing application, the relatively simple user interface has been integrated "around" the P_Mul implementation. Concerning data transfer during EMCON it should be remarked, that the advantages of the multicast technique can only be used, if the routers or network adaptors are prepared to support multicast traffic over uni-directional communication links and if specific multicast groups to be used for the EMCON traffic have already been dynamically installed during the pre-EMCON phase or statically installed by network configuration mechanisms. 3. Protocol Data Units (PDU) There are two groups of protocol data units: One group consists of those PDUs being used only for dynamic configuration of multicast groups. The other group consists of those PDUs needed for the transfer of data itself. As long as it is acceptable to have only a fixed set of multicast groups to be supported by the implementation of the P_Mul transfer protocol only the latter group of PDUs (for Data Transfer - see 3.2. -) is needed. As the P_Mul implementing processes have to keep track about the states of the message transfer (connections) between the sending node and the different receiving node, all PDUs are sent using the UDP protocol. Riechmann Expires October 1999 [Page 5] INTERNET-DRAFT P_MUL April 1999 Normally, all PDUs delivered by the sending node of a message are transmitted using the multicast communication service. Only in case that there (still) exists only one receiving node, the sending node may or should switch into unicast mode. All PDUs sent by the receiving nodes back to the sending node are transmitted in unicast mode. 3.1. PDUs to Agree Dynamically about New Multicast Groups We are assuming that we have a set of nodes interested in multicast message transfer; all these nodes have to be connected to a multicast supporting network. The total set consists of a subset "T" of potentially transmitting and of a subset "R" of potentially receiving nodes. Both subsets normally have a non empty intersection. The communication for this group management is based on having installed one globally known multicast group address. All members of T and R must join this "Group Management Group (GMG)". Next to allow different communication channels for T and R we assume that there are two wellknown ports "TPORT" and "RPORT". All transmitting nodes within T shall read PDUs with the addressing information GMG and TPORT; while all receiving nodes within R shall read PDUs being addressed for GMG and RPORT. (For information: The data transmission itself will be carried through on behalf of the dynamically installed multicast group and two additional ports "DPORT" (Data_Port) and "APORT" (Acknowledgement_Port)). For the dynamic installation of a multicast group 4 types of PDUs are defined: * Requesting a Multicast Group (Request_PDU) * Rejecting a Multicast Group (Reject_PDU) * Releasing a Multicast Group (Release_PDU) * Announcing a Multicast Group (Announce_PDU). The first 3 PDU types are used only for a communication between the transmitter within a sending node and all other members of T. The fourth PDU type is created by that node of T, which is in the state of installing of a new multicast group. This PDU is sent to the nodes within the set R, being addressed by the global group GMG with port RPORT. This PDU type is used to inform all those receiving nodes, which shall join the new group. The fourth PDU shall only be used after it has been agreed upon among the members of T. This case is denoted: "The transmitting node owns this specific multicast group". After the completion of message transfer it is the task of the owner Riechmann Expires October 1999 [Page 6] INTERNET-DRAFT P_MUL April 1999 of a multicast group to release it. 3.1.1 Requesting/Rejecting/Releasing a Multicast Group These 3 PDU types have the very same simple structure. They only contain few informations and differ only within the field PDU_Type: 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 | unused | | PDU_Type | +-------------------------------+---------------+---+-----------+ | unused | Checksum | +-------------------------------+-------------------------------+ | Source_ID | +---------------------------------------------------------------+ | Message_ID (MSID) | +---------------------------------------------------------------+ | Multicast_Group | +---------------------------------------------------------------+ Description of fields: Length_of_PDU: The field (2 octets) indicates the total number of octets within this PDU. PDU_Type: This 6-bit field specifies the type of the actual PDU. PDU_Types are either Request_PDU (X'05) or Reject_PDU (x'06') or Release_PDU (x'07'). 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 PDU. This ID must be unique for the actual multicast network (e.g. the Internet address of the specific multicast interface of the sending MTA node). Message_ID: MSID is a unique identifier built within the scope of Source_ID Riechmann Expires October 1999 [Page 7] INTERNET-DRAFT P_MUL April 1999 by the transmitter (e.g. derived from the seconds since 00:00:00 1.1.1970 - Unix Time -). Multicast_Group This field holds the address of a multicast group, which shall be either requested or released or rejected. 3.1.1.1 REQUEST_PDU The REQUEST_PDU is distributed to all members of T by using group GMG and port TPORT by that node, which wishes to initiate a new multicast message transmission. 3.1.1.2 Reject_PDU The Reject_PDU is used if one member of T already "owns" this multicast group. It is sent to the requesting node using the unicast addressing mode. 3.1.1.3 Release_PDU The Release_PDU is used in two situations: (a) after the sender has received a Reject_PDU. (b) after a transmission has been finished, and This PDU type is used to inform those members of T keeping track of used multicast group addresses, which this particular sender will no longer be interested in this particular multicast address. 3.1.2 Announcing a Multicast Group using the Announce_PDU This PDU type is used by the sending node to inform those nodes of R, which are intended receiving nodes for a specific message. As P_Mul has to observe a maximum PDU_size and as the number of Destination_IDs has no maximum value limitation, it is necessary to be able to split the total group information into more than one Announce_PDUs. To distinguish between the first, middle, or last Announce_PDU the MAP field ("More Address_PDUs") is used. Riechmann Expires October 1999 [Page 8] INTERNET-DRAFT P_MUL April 1999 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 | unused |MAP| PDU_Type | +-------------------------------+---------------+---+-----------+ | Count_of_Destination_Entries | Checksum | +-------------------------------+-------------------------------+ | Source_ID | +---------------------------------------------------------------+ | Message_ID (MSID) | +---------------------------------------------------------------+ | Expiry_Time | +---------------------------------------------------------------+ | Announced_Multicast_Group | +---------------------------------------------------------------+ | List_of_Destination_IDs (variable length) | : : | | +---------------------------------------------------------------+ Destinations_ID: 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 | +---------------------------------------------------------------+ Description of fields: Length_of_PDU: The field (2 octets) indicates the total number of octets within this PDU. MAP: This 2-bit field specifies whether this Announce_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 Announce_PDUs. '1': This is NOT the first one of a set of Announce_PDUs. The low order bit is set to '0': This is the last one of a set of Announce_PDUs. '1': This is NOT the last one of a set of Announce_PDUs. In the case both bits are set to zero, only one Announce_PDU Riechmann Expires October 1999 [Page 9] INTERNET-DRAFT P_MUL April 1999 exists. PDU_Type: This 6-bit field specifies the type of the actual PDU. PDU_Type x'04' denotes an Announce_PDU. Count_of_Destination_Entries: These 2 octets hold the total number of Destination_IDs within the List_of_Destination_IDs of this PDU. 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 Announce_PDU. This ID must be unique for the actual multicast network (e.g. the Internet address of the specific multicast interface of the sending MTA node). Message_ID: MSID is a unique identifier built within the scope of Source_ID by the transmitter (e.g. derived from the 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 -. This time is requested by the application (e.g. in case of X.400 from the Latest_Delivery_Time of the X.400 message). 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. Announced_Multicast_Group: This 4-octet field holds the address of the multicast group to be announced for the message transfer denoted by Source_ID and MSID. List_of_Destination_IDs: This is a variable length field containing a list of Destination_ID of the intended receiving nodes for the message denoted by Source_ID and MSID. Destination_ID: This field holds the ID of an intended receiving node (e.g. the Riechmann Expires October 1999 [Page 10] INTERNET-DRAFT P_MUL April 1999 Internet address of the specific receiving node). 3.2. PDUs for Data Transfer The number of PDUs used by P_Mul for data transfer is mainly determined by the fact that this protocol should also be suited for communication under EMCON or "Radio Silence" 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 * Discard_Message_PDU. Other types of PDUs, for example like "Recovery Packet" or "Alarm Packet" as defined for RMP, are not needed in this context. 3.2.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) | : : | | +---------------------------------------------------------------+ Riechmann Expires October 1999 [Page 11] INTERNET-DRAFT P_MUL April 1999 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_Symmetric_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 | +---------------------------------------------------------------+ | Symmetric_Key (variable length) | : : | | +---------------------------------------------------------------+ Description of fields: Length_of_PDU: The field (2 octets) indicates the total number of octets within this PDU. Priority: This 1-octet field enables the sending node to inform the other nodes that at the sending node 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. Riechmann Expires October 1999 [Page 12] INTERNET-DRAFT P_MUL April 1999 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 (e.g. the Internet address of the specific multicast interface of the sending node). Message_ID: MSID is a unique identifier built within the scope of Source_ID by the transmitter (e.g. derived from the 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 -. This time is requested by the application (e.g. in case of X.400 from the Latest_Delivery_Time of the X.400 message). 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 Symmetric_Key, which is encrypted with the public key of each receiving site. Riechmann Expires October 1999 [Page 13] INTERNET-DRAFT P_MUL April 1999 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 Symmetric_Key being encoded by the public key owned by this Destination_ID designated receiver. Length_of_Symmetric_Key: These 2 octets specify the length of the public key encoded "Symmetric_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 node on the actual multicast network (e.g. the Internet address of the receiving node). 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. Symmetric_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 nodes, will be asymmetrically encoded by the public key of each receiving node and transmitted within this field. Each receiving node 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.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. Riechmann Expires October 1999 [Page 14] INTERNET-DRAFT P_MUL April 1999 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) | : : | | +---------------------------------------------------------------+ Description of fields: Length_of_PDU: The field (2 octets) indicates the total number of octets within this PDU. Priority: This 1-octet field enables the sending node to inform the other nodes that at the sending node 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 Riechmann Expires October 1999 [Page 15] INTERNET-DRAFT P_MUL April 1999 network (e.g. the Internet address of the specific multicast interface of the sending node). Message_ID: MSID is a unique identifier built within the scope of Source_ID (e.g. derived from the seconds since 00:00:00 1.1.1970 - Unix Time -). Fragment of DATA: This portion of the Data_PDU holds the message or only fragments of it. 3.2.3. Discard_Message_PDU This PDU is used to inform the receiving nodes, 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 nodes. In this case the sending node 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) | +---------------------------------------------------------------+ Description of fields: Length_of_PDU: The field (2 octets) indicates the total number of octets within this PDU. Priority: This 1-octet field enables the sending node to inform the other nodes that at the sending node there exists at least one message with the denoted priority (for further study). The value 0 denotes the highest priority. PDU_Type: Riechmann Expires October 1999 [Page 16] INTERNET-DRAFT P_MUL April 1999 This 6-bit field specifies the type of the actual PDU. PDU_Type x'03' denotes a Discard_Message_PDU. 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 (e.g. the Internet address of the specific multicast interface of the sending node). Message_ID: MSID is a unique identifier built within the scope of Source_ID by the transmitter (e.g. derived from the seconds since 00:00:00 1.1.1970 - Unix Time -). 3.2.4. ACK_PDU This PDU is generated by a receiving node identified by the Source_ID_of_ACK_Sender and is used to inform the sending node 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 node. 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) | : : | | +---------------------------------------------------------------+ Riechmann Expires October 1999 [Page 17] INTERNET-DRAFT P_MUL April 1999 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 | : : | | +-------------------------------+ Description of fields: Length_of_PDU: The field (2 octets) indicates the total number of octets within this PDU. Priority: This 1-octet field enables the sending node to inform the other nodes that at the sending node 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. Checksum: The checksum will be built by using one of the currently available checksum algorithms and is calculated over the rest of Riechmann Expires October 1999 [Page 18] INTERNET-DRAFT P_MUL April 1999 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 (e.g. the Internet address of the specific multicast interface of the ACK_PDU sending node). 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. 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. Its value is equivalent to the value "Source_ID" of the corresponding Address_PDU. Message_ID: MSID is a unique identifier built by the sender (e.g. derived from the seconds since 00:00:00 1.1.1970 - Unix Time -). Its value is equivalent to the value "Message_ID" of the corresponding Address_PDU. List_of_Missing_Data_PDUs: This field contains the list of the order numbers of those Riechmann Expires October 1999 [Page 19] INTERNET-DRAFT P_MUL April 1999 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. Multicast Group forming Procedure A dynamic installation of multicast groups seems to be a usefull method for reducing the overall network load within a multicast network, specially in cases when the sender of a message or a file has exact knowledge about the addresses of the intended receiving nodes. The objective of the following mechanism is, that the multicast transmission of a message will only influence as few parts of the total network as possible. Joining and leaving of a multicast group are requests to influence the distribution tree for the multicast packets, which is heavily dependent on the dialogue between neighbour routers. Therefore this "Group forming Procedure" will be advantageous, if during this procedure none of the network links between the sending node and the intended receiving nodes are under EMCON condition. 4.1. Request of a Multicast Group First the sending node has to determine an address for the multicast group which shall be dynamically installed. This multicast address can be chosen by different methods, some of them are mentioned here: * selection from a set of multicast addresses, which is predefined and mutually excluding for each member of T, * random choice from a predefined set of multicast addresses or * on behalf of MADCAP (Multicast Address Dynamic Client Allocation Protocol) from a multicast address allocation server[MADCAP99]. Riechmann Expires October 1999 [Page 20] INTERNET-DRAFT P_MUL April 1999 As soon as the members of T have received this PDU, each of them has to test whether from its local point of knowledge this multicast group is already in use. To reduce the network load "Silent Procedure" is agreed. Only if the requested group is already in use, the particular node should reject this PDU. 4.2. Rejecting a Multicast Group If a transmitter detects that another sending node is requesting a multicast group address, which it already has in use, it should reject this request by sending a Reject_PDU. If the requesting sending node receives such a Reject_PDU it has to revoke its request by the transmission of a corresponding Release_PDU and to renem its request with a new multicast group address. If that node is under EMCON condition this rejection is not possible. Therefore the use of the requested multicast group will result in some additional overall network load. The same effect will occur, if the particular sending node, which already owns the requested multicast group, does not receive the Request_PDU or if the Reject_PDU is not received by the requesting sending node. If all members of T keep track about the ownership of the requested multicast group addresses, it can be expected that a rejection occurs very seldom. 4.3. Release of a Multicast Group There are 2 situations for the sending node to release a once requested multicast group address: (a) after having received a Reject_PDU or (b) after the transmission of a message has been finished. 4.4. Announcement to join a Multicast Group After the transmission of the concerning Request_PDU the requesting sending node waits a certain time (WAIT_FOR_REJECT_TIME) to receive Reject_PDUs from one member of T. After this time has expired without having received a Reject_PDU, because of "Silent Procedure", it announces the requested multicast group address to all receiving nodes. Once a multicast group has been announced, the late reception of a corresponding Reject_PDU will be ignored. Riechmann Expires October 1999 [Page 21] INTERNET-DRAFT P_MUL April 1999 This information is sent by the sending node on behalf of the Announce_PDU to the global group GMG and port RPORT. The reception of the Announce_PDU is most important for the reception of the following data transferring PDUs, therefore it seems to be reasonable to have a multiple transmission of this PDU. The number of the re-transmissions of the Announce_PDU is specified within ANNOUNCE_CT. As soon as the members of R have received this PDU each of them has to decide, whether it has to become a member of the announced group depending on they are mentioned in the List_Destination_IDs. If no, it can forget about this Announce_PDU; if yes, it has to join the the multicast group denoted by the actual Announce_PDU. The announcing sending node has to wait a certain period of time (ANNOUNCE_DELAY) until it can be expected that all routers within the multicast tree are informed about the group memberships of those nodes of the List_Destination_IDs. After this time expired the real data transfer can be started. After this announcing phase the transmitting node assumes that the intended receiving nodes have received the Announce_PDU and therefore have joint the Announced_Multicast_Group. It will start the first data transmission phase and transmit the Address_PDU(s) and Data_PDU(s) and wait for ACK_PDU(s). Before the transmitting node restarts a re-transmission phase it has to check whether it can be sure that all intended receiving nodes had received the Announce_PDU. This decision can be made upon the fact, whether it received an ACK_PDU from each intended receiving node. If not the re-transmission phase starts with a re-transmission of the eventually updated Announce_PDU according to the above rules concerning ANNOUNCE_DELAY and ANNOUNCE_CT followed by the next data transmission phase. 5. Messaging Procedures The following describes the messaging procedures to be employed between a transmitting node and one or more receiving nodes 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 Riechmann Expires October 1999 [Page 22] INTERNET-DRAFT P_MUL April 1999 * Acknowledgement 5.1. Transmission and Re-transmission of a Message An node shall initiate the transmission of a message by firstly transmitting an Address_PDU containing a list of all the nodes that are to receive the message. The transmitting node shall be made aware, by a 'Higher Management Function', which of the receiving nodes are in the non-EMCON and EMCON mode of operation. The transmitting node shall, based on the supplied mode of operation information, create a list of non-EMCON receiving nodes, from which it shall expect to receive ACK_PDUs. On completion of transmission of the Address_PDU the transmitting node 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. To avoid network congestion the transmitting node has to wait a certain amount of time (PDU_DELAY) before sending the next PDU. Each transmitting node must be prepared to receive ICMP messages indicating network congestion. As the event of network congestion can be caused by any other network traffic, it is recommended that the value of PDU_DELAY shall be decreased as soon as for a certain amount of time no congestion message is received. As soon as such a congestion message is received, the transmission of the following PDUs must be slowed down. This is easily done by increasing the actual value of PDU_DELAY. On completion of transmission of the last Data_PDU of a message the transmitting node shall initialise a "Transmitter Expiry_Time Timer" and an "EMCON Re-transmission Counter" (EMCON_RTC), if one or more of the receiving nodes is in the EMCON mode, and enter the non-EMCON or EMCON Re-transmission mode (see para. 5.1.3 resp. 5.1.4). 5.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 nodes have not acknowledged receipt of the complete message, this timer expires, the transmitting node 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. Riechmann Expires October 1999 [Page 23] INTERNET-DRAFT P_MUL April 1999 If, after having transmitted a Discard_Message_PDU, the transmitting node 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 node receives an ACK_PDU indicating receipt of the complete message, it shall disregard the ACK_PDU. If all the receiving nodes addressed in the Destination part of the Address_PDU acknowledge the receipt of the complete message before this timer expires, the timer shall be stopped. 5.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. 5.1.3. Non-EMCON Re-transmission The transmitting node shall enter this mode when one or more of the receiving nodes is in the non-EMCON mode. On entering this mode the transmitting node 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". 5.1.3.1. Ack Re-transmission Timer This timer shall be initialised when one or more of the receiving nodes are in the non-EMCON mode. The duration of this timer shall be derived from the maximum round trip delay plus a safeguard. Experiments proved that the duration of this timer should not be fixed and that the following algorithm works very well: Every next re-transmission increases this value of the timer by a certain amount or factor. If, in the event all the receiving nodes in the non-EMCON mode respond with an ACK_PDU before this timer expires, the transmitting node shall either: a. in the event that one or more of the ACK_PDUs indicate that a receiving node is missing Data_PDUs, re-transmit all the Riechmann Expires October 1999 [Page 24] INTERNET-DRAFT P_MUL April 1999 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 nodes in the EMCON mode the transmitting node shall enter the EMCON Re-transmission mode. If one or more of the receiving nodes 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 node shall either: a. in the event that it has not received a previous ACK_PDU from the receiving node, 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 node, only re-transmit the possibly updated Address_PDU and all the previously indicated missing Data_PDUs and re-initialise the timer. Note: As the reception of the ACK_PDUs has a strong impact to the overall network performance, at least for lossy networks, duplicate transmission of the ACK_PDUs is recommended. 5.1.3.2. Receipt of Message Complete ACK_PDU When a transmitting node receives an ACK_PDU from a non-EMCON or EMCON receiving node 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 node 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 node removed from the List_of_Destination_Entries field in the Address_PDU. After all receiving nodes have completely acknowledged, an Address_PDU containing an empty List_of_Destination_Entries has to transmitted. If the particular multicast group is one which was dynamically agreed upon the transmitting node shall now transmit a Release_PDU for the particular multicast group to the group of all transmitters (GMG,TPORT). 5.1.4. EMCON Re-transmission Riechmann Expires October 1999 [Page 25] INTERNET-DRAFT P_MUL April 1999 The transmitting node shall enter this mode as soon as all receiving nodes are in the EMCON mode. On entering this mode the transmitting node shall initialise the "EMCON Re-transmission Timer" (EMCON_RTI). 5.1.4.1. EMCON Re-transmission Timer This timer (EMCON_RTI) shall be initialised when all the receiving nodes 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 nodes 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 node 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 node shall wait until either: a. one or more of the receiving nodes 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. If, in the event one or more of the receiving nodes 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 node shall stop the timer and enter the "Non-EMCON Re-transmission" mode (see para. 5.1.3). 5.2. Reception of a Message The "Reception of a Message" mode shall be initiated when the receiving node receives either an Address_PDU or Data_PDU. 5.2.1. Receipt of an Address_PDU On receipt of an Address_PDU the receiving node shall first check whether the Address_PDU with the same tuple "Source_ID, MSID" has already been received. If such an Address_PDU has already been received the receiving node 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, Riechmann Expires October 1999 [Page 26] INTERNET-DRAFT P_MUL April 1999 re-transmit the message complete ACK_PDU and discard the Address_PDU else b. if its own ID does not exist in the List_of_Destination_Entries and it has previously sent a message complete ACK_PDU for this message, it knows that its own ACK_PDU has been successfully received by the sending node. Therefore it can release all information about this message and its membership to the eventually dynamically created multicast group and discard the Address_PDU else b. discard the Address_PDU. If the Address_PDU has not been previously received the receiving node 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 node 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 node 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 node shall update the status of the Data_PDU entry (see para. 5.2.2) to a message entry. In addition the receiving node shall stop the "Delete-Data_PDUs Timer" (see para. 5.2.2.1) and initialise the "Receiver Expiry_Time Timer". The receiving node shall then determine whether to enter the "Acknowledgement of a Message" mode (see para. 5.2.3). 5.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 node has not received all the Data_PDUs associated with a message, the receiving node shall discard Riechmann Expires October 1999 [Page 27] INTERNET-DRAFT P_MUL April 1999 the associated Data_PDUs and Address_PDU. 5.2.2. Receipt of a Data_PDU On receipt of a Data_PDU the receiving node shall first check whether the Data_PDU has already been received. If the Data_PDU has already been received the receiving node shall: a. if the receiving node has not received a duplicate of the associated Address_PDU (see para. 5.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 node 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 node shall update the status of the message entry and determine whether to enter the "Acknowledgement of a Message" mode (see para. 5.2.3). If the associated Address_PDU has been received but no message entry exists the receiving node shall discard the Data_PDU. If the associated Address_PDU has not been received the receiving node 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 node shall create a Data_PDU entry and await reception of the associated Address_PDU. In addition the receiving node shall initialise a "Delete Data_PDUs Timer" (see para. 5.2.2.1). If there exists a Data_PDU entry associated with this Data_PDU, the receiving node shall update the status of the Data_PDU entry and await reception of the associated Address_PDU. 5.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 node 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 node shall discard Riechmann Expires October 1999 [Page 28] INTERNET-DRAFT P_MUL April 1999 all Data_PDUs. 5.2.3. Entry to "Acknowledgement of a Message" Having updated the status of a message entry, the receiving node 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 node shall enter the "Acknowledgement of a Message" mode (see para. 5.3). In the event neither of the above is true the receiving node shall remain in the "Reception of a Message" (see para. 5.2) 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 node shall remain in the "Reception of a Message" mode. Note: It should be mentioned that after entering this message status the reception of any further Discard_Message_PDU or the Expiry_time of the message exceeds these particular events shall be ignored by the receiving node. Both events will be effective only before all PDUs of the message have been received. Because being in EMCON the completion acknowledgement of the message will be transmitted to the transmitting node when the non-EMCON mode will be re-entered. 5.2.4. Receipt of a Discard_Message_PDU In the event that a receiving node 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. If a special multicast group has been dynamically created for this specific message, the receiving node shall release this group now. 5.3. Acknowledgement of a Message The "Acknowledgement of a Message" mode shall only be entered by a receiving node that is in the non-EMCON mode of operation. The "Acknowledgement of a Message" mode procedures shall be dependent on Riechmann Expires October 1999 [Page 29] INTERNET-DRAFT P_MUL April 1999 whether the receiving node received the messages in the non-EMCON mode, (see para. 5.3.1) or in the EMCON mode, (see para. 5.3.2). To avoid the problem of ACK implosion on the message transmitting site, in the event that the receiving node has several ACK_PDUs to transmit, each transmission of an ACK_PDU should be delayed by a randomly determined period of time interval. 5.3.1. Receiving node in Non-EMCON A receiving node 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. 5.3.1.1. Last Data_PDU Received If the last Data_PDU of a message has been received, the receiving node shall determine whether there are any missing Data_PDUs in the message. Note: Experiments especially with large messages and in cases of asymmetric network connections (fast "forward" link from the sending node and a slow "backward" link from the receiving node to the sending node) showed that in case of a loss of the ACK_PDU unnecessary re- transmissions occur, which can be avoided/reduced by a duplicate transmission of the ACK_PDU. 5.3.1.1.1. Missing Data_PDUs If there are missing Data_PDUs the receiving node 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" (see para. 5.2) mode or b. if an ACK_PDU associated with this message had been previously transmitted, the receiving node shall return to the "Reception of a Message" (see para. 5.2) mode. 5.3.1.1.2. Received Complete Message If there are no missing Data_PDUs the receiving node 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 Riechmann Expires October 1999 [Page 30] INTERNET-DRAFT P_MUL April 1999 Application'. On completion of transmission of the ACK_PDU the receiving node shall return to the "Reception of a Message" (see para. 5.2) mode. 5.3.1.2. 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 node to be missing M Data_PDUs, without having received the last Data_PDU, therefore: A receiving node 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 node 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 node 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 node shall return to the "Reception of a Message" (see para. 5.2) mode. 5.3.2. Receiving node leaving EMCON If the receiving node 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. 5.3.1. 5.3.2.1. Last Data_PDU Received If the last Data_PDU of a message has been received, the receiving node shall determine whether there are any missing Data_PDUs in the Riechmann Expires October 1999 [Page 31] INTERNET-DRAFT P_MUL April 1999 message. 5.3.2.2. Missing Data_PDUs If there are missing Data_PDUs, the receiving node shall transmit an ACK_PDU listing denoting, which Data_PDUs are missing, and initialise an associated "ACK_PDU Timer" (see para. 5.3.2.4). If there are N missing Data_PDUs and N > M the receiving node 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. 5.3.1.4). The receiving node shall initialise an associated "ACK_PDU Timer" with each ACK_PDU transmitted. On completion of transmission of the ACK_PDU(s) the receiving node shall then return to the "Reception of a Message" mode. 5.3.2.3. Received Complete Message If there are no missing Data_PDUs, (e.g. tagged as complete, see para. 5.2.3), the receiving node shall transmit an ACK_PDU indicating that the message is complete and initialise the "ACK_PDU Timer". The receiving node 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 node shall return to the "Reception of a Message" mode. 5.3.2.4. ACK_PDU Timer The "ACK_PDU Timer" shall be initialised for every ACK_PDU transmitted by a receiving node, 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 node receives a response to a transmitted ACK_PDU from the transmitting node 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 node does not receive a response to the transmitted ACK_PDU(s) from the transmitting node in the form of the requested missing Data_PDUs or an Address_PDU, an "ACK_PDU Timer" expires, the receiving node shall re-transmit the associated ACK_PDU(s) and re-initialise the timer. Riechmann Expires October 1999 [Page 32] INTERNET-DRAFT P_MUL April 1999 6. Examples The following examples shall explain, how the PDUs are used between different nodes on a multicast network. They shall give only an impression, how the protocol works. Therefore the packets are described as a sort of function calls. 6.1. Example for the Agreement about New Multicast Groups This example shall give a rough impression, how a new multicast group is agreed upon among all transmitting nodes and announced to the receiving nodes. All these nodes must have joint the multicast group GMG. It is assumed that M0 is the sending node, which sends one message to the nodes M1, M2, M3 and M4. Only M3 and M4 are assumed to be under EMCON. First M0 selects (randomly?) a new multicast group address (e.g. 240.1.2.3) and transmits a corresponding Request_PDU to GMG: Request_PDU( Source_ID=M0, MSID=9876, Multicast_Group=240.1.2.3) We assume that some node within the network already "owns" this multicast group address. This node will detect this collision and will send directly (unicast) to M0 a corresponding Reject_PDU. Reject_PDU( Source_ID=M0, MSID=9876, Multicast_Group=240.1.2.3) As soon as M0 receives this Reject_PDU, it releases its old request by transmitting a corresponding Release_PDU. Additionally it restarts a new request with another multicast group address (e.g. 240.1.2.4). Release_PDU( Source_ID=M0, MSID=9876, Multicast_Group=240.1.2.3) Request_PDU( Source_ID=M0, MSID=9876, Multicast_Group=240.1.2.4) We assume that this multicast group address is not already in use or that only a node being in EMCON owns this group. Therefore after the waiting time WAIT_FOR_REJECT_TIME expires, M0 has not received any corresponding Reject_PDU. As a consequence after WAIT_FOR_REJECT_TIME has expired M0 transmits a corresponding Announce_PDU: Announce_PDU( Source_ID=M0, MSID=9876, Expiry_Time=1200, Announced_Multicast_Group=240.1.2.4, Dests=(Cnt=4,Dest_ID=(M1,M2,M3,M4))) After the transmission of this Announce_PDU any further reception of a corresponding Reject_PDU has to be discared. M0 starts now the Riechmann Expires October 1999 [Page 33] INTERNET-DRAFT P_MUL April 1999 timer ANNOUNCE_DELAY to enable the intended receiving nodes to join the announced multicast group and to enable the routers within the network to build the new multicast routing structure. Note: As the reception of the Announcement_PDU is necessary for the binding of of a receiving node to a multicast group and the construction of the Multicast_Routing_Tree it is reasonable to transmit this PDU repeatedly (see para. 4.4). 6.2. Example for Data Transfer This example shall give a rough impression, how the data transfer is coordinated. In continuation of the example in (6.1.) it is assumed that M0 is the sending node, which sends one message to the nodes 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. 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, Expiry_Time=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))) Riechmann Expires October 1999 [Page 34] INTERNET-DRAFT P_MUL April 1999 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, Expiry_Time=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: 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, Expiry_Time=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 for this particular message has been exceeded. M0 will send the following PDU: Discard_Message_PDU( Source_ID=M0, MSID=9876) After a further period of time M4 leaves EMCON and has to send its ACK_PDU. As assumed M4 has received the total message before the Riechmann Expires October 1999 [Page 35] INTERNET-DRAFT P_MUL April 1999 Expiry_Time has been exceeded, it will send the following ACK_PDU: 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 destinated application process 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, Expiry_Time=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 nodes. This means,that all information about the message MSID=9876 of M0 can be deleted. In case that this message has been sent to a multicast group dynamically been agreed upon, the transmitter will now release this group address by transmitting a Release_PDU to all members of the multicast group GMG: Release_PDU( Source_ID=M0, MSID=9876, Multicast_Group=240.1.2.4) 7. 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 [MADCAP99] B. V. Patel, M. Shah, S. R. Hanna: "Multicast Address Dynamic Client Allocation Protocol (MADCAP)", Internet-Draft, Feb. 1999 [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 Riechmann Expires October 1999 [Page 36] INTERNET-DRAFT P_MUL April 1999 [RMP95-3] T. Montgomery, B. Whetten, J.R. Callahan: "The Reliable Multicast Protocol Specification - Flow Control and NACK Policy -", Internal Documentation, October 5, 1995 [SMTP82-1] J. Postel: "Simple Mail Transport Protocol", RFC821, August 1982 [SMTP82-2] D. Crocker: "Standard for the format of ARPA Internet text messages", RFC822, August 1982 [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 GMG Group Management Group MAP More Address_PDUs MTA Message Transfer Agent PDU Protocol Data Unit RMP Reliable Multicast Protocol SMTP Simple Mail Transport Protocol UDP User Datagram Protocol XTP Xpress Transport Protocol A.2. Predefined Protocol Parameters ANNOUNCE_DELAY Time between sending an Announce_PDU and the first afiliated Address_PDU. ANNOUNCE_CT This counter specifies the number of re-transmissions of Riechmann Expires October 1999 [Page 37] INTERNET-DRAFT P_MUL April 1999 an Announce_PDU while waiting ANNOUNCE_DELAY. EMCON_RTC Maximum re-transmission counter controlling the number of message re-transmissions for EMCON nodes. EMCON_RTI Re-transmission interval controlling the waiting time between successive re-transmissions for EMCON nodes. MPDU_SIZE This is the maximum PDU size used to transmit messages over the multicast network. PDU_DELAY Time between the output of two subsequent Data_PDUs. WAIT_FOR_REJECT_TIME Time between sending a Request_PDU and an afiliated Announce_PDU. A.3. Proposed Multicast Group Addresses (for organisational purposes) To allow the dynamic creation of multicast groups it is necessary to have one multicast address to which all nodes have joint. 239.1.1.1 (GMG) This group address is used for group management purposes. To install a new group the sending node has to use this group to transmit Request_PDUs, Release_PDUs and Announce_PDUs. All nodes supporting the P_Mul based service have to join this multicast group. A.4. Proposed UDP Port Numbers To allow multiplexed multicast communication between all nodes of a network it is necessary to define some UDP port numbers: Port 2751 (TPORT) is used for the transmission of Request_PDUs, Reject_PDUs and Release_PDUs between the transmitting programs (transmitter). All transmitters have to listen to this port in conjunction with the multicast group GMG. Port 2752 (RPORT) is used by the transmitters for the transmission of the Announce_PDUs to inform those receiving process[es] (receiver[s]) involved in the concerning message transfer to join a specific multicast group. All receivers have to listen to this port in conjunction with the multicast group GMG. Riechmann Expires October 1999 [Page 38] INTERNET-DRAFT P_MUL April 1999 Port 2753 (DPORT) is used for the data traffic from the transmitter to the receiver[s]. Port 2754 (APORT) is used for the traffic from the receiver[s] to the transmitter. A.5. 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) { 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; Riechmann Expires October 1999 [Page 39] INTERNET-DRAFT P_MUL April 1999 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 Address: Christian Riechmann FGAN/FKIE Neuenahrer Strasse 20 D-53343 WACHTBERG Germany Phone: (+49) 228 9435 533 Fax: (+49) 228 9435 685 Email: riechmann@fgan.de Riechmann Expires October 1999 [Page 40]