Re: AS concepts and Relay in SUA and M3UA

Brian,
   
  It is irrelevant who made copy from which specification (either September 2002 M3UA from October 2004 SUA or vice versa). The only thing that matters is the fact that M3UA and SUA use the same concepts since the AS/RC related state machines, procedures etc... are the same.
   
  The fact is that the concept is not "tailored" for relay between the IPSP'es/ASP'es (especially considering the fact that SE model is mandatory). However regardless of the SE model the fact is that RC'es (application pointers) do not make any sense on the relay_process<->relay_process interface.
   
  For example what is the point of NOTIFY message on the IPSP<->relay_process interface indicating particular application with RC value??? What shoukd it represent?
   
  Why do you think that you must have AS/RC concept used in between two SUA relay processes? What do you think you loose if you introduce the concpet of the SGP<->SGP interface where you do not use AS/RC concept?
   
  Please explain also how can one build a network of relay processes with mandatory SE model where one has to specify both originating and destination SS7 addresses and only these combinations are allowed? This is extremely relay unfriendly!
   
  On the other hand SGP-SGP principle is fully compatible with AS/RC concepts which are of course used somewhere else (only on SGP-ASP and IPSP-IPSP interfaces) and at the same time very relay friendly since the concept uses the same principles as SCCP<->SCCP relay.
   
  / Stanislav
   
  

"Brian F. G. Bidulock" <[email protected]> wrote:
  Stanislav,

Stanislav Ivanovich wrote: (Mon, 19 Dec 2005 11:21:55)
> 
> 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)

In fact, much of the common text in M3UA came from SUA.

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

No. You were obviously not there while it is happening. I suggest you
review the mail archive over the last 5 years.

> 
> 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 rela! y by ASP/IPSP is a consequence of the
> fundamental properties of the AS/RC/Signaling Process concepts (which
> you copy from M3UA).

Again, much of these concepts, and particularly the RC concept, come from
SUA and was inserted into M3UA. See the long ladders on the mailing list
archives with regard to RC in DATA and SNMM.

You are now making pretty bold and brash statements that are not supported
by the facts.

SUA is not M3UA, and please don't try to force the concepts that M3UA adopted
poorly from SUA.

--brian

> 
> 
> 
> / Stanislav
> 
> 
> 
> "Brian F. G. Bidulock" 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 thi! nk 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


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


__________________________________________________
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