RE: M3UA: 1IPSP - multiple IPSPs traffic flow

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/