RE: M3UA: 1IPSP - multiple IPSPs traffic flow

Brian,

> -----Original Message-----
> From: Brian F. G. Bidulock [mailto:[email protected]]
> Sent: Monday, November 07, 2005 8:22 AM
> To: Tolga Asveren
> Cc: [email protected]
> Subject: Re: [Sigtran] M3UA: 1IPSP - multiple IPSPs traffic flow
>
>
> Tolga,
>
> The problem is that an SGP (intentionally) neither has an AS, nor does
> it have a traffic mode.  This is the same for the SGPF in the SE model.
> If you want to change the model, call it something different: how about
> SG-SG? ;)
[TOLGA]I belive the main reason why we have different opinions about this
issue is because you think the logic in SE-IPSP as a SGPF whereas I would
call it IPSPF -OTOH I totally would agree with you that it makes sense to
speak of SGPF and ASPF in IPSP for DE-model-. It is true that the messages
exchanged to bring the entities up and ready for message exchange are the
same for SE-IPSP and SGP/ASP cases -mainly for the sake of reusing existing
message codes- but there is a fundamental difference between two models:
with SE-IPSP model, we have two different application logic processing
entities on each end, which may have different traffic mode attributes. It
sounds reasonable to me to have a mechanism to set both of those values with
Traffic Mode parameter.

For SG-SG, yes it could be nice indeed ;-)
>
> --brian
>
> Tolga Asveren wrote:                       (Mon, 07 Nov 2005 07:54:58)
>
> --X--snip--X--
>
> > [TOLGA]I agree with Shashanks point here. IMO, we have an unnecessary
> > costraint in -SE-IPSP mode. I don't see any problem why using
> Traffic Mode
> > in both directions should create a problem. Forcing people to
> use DE-IPSP
> > mode -which is both optional and IMO more importantt han that
> not a really
> > peer-to-peer model- to set traffic modes in both directions is anot a
> > solution.
>
> --X--snip--X--
>
> --
> Brian F. G. Bidulock
> [email protected]
> http://www.openss7.org/
>