2.4.8 MBONE Deployment (mboned)

NOTE: This charter is a snapshot of the 62nd IETF Meeting in Minneapolis, MN USA. It may now be out-of-date.
In addition to this official charter maintained by the IETF Secretariat, there is additional information about this working group on the Web at:

       Additional MBONED Page

Last Modified: 2005-01-07


David Meyer <dmm@1-4-5.net>

Operations and Management Area Director(s):

Bert Wijnen <bwijnen@lucent.com>
David Kessens <david.kessens@nokia.com>

Operations and Management Area Advisor:

David Kessens <david.kessens@nokia.com>

Technical Advisor(s):

Scott Bradner <sob@harvard.edu>

Mailing Lists:

General Discussion: mboned@lists.uoregon.edu
To Subscribe: majordomo@lists.uoregon.edu
Archive: http://www.uoregon.edu/~llynch/mboned

Description of Working Group:

The MBONE Deployment Working Group is a forum for coordinating
the deployment, engineering, and operation of multicast routing
protocols and procedures in the global Internet. This activity will
include, but not be limited to:

- Documenting deployment of multicast routing in the global Internet.

- 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.

- Based on reports and other information, provide feedback to other
  relevant working groups.

- Develop mechanisms and procedures for sharing operational
  information to aid in operation of the multicast backbones and

- Update RFC 3171/BCP 51 based on experience.

- Develop a roadmap informational RFC that describes the current
  IPv4 and IPv6 IETF multicast architectures, including
  references to the relevant IETF documents and guidance for
  implementers and network operators.

- Complete the MSDP MIB

This is not meant to be a protocol development Working Group.

Goals and Milestones:

Done  Submit I-D on inter-provider coordination of the deployment of pruning mrouteds.
Done  Establish initial charter, goals, and long-term group agenda.
Done  Submit I-D outlining requirements for the existing MBONE infrastructure.
Done  Submit I-D specifying the use of administratively scoped multicast addresses (RFC 2365)
Done  Submit I-D specifying the use of native multicast where appropriate (e.g. exchange points).
Done  Submit I-D on IP Multicast and Firewalls (RFC 2588)
Done  Submit I-D specifying static allocations in 233/87 (RFC 3180)
Done  Submit I-D on debugging multicast problems.
Done  Submit final version of scope zone announcement protocol (MZAP RFC 2776)
Done  Submit final version of scoped address discovery protocol (SADP)
Done  Submit I-D describing ISP multicast deployment practices
Done  Submit I-D, with RPS WG, on extensions to RPSL to describe multicast routing policy
Done  Submit I-D describing extended allocations in 233/8 (RFC 3138)
Done  Submit I-D describing IANA Guidelines for IPv4 Multicast Address Assignments (RFC 3171)
Done  Submit I-D describing IP Multicast Applications issues (RFC 3170)
Done  Submit I-D describing Anycast (RP) mechanism (RFC 3446)
Done  Submit I-D describing Source-Specific Protocol Independent Multicast in 232/8
Done  Submit I-D describing MSDP Deployment Scenarios
Done  Submit I-D describing IPv4 Multicast Unusable Group And Source Addresses
Done  Submit I-D describing Embedded RP for IPv6 Multicast Address
Apr 04  Submit I-D on PIM-SM Multicast Routing Security Issues
May 04  Submit I-D on IPv4/IPv6 multicast co-existence issues and strategies for IPv4 multicast and IPv6 multicast
Jun 04  Update IANA Guidelines for IPv4 Multicast Address Assignments (RFC 3171/BCP 51)
Jun 04  Submit PIM-SM Multicast Routing Security Issues to IESG for Informational
Jun 04  Submit MSDP MIB to IESG for Experimental
Aug 04  Submit IPv4 multicast address allocation procedures IESG for BCP
Aug 04  Submit IPv4/v6 co-existence strategies to IESG for Informational
Aug 04  Submit multicast roadmap/reference architecture document to IESG for Informational


  • draft-ietf-mboned-ssm232-08.txt
  • draft-ietf-mboned-auto-multicast-04.txt
  • draft-ietf-mboned-msdp-deploy-06.txt
  • draft-ietf-mboned-ipv4-uni-based-mcast-02.txt
  • draft-ietf-mboned-mroutesec-04.txt
  • draft-ietf-mboned-ipv6-multicast-issues-02.txt
  • draft-ietf-mboned-addrarch-01.txt

    Request For Comments:

    RFC2365 BCP Administratively Scoped IP Multicast
    RFC2588 I IP Multicast and Firewalls
    RFC2770 E GLOP Addressing in 233/8
    RFC2776 PS Multicast-Scope Zone Announcement Protocol (MZAP)
    RFC3138 I Extended Allocations in 233/8
    RFC3170 I IP Multicast Applications: Challenges and Solutions
    RFC3171 BCP IANA Guidelines for IPv4 Multicast Address Assignments
    RFC3180 BCP GLOP Addressing in 233/8
    RFC3446 I Anycast Rendevous Point (RP) mechanism using Protocol Independent Multicast (PIM) and Multicast Source Discovery Protocol (MSDP)
    RFC3956 Standard Embedding the Rendezvous Point (RP) Address in an IPv6 Multicast Address

    Current Meeting Report

    MBONE Deployment WG (mboned)

    MONDAY, March 7, 2005 (0900-1130)

    CHAIR: David Meyer <dmm@1-4-5.net>
    MINUTES: Marshall Eubanks <tme@multicasttech.com>


    o Administriva

    - Mailing list: majordomo@lists.uoregon.edu
    subscribe mboned

    - Scribe(s)?

    - Blue Sheets

    o Agenda Bashing 5 minutes

    o Review and status of work items

    Active Drafts
    draft-ietf-mboned-addrarch-01.txt 5 minutes
    draft-ietf-mboned-auto-multicast-04.txt 5 minutes
    Thaler, et al.
    draft-ietf-mboned-ipv6-multicast-issues-02.txt 10 minutes

    Expired Drafts
    draft-ietf-mboned-rfc3171bis-03.txt 5 minutes

    Potential WG Drafts
    draft-jdurand-assign-addr-ipv6-multicast-dhcpv6-01.txt 7 minutes
    draft-jdurand-ipv6-multicast-ra-00.txt 8 minutes
    draft-lehtonen-mboned-dynssm-req-00.txt 10 minutes
    draft-savola-mboned-address-discovery-problems-00.txt 10 minutes
    draft-savola-mboned-routingarch-01.txt 5 minutes

    Multicast VPN 20 minutes

    TUESDAY, March 8, 2005 (1530-1630)
    CHAIR: David Meyer <dmm@1-4-5.net>
    MINUTES: Marshall Eubanks <tme@multicasttech.com>


    o Administriva

    - Mailing list: majordomo@lists.uoregon.edu
    subscribe mboned

    - Scribe(s)?

    - Blue Sheets

    Issues Related to Receiver Access Control in the Current 10 minutes
    Multicast Protocols
    Hiroaki Sato

    Accounting, Authentication and Authorization Issues in 8 minutes
    Well Managed IP Multicasting Services
    Tsunemasa Hayashi

    Using SIP for Multicast Source discovery 14 minutes


    Greg Shepard is not here
    ssm232-07 is hung on the PIM - SM spec, as is

    Pekka Savola - Multicast Address Architecture

    Idea is a BCP for multicast addressing

    Document is close to convergence and it would be a good time for the group to read it, before it goes to WG Last call.

    Tom Pusateri - Dave Thaler's automatic multicast

    AMT -03 to -04 just came out with minor updates.

    Media Access Code is generated and verified by the same host, so the algorithm does not have to be standardized.

    An example technique was put in the spec, but it is not required.

    Added a UDP source port to MAC

    IANA has assigned 2268 as the port number for AMT

    Need a /16 prefix for an anycast address, to find relays.

    Some firewalls require that the host send traffic out to keep state in the firewall. IGMP refresh may not be frequent enough. They recommend making this a tunable parameter.

    Dave Meyer : I am going to get together with IANA today to discuss this.

    How many people are away of the TC BOF that is at 3:30 today ? There are a bunch of application specific automatic tunnel protocols floating around. People should go to this BOF to see if there is a way to use the multicast ideas to create a single tunnel standard.

    Toerless E : Isn't there also a problem with a multicast-like API ?

    Dave : That is one possible solution.

    Pekka Savola : IPv6 Multicast Deployment

    Critique in December was harsh but to the point. This was not reviewed adequately in the working group.

    Issues : Structure and purpose of the document is not clear enough.

    Comment by Allison Mankin that she was doubtful about further work on ASM, but embedded RP is already there, so ASM is not going away.

    Comment that SSM deployment issues are not IPv6 specific, but these do not appear elsewhere, and this document seems a good place for them.

    Directions : Abandon the work, or get more readers and reviewers.

    Dave Meyer : My Internet Draft, Some Issues for Multicast Deployment, has timed out a long time ago, but it could be revived. Many of these concerns are still there and are coming back, what with multicast L3 VPN's, etc.

    Toerless : Why does this have to be limited to IPv6 ? That would solve the SSM scope issues.

    Dave Meyer

    rfc3171bis-03 timed out inadvertently.
    This isn't really helping right now. The intent was to find the way to solve the problem of people asking for multicast addresses to solve the embedded application problem.

    I need to know from the group whether it is worth reviving.

    IANA gets two or three of these group address requests per week from application writers

    Marshall Eubanks - Does that mean that there really a lot more, 10 or 20 or more per week, as many people won't apply ? That seems like a lot.

    Dave Meyer : Some history. After Jon Postel passed away, IANA made some applications of multicast addresses, particularly to the NASDAQ. Now, every financial house comes to them and says, we need a class 16, and NASDAQ has space, so why can't we get one ? I say no, and I get overruled.

    Lenny Giuliano : Why can't IANA say, that was then, this is now ?

    Dave : That is a legal issue. IANA has exposure.

    Dave : With respect to GLOP and every other address application, I have built an address state web site that you should follow. I tell them to do that, and they just say no.

    We have not build a lightweight service discovery protocol that can be used in a embedded application devices.

    Lenny : What about SAP ?

    Dave : It's not reliable enough.

    Toerless : It's not as if we haven't gone through the motions before. Why not just charge for them ?

    Dave : That's the e-glop idea. We tried that, and we could never get it instantiate.

    Operations AD - I have talked to RIPE and they should be coming back to this.

    Steve Minas - I really can't understand why these people want global deployment. Can't we explain why this is not a good idea.

    Pekka : We can discuss this later. Even if we gave addresses to RIR to allocate, they would still go to to IANA.

    Dave : But then IANA could just tell them to go to the RIR, and that would be sufficient.

    [Audience Member] If people think that this is an important issue, I would like to take this back to the RIR's.

    J. Durand :


    IPV6 Multicast Deployment.

    ASM + SSM is working now. Only existing solution for ASM is RFC 3956 for embedded RP.

    The problem is not about address uniqueness, the problem is making sure that addresses are picked which map to a proper RP.

    The RP is "chosen" by the application. It could be topologically far from the application or the user.

    Solutions : MADCAP - can do what we want, but is not deployed and is rather complex.

    Want to use protocols already used for multicast.



    Multicast address assignment was easy to add. We can even assign prefixes to the host for the host to pick from.

    Another ideda was NDP draft-jdurand-ipv6-multicast-ra-00

    Collisions are very unlikely to happen in IPv6 but could be dealt with if people thought it was necessary.

    The problem is different than for IPv4. Only addresses derived from a working RP will lead to a working multicast group.

    With NDP + DHCPv6, multicast and unicast addressing architecture becomes the same.

    Another idea : What if every DR is a RP ? The RP address is now the subnet anycast router address. Then embedded RP multicast address can be figured out by the application. It seems strange but it should work.

    Dave Meyer : Do you run into state synchronization problem with this ?

    Durand - with a mechanism like this I do not think that you have any redundancy in the RP's/

    Pekka - I think that the redundancy comes at the DR level.

    Durand : Do we need anything more than MADCAP + manual assignment ?

    If yes, which of the 3 proposed solutions (or others) should be pursued.

    Bill Fenner : MADCAP started as a DHCP v4 subset, and was turned into a different protocol, as it was not a good fit to DHCP.

    Pekka : I think it is important to analyze what sort of features MADCAP have and what IPv6 needs, to make sure we don't make the same mistakes.

    Steve Vignus : I think DHCP v6 is a much better fit than the v4 case.

    If you do this, do you need to solve other problems than just embedded RP, or is that enough ?

    Pekke : We are trying to address the 90% case.

    Bill Fenner : I would have said that that was the 20% case.

    Something to remember is that PIM gives the RP a lot of work, while the DR does not have a lot to do. If every DR becomes an RP, then small boxes may become overloaded.

    Durand : Don't you think that the work will be more distributed ?

    Bill : For a small edge router, being the RP for even one group may be too much work.

    Isadore : I do not understand something. If you create the address at the time the first sender starts sending, how do the other members learn about it.

    Toerless : I think that the original ASM model was focused on peer to peer applications, but now the focus is on client server applications. If there are P2P applications, then embedded RP in this fashion has problems - if it's really just the first member in the group, then what if his RP goes away ? So you have reliability problems.

    Marshall Eubanks - I would personally like to see a solution that solves the lightweight discovery problem in v4 and v6 using the same tools.

    Dave Meyer : Is this a topic that the working group should take on ? (Inconclusive show of hands). I think we need to take this to the list.
    Stig Venaas
    Rami Lehtonen / Mickael Hoerdt

    SSM applications need to know source addresses. In a videoconferencing type environment, this may be difficult, as people may come and go.

    We could use embedded RP, but we are trying to do this in the application with SSM. Different applications, say in the same video conference, need to work together. It might be useful to have an "application RP".

    Requirements :

    Want performance comparable to ASM
    No network requirements except to SSM
    Multiple applications on the same host should work
    Need to know when sources leaves to tear down the state.

    The signally might follow different traffic paths from the data.

    Questions : Is this a problem worth looking at ? Should it be solved here ?

    Pekka : I am a bit concerned what we are trying to accomplish. Why do we want to do this in SSM ?

    Stig : We are trying to have ASM applications work with SSM.

    John Meylor : I think that there is value in investigating the requirements here.

    It was dawning on me that this applies to the multi-point scenarios. A lot of the discussions there overlook the dynamics of the applications. I think that a little work on a requirements document would be useful.

    [Japanese member] : Are you interested in doing this in this WG ? I think doing requirements and solutions in one place is useful.

    Dave : We can do requirements for operations, but officially we do not do protocols.

    Stig Venaas : Maybe the biggest problem is actually getting in touch with application developers.

    The end goal is to have a lightweight solution that has no requirements on the network except for SSM.

    Lenny : The last two presentations were basically on how to discover stuff. If those two are in the charter, why shouldn't this be ?

    Stig : We are interested in very dynamic situations, where applications come and go very fast.



    Lightweight Address Discovery

    Debated many times, but nothing ever happens.
    The discussion does not seem to be converging.

    So, it seems to me that the only way to do this is to write drafts.

    4 Problems :

    - Static Assignments

    - mess up local scoping plans
    - depletes resources
    - doesn't work with embedded RP, as addresses are not correct
    - it's difficult to filter in MSDP

    Dave Meyer's insight is that application writers expect that the app might have to be used between sites, so they want global addresses.

    Problem Scopes

    - locally scoped addresses from IANA
    - Address discovery within one domain, with a configured domain
    - zero-config single admin address discovery
    - global multiple administration address discovery

    We need people to work on this and create I-D's if this is to go forward.

    Dave Meyer : I think that there needs to be some consensus about what the problem space really is.

    John Meylor : There was a comment about the expectations of application writers. Wasn't there an attempt to write a document about this.

    Dave Meyer : MADCAP was part of a unified field theory that is no longer unified.

    Bill Fenner : It is part of an infrastructure and architecture that never got deployed.

    In the context of embedded RP in IPv6, I think that MADCAP could be a reasonable solution.

    Dave Thaler was more involved. Maybe he remembers more about what the problems were.

    Dave Meyer : I think that it would be worthwhile to document this.

    Stig : I think that the most complex parts of MADCAP was the problem of sharing state between servers (different parts of the organization might be running different DHCP servers).

    Pekka - Multicast Addressing Architecture

    We need a short overview for new-comers and operators.

    This also obsoletes MOSPF, BGMP and CBT.

    About five people have reviewed this so far.

    Any document with a lot of references to other protocols has trouble with new protocols, so we suggest that we don't discuss protocols that haven't gone to the IESG yet.

    Tom Pusateri :

    Why do you consider MOSPF to be historic ?

    Pekka : If I understand it correctly, neither Juniper nor Cisco implements it.

    Tom : It has its place

    Dave Meyer : I think that NASA Science Internet has a large MOSPF deployment.

    Pekka : Historic doesn't mean that its obsolete or not used, just that it's not the current state of the art.

    This reflects my understanding of what historic meant.

    Tom P. I think that MOSPF could be placed in the same category as DVMRP.

    Dave M. Personally I think that we haven't done enough

    I also think that the term historic is loaded and should be avoided.

    Dave Meylor : I think that we are beginning to see other working groups make assumptions about what multicast protocols are supported.

    Pekka : As an ISP, I was trying to give some signal about what is legacy and what the real status of the protocols is.

    Dave Meyer : Bill [Fenner], can you give me an indication of the status of the MSDP MIB ?

    Bill Fenner : I have to add some words to the MIB saying why the MSDP MIB is IPv4 only. So I need to add two sentences to the draft and resubmit.

    Multicast VPN

    Yiqun Cai

    Development really started in the 1990's, but first draft is draft-rosen-vpn-mcast-00.txt

    Multicast was added to the charter in Seoul, 2004

    Last year in San Diego, draft-rosen-vpn-mcast-07.txt was accepted as a L3 VPN document.

    Also, start of scaling discussion, including SSM.

    A number of drafts were submitted for the IETF in DC in Fall 2004.

    Since there are multiple solutions, there was a need to merge them.

    New draft will be l3vpn-2547bis-mcast-00.txt

    This missed the meeting curfew.

    Cisco has implemented the 07 version of the rosen draft.

    Juniper has shipped a solution based on rosen draft 06.

    Other vendors are developing multicast VPN as well.
    Some interop testing.

    Significant and growing deployment world-wide since 2003.

    A note on the Rosen draft

    It's a complete solution

    - a balance between optimal traffic distribution and state maintenance

    - Inter-AS

    - Features have several years of deployment.

    The most heated recent discussion topics have been about scaling.

    - Control plane scaling
    - balance between traffic delivery versus cost.

    Ideas :

    Use SSM in the core to establish forwarding trees.
    - Use of PIM-SM / BiDir is never considered.

    PIM Adjacency between PE routers.

    Overhead includes PIM Hello's and PIM Join/Prunes.

    Is there any Order(MVPN) states in the core ?

    In the unicast case, the core does not keep any VPN state.

    The trade=off

    - No state in the core means that the ingress PE has to maintain all of the dynamic membership information

    - Aggregation reduces the state in the core, but may result in sub-optimal forwarding.

    - Optimal traffic distribution requires extra states on the ingress PE and/or in the core.

    So, the optimal solution is likely to be some combination of native multicast, unicast replication, and P2MP LSP.

    Existing deployments are providing empirical data.

    - the base proposal seems to work well for existing multicast.

    I do not think that there is a simple one size fits all solution. Service provider and enterprise networks can have very different characteristics. I believe different solutions will be needed.

    Questions for the group :

    What do we need to do to scale the P routers ? The PE routers ? Do we want to do both ?

    MBONED WG (second session)

    Tsune Hayashi presents draft-hayashi-maccnt-02.txt

    Pekka Savola : minor editorial issue, recommends changing title "well-managed multicasting"
    Quick response, channel changes, not a AAA item

    consensus to take as working group item, take to mailing list for any.

    Hiroaki Satou presents draft-hayashi-rac-issues-00.txt

    Resource protection
    between SP and user can't it be done be existing protocols? not clear what draft's relation is to other document want to signal admission control?

    Hiaxang He: need SLA, intelligent decision based on existing resourcing,

    Pekka: unclear where you want to do between SP and CP, from the last link

    Steven Wright, Bellsouth: many service providers are interested in these issues and it is valuable to document the question.. it is in scope. since unicasting has many of the features we are looking for maybe it would be possible to import multicast into unicast.. make unicast protocols support multicasting.

    Dave Meyer: need to be careful about pulling protocol not out of scope, but haven't done

    Toerless: less friction if we talk about adding to multicasting protocols, not step on other groups toes.

    consensus is to accept this draft as working group item but with condition that overlap between drafts is removed.

    Marshall Eubanks
    Using SIP
    how do you find out about sources out there?
    A little history
    - original "package" of multicast media included SAP (2974) well though out was well known and simple
    - This described announcements that were multicast to a well known group and port
    - bandwidth was limited
    announce included MIME type followed by SPP file (or equiv)

    question is how do I join?

    SAP troubles
    - SAP in conjunction with sdr was pretty cool
    - TV Guide like capability
    - used for address allocation

    ASM oriented doesn't scale

    SIP was orrignally build for th Mbone

    Multicast has faded

    user agent use edge box, allows user services is a "push" model send invite, invite contains SDP file

    three-way handshare to set up session URIs are used to identify agents

    SIP is ASCII, so the packets are easy to prepare Applications could send a SIP register packet

    - a proxy server on the LAN could listen for this
    - no way to force usage of this mechanism to announce info
    - but application writers aren't doing things like that

    SIP Session Discovery
    -SIP could be used to Multicast INVITEs
    -TTL is RECOMMENDED but not a MUST
    - would work over LAN, but so what?
    - what is gain over SAP
    -not much
    - still scaling issues
    - however can send to list of names

    SIP subscribe
    -RFC sets up a soft-state SUBSCRIPTION list
    - can keep track of users by this mechanism
    - would at least know who joined the group.

    Source Discover:
    Forward & Inverse Problems
    - SIP SUBSCRIVE could solve the "forward" source discovery problem Inverse problem

    - not likely to be purely "in band" (multicast)
    - cannot be a single central server
    -some purity is likely to be list Probably would be more like DNS

    Does not directly solve the TV Guide problem

    Collin Perkins: for TV Guide problems, work in MMUSIC group SIP not good for discovery but good for negotiation

    Toreless: whether using multicast is used or not is not most important, worried about negotiations in dynamic application

    Stig: interested in multiparty SSM.


    None received.