Subject: Consensus call (was: IPSP-IPSP summary)

From: [email-masked]
Date: Tue, 6 Nov 2001 12:49:35 +0200

Hi All,

> Perhaps we must take better care of defining our RKs, in 
> either direction.

I believe that handling RKs is an issue for the UA applicability
statement.  What we want to ensure is that the basic protocol
will work.

In my opinion, this thread has gotten very torturous and
is going nowhere.

I think clean proposals for the Single Ended approach and
for the Double Ended approach would be good, then we 
could take a vote or something to establish consensus.

best regards,
John

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

---

From: Verwimp Gery <[email-masked]>
Date: Tue, 6 Nov 2001 11:52:48 +0100

John,

I had a summary in my last mail, without sending new definitions (SE-DE)
into the world. Any comments on my proposal ?

____________________________

Gery Verwimp
> SIEMENS ATEA
> ICN D CS D5
> Tel. : +32 14 25 3424
Fax : +32 14 25 3212
mailto:[email-masked]
____________________________________

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: dinsdag 6 november 2001 11:50
To: sigtran
Subject: Consensus call (was: IPSP-IPSP summary)

Hi All,

best regards,
John

---
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: Tue, 6 Nov 2001 05:06:51 -0600

John,

Could we start by limiting the IPSP case to SEP-to-SEP
point-to-point communications without transfer/relay
function in the IP domain?

Transfer/relay function in the IP domain is the stuff of
extension drafts both for M3UA and SUA.

Within these limits, a cluster of IPSPs represent a
single SPMC (PC with aliases) for both M3UA and SUA
and management more granular than SNMM is not necessary.

This serves to not expose the AS (MTP-User/SCCP-User)
to the network.  The IPSP is responsible for MTP/SCCP
routing functions as would any SS7 SEP.  ASPSM/TM is
for the management of IPSPs within a cluster and traffic
distribution over the cluster.  RC values are not
required for sub-PC RKs, but may be used to represent
the entire SPMC only (and are implicit to an association).

There is no need for distributing MTP-Users/SCCP-Users
around the network in an arbitrary fashion.  SS7 does
not do this and there is no need for IPSP to do this
either.

In this case RC is not required in ASPAC/IA as it is
implicit to the association.  Then the existing UA
procedures (a single exchange) will suffice.

--brian

John Loughney wrote:                     (Tue, 06 Nov 2001 12:49:35)
> You are currently subscribed to sigtran as: [email-masked]

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

---

---

From: "Javier Pastor-Balbas (ECE)" <[email-masked]>
Date: Tue, 6 Nov 2001 12:19:42 +0100

Brian, 

It would be nice that you send a summary of your proposal, so that folks can vote.

We are always talking of ASP-ASP communication and never about transfer/relay in IP. I think that was clear from the beginning.

But since an ASP can serves more that one AS. You need RC to differenciate those traffics over the same association. Therefore you need to send along with DATA the RC associated with the destination AS.

Cheers // Javier.

> From: Brian F. G. Bidulock [mailto:[email-masked]]
> Sent: Tuesday, November 06, 2001 12:07 PM
> To: sigtran
> Cc: [email-masked]
> Subject: Re: Consensus call (was: IPSP-IPSP summary)
> 
> 
> John,
> 
> You are currently subscribed to sigtran as: 
> [email-masked]

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 6 Nov 2001 05:38:27 -0600

Javier,

Javier Pastor-Balbas (ECE) wrote:                          (Tue, 06 Nov 2001 12:19:42)
> We are always talking of ASP-ASP communication and never about
> transfer/relay in IP. I think that was clear from the beginning.
> 
> But since an ASP can serves more that one AS. You need RC to differenciate
> those traffics over the same association. Therefore you need to send along
> with DATA the RC associated with the destination AS.

SS7 SEPs serve more than one AS (User) without ever needing RCs.
AS is a concept only of the backhaul case, where users are arbitrarily
distributed over ASPs behind SGs.  The SIGTRAN framework document
shows this quite nicely: the peer-to-peer case is depicted only as
SG to SG communication.  If you want to distribute AS, use AS/SG
relationship on the back-end between the AS and IPSP.  The IPSP
acts solely as an SG but on a peer-to-peer basis between SGs in
the IP domain per the SIGTRAN architecture.  The error is in trying
to model IPSP as ASPs when their function is only that of an SG.

--brian

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

---

---

From: "Javier Pastor-Balbas (ECE)" <[email-masked]>
Date: Tue, 6 Nov 2001 12:46:53 +0100

Brian, 

Then I think I start seeing your point  :-) . You are talking about SG-SG communication. This was left for an extension draft. Maybe your proposal is good for that scenario. I'd have to study it a little bit further. But not now.

What SUA and M3UA are trying to get right now is to addapt the M3UA draft, with the same concepts and procedures, to the ASP-ASP communication.

Cheers // Javier.

> Sent: Tuesday, November 06, 2001 12:38 PM
> To: Javier Pastor-Balbas (ECE)
> Cc: sigtran
> > It would be nice that you send a summary of your proposal, 
> so that folks can
> > vote.
> > 

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 6 Nov 2001 06:01:36 -0600

Javier,

Javier Pastor-Balbas (ECE) wrote:                          (Tue, 06 Nov 2001 12:46:53)
> Brian, 
> 
> Then I think I start seeing your point  :-) . You are talking about SG-SG
> communication. This was left for an extension draft. Maybe your proposal is
> good for that scenario. I'd have to study it a little bit further. But not
> now.

SG-SG communication was not left for an extension draft.  Transfer/relay
function was left for an extension draft.  SG does not have to be STP.

> 
> What SUA and M3UA are trying to get right now is to addapt the M3UA draft,
> with the same concepts and procedures, to the ASP-ASP communication.

Doomed.  It does not follow the SIGTRAN architecture.  Exposing AS across
the network is as unnecessary in the IP domain as it is in the SS7 domain.

--brian

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

---

---

From: [email-masked]
Date: Tue, 6 Nov 2001 17:44:48 +0530

Brian

what do you mean by exposing AS across a network. If an AS is not
exposed across the network then how is an SGP supposed to route
the traffic.

---Vipin

"Brian F. G. Bidulock" <[email-masked]> on 11/06/2001 05:31:36 PM

Please respond to [email-masked]

To:   "sigtran" <[email-masked]>
cc:   [email-masked] (bcc: Vipin K Gupta/HSS)

Javier,

Javier Pastor-Balbas (ECE) wrote:                          (Tue, 06 Nov 2001
12:46:53)

--brian

--
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: Verwimp Gery <[email-masked]>
Date: Tue, 6 Nov 2001 13:16:26 +0100

Brian,

What SG-SG communication ? It doesn't send any REG or ASPAC, it just
acknowledges (the requests of the ASPs). In IPSP-case, each IPSP must
"advertise" itself (implicit or explicit with REG) and surely send ASPAC to
receive any traffic. For sending traffic, it needs REGs/APSACs from other
IPSPs. From this, each IPSP can build it's own view of what neighbour IPSPs
serve what kind of traffic; there's no need for a general, unique view of
"the AS" across the whole network (domain).

ASP-SG case is different in that only ASPs ever send REG or ASPAC; SGs only
acknowledge and it's clear what they stand for (SS7 interworking).

An IPSP cannot make such assumptions, unless you want to place IPSP1 in the
ASP-role, and IPSP2 in the SG-role. Are we going to reduce the general
IPSP-IPSP case to this ?

Gery Verwimp
Fax : +32 14 25 3212

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]]
Sent: dinsdag 6 november 2001 13:02
To: sigtran
Cc: [email-masked]
Subject: Re: Consensus call (was: IPSP-IPSP summary)

Javier,

--brian

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

---

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 6 Nov 2001 06:21:11 -0600

Vipin,

The SGP routes the traffic on the basis of the MTP/SCCP routing
rules in a point-to-point network.  For M3UA that means that
messages are routed on the basis of DPC.  A DPC exists at the
end of an association.  An association is selected on the basis
of the DPC in the message (and the RL format; i.e. NA).  RKs
are DPC only.  In point-to-point only a single SPMC exists at
the other end of an association.  When the assocation is available
(ASPAC without RC) and SNMM allows the PCs of the SPMC are available.
If the association is not available or SNMM does not allow, the
SPMC is unavailable.  No ASs.  The IPSP distributes to AS internally
just as any SS7 SEP does.

--brian

[email-masked] wrote:                                (Tue, 06 Nov 2001 17:44:48)

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

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 6 Nov 2001 06:29:00 -0600

Verwimp,

SS7 SEPs do not advertise themselves to the SS7 network.  Why must
an IPSP in point-to-point advertise itself?  It has a point code
and if there is an association to it SNMM does the rest.

RC is implicit.  REG REQ is unnecessary.  ASPAC does not need RC
and is only used to establish the traffic mode and activate the
association.

REG REQ is necessary only for backhaul case so that SGs can get
a view of the "availability" of its users (AS) and represent
that view to the SS7 network.  IPSP can represent any AS view
to another IPSP using SNMM in the same manner that SGs do
towards the SS7 network.  No RC is required to do this.  No
registration is necessary.

SS7 networks have statically configured routes.  There are no
route discovery protocols in SS7 (aside from testing).

If one SGP sends ASPAC so what?  Nobody thought of IPSP did they?

--brian

Verwimp Gery wrote:                                       (Tue, 06 Nov 2001 13:16:26)
> Fax: +32 14 25 3212

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

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 6 Nov 2001 07:24:22 -0600

Verwimp,

Verwimp Gery wrote:                                       (Tue, 06 Nov 2001 13:47:36)
> Brian,
> 
> Who says we have to take over the SS7 model ?

It is what we are transporting.  Who says we cannot?

> Are we going to use point codes in all-IP just as in SS7 ?

The view of the WG was yes.  See NA/RC discussion.

> Suppose that's one way to do it. But then why not throw
> ASPTM/SM away as well ?

Because ASPTM/SM also contains traffic modes (distribution).

> There's no need for it when
> everything's clear : either the SCTP association is up, congested or down
> ;)) Then you have SCTP associations instead of routes and everything is
> MTP3, including the management ... why not use M2PA only and get rid of the
> rest ?

You are seeing the light now...

> 
> IPSP/ASP differ from SG (as far as I understand it) in that SG is running no
> applications.

That is not true.  The draft specifically permits SG's to have other
local users (MTP-Users/SCCP-Users) and these users can be running
applications.  M3UA/SUA cannot tell the SS7 stack on the SG not to
have other users and not to run applications.

> It's just plain interworking (NIF and all that).

No, its, NIF (as a user), other local users (your GTT function doing
the coupling in SUA is an MTP-User that is local to the STP by the
way) and even the "Default ASP".

> So what does it need to register/go active for ?

It does not need to register.  I needs to go active so that both
sides agree that they can exchange data on the association and
so that MTP Restart procedures have a reference.  The presense of
and SCTP assocation is no assurance that the M3UA/SUA peers exist
and are ready to exchange data.

> If SG sends ASPAC, then gee, it's an ASP/IPSP after all ...
> why not as long as it knows what it's doing ?

No, it is an SG that is just sending an ASPAC to fake the other out.
In the earlier drafts, we permited SG to send not only the Ack side
of the mesage but messages such as ASPDN.  There is no hard and fast
rule that says if we allow an SG actiing as an IPSP to send an ASPAC
that suddenly it has become an ASP.

> Also, my proposal doesn't exclude the case where everything is clear from
> pre-configuration and just the single ASPAC-Ack exchange (no RC indicating
> "all") would be sufficient. Both in IPSP as in ASP-SG case.

Could you show when it is necessary to expose the AS to the network
in the IP domain?  There is no need for it that I can see.  After
all a point code is just a number.

--brian

> Sent: dinsdag 6 november 2001 13:29
> To: Verwimp Gery
> Cc: sigtran

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

---

---

From: Tolga Asveren <[email-masked]>
Date: Tue, 6 Nov 2001 05:47:31 -0800 (PST)

Brian,

Please see comments/questions below.

   Tolga

--- "Brian F. G. Bidulock" <[email-masked]>
> It is what we are transporting.  Who says we cannot?
[TOLGA] According to the draft an IPSP is "essentially
the same as an ASP, except that it uses M3UA in a
point to point fashion" It does not say that thi sis
SG-SG communication. Are you interpreting as the
endpoints of this communication signaling points? I
thought they should be ASs (or even maybe IPSPs)
Without deciding on the basics, it seems it is
impossible to come to a conclusion. I don't understand
why in case of AS/SGP distribution of a signaling
point to different nodes is acceptable and not in IPSP
case? If there is a need for it, it is applicable for
both of the cases, if not again for both of the cases.
What is the difference between them. Afterall, in both
of them, an AS is communciation with some other
entities. Why should the nature of peer change the
need to swtich from signaling point based entities to
AS based entities?
> M2PA only and get rid of the
[TOLGA] I agree with Gery, why not?
> > Verwimp Gery wrote:                               
>        (Tue, 06 Nov 2001
> > 13:16:26)
> > > "advertise" itself (implicit or explicit with
> REG) and surely send ASPAC
> > to
> > > IPSPs. From this, each IPSP can build it's own
> view of what neighbour
> > IPSPs
> > > ASP-SG case is different in that only ASPs ever
> send REG or ASPAC; SGs
> > only
> > > An IPSP cannot make such assumptions, unless you
> want to place IPSP1 in
> > the
=== message truncated ===

__________________________________________________
Do You Yahoo!?
Find a job, post your resume.
http://careers.yahoo.com

---

---

From: Verwimp Gery <[email-masked]>
Date: Tue, 6 Nov 2001 13:47:36 +0100

Brian,

Who says we have to take over the SS7 model ? Are we going to use point
codes in all-IP just as in SS7 ? Suppose that's one way to do it. But then
why not throw ASPTM/SM away as well ? There's no need for it when
everything's clear : either the SCTP association is up, congested or down
;)) Then you have SCTP associations instead of routes and everything is
MTP3, including the management ... why not use M2PA only and get rid of the
rest ?

IPSP/ASP differ from SG (as far as I understand it) in that SG is running no
applications. It's just plain interworking (NIF and all that). So what does
it need to register/go active for ? If SG sends ASPAC, then gee, it's an
ASP/IPSP after all ... why not as long as it knows what it's doing ?

Gery Verwimp
Fax : +32 14 25 3212

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]]
Sent: dinsdag 6 november 2001 13:29
To: Verwimp Gery
Cc: sigtran
Subject: Re: Consensus call (was: IPSP-IPSP summary)

Verwimp,

--brian

Verwimp Gery wrote:                                       (Tue, 06 Nov 2001
13:16:26)

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

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 6 Nov 2001 08:21:21 -0600

Tolga,

Tolga Asveren wrote:                                        (Tue, 06 Nov 2001 05:47:31)
> >      (Tue, 06 Nov 2001 13:47:36)
> > > Brian,
> > > 

AS/SG exposes the internal architecture of the SS7 node
for the purposes of backhaul.  This internal architecture
consists of independent users (AS) of a signalling point
(SG).  For peer-to-peer communications it is never
necessary to expose the relationship between the provider
of a service and the user of a service.  All that is
necessar is to identify (address) the service-access-
point (SAP).  This is accomplished in SS7 with point
codes, GT and subsystems.

In the AS/SG model we cut the MTP-User/SCCP-User into
fine pieces with RC so that the placement of users (AS)
could be independent from the placement of signalling
points (SG).  This was to meet the specific need of
backhaul within the SIGTRAN architecture.

For peer-to-peer all that is required is full point
codes or SPMC.  If the IPSP wishes to further distribute
AS (its users) over processors, it is welcome to use
the AS/SG model to do so.  This is even pictured in
the SIGTRAN architecture, where an ASP is shown connected
behind an SG and only SGs are directly interconnected
in the peer-to-peer case.

Attempting the illusion that an ASP can talk to an ASP
is foolish.  Already these "ASPs" have RKs and routing
tables.  They must peforming routing logic across a
large number of destinations spread across a large
number of peers.  The must turn association availability
and routing information into the SNMM equivalents expected
across the user interface to its users (e.g., MTP-PAUSE).
With all these functions they have turned into SGs.  There
is no function of the SG (aside from pure SS7 attachement)
that has not been clumped into the ASP to make it an IPSP.

> need to swtich from signaling point based entities to

Because entities must be managed as a group.  Even in
the AS/SG case, the SG is responsible for collecting
the states of the various AS and presenting this as
a single management view into the SS7 network.  There
is no difference in the IP case.  If I on IPSP3 am
connected to PC=3, SI=3 on IPSP1 and PC=3, SI=5 on
IPSP2, what do I do when IPSP1 sends DUNA(APC=3)?
How will IPSP1 even know to send DUNA(APC=3)?  The
IPSP must manage the SPMC just as the SG did, and there
goes all by the last function of an SG into the ASP
to make it an IPSP.

Just flip the view: the IPSP *is* and SGP and IPSPs
communicate between each other as SGs do across the
SS7 network, just with UA messages and over associations.
If you want users (AS) remote from the SG, connect
to it as an ASP.

Certainly an IPSP is not an ASP unless you remove
all those SG functions (RKs, routing tables, SNMM
generation, route availability, accepting registrations,
etc.).

--brian

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

---

---

From: Verwimp Gery <[email-masked]>
Date: Tue, 6 Nov 2001 15:46:27 +0100

Well, we need to sort out our definitions before any more confusion (if
possible) arises. Seems everyone has it's own ideas ... and the drafts have
gone through a lot of turmoil lately ...

First of all, the SG to me has only interworking significance. If it has
real M3UA/SUA users, why not, but then to me it is acting as ASP (when
soliciting another SG) or IPSP (when soliciting other IPSPs) in this
respect. So the terms SG, ASP, IPSP have distinct functions in distinct
environments. If not, why then, these terms are meaningless.

If an SG/ASP model is all we need even in the all-IP environment, then
there's no use for the IPSP term nor any additional effort to deal with it.
But I don't think this is the WG's view. After all, an IP-address is also
just a number ...

What is your concern with "exposing AS" to the network ? It seems pretty
obvious to me one has to know where to send messages to, be it
point-to-point or with the use of relay/transfer nodes.

Some further below ...

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]]
Sent: dinsdag 6 november 2001 14:24
To: Verwimp Gery
Cc: sigtran
Subject: Re: Consensus call (was: IPSP-IPSP summary)

Verwimp,

13:47:36)

[GV] : Big deal. Could also be pre-configured.

[GV] : Having a hidden agenda, don't you ?

[GV] : Think about it. SUA - no SUA user in sight. M3UA - point-to-point
communication between 2 SCCP peers, SG as IPSP from M3UA's point of view.

"Default ASP" : dustbin RK to catch the holes ... seems to me the SG can't
do much more than discard. If it can handle the SS7 traffic, why, it's not
an SG but an SS7 SEP plain and simple.

[GV] : Send your SSNM (DAVA, DUNA, ...); assume active on restart, find out
with response method, whatever ...

[GV] : So, SG fakes out. It acts as ASP or IPSP. No problem with that'n.

[GV] : hey, there's a thought, let's go active for a hidden AS !!

--gery

---

---

From: "Javier Pastor-Balbas (ECE)" <[email-masked]>
Date: Tue, 6 Nov 2001 16:06:26 +0100

Hi Gery and others, 

When talking about IPSP we talk about IP Server Process. Going to the definition it says IPSP "is an IP-based application". Talking about IPSP communication means that two IPSP are talking, one to each other. As IPSP are located in IP, no gateway is required. SIGTRAN stands for SIGnaling TRANsport and it's what all of these protocols are about. Therefore, we are talking about two SS7 applications talking one to each other in the IP network. Then no Gateway is needed at all. You can locate your  SS7 application whereever you want. But take into account that you are talking about SS7App/M3UA-----M3UA/SS7App. No SG has to be present in the discussion.

If you take a look to the draft, you see that these kind of nodes already exist in a way: SS7 applications over M3UA layer. And they are logically called AS. These ASs have instances called ASPs.

Since this node seems to be very similar to IPSP, why not to call them the same thing. It makes sense to have a node that can communicate with an SG to send messages to SS7 network, and also with other nodes inside the IP domain. This was a discussion that I had with John L. some weeks ago, and he agreed. In fact, in SUA draft was also addopted the AS nomenclature for the IPSP communication.

Concluding, 
- let's no talk about SG in IPSP communication. It's out of the topic. 
- If you agree, we can talk of ASP-ASP communication.

Cheers // Javier.

> From: Verwimp Gery [mailto:[email-masked]]
> Sent: Tuesday, November 06, 2001 3:46 PM
> To: sigtran
> Subject: RE: Consensus call (was: IPSP-IPSP summary)
> 
> 
> > MTP3, including the management ... why not use M2PA only 
> and get rid of
> the
> > rest ?
> 
> > IPSP/ASP differ from SG (as far as I understand it) in that 
> SG is running
> no
> > applications.
> 
> [email-masked]

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 6 Nov 2001 09:09:48 -0600

Gery,

This is the only peer-to-peer case that is presented in RFC 2719.
I don't see ASPs or IPSPs, but I do see SGs.

As the IPSP as described recently needs all of the functions
of an SG (except pure SS7 connection), why not accept that is
is more like an SG than an ASP?  There are insights that can
be gathered from the distinction.

The nearest situation we have to peer-to-peer in AS/SG is when
we have multiple SG/STPs.  To handle that case, a bunch of SG
functions needed to move to the ASP to permit things to function
correctly.

This is where I started in this discussion: If the IPSP is an
ASP, where are the MTP/SCCP state machines in the IPSP case?
Answer: at the IPSP.  MTP/SCCP state machines are only at the
SGP in the AS/SG case.  Gee.  There's another SGP function
that an IPSP must perform.

Once we say that an IPSP must perform the functions an SG
(including SS7 interworking if you look at RFC 2719 and are
getting ready to allow transfer/relay extension drafts)
we can realize that the IPSP is reponsible for a Signalling
Point Management Cluster (SPMC) and that routing at finer
granularity than the PC is pointless.

John Schantz' arguments against RC were all applicable to
the IPSP case.  There is no need for RC in the IPSP network.
Full point code routing an management are all that is
required.

An SG does not expose AS (or RCs or RKs) to its peers (other
SGs).  There is no need for IPSPs to do so either.

--brian

Verwimp Gery wrote:                         (Tue, 06 Nov 2001 15:46:27)
> [GV]: Big deal. Could also be pre-configured.
> 
> [GV]: Having a hidden agenda, don't you ?
> 
> > 
> [GV]: Think about it. SUA - no SUA user in sight. M3UA - point-to-point
> [GV]: Send your SSNM (DAVA, DUNA, ...); assume active on restart, find out
> [GV]: So, SG fakes out. It acts as ASP or IPSP. No problem with that'n.
> 
> [GV]: hey, there's a thought, let's go active for a hidden AS !!
> 
> --gery
> 
> 
> 
> 
> 
> ---

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

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 6 Nov 2001 09:23:22 -0600

Javier,

Javier Pastor-Balbas (ECE) wrote:                          (Tue, 06 Nov 2001 16:06:26)
> Hi Gery and others, 
> 
> When talking about IPSP we talk about IP Server Process. Going to the
> definition it says IPSP "is an IP-based application". Talking about IPSP
> communication means that two IPSP are talking, one to each other. As IPSP
> are located in IP, no gateway is required. SIGTRAN stands for SIGnaling
> TRANsport and it's what all of these protocols are about. Therefore, we are
> talking about two SS7 applications talking one to each other in the IP
> network. Then no Gateway is needed at all. You can locate your  SS7
> application whereever you want. But take into account that you are talking
> about SS7App/M3UA-----M3UA/SS7App. No SG has to be present in the
> discussion.

Consult RFC 2719 "Architectural Framework for Signalling Transport".
The only SEP to SEP communication across IP is shown via SGs.  I don't
know how M3UA managed to deviate so far from the architecture.

> 
> If you take a look to the draft, you see that these kind of nodes already
> exist in a way: SS7 applications over M3UA layer. And they are logically
> called AS. These ASs have instances called ASPs.

If you take a look to the RFC (not just a draft), you see that SEP
communicate over SS7 via SGs.

> Since this node seems to be very similar to IPSP, why not to call them the
> same thing. It makes sense to have a node that can communicate with an SG to
> send messages to SS7 network, and also with other nodes inside the IP
> domain. This was a discussion that I had with John L. some weeks ago, and he
> agreed. In fact, in SUA draft was also addopted the AS nomenclature for the
> IPSP communication.

Johns' views may have changed.  We should let John speak for himself.

> - let's no talk about SG in IPSP communication. It's out of the topic. 

Why would it be off topic to discuss the all of the SGP functions that
an IPSP needs to peform?

> - If you agree, we can talk of ASP-ASP communication.

Why restrict the dicussion?  Is censorship to the views that you
subscribe to really necessary?  (I thought the IEFT was a forum
for open discussion and a process for building concensus.)

--brian

> You are currently subscribed to sigtran as: [email-masked]

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

---

---

From: Verwimp Gery <[email-masked]>
Date: Tue, 6 Nov 2001 16:26:17 +0100

Brian,

Why suddenly short-cut the procedures laid out for SG-ASP communication in
case of IPSP-IPSP communication ? Regard IPSPs e.g. as replicated subsystems
as in SS7 ...

And if we're transporting SS7 traffic, why is the RK concept suddenly of no
value for the IPSP ? The next thing we know, you're going to promote the use
of NA in every message in case the IPSP has "multiple point codes in
multiple networks" ... that would be a 180° turn coming from you ;)))

Gery Verwimp
Fax : +32 14 25 3212

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]]
Sent: dinsdag 6 november 2001 15:21
To: sigtran
Cc: [email-masked]
Subject: Re: Consensus call (was: IPSP-IPSP summary)

Tolga,

Tolga Asveren wrote:                                        (Tue, 06 Nov
2001 05:47:31)

--brian

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

---

---

---

From: Verwimp Gery <[email-masked]>
Date: Tue, 6 Nov 2001 16:39:26 +0100

Hi Javier,

Fine with me, although the ASP would still bring up the co-notation of
"making use of SGs services". And ASP-ASP communication rings the bell of
these things sharing state or whatever internal information ...

But anything that could get us out of backhaul scenario's associated with
SG-ASP communication, and get us focussed on the true peer-to-peer behavior
is fine. From that, it should be a logical step to get to IPSP
relay/transfer nodes ...

Gery Verwimp
Fax : +32 14 25 3212

-----Original Message-----
From: Javier Pastor-Balbas (ECE)
[mailto:[email-masked]]
Sent: dinsdag 6 november 2001 16:06
To: sigtran
Subject: RE: Consensus call (was: IPSP-IPSP summary)

Hi Gery and others, 

Concluding, 

Cheers // Javier.

---

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 6 Nov 2001 09:59:22 -0600

Gery,

Verwimp Gery wrote:                                       (Tue, 06 Nov 2001 16:26:17)
> multiple networks" ... that would be a 180° turn coming from you ;)))

Take a look back at the NA/RC discussion.  I agreed wholeheartedly
with John Schantz for the IPSP case: there is no need for RC in IPSP:
entire point code routing and SNMM are all that are required in M3UA.
Don't worry, the RK(AMF) will come back in SUA where one can have
interesting RKs (but dynamic registration is still of kinda marginal
use).

Arguing out the use of RC in IPSP and who registers with who would
be more meaningful if there were a real-world case where an independent
IPSP cluster needed to represent less than a point code.  But there
isn't.  Any independent cluster of MTP-Users can be labelled with a
new point code (heh!, use an IP address for a point code, I don't care,
its just another NA).

--brian

> To unsubscribe send a blank email to [email-masked]

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

---

---

From: "Schantz, John" <[email-masked]>
Date: Tue, 6 Nov 2001 07:49:44 -0800

I can go along with this, the use of ASP-ASP communication, BUT you are
still giving AS and ASP more reality than they deserve.  AS and ASP are
routing concepts ONLY.  They define specific set(s) of signalling
traffic.  They are not a real SS7 App.  They actually go no further than
the "UA" that you are using.  The real SS7 App. is still higher in the
stack, above SCCP and TCAP.  So PLEASE stop trying to make AS into a
real application.  

Look at all the confusion that has been created by a BADLY named
concept.  You might be better off using IPSP (IP Signalling Process) for
all end-nodes instead and get away from "Application".

John

> Sent: Tuesday, November 06, 2001 9:06 AM
> To: sigtran
> When talking about IPSP we talk about IP Server Process. 
> Going to the definition it says IPSP "is an IP-based 
> application". Talking about IPSP communication means that two 
> IPSP are talking, one to each other. As IPSP are located in 
> IP, no gateway is required. SIGTRAN stands for SIGnaling 
> TRANsport and it's what all of these protocols are about. 
> Therefore, we are talking about two SS7 applications talking 
> one to each other in the IP network. Then no Gateway is 
> needed at all. You can locate your  SS7 application whereever 
> you want. But take into account that you are talking about 
> SS7App/M3UA-----M3UA/SS7App. No SG has to be present in the 
> discussion.
> 
> If you take a look to the draft, you see that these kind of 
> nodes already exist in a way: SS7 applications over M3UA 
> layer. And they are logically called AS. These ASs have 
> instances called ASPs.
> 
> Since this node seems to be very similar to IPSP, why not to 
> call them the same thing. It makes sense to have a node that 
> can communicate with an SG to send messages to SS7 network, 
> and also with other nodes inside the IP domain. This was a 
> discussion that I had with John L. some weeks ago, and he 
> agreed. In fact, in SUA draft was also addopted the AS 
> nomenclature for the IPSP communication.
> 
> Concluding, 
> You are currently subscribed to sigtran as: [email-masked]

---

---

From: Verwimp Gery <[email-masked]>
Date: Tue, 6 Nov 2001 17:15:22 +0100

Brian,

woho, don't make too much assumptions here ... see below !

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]]
Sent: dinsdag 6 november 2001 16:10
To: Verwimp Gery
Cc: sigtran
Subject: Re: Consensus call (was: IPSP-IPSP summary)

Gery,

=====>
[GV] : Question : in case the ASP has the opportunity to use more SGs
(redundancy is one of our trademarks here, and the most general case to
boot), didn't we establish that this is extremely difficult, if not
impossible, to realize when the ASP doesn't implement the necessary
state-machines ?

For a connectionless service (basically what MTP or SCCP CL do) it is
sufficient to have the minimum of routing data; for a connection-oriented
service (SCCP CO), it is clear to me the ASP should have the CO
state-machines. You surely won't argue with me on this one for the IPSP
case, will you ?

The AS/ASP approach is not just there to introduce finer granularities (with
all it's associated SS7 management interworking problems), but also to
introduce an extended redundancy policy (phew).

This concept remains useful for IPSP as well, unless you want to repeat the
MTP/SCCP management here.
<=====

[GV] : I don't agree with that, as John S. (but he can tell you himself)
clearly didn't see the need for it in M3UA period. And for SUA, granularity
up to SSN would be nice.

[GV] : don't agree with that either. For one thing, the SG (by nature)
exposes it's capability to connect to legacy SS7 nodes. The ASP has to know
which nodes, instead of finding that out by trial and error. And then
there's all that SGP stuff which the ASP has to know about, for SGPs
logically belonging to *one* SG.

The only way to cloak network architecture is routing on DN or GT, which is
resolved along the way by ISUP or SCCP gateways. Look at a network as an
administration domain, where everybody may know about everybody else, but
opaque to other(s) (operator's networks).

--gery

> > IPSP/ASP differ from SG (as far as I understand it) in that SG is
running

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

---

---

From: Dennis Niermann <[email-masked]>
Date: Tue, 06 Nov 2001 10:24:23 -0600

Brian, 
I have a few comments below....

> interesting RKs (but dynamic registration is still of kinda marginal
The need for RC is when there is more than one AS at the IPSP.
It does not matter whether they use the same point code or not.
The real world case is an AS for ISUP and an AS for SCCP.
Even your previous simple network example showed two AS's at the 
same IPSP and the use of RCs to distinguish them.
Why the sudden change in your outlook?

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

-- 
---------------------------------------------------------------
 Dennis Niermann              [email-masked]
 Ericsson Network Systems   
 Richardson, Tx 75081

---

---

From: "Javier Pastor-Balbas (ECE)" <[email-masked]>
Date: Tue, 6 Nov 2001 17:33:42 +0100

Hi John, 

Welcome back to the list !!  ;-)

You are right in your points. I agree that AS is not a real SS7 application and so on. But knowing that what you tell is right, since the basic M3UA protocol (AS-SG communication) is talking about ASP, I would prefer to follow this nomenclature to emphasize that it can be the same node. Thanks anyway for your clarification.

Cheers // Javier.

> From: Schantz, John [mailto:[email-masked]]
> Sent: Tuesday, November 06, 2001 4:50 PM
> To: sigtran

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 6 Nov 2001 10:46:06 -0600

Verwimp,

Verwimp Gery wrote:                                       (Tue, 06 Nov 2001 17:15:22)
> [GV]: Question : in case the ASP has the opportunity to use more SGs

Yes, we had to move SG functions into the ASP to make it more like
an SG and operate in more of a peer-to-peer fashion.

> state-machines. You surely won't argue with me on this one for the IPSP

Not until we start talking about IPSP transfer/relay nodes.  IPSP as a
signalling end point needs the state machines that only an SGP has in
the basic AS/SG case.

> introduce an extended redundancy policy (phew).

Redundancy is within an RC not across RCs.  It is not necessary to
have an RC concept to provide redundancy.  Finer granularity allowed
different users (AS) to have different policies on the same node.
The use of this, however, escapes me.  It is far more usual that
the nature of the ASP/SGP dictates the redunancy policy (traffic mode)
than the AS (slice of a user).

> MTP/SCCP management here.

The SG controls a whole point code.  That is the only reason it
can represent SNMM to both AS and the SS7 network.  Distribution
of DATA/SNMM in the SGP is based on the message.  It is only on
its way to the ASP that it needs to pick up RC.

For an IPSP to represent SNMM to its local users and correctly to
the remote users it must control an entire point code, just as the
SGP.  The state of local AS is meaningless to remote users, unless
expressed in the terms of SNMM.  To ammalgamate the local AS status
into a representation to remote SS7 user, and IPSP must control the
entire point code.  RC is not useful in this situation as SNMM is
both sufficient and necessary.

> [GV]: I don't agree with that, as John S. (but he can tell you himself)

The archives are there.

> [GV]: don't agree with that either. For one thing, the SG (by nature)

Consider that although you think that IPSPs are a new brave world
outside of SS7, they must still provide the same MTP/MTP-User and
SCCP/SCCP-User interface.

There is no MTP-PAUSE/RESUME for an RC.  Just for a Point Code.
There is no MTP-STATUS for an RC.  Just for a Point Code or User Part.
Well..  you get the drift.  An IPSP must still represent an SS7 
network to its users whether that network exists as a physical SS7
network or not.

> opaque to other(s) (operator's networks).

The User interface is what makes remote users unaware of RCs and RKs.
As such there is no need to communicate them between peers.  SNMM is
both sufficient and necessary.

--brian

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

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 6 Nov 2001 10:49:16 -0600

Dennis,

Dennis Niermann wrote:                                     (Tue, 06 Nov 2001 10:24:23)
> Why the sudden change in your outlook?

Because I realized that it is impossible for an IPSP to properly
represent SNMM to local and remote users unless it controls the
entire signalling point.  Even if an IPSP has SCCP and ISUP, it
must still represent the entire signalling point to remote IPSPs.
SNMM is both necessary and sufficient to accomplish this.  RC is
therefore not required to be communicated between peers.  It is
a thing of the AS/SG model.

--brian

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

---

---

From: "Schantz, John" <[email-masked]>
Date: Tue, 6 Nov 2001 08:44:31 -0800

Wow!  Go off and do some real work and come back and people are quoting
you!  Who would have thought...

Personally, I feel that all situations (ASP-SGP and IPSP-IPSP) could
have used the simple routing methods already provided by SS7 (point
codes between nodes; SSN, etc. within a node).  But there are always
some situations/architectures/implementations where there are extra
needs (whether they are justified or not).  Hence, if an end-node had
it's traffic specially packaged from a SG (SG-ASP case) then way should
it not expect to get this special packaging of traffic from other
end-points (IPSP-IPSP case).  The precedent was already set in the
SG-ASP case why shouldn't it be expected to be carried forth in the
IPSP-IPSP case.

I thought I would stir the nest a little.

John

> Sent: Tuesday, November 06, 2001 9:59 AM
> To: sigtran
> (Tue, 06 Nov 2001 16:26:17)
> > Brian,
> > 
> [email-masked]

---

---

From: "Javier Pastor-Balbas (ECE)" <[email-masked]>
Date: Tue, 6 Nov 2001 18:08:26 +0100

One small comment, 

From my point of view, SSNM messages are not applicable to point to point. These only have sense as a translation of what it's happening in the SS7 network to the IP endpoint. In SS7 network we have a complete network and one node informs the other about the availability of the other nodes unreachable for the latter. Here we are talking about point to point. You can get the same result with ASPIA.

Only I see DUPU as a possible one to use in this scenario. This is because DUPU can trigger an MTP3-STATUS in the other end, while ASPIA triggers an MTP-PAUSE.

Cheers // Javier.

> Sent: Tuesday, November 06, 2001 5:49 PM
> To: sigtran
> [email-masked]
> [email-masked]

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 6 Nov 2001 11:50:37 -0600

Javier,

Javier Pastor-Balbas (ECE) wrote:                          (Tue, 06 Nov 2001 18:08:26)
> One small comment, 
> 
> >From my point of view, SSNM messages are not applicable to point to point.
> >These only have sense as a translation of what it's happening in the SS7
> >network to the IP endpoint. In SS7 network we have a complete network and
> >one node informs the other about the availability of the other nodes
> >unreachable for the latter. Here we are talking about point to point. You
> >can get the same result with ASPIA.
> 
> Only I see DUPU as a possible one to use in this scenario. This is because
> DUPU can trigger an MTP3-STATUS in the other end, while ASPIA triggers an
> MTP-PAUSE.

ASPIA is not used to trigger MTP-PAUSE even in the AS/SG
case.

What ASPTM message corresponds to SCON and MTP-STATUS?

What ASPTM message corresponds to N-STATUS?  N-PCSTATUS?
N-COORD?  How will these be derived?

When we do transfer how will ASPTM represent DRST?

All SNMM information has a user interface equivalent.  But
there is not an equivalent ASPTM message for each SNMM?
How is the IPSP to present the network to the SS7-User
using ASPTM?

On the contrary, using SNMM, ASPTM is not required.

--brian

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

---