Subject: Re: [Sigtran] m3ua- IG

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

Brian,
--- "Brian F. G. Bidulock" <[email-masked]> wrote:
> Tolga,
>
> In the case of both SSN and CIC it is logically
> impossible to assure that such
> a function can be compliant in that regard.
>
> For CIC, this is because Circuit Supervision groups
> can always span Call
> Processing groups.  (It is not possible to assign
> Call Processing CIC ranges
> in such a fashion that Circuit Supervision groups
> are not broken, resulting in
> the problems mentioned in the appendix).
>
> For SSN, this is because SCCP management (SSN=0)
> functions span SSN
> assignments.
>
> If it were possible to do what you say (design a
> management functionality
> which was implementation dependent without causing
> interoperability problems)
> then I would say fine.  But as it is logically
> impossible to do so, M3UA
> cannot be said to suport either.
[TOLGA] For class0/class1 SCCP SSN based RKs seems to me doable. SSN state
can be kept on SG based on AS status, and also routing of management
messages probably won´t be very difficult for the ones destined for a
specific subsystem. A MSU containing SCCP congestion message needs to be
mapped to multiple DATA messages. One can argue that this violates some of
the paragraphs in RFC (the ones you pointed out, that one MSU should be
mapped to one DATA), but in fact this really does not bring a real
interoperability problem, because it does not require any special behaviour
from the peer. But still I would think a clarification sentence saying that
it might be necessary to map one MSU to multiple DATA to support non-MTP3
RKs, could be helpfull.

BTW, I agree for most of the changes you propose. IMO it is not a problem
to delete SSN examples but I prefer that RK types are kept flexible.
>
> --brian
>
> TOLGA ASVEREN wrote:
>                                 (Fri, 10 Jan 2003
> 09:36:57)
> >
> > Brian,
> >
> > It is true such a management functionality will be
> implementation
> > dependent, but it MUST be compliant with M3UA
> RFC/IG, so that it does not
> > bring interoperability problems.
> >
> >      Tolga
> >
> >
> >
> > TOLGA,
> >
> > TOLGA ASVEREN wrote:
> > (Fri, 10 Jan 2003 08:11:49)
> > >
> > > Samuel,
> > >
> > > What does it mean exactly that M3UA supports
> this or that RK? One can
> > argue
> > > about how suitable it is to use a certain RK
> type with M3UA but this IMO
> > is
> > > a different thing. I think the best is to leave
> RK types flexible and
> > maybe
> > > with one sentence to warn people about non-MTP3
> RK types, that those
> > might
> > > need some management functionalitiy on SG.
> >
> > Yes, some non-standard, non-iteroperable mangement
> functionality on the SG.
> > Which IMO is the same as saying that M3UA does not
> support it.
> >
> > --brian
> >
> >
> > --
> > Brian F. G. Bidulock
> > [email-masked]
> > http://www.openss7.org/
> >
> >
> >
> >
> > _______________________________________________
> > Sigtran mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/sigtran
>
> --
> Brian F. G. Bidulock
> [email-masked]
> http://www.openss7.org/
> _______________________________________________
> 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 01:38:54 -0700

TOLGA,

TOLGA ASVEREN wrote:                                                                 (Fri, 10 Jan 2003 10:18:25)
> specific subsystem.

Routing of management messages is impossible in an interoperable way.
Where they should go is niether specified nor obvious from the point
of view of using SSN for routing.  The ASP must know where and when it
will receive SCCP management messages to be interoperable.  M3UA does
not specify this, and so SSN routing keys are not supported.

> A MSU containing SCCP congestion message needs to be

Then the IG changes I proposed should meet with your approval.

--brian

---

From: "Valerie Gastaud" <[email-masked]>
Date: Fri, 10 Jan 2003 10:16:12 +0100

Brian,

TOLGA,

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

VG: If all the ASPs register for SSN=0 in broadcast mode, they will all
receive
SCCP management messages.

Valerie

---

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

Valerie,

Valerie Gastaud wrote:                                                             (Fri, 10 Jan 2003 10:16:12)
> receive SCCP management messages.

Then somewhere that would have to be specified, which it is not.  My point was
that the SG cannot do this without the ASP also having to know something of
the implementation.  Therefore, for interoperability it must be specified.

Tolga was trying to say that this could be implemented on the SG only without
the ASP even knowing about it, and without any procedures needing to be
specified for interoperability.  Your suggestion does not alter the case that
specification would be necessary for interoperability.

Also, if what you want to do is send particular SSNs to particular ASPs,
routing on SI and loadsharing on SSN is most appropriate.  Routing keys
are worthless in this regard do to underspecification in the RFC.

--brian