Subject: Re: SG as STP

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 7 Nov 2001 17:25:12 -0600

John,

John Schantz wrote:                                          (Wed, 07 Nov 2001 14:16:39)
> You are taking "backhaul" again.  ONLY in backhaul would an AS be
> considered a user of SG's (think of front-end (SG), back-end (AS) with
> M3UA or M2UA as the inter-connecting protocol).
> 
> In the non-backhaul, the AS is NEVER a user of the SG (its protocol
> stack).  It is a user of its own node's protocol stack (could be M2PA,
> M3UA, or SUA).  And there is a "network" connection between the node and
> the SG(s) or other nodes (IPSPs).
> 
> SG as an STP is more applicable to the non-backhaul case.

This is true; however, Greg did not want to address SG/STP with
a peer-to-peer protocol, but rather preferred to "fudge" the
backhaul case.  Even still SG/STP cannot be handled directly
and appropriately because IPSP only handles point-to-point and
has not even begun to address trasfer/relay node operation or
IPSP operating with SS7 network connections.  These things are
all still deferred to extension drafts.

So all we have for SG/STP currently is a fudge to the backhaul
case, where the AS are viewed as local users to the SG.  They
are not necessarily viewed as local to the STP.

--brian

> 
> John
> 
> > -----Original Message-----
> > From: Dennis Niermann [mailto:[email-masked]]
> > Sent: Wednesday, November 07, 2001 3:57 PM
> > To: sigtran
> > Subject: Re: SG as STP
> > 
> > 
> > Brian,
> > If an AS is always considered a local user of a SG MTP3,
> > and if the AS is reachable via two SGs,
> > is that AS considered a local user of both SG MTP3s?
> > /Dennis
> > 
> > "Brian F. G. Bidulock" wrote:
> > > 
> > > Dennis,
> > > 
> > > Dennis Niermann wrote:   (Wed, 07 Nov 2001 14:03:59)
> > > >
> > > > I would like to describe what I think is a major influence
> > > > on the different expectations concerning IPSP-IPSP.
> > > > It is based on how you view M3UA for the SG-ASP case.
> > > >
> > > > M3UA view 1:
> > > > M3UA is to MTP3 as M2UA is to MTP2.
> > > > I.e., M3UA provides a way to present the
> > > > upper interface of MTP3 (really in the SG)
> > > > to a User Part in a remote IP node.
> > > > With this view you could think of the AS's
> > > > in the M3UA IP node as the "local users" of
> > > > MTP3 in the SG.
> > > >
> > > > M3UA view 2:
> > > > M3UA view 1 is a very good way to conceptualize the
> > > > role of M3UA for the case of a SPMC, i.e. when the
> > > > SG acts a signalling end point in the SS7 network.
> > > > But, M3UA also supports SGs as STPs. And in the case
> > > > of SG as an STP, M3UA view 1 does not apply.
> > > > For the STP case, the SG is its own point code and
> > > > various other point codes are used by the ASs.
> > > > Thus, the ASs can not be viewed as local users
> > > > of the SG MTP3 stack.
> > > 
> > > In fact the AS are always viewed as local uses of the
> > > SG MTP3 stack.  See the overview for M3UA.
> > > 
> > > >
> > > > Acceptance of the fact that the STP mode for a
> > > > SG is allowed and is needed has a very significant
> > > > impact on one's perception and viewpoint on the IPSP-IPSP
> > > > case.
> > > 
> > > Yes.  If an IPSP has transfer capabilities, it will even
> > > more clearly necessary to use SNMM and even more clearly
> > > pointless to use ASPTM.  Or did you want the IPSP with
> > > transfer capability to proxy register all of the AS on all
> > > of the IPSPs with all of the IPSPs that it is connected to?
> > > 
> > > If you consider that an IPSP could also communicate with
> > > the SS7 network, it would be impossible to do proxy-
> > > registration of AS.
> > > 
> > > When you consider transfer/relay, approach (A) is even more
> > > clearly unworkable.  Approach (B) however, already supports
> > > this:  AS can communicate today via SG/STPs.
> > > 
> > > --brian
> > > 
> > > --
> > > Brian F. G. Bidulock
> > > [email-masked]
> > > http://www.openss7.org/
> > > 
> > > ---
> > > You are currently subscribed to sigtran as: 
> > [email-masked]
> > > To unsubscribe send a blank email to 
> > [email-masked]
> > 
> > -- 
> > ---------------------------------------------------------------
> >  Dennis Niermann              [email-masked]
> >  Ericsson Network Systems   
> >  Richardson, Tx 75081
> > 
> > 
> > ---
> > 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]

-- 
Brian F. G. Bidulock
[email-masked]
http://www.openss7.org/

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