North American Network Operators Group|
Date Prev | Date Next |
Date Index |
Thread Index |
Author Index |
mbone/NSFnet migration (fwd)
- From: bmanning
- Date: Thu Oct 20 08:32:49 1994
- Posted-date: Thu, 20 Oct 1994 05:31:53 -0700 (PDT)
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" <firstname.lastname@example.org>
> 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
> 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
> 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.
> (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.
- - - - - - - - - - - - - - - - -