Internet Draft: RMTP-II Specification B. Whetten, M. Basavaiah draft-whetten-rmtp-ii-app-00.txt GlobalCast Communications, Inc. Expires: Six months S. Paul Lucent Technologies, Bell Labs T. Montgomery West Virginia University N. Rastogi, J. Conlan, T. Yeh GlobalCast Communications, Inc. April 8, 1998 THE RMTP-II PROTOCOL APPENDICES Status of this Memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress". To view the entire list of current Internet-Drafts, please check the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). Abstract These appendices furnish supplementary information for the RMTP-II protocol draft. The appendices contain information on design rationale, congestion control algorithms, SNMP MIBs, forward error correction, time bounded reliability, and work in progress RMTP-II APPENDICES [Page 1] Internet Draft The RMTP-II PROTOCOL 8 April 1998 APPENDIX A - DESIGN RATIONALE It is widely recognized that no single reliable multicast protocol can meet the needs of all applications over all network types. RMTP-II targets a specific subset of application and network types. Targeted Network Types RMTP-II is designed to work over a controlled network, which typically has a single administrative domain. These networks have the fewest barriers to IP multicast and the greatest need for reliable multicast services. There is no current standard for bridging IP multicast over multiple administrative domains and heterogeneous routing protocols, although work is continuing in this area. In addition, internet service providers have concerns about peering and settlement for IP multicast traffic which spans multiple domains. These issues are delaying the deployment of widespread native IP multicast in the Internet. In contrast, a number of private companies, satellite operators, and ISPs have turned on, or are in the process of turning on, IP multicast for use strictly within their networks. In a conrolled intranet environment, a single network management organization typically controls each of the networks in which RMTP-II will be deployed. In order to promote the adoption of RMTP-II the following are required: - Network managers require tools for the monitoring and control of the reliable multicast traffic. - Network managers can provide manual configuration of the protocol, although requirements for this should be minimized. - Network managers can provide additional control over network congestion in addition to automatic end-to-end congestion control. - Network managers can have direct control over multicast senders. RMTP-II takes these requirements into account by providing the following features: - RMTP-II provides SNMP management of the control nodes. - RMTP-II segments node operations into trusted nodes (control nodes), and user nodes (sender and receiver nodes). - RMTP-II allows manual or automatic tree configuration. RMTP-II APPENDICES [Page 2] Internet Draft The RMTP-II PROTOCOL 8 April 1998 - RMTP-II provides the top node as a centralized point through which network managers control the rate parameters and congestion algorithms of the senders. - RMTP-II provides access control of multicast senders. While the majority of controlled networks are symmetrical and support many-to-many multicast, a significant percentage are asymmetrical and support few-to-many multicast. RMTP-II takes this into account by not requiring any many-to-many multicast services, and by dividing the communication paths of the protocol into two pieces - the data channel and the control channel. The use of a separately defined data channel, which is not assumed to overlap with the control channel, allows RMTP-II to support asymmetrical networks, such as a one way satellite data feed with a terrestrial return path, and ADSL. A number of extensions to IP multicast, such as subtree multicast, ACK accumulation, and PGM, have been proposed which can run in the routers. This would make tree based reliable multicast protocols easier to configure and to scale more readily. To date, none of these mechanisms have been standardized or released by a major commercial vendor. RMTP-II is designed with these mechanisms, especially subtree multicast, in mind. However, since the current goal of RMTP-II is to provide an immediate, graceful deployment path, these features will only be supported as options. Targeted Application Types Multicast applications can be divided into two classes, few-to-many and many-to-many. Many-to-many applications include server replication, multi-user games, small group conferencing, and computer supported collaborative work. These applications typically treat all members in a group as peers, require special semantics such as total ordering of messages from multiple senders, and rarely require scalability beyond 100 receivers. Other protocols, such as RMP [WMK94], have been designed to support these many-many applications. RMTP-II focuses on few-to-many applications, such as multicast file transfer, electronic software distribution, real time news and financial distribution, "push" applications, audio/video/data broadcasts, distance learning, and some types of server replication. These applications typically require at most 50 simultaneous senders, 10,000 or more receivers, have different roles for senders and receivers, and do not require total ordering of messages between senders. These applications may require strong guarantees on delivery, streaming of data in real time, or support for synchronous streaming. RMTP-II is designed to meet all of these requirements. RMTP-II APPENDICES [Page 3] Internet Draft The RMTP-II PROTOCOL 8 April 1998 RMTP-II provides a strong, but fully distributed membership protocol which supports scaling to 10,000 or more simultaneous receivers while providing strong guarantees on message delivery. RMTP-II is a streaming protocol and provides support for real time applications. RMTP-II meets the requirement of synchronous streaming applications with a new quality of service level called Time Bounded Reliability. Time Bounded Reliability restricts recovery of packets to a limited time interval. This keeps dropped packets from blocking the rest of a synchronous data stream and prevents a failed receiver from affecting other receivers. RMTP-II takes the application semantics into account by dividing the nodes' roles into senders, receivers, and control nodes. Other Design Considerations In addition to the requirements imposed by the targeted network and application types, RMTP-II takes into account the following factors and design goals: - ACK and NACK implosion must be prevented. - Control traffic, retransmission traffic, and retransmission latency must be minimized. - End-to-end congestion control algorithms must be strongly supported as they become mature. - Simplicity of design is required for ease of use and development. - Extensibility must be supported for future development. RMTP-II APPENDICES [Page 4] Internet Draft The RMTP-II PROTOCOL 8 April 1998 APPENDIX B - CONGESTION CONTROL ALGORITHMS Work in progress. RMTP-II APPENDICES [Page 5] Internet Draft The RMTP-II PROTOCOL 8 April 1998 APPENDIX C - SNMP MIBS FOR RMTP-II This appendix defines the SNMP MIB for the RMTP-II protocol and its entities. The MIBS are grouped according to the functionality of the RMTP-II nodes. RMTP DEFINITIONS ::= BEGIN IMPORTS enterprises, Counter, Gauge, IpAddress FROM RFC1155-SMI OBJECT-TYPE FROM RFC-1212 TRAP-TYPE FROM RFC-1215 PhysAddress FROM RFC1213-MIB; internet OBJECT IDENTIFIER ::= { iso org(3) dod(6) 1 } directory OBJECT IDENTIFIER ::= { internet 1 } mgmt OBJECT IDENTIFIER ::= { internet 2 } experimental OBJECT IDENTIFIER ::= { internet 3 } private OBJECT IDENTIFIER ::= { internet 4 } enterprises OBJECT IDENTIFIER ::= { private 1 } globalcast OBJECT IDENTIFIER ::= { enterprises 2751 } rmtp OBJECT IDENTIFIER ::= { globalcast 1 } ln OBJECT IDENTIFIER ::= { rmtp 1 } sd OBJECT IDENTIFIER ::= { rmtp 2 } ag OBJECT IDENTIFIER ::= { rmtp 3 } dr OBJECT IDENTIFIER ::= { rmtp 4 } tn OBJECT IDENTIFIER ::= { rmtp 5 } common OBJECT IDENTIFIER ::= { rmtp 6 } ------------------ -- Group common -- ------------------ inPkts OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of packets received, unicast and multicast" ::= {common 1} outPkts OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory RMTP-II APPENDICES [Page 6] Internet Draft The RMTP-II PROTOCOL 8 April 1998 DESCRIPTION "The number of packets sent" ::= {common 2} inMcastPkts OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of multicast packets received" ::= {common 3} outMcastPkts OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of multicast packets sent" ::= {common 4} -------------- -- Group ln -- -------------- lnParentAddress OBJECT-TYPE SYNTAX IpAddress ACCESS read-only STATUS mandatory DESCRIPTION "IP Address of the parent node in the RMTP tree" ::= {ln 1} lnParentPort OBJECT-TYPE SYNTAX INTEGER ACCESS read-only STATUS mandatory DESCRIPTION "UDP port of the parent node in the RMTP tree" ::= {ln 2} lnHbPkts OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of Heartbeat packets received" ::= {ln 3} lnNumRejoin OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of Rejoin requests made internally" ::= {ln 4} RMTP-II APPENDICES [Page 7] Internet Draft The RMTP-II PROTOCOL 8 April 1998 lnStreamTable OBJECT-TYPE SYNTAX SEQUENCE OF StreamEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "The Stream table - basic information." ::= {ln 5 } lnStreamEntry OBJECT-TYPE SYNTAX LnStreamEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "Each entry corresponds to one stream." INDEX {lnStreamId} ::= {lnStreamTable 1} LnStreamEntry ::= SEQUENCE { lnstreamId INTEGER, lnInDataPkts Counter, lnInRxPkts Counter, lnInNullDataPkts Counter, lnOuthackPkts Counter, lnDroppedPkts Counter, lnQos INTEGER, lnState INTEGER, lnSataChannel OCTET STRING } lnStreamId OBJECT-TYPE SYNTAX INTEGER ACCESS read-only STATUS mandatory DESCRIPTION "The unique identifier for the stream" ::= {lnStreamEntry 1} lnInDataPkts OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "Number of data packets received" ::= {lnStreamEntry 2} lnInRxPkts OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "Number of retransmission packets received" ::= {lnStreamEntry 3} RMTP-II APPENDICES [Page 8] Internet Draft The RMTP-II PROTOCOL 8 April 1998 lnInNullDataPkts OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "Number of null data packets received" ::= {lnStreamEntry 4} lnOutHackPkts OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "Number of HACK packets sent to the parent node" ::= {lnStreamEntry 5} lnDroppedPkts OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "Number of packets missed or dropped" ::= {lnStreamEntry 6} lnQos OBJECT-TYPE SYNTAX INTEGER { unordered(1), ordered(2) } ACCESS read-only STATUS mandatory DESCRIPTION "The current QoS for the stream" ::= {lnStreamEntry 7} lnState OBJECT-TYPE SYNTAX INTEGER { joining(1), joinAck(2), started(3), completed(4) } ACCESS read-only STATUS mandatory DESCRIPTION "Current state of the stream" ::= {lnStreamEntry 8} lnDataChannel OBJECT-TYPE SYNTAX OCTET STRING ACCESS read-only STATUS mandatory DESCRIPTION "Data channel used for this stream" RMTP-II APPENDICES [Page 9] Internet Draft The RMTP-II PROTOCOL 8 April 1998 ::= {lnStreamEntry 9} -------------- -- Group sd -- -------------- sdAdmitRate OBJECT-TYPE SYNTAX INTEGER ACCESS read-write STATUS mandatory DESCRIPTION "Admit rate specified by the sender application to control the bandwidth utilization" ::= {sd 1} sdDataQSize OBJECT-TYPE SYNTAX INTEGER ACCESS read-write STATUS mandatory DESCRIPTION "Current data queue size for the sender. It can be changed at run-time" ::= {sd 2} sdState OBJECT-TYPE SYNTAX INTEGER ACCESS read-only STATUS mandatory DESCRIPTION "State of the stream" ::= {sd 3} sdInHackPkts OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "Number of HACK packets received" ::= {sd 4} sdInHackPkts OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "" ::= {sd 5} sdOutDataPkts OBJECT-TYPE SYNTAX Counter ACCESS read-only RMTP-II APPENDICES [Page 10] Internet Draft The RMTP-II PROTOCOL 8 April 1998 STATUS mandatory DESCRIPTION "The number of data packets sent" ::= {sd 6} sdOutNullDataPkts OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of null data packets sent" ::= {sd 7} sdQos OBJECT-TYPE SYNTAX INTEGER { unordered(1), ordered(2) } ACCESS read-only STATUS mandatory DESCRIPTION "The QoS quality of service set for this stream" ::= {sd 8} sdQFullCounter OBJECT-TYPE SYNTAX INTEGER ACCESS read-only STATUS mandatory DESCRIPTION "The number of times the data queue was full. If this number is higher than data queue size should be increased to get better performance." ::= {sd 9} sdTopNode OBJECT-TYPE SYNTAX OCTET STRING ACCESS read-only STATUS mandatory DESCRIPTION "An ascii string for top node's address and port in the format xxx.xxx.xxx.xxx:nnnnn" ::= {sd 10} lowAdmitRate OBJECT-TYPE SYNTAX INTEGER ACCESS read-only STATUS mandatory DESCRIPTION "The lowest Admit rate provided by the sender application. In case of congestion, sender can lower the Admit Rate to lowAdmitRate." ::= {sd 11} RMTP-II APPENDICES [Page 11] Internet Draft The RMTP-II PROTOCOL 8 April 1998 highAdmitRate OBJECT-TYPE SYNTAX INTEGER ACCESS read-only STATUS mandatory DESCRIPTION "The highest Admit rate provided by the sender application. " ::= {sd 12} -------------- -- Group ag -- -------------- agParentAddress OBJECT-TYPE SYNTAX IpAddress ACCESS read-only STATUS mandatory DESCRIPTION "IP Address of the parent node in the RMTP tree" ::= {ag 1} agParentPort OBJECT-TYPE SYNTAX INTEGER ACCESS read-only STATUS mandatory DESCRIPTION "UDP port of the parent node in the RMTP tree" ::= {ag 2} agMaxChildren OBJECT-TYPE SYNTAX Gauge ACCESS read-only STATUS mandatory DESCRIPTION "The maximum number of children at any time" ::= {ag 3} agChildRejectCount OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of children rejected by the node" ::= {ag 4} agChildTable OBJECT-TYPE SYNTAX SEQUENCE OF ChildEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "The Child table - basic information." ::= {ag 5 } RMTP-II APPENDICES [Page 12] Internet Draft The RMTP-II PROTOCOL 8 April 1998 agChildEntry OBJECT-TYPE SYNTAX AgChildEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "Each entry corresponds to one Child." INDEX { agMod } ::= {agChildTable 1} AgChildEntry ::= SEQUENCE { agMod INTEGER, agStreamCount INTEGER } agMod OBJECT-TYPE SYNTAX INTEGER ACCESS read-only STATUS mandatory DESCRIPTION "The mod number assigned by the parent node" ::= {agChildEntry 1} agStreamCount OBJECT-TYPE SYNTAX INTEGER ACCESS read-only STATUS mandatory DESCRIPTION "The number of streams received by the node" ::= {agChildEntry 2} agStreamTable OBJECT-TYPE SYNTAX SEQUENCE OF AgStreamEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "The Stream table - basic information." ::= {ag 6 } agStreamEntry OBJECT-TYPE SYNTAX AgStreamEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "Each entry corresponds to one stream." INDEX {agStreamId} ::= {agStreamTable 1} AgStreamEntry ::= SEQUENCE { agStreamId INTEGER, agInHackPkts Counter, agOuthackPkts Counter, agChildCount INTEGER, agState INTEGER, RMTP-II APPENDICES [Page 13] Internet Draft The RMTP-II PROTOCOL 8 April 1998 agMaxLossRate INTEGER, agMaxLossRateAddress IpAddress } agStreamId OBJECT-TYPE SYNTAX INTEGER ACCESS read-only STATUS mandatory DESCRIPTION "The unique identifier for the stream" ::= {agStreamEntry 1} agInHackPkts OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "Number of HACK packets received" ::= {agStreamEntry 2} agOutHackPkts OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "Number of HACK packets sent" ::= {agStreamEntry 3} agChildCount OBJECT-TYPE SYNTAX INTEGER ACCESS read-only STATUS mandatory DESCRIPTION "Number of children receiving this stream" ::= {agStreamEntry 4} agState OBJECT-TYPE SYNTAX INTEGER { joining(1), joinAck(2), started(3), completed(4) } ACCESS read-only STATUS mandatory DESCRIPTION "Current state of the stream" ::= {agStreamEntry 5} agMaxLossRate OBJECT-TYPE SYNTAX INTEGER ACCESS read-only STATUS mandatory RMTP-II APPENDICES [Page 14] Internet Draft The RMTP-II PROTOCOL 8 April 1998 DESCRIPTION "Maximum loss rate of all the child nodes" ::= {agStreamEntry 6} agMaxLossRateAddress OBJECT-TYPE SYNTAX IpAddress ACCESS read-only STATUS mandatory DESCRIPTION "IP Address of the node having maximum loss" ::= {agStreamEntry 7} -------------- -- Group tn -- -------------- tnMaxChildren OBJECT-TYPE SYNTAX Gauge ACCESS read-only STATUS mandatory DESCRIPTION "The maximum number of children at any time" ::= {tn 1} tnChildRejectCount OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of children rejected by the node" ::= {tn 2} -------------------------------------------------- -- Global Parameters maintained at the top node -- -------------------------------------------------- branchFactor OBJECT-TYPE SYNTAX INTEGER ACCESS read-write STATUS mandatory DESCRIPTION "The maximum number of children for any node in the tree" ::= {tn 3} thackConstant OBJECT-TYPE SYNTAX INTEGER ACCESS read-write STATUS mandatory DESCRIPTION "The scaling coefficient for thack" ::= {tn 4} overHead OBJECT-TYPE SYNTAX INTEGER RMTP-II APPENDICES [Page 15] Internet Draft The RMTP-II PROTOCOL 8 April 1998 ACCESS read-write STATUS mandatory DESCRIPTION "The maximum number of HACKs should be received, for each data packet, at control nodes" ::= {tn 5} tJoinResponse OBJECT-TYPE SYNTAX INTEGER ACCESS read-write STATUS mandatory DESCRIPTION "Maximum time to wait for a response to a JoinStream request" ::= {tn 6} rJoin OBJECT-TYPE SYNTAX INTEGER ACCESS read-write STATUS mandatory DESCRIPTION "The number of retries of the JoinRequest befor declaring the parent unreachable" ::= {tn 7} tHB OBJECT-TYPE SYNTAX INTEGER ACCESS read-write STATUS mandatory DESCRIPTION "The time interval at which control nodes multicast heartbeat packets" ::= {tn 8} failureConstant OBJECT-TYPE SYNTAX INTEGER ACCESS read-write STATUS mandatory DESCRIPTION "The threshold time for failure detection" ::= {tn 9} tNulldataMax OBJECT-TYPE SYNTAX INTEGER ACCESS read-write STATUS mandatory DESCRIPTION "Maximum time interval between NullData packets" ::= {tn 10} thackMax OBJECT-TYPE SYNTAX INTEGER RMTP-II APPENDICES [Page 16] Internet Draft The RMTP-II PROTOCOL 8 April 1998 ACCESS read-write STATUS mandatory DESCRIPTION "Maximum time allowed between HACK transmission for each node" ::= {tn 11} rxMax OBJECT-TYPE SYNTAX INTEGER ACCESS read-write STATUS mandatory DESCRIPTION "Maximum number of retransmissions for a data packet" ::= {tn 12} optimistic OBJECT-TYPE SYNTAX INTEGER { pessimistic(0) optimistic(1), } ACCESS read-write STATUS mandatory DESCRIPTION "Defines the stability property for the RMTP-II tree" ::= {tn 13} tnChildTable OBJECT-TYPE SYNTAX SEQUENCE OF TnChildEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "The Child table - basic information." ::= {tn 14 } tnChildEntry OBJECT-TYPE SYNTAX TnChildEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "Each entry corresponds to one Child." INDEX { tnMod } ::= {tnChildTable 1} TnChildEntry ::= SEQUENCE { tnMod INTEGER, tnStreamCount INTEGER } tnMod OBJECT-TYPE SYNTAX INTEGER ACCESS read-only STATUS mandatory DESCRIPTION "The mod number assigned by the parent node" RMTP-II APPENDICES [Page 17] Internet Draft The RMTP-II PROTOCOL 8 April 1998 ::= {tnChildEntry 1} tnStreamCount OBJECT-TYPE SYNTAX INTEGER ACCESS read-only STATUS mandatory DESCRIPTION "The number of streams received by the node" ::= {tnChildEntry 2} tnStreamTable OBJECT-TYPE SYNTAX SEQUENCE OF TnStreamEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "The Stream table - basic information." ::= {tn 4 } tnStreamEntry OBJECT-TYPE SYNTAX TnStreamEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "Each entry corresponds to one stream." INDEX {tnStreamId} ::= {tnStreamTable 1} TnStreamEntry ::= SEQUENCE { tnStreamId INTEGER, tnInHackPkts Counter, tnOuthackPkts Counter, tnChildCount INTEGER, tnState INTEGER, tnMaxLossRate INTEGER, tnMaxLossRateAddress IpAddress } tnStreamId OBJECT-TYPE SYNTAX INTEGER ACCESS read-only STATUS mandatory DESCRIPTION "The unique identifier for the stream" ::= {tnStreamEntry 1} tnInHackPkts OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "Number of HACK packets received" ::= {tnStreamEntry 2} RMTP-II APPENDICES [Page 18] Internet Draft The RMTP-II PROTOCOL 8 April 1998 tnOutHackPkts OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "Number of HACK packets sent" ::= {tnStreamEntry 3} tnChildCount OBJECT-TYPE SYNTAX INTEGER ACCESS read-only STATUS mandatory DESCRIPTION "Number of children receiving this stream" ::= {tnStreamEntry 4} tnState OBJECT-TYPE SYNTAX INTEGER { joining(1), joinAck(2), started(3), completed(4) } ACCESS read-only STATUS mandatory DESCRIPTION "Current state of the stream" ::= {tnStreamEntry 5} tnMaxLossRate OBJECT-TYPE SYNTAX INTEGER ACCESS read-only STATUS mandatory DESCRIPTION "Maximum loss rate of all the child nodes" ::= {tnStreamEntry 6} tnMaxLossRateAddress OBJECT-TYPE SYNTAX IpAddress ACCESS read-only STATUS mandatory DESCRIPTION "IP Address of the node having maximum loss" ::= {tnStreamEntry 7} tnSenderTable OBJECT-TYPE SYNTAX SEQUENCE OF SenderEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "The sender table - basic information." ::= {tn 5 } RMTP-II APPENDICES [Page 19] Internet Draft The RMTP-II PROTOCOL 8 April 1998 tnSenderEntry OBJECT-TYPE SYNTAX SenderEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "Each entry corresponds to one sender." INDEX {tnStreamId} ::= {tnSenderTable 1} SenderEntry ::= SEQUENCE { tnSdstreamId INTEGER, tnSdAddress IpAddress, tnSdPort INTEGER } tnSdStreamId OBJECT-TYPE SYNTAX INTEGER ACCESS read-only STATUS mandatory DESCRIPTION "The unique identifier for the stream" ::= {tnSenderEntry 1} tnSdAddress OBJECT-TYPE SYNTAX IpAddress ACCESS read-only STATUS mandatory DESCRIPTION "IP Address of the sender node" ::= {tnSenderEntry 2} tnSdPort OBJECT-TYPE SYNTAX INTEGER ACCESS read-only STATUS mandatory DESCRIPTION "UDP Port of the sender node" ::= {tnSenderEntry 3} ---------------------------------------------------- -- The configuration table for each of the sender -- -- each entry gives the current, minimum and -- -- maximum admit rate for the sender. -- ---------------------------------------------------- tnSdConfigTable OBJECT-TYPE SYNTAX SEQUENCE OF SenderConfigEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "The sender Config table - Rate information." ::= {tn 6 } RMTP-II APPENDICES [Page 20] Internet Draft The RMTP-II PROTOCOL 8 April 1998 tnSenderConfigEntry OBJECT-TYPE SYNTAX SenderConfigEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "Each entry corresponds to one sender, sender index is used as the INDEX for this table" INDEX {tnSdIndex} ::= {tnSenderConfigTable 1} SenderConfigEntry::= SEQUENCE { tnSdIndex INTEGER, sdCurrentRate INTEGER, sdMaxRate INTEGER, sdMinRate INTEGER, sdCommand INTEGER } tnSdIndex OBJECT-TYPE SYNTAX INTEGER ACCESS read-only STATUS mandatory DESCRIPTION "The unique identifier for the sender" ::= {tnSenderConfigEntry 1} sdCurrentRate OBJECT-TYPE SYNTAX INTEGER ACCESS read-write STATUS mandatory DESCRIPTION "The current admit rate for the sender node" ::= {tnSenderConfigEntry 2} sdMaxRate OBJECT-TYPE SYNTAX INTEGER ACCESS read-write STATUS mandatory DESCRIPTION "The maximum admit rate for the sender node" ::= {tnSenderConfigEntry 3} sdMinRate OBJECT-TYPE SYNTAX INTEGER ACCESS read-write STATUS mandatory DESCRIPTION "The minimum admit rate for the sender node" ::= {tnSenderConfigEntry 4} sdCommand OBJECT-TYPE SYNTAX INTEGER ACCESS write-only RMTP-II APPENDICES [Page 21] Internet Draft The RMTP-II PROTOCOL 8 April 1998 STATUS mandatory DESCRIPTION "The commands that can be passed to the sender node" ::= {tnSenderConfigEntry 5} -------------- -- Group dr -- -------------- drParentAddress OBJECT-TYPE SYNTAX IpAddress ACCESS read-only STATUS mandatory DESCRIPTION "IP Address of the parent node in the RMTP tree" ::= {dr 1} drParentPort OBJECT-TYPE SYNTAX INTEGER ACCESS read-only STATUS mandatory DESCRIPTION "UDP port of the parent node in the RMTP tree" ::= {dr 2} drMaxChildren OBJECT-TYPE SYNTAX Gauge ACCESS read-only STATUS mandatory DESCRIPTION "The maximum number of children at any time" ::= {dr 3} drChildRejectCount OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of children rejected by the node" ::= {dr 4} drChildTable OBJECT-TYPE SYNTAX SEQUENCE OF ChildEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "The Child table - basic information." ::= {dr 5 } drChildEntry OBJECT-TYPE SYNTAX DrChildEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "Each entry corresponds to one Child." RMTP-II APPENDICES [Page 22] Internet Draft The RMTP-II PROTOCOL 8 April 1998 INDEX { drMod } ::= {drChildTable 1} DrChildEntry ::= SEQUENCE { drMod INTEGER, drStreamCount INTEGER } drMod OBJECT-TYPE SYNTAX INTEGER ACCESS read-only STATUS mandatory DESCRIPTION "The mod number assigned by the parent node" ::= {drChildEntry 1} drStreamCount OBJECT-TYPE SYNTAX INTEGER ACCESS read-only STATUS mandatory DESCRIPTION "The number of streams received by the node" ::= {drChildEntry 2} drStreamTable OBJECT-TYPE SYNTAX SEQUENCE OF DrStreamEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "The Stream table - basic information." ::= {dr 6 } drStreamEntry OBJECT-TYPE SYNTAX DrStreamEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "Each entry corresponds to one stream." INDEX {drStreamId} ::= {drStreamTable 1} DrStreamEntry ::= SEQUENCE { drStreamId INTEGER, drInHackPkts Counter, drOuthackPkts Counter, drChildCount INTEGER, drState INTEGER, drMaxLossRate INTEGER, drMaxLossRateAddress IpAddress } drStreamId OBJECT-TYPE RMTP-II APPENDICES [Page 23] Internet Draft The RMTP-II PROTOCOL 8 April 1998 SYNTAX INTEGER ACCESS read-only STATUS mandatory DESCRIPTION "The unique identifier for the stream" ::= {drStreamEntry 1} drInHackPkts OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "Number of HACK packets received" ::= {drStreamEntry 2} drOutHackPkts OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "Number of HACK packets sent" ::= {drStreamEntry 3} drChildCount OBJECT-TYPE SYNTAX INTEGER ACCESS read-only STATUS mandatory DESCRIPTION "Number of children receiving this stream" ::= {drStreamEntry 4} drState OBJECT-TYPE SYNTAX INTEGER { joining(1), joinAck(2), started(3), completed(4) } ACCESS read-only STATUS mandatory DESCRIPTION "Current state of the stream" ::= {drStreamEntry 5} drMaxLossRate OBJECT-TYPE SYNTAX INTEGER ACCESS read-only STATUS mandatory DESCRIPTION "Maximum loss rate of all the child nodes" ::= {drStreamEntry 6} drMaxLossRateAddress OBJECT-TYPE SYNTAX IpAddress RMTP-II APPENDICES [Page 24] Internet Draft The RMTP-II PROTOCOL 8 April 1998 ACCESS read-only STATUS mandatory DESCRIPTION "IP Address of the node having maximum loss" ::= {drStreamEntry 7} END RMTP-II APPENDICES [Page 25] Internet Draft The RMTP-II PROTOCOL 8 April 1998 APPENDIX D - FORWARD ERROR CORRECTION Recent work [NB96, NBT97, Rizzo97] has shown the benefits of incorporating forward error correction (FEC) into reliable multicast protocols. RMTP-II supports two modes of FEC: Proactive and Reactive. Proactive FEC is a mechanism by which parity packets are sent along with the data packets. The receivers use the parity packets to recover the missing data packets. This is used in environments where there is no back channel to get feedback from the receivers to the sender, and to support real time applications. Reactive FEC is a mechanism by which the sender encodes and sends parity packets only if it gets notification about missed data packets. The sender sends parity packets instead of retransmitting the data packets. The receivers are able to repair different lost packets with these parity packets. This is used in environments where receivers face independent loss. For example, if receivers are connected to the network by modem, the losses at the various receivers may be independent. If each receiver looses a different packet then there may be much transmission. Each receiver may be able to recover its missed data when a parity packet is transmitted. Algorithm Parity packets are sent using the reserved sequence number zero and the FEC option. The FEC option has three fields: BeginSeq: This is the beginning data packet sequence number for the FEC block. EndSeq: This is the end data packet sequence number for the FEC block. Index: This is the index number used for the parity packet. All data packets within a block need to be of fixed size to calculate parity. When transmitting, the sender must find the max size, Smax, from all the packets in the FEC block. All bytes in the block between the actual packet length and Smax are set to zero. This is only done for FEC calculation. Proactive FEC The following parameters are required: RMTP-II APPENDICES [Page 26] Internet Draft The RMTP-II PROTOCOL 8 April 1998 Bmax: This is the maximum block size (number of packets in a block). P: This is the number of parity packets per block. Tmax: This is the maximum time interval, after which a parity packet is forced out. When the sender sends the first packet of a block, it schedules a timer for time Tmax. After it sends Bmax packets, the sender computes P parity packets for Bmax packets and then sends the parity packets with sequence number zero. If the timer expires, then compute P parity packets just for the number of packets that have been sent. If the receiver receives a parity packet, it determines whether it has missed any data packets within the FEC block. The FEC option in the parity packet has the block information. If no data packets are missing within the FEC block it ignores the parity packets. If a receiver determines that one or more data packets are missed within a FEC block, it waits to receive that many parity packets. When it receives the required parity packets, the receiver passes the received data packets and parity packets to the FEC decoder to recover the missed data packets. If the parity packets received are less than the missed data packets within a FEC block, the FEC decoder cannot generate the missed data packets. In such a situation, it waits to recover the missed data packets from the data retransmissions done by the sender. Reactive FEC The following parameters are required: Bmax: This is the maximum block size (the number of packets in a block. P: The number of parity packets per block. When the sender receives a HACK, it creates FEC blocks from Lowest Sequence Number to Highest Sequence Number. It computes parity packets for each block and sends the parity packets instead of retransmitting the data packets. The receivers use these parity packets to compute the missed data packets. If the receiver cannot compute the missed data packets from RMTP-II APPENDICES [Page 27] Internet Draft The RMTP-II PROTOCOL 8 April 1998 the parity packets, it uses the FEC option in the HACK packet to notify the sender to retransmit the data packet instead of sending parity packets. The control node propagates this FEC option to the sender. If the sender receives a HACK with the FEC option to retransmit the data packets set, it will retransmit the data packets and not send parity packets. FEC option for HACK packet This option allows the receivers to request retransmission of data instead of parity 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | A | OTYPE | LENGTH | SendData | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ A: set to 00 skip option, process packet OTYPE: set to 11 Gcast FEC LENGTH: set to 1 SendData: If set, then all the control nodes, propagate this option to the sender. The sender retransmits the data packets instead of sending parity packets. FEC option for data packet This option allows the sender to send FEC parity packets to receivers. 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 | LENGTH | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | BeginSeq | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | EndSeq | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ParityIndex | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ A: set to 00 - skip option, process packet RMTP-II APPENDICES [Page 28] Internet Draft The RMTP-II PROTOCOL 8 April 1998 OTYPE: set to 11 - Gcast FEC LENGTH: set to 4 BeginSeq: This is the beginning data packet sequence number for the FEC block. EndSeq: This is the end data packet sequence number for the FEC block. ParityIndex: This is the index number used for the parity packet. References [NB96] J. Nonnenmacher and E.W. Biersack, "Reliable Multicast: Where to use Forward Error Correction", Proc. 5th. Workshop on Protocols for High Speed Networks, Sophia Antipolis, France, Oct. 1996. [NBT97] J. Nonnenmacher, E. W. Biersack, and Don Towsley. "Parity- Based Loss Recovery for Reliable Multicast Transmission", In Proc. of ACM SIGCOMM '97, Cannes, France, September 1997. [Rizzo97] L. Rizzo, "Effective erasure codes for reliable computer communications protocols", DEIT Technical Report LR-970115. RMTP-II APPENDICES [Page 29] Internet Draft The RMTP-II PROTOCOL 8 April 1998 APPENDIX E - TIME BOUNDED RELIABILITY RMTP includes a new quality of service level called Time Bounded Reliability. This QoS is designed to support synchronous streaming data types, such as streaming audio and video, and real time financial data. Packets with this QoS level are assigned a maximum latency Bound, and the receiver attempts to deliver the packets with a QoS of Source Ordered for up to Bound seconds. After that time elapses, the receiver stops requesting retransmission of the missing packets and "delivers" them to the application as an error code. This allows packets which have been blocking on the missing packets (because they have higher sequence numbers than the missing ones) to be delivered within a fixed amount of time after they are sent. Each stream can have only a single QoS and Bound associated with it, and this is fixed for the duration of the stream. We define the following variables for a given packet. Tsent: The time at the sender when the packet was generated (based on sender's clock). Treceived: The time at the receiver when the packet was received (based on receiver's clock). Lmin: The minimum physical latency for a packet to be delivered from the sender to the receiver. Bound: The maximum time allowed for recovery of a packet. Cdiff: The difference in clocks between the sender and the reciever. Tdrop: The time at the receiver when the packet should be declared dropped (based on receiver's clock). In order to be scalable, the protocol can not rely on any true clock synchronization algorithms for determining Cdiff. Instead, Lmin is defined as the minimum observed latency between the two computers, which occurs when (Treceived-Tsent) is the smallest. When each packet is received, the receiver calculates this Diff=Treceived- Tsent, and compares it to Cdiff. If it is smaller than Cdiff (which is initially set to positive infinity), then Cdiff is set to Diff. Tdrop for a given packet is then defined as Bound - Tsent + Cdiff. Given this, the algorithm may not give accurate results when: Bound is smaller than the sum of Lmin plus the timer resolution on the receivers' machines. During the initial packets sent in a data stream, when Cdiff has not yet been measured accurately. When a packet is sent, Tsent is included in the packet's header. RMTP-II APPENDICES [Page 30] Internet Draft The RMTP-II PROTOCOL 8 April 1998 Tsent is the time at which the sender's transport received the packet, not adjusted for daylight savings time. All clock measurements are not adjusted for daylight savings time, to avoid any discontinuities in operation when a computer adjusts its internal clock for this time change. When the packet is received, the current clock at the receiver is measured as Treceived, and Cdiff is updated if necessary. The packets in each receiver's incoming data queue are sorted by sequence number, using sequence number arithmetic. For the packet in the queue with the lowest sequence number, the current time at the receiver is regularly compared against Tdrop, as calculated with Tsent for that packet and the current values of Cdiff and Bound. If the current time is larger than Tdrop, then all of the missing packets with smaller sequence numbers are "delivered" to the application as error codes, and the tested packet is delivered as well. When this occurs, the receivers will stop requesting retransmission for the "delivered" missing packets, and will consider them to have gone stable. RMTP-II APPENDICES [Page 31] Internet Draft The RMTP-II PROTOCOL 8 April 1998 APPENDIX F - WORK IN PROGRESS Work is currently in progress for the following areas: 1) Security considerations 2) Analysis of protocol performance 3) Proof of protocol correctness 4) Integration with generic router assist mechanisms 5) Definition of automatic tree configuration algorithms for use in the session manager 6) Analysis of congestion control algorithms relative to TCP traffic 7) Header compression, including HACK bitfield compression The authors welcome any and all feedback on this draft, as well as offers to collaborate on any of these work in progress areas. RMTP-II APPENDICES [Page 32]