RE: SE-IPSP definition
"Tolga Asveren" <[email protected]>
| Newsgroups | gmane.ietf.sigtran |
|---|---|
| Message-ID | <[email protected]> |
Shashank, > -----Original Message----- > From: Prasad, Shashank S (Shashank) [mailto:[email protected]] > Sent: Wednesday, November 09, 2005 12:41 PM > To: 'Tolga Asveren'; [email protected] > Subject: RE: [Sigtran] SE-IPSP definition > > > Thanx Tolga, > I would appreciate if we could clarify on IPSP considerations in the next > release of the spec. This is really essential for clarity. > > I would also appreciate the RFC explicitly stated about a bit > more Modes (SE > and DE) and the inapplicability of SSNM messages for IPSPs. It would be > great to have the state machines for IPSPs discussed seperately. > > A few more questions to understand the model that u and Brian drafted. > 1. Is the SGPF in the IPSP different from the SGP in a Singnaling > Gateway ? [TOLGA]SGPF/ASPF/IPSPF etc.. are just terms we are using to refer to M3UA functionality to be implemented for the corresponding entity, SGP, ASP and IPSP respectively. I wouldn't call them "official" terms. Just follow what the specification says about IPSP behavior. I personbally call this functionality IPSPF. > 2. What did u really mean when u said relaying (in ur last mail) ? [TOLGA]Being able to send received messages to another entity, similar to what an STP does in MTP3 network. > > Can u share in slightly greater detail about the IPSP model explaining the > ASPF and SGPF ? [TOLGA]As said above, just follow the IPSP behavior as defined in the current specification, there is nothing more to it. > > Is it possible to have a look at the draft that u and Brian > prepared ? That > would give us more perspective on IPSPs and it relevance as understood by > M3UA community. [TOLGA]That draft is about SG-to-SG communication. Let me submit a new version of it -in a few days- and then you can have better idea about it. > > Let me give a fresh perspective to my understanding of IPSPs :) [TOLGA]Just follow the IPSP behavior as specified in the document ;-) > > shashank > > > > > > > > > -----Original Message----- > From: [email protected] [mailto:[email protected]]On > Behalf Of Tolga Asveren > Sent: Wednesday, November 09, 2005 9:06 PM > To: [email protected] > Subject: RE: [Sigtran] SE-IPSP definition > > > Shashank, > > > -----Original Message----- > > From: Prasad, Shashank S (Shashank) [mailto:[email protected]] > > Sent: Wednesday, November 09, 2005 10:36 AM > > To: 'Tolga Asveren'; [email protected] > > Subject: RE: [Sigtran] SE-IPSP definition > > > > > > Tolga, > > > > My issues: > > > > I am NOT able to understand the following IPSP model that Brian > > had said :) > > I felt that an IPSP can have ASPF and SGPF but an ASPF using the > > services of > > SGPF was NOT very clear. > > > > IPSP A IPSP B > > ___________ ___________ > > | _______ | | _______ | > > | | | | | | | | > > | | ASPF | | | | ASPF | | > > | |_______| | | |_______| | > > | | | | | | > > | ___|___ | | ___|___ | > > | | | | Association | | | | > > | | SGPF |-|--------------------|-| SGPF | | > > | |_______| | | |_______| | > > |___________| |___________| > [TOLGA]The above model is not something existing in official > specifications, > i.e. it is nothing you should be concerned about in terms of understanding > how IPSP as defined in exiting M3UA documents works. As Brian > said, I wrote > a draft -Brian also being another main contributor- but it did > not become a > WG item. I still think it is a good idea, mainly because it supports > relaying. OTOH, I think SE-IPSP model works fine as well, but it does not > have relaying capability -intentionally-. > > > > > > Next is that u said that IPSP do NOT use SSNM messages. > > I did NOT read anywhere explicit in the specs. Even the 3GPP > > standards want > > IPSPs to receive and send DUPU and SCON :). > [TOLGA]Too bad for 3GPP, it shows that they did not fully understand the > concept of IPSP. Availability for IPSP is managed by the state of > AS, so no > need for DUPU. For congestion, right now one needs to rely on SCTP > congestion but Brian is working on a ASPCONG draft to define a new ASPTM > message to convey AS congestion information. > If it is not clear in the current document that SSNM is not to be used for > IPSP, we may clarify this with a sentence. Actually lack of "IPSP > Considerations" sections for SSNM related procedures also hints for not > using SSNM for IPSP. > > If one want a model relying on SSNM, SG-SG communication is the way to > go -which the draft I authored was about-. > > > > > > About the Traffic Mode both ways in SE: > > We should surely add that enhancement suggested. My proposal > was NOT based > > on a different premise. I never had an ASPF using the services of > > SGPF. May > > be the spec should draw these diagrams... > > > > > > I had asked a question before: > > How would ur model fit in assuming that I have two peers sending SCCP > > messages to each other over an association ? > > > > +------+ +------+ > > |SCCP- | |SCCP- | > > | User | | User | > > +------+ +------+ > > | SCCP | | SCCP | > > +------+ +------+ > > | M3UA | | M3UA | > > +------+ +------+ > > | SCTP | | SCTP | > > +------+ +------+ > > | IP | | IP | > > +------+ +------+ > [TOLGA]I am not sure about what you are asking but both M3UA > stacks perform > functionality defined for M3UA-IPSP in the specification and that is it. > > > > > > BTW, what is C/SE-IPSP and D/SE-IPSP > [TOLGA]Something we need to get rid of :-) It refers to a SE-IPSP > acting as > client or server in the context of a "transaction", transaction meaning an > ASPTM message pair exchange, e.g. ASPAC/ASPAC-ACK. IMO, it is extremely > confusing. > > > > > > shashank > > > > > > > > -----Original Message----- > > From: [email protected] [mailto:[email protected]]On > > Behalf Of Tolga Asveren > > Sent: Wednesday, November 09, 2005 8:26 PM > > To: [email protected] > > Subject: RE: [Sigtran] SE-IPSP definition > > > > > > Shashank, > > > > I don't think there is as significant issue as you mention. As > > far as I can > > see, some text cleanup is the only thing we need-to get rid of > C/SE-IPSP , > > S/SE-IPSP distinction-. > > > > The original problem you mentioned -having traffic mode bothways- is > > something useful IMO as well. That can be added to the document > > but it does > > not change anything architecturally in terms of IPSP as defined in the > > document. > > > > What other issues do you consider as problems associated with IPSP? > > > > Tolga > > > > > -----Original Message----- > > > From: Prasad, Shashank S (Shashank) [mailto:[email protected]] > > > Sent: Wednesday, November 09, 2005 10:08 AM > > > To: 'Ken A Morneault (kmorneau)'; Tolga Asveren; [email protected] > > > Subject: RE: [Sigtran] SE-IPSP definition > > > > > > > > > Ken, > > > There is a serious issue in understanding the differences in > > IPSP and what > > > it means. > > > I am sure that u would have gone thru the mails where serious > > > issues of IPSP > > > understanding is evident. > > > > > > I feel that it should be resolved in the next draft before > > anything else. > > > An extention draft must include IPSP considerations. > > > > > > shashank > > > > > > > > > -----Original Message----- > > > From: [email protected] [mailto:[email protected]]On > > > Behalf Of Ken A Morneault (kmorneau) > > > Sent: Wednesday, November 09, 2005 8:12 PM > > > To: Tolga Asveren; [email protected] > > > Subject: RE: [Sigtran] SE-IPSP definition > > > > > > > > > > > > > > > Hi Tolga, > > > > > > Sorry for the delayed response. I took some time off. > > > > > > Regarding the IPSP text, that is an area that Javier > > > updated. At this point, I'm not sure if we will be > > > able to change the text. The document is supposed to > > > be heading to the Editor's queue to be published. > > > > > > Regards, > > > > > > Ken > > > > > > -----Original Message----- > > > From: [email protected] [mailto:[email protected]] On > > > Behalf Of Tolga Asveren > > > Sent: Tuesday, November 08, 2005 9:13 AM > > > To: [email protected] > > > Subject: RE: [Sigtran] SE-IPSP definition > > > > > > A few typo scorrected below. > > > > > > > -----Original Message----- > > > > From: [email protected] [mailto:[email protected]]On > > > > Behalf Of Tolga Asveren > > > > Sent: Tuesday, November 08, 2005 8:35 AM > > > > To: [email protected] > > > > Subject: [Sigtran] SE-IPSP definition > > > > > > > > > > > > Brian, > > > > > > > > -changed the subject of the thread- > > > > > > > > Ken, I re-checked and current bis document seems to be updated > > > > partially > > > > (4.3 has the definition I copy/pasted below -which is fine-, OTOH > > > > still there is text mentioning about C-IPSP, D-IPSP for > SE-model. The > > > > idea probably was to assign roles to IPSPS per "transaction", i.e. a > > > > message pair like ASPAC/ASPAC-ACK, ASPIA/ASPIA-ACK, but I > believe the > > > > concept of "client" > > > > and "server" can be misleading because it can be considered as one > > > > IPSP always playing client or server role while communicating with a > > > > certain peer IPSP. IMHO, the terms C-IPSP/D-IPSP confuse rather than > > > > clarify. > > > > > > > > Brian, more comments below. > > > > > > > > Tolga > > > > > > > > > -----Original Message----- > > > > > From: [email protected] [mailto:[email protected]]On > > > > > Behalf Of Brian F. G. Bidulock > > > > > Sent: Monday, November 07, 2005 7:52 PM > > > > > To: Tolga Asveren > > > > > Cc: [email protected] > > > > > Subject: Re: [Sigtran] M3UA: 1IPSP - multiple IPSPs traffic flow > > > > > > > > > > > > > > > Tolga, > > > > > > > > > > Tolga Asveren wrote: > > > > > (Mon, 07 Nov 2005 14:36:07) > > > > > > > > > > --X--snip--X-- > > > > > > > > > > > [TOLGA]If you look to " M3UAbis - consensus on comment > > > > resolution - Part > > > > > > 1&2" thread -which has happened later than the thread you > > > > > mentioned ;-) -, > > > > > > you will see that everybody involved in the discussion > > > > > "Valerie, you, myself > > > > > > and Javier" agreed to return to the original SE-IPSP model. The > > > > > conclusion > > > > > > was to use the text proposed by Valerie. It seems the bis > > > > > document is not > > > > > > updated accordingly. Ken, was there a technical > objection for that > > > > > > > > > change -actually I would call it reverting back to the original > > > > > model- or is > > > > > > this just an oversight? > > > > > > > > > > Really? Did you mean in "M3UAbis - consensus on comment > resolution" > > > > > > > > 23 Aug 2004 where Valerie says: > > > > > > > > > > IPSP-SE behaviour: > > > > > The IPSP acting as the SGP must sends ASPAC-ack only > when its side > > > > > of the RK is ready. The IPSP acting as the ASP is responsible to > > > > > retry the ASPAC until the remote peer is ready. > > > > > When the IPSP acting as the SGP wants to stop application traffic > > > > > from its side, it must send ASPIA-ack. > > > > [TOLGA] No, what I mean is the message on 08/30/2004 "M3UAbis - > > > > consensus on comment resoluti on-Part 1&2" > > > > > > > > 1- IPSP Single Exchange (SE) model. Only a single exchange of ASPTM > > > > or ASPSM messages is needed to change the IPSP state. > This means > > > > that a set of request from one end and acknowledge from the > > > other > > > > will be enough. The RK must define both sides of the traffic > > > flow. > > > > Each exchange of ASPTM or ASPSM messages can be initiated by > > > either > > > > IPSP. For this exchange, the initiating IPSP follows the > > > procedures > > > > described in section 4.3.1. > > > > > > > > The above is the original concept we defined for SE-IPSP mode. > > > > There are no > > > > predefined client/server relationship, a pure peer-to-peer > > > relationship. > > > > > > > > > > Or did you mean where we agreed to back out of the v03 changes > > > > > (which is what I think you are referring to with the IPSPF) and go > > > > > back to the > > > > > v02 description > > > > > (which is the same as RFC 3332 and the SGPF/ASPF approach). > > > > [TOLGA]No, what I mean as "IPSPF approach is v02 definition. As long > > > > as the problem is how you and I name it, there is no problem from > > > > specification point of view but I would call it IPSPF > because it has a > > > > > > > different machine > > > > > > ^^^^^^^^^ > > > > state > > > machine > > > > than SGPF and ASPF and does not send/receive messages. I believe > > > ^^^^^^^^^ > > > certain messages, e.g. SSNM > > > > you use the > > > > term SGPF in the context of a "transaction" not inthe context of the > > > > overall realtionship between two peer IPSPs. > > > > > > > > > > --brian > > > > > > > > > > > > > > > > > Considering the way it is supposed to work, i.e. according to > > > > > the text we > > > > > > had concensus on, we can't speak of exact SGPF semantics for > > > > > SE-IPSP even > > > > > > from basic message exchange point of view, e.g. SGPF does not > > > > > send ASPAC, > > > > > > can't receive ASPAC-ACK, sends SSNM etc...With SE-IPSP both > > > > > sides can send > > > > > > ASPAC/ASPAC-ACK and they don't send SSNM and they have a > > > > > > peer-to-peer relationship, not a client/server relationship. > > > > > > > > > > See Valerie's description above. As I have mantained, it is clear > > > > > that one IPSP acts in an SGP role and the other in an ASP role. > > > > > > > > > > > > > > > > > Regarding the issue we are discussing in this thread -being > > > > > able to support > > > > > > traffic mode in both directions-I think it is a nice thing to > > > > > have, because > > > > > > we have application logic at both sides, which may want to > > > > use different > > > > > > traffic . > > > > > > > > > > Again, the IPSP acting as an SGP in SE mode is not > required to have > > > > > a traffic mode. > > > > > > > > > > In the normal ASP/SGP exchange, the SGP does not have a > traffic mode > > > > > > > > to place in the ASPAC Ack. Any traffic distribution > towards the SGP > > > > > > > > is an SG-wide attribute and does not differ from AS to AS, nor ASP > > > > > to ASP. > > > > > > > > > > --brian > > > > > > > > > > -- > > > > > Brian F. G. Bidulock > > > > > [email protected] > > > > > http://www.openss7.org/ > > > > > > > > > > _______________________________________________ > > > > > 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 >