Subject: RE: [Sigtran] m3ua:IPSP

From: "Javier Pastor-Balbas (ECE)" <[email-masked]>
Date: Thu, 6 Jun 2002 11:28:37 +0200

Hi Reshma,

 See below...

> -----Original Message-----
> From: reshma [mailto:[email-masked]]
> Sent: Thursday, June 06, 2002 11:22 AM
> To: Javier Pastor-Balbas (ECE); 'Tolga Asveren'; [email-masked]
> Subject: Re: [Sigtran] m3ua:IPSP
> 
> 
> Hi Javier ,
> 
>     Comments below..
> 
> 
> > > 2. Should IPSP be able to communicate with SGP/ASP ?
> > >
> > IPSP is basically a modification of ASP to allow point to point
> communication (the definition of IPSP says that it is 
> basically an ASP). An
> SS7 application will have under it the M3UA layer. M3UA layer will
> communicate with SG using the client-server model defined in AS-SG
> communication and with another AS using the modifications 
> included in IPSP.
> Note that these modifications are basically to allow 
> receiving ASPTM and
> ASPSM messages.
> 
> [Reshma] okay that means only  M3ua-ASP will communicate
> with M3ua-SGP.And M3ua-IPSP will always talk to M3ua-IPSP
> only.
> 
> 
> > > 3. How can the present ASP/AS state machine work for IPSP?
> > >
> > It's just a small modification what is needed to allow to 
> receive ASP*M
> messages:
> >
> >
> >                  IPSP State Transition Diagram, per AS
> >
> >                                    +--------------+
> >                                    |              |
> >             +----------------------|  ASP-ACTIVE  |
> >             |        Other +-------|              |
> >             |   IPSP in AS |       +--------------+
> >             |    Overrides |           ^     |
> >             |              |    ASPAC/ |     | ASPIA/
> >             |              |[ASPAC-Ack]|     | [ASPIA-Ack]
> >             |              |           |     v
> >             |              |       +--------------+
> >             |              |       |              |
> >             |              +------>| ASP-INACTIVE |
> >             |                      |              |
> >             |                      +--------------+
> >             |                          ^     |
> >      ASPDN/ |                          |     | ASPDN /
> > [ASPDN-Ack/]|                   ASPUP/ |     | [ASPDN-Ack /]
> >   SCTP CDI/ |              [ASPUP-Ack] |     | SCTP CDI/
> >   SCTP RI   |                          |     | SCTP RI
> >             |                          |     v
> >             |                      +--------------+
> >             |                      |              |
> >             +--------------------->|   ASP-DOWN   |
> >                                    |              |
> >                                    +--------------+
> >
> 
> [Reshma] But we follow the same old statemachine in current 
> IPSP draft .

Yes that's right. The only difference is that transitions are also triggered with other events (reception of ASP*M messages)

> 
> > > 4. Do we need traffic mode loadshare in IPSP?Why?
> > >
> > It works in the same way as the current M3UA. It is also an 
> option. You
> can use TMT configuration in the same way.
> > Some operator scenarios that include more that one 
> signalling process per
> AS might require this.
> 
> [Reshma] Where this scenario will be used ? In IPSP one IPSP(ASP) will
> always serv one AS .

You might have more that one IPSP(ASP) serving one AS in the same way as the M3UA draft explains. This configuration will give you extra redundancy if needed. It's a choice for each implementor whether they recommend or not to have such a configuration for a specific scenario. We just give the means to make it possible.

> Also in this case, ASP state will reflect AS state and hence AS state
> machine is not needed.

In that case both state machines (AS and IPSP) are equivalent.

Cheers // Javier.

> 
> Thanks,
> Reshma
> >
> > Cheers // Javier.
> >
> >
> > >
> > > Thanks,
> > > Reshma
> > > ----- Original Message -----
> > > From: "Javier Pastor-Balbas (ECE)"
> > > <[email-masked]>
> > > To: "'reshma'" <[email-masked]>; "Javier
> > > Pastor-Balbas (ECE)"
> > > <[email-masked]>; "'Tolga Asveren'"
> > > <[email-masked]>; <[email-masked]>
> > > Sent: Thursday, June 06, 2002 12:54 PM
> > > Subject: RE: [Sigtran] m3ua:IPSP
> > >
> > >
> > > > Hi Reshma,
> > > >
> > > > I would participate in discussions focused on solving any
> > > problem found in
> > > the current SE IPSP model therefore. I think a text could be
> > > a good basis to
> > > find out what is missing and work no that.
> > > >
> > > > But I would not like starting again all the comparison
> > > between the two
> > > models and circular discussions without end. Simply they are
> > > two different
> > > points to work on.
> > > >
> > > > Cheers// Javier.
> > > >
> > > > > -----Original Message-----
> > > > > From: reshma [mailto:[email-masked]]
> > > > > Sent: Thursday, June 06, 2002 9:19 AM
> > > > > To: Javier Pastor-Balbas (ECE); 'Tolga Asveren'; 
> [email-masked]
> > > > > Subject: Re: [Sigtran] m3ua:IPSP
> > > > >
> > > > >
> > > > > Hi Javier ,
> > > > >
> > > > >     As per previous discussions all agreed for SE 
> IPSP approach
> > > > > and leave out DE approach .It will be better if we have more
> > > > > discussion on SE approach .
> > > > >
> > > > > Thanks,
> > > > > Reshma
> > > > > ----- Original Message -----
> > > > > From: "Javier Pastor-Balbas (ECE)"
> > > > > <[email-masked]>
> > > > > To: "'Tolga Asveren'" <[email-masked]>; 
> <[email-masked]>
> > > > > Sent: Thursday, June 06, 2002 12:30 PM
> > > > > Subject: RE: [Sigtran] m3ua:IPSP
> > > > >
> > > > >
> > > > > > Hi Tolga,
> > > > > >
> > > > > > Thanks a lot for your constructive efforts. :-)
> > > > > >
> > > > > > But we need to forget about comparisons and just finish
> > > IPSP to make
> > > > > current RFC interoperable, as Lyndon said. I'm sending the
> > > > > proposed text to
> > > > > the mailing list in a few days.
> > > > > >
> > > > > > Hopefully this issue will be finished before the
> > > Yokohama meeting...
> > > > > >
> > > > > >
> > > > > > Cheers // Javier.
> > > > > >
> > > > > >
> > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: Tolga Asveren [mailto:[email-masked]]
> > > > > > > Sent: Thursday, June 06, 2002 2:30 AM
> > > > > > > To: [email-masked]
> > > > > > > Subject: [Sigtran] m3ua:IPSP
> > > > > > >
> > > > > > >
> > > > > > > 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
> > > > > > >
> > > > > >
> > > > > > _______________________________________________
> > > > > > 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
> 

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

---

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

Hi Javier,

> You might have more that one IPSP(ASP) serving one AS in the same way as
the M3UA draft explains. This configuration will give you extra redundancy
if needed. It's a choice for each implementor whether they recommend or not
to have such a configuration for a specific scenario. We just give the means
to make it possible.

[Reshma] If such a configuration is not realistic  do we need to give such
options?
As we are trying to give all possible options(which may never be used?) we
are
making  IPSP-IPSP communication very complicated.Otherwise if we go for
normal configuration (In IPSP one IPSP(ASP) will  always serv one AS .)
we dont need all this complicated statemachine at all.

Thanks,
Reshma