2.4.5 MBONE Deployment (mboned)

NOTE: This charter is a snapshot of the 44th IETF Meeting in Minneapolis, Minnesota. It may now be out-of-date. Last Modified: 06-Jan-99


David Meyer <dmm@cisco.com>

Operations and Management Area Director(s):

Harald Alvestrand <Harald.Alvestrand@maxware.no>
Bert Wijnen <wijnen@vnet.ibm.com>

Operations and Management Area Advisor:

Harald Alvestrand <Harald.Alvestrand@maxware.no>

Technical Advisor(s):

Scott Bradner <sob@harvard.edu>

Mailing Lists:

General Discussion:mboned@ns.uoregon.edu
To Subscribe: majordomo@ns.uoregon.edu
Archive: ftp://ftp.uoregon.edu/mailing-lists/mboned*

Description of Working Group:

The MBONE Deployment Working Group will be 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:

- Deployment of multicast routing in the global Internet.

- Receive regular reports on the current state of the deployment of mbone technology. Create "practice and experience" documents that capture the experience of those who have deployed and are deploying various MBONE technologies (e.g. PIM, DVMRP, CBT).

- Based on reports and other information, provide feedback to IDMR.

- Develop mechanisms and procedures to aid in the transition to native multicast, where appropriate.

- Develop mechanisms and procedures for sharing operational information to aid in operation of the global MBONE.

- Development of guidelines to improve the use of administratively scoped multicast addresses.

- Develop mechanisms and procedures for creating and maintaining a MBONE topology database.

This working group will initially interact closely with IDMR. It is believed that, once hierarchical multicast routing systems are specified and deployed, the working groups will diverge somewhat. Finally, note that in the below 'Goals & Milestones', the type of RFC will be subject to discussions within the working group.

Goals and Milestones:

Sep 96


Submit Internet-Draft on inter-provider coordination of the deployment of pruning mrouteds.

Sep 96


Establish initial charter, goals, and long-term group agenda.

Jan 97


Submit Internet-Draft outlining requirements for the existing MBONE infrastructure.

Apr 97


Submit Internet-Draft specifying the use of administratively scoped multicast addresses.

Jun 97


Begin work, with RPS WG, on extensions to RPSL to describe multicast routing policy.

Jun 97


Subnmit Internet-Draft specifying the use of aggregation for DVMRP (and, in general where applicable). In addition, address the use of DVMRP default.

Sep 97


Submit Internet-Draft specifying the use of native multicast where appropriate (e.g. exchange points).

Sep 97


Begin work on document of co-existence strategies for IPv4 multicast and IPv6 multicast.

Dec 97


Begin work on a document describing the deployment of inter-provider hirearchical multicast routing coordination (or, when available).


Request For Comments:







Administratively Scoped IP Multicast

Current Meeting Report


agenda bashing for wed -
- add: maddogs
- change: static allocation from 226/8 to 233/8
- add: pavlin mbonemap
- add: thaler - status of mzap
- change: multicast traffic monitoring from fenner to almeroth
- add: mark handley on mtu discovery

agenda bashing for thurs
- thaler, multicast debugging handbook, 15 minutes


meyer: brief report on maddogs meeting, pointed to unofficial ietf web page, www.maoz.com/~maddogs described mboned-glob-bits draft, questioning assumption that they must be dynamically allocated, want to be able to bootstrap folks who want them now. talked about it in malloc, should it become a malloc document, yes, good suggestions, 233 not 226, add an explicit lifetime to the addresses allocated this way. get document back and written up, send it to malloc and ask for experimental status. ?? how to do inverse address mapping.

thaler: what does that mean

peter: get a name server or set of nameservers that serves 233, we know who owns an AS number, but no mapping to a computer. must be a manual process, ad hoc voluntary system with lifetime.

mrm - kevin almeroth

multicast routing monitor protocol overview.

router based implementation to help with debugging. last draft didnt make it out before deadline.

protocol was proposed a couple of years ago, in development. big can of worms with management. chicken and egg problems. start efforts with mrm so folks in the real world will deploy/manage multicast.

mrm allows you to source and receive traffic from multicast routers for testing. to replace the call your friends and test model. how do you administer this, what happens when you ask a router to source traffic, how to identify receivers, what to receive, how to send it back, etc.

3 components - mrm manager which controls everything. test manager aggregates and analyses data. test-sender sources data, test-receiver receives and reports what it sees.

[get notes from kevin and tell him not to use green as a slide color.]

uses for mrm:

pre event testing - like at an ietf meeting, before the event occurs.

company, ceo giving a talk (on future of multicast) wants to not be embarrased by demo.

fault isolation if someone is not getting data. Can you know before the phone rings, maybe with an active group that is for testing only.

session monitor, like rtpmon but able to do it without an active group. maybe do sampling, on very large group so you can get a feel.

fault logging. tell me when you see faults. Especially if an isp has to refund $$ when fault occurs and user whines.


use the rtpv2 packet format
manager messages:
- sequence number, acked even for udp
- beacon messages, sent every minute, includes state info
mgr to test-source messages
- total packets, rate, inter-arrival time
- address, etc.
mrg to test-receiver messages
- stats to keep
- faults (thresholds)
- how to send back
interface with existing tools (mtrace)

- md5 messages for authentication

how does it differ from existing tools
- snmp
- not really designed for interactive dynamic stuff, scalability
- not very good
- rtcp
- too restrictive, very useful, but not flexible enough
- mtrace
- limited to active groups/sources, need to be able to say
- start sourceing traffic and tell me what you see.

future work
- continue deployment, version 1 currently in experimental version of ios
- version 2 - add scalability, report suppression or aggregation
- add application level tools

thaler: what scalability is in version 1. unicast or mulitcast reports.

liming: scaling is a burden on the management software now

thaler: version 1 can be done with snmp, except maybe scalability, snmp cant limit frequency of traps, multicast feedback is something that cant be done in snmp. traffic sourcing like ping mib.

liming: want to develop mib for traffic sourcing, what kind of mib do we want. mrm is orthogonal to snmp, and more focussed. doesn't replace snmp.

thaler: security is a big issue here, new protocol, can deal with that by folding into snmp, if you cant use snmp, then strongly justify why you cant.

liming: make your snmp application able to use mrm and then you get security for free.

monitoring of as1088 dvmrp infrastructure, fenner

showed graph of dvmrp sources vs mbgp sources vs other sources.
dvmrp 2x or 3x mbgp in september for s,g entries in forwarding tables.

discovered a bug in ios's forwarding path stuff. scale went from 100 to 2000, due to stale entries.

latest data thru january shows mbgp and dvmrp much closer, got really noisy data in mid january, maybe the heuristic to find the buggy cache entries is failing.

want to find scope and interest of the two protocols, someday we hope dvmrp will go to 0

data shown in graphs is the number of sources at that point in time, it's worst case, not an average.

dino: where are routes coming from, bill: about 600 /16 or /20 ish mbgp routes and about 2000 dvmrp routes. dino: longest match makes some of the s,g's go to dvmrp instead of mbgp. so someone is misconfigured if this happened.

xxx: is there any way to get packet counts to see real sources from rtcp. fenner: already sort of does that in his bogus sources heuristic.

started to do mbgp monitoring, see www.aciri.org/fenner/mcast/mbgp.

sdr global session monitoring effort - kamil sarac (student of kevin almeroth)

monitoring sdr session announcements
collect sdr caches from several participants (40 at present, ~25 active)
- sender script - 60 lines of tcl
- sdr monitor parser - collects it and archives it
- participants (senders) are mostly in us and europe, 1 in asia, 1 in australia

- see if your session is getting out at all
- too far
- just right

graphs of ttl vs announcements showing global, regional, local
graphs of visibility (of sdr announcements) on long lived session
- some stable, some unstable probably due to local effects

graph of global sessions - visible roughly 50% of the time

conclusions - availability of sdr sessions poor and fluctuating a lot

- topology map of participants showing state of session relative to participants
- mtrace to participants to show where problems are
- please make suggestions

need more participants, email ksarac@cs.ucsb.edu to join see http://imj.ucsb.edu/sdr-monitor

mark: do you have any idea if the sdr data matches multicast data. since sdr announcements are bursty and some routers dont do bursty.

meilor: how much of the visiblity is the problem of the first hop router. shutting it down today, starting it tomorrow morning.

kamil/kevin: anwswer we fix stuff in the data. we keep a sequence number, so we notice that. use the first line in the cache entry, discard it if announcement was older than one day.

mark: 1 day too long, 1 hour better.

mantra - prashant rajvaidya

tool for monitoring and analyzing multicast data from routers. want to give global picture of multicast traffic. this is a first cut collect data from 3 routers, data shown only from fixw-mbone
- expect scripts, once every hour
- get 3 views now, from the cisco commands: xxx, xxx, xxx-
- data for the last four months
mantra is a tool to analyze it and put results on the web
- interactive applets
- html tables
demo - starting with empty screen
- x axis is time, by hour, have 3 months of data
- y axis you can choose #particpants, #groups, #sources, etc.
- can zoom time scale, no explanation of big fluctuations.
mantra request server
- request only data you are interest in
- trend analysis as we get more data
- debugging tool to explain spikes
- need data from multiple routers
- mantra at multiple sites, so sites can run it locally if they don't want to share their data.
- develop system for intra or inter domain monitoring
- data collection
- expect scripts [not likely on other peoples routers!]
- snmp
- email
- ??
- time granularity - scale, dont want to overwhelm busy routers

dino: can you monitor rpf changes, additions and deletions.

bill: hard to collect via a periodic sample, can get a big view, but granularity of changes is too small, need the router to tell you when they occur. router needs to have a counter to show rpf changes/rpf failures.

dino: router has counter to do that anyway, so dino is asking for that to be collected and displayed, he and dave thaler arguing about whether the existing counters are enough.

mzap - dave thaler

spec updated from orlando, port numbers assigned by iana, so going to working group last call

mbone map, pavlin

www.isi.edu/scam/mbone.html map available

fenner: how do you collect the data
answer: might have been mrinfo query, couldnt hear.

multicast mtu discovery, mark handley

ask what is the size of the last fragment that you received then receiver can report back to the sender.

dino: opaque pim message that captures population count and mtu to source.

mark: can do it independent of routing protocol, couldnt do it with tunnels, with native you can.

dino: if you know it's pim, can be more efficient.

dave: routes on receiving end find out mtu
- mark: push it up to the application level
- thaler: nice to be independent of routing protocol at network or application layer (dino/mark)
- thaler: as a receiver joins mtu might change, should sender flip/flop
- everyone: NO

steve casner: just say mtu is 1500 and be done with it.

mark: may be more of an issue as we get more dialup access

liming: is this multicast specific, same problem in unicast. use fixed value 576, mtu for entire network.

ross: how hard is it to get the value from the tcp stack, ie windows 95, what hope is there.

casner: there is a protocol for doing segmenetation and reassembly on ppp links, just use that instead of making all the packets so little.

thaler: reluctant to say 576, local intranet may want much higher value.


review of wed meeting

agenda, thurs
- anycast rp, dorian kim,
- sadp draft update/review
- challenges/solutions for multicast applications, quinn
- multicast debugging handbook

sadp - nested scoping

ttl scoping doesnt work for large scopes
- ttls not necessarily symmetric
- some hear request, some hear response, some hear both

admin scoping better
- nested

- which scopes nest (mzap draft)
- how to distribute info (madcap draft)
- which addresses to use in various scopes (sadp draft)

- service increase scalability
- caches messages
- request mechanism to allowserver to cache
- multiple addresses in a session but client might not be willing to join to all

dorian kim

draft-ietf-mboned-anycast-rp-00 intradomain case using anycast benefits is not clear

dmm - questions about benefits case of two AS, with rp's in each and connection between them. draft describes the benefits of connecting them

dino: could you use anycast rp across domains. like across providers that they share, reduces number of msdp sessions. could do that, coordination issue if anything goes wrong.

dino: rp cluster idea of a couple of years ago at ix'es. can we connect several providers thru the anycast rp.

peter: reason we did it is to not depend on someone elses rp.

dorian: need that info for deployment and support (that info= private address)

hal alverstan: would like anycast reference. old craig partridge rfc on it. steve deering will do a bof at the next ietf to produce a document on anycast.

dino: this anycast may be misnamed. we are doing shortest path routing, have two identical addresses. steve deering: yes, lets change the name here.

bob quin, ip multicast applications, challenges and solutions draft.

how many have read it (1/3 of the room maybe)

roadmap for newcomers, intro to applications and their requirements.
- avoid reinventing wheels
- avoid spinning wheels
- avoid running roughshod over the network

focus purely application, assumption - scaling with the igmp model.

changes in this revision - kevin almeroth added as co-author
added to services: expedient joins and leaves, send without join
added to service reqts synschronization.

added the many to one category to the text.
- doesnt model network level multicast
- resource discovery
- data collections
- auctions
- polling
- juke box

steve deering, multicasting to a group with only one member?

next: some minor edits, last call by july.

dave thaler, multicast debugging handbook

have two types of tools
- intra domain management, snmp mibs, mrm, route flap monitor, mview
- end-2-end management: mtrace, rtpmon

why isnt multicast deployed, asked multicast summit attendees what they needed
- more tools or better tools
- understand how to read/use the current ones
- need to know: is it red or green, not pile of numbers
- need expert system to read mtrace output.

handbook has debugging procedures
- problem referral, mtrace shows where problem is
- model where end user calls local help desk wont help
- referral big deal

wrote troubled, never released server because of memory leaks.
going to get kevins students to do it.

common problems
- congestion
- no route to source
- route flapping
- route dumping (unicast injected into dvmrp tables)

identify functional components
- multicast forwarder ...

need health meter for ability of link to forward multicast traffic

express health in terms of red/green scale has formulas for it

question: how do you measure utilization. if you know bandwidth use that, or rate limit, etc. skeptical about ability to estimate capacity. thaler: right, sometimes you just have to estimate/guess.

what to do if things are bad.
- congestion, what is causing it, tcpdump, netflow, etc.
- health problem, mtrace

dependency graph of functional components, at transport, network and link level.

troubled heuristic measures badness factor. had lots of formulas

falling asleep, not doing a very good job, dmm, sorry.

ran experiment using mtrace -d which listens to other mtraces.
- 12841 mtrace reports heard
- 106 alerts in 3 weeks for congestion problems
- 42 different as's
debugged for 2 weeks, analyzed data for final week
- 21 confirmed congestion on links
- 4 for confirmed problems on routers

peter: does this apply today, you are looking at the mbone as dvmrp tunneled architecture. what we are building now is mbgp, msdp. real problems are not congestion, state and configuration. whole new set of problems that are state related. need to have document to say here are todays problems and how to debug them. if we are going to redo the handbook today, we need to focus on these problems.

dave: document configuration problems for a vendor.

peter: document machinery to create forwarding state. not necessarily with a particular piece of equipment.

thaler: yes, what are the most common problems and their solutions, who has the experience. give me feedback. snmp community waiting for snmp v3 to be done, then will work on whats next. end-2-end management was high on their list of todo's next.

challenges - distinguish link loss vs router loss.
assymetric routing makes mtrace from each direction not helpful.
enumerate top users of link mcast traffic (vanograms)
identify # routes learned from each neighbor (unicast routes flooding)
same for # routing updates
local any legal path (cant get a route to mtrace with)
- might need a database or routing registry, mwatch used to
- do this via mrinfo database
bidirectional mtrace
- once the rp switches to the shortest path tree, but source is on the shared tree, mtrace may go to rp instead of source.

need alarm generation from tools.

draft ietf-mboned-mdh-*.txt
troubled details for mbone, chapter 3 of thesis
gdt protcol, draft-thaler-gdt-00.txt

john stewart from crc technology in canada: make a red/green monitor, boss likes it, up for 6 months


IP Multicast Applications: Challenges & Solutions