RMT Working Group                                         Brian Whetten
Internet Engineering Task Force                                Talarian                              Consultant
Internet Draft                                            Dah Ming Chiu
Document: draft-ietf-rmt-bb-track-01.txt               Sun Microsystems
 2 March, 2001 draft-ietf-rmt-bb-track-02.txt                Miriam Kadansky
 Expires 2 October, 2001
November 2002                                          Sun Microsystems
Expires May 2003                                           Seok Joo Koh
                                                                   ETRI
                                                         Gursel Taskale
                                                                Talarian
                                                                  TIBCO

         Reliable Multicast Transport Building Block for TRACK
                    <draft-ietf-rmt-bb-track-01.txt>
                    <draft-ietf-rmt-bb-track-02.txt>

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups. Note that other
   groups may also distribute working documents as Internet-
    Drafts. Internet-Drafts.
   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 Internet- Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt
   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

Abstract

   This document describes the TRACK Building Block.  It contains
   functions relating to positive acknowledgments and hierarchical tree
   construction and maintenance.  It is primarily meant to be used as
   part of the TRACK Protocol Instantiation.  It is also designed to be
   useful as part of overlay multicast systems that wish to offer
   efficient confirmed delivery of multicast messages.

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.

 Table of Contents

1. Introduction
    2. Design Rationale
    3. Applicability Statement
    3.1 Application types
    3.2 Network Infrastructure
    4. Message Types
    5. Global Configuration Variables, Constants, and Reason Codes
    5.1 Global Configuration Variables
    5.2 Constants
    5.3 Reason Codes
    6. External APIs
    6.1 Interfaces to
   One of the BB from PI's
    6.1.1 Start(boolean RepairHead, boolean RejoinAllowed,
          Advertisement)
    6.1.2 End
    6.1.3 incomingMessage(Message)
    6.1.4 getStatistics
    6.1.5 MessageSynched(Message)
    6.1.6 RepairHead(boolean)
    6.2 Interfaces from protocol instantiations the BB RMT WG is chartered to the PI
    6.2.1 outgoingMessage(Message)
    6.2.2 MessageReceived(Message, boolean Synch)
    6.2.3 SenderLost
    6.2.4 UnrecoverableData
    6.2.5 SessionDone
    7. Algorithms
    7.1 Tree Based Session Creation and Maintenance
    7.1.1 Overview create
   is a TRee-based ACKnowledgement protocol (TRACK).  Rather than create
   a set of Tree Configuration
    7.1.2 Bind
    7.1.2.1 Input Parameters
    7.1.2.2 Bind Algorithm
    7.1.3 Unbind
    7.1.4 Eject
    7.1.5 Fault Detection
    7.1.6 Fault Notification
    7.1.7 Fault Recovery
    7.2 TRACK Generation
    7.2.1 TRACK Generation with monolithic protocol specifications, the Rotating TRACK Algorithm
    7.2.2 Local Repair
    7.2.3 Flow Control Window Update
    7.2.4 Reliability Window
    7.2.5 Confirmed Delivery
    7.3 Feedback Aggregation
    7.4 Measuring Round Trip Times
    8. Security
    9. References
    10. Acknowledgements
    11. Authors' Addresses
 1. Introduction
    This document describes RMT WG has chosen to
   break the TRACK reliable multicast protocols into Building Block.  It contains
    functions relating to positive acknowledgments and hierarchical
    tree construction Blocks (BB) and maintenance.  It
   Protocol Instantiations (PI).  A Building Block is primarily meant to be
    used as part a specification of
   the TRACK Protocol Instantiation.  It is also
    designed to be useful as part algorithms of overlay multicast systems that
    wish a single component, with an abstract interface to offer efficient confirmed delivery
   other BBs and PIs.  A PI combines a set of multicast messages.

    As pointed out BBs, adds in the building blocks rationale draft [WVKHFL00],
   additional required functionality not specified in any BB, and
   specifies the specific instantiation of the protocol. For more
   information, see the Reliable Multicast Transport Building Blocks and
   Reliable Multicast Design Space documents [2][3].

   As specified in [2], there are two different primary reliability tasks that can be provided by requirements
   for a
    reliable multicast transport: transport protocol, ensuring goodput goodput, and confirming delivery of application level messages.
   to the Sender.  The NACK Protocol
    Instantiation NORM and ALC Protocol Instantiation PIs are each primarily
    concerned with responsible solely for
   ensuring goodput.  The  TRACK BB is designed to offer application level
   confirmed delivery, aggregation of control traffic and Receiver
   statistics, local recovery, automatic tree building, and enhanced
   flow and congestion control.

   Whereas the NORM and ALC PIs run only over other building blocks, the
   TRACK PI rely on has a repair tree to provide goodput as well as confirmed delivery. If
    Forward Error Correction, Generic Router Assist 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 mechanisms
    are used protocols in addition to help provide goodput, they are assumed NORM.  To meet
   both of these challenges, the TRACK PI is designed to work
    transparently at a integrate with
   other transport layer below this BB, as if the IP protocols, including NORM, PGM [20], ALC [19],
   UDP, or an overlay multicast
    service has lower error rate.

    The TRACK BB also assumes that system.  In order to accomplish this,
   there can be multiple TRACK PIs, one for each transport protocol it
   is an Automatic Tree Building
    BB [KLCWTCTK01] which provides the list specified to integrate with.  The vast majority of parents (known as
    Service Nodes within the protocol
   functionality exists in Tree BB) each node should join to.  If
    Receivers are used that may also serve as Repair Heads, this document, the TRACK
    BB assumes BB, which in turn
   references the Auto Tree BB is also responsible for selecting automatic tree building block [16].  For more details
   on the
    role specific functionality of each Receiver as either Receiver or Repair Head.  However, TRACK, please see the reference
   TRACK BB may specify that PI[21].

   TRACK is organized around a particular node may not operate as Data Channel and a Repair Head. Control Channel.  The TRACK BB also assumes that a separate session
   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.

   This document describes the TRACK Building Block.  It contains
   functions relating to positive acknowledgments and hierarchical tree
   construction and maintenance.  While named as a building block, this
   document describes more functionality than the PI documents.  With
   the exception of congestion control, almost all of the functionality
   is encapsulated in this document or the BBs it references.  The TRACK
   PIs are then primarily responsible for instantiating packet formats
   in conjunction with the other transport protocols it uses as its Data
   Channel.

   The TRACK BB assumes that there is an Automatic Tree Building BB [16]
   which provides the list of parents (known as Service Nodes within the
   Tree BB) each node should join to.  If Receivers are used that may
   also serve as Repair Heads, the TRACK BB assumes the Auto Tree BB is
   also responsible for selecting the role of each Receiver as either
   Receiver or Repair Head.  However, the TRACK BB may specify that a
   particular node may not operate as a Repair Head.

   The TRACK BB also assumes that a separate session advertisement
   protocol notifies the receivers Receivers as to when to join a session, the
   data multicast address for the session, and the control parameters
   for the session.

    The  This functionality MAY be provided in a TRACK BB provides additional information and aggregation
    capabilities, which are useful for congestion control. PI
   document.

   The TRACK BB provides the following detailed functionality.

    @ Hierarchical

   ...    .Hierarchical Session Creation and Maintenance.  This set of
     functionality is responsible for creating and maintaining (but not
     configuring) the a hierarchical tree of Repair Heads and Receivers.
         o
        - Bind.  When a child knows the parent it wishes to join to for
          a given data session, it Data Session, it binds to that parent.
         o
        - Unbind.  When a child wishes to leave a data session, Data Session, either
          because the session is over or because the application is
          finished with the session, it initiates an unbind operation
          with its parent.

         o
        - Eject.  A parent can also force a child to unbind.  This
          happens if the parent needs to leave the session, if the child
          is not behaving correctly, or if the parent wants to move the
          child to another parent as part of tree configuration
          maintenance.
         o
        - Fault Detection.  In order to verify liveness, parents and
          children send regular heartbeat messages between themselves.
          The sender Sender also sends regular null data messages to the group,
          if it has no data to send.
         o
        - Fault Recovery.  When a child detects that its parent is no
          longer reachable, it may switch to another parent.  When a
          parent detects that one of its children is no longer
          reachable, it removes that child from its membership list and
          reports this up the tree to the Sender of the Data Session.

    @ TRACK Generation.  This set
        - Distributed Membership.  Each Parent is responsible for
          maintaining a local list of the children attached to it.

   - Data Sessions.  This functionality is responsible for
       periodically generating TRACK messages from all receivers to
       acknowledge receipt the reliable,
     ordered transmission of data, report missing a set of data messages, advance
       flow control windows, provide roundtrip time measurements which together
     constitute a Data Session.  These are initially transmitted using
     another transport protocol, the Data Channel Protocol, which has
     primary responsibility for ensuring goodput and
       provide other group management information. congestion control.
        - Data Transmission.  The algorithms
       include:
         o TRACK Timing.  In order to avoid ACK implosion, Sender takes sequenced data messages
          from the
            Receivers application, and Repair Heads use passes them to the rotating TRACK
            algorithm.
         o Data Channel
          Protocol for multicast transmission.  It delays passing them
          to the Data Channel Protocol if it is presently flow
          controlled.
        - Flow Control and Buffer Management.  Receivers and Repair
          Heads MAY maintain a set of buffers that are at least as large
          as the Sender's Senders transmission window.  The Receivers pass their
          reception status up to the sender Sender as part of their TRACK
          messages.  This is MAY be used to acknowledge receipt of
            delivery, to advance the buffer windows at
          each node, node and
            to limit the sender's Senders window advancement to the
          speed of the slowest receiver.
         o Application Level Confirmed Delivery.  Confirmed Delivery
            provides transport level confirmation of delivery.  Senders
            can put a synch point request in data messages, asking Receiver.
        - Retransmission Requests.  While primary responsibility for application level confirmation.  Data messages
          goodput rests with
            this flag set are only confirmed by the Data Channel Protocol, Receivers after the
            Receiver applications confirm receipt.

    @ MAY
          request retransmission of lost messages from their parents.
        - Local Recovery. This functionality describes how repair  Repair heads
       maintain state on keep track of retransmission
          requests from their children children, and provide repairs in response to requests for them.  If
          a Repair Head cannot fulfill a retransmission contained in TRACK messages.
       This has overlap with the NACK BB, which is unified in the TRACK
       PI.

    @ TRACK Aggregation. In order to provide request, it
          forwards it up the highest levels tree.
        - End of
       scalability and Stream.  When a Data Session is completed, this is
          signaled as an End of Stream condition.

   ...TRACK Generation and Aggregation.  This set of functionality is
     responsible for periodically generating TRACK messages from all
     Receivers and aggregating them at Repair Heads.  These messages
     provide updated flow control window information, roundtrip time
     measurements, and congestion control statistics.  They OPTIONALLY
     acknowledge receipt of data, OPTIONALLY report missing messages,
     and OPTIONALLY provide group statistics.  The algorithms include:
        - TRACK Timing.  In order to avoid ACK implosion, the Receivers
          and Repair Heads use timing algorithms to control the speed at
          which TRACK messages are sent.
        - TRACK Aggregation. In order to provide the highest levels of
          scalability and reliability, interior tree nodes provide
          aggregation of control traffic flowing up the tree.  The
          aggregated feedback information includes that used for end-to-
          end confirmed delivery, flow control, congestion control, and
          group membership monitoring and management.

    @
        - Statistics Request.  A Sender may prompt Receivers to generate
          and report a set of statistics back to the Sender.  These
          statistics are self-describing data types, and may be defined
          by either the TRACK PI or the application.

        - Statistics Aggregation. In addition to the predefined
          aggregation types, aggregation of self-describing data may
          also be performed on Receiver statistics flowing up the tree.

   . Application Level Confirmed Delivery.  Senders can issue requests
     for application level confirmation of data up to a given message.
     Receivers reply to this request, and the confirmations are reliably
     forwarded up the tree.

   - Distributed RTT Calculations.  One of the primary challenges of
     congestion control is efficient RTT calculations.  TRACK provides
     two methods to perform these calculations.
         o
        - Sender Per-Message RTT Calculations.  Each message is
            stamped  On demand, a Sender
          stamps outgoing messages with a timestamp from the sender. timestamp.  As each TRACK is
          passed up the tree, the amount of dally time spent waiting at
          each node is accumulated.  The lowest measurements are passed
          up the tree, and the dally time is subtracted from the
          original measurement.
         o
        - Local Per-Level RTT Calculations.  Each parent measures the
          local RTT to each of its children as part of the keep-alive
          messages used for failure detection.

2. Design Rationale

    Much of the design rationale behind the protocol instantiations and
    building blocks being standardized by the RMT working group are
    laid out in [WVKHFL00].  In addition, the design rationale for the
    TRACK PI is laid out in [WCP00].  This building block conforms with
    the design rationales laid out in both Applicability Statement

   The primary objective of those documents. TRACK is designed to provide confirmed delivery, receiver-based
    flow control, distributed management of group membership (some of
    them may be dedicated servers in a repair tree), as well as
    providing aggregation of information up the tree.  It also provides
    requests for retransmissions as part of TRACK messages, and local
    recovery of lost packets.

    This TRACK BB is primarily designed to work as part of the TRACK
    PI, additional functionality
   in conjunction with other BB's including NACK, FEC, a receiver reliable protocol.  These functions
   MAY include application layer reliability, enhanced congestion
   control, flow control, statistics reporting, local recovery, and Auto
    Tree.  In the spirit of modular reuse specified in [WVKHFL00], it
   automatic tree building.  It is also designed to be useful as an additional layer of
    functionality on top of any of the following services.  1) The
    functionality (if not the exact message headers) of the NORM PI.
    2) The functionality (if not do this while still
   offering scalability in the exact message headers) range of the ALC
    PI.  3) Running directly on top 10,000s of an unreliable IP multicast
    routing protocol, but on a carefully provisioned network.  4) On
    top Receivers per Data
   Session.  The primary corresponding design tradeoffs are additional
   complexity, and lower isolation of an overlay multicast (also known as application layer
    multicast) system.

    Overlay multicast is a system where servers nodes in the network provide
    multicast (and unicast) routing as well as reliable multicast
    delivery, all on top of a combination face of unicast (i.e. TCP) and, as
    available, reliable multicast services. network and
   host failures.

   There is a fundamental tradeoff between reliability and real-time
   performance in the face of failures.  There are two primary types of
   single layer reliability that have been proposed to deal with this:  sender
   Sender reliable and receiver Receiver reliable delivery.  Sender reliable
   delivery is similar to TCP, where the sender Sender knows the identity of
   the receivers Receivers in a data session, Data Session, and is notified when any of them
   fails to receive all the data messages.  Receiver reliable delivery
   limits knowledge of group membership and failures to only the actual receivers.
   Receivers.  Senders do not have any knowledge of the membership of a
   group, and do not require receivers Receivers to explicitly join or leave a data session.
   Data Session.  Receiver reliable protocols scale better in the face
   of networks that have frequent failures, and have very high isolation
   of failures between
    receivers. Receivers.  This TRACK BB provides sender Sender
   reliable delivery,
    potentially on top of typically in conjunction with a receiver Receiver reliable
   system.

   This BB is specified according to the guidelines in [KV00].  In
    addition, it [21].  It
   specifies all communication between entities in terms of messages,
   rather than packets.  A message is an abstract communication unit,
   which may be part of, or all of, a given packet.  It does not have a
   specific format, although it does contain a list of fields, some of
   which may be optional, and some of which may have fixed lengths
   associated with them.  It is up to each protocol instantiation to
   combine the set of messages in this BB, with those in other
   components, and create the actual set of
    message packet formats that will be
   used.

   As mentioned in the introduction, this BB assumes the existence of a
   separate Auto Tree Configuration BB.  It also assumes that data
    sessions Data
   Sessions are advertised to all receivers Receivers as part of an external BB or
   other component.  It expects

   Except where noted, this applicability statement is applicable both
   to also interact with other BB's
    through the TRACK PI, but does not require this.

 3. Applicability Statement
    It is widely recognized that no single reliable multicast protocol
    can meet the needs of all application types over all network types.
    Distinguishing factors include functionality and performance.
    From a functionality perspective, TRACK BB and NACK based reliable
    multicast protocols present an inherently different reliability
    model.  TRACK based protocols are able to remove messages from the
    retransmission window when all the children have acknowledged them.
    NACK based protocols have to rely on other means for determining
    how long to keep messages in the retransmission window.  A popular
    method is a time based scheme[SFCGLTLLBEJMRSV00]. TRACK based
    protocols can keep track of the membership of the data session, and
    provide confirmed delivery against that membership list.  NACK
    protocols have anonymous membership.

    Since reliability PIs.

2.1 Application Types

   TRACK is obtained through control traffic, the
    difference in the semantics of the term reliability lead designed to the
    second distinguishing factor: performance.  When support a persistent
    failure occurs among the members wide range of a TRACK based protocol, there
    is a possibility applications that this may slow down other members of the
    group.  NACK protocols have higher isolation of failures, as well
    as smaller amounts of control traffic under many scenarios.

 3.1 Application types

    The objectives of TRACK are to provide high level reliability, high
    scalability, congestion control and flow control for
   require one to many bulk data dissemination.  TRACK is not designed for many to many
    applications. transfer and application layer
   confirmed delivery.  Examples of applications that fit into the one-to-
    many one-
   to-many data dissemination model are: real time financial news and
   market data distribution, electronic software distribution, audio
   video streaming, distance learning, software updates and server
   replication.  But, not all of these application types have the same
    reliability requirements.

   Historically, financial applications have had the most stringent
   reliability requirements, while audio video streaming have had the
   least stringent.  For applications that want to have strong
    confirmation of delivery guarantees, TRACK may be more applicable
    than alternatives such as NORM or ALC.  For applications that do not require this level of
   reliability, or that demand the lowest levels of latency and the
   highest levels of failure isolation, TRACK may be less applicable.

    The

   TRACK BB, in particular, is designed to optionally work on top
    of in conjunction with a NORM or ALC PI, receiver reliable
   protocol such as NORM, to allow applications to select this tradeoff
   on a dynamic basis.

 3.2

2.2 Network Infrastructure

    The TRACKs also serve to provide feedback information

   TRACK is designed to the
    sender.  The sender uses this information for congestion work over almost all multicast and flow
    control.  This allows TRACK broadcast
   capable network infrastructures.  It is specifically designed to be applicable in most networks (i.e.
    managed and shared networks,
   able to support both asymmetrical and high congestion networks.) single source multicast
   environments.

   Asymmetric networks with very low upbound bandwidth and a very low
   loss data channel Data Channel may be better served solely through NACK based
   protocols, particularly if high reliability is not required.  A good
   example is some satellite networks.

   Networks that have very high loss rates, and regularly experience
   partial network partitions, router flapping, or other persistent
   faults, may be better served through NACK only protocols.

 4. Message Types
    The following table summarizes the messages  Some
   wireless networks fall in to this category.

2.3 Private and their fields used
    by the Public Networks

   TRACK BB.  All messages contain the session identifier.

 +--------------------------------------------------------------------+
 Message          From      To     Mcast?       Fields
 +--------------------------------------------------------------------+

 BindRequest     Child    Parent    no         Scope, Level, Role,
                                               SubTreeCount
 +--------------------------------------------------------------------+

 BindConfirm     Parent   Child     no      Level, RepairAddr, SeqNum,
                                            MemberId, CacheInfo
 +--------------------------------------------------------------------+

 BindReject      Parent   Child     no         Reason
 +--------------------------------------------------------------------+

 UnbindRequest   Child    Parent    no         Reason
 +--------------------------------------------------------------------+

 UnbindConfirm   Parent   Child     no
 +--------------------------------------------------------------------+

 EjectRequest    Parent   Child    either         Reason
 +--------------------------------------------------------------------+

 EjectConfirm    Child    Parent    no
 +--------------------------------------------------------------------+

 Heartbeat       Parent   Child    either     Level, ParentTimestamp,
                                               ChildrenList, SeqNum
 +--------------------------------------------------------------------+

 NullData        Sender    all     yes   SenderTimeStamp, AppSynch, End
 Data                                    Rate, HighestReleased, SeqNum
 +--------------------------------------------------------------------+

 Retransmission  Parent   Child    yes   SenderTimeStamp, AppSynch, End
                                         Rate, HighestReleased, SeqNum
 +--------------------------------------------------------------------+

 Track           Child    Parent      no  SeqNum, BitMask, SubTreeCount
                                          Slowest, FailedChildren,
                                          HighestAllowed,LocalDallyTime
                                          ApplicationConfirms,
                                          ParentThere, ParentTimeStamp,
                                          SenderTimeStamp,
                                          SenderDallyTime
 +--------------------------------------------------------------------+

    The various fields of the messages are described as follows:

    - Scope: an integer to indicate how far a repair message travels.
    This is optional.

    - Level: an integer that indicates the level designed to work in private networks, controlled networks
   and in the repair tree.
    This value public Internet.  A controlled network typically has a
   single administrative domain, has more homogenous network bandwidth,
   and is used to keep loops in more easily managed and controlled.  These networks have the tree from forming, in
    addition
   fewest barriers to indicating the distance from IP multicast deployment and the sender.  Any changes most immediate
   need for reliable multicast services.  Deployment in the Internet
   requires a node's level are passed down protocol to span multiple administrative domains, over
   vastly heterogeneous networks.

2.4 Manual vs. Automatic Controls

   Some networks can take advantage of manual or centralized tools for
   configuring and controlling the Tree BB using the
    treeLevelUpdate interface.

    - Role: This indicates if the bind requestor is a receiver or
    repair head.

    - SubTreeCount: This is an integer indicating the current number usage of
    receivers below a reliable multicast group.
   In the node.

    - RepairAddr: This field in public Internet the BindConfirm message is used tools have to tell
    the receiver which multicast address the repair head will span multiple administrative
   domains where policies may be
    sending retransmissions on.  If this field inconsistent.  Hence, it is null, then the
    receiver should expect retransmissions preferable
   to be sent on the sender's
    data multicast address.

    - SeqNum: an integer indicating design tools that are fully distributed and automatic.  To address
   these requirements, TRACK provides automatic configuration, but can
   also support manual configuration options.

2.5 Heterogeneous Networks

   While the sequence number majority of a data
    message within a given data session. The SeqNum field controlled networks are symmetrical and support
   many-to-many multicast, in designing a protocol for the
    BindConfirm message indicates the sequence number starting from
    which the repair head promises to provide repair service.

    - MemberId: This is an integer the repair head assigns to Internet, we
   must deal with virtually all major network types.  These include
   asymmetrical networks, satellite networks, networks where only a
    particular child.  The child receiver uses this value
   single node may send to implement
    the rotating a multicast group, and wireless networks.
   TRACK Generation algorithm.

    - CacheInfo: This field contains information about the repair data
    available from takes this Repair Head.

    - Reason: a code indicating into account by not requiring any many-to-many
   multicast services.  TRACK does not assume that the reason topology used for the BindReject,
    UnbindRequest, or EjectRequest message.

    - ParentTimestamp: This field is included in Heartbeat
   sending control messages has any congruence to
    signal the need topology of the
   multicast address used for sending data messages.

2.6 Use of Network Infrastructure

   TRACK is designed to do run in either single level or hierarchical
   configurations.  In a local RTT measurement from a parent.  It single level, there is
    the time when the parent sent the packet.

    - ChildrenList: This field contains the identifiers no need for a list specialized
   network infrastructure.  In hierarchical configurations, special
   nodes called Repair Heads are defined, which may run either as part
   of
    children.  As a distributed application, or as part of dedicated server
   software.  TRACK does not specifically support or require Generic
   Router Assist or other router level assist.

2.7 Deployment Constraints
   The two primary tradeoffs TRACK has, for the keepalive message, this field together functionality it
   provides, are additional complexity, and decreased failure isolation.
   Hence, if target applications are to be deployed in networks with the SeqNum field
   high rates of persistent failures, and isolation of failed Receivers
   from affecting other Receivers is used to urge those listed receivers to
    send a of high importance, TRACK (for the provided SeqNum). may not
   be appropriate.  Similarly, if simplicity is paramount, TRACK may not
   be appropriate.

2.8 Target Scalability

   The repair head sending
    this must have been missing the regular TRACKs from these children
    for an extended period target scalability of time.

    - SenderTimestamp: This field TRACK is included in tens of thousands of simultaneous
   Receivers per Data messages Session.  Dedicated Repair Heads are targeted to
    signal the need
   be able to do support thousands of simultaneous Data Sessions.

2.9 Known Failure Modes

   If a roundtrip time measurement from the sender,
    through the tree, and back to the sender.  It hierarchical Control Tree is the time (measured
    by the sender's local clock) when it sent the packet.

    - AppSynch: a sequence number signaling a request for confirmed
    delivery by the application.

    - End: indicates misconfigured, so that this packet loop-free,
   contiguous connection is the end of the data for this
    session.

    - Rate: not provided, failure will occur.  This field
   failure is used by the sender designed to tell occur gracefully, at the receivers its
    sending rate, in packets per second.  It is part initialization of a
   Data Session.

   If the data or
    nulldata messages.

    - HighestReleased:  This field contains configuration parameters on control traffic are poorly chosen
   on an asymmetrical network, where there is much less control channel
   bandwidth available than data channel bandwidth, there may be a sequence number,
    corresponding to the trailing edge very
   high rate of the sender's retransmission
    window.  It control traffic.  This control traffic is used (as part not
   dynamically congestion controlled like the data traffic, and so could
   potentially cause congestion collapse.

   This potential control channel overload could be exacerbated by an
   application that makes overly heavy use of the data, nulldata application level
   confirmation or
    retransmission headers) to inform statistics gathering functions.

2.10 Potential Conflicts With Other Components

   None are known of at this time.

3. Architecture Definition

3.1 TRACK Entities

3.1.1 Node Types
   TRACK divides the receivers that they should no
    longer attempt to recover those messages with a smaller (or same)
    sequence number.

    - HighestAllowed: a sequence number, used for flow control from operation of the
    receivers.  It signals protocol into three major
   entities:  Sender, Receiver, and Repair Head.  The Repair Head
   corresponds to the highest
    sequence number Service Node described in the sender Tree Building draft.
   It is allowed to send assumed that will not overrun
    the receivers' buffer pools.

    - BitMask: Senders and Receivers typically run as part of an array
   application on an end host client. Repair Heads MAY be components in
   the network infrastructure, managed by different network managers as
   part of 1's different administrative domains, or MAY run on an end host
   client, in which case they function as both Receivers and 0's.  Together with a sequence
    number Repair
   Heads.  Absent of any automatic tree configuration, it is used to indicate lost data messages.  If assumed
   that the i'th
    element is Infrastructure Repair Heads have relatively static
   configurations, which consist of a 1, it indicates list of nearby possible Repair
   Heads.  Senders and Receivers, on the message SeqNum+i is lost.

    - Slowest: This field contains a field that characterizes other hand, are transient
   entities, which typically only exist for the
    slowest receiver in the subtree beneath (and including) the node
    sending the TRACK.  This is used duration of a single
   Data Session. In addition to provide information for the
    congestion control BB, and the aggregation methods on this
    information are defined by these core components, applications that BB.

    - ParentThere: This field indicates
   use TRACK are expected to the parent interface with other services that the receiver
    sending the TRACK has not been receiving the regular keepalive
    messages from its parent, reside
   in other network entities, such as multicast address allocation,
   session advertisement, network management consoles, DHCP, DNS,
   overlay networking, application level multicast, and multicast key
   management.

3.1.2 Multicast Group Address

   A Multicast Group Address is wondering if it needs to find a
    new parent.

    - SenderDallyTime: This field logical address that is associated with used to
   address a SenderTimestamp
    field.  It contains the sum set of the waiting time that should be
    subtracted from the RTT measurement at the sender.

    - LocalDallyTime: This is the same as the SenderDallyTime, but TRACK nodes.  It is
    associated with RECOMMENDED to consist of a ParentTimestamp instead pair
   consisting of an IP multicast address and a SenderTimestamp.

    - ApplicationConfirms: This is the SeqNum UDP port number.  In this
   case, it may optionally have a Time To Live (TTL) value, although
   this value MUST only be used for which delivery
    has been confirmed by all children at providing a global scope to a Data
   Session, and not for scoping of local retransmissions. Data Multicast
   Addresses are Multicast Group Addresses.

   TRACK MAY be used with an overlay multicast or below application layer
   multicast system.  In this parent.

    - FailedChildren: This is case, a list of all children that Multicast Group Address MAY have recently
    been dropped from a
   different format.  The TRACK PI is responsible for specifying the repair tree.

 5. Global Configuration Variables, Constants, and Reason Codes

 5.1 Global Configuration Variables
 These are variables that control
   format of a Multicast Group Address.

3.1.3 Data Session

   A Data Session is the data session and unit of reliable delivery of TRACK.  It
   consists of a sequence of sequentially numbered Data messages, which
   are advertised
 to all participants.

    @ TimeMaxBindResponse: the time, in seconds, to wait for sent by a
       response to single Sender over a BindRequest.  Initial value is
       TIMEOUT_PARENT_RESPONSE (recommended value is 3).  Maximum value single Data Multicast Address.
   They are delivered reliably, with acknowledgements and
   retransmissions occurring over the Control Tree.  A Data Session ID
   uniquely identifies it.  A given Data Session is MAX_TIMEOUT_PARENT_RESPONSE.

    @ MaxChildren: The maximum number received by a set of children
   zero or more Receivers, and a repair head is
       allowed to handle. Recommended value: 32.

    @ ConstantHeartbeatPeriod: Instead set of dynamically calculating zero or more Repair Heads.  One
   or more Data Sessions MAY share the
       HeartbeatPeriod as described same Data Multicast Address
   (although this is NOT RECOMMENDED).  Each TRACK node can
   simultaneously participate in Section 7.1.5, multiple Data Sessions.  A Receiver
   MUST join all the Data Multicast Addresses and Control Trees
   corresponding to the Data Sessions it wishes to receive.

3.1.4 Data Channel

   A Data Session is multicast over a constant period
       may be used instead.  Recommended value: 3 seconds.

    @ MinimumHeartbeatPeriod: Data Channel.  The minimum value Data Channel is
   responsible for efficiently delivering the dynamically
       calculated HeartbeatPeriod.  Recommended value: 1 second.

    @ MinHoldTime: The minimum amount of time a repair head holds on Data messages to data packets.

    @ MaxHoldTime: The maximum amount the
   members of time a repair head holds Data Session, and providing statistical reliability
   guarantees on
       to data packets.

    @ AckWindow: The number of packets seen before a receiver issues
       an acknowledgement.  Recommended value: 32.

 5.2 Constants

    @ NUM_MAX_PARENT_ATTEMPTS: The number of times to try to bind to this delivery.  It does this by employing a
       repair head before declaring a PARENT_UNREACHABLE error.
       Recommended value is 5.

    @ NULL_DATA_PERIOD: The time between transmission of NullData
       Messages.  Recommended value is 1.

    @ FAILURE_DETECTION_REDUNDANCY: The number of times a message is
       sent without receiving a response before declaring an error.
       Recommended value is 3.

    @ MAX_TRACK_TIMEOUT: The maximum value for TRACKTimeout.
       Recommended value Data
   Channel Protocol, such as NORM, ALC, PGM, or Overlay Multicast.
   TRACK is 5 seconds.

 5.3 Reason Codes

    @ BindReject reason codes
       @ LOOP_DETECTED
       @ MAX_CHILDREN_EXCEEDED

    @ UnbindRequest reason codes
       @ SESSION_DONE
       @ APPLICATION_REQUEST
       @ RECEIVER_TOO_SLOW

    @ EjectRequest reason codes
       @ PARENT_LEAVING
       @ PARENT_FAILURE
       @ CHILD_TOO_SLOW
       @ PARENT_OVERLOADED

 6. External APIs
 This section describes external interfaces then responsible for the building block.

 6.1 Interfaces to the BB from PI's

 6.1.1 Start(boolean RepairHead, boolean RejoinAllowed,
       Advertisement)

 Start instructs the BB providing application level, Sender
   based reliability, by confirming delivery to initiate operation.

 RepairHead indicates whether or all Receivers, and
   optionally retransmitting lost messages that did not get correctly
   delivered by the node may also operate as a
 repair head. This parameter is passed along Data Channel.  A common scenario would be to use
   TRACK to provide application level confirmation of delivery, and
   recover from persistent failures in the tree BB.

 RejoinAllowed indicates whether or not network that are beyond the node is allowed to rejoin
   scope of the session if Data Channel Protocol.

3.1.5 Data Channel Protocol

   This is the only repair heads available are missing some repair
 data needed transport protocol used by this node. a TRACK PI to ensure goodput
   and statistical reliability on a Data Channel.

3.1.6 Data Multicast Address

   This parameter also controls whether or not
 the node is allowed to join the session after Multicast Group Address used by the first data Data Channel
   Protocol, to efficiently deliver Data messages
 have become unrecoverable (late join).  The BB uses this parameter to
 decide whether or not all Receivers and
   Repair Heads.  All Data Multicast Addresses used by TRACK are assumed
   to use be unidirectional and only support a particular repair head (chosen by the
 tree BB) based on its available repair data.

 The Advertisement parameter passes single Sender.

3.1.7 Control Tree

   A Control Tree is a hierarchical communication path used to the BB all of the parameters send
   control information from the session advertisement.

 6.1.2 End

 End instructs the BB a set of Receivers, through zero or more
   Repair Heads (RHs), to end its operation.  If the node a Sender.  Information from lower nodes is
   aggregated as the Sender,
 it indicates information is relayed to higher nodes closer to
   the group that the last data message Sender.  Each Data Session uses a Control Tree.  It is the final one
 for the session.  Once acceptable
   to have a receiver has received degenerate Control Tree with no Repair Heads, which
   connects all of the session's
 data, it MAY unbind from its parent.  However, if Receivers directly to the receiver is also Sender.

   Each RH in the Control Tree uses a repair head, it continues separate Local Control Channel for
   communicating with its children.  It is RECOMMENDED that each Local
   Control Channel correspond to operate as a repair head until all of
 its children have finished.  Then it separate Multicast Group Address.
   Optionally, these RH multicast addresses MAY unbind from its own parent.

 If End be the same as the Data
   Multicast Address.

3.1.8 Local Control Channel
   A Local Control Channel is called at a repair head, it MUST use the unidirectional multicast Eject
 procedure path from a
   Repair Head or Sender to inform its children children.  It uses a Multicast Group
   Address for this session that it is leaving
 the group.  Once communication.

3.1.9 Host ID

   With the procedure is complete (all children have
 acknowledged receipt widespread deployment of network address translators,
   creating a short globally unique ID for a host is a challenge.  By
   default, TRACK uses a 48 bit long Host ID field, filled with the Eject, or low-
   order 48 bits of the Eject has been sent MD5 signature of the
 maximum number DNS name of times), the repair head source.  A
   TRACK PI, to match up with the goodput-ensuring protocol that TRACK
   PI uses as its Data Channel Protocol, MAY unbind from its own
 parent.

 If End redefine the length and
   contents of this identifier.

3.1.10 Data Session ID

   A Data Session ID is called at a receiver, it MUST use the Unbind procedure to
 inform its parent globally unique identifier for this session that a Data Session.
   It may either be selected by the Data Channel Protocol (i.e. NORM) or
   by TRACK.  By default, it is leaving the group.

 6.1.3 incomingMessage(Message)

 incomingMessage presents combination of the BB Host ID for the
   Sender, combined with message received by the PI.

 6.1.4 getStatistics

 getStatistics returns current BB statistics to 16 bit port number used for the upper BB or PI.

 6.1.5 MessageSynched(Message)

 MessageSynched tells Data
   Session at the BB that Sender.  This identifier is included in every TRACK
   message.

3.1.11 Child ID

   All members in a TRACK Data Session, besides the indicated message has been
 synched with Sender, are
   identified by the application.

 6.1.6 RepairHead(boolean)

 RepairHead tells combination of their Host ID, and the BB whether or not it port number
   with which they send IP packets to their parent.

3.1.12 Message Sequence Numbers

   A Message Sequence Number is now acting as a Repair
 Head.

 6.2 Interfaces from the BB to the PI

 6.2.1 outgoingMessage(Message)

 outgoingMessage instructs 32 bit number in the PI range from 1
   through 2^32  1, which is used to send specify the message.

 6.2.2 MessageReceived(Message, boolean Synch)

 MessageReceived passes sequential order of a data
   Data message up in a Data Stream.  A Sender node assigns consecutive
   Sequence Numbers to the PI. Synch indicates
 whether or not the PI should call MessageSynched once the message has
 been consumed Data messages provided by the Sender
   application.

 6.2.3 SenderLost

 SenderLost tells the PI  By default, zero is reserved to indicate that contact with the sender Data
   Session has been lost.

 6.2.4 UnrecoverableData
 UnrecoverableData indicates not yet started.  A TRACK PI MAY redefine this.  Message
   Sequence Numbers may wrap around, and so Sequence Number arithmetic
   MUST be used to compare any two Sequence Numbers.

3.1.13 Data Queue

   A Data Queue is a buffer, maintained by a Sender or a Repair Head,
   for transmission and retransmission of the PI that Data messages provided by
   the BB was unable to
 recover some session data.

 6.2.5 SessionDone

 SessionDone indicates Sender application.  New Data messages are added to the PI that Data
   Queue as they arrive from the sender has completed sending application, up to a specified
   buffer limit.  The admission rate of messages to the data, and network is
   controlled by the node flow and congestion control algorithms.  Once a
   message has left been received by the session.

 7. Algorithms

 7.1 Tree Based Session Creation and Maintenance

    7.1.1 Overview Receivers of Tree Configuration

    Before a Data Session starts delivering data, Stream, it may
   be deleted from the tree for buffer.

   At the Sender, A TRACK PI may integrate the Data
    Session needs to be created.  This process binds Queue with the
   buffer used by the Data Channel Protocol.

3.2 Basic Operation of the Protocol

   For each Receiver Data Session, TRACK provides sequenced, reliable delivery of
   data from a single Sender to
    either up to tens of thousands of Receivers.  A
   TRACK Data Session consists of a Repair Head network that has exactly one Sender
   node, zero or the Sender, more Receiver nodes and binds the participating zero or more Repair Heads into Heads.

   The figure below illustrates a loop-free tree structure TRACK Data Session with multiple
   Repair Heads.

   Before a Data Session starts, a session advertisement MUST be
   received by all members of the Sender as Data Session, notifying them to join
   the
    root of group, and the tree.  This process requires tree appropriate configuration
    knowledge, which can information for the Data
   Session.  This MAY be provided with some combination of manual
    and/or automatic configuration.  The algorithms for automatic tree
    configuration are part of directly by the Automatic application, by an
   external service, or by the TRACK PI.

   A Sender joins the Control Tree Configuration BB.
    They return to each node and a Data Channel Protocol.  It
   multicasts Data messages on the address Data Multicast Address, using the
   Data Channel Protocol.  All of the parent it should bind
    to, as well as zero or more backup parents to use if nodes in the primary
    parent fails.

    In addition session subscribe to receiving the tree configuration information, the
    receivers all receive a Session Advertisement message from the
    senders, informing them of
   the Data Multicast Address and other
    session configuration information.  This advertisement may contain
    other relevant session information such as whether or not Repair
    Heads should be used, whether manual or automatic tree
    configuration should be used, the time at which join the session will
    start, and other protocol settings.  This advertisement Data Channel Protocol.

   There is created
    as part no assumption of either congruence between the PI or as part topology of an external service.  In
    this way, the Sender enforces a set of uniform Session
    Configuration Parameters on all members Data
   Multicast Address and the topology of the session.

    As described in Control Tree.

                          -------> SD (Sender node)----->|
                         ^^^                             |
                       /  |  \    Control                |
              TRACKs /    |    \    Tree                 |
                   /      |      \                       |
                 /        |        \     (Repair         |
               /          |          \    Head           |
             /            |            \  nodes)         v
           RH             RH            RH  <------------|
           ^^            ^^^            ^^               | Data
          / |           / | \           | \              | Channel
         /  |          /  |  \          |  \             |
        /   |         /   |   \         |   \            v
       R    R        R    R    R        R    R  <---------
                           (Receiver Nodes)

   A Receiver joins the automatic tree configuration BB, appropriate Data Channel Protocol, and the general
    algorithm for a given node in tree creation is as follows.
    1) Get advertisement Data
   Multicast Address used by that a session is starting
    2) Get list of neighbor candidates using the getSNs Tree BB
       interface, contact them
    3) Select best neighbor as parent protocol, in a loop free manner
    4) Bind to parent
    5) Optionally, later rebind order to another receive Data.  A
   Receiver periodically informs its parent

    When a child finishes step 4, about the messages that it is up
   has received by unicasting a TRACK message to automatic tree
    configuration to, if necessary, continue building the tree parent.  It MAY
   also request retransmission of lost messages in order
    to connect the this TRACK.  Each
   parent node back to aggregates the Sender.  After the session is
    created, children can unbind TRACKs from their parents its child nodes and bind again to
    new parents.  This happens when faults occur, or as part of a tree
    optimization process.  Steps 1 through 3 are external to the TRACK
    BB.  Step 4 is performed as part of session creation.  Step 5 (if it is
    performed as part of session maintenance in conjunction with
    automatic tree building, as either an unbind or eject, combined
    with another bind operation.

    Once steps 1 through 3 are completed, Receivers join the Data
    Multicast Address, and attempt to bind to either
   not the Sender or Sender) unicasts a
    local Repair Head.  A Receiver will attempt to bind single aggregated TRACK to the first
    node in the tree configuration list returned by step 3, its parent.

   The Sender and if this
    fails, it will move to the next one.  A Receiver only binds to a
    single each Repair Head or Sender, at have a time, multicast Local Control
   Channel to their children.  This is used for each Data Session.

    The automatic tree building BB ensures transmitting Heartbeat
   messages that inform their child nodes that the tree parent node is formed
    without loops.  As part still
   functioning.  This channel is also used to perform local
   retransmission of this, when a Repair Head has a Receiver
    attempt lost Data messages to bind just these children.  TRACK
   MUST still provide correct operation even if multicast addresses are
   reused across multiple Data Sessions or multiple Local Control
   Channels.  It is NOT RECOMMENDED to it use the same multicast address
   for a multiple Local Control Channels serving any given Data Session, it may not at first
    be able Session.

   The communication path forms a loop from the Sender to accept the connection, until it is able Receivers,
   through the Repair Heads back to join the tree
    itself.  Because of this, a Receiver will sometimes have to
    repeatedly attempt to bind to a given parent before succeeding.

    Once the Sender initiates tree building, it is also free to start
    sending Data Sender.  Original data (ODATA),
   Retransmission (RDATA) and NullData messages on regularly exercise the Data Multicast Address.  Repair Heads
    and Receivers may start receiving these messages, but may not
    request retransmission or deliver
   downward data to direction.  Heartbeat messages exercise the application until
    they receive confirmation that they have successfully bound to downward
   control direction.  TRACK messages regularly exercise the
    tree.

 7.1.2 Bind

 7.1.2.1 Input Parameters

    In order to join a data session and bind to Control
   Tree in the tree, upward direction.  This combination constantly checks
   that all of the following nodes need in the following parameters. tree are still functioning correctly,
   and initiates fault recovery when required.

   This hierarchical infrastructure allows TRACK to provide a number of
   functions in a scaleable way.  Application level confirmation of
   delivery and statistics aggregation both operate in a request-reply
   mode.  A Repair Head requires the following parameters.

    - Session:  the unique identifier sender issues a request for application level confirmation
   or statistics reporting, and the data session to join,
    received from receivers report back the Session Advertisement algorithm
   appropriate information in their TRACK messages.  This information is
   aggregated by the PI.

    - ParentAddress:  the address Repair Heads, and port of the parent node passed back up to which the node should connect

    - UDPListenPort: Sender.
   Since TRACK messages are not delivered with the number reliability of the port on which the node will
    listen for its children's data
   messages, Receivers and Repair Heads transmit this information
   redundantly.

   TRACK also gathers control messages

    - RepairAddr: information that is useful for improving
   the multicast address, UDP port, performance of flow and TTL on which
    this node sends congestion control messages to its children.

    A Sender requires the above parameters, except for the
    ParentAddress.  A Receiver requires the above parameters, except
    for algorithms, including
   scaleable round trip time measurements.

   Normally, goodput in ensured by lower level protocols, such as the UDPListenPort
   NACKs and RepairAddr.

 7.1.2.2 Bind Algorithm

    A Bind operation happens when a child wishes to join a parent FEC algorithms in NORM and PGM. However, TRACKs MAY also
   include optional retransmission requests, in the distribution tree for a given data session. form of selective
   bitmaps indicating which messages need to be retransmitted.  The Receivers
    initiate RH
   is then responsible for retransmitting these messages on the first Bind protocols Local
   Control Channel to their parents, which then
    cause recursive binding by each parent, up its children.

3.3 Component Relationships
   TRACK is primarily designed to the Sender.  Each
    Receiver sends a separate BindRequest message run in conjunction with another
   transport protocol that is responsible for each of the
    streams ensuring goodput.  It is
   RECOMMENDED that this Data Channel Protocol also be responsible for
   congestion control, although the TRACK PI MAY provide this congestion
   control function instead, and MAY pass the congestion control
   statistics it would like collects to join.  At the discretion of the PI,
    multiple BindRequest messages may be bundled together Data Channel Protocol, in a single
    message.

    A node sends a BindRequest message order to its automatically selected or
    manually configured parent node.  The parent node sends either a
    BindConfirm message or a BindReject message.  Reception of a
    BindConfirm message terminates
   enhance the algorithm successfully, while
    receipt performance of a BindReject message causes the node congestion control algorithms.

   The primary Data Channel Protocol that TRACK is designed to either retry the
    same parent or restart work with
   is NORM.  In this case, the Bind algorithm NORM PI is responsible for interfacing
   with its next parent
    candidate (depending on the BindReject reason code), or if it has
    none, to declare a REJECTED_BY_PARENT error.  Once the node is
    accepted by a Repair head, it informs NACK BB, the Tree BB using FEC BB, the setSN
    interface.

    Reliability is achieved through Generic Router Assist BB, and the use of a standard request-
    response protocol.  At
   appropriate congestion control BB.

   TRACK then adds additional functionality that complements this
   receiver-reliable protocol, such as application level confirmed
   delivery, retransmission in the beginning face of the algorithm, the child
    initializes TimeMaxBindResponse to the constant
    TIMEOUT_PARENT_RESPONSE persistent failures,
   statistics aggregation, and initializes NumBindResponseFailures to
    0.  Every time it sends a BindRequest message, it waits
    TimeMaxBindResponse collection of extra information for a response from the parent node.  If no
    response
   congestion control.

   The TRACK BB is received, the node doubles its value responsible for
    TimeMaxBindResponse, but limits TimeMaxBindResponse to be no larger
    than MAX_TIMEOUT_PARENT_RESPONSE.  It also
    increments NumBindResponseFailures, and retransmits the BindRequest
    message.  If NumBindResponseFailures reaches
    NUM_MAX_PARENT_ATTEMPTS, it reports a PARENT_UNREACHABLE error.

    When a parent receives a BindRequest message, it first consults specifying all of the
    automatic tree building BB for approval (using TRACK-specific
   functionality.  It interfaces with the acceptChild Automatic Tree
    BB interface), Building Block.
   The TRACK PI is then responsible for instance to ensure instantiating a complete
   protocol that accepting includes all of the
    BindRequest other components.  It is expected
   that there will not cause a loop in the tree. Then the parent
    checks to be sure multiple TRACK PIs, one for each Data Channel
   Protocol that it does not have more than MaxChildren
    children already bound is specified to it work with.

   The following figure illustrates this, for this session.  If it can accept the child, it sends back a BindConfirm message.  Otherwise, it
    sends case where NORM is the node a BindReject message. Then the parent checks to
   Data Channel Protocol.

                            +----------+
                            |          |
                            |  TRACK   |
                            |    PI    |
                            |          |
                            +----------+
                               /     \
                             /         \
                           /             \
                   +---------+         +---------+
                   |         |         |         |
                   |  TRACK  |         |  NORM   |  Data Channel
                   |   BB    |         |   PI    |  Protocol
                   |         |         |         |
                   +---------+         +---------+
                        |                    |
                        |                    |
                        |                    |
                   +---------+         +-----------------------+
                   |         |         |                       |
                   |   Tree  |         |  FEC, CC, GRA, NACK   |
                   |    BB   |         |    Building Blocks    |
                   |         |         |                       |
                   +---------+         +-----------------------+

   For more details on integration, please see
    if it is already a member the example TRACK PI over
   UDP [17].

4. TRACK Functionality

4.1 Hierarchical Session Creation and Maintenance

4.1.1 Overview of this data session.  If it is not yet Tree Configuration

   Before a
    member of this session, it attempts to join Data Session starts reliably delivering data, the tree itself.

    The BindConfirm message contains the lowest sequence number that for
   the repair head has available.  If this number is 0 Data Session needs to be created.  This process binds each
   Receiver to either a Repair Head or 1, then the
    repair head has all of Sender, and binds the data available from
   participating Repair Heads into a loop-free tree structure with the start
   Sender as the root of the
    session.  Otherwise, tree.  This process requires tree
   configuration knowledge, which can be provided with some combination
   of manual and/or automatic configuration.  The algorithms for
   automatic tree configuration are part of the requesting Automatic Tree
   Configuration BB.  They return to each node is attempting a late join,
    and can only use this repair head if late join was allowed by the
    PI.  If late join is not allowed, address of the node may try another repair
    head, parent
   it should bind to, as well as zero or give up.

    Similarly, if a failure recovery occurs, when a node tries more backup parents to bind use if
   the primary parent fails.

   In addition to a new repair head, it must follow receiving the same rules as for a late
    join.  See section 7.1.5.

7.1.3 Unbind

    A child may decide to leave tree configuration information, the
   Receivers all receive a data session for Session Advertisement message from the following
    reasons.  1) It detects that
   Senders, informing them of the data Data Multicast Address and other
   session is finished.  2) The
    application requests to leave the data session.  3) It is configuration information.  This advertisement may contain
   other relevant session information such as whether or not able
    to keep up with Repair
   Heads should be used, whether manual or automatic tree configuration
   should be used, the data rate time at which the session will start, and other
   protocol settings.  This advertisement is created as part of either
   the data session.  When any TRACK PI or as part of
    these conditions occurs, it initiates an Unbind process.

    An Unbind is, like the Bind function, a simple request-reply
    protocol.  Unlike external service.  In this way, the Bind function, it only has
   Sender enforces a single response,
    UnbindConfirm.   With this exception, set of uniform session configuration parameters on
   all members of the Unbind operation uses session.

   As described in the
    same state variables and reliability algorithms as automatic tree configuration BB, the Bind
    function.

    When general
   algorithm for a child receives an UnbindConfirm message from its parent, it
    reports given node in tree creation is as follows.
   1) Get advertisement that a LEFT_DATA_SESSION_GRACEFULLY event.  If it does not
    receive this message after NUM_MAX_PARENT_ATTEMPTS, then it reports session is starting
   2) Get a LEFT_DATA_SESSION_ABNORMALLY event.  Unbinds are reported to list of neighbor candidates using the getSNs Tree BB using the lostSN interface.

 7.1.4 Eject

    A
      interface, and OPTIONALLY contact them
   3) Select best neighbor as parent may decide to remove one or more of its children from in a
    data stream for the following reasons.  1) The parent needs to
    leave the group due loop free manner
   4) Bind to application reasons.  2) The repair head
    detects an unrecoverable failure with either its parent or the
    sender.  3) The
   5) Optionally, later rebind to another parent detects that the
   When a child finishes step 4, it is not able to keep up with to automatic tree
   configuration to, if necessary, continue building the speed of tree in order
   to connect the data stream.  4) The parent is not able node back to
    handle the load of its Sender.  After the session is
   created, children can unbind from their parents and needs some of them to move bind again to
    another parent.  In the first two cases, the parent needs new
   parents.  This happens when faults occur, or as part of a tree
   optimization process.  Steps 1 through 3 are external to
    multicast the advertisement TRACK
   BB.  Step 4 is performed as part of the termination session creation.  Step 5 is
   performed as part of one session maintenance in conjunction with
   automatic tree building, as either an Unbind or more data
    sessions to all of its children.  In Eject, combined with
   another Bind operation.

   Once steps 1 through 3 are completed, Receivers join the second two cases, it needs Data
   Multicast Address, and attempt to send one or more unicast notifications Bind to one or more of its
    children.

    Consequently, an Eject can be done either with a repeated multicast
    advertisement message to all children, the Sender or a set of unicast request-
    reply messages
   local Repair Head.  A Receiver will attempt to bind to the subset of children that first node
   in the tree configuration list returned by step 3, and if this fails,
   it needs will move to go to.

    For the multicast version of Eject, next one.  A Receiver only binds to a single
   Repair Head or Sender, at a time, for each Data Session.

   The automatic tree building BB ensures that the parent sends tree is formed
   without loops.  As part of this, when a multicast
    UnbindRequest message Repair Head has a Receiver
   attempt to all of its children bBnd to it for a given Data Session, on its Local Multicast Channel.  It is only necessary to
    provide statistical reliability on this message, since children
    will detect the parent's failure even if the message is it may not
    received.  Therefore, at first
   be able to accept the UnbindRequest message connection, until it is sent
    FAILURE_DETECTION_REDUNDANCY times.

    For able to join the unicast version tree
   itself.  Because of Eject, the parent sends this, a unicast
    UnbindRequest message Receiver will sometimes have to
   repeatedly attempt to all of its children.  Each of them respond
    with an EjectConfirm.  Reliability is ensured through the same
    request-reply mechanism as the Bind operation.

    Ejections are reported to the Tree BB using the removeChild
    interface.

 7.1.5 Fault Detection

    There are three cases where fault detection is needed.  1)
    Detection (by a child) that a given parent has failed.  2) Detection (by
    a parent) that a child has failed.  3) Detection (by either a
    Repair Head or Receiver) that a before succeeding.

   Once the Sender has failed.

    In order initiates tree building, it is also free to be scaleable start
   sending Data messages on the Data Multicast Address.  Repair Heads
   and efficient, fault detection is
    primarily accomplished by periodic keep-alive Receivers may start receiving these messages, combined
    with but may not request
   retransmission or deliver data to the existing TRACK messages.  Nodes expect application until they receive
   confirmation that they have successfully bound to see keep-alive
    messages every set period of time.  If more than the tree.

4.1.2 Bind

4.1.2.1 Input Parameters

   In order to join a fixed number of
    periods go by, Data Session and no keep-alive messages Bind to the tree, the following
   nodes need the following parameters.

   A Repair Head requires the following parameters.

   - Session:  the unique identifier for the Data Session to join,
   received from the session advertisement algorithm specified in the
   PI.

   - ParentAddress:  the address and port of a given type are
    received, the parent node declares a preliminary failure.  The detecting
    node may then ping to which
   the potentially failed node before declaring it
    failed, or it can just declare it failed.

    Failures are detected through three keep-alive messages:
    Heartbeat, TRACK, and NullData.  The Heartbeat message is multicast
    periodically should connect, received from a parent to its children the Auto Tree BB.

   - UDPListenPort:  the number of the port on which the node will
   listen for its local childrens control
    channel.  NullData messages are multicast messages.  This parameter is
   configured by a sender on the global application.

   - RepairAddr:  the multicast address when it has no data to send.  TRACK messages are
    generated periodically, even if no data is being sent to a data
    session, as described in section 7.2.

    Heartbeat address, UDP port, and TTL on which this
   node sends control messages are multicast every HeartbeatPeriod seconds,
    from a parent to its children.  Every time that a parent sends a
    Retransmission message or a Heartbeat message (as well as at
    initialization time), it resets a timer  This parameter is
   configured by the application.

   A Sender requires the above parameters, except for HeartbeatPeriod
    seconds.  If the timer goes off, a Heartbeat is sent.  The
    HeatbeatPeriod is dynamically computed as follows:

            interval = AckWindow / PacketRate

            HeartbeatPeriod = 2 * interval

    Global configuration parameters ConstantHeartbeatPeriod ParentAddress.
   A Receiver requires the above parameters, except for the
   UDPListenPort and
    MinimumHeartbeatPeriod can be used to either set HeartbeatPeriod to
    a constant, or give HeartbeatPeriod RepairAddr.

4.1.2.2 Bind Algorithm

   A Bind operation happens when a lower bound, globally.

    Similarly, child wishes to join a NullData message is multicast by parent in the sender to all
    data session members, every NULL_DATA_PERIOD.  The NullData timer
    is set to NULL_DATA_PERIOD, and is reset every time that
   distribution tree for a given Data or
    NullData message is sent Session.  The Receivers initiate
   the first Bind protocols to their parents, which then cause recursive
   binding by each parent, up to the Sender.

    The key parameter  Each Receiver sends a
   separate BindRequest message for failure detection is each of the global tree
    parameter FAILURE_DETECTION_REDUNDANCY.  The higher streams that it would
   like to join.  At the value for
    this parameter, discretion of the more keep-alive PI, multiple BindRequest
   messages that must may be missed
    before bundled together in a failure is declared. single message.

   A major goal of failure detection is for children node sends a BindRequest message to detect its automatically selected or
   manually configured parent
    failures fast enough that there is node.  The parent node sends either a high probability they can
    rejoin the stream at another parent, before flow control has
    advanced the buffer window to a point where the child can not
    recover all lost messages in the stream.  In order to attempt to do
    this, children detect a failure of
   BindConfirm message or a parent if
    FAILURE_DETECTION_REDUNDANCY * HeartbeatPeriod time goes by without
    any heartbeats.  As part BindReject message.  Reception of buffer window advancement, described in
    section 7.2.4, all parents MAY choose to buffer all messages for a
    minimum
   BindConfirm message terminates the algorithm successfully, while
   receipt of FAILURE_DETECTION_REDUNDANCY * 2 * HeartbeatPeriod
    seconds, which gives children a period of time BindReject message causes the node to find a new either retry the
   same parent
    before or restart the buffers are freed.  Children report Bind algorithm with its next parent failures
   candidate (depending on the BindReject reason code), or if it has
   none, to declare a REJECTED_BY_PARENT error.  Once the node is
   accepted by a Repair head, it informs the Tree BB using the lostSN setSN
   interface.

    A parent detects a preliminary failure of one of its children if it
    does not receive any TRACK messages from that child in
    FAILURE_DETECTION_REDUNDANCY * TrackTimeout seconds (see discussion
    of how TrackTimeout is computed in 7.2.1).  Because a failed child
    can slow down the group's progress, it

   Reliability is very important that a
    parent resolve achieved through the child's status quickly.  Once a parent declares
    a preliminary failure use of a child, it issues a set standard request-
   response protocol.  At the beginning of up to
    FAILURE_DETECTION_REDUNDANCY Heartbeat messages that are unicast
    (or multicast) to the failed receiver(s).  These messages are
    spaced apart by 2*LocalRTT, where LocalRTT is algorithm, the round trip time
    that has been measured child
   initializes TimeMaxBindResponse to the child in question (see 7.4 constant
   TIMEOUT_PARENT_RESPONSE and initializes NumBindResponseFailures to 0.
   Every time it sends a BindRequest message, it waits
   TimeMaxBindResponse for
    description of how LocalRTT is measured).  These Heartbeat messages
    contain a ChildrenList field that contains response from the children who are
    requested parent node.  If no
   response is received, the node doubles its value for
   TimeMaxBindResponse, but limits TimeMaxBindResponse to send be no larger
   than MAX_TIMEOUT_PARENT_RESPONSE.  It also
   increments NumBindResponseFailures, and retransmits the BindRequest
   message.  If NumBindResponseFailures reaches NUM_MAX_PARENT_ATTEMPTS,
   it reports a TRACK immediately.

    Whenever PARENT_UNREACHABLE error.

   When a child parent receives a Heartbeat message with an
    ImmediateTRACK field set to 1, BindRequest message, it immediately sends a TRACK first consults the
   automatic tree building BB for approval (using the acceptChild Tree
   BB interface), for instance to its
    parent.  If a parent does ensure that accepting the BindRequest
   will not receive a TRACK message from a child
    after waiting cause a period of 2*ChildRTT after loop in the last Heartbeat
    message tree. Then the parent checks to be sure
   that child, it declares the child failed, and removes does not have more than MaxChildren children already bound to
   it
    from the parent's child membership list.  It informs the Tree BB
    using for this session.  If it can accept the removeChild interface.

    A child or child, it sends back a repair head detects
   BindConfirm message.  Otherwise, it sends the failure of node a sender BindReject
   message. Then the parent checks to see if it does
    not receive is already a member of
   this Data or NullData message from Session.  If it is not yet a sender in
    FAILURE_DETECTION_REDUNDANCY * NULL_DATA_PERIOD.

    Note member of this session, it
   attempts to join the tree itself.

   The BindConfirm message contains the lowest Sequence Number that the more receivers there are in a tree, and
   Repair Head has available.  If this number is 0, then the higher Repair Head
   has all of the loss rate, data available from the larger FAILURE_DETECTION_REDUNDANCY must be, in
    order to give start of the same probability that erroneous failures won't be
    declared.

 7.1.6 Fault Notification

    When session.
   Otherwise, the requesting node is attempting a parent detects late join, and can
   only use this Repair Head if late join was allowed by the PI.  If
   late join is not allowed, the node may try another Repair Head, or
   give up.

   Similarly, if a failure of recovery occurs, when a child, node tries to bind to
   a new Repair Head, it adds must follow the same rules as for a failure
    notification field late join.
   See Fault Recovery, below.

4.1.3 Unbind

   A child may decide to leave a Data Session for the next TRACK messages following reasons.
   1) It detects that it sends up the
    tree. Data Session is finished.  2) The application
   requests to leave the Data Session.  3) It sends this notification multiple times because TRACKs are is not delivered reliably.  A failure notification field includes able to keep up
   with the
    failure code, as well as a list data rate of one or more failed nodes.
    Failure notifications are aggregated up the tree, according to Data Session.  When any of these conditions
   occurs, it initiates an Unbind process.

   An Unbind is, like the
    rules in 7.3.  A failure notification is not Bind function, a definitive report of simple request-reply
   protocol.  Unlike the Bind function, it only has a failure, single response,
   UnbindConfirm.   With this exception, the Unbind operation uses the
   same state variables and reliability algorithms as the child may have moved to a different repair head.

 7.1.7 Fault Recovery

    The Fault Recovery algorithms require a list of one or more
    addresses of alternate parents that can be bound to, and that still
    provide loop free operation.

    If Bind function.

   When a child detects the failure of receives an UnbindConfirm message from its parent, it
   reports a LEFT_DATA_SESSION_GRACEFULLY event.  If it does not receive
   this message after NUM_MAX_PARENT_ATTEMPTS, then re-runs it reports a
   LEFT_DATA_SESSION_ABNORMALLY event.  Unbinds are reported to the
    Bind operation Tree
   BB using the lostSN interface.

4.1.4 Eject

   A parent may decide to remove one or more of its children from a new data
   stream for the following reasons.  1) The parent candidate, in order needs to rejoin leave the
    tree.  As described above in section 7.1.2, a node may perform a
    late join, i.e. binding
   group due to application reasons.  2) The Repair Head detects an
   unrecoverable failure with a repair head which cannot provide all either its parent or the necessary repair data, only if allowed by Sender.  3) The
   parent detects that the PI.

 7.2 TRACK Generation

    This section describes child is not able to keep up with the algorithms used by speed
   of the receiver to
    determine when data stream.  4) The parent is not able to send handle the TRACK messages.

    TRACK messages are sent from receivers load of
   its children and needs some of them to their parents.  TRACK
    messages may be sent for move to another parent.  In
   the following purposes:
    - first two cases, the parent needs to request retransmission multicast the advertisement
   of messages
    - to advance the sender's transmission window for flow control
    purposes
    - termination of one or more Data Sessions to deliver end-to-end confirmation of data reception
    - to propagate other relevant feedback information up through the
    session (such as RTT and loss reports, for congestion control)

    The TRACK PI also makes use all of its
   children.  In the NACK BB, which requests
    retransmission second two cases, it needs to send one or more
   unicast notifications to one or more of messages from a parent.  The TRACK request and
    response algorithms should its children.

   Consequently, an Eject can be highly similar to the NACK algorithms
    for this specific case.

 7.2.1 TRACK Generation done either with the Rotating TRACK Algorithm

    Each receiver sends a TRACK repeated multicast
   advertisement message to its parent once per
    AckWindow all children, or a set of data unicast request-
   reply messages received.  A receiver uses an offset
    from to the boundary subset of each AckWindow to send its TRACK, in order children that it needs to
    reduce burstiness go to.

   For the multicast version of control traffic at Eject, the parents.  Each parent
    has sends a maximum number multicast
   UnbindRequest message to all of children, MaxChildren.  When its children for a child binds given Data
   Session, on its Local Multicast Channel.  It is only necessary to
   provide statistical reliability on this message, since children will
   detect the parent, parents failure even if the parent assigns a locally unique ChildID to that
    child, between 0 and MaxChildren-1.

    Each child in a tree generates a TRACK message at least once every
    AckWindow of data messages, when the most recent data message's
    sequence number, modulo AckWindow, is equal to MemberID.  If not received.
   Therefore, the UnbindRequest message that would have triggered a given TRACK for a given node is
    missed, sent
   FAILURE_DETECTION_REDUNDANCY times.

   For the node will generate unicast version of Eject, the TRACK as soon as it learns that
    it has missed the message, typically through receipt of parent sends a higher
    numbered data message.

    Together, AckWindow and MaxChildren determine the maximum ratio of
    control messages unicast
   UnbindRequest message to data messages seen by each parent, given a
    constant load all of data messages.

    In each data message, the sender advertises the current PacketRate
    (measured in messages per second) it is sending data at.  This rate its children.  Each of them responds
   with an EjectConfirm.  Reliability is generated by ensured through the congestion control algorithms in use at same
   request-reply mechanism as the
    sender.

    At Bind operation.

   Ejections are reported to the time Tree BB using the removeChild
   interface.

4.1.5 Fault Detection

   There are three cases where fault detection is needed.  1) Detection
   (by a node sends child) that a regular TRACK, it also computes parent has failed.  2) Detection (by a
    TRACKTimeout value:

            interval = AckWindow / PacketRate

            TRACKTimeout = 2 * interval

    If no TRACKs are sent within TRACKTimeout interval, parent)
   that a TRACK is
    generated, child has failed.  3) Detection (by either a Repair Head or
   Receiver) that a Sender has failed.

   In order to be scaleable and TRACKTimeout efficient, fault detection is increased primarily
   accomplished by a factor of 2, up periodic keep-alive messages, combined with the
   existing TRACK messages.  Nodes expect to a
    value see keep-alive messages
   every set period of MAX_TRACK_TIMEOUT.

    This timer mechanism is used by time.  If more than a receiver to ensure timely repair fixed number of lost messages periods go
   by, and regular feedback propagation up the tree even
    when no keep-alive messages of a given type are received, the sender is not sending data continuously. This mechanism
    complements the AckWindow-based regular TRACK generation mechanism.

 7.2.2 Local Repair

    A repair head maintains the following state for each of its
    children, for the purpose of providing repair service to node
   declares a preliminary failure.  The detecting node may then ping the local
    group:

    - HighestConsecutivelyReceived:
   potentially failed node before declaring it failed, or it can just
   declare it failed.

   Failures are detected through three keep-alive messages:  Heartbeat,
   TRACK, and NullData.  The Heartbeat message is multicast periodically
   from a sequence number indicating all
       Data messages up parent to this number (inclusive) have been received its children on its Local Control Channel.  NullData
   messages are multicast by a given child.

    - MissingPackets: a data structure to keep track of the reception
       status of Sender on the Data Control Channel when
   it has no data to send.  TRACK messages with sequence number higher than
       HighestConsecutivelyReceived.

    In addition, are generated periodically,
   even if no data is being sent to a repair head also maintains other state for purposes
    of feedback aggregation Data Session, as described in the next section.

    The minimum HighestConsecutivelyReceived value of all
   section 7.2.

   Heartbeat messages are multicast every HeartbeatPeriod seconds, from
   a parent to its children
    is kept children.  Every time that a parent sends a
   Retransmission message or a Heartbeat message (as well as the variable LocalStable.

    A repair head also maintains at
   initialization time), it resets a retransmission buffer. The size of
    the retransmission buffer must be greater than timer for HeartbeatPeriod seconds.
   If the maximum value of timer goes off, a sender's transmission window. Heartbeat is sent.  The retransmission buffer must keep
    all the Data messages received by the repair head with sequence
    number higher than LocalStable, optionally some messages with
    sequence number lower than LocalStable if there HeatbeatPeriod is room (beyond the
    maximum value of sender's transmission window).  The latter
    messages are kept in the retransmission buffer in case a receiver
    from another group losses its parent
   dynamically computed as follows:

           interval = AckWindow / MessageRate

           HeartbeatPeriod = 2 * interval

   Global configuration parameters ConstantHeartbeatPeriod and needs
   MinimumHeartbeatPeriod can be used to either set HeartbeatPeriod to join this group.

    As TRACK messages are received, the repair head updates the above
    states.

    To perform local repair, a repair head implements
   constant, or give HeartbeatPeriod a retransmission
    queue with memory.  Each lost lower bound, globally.

   Similarly, a NullData message (reported is multicast by a child using the BitMask field) Sender to all Data
   Session members, every NULL_DATA_PERIOD.  The NullData timer is entered into the retransmission queue in
    increasing order according set
   to its sequence number. If the same NULL_DATA_PERIOD, and is reset every time that a Data or NullData
   message has already been retransmitted recently (recognized due to
    the queue's memory) it is delayed sent by the local group RTT (see
    roundtrip time measurement) before retransmission. Sender.

   The retransmissions are sent using the same PacketRate key parameter for failure detection is that used
    by the sender.

 7.2.3 Flow Control Window Update

    When a receiver sends a TRACK to its parent, the HighestAllowed
    field provides information on the status of the receiver's flow
    control window. global tree parameter
   FAILURE_DETECTION_REDUNDANCY.  The higher the value of HighestAllowed is computed as
    follows:

                     HighestAllowed = seqnum + ReceiverWindow

    Where seqnum is for this
   parameter, the highest sequence number of consecutively
    received data more keep-alive messages at the receiver.  The size of the
    ReceiverWindow may either that must be based on missed before a parameter local to the
    receiver or be a global parameter.

 7.2.4 Reliability Window

    The sender and each repair head maintain a window
   failure is declared.

   A major goal of messages failure detection is for
    possible retransmission.  As messages are acknowledged by all of
    its children, children to detect parent
   failures fast enough that there is a high probability they are released from can rejoin
   the parent's retransmission
    buffer, as described stream at another parent, before flow control has advanced the
   buffer window to a point where the child can not recover all lost
   messages in 7.2.2. the stream.  In addition, there are two global
    parameters that can affect when order to attempt to do this, children
   detect a parent releases failure of a data message
    from the retransmission parent if FAILURE_DETECTION_REDUNDANCY *
   HeartbeatPeriod time goes by without any heartbeats.  As part of
   buffer -- MinHoldTime, and MaxHoldTime.

    MinHoldTime specifies window advancement, all parents MAY choose to buffer all
   messages for a minimum length of time a message must be
    held for retransmission from when it was received. This parameter
    is useful to handle scenarios where one or more children have been
    disconnected from their parent, and have to reconnect to another.
    If, for example, MinHoldTime is set to FAILURE_DETECTION_REDUNDANCY * 2 * ConstantHeartbeatPeriod, then there is
   HeartbeatPeriod seconds, which gives children a high likelihood that
    any child will be able to recover any lost messages after
    reconnecting period of time to another parent.

    The sender continually advertises
   find a new parent before the buffers are freed.  Children report
   parent failures to the members of Tree BB using the data
    session both edges lostSN interface.

   A parent detects a preliminary failure of one of its retransmission window.  The higher value children if it
   does not receive any TRACK messages from that child in
   FAILURE_DETECTION_REDUNDANCY * TrackTimeout seconds (see discussion
   of how TrackTimeout is computed below).  Because a failed child can
   slow down the groups progress, it is very important that a parent
   resolve the SeqNum childs status quickly.  Once a parent declares a
   preliminary failure of a child, it issues a set of up to
   FAILURE_DETECTION_REDUNDANCY Heartbeat messages that are unicast (or
   multicast) to the failed Receiver(s).  These messages are spaced
   apart by 2*LocalRTT, where LocalRTT is the round trip time that has
   been measured to the child in question (see below for description of
   how LocalRTT is measured).  These Heartbeat messages contain a
   ChildrenList field that contains the children who are requested to
   send a TRACK immediately.

   Whenever a child receives a Heartbeat message where the child is
   identified in each Data the ChildrenList field, it immediately sends a TRACK to
   its parent.  If a parent does not receive a TRACK message from a
   child after waiting a period of 2*LocalRTT after the last Heartbeat
   message to that child, it declares the child failed, and removes it
   from the parents child membership list.  It informs the Tree BB using
   the removeChild interface.

   A child or NullData message, which
    specifies a Repair Head detects the highest sequence number failure of any data a Sender if it does
   not receive a Data or NullData message sent. from a Sender in
   FAILURE_DETECTION_REDUNDANCY * NULL_DATA_PERIOD.

   Note that the more Receivers there are in a tree, and the higher the
   loss rate, the larger FAILURE_DETECTION_REDUNDANCY must be, in order
   to give the same probability that erroneous failures wont be
   declared.

4.1.6 Fault Notification

   When a parent detects the failure of a child, it adds a failure
   notification field to the next TRANSMISSION_REDUNDANCY TRACK messages
   that it sends up the tree.  It sends this notification multiple times
   because TRACKs are not delivered reliably.  A failure notification
   field includes the failure code, as well as a list of one or more
   failed nodes.  Failure notifications are aggregated up the tree and
   delivered to the Sender.  A failure notification is not a definitive
   report of a node failure, as the child may have detected a
   communication failure with its parent and moved to a different Repair
   Head.

4.1.7 Fault Recovery

   The Fault Recovery algorithms require a list of one or more addresses
   of alternate parents that can be bound to, and that still provide
   loop free operation.

   If a child detects the failure of its parent, it then re-runs the
   Bind operation to a new parent candidate, in order to rejoin the
   tree.  A node may perform a late join, i.e. binding with a Repair
   Head which cannot provide all the necessary repair data, only if
   allowed by the PI.

4.1.8 Distributed Membership.

   Each Repair Head is responsible for maintaining a set of state
   variables on the status of its children.  Unlike the Generic Router
   Assist, this is hard state, that only is removed when a child leaves
   that Repair Head gracefully, or after the Repair Head detects that a
   child has failed.  These variables MUST include, but are not
   necessarily limited to, the following:
   - ChildID.  This is the two byte identifier assigned to the Child by
     the Repair Head.  This uniquely identifies this Child to this
     Repair Head, but has no meaning outside that scope.
   - GlobalChildIdentifier.  This is the globally unique identifier for
     this Child.
   - ChildRTT.  This is the weighted average of the local RTT to this
     Child.
   - LastTRACK.  This is the contents of the last TRACK message sent
     from this Child, if any, not including options.
   - LastApplicationLevelConfirmation.  This is the contents of the last
     Application Level Confirmation sent from this Child, if any.
   - Last Statistics.  This is the contents of the last Statistics
     message sent from this Child, if any.
   - ChildLiveness.  This is a set of variables that keep track of the
     liveness of each child.  This includes the last time a TRACK
     message was received from this child, as well as the number of
     Heartbeat messages that have been directed at it, and the time at
     which the last Heartbeat message was sent to the child.  Please see
     Fault Detection, above, for more details.

4.2 Data Sessions.

4.2.1 Data Transmission and Retransmission

   Data is multicast by a Sender on the Data Multicast Address via the
   Data Channel Protocol.  The Data Channel Protocol is responsible for
   taking care of as many retransmissions as possible, and for ensuring
   the goodput of the Data Session.  TRACK is then responsible for
   providing OPTIONAL flow control and application level reliability.
   The mechanics of an application level confirmation of delivery are
   handled by TRACK, including keeping track of the distributed
   membership list of receivers and aggregating acknowledgements up the
   Control Tree.  Please see below for more details on flow control and
   application level confirmation.

   A common scenario for handling recovery of lost messages is to allow
   the Data Channel Protocol to provide statistical reliability, and
   then allow TRACK to provide retransmissions for more persistent
   failure cases, such as if a Receiver is not able to receive any Data
   messages for a few minutes.

   Retransmissions of data messages may be multicast by the Sender on
   the Data Multicast Address or be multicast on a Local Control Channel
   by a Repair Head.

   A Repair Head joins all of the Data Multicast Addresses that any of
   its descendants have joined.  A Repair Head is responsible for
   receiving and buffering all data messages using the reliability
   semantics configured for a stream.  As a simple to implement option,
   a Repair Head MAY also function as a Receiver, and pass these data
   messages to an attached application.

   For additional fault tolerance, a Receiver MAY subscribe to the
   multicast address associated with the Local Control Channel of one or
   more Repair Heads in addition to the multicast address of its parent.
   In this case it does not bind to this Repair Head or Sender, but will
   process Retransmission messages sent to this address.  If the
   Receivers Repair Head fails and it transfers to another Repair Head,
   this minimizes the number of data messages it needs to recover after
   binding to the new Repair Head.

4.2.2 Local Retransmission

   If a Repair Head or Sender determines from its child nodes TRACK
   messages that a Data message was missed, the Repair Head retransmits
   the Data message.  The Repair Head or Sender multicasts the
   Retransmission message on its multicast Local Control Channel.  In
   the event that a Repair Head receives a retransmission and knows that
   its children need this repair, it re-multicasts the retransmission to
   its children.

   The scope of retransmission (the multicast TTL) is considered part of
   the Control Channels multicast address, and is derived during tree
   configuration.

   A Repair Head maintains the following state for each of its children,
   for the purpose of providing repair service to the local group:

   - HighestConsecutivelyReceived.  A Sequence Number indicating all
     Data messages up to this number (inclusive) that have been received
     by a given child.

   - MissingMessages.  A data structure to keep track of the reception
     status of the Data messages with Sequence Number higher than
     HighestConsecutivelyReceived.

   The minimum HighestConsecutivelyReceived value of all its children is
   kept as the variable LocalStable.

   A Repair Head also maintains a retransmission buffer. The size of the
   retransmission buffer MUST be greater than the maximum value of a
   Senders transmission window.  The retransmission buffer MUST keep all
   the Data messages received by the Repair Head with Sequence Number
   higher than LocalStable, optionally some messages with Sequence
   Number lower than LocalStable if there is room (beyond the maximum
   value of Senders transmission window).  The latter messages are kept
   in the retransmission buffer in case a Receiver from another group
   losses its parent and needs to join this group.

   As TRACK messages are received, the Repair Head updates the above
   state variables.

   To perform local repair, a Repair Head implements a retransmission
   queue with memory.  Each lost message is entered into the
   retransmission queue in increasing order according to its Sequence
   Number. If the same Data message has already been retransmitted
   recently (recognized due to the queues memory) it is delayed by the
   local group RTT (see roundtrip time measurement) before
   retransmission.

   Retransmissions MAY NOT be sent at a faster rate than the current
   TransmissionRate advertised by the Sender.

4.2.3 Flow and Rate Control

   TRACK offers the ability to limit the rate of Data traffic, through
   both flow control and rate limits.

   When a Receiver sends a TRACK to its parent, the HighestAllowed field
   provides information on the status of the Receivers flow control
   window.  The value of HighestAllowed is computed as follows:

           HighestAllowed = seqnum + ReceiverWindow

   Where seqnum is the highest Sequence Number of consecutively received
   data messages at the Receiver.  The size of the ReceiverWindow may
   either be based on a parameter local to the Receiver or be a global
   parameter.

   If flow control is enabled for a given Data Session, then a Sender
   MUST NOT send any Data messages to the Data Channel Protocol that are
   higher than the current value for HighestAllowed that it has. On
   startup, HighestAllowed is initialized to ReceiverWindow.

   In addition, the Sender application MAY provide minimum and maximum
   rate limits.  Unless overridden by the Data Channel Protocol, a
   Sender will not offer Data messages to the Data Channel Protocol at
   lower than MinimumDataRate (except possibly during short periods of
   time when certain slow Receivers are being ejected), or higher than
   MaximumDataRate.  If a Receiver is not able to keep up with the
   minimum rate for a period of time, it SHOULD leave the group
   promptly. Receivers that leave the group MAY attempt to rejoin the
   group at a later time, but SHOULD NOT attempt an immediate
   reconnection.

4.2.4 Reliability Window

   The Sender and each Repair Head maintain a window of messages for
   possible retransmission.  As messages are acknowledged by all of its
   children, they are released from the parents retransmission buffer,
   as described in 4.2.2. In addition, there are two global parameters
   that can affect when a parent releases a data message from the
   retransmission buffer -- MinHoldTime, and MaxHoldTime.

   MinHoldTime specifies a minimum length of time a message must be held
   for retransmission from when it was received. This parameter is
   useful to handle scenarios where one or more children have been
   disconnected from their parent, and have to reconnect to another.
   If, for example, MinHoldTime is set to FAILURE_DETECTION_REDUNDANCY *
   2 * ConstantHeartbeatPeriod, then there is a high likelihood that any
   child will be able to recover any lost messages after reconnecting to
   another parent.

   The Sender continually advertises to the members of the Data Session
   both edges of its retransmission window.  The higher value is the
   SeqNum field in each Data or NullData message, which specifies the
   highest Sequence Number of any data message sent.  The trailing edge
   of the window is advertised in the HighestReleased field.  This
   specifies the largest Sequence Number of any message sent that has
   subsequently been released from the Senders retransmission window.
   If both values are the same then the window is presently empty.  Zero
   is not a legitimate value for a data Sequence Number, so if either
   field has a value of zero, then no messages have yet reached that
   state.  All Sequence Number fields use Sequence Number arithmetic so
   that a Data Session can continue after exhausting the Sequence Number
   space.

   When a member of a Data Session receives an advertisement of a new
   HighestReleased value, it stores this, and is no longer allowed to
   ask for retransmission for any messages up to and including the
   HighestReleased value.  If it has any outstanding missing messages
   that are less than or equal to HighestReleased, it MAY move forward
   and continue delivering the next data messages in the stream.  It
   also SHOULD report an error for the messages that are no longer
   recoverable.

   MaxHoldTime specifies the maximum length of time a message may be
   held for retransmission.  This parameter is set at the Sender which
   uses it to set the HighestReleased field in data message headers.
   This is particularly useful for real-time, semi-reliable streams such
   as live video, where retransmissions are only useful for up to a few
   seconds.  When combined with Unordered delivery semantics, and
   application-level jitter control at the Receivers, this provides Time
   Bounded Reliability.  MaxHoldTime MUST always be larger than
   MinHoldTime.

4.2.5 Ordering Semantics

   TRACK offers two flavors of ordering semantics: Ordered or Unordered.
   One of these is selected on a per session basis as part of the
   Session Configuration Parameters.

   Unordered service provides a reliable stream of messages, without
   duplicates, and delivers them to the application in the order
   received.  This allows the lowest latency delivery for time sensitive
   applications.  It may also be used by applications that wish to
   provide its own jitter control.

   Ordered service provides TCP semantics on delivery. All messages are
   delivered in the order sent, without duplicates.

4.2.6 Retransmission Requests.

   A Receiver detects that it has missed one or more Data messages by
   gaps in the sequence numbers of received messages.  Each Receiver
   keeps track of HighestSequenceNumber, the highest sequence number
   known of for a Data Session, as observed from Data, RData, and
   NullData messages.  Any sequence numbers between HighestReleased and
   HighestSequenceNumber that have not been received are assumed to be
   missing.

   When a Receiver detects missing messages it MAY send off a request
   for retransmission, if local retransmission is enabled.  It does this
   by sending a Retransmission Request message.  The timing of this
   request is described below.

4.2.7 End Of Stream.

   When an application signals that a Data Session is complete, the
   Sender advertises this to its children by setting the End of Session
   option on the last Data Message in the Data Session, as well as all
   subsequent retransmissions of that Data Message, and all subsequent
   Null Data messages.

   The Sender SHOULD NOT leave the Data Session until it has a report
   from the TRACK reports that all group members have left the Data
   Session, or it has waited a period of at least
   FAILURE_DETECTION_REDUNDANCY * TrackTimeout seconds.

4.3 Control Traffic Generation and Aggregation.

   One of the largest challenges for scaleable reliable multicast
   protocols has been that of controlling the potential explosion of
   control traffic.  There is a fundamental tradeoff between the latency
   with which losses can be detected and repaired, and the amount of
   control traffic generated by the protocol.

   TRACK messages are the primary form of control traffic in this BB.
   They are sent from Receivers and Repair Heads to their parents.
   TRACK messages may be sent for the following purposes:
   - to request retransmission of messages
   - to advance the Senders transmission window for flow control
   purposes
   - to deliver application level confirmation of data reception
   - to propagate other relevant feedback information up through the
   session (such as RTT and loss reports, for congestion control)

4.3.1 TRACK Generation with the Rotating TRACK Algorithm

   Each Receiver sends a TRACK message to its parent once per AckWindow
   of data messages received.  A Receiver uses an offset from the
   boundary of each AckWindow to send its TRACK, in order to reduce
   burstiness of control traffic at the parents.  Each parent has a
   maximum number of children, MaxChildren.  When a child binds to the
   parent, the parent assigns a locally unique ChildID to that child,
   between 0 and MaxChildren-1.

   Each child in a tree generates a TRACK message at least once every
   AckWindow of data messages, when the most recent data messages
   Sequence Number, modulo AckWindow, is equal to MemberID.  If the
   message that would have triggered a given TRACK for a given node is
   missed, the node will generate the TRACK as soon as it learns that it
   has missed the message, typically through receipt of a higher
   numbered data message.

   Together, AckWindow and MaxChildren determine the maximum ratio of
   control messages to data messages seen by each parent, given a
   constant load of data messages.

   In each data message, the Sender advertises the current MessageRate
   (measured in messages per second) it is sending data at.  This rate
   is generated by the congestion control algorithms in use at the
   Sender.

   At the time a node sends a regular TRACK, it also computes a
   TRACKTimeout value:

           interval = AckWindow / MessageRate

           TRACKTimeout = 2 * interval

   If no TRACKs are sent within TRACKTimeout interval, a TRACK is
   generated, and TRACKTimeout is increased by a factor of 2, up to a
   value of MAX_TRACK_TIMEOUT.

   This timer mechanism is used by a Receiver to ensure timely repair of
   lost messages and regular feedback propagation up the tree even when
   the Sender is not sending data continuously. This mechanism
   complements the AckWindow-based regular TRACK generation mechanism.

4.3.2 TRACK Aggregation.

   There are many reasons for providing feedback from all the Receivers
   to the Sender in an aggregated form.  The major ones are listed
   below:

   1) End-to-end delivery confirmation.  This confirmation tells the
   Sender that all the Receivers (in the entire tree) have received data
   messages up to a certain Sequence Number.  This is carried in an
   Application Level Confirmation message.

   2) Flow control.  The aggregated information is carried in the field
   HighestAllowed.  It tells the Sender the highest Sequence Number that
   all the Receivers (in the entire tree) are prepared to receive.

   3) Congestion control feedback.  Information about the state of the
   tree can be passed up to help control the congestion control
   algorithms for the group.

   4) Counting current membership in the group.  This information is
   carried in the field SubTreeCount.  This lets the Sender know the
   number of Receivers currently connected to the repair tree.

   5) Measuring the round-trip time from the Sender to the "worst"
   Receiver.

   A Repair Head maintains state for each child.  Each time a TRACK
   (from a child) is received, the corresponding states for that child
   are updated based on the information in the TRACK message. When a
   Repair Head sends a TRACK message to its parent, the following fields
   of its TRACK message are derived from the aggregation of the
   corresponding states for its children.  The following rules describe
   how the aggregation is performed:

   - WorstLossRate.  Take the maximum value of the WorstLossRate from
     all Children.
   - SubTreeCount.  Take the sum of the SubTreeCount from all Children.
   - HighestAllowed.  Take the minimum of the HighestAllowed value from
     all children.
   - WorstEdgeThroughput.  Take the minimum value of the
     WorstEdgeThroughput field from all Children.
   - UnicastCost.  Take the sum of the UnicastCost from all Children.
   - MulticastCost.  Take the sum of the MulticastCost from all
     Children.
   - SenderDallyTime: take the minimum value, for all of the children,
     of (childs reported SenderDallyTime + childs local dally time).
   - FailureCount: take the sum of the FailureCount for all Children.
   - FailureList: concatenate the FailureList fields for all Children,
     up to a maximum list size of MaxFailureListSize.

   Note, the SenderTimeStamp, ParentTimestamp, and ParentDallyTime
   fields are not aggregated.  The Sender will derive the roundtrip time
   to the worst Receiver by doing its local aggregation for
   SenderDallyTime and then compute:
         RTT = currentTime  SenderTimeStamp  SenderDallyTime.

   Application level confirmations (ALCs) are handled as follows.  For a
   set of ALC requests from receivers, the ones with the highest value
   for HighConfirmationSequenceNumber are considered, and all others are
   discarded.

   For the ConfirmationStatus field, the following rules apply.  Note
   that ConfirmationStatus of SomeReceiversAcknowledge can correspond to
   a ConfirmationCount of zero.
        If all children report AllReceiversAcknowledge Then
                ConfirmationStatus = AllReceiversAcknowlege
        Else If at least one child reports (ListOfFailures OR
          FailuresExceedMaximumListSize) Then
                If the count of all reported failures >
                  MaximumFailureListSize Then
                     ConfimationStatus = FailuresExceedMaximumListSize
                Else
                     ConfirmationStatus = ListOfFailures
        Else
                ConfirmationStatus = SomeReceiversAcknowledge

   The ConfirmationCount field is equal to the sum of the
   ConfimationCount for the aggregated ALC reports of all Children.  The
   PendingCount field is equal to the sum of the PendingCount fields of
   all Children.  The FailureList field is the concatenation of the
   FailureList fields of all aggregated ALC reports of all children, up
   to a maximum length of MaximumFailureListSize.

   In addition to these fields with fixed aggregation rules, TRACK
   supports a set of user defined aggregation statistics.  These
   statistics are self describing in terms of their data type and
   aggregation method.  Statistics reports are numbered, and only the
   most recent statistics report request is aggregated to the Sender.
   Statistics are aggregated over the set of Child statistics reports
   that have been received with that number.  Aggregation methods
   include minimum, maximum, sum, product, and concatenation.

4.3.3 Statistics Reporting.

   A Sender can request a list of aggregated statistics from all
   Receivers in the group.  There are a set of predefined statistics,
   such as loss rate and average throughput.  There is also the capacity
   to request a set of other TRACK statistics, as well as application
   defined statistics.

   The format of each statistic is self-describing, both in terms of
   data type, size, and aggregation method.  A Sender reliably sends out
   a statistics request by attaching it as an option to a Data message.
   When a Receiver gets a request for a statistic, it fills in the data
   fields, and forwards it up the tree in the next TRACK message.  Since
   TRACKs are not reliable, multiple copies are sent in a total of
   NumReplies consecutive TRACK messages from each Receiver.  Each
   statistics report is aggregated according to the method described in
   the statistic, and the result is delivered to the Sender.

   Most aggregation options have fixed length no matter how many
   Receivers there are.  The one exception is concatenation, which
   creates a list of values from some or all Receivers, up to a length
   of MaximumStatisticsListSize entries.  It is NOT RECOMMENDED to use
   this to create group-wide lists, unless the groups size is carefully
   controlled.

4.4 Application Level Confirmed Delivery.

   Flow control and the reliability window are concerned with goodput,
   of delivering data with a high probability that it is delivered at
   all Receivers.  However, neither mechanism provides explicit
   confirmation to the Sender as to the list of recipients for each
   message.  Application level confirmed delivery allows applications to
   determine the set of applications that have received a set of data
   messages.

   There are three primary factors that determine the reliability
   semantics of a message: the senders knowledge of the Receiver list,
   the application level actions that must be performed in order to
   consider a message delivered, and the response to persistent failure
   conditions at Receivers.  For example, an extremely strong
   distributed guarantee would consist of the following.  First, the
   full Receiver membership list is known at the Sender, and verified to
   make sure no Receivers have left the group.  Second, the application
   at each Receiver must write the Data to persistent store before it
   can be acknowledged.  Third, Receivers are given a very long period
   of time - say one hour  to recover all lost Data messages, before
   they are ejected from the Data Session.  In the meantime,
   transmission of Data messages is flow controlled by the slowest
   receivers.

   A weaker form of reliability would include the following.  First,
   that the Sender gets a count of Receivers, and otherwise depends on
   the distributed group membership algorithms to maintain the
   membership list. Second, that Data messages are considered reliably
   delivered as soon as the application receives the Data from TRACK.
   Third, that Retransmissions are limited to only 30 seconds, and
   Receivers must choose to leave the Data Session or continue with
   missing Data messages, if a failure takes longer than this period to
   recover from.

   TRACK provides the functionality to easily implement a wide range of
   application level confirmation semantics, based on how these three
   items are configured.  It is the applications responsibility to then
   select the configurations it desires for a given Data Session.

4.4.1 Application Level Confirmation Mechanisms

   The primary mechanism for application level confirmation (ALC) of
   delivery is the ALC report.  To check for ALC of delivery, a Sender
   issues a Application Level Confirmation Request, by attaching this
   message as an option to a Data message, and reliably transmitting it
   to all Receivers.  Each ALC Request includes a specified level of
   reliability, a reply redundancy factor, and the range of Data message
   sequence numbers that the ALC Confirmation covers.

   When a Receiver gets an ALC Request, it checks to see if the
   application has delivered the specified range of Data Messages,
   including both the Low Confirmation Sequence Number and the High
   Confirmation Sequence Number.  When it sends the next TRACK out, it
   sets the ConfirmationStatus field to either SomeReceiversAcknowledge
   if it is still pending confirmation, AllReceiversAcknowledge if it
   has application level confirmation, ListOfFailures if it has a
   failure and MaximumFailureListSize > 0, or
   FailuresExceedsMaximumListSize otherwise.  It also sets the
   ConfirmCount to 1 if it has a confirmation, and PendingCount to 1 if
   it is still pending.  If the Immediate ACK bit is set in the ALC
   Request, the Receiver generates an ACK immediately.

   One example of how an application can implicitly signal confirmation
   of delivery is through the freeing of buffers passed to it by the
   transport.  The API could specify that whenever an application has
   freed up a buffer containing one or more data messages, then these
   messages are considered acknowledged by the application.
   Alternatively, the application could be required to explicitly
   acknowledge each message.

4.5 Distributed RTT Calculations.

   This TRACK BB provides two algorithms for distributed RTT
   calculations  LocalRTT measurements and SenderRTT measurements.
   LocalRTT measurements are only between a parent and its children.
   SenderRTT measurements are end-to-end RTT measurements, measuring the
   RTT to the worst Receiver as selected by the congestion control
   algorithms.

   The SenderRTT is useful for congestion control. It can be used to set
   the data rate based on the TCP response function, which is being
   proposed for the congestion control building blocks.

   The LocalRTT can be used to (a) quickly detect faulty children (as
   described under fault detection) or (b) avoid sending unnecessary
   retransmissions (as described in the local repair algorithm).

   In the case of LocalRTT measurements, a parent initiates measurement
   by including a ParentTimestamp field in a Heartbeat message sent to
   its children.  When a child receives a Heartbeat message with this
   field set, it notes the time of receipt using its local system clock,
   and stores this with the message as HeartbeatReceiveTime.  When the
   child next generates a TRACK, just before sending it, it measures its
   system clock again as TRACKSendTime, and calculates the
   LocalDallyTime.

            LocalDallyTime = TRACKSendTime  HeartbeatReceiveTime.

   The child includes this value, along with the ParentTimestamp field,
   as fields in the next TRACK message sent.  Every heartbeat message
   that is multicast to all children SHOULD include a ParentTimestamp
   field.

   The SenderRTT algorithm is similar.  A Sender initiates the process
   by including a SenderTimestamp field in a data message.  When a
   Receiver gets a message with this field set, it keeps track of the
   DataReceiveTime for that message, and when it generates the next
   TRACK message, includes the SenderTimestamp and SenderDallyTime
   value.  These values are aggregated by Repair Heads, as described
   above.

   Each node only keeps track of the most recent value for
   {SenderTimestamp, DataReceiveTime} and {ParentTimestamp,
   HeartbeatReceiveTime}, replacing any older values any time that a new
   message is received with these values set.  As long as it has non-
   zero values to report, each node sends up both a {SenderTimestamp,
   SenderDallyTime} and a {ParentTimestamp, LocalDallyTime} set of
   fields in each TRACK message generated.

   Unless redefined by the TRACK PI, these RTT measurements are averaged
   using an exponentially weighted moving average, where the first RTT
   measurement, RTT_measurement, initializes the average RTT_average,
   and then each successive measurement is averaged in according to the
   following formula.  The RECOMMENDED value for alpha is 1/8.
         RTT_average = RTT_measurement * alpha + RTT_average (1-alpha)

4.6 SNMP Support

   The Repair Heads and the Sender are designed to interact with SNMP
   management tools.  This allows network managers to easily monitor and
   control the sessions being transmitted.  All TRACK nodes MAY have
   SNMP MIBs defined in a separate document.  SNMP support is OPTIONAL
   for Receiver nodes, but is RECOMMENDED for all other nodes.

4.7 Late Join Semantics

   TRACK offers three flavors of late join support:
   a) No Recovery
      A Receiver binds to a Repair Head after the session has started
      and agrees to the reliability service starting from the Sequence
      Number in the current data message received from the Sender.
   b) Continuation
      This semantic is used when a Receiver has lost its Repair Head
      and needs to re-affiliate.  In this case, the Receiver must
      indicate the oldest Sequence Number it needs to repair in order
      to continue the reliability service it had from the previous
      Repair Head.  The binding occurs if this is possible.
   c) No Late Join
     For some applications, it is important that a Receiver receives
     either all data or no data (e.g. software distribution).  In this
     case option (c) is used.

   These are specified by the LateJoinSemantics session parameter, and
   enforced by a Parent when a Child attempts to bind to it.

5. Message Types
   The following table summarizes the messages and their fields used by
   the TRACK BB.  All messages contain the session identifier.  For more
   details, please see the sample TRACK PI [17].

+--------------------------------------------------------------------+
Message          From      To     Mcast?       Fields
+--------------------------------------------------------------------+

BindRequest     Child    Parent    no       Scope, Level, Role, Rejoin
                                      BindSequenceNumber, SubTreeCount
+--------------------------------------------------------------------+

BindConfirm     Parent   Child     no   RepairAddr, BindSequenceNumber
                                                 LowestAvailableRepair
                                               Level, ChildIndex, Role
+--------------------------------------------------------------------+

BindReject      Parent   Child     no       Reason, BindSequenceNumber
+--------------------------------------------------------------------+

UnbindRequest   Child    Parent    no               Reason, ChildIndex
+--------------------------------------------------------------------+

UnbindConfirm   Parent   Child     no
+--------------------------------------------------------------------+

EjectRequest    Parent   Child    either       Reason, AlternateParent
+--------------------------------------------------------------------+

EjectConfirm    Child    Parent    no
+--------------------------------------------------------------------+

Heartbeat       Parent   Child    either        Level, ParentTimestamp
                                                  ChildrenList, SeqNum
                                                       HighestReleased
+--------------------------------------------------------------------+

NullData,       Sender    all      yes     SenderTimeStamp, DataLength
OData                                          HighestReleased, SeqNum
                                         EndOfStream, TransmissionRate
+--------------------------------------------------------------------+

Rdata           Parent   Child     yes     SenderTimeStamp, DataLength
                                               HighestReleased, SeqNum
                                         EndOfStream, TransmissionRate
+--------------------------------------------------------------------+

Track           Child    Parent    no            BitMask, SubTreeCount
                                               Slowest, HighestAllowed
                                          ParentThere, ParentTimeStamp
                                      ParentDallyTime, SenderTimeStamp
                                    SenderDallyTime, CongestionControl
                                                           FailureList
+--------------------------------------------------------------------+

ALCRequest     Sender   Receiver    yes         Immediate, Reliability
                                               NumReplies, SeqNumRange
+--------------------------------------------------------------------+

ALCReply        Child   Parent      yes     SeqNumRange, ConfirmStatus
                                            ConfirmCount, PendingCount
                                                        FailedChildren
+--------------------------------------------------------------------+

StatsRequest   Sender   Receiver    yes         Immediate, StatsSeqNum
                                                 NumReplies, StatsList
+--------------------------------------------------------------------+

StatsReply      Child   Parent      yes         StatsSeqNum, StatsList
+--------------------------------------------------------------------+
   The trailing edge various fields of the window is advertised in the
    HighestReleased field. messages are described as follows:

   - BindSequenceNumber:  This specifies the largest is a monotonically increasing sequence
   number
    of any message sent that has subsequently been released for each bind request from the
    sender's retransmission window.  If both values are the same then
    the window is presently empty.  Zero is not a legitimate value given Receiver for a data sequence number, so if either field has given Data
   Session.

   - Scope: an integer to indicate how far a value of zero,
    then no messages have yet reached that state.  All sequence number
    fields use sequence number arithmetic so that repair message travels.
   This is optional.

   - Rejoin: a data session can
    continue after exhausting the sequence number space.

    When flag as to whether this Receiver was previously a member
   of a data session receives this Data Session.

   - Level: an advertisement of a new
    HighestReleased value, it stores this, and integer that indicates the level in the repair tree.
   This value is no longer allowed to
    ask for retransmission for any messages up used to and including keep loops in the
    HighestReleased value.  If it has any outstanding missing messages
    that are less than or equal tree from forming, in
   addition to HighestReleased, it MAY move forward
    and continue delivering indicating the next data messages distance from the Sender.  Any changes in
   a nodes level are passed down to the stream.  It
    also SHOULD report an error for Tree BB using the messages that are no longer
    recoverable.

    MaxHoldTime specifies
   treeLevelUpdate interface.

   - Role: This indicates if the maximum length of time bind requestor is a message may be
    held for retransmission. Receiver or Repair
   Head.

   - SubTreeCount: This parameter is set at an integer indicating the sender which
    uses it to set current number of
   Receivers below the HighestReleased node.

   - RepairAddr: This field in data the BindConfirm message headers.
    This is particularly useful for real-time, semi-reliable streams
    such as live video, where retransmissions are only useful for up used to
    a few seconds.  When combined with Unordered delivery semantics,
    and application-level jitter control at tell
   the receivers, this
    provides Time Bounded Reliability.  Obviously, MaxHoldTime must
    always be larger than MinHoldTime.

 7.2.5 Confirmed Delivery

    Flow control and Receiver which multicast address the reliability window are concerned with goodput,
    of delivering data with a high probability that it Repair Head will be sending
   retransmissions on.  If this field is delivered at
    all receivers.  However, neither mechanism provides explicit
    confirmation to null, then the sender as Receiver should
   expect retransmissions to be sent on the list of recipients for each
    message.  Confirmed delivery allows applications Senders data multicast
   address.

   - AlternateParent: This is an optional field that specifies another
   parent a Child may attempt to determine bind to.

   - SeqNum: an integer indicating the
    set Sequence Number of applications that have received a set of data messages.

    To request this service, message
   within a sender fills the AppSynch field of data
    messages with given Data Session.  For a Heartbeat, it is the highest
   sequence number of the highest data message it
    wishes to confirm delivery of.  It continues to do so until it
    receives confirmation, moves parent knows about.

   - ChildIndex: This is an integer the AppSynch point forward Repair Head assigns to a higher
    sequence number, or declares an error.

    When a receiver gets a data message with a non-zero AppSynch field,
    it starts including
   particular child.  The child Receiver uses this value to implement
   the rotating TRACK Generation algorithm.

   - LowestRepairAvailable: This is the highest lowest sequence number that has been
    acknowledged by a
   Repair Head will provide repairs for.

   - Reason: a code indicating the application in reason for the ApplicationConfirms BindReject,
   UnbindRequest, or EjectRequest message.

   - ParentTimestamp: This field of
    each TRACK message that it sends up is included in Heartbeat messages to
   signal the tree.  In order need to provide
    reliable delivery of this acknowledgement, this continues so long
    as do a receiver gets data messages with non-zero AppSynch fields.

    Each receiver local RTT measurement from a parent.  It is responsible for locally deciding
   the value of time when the
    ApplicationConfirms field.  There are two primary issues a receiver
    must consider in setting this field: parent sent the reliability semantics of message.

   - ChildrenList: This field contains the data stream, and when identifiers for a given message is considered confirmed
    at the receiver. list of
   children.  As part of the keepalive message, this is an application level confirmation, a
    handshake field together with
   the application SeqNum field is required used to get this
    confirmation.

    One example of how an application can implicitly signal
    confirmation of delivery is through the freeing of buffers passed urge those listed Receivers to it by send a
   TRACK (for the transport. provided SeqNum).  The API could specify that whenever an
    application has freed up a buffer containing one or more data
    messages, then Repair Head sending this must
   have been missing the regular TRACKs from these children for an
   extended period of time.

   - SenderTimestamp: This field is included in Data messages are considered acknowledged by the
    application.  Alternatively, the application could be required to
    explicitly acknowledge each message.

    With a given transport-application API for signaling
    acknowledgement, signal
   the transport then keeps track of all contiguous
    acknowledgements need to do a roundtrip time measurement from that application, the Sender, through
   the tree, and reports these up in back to the
    ApplicationConfirms field.  If one or more messages can not be
    acknowledged, Sender.  It is the receiver should pass an error code describing time (measured by the
    type of failure that occurred, and
   Senders local clock) when it sent the sequence number of message.

   - ApplicationSynch: a Sequence Number signaling a request for
   confirmed delivery by the first
    message application.

   - EndOfStream: indicates that has not yet been delivered.

    If MaxHoldTime this message is not in use for a the end of the data stream, so that delivery is
    fully reliable, then any message that can not be delivered will be
    considered a fatal error for that receiver.  If MaxHoldTime has a
    non-zero value, then any messages that could not be delivered, but
    are less than HighestReleased as advertised
   this session.

   - TransmissionRate: This field is used by the sender, are not
    reported as errors.

    In addition Sender to tell the AppSynch field, a sender may also set
   Receivers its sending rate, in messages per second.  It is part of
   the
    ImmediateACK field to 1.  When a node gets a data message that has
    this flag set, it will immediately send a TRACK after processing
    that message.

 7.3 Feedback Aggregation or nulldata messages.

   - HighestReleased:  This section describes how repair heads perform aggregation on
    feedback information sent up in field contains a Sequence Number,
   corresponding to the fields trailing edge of the TRACK message,
    and Senders retransmission
   window.  It is used (as part of the purposes for performing such aggregation.
    There are many reasons data, nulldata or retransmission
   headers) to inform the Receivers that they should no longer attempt
   to recover those messages with a smaller (or same) Sequence Number.

   - HighestAllowed: a Sequence Number, used for providing feedback flow control from all the
    receivers to
   Receivers.  It signals the sender in an aggregated form.  The major ones are
    listed below:

    1) End-to-end delivery confirmation.  This confirmation tells highest
   Sequence Number the
    sender Sender is allowed to send that all the receivers (in will not overrun
   the entire tree) have received
    data packets up to Receivers buffer pools.

   - BitMask: an array of 1s and 0s.  Together with a certain sequence number.  The field that
    carries this information Sequence Number it
   is AppSynch.

    2) Flow control.  The aggregated information used to indicate lost data messages.  If the ith element is carried in a 1,
   it indicates the message SeqNum+i is lost.

   - Slowest: This field contains a field HighestAllowed.  It tells the sender the highest sequence
    number that all the receivers (in the entire tree) are prepared to
    receive.

    3) Identifying characterizes the slowest receiver.  The aggregated information is
    carried
   Receiver in the field Slowest.  The sender can use this value as
    part of congestion control.

    4) Counting current membership in subtree beneath (and including) the group. node sending the
   TRACK.  This information is
    carried in used to provide information for the field SubTreeCount. congestion
   control BB.

   - SenderDallyTime: This lets the sender know field is associated with a SenderTimestamp
   field.  It contains the
    number sum of receivers currently connected to the repair tree.

    5) Measuring the round-trip waiting time that should be
   subtracted from the sender to RTT measurement at the "worst
    receiver.

    A repair head maintains state for each child.  Each time Sender.

   - ParentDallyTime: This is the same as the SenderDallyTime, but is
   associated with a TRACK
    (from ParentTimestamp instead of a child) SenderTimestamp.

   - DataLength: This is the length of the Data payload.

   - CongestionControl:  This includes any additional congestion control
   variables for aggregation, such as WorstLossRate,
   WorstEdgeThroughput, UnicastCost, and MulticastCost.

   - ApplicationConfirms: This is received, the corresponding states SeqNum value for which delivery
   has been confirmed by all children at or below this parent.

   - FailedChildren: This is a list of all children that child
    are updated based on the information in have recently
   been dropped from the TRACK message. When a repair head sends tree.

   - Immediate: If set to 1, a Receiver should immediately send a TRACK message
   on receipt of this packet.

   - Reliability: The level of reliability required in order to its parent, consider
   the following
    fields set of its data packets reliably delivered.

   - NumReplies: The number of consecutive TRACK messages that should be
   sent with this message are derived from the aggregation attached

   - SeqNumRange: The set of data messages that the
    corresponding states for its children. ALC request applies
   to.

   - ConfirmStatus: The following rules
    describe how acknowledgement status of the aggregation is performed:

    - AppSynch: take Receivers in the minimum of
   subtree up to the AppSynch value from all
    children node that sends this message.

   - HighestAllowed: take the minimum ConfirmCount: The number of Receivers in the HighestAllowed value from
    all children subtree up to the node
   that sends this message, that have acknowledged the ALC request.

   - Slowest: PendingCount: The number of Receivers in this is a measure subtree that are
   still pending in their decision as to acknowledging this ALC request.

   - StatsSeqNum: The number of how slow the slowest member this request for statistics.

   - StatsList: The list of statistics to be filled in by Receivers, and
   aggregated by the
    whole subtree is; take either control tree.

6. Global Configuration Variables, Constants, and Reason Codes

6.1 Global Configuration Variables
These are variables that control the minimum (or maximum) Data Session and are advertised to
all participants.  Some of them MAY instead be configured as constants.

   - TimeMaxBindResponse: the
    Slowest time, in seconds, to wait for a response
   to a BindRequest.  Initial value from all children (depending what the Slowest measure
    is). is TIMEOUT_PARENT_RESPONSE
   (recommended value is 3).  Maximum value is
   MAX_TIMEOUT_PARENT_RESPONSE.

   - SubTreeCount: take the sum MaxChildren: The maximum number of the SubTreeCount from all children a Repair Head is
   allowed to handle. Recommended value: 32.

   - SenderDallyTime: take ConstantHeartbeatPeriod: Instead of dynamically calculating the
   HeartbeatPeriod, a constant period may be used instead.  Recommended
   value: 3 seconds.

   - MinimumHeartbeatPeriod: The minimum value, value for all of the children, dynamically
   calculated HeartbeatPeriod.  Recommended value: 1 second.

   - MinHoldTime: The minimum amount of

          child's reported SenderDallyTime + child's local dally time

    Note, the SendTimeStamp field is left alone. a Repair Head holds on to
   data messages.

   - MaxHoldTime: The sender will
    derive the roundtrip maximum amount of time a Repair Head holds on to the worst receiver by doing its local
    aggregation for SenderDallyTime and then compute:

          RTT = currentTime
   data messages.

   - SendTimeStamp AckWindow: The number of messages seen before a Receiver issues an
   acknowledgement.  Recommended value: 32.

   - SenderDallyTime.

 7.4 Measuring Round Trip Times

    This TRACK BB provides two algorithms for distributed RTT
    calculations  LocalRTT measurements and SenderRTT measurements.
    LocalRTT measurements are only between LateJoinSemantics: The options available to a parent and its children.
    SenderRTT measurements are end-to-end RTT measurements, measuring Receiver who wishes
   to join a Data Session that is already in progress.

   - MaximumFailureListSize: The maximum number of entries that can be
   in a failure list.  This MUST be small enough that the RTT FailureList
   does not ever cause a TRACK to exceed the worst receiver as selected by size of a maximum UDP
   packet.  Recommended value:  800.

   - MaximumStatisticsListSize: The maximum number of entries that can
   be in a statistics list.  This MUST be small enough that the congestion control
    algorithms.
   FailureList does not ever cause a TRACK to exceed the size of a
   maximum UDP packet.  Recommended value:  100.

   - MaximumDataRate: The SenderRTT is useful maximum admission rate for congestion control. It can be used data messages from
   the application to
    set the data Data Channel Protocol.

   - MinimumDataRate: The minimum admission rate based on the TCP response function, which is
    being proposed for data messages from
   the congestion control building block.

    The LocalRTT can be used application to (a) quickly detect faulty children (as
    described in 7.1) or (b) avoid sending unnecessary retransmissions
    (as described in 7.2 in the local repair algorithm).

    In the case Data Channel Protocol.

6.2 Constants

   - NUM_MAX_PARENT_ATTEMPTS: The number of LocalRTT measurements, times to try to bind to a parent initiates
    measurement by including
   Repair Head before declaring a ParentTimestamp field PARENT_UNREACHABLE error.  Recommended
   value is 5.

   - TIMEOUT_PARENT_RESPONSE: The minimum value, in a Heartbeat
    message sent seconds, between
   attempts to its children.  When contact a child receives parent.  Recommended value is 1 second.

   - MAX_TIMEOUT_PARENT_RESPONSE:  The maximum value, in seconds,
   between attempts to contact a Heartbeat
    message with this field set, it notes the parent.  Recommended value is 16.

   - NULL_DATA_PERIOD: The time between transmission of receipt using its
    local system clock, and stores this with the message as
    HeartbeatReceiveTime.  When the child next generates a TRACK, just
    before sending it, it measures its system clock again as
    TRACKSendTime, and calculates the LocalDallyTime.

             LocalDallyTime = TRACKSendTime NullData
   Messages.  Recommended value is 1.

   - HeartbeatReceiveTime. FAILURE_DETECTION_REDUNDANCY: The child includes this value, along with the ParentTimestamp
    field, as fields in the next TRACK message sent.  Every heartbeat number of times a message that is multicast to all children SHOULD include sent
   without receiving a
    ParentTimestamp field. response before declaring an error.  Recommended
   value is 3.

   - MAX_TRACK_TIMEOUT: The SenderRTT algorithm maximum value for TRACKTimeout.  Recommended
   value is similar.  A sender initiates the process
    by including 5 seconds.

   - TRANSMISSION_REDUNDANCY: The number of times a SenderTimestamp field failure notification
   is redundantly sent up the tree in a data TRACK message.  When a
    receiver gets  Recommended
   value is 3.

6.3 Reason Codes

   - BindReject reason codes
     - LOOP_DETECTED
     - MAX_CHILDREN_EXCEEDED

   - UnbindRequest reason codes
     - SESSION_DONE
     - APPLICATION_REQUEST
     - RECEIVER_TOO_SLOW

   - EjectRequest reason codes
     - PARENT_LEAVING
     - PARENT_FAILURE
     - CHILD_TOO_SLOW
     - PARENT_OVERLOADED

7. Security

   As specified in [12], the primary security requirement for a message with this field set, it keeps track TRACK
   protocol is protection of the
    DataReceiveTime for that message, and when it generates transport infrastructure.  This is
   accomplished through the next
    TRACK message, includes use of lightweight group authentication of
   the SenderTimestamp control and, optionally, the data messages sent to the group.
   These algorithms use IPsec and SenderDallyTime
    value. shared symmetric keys.  For TRACK,
   [12] recommends that there be one shared key for the Data Session and
   one for each Local Control Channel.  These values keys are aggregated by Repair Heads, as described
    in section 7.3. distributed
   through a separate key manager component, which may be either
   centralized or distributed.  Each node only keeps track member of the most recent value group is responsible
   for
    {SenderTimestamp, DataReceiveTime} and {ParentTimestamp,
    HeartbeatReceiveTime}, replacing any older values any time that contacting the key manager, establishing a
    new message is received pair-wise security
   association with these values set.  As long as it has
    non-zero values to report, each node sends up both a
    {SenderTimestamp, SenderDallyTime} the key manager, and a {ParentTimestamp,
    LocalDallyTime} set of fields in each TRACK message generated.

    These measurements need to be averaged by obtaining the TRACK PI.

 8. Security

    This appropriate keys.

   The exact algorithms for this BB does not specifically deal with security.  It is are presently the
    responsibility subject of
   research within the TRACK PI or IRTF Secure Multicast Group (SMuG) and
   standardization within the Multicast Security BB.  This issue is
    covered working group.

8. References

   [1]  Bradner, S., "The Internet Standards Process -- Revision 3", BCP
      9, RFC 2026, October 1996.

   [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 Security Requirements For TRACK draft [HW00].

 9. References

    [HW00] T. Hardjono, B. 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,"
    Internet Draft, Internet Engineering Task Force, June, for TRACK"
      draft-ietf-rmt-pi-track-security-00.txt, June 2000.

    [KLCWTCTK01] M.  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, B. J. Wesley, J. Provino, "Tree-based
      Reliable Multicast (TRAM)", draft-kadansky-tram-02.txt, Work in
      Progress.

   [15]  Whetten, B. 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, G.
    Taskale, B. N., Taskale,
      G., Cain, D. B., Thaler, S. D., Koh, s. J., "Reliable Multicast
      Transport Building Block: Tree Auto-Configuration," Internet Draft, Internet
    Engineering Task Force, March, Auto-Configuration", draft-ietf-
      rmt-bb-tree-config-02.txt, March 2, 2001.  Work in Progress.

   [17]  Whetten, B. et. al., "TRACK Protocol Instantiation Over UDP",
      draft-ietf-rmt-track-pi-udp-00.txt, November 2002.

   [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.

    [KV00] R.  Work in Progress.

   [20]  Speakman, T., et. al., "Pragmatic General Multicast (PGM)",
      draft-speakman-pgm-spec-06.txt, Feb 2001.  Work in Progress.

   [21]  Kermode, L. R., Vicisano, L., "Author Guidelines for RMT Building
   Blocks and Protocol Instantiation Documents," Internet Draft,
    Internet Engineering Task Force, June, 2000.

    [SFCGLTLLBEJMRSV00] T. Speakman, D. Farinacci, J. Crowcroft, J.
    Gemmell, S. Lin, A. Tweedly, D. Leshchiner, M. Luby, N. Bhaskar, R.
    Edmonstone, K. M. Johnson, T. Montgomery, L. Rizzo, R.
    Sumanasekera, and L. Vicisano, "PGM Reliable Transport Protocol
    Specification," Internet Draft, Internet Engineering Task Force,
    November 2000.

    [WCP00] B. Whetten, D. Chiu, S. Paul, M. Kadansky, G. Taskale,
    "TRACK Architecture, A Scalable Real-Time Reliable Multicast
    Protocol," Internet Draft, Internet Engineering ask Force, July
    2000.

    [WVKHFL00]  B. Whetten, L. Vicisano, R. Kermode, M. Handley, S.
    Floyd, and M. Luby, "Reliable Multicast Transport Building Blocks
    for One-to-Many Bulk-Data Transfer," Documents", RFC 3048, January 2001. 3269.

10. Acknowledgements
   We would like to thank the follow people: Sanjoy Paul, Seok Joo Koh,
   Supratik Bhattacharyya, Joe Wesley, and Joe Provino.

11. Authors' Authors 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

   Miriam Kadansky
    miriam.kadansky@sun.com
   Sun Microsystems Laboratories
   1 Network Drive
   Burlington, MA 01803
   miriam.kadansky@sun.com

   Seok Joo Koh
   sjkoh@pec.etri.re.kr

   Gursel Taskale
    gursel@talarian.com
    Brian Whetten
    whetten@talarian.com
    Talarian
    333 Distel Circle
    Los Altos, CA 94022-1404
   TIBCO Corporation
   gursel@tibco.com

   Full Copyright Statement

   "Copyright (C) The Internet Society (2001). (2000). 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 languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."