RE: Some very fundamental SIGTRAN question

Hi Barry,
   
  First, thank you for yopur reply however seeing your answers I think that you didn't understand my view:
   
  I kindly ask you to look into my comments below and possibly reconsider your answers.
   
  many thanks and regards/ Stanislav Ivanovich
   
  
Barry Nagelberg <[email protected]> wrote:
    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.

  ------------------------------------------------------------------
  [Stanisalv Ivanovich] I do not question that SIGTRAN does address transport functions. However I have just said thatSIGTRAN concept you address these functions by SCTP and lower layers. xxUA protols (M3UA, SUA) do not solve transssion problems.
  ------------------------------------------------------------------
  
Your definition has several errors:
a) SGP/ASP/IPSP aren't protocols. They are network elements.
  ------------------------------------------------------------------
  [Stanisalv Ivanovich] You haven't understood my point. I do not question that ASP/IPSP/SGP'es are entities. Of course they are!
  What I said is that xxUA specifications specify only protocols between these entities without specifying internal SIgnalling Process structure.
  ------------------------------------------------------------------
  
b) Not "everything inside (ASP/IPSP/SGP) is implementor's choice". There are many "MUSTS" and "MUST NOTS" in the specs.
  ------------------------------------------------------------------
  [Stanisalv Ivanovich] This is true and I do not question that! What I said is that xxUA specifications do not manadate internal ASP/IPSP layering structure but only external behavior of these entities!
  -------------------------------------------------------------------

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.
   
  -------------------------------------------------------------------
  [Stanisalv Ivanovich] My point is -> ASP/IPSP is a user function. Of course it uses SCTP and it has to address interaction with it. However internal ASP/IPSP structure is irrelevant for the xxUA specificatons. This is all what I have said.
  -------------------------------------------------------------------
  
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.
  -------------------------------------------------------------------
  [Stanisalv Ivanovich] I think we cannot be both correct since these are contradictory statements. SS7 address is not application which you load into a process. My colleagues point is that AS is not application but SS7 address (or set of addressses) my point is that eventohugh AS has SS7 address it is not that (afterall AS has also RC). Anyway AS is an application (i.e. user function) that you load into a application process.
  -------------------------------------------------------------------
   
  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.

  -------------------------------------------------------------------
  [Stanisalv Ivanovich] I think we cannot be both correct since these are contradictory statements. Againmy point is -> if ASP/IPSP has endpoint it is not one. Endpoints are entities maintained in SCTP. ASP/IPSP is a process into which you load an application (AS) and which youi bind to an endpoint. Just because you bind it to a endpoint does not mean that ASP/IPSP is endpoint -> endpoitns are maintained in SCTP!
  -------------------------------------------------------------------
  
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.
  -------------------------------------------------------------------
  [Stanisalv Ivanovich] I do not quite understand you here.
  Are you telling me that M3UA or SUA protocls are desinged for adding extra trnasmsion resources???
  So by adding new Ethernet boards is reflected on xxUA protocol?
  -------------------------------------------------------------------
   
  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.


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

  


			
---------------------------------
Yahoo! Photos
 Got holiday prints? See all the ways to get quality prints in your hands ASAP.

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