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

From: "Tolga Asveren" <[email-masked]>
Date: Mon, 3 Jun 2002 10:33:35 -0400

Javier,

> -----Original Message-----
> From: Javier Pastor-Balbas (ECE)
> [mailto:[email-masked]]
> Sent: Monday, June 03, 2002 10:10 AM
> To: 'Tolga Asveren'; [email-masked]
> Subject: RE: [Sigtran] IPSP vs AS (was RE: sg-sg communication)
>
>
> Hi Tolga,
>
> Please, see below...
>
> > -----Original Message-----
> > From: Tolga Asveren [mailto:[email-masked]]
> > Sent: Monday, June 03, 2002 3:20 PM
> > To: [email-masked]
> > Subject: RE: [Sigtran] IPSP vs AS (was RE: sg-sg communication)
> >
> >
> > 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?
>
> As we have discussed and is already stated in the draft, if we
> select SE, we need a NEW state machine. The messages are already
> there and specified in the IPSP draft.
[TOLGA] For SE you are right. But here what I mean is DE, the criss-crosseed
model.
>
> > 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?
>
> It's just to follow your naming.  ;-)
>
> > And if IPSF is
> > not ASPF+SGPF,
>
> Yes, as ASPF is not the same as 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?
>
> Read the comments from Brian to the IPSP draft and you'll find
> why it is not the same. You are just modelling it in a way that
> you thought that was the best, but when you apply it to the
> different scenarios you can see that there are other ways of doing things.
[TOLGA] I think, you are confusing ASPF+SGPF with ASP+SGP. My point is not
that one can achieve it by putting one ASP and one SGP to the same box
(although one can do it) Important is the behavior of the endpoints, and it
behaves exactly like the defined endpoints for ASP and SGP case.
>
> IETF does not define node architectures, but protocols. The
> internal node architecture is implementation dependent. You can
> use your criss-crossed model to model the IPSPs, although I don't
> recommend it...
[TOLGA] This is exactly my point. If the defined state machines and messages
are enough for DE, there is no need to advertise it as something different.
Why do you think, I am trying to define a node type? I thought you are
trying to do it, because you want to give ASPF+SGPF a special name.
>
> > Will there be a difference between the
> > state machines they
> > keep? (or better said, do we need to make a difference there?)
>
> Most of people prefer SE, and SE does not follow the ASP state
> machine. This is already stated in the current RFC. Therefore a
> new state machine diferent from the ASP's is needed.
[TOLGA] SE means between two AS. It is not just about sending ASPUP once or
twice. In fact if we really decide for SE, then we can forget about DE
discussions, I think there is no reason to discuss about something, which is
not going to be defined in the draft.
>
> > 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)
>
> Yes, it's a direct association between the two IPSPs that serve
> different ASes.
[TOLGA] This question directly affects the nature of RKs. If it is between
two AS, then the RK should define both ends, otherwise there will be local
and remote RKs (DE). Although I believe, what initially meant was just
direct SCTP association, point-to-point between AS will eliminate problems
of DE case.
>
>
>
> Cheers // JAvier.
>
>
>
> >
> >    Tolga
> >
> > > 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
> >

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 3 Jun 2002 09:33:37 -0500

Javier,

Javier Pastor-Balbas (ECE) wrote:                          (Mon, 03 Jun 2002 16:09:30)
> > 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? 
> 
> As we have discussed and is already stated in the draft, if we select SE, we
> need a NEW state machine. The messages are already there and specified in
> the IPSP draft.

I disagree.  SE does not require any additional or new state machines as
illustrated in my previous note.

> 
> > 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? 
> 
> Read the comments from Brian to the IPSP draft and you'll find why
> it is not the same. You are just modelling it in a way that you
> thought that was the best, but when you apply it to the different
> scenarios you can see that there are other ways of doing things.
> 

IETF defines functional and node architectures: what did you think
that the SIGTRAN Architectural Framwork RFC was?

> 
> > Will there be a difference between the state machines they keep?
> > (or better said, do we need to make a difference there?)
> 

Incorrectly stated.  SE does not require any new state machines.  On
the other hand you have told us that DE requires different state
machines.

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

That statement doesn't clarify anything.

--brian

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 3 Jun 2002 09:45:56 -0500

Tolga,

Tolga Asveren wrote:                                        (Mon, 03 Jun 2002 10:33:35)
> not going to be defined in the draft.

I agree, Tolga.  I propose that we abandon DE discussions altogether
as a failed concept.

Can we start talking about SG-SG?

--brian

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

---

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

Hi Tolga, 

Please, see below...

> already described for ASP and SGP cases? 

As we have discussed and is already stated in the draft, if we select SE, we need a NEW state machine. The messages are already there and specified in the IPSP draft.

> between two ASPF+SGPF boxes and between two IPSPF boxes, will 

Read the comments from Brian to the IPSP draft and you'll find why it is not the same. You are just modelling it in a way that you thought that was the best, but when you apply it to the different scenarios you can see that there are other ways of doing things.

IETF does not define node architectures, but protocols. The internal node architecture is implementation dependent. You can use your criss-crossed model to model the IPSPs, although I don't recommend it...

> keep? (or better said, do we need to make a difference there?)

Most of people prefer SE, and SE does not follow the ASP state machine. This is already stated in the current RFC. Therefore a new state machine diferent from the ASP's is needed. 

> AS? (for example I tend to think it means a direct SCTP association)

Yes, it's a direct association between the two IPSPs that serve different ASes.

Cheers // JAvier.