Subject: Re: simple ASP-ASP communication via SG

From: Tolga Asveren <[email-masked]>
Date: Tue, 6 Nov 2001 16:23:46 -0800 (PST)

Hi,

Lets consider the following configuration:

   +---------+         +---------+
   |         |         |         |
   |  ASP1   |         |  ASP2   |
   |         |         |         |
   +--------++         ++--------+
            |           |
            |           |
            |           |
            |           |
            |           |
            |           |
           ++-----------+
           |            |
           |            |
           |    SG1     |
           |            |
           +------------+

It seems, to make everything work as much as possible
like in SG/ASP case is the main goal. Then let's keep
ASPs the same. On SG just process messages arriving
from ASPs a little bit different then the SG/ASP case.
First look whether they match one of the RKs on IP
domain. If yes, forward them to that ASP if not send
them to SS7 network. This works very similar what
Dennis described in one of his messages, the only
difference is that SG functionality and ASP
functionality are not in one box, they are separate
like in normal ASP-SG case. All of messaging works
like in SG/ASP case. In fact this is not a suprise,
because this is almost the same with SG/ASP case, with
a minor change on SG.
The drawback of this model is that it is not point to
point. But why do we want to have point to point
communication? What is the benefit of it?
One can think that this method is going to create a
bottleneck on SGs. But in every model proposed till
now, every message is going either through a SG or
through an entity with combined ASP-SG functionality.
So, if one is able to have a network without
bottlenecks with those models, it should be possible
also with this one. Also, one can put SG and ASP in
one box, which would correspond to the model of
Dennis.
There isn't much difference, just here it is more
visible that it follows the same logic like existing
SG/ASP case.

    Tolga

--- "Brian F. G. Bidulock" <[email-masked]>
wrote:
> Javier,
> 
> Javier Pastor-Balbas (ECE) wrote:                   
>       (Tue, 06 Nov 2001 19:04:19)
> > Brian, 
> > 
> > Comments below...
> > 
> > > -----Original Message-----
> > > From: Brian F. G. Bidulock
> [mailto:[email-masked]]
> > > Sent: Tuesday, November 06, 2001 6:39 PM
> > > To: sigtran
> > > Cc: [email-masked]
> > > Subject: Re: Consensus Call - Routing Key
> > > 
> > > 
> > > Amish,
> > > 
> > > Excellent idea!
> > > 
> > > We already know that AS can communicate
> peer-to-peer
> > > via one or more SGs and possibly via the SS7
> network
> > > between SGs.  So we have:
> > > 
> > >     ____________          ____________     
> > >    |   ______   |        |   ______   |    
> > >    |  |      |  |        |  |      |  |    
> > >    |  |  AS  |  |        |  |  AS  |  |    
> > >    |  |______|  |        |  |______|  |    
> > >    |     |      |        |     |      |    
> > >    |   __|___   |        |   __|___   |    
> > >    |  |      |  |        |  |      |  |    
> > >    |  | ASP  |  |        |  | ASP  |  |    
> > >    |  |______|  |        |  |______|  |    
> > >    |     |      |        |     |      |    
> > >    |   __|___   |        |   __|___   |    
> > >    |  |      |  |        |  |      |  |    
> > >    |  | SGP  |__|________|__| SGP  |  |    
> > >    |  |______|  |        |  |______|  |    
> > >    |____________|        |____________|    
> > >         IPSP                  IPSP
> > > 
> > > So we know that this will work peer to peer.  If
> we
> > > draw a box around the peers in this arrangement
> we
> > > have an IPSP.
> > > 
> > > Communication between IPSP needs to replace
> communication
> > > between SGs as show to be able to support
> peer-to-peer
> > > operation.  Several points can be made off the
> start:
> > > 
> > >   1.)  RC is not required.  SGs do not need RC
> > >        to communicate between themselves.
> > > 
> > RC is required if your ASP serves more than one
> AS.
> 
> RC is only required for the AS/SG case.  For IPSP is
> is
> clearly not require as it is arlready possible for
> two
> AS to communiate via SGs without a single exchange
> involving RC outside the IPSP: see diagram.
> 
> > 
> > >   2.)  Regsitration is not required.  SGs do not
> > >        register with each other.
> > > 
> > If Registration is not required your model is not
> valid since
> > it works only statically. Operators don't want
> that. It can be
> > a proprietary protocol.
> 
> SS7 networks are statically configured.  Didn't you
> know that?
> There is no route discovery protocol in SS7.  If two
> point
> codes have not been statically assigned routes
> through the SS7
> network they will simply not exchange MSUs.  I can't
> believe
> that you don't know that!
> 
> > 
> > >   3.)  SNMM is required.  SGs exchange SNMM
> messages.
> > > 
> > SNMM is required only when translating TFP, etc
> msgs from the
> > SS7 network to the IP network. Don't make sense in
> all-IP
> > commmunication. You have there other means as
> ASPIA, ASPAC, no
> > routes restricted, no need to audit anyghing and
> SCTP
> > congestion control mechanisms
> 
> They make plenty of sense, they are the only thing
> that
> translate directly into the User primitives and
> leave the
> status in the correct location.
> 
> > 
> > >   4.)  IPSPs control an entire point code
> (because
> > >        the SGs control an entire point code.
> > > 
> > You don't need to create that restriction. IPSP
> can control a
> > portion of the traffic to one entire point code as
> it is done
> > by ASP.
> 
> No, ASP merely exports the SS7/User interface.  The
> SG controls
> the point code, as it must, and is responsible for
> communicating
> the status of the SPMC to SS7-Users in the manner in
> which they
> require it, which corresponds to SNMM and are
> treated on a
> per-point code basis.  This is a necessary
> restriction.
> 
> > 
> > >   5.)  We need a mechanism like ASPUP/DN single
> ended
> > >        to enable traffic between SGs.  That
> should do.
> > >        Don't even really need ASPAC/IA because
> we don't
> > >        have RCs and we don't do RKMM.
> > > 
> > 
> > ASPUP/DOWN needed between two IPSPs. I agree with
> that. But
> > also you need to activate/deactivate the AS RKs...
> 
> 
> Nope.  Don'e need RCs and don't need ASPTM
> containing RCs.
> 
> > 
> > >   6.)  We need to exchange PDUs (DATA and SNMM).
> > > 
> > We need to exchange ASPSM, ASPST and DATA. And we
> have to
> > allow to exchange RRM for the implementations they
> want to.
> 
> Sorry, look at the diagram.  The SG's exchange DATA
> and
> SNMM.  Aside from the ASPSM messages.  But ASPTM is
> not
> required.
> 
> > 
> > > Looks like were done.  We have an IPSP.  Because
> an
> > > SG can also be an STP and have the
> relay/transfer
> > > function, this will be adequate for the
> relay/transfer
> > > case as well.  Configure the SG as you would an
> SEP
> > > or STP.
> > > 
> > 
> > Man, you have created a monster...  ;-)
> 
> It already works. AS can communicate to each other
> via SGs.
> This is requirement for SCCP.
> 
> What is it that you cannot stand about this
> arrangement?
> It is fully functional.
> 
> > 
> > The main thing here is that it seems that you
> don't have a
> > clear idea of what you want.
> 
> The clear objective is to place the minimum and
> sufficient
> information exchange between SGP to provide
> peer-to-peer
> communications.  That is the existing M3UA messages.
>  Some
> messages which apply only to ASPs are not required
> as these
> are now internal relationships to the node that need
> not
> 
=== message truncated ===

__________________________________________________
Do You Yahoo!?
Find a job, post your resume.
http://careers.yahoo.com

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 6 Nov 2001 19:04:18 -0600

Tolga,

Tolga Asveren wrote:                                        (Tue, 06 Nov 2001 16:23:46)
> Lets consider the following configuration:

No change to SG is required to do this.  AS can
communicate via the SG today, with no change.
NIF takes message from xUA and via SS7 stack puts
it back in xUA.  If ASP1 supports AS1 with PC=1
and ASP2 supports AS2 with PC=2, when AS1 sends
data to DPC=2, the SG will transfer it from AS1
to AS2 without any "minor changes" to the SG.

SCCP (and thus SUA) requires this behavior even
in a node that does not have the MTP transfer
function.

> one box, which would correspond to the model of

See Amish's other note.  The difference is in whether
the ASP functions in the box communicate with the
SGP functions outside the box.  It is sufficient that
SGP function communicate in a fully symmetrical
peer-to-peer fashion with other SGP fuctions, leaving
the ASP and AS internal to the node.

> visible that it follows the same logic like existing

All that you have presented is the current AS/SG case.
AS can communicate via SG today.

--brian

> You are currently subscribed to sigtran as: [email-masked]

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

---

---

From: [email-masked]
Date: Wed, 7 Nov 2001 05:14:50 -0800

Hi Brian,

Please see comments below.

  Tolga

> From:   "Brian F. G. Bidulock" <[email-masked]>
> Sent:   Tuesday, November 06, 2001 8:12 PM
> To:     "sigtran" <[email-masked]>
> Subject:     Re: simple ASP-ASP communication via SG
>
>  Tolga,
> Tolga Asveren wrote:
[TOLGA] If you say this is working, then why do you say that the following
is not working

   ***************         ***************
   *             *         *             *
   *             *         *             *
   *   +-----+   *         *  +----+     *
   *   | ASP1|   *         *  |ASP2      *
   *   |     |   *  +------*--+    |     *
   *   +-----+---*--+--+   *  +----+     *
   *   +-----+   *  |  |   *  +----+     *
   *   | SG1 |   *  |  |   *  | SG2|     *
   *   |     +---*--+  +---*--+    |     *
   *   +-----+   *         *  +----+     *
   *             *         *             *
   *             *         *             *
   *             *         *             *
   ***************         ***************

      IPSP1                     IPSP2

Everything is the same, just both ASP and SG are put in the same box.

> > 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]

---

---

From: Amish Chana <[email-masked]>
Date: Wed, 07 Nov 2001 14:00:12 +0000

Tolga,

Refer to email Brian sent about 14 hours before this email for a answer to 
your question.

Since the combined SG/ASP is able to satisfy both views why don't we settle 
on an IPSP as being a SG/ASP. There is no need to add additional 
functionality to the pure ASP and SG functional entities. If could simply 
define a IPSP to be a ASP+SG and make no further mention of IPSP in the 
drafts. Whichever method is finally used in a deployment depends on how the 
IPSP is implemented.

Amish.

>You are currently subscribed to sigtran as: [email-masked]

_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp

---

---

From: [email-masked]
Date: Wed, 7 Nov 2001 06:21:05 -0800

Hi Amish,

   Tolga

> From:   Amish Chana <[email-masked]>
> Sent:   Wednesday, November 07, 2001 9:07 AM
> Cc:
> Subject:     RE: Re: simple ASP-ASP communication via SG
>
>  Tolga,
[TOLGA] Isn't what you are saying the model which puts both SG/ASP in the
same IPSP box? You put conventional SG logic and ASP logic there and use it
as in the SG/ASP case. Or do you mean something else?

---