Subject: RE: [Sigtran] IPSP: SE vs DE

From: "Javier Pastor-Balbas (ECE)" <[email-masked]>
Date: Tue, 4 Jun 2002 16:40:22 +0200

Hi Tolga, 

See below...

> -----Original Message-----
> From: Tolga Asveren [mailto:[email-masked]]
> Sent: Tuesday, June 04, 2002 4:26 PM
> To: [email-masked]
> Subject: RE: [Sigtran] IPSP: SE vs DE
> 
> 
> Javier,
> 
> For PC granularity:
>  +------+              +------+
>  |U.P./ |              |U.P./ |
>  |NIF   |              |NIF   |
>  +------+              +------+
>  |      |              |      |
>  |SGPF  +--------------+SGPF  |
>  +------+              +------+
> 
> There is again only one M3UA entity, no additional nodes. Why 
> is this more
> expensive than IPSP? 

For me it is easier the following configuration. Everything is already define and working. We do you need to create another different configuration? Just for fun? What are the real advantages to throw away what is already there to create another different thing from the scratch?

  +------+              +------+
  |U.P.  |              |U.P.  |
  |      |              |      |
  +------+              +------+
  |      |              |      |
  |IPSP  +--------------+IPSP  |
  +------+              +------+

This configuration also works for SI, infra-SPC and supra-SPC granularity. What is the advantage of what you are proposing.?

> As I said, it is better to interprete SGPF as IP-STP/IP-SEP. For example:
> 
>  +------+          +------+
>  |ASP1  |          |ASP2  |
>  |      |          |      |
>  +--+---+          +--+---+
>     |                 |
>     |                 |
>     |                 |
>     |     +------+    |
>     |     | SGP1 |    |
>     +-----+      +----+
>           +------+
> 
> Also in the above configuration, SGP1 acts as IP-STP. If there is
> interaction necessary with SS7 domain, of course IP-STP will 
> have a MTP3
> interface and otherwise not.

For the above configuration I'd use the following configuration, where the direct path is the default communication used between both ASes. I don't want to have SG's dependencies

     AS1                AS2
   +------+   IPSP   +------+
   |IPSP1 |==========|IPSP2 |
   |ASP1  |          | ASP2 |
   +--+---+          +--+---+
      |                 |
      |                 |
      |                 |
      |     +------+    |
      |     | SGP1 |    |
      +-----+      +----+
            +------+

And therefore SGP is not really needed. Although if you keep it you can get some redundancy paths...

> 
> 
> The need for CIC routers if there is sub-PC granularity:
> There are n nodes. You change the CIC ranges in one of them. 
> But for the
> other ones you don't want to change. Or even worse,those 
> nodes are belonging
> to different operators. Operator1 does not want to change its 
> CIC ranges
> based on decision of Operator2. In such a case, one needs 
> concentration
> nodes.
> 
How can you deal with CIC granularity with SG-SG ? I thought it was just valid for PC granularity...

> I am aware of 3G but what I told was based on what I see 
> currently, how
> operators want to deploy initially SIGTRAN.

Tolga, both main operators and green fielders, are represented in 3G standardization fora...

Cheers // Javier.

> 
>    Tolga
> 
> > -----Original Message-----
> > From: Javier Pastor-Balbas (ECE)
> > [mailto:[email-masked]]
> > Sent: Tuesday, June 04, 2002 9:52 AM
> > To: 'Tolga Asveren'; [email-masked]
> > Subject: RE: [Sigtran] IPSP: SE vs DE
> >
> >
> > Hi Tolga,
> >
> > See my comments below...
> >
> > > -----Original Message-----
> > > From: Tolga Asveren [mailto:[email-masked]]
> > > Sent: Tuesday, June 04, 2002 3:16 PM
> > > To: [email-masked]
> > > Subject: RE: [Sigtran] IPSP: SE vs DE
> > >
> > >
> > > Hi Javier,
> > >
> > > I agree that they are not exactly compareable but if I have
> > > to choose one,
> > > without hesitation, I would choose SG-SG. Some more comments
> > > to the items
> > > you added to the list are below.
> > >
> > >   Tolga
> > >
> > > > -----Original Message-----
> > > > From: Javier Pastor-Balbas (ECE)
> > > > [mailto:[email-masked]]
> > > > Sent: Tuesday, June 04, 2002 2:40 AM
> > > > To: 'Tolga Asveren'; [email-masked]
> > > > Subject: RE: [Sigtran] IPSP: SE vs DE
> > > >
> > > >
> > > > Hi Tolga,
> > > >
> > > > These two methods are not comparable. They simply do different
> > > > things. But for sure that if I have to choose one, I'll go for
> > > > the current RFC with the IPSP. The reasons are in the 
> list below.
> > > >
> > > > Let's complete the table... (see below)
> > > >
> > > > > -----Original Message-----
> > > > > From: Tolga Asveren [mailto:[email-masked]]
> > > > > Sent: Monday, June 03, 2002 8:03 PM
> > > > > To: [email-masked]
> > > > > Subject: RE: [Sigtran] IPSP: SE vs DE
> > > > >
> > > > >
> > > > > My opinion is:
> > > > >
> > > > > First of all thinking that AS talks to SG is equivalent to
> > > > > say that a web
> > > > > browser talks to a router, instead of a web server. It is
> > > > > ASP-M3UA, which
> > > > > talks to SGP-M3UA. I think saying like this fits more to a
> > > > > layered approach,
> > > > > otherwise for any communication at any level we can say AS is
> > > > > talking to SG.
> > > > > In the context of M3UA stack, ASP corresponds to a physical
> > > > > endpoint whereas
> > > > > AS is only a traffic range. So, for example, ASPUP is not
> > > > > sent from AS to SG
> > > > > but from ASP-M3UA to SGP-M3UA (for example similarly if INAP
> > > > > logic in a SSP
> > > > > sends an INAP message to a SCP, the corresponding MSUs will
> > > > > possibly pass
> > > > > through some STPs. Does this mean that SSP talks to those
> > > > > STPs?). An AS is a
> > > > > logical HLR, SCP etc... so its peer will be again a
> > > > > corresponding entity, in
> > > > > IP domain or in SS7 domain.
> > > > >
> > > > > Advantages of using SG-SG communication:
> > > > > ========================================
> > > > > 1- Has relaying functionality
> > > > > 2- Allows smooth interaction with SS7 network
> > > > > 3- For PC granularity, user application might run directly on
> > > > > top of SGPF
> > > > > (of course with NIF)
> > > > > 4- Does not require separate state machines and separate
> > > > > logics for peers in
> > > > > SS7 domain and in IP domain
> > > > >
> > > > >
> > > > > Advantages of SE IPSP
> > > > > ======================
> > > > >
> > > > > 1- Will provide direct symmetric communication for sub-PC
> > > granularity.
> > > >
> > > > Let me add a few more:
> > > >
> > > > 2- Will provide direct symmetric communication for PC 
> granularity
> > > [TOLGA] SG-SG provides this
> >
> > But you need SG:
> > - More expensive
> > - Processing time increased
> >
> > > > 3- Will provide direct symmetric communication for supra-PC
> > > granularity
> > > > 4- No more messages needed
> > > [TOLGA] For intra-IP case, also for SG-SG no more messages needed.
> >
> > But you need SG:
> > - More expensive
> > - Processing time increased
> >
> > > > 5- No more working items needed
> > > [TOLGA] We still need to discuss about SE IPSP. Till now, 
> all of the
> > > discussion was focused on DE approach.
> > > > 6- No more standard process needed
> > > [TOLGA] ?
> >
> > See RFC 2026
> >
> > > > 7- Use of SG not needed to communicate two SS7 applications in
> > > > the IP domain
> > > [TOLGA] For PC granularity also not needed for SG-SG case. Or
> > > better said,
> > > one just need SG (which I think now we are interpreting more
> > > as IP-STP)
> >
> > If you use SG:
> > - More expensive
> > - Processing time increased
> > You don't need to introduce this delay. Using IPSP communication
> > between ASes, is direct and it will avoid unnecessary delays and
> > intermediate nodes...
> >
> > > > 8- Relaying function not needed in IP domain: we have routers
> > > [TOLGA] It is needed for a reasonable configuration if one
> > > goes to sub-PC
> > > granularity. Do we have routers working based on CIC ranges?
> >
> > What reasonable configuration needs it?
> >
> > > What about for
> > > multiple operators case? And if sub-PC grabularity is not
> > > needed, then IPSP
> > > also does not have any meaning. Because for PC granularity
> > > SG-SG provides
> > > everything IPSP can provide and more.
> >
> > Using SG-SG you need more nodes
> > - More expensive
> > - Processing time increased
> >
> > Less quality but more expensive
> >
> > > > 9- Allow an step forward moving from MTP2 to IP protocol to
> > > > transport SS7 signaling
> > > [TOLGA] That is in fact what SG-SG does
> >
> > You don't need to introduce more nodes in addition to the SS7
> > application talking one to each other using M3UA.
> >
> > > > 10- The future network without SS7 domain
> > > [TOLGA] SG-SG also provides this and additionaly also
> > > provides easy SS7
> > > communciation for the transition period, which most probably
> > > won't be very
> > > short. In fact, although I don't like it, what I see is,
> > > people want to use
> > > SIGTRAN
> > > a) either to get a remote SS7 interface for their IP-SCPs,
> > > Softswitches
> > > etc...
> > > b) or to backhaul between two SS7 nodes over IP
> >
> > Take a look to standardization fora for the third generation.
> >
> > > > 11- The first network small operators could make (SS7 is
> > > more expensive)
> > > [TOLGA] Why do you think for SG-SG SS7 is necessary? We have
> > > said several
> > > times, SG should be interpreted as IP-STP. SS7 interface is
> > > only necessary,
> > > if one want to communicate with nodes in SS7 domain.
> >
> > Read the definition for SG. IP-STP is not an SG in the same way
> > that SG is not necessary an SS7 STP. IP-STPs are just IP-STPs.
> > Another different thing is that you want to include IP-STP
> > functionality inside the same node as the SG. SG is not necessary
> > an SS7-STP either. Do I need to substitute IP-STP in every place
> > you put SG?  :-/
> >
> > Direct communication is always cheaper and faster when possible.
> >
> > Cheers // Javier.
> >
> >
> >
> > > >
> > > >
> > > >
> > > > Cheers // Javier.
> > > >
> > > >
> > > > >
> > > > > Let's try to complete those two lists. What else could be
> > > > > added to them?
> > > > >
> > > > >  Tolga
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: [email-masked]
> > > > > [mailto:[email-masked]]On Behalf Of
> > > > > > Javier Pastor-Balbas (ECE)
> > > > > > Sent: Monday, June 03, 2002 11:52 AM
> > > > > > To: [email-masked]'; Javier Pastor-Balbas (ECE)
> > > > > > Cc: [email-masked]'
> > > > > > Subject: RE: [Sigtran] IPSP: SE vs DE
> > > > > >
> > > > > >
> > > > > > Brian,
> > > > > >
> > > > > > Wrong concept. My AS can talk with a SG and ALSO with
> > > another AS.
> > > > > > The communication will be faster since the 
> processing is half or
> > > > > > even less.
> > > > > >
> > > > > > What is the advantage of AS-SG-(SG)-AS regarding 
> AS-AS ?? Please
> > > > > > list them.
> > > > > >
> > > > > > Cheers // Javier.
> > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: Brian F. G. Bidulock [mailto:[email-masked]]
> > > > > > > Sent: Monday, June 03, 2002 5:14 PM
> > > > > > > To: Javier Pastor-Balbas (ECE)
> > > > > > > Cc: [email-masked]'
> > > > > > > Subject: Re: [Sigtran] IPSP: SE vs DE
> > > > > > >
> > > > > > >
> > > > > > > Javier,
> > > > > > >
> > > > > > > Your IPSP will not work with an SG and therefore
> > > > > > > makes no sense.
> > > > > > >
> > > > > > > I still propose that IPSP be removed altogether as SG-SG
> > > > > > > communication is an better, easier and obvious 
> replacement.
> > > > > > >
> > > > > > > --brian
> > > > > > >
> > > > > > > Javier Pastor-Balbas (ECE) wrote:
> > > > > > > (Mon, 03 Jun 2002 16:58:54)
> > > > > > > > Hi Brian,
> > > > > > > >
> > > > > > > > IPSP will avoid the use of SG and therefore it 
> makes sense.
> > > > > > > >
> > > > > > > > Cheers // Javier.
> > > > > > > >
> > > > > > > > > -----Original Message-----
> > > > > > > > > From: Brian F. G. Bidulock 
> [mailto:[email-masked]]
> > > > > > > > > Sent: Monday, June 03, 2002 4:48 PM
> > > > > > > > > To: Javier Pastor-Balbas (ECE)
> > > > > > > > > Cc: [email-masked]'
> > > > > > > > > Subject: Re: [Sigtran] IPSP: SE vs DE
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > Javier,
> > > > > > > > >
> > > > > > > > > As SE was clearly agreed as possible using an SG to
> > > > > transfer and
> > > > > > > > > not requiring any new protocol or state machine
> > > description, I
> > > > > > > > > propose that IPSP be removed from the RFC
> > > altogether.  I also
> > > > > > > > > propose that the SG-SG be used to properly address
> > > > > peer-to-peer
> > > > > > > > > communication.
> > > > > > > > >
> > > > > > > > > --brian
> > > > > > > > >
> > > > > > > > > Javier Pastor-Balbas (ECE) wrote:
> > > > > > > > > (Mon, 03 Jun 2002 16:24:07)
> > > > > > > > > > Hi guys,
> > > > > > > > > >
> > > > > > > > > > I propose to move forward. Most of the folks
> > > that are now
> > > > > > > > > > active seem to prefer the SE. Then, I propose to
> > > > > remove the DE
> > > > > > > > > > exchange from the current RFC and leave 
> only SE. Anyone
> > > > > > > > > > against?
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > Cheers // Javier.
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > _______________________________________________
> > > > > > > > > > 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
> > > > > > >
> > > > > > > --
> > > > > > > Brian F. G. Bidulock
> > > > > > > [email-masked]
> > > > > > > http://www.openss7.org/
> > > > > > >
> > > > > >
> > > > > > _______________________________________________
> > > > > > 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: "Tolga Asveren" <[email-masked]>
Date: Tue, 4 Jun 2002 11:05:29 -0400

Hi Javier,

> Sent: Tuesday, June 04, 2002 10:40 AM
> For me it is easier the following configuration. Everything is
> already define and working. We do you need to create another
> different configuration? Just for fun? What are the real
> advantages to throw away what is already there to create another
> different thing from the scratch?
[TOLGA] I don't think everything is already defined and working for SE IPSP
case, we should and discuss about the details.. The advantage of using SGPF
is that its relationship with ASPF is already defined. To be able to make
IPSP communciate with SGP, one has to keep two different state machines.
> This configuration also works for SI, infra-SPC and supra-SPC
> granularity. What is the advantage of what you are proposing.?
>
>
> For the above configuration I'd use the following configuration,
> where the direct path is the default communication used between
> both ASes. I don't want to have SG's dependencies
>
>      AS1                AS2
>    +------+   IPSP   +------+
[TOLGA] The real important issue is that one needs to put also ASP state
machines and logic there. I am not saying this is impossible, just in my
opinion not desireable.
> was just valid for PC granularity...
[TOLGA] SG-SG has relaying functionality. So, one SG can concentrate traffic
on PC granularity and can relay it to another SG. SGPs and ASPs are
communciating can communciate in sub-PC without problem.