Subject: RE: [Sigtran] SG-SG communication overview

From: "Javier Pastor-Balbas (ECE)" <[email-masked]>
Date: Wed, 17 Apr 2002 20:28:57 +0200

Hi Tolga, 

Very nice approach. I would add some comments:

- I prefer not to create a new protocol but enhance M3UA. I mean, we could say instead of "M3PA" "SG2SG using M3UA". We could see it as the missing part for the future M3UAv02. IMO some of the features we define here could be reused for the IPSP-IPSP or SG-AS philosophies.

- I would add another scenario with SS7 and IP interworking where several possible routes are possible to reach the destination thanks to the SG-SG communication. I can write some text for this. I think this is one of the most important advantages for transition to IP.

- I don't agree very much on NA. From my point of view it is an unnecessary restriction. What other people think?

- I would also add ASPSM and ASPTM messages amongst the messages to use, to start communication after seting up the association. And also ERROR message (NTFY not needed).

Cheers // Javier.

> -----Original Message-----
> From: Tolga Asveren [mailto:[email-masked]]
> Sent: Wednesday, April 17, 2002 7:41 PM
> To: [email-masked]
> Subject: [Sigtran] SG-SG communication overview
> 
> 
> Hi,
> 
> While I am typing and putting everything in a nice format, I 
> thought it
> might be a good idea to share in general what was agreed 
> (well, of course
> there are still some disagreements, so it is better to add 
> "from my point of
> view") in IPSP discussion group, with the whole SIGTRAN 
> group, to get some
> feedback,opinions etc....
> 
> It seems an approach where we have to extension drafts, one for SG-SG
> communication and one for IPSP mode (probably it will be more 
> appropriate to
> call it inter-IP communication), is more aprropriate.
> 
> In that message I will try to give a brief overview of the 
> proposed SG-SG
> communication.
> Also for IPSP mode I will send a similar message soon.
> 
>    Tolga
> 
> 
> 
> SG-SG Communication
> ===================
> 
> 1. Overview
> The purpose of SG-SG communication is to increase inter-IP 
> communication
> capabilities of M3UA peers and to allow SS7 signalling 
> backhauling between
> SS7 nodes over IP. (to define SG-SG communication initially 
> only for M3UA is
> my personal opinion).
> 
>      -----              -----
>    //     \\          //     \\
>   |  ASP    |        |  ASP    |
>   |  Cloud 1|        |  Cloud 2|
>    \\     //          \\     //
>      --+--              --+--
>        |                  |
>        |                  |
>     +--+--+            +--+--+
>     | SG1 +------------+ SG2 |
>     +--+--+            +--+--+
>        |                  |
>        |                  |
>        |                  |
>        |     +-----+      |
>        +-----+ SG3 +------+
>              +--+--+
>                 |
>                 |
>               --+--
>             //     \\
>            |  ASP    |
>            |  Cloud 2|
>             \\     //
>               -----
> Figure1: Inter-IP communication using SG-SG communication.
> 
> Inter-IP communication using SG-SG protocol will be explained 
> in detail in
> draft[..]
> 
>  +---------+              +---------+
>  |   SG1   +--------------+   SG2   |
>  +----+----+              +----+----+
>       |                        |
>       |                        |
>  +----+----+              +----+----+
>  |SS7 node1|              |SS7 node2|
>  +---------+              +---------+
> Figure2: SS7 backhauling with SG-SG protocol
> 
> 
> SG-SG protocol management is based mainly on SSNM as defined in M3UA
> RFC[...], with some additional messages to handle changeover 
> and congestion
> handling cases as defined in Q.704.
> 
> 
> Communication of peers using SG-SG protocol is on PC 
> granularity. (I even
> think this as something like M3PA, again personal opinion )
> 
> 
> 2. Functional Areas
> 2.1 Signalling Point Code Representation
> SGs SHOULD control SPMCs as a whole. When a SPMC becomes 
> unavailable SG will
> broadcast DUNA to all SGs, it has an association with. 
> Similarly when a SPMC
> becomes available DAVA and when a SPMC becomes restricted 
> DRST will be sent.
> (For a full list of those transitions, references to 
> appropriate sections of
> Q.704 will be added)
> 
> 2.2 Routing Context and Routing Keys
> Unlike M3UA, there is no Routing Context/Routing Key concept 
> present in
> SG-SG protocol.
> 
> 2.3 Network Appearence
> To make an easy transition to a SG-SG protocol, which might 
> be used also for
> SUA peers, possible, NA is not used in SG-SG protocol 
> messages. So, one SCTP
> association should carry traffic belonging to one network 
> only and this
> should be coordinated among peers by configuration.
> 
> 2.4 SCTP Association Establishment
> There is no client/server relationship between peers in SG-SG 
> communication.
> SCTP associations might be initiated from any side.
> After a SCTP association is established, SGs will exchange 
> SSNM to update
> the remote peer about the status of th PCs, whihc are by configuration
> declared as reachable via them. Unless a corresponding 
> message is received,
> all PCs are assumed as accessible via the remote peer. Each 
> SG will send
> DUNA for not reachable PCs and DRST for restricted PCs after the
> establishment of association.
> 
> 
> 3.Protocol Messages
> SG-SG protocol uses DATA and SSNM messages from M3UA messages 
> defined in
> RFC[...]. RC and NA fields in messages are not used, i.e. 
> they MUST NOT be
> filled.
> 
> 3.1. DUPU
> A new filed is introduced to DUPU:
> ConcernedPC : Destination PC, which has caused DUPU to be generated.
> 
> (Messages corresponding to RCT and changeover mechanism 
> related messages
> will be added)
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> _______________________________________________
> 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: Wed, 17 Apr 2002 14:49:13 -0400

Hi Javier,

Please see comments below.

 Tolga

> From: Javier Pastor-Balbas (ECE)
> [mailto:[email-masked]]
> Sent: Wednesday, April 17, 2002 2:29 PM
> To: 'Tolga Asveren'; [email-masked]
> Subject: RE: [Sigtran] SG-SG communication overview
>
>
> Hi Tolga,
>
> - I prefer not to create a new protocol but enhance M3UA. I mean,
> we could say instead of "M3PA" "SG2SG using M3UA". We could see
> it as the missing part for the future M3UAv02. IMO some of the
> features we define here could be reused for the IPSP-IPSP or
> SG-AS philosophies.
[TOLGA] As I said just I call it M3PA :-) As mentioned also on the original
message, SG-SG protocol will play a key role in IPSP communciation (I will
continue to use the term IPSP for now but I think after I send the overview
for proposed IPSP communcation model, inter-IP will also make more sense to
you)
>
> - I would add another scenario with SS7 and IP interworking where
> several possible routes are possible to reach the destination
> thanks to the SG-SG communication. I can write some text for
> this. I think this is one of the most important advantages for
> transition to IP.
>
> - I don't agree very much on NA. From my point of view it is an
> unnecessary restriction. What other people think?
[TOLGA] This one, we should discuss more. But the main argument not to
include
NA was, because NA is not existing in SSNM for SUA. We should spend a little
bit more effort to see whether a global SG-SG protocol (applicable for
M3UA/SUA/(TUA) ) is possible or not.
>
> - I would also add ASPSM and ASPTM messages amongst the messages
> to use, to start communication after seting up the association.
> And also ERROR message (NTFY not needed).
[TOLGA] For ERROR I am not sure. But personally I don't think ASPSM and
ASPTM are necessary, because everything is in PC granularity and SSNM should
be sufficient.