[Search] [txt|pdf|bibtex] [Tracker] [Email] [Nits]

Versions: 00                                                            
   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]