Subject: Re: [Sigtran] m3ua- IG

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

Samuel,

As you have also pointed out in one of your messages, this will be sent as
a SCCP management message in DATA. Then it is up to management logic in SG
to decide whether the global SSN state should be updated or not (similar to
what happens with SPMC availability/unavailability)

      Tolga

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

  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:

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

_______________________________________________
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 06:04:14 -0700

TOLGA,

Then you would have the SG intercepting and altering DATA sent to it by the AS?
This was the same as the problem for CIC.  The ASP has an expectation (stated
in the RFC) that DATA messages are transferred unaltered.

--brian

TOLGA ASVEREN wrote:                              (Fri, 10 Jan 2003 14:54:18)

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

---

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

Tolga,

To the point if we want to support SSN RK with M3UA stack then RFC 3332
should have been writen with much details of SSN, but it was not writen
so.and its too late to update M3UA with SSN RKs.

But on the other hand i have SUA to handle all SSN related issues.
So One will always select SUA to implement SSN RKs.
Nobody will select M3UA to implement SSN RK because i have much better
stack SUA to support SSN RK.

--Samuel