North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical mbone/NSFnet migration (fwd)
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" <[email protected]> > 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 - - - - - - - - - - - - - - - - -
|