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

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 6 Aug 2001 14:13:06 -0500

Greg,

Please see comments inline...

Greg Sidebottom wrote:                                       (Mon, 06 Aug 2001 13:35:28)
> 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;^)
  ^^^^^^^^^^^^^^^^  why not?
> 
> 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.

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?

> 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.

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?

> 
> 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."

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.

> 
> 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.

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

> 
> 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
> > > > > 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]
> > > >
> > > >--
> > > >Brian F. G. Bidulock
> > > >[email-masked]
> > > >http://www.openss7.org/
> > > >
> > > >
> > > >---
> > > >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]
> >
> > --
> > Brian F. G. Bidulock
> > [email-masked]
> > http://www.openss7.org/
> >
> >
> > ---
> > 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]

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

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 6 Aug 2001 14:25:30 -0500

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

> possible) doesn't sound like a good reason to me.  In both cases there are

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

---