Re: 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.

If you want both IPSPs to each have an AS an traffic mode, use DE instead
of SE.

--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/