Re: ASP Capabilities value 0x2 of interworking field

Brian,
   
  I think you didn't understand my point, and as I see you again avoid to answer the essential question here -> what is the AS/RC cocnept used for in between two relay points which perform relay not on application logic but instead on SCCP logic (and even MTP logic since SPC relay is also possible in SUA)?
   
  [Brian]
  ASP TM messages are not used to manage relay. SNMM messages are.

  Why do you then neeed ASP Traffic Managemnt messages for different RC'es in between two relay points in SUA if you claim that they do not manage traffic but instead only SSNM.
   
  Are you saying that ASP TM messages are not used in between two relay points?
   
  What are they used for, then???
   
   
  I must copy my essential point which you constantly avoid:
   
    Even more, essential point is that the AS/RC is a redundancy concept. In IPSP-IPSP communication it is application logic (not xxUA layer logic!) which selects and/or loadshares between different ASP/IPSP'es. This logic also uses RC to point to a particular application the remote process serves.
   
  However if you use the AS/RC concept as a choice to build you relay network then you take control from the applications to point to RC. The applications then do not control RC'es thus do not have control over the essential/core meaning of the AS/RC concept. In that case IPSP'es points with SCCP GT relay functionality choose RC value! For this reason I say that RC is pointless there. What do you think it is good for??? Please, give us just one example.

   
   
   
  Regarding the SPC point below I am not saying that you cannot use ranges, I am aware of that and I amo not questioning that! I also didn't mention dynamic registration procedure so I do not understand what are you talking about.
   
  My point is -> in SE model one has to specify both orginating address(es) (or ranges) and destination address(es) (or ranges) and only these SS7 relations are possible.
   
  For example, A:SPC=2-100<->B:SPC2-200. 
   In direction A->B it is not allowed to send 2-900 -> 2-200 but only 2-100 -> 2-200. In the opposite direction it is not allowed to send 2-200 -> 2-600 but only 2-200 -> 2-100. 
   
  In traditional SS7 networks one specify Route Set by only considering remote destination. When you route messages you also consider only state of the remote destinations. But in xxUA networks you must also consider you own state in a specific AS!
  Thus is extremely relay-unfriendly! 
   
  /stanislav
   
  

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

Stanislav Ivanovich wrote: (Tue, 20 Dec 2005 07:44:05)
> 
> 
> However the essential point is that the AS/RC concepts which is
> symmetrical one (at least in SE model) is not suitable to perform the
> relay.
> 
> Traditi! onal SS7 networks (MTP and SCCP) are asymmetrical in sense
> that they do not care where the message originated but where it has to
> be delivered.

Yah. SS7 links are uni-directional.

> 
> In xxUA networks AS/RC concept in mandatory SE model both originating
> and destination addresses have to be specified and only
> these combinations are allowed. This is extremely unfriendly for
> relay!

No they don't. Any routing key is possible. Dynamic registration does not
support all possible routing keys. Provisioned routing keys can take any
form. Also note that SUA registration supports multiple and ranges of
addresses in a dynamically registered routing key. Not even M3UA restricts
its routing keys to a single originating or destination point code. You
can have one destination HLR point code and 400 MSC originating point codes
if you'd like. Or visa versa. Or 400 of each.

> 
> Thus in traditional networks TFP or SSP messages manage traffic in
> only one direction. Even more granularity of traffic is uniquely and
> defined by the specifications.
> 
> However in the AS/RC concept in the mandatory SE model one ASP TM
> message manages traffic in both directions!

ASP TM messages are not used to manage relay. SNMM messages are.

--brian


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