Subject: RE: [Sigtran] M3UA distributing ISUP group messages

From: James Doss <[email-masked]>
Date: Fri, 3 Jan 2003 15:05:53 -0800

Hi Joseph/Brian,
I was thinking IETF has a separate RFC for ISUP.
Is it not a good idea to start one. That will help to reduce the
complexities in the M3UA.
So that the ISUP and SCCP support can be seperated.

James Doss
Verisign 

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]]
Sent: Friday, January 03, 2003 5:06 PM
To: Wung, Joseph
Cc: [email-masked]
Subject: Re: [Sigtran] M3UA distributing ISUP group messages

Joseph,

I offerred to write one several times.  Nobody took me up
on my offer.

--brian

Wung, Joseph wrote:                      (Fri, 03 Jan 2003 11:35:13)
> Brian,
> 
> Is there ISUA anywhere?
> 
> Joe
> 
> > You will need to describe all that M3UA lacks in support
> > of CIC routing.  Once you are finished that exercise you
> > will have ISUA.  (As mentioned on the original thread
> > from July 2001.)
> > 
> > --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: "TOLGA ASVEREN" <[email-masked]>
Date: Mon, 6 Jan 2003 12:03:28 +0200

Valerie,

I agree that one might think any ISUP/SCCP functionality on SG as a
violation of a layered approach and this is not nice at all. It is obvious
that for non-MTP3 RKs, one migth need a management logic and such RKs are
not very suitable to be supported with a M3UA based SG. But I disagree with
a preassumption that any of those functionalities will bring
interoperability problems.
Another point is, if we want to keep the flexibility that RK types are not
limited, then it might be good to add a few sentences saying that
management functionality needed to support such RK types might require
message filterıng/generation on the level of the corresponding protocol.
This will address also some of the concerns Brian has pointed out.

         Tolga

                    "Valerie Gastaud"                                                                              
                    <valerie.gastaud@ul       To:     <[email-masked]>, "Tolga Asveren"                      
                    ticom.com>                 <[email-masked]>                                           
                    Sent by:                  cc:     <[email-masked]>                                           
                    sigtran-admin@ietf.       Subject:     RE: [Sigtran] M3UA distributing ISUP group messages     
                    org                                                                                            

                    06.01.2003 11:46                                                                               

Tolga, Brian,

Very interesting thread...
To me the point is that if it stays in the RFC, people will try to support
CIC range based RK. If there is a conscensus that this is a nonsense
because
this will lead to interoperability problems, then it must be removed from
the RFC.
I would tend to agree with you that M3UA, as a level 3 protocol, must only
route on level 3 available information, such as DPC and SIO.
If it is to route on CIC (or SSN), this means that NIF has to have some
sort
of level 4 functionality (ISUP or SCCP management) that must be identified
and specified. Also the limitations should be listed, such as pre-arranged
circuit groups for example.

Valerie

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of
Brian F. G. Bidulock
Sent: dimanche 5 janvier 2003 14:12
To: Tolga Asveren
Cc: [email-masked]
Subject: Re: [Sigtran] M3UA distributing ISUP group messages

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

---

From: "Wung, Joseph" <[email-masked]>
Date: Mon, 6 Jan 2003 13:41:15 -0500

Can someone tell me why as a user of MTP3, SCCP would need
SUA to backhaul SCCP services, but ISUP would not need
a UA function, e.g., ISUA to backhaul its services, and
rather uses M3UA to trasfer its services?

Joe

> From: James Doss [mailto:[email-masked]]
> Sent: Friday, January 03, 2003 6:06 PM
> To: [email-masked]'; Wung, Joseph
> Cc: [email-masked]
> Subject: RE: [Sigtran] M3UA distributing ISUP group messages
> 
> 
> Hi Joseph/Brian,

---

From: "TOLGA ASVEREN" <[email-masked]>
Date: Tue, 7 Jan 2003 08:15:43 +0200

Jo,

I would think, one of the reasons is, for separate ssn values, one might
have different applications whereas for different CIC values, it is still
the same call control. So, it seems to me loadsharing(instead of defining
separate RKs) for ISUP is a satisfactory solution.

          Tolga

Joe

---

From: "Ong, Lyndon" <[email-masked]>
Date: Tue, 7 Jan 2003 16:20:00 -0800

Guys,

This discussion is a bit confusing to me - the UAs 
were intended to interwork transport functions,
hence SCCP - SUA, MTP3 - M3UA.  ISUP is an application,
not transport, unless you are talking about user-to-user
signaling.

We've ended up with a proliferation of UAs since there
has not been a single model of how to interwork SS7 
and IP that has been preeminent.  I'm not sure that
adding more will help...

Cheers,

Lyndon

-----Original Message-----
From: Wung, Joseph [mailto:[email-masked]]
Sent: Monday, January 06, 2003 10:41 AM
To: 'James Doss'; [email-masked]'
Cc: [email-masked]
Subject: RE: [Sigtran] M3UA distributing ISUP group messages

Joe

---

From: "TOLGA ASVEREN" <[email-masked]>
Date: Wed, 8 Jan 2003 09:17:51 +0200

Brian,

     Brian,

          TOLGA,

          TOLGA ASVEREN wrote:
          (Wed, 08 Jan 2003 07:55:20)
          >
          > [TOLGA] I assume this can be handled with the basic CIC based
          routing
          > -without a management functionality on SG-.

          No, but it could be handled by CIC load sharing, just as SSN can
     be
          handled by load sharing.
     [TOLGA] So, for the case you mention, is it still possible to get ISUP
     management messages spanning multiple trunk groups, served by
     different
     applications?

     For SSN case, will loadsharing be enough for SCCP congestion case?
[TOLGA] Sorry, this won´t be a problem because SCCP will work as a single
entity in case of loadsharing. But this brings another question, if you
assume that user part(ISUP or SCCP) for one PC is going to work always as a
single entity, then what is the real benefit of loadsharing based on a user
part construct (CIC or SSN)? If the consensus is that entities, part of the
same user part and working independently are not necessary/easily
implementable then I also would agree with Brian that CIC range should be
taken out from RK in registration request.