Re: AS concepts and Relay in SUA and M3UA

Stanislav,

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

By listing the RFC dates do you think they are meaningful to this discussion?
M3UA and SUA text were finalized at about the same time.  M3UA slipped through
before security considerations became paramount, which stalled SUA becoming
an RFC for two years (yes, two years).

Similar concepts, but M3UA never adopted the full SUA model: relay being
one of them.

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

On the contrary, the concept was "tailored" for relay, for SUA.  RC makes
perfect sense.  SE vs. DE is a matter of the number of messages exchanged.
Perhaps you can present some example where this is not the case?

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

RC identifies a flow of traffic between SUA entitites.  The point of a NOTIFY
message containing it is to provide notification with regard to the traffic
flow identified by the RC.

>    Why  do you think that you must have AS/RC concept used in between two
>    SUA   relay   processes?  What  do  you  thin!  k  you  loose  if  you
>    introduce the  concpet of the SGP<->SGP interface where you do not use
>    AS/RC concept?

You are never required to assign RC to traffic flows between any SUA entities.
When no RC is assigned, and the association handles only one traffic flow,
it is optional in all messages.  Don't use it if you don't see a use for it.

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

You don't have to specify destination or originating addresses.  SUA permits
the description of an RK using GT ranges.  When registering with a IPSP relay
node, an IPSP can use the GT ranges that it expects to be served by the relay.
This is no different than SCCP.

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

SG-SG for M3UA defines messages missing from M3UA for peer-to-peer operation.
SUA does is missing no messages.  All SCCP protocol messages are represented
by equivalent SUA messages.  This is different than M3UA.  Also SG-SG for M3UA
avoids the use of RC.  This is because MTP provides no management messages for
its users (other than the feeble UPU) and has no user flow control.  SCCP OTOH
has managements messages for users and performs user flow control and congestion.
This is what permits SUA to manage within an RC. SG-SG concept for M3UA reduces
to pointcode-pointcode connnections, not requiring an RC.  SUA does not.

--brian

> _______________________________________________
> Sigtran mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/sigtran


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