Subject: RE: [SUA issue 17 & M3UA issue #11] IPSP cases - AN EXAMPLE! - OF F LIST

From: "Asveren, Tolga" <[email-masked]>
Date: Mon, 24 Sep 2001 08:13:42 -0500

Hi Amish,

Please see comments below and thank you for sharing your personal e-mails with us ;)

   Tolga

> -----Original Message-----
> From: Amish Chana [mailto:[email-masked]]
> Sent: Monday, September 24, 2001 7:39 AM
> To: sigtran
> Subject: RE: [SUA issue 17 & M3UA issue #11] IPSP cases - AN 
> EXAMPLE! -
> OF F LIST
> 
> 
> Hi Klaus,
> 
> >what an interesting thread (or is it really a threat? ;) )
> >If I understand you correctly you'd like to use RC's instead of SS7
> >addresses in the IP world?
> 
> Don't we already do that for IPSP? The RC value cuurently 
> used towards the 
> SGP is the source RC while for SGP to ASP and IPSP to IPSP we 
> insert the 
> destination's RC. I am simply saying that for ASP to SGP the 
> RC should have 
> some relavance to the destination.
[TOLGA] In draft8, for ASP->SG traffic, DPC reachability information is used (although it is said :and possibly other elements of the outgoing message such as the SLS value)to select a SG. I don't know yet, whether RC will be there in DATA for ASP->SG case in draft9. But even if like this, still it would have a different meaning than RC in SG->ASP case. In SG->ASP case, RC is used to select the correct ASP and is shipped in DATA message, so that on ASP side no additional RK analysis is needed, if more than one ASs are served via the same association.
For ASP->SG direction, one can use RC to select SG, but again this should be the same RC, which was used for SG->ASP case. Because for ASP->SG it is important to select a SG, with which ASPAC-ASPACACK message exchange is done (to select SG based on RC is not something mandated by draft, I speak just for the case, if one wants to do it in this way)My personal opinion is that selecting SG by considering ASPAC-ASPACACK message exchange can be usefull for screening on SG side and to allow messaging to be on or off in both directions for two PCs (although there were also discussions whether one should allow messaging path to be open only in one direction or not, again that it should be on or off for both directions is my personal opinion)
If you want to change the RC mechanism for ASP->SG case, then to be able to provide services described above, you will need to put two RC value in DATA message, one RC=DPC, whihc you are proposing, the other one the RC, which was used for ASPAC-ASPACACK messaging.
> 
> >And to avoid having to deal with SS7 addresses in
> >nodes communicating with both worlds you equate RC=DPC for 
> traffic going to
> >an SS7 node?
> 
> You cannot use RCs in SS7 protocols.
> 
> >If RC=address then don't we need a source and a destination RC? 
> >Specifically
> >if you've got IP-STPs?
> >
> 
> If all the nodes support IP do you think IP-STPs are necessary?
> Do you think it is necessary to re-built the SS7 network over 
> an IP network?
> 
[TOLGA] I think what you are saying is that IP routers are enough in IP domain. Still, I wouldn't ignore the idea of a M3UA-Router. Sometimes it can be usefull to have M3UA specific information to route more cleverly. But I also have the impression, that when in draft it is said "IPSP uses M3UA in a point to point fashion", what meant is that no M3UA routers are foreseen in the proposed architecture. 
> 
> _________________________________________________________________
> Get your FREE download of MSN Explorer at 
http://explorer.msn.com/intl.asp

---
You are currently subscribed to sigtran as: [email-masked]
To unsubscribe send a blank email to [email-masked]

---
You are currently subscribed to sigtran as: [email-masked]
To unsubscribe send a blank email to [email-masked]

---

From: Al Varney <[email-masked]>
Date: Mon, 24 Sep 2001 12:13:13 -0500

At 08:13 AM 9/24/01 -0500, Asveren, Tolga wrote:
> > ...
>[TOLGA] I think what you are saying is that IP routers are enough in IP 
>domain. Still, I wouldn't ignore the idea of a M3UA-Router. Sometimes it 
>can be usefull to have M3UA specific information to route more cleverly. 
>But I also have the impression, that when in draft it is said "IPSP uses 
>M3UA in a point to point fashion", what meant is that no M3UA routers are 
>foreseen in the proposed architecture.

    On the road to Nirvana (where SS7 merges into the one-ness of IP and 
only firewalls filled with NATs pester our existence), I think M3UA-Routers 
(and SUA-Routers) will exist.

    Imagine 2 ASPs [A,B] with M3UA associations to a pair of SGPs, each ASP 
having an SS7 Point Code (provided via the SGPs).  These ASPs communicate 
occasionally with another SS7 node [C] through the SGPs.  Seeking nirvana, 
node C becomes IP-aware and begins using the same SGPs for access to the 
SS7 network.  To minimize reconfiguration of other SS7 nodes, the SGPs 
assume Point Code C in addition to A & B.

    I'm assuming M3UA messages are now "routed" through the SGPs without 
actual use of SS7 links.  In effect, the SGPs become M3UA-Routers for 
[A->C] and [C->A] messages.  If these SGPs happen to support STP 
functionality for other SS7->SS7 traffic, I think it would be easy to call 
them "IP-STPs".  These STPs could continue to support gateway screening, 
accounting, message monitoring and Global Title Translation as they did 
before node C was enlightened.  No new M3UA "F-link" associations would be 
needed at A and B.

    The magic of Registration and RK/RC will handle adding this to the 
SGPs, right?  A & B won't know or care.  It's not quite IPSP-to-IPSP, and 
it still needs SS7 Point Codes, but that's OK.  Unlike the one-ness of IP, 
you can't run out of Point Codes.  Just create another SS7 network with a 
whole new set of Point Codes.  And interwork them at the IP-STPs.    Hmmm 
... maybe I've been on vacation too long???

Al Varney  --  [email-masked]

---