Subject: [SUA issue 17 & M3UA issue #11] IPSP cases - AN EXAMPLE!

From: [email-masked]
Date: Fri, 7 Sep 2001 11:04:29 +0300

Hello all,

I spent some time, making some signaling charts for
how IPSP - IPSP would establish connectivity.  Now,
I basically think that the protocol will be symetric.
I don't see a lot of extra considerations would would
need to be added, however, I think some text should
be added to chapter 4 (of M3UA & SUA) for clarity's
sake.

I could also show some examples for a failure case.

Comments would be appreciated.

John

The general scenario is: 

	AS A has 2 ASPs - ASP1 & ASP2 (1 + 1 model)
	AS B has 2 ASPs - ASP3 & ASP4 (1 + 1 model)

     AS A			  AS B
  +----------+     SCTP        +----------+
  | +------+ |  Associations   | +------+ |
  | | ASP1 |_____________________| ASP3 | |
  | |      | \___             __/|      | |
  | +------+ |   \___    ____/ | +------+ |
  |          |       \__/__    |          |
  |          |    _____/   \   |          |
  | +------+ |___/          \__| +------+ |
  | | ASP2 |/___________________\| ASP4 | |
  | |      | |                 | |      | |
  | +------+ |                 | +------+ |
  |          |                 |          |
  +----------+                 +----------+

Establish SCTP Connectivity - as per 2960. Note that SCTP 
connections are bi-directional.

The endpoint that establishes SCTP connectivity MUST also establishe 
UA connectivity (see RFC 2960, section 5.2.1 for handling collisions).

All ASPs are in the ASP-DOWN state
              
Now we bring up the ASPs.
We consider that 2 

ASP1 ----------------------ASP Up--------------------------> ASP3
ASP1 <--------------------ASP Up Ack------------------------ ASP3

<ASP1 is now in the ASP-INACTIVE state>
<ASP3 is now in the ASP-INACTIVE state>

Optionally, we may wish to bring up a spare UA signaling 
connection.

ASP2 ----------------------ASP Up--------------------------> ASP3
ASP2 <--------------------ASP Up Ack------------------------ ASP3

<ASP2 is now in the ASP-INACTIVE state>
<ASP4 is now in the ASP-INACTIVE state>

Now we have full UA connectivity between the IPSPs

If Routing Keys are not statically provisions, optional routing key 
registration can occur.  Each AS MAY register routing keys, 
indicating what range of traffic the AS can handle.

In order to fully configure both ends of the UA signaling 
connection (to ensure bi-directionality), ASP1 sends a ASPAC
with TMT1 & RC1 (note that both are optional parameters) which
specify which RC & which TMT ASP1 is using.  ASP3 responds with
an ASPAC ACK, echoing the RC & TMT.  

Then, ASP3 sends a ASPAC with TMT3 & RC3 (note that both are 
optional parameters) which specify which RC & which TMT ASP3 
is using.  ASP1 responds with an ASPAC ACK, echoing the RC & TMT.  

ASP1 ----------------------ASPAC (TMT1,RC1)----------------> ASP3
ASP1 <---------------------ASPAC ACK(TMT1,RC1)-------------- ASP3

<ASP1 is now in the ASP-ACTIVE state>

ASP1 <----------------------ASPAC (TMT3,RC3)---------------- ASP3
ASP1 ---------------------ASPAC ACK(TMT3,RC3)--------------> ASP3

<ASP3 is now in the ASP-ACTIVE state>

Traffic can now flow directly between ASPs, for example SUA CLDT
message.

ASP1 ---------------------------CLDT-----------------------> ASP3

---
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: Fri, 7 Sep 2001 03:31:06 -0500

John,

A couple of questions regarding ASPAC:

  When ASP1 sends traffic to ASP3 which RC does it use?  RC1?

  When ASP3 sends traffic to ASP1 which RC does it use?  RC3?

  What would be the point of having two RC values for the same
  traffic flow?  Both of which have to be negotiated or agreed
  between IPSPs?

  Because RK <-> RC, does RK1 have to be symmetrical to RK3?
  If not, how would ASP1 tell that RC3 and RC1 are related?

  What would be the point of having two RK's when they are
  symmetrical?

  What does each ASP do if it receives unsolicited ASPDN Ack?
  What does each ASP do if it receives unsolicited ASPIA Ack?

  Would not ASPIA deactivate traffic in both directions?

--brian

John Loughney wrote:                                  (Fri, 07 Sep 2001 11:04:29)
> 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: Fri, 7 Sep 2001 11:12:18 +0200

Hi, 

Good job John. I fully support your view. 

I'll try to answer Brian's questions inline. Comments welcome.

BR // Javier.

> -----Original Message-----
> From: Brian F. G. Bidulock [mailto:[email-masked]]
> Sent: Friday, September 07, 2001 10:31 AM
> To: sigtran
> Subject: Re: [SUA issue 17 & M3UA issue #11] IPSP cases - AN EXAMPLE!
> 
> 
> John,
> 

Yes, they can have independent assignment policies
>   If not, how would ASP1 tell that RC3 and RC1 are related?
RK is not symmetrical, since RK1 is saying what traffic is handled by ASP1 and RK3 says what traffic is handled by ASP3. In the general case they are not handling the same traffic. If the RK is based on DPC, it can not be symmetrical. 

>   What does each ASP do if it receives unsolicited ASPDN Ack?

From my point of view, the ASP receiving ASPDN_ACK should send ASPAC again, just to make sure that his RK is activated.

>   What does each ASP do if it receives unsolicited ASPIA Ack?

If ASPIA_ACK is received by ASP1, we have two options:

- ASP3 is INACTIVE. This means that all the traffic we try to send to ASP3 is gonna be rejected, and then ASP1 will realise that ASP3 is not working, and it will stop the traffic between them. The application in ASP1 will observe timers. 

- ASP3 is ACTIVE and the msg was lost from a previous dialogue. If ASP1 continue sending traffic, ASP1 will realise whether ASP1 is working properly or not

Based on this, no extra actions would be needed.

>   Would not ASPIA deactivate traffic in both directions?

Yes. If ASP1 receives ASPIA from ASP3, this means that ASP3 goes to INACTIVE: no traffic can be handled by ASP3. Therefore the traffic path gets broken. If we want to have a traffic path, both ASPs should be in ACTIVE state according to the draft.

> > 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: [email-masked]
Date: Fri, 7 Sep 2001 12:23:28 +0300

Brian,

>   traffic flow?  Both of which have to be negotiated or agreed

For the same traffic flow, then it might be possible that 1 RC
is OK (for send / reply type of operation).  

However, if User A wants to send something to User B, User A
should know User B's RC.  If User B wants to send something
to user A, then User A should know User A's RC.

John

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 7 Sep 2001 15:45:25 -0500

Javier,

Javier Pastor-Balbas (ECE) wrote:                          (Fri, 07 Sep 2001 11:12:18)
> RK is not symmetrical, since RK1 is saying what traffic is handled by ASP1
> and RK3 says what traffic is handled by ASP3. In the general case they are
> not handling the same traffic. If the RK is based on DPC, it can not be
> symmetrical. 

If RK is not symmetric, how is ASP1 to know that RC3 is related to RC1?
ASP1 needs to know that RC3 and RC1 are related so that it knows when
to permit traffic on RC1 and RC3 (which cannot be allowed until both are
active in the proposal).  Is the relationship between RC1 and RC3 to
be provisioned somehow at the ASP?  If so, why use two values where one
would be sufficient?  As one value is sufficient, there is no need to
perform activation in both directions.

> >From my point of view, the ASP receiving ASPDN_ACK should send ASPAC again,
> >just to make sure that his RK is activated.

In the proposal, ASP1 originally sending ASPAC cannot activate the RK3/RC3
for ASP3 unless it knows that ASP3 has already activated RK1/RC1.  Therefore,
if ASP1 was not prepared to activate RK3/RC3, it should not have sent ASPAC
for RK1/RC1.  Both ASP1 and ASP3 have all the information required to activate
both RK1 and RK3 in one exchange.  There is nothing to make sure of.  Setting
RC1 == RC3 will avoid having to configure twice as many RC values and is
perfectly consistent with the ASP/SGP approach.

> - ASP3 is INACTIVE. This means that all the traffic we try to send to ASP3
> is gonna be rejected, and then ASP1 will realise that ASP3 is not working,
> and it will stop the traffic between them. The application in ASP1 will
> observe timers. 
> 
> - ASP3 is ACTIVE and the msg was lost from a previous dialogue. If ASP1
> continue sending traffic, ASP1 will realise whether ASP1 is working properly
> or not
> 

Your description here is completely inconsistent with what is currently
performed for ASP/SGP.

> Yes. If ASP1 receives ASPIA from ASP3, this means that ASP3 goes to
> INACTIVE: no traffic can be handled by ASP3. Therefore the traffic path gets
> broken. If we want to have a traffic path, both ASPs should be in ACTIVE
> state according to the draft.

So, if ASP1 receives ASPIA for RC3 it needs to also deactivate RC1.  This
leaves two situations; either:

   o  an AS must be associated with two RC values (RC1 and RC3).

   o  or two AS's need their state bound together somehow.

The first violates the principle that RC == RK == AS.  The second is
so awkwards as to cause significant problems.

Setting RC1 == RC3 removes the problems: there is only one AS and RC == AS.

Setting RC1 == RC3 there is no need for both sides to activate.

--brian

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

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 7 Sep 2001 15:50:42 -0500

John,

I don't like having to try and couple the state of two AS's at
each ASP (one for RC1 and one for RC3).

But if RC1 == RC3 (which is both possible and sufficient) there
is only one AS state to track.  With only one AS state to track,
there is no need for both sides to send ASPAC.  It is sufficient
that either side be able to initiate, but only one exchange need
be performed to activate this single AS.

This would enforce a one-to-one mapping between AS on ASP1 and
the AS on ASP3.  However, this one-to-one mapping is even
required for your proposal, because otherwise there is no way
for ASP1 to know that RC1 and RC3 are related.

I believe that a double exchange of ASPAC complicates things way
more than necessary as a single exchange is always sufficient.

--brian

John Loughney wrote:                            (Fri, 07 Sep 2001 12:23:28)
> You are currently subscribed to sigtran as: [email-masked]

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

---

---

From: [email-masked]
Date: Sun, 9 Sep 2001 09:55:16 +0300

Hi Brian,

> more than necessary as a single exchange is always sufficient.

With regards to this, I think your proposal is a valid scenario.
However, I am not sure if this needs to be specified or not.
I'd like to get input from others on the list if your proposal
meets there needs.

John

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Sun, 9 Sep 2001 18:29:48 -0500

...resend

John,

I wasn't making a proposal.  I was commenting on your example.
Your example does not show where it is necessary to have a
double exchange.  Can you present a case where it is necessary?
Can anyone else?

--brian

John Loughney wrote:               (Sun, 09 Sep 2001 09:55:16)

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

---

---

From: [email-masked]
Date: Mon, 10 Sep 2001 09:40:35 +0300

Hi Brian,

> double exchange.  Can you present a case where it is necessary?

Actually, I agree with you.  Do you think that some text is needed?

br,
John

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 10 Sep 2001 02:52:46 -0500

John,

John Loughney wrote:                                         (Mon, 10 Sep 2001 09:40:35)
> Actually, I agree with you.  Do you think that some text is needed?

Text is certainly needed to cover IPSP cases.  As far as ASPAC is
concerned, text saying either side may initiate and RC values are
agreed between IPSPs should suffice.

--brian

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

---

---

From: Amish Chana <[email-masked]>
Date: Mon, 10 Sep 2001 10:23:31 +0100

Hi John & Brian,

In the example given where the RK is statically provisioned, Brian's comment 
is justified.

What about the dynamic registration scenario where ASP1 wishes to send 2 RKs 
to ASP3 while ASP3 only wants to send on RK? As an example, consider the 
case where each RK from ASP1 refers to a different SSN.

Text is certainly needed. Brian , see some comments below.

Amish

>concerned, text saying either side may initiate

What if they initiate both initiated the ASPAC simultaneously? I suggest the 
client be expected to initiate the ASPAC.

>and RC values are agreed between IPSPs should suffice.

How do they agree? If ASP1 initiates the ASPAC then does ASP3 use the same 
RC value?

>--brian

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

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 10 Sep 2001 12:57:34 -0500

Amish,

Amish Chana wrote:                              (Mon, 10 Sep 2001 10:23:31)
> case where each RK from ASP1 refers to a different SSN.

Following John's example, all three RC's would have to be activated
before traffic would flow.  It is simpler to assign one RK on each
side to one RC.

> client be expected to initiate the ASPAC.

Since they are for the same RC, each will receive ASPAC after sending
ASPAC and should reply with ASPAC Ack to complete the other's procedure.

> How do they agree? If ASP1 initiates the ASPAC then does ASP3 use the same 

The same way that they agree that RC1 and RC3 are related in John's
example.  The same ways that SGP and ASP agree on RC values.  They
are assigned that way.

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

---

---

From: "Javier Pastor-Balbas (ECE)" <[email-masked]>
Date: Tue, 11 Sep 2001 08:52:20 +0200

Hi John, 

Imagine that your IPSP is connected to several ones. That one of those several ones is connected to some more. Imagine that all of these IPSPs may not belong to the same company. In that case, if you have to agree on the RC used by both sides, you will need to have a RC assigner organism that assures the non repetition of RCs in a context...

BR // Javier.

> From: [email-masked] [mailto:[email-masked]]
> Sent: Monday, September 10, 2001 8:41 AM
> To: sigtran
> Subject: RE: [SUA issue 17 & M3UA issue #11] IPSP cases - AN EXAMPLE!
> 
> 
> Hi Brian,
> 

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 11 Sep 2001 02:09:52 -0500

Javier,

Javier Pastor-Balbas (ECE) wrote:                          (Tue, 11 Sep 2001 08:52:20)
> Hi John, 
> 
> Imagine that your IPSP is connected to several ones. That one of those
> several ones is connected to some more. Imagine that all of these IPSPs may
> not belong to the same company. In that case, if you have to agree on the RC
> used by both sides, you will need to have a RC assigner organism that
> assures the non repetition of RCs in a context...

Sounds like a good reason to support the routing key management
procedures (RKMM) in such an arrangement.  That would do away
with the need for such an assigner organism.

--brian

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

---

---

From: [email-masked]
Date: Tue, 11 Sep 2001 10:09:52 +0300

Hi Javier,

> Imagine that your IPSP is connected to several ones. That one 
> of those several ones is connected to some more. Imagine that 
> all of these IPSPs may not belong to the same company. In 
> that case, if you have to agree on the RC used by both sides, 
> you will need to have a RC assigner organism that assures the 
> non repetition of RCs in a context...

Perhaps we are getting tripped up on this.  If routing keys
are not pre-configured, then they should be exchanged.  As a
RC can identify an AS, each IPSP needs to inform its peer(s)
what RC it is.  However, ASPs at the IPSP MUST use the same RC.

I misinterpreted Brian's comments.  I assumed he was discussing
about ASPs at the same IPSP.  I agree with you with the above.

However, if the IPSPs have outside mechanisms for 'knowing'
the RK/RC/etc. of their peers (pre-configured, external
database, etc.) then the RCs would not need to be included.

br,
John

---

---

From: "Javier Pastor-Balbas (ECE)" <[email-masked]>
Date: Tue, 11 Sep 2001 12:33:15 +0200

Hi Brian, 

That doesn't solve the problem. You should use a negotiation algorithm to accord an RC number that is not used by any of the IPS involved. This can imply several tests. With the use of the double ASPAC, you easily solve it and you are using the same philosophy as the SG-ASP case.

BR // Javier.

> From: Brian F. G. Bidulock [mailto:[email-masked]]
> Sent: Tuesday, September 11, 2001 9:10 AM
> To: sigtran
> Importance: High

---

---

From: [email-masked]
Date: Tue, 11 Sep 2001 13:40:40 +0300

Hi Javier,

> That doesn't solve the problem. You should use a negotiation 
> algorithm to accord an RC number that is not used by any of 
> the IPS involved. This can imply several tests. With the use 
> of the double ASPAC, you easily solve it and you are using 
> the same philosophy as the SG-ASP case.

I agree.  I don't think that it is an excessively heavy 
procedure & gives a sanitity check that both ends of
the signaling connection are on the correct page.

John

---

---

From: [email-masked]
Date: Tue, 11 Sep 2001 14:14:28 +0300

Hi Javier & Brian,

> the signaling connection are on the correct page.

Optionally, if Brian REALLY objects to this, we could use
the NOTIFY message with the Routing Context.

So, it would be something like this:

ASP1 -------- ASPUP -------------> ASP3
ASP1 <------- ASPUP ACK ---------- ASP3

ASP1 -------- ASPAC (RC1) -------> ASP3
ASP1 <------- ASPAC ACK(RC1) ----- ASP3

ASP1 <------- NTFY (ASPAC,RC3) --- ASP3

Comments?

John

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 11 Sep 2001 06:35:02 -0500

John,

John Loughney wrote:                                         (Tue, 11 Sep 2001 13:40:40)
> the signaling connection are on the correct page.

If you are going to flip-flop, please go back an answer the
questions that I had to your double ASPAC example.  I would
really like to know how each IPSP relates RC1 to RC3.

--brian

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

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 11 Sep 2001 06:33:35 -0500

Javier,

Javier Pastor-Balbas (ECE) wrote:                          (Tue, 11 Sep 2001 12:33:15)
> Hi Brian, 
> 
> That doesn't solve the problem. You should use a negotiation algorithm to
> accord an RC number that is not used by any of the IPS involved.

It is not necessary to return an RC number not used by any of the IPSPs
involved.  The RC number is only interpreted in the context of a pair
of IPSPs.  An IPSP can return in a REG RSP any RC which is unique to the
traffic flow between the IPSP sending the REG REQ and that sending the
REG RSP.  RC values do not have global significance, nor do the RC values
used between IPSP A and B have any significance between B and C.

> This can imply several tests.

There is no test required.

> With the use of the double ASPAC, you easily solve it and you are using the
> same philosophy as the SG-ASP case.

With double ASPAC, the RC at A must be coupled to the RC a B either by
provisioning or by double REG REQ and REG RSP.  It is just double the
effort for nothing.

--brian

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

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 11 Sep 2001 06:37:55 -0500

John,

John Loughney wrote:                  (Tue, 11 Sep 2001 14:14:28)
> ASP1 <------- NTFY (ASPAC,RC3) --- ASP3

Why does RC1 and RC3 need to be different?  ASP and SGP
don't choose their own RC values!  Why ASP and ASP?

--brian

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

---

---

From: [email-masked]
Date: Tue, 11 Sep 2001 14:50:15 +0300

Hi Brian,

> don't choose their own RC values!  Why ASP and ASP?

Because an IPSP may have signaling connections to many
other IPSPs, each IPSP can be a separate AS.  

John

---

---

From: [email-masked]
Date: Tue, 11 Sep 2001 14:47:59 +0300

Hi Brian,
> really like to know how each IPSP relates RC1 to RC3.

If you have 3 IPSPs - A, B, C; each IPSP is a seperate AS.

	IPSP A == AS A, RC = a
	IPSP B == AS B, RC = b
	IPSP C == AS C, RC = c

Now, if A wants to send to B, it should use B's routing context.
Now, if A wants to send to C, it should use C's routing context.

Now, if B wants to send to A, it should use A's routing context.
Now, if B wants to send to C, it should use C's routing context.

Now, if C wants to send to B, it should use B's routing context.
Now, if C wants to send to A, it should use A's routing context.

I'll leave it to you to add D and E.

John

---

---

From: [email-masked]
Date: Tue, 11 Sep 2001 15:05:55 +0300

One more note, in the scenario below, it gets more complicated
if an ASP sits in 2 AS's ... for example as a backup. 

---

---

From: "Javier Pastor-Balbas (ECE)" <[email-masked]>
Date: Tue, 11 Sep 2001 14:35:27 +0200

Hi John, 

I prefer to use the double ASPAC. We don't need to add more extra procedures.

The rule is very simple: whenever you have an SS7 application using M3UA, this application (that takes part of ASP, IPSP) needs to activate the traffic towards it using ASPAC. That will be done with the reference called RC that points to a RK which will set the routing criteria. This is valid for IPSP and ASP model.

BR // Javier. 

> Sent: Tuesday, September 11, 2001 1:14 PM
> To: sigtran

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 11 Sep 2001 12:55:31 -0500

John,

John Loughney wrote:                        (Tue, 11 Sep 2001 14:50:15)
> other IPSPs, each IPSP can be a separate AS.  

So?  How is this a reason to make RC1 and RC3 different?

--brian

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

---

---

From: [email-masked]
Date: Wed, 12 Sep 2001 13:22:58 +0300

Brian
> So?  How is this a reason to make RC1 and RC3 different?

Because of what RCs are:

Routing Context - An Application Server Process may be configured to process
traffic within more than one Application Server.  In this case, the Routing
Context parameter is exchanged between the SGP and the ASP (or between two
ASPs), identifying the relevant Application Server.  From the perspective of
an SGP/ASP, the Routing Context uniquely identifies the range of traffic
associated with a particular Application Server, which the ASP is configured
to receive. There is a 1:1 relationship between a Routing Context value and
a Routing Key within an AS.  Therefore the Routing Context can be viewed as
an index into an AS Table containing the AS Routing Keys. The Routing
Context also uniquely identifies an SS7 entity (point code) into a SS7
network, as presented by the SG.  

John

---

---

From: Amish Chana <[email-masked]>
Date: Wed, 12 Sep 2001 12:30:24 +0100

Brian,

See comments below.

Amish

>before traffic would flow.  It is simpler to assign one RK on each

M3UAv8 states
1. An Application Server Process may be configured to process signalling 
traffic related to more than one Application Server, over a single SCTP 
Association.
2. At an ASP, the Routing Context parameter uniquely identifies the range of 
signalling traffic associated with each Application Server that the ASP is 
configured to receive.

According to the above, in the IPSP scenario where ASP1 serves two 
application servers two different RCs are required for each AS. Your 
suggestion of one RK and associated RC is only possible if the ASP handles 
the traffic of only one AS or allows multiple application servers to be 
associated with a single RK/RC combination (which breaks conformance with 
the above statements).

> > >John Loughney wrote:                                         (Mon, 10 
>Sep
> > >2001 09:40:35)
> > > > Hi Brian,
> > > >

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 12 Sep 2001 12:04:23 -0500

John,

SS7 is a peer to peer protocol.  RC1 identifies the traffic between
AS1 and AS3.  RC3 identifies the traffic between AS1 and AS3.  One
is redundant.

John Loughney wrote:                                         (Wed, 12 Sep 2001 13:22:58)
> network, as presented by the SG.  

This current definition has a single RC value identifying traffic in
both directions to and from an AS.  Using RC1 and RC3 in ASPAC is
inconsistent with this.

--brian

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

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 12 Sep 2001 12:06:53 -0500

Amish,

Amish Chana wrote:                                          (Wed, 12 Sep 2001 12:30:24)
> associated with a single RK/RC combination (which breaks conformance with 

The above quotes don't talk to the IPSP case.  Thus the issue.

--brian

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

---

---

From: Amish Chana <[email-masked]>
Date: Thu, 13 Sep 2001 09:55:21 +0100

Brian,

>The above quotes don't talk to the IPSP case.  Thus the issue.

In that case instead of redifining the elements and functions from the 
ASP-SGP specifications it would be best to remove all IPSP support from m3ua 
and sua and go ahead with your previous proposal for a mpa/spa.

This would help to create a more efficient protocol that does not inherit 
unnecessary ASP-SGP concepts.

Amish

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 13 Sep 2001 04:14:19 -0500

Amish,

Amish Chana wrote:  (Thu, 13 Sep 2001 09:55:21)
> unnecessary ASP-SGP concepts.

I agree.  Certainly either IPSP must be properly addressed in
the draft or removed.

But, I think we are alone in that opinion.

--brian

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

---

---

From: Amish Chana <[email-masked]>
Date: Thu, 13 Sep 2001 10:19:39 +0100

John

>both directions to and from an AS.  Using RC1 and RC3 in ASPAC is

Brian, has a valid point.
John, to demonstrate your proposal for different RC1 and RC3 values, lets 
examine the RC assignements in a possible implementation. For this example, 
lets say we have GSM MSC/VLR and HLR application servers in the IP domain.

Let ASP1 serve the application servers of the VLR(RC1) and MSC(RCM) and let 
ASP3(RC3) be part of the HLR AS.

Would you use RC1 for the UL and ISDA messages, and RC3 for the ISD and ULA 
messages or would you use RC3 for the UL and ISDA messages, and RC1 for the 
ISD and ULA messages?

If the VLR was in the IP domain and the HLR in the SS7 domain all these 
messages would be sent with RC1 by both the SGP and ASP.

Amish

---

---

From: "Javier Pastor-Balbas (ECE)" <[email-masked]>
Date: Thu, 13 Sep 2001 17:10:29 +0200

Hi Amish, 

Let's go back to the concept of RC. RC was mainly created to separate the traffic of two different AS that were served by the same ASP. I'm now referring to the SG-AS case. 

If we move to the IPS-IPS case, this should be treated in the same way. Let's consider that we have an IPSP serving two IPS (IPS-A and IPS-B) that communicates to another IPS (IPS-C). By using two RC (RC-A and RC-B) you can differenciate traffic coming to IPS-A from traffic coming to IPS-B from IPS-C.

Read below the responses to your mail...

> From: Amish Chana [mailto:[email-masked]]
> Sent: Thursday, September 13, 2001 11:20 AM
> To: sigtran
> > > Routing Context - An Application Server Process may be 
> configured to 
> >process
> > > traffic within more than one Application Server.  In this 
> case, the 
> >Routing
> > > Context parameter is exchanged between the SGP and the 
> ASP (or between 
> >two
> > > to receive. There is a 1:1 relationship between a Routing 
> Context value 
> >and
> > > a Routing Key within an AS.  Therefore the Routing 
> Context can be viewed 
> >as
You always use the RC that you got as result of the registration of the remote IPS.
This means:
	- Msgs from VLR (or MSC) to HLR contains (optionally) RC3
	- Msgs from HLR to VLR contains RC1
	- Msgs from HLR to MSC contains RCM

> messages would be sent with RC1 by both the SGP and ASP.
Yes, that is because this is a different scenario and SG relay data instead of guessing  what application it has to address on top of M3UA layer.

Cheers. // Javier.

> Amish

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

---

---

From: Amish Chana <[email-masked]>
Date: Thu, 13 Sep 2001 21:28:08 +0100

Hi Javier,

>Let's go back to the concept of RC. RC was mainly created to separate the 
>traffic of two different AS that were served by the same ASP. I'm now 
>referring to the SG-AS case.

OK.

>If we move to the IPS-IPS case, this should be treated in the same way. 
>Let's consider that we have an IPSP serving two IPS (IPS-A and IPS-B) that 
>communicates to another IPS (IPS-C). By using two RC (RC-A and RC-B) you 
>can differenciate traffic coming to IPS-A from traffic coming to IPS-B from 
>IPS-C.

Agreed.

>	- Msgs from HLR to MSC contains RCM

Why optionally? Is that beacase the ASP is only responsible for one ASP.

>Yes, that is because this is a different scenario and SG relay data instead 
>of guessing  what application it has to address on top of M3UA layer.

In the SGP/ASP case the ASP does not need the functionality to map different 
RCs to the outgoing messages (the RC value refers to the source AS), only 
the SGP needs to do the mapping. In the IPSP case, each IPSP has to map a RC 
value to the outgoing messages.

From the above discussion, I guess you are saying that the IPSP is an ASP 
which has inherited some of the functionality that would normally reside in 
the SGP. The SPMC may also be necessary if each IPS on the adjacent IPSP has 
a different point code. IPSP = ASP + SGP

Correct?

Cheers,
Amish

---

---

From: "Javier Pastor-Balbas (ECE)" <[email-masked]>
Date: Fri, 14 Sep 2001 15:33:48 +0200

Hi Amish, 

See answers below...

> Sent: Thursday, September 13, 2001 10:28 PM
> To: sigtran
> >You always use the RC that you got as result of the 
> registration of the 
> >remote IPS.
> >This means:
Yes.

> a different point code. IPSP = ASP + SGP
You could think of that. The IPSP has the part of functionality that SGP needs to manage the remote ASP since it need to do so. But that supposed "SGP" don't need to have connection to the SS7 world... ;-) and therefore is not an SGP. It's an IPSP.

Cheers // Javier.

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

---

---

From: Amish Chana <[email-masked]>
Date: Fri, 14 Sep 2001 16:23:42 +0100

Hi Javier,

>You could think of that. The IPSP has the part of functionality that SGP 
>needs to manage the remote ASP since it need to do so. But that supposed 
>"SGP" don't need to have connection to the SS7 world... ;-) and therefore 
>is not an SGP. It's an IPSP.
>

If the IPSP endpoint has partial SGP functionality then is the following 
implementation possible?

                                                +-------+
                                                |       |
                                          +-----+ SEP-C +
                                          |     |       |
     +--------+        +--------+   SS7   |     +-------+
     |        |  IP    |        +---------+
     | IPSP-A +--------+ IPSP-B |
     |        |        | /SGP-B +---------+
     +--------+        +--------+   SS7   |     +-------+
                                          |     |       |
                                          +-----+ SEP-D +
                                                |       |
                                                +-------+

In the above diagram IPSP-A is responsible for IPS-A, IPSP-B is responsible 
for IPS-B but also has full SGP functionality and hence is also able to 
connect to SEPs in the SS7 network.

In the above, could IPSP-B send 3 RKs to IPSP-A, one for traffic that can be 
handled by IPS-B (RC-B), one for SEP-C (RC-C) and one for SEP-D (RC-D)? 
Traffic from IPSP-A is then assigned one of three RCs. IPSP-A sees IPSP-B 
has hosting 3 IP servers. Traffic arriving at IPSP-B with RC-C or RC-D is 
simply forwarded to MTP3 for further forwarding to the concerned SS7 
endpoint.

IPSP-B/SGP-B could still be used even if IPS-B did not exist. The difference 
from the normal SGP/ASP case is that a MGC or IP resident database sees all 
endpoints as existing in the IP domain and does not need different 
functionality when connecting to a SGP or other IPSP.

Cheers,
Amish

---

---

From: [email-masked]
Date: Mon, 17 Sep 2001 10:12:44 +0300

Hi Amish,

> In the SGP/ASP case the ASP does not need the functionality 
> to map different RCs to the outgoing messages (the RC value 
> refers to the source AS), only  the SGP needs to do the mapping. 
> In the IPSP case, each IPSP has to map a RC  value to the outgoing 
> messages.

Not exactly - as it is possible that an ASP may be configured
to operate under more than one AS, it should be able to
map different RCs to outgoing messages.  

best regards,
John

---

---

From: "Javier Pastor-Balbas (ECE)" <[email-masked]>
Date: Mon, 17 Sep 2001 09:37:14 +0200

Hi Amish

> Sent: Friday, September 14, 2001 5:24 PM
> To: sigtran
> > > to map different
When the B node is acting as SGP it works in the same way as it is defined. SG is a relay point and no RC are send to IPSP-A (imagine of a ASP-A SGP-B scenario). IPSP-B is the one that would send RC to IPSP-A to say IPSP-A what traffic is dealing with. On the other hand IPSP-A will know, as it knows in the ASP-SGP case, what SG it has to use to get SEP-D and SEP-C. Therefore, only when an SS7 application is located in the node (no SG case) you have to interchage RC.

Cheers // Javier.

---

---

---

From: "Javier Pastor-Balbas (ECE)" <[email-masked]>
Date: Mon, 17 Sep 2001 09:59:22 +0200

Hi John, 

Are you working on any text about this? I think we should work together to have the same view in M3UA and SUA. I'm reading the new version of M3UA (v9) to add some more text about the IPSP cases. I'll keep you  informed of what I think is missing.

Cheers // Javier.

> Sent: Monday, September 17, 2001 9:13 AM
> To: sigtran

---

---

From: Amish Chana <[email-masked]>
Date: Mon, 17 Sep 2001 10:04:48 +0100

Hi Javier,

Would it not be more appropriate to have a symmetrical protocol for the 
example shown below?

In the current ASP/SGP scenario a SS7 node does not know that a remote point 
code exists in the IP domain, likewise could a IPSP or ASP not know that a 
point code exists in the SS7 domain?

Cheers,
Amish

>When the B node is acting as SGP it works in the same way as it is defined. 
>SG is a relay point and no RC are send to IPSP-A (imagine of a ASP-A SGP-B 
>scenario). IPSP-B is the one that would send RC to IPSP-A to say IPSP-A 
>what traffic is dealing with. On the other hand IPSP-A will know, as it 
>knows in the ASP-SGP case, what SG it has to use to get SEP-D and SEP-C. 
>Therefore, only when an SS7 application is located in the node (no SG case) 
>you have to interchage RC.
>
>Cheers // Javier.
>

---

---

From: [email-masked]
Date: Mon, 17 Sep 2001 13:02:07 +0300

Hi Amish,

> Would it not be more appropriate to have a symmetrical 
> protocol for the example shown below?
> 
> In the current ASP/SGP scenario a SS7 node does not know that 
> a remote point code exists in the IP domain, likewise could a 
> IPSP or ASP not know that a point code exists in the SS7 domain?

I fail to see your point.  For some protocols, such as TCAP,
it most likely would not matter.  

It is outside of the scope of SIGTRAN to make changes to
SS7 protocols, so I think that we cannot do anything 
so that a SS7 node would know anything about the IP 
domain.

John

---

---

From: Amish Chana <[email-masked]>
Date: Mon, 17 Sep 2001 11:46:03 +0100

Hi John,

see below for comments.

>I fail to see your point.

It appears so.

>For some protocols, such as TCAP,

I am not saying that changes are required to the SS7 protocols or their 
primitives to the UAs.

Currently RCs are assigned in a different manner at a ASP depending on 
whether the remote point code is in the SS7 or IP network:
1) If the point code is in the SS7 network an ASP uses the RC of the AS that 
originated the message.
2) If the point code is in the IP network an ASP uses the RC of the AS in 
the peer node.

I am saying that a RC should be associated with each node in the SS7 
network. Messages from the ASP to the SGP should use the RC that refers to 
the respective point code in the SS7 network. This means that the RC 
assignment scheme in (1) is not necessary. RCs would then only be assigned 
on a destination basis, i.e. they refer to the destination AS or SS7 node.

Regards,
Amish

---

---

From: [email-masked]
Date: Mon, 17 Sep 2001 14:40:28 +0300

Hi Amish,

> I am not saying that changes are required to the SS7 
> protocols or their primitives to the UAs.
> 
> Currently RCs are assigned in a different manner at a ASP 
> depending on whether the remote point code is in the SS7 or 
> IP network:
> 1) If the point code is in the SS7 network an ASP uses the RC 
> of the AS that originated the message.
> 2) If the point code is in the IP network an ASP uses the RC 
> of the AS in the peer node.
> 
> network. Messages from the ASP to the SGP should use the RC 
> that refers to the respective point code in the SS7 network. This
> means that the RC assignment scheme in (1) is not necessary. RCs would 
> then only be assigned on a destination basis, i.e. they refer to the 
> destination AS or SS7 node.

I think that for both cases, if we can come to an agreement on what 
RC is / represents, then write the proper text in chapter 4,
that would be enough.

From M3UA v08:

 1.4.2 Routing Contexts and Routing Keys

 1.4.2.1 Overview

 The distribution of SS7 messages between the SGP and the Application 
 Servers is determined by the Routing Keys and their associated Routing
 Contexts. A Routing Key is essentially a set of SS7 parameters used to 
 filter SS7 messages, whereas the Routing Context parameter is a 4-byte 
 value (integer) that is associated to that Routing Key in a 1:1 
 relationship. The Routing Context therefore can be viewed as an index 
 into a sending node's Message Distribution Table containing the Routing 
 Key entries.

So, if we can agree that the RC is sender specific & identifies that
peer to which the IPSP/ASP is sending to, I think that this is enough.

Additionally, I do not think we can or should guarantee uniqueness
of the RC between 2 peers in the IPSP case - more spefically,
I believe that RC is uni-directional in nature.

br,
John

---

---

From: Amish Chana <[email-masked]>
Date: Mon, 17 Sep 2001 16:43:28 +0100

Hi John,

see below for responses.

Amish

>peer to which the IPSP/ASP is sending to, I think that this is enough.

I'll agree with the sender specific, but I am suggesting the use of RC to 
identify:
1) the Application server to which a SGP/IPSP is sending traffic to, or
2) a SS7 end-point node to which an ASP is sending traffic to.

The first sentance of the text you quoted does not apply to point (2). The 
following flow diagram illustrates the messages that would have to be 
exchanged for my suggestion.

             ASP1                             SGP
              |                                |
              |-------------ASP Up------------>|
              |<---------ASP Up Ack------------|
              |                                |
           1. |-----REGISTER REQ(LRC1,RK1)---->|  LRC: Local Routing
              |                                |       Context
           2. |<---REGISTER RESP(LRC1,RC1)-----|   RK: Routing Key
              |                                |   RC: Routing Context
              |                                |
           3. |-------- ASP Active(RC1)------->|
           4. |<----ASP Active Ack (RC1)-------|
              |                                |
              |                                |
           5. |<----REGISTER REQ(LRC2,RK2)-----|
              |                                |
           6. |----REGISTER RESP(LRC2,RC2)---->|
              |                                |
              |                                |
           7. |<------- ASP Active(RC2)--------|
           8. |-----ASP Active Ack (RC2)------>|
              |                                |
              |                                |

Messages 1-4 are from the normal ASP registration process. Messages 5-8 are  
required by my proposal for symmetry. RK2 refers to a SS7 node and only 
contains the point code of this node in the DPC field of the RK. None of the 
optional parameters are used (except for NA if required).

When the route-set of this SS7 node becomes active the SGP sends the ASP 
Active message(7).

Additional REG REQs will be required from the SGP to the ASP for other  
nodes in the SS7 network.

>I believe that RC is uni-directional in nature.

Okay. Note in the above flow diagram uniqueness is not expected as the AS 
and SS7 node have different point codes and hence the DPC field is different 
in both REG REQ messages.

---

---

From: "Asveren, Tolga" <[email-masked]>
Date: Mon, 17 Sep 2001 12:01:27 -0500

Hi Amish,

please  see cooments questions below.

 Tolga

> Sent: Monday, September 17, 2001 11:43 AM
> To: sigtran
[TOLGA] Why do you think that the current approach is not enough for ASP-SG case? As far as I can see ASP-SG communication is O.K. and IMHO it is not so good to change it because something else is needed in IPSP case. For the cases you have described above there is DAVA, DUNA etc.... 
> in both REG REQ messages.

---
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: Mon, 17 Sep 2001 12:13:33 -0500

Amish,

In your example, how is ASP1 to know that RC1 is related to RC2?
How is ASP2 (SGP) to know that RC2 is related to RC1?  How do they
know when to start traffic in either direction?

--brian

Amish Chana wrote:       (Mon, 17 Sep 2001 16:43:28)

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

---

---

From: "Javier Pastor-Balbas (ECE)" <[email-masked]>
Date: Mon, 17 Sep 2001 19:13:25 +0200

Hi Amish, 

The SS7 SPC are supposed to be known by the AS and the SG's SPC are supposed to be known by the SS7 nodes. In SS7 you define and set the SPCs that you use and you have routing tables to deal with the right path to follow. It is done at configuration time.

IPSP has nothing to do with the SS7 domain, it is only IP. ASP will know what SPC it has to communicate by configuration. And from there it will start all the registration procedures to get the RC reference. RC is only needed for an IP node to know where to send traffic based on SPC through the IP network. It is needed in all communication from the SG to the IP world. From the SG to the SS7 world, the RL included in the msgs will be used instead. It will be also needed in all the IPSP communication that uses SPC, as SS7 applications (located at IPSP) do.

Cheers // Javier.

> Sent: Monday, September 17, 2001 11:05 AM
> To: sigtran
> a remote point 

---

---

---

From: "Javier Pastor-Balbas (ECE)" <[email-masked]>
Date: Mon, 17 Sep 2001 19:45:55 +0200

Hi Amish,

See comments below.

Cheers // Javier.

> Sent: Monday, September 17, 2001 5:43 PM
> To: sigtran

I only see this scenario when SGP is acting as IPSP at the same time since sending RC in the ASP to SGP direction is only valid for IPSP to detect to what IPS the message is intended to be sent.

> When the route-set of this SS7 node becomes active the SGP 

You should have the complete MTP3 routing table with all the STPs and SEPs. Having registration procedures makes sense in the IP world since we are dealing with point2point communication. But in SS7 MTP has huge routing tables with a lot of possible paths. It is not worthwhile since you are going to use just a few of destinations. 

Another point is: how would you know that a SEP is active? You can have a network of STPs and link in the middle...

Cheers // Javier.

---

---

---

From: Amish Chana <[email-masked]>
Date: Tue, 18 Sep 2001 13:20:49 +0100

Hi Tolga,

>[TOLGA] Why do you think that the current approach is not enough for ASP-SG 
>case? As far as I can see ASP-SG communication is O.K. and IMHO it is not 
>so good to change it because something else is needed in IPSP case. For the 
>cases you have described above there is DAVA, DUNA etc....

For the ability to have an ASP that does not need to distinguish between 
point codes that are in the IP domain and point codes that are in the SS7 
domain.

You will notice that the message flows that I proposed are very similar to 
those given for standard IPSP-IPSP examples. In effect, M3UA (or SUA) in the 
ASP does not need to distinguish outgoing messages to an IP node or SS7 node 
and assign RCs in a different manner depending on whether the message 
destined to a IPnode or SS7 SEP. I am suggesting RC assignment on a 
end-point basis, where it refers a AS in of a IPSP or a SEP for messages 
destined to the SS7 network.

Cheers,
Amish

---

---

From: Amish Chana <[email-masked]>
Date: Tue, 18 Sep 2001 13:22:48 +0100

Hi Brian,

>How is ASP2 (SGP) to know that RC2 is related to RC1?

I am working within the context of John's IPSP example. The following is 

>How do they know when to start traffic in either direction?

ASP ACTIVE with the respective RC (as per John's comment).

Amish

---

---

From: Amish Chana <[email-masked]>
Date: Tue, 18 Sep 2001 13:25:24 +0100

Hi Javier,

>The SS7 SPC are supposed to be known by the AS and the SG's SPC are
>supposed to be known by the SS7 nodes. In SS7 you define and set the SPCs
>that you use and you have routing tables to deal with the right path to
>follow. It is done at configuration time.

Yes, I fully agree. How is routing in the traditional SS7 network relevant?

>IPSP has nothing to do with the SS7 domain, it is only IP.
Yes.

>ASP will know
>what SPC it has to communicate by configuration. And from there it will
>start all the registration procedures to get the RC reference. RC is only
>needed for an IP node to know where to send traffic based on SPC through
>the IP network. It is needed in all communication from the SG to the IP
>world.

Right. I am suggesting applying this concept to communication from the IP 
world to the SG.

>From the SG to the SS7 world, the RL included in the msgs will be
>used instead. It will be also needed in all the IPSP communication that
>uses SPC, as SS7 applications (located at IPSP) do.

Yes.

Amish

---

---

From: Amish Chana <[email-masked]>
Date: Tue, 18 Sep 2001 13:56:08 +0100

Javier,

See responses below.

Amish

>I only see this scenario when SGP is acting as IPSP at the same time since 
>sending RC in the ASP to SGP direction is only valid for IPSP to detect to 
>what IPS the message is intended to be sent.
>

I am not sure about ANSI networks but in networks conforming to ITU and ETSI 
standards present day switches can be configured to act as both a SEP and 
STP. We should therefore not exclude the case where a node can be configured 
as both an AS and a SG. A ASP that exists only in the IP domain with an 
association to a host with combined ASP/SGP functionality should assign RCs 
to outgoing messages in the same manner, i.e. all the refer to the 
destination and some of them do not refer to the source AS.

>You should have the complete MTP3 routing table with all the STPs and SEPs. 
>Having registration procedures makes sense in the IP world since we are 
>dealing with point2point communication. But in SS7 MTP has huge routing 
>tables with a lot of possible paths. It is not worthwhile since you are 
>going to use just a few of destinations.
>

The above proposal does not apply to SS7 part of the network. It does not 
apply or impact SS7 routing tables, SS7 protocol standards, MTP3, SS7 
protocol primitives, etc. It simply aims to harmonise the RC assignment 
process, irrespective of whether the message from a AS is destined to a SS7 
node or another AS.

>Another point is: how would you know that a SEP is active? You can have a 
>network of STPs and link in the middle...

Since the above proposal does not change how the SG sees the SS7 network, 
then my answer would be the same way that the SG currently knows a SEP is 
active or the same method in which it detects the link in the middle has ...

---

---

From: "Javier Pastor-Balbas (ECE)" <[email-masked]>
Date: Tue, 18 Sep 2001 18:13:34 +0200

Hi Amish, 

See below.

BR // Javier.

> Sent: Tuesday, September 18, 2001 2:25 PM
> To: sigtran
I think I don't get your point... From communication from the ASP to SGP no extra routing info is needed because you already should have a table with SPC-SG and SG-SGPs entries. From the SPC that you want to reach, you get the SG and from the SG the specific SGP. The management of the SS7 SPC endpoints is done by MTP3 layer in the SS7 domain. The SG informs ASP with the apropiate message when something is wrong or it gets fixed.

---

---

---

From: "Javier Pastor-Balbas (ECE)" <[email-masked]>
Date: Tue, 18 Sep 2001 18:41:59 +0200

Hi Amish, 

See below.

Cheers // Javier.

> Sent: Tuesday, September 18, 2001 2:56 PM
> To: sigtran
> > >               |                                |   RC: 
> Routing Context
That's OK. You only have to go to the ASP text in the draft and act according to it. :-)

> process, irrespective of whether the message from a AS is 

I think this is one point where I don't agree with you. In the communication from SGP to ASP it's not practical to send registration since the SGP can access to a lot of SPCs in the SS7 network. The ASP only needs to access some of them. Under my point of view, it's much better to configure this information by hand. The registration option implies that the ASP is gonna have a big table with a lot of unused entries. And evenmore, the registration message would be really big. It's not practical...

---

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 18 Sep 2001 12:25:00 -0500

Amish,

--brian

Amish Chana wrote:                              (Tue, 18 Sep 2001 13:22:48)

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

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 18 Sep 2001 12:54:35 -0500

Javier,

Javier Pastor-Balbas (ECE) wrote:                          (Tue, 18 Sep 2001 18:41:59)

> > process, irrespective of whether the message from a AS is destined to a
> > SS7 node or another AS.
> 
> I think this is one point where I don't agree with you. In the communication
> from SGP to ASP it's not practical to send registration since the SGP can
> access to a lot of SPCs in the SS7 network. The ASP only needs to access
> some of them. Under my point of view, it's much better to configure this
> information by hand. The registration option implies that the ASP is gonna
> have a big table with a lot of unused entries. And evenmore, the
> registration message would be really big. It's not practical...
> 

It is not practical in the IPSP case either...

--brian

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

---

---

From: "Asveren, Tolga" <[email-masked]>
Date: Wed, 19 Sep 2001 18:39:18 -0500

Hi,

Maybe this will be quite basic question with IPSP case but what was the
reason that definition of IPSP is changed from "An IPSP is essentially the
same as an ASP, except that it uses M3UA in a peer-to-peer fashion" in
draft5 to "An IPSP is essentially the same as an ASP, except that is uses
M3UA in a point-to-point fashion" in draft6?
My understanding of point-to-point communication is that there are only two
endpoints communicating and so no distribution of messages, because there is
only one place to which one endpoint can send the messages(so no route
keys).

   Tolga

---

---

From: Amish Chana <[email-masked]>
Date: Mon, 24 Sep 2001 15:33:59 +0100

Hi Tolga,

See comments below. :>

Amish

>[TOLGA] In draft8, for ASP->SG traffic, DPC reachability information is 
>used (although it is said :and possibly other elements of the outgoing 
>message such as the SLS value)to select a SG.

A SGP does not select between SGs. "Signalling Gateway Process (SGP) - A 
process instance of a Signalling Gateway."

>For ASP->SG direction, one can use RC to select SG, but again this should 
>be the same RC, which was used for SG->ASP case. Because for ASP->SG it is 
>important to select a SG, with which ASPAC-ASPACACK message exchange is 
>done (to select SG based on RC is not something mandated by draft, I speak 
>just for the case, if one wants to do it in this way)My personal opinion is 
>that selecting SG by considering ASPAC-ASPACACK message exchange can be 
>usefull for screening on SG side and to allow messaging to be on or off in 
>both directions for two PCs (although there were also discussions whether 
>one should allow messaging path to be open only in one direction or not, 
>again that it should be on or off for both directions is my personal 
>opinion)
>If you want to change the RC mechanism for ASP->SG case, then to be able to 
>provide services described above, you will need to put two RC value in DATA 
>message, one RC=DPC, whihc you are proposing, the other one the RC, which 
>was used for ASPAC-ASPACACK messaging.

Would you say the same analogy can be applied to the IPSP case?

---

---

From: "Asveren, Tolga" <[email-masked]>
Date: Mon, 24 Sep 2001 10:03:29 -0500

Hi Amish,

Just a small clarification below.

  Tolga

> Sent: Monday, September 24, 2001 10:34 AM
> To: sigtran
[TOLGA] What I meant was selection of SG by ASP for outgoing traffic. In draft8 for that purpose DPC reachability by SGs, is used.

---

---

---

From: "Javier Pastor-Balbas (ECE)" <[email-masked]>
Date: Mon, 24 Sep 2001 20:21:56 +0200

Hi Brian, 

Answers below.

BR // Javier.

> Sent: Tuesday, September 18, 2001 7:55 PM
> To: sigtran

You don't have to use it since it is an optional procedure.  :-)

---

---

From: "Javier Pastor-Balbas (ECE)" <[email-masked]>
Date: Mon, 24 Sep 2001 20:24:53 +0200

Hi Amish,

Answers below.

Cheers // Javier.

> Sent: Monday, September 24, 2001 1:09 PM
> To: sigtran
> Brian/Javier,
> See comment below.
> Are you'll not imposing limitations on the functionality of the ASP?
> Consider the case where the ASP is a HLR database with M3UA, 
> where full GTT 
> is performed to determine the point code of MSCs in the SS7 
> network. It is 
> possible, today, for a HLR to know the point codes of all the 
> MSCs - but you 
> say that the ASP only needs to access some of them. Why?
> 
> 

Well, it depends on how you define your network. You can access as many nodes as your implementation allows... There are not imposed limits there.

---

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 24 Sep 2001 15:02:38 -0500

Javier,

Javier Pastor-Balbas (ECE) wrote:                          (Mon, 24 Sep 2001 20:21:56)
> You don't have to use it since it is an optional procedure.  :-)

To which optional procedure are you referring?

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

---