Reliable Multicast Transport (RMT) Internet Draft B. Whetten Document: draft-whetten-rmt-track-pi-00.txt Consultant D. Chiu Expires: April 2002 M. Kadansky Sun Microsystems Seok Joo Koh ETRI Gursel Taskale TIBCO October 28, 2002 TRACK PROTOCOL INSTANTION OVER UDP: TREE ACKNWOLEGEMENT BASED RELIABLE MULTICAST Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [1]. 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. 1. Introduction One of the protocol instantiations the RMT WG is chartered to create is a TRee-based ACKnowledgement protocol (TRACK). Rather than create a set of monolithic protocol specifications, the RMT WG has chosen to break the reliable multicast protocols into Building Blocks (BB) and Protocol Instantiations (PI). A Building Block is a specification of the algorithms of a single component, with an abstract interface to other BBs and PIs. A PI combines a set of BBs, adds in the additional required functionality not specified in any BB, and specifies the specific instantiation of the protocol. For more Whetten Expires - April 2003 [Page 1] TRACK PROTOCOL INSTANTIATION OVER UDP October 2002 information, see the Reliable Multicast Transport Building Blocks and Reliable Multicast Design Space documents [2][3]. As specified in [2], there are two primary reliability requirements for a transport protocol, ensuring goodput, and confirming delivery to the sender. The NORM and ALC PIÆs are responsible solely for ensuring goodput. TRACK is designed to offer confirmed delivery, aggregation of control traffic and receiver statistics, local recovery, automatic tree building, and enhanced flow and congestion control, in conjunction with NORM. Whereas the NORM and ALC PIÆs run only over other building blocks, the TRACK PI has a more difficult integration task. To run in conjunction with NORM, it must either re-implement the functionality in the NORM PI, or integrate directly with the NORM PI. In addition, in order to have reasonable commercial applicability, TRACK needs to be able to run over other protocols in addition to NORM. To meet both of these challenges, the TRACK PI is designed to integrate with other transport layer protocols, including NORM, PGM [20], ALC [19], UDP, or an overlay multicast system. In order to accomplish this, there can be multiple TRACK PIÆs, one for each transport protocol it is specified to integrate with. The vast majority of the protocol functionality exists in the TRACK BB [17], which in turn references the automatic tree building block [16]. For more details on the specific functionality of TRACK, please see those building blocks. TRACK is organized around a Data Channel and a Control Channel. The Data Channel is responsible for multicast data from the sender to all other nodes in a TRACK session. In order to integrate with NORM and other goodput-ensuring transport protocols, these protocols are used as the Data Channel for a given Data Session. This Data Channel MAY also provide congestion control. Otherwise, congestion control MUST be provided by the TRACK PI, through using the TFMCC or other approved congestion control building block. As the simplest example of a TRACK PI, this document instantiates TRACK on top of UDP, without any extra congestion control This is primarily done for illustration purposes, and is NOT RECOMMENDED for widespread deployment. Other TRACK protocol instantiation documents will then provide specific details of how to instantiate TRACK in conjunction with other protocols, such as NORM. In integration with another protocol, some of the fields in the TRACK packet headers MAY overlap with those in the other protocol. This MUST be resolved in the appropriate version of the TRACK PI. The first principal role of this TRACK PI is to instantiate the packet formats for this protocol over UDP, using the message formats in the TRACK building block as a base. The second is to specify how the TRACK BB is to be integrated with a UDP based Data Channel. Whetten Expires - April 2003 [Page 2] TRACK PROTOCOL INSTANTIATION OVER UDP October 2002 Building blocks specify abstract messages, and typically use a naming convention such as ôBindRequestö. TRACK packet types are then instantiated in this document, and use a naming convention such as ôBIND_REQUESTö. 2. Conventions Used in this Document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [4]. 3. Applicability Statement This section describes the applicability of the TRACK PI as instantiated in conjunction with the use of UDP multicast as the Data Channel. A further applicability statement can be found in the TRACK BB, which covers all TRACK protocol instantiations. This protocol instantiation is NOT RECOMMENDED for widespread deployment. It may be used for EXPERIMENTAL use, only in tightly controlled networks, preferably ones that only span a single administrative domain. 4. Integration With UDP Transport TRACK uses a statistically reliable protocol for the data channel. This adjacent transport protocol is responsible for delivering most of the packets reliably, and MAY be responsible for providing the primary congestion control algorithms. This version of the TRACK PI uses UDP as an initial demonstration of this functional integration. A TRACK PI is responsible for dealing with the following integration points. Each of the following sections describes the generic requirement. It also describes how this is to be implemented with UDP as a sample transport. 4.1 Data Sessions 4.1.1 Data Session Announcement All members of a group must receive, either from an advertisement message, or pre-configuration, the set of configuration parameters for a new Data Session. Whetten Expires - April 2003 [Page 3] TRACK PROTOCOL INSTANTIATION OVER UDP October 2002 With UDP, if a Session Advertisement message is required, this is handled by sending NUM_SESSION_ANNOUNCEMENTS SESSION_ANNOUNCEMENT packets to a well known Multicast Group Address, SESSION_ANNOUNCEMENT_ADDRESS, at intervals of SESSION_ANNOUNCEMENT_INTERVAL. In this case, a Sender MUST then wait for SESSION_ANNOUNCEMNT_INTERVAL time after the last SESSION_ANNOUNCEMENT packet is sent, before it can send any data packets. 4.1.2 Data Session Initialization When a new session starts, TRACK MUST open up the set of ports on which control and data packets will be received for that Data Session. It MUST also initialize the TRACK BB. With UDP, initialization consists of opening up the following UDP ports, for nodes with the specified roles. The addresses for these ports come from either the Session Announcement message, as part of the configuration parameters, or as part of the BindConfirm message. - Child Incoming Control Port, incoming unicast, (Sender, Repair Head) - Local Control Channel Port, outgoing multicast, (Sender, Repair Head) - Parent Outgoing Control Port, outgoing unicast, (Repair Head, Receiver) - Parent Incoming Control Port, incoming multicast, (Repair Head, Receiver) - Outgoing Data Channel Port, outgoing multicast, (Sender) - Incoming Data Channel Port, incoming multicast, (Repair Head, Receiver) 4.1.3 Data Session Shutdown When a Data Session terminates, TRACK MUST close down the set of ports that were opened for that Data Session, as per section 4.1.2, unless these ports are also being used for other, still active, Data Sessions. In this case, TRACK MUST NOT close down ports that are being used for other Data Sessions. 4.2 Data Packets 4.2.1 Data Transmission Senders MUST be able to send ODATA and NULL_DATA packets on the Data Channel. Senders and Repair Heads MUST be able to send RDATA packets on the Local Control Channel. Whetten Expires - April 2003 [Page 4] TRACK PROTOCOL INSTANTIATION OVER UDP October 2002 With UDP, when a Sender needs to send an ODATA or NULL_DATA packet, it creates a new UDP packet, fills it in, and sends it over the Outgoing Data Channel Port. When a Sender or Repair Head needs to send a RDATA packet, it sends it over the Local Control Channel Port. 4.2.2 Data Reception Repair Heads and Receivers must be able to receive ODATA and RDATA packets. With UDP, all packets that are received for a given Data Session, on all incoming ports, are automatically handed to the TRACK BB, including any ODATA and RDATA packets. 4.3 Control Packets 4.3.1 Sending Control Packets All nodes must be able to send control packets. With UDP, when a node needs to send a control packet, it does so by either unicasting it to its parent via its Parent Outgoing Control Port, or by multicasting it to its children on its Local Control Channel Port. 4.3.2 Receiving Control Packets All nodes must be able to receive control packets. In addition, some control packets that are received MAY be of value to the data channel, such as statistics on the number of receivers. This information MAY be passed to the data channel. With UDP, all packets that are received for a given Data Session are automatically handed to the TRACK BB, including any control packets. No extra control information is passed to the UDP data channel. 4.3.3 Missing Packet Notification When a data packet is marked as unrecoverable by the Data Channel, the TRACK BB needs to be notified of this. With UDP, all packets that are received for a given Data Session are automatically handed to the TRACK BB, including any Data packets. The TRACK BB will automatically detect missing packets by the gaps in their sequence numbers, and will then request retransmission. 4.4 Packet Identifiers 4.4.1 Multicast Group Address Whetten Expires - April 2003 [Page 5] TRACK PROTOCOL INSTANTIATION OVER UDP October 2002 The Multicast Group Address MAY be unique to TRACK, or it MAY be a shared identifier with the data channel. With UDP, the Multicast Group Address is unique to TRACK, and is part of the Session Advertisement. 4.4.2 Data Session ID The Data Session ID MAY be unique to TRACK, or it MAY be a shared identifier with the data channel. With UDP, the Data Session ID is unique to TRACK, and is part of the Session Advertisement. 4.4.3 Packet Sequence Numbers Packet Sequence Numbers MAY be unique to TRACK, or they MAY be shared identifiers with the data channel. With UDP, Packet Sequence Numbers are unique to TRACK, and are not shared. 4.5 Data Queue The Data Queue MAY be maintained separately by TRACK, or it MAY be shared with the data channel. With UDP, the TRACK BB maintains its own Data Queue, and this is not integrated with UDP. 4.6 Flow and Congestion Control A TRACK session MUST have congestion control that meets the requirements of RFC2357, if it is to be deployed for widespread use. The Data Channel itself MAY provide this congestion control, or a separate congestion control building block integrated with the TRACK PI MAY provide it. If the Data Channel provides congestion control, the TRACK PI MAY provide additional information, such as RTT estimates, to the Data ChannelÆs congestion control functionality. If the Data Channel does NOT provide congestion control, the TRACK PI MUST provide it, if it is to be deployed in the general Internet. TRACK provides flow control, by limiting when data packets can be sent to the Data Channel. This functionality MAY be shared with the Data Channel, or it MAY be independent. Whetten Expires - April 2003 [Page 6] TRACK PROTOCOL INSTANTIATION OVER UDP October 2002 With UDP, TRACK MUST integrate the TFMCC BB if it is to be deployed in the general Internet. This is not done in this document, and so this particular TRACK PI MAY NOT be deployed in the general Internet. The flow control functionality is implemented by the TRACK BB, and is not shared with UDP. 4.7 Error Conditions Fatal error conditions in TRACK or in the Data Channel SHOULD invoke session termination for all affected sessions, both of the TRACK session, and the Data Channel session. All error conditions in the Data Channel SHOULD be reported to the TRACK application. All error conditions in a TRACK session MAY be reported to the Data Channel. 5. Global Configuration Variables, Constants, and Reason Codes This section contains parameters that are specific to this particular TRACK PI. 5.1 Global Configuration Variables These are variables that control the Data Session and are advertised to all participants. With UDP, there are no extra Global Configuration Variables. 5.2 Constants With UDP, the following constants are defined. NUM_SESSION_ANNOUNCEMENTS = 5 SESSION_ANNOUNCEMENT_ADDRESS = To Be Defined SESSION_ANNOUNCEMENT_INTERVAL = 3 seconds 6. Packet Types Each TRACK packet definition consists of a fixed header, zero or more option headers, followed by data or control information. When instantiated on top of another protocol such as NORM, the fixed header and option headers can be merged with the fixed header and option headers of that protocol. Whetten Expires - April 2003 [Page 7] TRACK PROTOCOL INSTANTIATION OVER UDP October 2002 With UDP, there is no merging of headers that occurs, except that UDP port numbers do not have to be repeated in the TRACK packet headers. Original data is carried in ODATA packets. Retransmissions of data packets are carried in RDATA packets. Collectively, ODATA and RDATA packets are called Data packets. Each Data packet has a Session ID and a sequence number, which identifies the packet and allows a receiver application to reconstruct the data stream from the ODATA and RDATA packets. Receivers and Repair Heads unicast periodic status packets to their parents. A TRACK packet is sent regularly to confirm the reception of the set of Data packets that have arrived, which MAY allow the Sender to advance its transmission window. A TRACK packet also MAY provide an application level confirmation of delivery of a stream of packets. A TRACK packet MAY furnish congestion control or other statistics about the state of data reception at the node, which will be aggregated by the repair heads in the tree. Finally, a TRACK packet MAY request retransmission of Data packets that have not been received. TRACK uses the Tree Building Building Block draft as a reference for building its repair tree. The following is a description of this PIÆs implementation of tree building that is consistent with that draft. When a Receiver or Repair Head wishes to establish a repair service relationship for a given Data Session, it uses a BIND_REQUEST packet to request to bind to a parent Repair Head. A parent sends a BIND_CONFIRM or BIND_REJECT message after it processes a BIND_REQUEST packet. The BIND_REJECT message comes with a reason code that explains the reason for rejection. The reason may indicate that the parent is not connected into the tree yet, so that the receiver can try again later. If the parent sends a BIND_ACCEPT, this constitutes Joining a session. When a Receiver or Repair Head wishes to leave a Data Session, it sends an UNBIND_REQUEST to its parent. The parent replies with an UNBIND_CONFIRM packet, at which time the child is allowed to leave the Data Session. A Repair Head periodically sends HEARTBEAT packets to notify its child nodes that it is alive, and to advertise the current leading and trailing edges of its transmission window. If a Sender has no data to send for a Session, it periodically multicasts a NULL_DATA packet on the Data Multicast Address. NULL_DATA packets inform receivers about the state of the Data Session and the Sender. Whetten Expires - April 2003 [Page 8] TRACK PROTOCOL INSTANTIATION OVER UDP October 2002 If a Child node is not operating normally, or a Parent node restarts after a failure and receives a packet from a Child not in its child list, then the Parent node sends an EJECT_REQUEST packet to the child node, causing the child node to terminate its connection to the control tree. The Child SHOULD reply with an EJECT_CONFIRM packet, although the Parent node MAY choose to immediately mark the Child as Removed. The Parent SHOULD attempt to notify the child multiple times that it has been ejected before completely removing the Child from the ParentÆs Child List. 6.1 TRACK Fixed Header 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ver | O Num | Type | Global Source ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Global Source ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sender Port | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Data or Options Fields ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Ver: Specifies the version number of the protocol, the first field to be checked by a receiver. If there is a mismatch between the version of the packet received, and the version of the protocol in use at this node, the packet SHOULD be discarded, unless there are specific backwards compatibility specifications standardized for this case. O Num: The number of options present in this packet. If no options are present, then this field is set to 0. Each option is encoded in Type, Length, Value format. Type: Packet type. Value Meaning 0 Reserved 1 ODATA 2 RDATA 3 NULL_DATA 4 TRACK 5 HEARTBEAT 6 BIND_REQUEST 7 BIND_CONFIRM 8 BIND_REJECT 9 UNBIND_REQUEST 10 UNBIND_CONFIRM Whetten Expires - April 2003 [Page 9] TRACK PROTOCOL INSTANTIATION OVER UDP October 2002 11 EJECT_NOTIFICATION 12 EJECT_CONFIRM 13 PARENT_QUERY 14 PARENT_ADVERTISEMENT 15 SESSION_ADVERTISEMENT 16-255 Reserved for Future Use Global Session ID: This is a unique identifier that, when combined with a sender assigned port number, specifies the Data Session ID. It is a globally unique source identifier. This ID MUST NOT change throughout the duration of the transport session. A RECOMMENDED identifier is the low-order 48 bits of the MD5 [9] signature of the DNS name of the source. Sender Port: This is a port number assigned by the Sender of this Data Session. When combined with the Global Session ID, this forms the Data Session ID. 6.1.1 Dependencies on Lower Protocols Each packet requires the following fields, which MUST be provided by a lower level protocol. With UDP, they are provided in the UDP packet header. Source Port: The 16 bit UDP port number used by the sender of this packet. Destination Port: A 16 bit port number that, when combined with the IP unicast or IP multicast address of a packet, specifies the destination of the packet. Checksum: A standard field to detect whether the contents of the packet were corrupted. 6.2 ODATA, RDATA, NULL_DATA Packet Headers 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Highest Released | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sender TimeStamp | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Transmission Rate | Data Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Data ... Whetten Expires - April 2003 [Page 10] TRACK PROTOCOL INSTANTIATION OVER UDP October 2002 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Sequence Number: A sender stamps each Data packet that it sends with a sequence number. Sequence numbers are 32 bits in length and have a valid range of 1 to 2^32-1. The value 0 is reserved. Because this range is finite, all arithmetic and comparison with these numbers is Modulo 2^32. TRACK requires that no more than 2^31-1 packets can be created over a period equal to the maximum lifetime for a datagram packet in the network. This condition holds true when IPv4 is used as the datagram service. If this is a NULL_DATA packet, Sequence Number corresponds to the sequence number of the leading edge of the SenderÆs transmission windowùthe highest sequence number transmitted. Highest Released: This field contains a sequence number, equal to the trailing edge of the SenderÆs retransmission window. A Receiver or Repair Head SHOULD NOT attempt to recover any packets with smaller sequence number than Highest Released. Sender Timestamp: This is a 32 bit time stamp with millisecond granularity used to indicate the time that the packet was generated at the Sender. If this field is not equal to zero, the Receivers should generate a round trip time measurement in their next TRACK packet. Transmission Rate: This is the current transmission rate of the Sender, in packets per second. Data Length: This is the length of the data in bytes. Data: This holds the data to be delivered. 6.3 TRACK Packet Format 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Multicast Group Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Multicast Port | Worst Loss Rate | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sub Tree Count | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Highest Allowed | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Worst Edge Throughput | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Whetten Expires - April 2003 [Page 11] TRACK PROTOCOL INSTANTIATION OVER UDP October 2002 | Unicast Cost | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Multicast Cost | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sender Timestamp | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sender Dally Time | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Parent Timestamp | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Parent Dally Time | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Multicast Group Address: This is the multicast address for the data channel for this session. Multicast Port: This is the UDP port for the multicast data channel for this session. Worst Loss Rate: This is the highest loss rate of any receiver in the subtree rooted at this node. The value for this field is created by multiplying the loss rate (a real number between 0 and 1)by 50000. This is part of RWE in TFMCC. Sub Tree Count: This is an integer indicating the current number of receivers below this node. Highest Allowed: a sequence number, used for flow control from the receivers. It signals the highest sequence number the sender is allowed to send that will not overrun the receiversÆ buffer pools. Worst Edge Throughput: This is the lowest throughput, in bytes per second, of any edge of the tree below this child. This is part of RWE in TFMCC. If RWE is not in use, this corresponds to the slowest receiver in the subtree rooted at this node. Unicast Cost: This is the cost, as calculated by RWE in TFMCC, to send a packet to each receiver of this subtree, using unicast. It is measured in units of milliseconds. Multicast Cost: This is the cost, as calculated by RWE in TFMCC, to send a packet to each receiver of this subtree, using multicast. It is measured in units of milliseconds. Sender Timestamp: This is a timestamp from the sender that is being replied to for a round trip time measurement. This value is copied from the appropriate Data packet, and is not modified. If it is zero, no RTT measurement is being acknowledged. Since TRACK packets Whetten Expires - April 2003 [Page 12] TRACK PROTOCOL INSTANTIATION OVER UDP October 2002 are not delivered reliably, multiple TRACK packets may acknowledge the same RTT request from a sender. Sender Dally Time: This field is associated with a Sender Timestamp field. It contains the sum of the waiting time that should be subtracted from the RTT measurement at the sender. It is an unsigned number of milliseconds. Parent Timestamp: This is a timestamp from this childÆs parent that is being replied to for a round trip time measurement. This value is copied from the appropriate HEARTBEAT packet, and is not modified. If it is zero, no RTT measurement is being acknowledged. Since TRACK packets are not delivered reliably, multiple TRACK packets may acknowledge the same RTT request from a parent. Parent Dally Time: This field is associated with a Parent Timestamp field. It contains the sum of the waiting time that should be subtracted from the RTT measurement at the parent. It is an unsigned number of milliseconds. 6.4 HEARTBEAT Packet Format 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Level | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Highest Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Highest Released | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Parent Timestamp | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Children List ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Level: This is an integer that indicates the level of the parent in the repair tree. This value is used to keep loops in the tree from forming, in addition to indicating the distance from the sender. See the Automatic Tree Building Building Block for more details. Highest Sequence Number: This is the highest sequence number that has been transmitted that the Parent knows about. Highest Released: This field contains a sequence number, equal to the trailing edge of the ParentÆs retransmission window. A child Whetten Expires - April 2003 [Page 13] TRACK PROTOCOL INSTANTIATION OVER UDP October 2002 Receiver or Repair Head SHOULD NOT attempt to recover any packets with smaller sequence number than Highest Released. Parent Timestamp: This is a 32 bit time stamp with millisecond granularity used to indicate the time that the packet was generated at the parent. If this field is not equal to zero, the children should generate a round trip time measurement to this parent in their next TRACK packet. Children List: This field contains the identifiers for a list of children that the parent has not heard from recently, and that are to generate immediate TRACK messages. Each child identifier in the list is two bytes long, and MUST be unique across this Data Session at this parent. They correspond to the Child Index field assigned by the parent in a BIND_CONFIRM packet, below. 6.5 BIND_REQUEST Packet Format 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Level |R|Role | Res | Bind Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Session Multicast Port | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Session Multicast Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Subtree Count | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Level: This is an integer that indicates the level of the parent in the repair tree. This value is used to keep loops in the tree from forming, in addition to indicating the distance from the sender. See the Automatic Tree Building Building Block for more details. Role: This indicates if the bind requestor is a receiver or repair head. It can have one of the following values: 0x02 û Repair Head 0x03 û Receiver R: This flag is set to 1 to indicate a rejoin request. Res: Reserved. Must be set to 0. Bind Sequence Number: This is the sequence number of the BIND_REQUEST packet. Whetten Expires - April 2003 [Page 14] TRACK PROTOCOL INSTANTIATION OVER UDP October 2002 Subtree Count: This is an integer indicating the current number of receivers below the node. Session Multicast Port: This is the multicast port for the sender's data channel. Session Multicast Address: This is the multicast address for the sender's data channel. The combination of the TRACK Session ID, the Session Multicast Port and the Sessions Multicast Address uniquely identifies the stream. 6.6 BIND_CONFIRM Packet Format 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Level | Role| Reserved| Child Index | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Parent Repair Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Parent Repair Port | Bind Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Lowest Available Repair | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Level: This is an integer that indicates the level of the parent in the repair tree. This value is used to keep loops in the tree from forming, in addition to indicating the distance from the sender. See the Automatic Tree Building Building Block for more details. Role: This identifies or acknowledges the role of the parent. It can have one of the following values: 0x01 - Sender 0x02 û Repair Head Child Index: This is the index of the child node in its parent's child list. Parent Repair Address: This is the IP multicast address that the parent will be using for communication to this child. If this field is null, then the receiver should expect retransmissions to be sent on the sender's data multicast address. Whetten Expires - April 2003 [Page 15] TRACK PROTOCOL INSTANTIATION OVER UDP October 2002 Parent Repair Port: This is the UDP port corresponding to the Parent Repair Address. If the Parent Repair Address is null, then this field MUST be null. Bind Sequence Number: This is the sequence number of the BIND_CONFIRM packet. This has the same value as the Bind Sequence Number field in the BindRequest that this packet is replying to. Lowest Available Repair: This is the lowest sequence number that the parent is willing to start repairing from, for this stream. 6.7 BIND_REJECT Packet Format 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Bind Sequence Number | Level | Reason | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Bind Sequence Number: This is the sequence number of the BIND_CONFIRM packet. This has the same value as the Bind Sequence Number field in the BindRequest that this packet is replying to. Level: This is an integer that indicates the level of the parent in the repair tree. This value is used to keep loops in the tree from forming, in addition to indicating the distance from the sender. See the Automatic Tree Building Building Block for more details. Reason: This is the reason for rejecting the child from joining. This can have one of the following values: 0x01 û Loop Freedom Not Guaranteed, Try Again Later 0x02 û Too Many Children 0x03 û Not Servicing This Session 0x04 û Other 0x05-0xFF û Reserved 6.8 UNBIND_REQUEST Packet Format 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Child Index | Reason | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Whetten Expires - April 2003 [Page 16] TRACK PROTOCOL INSTANTIATION OVER UDP October 2002 Child Index: This is the index of the child node in its parent's child list. Reason: This is the reason the child is leaving. This can have one of the following values: 0x01 û End of Stream 0x02 û Application Request to Leave 0x03 û Loss Rate Too High 0x04 û Other Failure 0x05-0xFF û Reserved 6.9 UNBIND_CONFIRM Packet Format There are no extra fields to this packet. 6.10 EJECT_NOTIFICATION Packet Format 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reason | Reserved | Alternate Parent Port | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Alternate Parent Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Reason: This is the reason the child is being ejected. This can have one of the following values: 0x01 û Parent Ending Service For Stream 0x02 û Child Loss Rate Too High 0x03 û Child Misbehaving 0x04 û Too Many Children 0x05 û Other Failure 0x06-0xFF û Reserved Alternate Parent Port: If the Reason code is either 0x01 or 0x04, the child may attempt to connect to another parent. If this parent knows of an alternative parent, it may list the UDP port for that alternative parent in this field. Alternate Parent Address: This is the address for an alternative parent. 6.11 EJECT_CONFIRM Packet Format Whetten Expires - April 2003 [Page 17] TRACK PROTOCOL INSTANTIATION OVER UDP October 2002 This packet has no additional fields. 6.12 SESSION_ADVERTISEMENT Packet Format 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MaxChildren | ACKWindow | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ConstantHeartbeatPeriod | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MinimumHeartbeatPeriod | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MinHoldTime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MaxHoldTime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | DataMulticastAddress | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | DataMulticastPort | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The following session parameters are set at the Sender, and advertised to the group in the SESSION_ADVERTISEMENT message. Note that in a SESSION_ADVERTISEMENT, the Data Source ID in the fixed header is filled in to correspond to the Data Source ID of the new session, that is being advertised. MaxChildren: The maximum number of children a repair head is allowed to handle. ACKWindow: The number of packets seen before a receiver issues an acknowledgement. ConstantHeartbeatPeriod: If not zero, this is the constant period between HEARTBEAT packets, in milliseconds. MinimumHeartbeatPeriod: If not zero, this is the minimum period between HEARTBEAT packets, in milliseconds. MinHoldTime: The minimum amount of time a repair head holds on to data packets, in milliseconds. MaxHoldTime: The maximum amount of time a repair head holds on to data packets, in milliseconds. Whetten Expires - April 2003 [Page 18] TRACK PROTOCOL INSTANTIATION OVER UDP October 2002 DataMulticastAddress: This is the IP Multicast address of the Data Channel Multicast Group Address. DataMulticastPort: This is the UDP port of the Data Channel Multicast Group Address. MaxNullDataTime: This number specifies the maximum time interval for sending NullData packets. If the receiver does not receive any data packet from the sender within 5*MaxNullDataTime, it detects a sender failure. 6.13 TRACK Options Header TRACK Options take a general form for their first 32 bits. That form is: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | A | OType | Resevered | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ A: a 2-bit flag that indicates how the packet is processed if the option is not supported by the implementation. 00: ignore the option, but process the packet 01: ignore the packet 10: leave the Data Session 11: reserved The flag A is set to 00 to indicate that the option is to be skipped and the packet processed. A is set to 01 to indicate that the whole packet is to be discarded. A is set to 10 to indicate that this is an important option which modifies the functional characteristics of the TRACK protocol and so the node must exit the Data Session. OType: A number that indicates the option type. The predefined values of OTYPE are: 1 Request for Application Confirmation 2 Application Level Confirmation 3 Retransmission Request 4 Request for Tree Statistics 5 Tree Statistics 6 Time Bounded Reliability 7 End of Stream 7-63 Reserved for future use Whetten Expires - April 2003 [Page 19] TRACK PROTOCOL INSTANTIATION OVER UDP October 2002 Length: Specifies the length of this option block in 32 bit words. 6.13.1 Data Packet Option û Request for Application Confirmation This option allows a sender to request that the TRACK session report the status of delivery for a range of packets. If this option is included in any given ODATA packet, it should be duplicated in any RDATA packets that are generated with the same sequence number. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reliability | Num Replies | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Low Confirmation Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | High Confimation Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Reliability: This is the reliability semantics that these packets must have been delivered with in order to qualify for acknowledgement. This can take one of the following values: 0x01 û Delivered to Application with Time Bounded Reliability 0x02 û Delivered to Application without Losses 0x03 û Application Provides Confirmation of Receipt and Use 0x04 û Application Provides Confirmation of Persistence to Disk 0x05-0x1F û Reserved for TRACK 0x20-0xFF û Reserved for Application Specific Codes Num Replies: Since TRACK packets are not delivered reliably; this is the minimum number of consecutive TRACK packets that should include a confirmation response. Low Confirmation Sequence Number: This is the starting sequence number in the stream that the confirmation request covers. If equal to 0, then this request covers all sequence numbers in the stream. High Confirmation Sequence Number: This is the highest sequence number in the stream that the confirmation request covers. 6.13.2 TRACK Packet Option û Application Level Confirmation This option is used to report up an application level confirmation of delivery. It should be used as a reply to a Data packet that included an Acknowledgement Request option. The size of the Failure List should never exceed the global parameter, Maximum Failure List Whetten Expires - April 2003 [Page 20] TRACK PROTOCOL INSTANTIATION OVER UDP October 2002 Size. The mechanisms for this option MAY be used to create a complete list of all receivers with their status codes, either successful or not. However, this SHOULD NOT be used with large receiver group sizes. Note that the maximum list size is limited by the maximum size of a single UDP packet. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Low Confirmation Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | High Confimation Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Confirmation Status | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Confirmation Count | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Failure List ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Failure List Entry +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Receiver IP Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Receiver IP UDP Port | Receiver Status | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Confirmation Sequence Number: This is the highest sequence number, for which application level confirmation has been requested, and which is being replied to with this option. Confirmation Count: This is the number of receivers that have confirmed delivery. Note that the number of receivers that have not confirmed delivery is equal to Sub Tree Count û Confirmation Count. Confirmation Status: This is the status of the confirmation. It can include one of the following values: 0x01 û All Receivers Acknowledge 0x02 û List of Failures 0x03 û Failures Exceed Maximum List Size Failure List: This is a list of eight byte Failure List Entries, each of which consists of the following three fields. Receiver IP Address: This is the four byte IP host address for the receiver in this Failure List Entry. Receiver IP UDP Port: This is the incoming, IP unicast port number for this receiver Whetten Expires - April 2003 [Page 21] TRACK PROTOCOL INSTANTIATION OVER UDP October 2002 Receiver Status: This is the status code for this receiver. This can include one of the following values: 0x01 û Delivery Successful 0x02 û Application Pending Acknowledgement 0x03 û Not Delivered to Application With Requested Reliability 0x04 û Application Can Not Confirm With Requested Reliability 0x05 û Application Failure 0x06 û Client Unreachable 0x07 û Client Flow Controlled 0x0008-0x00FF û Reserved for TRACK Codes 0x1000-0xFFFF û Application Specific Return Code 6.13.3 TRACK Packet Option û Retransmission Request This option is used to request retransmission of lost packets. This option is unlikely to be used if instantiated on top of a reliable protocol such as NORM or PGM, except to handle and recover from persistent failures that last for up to many minutes. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Bitmask Base | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Bitmask ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Bitmask Base: This is a sequence number corresponding to the lowest bit in the Bitmask field. Bitmask: This is an array of 1's and 0's. Together with the sequence number Bitmask Base, this is used to indicate lost data messages that are being requested for retransmission. If the i'th element is a 1, it indicates the message Bitmask Base+i is lost and needs to be retransmitted. 6.13.4 Data Packet Option û Statistics Request This option is used to prompt the members of a Data Session to generate and aggregate statistics about the Data Session. The aggregation variables are self-describing, are automatically aggregated by the Repair Heads, and delivered to the Sender. Statistics List +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Stat Format | Aggregation | Statistic ID | Whetten Expires - April 2003 [Page 22] TRACK PROTOCOL INSTANTIATION OVER UDP October 2002 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Statistic Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | Statistics List: Each statistic entry in the Statistics List has each of the four following values, and MUST be an even multiple of four bytes in length. Statistic ID: This is an identifier for the statistic that is contained in the Statistic Value field of this statistic in the statistic list. It can be either defined by TRACK or by the application. It can have one of the following values, which are further detailed in Appendix A: 0x01 û Loss Rate 0x02 û Throughput 0x03 û ODATA Packets Received 0x04 û RDATA Packets Received 0x05 û Total Detected Lost Packets 0x06 û Total Undeliverable Data Packets 0x07 û HEARTBEAT Packets Received 0x08 û NULL_DATA Packets Received 0x08 û Receiver Flow Window 0x09 û Round Trip Time to Parent 0x10 û Unicast Cost 0x11 û Multicast Cost 0x12 û Total Bind Attempts 0x13 û Successful Bind Attempts 0x14 û Number of Children 0x0015-0x7FFF û Reserved for TRACK 0x8000-0xFFFF û Reserved for Application Stat Format: The type and length of the Statistic Value field. All data formats must be encoded in network byte order. It can have one of the following values, which are further detailed in Appendix A. 0x01 û 32 bit unsigned integer 0x02 û 32 bit signed integer 0x03 û 64 bit unsigned integer 0x04 û 64 bit signed integer Aggregation Type: This is the aggregation rule that each Repair Head or Sender are to follow in aggregating this statistic. It can have one of the following values, which are detailed further in Appendix A. 0x01 û Ignore this Value 0x02 û Sum 0x03 û Product 0x04 û Minimum 0x05 û Maximum Whetten Expires - April 2003 [Page 23] TRACK PROTOCOL INSTANTIATION OVER UDP October 2002 Statistic Value: This is the value of the statistic. 6.13.5 TRACK Packet Option û Tree Statistics This option is used to collect usage statistics at the Receiver. It can be used to provide a self-describing set of aggregation variables that will be aggregated by the Repair Heads in the tree, and delivered to the Sender. It is generated in response to a Statistics Request option in a Data packet. This list of statistics fields in the Statistics Request option MUST be copied exactly in to this option, with the exception of the Aggregation and Statistic Value fields. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number of Request | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Statistics List +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Stat Format | Aggregation | Statistic ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Statistic Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | Sequence Number of Request: The sequence number of the ODATA packet that contained the Statistics Request option that this is a response to. Statistics List: Each statistic entry in the Statistics List has each of the four following values, and MUST be an even multiple of four bytes in length. Statistic ID: This is an identifier for the statistic that is contained in the Statistic Value field of this statistic in the statistic list. It can be either defined by TRACK or by the application. It can have one of the following values, which are further detailed in Appendix A: 0x01 û Loss Rate 0x02 û Throughput 0x03 û ODATA Packets Received 0x04 û RDATA Packets Received 0x05 û Total Detected Lost Packets 0x06 û Total Undeliverable Data Packets 0x07 û HEARTBEAT Packets Received Whetten Expires - April 2003 [Page 24] TRACK PROTOCOL INSTANTIATION OVER UDP October 2002 0x08 û NULL_DATA Packets Received 0x08 û Receiver Flow Window 0x09 û Round Trip Time to Parent 0x10 û Unicast Cost 0x11 û Multicast Cost 0x12 û Total Bind Attempts 0x13 û Successful Bind Attempts 0x14 û Number of Children 0x0015-0x7FFF û Reserved for TRACK 0x8000-0xFFFF û Reserved for Application Stat Format: The type and length of the Statistic Value field. All data formats must be encoded in network byte order. It can have one of the following values, which are further detailed in Appendix A. 0x01 û 32 bit unsigned integer 0x02 û 32 bit signed integer 0x03 û 64 bit unsigned integer 0x04 û 64 bit signed integer Aggregation Type: This is the aggregation rule that each Repair Head or Sender are to follow in aggregating this statistic. It can have one of the following values, which are detailed further in Appendix A. 0x01 û Ignore this Value 0x02 û Sum 0x03 û Product 0x04 û Minimum 0x05 û Maximum Statistic Value: This is the value of the statistic. 6.13.6 Time Bounded Reliability Option This option provides support for time bounded reliability and can be used by a Sender in the Data packets. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Bound | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tsent_0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tsent_1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Bound: This is the maximum time in milliseconds allowed for recovery of the packet Whetten Expires - April 2003 [Page 25] TRACK PROTOCOL INSTANTIATION OVER UDP October 2002 Tsent: This is the time at the sender when the packet was generated. The timestamp is expressed in elapsed seconds and microseconds since 00:00 Universal Coordinated Time, January 1, 1970. Tsent_0 contains the seconds part of the timestamp and Tsent_1 contains the microseconds part of the timestamp. 6.13.7 Data Packet Option û End of Stream This option notifies the receivers that the end of stream has been reached, and that they can leave the group. This should not be set while an application confirmation option is still pending. This option has no additional fields. 7. Conformance Statement In addition to the requirements imposed by the targeted network and application types, TRACK is designed to meet all of the requirements proposed by the IETF in RFC2357. - Congestion Control. In order to be approved for general use, each TRACK PI must use provably safe and TCP-friendly congestion control algorithms that also scale to large groups. While the current version of this PI does not meet this requirement, the versions meant for general use will. - Well-controlled, Scaleable Behavior. TRACK includes carefully analyzed algorithms that manage and smooth the control traffic and retransmissions. These are key to avoiding NACK implosion, ACK implosion, and retransmission implosion (the local recovery pathology). - Security. TRACK is designed to support protection of the transport infrastructure, through the use of lightweight authentication of control and data packets. The security requirements of TRACK are analyzed in the Security Requirements for TRACK draft [12]. 8. Security Considerations The security requirements of TRACK are analyzed in the Security Requirements For TRACK draft [12]. 9. References [1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. Whetten Expires - April 2003 [Page 26] TRACK PROTOCOL INSTANTIATION OVER UDP October 2002 [2] Whetten, B., et. al. ôReliable Multicast Transport Building Blocks for One-to-Many Bulk-Data Transfer.ö RFC 3048, January 2001. [3] Handley, M., et. al. ôThe Reliable Multicast Design Space for Bulk Data Transfer.ö RFC 2887, August 2000. [4] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997 [5] Whetten, B., Taskale, G. ôOverview of the Reliable Multicast Transport Protocol II (RMTP-II).ö IEEE Networking, Special Issue on Multicast, February 2000. [6] Nonnenmacher, J., Biersack, E. "Reliable Multicast: Where to use Forward Error Correction", Proc. 5th. Workshop on Protocols for High Speed Networks, Sophia Antipolis, France, Oct. 1996. [7] Nonnenmacher, J., et. al. "Parity-Based Loss Recovery for Reliable Multicast Transmission", In Proc. of ACM SIGCOMM '97, Cannes, France, September 1997. [8] Rizzo, L. "Effective erasure codes for reliable computer communications protocols", DEIT Technical Report LR-970115. [9] Nonnenmacher, J., Biersack, E. "Optimal Multicast Feedback", Proc. IEEE INFOCOM 1998, March 1998. [10] Whetten, B., Conlan, J. ôA Rate Based Congestion Control Scheme for Reliable Multicastö, GlobalCast Communications Technical White Paper, November 1998. http://www.talarian.com/rmtp-ii [11] Padhye, J., et. al. ôModeling TCP Throughput: A Simple Model and its Empirical Validationö. University of Massachusetts Technical Report CMPSCI TR 98-008. [12] Hardjorno, T., Whetten, B. ôSecurity Requirements for TRACKö draft-ietf-rmt-pi-track-security-00.txt, June 2000. Work in Progress. [13] Golestani, J., ôFundamental Observations on Multicast Congestion Control in the Internetö, Bell Labs, Lucent Technology, paper presented at the July 1998 RMRG meeting. [14] Kadansky, M., D. Chiu, J. Wesley, J. Provino, ôTree-based Reliable Multicast (TRAM)ö, draft-kadansky-tram-02.txt, Work in Progress. Whetten Expires - April 2003 [Page 27] TRACK PROTOCOL INSTANTIATION OVER UDP October 2002 [15] Whetten, B., M. Basavaiah, S. Paul, T. Montgomery, ôRMTP-II Specificationö, draft-whetten-rmtp-ii-00.txt, April 8, 1998. Work in Progress. [16] Kadansky, M., Chiu, D. M., Whetten, B., Levine, B. N., Taskale, G., Cain, B., Thaler, D., Koh, s. J., ôReliable Multicast Transport Building Block: Tree Auto-Configurationö, draft-ietf- rmt-bb-tree-config-02.txt, March 2, 2001. Work in Progress. [17] Whetten, B., Chiu, D. M., Kadansky, M., Taskale, G., ôReliable Multicast Transport Building Block for TRACKö, draft-ietf-rmt-bb- track-01.txt, March 2, 2001. Work in Progress. [18] Adamson, B., et. al., ôNACK Oriented Reliable Multicast Protocol (NORM), draft-ietf-rmt-pi-norm-02.txt, July 2001. Work in Progress. [19] Vicisano, L., et. al., ôAsynchronous Layered Coding - A scalable reliable multicast protocolö, draft-ietf-rmt-pi-alc- 02.txt, July 2001. Work in Progress. [20] Speakman, T., et. al., ôPragmatic General Multicast (PGM)ö, draft-speakman-pgm-spec-06.txt, Feb 2001. Work in Progress. 10. Acknowledgments Special thanks goes to the following individuals, who have contributed to the design and review of this document. Supratik Bhattacharyya, Sprint Labs Joseph Wesley, Sun Microsystems 11. Author's Addresses Brian Whetten 890 Sea Island Lane Foster City, CA 94404 b2@whetten.net Dah Ming Chiu Sun Microsystems Laboratories 1 Network Drive Burlington, MA 01803 dahming.chiu@sun.com Whetten Expires - April 2003 [Page 28] TRACK PROTOCOL INSTANTIATION OVER UDP October 2002 Miriam Kadansky Sun Microsystems Laboratories 1 Network Drive Burlington, MA 01803 miriam.kadansky@sun.com Seok Joo Koh sjkoh@pec.etri.re.kr Gursel Taskale TIBCO Corporation gursel@tibco.com Full Copyright Statement Copyright (C) The Internet Society, 2001. All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into other languages. Whetten Expires - April 2003 [Page 29]