idnits 2.17.1 draft-boudani-mpls-multicast-tree-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Found some kind of copyright notice around line 534 but it does not match any copyright boilerplate known by this tool. Expected boilerplate is as follows today (2024-04-19) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** 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 -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 10 longer pages, the longest (page 1) being 63 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 11 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. (A line matching the expected section header was found, but with an unexpected indentation: ' 1 Introduction' ) ** The document seems to lack a Security Considerations section. ** 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.) ** There are 40 instances of too long lines in the document, the longest one being 1 character in excess of 72. ** The abstract seems to contain references ([2], [3], [4], [5], [6], [4,5], [7], [8], [9], [10], [11], [1]), 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 == The "Author's Address" (or "Authors' Addresses") section title is misspelled. -- 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.) -- The document date (October 2004) is 7126 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? '1' on line 476 looks like a reference -- Missing reference section? '2' on line 478 looks like a reference -- Missing reference section? '3' on line 482 looks like a reference -- Missing reference section? '4' on line 485 looks like a reference -- Missing reference section? '5' on line 488 looks like a reference -- Missing reference section? '9' on line 500 looks like a reference -- Missing reference section? '6' on line 491 looks like a reference -- Missing reference section? '7' on line 494 looks like a reference -- Missing reference section? '10' on line 502 looks like a reference -- Missing reference section? '8' on line 497 looks like a reference -- Missing reference section? '11' on line 504 looks like a reference Summary: 8 errors (**), 0 flaws (~~), 5 warnings (==), 13 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET DRAFT Ali Boudani, Bernard Cousin 3 Expires: April 2005 Jean-Marie Bonnin 4 IRISA-France 5 October 2004 7 An Effective Solution for Multicast Scalability: 8 The MPLS Multicast Tree (MMT) 9 11 Status of this Memo 13 By submitting this Internet-Draft, I certify that any applicable 14 patent or other IPR claims of which I am aware have been disclosed, 15 or will be disclosed, and any of which I become aware will be 16 disclosed, in accordance with RFC 3668." 18 Internet Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and working groups. Note that other 20 groups may also distribute working documents as Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six 23 months and may be updated, replaced, or obsolete by other documents 24 at anytime. It is inappropriate to use Internet Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 Abstract 35 A multicast router should keep forwarding state for every multicast 36 tree passing through it. The number of forwarding states grows with 37 the number of groups. In this paper, we present a new approach, the 38 MPLS multicast Tree (MMT), which utilizes MPLS LSPs between 39 multicast tree branching node routers in order to reduce forwarding 40 states and enhance scalability. In our approach only routers that 41 are acting as multicast tree branching node routers for a group 42 need to keep forwarding state for that group. All other non- 43 branching node routers simply forward data packets by traffic 44 engineered unicast routing using MPLS LSPs. We can deduce that our 45 approach can be largely deployed because it uses for multicast 46 traffic the same unicast MPLS forwarding scheme. We will briefly 47 discuss the multicast scalability problem, related works and 48 different techniques for forwarding state reduction. We discuss also 49 the advantages of our approach, and conclude that it is feasible and 50 promising. Finally, we analytically evaluate our approach. 52 1 Introduction 54 Multicast has become increasingly important with the emergence of 55 network-based applications such as IP telephony, video conferencing, 56 distributed interactive simulation (DIS) and software upgrading. 57 Using the multicast services, a single transmission is needed for 58 sending a packet to n destinations, while n independent 59 transmissions would be required using the unicast services. A 60 multicast routing protocol should be simple to implement, scalable, 61 robust, use minimal network overhead, consume minimal memory 62 resources, and inter-operate with other multicast routing protocols. 63 Multicast suffers from scalability problem with the number of 64 concurrently active multicast groups because it requires a router to 65 keep forwarding state for every multicast tree passing through it 66 and the number of forwarding states grows with the number of groups. 67 Scalability can be evaluated not only in terms of the overhead 68 growth in the presence of a large number of groups but also by the 69 number of participants per group and by groups for which the set of 70 participants changes often over time. Overhead can be measured in 71 terms of memory resources (in routers) as they relate to routing 72 states maintained per group and can be measured also by bandwidth 73 resources in terms of control or signaling messages per group and 74 also by processing power. 75 Recently, significant research effort has focused on the multicast 76 scalability problem. Some schemes attempt to reduce forwarding state 77 by tunneling [1] or by forwarding state aggregation [2]. Both these 78 works attempt to aggregate routing state after this has been 79 allocated to groups. Other architectures aim to eliminate 80 forwarding states at routers either completely by explicitly 81 encoding the list of destinations in the data packets, instead of 82 using a multicast address [3] or partially by using branching node 83 routers in the multicast tree [4,5]. 84 The Xcast proposal [3], used for small groups, eliminates the need 85 for forwarding states. The source encodes the list of destinations 86 in the Xcast header, and then sends the packet to a router. Each 87 router along the way parses the header, partitions the destinations 88 based on each destination's next hop, and forwards a packet with an 89 appropriate Xcast header to each of the next hops. 90 In SEM [4], we proposed that the source uses unicast encoding for 91 multicast packets and sends them to its next hop branching node 92 routers. Each branching node router acts as a source and packets 93 travel from a branching node router to another. A special mechanism 94 was introduced to inform each branching node router about its next 95 hop branching node routers for a group. 96 REUNITE [5], uses recursive unicast trees to implement multicast 97 service. REUNITE does not use class D IP addresses. Instead, both 98 group identification and data forwarding are based on unicast IP 99 addresses. Only branching node routers for a group need to keep 100 multicast forwarding state. All other non-branching node routers 101 simply forward data packets by unicast routing. 102 We think that using the branching node routers to forward multicast 103 data packets in unicast mode is very efficient in order to reduce 104 forwarding state and thus enhance scalability. The main problem is 105 how to ensure that a branching node router has a complete knowledge 106 about its next hop branching node routers. And another issue is how 107 can we reduce the effect of encapsulated multicast packets in 108 unicast packets. We think that a network information manager 109 system (NIMS) in each domain can be used to resolve the first 110 problem while the multi protocol label switching (MPLS) [9] 111 presents an efficient solution for the second problem. 112 A framework for MPLS multicast traffic engineering that explain IP 113 multicast deployment in MPLS environment was proposed by Ooms et 114 al [6]. Another studies about MPLS and multicast proposed by 115 Farinacci et al. [7] explain how to use PIM to distribute MPLS 116 labels for multicast routes. Other expired Internet drafts studied 117 the same subject [10]. 118 The latest interesting proposal is aggregated multicast [8]. The key 119 idea of aggregated mulicast is that, instead of constructing a tree 120 for each individual multicast session in the core network, one can 121 have multiple multicast sessions share a single aggregated tree to 122 reduce multicast state and, correspondingly, tree maintenance 123 overhead at network core. In this proposal there was two 124 requirements: (1) original group addresses of data packets must be 125 preserved somewhere and can be recovered by exit nodes to determine 126 how to further forward these packets;(2) some kind of identification 127 for the aggregated tree which the group is using must be carried and 128 transit nodes must forward packets based on that. Instead of using 129 IP encapsulation as in SEM, which of course, adds complexity and 130 processing overhead, a potentially much better possibility is to use 131 MPLS [9]. To handle aggregated tree management and matching between 132 multicast groups and aggregated trees, a centralized management 133 entity called tree manager is introduced. In group to aggregated 134 tree matching, complication arises when there is no perfect match or 135 no existing aggregated tree covers a group. There was a disadvantage 136 in leaky matching because certain bandwidth should be wasted to 137 deliver data to nodes that are not involved for the group. In our 138 proposal we intend to resolve also this problem of leaky matching. 139 Using MPLS with multicast has many benefits not only for reducing 140 multicast forwarding states but also for traffic engineering and 141 QoS issues. In this paper, we only focus on the scalability 142 problem. We propose a novel approach to reduce multicast state, the 143 MPLS multicast Tree. This approach uses MPLS LSPs between multicast 144 tree branching node routers in order to reduce forwarding states 145 and enhance scalability. The main difference with previous 146 approaches is that we use only multicast states for branching 147 routers in the multicast tree. Other routers between two branching 148 nodes don't have multicast states. Unicast is used between two 149 branching routers. This way the total number of multicast forwarding 150 states may be significantly reduced. By using MPLS LSPs between 151 branching routers, memory resource is reduced also and no need for 152 encapsulation techniques. The MPLS forwarding process conserve the 153 router resources also. In this paper, we examine several design and 154 implementation issues of our scheme and present an evaluation for 155 our protocol. 156 The remainder of this paper is organized as follow. In section 2 the 157 concept of MPLS multicast aggregation is described and some 158 implementation related issues are discussed. Section 3 contains the 159 approach analysis and an evaluation for its forwarding state and 160 messaging overhead. Section 4 is a summary followed by a list of 161 references. 163 2 Observation and proposal: MPLS Multicast Tree 165 The key idea of MPLS multicast tree is that, instead of having 166 multicast forwarding states in all routers in a constructed tree for 167 each individual multicast session in the core network (backbone), 168 one can have only multicast forwarding states in branching node 169 routers of the tree. By using the branching node routers, multicast 170 forwarding states are reduced, correspondingly, the tree maintenance 171 overhead at network core. 172 The MPLS multicast tree is targeted basically for intra-domain 173 multicast, but it is not limited for that only since it is based on 174 MPLS, and can be used also for inter-domain multicast. 176 2.1 Observation 178 In conventional multicast, routers on the multicast tree located 179 between the source and a group member should maintain multicast 180 states for the group. 181 Let's consider the network illustrated in fig.1 (single multicast 182 session with only one source and one group). Suppose that there are 183 group members at router R5, then routers R1, R2 R3, R4 should all 184 have multicast state for the group G even if they don't have 185 directly connected members. 186 S 187 | 188 R1 189 | 190 R2 191 | 192 R3 193 | 194 R4 195 / \ 196 / \ 197 R6 R5 199 Fig.1 : Multicast tree (one source, one group) 201 Let's take the same network but with multiple multicast sessions 202 (one single source and two groups). We suppose that there are 203 members for group G1 at R5 and members for group G2 at R6. Routers 204 R1, R2, R3, R4 should maintain states for groups G1 and G2 even if 205 they don't have directly connected group members. When the number of 206 group increase in time multicast states became harder and harder. 207 Fig.2 represents a multicast topology (constructed tree) resulting 208 from a traceroute experiments [5]. In the entire multicast tree 209 there are 8 branching node routers out of 97 routers. 211 Fig.2: Traceroutre experiment from a source to 15 other sites 212 One can conclude that maintaining multicast forwarding states in non 213 branching node routers is a waste of resources and that only 214 branching node routers for multicast groups should maintain 215 multicast forwarding states. In conventional multicast a router can 216 discover that it is a branching node router for a group but it 217 doesn't have any idea about its next hop branching node routers for 218 that group. 219 A second observation is that even when 2 multicast trees share 220 multiple links, multicast forwarding states on routers for the 221 shared links will not be aware of that and there is no possibility 222 for aggregation. 223 In REUNITE there was a completely unicast approach for delivering 224 multicast packets. However, many of the LAN and WAN technologies 225 have native support for multicast. Sending individual unicast 226 messages to each of the receivers in a multicast-capable subnet as 227 ethernet is very inefficient. Multicast packets should always 228 contain the IP multicast header. 229 In SEM we have introduced a tunneling process which can be 230 implemented to conventional multicast too but messages between 231 branching node routers in order to construct tunnels can be 232 considered as expensive overheads. Our proposal will take all these 233 observations into account. 234 Overheads are the header processing time that take a router to 235 determine the routing and also the size of multicast routing table. 236 These two overheads are related. Our goal is to minimize the 237 multicast overheads in each router. In our proposal, only branching 238 node routers will contain the multicast routing table. All other 239 routers do not need the routing states. 240 In aggregated multicast[8], the solution was to have a single shared 241 aggregated multicast tree but as mentioned in discussions 242 complication arises when there is no perfect match or no existing 243 tree covers a group. The disadvantage here is that certain bandwidth 244 is wasted to deliver data to nodes that are not involved for the 245 group. Bandwidth can crucial factors for provisioning QoS in 246 multicast networks and even for best effort Internet. 248 2.2 proposal 250 In order to inform a branching node router about its next hop 251 branching node routers for a group, each domain should contain a 252 network information manager system (NIMS) for each group, charged to 253 collect join messages from all group members in that domain. After 254 collecting all join and prune messages, the NIMS should compute the 255 multicast tree for that group in the domain. The computation for a 256 group means discovering all branching node routers and the next hop 257 branching node routers for each group. 258 We should note that scalable multicast protocols like PIM-SM 259 (shared tree) and CBT use a core router similar to the one used in 260 our approach. 261 In our approach we are suggesting that the NIMS should collect join 262 messages from all group members and have a complete overview about 263 the multicast network. 265 The NIMS send then messages to all branching node routers to inform 266 them about their next hop branching node routers. On receiving this 267 message, a branching node router creates a multicast forwarding 268 state for the multicast session. 269 Once branching node routers and their next hop are identified, 270 packets will be send from a branching node router to another until 271 achieving their target. 272 Tunneling between branching node routers was studied in [1], [4], 273 and [5] but was judged very expensive and very complicated since 274 multicast packets should be encapsulated as unicast packets and 275 send after that over the tunnel. 276 Based on observations, we propose a new approach, the MPLS multicast 277 tree, which utilizes MPLS dynamically established LSPs between 278 multicast tree branching node routers in order to reduce forwarding 279 states and enhance scalability. 280 When a multicast packet arrives to the ingress router of a MPLS 281 domain, the packet is analyzed according to its multicast IP header. 282 The router should determine who are the next hop branching node 283 routers for that packet. Based on this information, multiple copies 284 of the packets are generated and a MPLS label is pushed to the 285 multicast packet corresponding to each next branching node router. 286 Then a labeled multicast packet will not be different from a labeled 287 unicast packet. 288 When arriving to a next hop branching node router, the label is 289 pulled and again the same process is repeated. This process should 290 be repeated until the packet arrives to its destination. 291 When arriving to a LAN, the packet unlabeled can be delivered by 292 conventional multicast protocols according to IGMP informations. 293 Note that labeled multicast packets will be examined at each 294 branching router and that is why a multicast packet on non-branching 295 router will be treated as a MPLS labeled unicast packet. So no extra 296 charges are needed for multicast packets since the MPLS tables 297 already exist in routers. The examination of a multicast packets in 298 intermediate routers on the tree is considered as a disadvantage of 299 this approach but we leave this issue for further studies. 300 When a branching node router receive the message from the NIMS it 301 should calculate the label corresponding to the next hop router and 302 it should add a label with an interface to the (S, G) entry in the 303 branching node router. In this way we can ensure that there is no 304 extra overhead. 306 2.3 Protocol evaluation 308 The efficiency of the MMT can be evaluated in terms of state 309 information requirement, tree cost, data processing efficiency, and 310 control overhead. In this analysis, we will focus on the state 311 information requirement, and control overhead of the MMT. 312 The state information requirement can be measured using the average 313 multicast forwarding table size. State information analysis includes 314 also the MPLS overhead. The control overhead can be measured using 315 the total number of control packets sent to all the links that are 316 needed to maintain the protocol states. 318 2.4 MPLS overhead 320 In MMT, MPLS as unicast traffic engineering tool will be used also 321 as multicast traffic engineering tool. IN MMT, multicast will take 322 all the benefits of MPLS, that already been used for unicast, and 323 will introduce no extra overheads. A multicast packet will be 324 treated like a unicast packet and that is an advantage. 326 2.5 Control overhead 328 The control overhead of MMT can be measured in terms of average 329 number of control messages sent per link or the total percentage of 330 bandwidth spent on control traffic. 332 In PIM-SSM, each distribution tree needs to be refreshed 333 periodically and that to rapidly detect a router that belong to a 334 tree, goes down. In our approach, we don't need the join and prune 335 messages periodically. When a router goes down, the unicast tables 336 will detect it and thus no extra information is needed. 338 3 related issues 340 3.1 The tree manager 342 One can argue that using NIMS and sending join and leaves messages 343 to it are weak points in our approach. But we have to mention that 344 the most scalable approaches in conventional multicast like PIM-SM 345 and CBT use similar techniques. In PIM-SM and CBT, a router should 346 act as a Rendez-Vous point that collect join messages for each group 347 and these join messages will be refreshed periodically. But in our 348 approach, messages will not be sent periodically. Also a few 349 messages will be sent from the NIMS to branching routers, thus there 350 is no remarkable overhead. We think that our approach has an 351 advantage over these conventional multicast protocols since we don't 352 force multicast packets to be sent all the way to the Rendez-Vous 353 point and next to receivers. By contrast packets follow always the 354 constraints shortest path. Besides there is no switching between 355 shared tree and source specific tree. 356 NIMS could be unique for each group like the case in CBT and PIM-SM. 357 We can also imagine that there is multiple NIMSs that can 358 communicate with each other to update informations about topology. 359 Finally, in OSPF networks the NIMS can easily collect informations. 361 3.2 MPLS issues 363 3.2.1 Multicast aggregation 365 In conventional multicast, it is not possible to aggregate multicast 366 IP addresses. Receivers can be located anywhere in the Internet, 367 there is no other alternative than having one entry by multicast IP 368 address in the multicast routing table. Some scheme tried to 369 aggregate by using leaky trees. 370 Since in MMT, we are using MPLS, aggregation of multicast IP 371 addresses can be transformed to label aggregations. There is no 372 wasted bandwidth to realize aggregation, the aggregation overhead is 373 zero. We have an advantage here that the traffic engineer will 374 control perfectly its network. 375 Multicast groups may share some links in their multicast trees and 376 aggregation introduce benefits. 378 3.2.2 Loop detection 380 In MMT, multicast loop detection for multicast traffic is the same 381 loop detection in unicast since packets will be send using MPLS 382 labels between branching node routers. 384 3.2.3 LSP constructions 386 One can say that LSP construction is very expensive if there is no 387 multicast traffic, but these LSPs are already constructed and used 388 by unicast traffic also and thus no extra LSP construction 389 overheads. There are no MPLS extra states for multicast traffic 390 needed. 392 3.2.4 Multicast LDP extensions 394 There are no modifications to LDP. Labels used for multicast packets 395 are the same used for unicast packets and that is the major 396 difference with all other MPLS multicast approaches. 397 We have just to be sure that at branching node routers, when a 398 packet arrive, the label is pulled up and the new labels 399 (corresponding to each next hop branching node router) are pushed 400 in. 402 3.2.5 Multicast load balancing 404 In MMT, multicast packets will be sent from a branching node to 405 another, but we are not obliged to follow the same path constructed 406 by conventional multicast protocols. By using different LSPs, load 407 balancing is ensured. 409 3.3 Using MMT for inter-domain multicast 411 Join messages in domains are sent to the NIMS. Each domain had its 412 own NIMS for the group. 413 To receive packets from sources belonging to other domains, the 414 NIMS, after calculating which border router will transmit the 415 packets, will sent a message to create forwarding state for the 416 group in that border router. Due to the creation of this forwarding 417 state, the border router will contact border routers in other 418 domains with a normal (S, G) join message. These border routers will 419 contact NIMS routers in their domains. 420 Other domains don't need to be implementing MMT. Once a packet 421 arrives in a border router for a particular domain, a label is 422 pushed down and sent to all receivers. 424 3.4 Other ideas (difference between multicast and unicast traffic) 426 In our approach, multicast packets will follow the same path as 427 unicast packets. One can say that multicast packets should follow 428 different paths from unicast packets, but this solution is too heavy 429 because encoding technique described in [11] will be used. There is 430 no meaning then to have the same labels for unicast and multicast 431 and there are extra forwarding states in the routers. 433 3.5 Switching between L2 and L3 in branching node router 435 One may say that switching between L2 and L3 in branching node 436 router eliminates the gain obtained by using the MPLS. This is true 437 if there is a lot of branching node routers in the multicast tree in 438 a domain. But, it is also true that it is better than having 439 multicast states in all routers. But as a solution for this problem. 440 We can imagine that every multicast session (S,G) is associated at 441 the ingress router of a domain to a label (this is the NIMS mission 442 to reserve labels for sessions). this label represents the group 443 only in the domain, so there is no need for label allocation. The 444 modified label distribution protocol can manage this lable 445 distribution. One may argue that we can not attribute and associate 446 labels to all multicast sessions since the multicast labels are 447 limited (20 bits). This is true, but the traffic engineer should 448 manage the demands and include the QoS and differtiated services to 449 serve the sessions in the way that more important sessions passes 450 first. This is very convenient with the Internet best-effort logic. 452 4 Conclusion 454 In this paper, we present a new approach, the MPLS multicast tree, 455 which utilizes MPLS LSPs between multicast tree branching node 456 routers in order to reduce forwarding states and enhance 457 scalability. In our approach only routers that are acting as 458 multicast tree branching node routers for a group need to keep 459 forwarding state for that group. All other non-branching node 460 routers simply forward data packets by traffic engineered unicast 461 routing using MPLS LSPs. In our approach, we do not need MPLS 462 multicast labels different from those used for unicast. 463 The MPLS labels used for unicast are used for multicast traffic 464 also. Of course the disadvantage is that multicast packets need 465 to be examined at the IP level in each branching node router on 466 the multicast tree. We leave this issue for further studies. 467 We briefly discussed the multicast scalability problem and related 468 works for forwarding state reduction. We discussed also the 469 advantages of our approach, and concluded that it is feasible and 470 promising. Finally, we analytically evaluate our approach and we 471 deduced that our approach could be largely deployed because it uses 472 for multicast the same unicast MPLS forwarding scheme. 474 References 476 [1] J. Tian et al., Forwarding state reduction for sparse mode multicast 477 Communication,Proceedings of IEEE INFOCOM, MArch 1998. 478 [2] P. Radoslavov et al., Exploiting the bandwidth-memory tradeoff in 479 multicast state aggregation, Technical report, USC Dept. of CS 480 Technical Report 99-697, july 1999. 482 [3] R. Boivie et al., Explicit Multicast (Xcast) Basic Specification, 483 Internet draft, 2000. 485 [4] A. Boudani et al., Simple Explicit Multicast(SEM), 486 Internet draft, 2001. 488 [5] I. Stoica, et al., "REUNITE: A recursive Unicast Approach to 489 Multicast", http://www.ieee-infocom.org/2000/papers/613.ps. 491 [6] D. Ooms et al., Framework for IP multicast in MPLS, Internet draft, 492 december 2000 494 [7] D. Farinacci et al., Using PIM to distribute MPLS labels for 495 multicast routes, Internet draft, november 2000 497 [8] A. Fei and al., Aggregated multicast: an approach to reduce 498 multicast state, UCLA CSD Technical Report #010012, June 2001 500 [9] Multiprotocol label switching architecture, RFC3031, January 2001. 502 [10] http://ardnoc41.canet2.net/mpls/drafts/index.html. 504 [11] E. Rosen et al., MPLS label stack encoding, RFC3032, January 2001. 506 Authors Addresses 508 Ali Boudani 509 IRISA/INRIA Rennes 510 Campus Universitaire de Beaulieu 511 Avenue du General Leclerc 35042 Rennes France 512 Phone : (33) 02 99 84 25 37 513 Fax : (33) 02 99 84 25 29 514 E-mail : aboudani@irisa.fr 516 Bernard Cousin 517 IRISA/INRIA Rennes 518 Campus Universitaire de Beaulieu 519 Avenue du General Leclerc 35042 Rennes France 520 Phone : (33) 02 99 84 73 33 521 Fax : (33) 02 99 84 71 71 522 E-mail : bcousin@irisa.fr 524 Jean Marie Bonnin 525 IRISA/INRIA Rennes 526 Campus Universitaire de Beaulieu 527 Avenue du General Leclerc 35042 Rennes France 528 Phone : (33) 02 99 12 70 07 529 Fax : (33) 02 99 12 70 30 530 E-mail : jm.bonnin@enst-bretagne.fr 532 Copyright Statement 534 Copyright (C) The Internet Society (2004). This document is subject 535 to the rights, licenses and restrictions contained in BCP 78, and 536 except as set forth therein, the authors retain all their rights." 538 "This document and the information contained herein are provided on an 539 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 540 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 541 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 542 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 543 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 544 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 546 Expiration Date: April 2005