Subject: [Sigtran] m3ua:IPSP

From: "Tolga Asveren" <[email-masked]>
Date: Wed, 5 Jun 2002 20:30:14 -0400

With the hope to move forward, please see some questions/comments
(constructive ones ;-) ) and what I understood till now from our discussions
below (please comment especially on different configurations below)

I agree with Brian that SG-SG also could be considered as IPSP
communication. To me, the important point is, whether it defines a
point-to-point M3UA relationship or not, and it really defines one between
M3UA-SGPFs. Communication is based on SPMC(PC) and management of traffic on
SSNM. On the other hand, by selecting SE over DE and with symmetric RKs (for
this we have decided right? ) we had a good step to a point-to-point
relationship . Still it won't be M3UA-ASP-to-M3UA-ASP, because still we will
need routing functionality, but this is not so terrible. Here communication
is based on RKs (which are symmetric and are defining traffic at both ends)
and traffic management is based on ASPTM. This model will bring a different
state machine and in my opinion this is not very elegant, because this will
make additional state machines/logic necessary, if we want the same node to
communicte with ASPs and SGPs, not impossible but also not nice in my
opinion:

 ************
 *          *
 * +------+ *
 * |U.P/  | *
 * |NIF   | *
 * +------+ *
 * |ASPF  | *
 * |      | *
 * +--+---+ *
 ************  ************************      ***********
      |        *+-------------------+ *      * +------+*
      |        *|  U.P/ NIF         | *      * |U.P/  |*
      |        *|                   | *      * |NIF   |*
      |        *+------+------+-----+ *      * +------+*
      +--------*+SGPF  |ASPF  |IPSPF| *      * |IPSPF |*
               *|      |      |     +-*------*-+      |*
               *+------+---+--+-----+ *      * +------+*
               *           |          *      *         *
               ************************      ***********
                           |
                      ************
                      * +--+---+ *
                      * |SGPF  | *
                      * |      | *
                      * +--+---+ *
                      ************
                           |
                           |
                           |
                           |
                           |
                          -+--
                        //    \\
                       |        |
                      |  SS7     |
                       |        |
                        \\    //
                          ----
To be honest, in such a mixed configuration, I would prefer SG-SG solution:

  ************       ************        ************
  * +------+ *       * +------+ *        * +------+ *
  * |U.P/  | *       * |U.P/  | *        * |U.P/  | *
  * |NIF   | *       * |NIF   | *        * |NIF   | *
  * +------+ *       * +------+ *        * +------+ *
  * |ASPF  | *       * |SGPF  | *        * |ASPF  | *
  * |      +-*-------*-+      +-*--------*-+      | *
  * +------+ *       * +--+---+ *        * +------+ *
  ************       ************        ************
                          |
                          |
                          |
                     ************
                     * +--+---+ *
                     * |SGPF  | *
                     * |      | *
                     * +--+---+ *
                     ************
                          |
                          |
                          |
                          |
                         -+---
                       //     \\
                      | SS7     |
                      |         |
                       \\     //
                         -----

Now if we consider different cases:
1- PC granularity
Because of the reason explained above, for this granularity I would prefer
SG-SG approach. Also for PC granularity, we need to have DUPU for
M3UA-IPSPF-to-M3UA-IPSPF approach, not the end of the world, but in my
opinion a small hint showing that  for PC granularity, thinking the
endpoints as PCs is a better modelling.

2- Sub-PC granularity
IMHO, it is not very realistic to have a fully-mesh network in sub-PC
granularity, especially when the RKs are symmetric. For SI granularity this
seems a little bit more manageable (but probbaly still not a fully-mesh
network), but for CIC ranges only between a few nodes. So, even if
distribution of user parts is desireable, I would think such a network:

     1-1-1     1-1-1/2-2-2    2-2-2/1-1-1  2-2-2
   CIC:0-100   CIC:0-100      CIC:0-100    CIC:0-100
       +-----+-----+               +-----+-----+
       |ASPF |IPSPF|               |IPSPF|ASPF |
       |     |     +---------------+     |     |
       +--+--+-----+               +-----+-+---+
          |                                |
          |                                |
          |                                |
          |               +-----------------
          |               |
          |            +--+--+           +-----+          ----
          |            |SGPF |           |SGPF |        //    \\
          +------------+     +-----------+     +-------+ ASPs   |
                       ++--+-+           +-----+      |          |
                        |  |                           |        |
                        |  |                            \\    //
               +--------+  +----+                         ----
               |                |
             +-+---+        +---+-+
             |ASPF |        |ASPF |
             |     |        |     |
             +-----+        +-----+
            3-3-3           3-3-3
           CIC:0-50        CIC:51-100

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

---

From: "reshma" <[email-masked]>
Date: Thu, 6 Jun 2002 18:24:35 +0530

Hi Tolga,

    Comments below...

> need routing functionality,

[Reshma] Aslo it cant be pure M3UA-SGP-to-M3UA-SGP(SG-SG) ,b'coz it needs
some functionalities of ASP (like sending ASPTM/ASPSM messages :-)

but this is not so terrible. Here communication
> make additional state machines/logic necessary,

[Reshma] If you include ASPTM/ASPSM messages and have subPC granularity
you need statemachine in SG-SG also .How we avoid this?

Thanks,
Reshma

---

From: "Tolga Asveren" <[email-masked]>
Date: Thu, 6 Jun 2002 09:11:31 -0400

Reshma,

> -----Original Message-----
> From: reshma [mailto:[email-masked]]
> Sent: Thursday, June 06, 2002 8:55 AM
> To: Tolga Asveren; [email-masked]
> Subject: Re: [Sigtran] m3ua:IPSP
>
>
> Hi Tolga,
>
>     Comments below...
>
>
[TOLGA] This is not true in my opinion. Concept of RK does not exist for
SG-SG. In fact by replacing TAL with ASPUP/ASPAC, what we are doing is just
reusing them with some different meaning (especially for ASPAC) to prevent
addition of a new message. Please note that no state machine per AS is kept
for SG-SG communication.
> you need statemachine in SG-SG also .How we avoid this?
[TOLGA] With SG-SG communication as it stands, there is no sub-PC
granularity, because it does not have the concept of RK but PC.

---

From: "reshma" <[email-masked]>
Date: Thu, 6 Jun 2002 18:53:44 +0530

Hi Tolga,

> SG-SG.

[Reshma] Then for IPSP-IPSP using SG-SG how do we config RK's?
if suppose IPSP1 has PC 1-1-1 and IPSP2 has PC 2-2-2 ,then
at IPSP1 we configure an RK as DPC-2-2-2 and OPC 1-1-1 and
IPSP2 we configure as OPC 2-2-2 and DPC 1-1-1?

 In fact by replacing TAL with ASPUP/ASPAC, what we are doing is just
> addition of a new message. Please note that no state machine per AS is
kept

[Reshma]Do you mean every ASPUP/ASPAC will be acknowledged by the peer
There wont be any case that peer will send a negative reply to ASPUP/ASPAC ?
In such case only we can avoid ASP state machine else we need it.?

> granularity, because it does not have the concept of RK but PC.

[Reshma] Okay. I opinion is for IPSP also we dont need Sub PC granularity.

Thanks,
reshma

---

From: "Tolga Asveren" <[email-masked]>
Date: Thu, 6 Jun 2002 09:56:50 -0400

Reshma,

> Sent: Thursday, June 06, 2002 9:24 AM
[TOLGA]They are configured statically, similar to SS7 case.
> In such case only we can avoid ASP state machine else we need it.?
[TOLGA] Again ASPUP-ACK can be interpreted as the peers M3UA is also ready.
In fact, of course one will have a small state machine -if you like- for any
communciation with states peer-is -on, perr-is-off. The point I wanted to
underline was that no state machines per AS are necessary.
> > > > is based on RKs (which are symmetric and are defining
> traffic at both
> > > ends)
> > > > state machine and in my opinion this is not very elegant,
> because this
> > > will