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

From: "Wung, Joseph" <[email-masked]>
Date: Fri, 3 Jan 2003 15:33:43 -0500

Tolga,

> -----Original Message-----
> From: Tolga Asveren [mailto:[email-masked]]
> Sent: Friday, January 03, 2003 12:42 PM
> To: [email-masked]
> Subject: RE: [Sigtran] M3UA distributing ISUP group messages
> 
> 
> Joe,
> --- "Wung, Joseph" <[email-masked]> wrote:
> > Tolga,
> > 
> > You're proposing a solution that may work only in a
> > case
> > where both ends of the M3UA interface, i.e., SGP and
> > ASP, are implemented by the same vendor.  Then why
> > bother to specify an interface as an IETF standard?
> [TOLGA] Why should they be implemented by the same
> vendor? What I say is implementing necessary logic -if
> possible- only on SG. I think this is doable for
> class0/class1 SSN based RKs. For ISUP, I didn't think
> in too much detail. But for example for the case you
> presented, what special procedure should ASP follow to
> make it work? AS will receive CGB and will reply it
> with CGBA. It is responsibility of SG, to corraleta
> the answers and pack them to a single reply. What
> special procedure from M3UA point of view is
> introduced?

There are no such procedures in M3UA as it stands that 
would enforce SG vendors to do so.  In addition, how is
the ASP that receives such CGB with CICs outside the 
range defined for the ASP to know that those CICs are 
NOT unequipped so it will not send UCIC messages in
response?

Joe
> > 
> > Joe
> > 
> > > [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? 
> > > 
> > > 
> > > __________________________________________________
> > > 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
> > > 
> 
> 
> __________________________________________________
> 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
> 
_______________________________________________
Sigtran mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/sigtran

---

From: Tolga Asveren <[email-masked]>
Date: Fri, 3 Jan 2003 14:20:55 -0800 (PST)

Joe,
> NOT unequipped so it will not send UCIC messages in
[TOLGA]I think I failed to explain what I mean. First,
such procedures don't need interaction between
SGP/ASP, so what one needs it to take ISUP spec and
implement it according to it. 
For your case, what I say is that one CGB maps to
multiple CGB is it spans multiple RKs. So, each AS
will receive just the part it is configured for. SG
should wait for CGBAs and should generate one CGBA
based ont he information received from them. So, there
is no change necessary to the M3UA protocol.
Everyhting is handled in SG, and the guideline is ISUP
spec.
Having said all of that, implementing such a logic on
SG is really ugly, but the point is, it does not
require something to be defined in the M3UA protocol
itself.

---

From: Tolga Asveren <[email-masked]>
Date: Fri, 3 Jan 2003 14:25:33 -0800 (PST)

Joe,
> would enforce SG vendors to do so.  In addition, how
[TOLGA] Please also note that M3UA does not put any
restrictions on the type of rouye keys. So, it is SGs
responsibility to support necessary management for
them. Otherwise, we would need to explain for each and
every possible RK type, what to do. Of course M3UA
does not mandate SGs to support SSN/CIC based RKs. But
if one SG wants to support it (without any changes to
M3UA as defined in RFC/IG) it should be free to do so.

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 3 Jan 2003 15:53:42 -0700

Tolga,

Tolga Asveren wrote:                     (Fri, 03 Jan 2003 14:20:55)
> Everyhting is handled in SG, and the guideline is ISUP spec.

Two things:

(1) having the SG change the content of an MSU
    changes the on-the-wire protocol.  M3UA does not change the
    content of MSUs that it passes to an AS.  (See section
    1.3.1)

(2) If SG does not alter the circuit group message in this case,
    the ISUP user at the AS would need to be changed from the
    standard ISUP state machines, otherwise, the AS will respond
    to the _entire_ circuit group message as is required by the
    ISUP specifications.

So M3UA does not support what you propose.

--brian

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 3 Jan 2003 16:00:40 -0700

Tolga,

Tolga Asveren wrote:                       (Fri, 03 Jan 2003 14:25:33)
> M3UA as defined in RFC/IG) it should be free to do so.

The M3UA SG is not free to change the content of an MSU.

Also, we went to lengths to indicate that the functions of
the SCCP are not reproduced in M3UA (see Sections 1.3.1 and
section 1.5.3.)  The same applies to ISUP.

Also, read section 1.1 carefully.

  "The delivery mechanism should meet the following criteria:

   *  Support for the transfer of all SS7 MTP3-User Part
      messages (e.g. ISUP ...

Remember that "should" and "SHOULD" are the same thing.

--brian

---

From: Tolga Asveren <[email-masked]>
Date: Fri, 3 Jan 2003 15:05:39 -0800 (PST)

Brian,
--- "Brian F. G. Bidulock" <[email-masked]>
>     content of MSUs that it passes to an AS.  (See
[TOLGA] If message filtering/generation is done in
NIF, I wouldn't think this as a violation. IMO,
important is, whether some special behavior is
expected from the peer, i.e. from ASP. IMO anything
else is not a change to the on the wire protocol. 
> (2) If SG does not alter the circuit group message
[TOLGA] It will alter.
> So M3UA does not support what you propose.
[TOLGA] Of course nobody will force anybody to support
it, but if somebody can support it wothout any
additional requirements to the on the wire protocol,
this also should be allowed (in fact, what can we do,
put the guy to the jail or declare the SGP incompliant
with M3UA-although it is working fine with any M3UA
compliant ASP- because it claims to support CIC RKs?)

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 3 Jan 2003 16:12:19 -0700

Tolga,

Tolga Asveren wrote:                                                                 (Fri, 03 Jan 2003 15:05:39)
> else is not a change to the on the wire protocol. 

But it *is* a change to on-the-wire protocol making it
un-M3UA.

> additional requirements to the on the wire protocol,

Changing MSU content is a change to the on-the-wire
protocol.

--brian

---

From: Tolga Asveren <[email-masked]>
Date: Fri, 3 Jan 2003 15:19:24 -0800 (PST)

Brian,
> section 1.5.3.)  The same applies to ISUP.
[TOLGA] They can be implemented in NIF (like all of
the other ugly procedures)

> Remember that "should" and "SHOULD" are the same
[TOLGA]My understanding of this sentence: Traffic for
any user part should be supported.
If I do a ISUP mapping in NIF, is there a problem from
protocol point of view? 

We have different opinion about what is on the wire
protocol. For example if a have a SGP changing the MSU
(which you don't like), will your ASP complain when
talking to this SGP?

Do I find supporting CIC/SSN based routing with M3UA
easy/nice/elegant? This is a different question.

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 3 Jan 2003 16:36:46 -0700

Tolga,

Tolga Asveren wrote:                                                                 (Fri, 03 Jan 2003 15:19:24)
> the other ugly procedures)

It doen't matter where you change the MSU: it is not a 
matter of functional placement.  The point is that the
on-the-wire protocol betwen SG and ASP is changed.

> If I do a ISUP mapping in NIF, is there a problem from

The sentence says "transfer" not "traffic".

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 3 Jan 2003 16:43:06 -0700

Tolga,

Let's go one step further with this.

What happens when an AS across the circuit group split goes
AS-INACTIVE and the other is AS-ACTIVE?  What will the SG do?

In ISUP the entire User-Part is equipped or unequipped,
acessible or inaccessible.

What will the SG do when only a one part of a circuit range is
inaccessible?

--brian

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 3 Jan 2003 17:10:09 -0700

Tolga,

> else is not a change to the on the wire protocol. 

Filtering (message discrimination and routing) and
generation (of MTP management messages) are MTP Level
3 functions.  These do not reside in the NIF, they
reside in MTP Level 3.

Filtering and generation of ISUP messages is not an
MTP Level 3 function.  Placing these functions on an
SG result in the SG performing a part of the functions
of ISUP.  Unfortunately, to properly perform most ISUP
functions requires that the function be aware of
circuit-state.  M3UA protocol has no mechanism for
coordinating circuit state between SG and ASP.
Circuit state is the sole domain of ISUP at the ASP.

Trying to "fake out" ISUP state machines at the ASP
makes presumptions about ISUP implementation and ISUP
configuration at the ASP.  The only way to ensure that
these presumptions hold is to place requirements on
ISUP at the ASP.  It is not in fitting with M3UA's
purpose or intention to place requirements on ISUP
implementation or configuration at an ASP.

Routing on CIC requires that management functions
still interwork at the SG.  M3UA (by nature of the
MTP3 below it) has procedures when signalling point
codes change state (e.g. transfer-prohibited) and when
MTP-Users change state (e.g. user-part-unavailable),
but M3UA has no procedures to handle a CIC range
becoming unacessible (there is no such state for a
circuit).  Therefore M3UA is unequipped to deal with
CIC Routing.

On the other hand, M3UA is well equipped to perform
OPC/CIC load-sharing within an AS which only uses
DPC/SI as a routing key.  This is because either the
entire user part is available or it is unavailable.

One could even argue that M3UA can perform
load-sharing on CIC within an AS within a OPC/DPC/SI
routing key (presuming that an originating SS7 node
does not aggregate remote user state across multiple
OPCs).

When load-sharing, either the entire AS is available
or it is not.  M3UA can properly manage SPMC state as
well as user state witin the SPMC.

So, there is much more to consider than just faking
out circuit group messages.

Circuit-state is integral to all ISUP state machine
functions.  Experience has shown that when one
attempts to separate functions without regard to
circuit state, the result is hung circuits,
maintenance alarms and overhead, repeated and annoying
manual interventions, unnecessary cost and loss of
revenue.

--brian

---

From: Tolga Asveren <[email-masked]>
Date: Sat, 4 Jan 2003 05:40:43 -0800 (PST)

Brian,
> 3 functions.  These do not reside in the NIF, they
[TOLGA] You can filter/generate messages at any layer.
If you filter MTP3 messages it is done of course in
MTP3. If one is interested in ISUP messages, it is in
ISUP.
> Circuit state is the sole domain of ISUP at the ASP.
[TOLGA] I agree that SG will need to keep ISUP related
info and implement some ISUP logic in this case. But
the point is, no additon to M3UA is necessary. Based
on AS state and by checking ISUP messages necessary
information can be kept.
> circuit).  Therefore M3UA is unequipped to deal with
[TOLGA] In such a case, I would think one can block
the circuit. Or alternatively, even when one AS
(serving a CIC range) goes inactive, SG declares user
part unavailable.
> entire user part is available or it is unavailable.
[TOLGA] I also would prefer this method. As I said
several times, I don't consider CIC based RKs as a
good alternative and as elegant. But if one tries to
support them without an additional requirement to
M3UA, let them try it. Whether they succeed or fail is
their problem. Especially SSN based routing for
class0/class1 seems doable for me. There might be also
RK types, which require a managent logic to be
implemented in SG, IMO as long as it does not put
additonal requirement to M3UA, there is no problem.

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Sat, 4 Jan 2003 06:58:24 -0700

Tolga,

Tolga Asveren wrote:                                                                 (Sat, 04 Jan 2003 05:40:43)
> > > [TOLGA] If message
> > > filtering/generation is done in NIF,
> > > I wouldn't think this as a
> > > violation. IMO, important is,
> > > whether some special behavior is
> > > expected from the peer, i.e. from
> > > ASP. IMO anything else is not a
> > > change to the on the wire protocol. 
> > 
> > Filtering (message discrimination and
> > routing) and generation (of MTP
> > management messages) are MTP Level 3
> > functions.  These do not reside in the
> > NIF, they reside in MTP Level 3.
> [TOLGA] You can filter/generate messages
> at any layer.  If you filter MTP3
> messages it is done of course in MTP3.
> If one is interested in ISUP messages,
> it is in ISUP.
> > 
> > Filtering and generation of ISUP
> > messages is not an MTP Level 3
> > function.  Placing these functions on
> > an SG result in the SG performing a
> > part of the functions of ISUP.
> > Unfortunately, to properly perform
> > most ISUP functions requires that the
> > function be aware of circuit-state.
> > M3UA protocol has no mechanism for
> > coordinating circuit state between SG
> > and ASP.  Circuit state is the sole
> > domain of ISUP at the ASP.
> [TOLGA] I agree that SG will need to
> keep ISUP related info and implement
> some ISUP logic in this case. But the
> point is, no additon to M3UA is
> necessary. Based on AS state and by
> checking ISUP messages necessary
> information can be kept.

M3UA is not just message syntax, it is
procedures.  By adding procedures, you are
changing M3UA.

> > 
> > Trying to "fake out" ISUP state
> > machines at the ASP makes presumptions
> > about ISUP implementation and ISUP
> > configuration at the ASP.  The only
> > way to ensure that these presumptions
> > hold is to place requirements on ISUP
> > at the ASP.  It is not in fitting with
> > M3UA's purpose or intention to place
> > requirements on ISUP implementation or
> > configuration at an ASP.
> > 
> > Routing on CIC requires that
> > management functions still interwork
> > at the SG.  M3UA (by nature of the
> > MTP3 below it) has procedures when
> > signalling point codes change state
> > (e.g. transfer-prohibited) and when
> > MTP-Users change state (e.g.
> > user-part-unavailable), but M3UA has
> > no procedures to handle a CIC range
> > becoming unacessible (there is no such
> > state for a circuit).  Therefore M3UA
> > is unequipped to deal with CIC
> > Routing.
> [TOLGA] In such a case, I would think
> one can block the circuit. Or
> alternatively, even when one AS (serving
> a CIC range) goes inactive, SG declares
> user part unavailable.

The circuit is neither blocked from a
hardware or a maintenance perspective.
The blocking state of the circuit is at
the ASP (not at the SG).  How can the SG
know whether the circuit is already
blocked or not?  If the SG blocks an
already blocked circuit, maintenance
alarms will trigger at the remote end on a
per-circuit basis.

Sending UPU is incorrect unless the other
AS based on routing key are taken out of
service as well (they cannot be allowed to
send messages when UPU is signalled).  How
will the SG know when they are available
again if it forces all the AS out of
service with, say, ASPIA ACK?  How does it
know when it can activate them again and
when to stop sending UPU?

You see, circuit blocking is incorrect
(because the SG does not know the circuit
state), and UPU is incorrect (because
routing is being performed sub SI).  This
is why M3UA has insufficient support for
CIC routing.

If one load-shares on CIC (rather than
routing) there is no problem.

> > 
> > On the other hand, M3UA is well
> > equipped to perform OPC/CIC
> > load-sharing within an AS which only
> > uses DPC/SI as a routing key.  This is
> > because either the entire user part is
> > available or it is unavailable.
> [TOLGA] I also would prefer this method.
> As I said several times, I don't
> consider CIC based RKs as a good
> alternative and as elegant. But if one
> tries to support them without an
> additional requirement to M3UA, let them
> try it.

Why?  If they want to experiment, let them
experiment outside the standard.

> Whether they succeed or fail is their
> problem.

Let them succeed or fail outside the
standard.

Besides, who are these people?  They do
not exist.

> Especially SSN based routing for
> class0/class1 seems doable for me.

Can't handle management either.  SUA is
the recommended way to transport
SCCP/SCCP-User interface.

> There might be also RK types, which
> require a managent logic to be
> implemented in SG, IMO as long as it
> does not put additonal requirement to
> M3UA, there is no problem. 

Adding procedures outside MTP3 is placing
additional requirement on M3UA (not to
mention placing requirement on the ASP),
so all of them have a problem.

--brian

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Sat, 4 Jan 2003 07:15:35 -0700

Tolga,

> on AS state and by checking ISUP messages necessary

Take a look at the AS to SG direction now:

I have two AS1 RK=5/6/CIC=0-23 and AS2
RK=5/6/CIC=32-54.

AS1 sends a maintenance oriented CGB
message for CIC=21-42 and expects an
identical range in CGBA.

It might happen that CIC=39 is either
unequipped or not under the control of
ISUP at the remote switch.

How does your SG get the correct messages
(possibly CGBA) back to AS1?

--brian

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Sat, 4 Jan 2003 07:18:29 -0700

Tolga,

> (serving a CIC range) goes inactive, SG declares user

If you block the circuits, what happens when
a test call (IAM) is received for one of the
circuits which has no active AS?

--brian

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Sat, 4 Jan 2003 07:26:14 -0700

Tolga,

Brian F. G. Bidulock wrote:                                                          (Sat, 04 Jan 2003 07:18:29)
> circuits which has no active AS?

The SG must not block unallocated circuits
within the CIC range.

How does the SG know when circuits have
been deallocated (no longer under ISUP
control)?

--brian

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Sat, 4 Jan 2003 07:28:30 -0700

Tolga,

> circuits which has no active AS?

When an AS is down, how does your SG respond to
circuit query messages?

--brian

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Sat, 4 Jan 2003 07:32:19 -0700

Tolga,

> (serving a CIC range) goes inactive, SG declares user

Does the SG deactivate the other AS?

Must all the AS either be active or inactive together?

How are the AS brought active in the first place?  Must
they all be activated at the same time?

--brian

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Sat, 4 Jan 2003 07:35:58 -0700

Tolga,

How does your SG handle circuit group messages that have
ANSI pre-arranged circuit groups?  (These are circuit
group messages that have one CIC in the label and a range
of zero, where the actual members of the group are
configured at the receiving switch.)  How does your SG
know which circuits are in the pre-arranged group?

--brian

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Sat, 4 Jan 2003 07:41:40 -0700

Tolga,

When a circuit within an existing
CIC-range is taken out of service
(permanently and no longer under the
control of ISUP), how does your SG know
that this has happened?

--brian

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Sat, 4 Jan 2003 07:45:20 -0700

Tolga,

> circuits which has no active AS?

What happens if you get a CCR for one of these
circuits?

--brian

---

From: Tolga Asveren <[email-masked]>
Date: Sat, 4 Jan 2003 08:20:13 -0800 (PST)

Brian,
[... a lot of snipping here...]
> so all of them have a problem.
[TOLGA] I will not try to answer your list of ISUP
related questions, they might be problems which might
be solved or not and I am not planning to implement it
now and I believe here we are discussing what
implications it might have on M3UA itself. Your
questions are related with the part outside of the
scope of M3UA. The key point is that you think SG only
as MTP3 and M3UA. This is not my view. It has a big
fat NIF inside. And I can also put whatever I want
there, as long as it can interoperate with M3UA
compliant ASPs. So, in fact there is no point to
discuss this, your ASP even won't feel it(if it feels
then of course you can complain). You say let the
people experiment outside of the protocol, this is
also what I am saying. As long as necessary logic is
kept only in SG and existing M3UA protocol is used,
there is no problem from M3UA point of view. So,
please keep it as it is, no restriction on RKs for
static case (especially SSN based for class0/class1
seems implementable to me for now, but this is besides
the point, easy or difficult, it is outside of M3UA
protocol itself and is a problem for persons, which
want to implement it)

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Sat, 4 Jan 2003 09:40:16 -0700

Tolga,

Tolga Asveren wrote:                                                                 (Sat, 04 Jan 2003 08:20:13)
> protocol itself and is a problem for persons, which

I'm afraid you will have to answer the AS state related
questions if you wish to maintain the position that
M3UA "supports" CIC routing keys.

The list of questions serve to illustrate the many ways
in which CIC routing keys break interoperability.

Also, here is another:

The ASP is under no requirement to send the ack messages
to the same SG from which it received the blocking message.

How does your message splitting algorithm work when
multiple SG's are involved?

--brian

---

From: Tolga Asveren <[email-masked]>
Date: Sat, 4 Jan 2003 08:59:58 -0800 (PST)

Brian,
wrote:
> Tolga Asveren wrote:                                
>                                 (Sat, 04 Jan 2003
> 08:20:13)
[TOLGA] Answer for all of your AS related questions
is, if one wants to support CIC based RK with M3UA,
then they should comply with what it stands in M3UA,
so whatever they do, they shouldn't violate RFC/IG,
i.e. AS related procedures there. And also I believe
it is left to the implementors, which types of RKs
they want to "support", as long as they are compliant
with M3UA.  
> in which CIC routing keys break interoperability.
[TOLGA] Your questions are related with ISUP. If one
tries to solve them by putting additional requirements
on M3UA itself, then this would break the
interoperability.
> multiple SG's are involved?
[TOLGA[ Do you think multiple SG case is handled
properly even for DPC+SI based RKs? So the answer
would be, only connection to one SG is supported (well
I couldn't stop myself and answered, because multiple
SG with ASP/SGP scenario is not my favorite model)

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Sat, 4 Jan 2003 10:25:24 -0700

Tolga,

Tolga Asveren wrote:                                                                 (Sat, 04 Jan 2003 08:59:58)
> they want to "support", as long as they are compliant

So I take it you can't figure out how any of these
would work.  As there is no basis for interoperability,
(not even one way that things can work), it is certainly
not supported by M3UA.

> on M3UA itself, then this would break the

And that is why M3UA does not support CIC Routing Keys,
because, solving the problems it creates would break
interoperability.

> properly even for DPC+SI based RKs?

Yes.

> So the answer would be, only connection to one SG is
> supported (well I couldn't stop myself and answered,
> because multiple SG with ASP/SGP scenario is not my
> favorite model)

So where in the RFC does it say that only one SG can
be supported for CIC Routing Keys?

Now how about multiple SGP in the same SG?  Because
certainly the ack might go back to a different SGP
that the one which split the group message.

So, are CIC Routing Keys only supported on a single SG
made up of a single SGP?

And you never answered the question of the AS sending
the circuit group message spanning Routing Contexts to
the SG.  The SG cannot split these, how, is it to get
the (correct) response back to the correct place?

Also, you didn't say how your splitting algorithm is
going to split pre-arranged circuit group messages...

--brian

---

From: Tolga Asveren <[email-masked]>
Date: Sat, 4 Jan 2003 12:04:16 -0800 (PST)

Brian,
wrote:
> 08:59:58)
> > >                                 (Sat, 04 Jan
> 2003
> > > > related questions, they might be problems
> which
> > > might
> > > > scope of M3UA. The key point is that you think
> SG
> > > only
> > > > as MTP3 and M3UA. This is not my view. It has
> a
> > > big
> > > > discuss this, your ASP even won't feel it(if
> it
> > > feels
> > > > also what I am saying. As long as necessary
> logic
> > > is
[TOLGA] You can think whatever you want but I don't
want to dig in into ISUP specs to discuss some
implementation dependent ISUP management
functionality.The key point is that any necessary
management functionality to be implemented to support
different RKs is not part of M3UA protocol (and you
keep asking me about this implementation dependent
logic, which I am not interested in)
> 
> > > 
> > > The list of questions serve to illustrate the
> many
> > > ways
[TOLGA] Even the question whether M3UA does support
CIC based RKs or not is absurd IMO. How M3UA works is
clear. That you (or I) can't solve some
implelementation dependent problems does not proove
nobody else can do it(if you say it is not suitanle in
your opinion this is a different story). But of
course, if you like for each and every possible
protocol you can do some anlysis and say your opinion
whether M3UA is suitable for RKs based on constructs
of those protocols or not.
> > > to the same SG from which it received the
> blocking
> > > message.
> > > 
[TOLGA] If it is configured as different AS, then I
wouldn't expect this to happen (sorry I again answered
one non-M3UA related question)

---

From: Tolga Asveren <[email-masked]>
Date: Sat, 4 Jan 2003 12:13:03 -0800 (PST)

Brian,
> > properly even for DPC+SI based RKs?
Let's consider the following scenario:

 AS1:1-1-1 ISUP     AS2:1-1-1 SCCP
 +------+           +------+
 |ASP1  |           |ASP2  |
 |      |           |      |
 +-+-+--+           +----+++
   | |                   ||
   | +----------X------+ ||
   |                   | ||
   |  +----------------+-+|
 +-+--+-+           +--+--++
 | SG1  |           | SG2  |
 |      |           |      |
 +---+--+           +---+--+
     |                  |
     |                  |
     |                  |

Messages coming dor ISUP 1-1-1 to SG2 are replied with
UPU whereas the ones arriving to SG1 are routed to
ASP1.
Is it ever possible on TDM based SS7 that this
happens?The problem is, there can be only one layer3
for one entity (migth be distributed on different
hosts if they are synchronized) but in this scenario
each layer3 for 1-1-1 on SG1 and SG2 are acting
independently.

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Sat, 4 Jan 2003 13:22:06 -0700

Tolga,

Tolga Asveren wrote:                            (Sat, 04 Jan 2003 12:04:16)
> [TOLGA] You can think whatever you want
> but I don't want to dig in into ISUP
> specs to discuss some implementation
> dependent ISUP management
> functionality.The key point is that any
> necessary management functionality to be
> implemented to support different RKs is
> not part of M3UA protocol (and you keep
> asking me about this implementation
> dependent logic, which I am not
> interested in)

Then why did you say that the SG could
split up CGB messages?  This is an ISUP
procedure.  Did you not consult the ISUP
specs when you recommended this approach?
Do you agree now that the approach that
you proposed is flawed?

> [TOLGA] Even the question whether M3UA
> does support CIC based RKs or not is
> absurd IMO. How M3UA works is clear.
> That you (or I) can't solve some
> implelementation dependent problems does
> not proove nobody else can do it(if you
> say it is not suitanle in your opinion
> this is a different story). But of
> course, if you like for each and every
> possible protocol you can do some
> anlysis and say your opinion whether
> M3UA is suitable for RKs based on
> constructs of those protocols or not.

It is quite clear to me that routing keys
based on MTP Level 3 information is the
only routing key that M3UA can support.
When you use a routing key such as SSN or
CIC and accept the boundary violation of
an MTP3 layer examining upper layer PDUs,
you must address the interworking of the
upper layer peers to show that
interoperability exists.

Now if you say that CIC Routing Keys are
implementation dependent, then why are
they right there in the Routing Key?
Nowhere in the RFC does it say that the
use of CIC Routing Keys is implementation
dependent, yet the RFC has no support for
them.

I propose that CIC be removed from the
Routing Key.

> > So where in the RFC does it say that
> > only one SG can be supported for CIC
> > Routing Keys?
> > 
> > Now how about multiple SGP in the same
> > SG?  Because certainly the ack might
> > go back to a different SGP that the
> > one which split the group message.
> > 
> > So, are CIC Routing Keys only
> > supported on a single SG made up of a
> > single SGP?
> > 
> > And you never answered the question of
> > the AS sending the circuit group
> > message spanning Routing Contexts to
> > the SG.  The SG cannot split these,
> > how, is it to get the (correct)
> > response back to the correct place?
> [TOLGA] If it is configured as different
> AS, then I wouldn't expect this to
> happen (sorry I again answered one
> non-M3UA related question)

You call this a non-M3UA related question
an yet you say that M3UA has support for
CIC Routing Keys and propose that M3UA NIF
split up CGB messages?  You started the
boundary violation: admit that M3UA cannot
support CIC Routing Keys, particularly in
the fashion that you proposed.

--brian

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Sat, 4 Jan 2003 13:29:11 -0700

Tolga,

Tolga Asveren wrote:                                                                 (Sat, 04 Jan 2003 12:13:03)
> Brian,
> > > [TOLGA[ Do you think multiple SG
> > > case is handled properly even for
> > > DPC+SI based RKs?
> > 
> > Yes.
> Messages coming dor ISUP 1-1-1 to SG2
> are replied with UPU whereas the ones
> arriving to SG1 are routed to ASP1.
>
> Is it ever possible on TDM based SS7
> that this happens?

No, in SS7 it cannot happen.

> The problem is, there can be only one
> layer3 for one entity (migth be
> distributed on different hosts if they
> are synchronized) but in this scenario
> each layer3 for 1-1-1 on SG1 and SG2 are
> acting independently.

Put C-Links between SG1 and SG2 and then
SG2 can route ISUP messages over C-Links
and perform transfer-restricted procedures
towards the network.

But if you break ISUP into CIC ranges you
cannot solve the problem with C-Links
because MTP3 cannot route on CIC.

--brian

---

From: Tolga Asveren <[email-masked]>
Date: Sat, 4 Jan 2003 12:34:36 -0800 (PST)

Brian,
> Tolga Asveren wrote:                           
> (Sat, 04 Jan 2003 12:04:16)
[TOLGA] I don't have any problem by agreeing with this
(till the concerns you raised are addressed). But if
it is said that it would bring interoperability
problems,  I don't agree. The problems are related
with an entity outside of M3UA itself.
> upper layer peers to show that
[TOLGA] For that I agree. Any RK based on non-MTP3
contructs will result in implementing necessary
management functionality.
> I propose that CIC be removed from the
[TOLGA] Again for that I tend to agree. Either also
include SSN again or don't include both of them.
Although again one can argue it is difficult(or even
maybe impossible) to support such RK types, SGP can
reply with an error message. But then somebody might
ask also for other RKs based on constructs of other
protocols.
> the fashion that you proposed.
[TOLGA] What I am saying is that even the concept of
M3UA supporting CIC based (or based on a construct of
another upper layer) RKs does not sound very logical
to me. Anyhting related with those RKs is to be
implemented -if possible- outside of M3UA protocol and
IMO is totally implementation dependent.

---

From: Tolga Asveren <[email-masked]>
Date: Sat, 4 Jan 2003 12:38:20 -0800 (PST)

Brian,
> 12:13:03)
[TOLGA] But MTP3 does not route based on user parts
either. A destination PC is either reachable or not.
And in this scenario it 1-1-1 is reachable from SG2.

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Sat, 4 Jan 2003 14:24:36 -0700

Tolga,

Tolga Asveren wrote:                                                                 (Sat, 04 Jan 2003 12:34:36)
> with an entity outside of M3UA itself.

What entity outside of M3UA?  It is your M3UA that is
mucking with the CGB messages instead of passing them
on.  If you M3UA doesn't much with the messages (or
try to route on information not contained in the MTP3
header) there is never a problem.

> management functionality.

And unless specified will not be operable and so
there is no reaons to route on CIC in M3UA spec.

> ask also for other RKs based on constructs of other

Removing it would keep people from chasing wild geese
and confusing them into thinking that M3UA was designed
to support this kind of routing.

> IMO is totally implementation dependent.

Totally implementation depedent => non-standard
=> not supported by M3UA => remove it from M3UA spec.

--brian

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Sat, 4 Jan 2003 14:30:03 -0700

Tolga,

Tolga Asveren wrote:               (Sat, 04 Jan 2003 12:38:20)
> And in this scenario it 1-1-1 is reachable from SG2. 

See SCCP alias point codes in MTP (ANSI
T1.111.4/2000).  MTP routes across C-Links
on the basis of the inaccessibility of a
local MTP-User (SCCP) precisely as I
described (including provision for
transfer-restricted procedures as well).

--brian

---

From: Tolga Asveren <[email-masked]>
Date: Sat, 4 Jan 2003 14:20:12 -0800 (PST)

Brian,
> transfer-restricted procedures as well).
[TOLGA] So, only alias point code configurations are
supported? What about ITU networks? What about the
case, where ISUP is also inaccessible from SG1, are we
going to keep hop counters to prevent ping-pong
scenarios?
To me, it is obvious that this is a problem scenario
and it is not a suprise: there are two MTP3 logic for
1-1-1 which are working independently.

---

From: Tolga Asveren <[email-masked]>
Date: Sat, 4 Jan 2003 14:25:39 -0800 (PST)

Brian,
> header) there is never a problem.
[TOLGA] Any management functionality necessary to
support non-MTP3 based RKs shoul dbe done in NIF, i.e.
it is not in M3UA.
> there is no reaons to route on CIC in M3UA spec.
[TOLGA] I disagree. If it does not require any change
to M3UA and does not expect some special behavior from
peers, it is not a problem.
> => not supported by M3UA => remove it from M3UA
[TOLGA] Implementation dependent does not mean not
supported by M3UA. NIF is implementation dependent, so
does it mean to have NIF is violating M3UA?

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Sat, 4 Jan 2003 17:47:25 -0700

Tolga,

Tolga Asveren wrote:                                                                 (Sat, 04 Jan 2003 14:20:12)
> [TOLGA] So, only alias point code
> configurations are supported? What
> about ITU networks? What about the
> case, where ISUP is also inaccessible
> from SG1, are we going to keep hop
> counters to prevent ping-pong
> scenarios?

Hop counters?  Ridiculous: you should
know that the transfer-prohibited
procedure prevents the other STP from
routing back.  An STP never sends
traffic to its mate without first
sending transfer-prohibited to the mate
with regard to the same traffic.

> To me, it is obvious that this is a
> problem scenario and it is not a
> suprise: there are two MTP3 logic for

Don't worry, those that know how to
build STPs also know how to do this
correctly.  Where do you thing alias
point code came from?

--brian

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Sat, 4 Jan 2003 18:04:46 -0700

Tolga,

Tolga Asveren wrote:                                                                 (Sat, 04 Jan 2003 14:25:39)
> [TOLGA] Any management functionality
> necessary to support non-MTP3 based RKs
> shoul dbe done in NIF, i.e.  it is not
> in M3UA.

Just because the NIF was left
implementation dependent does not mean
that you can jam anything you like in
there (like half an ISUP stack).  The NIF
was left implementation dependent to
permit implementors the leeway necessary
to meet SS7 MTP requirements.  Read the
RFC again, particularly the opening
passages.  The NIF adapts an
implementation specific MTP/MTP-User
interface to M3UA so that M3UA at the SG
can transport it to the ASP.  It isn't the
dumping ground for all manner of boundary
violation junk.  The obligation is on the
SG implementor to meet SS7 requirements
(and that includes not breaking ISUP while
they are at it).

But such broken implementations are
unlikely to ever be connected to a real
SS7 network anyway (even if they do, not
for long before they are fork lifted out
the window to the trash bins from the 4th
floor).

> [TOLGA] I disagree. If it does not
> require any change to M3UA and does not
> expect some special behavior from peers,
> it is not a problem.

You did not answer the question how the AS
gets the response to its CGB to the
correct place.  This will take the
cooperation of the ASP which requires
interoperability.  If you still think that
the ASP need do nothing special, answer
the questions. ;)

> > > to me. Anyhting related with those
> > > RKs is to be implemented -if
> > > possible- outside of M3UA protocol
> > > and IMO is totally implementation
> > > dependent.
> > 
> > Totally implementation depedent =>
> > non-standard => not supported by M3UA
> > => remove it from M3UA spec.
> [TOLGA] Implementation dependent does
> not mean not supported by M3UA. NIF is
> implementation dependent, so does it
> mean to have NIF is violating M3UA?

NIF is not "totally" implementation
dependent.  Requirements are placed on the
NIF by the M3UA RFC.  What you propose to
place in it is, as you say, "totally"
implementation dependent and, as such, has
no basis for interoperability.  Something
which is completely unstandardized,
doesn't have a single documented workable
solution, doesn't even have a glint of a
change of being interoperable.

--brian

---

From: Tolga Asveren <[email-masked]>
Date: Sun, 5 Jan 2003 03:59:18 -0800 (PST)

Brian,
wrote:
> 14:20:12)
[TOLGA] For the case where ISUP is inaccessible from
both of the SGs but SCCP is accessible (the case I am
referring to), will they send TFP to each other?  
Does MTP route also for ISUP based on accessibility
status for the user part? Also for ITU?
> correctly.  Where do you thing alias
[TOLGA]Is this stated somewhere in the RFC/IG? For
some other minor things, clarifications are added. 
IMO, from architecture point of view this is still a
problem scenario.

---

From: Tolga Asveren <[email-masked]>
Date: Sun, 5 Jan 2003 04:10:25 -0800 (PST)

Brian,

Last message of this thread from my point of view
because I think I already expressed my opinions (some
of them several times) and I don't want to thrash the
list.
Comments are inline below.

wrote:
> 14:25:39)
[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. 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.
> change of being interoperable.
[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.

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Sun, 5 Jan 2003 05:38:55 -0700

Tolga,

Tolga Asveren wrote:                                                                 (Sun, 05 Jan 2003 03:59:18)
> referring to), will they send TFP to each other?  

Yes.  When one SG receives TFP from the other
with respect to the 1-1-1 point code, it can combine
the inaccessibility of ISUP with the TFP to send UPU
for ISUP and send TFP to its mate.  If one of the SGs
should then lose SCCP, it can send TFP to the network
and the network will reroute to the alternate SG if
it still has access to SCCP.

> status for the user part? Also for ITU?

There is nothing in ITU specs that preclude this (or
the Alias Point Code) behavior.

Besides, this is what you argued for on the DUPU threads.

--brian

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Sun, 5 Jan 2003 06:11:54 -0700

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: Tolga Asveren <[email-masked]>
Date: Sun, 5 Jan 2003 05:55:34 -0800 (PST)

Brian,
wrote:
>                                 (Sun, 05 Jan 2003
> 03:59:18)
[TOLGA] I think I failed to explain what I mean:
  1-1-1 ISUP              1-1-1 SCCP
    +-------+             +-------+
    |ASP1   |             |ASP2   |
    |       |             |       |
    ++-+----+             +--+---++
     | |                     |   |
     | | +--------X----------+   X
     | | |                       |
     | +-+---------------------+ |
    ++---+--+             +----+-++
    |  SG1  |             |  SG2  |
    |       +-------------+       |
    +---+---+             +----+--+
        |                      |
Now when SCCP becomes unavailable, will SG1 send UPU
to SG2? In such a case they should keep reachability
info per user part for their peers, with which they
have alias point code relationship unless number of
such nodes are restricted to two (probably this is the
case with alias point codes (?) )
But is there a restriction in M3UA restricting number
of SGs for DPC+SI based RKs to 2? 
> the Alias Point Code) behavior.
[TOLGA] So, it is not defined(?) and routing is based
only on PC.
> Besides, this is what you argued for on the DUPU
[TOLGA] No. My position for DUPU from ASP to SGP is,
it is not necessary because this is a MTP3/MTP3-User
interface and if one wants User Part granularity, the
way to achieve this is defining AS per user part.

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Sun, 5 Jan 2003 08:32:40 -0700

Tolga,

Tolga Asveren wrote:                                                                 (Sun, 05 Jan 2003 05:55:34)
> Now when SCCP becomes unavailable, will
> SG1 send UPU to SG2? In such a case they
> should keep reachability info per user
> part for their peers, with which they
> have alias point code relationship
> unless number of such nodes are
> restricted to two (probably this is the
> case with alias point codes (?) ) But is
> there a restriction in M3UA restricting
> number of SGs for DPC+SI based RKs to 2? 

When SCCP becomes unavailable at SG1, SG1
sends TFP to SG2 for 1-1-1 and sends SCCP
traffic to SG2.  It could still process
ISUP traffic locally.

Why does not ASP1 also support SCCP?  Or
at least why does it not pass traffic to
ASP2?  ISUP and SCCP have to work together
closely in a switch (single point code)
and it is inconceivable that they are so
separated that they are not in the same
room.

Do you have a real world example where one
would want to separate ISUP and SCCP like
this on the same point code?

--brian

---

From: Tolga Asveren <[email-masked]>
Date: Sun, 5 Jan 2003 07:41:31 -0800 (PST)

Brian,
wrote:
> 05:55:34)
[TOLGA] Why does SG1 send TFP for 1-1-1 in such a
case? ISUP is still available. IMO, 1-1-1 is still
available -all traffic is handled locally- or 1-1-1 is
not available -all traffic for 1-1-1 is routed to SG2-
from MTP3 of SG1 point of view.
> this on the same point code?
[TOLGA]The point is, whether such a configuration is
properly supported or not with the current ASP/SGP
architecture. IMO, it is not supported (I also don't
see the need to support it with ASP/SGP model).

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Sun, 5 Jan 2003 08:57:51 -0700

Tolga,

Tolga Asveren wrote:                                                                 (Sun, 05 Jan 2003 07:41:31)
> see the need to support it with ASP/SGP model).

It is not a realistic example.  We
discussed this at great lenth under "SGP
partitioning" as well.  Just relabel SG1
and SG2 as SGP1 and SGP2 and break the
connection between SGP1 and SGP2.  It is
the same situation.

   1-1-1 ISUP              1-1-1 SCCP
     +-------+             +-------+
     |ASP1   |             |ASP2   |
     |       |             |       |
     ++-+----+             +--+---++
      | |                     |   |
     | SGP1  |             | SGP2  |
     |       +-----X-------+       |
     +---+---+             +----+--+
         |                      |

At some point the ASP configuration is so
poorly engineered that the SGP has to take
down the entire point code to the network
due to partial failures.

A real-world arrangement would be as
follows:

   1-1-1 ISUP              1-1-1 ISUP
   1-1-1 SCCP              1-1-1 SCCP
     +-------+             +-------+
     |ASP1   |             |ASP2   |
     |       |             |       |
     ++-+----+             +--+---++
      | |                     |   |
      | | +--------X----------+   X
      | | |                       |
      | +-+--------X------------+ |
     ++---+--+             +----+-++
     | SGP1  |             | SGP2  |
     |or SG1 +-----X-------+or SG2 |
     +---+---+             +----+--+
         |                      |

In which case there is no problem.  It is
correctly engineered and the last
communication link has to fail before any
traffic will be lost.

--brian

---

From: Tolga Asveren <[email-masked]>
Date: Sun, 5 Jan 2003 08:14:48 -0800 (PST)

Brian,
wrote:
> 07:41:31)
> > >                                 (Sun, 05 Jan
[TOLGA] So, you propose the above configuration as
solution. Fine, no problem. So, the configuration I
presented is not supported properly with ASP/SGP
model. BTW, even for your configuration, what will
happen if one AS is not ACTIVE? So, should SGP wait
for all AS of the same SPMC to be ACTIVE? The source
of the problem is clear: to have two separate MTP3
logic for the same PC, working independently, which
IMO is not very correct from architecture point of
view. Mines was just an example to show this, and as I
said, I think M3UA should not try to support such a
configuration with ASP/SGP model.
Maybe not exactly the topic of this discussion, but I
have one comment about the scenario, where you
replaced SGs with SGPs. Once the syncronization
between MTP3 of SGPs is broken, I wouldn't consider SG
as operational.Afterall it is the single MTP3 entity,
which makes them to be called SGPs of the same SG.

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Sun, 5 Jan 2003 09:50:38 -0700

Tolga,

Tolga Asveren wrote:                                                                 (Sun, 05 Jan 2003 08:14:48)
> [TOLGA] So, you propose the above
> configuration as solution. Fine, no
> problem. So, the configuration I
> presented is not supported properly with
> ASP/SGP model.

No, the configuration you presented is
just more brittle.  When part of it
breaks, it all breaks.  There is nothing
stopping the SG from saying that because
one AS is down, that the whole SPMC is
down.  It is even permitted to send ASPIA
Ack and ASPDN Ack under partial or
complete failure scenarios.  If you
want more reliability than that, design
your configuration better.

> BTW, even for your
> configuration, what will happen if one
> AS is not ACTIVE? So, should SGP wait
> for all AS of the same SPMC to be
> ACTIVE?

Sure, why not?  It is up the SG to
determine when the SPMC is active or not.
In the SG case, SG1 does not send TFA
until both ISUP and SCCP are up.  It can
also withold MTP-RESUME from the ASP until
both users are active.

> The source of the problem is clear: to
> have two separate MTP3 logic for the
> same PC, working independently, which
> IMO is not very correct from
> architecture point of view.

It makes perfect architectural sense.
That's how SS7 works.  Almost all SS7
nodes today distribute MTP over multiple
processors. It is just foolish to split
between users.

> Mines was just an example to show this,
> and as I said, I think M3UA should not
> try to support such a configuration with
> ASP/SGP model.

It supports it.  You just get different
failure response in different situations,
none of which has to violate any M3UA
or SS7 network requirements.

> Maybe not exactly the topic of this
> discussion, but I have one comment about
> the scenario, where you replaced SGs
> with SGPs. Once the syncronization
> between MTP3 of SGPs is broken, I
> wouldn't consider SG as operational.
> Afterall it is the single MTP3 entity,

Modern SS7 nodes can suffer partitioning
and function quite well.

--brian

---

From: Tolga Asveren <[email-masked]>
Date: Sun, 5 Jan 2003 09:03:22 -0800 (PST)

Brian,
[...snip.....]
>processors. It is just foolish to split
[TOLGA] The problem is not to use multiple
processors/hosts, but not to synchronize them and make
them work as a separate entities, which is the case
whith multiple SG configurations.

[...snip...]
>Modern SS7 nodes can suffer partitioning
[TOLGA] It is not logical to think multiple SGPs with
separate MTP3 logic as parts of the same SG.

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Sun, 5 Jan 2003 10:18:56 -0700

Tolga,

Tolga Asveren wrote:                                                                 (Sun, 05 Jan 2003 09:03:22)
> Brian,
> [...snip.....]
> >> The source of the problem is clear:
> >> to have two separate MTP3 logic for
> >> the same PC, working independently,
> >> which IMO is not very correct from
> >nodes today distribute MTP over
> >multiple processors. It is just
> >foolish to split between users.
> [TOLGA] The problem is not to use
> multiple processors/hosts, but not to
> synchronize them and make them work as
> a separate entities, which is the case

Multiple SG as STP is a natural
architectural component of SS7: it is
the associated pair of STPs.

> >> discussion, but I have one comment
> >> about the scenario, where you
> >> replaced SGs with SGPs. Once the
> >> syncronization between MTP3 of SGPs
> >> is broken, I wouldn't consider SG
> >> as operational.  Afterall it is the
> >> single MTP3 entity, which makes
> >> them to be called SGPs of the same
> >> SG.
> >
> >Modern SS7 nodes can suffer
> >partitioning and function quite well.
> [TOLGA] It is not logical to think
> multiple SGPs with separate MTP3 logic
> as parts of the same SG. 

Yes, they are part of the same SG, the
SG just happes to be temporariliy
"partitioned".

--brian

---

From: Tolga Asveren <[email-masked]>
Date: Sun, 5 Jan 2003 09:48:08 -0800 (PST)

Brian,
wrote:
> 09:03:22)
[TOLGA] Problem is not the local MTP3 of SG itself (it
has different PC and so a different entity for each SG
anyway) The problem is because of the MTP3 logic
running on behalf of the AS on SGs. With multiple SGs,
one has separate MTP3 entities for the same PC, if
those SGs control the same SPMC.

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Sun, 5 Jan 2003 11:53:45 -0700

Tolga,

Tolga Asveren wrote:                                                                 (Sun, 05 Jan 2003 09:48:08)
> those SGs control the same SPMC.

There is no problem because the SS7 network has a
independent view of the accessibility of the SPMC
via each SG acting as an STP.  So the view each SG
presents is independent anyway.

--brian

---

From: Tolga Asveren <[email-masked]>
Date: Sun, 5 Jan 2003 11:47:04 -0800 (PST)

Brian,
wrote:
> 09:48:08)
[TOLGA] Accessibility/inaccessibility/restriction of
the SPMC is announced to the network by the local MTP3
of SG. For them, there is no problem. Problem is for
user part unavailability, because it is decided by the
MTP3 logic running for SPMC on SG. When those two
MTP3s -which in fact have the same PC- have different
views for user part availability problem happens.

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Sun, 5 Jan 2003 19:38:35 -0700

Tolga,

Tolga Asveren wrote:                                                                 (Sun, 05 Jan 2003 11:47:04)
> views for user part availability problem happens.

So when you configure things with insufficient redundancy
the SG is sometimes forced to place the entire SPMC in
the inaccessible state.  So what?  Don't build things
that way and you won't have a problem.

--brian

---

From: "Valerie Gastaud" <[email-masked]>
Date: Mon, 6 Jan 2003 10:46:25 +0100

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)

Section 3.3.1:

Section 3.3.1:

Section 3.3.1:

Section 1.5.1

Section 4.1.1:

Section 5.4.2.1:

Who is "they?"

--brian