Internet Engineering Task Force Fernando Cuervo INTERNET DRAFT Abdallah Rayhan <draft-cuervo-megaco-tudp-00.txt> Nortel Networks Category: Informational J. Steven Mayer Expires: December 15, 1999 dynamicsoft Transaction UDP plus Timers (TUDP) for MEGACO <draft-cuervo-megaco-tudp-00.txt> Status of This Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC 2026. Internet-Drafts are working docu- ments 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 To view the list of Internet-Draft Shadow Directories, see http://www.ietf.org/shadow.html Abstract: This document describes transaction-oriented reliable UDP with timers (TUDP). It can be used to provide reliable delivery of transactions for MEGACO [1] applications. The objective of the protocol is to deliver transactions and messages within the time constraints of the applica- tion, i.e., the application timer. Transaction sequences are ordered per stream, and superseding of transactions is allowed. MEGACO implementations may choose to use TUDP for applications that Cuervo, Rayhan, Mayer [Page 1]
Internet draft Transaction UDP + Timers 15 June 1999 require high fan-out, reliable and ordered delivery. Other transports such as TCP, UDP or SIGTRAN may be useful in other situations. Table of Contents 1. Introduction 2. Overview of the Protocol Characteristics 2.1 Definitions 2.2 Transaction Mechanisms 2.3 Reliability Mechanisms 2.4 Merits of TUDP for use by MEGACO 3. Describing the Protocol 3.1 Protocol Format 3.1.1 Protocol Header 3.1.2 Transaction Segment 3.1.3 Message Segment 3.1.4 Ack Segment 3.1.5 Repeat Segment 3.1.6 Release Segment 3.1.7 DISC Segment 3.2 Protocol Procedures 3.2.1 Initialization 3.2.2 Transmission 3.2.3 Congestion Control Procedure 3.2.4 Disconnect 3.2.5 Retransmission Timer 3.2.6 Ack Timer 3.3 Protocol Examples 3.3.1 Association & Stream Initialization 3.3.2 Stream Release 3.3.3 Disconnect 3.3.4 Retransmission and Duplication 3.3.5 Resetting 3.3.6 Fragmentation 4. Conclusion 5. Acknowledgements 6. References 7. Authors' addresses Cuervo, Rayhan, Mayer [Page 2]
Internet draft Transaction UDP + Timers 15 June 1999 1. Introduction The MEGACO working group has been considering two different approaches to address the reliability issue. The first approach is to relieve the MEGACO layer from needing to handle reliability issues by introducing a light reliable transport. With this approach, the MEGACO application level commands require no transport-related fields, nor any transport- related commands; all transport issues are handled by a standalone tran- sport layer protocol. The other approach is to make reliability part of the MEGACO layer. Given the range of applications of the MEGACO protocol, i.e., from small media gateways to large carrier class gateways, there is a need to allow for different transport choices. Bundling reliability into the MEGACO spec would constrain the applicability of MEGACO. | | | Application | | Application | | | +--------------------+ +--------------------+ | MEGACO | | MEGACO | +--------------------+ | + Reliability | | Reliable Transport | vs. +--------------------+ +--------------------+ | | | UDP | | UDP | | | | | This document provides a solution for the layered approach. It specifies a mechanism for transaction-based reliable transport for MEGACO over UDP. TUDP inherits several concepts introduced in T/TCP [2,3]. The objective of the protocol is to deliver transactions and messages within the time constraints of an application, i.e., the application timer. Transactions are formed by a request/reply pair. A sequence of related transactions is a "stream". The timely delivery of a request/reply by TUDP causes the application to issue the next transac- tion in the stream. When TUDP fails to successfully complete a transaction (because of net- work congestion or host delay, the time to complete the transaction is larger than what the application tolerates), then the application may issue a new transaction on the same stream to override the previous one. When this occurs the transport must ignore the old transaction. Streams may have associated messages (e.g., MEGACO Notifys). TUDP accepts any number of messages passed by the application. It guarantees ordered delivery of messages with respect to other messages and Cuervo, Rayhan, Mayer [Page 3]
Internet draft Transaction UDP + Timers 15 June 1999 request/replies in the stream. 2. Overview of the Protocol Characteristics 2.1. Definitions Association: An association is a communication link which is described by an Associa- tion Descriptor (AssocDesc). The Association Descriptor uniquely identi- fies two TUDP ends; each end is identified by an IP address and a port number. An association has a limit on the number of streams allowed (MaxStream). TUDP allows more than one association between two hosts as long as AssocDesc is unique. Stream: One or more streams can be multiplexed in one association. Each stream serves one sequence of transactions (i.e., request/replies and associ- ated event notifications, etc. Transaction: A transaction is defined as Request/Reply pair. Hence, every Request is associated with a Reply. Message: A message is a Request that does not require a Reply. For instance, a MEGACO Notify is a message. Segment: A TUDP datagram is called a segment. 2.2. Transaction Mechanisms Handling transactions in TUDP eliminates the need to add semantic and syntactic complexities to the MEGACO base protocol. TUDP addresses these transaction requirements: 1) Reliable Transactions and Messages: TUDP reliably delivers both Request/Reply messaging pairs, and uni- directional messages. Cuervo, Rayhan, Mayer [Page 4]
Internet draft Transaction UDP + Timers 15 June 1999 2) Single and Multiple Streams: TUDP associations carry one or more streams. Each stream serves a sequence of transactions and operates independently of other streams. 2.3. Reliability Mechanisms TUDP provides transport reliability using the following mechanisms: 1) Order of arrival within a stream: Order is preserved by a simple mechanism: Any stream can have only one outstanding transaction in TUDP at any given time (i.e., the application enforces a window of 1 for each stream). If the TUDP transport is requested to deliver a transaction while another transaction is still outstanding in the same stream, then the new transaction takes pre- cedence. The old transaction is removed from the transport. This action is also known as sequence restart (See Section 3.3.5 Resetting transac- tions). It is possible to interleave messages (e.g. notifications) with the Request/Reply elements of the sequence. Any number of messages can be delivered to TUDP, however TUDP ensures that messages arrive in order per stream (the application cannot use a window of 1 since it lacks the application level responses to them and naturally the concept of restart does not apply to messages). Message order is preserved with respect to the sequence also. 2) Loss of transaction/message: In the case of a lost segment (i.e., no ack for that segment has been received) the transport retransmits the lost segment (which contains a transaction/message). 3) Long transaction/message: When a transaction or message is larger than the maximum segment length, it must be fragmented. Fragmentation requires buffering and reordering of segments in order to obtain the original transaction. 4) Duplicated transaction/message: TUDP detects a duplicate request and reissues the corresponding reply; if the reply has been previously acked then the duplicate request is ignored. 5) Reset Transaction: When a new transaction is sent that supersedes the previous one for any Cuervo, Rayhan, Mayer [Page 5]
Internet draft Transaction UDP + Timers 15 June 1999 reason (to be determined and acted upon by the application), the Reset Transaction must be issued at one host and processed properly at the peer host in such a way that it overrides any older transaction Request/Reply. This requires buffer management in order to flush the buffer of the old transaction. The effect of resetting a transaction is equivalent to canceling the previous transaction and issuing a new one. Messages are not affected by the reset. 2.4. Merits of TUDP for use by MEGACO The main difference between TUDP and other approaches, such as SIGTRAN, is this: the main performance metric for TUDP is that transactions/messages are delivered in order within the timing con- straints of the application. The merits of TUDP can be summarized as follows: 1) Reliability and Timely Delivery: TUDP maintains retransmissions as required, within the time interval needed by the application, in order to achieve a high probability of timely delivery. 2) No 3-way handshake: TUDP avoids the 3-way handshake, one of the main sources of delay and complexity in TCP-type transports. By avoiding this mechanism, the tran- sport gains transmission efficiency and speed. 3) High communication fan-out: TUDP uses two timers per association: a retransmission timer and an ack timer to control retransmission and acknowledgement of segments, respec- tively. 4) Fixed length header, separated data and control: Transaction processing is simplified with a fixed length header and separated data and control since minimal processing is needed to transmit a transaction. 5) No windowing: TUDP avoids the complexities of windowing by enforcing a window of size 1 per stream. For the association, TUDP uses an implicit window size, which is the maximum number of streams per association, (MaxStream) to Cuervo, Rayhan, Mayer [Page 6]
Internet draft Transaction UDP + Timers 15 June 1999 transmit transactions. When network congestion occurs, Section 3.2.3 Congestion Control Procedure is followed. 6) Minimum number of messages: TUDP defines five messages: one each for transactions and messages, one for releasing a stream, one for segment ack, and one for disconnecting the association. The main differences between the TUDP approach and the SIGTRAN approach can be summarized as follows: 1) SIGTRAN provides a reliable transport while TUDP's objective is to transport transactions and messages within the limit of the appli- cation timer. In the case of transactions, if a transaction is not transported in time, the application can reset the stream by send- ing a new transaction. 2) MEGACO does not require path redundancy while it is required for SIGTRAN. Therefore, TUDP does not address this problem. 3) When congestion is encountered within an association, TUDP limits the ability of the application to open a new stream or restart streams that have failed. Service to new entrants is blocked until the congestion is reduced. 4) The protocol complexity of TUDP is reduced for transaction stream- ing because it has a window of 1. 3. Describing the Protocol 3.1. Protocol Format 3.1.1. Protocol Header A TUDP segment has an 12-byte header. It consists of Vers, Type, 8 1-bit flags, Segment Length, CC, and CCEcho. Cuervo, Rayhan, Mayer [Page 7]
Internet draft Transaction UDP + Timers 15 June 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 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Vers | Type |C|A|D|R|S|F|E|M| Segment Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CC | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CCEcho | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1- Vers: is a 4-bit word describing the version of the transport. 2- Type: is a 4-bit word describing the type of the segment. TUDP has 5 different segments to achieve reliable transaction-based tran- sport, namely, Transaction, Message, Ack, Repeat, DISC. 3- Flags: There are 8 flags in total. Each flag is 1-bit. Each segment type has a defined subset of flags. For example, if the subset is {C,A,S}, then these are the only flags that can be set to "1" in this segment. All flags are set to "0" by default in every transmitted segment unless stated otherwise. If other flags are set, then this segment is not compliant with protocol and ignored. 4- C: This flag marks the beginning of transaction/message. It is only set in the first segment of a new transaction/message. 5- A: This flag indicates the presence of CCEcho. 6- D: This flag is set to "1" for every segment other than first seg- ment of a transaction/message. 7- R: This flag is set to "1" if CCRep is present in the segment. 8- S: This flag is set to "1" if the segment carries a Reset transac- tion segment. 9- F: This flag is set to "1" if the segment carries a fragmented transaction. 10- E: This flag indicates that the current segment is the end of a Cuervo, Rayhan, Mayer [Page 8]
Internet draft Transaction UDP + Timers 15 June 1999 fragmented transaction. 11- M: This flag is set to "1" if the current segment is a message seg- ment. The beginning and end of a fragmented transaction/message is marked by "C" and "E", respectively. Any other segments in the transaction/message will have "D" set in addition to "E" if it applies. Fragmentation is indicated by "F". If Ack is piggybacked with the transaction, "A" is set. If "A" is not set, then CCEcho is set to "0"s, which means undefined. If the transaction is a reset, e.g., superseding the previous one, "S" is set in every segment of the Request but not the Reply. Flag "M" is set for messages. If "M" is set, then only "A", "F", and "E" can be set in this segment. Flag "R" is set for Repeat segments. If "R" is set, then only "A" can be set in this segment. Ack segments have only flag "A" set. 12- Segment Length: The value of this field represents the length of the datagram including the header in bytes. 13- CC: 32-bit sequence counter. Transmitted segments are sequenced using this sequence counter. Unless a segment is retransmitted, This counter is incremented by 1 every time a segmented is transmitted. 14- CCEcho: 32-bit counter used to acknowledge received segments. 15- CCRep: 32-bit counter used to request the retransmission of segment CC. This counter appears when flag R is set to "1". 16- SIDL: 16-bit stream identifier at the local end of an association. 17- SIDR: 16-bit stream identifier at the remote end of the associa- tion. Cuervo, Rayhan, Mayer [Page 9]
Internet draft Transaction UDP + Timers 15 June 1999 3.1.2. Transaction Segment: 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 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Vers | Type |C|A|D|0|S|F|E|0| Segment Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CC | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CCEcho | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SIDL | SIDR | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Order | | +-+-+-+-+-+-+-+-+ | / Transaction / / Payload (TP) / | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The payload of segment is called Transaction Payload (TP). A transaction segment is identified by its type. The first segment of a transaction can either be a new transaction segment, or a reset transaction segment. Others are called subsequent segments. The header parameters for tran- sactions are: 1- Type: "1000" 2- New Transaction Segment: The flags that belong to this segment are: {"C","A","F","E"}. "C" must be set to "1". 3- Reset Transaction Segment: The flags that belong to this segment are: {"C","A","S","F","E"}. "C" and "S" must be set to "1". 4- Subsequent Segment: The flags that belong to this segment are: {"D","A","S","F","E"}. "D" must be set to "1". If this segment is part of a reset transaction, then "S" must be set to "1", other- wise, "0". 5- CC: Segment sequence number. 6- CCEcho: sequence number of acknowledged segment if exist. 7- SIDL: stream identifier at the local transport. 8- SIDR: stream identifier at the remote transport. Cuervo, Rayhan, Mayer [Page 10]
Internet draft Transaction UDP + Timers 15 June 1999 9- Order: is the number of segments carrying the current transaction. 10- TP: transaction payload. 3.1.3. Message Segment: 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 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Vers | Type |0|A|0|0|0|F|E|M| Segment Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CC | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CCEcho | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SIDL | SIDR | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Order | | +-+-+-+-+-+-+-+-+ | / Transaction / / Payload (TP) / | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ A message segment does not require a reply transaction. The payload of transaction is TP. The header parameters for messages are: 1- Type: "0100" 2- The flags that belong to this segment are: {"A","F","E","M"}. "M" must be set to "1". 3- CC: Segment sequence number. 4- CCEcho: sequence number of acknowledged segment if exist. 5- SIDL: stream identifier at the local transport. 6- SIDR: stream identifier at the remote transport. 7- Order: is the number of segments carrying the current message. 8- TP: message payload. Cuervo, Rayhan, Mayer [Page 11]
Internet draft Transaction UDP + Timers 15 June 1999 3.1.4. Ack Segment: 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 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Vers | Type |0|A|0|0|0|0|0|0| Segment Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CC | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CCEcho1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CCEcho2 | / . . . . . . / / . . . . . . / | CCEchoN | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ An Ack segment acknowledges one or more segments. The payload of segment is N CCEcho sequences. The header parameters for Acks are: 1- Type: "0010" 2- The flags that belong to this segment are: {"A"}. "A" must be set to "1". 3- CC: Segment sequence number. 4- CCEchos: sequence numbers of acknowledged segments. 3.1.5. Repeat Segment: 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 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Vers | Type |0|A|0|R|0|0|0|0| Segment Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CC | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CCEcho | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CCRep1 | / . . . . . . / / . . . . . . / | CCRepN | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Cuervo, Rayhan, Mayer [Page 12]
Internet draft Transaction UDP + Timers 15 June 1999 A Repeat segment requests retransmission of one or more segments. The payload of a segment is N CCRep sequences. The header parameters for Repeat are: 1- Type: "0001" 2- The flags that belong to this segment are: {"A","R"}. "A" and "R" must be set to "1". 3- CC: Segment sequence number. 4- CCEcho: sequence number of acknowledged segment. 5- CCReps: sequence numbers of requested segments. 3.1.6. Release Segment: 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 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Vers | Type |0|A|0|0|0|0|0|0| Segment Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CC | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CCEcho | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SIDL.1 | SIDR.1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SIDL.2 | SIDR.2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SIDL.N | SIDR.N | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ A Release segment signals to the remote host the release of one or more streams. The header parameters for Release segments are: 1- Type: "0111" 2- The flags that belong to this segment are: {"A}. 3- CC: Segment sequence number. 4- CCEcho: sequence number of acknowledged segment if exist. Cuervo, Rayhan, Mayer [Page 13]
Internet draft Transaction UDP + Timers 15 June 1999 5- SIDL.1: stream identifier at the local transport for the first stream. 6- SIDR.1: stream identifier at the remote transport for the first stream. 3.1.7. DISC Segment: 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 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Vers | Type |0|A|0|0|0|0|0|0| Segment Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CC | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CCEcho | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ A DISC segment signals the termination of a connection between two hosts. The header parameters for DISC are: 1- Type: "1111" 2- The flags that belong to this segment are: {"A"}. "A" must be set to "1". 3- CC: Segment sequence number. 4- CCEcho: sequence number of acknowledged segment. 3.2. Protocol Procedures 3.2.1. Initialization: An association is initialized by the first segment transmitted between two hosts. Each stream multiplexed in an association is identified by a SID. Multiple associations can exist between two applications. Different associations are processed independently by the transport. SIDs are assigned locally but have end-to-end significance for the association between hosts. The end-to-end SID consists of two parts, local (SIDL) and remote (SIDR). SIDs are defined in the first Request/Reply exchange, that is the first Request carries the SIDL and the first Reply provides the SIDR. Both SIDL and SIDR are explicitly released when the stream is terminated. Cuervo, Rayhan, Mayer [Page 14]
Internet draft Transaction UDP + Timers 15 June 1999 The transport that transmits the first Request of an association sets the first 16-bit of SID to the selected number, and sets the last 16-bit to NULL; SID has a NULL value when set to "1"s. The receiver transport sets the NULL SID to its own desired number. The order of SID does not change through out the life of the stream. Release segments are used to release streams. Each TUDP layer in an association must ensure the uniqueness of its part in the SID. 3.2.2. Transmission: When the application issues a Request, it gets transmitted as new tran- saction segment with "C" set. If an Ack is piggybacked, "A" is set. If the transaction is fragmented, "F" is set. The rest of the segments will have "D" and "F" set in addition to "A" if they apply. The last segment of the transaction will have "E" set. Each time a segment is transmit- ted, CC is incremented by 1. CC and CCEcho are used to sequence and ack- nowledge transmitted segments rather than streams. When the other end receives a request, it tests if the CCEcho matches any of the unacknowledged segments. If that is the case, the segment gets flushed out of the buffer. Otherwise, it waits on the expiry of the Ack timer. When a transaction is received, it is passed to the applica- tion and waits on a Reply transaction. When the Reply is ready, it is fragmented and transmitted as a subsequent segment(s). If the Ack Timer expires before Reply is ready or any segment is transmitted, an Ack segment is sent acknowledging the last segment(s) received since last acknowledgement. When several segments arrive out of order and Ack timer expires, a Repeat segment is used to request retransmission of any missing segment(s). The application maintains its own transaction timer in its own domain each time a Request is issued. When the timer expires before receiving a Reply, the application may issue another request to over ride the previ- ous one. The new Request is called a Reset Request and transmitted by the transport as a Reset segment. When a Reset segment is received, the transport flushes the buffer of any pending transaction and passes it to the application as a Reset transaction. The transport always matches Requests and Replies before clearing up buffers. A transaction is flushed when it is acknowledged or reset. The application can issue Messages at any time. The transport processes the message and sends it in the order it was received with respect to the sequence of transactions. The transport retransmits segments when the Retransmission timer expires and no acknowledgement is received, or when Repeat segment is received. Cuervo, Rayhan, Mayer [Page 15]
Internet draft Transaction UDP + Timers 15 June 1999 A retransmitted segment is a copy of the lost one, however, CCEcho is updated if retransmission is consequence of a Repeat segment. 3.2.3. Congestion Control Procedure: TUDP addresses congestion control by following two mechanisms. First, TUDP refuses to restart failed streams or add new streams to the associ- ation, however, it remains committed to the current transactions. In other words, it follows the retransmission procedure. When the maximum number of retransmissions (MaxTransmit) is reached, TUDP communicates transmission failure to the application through error handling mechanism and refuses processing Reset Transactions. Second, TUDP adjusts the Retransmission Timer to reflect the network congestion. Once the network is less congested, TUDP allows failed streams to restart (Reset Transaction), and new streams to be added to the association using a recovery mechanism such as accepting one stream, two, four, etc., until the maximum number of streams (MaxStream) allowed in the association is reached. 3.2.4. Disconnect: An association is terminated by a DISC segment. DISC signaling is a 3- way handshake. This is necessary to ensure the delivery of all pending transactions and the clearing the buffers. 3.2.5. Retransmission Timer: This timer is defined per association. When a transaction is transmit- ted, this timer is set. If the timer expires before an Ack is received the segment is retransmitted and the timer is reset. The number of retransmissions is defined as MaxTransmit. This timer is set at the last segment of a fragmented transaction. When more than one stream is defined within an association, TUDP maintains order of transactions for retransmissions. The value of this timer is estimated using the RTT scheme defined in [3]. 3.2.6. Ack Timer: This timer is defined per association. When a request is received by the peer transport this timer is set. If the timer expires before a Reply a segment is transmitted, an Ack segment is sent to acknowledging any out- standing CCEcho(s). If a transaction is fragmented, the timer is set at receiving the first segment of the transaction Cuervo, Rayhan, Mayer [Page 16]
Internet draft Transaction UDP + Timers 15 June 1999 3.3. Protocol Examples: A segment is presented as < . . . >. We show a flag in the segment if it belongs to the header and set to "1". Otherwise, it is not shown. If a segment is lost, it is marked by X, e.g. ---->X. The party that issues a Request is referred to as Client and the one that replies is the Server. Length of segment is not shown and the payload of Request/Reply is shown as TP. 3.3.1. Association & Stream Initialization: An association between two hosts is established by the first transmitted segment. Thus avoiding the 3-way handshake. Streams are initialized using the procedure described in Section 3.2.1 Initialization. Client Server <1000,C,CC 123,SIDL 1, SIDR Null,Order 1, TP> (Request)--------> // Set Retransmission Timer // 1st segment received // Set Ack Timer // Reply is ready // Unset Ack Timer <1000,DA,CC 345,CCEcho 123, // Reply received <--------(Reply) SIDL 1, SIDR 1,Order 1,TP> // Unset Retransmission Timer // Set Retransmission Timer <0010,A,CC 124, CCEcho 345> (Ack) --------> // Unset Retransmission Timer 3.3.2. Stream Release: When one host terminates a stream, TUDP transmits a Release segment. The other host sends Ack to confirm the release. Client Server <0111,CC 123, SIDL 1,SIDR 1> (Release)--------> // Set Retransmission Timer // Release segment received <--------(Ack) <0010,A,CC 345,CCEcho 123> // Unset Retransmission Timer Cuervo, Rayhan, Mayer [Page 17]
Internet draft Transaction UDP + Timers 15 June 1999 3.3.3. Disconnect: Disconnect follows a 3-way handshake. When one host initiates DISC, it ignores any segment other than DISC reply from the other host. The other host shell flush its own buffer and ignore all segments other than the DISC segment acknowledging its own DISC. Client Server <1111,CC 123> (DISC) --------> // Set Retransmission Timer // DISC segment received <--------(DISC) <1111,A,CC 345,CCEcho 123> // Unset Retransmission Timer // Set Retransmission Timer <1111,A,CC 124, CCEcho 345> (DISC) --------> // Unset Retransmission Timer 3.3.4. Retransmission and Duplication: When the Retransmission Timer expires, the transport retransmits the outstanding segments using the same CC values and updating CCEcho if it applies. A segment is a duplicate if its CC value has been received before. Client Server <1000,C,CC 123,SIDL 1, SIDR 3,Order 1,TP> (Request)-------->x // Set Retransmission Timer // Retransmission Timer Expires <1000,C,CC 123,SIDL 1, SIDR 3,Order 1,TP> (Request)--------> // Set Retransmission Timer // segment received // Set Ack Timer // Reply is ready // Unset Ack Timer <1000,DA,CC 345,CCEcho 123, // Reply received <--------(Reply) SIDL 1, SIDR 3,Order 1,TP> // Unset Retransmission Timer // Set Retransmission Timer <0010,A,CC 124, CCEcho 345> (Ack) --------> // Unset Retransmission Timer Cuervo, Rayhan, Mayer [Page 18]
Internet draft Transaction UDP + Timers 15 June 1999 3.3.5. Resetting: A client can issue a transaction to supersede the previously transmitted one. The application keeps track of which transaction is issued and set its own timer to supersede a delayed Reply. Superseding is achieved by issuing a new transaction before receiving the reply of the expired transaction. In this case, the transport learns that this is a Reset transaction since a Reply has not been received . The Reset transaction has "C" and "S" set to "1". Client Server <1000,C,CC 123,SIDL 1, SIDR 3,Order 1,TP> (Request)--------> // Set Retransmission Timer // segment received // Set Ack Timer // Ack Timer expires // No Reply is ready <--------(Ack) <0010,A,CC 345, // segment received CCEcho 123> // Unset Retransmission Timer // application issues // Reset Transaction <1000,CAS,CC 124,CCEcho 345,SIDL 1, SIDR 3,Order 1,TP> (Request)--------> // Reset Transaction received // Set Retransmission Timer // Reply for Reset Transaction <1000,DA,CC 346,CCEcho 124, // Reply received <--------(Reply) SIDL 1, SIDR 3,Order 1,TP> <0010,A,CC 125, // Set Retransmission Timer CCEcho 346> (Ack) --------> // Unset Retransmission Timer 3.3.6. Fragmentation: When a transaction is longer than the maximum segment size, it gets fragmented. Flag "F" will indicate fragmentation. Flags "C" and "E" will mark the beginning and end of fragmentation. Any segment in between, including the last one, will have "D" set rather than "C". Ordering of fragmented transactions is performed at the transport level. We present below two examples of fragmentation. The first one encounters no loss and the second with loss. Cuervo, Rayhan, Mayer [Page 19]
Internet draft Transaction UDP + Timers 15 June 1999 Client Server <1000,CF,CC 123,SIDL 1, SIDR 3,Order 3,TP> (Request)--------> <1000,CF,CC 124,SIDL 1, SIDR 3,Order 3,TP> (Request)--------> <1000,CF,CC 125,SIDL 1, SIDR 3,Order 3,TP> (Request)--------> // Set Retransmission Timer // segments received // Set Ack Timer // Ack Timer expires // No Reply is ready <--------(Ack) <0010,A,CC 345, // segment received CCEcho 123,124,125> // Unset Retransmission Timer // Reply is ready <1000,D,CC 346, <--------(Reply ) SIDL 1, SIDR 3,Order 1,TP> // Reply received // Set Retransmission Timer <0010,A,CC 126, CCEcho 346> (Ack) --------> // Unset Retransmission Timer The following example shows how fragmentation is handled when segments are lost. Cuervo, Rayhan, Mayer [Page 20]
Internet draft Transaction UDP + Timers 15 June 1999 Client Server <1000,CF,CC 123,SIDL 1, SIDR 3,Order 4,TP> (Request)--------> <1000,DF,CC 124,SIDL 1, SIDR 3,Order 4,TP> (Request)-------->x <1000,DF,CC 125,SIDL 1, SIDR 3,Order 4,TP> (Request)-------->x <1000,DFE,CC 126,SIDL 1, SIDR 3,Order 4,TP> (Request)--------> // Set Retransmission Timer // segments received // send Ack and Repeat <--------(Ack) <0010,A,CC 345, CCEcho 123,126> <--------(Repeat) <0001,R,CC 346, // segments received CCEcho 124,125> // Unset Retransmission Timer // set Retransmission Timer <1000,DAF,CC 124,CCEcho 345,SIDL 1, SIDR 3,Order 4,TP> (Request)--------> <1000,DAF,CC 125,CCEcho 346,SIDL 1, SIDR 3,Order 4,TP> (Request)--------> // Set Retransmission Timer // Unset Retransmission Timer // Transaction complete <--------(Ack) <0010,A,CC 347, // Unset Retransmission Timer CCEcho 124,125> // Reply is ready <1000,D,CC 348, // Reply received <--------(Reply) SIDL 1, SIDR 3,Order 1,TP> <0010,A,CC 127, // Set Retransmission Timer CCEcho 348> (Ack) --------> // Unset Retransmission Timer 4. Conclusion TUDP satisfies the transport requirements of MEGACO. It is proposed that this protocol be referenced in the MEGACO protocol specification as the protocol for the class of applications that require large fan-out and reliable-ordered delivery of MEGACO transactions. 5. Acknowledgements The authors wish to thank Nancy Greene, Spencer Dawkins, Lyndon Ong, Cuervo, Rayhan, Mayer [Page 21]
Internet draft Transaction UDP + Timers 15 June 1999 Peter Blatherwick, and Christopher Ross for their very valuable comments in the presentation of this document. 6. References [1] Cuervo et al, "MEGACO Protocol", draft-ietf-megaco-protocol-01.txt, April, 1999. [2] R.T. Braden, RFC 1379 "Extending TCP for Transactions-Concepts", Nov. 1992. [3] R.T. Braden, RFC 1644 "T/TCP-TCP Extensions for Transactions, Func- tional Specification", July 1994. 7. Authors' addresses Fernando Cuervo Nortel Networks P.O. Box 3511 Stn C Ottawa, ON, Canada K1Y 4H7 Email: cuervo@nortelnetworks.com Abdallah Rayhan Nortel Networks P.O. Box 3511 Stn C Ottawa, ON, Canada K1Y 4H7 Email: arayhan@nortelnetworks.com J. Steven Mayer dynamicsoft 200 Executive Drive Suite 250 West Orange, NJ 07052 Email: smayer@dynamicsoft.com Cuervo, Rayhan, Mayer [Page 22]