Re: AS concepts and Relay in SUA and M3UA

Barry,

Well, Barry, the major difference between the two is SUA IPSP
supports relaying and M3UA IPSP does not.

--brian

Barry Nagelberg wrote:                                                               (Mon, 19 Dec 2005 11:54:36)
> Stanislav,
> 
> Your option #1 below is unnecessary - Brian's statement that the "AS concept for SUA is different from that for M3UA" is
> nonsense.
> 
> The AS concept is identical in all xUA specs. There may be minor differences in areas such as how the AS is configured,
> but the concept is identical.
> 
> Barry Nagelberg
> Adax, Inc.
> 
> -----Original Message-----
> From: [email protected] [mailto:[email protected]]On Behalf Of Stanislav Ivanovich
> Sent: Monday, December 19, 2005 11:37 AM
> To: SIGTRAN
> Subject: RE: [Sigtran] AS concepts and Relay in SUA and M3UA
> 
> 
> John, Brian
> 
> I think that at this point it is rather clear that SUA paper suffers from the serious children's diseases. All the
> comments I have read today confirm my original impression that SUA RFC added SCCP alike relay (i.e. GT relay) in an
> ad-hoc manner.
> 
> The major objection is that it uses AS/RC and Signaling Process concepts as used/defined in the M3UA RFC (by making
> copy/paste from M3UA RFC) and at the same time we hear statements like these:
> 
> -----------------------------------------------------------------------------------------
> [JOHN]
> 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]
> The notion of a process, IMO, is an implementation issue - different OSes may behave
> different.
> -----------------------------------------------------------------------------------------
> [BRIAN]
> It might help you to start with the understanding that, although common text was shared to save redundant wordsmithing,
> the AS concept for SUA is different from that for M3UA.  Just as it is different for M2UA and IUA, etc.
> -----------------------------------------------------------------------------------------
> 
> All the statements above do not make sense especially the second one. Of course that no one expects the defintion of a
> process in an operating system language but instead in the terms of:
> 
> 1) functionality they perform (e.g. do they contain application functionality or not)
> 2) communication protocol the entities/pr! ocesses use to communicate with each other
> 
> As I said in a mail sent on Friday last week:
> 
> "A protocol designer must not make any assumptions on the implementation or installation of different protocol entities!
> In another words protocol design must only consider communication between logical entities and must not show any
> dependency on the installation!
> Thus in SUA case you achieve SCCP relay at SCCP endpoint by installing two protocol entities at the same place (i.e. in
> the same machine), namely IPSP (or ASP) and SRP (or SGP).
> However nature of the relation between the processes is still clear and kept intact!
> Namely IPSP is application and SRP (or SGP whatever you call it) is a process which performs SCCP relay."
> 
> 
> Practically speaking, in my view you have two alternatives for SUA:
> 
> 1) Abandon or change the original AS/RC/signaling process xxUA c! oncepts (which are strictly followed by M3UA).
> In this case serious rework on the SUA paper is needed since the paper uses (more or less) copy/paste of the fundamental
> procedures from M3UA.
> 
> 2) Follow the fundamental/original AS/RC/signaling process principles (which are copy/pasted from M3UA) but cover the
> relay functionality by introducing another relationship since as said above the AS/RC concept does not originally cover
> the relay. In this case you need to extend the role of SGP process to relay between IP-IP and introduce SGP-SGP
> relationship.
> 
> I prefer the second option since the AS/RC concept has been originally designed/tailored for direct communication. If
> one wants to think of any relay in xxUA networks he/she fill very soon realize the complete unsuitability of the AS/RC
> concept for the building of relay equipped networks. This is especially the case if one wants to do that by following
> mandatory SE ! model. In other words there are serious reasons for not allowing the AS/RC concepts be visible/used on
> the interface between two relay points.
> 
> However regardless of this fact the RC (as a pointer to an application served by an application process) does not have
> any meaning between the processes (whatever you call them) which perform the relay on the SCCP level.
> 
> On the other hand the RC has very important and meaningful role on the SGP-ASP and IPSP-IPSP interfaces.
> 
> thanks and regards/ Stanislav Ivanovich
> 
> 
> 
> [email protected] wrote:
> Tolga,
> 
> >The question is -at least as far as I understand-, whether an
> >SUA-IPSP supports relaying.
> 
> Is the question:
> 
> 1) MAY an IPSP support relaying.
> 2) SHOULD an IPSP sup! port relaying.
> 3) MUST an IPSP support relaying.
> 
> Which one is the question.
> 
> I'd say my answer would be:
> 
> 1) Yes.
> 2) Maybe.
> 3) No.
> 
> John
> 
> _______________________________________________
> Sigtran mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/sigtran
> 
> 
> 
> __________________________________________________
> Do You Yahoo!?
> Tired of spam? Yahoo! Mail has the best spam protection around
> http://mail.yahoo.com
> 
> 
> _______________________________________________
> Sigtran mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/sigtran

-- 
Brian F. G. Bidulock
[email protected]
http://www.openss7.org/