Subject: RE: [Sigtran] IPSP issues

From: "Javier Pastor-Balbas (ECE)" <[email-masked]>
Date: Tue, 23 Apr 2002 17:54:02 +0200

Hi Tolga, see below...

> -----Original Message-----
> From: Tolga Asveren [mailto:[email-masked]]
> Sent: Tuesday, April 23, 2002 4:42 PM
> To: [email-masked]
> Subject: RE: [Sigtran] IPSP issues
> 
> 
> Hi Javier,
> 
> In my opinion, once one moves to ASP-ASP communication 
> direction, there are
> two things, to be considered:
> 1) For this, new state machines and procedures should be 
> defined. I think,
> this very well will be beyond adding a few clarification lines.
> 
You don't need to define new states machines or procedures. The ones for ASP and AS are perfectly applicable. you don't either need to define new procedures since these are already writen with the help of the "IPSP Considerations"

> 2) In such a case, number of needed RKs, is much more than 
> for ASP/SGP case,
> if one has multiple associations.(To get rid of this problem, 
> you know that
> we moved to the direction of "double-ended" approach. This is 
> in my view,
> nothing else than a sample configuration of the existing SGP/ASP
> functionality, so I wouldn't see this as ASP-ASP communication)
> 

When two IPSPs want to talk to each other they can register the RK they want, filtering traffic towards them. It works in the same way as always!!  :-). The number of associations and IPSP per AS that you want to use is a configuration matter.

> 3) With the existing M3UA, in my opinion it is possible to 
> think that an ASP
> endpoint is always communicating with a SGP endpoint and to 
> communciate
> purely in IP domain. I think, what you don't like is the word 
> "Gateway" in
> SGP, because it reminds one to an entity, which is a bridge 
> between IP and
> SS7 domains. But here, what we want to reuse is the 
> distribution (and maybe
> SPMC handling) capability of SGP.
> For example consider the follwoing scenario:
> 
>  *********                *********
>  *       *                *       *
>  *       *                *       *
>  *IPSP1  *----------------* IPSP2 *
>  *       *                *       *
>  *       *                *       *
>  *********                *********
> 
> Now, let's try to make this work with existing functionalities:
> 
>   *************               **************
>   *           *               *            *
>   *+---------+*               *+---------+ *
>   *|         |*               *|         | *
>   *|         |*               *|         | *
>   *|   X     |*               *|   y     | *
>   *|         |*               *|         | *
>   *|         |*               *|         | *
>   *+---------+*               *+---------+ *
>   *| SGP1    |*               *| ASP2    | *
>   *|         +*---------------*+         | *
>   *+---------+*               *+---------+ *
>   *************               **************
> The responsibility of the protocol is to define the messaging and
> relationship between two endpoints. So, IPSP1 sees IPSP2 as 
> ASP1 and IPSP2
> sees IPSP1 as SGP1. X and Y are implementation dependent 
> things. I don't
> think, we need to address them.
> One does not need to implement SGP functionalities, which are 
> not needed in
> this configuration. Just as an example X might be NIF+ASP and 
> Y might be
> NIF. But this is implemenation dependent.
> (One might have both SGP and ASP functionalities in one node, 
> but this does
> not change anything, again, everyhting styas the same like in 
> ASP/SGP case)
> 

You describe the communication in one direction but not in the other. If you include both, you'll have a mixture of what the ASP and SGP logic are making up an IPSP.

I disagree with you in saying that NIF functionality is included in IPSP but while you follow the protocol, as you say, you can have inside a physical node as much as you want.

> 4) It is of course possible to put more than one 
> functionality in one node
> (ASP and IPSP), but if both of them are trying to distribute 
> traffic in the
> same direction, then this wouldn't create a nice situation. 
> One should check
> for each message, which one of them should be used, a second layer of
> distribution.
> 

I prefer the name of role instead of functionality or even ability.

I don't find that problem in our implementation. When you send data you just find the SPC of the destination, and then you translate it to an IP address and send the message towards that node. The AS knows if the destination is a SG or another AS. In a practical situation (think of MSC - HLR communication) I don't see the problem...

Cheers // Javier.

> 
>     Tolga
> 
> > -----Original Message-----
> > From: Javier Pastor-Balbas (ECE)
> > [mailto:[email-masked]]
> > Sent: Tuesday, April 23, 2002 9:30 AM
> > To: 'Tolga Asveren'; [email-masked]
> > Subject: RE: [Sigtran] IPSP issues
> >
> >
> > Hi Tolga,
> >
> > See below....
> >
> > Cheers / Javier.
> >
> >
> > > -----Original Message-----
> > > From: Tolga Asveren [mailto:[email-masked]]
> > > Sent: Tuesday, April 23, 2002 3:16 PM
> > > To: [email-masked]
> > > Subject: RE: [Sigtran] IPSP issues
> > >
> > >
> > > Hi Javier,
> > >
> > > To make this thread more productive let me list my concerns:
> > >
> > > 1) The fact, that "IPSP" is described in a few lines in M3UA
> > > draft is in my
> > > view enough evidence, that it just reuses already defined ASP/SGP
> > > functionalities. I don't think there is a need to give a
> > > special name to
> > > this, because it is just a special configuration of the existing
> > > functionalities. Of course, different people might have
> > > different opinions
> > > on that issue.
> > >
> >
> > About the special name I agree with you that no new names were
> > needed. I prefer to call it ASP-ASP
> > Note about the RFC names:
> > AS
> > IPSP: node that communicates with another IPSP
> >
> >
> > > 2) I don't necessarily agree with your sentence "IPSP is an
> > > IP-only node".
> > > In the recent IPSP discussions, the question which everybody
> > > was asking was
> > > "Can I have an aasociation between IPSP and SGP, what about
> > > IPSP and ASP?".
> > > That is also one of the reasons, why I like to see it as a special
> > > configuration of ASP/SGP, because, in such a case the
> > > relationship between
> > > endpoints is well defined.
> > >
> >
> > In fact you may be right. I'll try to remake my point better:
> >
> > IPSP is not and IP-node itself. "IPSP communication" is the
> > "procedure" (using M3UA messages) that two AS (i.e IP nodes) need
> > to use to talk among them.
> > And AS-SG procedures are the ones that an AS has to use to 
> talk to an SG.
> >
> > We can think of ASP and IPSP as roles.The implementation of an AS
> > in processes is as follows:
> > 	- An AS implementation is called ASP if it talks with and SGP
> > 	- An AS implementation is called IPSP if it talks to
> > another AS implementation (also called IPSP)
> >
> > It can be possible that an AS can talk to both kind of nodes at
> > the same time: an SG and another AS. In that case the
> > implementation of that AS (what we call process) will take the
> > roles of ASP and IPSP at the same time.
> >
> > I know this nomenclature is not very clear. In fact I tried to
> > change the term "IPSP communication" for "ASP-ASP Communication"
> > but some folks preferred to have different names to differenciate
> > both situations. But anyway in the draft it is said that "an IPSP
> > serves an AS" in the same way that it is said that "an ASP 
> serves an AS".
> >
> > Therefore we can conclude that it is not possible to connect an
> > ASP with an IPSP, since this are roles that the AS implementation
> > can have. The AS is the one that can be called IP-node.  :-D
> >
> >
> > Hope this clarifies a little more...  :-/
> >
> >
> > > Your main concern is -as far as I understand- that SGP
> > > functionality has
> > > some components, which are not necessary for "IPSP" case. For
> > > which parts
> > > are you concerned?
> >
> > I hope the discussion above clarifies my point... :-D
> >
> > >
> > > > See it as the following:
> > > > If you add to an AS the functionality needed for an SG to send
> > > > messages to an AS, and you mix it according with the M3UA RFC,
> > > > you'll have an IP node that can talk to an SG but also DIRECTLY
> > > > to another IP-node. It is what is already defined and it works
> > > > fine. It worked fine in the last interop. The open issue we have
> > > > is to decide the start-up of the connection, but the 
> rest doesn't
> > > > need any urgent modification...
> > > That is also exactly what I am saying. More and more I have
> > > the feeling, the
> > > main difference is, you want to give this thing a new name
> > > and I don't.
> > > Well, this is not a big issue :-)
> > >
> > >     Tolga
> > >
> > >
> > >
> > > _______________________________________________
> > > 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: "Tolga Asveren" <[email-masked]>
Date: Tue, 23 Apr 2002 13:20:03 -0400

Javier,

In my view, if you don't define new state machines, this means you are using
the existing ones. So, this means there is no need to define a new process
type -IPSP- in addition to ASP and SGP.

    Tolga

> Sent: Tuesday, April 23, 2002 11:54 AM
> You don't need to define new states machines or procedures. The
> ones for ASP and AS are perfectly applicable. you don't either
> need to define new procedures since these are already writen with
> the help of the "IPSP Considerations"
>
>
> When two IPSPs want to talk to each other they can register the
> RK they want, filtering traffic towards them. It works in the
> same way as always!!  :-). The number of associations and IPSP
> per AS that you want to use is a configuration matter.
>
>
> You describe the communication in one direction but not in the
> other. If you include both, you'll have a mixture of what the ASP
> and SGP logic are making up an IPSP.
>
> I disagree with you in saying that NIF functionality is included
> in IPSP but while you follow the protocol, as you say, you can
> have inside a physical node as much as you want.
>
>
> I don't find that problem in our implementation. When you send
> data you just find the SPC of the destination, and then you
> translate it to an IP address and send the message towards that
> node. The AS knows if the destination is a SG or another AS. In a
> practical situation (think of MSC - HLR communication) I don't
> see the problem...
>
> Cheers // Javier.
>
>
>
>
>
> >
> >     Tolga
> >