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