Re: M3UA: 1IPSP - multiple IPSPs traffic flow
"Brian F. G. Bidulock" <[email protected]>
| Newsgroups | gmane.ietf.sigtran |
|---|---|
| Organization | http://www.openss7.org/ |
| Message-ID | <[email protected]> |
Prasad,, Prasad, Shashank S (Shashank) wrote: (Sun, 06 Nov 2005 22:25:56) > Thanx Brian for ur inputs. > However, I re-read the sections that u mentioned but I still did NOT get the > answer that I was seeking. > > I will try to give an example to better explain. > Possibly, ur answers to the questions (below) could be of good help. > > > -----------------------|----------------------------------------------- > AS1 | AS2(Loadshared), AS3(Override) > -----------------------|----------------------------------------------- > IPSP1 | IPSP2 IPSP3 > (AS1) | (AS2,AS3) (AS2) > -----------------------|----------------------------------------------- > | > > IPSP1 serves AS1. > IPSP2 serves AS2 and AS3. > IPSP3 serves AS2. > > > > 1. In a Single Ended scenario, if the IPSP1 sends ASPAC message to the IPSP2 > and IPSP3, how would IPSP1 know that IPSP2 and IPSP3 are loadshared for AS2 > ? In SE, one IPSP acts as ASP, the other as SGP. If you want a loadshared AS at IPSP2 it will have to send the ASPAC. IPSPs receiving ASPAC act as an SGP (as stated in the passages). For distribution of messages over SGP, see 1.4.2.5 and A.2.2. --brian > > I did NOT see how this would happen, and therefore, we (Tolga and I) were > discussing that IPSP2 and IPSP3 send their respective Traffic Modes for the > various AS they are serving. Which means that ASPAC-Ack from IPSP2 must send > Routing Key of AS2 and AS3 with the Traffic Mode of AS2 and AS3. > > > 2. If the IPSP2 sends ASPAC message to IPSP1, with multiple Routing Keys in > the same ASPAC, it should also send Traffic mode for different Routing Keys > too (AS2 and AS2). > > > Thanx. > shashank > > > > > > -----Original Message----- > From: Brian F. G. Bidulock [mailto:[email protected]] > Sent: Saturday, November 05, 2005 2:11 PM > 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. > > Traffic Mode included in the ASP Active Ack is simply the value from the > ASP Active message reflected back at the activating ASP. > > SGPs do not have traffic modes. Also, they do not have activation or > up/down states either. See RFC 3332 Section 1.4.2.5: > > 1.4.2.5 Message Distribution at the ASP > > The ASP must choose an SGP to direct a message to the SS7 network. > This is accomplished by observing the Destination Point Code (and > possibly other elements of the outgoing message such as the SLS > value). The ASP must also take into account whether the related > Routing Context is active or not (See Section 4.3.4.3). > > Implementation Note: Where more than one route (or SGP) is possible > for routing to the SS7 network, the ASP could, for example, maintain > a dynamic table of available SGP routes for the SS7 destinations, > taking into account the SS7 destination > availability/restricted/congestion status received from the SGP(s), > the availability status of the individual SGPs and configuration > changes and failover mechanisms. There is, however, no M3UA messaging > to manage the status of an SGP (e.g., SGP-Up/Down/Active/Inactive > messaging). > > Whenever an SCTP association to an SGP exists, the SGP is assumed to > be ready for the purposes of responding to M3UA ASPSM messages (Refer > to Section 3). > > See also RFC 3332 Appendix A.2.2: > > A.2.2 Signalling Gateway Redundancy > > Signalling Gateways may also be distributed over multiple hosts. > Much like the AS model, SGs may comprise one or more SG Processes > (SGPs), distributed over one or more hosts, using an active/backup or > a loadsharing model. Should an SGP lose all or partial SS7 > connectivity and other SGPs exist, the SGP may terminate the SCTP > associations to the concerned ASPs. > > It is therefore possible for an ASP to route signalling messages > destined to the SS7 network using more than one SGP. In this model, > a Signalling Gateway is deployed as a cluster of hosts acting as a > single SG. A primary/backup redundancy model is possible, where the > unavailability of the SCTP association to a primary SGP could be used > to reroute affected traffic to an alternate SGP. A loadsharing model > is possible, where the signalling messages are loadshared between > multiple SGPs. A broadcast model is also possible, where signalling > messages are sent to each active SGP in the SG. The distribution of > the MTP3-user messages over the SGPs should be done in such a way to > minimize message missequencing, as required by the SS7 User Parts. > > It may also be possible for an ASP to use more than one SG to access > a specific SS7 end point, in a model that resembles an SS7 STP mated > pair. Typically, SS7 STPs are deployed in mated pairs, with traffic > loadshared between them. Other models are also possible, subject to > the limitations of the local SS7 network provisioning guidelines. > > From the perspective of the M3UA layer at an ASP, a particular SG is > capable of transferring traffic to a provisioned SS7 destination X if > an SCTP association with at least one SGP of the SG is established, > the SGP has returned an acknowledgement to the ASP to indicate that > the ASP is actively handling traffic for that destination X, the SGP > has not indicated that the destination X is inaccessible and the SGP > has not indicated MTP Restart. When an ASP is configured to use > multiple SGPs for transferring traffic to the SS7 network, the ASP > must maintain knowledge of the current capability of the SGPs to > handle traffic to destinations of interest. This information is > crucial to the overall reliability of the service, for active/backup, > loadsharing and broadcast models, in the event of failures, recovery > and maintenance activities. The ASP M3UA may also use this > information for congestion avoidance purposes. The distribution of > the MTP3-user messages over the SGPs should be done in such a way to > minimize message missequencing, as required by the SS7 User Parts. > > I think these passages are quite clear. > > --brian > > > Prasad, Shashank S (Shashank) wrote: (Sat, 05 Nov 2005 12:24:04) > > Tolga, > > I agree with ur point. In a Single Ended exchange, the Traffic Mode in the > > ASPAC-Ack could be interpreted as the Traffic Mode of the Node sending > > ASPAC-Ack. This would help the peers to "know" the Traffic Mode of each > > other. > > > > Some more important points: > > The ASPAC message can have multiple (n) Routing Contexts. > > And therefore the Traffic Mode sent in the ASP-Ack must also have the > > Traffic Mode per Routing Context. > > > > Hence the ASPAC-Ack should have Traffic Mode per Routing Context. Would u > > agree ? > > > > > > > > However, there is still a catch. > > The Traffic Mode is an Optional parameter in ASPAC and ASPAC-Ack messages. > > At present, M3UA has left to the implementators on how to interpret > Traffic > > Modes of each other, in case, the peers do NOT exchange Traffic Modes. > > > > I was therefore suggesting that we could have M3UA suggest a default > > implementation of Traffic Mode, and rather NOT leave to the > implementation. > > And I suggested Override, because, I would always believe that whenever a > > node gets the last ASPAC or ASPAC-Ack (intrododuced in the course of our > > discussion), without any Traffic Mode (since it is Optional), it shall > > interpret that the peer intends to use this ASP for its communication. > > > > > > At the same time, we ALSO have ur suggestion about IPSPs sending their > > respective Traffic modes in ASPAC-Ack messages. > > > > > > shashank > > > > > > -----Original Message----- > > From: [email protected] [mailto:[email protected]]On > > Behalf Of Tolga Asveren > > Sent: Saturday, November 05, 2005 1:42 AM > > To: [email protected] > > Subject: RE: [Sigtran] M3UA: 1IPSP - multiple IPSPs traffic flow > > > > > > Shashank, > > > > > -----Original Message----- > > > From: [email protected] [mailto:[email protected]]On > > > Behalf Of Prasad, Shashank S (Shashank) > > > Sent: Friday, November 04, 2005 2:08 PM > > > To: [email protected] > > > Subject: RE: [Sigtran] M3UA: 1IPSP - multiple IPSPs traffic flow > > > > > > > > > Reply embedded. > > > > > > shashank > > > > > > > > > -----Original Message----- > > > From: [email protected] [mailto:[email protected]]On > > > Behalf Of Tolga Asveren > > > Sent: Friday, November 04, 2005 10:09 PM > > > To: [email protected] > > > Subject: RE: [Sigtran] M3UA: 1IPSP - multiple IPSPs traffic flow > > > > > > > > > Shashank, > > > > > > > -----Original Message----- > > > > From: [email protected] [mailto:[email protected]]On > > > > Behalf Of Prasad, Shashank S (Shashank) > > > > Sent: Friday, November 04, 2005 11:07 AM > > > > To: 'Tolga Asveren'; [email protected] > > > > Subject: RE: [Sigtran] M3UA: 1IPSP - multiple IPSPs traffic flow > > > > > > > > > > > > Oh OK ! > > > > Looks like, it could potentially happen that NodeB can limit itself to > > > > sending traffic for PS1 on only one of associations also, rather > > > > than both. > > > > However, IPSP1 has really to "listen" at both the associations. > > > > Is that correct ? > > > [TOLGA]Yes. Please also note that it is the M3UA-User which controls > this > > > behavior on Node-B, i.e. this is not loadhsaring on M3UA level > > > but one layer > > > above. IPSP2 and IPSP3 have only one peer anyway, IPSP1. When > > > they receive a > > > message from their user, they will send it to IPSP1. > > > > > > [SHASHANK] OK, I get ur point related to the role of M3UA User. > > > > > > > > > > > > > > > > > > > > A couple of more questions that now comes up: > > > > 1. In a single ended scenario, how could have IPSP1 (at NodeA) > > > determined > > > > the Traffic Mode of AS2 at NodeB, if the ASP Active was sent > > > from IPSP1 to > > > > IPSP2 and IPSP3 ? (Instead of what is shown my illustration) > > > [TOLGA]Through local configuration, please note Traffic Mode parameter > is > > > optional. OTOH, I think that it could be an idea to modify the protocol > a > > > bit to use TrafficMode parameter in ASPAC-ACK to inform ASPAC sending > side > > > about traffic mode on the peer side in case it is necessary. > > > > > > > > > > [SHASHANK] Yeah, I believe that ASPAC-ACK can be tailored to to > > > inform ASPAC > > > sending side > > > about traffic mode on the peer side in case it is necessary. That > > > will help > > > a > > > great deal in the single exchange scenarios to exchange the Traffic > Modes. > > > At present, the M3UA protocol does NOT say anything explicitly on this. > > > > > > Alternatively, the protocol could also define a default Traffic Mode > > > explicitly (possibly Override). And in case the peers do NOT exchange > > > the Traffic mode, the default Traffic Mode (as specified in the specs) > can > > > be used. > > > > > > Now that we understand the need, do u think that this could be taken up > > > further ? > > [TOLGA]I am not sure whether it is a good idea to declare a default > traffic > > mode but allowing both sides to use Traffic Mode parameter makes sense to > > me. Similar concept could be applied for SGPs as well, i.e. they declare > > their traffic mode with Traffic Mode in ASPAC-ACK -actually this in > > practicall life is probably less useful-. Any other opinions about this > > issue? It looks like a useful feature to me to use Traffic Mode in both > > directions. > > > > > > > > > > 2. In a single exchange scenario, isn't it needed to have the peer ASs > > > > having the same Traffic Mode ? > > > [TOLGA]I believe what you mean as "AS traffic mode" is traffic > > > mode of peer > > > IPSPs in the context of an AS. As far as I can see different traffic > modes > > > shouldn't be a problem. Important is that AS becomes ACTIVE/INACTIVE > > > simultaneously at both sides. > > > > > > > [SHASHANK] I agree with the answer to my second question. > > > > > > > shashank > > > > > > > > > > > > > > > > -----Original Message----- > > > > From: [email protected] [mailto:[email protected]]On > > > > Behalf Of Tolga Asveren > > > > Sent: Friday, November 04, 2005 8:51 PM > > > > To: [email protected] > > > > Subject: RE: [Sigtran] M3UA: 1IPSP - multiple IPSPs traffic flow > > > > > > > > > > > > This is implementation/traffic type dependent and is not something > > > > standardized by M3UA. > > > > > > > > > -----Original Message----- > > > > > From: Prasad, Shashank S (Shashank) [mailto:[email protected]] > > > > > Sent: Friday, November 04, 2005 10:28 AM > > > > > To: 'Tolga Asveren'; [email protected] > > > > > Subject: RE: [Sigtran] M3UA: 1IPSP - multiple IPSPs traffic flow > > > > > > > > > > > > > > > Thanx Tolga. U are right in understanding my question. > > > > > > > > > > Followup Question: > > > > > Since IPSP2 and IPSP3 are serving the same AS, what would determine > at > > > > > NodeB, if the traffic to IPSP1 is > > > > > to be sent via IPSP2 or IPSP3 ? > > > > > > > > > > > > > > > shashank > > > > > > > > > > -----Original Message----- > > > > > From: [email protected] [mailto:[email protected]]On > > > > > Behalf Of Tolga Asveren > > > > > Sent: Friday, November 04, 2005 8:13 PM > > > > > To: [email protected] > > > > > Subject: RE: [Sigtran] M3UA: 1IPSP - multiple IPSPs traffic flow > > > > > > > > > > > > > > > Shashank, > > > > > > > > > > As far as I understand your question: > > > > > > > > > > You have IPSP1, IPSP2, IPSP3. You have one RK. IPSP sends ASPAC > > > > > for this RK > > > > > to IPSP2 and IPSP3. IPSP2 and IPSP3 are working in loadsharing > > > > > mode. You are > > > > > wondering whether IPSP1 will receive traffic from both IPSP2 > > > and IPSP3. > > > > > > > > > > Yes, it can, but I wouldn't call it traffic being loadshared to > > > > > IPSP1. IPSP2 > > > > > and IPSP3 are not the same entities. OTOH it makes sense to speak of > > > > > loadharing traffic from IPSP1 to IPSP2 and IPSP3 because > > > traffic from a > > > > > single source is distrubuted to multiple peers. > > > > > > > > > > Tolga > > > > > > > > > > > -----Original Message----- > > > > > > From: [email protected] [mailto:[email protected]]On > > > > > > Behalf Of Prasad, Shashank S (Shashank) > > > > > > Sent: Friday, November 04, 2005 9:48 AM > > > > > > To: '[email protected]' > > > > > > Subject: [Sigtran] M3UA: 1IPSP - multiple IPSPs traffic flow > > > > > > > > > > > > > > > > > > Hi, > > > > > > I had a specific question related to a specific scenario > > > > explained below > > > > > > (Single Exchange scenario) > > > > > > > > > > > > NodeA supports 1 PS with 1 IPSP > > > > > > NodeB supports 1 PS with 2 IPSPs in Loadshared mode. > > > > > > > > > > > > > > > > > > There are two associations between NodeA and NodeB. > > > > > > The first association is between IPSP1 (NodeA) and IPSP2 (NodeB). > > > > > > The second association is between IPSP1 (NodeA) and IPSP3 (NodeB). > > > > > > > > > > > > The IPSP2 and IPSP3, which are serving loadshared for the PS2 > > > > on NodeB, > > > > > > send an ASP Up to IPSP1 serving for PS1 on NodeA. Which means > > > > > > that IPSP2 and > > > > > > IPSP3, > > > > > > serving a loadshared PS2, are essentially telling NodeA to > > > > > > loadshare all the > > > > > > traffic > > > > > > for PS2, between IPSP2 and IPSP3. > > > > > > > > > > > > The above concepts are also illustrated below....(I have > > > purposefully > > > > > > avoided AS-ACTIVE notification) > > > > > > > > > > > > > > > > > > > > > > > > NodeA <------------NodeB------------> > > > > > > > > > > > > PS1-IPSP1 PS2-IPSP2 > PS2-IPSP3 > > > > > > | | | > > > > > > |<-----ASP Up------------| | > > > > > > |-------ASP Up Ack------>| (Assoc #1) | > > > > > > | | | > > > > > > | | | > > > > > > |<--------------------ASP Up------------------------| > > > > > (Assoc #2) > > > > > > |----------------------------ASP Up Ack------------>| > > > > > > | | | > > > > > > | | | > > > > > > | | | > > > > > > |<--ASP Active(Ldshr)----| | > > > > > > |------ASP Active Ack--->| | > > > > > > | | | > > > > > > | | | > > > > > > | | | > > > > > > |<--------------------ASP Active(Ldshr)-------------| > > > > > > |----------------------------ASP Up Ack------------>| > > > > > > | | | > > > > > > | | | > > > > > > |---NOTIFY(AS-ACTIVE)--->| | > > > > > > |--------------------------NOTIFY(AS-ACTIVE)------->| > > > > > > | | | > > > > > > > > > > > > > > > > > > > > > > > > Questions: > > > > > > Assuming a single exchange scenario, would the traffic towards > > > > > > PS1 on NodeA, > > > > > > > > > > > > be also loadshared across 2 associations ? > > > > > > > > > > > > I thought it would and hence another follow-up question: > > > > > > It looks like a loadshared peer (NodeB in our case) with > > > > > multiple IPSPs, > > > > > > is putting a constraint on the NodeA, to ALSO be ready to > > > > > receive data on > > > > > > multiple associations and possibly loadshared. Is this a fair > > > > > > understanding > > > > > > ? > > > > > > > > > > > > > > > > > > shashank > > > > > > > > > > > > _______________________________________________ > > > > > > Sigtran mailing list > > > > > > [email protected] > > > > > > https://www1.ietf.org/mailman/listinfo/sigtran > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > Sigtran mailing list > > > > > [email protected] > > > > > https://www1.ietf.org/mailman/listinfo/sigtran > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > Sigtran mailing list > > > > [email protected] > > > > https://www1.ietf.org/mailman/listinfo/sigtran > > > > > > > > _______________________________________________ > > > > Sigtran mailing list > > > > [email protected] > > > > https://www1.ietf.org/mailman/listinfo/sigtran > > > > > > > > > > > > > > > > _______________________________________________ > > > Sigtran mailing list > > > [email protected] > > > https://www1.ietf.org/mailman/listinfo/sigtran > > > > > > _______________________________________________ > > > Sigtran mailing list > > > [email protected] > > > https://www1.ietf.org/mailman/listinfo/sigtran > > > > > > > > > > > _______________________________________________ > > Sigtran mailing list > > [email protected] > > https://www1.ietf.org/mailman/listinfo/sigtran > > > > _______________________________________________ > > Sigtran mailing list > > [email protected] > > https://www1.ietf.org/mailman/listinfo/sigtran > > -- > Brian F. G. Bidulock > [email protected] > http://www.openss7.org/ -- Brian F. G. Bidulock [email protected] http://www.openss7.org/