RE: M3UA: 1IPSP - multiple IPSPs traffic flow
"Prasad, Shashank S (Shashank)" <[email protected]>
| Newsgroups | gmane.ietf.sigtran |
|---|---|
| Message-ID | <6733C768256DEC42A72BAFEFA9CF06D210FB6887@ii0015exch002u.iprc.lucent.com> |
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. 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/