Subject: Re: [Sigtran] m3ua- IG

From: "TOLGA ASVEREN" <[email-masked]>
Date: Fri, 10 Jan 2003 13:51:14 +0200

Samuel,

The point is, no special management logic should be necessary on ASP. The
ASP is just any M3UA compliant ASP, nothing special there. BTW, does M3UA
RFC tell to support any specific RK type? For example if a SG supports only
DPC based RKs, will it be compliant or not with RFC?
I think it is totally dependent on the implementor, which types of RKs
her/his SG is going to support.

    Tolga

Tolga,

If X has implemented SG with SSN RK (eventhough it is not told in rfc),
How does X expect Y to implement the same 'management logic' at ASP?

Everyone will try to follow RFC strictly to go for interop.

Blindly speaking SSN is not a field(whereas SSN in one of the fields in
SUA messages) of any M3UA message so nobody will implement SSN RK with
M3UA stack.

--Samuel

  Alcatel USA, Inc.                  Internet: <userid>@ssd.usa.alcatel.com
  1000 Coit Road, Plano, Texas 75075
  ******* The opinions expressed are not those of Alcatel USA, Inc. *******

On Fri, 10 Jan 2003, TOLGA ASVEREN wrote:

>
> Brian,
> --- "Brian F. G. Bidulock" <[email-masked]> wrote:
> > TOLGA,
> >
> > TOLGA ASVEREN wrote:
> >                                 (Fri, 10 Jan 2003
> > 13:10:15)
> > > > In a short period of time we have two
> > > > approaches: yours and Valerie's.  How
> > > > many more approaches must both the SG
> > > > and ASP support to be interoperable?
> > > > That is what is missing from the M3UA
> > > > spec: a basis for interoperability.
> > > > As an IETF document, M3UA RFC as it
> > > > stands does not support SSN, because
> > > > there is no basis for this
> > > > interoperability (because it is
> > > > completely unspecified).
> > > >
> > > > So, tommorrow, Joe comes up with a new
> > > > approach for SCCP management.  He
> > > > reads the M3UA spec and it says that
> > > > any messages that do not match a
> > > > routing key are sent to a default ASP.
> > > > So he builds his ASP to receive these
> > > > messages only when it is configured in
> > > > the SG as the default ASP.  His ASP
> > > > does not work with your or Valerie's
> > > > SGs, but he has not violated any
> > > > requirement in the M3UA RFC.
> > > >
> > > > So all that results is a bunch of
> > > > non-interoperable solutions.  That is
> > > > not the objective of an IETF RFC.  In
> > > > fact, an RFC should remove the
> > > > possibility of interoperability
> > > > through specification.  Therefore, the
> > > > M3UA RFC should go so far as to say
> > > > that SSN Routing Keys MUST NOT be
> > > > supported, because non-interoperable
> > > > solutions will result.
> > > [TOLGA] I totally disagree. You present
> > > some solutions, which bring some
> > > interoperability problems, and use this
> > > as an evidence of inappropriateness of a
> > > solution, which does not have
> > > interoperability problems. As I said
> > > several times, as long as a SG
> > > supporting SSN based routing works with
> > > a standard M3UA based ASP, I don´t see
> > > any problem.
> >
> > Which standard M3UA ASP?  Yours?
> > Valeries?  Joes?  Several? All?
> [TOLGA] Any ASP compliant with M3UA RFC.
> >
> > You cannot acheive interoperability in
> > this regard without both the SG and the
> > ASP knowing which procedures are used.
> [TOLGA] I don´t propose this. What I propose is, an implementation
> dependent management funtionality on SG, which does not require any
change
> on the peer, i.e. which won´t prevent SG to work with a M3UA compliant
ASP.
> >
> > Therefore, you cannot (as you said
> > previously) just implement SSN RK on the
> > SG without the ASP knowing how it is done.
> [TOLGA]Why? What requirement will it put to ASP or to the M3UA protocol?
> >
> > Is there anyone else on the list that
> > thinks this is basis for interoperability?
> [TOLGA} Or which thinks that ımplementing a functionality on SG which
does
> not put any requirement to M3UA protocol or to the peer, is a violation
of
> the protocol?
>
> _______________________________________________
> Sigtran mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/sigtran
>

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 10 Jan 2003 05:08:13 -0700

TOLGA,

TOLGA ASVEREN wrote:                                                                 (Fri, 10 Jan 2003 13:51:14)
> 
> Samuel,
> 
> The point is, no special management logic should be necessary on ASP.

The point is special management logic is required on the ASP so that
it can know where and when it is receiving SCCP management messages.

> The ASP is just any M3UA compliant ASP, nothing special there.

It is a VERY special ASP.  It's M3UA knows about SCCP mangement messages
and knows where the particular SG is going to place them, whether it needs
to register for an AS with SSN=0, whether it needs to only act as a default
ASP, whether it can expect management messages on each AS corresponding to
a subsystem, in fact it needs to know that the SG is performing SSN routing
at all (which is not supported by dynamic registration).

> BTW, does M3UA RFC tell to support any specific RK type? For example if a SG
> supports only DPC based RKs, will it be compliant or not with RFC?  I think
> it is totally dependent on the implementor, which types of RKs her/his SG is
> going to support.

Of the proper M3UA routing keys (OPC/DPC/SI) routing on DPC must be supported
at a minimum, otherwise, the implementation will not be useful.

--brian

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

---

From: "Samuel Dur D. Jeyaseelan" <[email-masked]>
Date: Fri, 10 Jan 2003 06:49:01 -0600 (CST)

Tolga,
  
Say i have implemented M3UA with SSN RK.means my node has a
database which contains Subsystem backup type(such as Load
shared,replicate...) and Subsystem status(such as available,congested and
unavailable).

Subsystem at ASP is congested or unavailable ,How does ASP indicate this
to SG? Do you have any M3UA message which will say so and so subsytem is
congested...like this lot issues are there.

--Samuel

On Fri, 10 Jan 2003, TOLGA ASVEREN wrote:

> > [TOLGA} Or which thinks that ýmplementing a functionality on SG which
> does