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

From: "Wung, Joseph" <[email-masked]>
Date: Thu, 2 Jan 2003 11:17:23 -0500

Sanjeev,

No.

ANSIT1.113-4 Section 2.8.2.3

"When an exchange upon receipt of a CGB Message in not
able to give an appropriate blocking acknowledgement 
indication for each CIC ..., then no blocking 
acknowledgement indication" relating
to that/those CICs shall be given in the Status field
of the corrsponding CGBA Message which shall be sent
in response."  

"If a CGBA message in response to a CGB Message is
received containing in the status field the indications
no blocking acknowledgement for some or all of the 
circuits which are to be blocked due to the previously
sent CGB Message, then the maintenance personnel should
be notified for the circuits concerned"

How is the CGBA receiving side at the SS7 network to 
know a modifed CGB message would work.  I don't see 
M3UA has a solution here.

Joe

-----Original Message-----
From: Sanjeev P.J [mailto:[email-masked]]
Sent: Thursday, January 02, 2003 10:17 AM
To: Wung, Joseph; [email-masked]
Cc: [email-masked]
Subject: RE: [Sigtran] M3UA distributing ISUP group messages

True. But the response can have "no indication" for the CICs outside the
range defined for the AS allowing the other end to resend the group message
with the modified range.

Can't this be done??

sanjeev.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of
Wung, Joseph
Sent: Thursday, January 02, 2003 8:34 PM
To: [email-masked]'
Cc: [email-masked]'
Subject: RE: [Sigtran] M3UA distributing ISUP group messages

Brian,

It is not up to the ASP or AS.  The SS7 side can choose
to opearate on any circuit group as they want.

For example,
ASP-a serves AS-1(CIC=5000~5071) and
		 AS-2(CIC=5072~5143),

ASP-b serves AS-3(CIC=5144~5215) and
		 AS-4(CIC=5216~5287)

Neither the ASPs nor the ASes are splitting anything here.
The SS7 side can send a group related ISUP message, e.g.,
CGB, using any 24 circuit range across 5000~5287.  I
guess this is legal for them to do so.

But this would cause the SG send the message to ASP-a if
the CIC range in the CGB crosses the ASP boundary, or cause
one ASP to send it to AS-1 or AS-3 if crossing the AS
boundary.

Joe

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]]
Sent: Friday, December 27, 2002 5:08 PM
To: Wung, Joseph
Cc: [email-masked]'
Subject: Re: [Sigtran] M3UA distributing ISUP group messages

Joseph,

That would be up to the ASP.  If you want to make things easier
for the ASP, don't split circuit groups across AS either.

--brian

Wung, Joseph wrote:
(Fri, 27 Dec 2002 16:30:23)
> Brian,
>
> "don't split up your circuit groups across ASPs" would
> solve the problem of distributing group messages for the
> SG.  What if an ASP serves multiple ASes, which cover
> a spectrum of contiguous CICs.  For example, an ASP
> serves AS1(CIC=5000~5071), AS2(CIC=5072~5143).  Now
> the ASP receives a message about CICs(5060~5083).
> How would the ASP distribute the received message to
> the ASes it serves?
>
> Thanks,
> Joe
>
> -----Original Message-----
> From: Brian F. G. Bidulock [mailto:[email-masked]]
> Sent: Friday, December 27, 2002 3:59 PM
> To: Wung, Joseph
> Cc: [email-masked]'
> Subject: Re: [Sigtran] M3UA distributing ISUP group messages
>
>
> Joseph,
>
> Section A.2.1 says:
>
>   "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."
>
>
> The solution is: don't split up your circuit groups across ASPs: which
> makes sense anyway.
>
> --brian
>
> Wung, Joseph wrote:                              (Fri, 27 Dec 2002
15:14:38)
> > Each of the ISUP group related messages, i.e., CGB, CGU, GRS, GRA, etc.,
> has
> > a range field in addition to the CIC parameter that together specify a
> range
> > of circuits to operate on.  I would assume that the SGP that receives
> those
> > message would distribute them toward an ASP based on the CIC parameter
in
> > the messages without looking at the range field.  This may be ok if the
> > entire range fall into the same AS as the CIC.  What if the range
crosses
> > the boundary of the AS?  This may seem like an implementation dependent
> > issue, but it does impact how ISUP messages are distributed based on the
> > routing key.  Any solution?
> >
> > Joe
> > _______________________________________________
> > Sigtran mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/sigtran
>
> --
> Brian F. G. Bidulock
> [email-masked]
> http://www.openss7.org/

--
Brian F. G. Bidulock
[email-masked]
http://www.openss7.org/
_______________________________________________
Sigtran mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/sigtran

*********************************************************
Disclaimer

This message (including any attachments) contains 
confidential information intended for a specific 
individual and purpose, and is protected by law. 
If you are not the intended recipient, you should 
delete this message and are hereby notified that 
any disclosure, copying, or distribution of this
message, or the taking of any action based on it, 
is strictly prohibited.

*********************************************************
Visit us at http://www.mahindrabt.com

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

---

From: Tolga Asveren <[email-masked]>
Date: Thu, 2 Jan 2003 16:40:17 -0800 (PST)

Joe,
> M3UA has a solution here.
[TOLGA] IMO it is not very correct to say that "M3UA
has no solution" for this or similar situations. If
RKs based on constructs which are not native to MTP3
are used , one has to implement the necessary
mananegement functionality on NIF. This migth be
ugly/bad/difficult/not elegant/not recommended but IMO
is a valid solution.

__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com
_______________________________________________
Sigtran mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/sigtran

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 2 Jan 2003 17:48:58 -0700

Tolga,

Tolga Asveren wrote:                                                                 (Thu, 02 Jan 2003 16:40:17)
> ugly/bad/difficult/not elegant/not recommended but IMO

Or, in this case, not specified by M3UA and therefore not
supported by M3UA: i.e. M3UA does not have a solution here.

--brian

---

From: Tolga Asveren <[email-masked]>
Date: Thu, 2 Jan 2003 16:55:26 -0800 (PST)

Brian,
--- "Brian F. G. Bidulock" <[email-masked]>
wrote:
> Tolga Asveren wrote:                                
>                                 (Thu, 02 Jan 2003
> 16:40:17)
> > > "When an exchange upon receipt of a CGB Message
> in
> > > not
[TOLGA] IMO, if one wants to support RKs based on CIC
ranges, what needs to be done is taking the relevant
ISUP specifications, and implementing necessary
functionality in NIF. I don't think it is a very good
idea to explain in detail for each and every case,
what needs to be done. Is there a message from SS7
with a CIC value not mapping to any AS? Then IMO what
needs to be done is trying to imitate ISUP, where the
procedure is explained in ISUP specification.

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 2 Jan 2003 18:06:11 -0700

Tolga,

Tolga Asveren wrote:                                                                 (Thu, 02 Jan 2003 16:55:26)
> procedure is explained in ISUP specification.

In this fantastic SG implementation, what user is there at the
AS?  It is obviously not an MTP-User, but something higher-up in
ISUP.  That interface has not been specified in M3UA and
therefore interoperability cannot be acheived.

Where there is no interoperability there is no IETF standard.
Thus, M3UA does not support this.  Your bundle-fly M3UA might,
but then than would be a creature of your own making and not
the IETF standard.

Because there can be no interoperability without at least an
interface specification, it is not too strong to say that:

   M3UA MUST NOT route on SSN.

Besides, it was the concensus of the LC thread to strike them
along with the TIDs.  Greg just got tied up at about that time.

If you want to use them, you need to describe the interface
between your bundle-fly NIF and the AS-User, because it is not
the MTP/MTP-User interface that M3UA claims to transparently
preserve.

--brian

---

From: Tolga Asveren <[email-masked]>
Date: Thu, 2 Jan 2003 17:15:14 -0800 (PST)

Brian,
wrote:
> 16:55:26)
[TOLGA] No change is necessary on ASP side. 
> but then than would be a creature of your own making
[TOLGA] One can speak of interoperability, if there is
a procedure, which needs coordinated involvement of
both SGP and ASP. If necessary procedures are
implemented on SGP and no change is required on ASP,
nothing is changed from M3UA point of view. If changes
on SGP mandate any change on ASP, then I would agree
with you.
> along with the TIDs.  Greg just got tied up at about
[TOLGA] That M3UA is not friendly to support them and
so they shouldn't be given as examples and saying that
they MUST NOT be used are very different things.
> the MTP/MTP-User interface that M3UA claims to
[TOLGA] No, the MTP/MTP-User interface will be
preserved. That you go up on the stack when
necessary(in fact you don't, you can put whatever you
like to NIF, i.e. also the necessary management
functionality) does not mean that you can again go
down before leaving the node.

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 2 Jan 2003 18:25:26 -0700

Tolga,

Tolga Asveren wrote:                                                                 (Thu, 02 Jan 2003 17:15:14)
> [TOLGA] No change is necessary on ASP side. 

An AS that cannot be sure that the CGBA in response
to its CGB will come back to it, needs to be changed.

An AS that cannot be implemented with the lower boundary
primitives (MTP/MTP-User) specified in the ISUP standards
needs a change.

> implemented on SGP and no change is required on ASP,

First specify an interface (because MTP/MTP-User will not
do) and then worry about procedures.  You don't even have
an interface specification to work to: how are you going
to describe procedures?

> on SGP mandate any change on ASP, then I would agree

Change is required on the the ASP, so I suppose you agree.

> they MUST NOT be used are very different things.

The concensus on the thread was that M3UA should stick to
MTP information for routing. (Gee, that sounds like what
MTP does...)

> down before leaving the node.

It is not preserved.  That's why there is a problem with
circuit group management and unequipped CIC messages and
ACL congestion controls and ITU response to point code
congestion and inaccessibility of user parts and ...

You will have to back that statement up by demonstrating
to us how all these things will be handled for CIC routed
AS using the MTP/MTP-User interface as specified in the
standards.

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

---

From: Tolga Asveren <[email-masked]>
Date: Thu, 2 Jan 2003 19:36:15 -0800 (PST)

Brian,
wrote:
> 17:15:14)
> > >                                 (Thu, 02 Jan
> 2003
> > > > [TOLGA] IMO, if one wants to support RKs based
> on
> > > CIC
> > > > functionality in NIF. I don't think it is a
> very
> > > good
> > > > with a CIC value not mapping to any AS? Then
> IMO
> > > what
> > > > needs to be done is trying to imitate ISUP,
> where
> > > the
> > > In this fantastic SG implementation, what user
> is
> > > there at the
> > > AS?  It is obviously not an MTP-User, but
> something
> > > higher-up in
> > > ISUP.  That interface has not been specified in
> M3UA
> > > and
> > > Where there is no interoperability there is no
> IETF
> > > standard.
> > > Thus, M3UA does not support this.  Your
> bundle-fly
> > > M3UA might,
> > > but then than would be a creature of your own
> making
> > > and not
> > > the IETF standard.
> > > Because there can be no interoperability without
> at
> > > least an
> > > interface specification, it is not too strong to
> say
> > > that:
> > > 
> > > Besides, it was the concensus of the LC thread
> to
> > > strike them
> > > along with the TIDs.  Greg just got tied up at
> about
> > > that time.
> > > If you want to use them, you need to describe
> the
> > > interface
> > > between your bundle-fly NIF and the AS-User,
> because
> > > it is not
[TOLGA] For example for the case Joe has presented,
how it should work IMO with a pure M3UA solution is:
CGB arrives. If the range spans multiple RKs, SG
should generate multiple CGBs, pack them properly and
send them to the corresponding ASPs serving the
relevant AS. I agree, this is ugly and even arguably
against the spirit of a layered approach, but if one
wants to support RKs based on CIC ranges with M3UA,
this is the solution. So, what SG is doing is
filter/generate ISUP/SCCP messages for management
purposes to support CIC/SSN based routing. Where is
the change to M3UA protocol and to the interface
between SGP/ASP?

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 2 Jan 2003 22:14:15 -0700

Tolga,

Tolga Asveren wrote:           (Thu, 02 Jan 2003 19:36:15)
> relevant AS.

This violates the MTP/MTP-User interface: one MTP-User message
is being delivered across multiple interfaces.  This is not the
MTP/MTP-User interface and is therefore not an M3UA interface.

> I agree, this is ugly and even arguably
> this is the solution.

But it is not an M3UA solution.  It violates M3UA's own
proclaimed architecture:

  "The M3UA Layer at an ASP or IPSP provides the equivalent set of
   primitives at its upper layer to the MTP3-Users as provided by the
   MTP level 3 to its local MTP3-Users at an SS7 SEP."

Any questions?

What you are proposing is as un-M3UA as it is un-MTP3.

> the change to M3UA protocol and to the interface

Deliver one DATA message accross multiple interfaces?  It
shouldn't happen:

   "Routing Keys SHOULD be unique in the sense that each received SS7
    signalling message SHOULD have a full or partial match to a single
    routing result."

Sounds to me like you want to take one message and match it to
multiple results.  That is load-sharing not routing.

If you want more discussion on CIC, read that thread from July
2001 again.

AFAIC it not required in the RFC, it has no hope of
interoperability as a Routing Key (only useful for loadsharing),
and it will fall by the wayside anyway.

Even TALI (after which this CIC stuff was tailored) did a very
poor job of specifying any reasonable circuit management.

Not to mention that, as it stands, one has to turn down entire
trunk groups to add or remove a circuit, and I think it is well
on its way to being toast.

--brian

---

From: Tolga Asveren <[email-masked]>
Date: Fri, 3 Jan 2003 09:56:26 -0800 (PST)

Brian,
> MTP/MTP-User interface and is therefore not an M3UA
[TOLGA] This is far from being elegant but I wouldn't
think it as one MTP/MTP-User interface message being
delivered on multiple interfaces. What is happening is
that one ISUP message is mapped to multiple messages,
i.e. to multiple MTP/MTP-User messages and sent to the
reloevant ASPs. This is similar (I agree not the same,
happens one layer above) like one TFP is mapped to
multiple DUNA.
>    MTP level 3 to its local MTP3-Users at an SS7
[TOLGA] IMO, this does not change the interface.
Generating/Filetering ISUP/SCCP messages or keeping
some management information is not exposed to SGP/ASP
interface.
> multiple results.  That is load-sharing not routing.
[TOLGA] Not exacxtly. Mapping one message to multiple
messages happen on SCCP/ISUP level, not on M3UA level.
> on its way to being toast.
[TOLGA] I don't say, it is easy/elegant to support
non-MTP3 constructs as RKs, but it migth be possible.