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

From: "Lamberton, Marc" <[email-masked]>
Date: Wed, 12 Jun 2002 19:13:02 +0200

Brian,

please find my comments below...

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]]
Sent: Tuesday, June 11, 2002 11:59 PM
To: Lamberton, Marc
Cc: [email-masked]
Subject: Re: [Sigtran] IPSP / SG-SG models applied to other UAs

Marc

SUA already supports SG-SG communication (relay), but it is called IPSP in
SUA.  In SUA IPSP is not point to point (relay is supported).  Count the
occurrences of the phrase "SGP or IPSP" in the SUA draft and you will see
what I mean.  
[MARC] 13 occurences! ;)

Also, from the examples SUA is SE and there are no effective
differences between IPSP SE and SG-SG the way that IPSP is described in SUA.

[MARC] in sua draft "5.2 IPSP examples" shows bi-directional ASP-UP/ASP-up ACK echanges, and a one-way ASP-ACT/ASP-ACT ACK exchange. Since RC is mandatory in CLDT, can we assume that CLDTs flowing in both direction carry the same RC ?

Therefore, IMO the IPSP described in SUA is no different from SG-SG.  M2UA
has a separate M2PA.  It is only for M3UA that the issue is so confused.

[MARC] Would it make sense to use for sua the sg-sg method described in draft-bidas-sigtran-sgsg? In m3ua sg-sg draft the routing is based on PC, no RC is used between the 2 SG. When AS-1 sends a message addressed to GT2, SG-1 performs a GTT which outputs PC2. The SUA CLDT message is forwarded to SG-2(PC2) with no RC value. Then SG-2 forwards the message to AS-2 as a normal gateway (RK = either GT2, or PC2/SSN). SNM messages flowing between the SGs could also be mapped to SCCP API primitives (N-PCSTATE).

      _______                 _______ 
     |       |               |       |
     |  AS-1 |               |  AS-2 | RK=GT2 (or PC2/SSN)
     |_______|               |_______|
      _______  |              _______   A
     |  SUA  | |             |  SUA  |  |
     |  ASPF | | called=     |  ASPF |  |    
     |_______| | GT2         |_______|  |
      _______  V              _______   | called=GT2 (or PC2/SSN)
     |       |    CLDT       |       |  |
     |  SG-1 |-------------->|  SG-2 |  |
     |_______|               |__PC2__|
        GTT(GT2)->PC-2
        Route on PC-2

--brian

Lamberton, Marc wrote:                                 (Tue, 11 Jun 2002 20:34:41)
> 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
> 
> 
> 
> 
> _______________________________________________
> 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

---

From: "Tolga Asveren" <[email-masked]>
Date: Wed, 12 Jun 2002 14:41:53 -0400

Marc,

> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Lamberton, Marc
> Sent: Wednesday, June 12, 2002 1:13 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: RE: [Sigtran] IPSP / SG-SG models applied to other UAs
>
>
> Brian,
>
> [MARC] in sua draft "5.2 IPSP examples" shows bi-directional
> ASP-UP/ASP-up ACK echanges, and a one-way ASP-ACT/ASP-ACT ACK
> exchange. Since RC is mandatory in CLDT, can we assume that CLDTs
> flowing in both direction carry the same RC ?
[TOLGA] I believe it is just an editorial error. As far as I remember those
parts were directly copied from M3UA draft (please correct me if I am wrong
and if there is a reason for not putting double ASPAC/ASPAC-ACK case) But
now, I think DE for M3UA is history, so text for ASPAC/ASPAC-ACk in SUA
draft is correct (from SE IPSP point of view).
> [MARC] Would it make sense to use for sua the sg-sg method
> described in draft-bidas-sigtran-sgsg? In m3ua sg-sg draft the
> routing is based on PC, no RC is used between the 2 SG. When AS-1
> sends a message addressed to GT2, SG-1 performs a GTT which
> outputs PC2. The SUA CLDT message is forwarded to SG-2(PC2) with
> no RC value. Then SG-2 forwards the message to AS-2 as a normal
> gateway (RK = either GT2, or PC2/SSN). SNM messages flowing
> between the SGs could also be mapped to SCCP API primitives (N-PCSTATE).
[TOLGA] I would say SG-SG for SUA should be based on PC+SSN. SSNM for SUA
already has SSN.