RE: M3UA: 1IPSP - multiple IPSPs traffic flow

Shashank,

> -----Original Message-----
> From: [email protected] [mailto:[email protected]]On
> Behalf Of Prasad, Shashank S (Shashank)
> Sent: Monday, November 07, 2005 7:09 AM
> To: [email protected]
> Cc: '[email protected]'
> Subject: RE: [Sigtran] M3UA: 1IPSP - multiple IPSPs traffic flow
>
>
> Brian,
>
> Replies embedded.
>
>
> -----Original Message-----
> From: Brian F. G. Bidulock [mailto:[email protected]]
> Sent: Monday, November 07, 2005 4:24 PM
> To: Prasad, Shashank S (Shashank)
> Cc: [email protected]
> Subject: Re: [Sigtran] M3UA: 1IPSP - multiple IPSPs traffic flow
>
>
> Shashank,
>
> The RFC is clear: the TM in the ASP Active Ack is the value that was sent
> in the ASP Active.
>
> In SE mode, the peer does not have a traffic mode.  It is acting like an
> SGP.
> Again, see A.2.2.
>
> [SHASHANK] U are putting a lot of constraints by this statement. Ur
> statement means that IPSP-IPSP cannot have a SE mode. This is NOT really
> correct. Here I am trying to make some minor improvements in the
> M3UA specs
> so that IPSPs can also use the SE effectively.
[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.
>
>
> If you want both IPSPs to each have an AS an traffic mode, use DE instead
> of SE.
>
> [SHASHANK] This is a big contraint and not acceptable :)
> IPSPs can surely use SE mode too between themselves (IPSPs).
> Moreover DE is
> optional.
>
>
> --brian
>
>
> Prasad, Shashank S (Shashank) wrote:               (Mon, 07 Nov 2005
> 15:06:34)
> > Brian,
> >
> > ASPAC (and ASPAC-Ack) message has one Traffic mode and
> mutiple(n) Routing
> > Contexts.
> > My point is that the ASP Active message must have as many modes
> as Routing
> > Contexts ....OR....
> >
> > ...The implementation should club all the Routing Contexts with the same
> > Traffic Mode in a ASP Active message and then send the others in a
> different
> > ASP Active.... This is possible but it is quite and indirect
> mechanism to
> > send ASP Active messages....
> >
> >
> > Verbatim from the specs:
> >
> >    For the Application Servers that the ASP can be successfully
> >    activated, the SGP or IPSP responds with one or more ASP Active Ack
> >    messages, including the associated Routing Context(s) and reflecting
> >    any Traffic Mode Type value present in the related ASP Active
> >    message.
> >
> >
> > Does this mean that the Traffic mode in the ASPAC-Ack is the
> traffic mode
> of
> > the sender of ASP-Ack ?
> > >From the RFC text "...reflecting any Traffic Mode Type value present in
> the
> > related ASP Active message ", I interpret that the Traffic Mode received
> in
> > the ASPAC messages shall be sent back in ASPAC-Ack.
> > And it is NOT really the Traffic mode of the sender of ASPAC-Ack.
> >
> > And that's the issue which I see in the Single Ended mode wherein the
> sender
> > of ASPAC will never come to know the Traffic Mode of the peer.
> >
> > shashank
> >
> >
> >
> >
> > -----Original Message-----
> > From: Brian F. G. Bidulock [mailto:[email protected]]
> > Sent: Monday, November 07, 2005 8:28 AM
> > To: Prasad, Shashank S (Shashank)
> > Cc: [email protected]
> > Subject: Re: [Sigtran] M3UA: 1IPSP - multiple IPSPs traffic flow
> >
> >
> > Shashank,
> >
> > > > RFC 3332 says: (Section 4.3.4.3 second paragraph)
> > > >
> > > >    For the Application Servers that the ASP can be successfully
> > > >    activated, the SGP or IPSP responds with one or more ASP
> Active Ack
> > > >    messages, including the associated Routing Context(s) and
> reflecting
> > > >    any Traffic Mode Type value present in the related ASP Active
> > > >    message. The Routing Context parameter MUST be included
> in the ASP
> > > >    Active Ack message(s) if the received ASP Active message
> contained
> > > >    any Routing Contexts.  Depending on any Traffic Mode Type request
> in
> > > >    the ASP Active message, or local configuration data if
> there is no
> > > >    request, the SGP moves the ASP to the correct ASP traffic state
> > > >    within the associated Application Server(s).  Layer Management is
> > > >    informed with an M-ASP_Active indication. If the SGP or IPSP
> receives
> > > >    any Data messages before an ASP Active message is
> received, the SGP
> > > >    or IPSP MAY discard them.  By sending an ASP Active Ack message,
> the
> > > >    SGP or IPSP is now ready to receive and send traffic for the
> related
> > > >    Routing Context(s).  The ASP SHOULD NOT send Data or
> SSNM messages
> > > >    for the related Routing Context(s) before receiving an ASP Active
> Ack
> > > >    message, or it will risk message loss.
> > > >
> > > > I think that this is quite clear with regard to two things:
> > > >
> > > > The IPSP receiving the ASP Active message responds with regard to
> > Traffic
> > > > Mode in the same fashion as an SGP would.
> >
> > Prasad, Shashank S (Shashank) wrote:
> > (Mon, 07 Nov 2005 05:17:59)
> > > Brian,
> > > I have only IPSPs in peer to peer communication.
> > > There are no SGs. And therefore I would NOT consider SGPs or their
> > > equivalent functionality.
> > >
> > > Ur answer tends me to believe that the Single Exchange is ONLY between
> an
> > > ASP and SGP.
> > > Which is NOT correct. Please refer to Sec 5.5.1 and Sec 5.5.2
> in the RFC
> > > 3332.
> > >
> > > I can always have SE between 2 IPSPs. It is upto the IPSPs to exchange
> the
> > > right parameters in the messages to indicate to each other about
> > > loadsharing.
> > >
> > >
> > > shashank
> > >
> >
> > --
> > Brian F. G. Bidulock
> > [email protected]
> > http://www.openss7.org/
>
> --
> Brian F. G. Bidulock
> [email protected]
> http://www.openss7.org/
>
> _______________________________________________
> Sigtran mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/sigtran
>