Subject: Consensus Call - Routing Key

From: Dennis Niermann <[email-masked]>
Date: Tue, 06 Nov 2001 07:59:56 -0600

It is very clear to me that core of the dispute is
over what a routing key is. This comes up over and over
throughout this discussion.

So the key question is this:

  1) Does a routing key define traffic for an AS?

  2) Or, does a routing key define two-way traffic 
     between a pair network entities, i.e. a route?

If there is consensus on that question, I believe 
that everything else follows.

To me, the answer is clearly 1) as the entire M3UA 
specification is based on that definition. 

/Dennis

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

---
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 08:23:51 -0600

Dennis,

The draft is very clear that an RK is only used
to route traffic at an SG.  Why do you want it
used to route traffic at an ASP?

--brian

Dennis Niermann wrote:                                     (Tue, 06 Nov 2001 07:59:56)
> 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 15:28:22 +0100

Brian, 

It's used to route traffic TO an ASP. It's an  ASP the origin of the RK. And RK are provided to a remote end for that remote end to know what kind of traffic has to send to the ASP.

Cheers // Javier.

> -----Original Message-----
> From: Brian F. G. Bidulock [mailto:[email-masked]]
> Sent: Tuesday, November 06, 2001 3:24 PM
> To: sigtran
> Cc: [email-masked]
> Subject: Re: Consensus Call - Routing Key
> 
> 
> Dennis,
> 
> > To unsubscribe send a blank email to 
> [email-masked]
> 
> -- 
> Brian F. G. Bidulock
> [email-masked]
> http://www.openss7.org/
> 
> 
> ---
> You are currently subscribed to sigtran as: 
> [email-masked]
> To unsubscribe send a blank email to 
> [email-masked]
> 

---

---

From: Dennis Niermann <[email-masked]>
Date: Tue, 06 Nov 2001 08:38:37 -0600

Brian,
I would say that an RK is used to route traffic to 
an AS. In the SG-AS case it is only a SG that 
needs to route traffic to an AS. in the IPSP-IPSP
there is a need for the IPSP to route traffic to an AS.
/Dennis

"Brian F. G. Bidulock" wrote:
> You are currently subscribed to sigtran as: [email-masked]

---

---

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

Javier,

Javier Pastor-Balbas (ECE) wrote:                          (Tue, 06 Nov 2001 15:28:22)
> Brian, 
> 
> It's used to route traffic TO an ASP.

from an SG.

> It's an  ASP

layer management function that is

> the origin of the RK.

if the optional registration procedure is used.

> And RK are provided to a remote end for that
> remote end to know what kind of traffic has to
> send to the ASP.

by static configuration (MUST) and by an
ASP's layer management function (OPTIONAL).

ASPs are never required to maintain or route
on RKs.

--brian

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

---

---

From: Dennis Niermann <[email-masked]>
Date: Tue, 06 Nov 2001 08:47:59 -0600

---

---

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

Dennis,

Dennis Niermann wrote:                                     (Tue, 06 Nov 2001 08:38:37)
> there is a need for the IPSP to route traffic to an AS.

What else does an IPSP need to do that an SGP normally does?

Well, REG REQ is not sent to an ASP.  But IPSPs appear
to need to respond to them.  ASPs to not maintaint RK
tables, but IPSPs appear to have to maintain RK tables.
ASPs do not need to maintain the status of destinations
(except in the oddball multiple SG as STP case).  But
it appears that IPSPs need to maintain status of destinations.
ASP do not need to examine routing labels.  Yet, it appears
that IPSPs need to examine routing labels.  ASPs do not
need to maintain NA mappings.  IPSPs need to maintain
NA mappings.

What is there that an SG does besides physical SS7 connectivity
that an IPSP does not have to do?

--brian

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

---

---

From: [email-masked]
Date: Tue, 6 Nov 2001 09:51:15 -0500

Javier,

In order to understand Brian's comments, you have to understand the 
architecture of his implementation. 

When Brian hears the phrase "routing to an AS", he does not think, as most 
implementors of M3UA do, that the source of the message is the SG. Brian 
thinks that the source of the message is the ASP. This is because Brian 
has implemented the ASP in the Linux kernel, and the AS in the Linux user 
space. Thus he has 2 separate entities - the ASP and the AS - and must 
have a mechanism for routing between them. He is apparently trying to use 
the routing key. Of course, this implementation is clearly not what was 
intended by the draft - the AS is defined as a logical entity and is not 
intended to be a real process, thread, etc.

Brian has consistently continued his attempt to warp the M2UA/M3UA/SUA 
drafts to fit his implementation, rather than fit his implementation to 
the draft, and in the process has paralyzed almost the entire working 
group.

I think that it is time for the working group chair to end this travesty, 
and allow the drafts to reach the RFC stage.

Barry Nagelberg
Software Engineer
RadiSys, Corp.
Signaling Products Design Center
[email-masked]
+1-856-642-9229 x237

"Javier Pastor-Balbas (ECE)" <[email-masked]>
11/06/01 09:28 AM
Please respond to sigtran

        To:     "sigtran" <[email-masked]>
        cc: 
        Subject:        RE: Consensus Call - Routing Key

Brian, 

It's used to route traffic TO an ASP. It's an  ASP the origin of the RK. 
And RK are provided to a remote end for that remote end to know what kind 
of traffic has to send to the ASP.

Cheers // Javier.

---

---

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

Barry,

Your note is offensive and unprofessional.

--brian

[email-masked] wrote:                (Tue, 06 Nov 2001 09:51:15)

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

---

---

From: Amish Chana <[email-masked]>
Date: Tue, 06 Nov 2001 15:16:38 +0000

Brian,

>that an IPSP does not have to do?

As you pointed out some SGP functionality is necessary.
But, for an implementation that has both ASP and SGP functionality, would it 
not be possible to achieve IPSP to IPSP connectivity with what is already 
defined?

Amish

_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp

---

---

From: "Lehecka, Gary R (SAIC)" <[email-masked]>
Date: Tue, 6 Nov 2001 09:28:48 -0600

If they can NOT be separated,
then the AS WOULD NOT be a logical entity.

The point of a logical entity is that
implementation whether it is separate or not
SHOULD NOT matter.

i.e.
They COULD be separate physical entities
or they COULD be (parts of) the same physical entity.
It SHOULD NOT matter ...

Thanks,
mailto:[email-masked]
-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: 2001, November 06, Tuesday 09:51
To: sigtran
Subject: RE: Consensus Call - Routing Key

Javier,

Barry Nagelberg
Software Engineer
RadiSys, Corp.

Brian, 

Cheers // Javier.

> > specification is based on that definition. 

---
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 09:30:31 -0600

Amish,

Amish Chana wrote:                                          (Tue, 06 Nov 2001 15:16:38)
> not be possible to achieve IPSP to IPSP connectivity with what is already 

I don't think new functionality needs to be defined for IPSPs.  The
functionality provided by SGPs will do.  In fact if one just starts
calling an IPSP an SGP, only a minor addition to SGP would be required
to build a peer-to-peer network in the IP domain: issuing ASPUP/DN/AC/IA.

Already it has been identified that AS can communicate with each
other via the SG.  This is provided for both in MTP/M3UA and SCCP/SUA.
If the direct SG to SG communications via associations is established,
none of the model or functionality changes.  AS can communicate with
AS via SGs, it just won't require an SS7 network to do so.

--brian

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

---

---

From: Amish Chana <[email-masked]>
Date: Tue, 06 Nov 2001 15:49:08 +0000

Brian and others,

See below...

>to build a peer-to-peer network in the IP domain: issuing ASPUP/DN/AC/IA.

I think a number of other people on the list agree that some SGP 
functionality is required at the IPSP (correct me if I am wrong!). Lets make 
this clear in the definition - i.e. it is an element that requires both ASP 
and SGP functionality.

Brian, what would this minor addition be. If you have already mentioned it 
I've probably lost track or missed it.

Amish

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

---

---

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

Amish,

Amish Chana wrote:                                          (Tue, 06 Nov 2001 15:49:08)
> I've probably lost track or missed it.

Allowing an SGP to issue an ASPUP/DN/AC/IA, not just the Ack.  With that
additionan SGP is and IPSP.  No other ASP functionality would be necessary.

--brian

> 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 17:03:30 +0100

Hi Amish, 

From my point of view, IPSP needs to:

- Send data msg to the other IPSP in the way an SGP sends a message to an ASP
- Receive data messages and distribute them to the ASs in the same way ASP does it
- Send ASPSM and ASPTM in the same way ASP does
- Receive and treat ASPTM and ASPSM in the same way as SGP.

Other classification of IPSP functionality:

As an SGP
- Send data msg to the other IPSP in the way an SGP sends a message to an ASP
- Receive and treat ASPTM and ASPSM in the same way as SGP.

As an ASP
- Receive data messages and distribute them to the ASs in the same way ASP does it
- Send ASPSM and ASPTM in the same way ASP does 

(This last point has the particularity that only one ASP-UP is needed. When an IPSP receives an ASPUP and sends back an ASPUP-Ack it does not need to send another ASPUP to the peer and can consider the peer as INACTIVE)

Cheers // Javier.

> From: Amish Chana [mailto:[email-masked]]
> Sent: Tuesday, November 06, 2001 4:49 PM
> To: sigtran
> > > But, for an implementation that has both ASP and SGP 
> functionality, 
> >would it

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

---

---

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

Brian,
I wish that you would answer the initial question.
I felt that it was clear and simple.
I interpret your comments as simply an attempt
to divert attention and create confusion.

But, in answer to your question, it should not
come as no surprise that that if both an SGP
and an IPSP need to be able to route traffic
to an external AS serviced by an external ASP/IPSP 
that they would have some common capabilities.
/Dennis

---

---

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

Javier,

Javier Pastor-Balbas (ECE) wrote:                          (Tue, 06 Nov 2001 17:03:30)
> - Receive data messages and distribute them to the ASs in the same way ASP does it

An SG distributes messages to local users as well.  So I classify this as
an SG function as well as an ASP function.  Nothing of an ASP needs to be
added to the SG to perform this function.

> - Receive data messages and distribute them to the ASs in the same way ASP does it

Again, this is also an SG function.

> (This last point has the particularity that only one ASP-UP is needed. When
> an IPSP receives an ASPUP and sends back an ASPUP-Ack it does not need to
> send another ASPUP to the peer and can consider the peer as INACTIVE)
> 

Does an SGP need anyting else than sending ASPTM/SM to make it an IPSP?

--brian

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

---

---

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

Brian, 

Comments below...

> Sent: Tuesday, November 06, 2001 5:19 PM
> To: sigtran
Brian, the basic SG-AS communication consist of a SG WITHOUT an SS7 aplication over it and an ASP WITH an SS7 application over it. What I'm referring to is the latter: distribution of messages amongst the AS that are served by an ASP. 

Cheers // Javier.

> > > > > not be possible to achieve IPSP to IPSP connectivity 
> with what is 
> > > >already
> > > > > defined?
> > > >

---

---

From: Amish Chana <[email-masked]>
Date: Tue, 06 Nov 2001 16:33:46 +0000

Brian,

>additionan SGP is and IPSP.  No other ASP functionality would be necessary.

If the IPSP is defined as having both SGP and ASP functionality then it 
should be able to issue ASPUP/DN/AC/IA. Would that be acceptable?

Amish

---

---

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

Dennis,

Well, an IPSP cannot provider service to its local
users with regard to remote AS if that AS is more
granular than a point code.  Consider a simple M3UA
example:

   PC=3, SI=5
    _______
   |       |
   | IPSP1 |--XXX-+     _______ 
   |_______|      |____|       | PC=4, SI=5
                   ____| IPSP3 |           
    _______       |    |_______| PC=4, SI=3
   |       |      |
   | IPSP2 |------+
   |_______|

   PC=3, SI=3

Association between IPSP1 and IPSP3 goes down.
MTP User (ISUP) at IPSP3 (PC=4) is given what
indication?

An SS7 MTP User expects to receive an indication
of the status of the remote ISUP user on PC=3.
That indication can be one of:

      Unquipped Remote User
      Inaccessible Remote User

Is SI=5 on PC=3 unequipped?  Inaccessible?
Only PC=3 knows.

Things get even funner with SUA subsystems.

Only the remote signalling point knows the status
of its users.  That user status is communicated
using SNMM messages when peer-to-peer.  ASPTM
messages are for backhaul where the SGP knows
the status of all its users and all its pieces.

IPSP1 and IPSP2 need to be in the same cluster
and AS cannot be more granular than a point code
for an IPSP to properly represent SNMM across the
MTP/MTP-User or SCCP/SCCP-User interface.

--brian

Dennis Niermann wrote:                                     (Tue, 06 Nov 2001 10:04:35)

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

---

---

From: Amish Chana <[email-masked]>
Date: Tue, 06 Nov 2001 16:43:36 +0000

Brian & Javier,

Lets leave the pure SG and ASP cases as is. Rather redefine IPSP has a 
combined SGP/ASP.

This would help achieve the objective of implementations that aim to be pure 
SGs, pure ASes or hybrids.

Any objections?

Amish

>Brian, the basic SG-AS communication consist of a SG WITHOUT an SS7 
>aplication over it and an ASP WITH an SS7 application over it. What I'm 
>referring to is the latter: distribution of messages amongst the AS that 
>are served by an ASP.
>
>Cheers // Javier.
>

---

---

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

Amish, 

An IPSP can also send RRM messages (REG and DEREG).
And don't forget that IPSP needs also to have the mechanism to distribute msgs to the different AS it is serving. 

Anyway I prefer seeing an IPSP as an ASP with some SGP functionality since ASP already have the SS7 application above it (like IPSP) while SGP doesn't.

Cheers // Javier.

> Sent: Tuesday, November 06, 2001 5:34 PM
> To: sigtran

---

---

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

Amish,

Amish Chana wrote:                                          (Tue, 06 Nov 2001 16:33:46)
> should be able to issue ASPUP/DN/AC/IA. Would that be acceptable?

That should do it.

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

---

---

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

Javier,

Javier Pastor-Balbas (ECE) wrote:                          (Tue, 06 Nov 2001 17:28:19)
> referring to is the latter: distribution of messages amongst the AS that are
> served by an ASP. 

"The MTP3 layer at an SGP may also be unaware that its
local users are actually remote user parts over M3UA."

An SGP does not necessarily know that the AS are remote.
An SG can have local users using the same or different
point codes from the AS.  An SG has a full SS7 stack which
is capable of supporting local users outside of M3UA/SUA.
Coupling of CO sections in SUA is performed by SCCP at the
SG and is an MTP-User that is local to the SG.

I'm sorry but there is no restriction placed on an SC that
keeps it from having local users.

--brian

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

---

---

From: Amish Chana <[email-masked]>
Date: Tue, 06 Nov 2001 16:58:20 +0000

Javier,

Rather than debate as to whether its a ASP or SGP with some added 
functionality could we call it a hybrid signalling process (to make everyone 
happy) and define what capabilties it needs to support from the ASP and SGP.

Amish.

>Anyway I prefer seeing an IPSP as an ASP with some SGP functionality since 
>ASP already have the SS7 application above it (like IPSP) while SGP 
>doesn't.
>
>Cheers // Javier.
>

---

---

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

Hi Amish, 

I prefer to call it ASP because it has an SS7 application and you emphasize that they can be the same node with capability to communicate to both: another ASP or an SG. But if a majority wants to call it with other name, let's choose IPSP. We don't need to invent more terms :-).

Cheers // Javier.

> Sent: Tuesday, November 06, 2001 5:58 PM
> To: sigtran
> >And don't forget that IPSP needs also to have the mechanism 
> to distribute 
> >msgs to the different AS it is serving.
> >

---

---

---

From: Dennis Niermann <[email-masked]>
Date: Tue, 06 Nov 2001 11:16:30 -0600

Brian,
I see no answer to the original question.

If neither of these matches what you think a routing
key is, then please explain your definition.

Responses to what you did write below.... 

> MTP User (ISUP) at IPSP3 (PC=4) is given what
IPSP3 sees COMM-DOWN from SCTP.
At that moment in time there is no notification
to the local ISUP.
In response to the next request from the local ISUP user,
a status of User Part Unavailable - Inaccessible 
Remote User is returned.

> Is SI=5 on PC=3 unequipped?  Inaccessible?
I think that it is best to use Inaccessible.

The scenario you pose is exactly the same one 
faced in SG-AS by an SG when it has access to an AS
defined for PC=3,SI=3, but does not have access to
an AS defined for PC=3, SI=5.  It has nowhere to send
ISUP traffic. It also can not 
use point code ganularity back to the SS7 node, it
must communicate status at the user part level.
So, this is not just a problem only for IPSP-IPSP.
And, of course it gets even more hairy if there are
ASs defined for ranges of circuits.

---

---

From: "Ong, Lyndon" <[email-masked]>
Date: Tue, 6 Nov 2001 09:35:35 -0800

Folks,

There has been a very large outpouring of messages on the IPSP-IPSP
issue, but it is not clear to me that we are reaching a consensus
on this.

We should consider putting a cap on this discussion and either
reaching agreement or separating the issue into an extension draft.

Cheers,

L. Ong

-----Original Message-----
From: Javier Pastor-Balbas (ECE)
[mailto:[email-masked]]
Sent: Tuesday, November 06, 2001 9:13 AM
To: sigtran
Subject: RE: Consensus Call - Routing Key

Hi Amish, 

I prefer to call it ASP because it has an SS7 application and you emphasize
that they can be the same node with capability to communicate to both:
another ASP or an SG. But if a majority wants to call it with other name,
let's choose IPSP. We don't need to invent more terms :-).

Cheers // Javier.

---

---
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 11:42:40 -0600

Dennis,

Dennis Niermann wrote:                                     (Tue, 06 Nov 2001 11:16:30)
> key is, then please explain your definition.

An RK is a pattern that can be matched against messages
to separate traffic.  What did you think it was?

--brian

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

---

---

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

Amish,

Excellent idea!

We already know that AS can communicate peer-to-peer
via one or more SGs and possibly via the SS7 network
between SGs.  So we have:

    ____________          ____________     
   |   ______   |        |   ______   |    
   |  |      |  |        |  |      |  |    
   |  |  AS  |  |        |  |  AS  |  |    
   |  |______|  |        |  |______|  |    
   |     |      |        |     |      |    
   |   __|___   |        |   __|___   |    
   |  |      |  |        |  |      |  |    
   |  | ASP  |  |        |  | ASP  |  |    
   |  |______|  |        |  |______|  |    
   |     |      |        |     |      |    
   |   __|___   |        |   __|___   |    
   |  |      |  |        |  |      |  |    
   |  | SGP  |__|________|__| SGP  |  |    
   |  |______|  |        |  |______|  |    
   |____________|        |____________|    
        IPSP                  IPSP

So we know that this will work peer to peer.  If we
draw a box around the peers in this arrangement we
have an IPSP.

Communication between IPSP needs to replace communication
between SGs as show to be able to support peer-to-peer
operation.  Several points can be made off the start:

  1.)  RC is not required.  SGs do not need RC
       to communicate between themselves.

  2.)  Regsitration is not required.  SGs do not
       register with each other.

  3.)  SNMM is required.  SGs exchange SNMM messages.

  4.)  IPSPs control an entire point code (because
       the SGs control an entire point code.

  5.)  We need a mechanism like ASPUP/DN single ended
       to enable traffic between SGs.  That should do.
       Don't even really need ASPAC/IA because we don't
       have RCs and we don't do RKMM.

  6.)  We need to exchange PDUs (DATA and SNMM).

Looks like were done.  We have an IPSP.  Because an
SG can also be an STP and have the relay/transfer
function, this will be adequate for the relay/transfer
case as well.  Configure the SG as you would an SEP
or STP.

--brian

Amish Chana wrote:                                          (Tue, 06 Nov 2001 16:58:20)

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

---

---

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

Lyndon,

Would separating the issue into an extension draft include
removing (possibly conflicting) IPSP references from the
current drafts?

--brian

Lyndon Ong wrote:                                          (Tue, 06 Nov 2001 09:35:35)

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

---

---

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

Brian, 

Comments below...

> Sent: Tuesday, November 06, 2001 6:39 PM
> To: sigtran
RC is required if your ASP serves more than one AS.

>        register with each other.
If Registration is not required your model is not valid since it works only statically. Operators don't want that. It can be a proprietary protocol.

>   3.)  SNMM is required.  SGs exchange SNMM messages.
SNMM is required only when translating TFP, etc msgs from the SS7 network to the IP network. Don't make sense in all-IP commmunication. You have there other means as ASPIA, ASPAC, no routes restricted, no need to audit anyghing and SCTP congestion control mechanisms

>        the SGs control an entire point code.
You don't need to create that restriction. IPSP can control a portion of the traffic to one entire point code as it is done by ASP.

>        have RCs and we don't do RKMM.

ASPUP/DOWN needed between two IPSPs. I agree with that. But also you need to activate/deactivate the AS RKs... 

>   6.)  We need to exchange PDUs (DATA and SNMM).
We need to exchange ASPSM, ASPST and DATA. And we have to allow to exchange RRM for the implementations they want to.

> case as well.  Configure the SG as you would an SEP

Man, you have created a monster...  ;-)

The main thing here is that it seems that you don't have a clear idea of what you want. But instead you know what you don't want. Give a working solution if you can and sent it out. And if you do it in time (before M3UA v10 is issued) the mailing list will decide what they want. :-D

If you don't have a working solution, just try to be constructive and let's work out one from the basis we have...  :-D

Cheers // Javier.

> > >And don't forget that IPSP needs also to have the 
> mechanism to distribute 
> > You are 
> currently subscribed to sigtran as: [email-masked]
> [email-masked]

---

---

From: "Ong, Lyndon" <[email-masked]>
Date: Tue, 6 Nov 2001 09:53:20 -0800

We would have to look closely at the text that is 
there now.

Lyndon

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]]
Sent: Tuesday, November 06, 2001 9:44 AM
To: Ong, Lyndon
Cc: sigtran
Subject: Re: Consensus Call - Routing Key

Lyndon,

--brian

Lyndon Ong wrote:                                          (Tue, 06 Nov 2001
09:35:35)

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

---

---

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

Dear all, 

I think we should all go for a solution in this issue. It can not be so hard. It could be good that all of us participate not to bias the discussion. I'll send out a new version of my proposal updating some obscure issues that have been discussed mainly about message distribution. Some other remain the same. Let's construct from there the best possible solution being compliance with the current concepts and architecture. We don't have to reinvent the wheel.

Thanks  // Javier.

> From: Ong, Lyndon [mailto:[email-masked]]
> Sent: Tuesday, November 06, 2001 6:36 PM
> To: sigtran

---

---

From: Dennis Niermann <[email-masked]>
Date: Tue, 06 Nov 2001 13:20:53 -0600

Brian,
Respectfully, this is another non-answer since it
does not distinguish between the key difference
articulated in definitions #1 and #2 below.
I unequivically subscribe to definition #1 below.
Previously, you have advocated definition #2. 
Is that still true?

If it is still true then I don't see a consensus
happening.
If you no longer strongly feel that a single RK
should represent routing for both directions
then a consensus should be possible.
  
/Dennis

> to separate traffic.  What did you think it was?

[SNIP]

---

---

From: Tolga Asveren <[email-masked]>
Date: Tue, 6 Nov 2001 12:34:09 -0800 (PST)

Dennis,

I think currently we have a more serious disagrement.
Should we allow ASs with granularity less than point
code in IPSP case or not? Do we need ASPTM and/or
SSNM?
First we should convince Brian that granularity less
than a point code is applicable in IPSP case or he
should convince us for the opposite, so we can proceed
:-) As far as I understand, his current answer to your
question should be , "you don't need RKs at all"
(or again I misunderstand it :-) )

    Tolga

--- Dennis Niermann <[email-masked]> wrote:
> [email-masked]

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

---

---

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

Dennis,

In the AS/SG case the AS and SGP are concerned about both
directions of traffic.  The RK is used to forward route
the traffic from the SGP to the AS, but there is not always
a "reverse RK" so the RC is implicitly associated with
the AS at the ASP and used to identify traffic in the reverse
direction.

In this situation, RK separates traffic at the SGP
and allows it to be assigned an RC value in the SGP to AS
direction.  In the AS to SGP direction, the RC is implicitly
associated with the AS (but could be a different "value"
depending on the outgoing association) and used to identify
for the SGP the traffic in the AS to SGP direction by
assigning it the same RC value that the SGP would assign
for the SGP to ASP direction for the same AS.

So, RK identifies traffic in one direction, but the RC
value identifies traffic in both directions.  Understand?

There is no reason why this must change at the AS.  The
AS always knows implicity that traffic it sends belongs
to it.  The ASP labels the traffic the AS sends with the
RC that the SGP would use when sending traffic towards
the AS for the same association.

This is no different for a (OPC=*,DCP=x) RK than any other.
When an AS (PC=x) sends data it uses the RC values that
the SGP would use for sending data from anywhere to the
AS.  This ensure that RKs that have no reverse (e.g., SUA
CODT) can yeild an RC value that indicates the traffic
in both directions.

At the SGP, applying a "reverse RK" to incoming data to
determine the AS source was unacceptable because such
"reverse RK" does not always exist.  The AS can always
implicity label with RC in this way.

For the IPSP case, there is no need to expose the AS
concept to the remote as the AS is a local concept only
the the IPSP node.  The status of user parts and point
codes must be communicated to the IPSP peer using SNMM
when an association is available, and no distinction
of anything at the sub-PC level is necessary with ASPTM.

You confusion and preoccupation with RK's lies in that
you are trying to make ASPs talk to each other when
all is needed is SGs that talk to each other.

--brian

Dennis Niermann wrote:                                     (Tue, 06 Nov 2001 13:20:53)

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

---

---

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

Javier,

Javier Pastor-Balbas (ECE) wrote:                          (Tue, 06 Nov 2001 19:04:19)
> RC is required if your ASP serves more than one AS.

RC is only required for the AS/SG case.  For IPSP is is
clearly not require as it is arlready possible for two
AS to communiate via SGs without a single exchange
involving RC outside the IPSP: see diagram.

> If Registration is not required your model is not valid since
> it works only statically. Operators don't want that. It can be
> a proprietary protocol.

SS7 networks are statically configured.  Didn't you know that?
There is no route discovery protocol in SS7.  If two point
codes have not been statically assigned routes through the SS7
network they will simply not exchange MSUs.  I can't believe
that you don't know that!

> SNMM is required only when translating TFP, etc msgs from the
> SS7 network to the IP network. Don't make sense in all-IP
> commmunication. You have there other means as ASPIA, ASPAC, no
> routes restricted, no need to audit anyghing and SCTP
> congestion control mechanisms

They make plenty of sense, they are the only thing that
translate directly into the User primitives and leave the
status in the correct location.

> You don't need to create that restriction. IPSP can control a
> portion of the traffic to one entire point code as it is done
> by ASP.

No, ASP merely exports the SS7/User interface.  The SG controls
the point code, as it must, and is responsible for communicating
the status of the SPMC to SS7-Users in the manner in which they
require it, which corresponds to SNMM and are treated on a
per-point code basis.  This is a necessary restriction.

> ASPUP/DOWN needed between two IPSPs. I agree with that. But
> also you need to activate/deactivate the AS RKs... 

Nope.  Don'e need RCs and don't need ASPTM containing RCs.

> We need to exchange ASPSM, ASPST and DATA. And we have to
> allow to exchange RRM for the implementations they want to.

Sorry, look at the diagram.  The SG's exchange DATA and
SNMM.  Aside from the ASPSM messages.  But ASPTM is not
required.

> Man, you have created a monster...  ;-)

It already works. AS can communicate to each other via SGs.
This is requirement for SCCP.

What is it that you cannot stand about this arrangement?
It is fully functional.

> 
> The main thing here is that it seems that you don't have a
> clear idea of what you want.

The clear objective is to place the minimum and sufficient
information exchange between SGP to provide peer-to-peer
communications.  That is the existing M3UA messages.  Some
messages which apply only to ASPs are not required as these
are now internal relationships to the node that need not
be exposed.

Is that clear enough for you?

> But instead you know what you don't want. Give a working
> solution if you can and sent it out.

This already works.  It is recommended that SGP communicate
between them in support of AS.   AS are permitted to communicate
with each other via the SG.  SGP exchange messages between
them (DATA and SNMM) to accomplish this.

> And if you do it in time (before M3UA v10 is issued) the
> mailing list will decide what they want. :-D

I have already presented it.

> If you don't have a working solution, just try to be
> constructive and let's work out one from the basis we have...
> :-D

I have a working solution, it is you that do not.

--brian

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

---

---

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

Tolga,

Consider that I have a bunch of AS (MTP-Users) that represent
a CIC range for ISUP.  Why whould each of these AS register
(or need to be separately configured for) and have RCs
assigned to be able to exchange traffic with the peer ISUP?

In the AS/SG case these are each MTP-Users that must indicate
their availability to the MTP-Provider at the SGP to exchange
data with the provider.

In peer-to-peer, however, it is sufficient that the point
codes can communicate and that the DPC is accessible.  No
separate activation of each CIC range for each PC is needed
(whether static or dynamic).

For IPSP the MTP/MTP-User relationship is internal to the
node.  There is no reason to register it outside the IPSP
cluster.  The IPSP has all the information necessary to
represent the node to the outside world using SNMM.

The last thing I want to do is go assigning RC values (whether
single or double) or registering RKs at both ends of a network
just to add circuits to an MGC.

Does that make this view a bit clearer?

What did you think these RCs would be used for?

--brian

Tolga Asveren wrote:             (Tue, 06 Nov 2001 12:34:09)

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

---

---

From: Dennis Niermann <[email-masked]>
Date: Tue, 06 Nov 2001 17:00:28 -0600

Hi Tolga,
I know that there are disagreements about AS granularity
and ASPTM/SSNM. And that there are two aspects - 
are they needed? and can they work?

I could be alone in this feeling, but I feel that a lot of what 
makes this WG function at a less than an ideal level 
(that's my politically correct way of describing it) is
that there is not a common understanding and common acceptance
of key terms and concepts. Unfortunately, some of the names 
used (Application Server and Application Server Process for
example) can be misleading on the surface. Communication is
unproductive when people don't share a common understanding of
the language.

In the case of IPSP-IPSP, I have concluded that the exact 
meaning RC and RK has been at least partially to blame for
the different perspectives about what works and how it works 
in IPSP-IPSP. 
 
/Dennis

---

---

From: Amish Chana <[email-masked]>
Date: Tue, 06 Nov 2001 23:02:21 +0000

Hi Javier & Brian,

Let's modify the diagram slightly....

     ____________          ____________
    |   ______   |        |   ______   |
    |  |      |  |        |  |      |  |
    |  |  AS  |  |        |  |  AS  |  |
    |  |______|  |        |  |______|  |
    |     |      |        |     |      |
    |   __|___   |        |   __|___   |
    |  |      |  |        |  |      |  |
    |  | ASP  |__|_     __|__| ASP  |  |
    |  |______|  | \ A /  |  |______|  |
    |     |      |  \ /   |     |      |
    |   __|___   |   /    |   __|___   |
    |  |      |__|__/ \___|__|      |  |
    |  | SGP  |__|________|__| SGP  |  |
    |  |______|  |   B    |  |______|  |
    |____________|        |____________|
         IPSP-X                IPSP-Y

If the IPSP is defined as above:
A) The associations between the ASPs and SGPs would serve the provide the 
configuration the Javier and others suggest. Messages exit via the SGP and 
enter via the ASP. Futhermore, this method also allows one to have an IPSP 
that only serves a portion of a point code's traffic.
B) Since the SGPs are already present a connection between SGP and SGP 
should technically also be possible and provide Brian his proposed 
connectivity. In this case a SG could also have a distributed pure ASP 
behind it.

Why not suggest both as possible IPSP cases? Each method has its 
advantages/disadvantages.

The above also makes use of concepts that have already been defined for the 
pure ASP and SGP scenario.

To quote Javier in a parallel thread, "We don't have to reinvent the wheel." 
;-)

Amish.

>If Registration is not required your model is not valid since it works only 
>statically. Operators don't want that. It can be a proprietary protocol.
>
>SNMM is required only when translating TFP, etc msgs from the SS7 network 
>to the IP network. Don't make sense in all-IP commmunication. You have 
>there other means as ASPIA, ASPAC, no routes restricted, no need to audit 
>anyghing and SCTP congestion control mechanisms
>
>You don't need to create that restriction. IPSP can control a portion of 
>the traffic to one entire point code as it is done by ASP.
>
>We need to exchange ASPSM, ASPST and DATA. And we have to allow to exchange 
>RRM for the implementations they want to.
>
>The main thing here is that it seems that you don't have a clear idea of 
>what you want. But instead you know what you don't want. Give a working 
>solution if you can and sent it out. And if you do it in time (before M3UA 
>v10 is issued) the mailing list will decide what they want. :-D
>
>If you don't have a working solution, just try to be constructive and let's 
>work out one from the basis we have...  :-D
>
>
>Cheers // Javier.
>
>
> > --brian
> >
> > Amish Chana wrote:

---

---

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

Amish,

Your diagramatic comparison follows my understanding of the
approaches as well.  (A), just as you have diagrammed it,
has always caused me problems because somehow half a state
machine (MTP or SCCP state machines) is in one node and
*another* (not necessarily the other) half is on the other
node.  This makes IPSP-X responsible for IPSP-Y's state
(state of AS, state of the Point Code, state of the subsystem)
and IPSP-Y responsible for IPSP-X's state.  It is unworkable
to attempt to make all the nodes that communicate with IPSP-X
responsible for IPSP-X's user and node state.  Also it is
unworkable to attempt to make IPSP-X responsible for the
user (AS) and node (PC) state of all the IPSPs with which it
communicates.  And, yet, this is what (A) attempts to do.
The SGP function on IPSP-X is forced to track the AS state
of all the remote AS to which it communicates.  And the
SGP functions of all the IPSPs that communicate with the
ASP function in IPSP-X are forced to track the AS state
of the AS that are otherwise completely local to IPSP-X.

So, (B) is necessary and sufficient.  (A) provides an unworkable
situation at granularities of RC finer than an SPMC.  At
RC granularity equal to an SPMC, (A) collapses to (B) and
the unworkable situation of tracking remote AS and SPMC
state reduces to tracking the state of the associations only.

To amplify the unworkability of (A), consider that IPSP-X
has a separate AS for each of 16000 CICs (this is legal).
In (A), the SGP function at IPSP-Y is forced to configure
or register and track the state of the 16000 AS that belong
to IPSP-X and somehow ammalgamate that into an SNMM view
towards its local MTP users.

Consider that IPSP-X is an SUA database (SCP/HLR).  In SUA we
can legally have as many AS associated with an SSN on IPSP-X
as there are numbers in the telephone book, we could force
every other IPSP (i.e., all MGCs) communicating with IPSP-X
to maintain the AS state and SPMC state for the millions of
AS at IPSP-X.

Having an IPSP force its internal configuration on the rest
of the network in this fashion is not practical, any there
has been no benefit shown of doing (A) at all, far less a
benefit that would justify such a configuration nightmare.

--brian

Amish Chana wrote:                                          (Tue, 06 Nov 2001 23:02:21)

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

---

---

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

Hi Brian,
Thanks for your answer, see below...

> the AS at the ASP and used to identify traffic in the reverse
OK. I think that this RK defintion is consistent with the 
definiton #1 that I defined, so I agree.
For the RC, I may have worded it slightly differently to 
say that for traffic sent to the ASP, the RC identifies the AS
that the DATA message is being sent to and for
traffic from the ASP the RC identifies the AS sending the 
DATA message. Based on your next paragraph, I think that
you would agree.

> value identifies traffic in both directions.  Understand?
I think so. This may seem trivial, but becomes more 
significant when talking IPSP-IPSP later. So long as by 
"both directons" we mean "to the AS" and "from the AS",
i.e. in both cases identifying the AS.

> the AS for the same association.
OK.

> implicity label with RC in this way.
OK. A key point is that you say that at the SGP the RC is 
identifying the AS source. I agree.

> of anything at the sub-PC level is necessary with ASPTM.
Seven paragraphs so far and this is my first disagreement 
with you. I think that we are making some real progress here! :)
If a sub-PC level AS at the IPSP is never required, then you 
are correct that SNMM would suffice. But, I believe that 
there is no reason to make that limitation. 

As for as being a requirement... I think that if sub-PC level
AS's are useful in the case of communicating with 
real SS7 destinations, then they are equally useful when 
communicating with other M3UA-based AS's. 
 
As for as being workable... I think that sub-PC level AS's
are equally workable for the IPSP-IPSP case as they are for
the SGP-ASP case. I believe that previous concerns that you
have expressed are just as relevant for the SGP-ASP case. 

For example, you previously mentioned that an IPSP would have 
a problem if it lost access to the remote AS for PC=3,SI=5
but still had access to remote AS PC=3,SI=3.
But consider that an SGP would have a very similar
problem. Just like the IPSP can not indicate PAUSE to its
local ISUP user, the SGP can not send a TFP to an SS7 node.
And, it is also not entirely correct for the SGP to tell an SS7 
node that the ISUP user at PC 3 is unavailable. 

> all is needed is SGs that talk to each other.
I'll admit to a preoccupation with consistent and clear
use of terminology, but I am not yet ready to admit to being
confused :)
ASPs need to talk to each other (IPSP sending data like a SGP) 
if sub-PC AS's or multiple ASs at an IPSP are to be supported.
SGPs talking to each (IPSP sending data like a ASP) can probably
work if neither sub-PC AS's nor multiple AS's at an IPSP are 
required.

---

---

From: Verwimp Gery <[email-masked]>
Date: Wed, 7 Nov 2001 09:27:58 +0100

Javier,

I couldn't agree more. Where Brian got this delusional idea to declare the
SNMM messages holy for the point-to-point IPSP case goes beyond me. And
what's this AS-ASP-IPSP stack nonsens ? Mixing logical and physical entities
? Throw everything on a big heap and hope it magically works ?

For point-to-point the ASPTM are sufficient and necessary, and covers any
case (entire point codes or finer for whatever reason). Same reasoning as
with the NA/RC discussion. Congestion indication we get from the SCTP.

Brian, in point-to-point, when the SCTP association goes down you can't get
any message across. So what's the benefit of using SNMM over ASPTM here ???
Please think before you draw a picture like that. DUNA, DAVA, SCON etc. we
get via SG through which we want to reach the unavailable or
congested/restricted SEP. We won't get there before we discuss the relay
function of an IPSP. And if ASPTM is insufficient for IPSPs, then it surely
is for ASPs; an ASP can't signal congestion to the SG either via SNMM nor
ASPTM. It shouldn't have to : it's a single process handling the traffic of
it's associations, if it can't follow, the associations get congested.
Simple.

More than one process can handle a specific part of the traffic. One process
can handle several RKs. Please put a little consistency in your thinking.

____________________________

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

-----Original Message-----
From: Javier Pastor-Balbas (ECE)
[mailto:[email-masked]]
Sent: dinsdag 6 november 2001 19:04
To: sigtran
Subject: RE: Consensus Call - Routing Key

Brian, 

Comments below...

>   3.)  SNMM is required.  SGs exchange SNMM messages.
SNMM is required only when translating TFP, etc msgs from the SS7 network to
the IP network. Don't make sense in all-IP commmunication. You have there
other means as ASPIA, ASPAC, no routes restricted, no need to audit anyghing
and SCTP congestion control mechanisms

>        the SGs control an entire point code.
You don't need to create that restriction. IPSP can control a portion of the
traffic to one entire point code as it is done by ASP.

>        have RCs and we don't do RKMM.

ASPUP/DOWN needed between two IPSPs. I agree with that. But also you need to
activate/deactivate the AS RKs... 

Cheers // Javier.

> [email-masked]

---
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: Wed, 7 Nov 2001 02:54:48 -0600

Gery,

Calm down.  RC values are assigned to traffic on the basis of
RK analysis on the message in the forward direction.  It is
always possible at an IPSP to apply any routing keys that are
necessary to incoming messages to determine to which AS the
message is destined.  It is always possible at the IPSP to,
from the local state of the AS and the contents of the message
determine the appropriate SNMM response.

The only reason we used RC in data messages in the SGP to ASP
direction was to that the ASP would not have to know about or
apply RKs to received messages to determine AS.  The IPSP cannot
escape applying RKs and is fully welcome to apply RK to incoming
messages to determine AS.  The IPSP does not need RC in the
message.  RC values can be determined at the receiver of the
messages by applying the RK to the message.

For the outgoing side, messages need to be routed on the basis
of status within an SS7 context (congestion, availability,
inaccessibility, unequipped entities).  The availability of
associations and the point-to-point nature of IPSPs permits
this to be performed without RK analysis and without the need
to place RC in outgoing messages.

Because IPSPs have the functions necessary to perform RK analysis
on messages, RC never needs to be exchanged, configured, or
registered between IPSPs.

As for the need for SNMM, the lack of the ability for ASPTM to
communicate necessary status and the lack of a need for RC at
all, is clear.

Perhaps a good example is SCON.  When an MTP becomes congested
at an IPSP/SEP (and, no, that's not an association, but the MTP
state machines and processes themselves and even an MTP user
application) it signals SCON to is peers to indicate the congestion.
Even in the AS/SG case, the ASP sends SCON to the SGP to indicate
application congestion and the SGP can turn this into a TFC to
the network.  Not allowing the ASP function in the IPSP to signal
SCON to other users on other IPSPs would break this MTP-User
(MTP-STATUS) and SCCP-User (N-PCSTATE) behavior.

ASPTM is focussed at alowing an ASP to signal to an SG the
activity of an AS (slice of an SS7-User) so that the SG can
amalgamate these activities into SNMM events that are meaningful
to remote users.  There is simply no reason to make the remote
IPSP do this work for local AS when it is fully within the local
IPSP's abilities to do so.

This double-ended model forces an IPSP to track the state of
*remote* AS.  Neither the ASP nor the SGP in the AS/SG case
track the activity of *remote* AS, only *local* AS.

When the IPSP is made responsible only for tracking the activity
of *local* AS (as in the AS/SG case), then RC no longer needs to
be exchanged between IPSP, just SNMM.  Registration and configuration
of RCs between IPSPs is not required.

The only reason that RC management is required in the AS/SG case
is because the AS as MTP/SCCP-Users are *local* to the SG as well
as *local* to the ASP.  This single state must be coordinated
between SG/AS to present a proper view of the state of the AS.
This view of the activity of the AS is never exposed to remote SS7
Users, SNMM is used to inform remote SS7 Users of the state of
entities in the network.

It is not necessary for an IPSP to expose the activity of *local*
AS (Users) to its peers.  Remote users are sufficiently and
necessarily informed by using SNMM.

The RC which is used to coordinate the view of *local* AS
activity between SGP and AS has been turned to try and force
the remote IPSP to *remote* AS state for all IPSPs to which
it is connected anc communicates.  That is rather absurd.
What delusion caused anyone to think that it was necessary for
an IPSP to track the state of *remote* AS?

--brian

Verwimp Gery wrote:                                       (Wed, 07 Nov 2001 09:27:58)
> ASPTM.
> It shouldn't have to : it's a single process handling the traffic of
> Fax: +32 14 25 3212

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

---

---

From: "Javier Pastor-Balbas (ECE)" <[email-masked]>
Date: Wed, 7 Nov 2001 09:54:16 +0100

Brian, 

See my short comments below...

> Sent: Wednesday, November 07, 2001 9:31 AM
> To: sigtran
> I should point out several things about RK that were agreed
> for the AS/SG that are not applicable for IPSP.
> 
Do you want to change M3UA protocol so far ???  :-O

> The reason for labelling DATA in the forward direction from
> SGP to AS with RC was so that the ASP would not need to
> reapply the RK to received messages to determine the AS to
> which the message is delivered.  By labelling DATA with RC
> after RK analysis at the SGP, the SGP saves the ASP from
> repeating this RK analysis.  In this way, the ASP does not
> need to maintain RKs nor apply them to DATA messages to
> determine AS.  In the reverse direction, the ASP, knowing the
> AS that is sending the message, labels DATA with RC so that
> the SGP can perform ASPTM on the incoming DATA message even
> when a reverse RK does not exist.  This leaves protocol
> variant and NA specific RK analysis at the SG and the ASP need
> not examine the contents of DATA messages to perform its
> function.
> 

Brian, the use of RC in M3UA is only compulsory for the case where you have more than one AS that is served by the same ASP. Remember the definition we agreed (I expect you don't want to change it as well...)

 Routing Context: 32-bits (unsigned integer)
 
    The Routing Context parameter contains the Routing Context 
    value associated with the DATA message.   Where a Routing Key
    has not been coordinated between the SGP and ASP, sending of
    Routing Context is not required.  Where multiple Routing 
    Keys and Routing Contexts are used across a common association
    and is used to assist in the internal distribution of Data messages, 
    Routing Context MUST be sent to identify the traffic flow.
 
Any other uses of RC are implementation dependat.

> I would like to consider the SNMM messages in a separate message, as
> there have been different considerations expressed about NA and RC
> in SNMM messages.

> In the DE IPSP proposal, the IPSP is performing RK analysis on
> outgoing messages and labelling DATA with RC.  But this serves
> no purpose to the receiving IPSP.  The receiving IPSP must
> maintain its own set of NA and protocol variant specific RKs
> and perform RK analysis on all the messages it sends.
> 

IPSP will only label data with RC if there are more than one RK (and therefore RC) that are used over one association. It follows the definition 100%.

> Because each IPSP needs to maintain RKs and perform NA/variant
> specific analysis, the IPSP might as well perform this on
> *incoming* messages instead of *outgoing* messages.  When this
> is performed, no RC needs to be placed in the DATA messages.
> The local AS at the IPSP is determined for incoming messages
> by performing RK analysis on the incoming data messages using
> local knowledge of AS configuration.  

This is the main reason because only sending one RC in DATA is enough. It's completely compliance with the protocol messages

> In this way, the IPSP
> does not need to maintain or register RC values and RC values
> never need to be communicated, registered or configured
> between IPSPs.
> 
> On received messages, the IPSP performs internal analysis on
> the contents of messages to determine the SS7-User (AS) to
> which to propagate the message.  Outgoing messages from the
> IPSP are routed using normal SS7 routing tables and techniques
> (based on the availability of associations to other IPSPs and
> the receipt of SNMM messages) and need not be labelled with
> RC.
> 

It is the same routing SGP has to do when sending DATA msgs to ASP.
SNMM messages has no sense at all in an all-IP scenario. Take a look to their definition. Do you also want to change this?

> So you see, the only reason for labelling data and snmm with
> RC was to save the ASP from the specifics of routing keys.
> The IPSP cannot be saved from the task of routing, so there is
> no need for RC.  By applying RKs in this fashion at the IPSP,
> the adminstrative burden of configuring or registering RC
> values is removed from the IPSP.  Essentially, the IPSP can do
> without RC-based ASPTM and without RC in DATA an SNMM.  It wil
> be very hard to force an IPSP implementation to use RC values
> when it can do without them.  Their purpose is for the AS/SG
> backhaul case only, where it is possible to remove the burden
> of NA/variant specific RK maintenance and analysis from the
> ASP altogether.
> 

So, concluding, if you:

- change the M3UA protocol, 
- don't have more than one AS per IPSP, 
- change the definition of SNMM messages and their purpose
- don't allow the use of REGISTRATION, 
- don't allow the use of ASPTM

then and only then, you can make your monster work...  :-/

(at least it seems that RC can remain like it is right now...)

Cheers // Javier.

> I hope this clears up RKs and RCs for you.
> 
> --brian
> 
> 
> Dennis Niermann wrote:              (Tue, 06 Nov 2001 17:54:23)
> > Hi Brian,
> > confused:)
> [email-masked]

---

---

From: Verwimp Gery <[email-masked]>
Date: Wed, 7 Nov 2001 10:00:12 +0100

Brian,

See below ...

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]]
Sent: dinsdag 6 november 2001 23:38
To: sigtran
Cc: [email-masked]
Subject: Re: Consensus Call - Routing Key

Tolga,

=====>
[GV] : Excuse me : the AS *is* the CIC-range for ISUP. I suppose you mean a
bunch of ASPs. And if you don't want to split CIC ranges, you simply don't !
Then use a single RC for the entire ISUP AS.
<=====

=====>
[GV] : The same reasoning can be used for AS/SG case. No compelling reason
there either to split up CIC ranges. And especially in AS/SG cases, it would
be better not to split because of the SS7 NM interworking. So why do you
allow this here and not in IPSP ? It's either go or no go for both.
<=====

=====>
[GV] : You're stuck to a backhaul way of thinking. That may be true (but you
can get around this as well) if SG is an SS7 SEP and the ASPs really only
have an association with this one SG. SG and ASPs are then one big node. It
already gets a lot different when the SG is an STP, and the ASP has multiple
associations with multiple SGs. The MTP/MTP-user "relationship" is internal
to the ASP here as well. How else would it operate ?
<=====

=====>
[GV] : Brian, use of RC (either dynamic via REG or static) doesn't compell
you to split beyond a point code. They perfectly allow you to stay on
point-code level. You may even use SNMM messages in the IPSP case; what's
there to prevent you ?
<=====

=====>
[GV] : Either purpose would be fine. Why restrict ?
<=====

--brian

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

---

---

---

From: Verwimp Gery <[email-masked]>
Date: Wed, 7 Nov 2001 10:18:31 +0100

Dennis, Brian,

I have a slightly different view, but at least now we're getting somewhere.

When the ASP registers (dynamic with REG or static by config), it let's the
SG know by RK parameters which SS7 traffic it is willing to receive. Hence
RK and RC define the traffic flow in SG->ASP direction. So far so good.

Now the nature of SG is that it provides SS7 interworking, but doesn't
explicitly advertise (register) this. In fact, we wouldn't need RC in
ASP->SG direction, if it weren't for the different MTP networks an SG might
be configured in. The SG otherwise exactly knows how to route based on
routing label for M3UA and destination address for SUA.

What is implicitly happening in my view is that SG automatically "registers"
the same RK back to ASP (it can handle any traffic sent to SS7) and ASP
"assigns" the same RC. So although one registration is explicitly done, and
one RK/RC set is defined, it's used in both directions. It's put to double
use if you want.

Now in IPSP case, we have to make explicit RK/RC advertisements for both
directions, because we can't make the same assumptions for an IPSP as we did
for SG(P). This is the key point. Both IPSPs have to tell the other which
SS7 traffic portions they are willing to handle. And the view that only one
RC defines the traffic flow in both directions isn't correct, because it is
attached to a single RK, advertised by essentially one party only.

Regards,

Gery Verwimp
Fax : +32 14 25 3212

-----Original Message-----
From: Dennis Niermann [mailto:[email-masked]]
Sent: woensdag 7 november 2001 0:54
To: sigtran
Subject: Re: Consensus Call - Routing Key

Hi Brian,

OK.

 

---

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 7 Nov 2001 03:23:39 -0600

Javier,

Javier Pastor-Balbas (ECE) wrote:                          (Wed, 07 Nov 2001 09:54:16)
> Brian, the use of RC in M3UA is only compulsory for the case where you have
> more than one AS that is served by the same ASP. Remember the definition we
> agreed (I expect you don't want to change it as well...)
> 

And this is so the ASP does not need to perform RK analysis on
incoming messages.  If the ASP knows the RK that corresponds to
the RC, it is perfectly capable of applying the RK to incoming
messages and deriving its own RC value.  The RC value is placed
in the message so that the ASP need not apply or know about RKs.
This is what is meant by "assist in the internal distribution".
And the MUST is because the SGP cannot know if the ASP is RK
aware or not.

Perhaps you missed the discussion on Routing Context?

> IPSP will only label data with RC if there are more than one RK (and
> therefore RC) that are used over one association. It follows the definition
> 100%.

For IPSP it is not necessary to "save" the ASP from applying a
RK to incoming messages, because the IPSP must examine the contents
of message to perform outgoing routing anyways.  The MUST is only
for an SGP talking to an ASP.

> This is the main reason because only sending one RC in DATA is enough. It's
> completely compliance with the protocol messages

There is no need to coordinate AS state across IPSPs and attempting
to do so causes unnecessary complication.

> It is the same routing SGP has to do when sending DATA msgs to ASP.

Err, no...  When an SGP routes messages to an ASP it is
routing messags to a **LOCAL** user.  When an IPSP routes
messages, it is routing messages to a **REMOTE** user.

> SNMM messages has no sense at all in an all-IP scenario.

ASPTM is the SGP/ASPs way of informing each other of the
state of the **LOCAL** user.  SNMM is the SGP/ASP and IPSPs
way of informing the **REMOTE** user.

IPSPs only need to inform the **REMOTE** user of the state
of the node and only SNMM are necessary.  ASPTM is only
meaningful betweer SGP and ASP sharing the same **LOCAL**
user.

> Take a look to their definition. Do you also want to change
> this?

No change.  You are just preoccupied with the backhaul case
and the definitions of backhaul terms.

> - change the M3UA protocol, 

No change.

> - don't have more than one AS per IPSP, 

An IPSP can have as many **LOCAL** AS as it likes.  It just
doesn't need to broadcast their existence to the world.

> - change the definition of SNMM messages and their purpose

They are used in the same fashion: for informing the **REMOTE**
user.

> - don't allow the use of REGISTRATION, 

No need: registration is a thing to permit ASP and SGP to agree
on the partiioning of **LOCAL** users that they share.  IPSPs
share no **LOCAL** users and do not need registration.

> - don't allow the use of ASPTM

ASPTM is for SGP and ASP to coordinate state concerning **LOCAL**
AS.  As IPSP never need to corrdiate copies of **LOCAL** AS
activity between IPSPs they are not needed.

> then and only then, you can make your monster work...  :-/

It works already.  AS can comunicate in this fashion via
SGP and the SS7 network today, without changing anything in
the draft.

--brian

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

---

---

From: Verwimp Gery <[email-masked]>
Date: Wed, 7 Nov 2001 10:25:53 +0100

Hi all,

This is all a little artificial (A & B would be the same SCTP association,
or are there 2 separate ones ?) and this split-up isn't needed, even
conceptually, if the nature of RK/RC registration in both directions is well
understood.

ASP->SG registration was up to now the only one made explicit. SG->ASP
registration was understood implicitly by nature of the SG. IPSP simply has
to handle it both ways. I hope I was elaborate enough in my previous mails
to make this point.

The figure is misleading in the sense that a logical AS may span several
IPSPs. It isn't tied to a single one.

Gery Verwimp
Fax : +32 14 25 3212

-----Original Message-----
From: Amish Chana [mailto:[email-masked]]
Sent: woensdag 7 november 2001 0:02
To: sigtran
Subject: RE: Consensus Call - Routing Key

Hi Javier & Brian,

;-)

Amish.

---

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 7 Nov 2001 03:30:55 -0600

Verwimp,

Verwimp Gery wrote:                                       (Wed, 07 Nov 2001 10:00:12)
> [GV]: Excuse me : the AS *is* the CIC-range for ISUP. I suppose you mean a

CIC Ranges are a valid routing key.

 |Circuit Range:
 |
 |   An ISUP controlled circuit is uniquely identified by the SS7 OPC, 
 |   DPC and CIC value.  For the purposes of identifying Circuit Ranges 
 |   in an M3UA Routing Key, the optional Circuit Range parameter 
 |   includes one or more circuit ranges, each identified by an OPC and 
 |   Upper/Lower CIC value.  The DPC is implicit as it is mandatory and 
 |   already included in the DPC parameter of the Routing Key.  The 
 |   absence of the Circuit Range parameter in the Routing Key indicates 
 |   the use of any Circuit Range values, in the case of ISUP/TUP 
 |   traffic.  The Origination Point Code is encoded the same as the 
 |   Destination Point Code parameter, while the CIC values are 16-bit 
 |   integers.
 |
 |   The Circuit Range format is as follows:
 |
 |    0                   1                   2                   3
 |    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 |   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |   |           Tag = 0x020f        |              Length           |
 |   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |   |    Mask = 0   |          Origination Point Code #1            |
 |   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |   |       Lower CIC Value #1      |      Upper CIC Value #1       |
 |   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |   |    Mask = 0   |          Origination Point Code #2            |
 |   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |   |       Lower CIC Value #2      |      Upper CIC Value #2       |
 |   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |   /                              ...                              /
 |   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |   |    Mask = 0   |          Origination Point Code #n            |
 |   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |   |       Lower CIC Value #n      |      Upper CIC Value #n       |
 |   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

> [GV]: The same reasoning can be used for AS/SG case. No compelling reason

Please, split them up in IPSP but don't expose them to the world.
Peer IPSP don't care how an IPSP splits up its AS.  It only cares
how to represent the network to its users and how to get messages
to and fro.

> [GV]: You're stuck to a backhaul way of thinking. That may be true (but you

The MTP/MTP-User relationship is shared across SGP/ASP.  Procedures
are required so the state and activity of this relationship can be
synchronized between SGP and ASP.  IPSPs have no need to synchronize
their local MTP/MTP-User relationship with IPSP peers.  SNMM (DUPU)
is enough.

> [GV]: Brian, use of RC (either dynamic via REG or static) doesn't compell

The remote IPSP does no need to know the activity of the local IPSPs
AS.  RC is not require, only SNMM.

> [GV]: Either purpose would be fine. Why restrict ?

Because the management of RCs is not necessary in the IPSP case.

--brian

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

---

---

From: Verwimp Gery <[email-masked]>
Date: Wed, 7 Nov 2001 10:31:58 +0100

Brian,

See below.

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]]
Sent: woensdag 7 november 2001 1:12
To: sigtran
Cc: [email-masked]
Subject: Re: Consensus Call - Routing Key

[snip,snip]

On the contrary, the SGP is in control of the whole point
code (SPMC).  It is easy for the SGP to decide when to send
UPU and when to send TFP.  The SS7 stack at the SGP does
this for local users every day even in pure SS7 nodes.
The problem in the IPSP example is that the IPSP is made
responsible for tracking the AS (e.g., MTP-Users) of
*remote* nodes.  It is a far simpler and less problem prone
solution to let the node keep track of its own AS (Users)
and represent that to other IPSPs using SNMM in the same
fashion in the SS7 network today.

> work if neither sub-PC AS's nor multiple AS's at an IPSP are 

You see, not only is the IPSP tracking the state of all remote
AS unworkable, but it is unnecessary.  No benefit can be gained
from fragmenting management in this way, because it has to be
amalgamated back together to be presented to the SS7-User local
to the IPSP using the existing SS7-User interface.

See also my response to Amish on this thread.

[GV] : Brian, the IPSPs tracking of AS state is no different from what the
SG does. More than 1 IPSP can service the same AS. And the AS is available
to the SS7-user, as long as 1 IPSP is actively serving. IPSP simply keeps
track (and has to do this anyway) of the state of the SCTP associations
(point-to-point) with the other IPSPs, based on ASPTM and SCTP indications
(congestion, communication down etc.)

--gery

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 7 Nov 2001 03:34:34 -0600

Verwimp,

Verwimp Gery wrote:                                       (Wed, 07 Nov 2001 10:18:31)
> attached to a single RK, advertised by essentially one party only.

What does one IPSP care about the state of another IPSP's AS?

--brian

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

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 7 Nov 2001 03:42:01 -0600

Gery,

Verwimp Gery wrote:                                       (Wed, 07 Nov 2001 10:31:58)

> 
> [GV]: Brian, the IPSPs tracking of AS state is no different from what the
> SG does.

It is different:  An SG tracks its own AS (local users).  You have the IPSP
tracking all the other IPSP's ASs.

> More than 1 IPSP can service the same AS. And the AS is available
> to the SS7-user, as long as 1 IPSP is actively serving.

What does one IPSP care of the state of another IPSP's AS?

> IPSP simply keeps

SCON cannot be derived from SCTP congestion:

    "The M3UA layer at an ASP or IPSP MAY indicate local congestion to an 
     M3UA peer with an SCON message.  When an SG receives a congestion 
     message (SCON) from an ASP, and the SG determines that an SPMC is now 
     encountering congestion, it MAY trigger SS7 MTP3 Transfer Controlled 
     management messages to concerned SS7 destinations according to 
     congestion procedures of the relevant MTP3 standard.

--brian

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

---

---

From: "Javier Pastor-Balbas (ECE)" <[email-masked]>
Date: Wed, 7 Nov 2001 10:45:03 +0100

Brian, 

See comments below..

> Sent: Wednesday, November 07, 2001 10:24 AM
> To: Javier Pastor-Balbas (ECE)
> Cc: sigtran

The same case happens in IPSP communication. You send RC to "assist" in detecting the right AS although it could get the right AS working a little more and analysing the RK, and you can send RC if no dynamic registration has happened what make sense with the MUST.

> for an SGP talking to an ASP.
I'm talking about incoming messages and not outcoming. If you receive RC you don't have to analyse the addressing parameters again. Of course you will do when sending msgs to the other peer, in the same way an SGP does it when sending msgs to an ASP. 

> to do so causes unnecessary complication.

If we allow to have more than one AS per ASP, we also need to allow more than one AS per IPSP. 

> messages, it is routing messages to a **REMOTE** user.

In both cases the routing procedures is the same:
- Get the addressing parameters
- Match them with a RK
- Get the RC/AS
- Find and active ASP
- Send msg to that ASP

> way of informing the **REMOTE** user.
ASPTM is more, is the way of informing the other end of the traffic it wants to receive. It's also a way of informing if the AS is processing traffic or not.

SNMM only makes sense as a translation of SS7 procedures (TFP, TFA, TFC, ...)

> doesn't need to broadcast their existence to the world.
Then you only allow static configuration... not good.

> They are used in the same fashion: for informing the **REMOTE**
You forget that it is a translation of SS7 messages that informs about availability/congestion of other nodes not accessible in a peer to peer basis.

> share no **LOCAL** users and do not need registration.

Registration allows the network be dynamic and it's vital between different operators. We can not exclude it from the model.

> activity between IPSPs they are not needed.
ASPTM allow know status of the remote AS (not located in the same node) and allow to activate/deactivate ASs. Also needed.

> SGP and the SS7 network today, without changing anything in

You change or remove basic procedures that are agreed today (registration, ASPTM, multiple ASs per IPSP). From my point of view this is not acceptable.

I would like to see more opinions about this.... 

Cheers // Javier.

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 7 Nov 2001 04:12:03 -0600

Javier,

Javier Pastor-Balbas (ECE) wrote:                          (Wed, 07 Nov 2001 10:45:03)
> The same case happens in IPSP communication. You send RC to "assist" in
> detecting the right AS although it could get the right AS working a little
> more and analysing the RK, and you can send RC if no dynamic registration
> has happened what make sense with the MUST.

The IPSP is already doing RK analysis independent of the sending
IPSP's view of AS division.  Therefore, there is no need to send it.

> I'm talking about incoming messages and not outcoming. If you receive RC you
> don't have to analyse the addressing parameters again. Of course you will do
> when sending msgs to the other peer, in the same way an SGP does it when
> sending msgs to an ASP. 

An IPSP does not care about the activity of another IPSP's AS.
It need not perform RK analysis on outgoing messages (just MTP/SCCP
routing) and need not perform RK analysis on incoming messages
(just MTP/SCCP distribution).  An IPSP cannot be required to view
the world according to another IPSP's internal division of AS.

> If we allow to have more than one AS per ASP, we also need to allow more

Have 'em.  Other IPSPs are not required to know about them.

> - Get the addressing parameters

No.  For remote (outgoing) routing, MTP/SCCP routing rules
can be used.  The IPSP need not maintain outoing RK because
it doesn't care about another IPSP's internal AS arrangements.

> ASPTM is more, is the way of informing the other end of the traffic it wants
> to receive. It's also a way of informing if the AS is processing traffic or
> not.

What does one IPSP care about the activity of another IPSP's AS?
ASPTM is not needed.

> SNMM only makes sense as a translation of SS7 procedures (TFP, TFA, TFC,

It makes sense because this is the terms in which the IPSP
must reflect the state of the network to its users.  You
hadn't intended on changing the MTP/MTP-User and SCCP/SCCP-User
interfaces, had you?

> Then you only allow static configuration... not good.

The SS7 network is statically configured... sufficient.

> You forget that it is a translation of SS7 messages that informs about
> availability/congestion of other nodes not accessible in a peer to peer
> basis.

SNMM is peer to peer information.

> Registration allows the network be dynamic and it's vital between different
> operators. We can not exclude it from the model.

SS7 has no dynamic routing protocols.  Operators do not need
a dynamic SS7 network.  SS7-users cannot deal with them anyway.

> ASPTM allow know status of the remote AS (not located in the same node) and
> allow to activate/deactivate ASs. Also needed.

The IPSP does not care about the state of another IPSP's AS.  It
is not necessary for the IPSP to know this information to reflect
the state of the newtork to its SS7-Users.  It only needs SNMM
for this.

> You change or remove basic procedures that are agreed today (registration,
> ASPTM, multiple ASs per IPSP). From my point of view this is not acceptable.

You attempt to misapply backhaul procedures to peer-to-peer
arrangements.  SS7 works just fine without ASPTM and without RCs.

--brian

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

---

---

From: Verwimp Gery <[email-masked]>
Date: Wed, 7 Nov 2001 11:35:25 +0100

Brian,

Down under ...

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]]
Sent: woensdag 7 november 2001 9:31
To: sigtran
Cc: [email-masked]
Subject: Re: Consensus Call - Routing Key

Dennis,

=====>
[GV] : Why not ? This saves the IPSP the trouble of performing RK analysis
again when it is serving multiple AS. Remark that in SUA, we don't format a
routing label, and the PC aren't necessarily in the addresses (routing on
GT). In general, the RC label MUST be there. When the IPSP receives traffic,
it's a sign it registered for this, thus it got an RC assigned for it by the
remote end. So use it. 

On the sending side, it has to perform it's own RK analysis based on the RKs
it got from other IPSPs. For these, it assigned an RC value itself and thus
should label it's DATA messages with it for the receiver's sake. (Combined
SG/ASP behaviour, sending/receiving).
<=====

local knowledge of AS configuration.  In this way, the IPSP

=====>
[GV] : Same discussion we had for NA/RC. This leaves you with at least
having to include the NA parameter again, because an IPSP may get traffic
for several variants (different networks) on 1 association. So why not use
the RC in general ?
<=====

=====>
[GV] : Sorry Brian, but I don't agree with your view here. ASP *knows* the
speficis for RKs, it registers/configures them for starters. The
administrative burden you mention all depends on how fine we're going with
the granularity of your RKs; it's not up to us to put a restriction on this.
And without RC, you're still stuck with the NA ... the sending IPSP should
be aware of the variants the other IPSP is supporting, and the receiving
IPSP should know for what variant it is receiving a message.

--gery

---

---

From: Amish Chana <[email-masked]>
Date: Wed, 07 Nov 2001 10:51:46 +0000

Hi Gery,

>conceptually, if the nature of RK/RC registration in both directions is 

The intention is not two have two associations. It simply illustrates the 
two different competing views.

The think the intention behind IPSP support in M3UA and SUA was to use the 
existing functionality that has already been defined for ASP and SGP 
communication to achieve IPSP connectivity rather than redefine new 
functionality for the ASP (or SGP).

The question comes down to: Can the existing ASP and SGP functionality be 
used to transport messages between application servers? Sure, it may require 
using both the SGP and ASP but there is now no need redefine the ASP to now 
have SGP funtions for the IPSP.

Gery, do you think the method of using RCs between IPSPs can not be achieved 
with option (A) or is additional ASP functionality necessary? If cannot be 
achieved with (A), what more has been provided above and beyond the existing 
ASP and SGP functions? We have passed last call should we be introducing new 
features/functions?

Amish

---

---

From: Verwimp Gery <[email-masked]>
Date: Wed, 7 Nov 2001 12:18:08 +0100

Brian,

Well, you got my view on previous occasions, but once more ...

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]]
Sent: woensdag 7 november 2001 9:55
To: Verwimp Gery
Cc: sigtran
Subject: Re: Consensus Call - Routing Key

Gery,

=====>
[GV] : When you have RKs, you have RCs, and you have traffic management. No
reason to restate their definitions in the IPSP case. In fact, RC is mighty
useful in IPSP case as well. If not, what do you do with network appearance
? The lack of routing label in SUA messages ? Finer granularities than PC
(e.g. SSN) ? It's not up to us to put restrictions here ... just
implementation notes ;))
<=====

=====>
[GV] : In multiple SG case, I could think of cases where the ASP also has to
perform some RK analysis before it sends out a message. Anyway, the RK
analysis must be done on the sending side, so why not label it with RC
afterwards ? Why repeat it at the receiving side (if at all possible) ? The
IPSP should know for what traffic it registered, so pick up the RC.
<=====

=====>
[GV] : Wrong. The ASP doesn't send SCON (it cannot in general, e.g. when
you're handling CIC ranges). And even if it did, the SG is in general
incapable of informing the SS7 network (multiple ASPs in 1 AS). The use of
SNMM messages is informative from SG->ASP (MTP-STATUS and N-PCSTATE
INDICATIONS).

And if MTP-users signal congestion to one another, they won't use SNMM but
their own messages transported in the M3UA DATA primitives. (e.g. SCCP
subsystem management messages). The M3UA state itself is clear from ASPTM,
and if you like, we can add a congestion level parameter to it.
<=====

=====>
[GV] : Huh ? If the IPSP doesn't track, what's the use of any management
scheme ? Let me spell it out :

- IPSP knows the state of it's communication partners (connected IPSPs who
have registered for some RKs) through SCTP association management and ASPTM
- IPSP sending performs RK analysis, for what other purpose than to
determine the AS and find IPSPs serving it ?
- nobody is forcing anything, it's the natural flow of things ... why hold
up the water in the middle of the river ??
<=====

--gery

---

---

From: Verwimp Gery <[email-masked]>
Date: Wed, 7 Nov 2001 13:03:36 +0100

Brian,

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]]
Sent: woensdag 7 november 2001 10:42
To: Verwimp Gery
Cc: sigtran
Subject: Re: Consensus Call - Routing Key

Gery,

Verwimp Gery wrote:                                       (Wed, 07 Nov 2001
10:31:58)

=====>
[GV] : local, remote, ... it's still 2 different platforms from 2 different
vendors talking to each other via standard M3UA. Whether the SG chooses to
see an AS as "local" or "remote" is implementation dependent.

And the IPSP tracks the statuses of the ASs it communicates (= sends traffic
to, RK analysis remember ?) with anyway. What's the difference with SS7 NM ?
Didn't you know the SS7 nodes keeps track of remote DPCs statuses ?
<=====

=====>
[GV] : As if an IPSP would send a message down a blind alley, come on, be
serious. You're idea of an all-IP case is in fact an all SS7 case. Use M2PA
!
<=====

[GV] : Big deal, we don't need SNMM in point-to-point cases since we have
ASPTM. Add a congestion indication to it, if you like. And use RC with any
granularity you like, instead of NA and depending on a routing label
defining your RK.

---

---

From: Verwimp Gery <[email-masked]>
Date: Wed, 7 Nov 2001 13:45:42 +0100

Hi Amish,

It comes down to 1 SCTP association between 2 SPs. In SG-ASP case, 1 RK/RC
definition is sufficient, and silently used for the backward direction as
well. In IPSP-IPSP case, there's 2 RK/RC definitions, for each direction
(each IPSP has the opportunity to register, or SG-ASP + ASP-SG), case A) if
you want.

Case B) is fish nor meat. The SCTP association is there (active for what AS
??), and the SGP function still has to distribute using the RK principles,
in both directions. And actually, you did silently agree on 2 RK/RCs (one
for each SPC cluster, SG-SG case) which is covered by A) as well.

So in my view, A) swallows B) as it is the most general architecture.

Gery Verwimp
Fax : +32 14 25 3212

-----Original Message-----
From: Amish Chana [mailto:[email-masked]]
Sent: woensdag 7 november 2001 11:52
To: sigtran
Subject: RE: Consensus Call - Routing Key

Hi Gery,

features/functions?

Amish

---

---

---

From: Amish Chana <[email-masked]>
Date: Wed, 07 Nov 2001 13:35:33 +0000

Gery,

>It comes down to 1 SCTP association between 2 SPs.

With (A) we do have 1 association. Messages leaving an IPSP with a RC of the 
other IPSP simply leave via the SGP block.

In SG-ASP case, 1 RK/RC
>(each IPSP has the opportunity to register, or SG-ASP + ASP-SG), case A) if

Yes. Gery, can I assume that (A) satifies the needs of an IPSP from your 
perspective. It is a ASP+SGP rather than a super-ASP.

>So in my view, A) swallows B) as it is the most general architecture.

On a slightly different note, since you don't favour (B). Some people would 
want to concentrate the traffic from ASPs. What IP SIGTRAN protocol would 
you use between the M3UA/SUA SGs? Would a fully meshed network be 
appropriate between IPSPs?

Amish.

> > >ASPUP/DOWN needed between two IPSPs. I agree with that. But also you 
>need
> > >to activate/deactivate the AS RKs...
> > >

---

---

From: Tolga Asveren <[email-masked]>
Date: Wed, 7 Nov 2001 06:13:33 -0800 (PST)

Hi Brian,

I disagree with you in two points.
The first one is use of RC. You just explained the use
of RCs from an ASP point of view, to avoid expensive
RK anaylsis on RK. But they are also usefull in
ASP->SG direction. As Gery pointed out to
deifferentiate between different networks and also if
one wants to check whether DATA is coming from an
active AS. You said that checking activeness of AS on
SGP is usefull, but maybe I remember wrong, please
correct me. And I also agree with Gery, even if we
need RK analysis logic in both of the IPSPs (in their
SG functionality part) this shouldn't stop us putting
RC in DATA. This will save us to do the same analysis
twice. Secondly and more importantly, in my opinion
there is a silent disagreement in the definiton of
"local" and "remote". Lets reconsider the approach
proposed by Javier/Dennis : (I interprete their model
as a box with both ASP and SG functionality)

   ***************     ***************
   *             *     *             *
   *             *     *             *
   *  +------+   *     *  +------+   *
   *  | ASP1 |   * +---*--| ASP2 |   *
   *  +------+---*-+--+*  +------+   *
   *             * |  |*             *
   *  +------+   * |  |*  +------+   *
   *  | SG1  +---*-+  +*--+ SG2  |   *
   *  +------+   *     *  +------+   *
   *             *     *             *
   *             *     *             *
   ***************     ***************

      IPSP1                IPSP2

Now, in this figure who is remote and who is local? If
you use the terms local and remote in the same context
like in SG/ASP case then I would say both ASP1 and
ASP2 are local to SG2 and SG1. That ASP1 and SG1 are
sitting in the same box does not mean that that they
are "local" to each other. From M3UA point of view, if
one follows the terminology with the same
interpretation like in SG/ASP case the locals are the
ASP entities, which are connected to a particular SG.
As far as I understand you were using the term "local"
and "remote" based on the place where ASP and SG
functionalities are existing. As you also pointed out,
if you take out SG functionality out of the IPSP bow
and have two ASPs, it works. Then why shouldn't it
work, if you put SG functionality in the same box with
ASP functionality?

   Tolga

--- "Brian F. G. Bidulock" <[email-masked]>
> consistency in your thinking.
=== message truncated ===

---

---

From: "Javier Pastor-Balbas (ECE)" <[email-masked]>
Date: Wed, 7 Nov 2001 15:09:57 +0100

Hi Amish, 

Only one comment, that you can think of a philosophical comment, but anyway important from my point of view. We can not say that an IPSP is SGP+ASP. SG, by definition has access to the SS7 networks and it includes some function that are never used in all IP point to point communication. As an example of that you have all the SS7-IP interoperation features.

On the other hand, you can say that an IPSP has all the features that an ASP has plus the routing part of the SGP.

We are always talking of specific functions that already exist, and we should avoid talking about nodes and even more mixing phisical nodes. We should not say it is a super-ASP nor a SGP-ASP. Simply say, as you proposed, that it is an IPSP. If you are looking for a definition take one like this:

IPSP: Node that have a mixed functionality...

As an SGP:
- when sending data msg to the other IPSP it does it in the same way an SGP sends a message to an ASP: including  the RC that ASP got when registering its RK
- Receive and treat ASPTM, ASPSM and RRM in the same way as SGP, having status information of the other peer

As an ASP:
- Receive data messages and distribute them to the ASs in the same way ASP does it, using RC when more than one  AS is present in the destination.
- Send ASPSM, ASPTM and RRM in the same way ASP does 

More comments below...

> Sent: Wednesday, November 07, 2001 2:36 PM
> To: sigtran
What you say here is an step forward that we definitely leave for an extension draft. Let's do things little by little. The scope for now is to make two IP based SS7 applications communicate themselves through an IP network. This is what is requested by 3GPP and this is what we should get. 

Communication SG-SG or others are out of the topic for now...  :-D

Cheers // Javier.

> > >conceptually, if the nature of RK/RC registration in both 
> directions is
> > >well
> > >understood.
> >
> >ASP and SGP functions? We have passed last call should we be 
> introducing 
> >new
> >
> >features/functions?
> >
> >Amish
> >
> > >registration was understood implicitly by nature of the 
> SG. IPSP simply 
> >has
> > >to handle it both ways. I hope I was elaborate enough in 
> my previous 
> >mails
> > >to make this point.
> > >
> > >configuration the Javier and others suggest. Messages exit 
> via the SGP 
> >and
> > >enter via the ASP. Futhermore, this method also allows one 
> to have an 
> >IPSP
> > >The above also makes use of concepts that have already 
> been defined for 
> >the
> > >To quote Javier in a parallel thread, "We don't have to 
> reinvent the
> > >wheel."
> > >
> > >;-)
> > >
> > >Amish.
> > >
> > >
> > > >If Registration is not required your model is not valid 
> since it works
> > >only
> > >
> > > >SNMM is required only when translating TFP, etc msgs 
> from the SS7 
> >network
> > > >there other means as ASPIA, ASPAC, no routes restricted, 
> no need to 
> >audit
> > > >You don't need to create that restriction. IPSP can 
> control a portion 
> >of
> > > >We need to exchange ASPSM, ASPST and DATA. And we have 
> to allow to
> > >exchange
> > >
> > > >The main thing here is that it seems that you don't have 
> a clear idea 
> >of
> > > >solution if you can and sent it out. And if you do it in 
> time (before
> > >M3UA
> constructive and
> > >let's

---

---

---

From: Dennis Niermann <[email-masked]>
Date: Wed, 07 Nov 2001 08:47:55 -0600

Hi Brian,
Just one response before I get caught up on the other threads...

> fashion in the SS7 network today.
Brian, You are only addressing the case where the SG is 
a SEP and in control of the whole point code (SPMC).
My example was really for the case where the SG is a STP
towards the SS7 network and thus it can interact with multiple
AS's, and AS's with using different point codes.

I think that this is another disconnect that happens quite often.
The SG as an STP is a very legitimate case and it needs to be 
supported.

Keeping that in mind you can see that the STP-type SG has an 
even bigger problem than the IPSP. 
SS7 really expects the UPU to originate from the SEP where the 
user part resides. If the STP-type SG sends a UPU on behalf of
the AS when it loses contact with the AS then what if the SS7 
node really had another path to the AS, 
through a different SG. The SG sending UPU would really
be sending a lie. On the other hand, the IPSP has all the state
information it needs to accurately respond to local users since
it knows the state of all reachable AS's.

[SNIP]

---

---

From: Verwimp Gery <[email-masked]>
Date: Wed, 7 Nov 2001 15:50:08 +0100

Hi Amish,

You're touching the IPSP relay functionality here. If, for the moment, we
only consider point-to-point cases, it's a fully meshed network.

For IPSP relay points (or concentrators), registration procedures are no
different. It acts to the outside world as handling all traffic for the
IPSPs "behind" it and registers as such.

Regards,

Gery Verwimp
Fax : +32 14 25 3212

-----Original Message-----
From: Amish Chana [mailto:[email-masked]]
Sent: woensdag 7 november 2001 14:36
To: sigtran
Subject: RE: Consensus Call - Routing Key

Gery,

In SG-ASP case, 1 RK/RC

Amish.

---

---

---

From: "Ong, Lyndon" <[email-masked]>
Date: Wed, 7 Nov 2001 09:54:43 -0800

Folks,

One design concern that this discussion has raised:
should RC actually be defined as two parameters,
a Destination RC and a Source RC?  The interpretation
seems to be different depending on whether the DATA
message is being sent by an SG or an ASP, and this 
could cause some confusion in an IPSP-IPSP case.

Cheers,

Lyndon

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 7 Nov 2001 12:45:53 -0600

Verwimp,

Verwimp Gery wrote:                                       (Wed, 07 Nov 2001 11:35:25)
> [GV]: Why not ? This saves the IPSP the trouble of performing RK analysis

IPSPs do not have to perform RK analysis, they only have to perform
MTP/SCCP Distribution.  The difference is when an ASP distributes
based on RC, all it has to do is propagate the message to the AS.
The IPSP has more to do: it must run the MTP/SCCP state machines on
the message.  When a message arrives at an SGP for an unequipped
user, the SGP responds with UPU to the SS7 network.  When an ASP
receives a message from an SGP, all it has to do is propagate it to
the AS.  The is the effect of "exporting the user interface".  When
a message arrives at an IPSP for an unequipped user, the IPSP needs
to response with a DUPU.  The IPSP cannot simply propagate the
message as was done in the ASP case.  It must perform the SGP
function.  It must run the MTP/SCCP state machines on the message.

What the proposal wrongfully attempts to do is to make the sending
IPSP perform the receiving IPSP's state machines for one direction
of traffic between peers, but visa versa for the other direction of
traffic.  This splitting of one state machine across two (well,
many) nodes will not work and will not scale.

> [GV]: Same discussion we had for NA/RC. This leaves you with at least

I don't think we'll need to use the NA parameter in point-to-point.
NA can easily be implied by the association.

> [GV]: Sorry Brian, but I don't agree with your view here. ASP *knows* the
> speficis for RKs, it registers/configures them for starters.

ASPs do not configure RKs, Gery.  Only if the optional registration
procedure is used do they need to know about them at all.  When
registration is used, the RK can be treated opaquely and by
management functions only.  The RK does not have to be maintained in
any way in the ASP during normal operation.  RC is sufficient for
all purposes.  But you see, the ASP has nothing to do but export
the user interface.  As such each message maps onto a primitive.
It is the SGP that is in control and must know about protocol.

> The administrative burden you mention all depends on how fine
> we're going with the granularity of your RKs; it's not up to us to
> put a restriction on this.

The administrative burden is gone when you get rid of RC.

What does the IPSP care about the state of another IPSP's AS?

> And without RC, you're still stuck with the NA ... the sending
> IPSP should be aware of the variants the other IPSP is supporting,
> and the receiving IPSP should know for what variant it is
> receiving a message.

Gery, your stuck with NA even with RC.  It is just implied by RC.
Without RC, NA can still be implied by the association.

--brian

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

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 7 Nov 2001 12:59:50 -0600

Javier,

Javier Pastor-Balbas (ECE) wrote:                          (Wed, 07 Nov 2001 15:09:57)
> Hi Amish, 
> 
> Only one comment, that you can think of a philosophical comment, but anyway
> important from my point of view. We can not say that an IPSP is SGP+ASP. SG,
> by definition has access to the SS7 networks and it includes some function
> that are never used in all IP point to point communication. As an example of
> that you have all the SS7-IP interoperation features.
> 
> We are always talking of specific functions that already exist, and we
> should avoid talking about nodes and even more mixing phisical nodes. We
> should not say it is a super-ASP nor a SGP-ASP. Simply say, as you proposed,
> that it is an IPSP. If you are looking for a definition take one like this:
> 
> 
> - when sending data msg to the other IPSP it does it in the same way an SGP
> sends a message to an ASP: including  the RC that ASP got when registering
> its RK

I cannot.  When an SGP sends a message to an ASP it is sending it up
the stack.  When an IPSP sends a message to an IPSP it is sending it
down the stack.  They bear no similarity.

> status information of the other peer

When an SGP receive ASPTM/SM, it is recieving it from above on the
stack.  When an IPSP receives management messages, they are SNMM from
below.

> 
> As an ASP:
> - Receive data messages and distribute them to the ASs in the same way ASP
> does it, using RC when more than one  AS is present in the destination.

This is internal to the IPSP.

> - Send ASPSM, ASPTM and RRM in the same way ASP does 

This is internal to the IPSP.

Javier, it is getting pretty bad when you can't even look at
the protocol stack.  ASP/AS are SS7-User *above* SGP as SS7-Provider
on the *same* stack.

IPSPs are two different stacks.

You are trying to make user-provider protocol fit peer-peer.
There is no point in that.

--brian

> What you say here is an step forward that we definitely leave for an
> extension draft. Let's do things little by little. The scope for now is to
> make two IP based SS7 applications communicate themselves through an IP
> network. This is what is requested by 3GPP and this is what we should get. 

(B) does that for them.  (A) is insane.

> Communication SG-SG or others are out of the topic for now...  :-D

I do not subscribe to your censorship.  First you say IPSP is not
ASP-SGP and then you say SG-SG communication is scoped out.

(B) is IPSP-IPSP communication.  SGP-function to SGP-function.

--brian

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

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 7 Nov 2001 15:01:01 -0600

Gery,

The view that SNMM is not required for IPSP cannot be
supported.  Contrary to your statements, an ASP can and
does send SNMM.

In particular, section 1.4.6 of M3UAv9 says:

    The M3UA layer at an ASP or IPSP MAY indicate local congestion to an 

This is an ASP's way of informing MTP-User peers of application
congestion.  Application flow control is also performed for SCCP
subsystems.

To highlight why ASPTM is useless and unnecessary for IPSP,
and is completely replaced by SNMM, lets consider a very
simple example:

(I think we are all capable of understanding Amish's model.
And I have labelled ASP functions as ASF and SGP functions
as SGF to avoid pointless disputes.)

     ___________                     ___________      
    |  _______  |                   |  _______  |     
    | |       | |                   | |       | |     
    | |  AS   | |                   | |  AS   | |     
    | |_______| |                   | |_______| |     
    |     |     |                   |     |     |     
    |  ___|___  |                   |  ___|___  |     
    | |       | |                   | |       | |     
    | |  ASF  |_|_______     _______|_|  ASF  | |     
    | |_______| |       \   /       | |_______| |     
    |           |        \ /        |     |     |     
    |  _______  |         X         |  ___|___  |     
    | |       | |        / \        | |       | |     
    | |  SGF  |_|__<___ /   \___>___|_|  SGF  | |     
    | |_______| |                   | |_______| |     
    |___________|                   |___________|     
                                                      
        IPSP-X                          IPSP-Y        

The AS at IPSP-X experiences congestion.  In the normal
AS/SG scenario, the ASP sends SCON to the SGP and the SGP
can turn this into TFC to the SS7 network.  The result
at the distant SS7-User is the presentation of an MTP-STATUS
primitive with the affected point code and congestion level.
What is required in IPSP is for the ASF at IPSP-X to be able
to do something that generates the same MTP-STATUS primitive
to the ASF at IPSP-Y.

A SCON message would do the trick.  The ASF at IPSP-X sends
SCON to IPSP-Y.  The SCF at IPSP-Y sends this SCON up stack
and the ASF at IPSP-Y delivers MTP-STATUS to the AS at IPSP-Y.

There is no ASPTM message to accomplish this.  This is
accomplished using SNMM messages.

There would be little point to modifying the ASPTM message
to indicate congestion and levels of congestion.  And there
is no reason to have IPSP use a different message when the
purpose is the same.  SNMM are required for IPSP operation.

Now, considering DUNA/DAVA/DUPU:  DUNA/DAVA are management
message on a point-code basis.  They precisely correspond
to the MTP-PAUSE and MTP-RESUME primitives in M3UA and the
N-PCSTATE/N-STATE primitives in SUA.

The acessibility or inaccessibility of a point code at
IPSP-X is not determined solely by the activity of the
users of the point code.  It is possible to have a point
code which is accessible, but which has no accessible users.

In terms of ASPTM, it is possible that each AS does
not neatly correspond to an specific user (CIC range,
TID range).

A specific IPSP-Y does not have to be registered with
every AS at IPSP-X.  This means that IPSP-Y is in general
incapable of amalgamating AS activity into status
primitives to its users.

Let's take a specific example:

    _____                                                   
   /     \                                                  
  |  AS1  |                                                 
   \_____/                                                  
  PC=3, SI=5                        ________                
   CIC=0-100                       |        |               
   (OPC=4)  X                     /| IPSP-Y |____           
    _____    X   ________  assoc / |________|    \   _____  
   /     \    X_|        |______/                 \ /     \ 
  |  AS2  |----=| IPSP-X |______                   |  AS4  |
   \_____/    / |________|      \   ________      / \_____/ 
  PC=3, SI=5 /                   \ |        |____/ PC=4, SI=5
  CIC=101-200                     \| IPSP-Z |      CIC=0-100
           /                       |________|\      (OPC=3) 
    _____ /                                  |\   _____     
   /     \                                   | \ /     \    
  |  AS3  |                                  |  |  AS5  |   
   \_____/                                   |   \_____/    
  PC=3, SI=3                                 | PC=4, SI=3   
                                             |              
                                              \   _____     
                                               \ /     \    
                                                |  AS6  |   
                                                 \_____/    
                                               PC=4, SI=5   
                                              CIC=101-200   
                                                (OPC=3)     

Consider that IPSP-X looses AS1.  It sends ASPIA(RC=AS1) to
IPSP-Y and IPSP-Z.  Several big questions arrise:

How does IPSP-Y inform AS4?

     MTP-PAUSE? IPSP-Y has no active RC for PC-3, but
     MTP-PAUSE would be incorrect because PC=3 is still
     accessible via IPSP-Z.

     MTP-STATUS(PC=3, SI=5 inacessible)?  IPSP-Y has no
     active RC for PC=3, but MTP-STATUS would be incorrect
     because PC=3,SI=5 is still accessible via IPSP-Z.

This demonstrates that an IPSP cannot generate MTP management
primitives based on ASPTM (which is per-association).  To
properly generate MTP-PAUSE/RESUME/STATUS primitives requires
a knowlege of the actual state of the entity being indicated
and knowledge of the activity of a few AS doesn't help.

IPSP-X, on the other hand, has intimate knowledge of local
conditions regard its users.  IPSP-X is in the best position
to translate local conditions into SNMM messages that correspond
directly to MTP-PAUSE/RESUME/STATUS messages.  In this example,
IPSP-X knows that PC=3,SI=5 is still available and will not
send DUPU.  IPSP-X also knows that PC=3 is still available and
will not send DUNA.  This is normal SGP behavior.

There is certainly no point to IPSP-X taking local state,
translating it to ASPTM and then having IPSP-Y botch the
job of translating them back into SNMM to the AS.  IPSP-X
can send SNMM directly.

So, Gery, it is all fine and dandy to go saying that the
IPSP informs its users of SNMM events based on ASPTM, but,
it cannot work that way.

--brian

Verwimp Gery wrote:    (Wed, 07 Nov 2001 12:18:08)
> [GV]: When you have RKs, you have RCs, and you have traffic management. No
> [GV]: In multiple SG case, I could think of cases where the ASP also has to
> [GV]: Wrong. The ASP doesn't send SCON (it cannot in general, e.g. when
> [GV]: Huh ? If the IPSP doesn't track, what's the use of any management

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

---

---

From: Dennis Niermann <[email-masked]>
Date: Wed, 07 Nov 2001 16:31:24 -0600

Hi Gery,
A few comments below...

> RK and RC define the traffic flow in SG->ASP direction. So far so good.
Yep.

> routing label for M3UA and destination address for SUA.
Yep.

> one RK/RC set is defined, it's used in both directions. It's put to double
This is where I do not concur. As described in section 1.4.2.5, the ASP
selects a SGP based on DPC of the message. The RK does not even
necessarily
include that point code (it would be the OPC in the RK if it did).
The RK is only used for routing in the SGP to ASP direction.

> attached to a single RK, advertised by essentially one party only.
Yep.

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 7 Nov 2001 17:20:15 -0600

Dennis,

The reference to DPC in section 1.4.2.5 is meant for the general
case for multiple SG where the ASP needs to maintain PC routing
tables for each SG.  The text is introductory and in no way
requires the ASP to route on DPC.

--brian

Dennis Niermann wrote:                                     (Wed, 07 Nov 2001 16:31:24)

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

---

---

From: [email-masked]
Date: Wed, 7 Nov 2001 18:53:18 -0500

Brian,

Please see comments/questions below.

   Tolga

> From:   "Brian F. G. Bidulock" <[email-masked]>
> Sent:   Wednesday, November 07, 2001 4:16 PM
[TOLGA]  As I tried to point out in another message, if one tries to
analyze the model described by the diagram above (I believe this is  also
more or less what Javier/Dennis are proposing, please correct me if I am
wrong) it is easy to see that  ASF sends outgoing messages to remote SGF.
Then this SGF forwards the message to the local ASF. IPSP-IPSP
communication is defined as point-to-point and all of the ASs should be
defined both in IPSP-Y and IPSP-X. That's what is proposed, whether this is
efficient or not is another question but I also think once we accept that
IPSP-IPSP communication is point-to-point, we should expect a mesh
configuration. Otherwise we have to have some relay nodes, which I believe
could be usefull. But it won't be point-to-point. So, maybe we should also
define it.

>   |  AS2  |----=| IPSP-X |______                   |  AS4  |
[TOLGA] The same problem arises also in ASP/SG case. The answer is
configuration. Also if one wants to give a consistent and reasonable view
of some ASs to SS7 world by a SG, one should define all ASs belonging to a
particular SPMC in that SG. Otherwise one can have the same problems. So,
my answer to those problems would be all of the ASs should be defined  on
IPSP-Y. The problems, arising from the fact that some ASs areaccessible via
IPSP-Z has again its equivalent in the ASP-SG world :

        AS1:  PC=3   SI=3
        AS2:  PC=3   SI=5  CIC=0-100 (OPC=4)
        AS3:  PC=3   SI=5  CIC=101-200
        +--------+
        |        |
        |  ASP1  |
        +-------++
        |       |
        |       |
        |       |
    +---++     ++----+
    | SG1|     | SG2 |
    +----+     +-----+
If only AS2 is activated for SG2 whereas all of them are activated for SG1,
the same problem happens. Again, we should have carefull configuration to
not to have such problems.
> You are currently subscribed to sigtran as: [email-masked]

---

---

From: [email-masked]
Date: Wed, 7 Nov 2001 15:58:46 -0800

Hi Dennis,

Please see a short comment below.

   Tolga

> From:   Dennis Niermann <[email-masked]>
> Sent:   Wednesday, November 07, 2001 5:41 PM
> Cc:
[TOLGA] This part is going to be changed (at least this is what was agreed
(?) ) to be consistent with 1.4.4.2, where it is said that activeness of
the AS is also part of the process to select the SGP. So, ASP will select a
SGP from the set, to which it has send ASPAC and received ASPAC-ACK and via
which it can reach DPC.
> > > Dennis Niermann wrote:
>  (Tue, 06 Nov
> > 2001 13:20:53)
> > > > > Dennis Niermann wrote:
>      (Tue, 06
> > Nov 2001 11:16:30)
> [email-masked]

---

---

From: Dennis Niermann <[email-masked]>
Date: Wed, 07 Nov 2001 18:05:32 -0600

Hi Tolga,
OK, I have no problem with that clarification.
/Dennis

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 7 Nov 2001 19:52:04 -0600

Tolga,

Please see below...

[email-masked] wrote:                        (Wed, 07 Nov 2001 18:53:18)
> could be usefull. But it won't be point-to-point. So, maybe we should also

Where is the requirement to define all AS for each IPSP?  There
is certainly no such requirement for ASPs.

But look at this a bit more.  The configuration in the diagram
is still valid if one allows AS to be active/inactive on a
per-IPSP basis regardless of whether they are defined.  The
only way to avoid the situation diagrammed is if all AS served
by an IPSP must active or inactive together.  In which case,
it would be the same as one big AS per IPSP, needing no RCs
(implicit to association).

So, as long as AS may independently go active or inactive,
this configuration must be addressed.

> [TOLGA] The same problem arises also in ASP/SG case.

No, it does not.  The SG is responsible for all the AS in an SPMC.
The SG controls the state of the SPMC and users and relfects the
state of the SPMC and users to the network with SS7 SNMM.

> The answer is configuration. Also if one wants to give a consistent and
> reasonable view of some ASs to SS7 world by a SG, one should define all ASs
> belonging to a particular SPMC in that SG.  Otherwise one can have the same
> problems.

The same situation does not occur for the SG because:

   1)  All of the AS belong to an SPMC at the SG and the SG controls
       the SPMC.

   2)  All SGP within an SG provide the same SS7 connectivity to
       the ASPs.

   3)  An SNMM message from one SGP reflects the state of the
       destination for all SGP.

   4)  ASPs propagate SNMM received from the SG as MTP-PAUSE/...
       primitives to the AS.

None of these hold for the IPSP approach (A).  They all hold
for approach (B).

> So, my answer to those problems would be all of the ASs should be defined
> on IPSP-Y.

That is only half way there.  They must also be active or inactive
together.

> The problems, arising from the fact that some ASs areaccessible via

> If only AS2 is activated for SG2 whereas all of them are activated
> for SG1, the same problem happens. Again, we should have carefull
> configuration to not to have such problems.

This is not a problem for SG2.  SG2 can mark the SPMC inaccessible
and routes messages for PC=3 to SG1 across C-links.

Besides, this is a different situation altoether: it is not
point-to-point.  In the point-to-point case there is only one
SG.  In the IPSP case we are talking of there is only one
IPSP node.  The equivalent case with SG is as follows:

         AS1:  PC=3   SI=3
     |SGP1|     |SGP2 |
     +----+     +-----+

Where these are SGP belonging to the same SG.  There is no
difficulty with two SGP handling this case.  SGP have a requirement
to be able to route messages between themselves.  If the any
AS is active for any SGP, then it is accessible and there is
not a problem.

Why is it a problem in the IPSP case?

Well, if a requirement is placed on IPSPs in an IPSP cluster that
they be able to pass data between themselves as for SGP, then
when the IPSP cluster then there would not be problem.

So, please add this requirement to approach (A): that the IPSP
serving the same SPMC must be able to pass data between themselves
and that each IPSP must present the same connectivity to the AS
which belong to the SPMC from each IPSP in the cluster.

That will solve the problem.

However, if this requirement is placed, there will be no need
for IPSP in a cluster to communicate on a per-ISPS basis
concerning the activity or inactivity of local AS (because
they all present the same view).  This makes ASPTM unnecessary
as SNMM on an IPSP cluster basis will suffice.  Without ASPTM
there is no need for RC or registration, and we reduce to
approach (B).

--brian

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

---

---

From: Amish Chana <[email-masked]>
Date: Thu, 08 Nov 2001 10:00:21 +0000

Hi Tolga,

> > defined both in IPSP-Y and IPSP-X.

What's with the all the ASs should be defined in all the IPSPs?
Lets assume I have a HLR AS and VLR AS and I want connect them in a IPSP 
manner. You are stating that every IPSP must have a HLR and VLR. Great, now 
I don't have to send traffic across the M3UA connection (however it may be 
defined) because the same VLR and HLR exists in every IPSP.

Amish

> > That's what is proposed, whether this is

---

---

From: [email-masked]
Date: Thu, 8 Nov 2001 05:26:47 -0800

Hi Amish,

Please see comments below.

  Tolga

> From:   Amish Chana <[email-masked]>
> Sent:   Thursday, November 08, 2001 5:06 AM
> I don't have to send traffic across the M3UA connection
[TOLGA] The first argument to define all of the ASs is, because IPSP-IPSP
communication is defined as point-to-point. It seems everybody has
different understanding of point-to-point communciation and what the
endpoints of this communication are for IPSP-IPSP.
I am not saying this is the best or only solution. But in the draft it is
defined as a point-tpoint communication.
Secondly, if you don't define all of those ASs, the idea presented by
JAvier/Dennis and also afterwards restated by you as putting ASP and SG
functionality to one box and call it IPSP will have serious problems.
So, maybe it should be decided, what we want to build, a point-pto-point
mechanism or not?
By the way I don't agree with your view of AS. AS represents just the
traffic range, not the user application itself. HLR, VLR in your example
are user applications. So, you don't need to have the applciations in both
of the sides, just you should define the traffic ranges.
> (however it may be
> > > efficient or not is another question but I also think
> once we accept
> >that
> > > could be usefull. But it won't be point-to-point. So,
> maybe we should
> >also
> > > define it.
> >

---

---

From: [email-masked]
Date: Thu, 8 Nov 2001 05:53:35 -0800

---

---

From: Tolga Asveren <[email-masked]>
Date: Thu, 8 Nov 2001 06:05:33 -0800 (PST)

resending.....

Hi Brian,

Please see questions/comments below.

  Tolga

> Sent:	Wednesday, November 07, 2001 8:59 PM
(Wed, 07 
> Nov 2001 18:53:18)
> > >     The M3UA layer at an ASP or IPSP MAY
indicate local
> > > congestion to an
> > >     M3UA peer with an SCON message.  When an SG
receives 
> a congestion
> > >     message (SCON) from an ASP, and the SG
determines that an
> > > SPMC is now
> > >     encountering congestion, it MAY trigger SS7
MTP3 Transfer
> > > Controlled
> > >     |  _______  |                   |  _______ 
|
> > >     | |       | |                   | |       |
|
> > >     | |  AS   | |                   | |  AS   |
|
> > >     |     |     |                   |     |    
|
> > >     |  ___|___  |                   |  ___|___ 
|
> > >     | |       | |                   | |       |
|
> > >     |           |        \ /        |     |    
|
> > >     |  _______  |         X         |  ___|___ 
|
> > >     | |       | |        / \        | |       |
|
> > analyze the model described by the diagram above
(I believe 
> this is  also
> > more or less what Javier/Dennis are proposing,
please 
> correct me if I am
> > wrong) it is easy to see that  ASF sends outgoing
messages 
> to remote SGF.
> > communication is defined as point-to-point and all
of the 
> ASs should be
> > defined both in IPSP-Y and IPSP-X. That's what is
proposed, 
> whether this is
> > efficient or not is another question but I also
think once 
> we accept that
> > configuration. Otherwise we have to have some
relay nodes, 
> which I believe
> > could be usefull. But it won't be point-to-point.
So, maybe 
> we should also
[TOLGA] IPSP communication is defined as
point-to-point in the draft. So endpoints of it should
be defined at both of the ends. My interpretation of
endpoints is that they are ASs. But I don't know what
else interpretation there are. So, the base of my
opinion why all ASs should be defined is because of
those reasons. 
I agree with you that there is no requirement for two
ASPs, two define all of the ASs, the other ASPs have.
But it is a requirement for a SG, to define all of the
RKs, defines on the ASPs it is connected to, if the SG
wants to transfer belonging to traffic range of RK.
So, requirement of defining all ASs is not because of
the ASP functionality of IPSP but because of SG
functionality of the proposed IPSP model.
> > >    (OPC=4)  X                     /| IPSP-Y
|____
> > >    /     \    X_|        |______/               
 \ /     \
> > >            /                       |________|\  
   (OPC=3)
> > >     _____ /                                  |\ 
 _____
> > >    /     \                                   | \
/     \
> > >   |  AS3  |                                  | 
|  AS5  |
> > >    \_____/                                   |  
\_____/
> > >   PC=3, SI=3                                 |
PC=4, SI=3
> > >                                               \ 
 _____
> > >                                                \
/     \
|  AS6  |
\_____/
PC=4, SI=5
CIC=101-200
(OPC=3)
> > The answer is configuration. Also if one wants to
give a 
> consistent and
> > reasonable view of some ASs to SS7 world by a SG,
one 
> should define all ASs
> > belonging to a particular SPMC in that SG. 
Otherwise one 
> can have the same
> > So, my answer to those problems would be all of
the ASs 
> should be defined
[TOLGA] The proposed IPSP model consist of ASP and SG
functionality. If there are two different IPSPs and if
they are not sharing information with a proprietary
protcol, then their SG functionalities are like two
different SGs, not like two SGPs belonging to the same
SG. So, all of the above items, are applicable, but as
I said in IPSP we have the SG not SGP (or better said
an SG consisting of only one SGP)
>          AS3:  PC=3   SI=5  CIC=101-200
12:18:08)
> > > > [GV]: When you have RKs, you have RCs, and you
have traffic
> > > management. No
> > > > reason to restate their definitions in the
IPSP case. In
> > > fact, RC is mighty
> > > > useful in IPSP case as well. If not, what do
you do with
> > > network appearance
> > > > ? The lack of routing label in SUA messages ?
Finer
> > > granularities than PC
> > > > Because IPSPs have the functions necessary to
perform 
> RK analysis
> > > > [GV]: In multiple SG case, I could think of
cases where the
> > > ASP also has to
> > > > perform some RK analysis before it sends out a
message.
> > > Anyway, the RK
> > > > analysis must be done on the sending side, so
why not label
> > > it with RC
> > > > afterwards ? Why repeat it at the receiving
side (if at all
> > > possible) ? The
> > > > IPSP should know for what traffic it
registered, so 
> pick up the RC.
> > > > application) it signals SCON to is peers to
indicate 
> the congestion.
> > > > Even in the AS/SG case, the ASP sends SCON to
the SGP 
> to indicate
> > > > the network.  Not allowing the ASP function in
the IPSP 
> to signal
> > > > [GV]: Wrong. The ASP doesn't send SCON (it
cannot in
> > > general, e.g. when
> > > > you're handling CIC ranges). And even if it
did, the SG is
> > > in general
> > > > incapable of informing the SS7 network
(multiple ASPs in 1
> > > AS). The use of
> > > > SNMM messages is informative from SG->ASP
(MTP-STATUS 
> and N-PCSTATE
> > > > INDICATIONS).
> > > >
> > > > And if MTP-users signal congestion to one
another, they
> > > won't use SNMM but
> > > > their own messages transported in the M3UA
DATA primitives.
> > > (e.g. SCCP
> > > > subsystem management messages). The M3UA state
itself is
> > > clear from ASPTM,
> > > > be exchanged between IPSP, just SNMM. 
Registration and
> > > configuration
> > > > is because the AS as MTP/SCCP-Users are
*local* to the 
> SG as well
> > > > This view of the activity of the AS is never
exposed to 
> remote SS7
> > > > It is not necessary for an IPSP to expose the
activity 
> of *local*
> > > > [GV]: Huh ? If the IPSP doesn't track, what's
the use of
> > > any management
> > > > - IPSP knows the state of it's communication
partners
> > > (connected IPSPs who
> > > > have registered for some RKs) through SCTP
association
> > > management and ASPTM
> > > > - IPSP sending performs RK analysis, for what
other 
> purpose than to
> > > > - nobody is forcing anything, it's the natural
flow of
> > > things ... why hold
[email-masked]
> > > [email-masked]
[email-masked]
> > You are currently subscribed to sigtran as:
[email-masked]
> [email-masked]
[email-masked]

---

---

From: [email-masked]
Date: Thu, 8 Nov 2001 09:12:14 -0500

resending.....

Hi Brian,

  Tolga

> this configuration must be addressed.
[TOLGA] IPSP communication is defined as point-to-point in the draft. So
endpoints of it should be defined at both of the ends. My interpretation of
endpoints is that they are ASs. But I don't know what else interpretation
there are. So, the base of my opinion why all ASs should be defined is
because of those reasons.
I agree with you that there is no requirement for two ASPs, two define all
of the ASs, the other ASPs have. But it is a requirement for a SG, to
define all of the RKs, defines on the ASPs it is connected to, if the SG
wants to transfer belonging to traffic range of RK. So, requirement of
defining all ASs is not because of the ASP functionality of IPSP but
because of SG functionality of the proposed IPSP model.
> That is only half way there.  They must also be active or inactive
[TOLGA] The proposed IPSP model consist of ASP and SG functionality. If
there are two different IPSPs and if they are not sharing information with
a proprietary protcol, then their SG functionalities are like two different
SGs, not like two SGPs belonging to the same SG. So, all of the above
items, are applicable, but as I said in IPSP we have the SG not SGP (or
better said an SG consisting of only one SGP)

---

---

From: Amish Chana <[email-masked]>
Date: Thu, 08 Nov 2001 14:08:18 +0000

Tolga,

>traffic range, not the user application itself.

Yes. I am applying IPSP to one possible deployment scenario. Each AS can 
represent the entire traffic range of a VLR or HLR.

I don't see why you want to define the ASes in every IPSP.
Lets look at this a little further. Let us say we have AS1 and AS2 defined 
on both IPSPs (call them IPSP-X and IPSP-Y). Lets have the following RKs 
represent the traffic range of each AS:
AS1: DPC=1-1-1, SI=3
AS2: DPC=1-1-2, SI=3
(You are welcome to use other RKs instead of the above 2)

Now, according to you AS1 and AS2 are defined on both IPSPs. Correct?

If yes, what is the benefit of IPSP-X sending traffic to AS1 or AS2 in 
IPSP-Y when AS1 and AS2 already exist in IPSP-X.

Could you provide an example where the above would be used in the real 
world.

I get the feeling that the AS across all IPSPs concept is meant achieve 
distributed processing within a node (or logical node or point code) rather 
than signalling transport.

Amish

>HLR, VLR in your example

---

---

From: Tolga Asveren <[email-masked]>
Date: Thu, 8 Nov 2001 06:26:50 -0800 (PST)

Amish,

  Tolga
> Could you provide an example where the above would
[TOLGA] 
    +-----+         +-----+
    | ASP1+--+ +----+ ASP2|
    +--+--+  | |    +---+-+
       |     | |        |
       |     | |        |
    +--+--+  --+----+---+-+
    | SG1 +----+    | SG2 |
    +-----+         +-----+

Consider the above ASP/SG case.Now, you want to send
traffic belonging to AS1 from ASP1 to ASP2. AS1 should
be defined on ASP1. I think this is clear. But it
should also be defined on SG2, so that ASP1 can send
traffic to SG2 belonging to that RK. Afterall, first
ASP1 has sent ASPAC and received ASPAC-ACK to and from
SG2.
On ASP2, one needs to define also all of the ASs it is
serving. So, the remote ASs one defines because of the
SG functionality of the IPSP, whereas the local ones
are defined because of the ASP functionality.
Now lets put ASP1 and SG1 in the same box (like also
you proposed) and call tham IPSP1
You just define the ASs, your HLR is only connected to
IPSP1 and your VLR only to IPSP2.

> > > > > configuration. Otherwise we have to have
> some relay nodes, which I
> > > >believe

---