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

From: "Javier Pastor-Balbas (ECE)" <[email-masked]>
Date: Mon, 3 Jun 2002 14:45:13 +0200

Hi Brian, 

Please, see below...

> -----Original Message-----
> From: Brian F. G. Bidulock [mailto:[email-masked]]
> Sent: Monday, June 03, 2002 11:26 AM
> To: Tolga Asveren
> Cc: [email-masked]
> Subject: Re: [Sigtran] IPSP vs AS (was RE: sg-sg communication)
> 
> 
> 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
> 

Brian , this is the modeling you have created for that. I don't think this is a good option taking into account the problems it creates. Even you showed those problems when trying to apply this model to the IPSP draft. Therefore I would say, this model is NOT valid. Use instead the IPSP model as a whole and combine it with the ASP to get the AS-SG scenario working at the same time.

                               +-----------------------+
               M3UA            |                       |
               Layer:          | Functions common to   |
               ASP/IPSP        |                       |
               implementation  |       ASP/IPSP        |
                               |                       |
                               |-----------+-----------|
                               |   ASP     |   IPSP    |
                               | Specific  |  Specific |
                               |  Funcs.   |   Funcs.  |
                               +-----------+-----------+

> Aside from this half-duplex exchange of data, what
> Javier described was almost this:
> 
>     _______                 _______  
>    |       |               |       | 
>    |  ASP  |<----\   /---->|  ASP  | 
>    |_______|      \ /      |_______| 
>     _______        X        _______  
>    |       |      / \      |       | 
>    |  SGP  |<----/   \---->|  SGP  | 
>    |_______|      one      |_______| 
>                assocation
> 

I said this could be possible, but I don't recommend this modelling. I see it as unefficient and difficult to deal with. See all the problems it has in the answers to the IPSP draft...

> And Javier recently said that this was possible:
> (which reinforces the view above)
> 
>    _________
>   | _______ |
>   ||       ||
>   || ASPF  ||<----\
>   ||_______||      \
>   | _______ |       \         _______  
>   ||       ||        \       |       | 
>   || SGPF  ||         \----->|  SGP  | 
>   ||_______||                |_______| 
>   |_________|
>      IPSP
> 

This could be a possible scenario in theory but I want to clarify my view:
	- It is not covered in the current M3UA draft
	- It can generate more problems not studied by this time
	- Does this network configuration have sense in real networks ?? IMO not.

> 
> I think that we agreed that these types of things
> were already possible (and even necessary) using
> backhaul like this:
> 
>     _______                 _______  
>    |       |               |       | 
>    |  ASP  |<----+   +---->|  ASP  | 
>    |_______|     |   |     |_______| 
>                 _|___|_ 
>                |       |
>                |  SG   |
>                |_______|
> 

I don't agree on needing a SG as the only way to communicate two ASes. I agree that IP-STP is possible, buy not the fastest and definitely the only way.

> 
> Or a single-ended model like this:
> 
>    _________                 _________
>   | _______ |               | _______ |
>   ||       ||               ||       ||
>   || ASPF  ||<----\         ||  ASPF ||
>   ||_______||      \        ||_______||
>   | _______ |       \       | ___|___ |
>   ||       ||        \      ||       ||
>   || SGPF  ||         \---->||  SGPF ||
>   ||_______||               ||_______||
>   |_________|               |_________|
>      IPSP                       IPSP
> 

Single Ended mode will be also easier and more efficient without implementing the criss-crossed model. Remember that you need to implement the new IPSP state machine for SE... 

=> An ASPF is even nor valid for that !!

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

To make this work, you should substitute ASPF with IPSP (or IPSPF). 

> We arrived at the better, true peer-to-peer SG-SG
> solution in this:
> 
>     _______                 _______  
>    |       |               |       | 
>    |  ASP  |               |  ASP  | 
>    |_______|               |_______| 
>        |                       |
>        |                       |
>     ___|___                 ___|___  
>    |       |               |       | 
>    |  SGP  |<------------->|  SGP  | 
>    |_______|               |_______| 
>

Yes, but I doubt people is interested in buying more SGs when IPSP communication make it possible to communicate two ASes

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

You can make it easier and cheaper if you integrate just the needed functions into an IPSP.

Cheers // Javier.

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

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

---

From: "Tolga Asveren" <[email-masked]>
Date: Mon, 3 Jun 2002 09:20:17 -0400

Hi Javier,

The point is, does the M3UA stack at the IPSP as you describe, need
additional functionality, state machines or messages, apart from the ones
already described for ASP and SGP cases? In my view, the first figure below
really reflects what is described as IPSP well. One combines SGPF and ASPF
(one can also draw it together as IPSF box, but I don't see any benefit on
this and I also don't think, this will eliminate any problems of this
model)in the same physical entity. As long as we define the same things,
what is the use of renaming ASPF+SGPF as IPSF? And if IPSF is not ASPF+SGPF,
what is the difference to make us believe that it is not the same? For
example if we draw the message flows
between two ASPF+SGPF boxes and between two IPSPF boxes, will there be a
difference there? Will there be a difference between the state machines they
keep? (or better said, do we need to make a difference there?)
BTW, another question is still pending, who are the endpoints of the
point-to-point IPSP communication? Does point-to-point mean a direct SCTP
association between to M3UA entities or a direct communication between two
AS? (for example I tend to think it means a direct SCTP association)

   Tolga

> Brian , this is the modeling you have created for that. I don't
> think this is a good option taking into account the problems it
> creates. Even you showed those problems when trying to apply this
> model to the IPSP draft. Therefore I would say, this model is NOT
> valid. Use instead the IPSP model as a whole and combine it with
> the ASP to get the AS-SG scenario working at the same time.
>
>
>
> I said this could be possible, but I don't recommend this
> modelling. I see it as unefficient and difficult to deal with.
> See all the problems it has in the answers to the IPSP draft...
>
> I don't agree on needing a SG as the only way to communicate two
> ASes. I agree that IP-STP is possible, buy not the fastest and
> definitely the only way.
>
> >
> Single Ended mode will be also easier and more efficient without
> implementing the criss-crossed model. Remember that you need to
> implement the new IPSP state machine for SE...
>
> Yes, but I doubt people is interested in buying more SGs when
> IPSP communication make it possible to communicate two ASes
>
>
>

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 3 Jun 2002 08:46:18 -0500

Javier,

Javier Pastor-Balbas (ECE) wrote:                          (Mon, 03 Jun 2002 14:45:13)

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

Nothing more, nothing less.  If IPSP is something different please
describe it in a coherent fashion.

As you and other have had over 6 months to do so, I don't think it
is possible.

--brian

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