The IP over ATM Mailing List Archive by date

Cell Relay Retreat>List Archive>month:1996-Jan> msg00274



[Date Prev][Date Next][Thread Prev][Thread Next]  
  [Date Index][Thread Index][Author Index][Subject Index]

IP flatnet <> ATM flatnet

  • From: bryang@eng.adaptec.com (Bryan Gleeson x3228)
  • Date: Tue, 30 Jan 96 19:05:02 PST


Lode,

>The routing of that message is based on the digits of 
>the universal number(take 1-800-GLEESON).  The orignator node put the number 
>in the message and the network layer of the orginator node(=A) will translate 
>this number based on the first 2 or 3 digits to a pointcode, of a node(B) 
>which the originator node thinks is nearer to the final destination(=D)....

>Now the message is routed using the generated pointcode to the  B node( just 
>the same as IP does with its DPC, OPC is left alone). When the message arrives 
>in the B nodes then ihe networklayer will find that this is not the final 
>destination, so yet another translation is performed on the number, yielding 
>another pointcode(this time of the node C) The rules to which this translation 
>confirms are under the discretion of the network operator ...

>Now in C the we cross a 
>network border, that means  we are going from one operator to another operator 
>network Here also a translation is done on the called part addres(=destination 
>number), but the calling party address of node A  is also changed, because 
>otherwise the return message would not be able to find A back....
>

Let's see if I have this right. Database updates and queries are made using a full 
transaction protocol / remote operations / SCCP / MTP stack. To progress a
query or update towards the database, (or indeed any message)  there are multiple 
global title -> next hop point code translations performed along the way, by the SCCP 
layer, using a predefined table of some sort at each sigalling point to do this 
translation.  At an administrative boundary a "new" request is generated which is in 
effect chained to the old one. 

If anything the closest thing to IP -> ATM address mapping is the global title to
point code mapping, rather than the 800 number to current location number, which
I guess is translating one global title into another and is more like a DNS name 
to IP address mapping.

(BTW what does all this next-hop determination and chained requests at boundaries
remind you of :-)


>The only premise is that the application and the ASE supplying the remote 
>operation concept must be the same.  This is not always the case: The rest of 
>the world has standaized itself on a ITU SS7 stack with ITU or ETSI defined 
>applications(called sometimes CCS7 for Common channel signalling nr 7). The US 
>and Canada are using a ANSI SS7 stack with ANSI defined applications. The good 
>news is that up to and including the network layer, the functionalty and 
>syntax of the message is the same. The bad new is that the application layer 
>And what is worse internetworking between the US and the Rest of world 
>is not considered usefull at this moment.(turning the US into a SS7 island) To 
>a European used to crossing networks borders at will  in the SS7 networks, 
>this is nearly impossible to believe.


Actually I find this quite easy to believe !


>If everbody has a universal number, then everybody has a database entry 
>somewhere in a node somewhere in the world. To obtain number portability, a 
>commonly owned database can be used(distributed of course over a number of 
>nodes) or a redirection to the second operator  in the database of the first 
>operator could be installed. 
>
>As for the number of entries in a database, in a GSM or IS-41 net, a HLR can 
>contain more than 200 000 entries, and most of these people willl be moving, 
>so the location update alone will be generating most traffic. So short 
>transaction over a connectioless network are indeed used, even in a telephone 
>system.
>


Hmm... makes doing ATMARP for 10000 hosts seem quite tame by comparison.
Now maybe if we could just get the Americans and the Europeans to insist on
different packet formats or something it might be a bit more challenging :-)

Bryan Gleeson,
Adaptec.