C. Diot, B. Lyles, B. Levine, and H. Kassem, "Requirements for the definition of new IP-multicast services," IEEE Network, January/February 2000.  Home/Search   Document Not in Database   Summary   Related Articles   Check

....is bound to be difficult simply due to the large number of devices that need modification and the personnel needed to manage the service. Second, deployment of network layer multicast, especially at the interdomain level, has been observed to be a particularly hard problem for a variety of reasons[8], 9] Finally, problems such as instability of the overall infrastructure, routing peculiarities, political barriers, and hardware lifetimes further complicate the challenge of deployment. For multicast, challenges in assuring stability primarily stem from the fact that multicast protocols, ....

C. Diot, B. Lyles, B. Levine, and H. Kassem, "Requirements for the definition of new IP-multicast services," IEEE Network, January/February 2000.

....networks) The future of multicast is rooted in the continued development, evaluation, and standardization of new protocols. However, unlike current efforts, which are focused primarily on routing, future efforts are likely to include other issues such as address allocation, management, and billing[3]. The remainder of this paper is organized as follows. Section 2 describes the early evolution of multicast, in particular the development of intra domain multicast. The focus of Section 3 is on inter domain multicast, including the best current practices and several of the efforts to define the ....

....dynamic protocol like AAP MADCAP, or by using an modified, intra domain version of sdr. Root Addressed Multicast Architecture In response to the perceived complexity of MBGP PIM SM MSDP and BGMP, and to the need to address additional multicast related issues like security, billing, and management[3], some members of the multicast community are looking to make fundamental changes to the multicast model. One class of proposals that has received much attention recently is called the Root Addressed Multicast Architecture (RAMA) 30] The premise for RAMA style protocols is that most multicast ....

C. Diot, B. Lyles, B. Levine, and H. Kassem, "Requirements for the definition of new IPmulticast services", IEEE Network, January/February 2000.

....mainly related to the instability and complexity of multicast routing protocols. It is believed that the availability of good management tools has become a crucial part in multicast deployment. Deploying multicast without such tools is likely to yield a less than satisfactory customer experience[5]. Monitoring stream quality and multicast reachability are important multicast management issues. Monitoring stream quality helps data sources to fine tune their transmission rates so that receivers can potentially optimize reception quality[6] Reachability ensures that sources can reach all ....

C. Diot, B. Lyles, B. Levine, and H. Kassem, "Requirements for the definition of new IP-multicast services," IEEE Network, January/February 2000.

....is difficult. After much research experimentation, multicast was initially deployed as the researchoriented Multicast Backbone (MBone) 2] has now grown beyond a research network and is beginning to be deployed by Internet Service Providers (ISPs) and used by service oriented companies[3]. However, the growing popularity of real time audio and video traffic and the aforementioned network failures have created a compelling business justification for multicast. Organizations such as the IP Multicast Initiative (IPMI) 1 have been working to educate consumers about the benefits of ....

C. Diot, B. Lyles, B. Levine, and H. Kassem, "Requirements for the definition of new IPmulticast services," IEEE Network, January/February 2000.

....management platforms. 1 Introduction Management of multicast traffic has become a key technical barrier to the further deployment of multicast in the Internet. The lack of usable management tools is being listed among the reasons why there has not been more rapid deployment and use of multicast[1]. For sake of completeness, other barriers that have been listed include the relative instability of multicast routing protocols, the lack of substantive experience among network engineers, and the chicken and egg problem of needing a true killer application . However, as most of these are not ....

C. Diot, B. Lyles, B. Levine, and H. Kassem, "Requirements for the definition of new IPmulticast services," IEEE Network, January/February 2000.

....suggest the MBone should disappear as we no longer need a research infrastructure . The thinking is that we should now be working toward a fully deployed, native multicast infrastructure. This process is underway and a number of Internet Service Providers (ISPs) are focused on deploying multicast[1]. Since the MBone s inception, relatively little formal research has been conducted on how the MBone is used, what performance gains multicast has provided, how multicast deployment has progressed, and what barriers exist for the continued deployment and success of multicast. While some of these ....

C. Diot, B. Lyles, B. Levine, and H. Kassem, "Requirements for the definition of new IP-multicast services," IEEE Network, January/February 2000.

....Source Discovery Protocol (MSDP) 2] In addition, the Internet Group Management Protocol (IGMP) was designed for end hosts to dynamically join and leave multicast groups. The wide scale commercial deployment of this service model and protocol architecture has run into significant barriers [3]. Many of these barriers are rooted in the problem that building efficient multicast trees for dynamic groups of receivers is a non trivial problem. As a result, the existing set of protocols is fairly complex and the learning curve is quite steep. Furthermore the anyto any design philosophy of ....

....In addition, they must not propagate ( G) joins for group addresses in the SSM address range. ffl Rendezvous Points (RPs) must not accept PIM Register messages or ( G) join messages. In summary, the ASM service model and protocol architecture suffer from a number of serious deployment problem[3]. The SSM service model addresses many of the needs of today s commercial multicast applications. Also, the associated protocol architecture is simpler, and easy to deploy in networks that already supports ASM. The challenge then becomes integrating the two. 4 Integrating ASM and SSM In this ....

C. Diot, B. Lyles, B. Levine, and H. Kassem, "Requirements for the definition of new IP-multicast services," IEEE Network, January/February 2000.

Online articles have much greater impact   More about CiteSeer.IST   Add search form to your site   Submit documents   Feedback  

CiteSeer.IST - Copyright Penn State and NEC