Cell Relay Archive

[dmcclure_NO_SPAM@infi.net (Doug McClure)]

On Mon, 15 Jun 1998 14:10:18 -0500, R Wilcox <nulldevice@eli.net> spoke into
cyberspace:

->This is a hot topic of discussion within the ATM Forum now.
->Several documents offering guidance and reference material
->are awaiting approval. There is also a longer term "bilevel
->addressing" proposal which allocates the higher order bits
->to the carrier and the lower order bits to the enterprise in a
->standard way such that the lower order bits are "portable"
->(as in local number portability).

I can see where the portability of address space will be very important in the
future.

->
->Some general guidelines:
->
->It is recommended that enterprises obtain addresses from
->their carrier to minimize route fragmentation. The Internet,
->with 50K+ routes, is an example of route fragmentation.
->Note that the trend in the Internet is for enterprises to get
->IP addresses from carriers too.

What if the size of the network scales to as large as the carrier's network?
How will utilizing their addressing format (whether private or public addresses)
affect any public peering plans within our network?  What if we had public
connections to more than one carrier?

->
->E.164 addresses are primarily designed for carrier networks
->not recomended, and probably not available to enterprises.
->Your carrier may assign some to you, but there is somewhat
->a shortage of them too.
->

How large must the network be to be classified as a carrier?  CLEC status, large
backbone provider, or what?  What do other large ATM providers use?  Are network
providers mainly using private addressing and carriers (RBOC's/CLECS) using
public addressing?  Isn't it best to go the same route as the carrier is so we
can ensure compatibility with whomever we connect/peer with?

->For US enterprises and carriers, the DCC format addresses
->allow 6 bytes to be split between the carrier and customer
->routing heirarchy.
->
->The ICD format has 10 bytes available to be split between
->the carrier and the enterprise. These are assigned by the
->British Standards Institute on behalf of ISO.

I did some reading over the weekend on the IDP and HO-DSP.  How are these bytes
manipulated to form a hierarchy for routing?  If I were to apply for any format
of ATM address, how are the bytes manipulated.    I know that the IDP, HO-DSP,
and ESI all must be unique.  Is it just the HO-DSP part (or x number of bytes)
that's assigned to us by the address authority (carrier or ANSI/ISO)?

->
->You will need to negotiate with your carrier on the allocation
->of bits in the address between carrier routing and your internal
->enterprise routing.
->

Basically we'd agree on what the high order bytes would be and then we'd be able
to manipulate and assign unique prefixes to each of our ports right?

->If you are extremely large, like the US Department of Defense,
->there is more of an argument for acquiring your own address space.
->
->Production SVC service is still a bit rare. ATT in the US has it
->now. Many carriers plan it later in the year. There are few (to
->none) carrier interconnection agreements for PVC's, and none
->for SVC's I know of. The usual method is SVC tunneling.

So it's pretty much all manual PVC building right now.  I understand how ILMI
will take a load off a network administrator's back.  When that time comes it'll
be very important to make use of ILMI for address negotiation.

->
->Your enterprise numbering should be topologically significant within
->its own ATM routing domain.As well it should be one format.

Tell me if I have this right:

Let's say I divide the US into six geographic regions A through F.  I'd assign
(as determined with my carrier) a certain number of high order bytes of the
HO-DSP to each of my ATM nodes.  So let's say, every node within each region
would be numbered with an address that one, identified it as part of the region
routing domain, and two, identified the specific ATM node.  Each port on each
ATM node would be uniquely identified by it's port prefix as part of a specific
ATM node within a specific routing domain.  From what I've read, each regional
routing domain (group) elects a peer group leader to communicate with each of
the other routing domain peer group leaders.

In the event that a call needs to be established from an end station off an ATM
node in routing domain A to an end station off an ATM node in routing domain F,
all the routing requests and call/path setup are handled by the peer group
leaders whom know about how to get to each routing domain, and thusly know how
to reach each port on any ATM node.  Is this about right??  All the reading I've
been doing seems to just blend all together.  I need a comprehension check!

->
->If you obtain carrier addresses, or even if you use your own,
->you may need to renumber in the future. ILMI address registration
->helps.

Well, I hope we don't have to come to that.  It's not fun!!

Tks for any and all comments and pointers to additional information.


Doug


->
->R. Wilcox
->Electric Lightwave
->
->
->
->
->
->Doug McClure wrote:
->
->> I'm doing research on the different ATM addressing schemes for a planned large
->> backbone ATM network.
->>
->> What ATM address method should be used?  Private E.164, DCC, and ICD or native
->> E.164?  If the network connected to a public ATM carrier, what would I have to
->> use?  I assume I would have to use the standard they're using.  Is there a
->> standard addressing scheme for all public ATM carriers? What do domestic ATM
->> carriers (MCI/ATT/Sprint/UUNet/WorldCom, etc) use for ATM addressing formats?
->> Should address space be acquired or just delegated from the upstream provider?
->>
->> If the backbone network is a mesh of private links and public links, what are
->> the recommended addressing formats to use?  Should it be consistent across the
->> network?  If the network is all private, what format should be used?  All
->> public?
->>
->> Are there advantages/disadvantages in addressing a large scale ATM backbone in
->> one format vice another?
->>
->> Thanks for any pointers, links and advice.
->>
->> Doug
->
->