Subject: [Sigtran] Upper boundary of Adaptation Layers

From: Ilie Glib <[email-masked]>
Date: Mon, 9 Jan 2006 16:07:00 +0100

Hello Folks,

In my current understanding of the SIGTRAN:

- SUA and M3UA RFCs define the primitives of the adaptation layers
towards their users in Section "1.6.1.  Definition of the upper
boundary".
  SUA and M3UA RFCs simply refer to ITU-T and ANSI standards for the
complete definition of the primitives towards the users, therefore
SIGTRAN supports existing
  SCCP/MTP users without them being aware of the fact that SIGTRAN is
used for the transport of messages.
  SIGTRAN concepts and the corresponding entities/objects like AS, RK,
RC, IPSP, ASP, and SGP are not part of the currently standardized
upper boundary of M3UA (SUA).
  Thus today's SIGTRAN users do not know anything about those concepts.

Can you please confirm this view or tell me if I'm mislead by my
interpretation ?

Is their any attempt in SIGTRAN WG to define an extended upper
boundary for xxUA that gives the option of managing entities like AS,
RK, RC, IPSP, ASP, and SGP to xxUA users and what are the enhanced
services expected from adaptation layers ?

Thank you in advance

--
Ilie

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 9 Jan 2006 08:19:33 -0700

Ilie,

This can be true for the strict backhaul scenario.  It is not
necessarily true for the multiple SG as STP scenario, nor IPSP,
nor for SCCP Relay.  SUA already defines an enhanced SUA User
that can use IP addresses or Host names in called or calling
party addresses, and is thus aware of SUA.

--brian

Ilie Glib wrote:                          (Mon, 09 Jan 2006 16:07:00)

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

---

From: "Barry Nagelberg" <[email-masked]>
Date: Mon, 9 Jan 2006 10:22:41 -0500

Ilie,

Your summary of the current architecture is mostly correct.

The most important part of your summary is that "SIGTRAN supports existing SCCP/MTP users without them being aware of
the fact that SIGTRAN is used for the transport of messages."

This is the entire reason for the existance of SIGTRAN. SIGTRAN is a bridging mechanism designed to allow legacy
SCCP/MTP3 users to take advantage of cheap IP transport without having to modify their legacy protocol stacks.

Any attempt to make SCCP/MTP3 users aware of SIGTRAN would make SIGTRAN almost worthless.

Barry Nagelberg
Adax, Inc.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On
Behalf Of Ilie Glib
Sent: Monday, January 09, 2006 10:07 AM
To: SIGTRAN
Subject: [Sigtran] Upper boundary of Adaptation Layers

Hello Folks,

Thank you in advance

--
Ilie

---

From: Stanislav Ivanovich <[email-masked]>
Date: Mon, 9 Jan 2006 07:27:17 -0800 (PST)

Hello,
   
  Since I find Ilie's questions ambiguous I will extend his questions by asking:
   
  1) Is there a layer which owns state of SIGTRAN objects (like ASP/IPSP process states) indepdnednetly on MTP-user or SCCP-user applications by making these applications idendepndtz on the ASP/IPSP state?
   
  2) If such layer exisits and if M3UA and SUA are not just and only protocls but also boxes/layers which have a place in the signalling system which is to isolate user functions on ASP/IPSP state shold such layer own the control on ASP/IPSP states? 
   
  For example SCCP subsystem does not want to handle traffic. In legacy systems SCCP-user applications own the control on the SCCP-subsystem state change thus they control appaearance on N-STATE_request primitive on SCCP API.
  However if one thinks that xxUA is not just a set of protocls (ASP-SGP and IPSP-IPSP) but also a box which contains a functionality which is to isolate user functions on SIGTRAN concepts (like ASP/IPSP) does that imply that such box should own commands for AS state change, i.e. it is SUA box but not SCCP user function which owns control on AS state change, see section 1.6.3. in xxUA RFCs, e.g. Definition of the Boundary between SUA and Layer Management:
   
    M-ASP_ACTIVE request
  Direction: LM -> SUA
  Purpose: LM requests ASP to send an ASP Active message to its peer.
  M-ASP_INACTIVE request
  Direction: LM -> SUA
  Purpose: LM requests ASP to send an ASP Inactive message to its
  peer.
   
  Is this an RFC fault?

  regards/ stanislav

Ilie Glib <[email-masked]> wrote:
  Hello Folks,

Thank you in advance

--
Ilie

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 9 Jan 2006 08:34:07 -0700

Stanislav,

Stanislav Ivanovich wrote:                                       (Mon, 09 Jan 2006 07:27:17)

---X-snip-X---
>    Purpose: LM requests ASP to send an ASP Inactive message to its

No.  SCCP also requires local management.  N-STATE request is not an
SCCP/SCCP-User primitive.  It is an SCCP/SCCP Management primitive.

--brian

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

---

From: Ilie Glib <[email-masked]>
Date: Mon, 9 Jan 2006 17:21:57 +0100

Hello Brian,

I can not agree with you that SUA enables applications to use IP
addresses. Indeed Source and Destination addresses can contain IP
addresses, but this is an implicit impact on the xxUA users rather
than an explicit impact. Currently section "1.6.1.  Definition of the
upper boundary" does not extend SS7 primitives. If this extension is
wanted it shall be in the standard documents (RFCs).

Apropos Source and Destination addresses cannot contain hostnames.
IMHO hostnames are much more usefull than IP addresses.

If it is wanted that xxUA become a true standard the content of the
upper boundary shall be defined down to the last bit.

what do you mean by
> It is not necessarily true for the multiple SG as STP scenario,
?

See below for one more question.

Thank you in advance

Ilie
On 1/9/06, Brian F. G. Bidulock <[email-masked]> wrote:
> Ilie,
>
> This can be true for the strict backhaul scenario.

[Ilie] Do you mean SGP to ASP interface (assuming ASP does not have
relay capability)?

> It is not necessarily true for the multiple SG as STP scenario, nor IPSP,

--
Ilie

---

From: Stanislav Ivanovich <[email-masked]>
Date: Mon, 9 Jan 2006 08:36:40 -0800 (PST)

Brian, Tolga,
   
  Brian, are you saying that SCCP-user function is not owner of the management of its resources, i.e. user function does not own control if/how/when it can withdraw from the traffic?
   
  For example an SCCP-user application in ISDN networks installed in an SCCP-subsystem has to do certain checks when and how and if it can withdraw from the traffic, and another SCCP-user application in WCDMA networks installed in an SCCP-subsystem performs other checks different from the first ones. So these cheks cannot be part of SCCP and for this reason ITU-T puts it in SCCP-user applications by introducing N-STATE_request primitive. Are you saying that SUA layer (which should replace SCCP) should own command which is to remove an SCCP-user from traffic (i.e. generate ASP_INACTIVE message)? If so how do you make your SUA box/layer application independet since each application has its own checks and actions performed when withdrawing from the traffic?

  Tolga, I read your comments on the question posted on 4th of November by Prasad Shashank at http://www1.ietf.org/mail-archive/web/sigtran/current/msg05292.html and answers from you at http://www1.ietf.org/mail-archive/web/sigtran/current/msg05295.html and http://www1.ietf.org/mail-archive/web/sigtran/current/msg05297.html.
   
  I completely agree with you but in order to make it clear I just want to make it more explicit:
   
  1) Is the user application the entitiy which sends traffic from a local ASP/IPSP or it is in xxUA "box/layer" responsiblity which is to be indepednet on applications and which decides which local (!) IPSP/ASP to use.
  In other words is it that you have one application supported by xxUA box/layer and within this xxUA box/layer you have 2 or more local IPSP/ASP processes and it is then in this xxUA box/layer responisbility to chose right ASP/IPSP?
   
  In my view you install an application in a process and when this applicaton clone generates traffic it is unambiguous which local ASP/IPSP to use since the local process is application resource (clone). Please confirm or deny my understanding.

  2) In my view xxUA is not a box/layer but only a set of protocls (ASP-SGP and IPSP-IPSP). ASP/IPSP is a user application entity own and controlled by the application. However possibly being wrong I need answer on this -> is it true that xxUA specifications manadate (!) that there must (!) be a layer/box which is to own control on which local ASP/IPSP to use when sending traffic.
   
  3) I kindly ask you to comment SUA example above and Brian's point about the fact that applications do not own control on their wiothdrawal from or statrting of traffic.
   
  many thanks and regards/ stanislav

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

---X-snip-X---

--brian

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

---

From: Ilie Glib <[email-masked]>
Date: Mon, 9 Jan 2006 17:38:15 +0100

Hello Barry,

thank you for your answer. I agree 100% with your statements.

My intention was to stress that current SIGTRAN RFCs do not extend SS7
primitives, and as a consequence do not put any requirements on the
user applications.

In case an extension of SS7 primitives is wanted this extension shall
be documented in IETF standards. For instance the
draft-asveren-sigtran-m3uaipsp-00.txt may be the right place to
document such extensions of services that M3UA Layer provides to its
users in IPSP to IPSP scenario.

Regards

Ilie

--
Ilie

---

From: Ilie Glib <[email-masked]>
Date: Mon, 9 Jan 2006 17:44:59 +0100

Hello Stanislav,

On 1/9/06, Stanislav Ivanovich <[email-masked]> wrote:
> 1) Is there a layer which owns state of SIGTRAN objects (like ASP/IPSP
> process states) indepdnednetly on MTP-user or SCCP-user applications by
> making these applications idendepndtz on the ASP/IPSP state?
>

[Ilie] I have not questioned that, in my view this is a fact written
in stone (RFCs).
check e.g. the SIGTRAN applicability draft:
http://tools.ietf.org/html/draft-ietf-sigtran-signalling-over-sctp-applic-09.txt

> 2) If such layer exisits and if M3UA and SUA are not just and only protocls
> but also boxes/layers which have a place in the signalling system which is
> to isolate user functions on ASP/IPSP state shold such layer own the control
> on ASP/IPSP states?
>
> For example SCCP subsystem does not want to handle traffic. In legacy
> systems SCCP-user applications own the control on the SCCP-subsystem state
> change thus they control appaearance on N-STATE_request primitive on SCCP
> API.
> However if one thinks that xxUA is not just a set of protocls (ASP-SGP and
> IPSP-IPSP) but also a box which contains a functionality which is to isolate
> user functions on SIGTRAN concepts (like ASP/IPSP) does that imply that such
> box should own commands for AS state change, i.e. it is SUA box but not SCCP
> user function which owns control on AS state change, see section 1.6.3. in
> xxUA RFCs, e.g. Definition of the Boundary between SUA and Layer Management:
>
> M-ASP_ACTIVE request
> Direction: LM -> SUA
> Is their any attempt in SIGTRAN WG to define! an extended upper
> ________________________________
> Yahoo! Photos

--
Ilie

---

From: Stanislav Ivanovich <[email-masked]>
Date: Mon, 9 Jan 2006 08:48:03 -0800 (PST)

Barry,
   
  Which entitiy controls the start and removal of application from traffic? Is it MTP/SCCP or User Parts/SCCP-users?
   
  When for example SCCP-user requests N-STATE_request which is to be translated into ASP-INACTIVE who controls the AS state? Is it SUA "layer" or SCCP-user application?
   
  regards/ Stanislav

Barry Nagelberg <[email-masked]> wrote:
  Ilie,

Barry Nagelberg
Adax, Inc.

-----Original Message-----

Hello Folks,

Thank you in advance

--
Ilie

		
---------------------------------
 Yahoo! DSL Something to write home about. Just $16.99/mo. or less

---

From: Stanislav Ivanovich <[email-masked]>
Date: Mon, 9 Jan 2006 08:53:55 -0800 (PST)

Hello Ilie,
   
  Please first let us hear Tolga and Brian on my last mail about this issue.
   
  If you now claim that you didn't question that user function should own control for activation/deactivation of AS please tell us what was your point in this question that you sent me on my private mail and which I simply copy/pasted and forwarded:
   
    -------------------------------------------------------------------------------------------------------------------
  [Ilie Glib] After all what is the point for ASP Activation commands in xxUA layers (see section 1.6.3. in xxUA RFCs, e.g. Definition of the Boundary between SUA and Layer Management)
  M-ASP_ACTIVE request
  Direction: LM -> SUA
  Purpose: LM requests ASP to send an ASP Active message to its peer.
  M-ASP_INACTIVE request
  Direction: LM -> SUA
  Purpose: LM requests ASP to send an ASP Inactive message to its
  peer.
  Is this an RFC fault?
  -------------------------------------------------------------------------------------------------------------------

  /stanislav

> Ilie Glib wrote:

--
Ilie

---

From: "Barry Nagelberg" <[email-masked]>
Date: Mon, 9 Jan 2006 12:02:53 -0500

Stanislav,

Both entities. You are describing an API msg (N-STATE req) and the resulting SUA action.

The critical part is that the SCCP-user doesn't know (and shouldn't know) how the API msg is handled "under the hood".

Barry Nagelberg
Adax, Inc.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of Stanislav Ivanovich
Sent: Monday, January 09, 2006 11:48 AM
To: SIGTRAN
Subject: RE: [Sigtran] Upper boundary of Adaptation Layers

Barry,

When for example SCCP-user requests N-STATE_request which is to be translated into ASP-INACTIVE who controls the AS
state? Is it SUA "layer" or SCCP-user application?

regards/ Stanislav

Barry Nagelberg
Adax, Inc.

-----Original Message-----

Hello Folks,

used for the trans! port of messages.

Thank you in advance

--
Ilie

---

From: Ilie Glib <[email-masked]>
Date: Mon, 9 Jan 2006 18:15:27 +0100

Stanislav,

I did not want to post this question on the SIGTRAN list. I do not
have any doubts that SUA, or M3UA layers can activate and deactivate
ASPs on request from SUA/M3UA Layer Management

On 1/9/06, Stanislav Ivanovich <[email-masked]> wrote:
> If you now claim that you didn't question that user function should own
> control for activation/deactivation of AS please tell us what was your point
> in this question that you sent me on my private mail and which I simply
> copy/pasted and forwarded:
>
> [Ilie Glib] After all what is the point for ASP Activation commands in xxUA
> layers (see section 1.6.3. in xxUA RFCs, e.g. Definition of the Boundary
> between SUA and Layer Management)
> M-ASP_ACTIVE request
> Direction: LM -> SUA
> > user functions on SIGT! RAN concepts (like ASP/IPSP) does that imply that
> such
> > ! Thank you in advance

--
Ilie

---

From: Stanislav Ivanovich <[email-masked]>
Date: Mon, 9 Jan 2006 09:32:04 -0800 (PST)

Barry,
   
  I agree that user applications are to be isolated from the underlaying layers (i.e. SCTP, IP etc...). However I completely disagree that as you say both (!) entities (i.e. MTP/SCCP and their users) control the acitvation/deactivation of applications in the traffic! Instead in the legacy systems (and even in pure logic) it is in application responsiblity to know if/how/when to start/stop handling traffic.
   
  In my view:
   
  1) The concept "AS and Signalling Process" is a concept of redundancy of application resources not transmisson ones.
  Unlike MTP and SCCP which are desinged to solve transmisson related problems M3UA and SUA are not desinged for that! They are only external protocls (not some magic boxes/layers) which control only application redundacy. MTP and SCCP also have redundancy but there is another type of redundacy namely transmission resource redundancy
   
  2) ASP/IPSP is not transmission resource (like SGP) but instead a processing resource -> you load a particular application in one or several ASP/IPSP'es. So each ASP/IPSP is a clone of application. i.e. each application know in advance which local IP address + port number to use since it os bound to that endpoint during installation.
   
  3) Even in legacy systems it is in applications which control redundancy of applications (ie. algortihm to use when loadsahring between remote application clones is owned by applications not MTP or SCCP).

  /Stanislav Ivanovich

Barry Nagelberg
Adax, Inc.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of Stanislav Ivanovich
Sent: Monday, January 09, 2006 11:48 AM
To: SIGTRAN
Subject: RE: [Sigtran] Upper boundary of Adaptation Layers

Barry,

regards/ Stanislav

Barry Nagelberg wrote:
Ilie,

Barry Nagelberg
Adax, Inc.

-----Original Message-----

Hello Folks,

Thank you in advance

--
Ilie

		
---------------------------------
Yahoo! Photos – Showcase holiday pictures in hardcover
 Photo Books. You design it and we’ll bind it!

---

From: Ilie Glib <[email-masked]>
Date: Mon, 9 Jan 2006 17:49:53 +0100

Stanislav

I should correct myself. I mean that there are no doubts that there
are xxUA Layers, and applications residing on top of them depend on
them as SCCP-Users, depend on SCCP services.

Regards

Ilie

--
Ilie

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 9 Jan 2006 11:58:41 -0700

Ilie,

Ilie Glib wrote:                                                      (Mon, 09 Jan 2006 17:21:57)
> wanted it shall be in the standard documents (RFCs).

Don't be absurd.  1.6.1 says that the standard SCCP/SCCP-User primitives
are supported.  It does not say that nothing else is supported or
supportable.  It does not say that no other primitives shall be used.
It is just the list of intentionally supported primitives.

There are, I hope you realize, more national protocol variants than just
ITU or ANSI.

> upper boundary shall be defined down to the last bit.

Actually, the upper boundary at the ASP is a local matter.  There are no
requirements placed on the boundary.  It certainly does not have to
specified to the bit.

> > It is not necessarily true for the multiple SG as STP scenario,

I mean it is not necessarily true for the multiples SG as STP scenario.

> [Ilie] Do you mean SGP to ASP interface (assuming ASP does not have

No. SG to ASP interface where the Provider protocol layer (e.g., SCCP)
is located at the SG.  That is, the ASP's point-code is hosted at the
SG.

--brian

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 9 Jan 2006 12:17:12 -0700

Stanislav,

Stanislav Ivanovich wrote:                                       (Mon, 09 Jan 2006 08:36:40)
> 
>    Brian, Tolga,
> 
> 
> 
>    Brian,  are  you  saying that  SCCP-user  function is not owner of the
>    management  of  its resources, i.e. user function does not own control
>    if/how/when it can withdraw from the traffic?

See Figure 10/Q.1400.

--brian

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 9 Jan 2006 12:23:29 -0700

Stanislav,

Stanislav Ivanovich wrote:                                       (Mon, 09 Jan 2006 09:32:04)
> 
>    Barry,
> 
> 
> 
>    I agree that user applications are to be isolated from the underlaying
>    layers  (i.e.  SCTP, IP etc...). However I completely disagree that as
>    you  say both (!) entities (i.e. MTP/SCCP and their users) control the
>    acitvation/deactivation of applications in the traffic! Instead in the
>    legacy  systems  (and  even  in  pure  logic)  it  is  in  application
>    responsiblity to know if/how/when to start/stop handling traffic.
> 

See Figure 10/Q.1400 and then reconsider Barry's answer.

--brian

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

---

From: Stanislav Ivanovich <[email-masked]>
Date: Mon, 9 Jan 2006 11:55:03 -0800 (PST)

Thank You very much Brian, now I 100% agree with You!
   
  I think that you pointed the very essential (!) property of all xxUA specifications:
   
  ------------------------------------------------------------------------
  [Brian F. G. Bidulock]
Actually, the upper boundary at the ASP is a local matter. There are no
requirements placed on the boundary. It certainly does not have to
specified to the bit.
  ------------------------------------------------------------------------
   
  This is all what I have been saying and the essential of the dispute between me and Ilie Glib!
   
  My point was -> xxUA specifications do not mandate xxUA box/layer but instead leave up to implementation to chose how should the protocol be implemented. This does not mean that xxUA specifications forbid layered apporach (i.e. a box with upper boundary) but certainly do not manadate any! xxUA specification only specify external protocl but not any boxes/layers - this is manatory everything else is implementation choice!
   
  Thank You once again for Your cooperation!
   
  with very best reagrds/ Stanislav Ivanovich

"Brian F. G. Bidulock" <[email-masked]> wrote:
  Ilie,

> On 1/9/06, Brian F. G. Bidulock wrote:
> > Ilie,
> >

--brian

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

---

From: Stanislav Ivanovich <[email-masked]>
Date: Mon, 9 Jan 2006 13:34:17 -0800 (PST)

Brian,
   
  I can only confirm what I told Barry!
   
  ITU-T specifications are very clear and I have read the ITU-T Q.1400 specification and there is nothing contradictory there to my point that each SCCP-user function controls its own traffic state -> there is no other way but to leave the user-function to control this since it is application dependent (i.e. each SCCP-user application can have its own management).
   
  ITU-T Q.1400 ch. 7 "Management Functionality":
  
"Figure 10 shows that each entity in the protocol architecture has a Level Management Entity (LME) associated with it.
The LME may be more or less explicitly defined within the level. For example, in the SCCP, there are a number of
management functions (e.g. SSN management) which constitute the LME for the SCCP."
   
  I do not have any problems with this since indeed SCCP management (like any other piece of functionality) has to be configured. For example SCCP Management must be configured in order to know to which remote SCCP subsystems the SCCP Management has to send SSP when it performs SSP broadcast. Another example is that "SCCP Signalling point congested" procedure as part of SCCP Management has also to be configured by the SCCP LM.
   
  However ITU-T Q.1400 certainly does not tell you that SCCP owns the functionality which is to remove the local SCCP-user form the service (or put it into service). Specifications are clear and in accordance to pure logic -> only SCCP-user entity can control logic which is to check if/how/when it can withdraw from traffic or start handling traffic!
   
  See ITU-T Q.711 "Functional description of the signalling connection control part", sec. 6.3 "SCCP management", sub-sec. 6.3.2.3.2 "STATE",
  
"The "N-STATE request" primitive (Table 16) is used to inform the SCCP management about the status of the originating user. The "N-STATE indication" primitive is used to inform an SCCP user accordingly."
   
  Note that N-xxx means Network Layer primitive (according to OSI model) i.e. primitive from Network Layer to its user function!
   
  / stanislav

--brian

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 9 Jan 2006 15:22:41 -0700

Stanislav,

Perhaps you can point to where in Q.711 the SCCP user is attached to
or removed from an NSAP. ;)

This is a local management function.  Attaching to an NSAP is equivalent
to activating an AS, detaching, deactivating.  The address of the NSAP
itself is the RK.  Attaching and detaching a user at an NSAP is ASP Active
and ASP Inactive for the AS with the RK associated with the NSAP.

Understand?

--brian

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

---

From: Stanislav Ivanovich <[email-masked]>
Date: Mon, 9 Jan 2006 14:53:55 -0800 (PST)

Brian,
   
  You actually confirm my point -> attaching/deattaching, activation/deactivation... all of these activities are performed by non-SCCP functionality, i.e. it is not SCCP that attaches or activates an SCCP subsystem but user that attaches to the service or activates itself for the traffic exchanged with the service! Users attach to service not vice versa!
   
  You cannot also find in SCCP specifications that SCCP service attaches local users...

  Anyway, our dispute was that according to you N-STATE_request is not a primitive between SCCP and SCCP-user but between SCCP and SCCP-LM. As I showed this is not the case but instead as I pointed it is the primitive between SCCP and SCCP-user application!
   
  By the way, are you saying that N-STATE_request from an SCCP-user application should not generate ASP_INACTIVE on the external interface??? Do you remember our last week's discussion about this -> your point was that ASP is not allowed to send DUNA reflecting N-STATE_request but instead that is to be done by ASP_ACTIVE/INACTIVE? Look at http://www1.ietf.org/mail-archive/web/sigtran/current/msg05667.html

  best regards/ Stanislav Ivanovich

Understand?

--brian

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 9 Jan 2006 16:47:25 -0700

Stanislav,

No, the N-STATE Request does not necessarily originate at the Subsystem
(SCCP-User).  This is particularly true of TCAP, which separates these
management functions from the user functions.

Also not that N-STATE Request does not have sufficient information for
SCCP to do its job.  It must be determined whether an out of service
subsystem is a transient or permanent condition.  Furthermore, a
separate interface than that used to transfer data on a connection
(CONS) must be used to signal that a connection-oriented subsystem is
out of service, and again, it must be signalled whether it is a
transient or permanent condition.  Although TCAP can bind to multiple
NSAPs for the same subsystem, and each can receive N-STATE indication,
N-STATE request must is sent by a separate management function.

Nevertheless, your SCCP-User at the ASP can issue N-STATE Request to SUA
at the ASP to its heart's content.  SUA will translate this to ASP
Active/Inactive.  At the SG, the SG is responsible for determining the
availability of the subsystem (from AS availablility) and issuing local
N-STATE Requests as necessary.  At the SG, N-STATE Request does not come
from the user, it is generated by the NIF to present a single management
view of the subsystem to the SS7 network and other SCCP users.

--brian

Stanislav Ivanovich wrote:                      (Mon, 09 Jan 2006 14:53:55)
> 
>    Brian,
> 
> 
> 
>    You    actually    confirm    my   point   ->   attaching/deattaching,
>    activation/deactivation...  all  of  these activities are performed by
>    non-SCCP functionality, i.e. it is not SCCP that attaches or activates
>    an  SCCP  subsystem but user that attaches to the service or activates
>    itself  for  the  traffic  exchanged with the service! Users attach to
>    service not vice versa!
> 
> 
> 
>    Anyway, our dispute was that according to you N-STATE_request is not a
>    primitive  between SCCP and SCCP-user but between SCCP and SCCP-LM. As
>    I  showed  this  is  not  the  case but instead as I pointed it is the
>    primitive between SCCP and SCCP-user application!
> 
> 
> 
>    By  the  way,  are  you  saying that N-STATE_request from an SCCP-user
>    application   should   not   generate   ASP_INACTIVE on  the  external
>    interface??? Do  you remember our last week's discussion about this ->
>    your    point   was   that   ASP is   not   allowed   to   send   DUNA
>    reflecting N-STATE_request   but   instead  that  is  to  be  done  by
>    ASP_ACTIVE/INACTIVE? Look at
>    [1]http://www1.ietf.org/mail-archive/web/sigtran/current/msg05667.html
> 
> 
> 
> 
> 

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

---

From: Ilie Glib <[email-masked]>
Date: Tue, 10 Jan 2006 12:00:52 +0100

Hello Brian,

On 1/9/06, Brian F. G. Bidulock <[email-masked]> wrote:
> are supported.

[Ilie] Therefore an implementation of SUA Layer in may not have any
other primitives than SCCP/SCCP-User primitives. Is this correct?

>It does not say that nothing else is supported or

[Ilie] This was just a poetical exaggeration.

I interpret your statement above, that it is an implementation matter
whether other than  SCCP/SCCP-User primitives are introduced or not.
By the way are there any standardized SCCP/SUA (M3UA) user
applications/protocols that use other primitives that those mentioned
in 1.6.1?
I have not heard of any.
My opinion is that it is not possible to standardize an xxUA-User
/Application (which uses an extended  service as compared to
SCCP/MTP3) without having the SUA/M3UA upper boundary well defined, at
the level the ITU-T defines SCCP-User primitives, or alternatively
this new standard of the application shall refine its lower boundary.
Do you agree?

With the current definition of the xxUA upper boundary all User
Applications will rely on the definitions in the SS7 (section 1.6.1 in
the RFCs).
If some vendors will implement extensions to the primitives in 1.6.1,
those will be most probably due to internal system architecture.

Regards

--
Ilie

---

From: Stanislav Ivanovich <[email-masked]>
Date: Tue, 10 Jan 2006 04:11:32 -0800 (PST)

Ilie,
   
  Please read Brian's statement that I 100% agree with:

  What Brian claims here is what I believe is the very essential (!) truth for all xxUA specifications. It is very important here to note that this is not so because of some agreement with the SIGTRAN community but rather a consequence of the very fundamental SIGTRAN concepts -> ASP/IPSP is an application resource not transmission one.
   
  For example no one would ever accept that M3UA specifies internal (!) boundaries of MTP3-user applications which use M3UA protocol. The same is the case for any other xxUA.
   
  The point is -> IPSP/ASP'es are application processes whose internal structure is irrelevant for xxUA specifications. What these specifications mandate is only external protocol i.e. behavior of the application processes on the external interface. Internal structure of application processes i.e. should there be any particular layer/box is irrelevant for the xxUA specifications.
   
  Therefore it is not true that xxUA specifications do mandate any particular layer/box which must have defined upper boundary. It is not true that xxUA specifications say "there MUST be a layer within an application process". However xxUA specifications do not forbid layered approach -> you can implement since it is not visible externally -> externally is only important that ASP/IPSP (application clones) behave according to xxUA protocols.
   
  Nevertheless applications are APS/IPSP'es which control their own resources -> activation/deactivation... therfore applications (!) control behavior on the external xxUA protocol rather then some magic xxUA box/layer -> there is no such box in xxUA specifications but you can implement them as implementation choice! Specifications only specify external protocols not internal ones!
   
  / stanislav

Regards

Ilie

--
Ilie

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 10 Jan 2006 07:08:42 -0700

Ilie,

Ilie Glib wrote:                                                      (Tue, 10 Jan 2006 12:00:52)

> those will be most probably due to internal system architecture.

I don't know what you mean by "rely on."  All SS7 stacks are vendor
specific.  The only thing an application can rely upon is the interface
provided by the vendor.

The closest to an application interface standard is the Network Provider
Interface (NPI) from UNIX International (OSI Work Group) [now OpenGroup],
which provides X.210 support for X.213 and can, therefore, be applied to
SCCP.

The NPI uses N_BIND_REQ/N_BIND_ACK instead of N-STATE Request/Indication,
and N_UDERR_IND/N_DISCON_IND instead of N-NOTICE and N-PCSTATE.  Q.713
even provides mapping of SCCP causes into X.213 causes so the OSI header
files for NPI are usable.

The other UAs have no API standard whatsoever.

--brian

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

---

From: "Tolga Asveren" <[email-masked]>
Date: Tue, 10 Jan 2006 11:40:17 -0500

Stanislav,

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of
Stanislav Ivanovich
Sent: Monday, January 09, 2006 11:37 AM
To: SIGTRAN
Subject: Re: [Sigtran] Upper boundary of Adaptation Layers

Brian, Tolga,

Brian, are you saying that SCCP-user function is not owner of the management
of its resources, i.e. user function does not own control if/how/when it can
withdraw from the traffic?

For example an SCCP-user application in ISDN networks installed in an
SCCP-subsystem has to do certain checks when and how and if it can withdraw
from the traffic, and another SCCP-user application in WCDMA networks
installed in an SCCP-subsystem performs other checks different from the
first ones. So these cheks cannot be part of SCCP and for this reason ITU-T
puts it in SCCP-user applications by introducing N-STATE_request primitive.
Are you saying that SUA layer (which should replace SCCP) should own command
which is to remove an SCCP-user from traffic (i.e. generate ASP_INACTIVE
message)? If so how do you make your SUA box/layer application independet
since each application has its own chec! ks and actions performed when
withdrawing from the traffic?

Tolga, I read your comments on the question posted on 4th of November by
Prasad Shashank at
http://www1.ietf.org/mail-archive/web/sigtran/current/msg05292.html and
answers from you at
http://www1.ietf.org/mail-archive/web/sigtran/current/msg05295.html and
http://www1.ietf.org/mail-archive/web/sigtran/current/msg05297.html.

I completely agree with you but in order to make it clear I just want to
make it more explicit:

1) Is the user application the entitiy which sends tr! affic from a local
ASP/IPSP or it is in xxUA "box/layer" responsiblity which is to be
indepednet on applications and which decides which local (!) IPSP/ASP to
use.
In other words is it that you have one application supported by xxUA
box/layer and within this xxUA box/layer you have 2 or more local IPSP/ASP
processes and it is then in this xxUA box/layer responisbility to chose
right ASP/IPSP?

In my view you install an application in a process and when this applicaton
clone generates traffic it is unambiguous which local ASP/IPSP to use since
the local process is application resource (clone). Please confirm or deny my
understanding.
[TOLGA]Yes, I agree with your interpretation. It probably is not wrong from
SIGTRAN point of view to build a system with the other approach but I don't
know why one would like to do that.

2) In my view xxUA is not a box/layer but only a set of protocls (ASP-SGP
and IPSP-IPSP). ASP/IPSP is a user application entity own and controlled by
the application. However possibly being wrong I need answer on this -> is
it! true that xxUA specifications manadate (!) that there must (!) be a
layer/box which is to own control on which local ASP/IPSP to use when
sending traffic.

3) I kindly ask you to comment SUA example above and Brian's point about the
fact that applications do not own control on their wiothdrawal from or
statrting of traffic.
[TOLGA]For that issue, I think similar to the clarifications stated in the
list by Brian.

---X-snip-X---
> Purpose: LM requests ASP ! to send an ASP Inactive message to its
> peer.
>
> Is this an RFC fault?

--brian

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

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

---

From: Ilie Glib <[email-masked]>
Date: Tue, 10 Jan 2006 15:49:31 +0100

Brian,

I am happy about your statements

> I don't know what you mean by "rely on."

[Ilie] My understanding is that SCCP-users are standardized as
application layers using services provided by SCCP in its primitives
to the SCCP-Users. Thus applications rely (read use) SCCP upper
boundary as of Q.711.

>All SS7 stacks are vendor
[Ilie] I believe it is not very difficult for SCCP User applications
to change from SCCP layer of one vendor to another (or from SCCP use
to SUA), they anyway follow the primitives of Q.711.

--
Ilie

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 10 Jan 2006 12:46:25 -0700

Ilie,

Ilie Glib wrote:                                                      (Tue, 10 Jan 2006 15:49:31)
> to SUA), they anyway follow the primitives of Q.711.

It was our objective when formulating the specifications to permit an
implementation that follows the primitives of Q.711 and the interface
described in the SDLs of Q.714 (or similar specifications, such as ANSI
T1.112) to be able to use SUA in a manner transparent to that of SCCP.
Thus, as Barry noted, permitting an implementation of MTP2, MTP3 or SCCP
to present the same interface to the MTP, MTP User, and SCCP User from
M2UA, M3UA and SUA as is presented by a specific implementation of MTP2,
MTP3 and SCCP.  It was considered important to ease implementation of
M2UA, M3UA and SUA within an existing SS7 protocol stack implementation,
as well as a conceptual test of adequacy of the protocol.

However, note that the approach is only applicable to the pure backhaul
case (exporting the SS7/SS7-User interface from SG to ASP).  For the
IPSP and multiple SG as STP scenarios things are somewhat different at
the IPSP and SG.  For multiple SGs as STP, a richer interface is
required at the SG (between the SS7 stack and the NIF) to support the
scenario, and the protocol between the SG and ASPs more closely
resembles an SG-SG interface.  For IPSP the protocol is again different.
SGs as STP requires a higher level of understanding of the specific SS7
network, but is largely a local matter at the SG and how the SG iteracts
with the SS7 network, which is, to some degree, outside the scope of the
specifications.  The statements in the specs about NIF and SG
interactions with the SS7 network are, therefore, largely illustrative.

See, for example, section 4.7.4 in SUA.

--brian

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