RE: Some very fundamental SIGTRAN question

Stanislav,

1) Your colleague is correct. xUA is a SIGnalling TRANsport (SIGTRAN) protocol, designed to transport legacy SS7
signalling over modern packet networks. Nothing more and nothing less.

Your definition has several errors:
a) SGP/ASP/IPSP aren't protocols. They are network elements.
b) Not "everything inside (ASP/IPSP/SGP) is implementor's choice". There are many "MUSTS" and "MUST NOTS" in the specs.

2) Your colleague is wrong. No particular layers are mandated by the xUA spec. There are some RECOMMENDED layers, such
as SCTP and Layer Manager, but the internal implementation is not MANDATED.

You are also wrong. The xUA protocols must be concerned with transmission of traffic. xUA, as an SCTP-user, must
supervise and control the operation of the SCTP layer.

3) You are both correct. At the SGP, the AS is essentially an addressing concept. At the ASP, the AS is essentially an
application concept.

4) You are both correct. At the SGP, the ASP is a transport concept (there is a 1:1 relationship between ASP and SCTP
association). At the ASP, the concept of ASP is an instantiation of an AS.

5) You are both correct. xUA handles transport. At the ASP, xUA handles granularity of Application Services - for
example, how many instantiations, or ASPs, are necessary to handle the traffic for an Application Server.

6) Your colleague is wrong. The interaction between Layer Manager and xUA is simply a recommendation. It's not a
mandatory part of the spec.

Barry Nagelberg
Adax, Inc.

-----Original Message-----
From: [email protected] [mailto:[email protected]]On Behalf Of Stanislav Ivanovich
Sent: Friday, January 13, 2006 11:24 AM
To: SIGTRAN
Subject: [Sigtran] Some very fundamental SIGTRAN question


Hello SIGTRAN community,

I have a very serious dispute with my colleague about very fundamental point of the SIGTRAN xxUA protocols. Although I
know the answer to the following question I am sending it to the SIGTRAN forum just to have some sort of argument and
official proof. Therefore I kindly ask you to give a judgment on whose standpoint is correct:

My colleague's view:

1) xxUA concepts are concepts of transmission related functions since M3UA replaces MTP and SUA replaces SCCP

2) Because of point 1 above xxUA specifications do mandate (!) a box/layer which is to contain all the xxUA concepts
(AS, RK, SGP, ASP, IPSP...) so that application entities and operations of these are completely non-related to xxUA
entities and operations

Example: ASP/IPSP is object in the xxUA laye! r/box and operation of it is done in that box -> always (!) and this is
not subject to vendor/implementor's choice. Therefore they do not represent application instances/clones.

3) Because of point 1 AS is not application but address (or set of SS7 addresses) therefore AS concept belongs to
transport stack not to application layers

4) Because of point 1 ASP/IPSP is transmission resource since it is visible as endpoint (set of IP addresses + port
number) therefore ASP/IPSP concept belongs to transport stack not to application layers


5) xxUA protocols are protocols designed to solve transmission related problems (like having multiple IP addresses used
for different directions, scale transmission capacity in case a SCTP host is limited in capacity etc...)

6) Management of all the xxUA entities is done in LM of the xxUA box/layer according to xxUA specifications and this! is
not application management and it is not in implementor's choice!



My view:

1) xxUA specifications do not specify (or mandate!) any box/layer especially not one which is to perform or address
transmission related functions. Instead xxUA specifications specify only two protocols (namely SGP-ASP and IPSP-IPSP)
which are originally designed/tailored to address application (not transmission!) redundancy. Everything inside
(ASP/IPSP/SGP) is implementor's choice and certainly not specified mandated in xxUA specifications. I.e. xxUA
specifications do not forbid an implementor to implement a layered structure within an ASP/IPSP process but with respect
to specifications it is the matter of implementation and not subject to specifications.

2)  In the SIGTRAN concept transmssion related problems are addressed by SCTP/IP/Ethernet... and underlying
function/mechanisms/tools.
Of course rapping of principles is possible thus one can see an Ethernet board as ASP/IPSP so addrsssing transmission
redundacy is visible on the xxUA protocls (i.e. new Ethernet boards imply new ASP_ID's) but this is not for what xxUA
protocls are originally designed for!
Originally addressing transmssion related problems should not reflect on the xxUA protocol.

3) AS is not an SS7 address but application (i.e. functionality)!
The fact that AS has SS7 address(es) in order to be externally visible certainly does not imply that AS itself is an SS7
address (or set of addresses).Therefore the concept of AS is certainly not transmission layer concept!

4) ASP/IPSP are application processes i.e. application clones.
In other words ASP/IPSP is container into which you load your application (or part of it) - to be illustratvie into
which you load program ! code which represents AS (or several AS'es).
The fact ASP/IPSP has an endpoint in order to be externally visible certainly does not imply that ASP/IPSP itself is an
endpoint. Therefore the concept of ASP/IPSP is certainly not transmission layer concept!

5) AS granularity, AS management and AS redundancy are all in application designer responsibility!
This is already the case in legacy systems. If applications want reliability then they support multiple instances
(clones, processes... whatever you call them) of their logic. This is not the task of transmission layers.

6) SUA and M3UA both say in section 1.2 "Terminology"

- "Application Server Process (ASP) - An Application Server Process serves as an active or backup process of an
Application Server"
- "IP Server Process (IPSP) - A process instance of an IP-based application. An IPSP is essentially the same as an ASP,
except that it uses SUA in a peer-to-p! eer fashion."

Therefore ASP/IPSP'es are clones of appliccations and not some entities in a magic box/layer thus not related to
applications -> if one does not want application clones he/she does not need several ASP/IPSP'es. Originally in the
spirit of xxUA specifications!

Again, raping of prinipcles is possible (e.g. an Ethernet board maybe can be an IPSP/ASP so having many boards implies
many ASP/IPSP'es and at the same time only one application insatnce) but I want to know what is it originally
designed/tailored for!

Whose opinion is correct?

Many thanks!

best regards/ Stanislav Ivanovich



Yahoo! Photos
Ring in the New Year with Photo Calendars. Add photos, events, holidays, whatever.