Re: Multiple SUA SGs, sending for SSP from SGs
Stanislav Ivanovich <[email protected]>
| Newsgroups | gmane.ietf.sigtran |
|---|---|
| Message-ID | <[email protected]> |
Dear Brian and Tolga, First, thank you Tolga and Brian, indeed very much for your great contribution and patience both of you show to all of us SIGTRAN implementors every single day by answering long questions! Please, I kindly ask you to have just a little bit more patience with this (in my view) very essential issue. As we have seen here whatever question one arise (in this case multiple SG'es or something else) he/she will finish at the core of the issue which I am to be honest very afraid of. Brian, I really see no problems in understanding AS concepts when they apply on interface between MTP3/SCCP and their user-functions or in-between two user-functions whatever you call the hosting processes. However when one applies this concept in between two MTP3/SCCP instances I have tremendous conceptual problems. I understand your proposal Brian and this seems reasonable -> if one does not want/like the AS concept in between two MTP3/SCCP instances then he/she does not need to use it (to be honest I thought it was mandatory since RC was mandatory parameter is DATA messages of SUA but now I see that this is not the case). However if one vendor supports this (because he understands this) and my company does not support this (because I do not understand it) this brings my company in serious disadvantage! Therefore regardless of implementation of a particular feature the xxUA protocols offer I first need to fully understand all the capabilities/possibilities the specifications give me. My point is that in my current understanding AS concept in between two MTP3/SCCP instances brings me just restrictions (i.e. some configurations are not possible), while OTOH I get nothing "in-return" (e.g. better redundancy... etc). In my view SGP-SGP brings you the same redundancy as ASP-SGP and IPSP-IPSP protocols while it does not impose any kind of restrictions. Which restrictions? Here are just few of them: 1) if AS is to be used in between 2 MTP3/SCCP instances then it implies that AS represents an SS7 destination. However in MTP3/SCCP networks relay can be easily built because when one sends traffic it is irrelevant what is the state of the sending entity. What only matters is the accessibility state of remote destination. For example if I have SGP connected to ASP equipped with relay which serves local user for 2-100 and supports relay for 2-200 then according to xxUA specifications ASP must not send (!) traffic until it is not prepared to receive any. So ASP has to activate its (local) receiver for 2-100 just to make 2-200 possible to send traffic over it to SGP!?! Why this? This would imply that ASP has to register 2-200 at SGP also what is very different from SCCP/MTP3 relay. In MTP3/SCCP networks one can have a sender sending over relay and receiving traffic over another independent relay. My comment is -> This has serious consequence on building of relay networks based on these AS principles. It is obvious why in both M3UA and SUA specifications it is explicitly said ASP is not allowed to send (!) until it is activated itself within an AS at SGP (thus be able to receive) -> this is how User Parts (or SCCP users) work: if they are not connected to MTP3/SCCP layers then they will not be able to either send or receive traffic. However if we do not understand AS'es as MTP3/SCCP user functions but as SS7 addresses in between two MTP3/SCCP instances then this becomes serious restriction. Note that removing restriction for ASP/IPSP to send (!) traffic regardless of its activation within an AS is not "administrative" but has serious technical consequence -> moving of SSNM messages from SGP to ASP from ACTIVE to DOWN state... 2) In traditional MTP/SCCP networks one can have destination SPC1 reachable over two STP functions STP1 and STP2 while SPC2 reachable over only STP1 for example. However by having the AS concept one is not allowed to have at SPCx place (for example an IPSP) an SS7 address in two different AS'es. So AS1 cannot be (SPC1, SPC2) and STP1 is a process supporting AS1 while AS2 is (SPC1) and STP2 is supporting AS2. Because of resolution problems at SPCx place which must have AS configuration in this way: AS1 (SPC1) supported by STP1 and STP2 and AS2 (SPC2) supported by STP1 one must introduce 2 AS'es at STP1 place! This kind of influence of one node on the configuration of other one you cannot find in traditional SS7 networks! Another practical problem! 3) Please Brian, I kindly ask you to make your opinion about this (I would very much appreciate opinions of other SUA RFC co-authors as well!) -> if we allow that ASP/IPSP hosts MTP3/SCCP layers then this is not only against basic definition in the SUA paper itself: e.g. SUA RFC section 1.2.2. "Terminology": "IP Server Process (IPSP) - A process instance of an IP-based application. An IPSP is essentially the same as an ASP, except that it uses SUA in a peer-to-peer fashion." but even more -> this is very serious conceptual problem! Why do we define several process types and 2 different protocols if there is no difference between the processes? By reading all the threads last weeks I see that even ASP can send SSNM messages towards SGP, IPSP can send and receive SSNM so actually even the difference between the protocols themselves disappears! This is very serious conceptual problem for which I haven't still received any convincing answer -> the only answers I received are these: ---------------------------------------- [John Loughney] "Process-types, in my view, are illustrative text, to give an implementor an idea of what we are talking about - however, they are not meant that each capability MUST be implemented as a separate process." ---------------------------------------- [John Loughney] "The notion of a process, IMO, is an implementation issue - different OSes may behave different." ---------------------------------------- see thread "[Sigtran] AS concepts and Relay in SUA and M3UA" I am really very sorry but this does not sound very convincing, does it? 4) If the essence of the AS concept is a redundancy concept (AS is served by several signaling processes) then there is no redundancy scheme which SGP-SGP concept does not provide and which could be provided by existing protocols (ASP-SGP and IPSP-IPSP). However advantage if SGP-SGP model is that it does not suffer from the restrictions/problems described in point 1-3 above. However SGP-SGP concept provides us with the resolution of all the problems described in points 1-3 above and at the same time it preserves the existing protocols and keeps the signaling process definition clear and consistent! Tolga, Thank you for your comments! I do not only understand this: [Tolga Asveren] "AFAICS, the main advantage of ASP/SGP model is to allow routing on AS level, i.e. in sub-PC granularity." In my view this is not effectively possible. Yes, one can have AS configured as User Part of SCCP SSN (i.e. granularity below SPC). However, in my view, this does not imply that relay based on this is effectively possible! This is for the following reasons: 1) How would STP based on finer granularity support this kind of management? When a process receives DUPU indicating UPU or SSP then it will not try to divert traffic to another "STP" since it assumes that the user function is dead rather then STP connection to it. Especially if we are to relay that UPU/SSP message into SS7 network... 2) Different types of traffic granularity require support for different types of Traffic Management in order to support relay based on different granularities. ANSI MTP is a good example -> there you can find the concept of Cluster Destinations. However the essence of this concept is that it is unique granularity across all the STP nodes which is not the subject of "bilateral" agreement between two adjacent STP nodes what we have with IPSP processes equipped with relay capability. In other words in ANSI MTP networks all the STP across the network that is to use Cluster concept use the same (!) traffic granularity which is supported by the same Traffic Management which is not subject to agreement between two STP nodes but spans across the whole network. In xxUA networks we have management by SSNM and AS is the agreement between two adjacent nodes... All in all - in my opinion not very efficient... Thank you both Brian and Tolga once again for your great support to SIGTRAN community as well as your patience! with best regards/ Stanislav Ivanovich "Brian F. G. Bidulock" <[email protected]> wrote: Stanislav, Neither the ASP-SGP nor IPSP-IPSP models require you to use AS or RC. Define 1 AS per ASP only and give it RC value 0. Make that AS an entire point code (or network appearance for that matter). Then this RK:AS:RC 3-tuple that bothers you so much falls away. --brian Stanislav Ivanovich wrote: (Fri, 13 Jan 2006 12:19:29) > > Hello, > > > > In addition to the last mail: > > > > The original idea was to have one user function at ASP connected to 2 > SGW (thus two independent SCCP/MTP layers). So in order to solve this > we said -> we need an (i.e. 1) MTP/SCCP layer at ASP place which is to > communicate with independent MTP/SCCP layers at SGW'es side. > > > > However here you again have one user function connected to one > MTP/SCCP layer. This is exactly what the Tolga's SGP-SGP solution > covers. The only difference is that ASP-SGP and IPSP-IPSP protocols do > mandate use of AS concepts with all the restrictions which imply from > these protocols... which we do not have in SGP-SGP protocol. > > > > So again we have very fundamental question -> what does AS/RC concept > provide us with on the interface between two MTP/SCCP relay equipped > processes? > > > > It brings us just restrictions and problems nothing else! > > > > / stanislav > -- Brian F. G. Bidulock [email protected] http://www.openss7.org/ --------------------------------- Yahoo! Photos Ring in the New Year with Photo Calendars. Add photos, events, holidays, whatever. _______________________________________________ Sigtran mailing list [email protected] https://www1.ietf.org/mailman/listinfo/sigtran