I frequently teach routing and operations, and find this discussion of terms to be coming up with a useful consensus to answer some very frequently asked questions. I'd like to see the results of this discussion spread more widely than the NANOG list. It strikes me that the discussion is the kernel of an informational RFC complementary to Dave Crocker's RFC1775, "To be "on" the Internet." Here, perhaps we are defining what it means to be "in" the Internet. RFC1775 emphasized the user perspective; it would seem that a different document emphasizing the operator perspective also would be useful. Michael Dillon and others have put forth some good definitions. Would any of you active contributors be interested in trying an RFC on this? I'll step up to editing it if it would be useful. ----- My comments on Michael's last posting: HCB> Another FAQ is the meaning of "multihoming." There seem to be HCB> two cases in common usage: IP-level multiple paths to a single HCB> AS, and BGP peerings to >1 AS. If we think like an onion (shades of TinyBASIC!) then the core of the Internet are these providers who supply transit over their own national and international backbones and who do not need to buy transit from other providers. The providers who form the Internet core are sometimes called NSP's (Network Service Providers) and sometimes called Tier 1 providers HCB> I'd add that a Tier 1 provider/NSP has at least some routers that HCB> are default-free.
That's pretty common usage. Sounds much better than an-as-pee. The term for second-tier is "regional provider" and third tier is usually local providers.
The next layer of the onion is the Tier 2 providers sometimes referred to as regional providers although they may actually serve overlapping geographical regions. These providers do not provide transit but they do supply other providers in a lower tier. HCB> I'm not sure about the part that a Tier 2 provider never provides HCB> transit. This brings us to the Tier 3 providers commonly known as ISP's (Internet Service Providers. These organizations may connect to Tier 2 providers or Tier 1 providers but their distinguishing characteristic is that they do no normally supply organizations who resell Internet access. Tier 4 networks belong to those organizations who provide Internet access for their own members or employees. These could be corporations, schools, or universities who operate both internal networks and provide dialup services that are not available to the general public. Sometimes a Tier 4 network provides access to other organizations such as a company which supplies its subcontractors with their Internet connectivity. HCB> A Tier 4 might be the first level that provides proxy aggregation, HCB> if it supports external organizations such as subcontractors. HCB> Proxy aggregation is more likely to be at Tier 3 or higher. Tier 5 is the end user. They may have a single PC that dials up to the Internet or they may be sitting in front of a workstation on a corporate LAN. Unlike an onion skin, these layers are not precise and there is some overlap especially in Tier 2. Until recently most ISP's connected directly to Tier 1 providers and although there are some providers who are starting to specialize in Tier 2 services it will remain common for both Tier 1 and 3 organizations to be in that market. This seems to explain the relationships in a way that I think the average person or journalist could understand and still form concepts fairly close to the reality of today's global Internet.
On Sat, 6 Apr 1996, Howard C. Berkowitz wrote:
Michael Dillon and others have put forth some good definitions. Would any of you active contributors be interested in trying an RFC on this? I'll step up to editing it if it would be useful.
I've been fleshing out a longer explanation in my mind last evening so I'm willing to continue with this.
HCB> I'm not sure about the part that a Tier 2 provider never provides HCB> transit.
This is true. The lines of division are somewhat fuzzy. My feeling is that the Tier 2 provider is not primarily in the business of supplying transit but may do so incidentally to their primary operations and even then. Michael Dillon Voice: +1-604-546-8022 Memra Software Inc. Fax: +1-604-546-3049 http://www.memra.com E-mail: michael@memra.com
participants (2)
-
hcb@clark.net
-
Michael Dillon