mbone/NSFnet migration (fwd)

bmanning at ISI.EDU bmanning at ISI.EDU
Thu Oct 20 12:31:53 UTC 1994


If we end up w/ a few minutes this might be a useful topic of discusssion .. :)

> Subject: mbone/NSFnet migration
> Date: Wed, 19 Oct 94 22:50:18 -0400
> From: "Matt Mathis" <mathis at pele.psc.edu>
> X-Mts: smtp
> 
> 
> Hopefully most of you are aware of the pending massive restructuring of the
> U.S. Internet (see footnote (1) below if not).  In a few idle minutes (ha!) I
> attempted to extrapolate the existing mbone onto (my limited understanding of)
> the brave new North American Internet topology.
> 
> First the good news: When everything is done, the existing mbone will match
> new topology far better than we deserve to expect, perhaps almost optimal,
> needing only a few minor tweaks.  This was a real surprise!
> 
> Naturally during the transition, this will not be the case: unless two
> regionals connected by a tunnel move to their new National Service Provider at
> the same time, the tunnel between them will temporarily pass through an
> interconnect (a Network Access Point) between the NSPs.  Since all regionals
> are going to be making the transition at different paces, the intermediate
> states are likely to be pretty ugly, with possibly a dozen or more tunnels
> crossing the NAPs.
> 
> It is hard to predict if this will be a problem.  The aggregate bandwidth
> through the NAPs will be quite large - hundreds if not thousands of megabits
> per second (see 2), so even two dozen copies of the mbone may be ok.  I would
> not do anything drastic, such as shutting down the mbone (even temporarily).
> However, if there are problems we MUST be prepaired to adjust the mbone's
> bandwidth rating.
> 
> Now the bad news: the the transition schedule is already slipping, and the
> slippage has widened the spread in expected transition dates.  The original
> cut off date for the existing NSFnet service was October 31th.  It is being
> extended on a month-by-month, peer-by-peer basis.  Most connections have
> already been extended to Nov 30, which is less than a week before the
> IETF......
> 
> The situation is complicated be two other issues: the Internet itself is going
> to be rather fragile during the transition.  Although hundreds (thousands?) of
> people have been working very hard on it, there is just too much new
> technology, infrastructure and hardware for the transition to be totally free
> of glitches.  There will be mbone outages that are due to IP failures
> unrelated to mbone traffic.   It may be very difficult to tell if the mbone is
> contributing any observed instability.
> 
> Furthermore, most of the contacts on the mbone provider list are already
> working overtime on the Internet transition.  If some regional is having
> problems with vanilla IP service, mbone problems will be secondary.
> 
> So, what can the research community do to help?  I can think of several things:
> 
> o Dust off mbone mapping, instrumentation and diagnostic tools - particularly
> 	"strip charts" for mbone load and route transitions per hour, so we
> 	have a "before" baseline, and can correlate route flaps with load.  If
> 	data storage is a problem let me know, and I can make some
> 	arrangements.
> 
> o Be patient when it is broken, and be aware that the the person who needs to
> 	fix it may have already been up all night.
> 
> o Be gentle with the bandwidth, or it may be discovered that is your bits were
> 	the "last straw".
> 
> o We need to have some administrative mechanism to come to a consensus about
> 	mbone capacity.  The scheduling tools are a nice idea, but how do you
> 	know how much BW you have to divide under conflicting reports of
> 	signal quality.
> 
> o Don't start a conversation about the tunneled vs native multicast.  We've
> 	been there.
> 
> I will be posting an updated mbone provider contact list sometime soon.
> 
> Sorry about the duplicate posting, but I believe that both the mbone users and
> providers need to be aware of what is going on.
> 
> --MM--
> 
> ----------------------------------------
> Footnotes:
> 
> (1) To make a long story short, the existing NSFnet is a service of one
> provider: Merit, with one prime subcontractor: ANS.  NSF is spending a large
> sum of money to provide "free" T3 connections to the regionals.
> 
> After the transition, the NSF money will flow directly to the regionals (with a
> builtin 5 year sunset), who must purchase connectivity from NSF certified
> National Service Providers.  The primary requirement to be a NSP is that they
> connect to the NSF awarded NAPs, which are for exchanging traffic between
> providers.  (Much detail omited....).  In addition there are some Independent
> Service Providers, who are selling a la cart connectivity, mostly to
> businesses, etc.  They may also connect to the NAP's but unless they meet the
> NSP certification, they are ineligible to directly carry NSF funded regionals.
> Note that no NSF money goes directly to the NSPs, NAPs, or ISPs.  They get
> all of their revenue by charging for their services.
> 
> The up-to-date status can be obtained under http://rrdb.merit.edu/home.html.
> Note that the intended audience is the service providers, who do not need
> introductory explanations.
> 
> (2) The aggregate bandwidth available within the NAPs is surely
> gigabits/second, but most (all?) NSPs will connect via T3 links to 3 or 4
> NAPs for a total usable IP bandwidth of no more than 160 Mbit/s.  I am not
> privy to any of the global traffic models, so I can not comment on the
> expected load on these links.
> 
> 


-- 
--bill





More information about the NANOG mailing list