Subject: RE: [Sigtran] IPSP / SG-SG models applied to other UAs

From: "Tolga Asveren" <[email-masked]>
Date: Wed, 12 Jun 2002 09:12:37 -0400

Marc,

> -----Original Message-----
> From: Lamberton, Marc [mailto:[email-masked]]
> Sent: Wednesday, June 12, 2002 5:18 AM
> To: Tolga Asveren; [email-masked]
> Subject: RE: [Sigtran] IPSP / SG-SG models applied to other UAs
>
>
> Tolga,
>
> please find comments below...
>
> -----Original Message-----
> From: Tolga Asveren [mailto:[email-masked]]
> Sent: Wednesday, June 12, 2002 12:38 AM
> To: [email-masked]
> Subject: RE: [Sigtran] IPSP / SG-SG models applied to other UAs
>
>
> Marc,
>
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]]On Behalf Of
> > Lamberton, Marc
> > Sent: Tuesday, June 11, 2002 2:35 PM
> > To: [email-masked]
> > Subject: [Sigtran] IPSP / SG-SG models applied to other UAs
> >
> >
> > Hi all,
> >
> > For a couple of weeks the discussions about IPSP vs SG-SG models
> > have focused on m3ua because it seems simpler to agree on a model
> > for m3ua, and then apply it on other UAs. Despite this
> > "simplification" no concensus has been reached yet. Could we
> > check how the two remaining models (IPSP-SE and SG-SG) would also
> > apply to other UAs such as SUA or TUA ? If it comes out that one
> > model fits to a wider range of UAs, could we agree that the 1st
> > priority is to complete its definition ? This would also greatly
> > help to stabilize implementations before the next plugtest.
> >
> > SUA example:
> > ------------
> > It seems that the SG-SG model supports well PC granularity (the
> > SGs exchange SNM messages=PC reachability status). For SUA it
> > might be extended with SNM messages=PC+[SSN]. But SUA RK can be
> > much more that PC and SSN, it can also be GT (not talking about
> > hostnames...). When an AS-1 addresses a message to an AS-2 with
> > called address = GT2, the SG-1 needs to perform GTT first, and
> > then route the message to SG-2 according to PC2 (output of GTT).
> > Is that correct? It seems that a direct IPSP to IPSP
> > communication with direct RK matching on GT, would avoid this
> > additional step, and useless GTT rules definition.
> >
> >
> > SG-SG applied to SUA:
> >      _______                 _______
> >     |       |               |       |
> >     |  AS-1 |               |  AS-2 | RK=GT2
> >     |_______|               |_______|
> >      _______  |              _______   A
> >     |       | | RC1,        |       |  |
> >     |  ASP-1| | called=     |  ASP-2|  |
> >     |_______| | GT2         |_______|  |
> >         |     |                 |      |
> >         |     |                 |      | RC2,
> >      ___|___  V              ___|___   | called=GT2
> >     |       |               |       |  |
> >     |  SG-1 |<------------->|  SG-2 |  |
> >     |_______|               |_______|
> >        GTT(GT2)=PC2              match GT2 to RC2
> >        =>route to SG-2
> >
> > IPSP-SE applied to SUA:
> >      _______                 _______
> >     |       |RK=GT1/GT2;RC  |       | RK=GT2/GT1;RC
> >     |  AS-1 | |             |  AS-2 |
> >     |_______| |called=      |_______|
> >      _______  |GT2           _______
> >     |       | V             |       |
> >     | IPSP-1|               | IPSP-2|
> >     |_______|-------------->|_______|
> >        Match GT2 to RC
> >
> [TOLGA] It should be also considered, how IPSP1 in your figure
> decides that
> the message is intended for a specific RK. It will need to do GTT
> for this,
> so translation is still there.
>
> [MARC] If the provisioned RK is (called=GT2, calling=GT1), I
> would expect IPSP1 directly match the message to that RK and
> associated RC, which you may consider being a kind of GTT.
> When you say "it will need to do GTT", do you mean a "classical
> GTT" as described in Q.714-chap 2.4 whose output is (at least) a
> DPC and RI? In that case how that output DPC can help IPSP1 to
> find it peer IPSP-2 ? Don't we want to get rid of PCs with SUA IPSP?
[TOLGA] I don't think a RK with calling/called parties is realistic.
Imagine, how many RKs one would need in such a case(and even like this one
would need to match the message to a RK, some GTT-like procedure). So, again
for a configuration like your IPSP figure, I think RKs will be something
like SSN+PC/SSN+PC or if you like SSN+IP/SSN+IP. In such a case I believe,
one will need at least one "classical GTT" to decide for the remote SSN+PC.
Even for SUA, I don't know whether it is really possible to get rid of PC
concept. Still the SCCP user registers to a SSN+PC, still there is
N-PCSTATE-INDICATION. But I think about this, people, which have spent more
time on SUA might comment more and correct me.
>
> In fact, the result will be the same like in
> M3UA case: SGPF functionality will be shifted to ASP and it will be called
> IPSP.
> Particularly for M3UA case SGPF = SPMC management + Routing Functionality.
> For M3UA-IPSP both of them are needed, so it is not like it is
> stated in the
> draft "IPSP does not use services of a SG", it already has one
> inside. M3UA
> is intended to provide MTP3 services to user parts, so in my opinion it is
> logical that point-to-point relationship for M3UA is based on SPMC, like
> point-to-point relationship for MTP3 is based on PC.
>
>
> _______________________________________________
> 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: "Lamberton, Marc" <[email-masked]>
Date: Wed, 12 Jun 2002 11:18:27 +0200

Tolga,

-----Original Message-----
From: Tolga Asveren [mailto:[email-masked]]
Sent: Wednesday, June 12, 2002 12:38 AM
To: [email-masked]
Subject: RE: [Sigtran] IPSP / SG-SG models applied to other UAs

Marc,

> help to stabilize implementations before the next plugtest.
[TOLGA] It should be also considered, how IPSP1 in your figure decides that
the message is intended for a specific RK. It will need to do GTT for this,
so translation is still there.
 
[MARC] If the provisioned RK is (called=GT2, calling=GT1), I would expect IPSP1 directly match the message to that RK and associated RC, which you may consider being a kind of GTT.
When you say "it will need to do GTT", do you mean a "classical GTT" as described in Q.714-chap 2.4 whose output is (at least) a DPC and RI? In that case how that output DPC can help IPSP1 to find it peer IPSP-2 ? Don't we want to get rid of PCs with SUA IPSP?

In fact, the result will be the same like in
M3UA case: SGPF functionality will be shifted to ASP and it will be called
IPSP.
Particularly for M3UA case SGPF = SPMC management + Routing Functionality.
For M3UA-IPSP both of them are needed, so it is not like it is stated in the
draft "IPSP does not use services of a SG", it already has one inside. M3UA
is intended to provide MTP3 services to user parts, so in my opinion it is
logical that point-to-point relationship for M3UA is based on SPMC, like
point-to-point relationship for MTP3 is based on PC.