RMT Working Group Brad Cain/Mirror Image Internet Engineering Task Force Dah Ming Chiu/Sun Microsystems INTERNET-DRAFT Miriam Kadansky/Sun Microsystems draft-ietf-rmt-bb-tree-config-00.txt Seok Joo Koh/ETRI/Korea 14 July, 2000 Brian Neil Levine/UMass Expires 14 January 2001 Gursel Taskale/Talarian Brian Whetten/Talarian Reliable Multicast Transport Building Block: Tree Auto-Configuration <draft-ietf-rmt-bb-tree-config-00.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 valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as a "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 The Reliable Multicast Transport Working Group has been chartered to standardize multicast transport services. This working group expects to initially standardize three protocol instantiations. This draft is concerned with the requirements of the tree-based ACK protocol. In particular, it is concerned with defining the building block for auto-configuration of the logical ACK-tree. According to the charter, a building block is "a coarse-grained modular component that is common to multiple protocols along with abstract APIs that define a building block's access methods and their arguments." For more information, see the Reliable Multicast Transport Building Blocks and Reliable Multicast Design Space documents [WLKHFL00][HWKFV00]. draft-ietf-rmt-bb-tree-config-00 [Page 1]
INTERNET DRAFT draft-ietf-rmt-bb-tree-config-00.txt 14 July 2000 Table of Contents 1. Introduction 1.1 Terminology 1.2 Assumptions 1.3 Requirements 2. Overview 3. Metrics 3.1 Static Metric 3.2 Expanding Ring Search Metric 3.3 Point-of-Contact (POC) Metric 3.4 Routing Metric 4. Tree Formation 4.1 Step 1: Session Advertisement 4.1.1 Static Metric 4.1.2 Expanding Ring Search Metric 4.1.3 Point-of-Contact (POC) Metric 4.1.4 Routing Metric 4.2 Step 2: Neighbor Discovery and Selection 4.2.1 Static Metric 4.2.2 Expanding Ring Search Metric 4.2.3 Point-of-Contact (POC) Metric 4.2.4 Routing Metric 4.3 Step 3: Binding to the Service Node 4.4 Late Joins 5. Tree Maintenance 5.1 Monitoring Parents and Children 5.2 Optimizing the Tree 6. Messages 7. Open Issues 8. References Authors' Addresses draft-ietf-rmt-bb-tree-config-00 [Page 2]
INTERNET DRAFT draft-ietf-rmt-bb-tree-config-00.txt 14 July 2000 1. Introduction The Reliable Multicast Transport (RMT) working group has been chartered to standardize IP multicast transport services. This draft is concerned with the requirements of the tree-based ACK protocol[WCP00]. In particular, this draft defines a protocol that comprises the building block for auto-configuration of a logical ACK-tree comprised of a single Sender, Service Nodes, and Receivers into a tree. The design goals of this draft are motivated by the needs of TRACK-based protocols, however the trees it constructs are useful for other services. The process of ACK tree construction is difficult for IP multicast. The best trees match the underlying (i.e. forwarding tree) multicast routing tree topology[LPG98], however the multicast service model[DEE89] does not provide explicit support for discovering routing tree topology. Furthermore, deployed multicast architectures can vary; for example, hosts may be restricted to multicast reception and not transmission with PIM-SS[HC00]; and routers may provide special extended routing services with Generic Router Assist [CST00]. The RMT charter does not restrict the use of any particular network service in constructing the tree, it only suggests preferred scenarios. Accordingly, there are several viable solutions for constructing a tree. This draft describes a unified solution for tree construction in the presence of different multicast service models and routing protocols. In particular, it specifies a single protocol which may be used with various metrics, several of which are specified within this document. Different implementations can differ by what metrics are used to build the tree and also what mechanisms are used to discover such metrics, but the signaling for building the tree is exactly the same and therefore interoperable. In order to accommodate various multicast deployments, this document divides the tree building process into two components: 1. A protocol for construction and maintenance of logical Session Trees (which is common across all metrics). 2. Several metrics for using in tree construction and the methods for obtaining those metrics. This document currently describes four such metrics. These are the following: Static configuration, Beacon (by way of a Sender Beacon or GRA), Point-of-Contact, and through the use of a SN routing metric. This draft is required to conform to the guidelines specified in draft-ietf-rmt-author-guidelines-xx, Author Guidelines for RMT Building Blocks and Protocol Instantiation Documents [KV00]. A future version of this draft will more explicitly describe this conformance. 1.1 Terminology 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. Session A session is used to distribute data over a multicast address. A draft-ietf-rmt-bb-tree-config-00 [Page 3]
INTERNET DRAFT draft-ietf-rmt-bb-tree-config-00.txt 14 July 2000 tree is used to provide reliability service for a session. Sender The single sender of data on a multicast session. The Sender is the root of the Session Tree. Receiver A receiver receives data from the sender via the multicast session. Session Identifier A 48-bit number, chosen either by the application that creates the session or by the transport. Senders and Receivers use the Session Identifier to distinguish sessions. Service Node (SN) A node within the tree which receives and retransmits data, and aggregates and forwards control information toward the Sender. The Sender operates as the root Service Node in any session tree. Service Nodes MAY be dedicated servers within a network designed to participate in multiple Sessions, or they MAY be Receivers participating in an individual session. SNs MAY limit the number of Children they choose to service, and MAY also make other restrictions on the characteristics of each Child (distance, location, etc.). An SN that has accepted Children for a session is called a Parent. Session Tree (ST) The Session Tree is a spanning tree per Session, rooted at the Sender and consisting of a number of Service Nodes. An ST is constructed for the forwarding of control information back to the Sender as well as for the resending of missed data to the Receivers. The ST for a particular session may change over the course of the session. Parent A Parent is an SN or Receiver's predecessor in the ST on the path toward the Sender. Every SN or Receiver on the tree except the Sender itself has a parent. Each Parent communicates with its children using either an assigned multicast address or through unicast. If a multicast address is used, this may be the same address used by the session, or one specifically assigned to the Parent. Children The group of Receivers and SNs one Tree Level below for which an SN is providing repair and feedback services. Tree Level A number indicating a SN's level within the ST. The Sender's Tree Level is always 0. The Sender's Children are at level 1, etc. Each Node (except the Sender) has an initial Tree Level of 100, indicating that it is not yet on the tree. This means that the maximum number of tree levels is 99. Once a Node joins the tree, its Tree Level is updated. draft-ietf-rmt-bb-tree-config-00 [Page 4]
INTERNET DRAFT draft-ietf-rmt-bb-tree-config-00.txt 14 July 2000 Metric A measurement procedure used to determine relative distances between Receivers, SNs, and the Sender. Several Metrics are described in this draft. The Metric (or Metric to Sender) is used to select a SN as parent and therefore to build the Session Tree. This document describes several metrics. These metrics may include different mechanisms for discovery. Neighbor A Receiver or SN's Neighbors are SNs that, according to the selected Metric, are closest to it and also closer to the Sender than the Receiver. Sender Beacon One metric discovery process is through a Sender initiated beacon message. A Sender Beacon is initiated by the Sender to measure distances between the Sender and Receivers and SNs. 1.2 Assumptions This document describes how to build trees under the following conditions: a. The multicast group has only a single sender. b. A single SN can serve multiple sessions. c. Sessions can take advantage of a pre-deployed infrastructure of SNs (ones that are not necessarily aware of a session before tree-building starts), or recruit Receivers to be SNs. d. Generic Router Assist[CST00] and Expanding Ring Search[YGS95] are not required of the network infrastructure, but if available they should be able to be utilized. 1.3 Requirements The following are specifically required: a. While tree-building make take advantage of information from the routing layer, the mechanisms described are independent of the routing protocol(s) used by the underlying multicast tree. b. All trees constructed must be loop free c. These mechanisms must support late joiners and tree optimization 2. Overview The tree building process described within this document builds logical trees which consist of: 1. A root node which is the Sender 2. Intermediate nodes which may be either Receivers or nodes specifically allocated to the task of repair and aggregation 3. Leaf nodes which are Receivers only ACK trees are spanning trees rooted at the Sender and built in a "bottom-up" or receiver-initiated fashion. ACK trees can be used for the forwarding of control information (i.e. ACKs) towards the root, or for forwarding of data (i.e. repairs) towards the leafs. draft-ietf-rmt-bb-tree-config-00 [Page 5]
INTERNET DRAFT draft-ietf-rmt-bb-tree-config-00.txt 14 July 2000 ACK trees are constructed per Sender; each node initiating a tree join request uses its metric(s) to the Sender to make a decision as to which node is the best parent. This document specifies several such metrics (and methods for obtaining those metrics). The only requirement is that a single tree must be constructed using the same metrics throughout. It is important to note that SNs may be actual Receivers (e.g. Receivers willing and able function as Repair Heads) or pre-deployed "specialized" servers that are prodded into service by Receivers. We use the term Service Node to refer to either a Receiver or "server" which is participating as part of the logical tree formation. Tree construction, regardless of metric, proceeds generically as follows. 1. Receivers of a session use standard out-of-band mechanisms for discovery of a session's existence (e.g. Session Advertisement[HPW00], URL, etc). In this way, a Receiver discovers the multicast group address, the Sender's address, and other information necessary for logical tree construction. 2. Each Receiver then determines the best SN to use for the session, and binds with it for service. If a Receiver is also an SN, then it may use mechanisms described in this document to find an SN for itself. 3. All SNs must determine their distance to the Sender using the Metric required for the Session. 4. Once an SN determines its own metric to the Sender, it discovers other potential parents and their metrics as well. In this way, the SN can make a choice as to where it should graft itself into the Session Tree. 5. When an appropriate parent SN has been chosen, a SN must bind to the chosen parent. Once an SN receives a bind from a child, that SN must then also bind with other SNs in order to form the Session Tree (rooted back to Sender). 6. During a session, a Receiver or SN may change to a different SN for a number of reasons described below. The Session Tree is maintained and optimized over time. draft-ietf-rmt-bb-tree-config-00 [Page 6]
INTERNET DRAFT draft-ietf-rmt-bb-tree-config-00.txt 14 July 2000 The protocol provides mechanisms for maintaining and optimizing the tree, as well as tearing it down when the Sender is done with it. In the rest of this document, the term 'Node' denotes a Receiver or SN. +---------------+ | | | Session | | Advertisement | | | +---------------+ | | | Node receives tree-building parameters | V +--------------------+ | | | Neighbor Discovery |<-------------------------| | and Selection | | | | | +--------------------+ | | | | | | Node picks best Neighbor | | | V | +--------------------+ | | | | | Binding to |--------------------------- | Service Node | Periodic optimization try | | or Parent leaves +--------------------+ 3. Metrics Metrics to the Sender are used to rank and determine which Neighbor is an appropriate parent. Several Metrics for determining and ranking Neighbors for a Node can be used within this building block. A Node MAY use multiple metrics to determine its Neighbors. However, different Metrics are not necessarily comparable and a single Metric should be used at at any one point in a Session. However, different Metrics MAY be used serially, with a node falling back on a less desirable metric after a different Metric fails to provide a Parent. A short description of each Metric is included here. More details of how each one operates in included in the Tree Formation section below. 3.1 Static Metric A list of Neighbors and optionally their distances are made available to a Node in some well-known location. The Node determines the Neighbors' distances, then picks the best one to be its SN. 3.2 Expanding Ring Search Metric Nodes learn their approximate distance to a the Sender through either a Sender Beacon or through the use of GRA. Once this metric is draft-ietf-rmt-bb-tree-config-00 [Page 7]
INTERNET DRAFT draft-ietf-rmt-bb-tree-config-00.txt 14 July 2000 learned, it can be advertised to Neighbors through the use of either an expanding ring search or through other means (e.g. GRA). SNs multicast their request using an expanding ring search. SNs offering service respond to requests with their own TTL from the source. Nodes increase the TTL of their requests until responses are received, then pick the best SN. 3.3 Point-of-Contact (POC) Metric [BRIAN] Nodes learn their distance from the source, then query a designated node, the POC, for Neighbors using this distance. The POC returns one or more choices of SN, from which the node chooses. 3.4 Routing Metric Nodes learn their distance from the source through either static configuration, through a Sender Beacon, or other such means. Nodes have preconfigured relationships with potential parents to which they advertise their own Metric. 4. Tree Formation The following is a detailed description of the tree formation process. All tree construction follows this pattern. The ONLY differences between instantiations of this building block lie in how nodes discovers metrics and what metrics are used. 4.1 Step 1: Session Advertisement Receivers of a session are informed of the session's existence through some out-of-band method, such as Session Advertisement[HPW00], e-mail, etc. SNs do not necessarily receive these advertisements. If an SN is not a Receiver, it obtains the advertisement information once it is contacted by a Receiver. The advertisement includes the multicast address being used, the Sender's address, the Session Identifier, any specific port numbers to be used, the Metric(s) to be used, and any Metric-specific information. Metric-specific information for each Metric is as follows: 4.1.1 Static Metric The location of the Neighbor list, which could be a file name, a URL, or a DNS name. This Neighbor list may consist of a definitive parent per Session or a list of potential Neighbors and their distances to a Sender or set of Senders. 4.1.2 Expanding Ring Search Metric For the Expanding Ring Search Metric, the advertisement MUST include the multicast address and the maximum TTL to use for solicitation, plus the TTL increment to use for successive solicitations, and the time interval between them. 4.1.3 Point-of-Contact (POC) Metric [BRIAN] Address of the Sender's POC. draft-ietf-rmt-bb-tree-config-00 [Page 8]
INTERNET DRAFT draft-ietf-rmt-bb-tree-config-00.txt 14 July 2000 4.1.4 Routing Metric When using the Routing Metric, Nodes are configured with a set of potential Neighbors to exchange Metrics with. This list is simply the list of unicast IP addresses of the Nodes. 4.2 Step 2: Neighbor Discovery and Selection Using one or more of the metrics, a Node determines its location relative to the source, and collects information about nearby SNs and their locations relative to the source. An SN is added to the Node's list of Neighbors if it is closer to the source than the Node itself. The best Neighbor, as determined by the Metric, is then selected from the list of Neighbors. The remaining list may then be cached for future use. The selected Neighbor must also meet loop-free criterion: the Neighbor must have a Tree Level lower than or equal to the Node's. In addition, if the Neighbor's Tree Level is less than 100, the Node knows that the Neighbor is connected to the tree. The details of this process for each metric follow. 4.2.1 Static Metric A list of Neighbors and optionally their distances are made available to a Node in some well-known location. The location of the Neighbor list, which could be a file name, a URL, or a DNS name, MAY be included in the advertisement. The list of Neighbors may also include pre-determined distance information. If not, the node determines each Neighbor's Metric using the same solicit procedure described in section 4.2.2, except a unicast SOLICIT message is used instead of a multicast message. Each Node then picks the best Neighbor to be its SN. 4.2.2 Expanding Ring Search Metric Nodes look for Neighbors using a multicast SOLICIT message. An SN that is able to handle additional Children SHOULD respond to a SOLICIT message by multicasting a HEARTBEAT message. If the SN is not yet a Parent, the TTL used in this response is the same TTL used in the SOLICIT message. If the SN is a Parent, the TTL used is the greater of the SOLICIT TTL and the Parent's current HEARTBEAT TTL. The Node listens for HEARTBEAT messages after sending the SOLICIT message. If one or more HEARTBEAT messages are received during a solicit interval, the best SN among them is selected. If no HEARTBEAT messages are received, the Node sends another multicast SOLICIT message with an incremented TTL. The process of sending the multicast SOLICIT message with an increasing TTL value continues until a response is received. The TTL value is limited by a value specified in the advertisement. If the TTL value required to reach the soliciting Node is greater than the TTL used to reach the SN, a HEARTBEAT message may not reach the Node. However, if future SOLICIT messages have increased TTL values, the TTL may eventually be large enough for the HEARTBEAT message to reach the Node. However, it is possible that the Node draft-ietf-rmt-bb-tree-config-00 [Page 9]
INTERNET DRAFT draft-ietf-rmt-bb-tree-config-00.txt 14 July 2000 will not locate any SNs using Expanding Ring Search. SNs SHOULD suppress sending HEARTBEAT messages in response to SOLICIT messages if one was sent with at least the SOLICIT's TTL within the last solicit interval. Nodes MAY suppress sending SOLICIT messages for one interval when they first start in order to collect information from HEARTBEAT messages already solicited by other nodes. The multicast TTL value required to reach a Receiver from an SN defines the distance between them. The best Neighbor is the one closest to the Sender. Criteria used to break ties MAY include the SN's number of Children, capacity, Tree Level, or IP address. 4.2.3 Point-of-Contact (POC) Metric [BRIAN] Address of the Sender's POC. 4.2.4 Routing Metric Nodes contact each potential Neighbor with a unicast HEARTBEAT message. Nodes announce their metrics to each potential Neighbor with a unicast SENDERMETRIC message. Each message contains a Node's Metric to the Sender(s). SENDERMETRIC messages are sent whenever a Node's Metric changes. The Metric that is included in SENDERMETRIC messages may be discovered through a variety of means. Each Node maintains a list of potential Neighbors from which it has received HEARTBEAT messages. A bi-directional relationship is established between potential Neighbors. Before sending a SENDERMETRIC to a potential Neighbor, it must be assured that the potential Neighbor has received the Node's HEARTBEAT message. This is accomplished through the use of a bi-directional bit in the HEARTBEAT message. SENDERMETRIC updates are sent after the following events: 1. When a new potential Neighbor's HEARTBEAT message is received (with the bi-directional bit set). 2. When a Node's Metric changes. After receiving SENDERMETRIC messages from each potential Neighbor, a Node makes a choice as to which Neighbor is the most appropriate parent. 4.3 Step 3: Binding to the Service Node Once an SN has been selected, the Node sends a BIND message to the SN. If the SN accepts the Node as a Child, it returns an ACCEPT message. If it does not accept the Node, it sends a REJECT message. If the Node does not receive a response after a reasonable number of tries and timeout period, it MAY select the next best Neighbor from its cached list, else it runs the Neighbor Discovery and Selection step again to determine an alternate SN to try. draft-ietf-rmt-bb-tree-config-00 [Page 10]
INTERNET DRAFT draft-ietf-rmt-bb-tree-config-00.txt 14 July 2000 The ACCEPT message MUST include the Parent's current Tree Level. The Node MUST set its Tree Level to one more than the Parent's level. If the Node itself has Children, it MUST send a HEARTBEAT message containing the new Tree Level. The ACCEPT message MAY also indicate the starting sequence number of the message from which data reliability is assured. Service Nodes MAY limit the number of children they support depending on their capacity. Once an SN has accepted its maximum number of Children, it stops accepting new Children until a change in membership causes its count of Children to go below this limit. If an SN limits the number of children it supports, it MUST reserve several child slots for other SNs. This guarantees the growth of the repair tree. [BRIAN] Some metrics require action by an SN whenever its list of Children changes. 4.4 Late Joins A late joiner is a node seeking membership in the tree after the Sender has started to send data. In this case, it is possible that some of the data is no longer available within the tree. Nodes may need to have specific information about repair availability before selecting a Parent from its possible Neighbors. In order to accommodate this requirement, the SOLICIT, BIND, ACCEPT, and HEARTBEAT messages may contain information about both a Node's requirements for repair data, and an SN's ability to provide that data. 5. Tree Maintenance Tree maintenance is an ongoing process active in every Node. Because the tree is based on the operation of SNs, as well as the various underlying metrics that may change over time, it is important that these dependencies be monitored for changes. Nodes MUST monitor Parents for liveliness and changes in tree level, and SHOULD continue to run the Neighbor Discovery and Selection process in order to optimize their choice of SN. Parents must monitor Children for liveliness. 5.1 Monitoring Parents and Children Parents periodically send out HEARTBEAT messages unicast or on their assigned multicast addresses as a keep-alive to their Children. The HEARTBEAT message MUST contain the Parent's current Tree Level. Children MUST set their Tree Level to one more that their Parent's level. Children respond to their Parent's HEARTBEAT message with a HEARTBEATCONFIRM message. Both messages MAY be suppressed if other messages in the protocol instantiation have recently provided a keep-alive function. If a Child does not receive a HEARTBEAT message from its Parent for a period of time, it MUST attempt to bind with an alternate SN. A Child that is leaving a session MUST send a unicast LEAVE message to its Parent. The Parent SHOULD respond with a LEAVECONFIRM draft-ietf-rmt-bb-tree-config-00 [Page 11]
INTERNET DRAFT draft-ietf-rmt-bb-tree-config-00.txt 14 July 2000 message. A Parent that is leaving the session MUST send a multicast LEAVE message to its Children indicating that they need to bind with an alternate SN. [BRIAN] Some metrics require action by an SN whenever it leaves the session. If a Parent does not hear a HEARTBEATCONFIRM message from a Child for a period of time, or it receives a LEAVE message from a Child, it removes that Child from its list of Children. [BRIAN] Some metrics require action by an SN whenever it's list of Children changes. 5.2 Optimizing the Tree Implementations of this building block SHOULD continue to run the Neighbor Discovery and Selection process in order to optimize the choice of SN. This continuous process also keeps the metric information for the current Parent up- to-date. Whenever the process returns a better SN than the current one, the Node SHOULD bind to the new SN. Once the new SN is bound to, the Node MUST send a LEAVE message to the original Parent. A Parent with no Children MAY leave the session. draft-ietf-rmt-bb-tree-config-00 [Page 12]
INTERNET DRAFT draft-ietf-rmt-bb-tree-config-00.txt 14 July 2000 6. Messages These messages are required for implementations of this building block. The list below indicates which message contents are required by implementations. Implementations may also include other protocol-specific information in these messages. +------------------+---------------------------------+----------------------+ | Message Name | Description | Required | | m'cast or u'cast | | Contents | |------------------+---------------------------------+----------------------+ | SOLICIT | queries Neighbors for metric | Metric(s) | | both | information | | |------------------+---------------------------------+----------------------+ | BIND | request to SN to join tree | Metric information | | unicast | | current Tree Level | |------------------+---------------------------------+----------------------+ | ACCEPT | acceptance of BIND from SN | current Tree Level | | unicast | | | |------------------+---------------------------------+----------------------+ | REJECT | rejection of BIND from SN | reject reason | | unicast | | | |------------------+---------------------------------+----------------------+ | LEAVE | Child leaving Parent (u'cast), | | | both | or Parent leaving tree (m'cast) | | |------------------+---------------------------------+----------------------+ | LEAVECONFIRM | Acknowledgement of LEAVE | | | unicast | message | | |------------------+---------------------------------+----------------------+ | HEARTBEAT | Periodic keep-alive from Parent | current Tree Level | | both | to Children | | |------------------+---------------------------------+----------------------+ | HEARTBEATCONFIRM | Acknowledgement of HEARTBEAT | | | unicast | from Child | | |------------------+---------------------------------+----------------------+ draft-ietf-rmt-bb-tree-config-00 [Page 13]
INTERNET DRAFT draft-ietf-rmt-bb-tree-config-00.txt 14 July 2000 7. Open Issues Tree Recording We should have an interface for recording the tree structure in order to be able to recreate it using static settings. Globalized Metrics It would be nice to have more ways of using metrics to optimize trees in different ways, like using the minimal number of SNs, or the minimal number of Children per SN, etc in order to create trees with certain global or optimized characteristics. Tree-Connection Knowledge Is it useful (or necessary?) for an SN to know if it is on the tree? Is it useful for an SN to be preferred if it is already on the tree ("metric bonus")? Measuring Distances We need to specify more about how to measure distances. Unicast or multicast? Port Numbers Port number issues need to be spelled out. Do we need a reserved port number? Split up 'Metric'? Are there really two parts to Metric, methods (ERS, Static, etc.) and metrics (unicast or multicast TTL, child count, etc.). Separate Learning Metrics from Advertising Metrics? There may be a particular way to learn a metric to sender (e.g. Sender Beacon) but there may be different ways to advertise it to other SNs (e.g. Routing messages, POC, ERS). Here's how I divide it up: Static: learn and/or advertise Sender Beacon: learn GRA: learn and/or advertise Routing Messages: advertise (possibly learn but not covered yet) ERS: learn and/or advertise POC: learn and/or advertise Combine Messages Can we consolidate more of the tree-building messages? draft-ietf-rmt-bb-tree-config-00 [Page 14]
INTERNET DRAFT draft-ietf-rmt-bb-tree-config-00.txt 14 July 2000 8. References [CST00] B. Cain, T. Speakman, D. Towsley, "Generic Router Assist (GRA) Building Block - Motivation and Architecture", Internet Draft, Internet Engineering Task Force, March 2000. [DEE89] Deering, S., "Host Extensions for IP Multicasting", RFC 1112. [ECTP00] ITU-T SG7/Q.13 and ISO/IEC JTC1/SC6/WG7, "Enhanced Communication Transport Protocol," ITU-T Draft Recommendation X.ectp and JTC1/SC6 Committee Draft 14476, June, 2000. [HC00] H. Holbrook, B. Cain, "Source-Specific Multicast for IP," Internet Draft, Internet Engineering Task Force, March 2000. [HPW00] Handley M., Perkins, C., Whelan, E. "Session Announcement Protocol", Internet Draft, Internet Engineering Task Force, March 2000. [HWKFV00] M. Handley, B.Whetten, R. Kermode, S.Floyd, L. Vicisano, and M. Luby, "The Reliable Multicast Design Space for Bulk Data Transfer," Internet Draft, Internet Engineering Task Force, March 2000. [KV00] R. Kermode, L. Vicisano, "Author Guidelines for RMT Building Blocks and Protocol Instantiation Documents," Internet Draft, Internet Engineering Task Force, July, 2000. [LPG98] B.N. Levine, S. Paul, and J.J. Garcia-Luna-Aceves, "Organizing Multicast Receivers Deterministically According to Packet-Loss Correlation," Proc. Sixth ACM International Multimedia Conference (ACM Multimedia 98), Bristol, UK, September 1998. [WCP00] B. Whetten, D. Chiu, S. Paul, "TRACK Architecture, A Scalable Real-Time Reliable Multicat Protocol," Internet Draft, Internet Engineering Task Force, July 2000. [WLKHFL00] 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," Internet Draft, Internet Engineering Task Force, March 2000. [YGS95] R. Yavatkar, J. Griffioen and M. Sudan, "A Reliable Dissemination Protocol for Interactive Collaborative Applications", University of Kentucky, 1995. draft-ietf-rmt-bb-tree-config-00 [Page 15]
INTERNET DRAFT draft-ietf-rmt-bb-tree-config-00.txt 14 July 2000 Authors' Addresses Brad Cain brad.cain@mirror-image.com Mirror Image Dah Ming Chiu dahming.chiu@sun.com Miriam Kadansky miriam.kadansky@sun.com Sun Microsystems Laboratories 1 Network Drive Burlington, MA 01803 Seok Joo Koh sjkoh@pec.etri.re.kr ETRI/Korea 161 Kajong-dong Yusong-Gu, TAEJON, 305-350, KOREA Brian Neil Levine brian@cs.umass.edu Computer Science Department University of Massachusetts Amherst, MA 01060 Gursel Taskale gursel@talarian.com Brian Whetten whetten@talarian.com Talarian 333 Distel Circle Los Altos, CA 94022-1404 Full Copyright Statement Copyright (C) The Internet Society (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 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." draft-ietf-rmt-bb-tree-config-00 [Page 16]
