Subject: Re: [Sigtran] IPSP vs AS (was RE: sg-sg communication)

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 3 Jun 2002 04:26:27 -0500

Tolga,

Yes, the criss-cross is clear in the data flow described:

> - Send data msg to the other IPSP in the way an SGP sends a
> message to an ASP

   _________                 _________
  | _______ |               | _______ |
  ||       || DATA     DATA ||       ||
  || ASPF  ||<----\   /---->||  ASPF ||
  ||_______||      \ /      ||_______||
  | _______ |       X       | _______ |
  ||       ||      / \      ||       ||
  || SGPF  |+-----/   \-----+|  SGPF ||
  ||_______||               ||_______||
  |_________|               |_________|
     IPSP                       IPSP

Aside from this half-duplex exchange of data, what
Javier described was almost this:

    _______                 _______  
   |       |               |       | 
   |  ASP  |<----\   /---->|  ASP  | 
   |_______|      \ /      |_______| 
    _______        X        _______  
   |       |      / \      |       | 
   |  SGP  |<----/   \---->|  SGP  | 
   |_______|      one      |_______| 
               assocation

And Javier recently said that this was possible:
(which reinforces the view above)

   _________
  | _______ |
  ||       ||
  || ASPF  ||<----\
  ||_______||      \
  | _______ |       \         _______  
  ||       ||        \       |       | 
  || SGPF  ||         \----->|  SGP  | 
  ||_______||                |_______| 
  |_________|
     IPSP

I think that we agreed that these types of things
were already possible (and even necessary) using
backhaul like this:

    _______                 _______  
   |       |               |       | 
   |  ASP  |<----+   +---->|  ASP  | 
   |_______|     |   |     |_______| 
                _|___|_ 
               |       |
               |  SG   |
               |_______|

Or a single-ended model like this:

   _________                 _________
  | _______ |               | _______ |
  ||       ||               ||       ||
  || ASPF  ||<----\         ||  ASPF ||
  ||_______||      \        ||_______||
  | _______ |       \       | ___|___ |
  ||       ||        \      ||       ||
  || SGPF  ||         \---->||  SGPF ||
  ||_______||               ||_______||
  |_________|               |_________|
     IPSP                       IPSP

And that one doesn't need the non-protocol part in
the SG if one doesn't want it.

I think we also agreed that the following was not
useful, interesting or even possible:

   _________                 _________
  | _______ |               | _______ |
  ||       ||               ||       ||
  || ASPF  ||<------------->||  ASPF ||
  ||_______||               ||_______||
  |_________|               |_________|
     IPSP                       IPSP

We arrived at the better, true peer-to-peer SG-SG
solution in this:

    _______                 _______  
   |       |               |       | 
   |  ASP  |               |  ASP  | 
   |_______|               |_______| 
       |                       |
       |                       |
    ___|___                 ___|___  
   |       |               |       | 
   |  SGP  |<------------->|  SGP  | 
   |_______|               |_______| 

And, again, one doesn't need the non-protocol part
int the SGP if it is not required to interconnect
to the SS7 network.

Then there is nothing stopping one from building
a true peer-to-peer IPSP like this:

   _________                 _________
  | _______ |               | _______ |
  ||       ||               ||       ||
  || ASPF  ||               ||  ASPF ||
  ||_______||               ||_______||
  | ___|___ |               | ___|___ |
  ||       ||               ||       ||
  || SGPF  ||<------------->||  SGPF ||
  ||_______||               ||_______||
  |_________|               |_________|
     IPSP                       IPSP

I wish we would get on with discussion on these
last two models (SG-SG) as they are the useful ones.
Discussion on this schyzophrenic DE IPSP model are
worthless and have achieved nothing but the confusion
unfortunately included in the RFC.

--brian

Tolga Asveren wrote:                                        (Fri, 31 May 2002 13:08:03)
> Javier,
> 
> > I was very involved from the beginning in the IPSP discussions
> > and I can tell you that the idea was never having a criss-crossed
> > model. In addition I think this is only a model you can use, but
> > for me much better models exists...
> >
> > What really happened is that we included the two approaches to
> > close the RFC, because discussions had no end.
> [TOLGA] I was also involved on those discussions from the very beginning.
> For DE, from protocol point of view, the idea was to make this happen with
> the defined ASP/SGP state machines and with already defined messaging. That
> was the reason, why people were attracted by it (including me). If one does
> not have SS7 connectivity, it is obvious that no MTP3 interworking is
> necessary, but this already belongs to non-protocol part. For example there
> is a nice message from you explaining the DE approach during the initial
> IPSP discussions. I think, it shows well, what people at that time were
> referring to as DE approach.
> 
> (Date of message is 11/6/01)
> Hi Amish,
> 
> >From my point of view, IPSP needs to:
> 
> - Send data msg to the other IPSP in the way an SGP sends a message to an
> ASP
> - Receive data messages and distribute them to the ASs in the same way ASP
> does
> it
> - Send ASPSM and ASPTM in the same way ASP does
> - Receive and treat ASPTM and ASPSM in the same way as SGP.
> 
> 
> Other classification of IPSP functionality:
> 
> As an SGP
> - Send data msg to the other IPSP in the way an SGP sends a message to an
> ASP
> - Receive and treat ASPTM and ASPSM in the same way as SGP.
> 
> As an ASP
> - Receive data messages and distribute them to the ASs in the same way ASP
> does
> it
> - Send ASPSM and ASPTM in the same way ASP does
> 
> (This last point has the particularity that only one ASP-UP is needed. When
> an
> IPSP receives an ASPUP and sends back an ASPUP-Ack it does not need to send
> another ASPUP to the peer and can consider the peer as INACTIVE)
> 
> 
> Cheers // Javier.
> 
> 
> _______________________________________________
> Sigtran mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/sigtran

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

_______________________________________________
Sigtran mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/sigtran