Subject: Re: [Sigtran] m3ua- IG

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

Brian,

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.
[TOLGA] (In addition to the changes I initially proposed)
"This management functionality might require that some messages are
filtered/generated by SG."

--brian

TOLGA ASVEREN wrote:                              (Fri, 10 Jan 2003
14:54:18)
>
> 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
>

--
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 06:22:26 -0700

TOLGA,

TOLGA ASVEREN wrote:                                                                 (Fri, 10 Jan 2003 15:10:53)
> filtered/generated by SG."

Which messages?  The ASP has an expectation that DATA messages that it sends
are not altered.  Are you saying that ANY DATA message can be altered,
filtered, generated?  That is in conflict with statements in the RFC requiring
non-encapsulation of MTP management messages and normal DATA message flows.
Please redescribe the discrimination and distribution functions of M3UA with
the additions of these new filtering and generation procedures.  I provided on
the CIC thread a number of statements in the RFC that present that no
alteration be made to DATA messages (see attached).  Please provide proposed
text changes for each of those sections.

--brian

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

Subject: Re: [Sigtran] M3UA distributing ISUP group messages
From: "Brian F. G. Bidulock" <[email-masked]>
To: Tolga Asveren <[email-masked]>
Cc: [email-masked]
Date: Sun, 5 Jan 2003 06:11:54 -0700
List-Id: Signaling Transport <sigtran.ietf.org>

Tolga,

Tolga Asveren wrote:                                                                 (Sun, 05 Jan 2003 04:10:25)
> [TOLGA] I feel I really fail to explain
> what I mean.  The real point is, if
> somebody can do it without
> interoperability problems, let them do
> it.

Let them do it outside of the standard
unless they can (at least logically)
demonstrate interoperability.

> And for some RK type even if it is
> really impossible, why us this related
> with M3UA itself? It is clear that for
> non-MTP3 RKs some management logic needs
> to be implemented and without violating
> the protocol. IMO, this is the only
> relevant thing from M3UA point of view.

Section 3.3.1:

  "The DATA message contains the SS7
  MTP3-User protocol data, which is an
  MTP-TRANSFER primitive, including the
  complete MTP3 Routing Label."

Split CGBs are not MTP-TRANSFER
primitives.

Section 3.3.1:

  "The Protocol Data parameter contains
  the original SS7 MTP3 message, including
  the Service Information Octet and
  Routing Label."

Split CGBs are not the "original SS7
MTP3 message".

Section 3.3.1:

  "The User Protocol Data field contains
  a byte string of MTP-User information
  from the original SS7 message starting
  with the first byte of the original SS7
  message following the Routing Label."

Split CGBs do not contain the original
SS7 byte for byte as indicated here.

Section 1.5.1

  "For internal SGP modeling purposes, at
  the NIF level, SS7 signalling messages
  that are destined to the MGC are
  received as MTP-TRANSFER indication
  primitives from the MTP Level 3 upper
  layer interface, translated to
  MTP-TRANSFER request primitives, and
  sent to the local M3UA-resident message
  distribution function for outgoing
  routing to the final IP destination.
  Messages received from the local M3UA
  network address translations and mapping
  function as MTP-TRANSFER indication
  primitives ar esent to the MTP Level 3
  upper layer interface as MTP-TRANSFER
  request primitives for outgoing MTP
  Level 3 routing to an SS7 SEP."

The message distribution function and
network address translations (routing) is
M3UA-resident (it is not in the NIF).

(Note that the above was also the only
ISUP example in the spec.)

Section 4.1.1:

  "The M3UA peer receiving the DATA
  message sends a MTP-TRANSFER indication
  primitive to the upper layer."

  "The M3UA message distribution function
  (see Section 1.4.2.1) determins the
  Application Server (AS) based on
  comparing the information in the
  MTP-TRANSFER request primitive with a
  provisioned Routing Key."

Comparison with Routing Keys occurs in the
M3UA, not the NIF.

Section 5.4.2.1:

  "When the M3UA layer at the SGP has
  received DATA messages from its peer
  destined to the SS7 network it will do
  the following:

  - Evaluate the optional fields of the
    DATA message, if present, to determine
    the Network Appearance;

  - Map the Protocol data field of the
    DATA message into an MTP-TRANSFER
    request primitive;

  - Pass the MTP-TRANSFER request
    primitive to the MTP3 of the concerned
    Network Appearance."

Aggregating CGBA responses would violate
this procedure.

> [TOLGA] For me the guideline is RFC/IG.
> As long as one does not violate it,
> she/he is free to do anyhting. I agree,
> the same applies to NIF, never violate
> the protocol. This is also my opinion
> for non-MTP3 RKs, if one can support
> them by not breaking the protocol, they
> are free to do it.

Who is "they?"

For CIC routing keys, the only current
propsal that does not violate the protocol
is to ensure than no circuit groups span
routing keys, ensuring that there is
always a default AS, and arranging
circuits and trunks such that a circuit
group message will never be generated that
spans the routing keys.

(Which is what I was telling Joseph when
you proposed your splitting algorithm
which violates all of the above.)

The fully interoperable way to acheive
what is being attempted with CIC routing
keys (but fails dismally) is by
_load-sharing_ on CIC ranges rather than
_routing_ on CIC ranges.

Why would anyone want to court a
proprietary solution (CIC routing) when an
interoperable solution (CIC load-sharing)
exists? 

I don't see any problem saying that M3UA
MUST use CIC load-sharing, which is
demonstrably interoperable, and MUST NOT
use CIC routing keys which cannot (any
time soon) be demonstrated  to
interoperate.

--brian