Re: AS concepts and Relay in SUA and M3UA

Brian,
   
  Consequence of the AS/RC concept as used in M3UA is that IPSP/ASP equipped relay conceptually, practically and theoretically does not make sense and is not possible. If you claim that SUA IPSP does have possibility to relay why then you didn't change the AS/RC concept for SUA instead of making copy/paste from M3UA? (as I proposed in the option 1)
   
  You just made ad-hoc addition by saying "SUA IPSP does perform SCCP relay" but you didn't look wider on this by considering all the consequences of this addition on the AS/RC/Signaling Process concepts... Instead you used these concepts from M3UA.
   
  My opinion is that you do not see why M3UA does not support relay by ASP/IPSP processes. It is not because there is an "administrative" prohibition on this while the AS/RC concepts do support it. This is not the case!
  Instead not support of relay by ASP/IPSP is a consequence of the fundamental properties of the AS/RC/Signaling Process concepts (which you copy from M3UA).
   
  / Stanislav
   
  

"Brian F. G. Bidulock" <[email protected]> wrote:
  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/

_______________________________________________
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