Subject: Re: [Sigtran] M3UA MIB Draft05: Loadsharing on CIC ,SSN

From: [email-masked]
Date: Tue, 8 Jul 2003 09:37:15 +0530

Hi Brian and Samule,
  I have not got to the point answer to my question :
I want to know how an MTP3  user (ISUP or SCCP) selects SLS for effective
load distribution at MTP3 layer among the links available to reach a given
DPC. Is it that SLS is chosen per DPC for a logical session or globally per
each logical session irrespective of DPC for which this session is
intended.I know it is implementation dependent option but i want to know
how do most of the MTP3 user implementations choose SLS. By logical session
i mean logically related data.

Regards
Kamesh Kaul
www.hssworld.com
Hughes Software Systems

"Samuel Dur D. Jeyaseelan" <[email-masked]>@ietf.org on
07/04/2003 10:58:14 AM

Sent by:    [email-masked]

To:    [email-masked]
cc:

Subject:    Re: [Sigtran] M3UA MIB Draft05: Loadsharing on CIC ,SSN

Pastor,

 MIB-05 does not have 'load-shar on dpc',i was referring mib-04 which lead
 me into confusion.

 Thanks kakaul for our mail.

Kakaul,

 As you said MTP3 does not route messages based on CIC or SSN because
 there are no standards available, i agree with it.

 Have a look, suppose SG receives an MSU with routing indicator="Route on
 PointCode/SSN", if your SG supports static configuration then it is easy
 to route these messages to the corresponding subSystems based on
 statically configured SSN-ASP table the same way CIC-ASP table can be
 used to route ISUP messages to the corresponding MGCs.Basically CIC was
 removed from RFC to avoid complex problems say a msg comes with CIC
 range,this CIC range can be split across MGCs here the problem is
 potential.

 These are the reasons caused me to say that with static configuration
 CIC or/and SSN can be supported if an SG vendor and ASP vendor has
 mutual understanding.(but this is outside the scope of M3UA RFC)

--Samuel

  Alcatel USA, Inc.                  Internet: <userid>@ssd.usa.alcatel.com
  1000 Coit Road, Plano, Texas 75075
  ******* The opinions expressed are not those of Alcatel USA, Inc. *******

On Fri, 4 Jul 2003 [email-masked] wrote:

>
>
>
>
> Hi Samule,
>   Does MTP3 use CIC or SSN for load-distribution among the available
> links.I guess only SLS parameter in MTP3 is used for load-distribution
> among the available link.I want to know how an MTP3  user (ISUP or SCCP)
> selects SLS for effective load distribution at MTP3 layer among the links
> available to reach the  a given DPC.
>
> Regards
> Kamesh Kaul
> www.hssworld.com
> Hughes Software Systems
>
>
>
>
> "Samuel Dur D. Jeyaseelan" <[email-masked]>@ietf.org on
> 07/04/2003 09:29:51 AM
>
> Sent by:    [email-masked]
>
>
> To:    [email-masked]
> cc:
>
> Subject:    Re: [Sigtran] M3UA MIB Draft05: Loadsharing on CIC ,SSN
>
>
>
>  this is just an info regarding CIC and SSN - load-sharing.
>
>  A node can load-share its traffic based on CIC or SSN with the
>  help of static configuration but this is outside of the scope of M3UA
>  rfc.When an ASP vendor and SGP vendor agrees to do load-sharing based on
>  CIC or SSN with static confiuration they are welcome to do this,
>  since this has not been standardised, taking this to interop will
>  lead to problems.So almost everybody agrees to delete CIC and SSN
>  loadsharing concept from MIB-04.
>
>
> --Samuel
>
>   Alcatel USA, Inc.                  Internet:
<userid>@ssd.usa.alcatel.com
>   1000 Coit Road, Plano, Texas 75075
>   ******* The opinions expressed are not those of Alcatel USA, Inc.
*******
>
> On Thu, 3 Jul 2003, Brian F. G. Bidulock wrote:
>
> > agurmukhani,
> >
> > I think that they should be removed from the MIB, but we did NOT agree
> > that CIC or SSN should not be used for loadsharing.  Any criteria that
> > the SG/ASP desires to use for loadsharing being congnisant of the need
> > for ordering of user part messages is allowed for loadsharing.  We DID
> > agree to remove CIC, SSN from the Routing Key, because a rational and
> > interoperable basis for splitting CICs and SSNs across AS could not be
> > decided.
> >
> > The meanse oadsharing, on the other hand, is not specified in M3UA.
> > Some examples are given, but no requirements.  Some things that could
> > clearly be used are SLS, DPC/SLS, OPC/DPC/SLS, CIC, DPC/CIC,
OPC/DPC/CIC,
> > OPC/DPC/CIC/SLS, SSN, ....  and other permutations of these and even
> > higher layer parameters such as TID.
> >
> > My argument for removing them from the MIB is not that they cannot be
> > used, but that they have not been standardized.
> >
> > --brian
> >
> > [email-masked] wrote:
> (Thu, 03 Jul 2003 10:23:35)
> > >
> > >
> > >
> > >
> > > Hi...
> > >
> > >
> > > In my understanding and  as per the discussion and consensus on the
> mailing
> > > list , everyone agreed that  CIC and SSN should not be used as
> loadsharing
> > > basis
> > > be it within streams in a particular SCTP association or for active
> > > signalling processes.
> > >
> > > So would these be removed from  the m3uaStreamLshMethod  and
> > > m3uaSpLshMethod OBJECT-TYPE s in M3UA MIB draft.
> > >
> > >
> > > Thanks and Regards
> > > Anjali
> > > www.hssworld.com
> > > Hughes Software Systems.
> > >
> > > "DISCLAIMER: This message is proprietary to Hughes Software Systems
> Limited
> > > (HSS) and is intended solely for the use of the individual to whom it
> is
> > > addressed. It may contain  privileged or confidential information and
> > > should not be circulated or used for any purpose other than for what
it
> is
> > > intended. If you have received this message in error, please notify
the
> > > originator immediately. If you are not the intended recipient, you
are
> > > notified that you are strictly prohibited from using, copying,
> altering, or
> > > disclosing the contents of this message. HSS accepts no
responsibility
> for
> > > loss or damage arising from the use of the information transmitted by
> this
> > > email including damage from virus."
> > >
> > >
> > > _______________________________________________
> > > 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
>
>
>
> _______________________________________________
> Sigtran mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/sigtran
>

_______________________________________________
Sigtran mailing list
[email-masked]
 https://www1.ietf.org/mailman/listinfo/sigtran

_______________________________________________
Sigtran mailing list
[email-masked]
 https://www1.ietf.org/mailman/listinfo/sigtran

"DISCLAIMER: This message is proprietary to Hughes Software Systems Limited
(HSS) and is intended solely for the use of the individual to whom it is
addressed. It may contain  privileged or confidential information and
should not be circulated or used for any purpose other than for what it is
intended. If you have received this message in error, please notify the
originator immediately. If you are not the intended recipient, you are
notified that you are strictly prohibited from using, copying, altering, or
disclosing the contents of this message. HSS accepts no responsibility for
loss or damage arising from the use of the information transmitted by this
email including damage from virus."

_______________________________________________
Sigtran mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/sigtran

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 7 Jul 2003 22:32:10 -0600

kakaul,

I'm sorry that we did not answer your question, but it is rather outside the
scope of SIGTRAN and is in the domain of SS7 standards and implementation.

Is there not anyone within your own organization that understands SS7 well
enough to answer this question for you?

If not, you are probably better to ask SS7 questions on the forums at
http://www.c7.com/ or on the OpenSS7 mailing list at http://www.openss7.org/

ITU-T/ETSI ISUP, for example, associates a fixed SLS value with each CIC of an
ISUP trunk group and use that fixed SLS value for each ISUP message pertaining
to the CIC.

ANSI T1.113 ISUP does not associate an SLS value with a CIC.  Rather, the ISUP
user selects an SLS for each call.  This performs better SLS load distribution
that is achieved by the ITU-T/ETSI approach above.

The most direct approach is to simply use global variables and increment them
with each call, each SCCP connection, or each SCCP unit data.

This is not done on a per-destination basis for SCCP and ANSI ISUP.  For
ITU-T/ETSI ISUP it just happens that the fixed SLS assignment per CIC happens
to be on a per-destination basis, but this does not achieve optimal load
sharing.

If one wants to load share on anything less than a global basis, it should be
done on a per-outgoing-route basis rather than a per-route-set basis.  The
difference is that SLS is used to load share between signalling links
belonging to a combined link set (routes of equal priority) and it is on this
basis that it needs to be best distributed to achieve load sharing.

--brian

[email-masked] wrote:                     (Tue, 08 Jul 2003 09:37:15)

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