idnits 2.17.1 draft-sjkoh-rmt-bb-tree-config-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([RFCxxxx]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: - SolicitPeriod: Each receiver MUST not send more than one QUERY message per SolicitPeriod. When a RH responds to QUERY messages, it also suppresses its ADVERTISE message if one has been sent less than SolicitPeriod ago. This parameter is used to control the amount of control traffic during tree construction if ERS is used. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2119' is defined on line 1162, but no explicit reference was found in the text == Unused Reference: 'RFC3048' is defined on line 1165, but no explicit reference was found in the text == Unused Reference: 'RFC3269' is defined on line 1176, but no explicit reference was found in the text == Unused Reference: 'RFC2357' is defined on line 1184, but no explicit reference was found in the text Summary: 7 errors (**), 0 flaws (~~), 6 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 RMT Working Group Dah Ming Chiu, CUHK 3 Internet Engineering Task Force Seok Joo Koh, ETRI 4 Category: Informational Miriam Kadansky, Sun Microsystems 5 December 2003 Brian Whetten, Consultant 6 Expires June 2004 Gursel Taskale, Tibco 8 Tree Auto-Configuration (TREE) Building Block 9 for Reliable Multicast Transport 11 13 Status of this Memo 15 This document is an Internet-Draft and is in full conformance with 16 all provisions of Section 10 of RFC 2026. 18 Internet-Drafts are valid for a maximum of six months and may be 19 updated, replaced, or obsoleted by other documents at any time. It 20 is inappropriate to use Internet-Drafts as reference material or to 21 cite them other than as a "work in progress". 23 The list of current Internet-Drafts can be accessed at 24 http://www.ietf.org/ietf/1id-abstracts.txt 25 The list of Internet-Draft Shadow Directories can be accessed at 26 http://www.ietf.org/shadow.html. 28 Abstract 30 This document defines the TREE building block (BB) for tree 31 configuration within a reliable multicast transport (RMT) protocol. 32 As an RMT building block, the TREE BB is a coarse-grained modular 33 component that may be common to multiple RMT protocols. The TREE 34 BB provides automatic configuration of a logical ACK-tree for RMT 35 protocols in the tree-based ACK family. A companion document 36 [RFCxxxx] describes the TRACK (Tree-based ACK) building block, 37 which assumes that the logical ACK tree has been configured by the 38 TREE BB described here. 40 Table of Contents 42 1. Introduction..................................................3 43 2. Terminology...................................................4 44 3. TREE BB Rationale.............................................5 45 4. Functionality of TREE BB......................................5 46 4.1 Assumptions and Requirements..............................5 47 4.2 Functional Overview.......................................6 48 5. BB Details: Session Announcement..............................9 49 6. BB Details: Repair Head Discovery and Selection...............9 50 6.1 Repair Head Discovery Algorithms..........................9 51 6.2 Distance Measurement.....................................16 52 6.3 Repair Head Selection....................................18 53 7. BB Details: Tree Formation...................................19 54 8. BB Details: Tree Maintenance.................................21 55 8.1 Monitoring Parents and Children..........................21 56 8.2 Optimizing the Tree......................................21 57 9. External Interfaces..........................................22 58 9.1 Interfaces to this BB....................................22 59 9.2 Interfaces from this BB to the PI or a higher-level BB...23 60 10. Applicability Statement.....................................24 61 11. Messages for TREE BB........................................25 62 12. Requirements from other Building Blocks.....................26 63 13. Security Considerations.....................................26 64 14. References..................................................27 65 Acknowledgments.................................................27 66 Author's Addresses..............................................28 68 1. Introduction 70 The Reliable Multicast Transport (RMT) working group was chartered 71 to standardize IP multicast transport services [RFC2887]. Rather 72 than create a set of monolithic protocol specifications, the RMT WG 73 has chosen to break the reliable multicast protocols into Building 74 Blocks (BB) and Protocol Instantiations (PI). A Building Block is 75 a specification of the algorithms of a single component, with an 76 abstract interface to other BBs and PIs. A PI combines a set of 77 BBs, adds in the additional required functionality not specified in 78 any BB, and specifies the specific instantiation of the protocol. 80 This document describes the Tree auto-configuration building block, 81 or TREE BB. The function of the TREE BB is to construct a session 82 tree, comprised of a single sender, repair heads, and receivers, 83 for use by a tree-based ACK reliable delivery protocol, for example 84 the Tree-Based ACK (TRACK) BB [RFCxxxx]. The design goals of the 85 TREE BB are motivated by the TRACK BB, but trees it constructs 86 could be useful for other functions. 88 The process of session tree construction for IP multicast is 89 difficult. The best session trees match the underlying multicast 90 routing tree topology; however, the multicast service model does 91 not provide explicit support for discovering routing tree topology. 92 There are several viable solutions for constructing a tree, 93 depending on network conditions. The optimality of a tree may 94 depend on a variety of factors, such as the need for load balancing 95 and the need to minimize the tree depth used for collecting 96 feedback information. 98 The TREE building block specifies a distributed procedure for 99 automatically constructing a tree that is loop-free and as 100 efficient as possible, given the information available. It 101 provides a unified solution for tree construction in the presence 102 of different multicast service models and routing protocols. In 103 particular, it specifies a single procedure which may be used with 104 various techniques for repair head discovery and distance 105 measurements, several of which are specified within this document. 106 The difference in these techniques primarily affects the optimality 107 of the tree. 109 2. Terminology 111 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 112 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 113 this document are to be interpreted as described in RFC 2119. 115 In addition, the following terms are applied in this document as 116 well as the TRACK BB document [RFCxxxx]. 118 Session 120 A session is used to distribute data over a multicast address. A 121 Session Tree is used to provide reliability and feedback 122 services for a session. 124 Session Identifier 126 A fixed-size number, chosen either by the application that 127 creates the session or by the transport. Senders and receivers 128 use the session Identifier to distinguish sessions. 130 Repair Head (RH) 132 A node within the tree which receives and retransmits data, and 133 aggregates and forwards control information toward the sender. 134 The sender operates as the root repair head in any session tree. 135 An RH that has accepted children for a session is called a 136 parent. 138 Session Tree (ST) 140 The session tree is a tree spanning all receivers of a multicast 141 session. It is rooted at the sender, consisting of zero of more 142 repair heads as interior nodes, and zero or more receivers as 143 leaf nodes. 145 Parent 147 A parent is an RH or receiver's predecessor in the ST on the 148 path toward the sender. Every RH or receiver on the tree except 149 the sender itself has a parent. Each parent communicates with 150 its children using either an assigned multicast address or 151 through unicast. 153 Children 155 The set of receivers and RHs for which an RH or the sender is 156 providing repair and feedback services. 158 3. TREE BB Rationale 160 In order to accommodate various multicast deployments, this 161 document divides the tree building process into the following major 162 components: 164 A. Several techniques for discovering neighboring repair heads: 165 static, expanding ring search, and mesh. Discovering 166 neighboring repair heads is a necessary condition for getting 167 connected, so each node in the session must implement at least 168 one of the above techniques. 170 B. Several algorithms for selecting neighboring repair heads: the 171 measurement and use of neighbor distance and sender distance 172 are described. These repair head selection algorithms help 173 produce a good tree. 175 C. A single distributed procedure for construction and 176 maintenance of loop-free session Trees. 178 4. Functionality of TREE BB 180 4.1 Assumptions and Requirements 182 This TREE BB is designed based on the recommendations for tree 183 configuration (Section 4.5 of RFC 3048, as also shown below), along 184 with RFC 2357, RFC 2887 and RFC 3269. 186 It has been shown that the scalability of RM protocols can be 187 greatly enhanced by the insertion of some kind of retransmission 188 or feedback aggregation agents between the sender and receivers. 189 These agents are then used to form a tree with the sender at the 190 root, the receivers at the leaves of the tree, and the 191 aggregation/local repair nodes in the middle. The internal 192 nodes can either be dedicated software for this task, or they 193 may be receivers that are performing dual duty. 195 The effectiveness of these agents to assist in the delivery of 196 data is highly dependent upon how well the logical tree they use 197 to communicate matches the underlying routing topology. The 198 purpose of this building block would be to construct and manage 199 the logical tree connecting the agents. Ideally, this building 200 block would perform these functions in a manner that adapts to 201 changes in session membership, routing topology, and network 202 availability. 204 This TREE BB document describes how to build trees under the 205 following conditions: 207 a. The multicast group has only a single sender. 208 b. A single RH can serve multiple sessions. 209 c. Sessions can take advantage of a pre-deployed infrastructure 210 of RHs (ones that are not necessarily aware of a session 211 before the receivers), or recruit receivers to be RHs. 212 d. Generic Router Assist and Expanding Ring Search are not 213 required of the network infrastructure, but if available they 214 should be able to be utilized. 216 For tree configuration, the following are specifically required: 218 a. While the tree building process may take advantage of 219 information from the routing layer, the mechanisms described 220 are independent of the routing protocol(s) used by the 221 underlying multicast tree. 222 b. All trees constructed must be loop-free 223 c. These mechanisms must support late joiners and tree 224 optimization 226 4.2 Functional Overview 228 Session trees are spanning trees rooted at the sender. Session 229 trees can be used for forwarding control information (i.e. ACKs) 230 towards the root, or for forwarding data (i.e. repairs) towards the 231 leaf nodes. 233 Figure 1 illustrates overall procedures for tree configuration. 235 +--------------------+ 236 | 1. Session | 237 | Advertisement | 238 +--------------------+ 239 | 240 | Node receives tree-building parameters 241 V 242 +--------------------+ 243 | 2. Measurements |<-------------------------| 244 | to the sender | | 245 | (optional) | | 246 +--------------------+ | 247 | | 248 | | 249 V | 250 +--------------------+ | 251 | 3. Neighbor | | 252 | Discovery | | 253 +--------------------+ | 254 | | 255 | | 256 V | 257 +--------------------+ | 258 | 4. Repair Head | | 259 | Selection | | 260 +--------------------+ | 261 | | 262 | Node picks best neighbor | 263 V | 264 +--------------------+ | 265 | 5. Binding to |--------------------------- 266 | Repair Head | 6. Optimization (optional) 267 | | and fault recovery 268 +--------------------+ 270 Figure 1. Generic procedures for tree configuration 272 Session trees are constructed per sender; each node wishing to join 273 the tree discovers its neighboring RHs and then selects its best 274 parent based on locally available information, such as the relative 275 sender distances and neighbor distances. This document specifies 276 several techniques for measuring distances. 278 It is important to note that RHs may be actual receivers (e.g. 279 receivers willing and able to also function as RHs) or pre-deployed 280 "specialized" servers that are signaled to join the tree by 281 receivers. We use the term repair head to refer to either a 282 receiver or server that is participating as part of the logical 283 tree formation. 285 Tree construction, regardless of RH discovery and selection 286 algorithm, proceeds generically as follows. 288 4.2.1 Session Announcement 290 Receivers of a session use standard out-of-band mechanisms for 291 discovery of a session's existence (e.g. session advertisement in 292 RFC 2974). In this way, a receiver discovers the multicast group 293 address, the sender's address, and other information necessary for 294 logical tree construction. 296 Sessions may be announced in two parts, the first part containing 297 generic information about the session, such as the multicast 298 address, and the second part, announced on the multicast address, 299 containing additional information. 301 4.2.2 Measurements to the sender (optional) 303 All RHs and receivers that know about the session optionally 304 determine their distance to the sender. 306 4.2.3 Neighbor Discovery 308 Meanwhile, each receiver discovers nearby RHs (candidate parents) 309 for the session using the neighbor discovery algorithm(s). 311 4.2.4 Repair Head Selection 313 Once a receiver (or RH needing to join the tree) discovers a nearby 314 RH, it obtains the RH's distance to the sender as well as the RH's 315 distance to the receiver and other suitability values, if available. 316 After discovery is complete, the best RH is selected. 318 4.2.5 Binding to Repair Head 320 The receiver or RH then binds to the chosen RH. If a bind is 321 unsuccessful, the receiver or RH retries with another nearby RH, or 322 starts the discovery process all over again. Once an RH receives 323 a bind from a child, that RH then joins the tree if it has not 324 already, discovering an RH of its own, possibly using a different 325 method than leaf receivers. 327 4.2.6 Optimization (optional) and Fault Recovery 329 During a session, a receiver or RH may change to a different RH for 330 a number of reasons described below, including fault tolerance. 331 The session Tree is maintained and optimized over time. 333 5. BB Details: Session Announcement 335 The first step in the tree-building process is for a node to be 336 informed of the session's existence. This can be done using some 337 out-of-band method, such as Session Advertisement [RFC2974], URL, 338 e-mail, etc. 340 RHs do not necessarily receive these advertisements. If an RH is 341 not a receiver, it obtains the advertisement information once it is 342 contacted by a receiver. 344 The advertisement includes the multicast address being used, the 345 sender's address, the session Identifier, any specific port numbers 346 to be used, and any global information useful for tree construction. 348 The advertisement may also contain information about one or more 349 repair head Discovery options (such as Static, ERS, and Mesh) that 350 can possibly be used by receivers in the session. 352 6. BB Details: Repair Head Discovery and Selection 354 Discovery is the process by which a node determines a suitable 355 repair head. During the discovery process, suitable neighbors are 356 found, sender distances are optionally exchanged, and the best RH 357 is selected. 359 6.1 Repair Head Discovery Algorithms 361 This draft describes three algorithms for discovering RHs: Static, 362 Expanding Ring Search (ERS), and Mesh. 364 Multiple algorithms may be used within a single session. For 365 example, RHs may use the Mesh algorithm, while the receivers use 366 static configuration to discover the RHs; alternatively, some 367 receivers may use static configuration while other receivers depend 368 on ERS (in an intranet where ERS is available). Each receiver may 369 pre-configure which algorithm to use before it starts. 371 The transport protocols request the following information from this 372 BB using the getRHs interface. 374 Repair Heads: 376 1. parentAddress: the address and port of the parent node to 377 which the node should connect 378 2. UDPListenPort: the UDP port number on which the node will 379 listen for its children's control messages 380 3. RepairAddr: the multicast address, UDP port, and TTL on 381 which this node sends control messages to its 382 children. 384 Receivers: 386 1. parentAddress. 388 Senders: 390 1. UDPListenPort 392 2. RepairAddr 394 After the above information is obtained from tree-configuration, 395 the transport protocol may perform the necessary Bind operations 396 for participating in the session tree. 398 Tree configuration may rely on a functional entity, named Tree 399 Configurator (TC), which is pre-configured by sender for tree 400 configuration. TC may be simply implemented by a program and thus 401 installed at sender or any other host. It is not necessarily 402 specialized infrastructure. 404 6.1.1 Static 406 In the static scheme, TC is used to govern the tree building based 407 on its own (session-specific) tree configuration and RH(s) 408 selection rules for the new joiners. 410 If a TC is used for tree building, its address and port are 411 included with the session advertisement. Receivers and RHs will 412 realize there is a TC for the session via session Announcement, and 413 they can contact with the TC to get a list of candidate RHs by 414 sending a unicast Query message. 416 In response to a Query message, TC replies with an advertisement 417 message that contains a list of candidate RHs available to the new 418 joiner. The rule of determining such candidate RHs may depend on 419 the pre-configured mechanism taken by TC. For example, TC may 420 determine the candidate RH list for a node among the possible RHs 421 (it contains at that time) by considering which RHs are in the same 422 network domain with the node (i.e., via comparing their network 423 prefix), or by considering the load balancing for the tree topology 424 it has configured until then. For this purpose, TC maintains a pool 425 of active RHs for the session. The list of candidate RHs carried by 426 Advertise message is ordered in decreasing levels of preference, in 427 which a lower number represents a higher preference. 429 When a receiver node receives the responding advertisement message 430 from TC, the node MAY proceed to try to bind to a candidate RH 431 following the given order by sending a BindRequestmessage, and then 432 waits for the responding message such as BindConfirm or BindReject 433 from TC. These binding steps will be done according to the TRACK 434 mechanism, as described in the TRACK BB. 436 In the static algorithm, RH discovery with a TC proceeds as 437 follows: 439 1. The node joins the multicast session and learns of the 440 location of TC (from the session announcement). 442 2. The node optionally discovers its distance from the sender. 443 Any metric described in Section 4.2 may be used. 445 3. The node sends a Query message to the TC for a parent. The 446 request includes (optionally) the node's distance to the 447 sender and whether the node functions as an RH or not. 449 4. The TC chooses one or more candidate parents (RHs) for the 450 node from the active RHs by its own tree configuration rule. 451 The selection of candidate parents may be done by comparing 452 the network prefix or by referring to any other information 453 such as the number of currently attached children, etc. 455 5. The TC responds to the Query message with an Advertise 456 message, which include the candidate parent list. In the 457 list, each entry contains the corresponding IP address and 458 port of an RH. 460 All the entries in the list need to be arranged in the 461 decreasing order of preference levels. 463 In the rejection case, the Advertise message does not include 464 any candidate parent. In this case, the node may resort to 465 the other mechanism such as ERS and Mesh. 467 In the success case, the node will be enrolled as an active 468 RH by the TC, if it functions as an RH in the session. Each 469 active RH (functioning as a parent for the session Tree) 470 sends the TC the periodic Query messages with a flag 471 indicating that it is active over a specific time interval. 472 Based on the Query messages, the TC updates a pool of active 473 RHs in the session. In response to the Query message, the TC 474 sends an Advertise with a flag simply indicating that the 475 Query message is received. 477 6. After receiving a successful Advertise message from the TC, 478 the node will try to connect to its parent by sending 479 BindRequest messages based on the candidate parent list. 481 Depending on implementation, one or more TCs may be locally 482 deployed, in which each receiver can locally access some configured 483 list of the prospective RHs. 485 6.1.2 ERS 487 ERS is used only in the network environments where IP multicast 488 transmissions are allowed by receivers and RHs. 490 In ERS algorithm, the RH discovery with a TC proceeds as follows: 492 1. The nodes first look for Neighbors using a multicast Query 493 message. The initial TTL value in the Query message, 494 TTLNeighborInit, is specified in the session announcement 495 and may be as large as the session TTL (TTLSession). 497 An RH that is able to handle additional children responds to 498 a Query message by multicasting an Advertise message. 500 If the RH is not yet a parent, the TTL used in this response 501 is the same TTL used in the Query message. If the RH is a 502 parent, the TTL used is the greater of the Query TTL and the 503 parent's current Advertise TTL. 505 2. The node listens for Advertise messages after sending the 506 Query message. If one or more Advertise messages are 507 received during a SolicitPeriod, the best RH among them is 508 selected. 510 3. If no Advertise messages are received, the node sends 511 another multicast Query message with a TTL that is 512 incremented by TTLIncrement. The process of sending the 513 multicast Query message with an increasing TTL value 514 continues until a response is received. 516 The TTL value is limited by a value, TTLMax, also specified 517 in the session announcement. TTLMax defaults to the value 518 of TTLSession. 520 If the TTL value required to reach the soliciting node is 521 greater than the TTL used to reach the RH, an Advertise 522 message may not reach the node. However, if future Query 523 messages have increased TTL values, the TTL may eventually 524 be large enough for the Advertise message to reach the node. 525 However, it is possible that the node will not locate any 526 RHs using Expanding Ring Search. It is advisable that a 527 backup method, such as static, be available. 529 4. RHs need to suppress sending Advertise messages in response 530 to Query messages if one was sent with at least the Query's 531 TTL within the last SolicitPeriod. 533 After multicasting a Query message, a node waits for an 534 interval, BetweenQuery, before sending another Query message. 535 Nodes will suppress sending Query messages for BetweenQuery 536 seconds when they first start in order to collect 537 information from Advertise messages already solicited by 538 other nodes. 540 5. Getting a successful Advertise message via ERS, the node 541 will try to connect to the parent by sending BindRequest 542 messages. 544 The following variables are used in the Expanding Ring Search 545 algorithm. 547 - TTLNeighborInit: This is the initial TTL value to be used by the 548 ERS if no other TTL value is specified by the algorithm. 550 - TTLIncrement: This is the periodic increment for the TTL used in 551 ERS. 553 - TTLMax: This is a configured maximum TTL value to be used by 554 either Query or Advertise messages. 556 - TTLSession: This is the session TTL value for the multicast 557 session. 559 - SolicitPeriod: Each receiver MUST not send more than one QUERY 560 message per SolicitPeriod. When a RH responds to QUERY messages, 561 it also suppresses its ADVERTISE message if one has been sent 562 less than SolicitPeriod ago. This parameter is used to control 563 the amount of control traffic during tree construction if ERS is 564 used. 566 - BetweenQuery: This is the time interval a node waits before 567 sending successive Query messages. 569 - MaxBindAttempts: This variable is an integer used to control how 570 many times a receiver tries to bind to a RH before giving up and 571 try another one. 573 - BindPeriod: In order to prevent loops, sometimes a RH may reject 574 a BindRequest (for example, when the RH is not on the tree yet 575 and has a BindRequest outstanding itself) from a receiver. In 576 this case, if the receiver needs to retry binding to the same RH 577 again (perhaps because the receiver does not discover any 578 alternative RHs), then it waits for BindPeriod seconds. 580 6.1.3 Mesh 582 The mesh approach relies on a set of RHs already deployed as 583 infrastructure servers. These RHs are on-line, but are not 584 necessarily aware of any particular session unless informed by the 585 following mechanisms. 587 RHs in the mesh are configured to know who their neighbor RHs are, 588 and exchange reachability information with their neighbors in a way 589 analogous to routers in a network. The actually protocol used by 590 RHs to exchange such reachability information is outside the scope 591 of this BB. 593 Instead, this BB specifies the following properties that the mesh 594 of RHs MUST satisfy: 596 a) Each RH knows a subset of RHs in the mesh as its immediate 597 neighbors. 599 b) Each RH has a "forwarding table", such that given any other 600 (destination) RH in the mesh, the forwarding table gives a 601 "next-hop" RH that can be used to reach the destination RH, 602 plus the distance to the destination RH from the local RH. 604 c) A given RH in the mesh can "broadcast" information to all 605 other RHs in the mesh (in the sense of having a means of 606 sending the same information to all other RHs, but not 607 necessarily simultaneously). 609 d) All potential sender and receivers of a multicast session 610 can discover a "neighboring" RH in the mesh, using the 611 neighbor discovery mechanisms described in Section 4.1. 613 The reason for running a routing-like algorithm to maintain the 614 forwarding tables in each RH is to provide fault tolerance when 615 some RHs in the mesh fail. When that happens, the remaining RHs 616 exchange information with each other to update the forwarding 617 tables. In the steady state, the mesh of RHs still needs to satisfy 618 the above four properties. 620 In the simplest form, each RH in the mesh has a forwarding table 621 that contains all other RHs in the mesh. This is called a fully- 622 connected mesh. 624 As mentioned earlier, the mesh scheme assumes that there is a pre- 625 deployed infrastructure of RH servers. That is, the RH-RH bindings 626 and sender-RH (Sender's RHs) will be performed internally by the 627 provider's own policy. The only thing done by sender is to inform 628 its RH's that a session starts. The relationships between sender 629 and its RH's (i.e., sender-RH bindings) MUST also be pre-configured. 631 For example, the internal bindings between sender and RHs MAY be 632 done as follows: 634 1. The sender locates a neighbor RH in the mesh by a pre- 635 configured mechanism. This RH is referred to as the sender's 636 RH. 638 2. The sender sends the multicast session id, address and port 639 (all these can be set as a abbreviated session announcement 640 message) to the sender's RH. 642 3. The sender's RH in turn "broadcasts" the session information 643 to all RHs in the mesh; since RHs can support multiple 644 sessions simultaneously, they keep the information about each 645 session in an entry in a session table. 647 4. After the sender-RH bindings, sender multicasts its session 648 announcement to the multicast receivers. Then, the sender's RH 649 binds to the sender by sending a BindRequest message. 651 During the internal processing of sender-RH binding described up to 652 now, no Query and Advertise messages are used. 654 When a session starts, the bindings between RH and receivers will 655 be done. The tree binding of RH-receiver is done with the Tree 656 Configurator (TC), which was used in the Static algorithm. The main 657 difference between Static algorithm with TC and Mesh algorithm with 658 TC is that the active RHs are considered as candidate RHs in the 659 Static scheme, while the pre-deployed RHs are considered as 660 candidates in the Mesh scheme. That is, in the Mesh scheme, the TC 661 is required to already get the information on the locations of the 662 pre-deployed RHs. 664 Then the tree buildings is done as follows: 666 1. When a session starts, a receiver sends a Query message to 667 the TC. The receiver may optionally discover its distance from 668 the sender. Any metric described in Section 4.2 may be used. 670 2. The TC chooses one or more candidate parents RHs for the 671 receiver from the pre-deployed RHs by its own tree 672 configuration rule, as described in Section 4.1.1. 674 3. TC responds to the Query message with an Advertise message, 675 which includes the candidate parent list. In the list, each 676 entry contains the corresponding IP address and port of the 677 parent. 679 4. Receiving a successful Advertise message from the TC, the 680 node will try to connect to its parent by sending BindRequest 681 messages based on the candidate parent list. 683 Once a receiver is connected to a parent RH, the RH-RH bindings 684 will also be done internally by the pre-configured provider's 685 policy. For example, each RH in the mesh tries to bind to its 686 "next-hop" RH. If the "next-hop" RH is not reachable for some 687 reason, an RH may also try to bind to any neighbor RH as a back-up 688 alternative. These procedures will be devised to ensure that the 689 loop freedom is guaranteed. 691 6.2 Distance Measurement 693 Different techniques can be used to determine distances between 694 nodes in a session. The distances of interest are: 696 Sender distance - distance from a RH to sender 698 Neighbor distance - distance from a receiver to a neighboring RH 700 These distances can be used in selecting a repair head if several 701 are discovered. 703 These techniques quantify distance differently. Each specific way 704 of quantifying distance is called a metric. Different Metrics are 705 not necessarily comparable. For example, if distance between A and 706 B is X using metric m1, and distance between A and C is Y using 707 metric m2, then X > Y does not necessarily imply B is farther from 708 A than C. 710 Only distances of the same metric will be compared and ranked. 711 Therefore, a receiver will only rank two RHs based on their 712 respective sender distance if those distances are based on the same 713 metric. 715 On the other hand, it is not necessary for all receivers to use the 716 same metric to select their neighboring RH to connect to. Suppose 717 the receivers use neighbor distance as a selection criterion. One 718 receiver may determine neighbor distances to RHs based on hop count, 719 whereas another receiver may determine neighbor distances to its 720 neighboring RHs based on delay. 722 6.2.1 TTL Hop-Count 724 If this metric is used, a node periodically sends a Beacon message 725 on the session's multicast address. The Beacon message includes 726 the original time-to-live value set by the node. The distance to 727 the node is then calculated as 729 Beacon's original TTL - Beacon's current TTL 731 One node is closer than another if its distance is a lower number. 732 Note that the TTL value may not be available in some implementation 733 environments. 735 6.2.2 Number of Levels 737 One metric a receiver can use for RH selection is the number of 738 levels the RH is from the sender. For example, given two RHs in 739 close proximity to a receiver, if one RH is n levels from the 740 sender and the other is m levels, where m