Subject: Re: M3UAv8: SSN in Routing Key and TCAP TID in example.

From: Greg Sidebottom <[email-masked]>
Date: Mon, 6 Aug 2001 12:44:22 -0400

Hi Barry, Gery,

Using the CIC for loadsharing within an AS as in Section 4.1.4 example, and
also as a Routing Key parameter (i.e., CIC Ranges) is not mutually
exclusive.  I don't believe we have to choose between the uses.

Cheers,

   Greg

----- Original Message -----
From: <[email-masked]>
To: "sigtran" <[email-masked]>
Sent: Thursday, August 02, 2001 11:55 AM
Subject: RE: M3UAv8: SSN in Routing Key and TCAP TID in example.

> Lyndon,
>
> Gery is definetly not alone in his view that the CIC "should be used for
loadsharing within a single AS, i.e. to select
> appropriate ASP, and thus be termed "Loadsharing Key" parameter instead of
> "Routing Key" parameter."
>
> Section 4.1.4 of m3ua v8 says the same:
>
> "The [loadsharing] selection algorithm is implementation dependent but
> could, for example, be round-robin or based on, for example, the SLS or
> ISUP CIC."
>
> Barry Nagelberg
> Software Engineer
> RadiSys, Corp.
> Signaling Products Design Center
> [email-masked]
> +1-856-642-9229 x237
>
>
>
>
>
> Verwimp Gery <[email-masked]>
> 08/02/01 11:05 AM
> Please respond to sigtran
>
>
>         To:     "sigtran" <[email-masked]>
>         cc:
>         Subject:        RE: M3UAv8: SSN in Routing Key and TCAP TID in
example.
>
>
> Hi Lyndon,
>
> To summarize MHO :
>
> - remove TRID (I think we have a consensus here ?)
>
> - remove SSN (otherwise you'd have to support SCCP subsystem management in
> M3UA ??); an AS on M3UA level "should" be defined no smaller than the
> smallest manageable MTP3 entity (phew !), i.e. an MTP3-User. For SUA, you
> can go down to an SCCP-user (SSN). For an M3UA AS this means RK =>
> NA/OPC/DPC/SI ranges. Hope we can reach consensus here ;))
>
> - CIC : actually my (and other's !) view is this parameter should be used
> for loadsharing within a single AS, i.e. to select appropriate ASP, and
> thus
> be termed "Loadsharing Key" parameter instead of "Routing Key" parameter.
> M3UA doesn't have any trunk group management procedures, does it ?
>
> So a proposal not to strike CIC from the REG REQ etc. parameters sent by
> an
> ASP, but not to define a different AS (single management view from M3UA).
>
> ____________________________
>
> Gery Verwimp
> > SIEMENS ATEA
> > ICN D CS D5
> >
> > Tel. : +32 14 25 3424
> Fax : +32 14 25 3212
> mailto:[email-masked]
> ____________________________________
>
>
> -----Original Message-----
> From: Greg Sidebottom [mailto:[email-masked]]
> Sent: donderdag 2 augustus 2001 8:24
> To: sigtran
> Subject: Re: M3UAv8: SSN in Routing Key and TCAP TID in example.
>
>
> Hi Lyndon,
>
> Yes the discussion is all over the place.  I think there is agreement to
> remove the TRID example.  As for removing the SSNs from the RK parameter -
> I
> am not sure.  IMHO if anybody is using it (or wants to use it) I say leave
> it in as an option but with an "Implementation Note" to help with
> interoperability (content of note to be determined).
>
> I thought that there was a proposal to remove CIC-range from the RK but
> this
> is apparently not the case.  But we probably need a note here also to
> assist
> with interoperability.
>
> Cheers,
>
>      Greg
>
> ----- Original Message -----
> From: "Lyndon Ong" <[email-masked]>
> To: "sigtran" <[email-masked]>
> Sent: Wednesday, August 01, 2001 8:36 PM
> Subject: Re: M3UAv8: SSN in Routing Key and TCAP TID in example.
>
>
> > Guys,
> >
> > This discussion is getting difficult to follow.  Can each person maybe
> summarize their proposal regarding the text, and we can see where there is
> actual disagreement and how to resolve it?
> >
> > Thanks,
> >
> > Lyndon
> >
> >
> >
> > Join 18 million Eudora users by signing up for a free Eudora Web-Mail
> account at http://www.eudoramail.com
> >
> >
> > ---
> > You are currently subscribed to sigtran as: [email-masked]
> > To unsubscribe send a blank email to
> [email-masked]
>
>
>
> ---
> You are currently subscribed to sigtran as: [email-masked]
> To unsubscribe send a blank email to
> [email-masked]
>
>
> ---
> You are currently subscribed to sigtran as: [email-masked]
> To unsubscribe send a blank email to
> [email-masked]
>
>
>
>
>
> ---
> You are currently subscribed to sigtran as: [email-masked]
> To unsubscribe send a blank email to
[email-masked]

---
You are currently subscribed to sigtran as: [email-masked]
To unsubscribe send a blank email to [email-masked]

---

From: Greg Sidebottom <[email-masked]>
Date: Mon, 6 Aug 2001 13:35:28 -0400

Hi Brian,

Allowing SSN as an option in the RK and then saying we SHOULD NOT use it is
not going to fly, but I guess you probably knew that  2;^)

I am, at a philosophical level, still puzzled why it is OK for ISUP CIC
ranges in an RK but not SCCP SSNs, as the same general management issues
come into play.   The lack of an ISUP-UA option (if that were actually
possible) doesn't sound like a good reason to me.  In both cases there are
issues in making the upper layer management procedures work.  I gather that
both CIC ranges and SSNs have been (or can be) used successfully for some
applications.

There is already a warning note about ISUP on page 18:

   "Care might need to be exercised by a Network Operator in the selection
of the routing information to be used as the Routing Key for a particular
AS.

   For example, where Application Servers are defined using ranges of ISUP
CIC values, the operator is implicitly splitting up control of the related
circuit groups.  Some CIC value range assignments may interfere with ISUP
circuit group management procedures."

I certainly believe that the ISUP management issues are easier to solve than
the SCCP management issues (!!) but I think, at a practical level, adding a
similar note could suffice.  I think the SSN note would have to be stronger,
ensuring that the SCMG procedures that are used work across the SG, and also
point to the use of the SUA for anything other than supporting some simple
class 0/1 services.  But I don't think we need to re-describe the SCCP
management procedures.

Cheers,

   Greg

----- Original Message -----
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Sent: Thursday, August 02, 2001 1:45 PM
Subject: Re: M3UAv8: SSN in Routing Key and TCAP TID in example.

> Ken,
>
> As long as the implementation note says that it SHOULD NOT
> be used, then there is no problem.
>
> Anything else and you will have to describe a set of procedures
> to go along with it which permits separate SG and AS implementations
> interoperable.  Perhaps we could just pull the entire connection-less
> part of SUA into the M3UA draft? ;)
>
> --Brian
>
> Ken Morneault wrote:                                          (Thu, 02 Aug
2001 12:38:53)
> >
> >
> > Pls see comments below.
> >
> > Ken
> >
> > At 11:10 AM 8/2/01 -0500, you wrote:
> > >Barry,
> > >
> > >The distinction between a Loadsharing Key and a Routing Key
> > >is rather blurry.  Removing CIC from Routing Key would
> > >preclude separate override AS for CIC ranges.  I don't know
> > >whether that should be thrown away: there is no ISUP-UA
> > >to handle the job.
> > >
> > >--brian
> > >
> >
> > I second that there is interest in supporting Override AS for CIC
> > ranges.  I don't think we should remove CIC from the Routing
> > Key.
> >
> > However, in regards to SSN comments below, I think it is
> > clear that there is interest in keeping SSN as an option based
> > on previous email.  I agreed with Greg's conclusion that we
> > should leave SSN as an option with an Implementation Note.
> > Therefore, I don't think we will be able to reach consensus
> > to remove it.
> >
> > >[email-masked] wrote:                (Thu, 02 Aug 2001
11:55:48)
> > > > Lyndon,
> > > >
> > > > Gery is definetly not alone in his view that the CIC "should be used
for loadsharing within a single AS, i.e. to select
> > > > Fax: +32 14 25 3212
> > > > You are currently subscribed to sigtran as: [email-masked]
> > >
> > >--
> > >Brian F. G. Bidulock
> > >[email-masked]
> > >http://www.openss7.org/
> > >
> > >
> > >---
> > >You are currently subscribed to sigtran as: [email-masked]
> >
> >
> >
> > ---
> > You are currently subscribed to sigtran as: [email-masked]
> --
> Brian F. G. Bidulock
> [email-masked]
> http://www.openss7.org/

---

---

From: Greg Sidebottom <[email-masked]>
Date: Mon, 6 Aug 2001 17:48:56 -0400

Hi Brian,

Response below ..

----- Original Message -----
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Sent: Monday, August 06, 2001 3:25 PM
Subject: Re: M3UAv8: SSN in Routing Key and TCAP TID in example.

> Greg,
>
> This issue of SSN is more a matter of what the SIGTRAN recommendation
> for SCCP transport will be.  Will it be SUA or will it be M3UA?
> I believe that it should be SUA, as SUA provides all the interoperability
> mechanisms necessary for a separate SG and ASP implementation to work
> together.  M3UA provides no expectation of interoperability on SCCP.
> As such, I cannot understand why SIGTRAN would also recommend SCCP on
> M3UA.  With SUA going to Last Call, SCCP elements should quite simply
> be struck from the M3UA proposal.  Proprietary solution can do what
> they may.
>
> --brian
>

[Greg2] I believe that we really think very differently here (not that there
is anything wrong with that!).

Here is my view (ignoring ISUP/TUP for a moment):

     - Sigtran transport of TCAP, RANAP, etc:  SUA
     - Sigtran transport of SCCP/(TCAP, RANAP ..): Any of M2PA, M2UA, M3UA
                                                         depending on
architectural need
     - Sigtran transport of MTP3/SCCP/(TCAP, RANAP..): M2UA or M2PA
depending on
                                                           architectural
need

Any of M2UA, M2PA, and M3UA transport SCCP within the Sigtran architecture.
SCCP is running at the ASP, and the peer SCCP is at the SG or at an SS7
node.  It goes without saying that for each of these peers to actually work
together properly, the upper layer SCCP needs to be set up
correctly/responsibly in the network.  Having an M3UA Routing Key use a
Subsystem number (which is the original question) may make this more
challenging, or downright impossible for some applications, but in the end
it is up to the operation of SCCP to make this work.   This doesn't make it
proprietary operation as long as SCCP is used according to specification.  I
don't believe we want/need to import an SCMG analog into M3UA to make it
work for all cases.

SUA to me is not for SCCP transport but for TCAP (or RANAP ..) transport.
The SCCP is terminated at the SG so the SUA spec explicitly handles the
interworking between SUA and SCCP SCMG.   The SG is relied upon to make
everything work together underneath the TCAP layer so it provides more
flexibility of application than M3UA.  A similar argument can be made for
use of M3UA over M2UA - because the SG is relied upon to make everything
work together underneath SCCP and ISUP, it provides more flexibility in
application.  That does not make M3UA superior to M2UA and cause us to
wonder why Sigtran allows us to have two choices for transport of ISUP.

Cheers,

   Greg

> Greg Sidebottom wrote:                                       (Mon, 06 Aug
2001 13:35:28)
> > > > > > "The [loadsharing] selection algorithm is implementation
dependent
> > but
> > > > > > could, for example, be round-robin or based on, for example, the
SLS
> > or
> > > > > >         Subject:        RE: M3UAv8: SSN in Routing Key and TCAP
TID
> > in example.
> > > > > > M3UA ??); an AS on M3UA level "should" be defined no smaller
than
> > the
> > > > > > - CIC : actually my (and other's !) view is this parameter
should be
> > used
> > > > > > for loadsharing within a single AS, i.e. to select appropriate
ASP,
> > and
> > > > > > ASP, but not to define a different AS (single management view
from
> > M3UA).
> > > > > > am not sure.  IMHO if anybody is using it (or wants to use it) I
say
> > leave
> > > > > > I thought that there was a proposal to remove CIC-range from the
RK
> > but
> > > > > > this
> > > > > > is apparently not the case.  But we probably need a note here
also
> > to
> > > > > > > This discussion is getting difficult to follow.  Can each
person
> > maybe
> > > > > > summarize their proposal regarding the text, and we can see
where
> > there is

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 6 Aug 2001 20:12:15 -0500

Greg,

Gee, Greg, that would be really cool if only someone could come
up with a need for doing this M3UA SSN thing.  On the contrary,
it appears that implementers prefer to scrap it.

So discard it: there is no use for it.

Again, I propose we scrap SSN from the M3UA document altogether.
Any implementors who care to object?

--brian

Greg Sidebottom wrote:                            (Mon, 06 Aug 2001 17:48:56)

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

---

---

From: Greg Sidebottom <[email-masked]>
Date: Mon, 6 Aug 2001 22:03:05 -0400

Thanks Brian,

More comments in-line ...

----- Original Message -----
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Sent: Monday, August 06, 2001 3:13 PM
Subject: Re: M3UAv8: SSN in Routing Key and TCAP TID in example.

> Greg,
>
> Please see comments inline...
>
2001 13:35:28)
>   ^^^^^^^^^^^^^^^^  why not?
> >

[Greg2] Everytime I think I've figured out what you are thinking, you
surprise me again 2;^)

> > possible) doesn't sound like a good reason to me.
>
> The only reason for CIC being the lack of ISUP-UA makes perfect sense to
me.
> What don't you understand about the fact that SUA is better adapted to
> exporting the SCCP/SCCP-User interface than M3UA?
>

[Greg2] Huh? Who said that the M3UA is better adapted to exporting the
SCCP/SCCP-User inteface - certainly not me.  The M3UA leaves the
SCCP/SCCP-User interface in the hands of the SCCP (the original owner!).

> > In both cases there are
> In the one case there is SUA, in the other there is not ISUP-UA.  How
about
> we write an ISUP-UA (call it ISUA 'cause IUA is used) and strike CIC too?
>

[Greg2] At least that sounds more consistent to me - but I 'll decline
thanks 2;^)

> Yes, but it doesn't go so far as to say how two implementations can
possibly
> be expected to interoperate, rendering it useless except in proprietary
> implementations.
>

[Greg2] It is just a warning that the M3UA doesn't guarantee that anything
anyone dreams up for splitting Application Servers based on CIC ranges will
work.  We can certainly add to it but there comes a point where we can't
stop every dumb thing that is possible.  Putting a danger sign up, or adding
a tall fence doesn't guarantee that nobody will fall (or throw themselves)
off a cliff.  How about we put together more details for the Applicability
statement - or even better perhaps the people that are doing this already
can provide some more guidelines.

> Again, if the draft does not state how SG and ASP are epected to
interoperate,
> implementations using SSN can only be proprietary in nature, having no
place
> in the draft.

[Greg2] In the case of M3UA I think it is SCCP that is expected to make it
interoperate (if thats the right word!).  I've agreed that in many
applications it can't, but that doesn't mean that I want to add SUA
functions to the M3UA to make these work.  Why can't we just accept that
some people want to do use SSN in an RK (or have done it already) for some
applications.  Nobody is mandating that everybody has to use it.  If an SGP
receives an RK with an SSN it has every right to refuse it (the cause code
is there) - if an ASP doesn't send it then all is well.  If in the future
nobody uses it anymore and nobody tests its interoperability, then it will
drop out of the spec per existing IETF procedures.

Cheers,

   Greg

dependent
SLS
TID
than
should be
ASP,
from
say
RK
also
person
where

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 6 Aug 2001 21:43:34 -0500

Greg,

Please see comments below...

Greg Sidebottom wrote:                                (Mon, 06 Aug 2001 22:03:05)
> > The only reason for CIC being the lack of ISUP-UA makes perfect sense to me.
> > In the one case there is SUA, in the other there is not ISUP-UA.  How about

I'll take it on, if we remove CIC from M3UA...

> > Yes, but it doesn't go so far as to say how two implementations can possibly

Gee, I'd like to add a parameter to the routing key: Signalling Link Code.
That way I can distribute messages based on which signalling link the message
came in on.  The would really help 'cause I don't want to use M2UA, and then
I could use M3UA for a signalling link.

:P

> > Again, if the draft does not state how SG and ASP are epected to interoperate,
> > implementations using SSN can only be proprietary in nature, having no place
> > in the draft.
> >
> > --Brian
> 

That's the worst excuse for cruft I've heard yet: that the IETF procedures
will eventually clear the cruft.  What is more likely is that nobody will
remember why it was there but suppose that someone might be using it (as you
are) and leave it in there.

--brian

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

---

---

From: Greg Sidebottom <[email-masked]>
Date: Mon, 6 Aug 2001 23:17:49 -0400

Hi Brian,

As you know I have no vested interest in use of the SSN in the RK.   I could
be arguing on my spare time (Sorry - I couldn't resist the Monty Python
quote).  Seriously, I detected some support for leaving in its use but if I
am in error I will graciously back off.   I have not noticed most
implementers saying to scrap it - I saw notes from two vendors to leave it
in and I have seen it used by another successfully in a specific
application.  If they have changed their minds then great , lets remove it -
I'm really tired of arguing on behalf of others.

Cheers,

   Greg

----- Original Message -----
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Cc: <[email-masked]>
Sent: Monday, August 06, 2001 9:12 PM
Subject: Re: M3UAv8: SSN in Routing Key and TCAP TID in example.

---

---

From: Greg Sidebottom <[email-masked]>
Date: Mon, 6 Aug 2001 23:35:34 -0400

Hi Brian,

More comments below ...

----- Original Message -----
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Sent: Monday, August 06, 2001 10:43 PM
Subject: Re: M3UAv8: SSN in Routing Key and TCAP TID in example.

about
possibly
> I could use M3UA for a signalling link.

[Greg3] Hee Hee - Good one!   But now you have to prove the need for it and
show how you are going to guarantee interoperability  2;^)

interoperate,
place
> are) and leave it in there.

[Greg3] A little lame I agree.  But IMHO we don't have agreement that it is
cruft - if we do then I agree, lets kill it now.  I don't think it has to be
left to anyone's assumptions - I thought that any part of the draft
eventually has to have interoperability between at least two
implementations.  If some functionality cannot be shown to be interoperable
then it must be removed.  But I am really not an expert on these procedural
things.

Cheers,

  Greg

> > > > > Ken Morneault wrote:
(Thu, 02
> > Aug
> > > > > > > > Gery is definetly not alone in his view that the CIC "should
be
> > > > > > > > appropriate ASP, and thus be termed "Loadsharing Key"
parameter
> > > > instead of
> > > > > > > > smallest manageable MTP3 entity (phew !), i.e. an MTP3-User.
For
> > > > SUA, you
> > > > > > > > can go down to an SCCP-user (SSN). For an M3UA AS this means
RK
> > =>
appropriate
> > ASP,
> > > > and
> > > > > > > > thus
> > > > > > > > be termed "Loadsharing Key" parameter instead of "Routing
Key"
> > > > parameter.
> > > > > > > > M3UA doesn't have any trunk group management procedures,
does it
> > ?
> > > > > > > >
> > > > > > > > So a proposal not to strike CIC from the REG REQ etc.
parameters
> > > > sent by
> > > > > > > > remove the TRID example.  As for removing the SSNs from the
RK
> > > > parameter -

---

---

From: "Gradischnig, Klaus" <[email-masked]>
Date: Tue, 7 Aug 2001 03:24:02 -0500

Greg,

whether or not SSNs are removed from RKs I don't care too much. However, any
indication that m3ua should not be used to transport SCCP would be really
objectionable.

Klaus

> Sent: August 06, 2001 11:18 PM
> To: sigtran
> > > [Greg2] I believe that we really think very differently 
> here (not that
> there
> > >      - Sigtran transport of SCCP/(TCAP, RANAP ..): Any of 
> M2PA, M2UA,
> M3UA
> > >                                                          
> depending on
> > > architectural need
> > > node.  It goes without saying that for each of these 
> peers to actually
> work
> > > challenging, or downright impossible for some 
> applications, but in the
> end
> > > it is up to the operation of SCCP to make this work.   
> This doesn't make
> it
> > > flexibility of application than M3UA.  A similar argument 
> can be made
> for
> You are currently subscribed to sigtran as: 
> [email-masked]

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 7 Aug 2001 04:12:30 -0500

Klaus,

I don't think that anyone has proposed that M3UA not transport SCCP
as a normal MTP-User.

--brian

Gradischnig, Klaus wrote:                 (Tue, 07 Aug 2001 03:24:02)

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

---

---

From: Greg Sidebottom <[email-masked]>
Date: Thu, 9 Aug 2001 00:10:04 -0400

Hi Klaus,

We could never add such an indication - it is clearly M3UA's mandate from
the beginning to transport SCCP (and ISUP, TUP).   I have never understood
the M3UA and SUA to be competing Sigtran solutions for transporting of SCCP
because SUA doesn't even transport SCCP.

While I'm on my soapbox ... The real issue in the thread is how far one can
run with M3UA's routing flexibility before you break the SCCP routing and/or
management going on a layer above.  (BTW, having an SCCP layer in the SG
helps with this issue a lot, but I won't go there in this e-mail).   How far
you can run with the M3UA routing flexibility also depends on what subset of
SCCP services/management is being used by the SCCP-User and applications.
SUA doesn't have to contend with this issue because it doesn't transport
SCCP but rather provides the SCCP upper layer interface (and services)
itself and interworks with the SCCP at the SG.

Cheers,

   Greg

----- Original Message -----
From: "Gradischnig, Klaus" <[email-masked]>
To: "sigtran" <[email-masked]>
Sent: Tuesday, August 07, 2001 4:24 AM
Subject: RE: M3UAv8: SSN in Routing Key and TCAP TID in example.

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 9 Aug 2001 00:50:32 -0500

Greg,

Greg Sidebottom wrote:                            (Thu, 09 Aug 2001 00:10:04)
> because SUA doesn't even transport SCCP.

What is your definition of "transport" here?  Does M3UA "transport"
MTP?  What about the IPSP cases?

> helps with this issue a lot, but I won't go there in this e-mail).

(Having SUA on SCCP running at the SG would help even more.)

> How far

Again, what is your definition of "transport"?  Both SUA and M3UAs messages
are parallels to SCCP and MTP PDUs.  Isn't it SCTP which is "transporting"
the MTP and SCCP?  Not M3UA?

--Brian

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

---

---

From: Lyndon Ong <[email-masked]>
Date: Thu, 09 Aug 2001 01:15:08 -0700

Brian,

I think what Greg means is "transports transparently" or something to that effect, SCTP is the transport layer but M3UA (or SUA or xUA) adapts SCTP to an existing upper layer protocol's needs.  SUA (+SCTP) transports SCCP Users, rather than SCCP.  

Anyway, this discussion is getting off point.  For those folks who have been arguing over SUA vs. M3UA, both are working group work items and are on track to be completed by the group (albeit slowly).

Let's get back to the specific M3UA issue :o)

Cheers,

L. Ong 
--

On Thu, 9 Aug 2001 00:50:32    Brian F. G. Bidulock wrote:
>You are currently subscribed to sigtran as: [email-masked]

Join 18 million Eudora users by signing up for a free Eudora Web-Mail account at http://www.eudoramail.com

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 9 Aug 2001 11:35:04 -0500

Lyndon,

Getting back to the specific M3UA issue, no-one has come up
with a situation where M3UA requires routing on SSN (despite
Greg's defense of these phantom individuals).

I propose that it be removed from the draft.

--Brian

Lyndon Ong wrote:                             (Thu, 09 Aug 2001 01:15:08)
>
> Brian,
> 
> I think what Greg means is "transports transparently" or something
> to that effect, SCTP is the transport layer but M3UA (or SUA or
> xUA) adapts SCTP to an existing upper layer protocol's needs.  SUA
> (+SCTP) transports SCCP Users, rather than SCCP.  
> 
> Anyway, this discussion is getting off point.  For those folks who
> have been arguing over SUA vs. M3UA, both are working group work
> items and are on track to be completed by the group (albeit
> slowly).
> 

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

---