Subject: Re: [Sigtran] m3ua- IG

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

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

---

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

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.

--brian

TOLGA ASVEREN wrote:                                                                 (Fri, 10 Jan 2003 09:36:57)