Multicast Survey in Support of a Re-Chartering of the MBoneD IETF Working Group. June 2006 1. Presentation 1.1 Context and goal The MBoneD working group's charter includes a requirement to "Receive regular reports on the current state of the deployment of multicast technology. Create "practice and experience" documents that capture the experience of those who have deployed and are deploying various multicast technologies." At present, the state of multicast deployment presents new opportunities, with a considerable push to develop and deploy Multicast VPNs, development of multicast protocols for cell networks, such as MBMS and BCMCS, and deployment of multicast in as part of the so called "network convergence" or "Network Triple Play." These deployments, being not anticipated at the time of the original development of ASM and SSM, will mean new challenges to the Mboned Working Group. With the change in the Working Group Chair, and the desire to re-charter the Working Group, there is a need for a broad based look at the future of Internet-wide multicast. As part of their multicast efforts, the L3VPN working group conducted a multicast survey, focusing on Multicast VPN issues. The results of this survey can be obtained from http://www.dnni.com/l3vpn/survey/results.html http://www.dnni.com/l3vpn/survey/summary.html (a summary of the responses) Because this survey covered the Multicast VPN arena, and because of the preliminary nature of mobile multicast deployment efforts such as MBMS and BCMCS, the current survey focuses on multicast video deployment efforts. 1.2 The Network Triple Play. Many ISPs are currently building IP based networks supporting so-called Triple Play scenarios, delivering support for voice, data and video services on the same network. Live TV, as one of the major applications of as one of the major applications, requires a low packet loss and delay jitter delivery to meet typical entertainment video requirements, and in many cases will be delivered by an IP-Multicast enabled network. The Goal of the survey is to look into the different requirements on the network from both an operator perspective and a protocol development perspective, in order to determine if there are new goals, or changes to existing goals, for the working group. 1.3 Answering this survey This survey will hopefully be answered by ISPs planing to offer multicast service, and possibly by content providers having a need for such a service (not all questions of this survey will be relevant in that later case). If you are an ISP, the answers should relate not to what you would expect today, but more to what you see as a longer term target for such a service. For scalability figures, please answer what you think you would need to support in the longer term. If you expect many significantly different deployments, it is possible to answer the survey multiple times. Please answer as many questions as possible, but feel free to omit answers if the question are not relevant for you. Note that the responses will be anonymized to protect any confidential business information. 1.4 Sending the results Once completed, we'd appreciate that you send the document to Lucy Lynch , who will anonymize the survey results before forwarding them to the survey authors and the MBoned community. Please put your name and the words "Multicast Chartering Survey" in the subject line when you submit the survey and any other related correspondence so that this traffic can be easily isolated. Please feel free to add attachments (figures, graphs, etc.) you want to send to the survey organizers. Please indicate clearly which question these are intended to answer or illustrate. Please note that while the anonymizer will not reveal the source of these attachments to the survey team, she will make no attempt to remove any internal evidence of their origin. Please return completed surveys before July 15th, 2006 if possible; the intention is to discuss the results at IETF-66. Thank you very much ! 2.0 General IPTV/Multicast requirements: Here, we are just expecting rough figures and orders of magnitude, such as: 20k, tens of thousands, hundreds, ~7500, O(10^2), etc. 2.1 How many content sources do you expect to support ? total _____ Outside your domain _____ per geographic location _____ 2.2 How many separate geographic locations do you expect to have multicast sources ? _____ 2.3 How many separate geographic locations do you expect to have multicast receivers ? _____ 2.4 What proportion of the receivers of your multicasts will be Servers, such as content servers _____ Middleware devices, such as caches _____ Home or office computers _____ Set top boxes _____ Other devices _____ 2.4 How many multicast channels do you expect to support internally (by internally, we mean served or duplicated from routers or servers within your network) ? _____ 2.4.1 What is the maximum bandwidth of your internal multicast channels ? _____ 2.4.1.1 Bandwidth per channel (Group/ASM): ____ 2.4.1.2 Total bandwidth of multicast traffic: ____ 2.4.2 What is the average bandwidth of your internal multicast channels ? _____ 2.4.3 Are your internal multicasts static or dynamic in nature ? (In other words, will the set of channels offered be primarily constant, or will they vary considerably with time ?) _____ 2.4.3.1 If your internal multicasts are primarily dynamic, what is a typical time for the channel set to change ? _____ 2.4.3.2 How long (typical duration) will a channel be assigned to the same broadcast ? _______ 2.5. Do you plan to source your internal multicasts to external users (i.e., to users that are not on your network) ? immediately _____ eventually _____ 2.6. Do you plan to allow external multicast sources to reach your users (i.e., from sources that are not on your network) ? immediately _____ eventually _____ 2.6.1 If you allow external multicasts, will these be available to all users, or only to a subset (those who have made prior arrangements, for example). 2.7 Do you plan to support an electronic program guide ? _____ 2.8. There has been a lot of discussion about the time required to change a multicast channel (i.e., for a user to stop receiving one stream and start receiving another). 2.8.1 How often do you estimate that your users will change their multicast channels per hour ? _____ 2.8.2 What is the desired time for a user of your services to change the channel ? _____ 2.8.3 How many channel change events to you expect per second/per network device? ____ 3.0 Multicast and QoS Some Live TV applications are very sensitive to packet loss. 3.1. Do you plan to offer QOS as part of your multicast service ? _____ 3.1.1. If yes, please specify the type _____ 3.1.2. Will your QOS solutions be different for your backbone and edge networks ? 3.2. Do you plan to offer Forward Error Correction (FEC) as part of your multicast service ? _____ 3.2.1. If yes, please specify the type _____ 3.3 What availability is required for the multicast services (e.g. 99.999)? ____ 3.3.1 What is the maximum packet loss allowed for the Multicast service? ____ 3.3.2 Are the packet loss requirements for Multicast different (more stringent, weaker) from the packet loss requirements for unicast ? ____ 4.0 Multicast Service Model 4.1. What proportion of your multicast service will be in the various service models. How many Mroutes do you plan per model ? ASM _____ SSM _____ BiDir _____ Other (please specify) _____ 4.2. Will you offer parallel support for ASM and SSM ? _____ 4.3. Will you offer parallel support of IGMP v2 and v3 ? _____ 4.4. Would you use an IGMPv2 / ASM edge and an SSM Core if it was available ? _____ 4.5. What proportion of your multicast service will be IPv4 _____ IPv6 _____ 4.5.1. If you are offering IPv6 support, will you offer support for IPv6 MLDv2 _____ Embedded RP _____ SSM _____ 4.5.2. Inside your domain, do you use or plan to use Anycast-MSDP _____ Anycast-PIM _____ 4.5.3. If you support MSDP Anycast RP, do you plan to shift to PIM Anycast ? _____ 5. Multicast enabled Backbone networks 5.1. Do you expect to deploy other multicast services, such as L2VPN _____ L3VPN _____ MBMS _____ BCMCS _____ Reliable Multicast _____ Other (please specify) _____ 5.2. Do you support or expect to support Automatic Multicasting without Tunneling (AMT) or similar tunneling mechanisms in the access area / edge network ? Yes ____ No _____ 5.3. Do you support interdomain Multicast ? _____ 5.3.1.a (If yes on 5.3) Please describe what policies you use to accept data from external multicast sources ? ___________________________________________________________________ 5.3.1.b (If yes on 5.3) Please describe what policies you would require to accept data from external multicast sources ? ___________________________________________________________________ 5.3.1.c (If no on 5.3) Why not ? ___________________________________________________________________ 5.3.2. Do you support MSDP, for interdomain peering _____ Anycast RP _____ Both _____ 5.3.3. In inter-domain multicast routing, if there are many receivers inside a network for a stream coming from outside, there is a potential choice between "hot potato" and "cold potato" multicast routing : replicating a stream outside of the network (thus potentially requiring the stream to come into many entry points close to the receivers) versus having one multicast stream enter the network for replication inside. Would you prefer to have a multicast stream enter your network at multiple locations if there was a wide-spread distribution of active receivers inside your network ? _____ 5.3.3.1. Would you support this capability for streams exiting your network ? _____ 5.4. Have you deployed or do you plan to deploy Bi-Directional (Bi-Dir) Multicast ? Yes _____ No _____ 5.4.1. (If answering yes to question 5.4.) Would you be interested in interdomain Bi-Dir ? Yes _____ No _____ 6. What multicast tools do you use, for monitoring and debugging ? 6.1. mtrace _____ 6.2. mping _____ 6.3. the multicast beacon _____ 6.4. rtpdump / rtpqual _____ 6.5. Other (please specify) ___________________________ 6.6. Is there a multicast tool that you would like to have available ? (please specify) ___________________________ 7. Other Issues 7.1 Are there other multicast issues that are important to you or that you feel require greater support ? Please be as specific as possible. 8. Comments Section 8.1 Please provide any comments you wish about the status and the future of multicast deployment, items that you feel should have been covered by the survey, etc., at the end of this section. 8.2. You can also send attachments to be included with the comments on the survey. Please mark these as intended for the public comment section, and note that no attempt will be made to remove any internal evidence for their origin.