One document matched: draft-ietf-rmt-bb-tree-config-00.txt
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]
| PAFTECH AB 2003-2026 | 2026-04-22 23:25:54 |