Subject: IPSP-IPSP summary

From: Dennis Niermann <[email-masked]>
Date: Sun, 04 Nov 2001 17:23:10 -0600

I would like to take a step back and say that I 
believe that the real difference between the two IPSP-IPSP 
alternatives can be summarized as such:

[DE] double-ended: RK corresponds to a single AS.
[SE] single-ended: RK corresponds to a AS pair.

On one hand, one might think of a RK as identifying
traffic for a particular destination (AS) [DE]. 
On the other hand, one might think of a RK  
as identifying traffic between a pair of destinations 
(ASs) [SE]. 

Which of these more closely matches the spirit of
the current SGP-ASP is most of what the debate is about.
On the one hand, you can make the case that a "Routing Key"
should refer to an route and is not an AS identifier [SE].
On the other hand, there is a lot of language throughout 
the M3UA specification that explicitly and implicitly treats RK
and RCs as identifying an AS [DE].

You can make one alternative or the other seem more
complicated or unworkable if you try to apply the semantics 
of one alternative to the other. I think that we should
move pass that. I would like to summarize my understanding
of the impacts in what I think are the key areas of impact
compared to the ASP-SGP case.

IMPACT TO ROUTING LOGIC
Probably the most important impact that IPSP-IPSP
functionality introduces into an M3UA implementation 
is the impact to the routing logic for outgoing traffic
at an ASP. When the IPSP-IPSP possibility is included,
an ASP needs to route some traffic to SS7 destinations 
(and thus through a SG) and at the same time route other 
traffic to a M3UA AS at a IPSP. 

This is an impact for both the SE and DE alternatives.

I see two general approaches to the issue:
1) try to find an M3UA AS match and if that fails
try to find an SGP (or vice-versa).
2) merge the two into a single lookup logic.

For the DE alternative, the logic for routing approach 1
would be as follows:
 First use the same routing logic that a SGP would 
 use. Based on routing label info, find a RK. This
 identifies an AS. From the AS select an approriate ASP,
 taking into account traffic mode and the AS activation 
 state for each ASP.
 If RK lookup comes up empty, use the same logic that the ASP
 currently uses to route outgoing traffic. Find a SGP
 based on the DPC and NA, taking into account destination
 availability, congestion, etc.

You could describe the DE logic for routing approach 2
as follows:
 Define a "pseudo AS" for each possible SS7 destination. 
 Its RK would include NA and DPC only.
 Now apply the routing logic of an SGP of doing a RK lookup
 from routing label info. This one lookup might yield a M3UA AS 
 at a IPSP or it might yield a SS7 destination serviced by a SGP.
 
Both of these approaches work, there might be others. 

I think that the SE logic for routing might be a 
little different, but not necessarily more complicated.
I think I should let a SE proponent describe its algorithm.

IMPACT TO M3UA MESSAGES
The DE approach would require both an originating RC
and a destination RC parameter in the DATA message
(since the DE paradigm uses an RC for an AS).
The SE approach needs only the one RC parameter
in the DATA message (since the SE paradigm uses an RC
for AS-AS path).
So yes, only the DE approach implies a change to an 
M3UA message.

IMPACT TO MESSAGE FLOW
For both SE and DE there can be the need for ASPSM to 
flow from either direction. This is because either side may
have an AS become active or inactive thus need to 
communicate that fact to the otherside (this has been agreed to).
In line with the semantics of the approaches, 
an ASPAC in the SE approach activates the path between
the two ASs and thus a single ASPAC, ASPAC ACK sequence
completes the activation.
Whereas, in the DE approach an ASPAC is activating its
own AS(s) and thus the other ASP would also be obligated
to activate its own AS(s).

IMPACT TO CONFIGURATION DATA
Since in the DE approach, a RK maps to an AS, the number of 
RKs and RCs grows proportionally to the number ASs. This 
is true both at a particular IPSP and from a network-wide
perspective.

Since in the SE approach, a RK maps to an AS pair, 
the number of RKs and RCs grows with the 
number of such pairs. At a particular IPSP the count
of AS pairs is equal to the number of external ASs,
but on a network perspective it can be much larger.

 

-- 
---------------------------------------------------------------
 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: Dennis Niermann <[email-masked]>
Date: Mon, 05 Nov 2001 08:08:33 -0600

Hi Brian,
see below...

"Brian F. G. Bidulock" wrote:
> 
> Dennis,
> 
> Please see comments below...
> 
> Dennis Niermann wrote:                                     (Sun, 04 Nov 2001 17:23:10)
> >
> SGP only uses 1 RC to represent both directions of
> traffic flow.  What you are describing is the SE approach,
> not the DE approach.
I am describing the DE approach. I am saying that the RK
lookup yields an AS (not an AS pair as in SE). And, I am saying that 
this is exactly what is currently described for SG-AS.  

> For RK with NA and DPC only there is no need for RC.  All
> ASPACs can be implicit.  DUNA/DAVA identify which DPCs are
> available or not via whichever IPSPs.
I did not mention an RC. For both SE and DE, an RC is necessary
if the association carries traffic for multiple ASs, 
supperfluous if it does not.

> 
> This is not a proposal at all.  This is currently accomplished
> within the model for all points (whether they be SGP/ASP/IPSP).
I did not say that this was a new proposal.
It is an attempt to bring clarity and accuracy to the 
DE approach by describing exactly what it does. And to show that it
is completely in line with the current M3UA spec and the SG-ASP case.
It is the SE approach that introduces inconsistent routing logic.

> Perhaps an example?  Could you show how your "modified",
> "pseudo AS" approach works in the simple 3-AS example
> that I provided?
Your example did not have any SS7 destinations serviced by an SGP.
It only included AS's services by IPSPs.  So, it is not applicable. 

> --brian
> > You are currently subscribed to sigtran as: [email-masked]
> Brian F. G. Bidulock
> [email-masked]
> http://www.openss7.org/

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 5 Nov 2001 08:29:26 -0600

Dennis,

Oh, I see.  You mean that your proposal is not applicable
to the IPSP case.  So what are you talking about?

--brian

Dennis Niermann wrote:                                     (Mon, 05 Nov 2001 08:08:33)
> You are currently subscribed to sigtran as: [email-masked]

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

---

---

From: Dennis Niermann <[email-masked]>
Date: Mon, 05 Nov 2001 09:02:41 -0600

Brian, why would you say that. 
Of course it is. It is all about the IPSP-IPSP case.
"Double ended" (DE) is a definition for the IPSP-IPSP case.
In my opinion, it is the IPSP-IPSP definition that happens 
to be the most consistent with the concepts and semantics 
from the SGP-ASP case.

/Dennis

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

---

---

From: "Javier Pastor-Balbas (ECE)" <[email-masked]>
Date: Mon, 5 Nov 2001 16:05:43 +0100

Hi Dennis, 

Very good summary. Only one minor remark and more aspects to assist in comparation. See below...

Cheers // Javier.

> -----Original Message-----
> From: Dennis Niermann [mailto:[email-masked]]
> Sent: Monday, November 05, 2001 12:23 AM
> To: sigtran
> Subject: IPSP-IPSP summary
> 
> 
> 

Very good description for DE.

> I think I should let a SE proponent describe its algorithm.

Brian, can I see your approach ??

> So yes, only the DE approach implies a change to an 

For DE only the RC of the receiving AS is necessary, as in the case of SG->AS communication. Hence you just need to send one RC within the DATA message so that you don't need to modify the M3UA message either...

Some more issues to be add:

REGISTRATION
SE also makes automatic registration impossible and go back the the client-server philosophy leaving away the peer-to-peer. It is not acceptable that one IPSP send the its own RK and the peer's RK to the peer IPSP in Registration receiving as a response a common RC. You have to preconfigure all the network. And it can be a big network... 

DE handles the registration in the same way as AS-SG. All the ASs registrate their RK and get a RC to be sent when sending data from the other peer to differenciate the receiving AS within one association.

PEER-TO-PEER
As I have said peer to peer philosophy is lost in SE unless double configuration is done (the same for each peer). This makes REG useless

DE support perfectly Peer2peer since any node can initiate communication with minimum configuration. It's also compatible with REG procedures.

RC DEFINITION
Meaning of RC is also lost in SE. RC defines one AS and not a communication between two ASs. 

DE define them per AS as they are defined in M3UAv09.

RC UNICITY IN EACH NODE
It has also been demonstrated for SE that in the simple scenario   ASP1------ASP2-------ASP3, ASP2 can obtain two RC from ASP1 and ASP3 that are the same value. In that case another characteristic of RC (index of RK table) has been aniquilated.

In DE as each ASP gives the RC for the peer RK being registrated, each ASP can control the unicity of RC and the "routing table index" feature.

KEEPING NODE NEEDS vs KEEPING NUMBER OF MESSAGES IN THE WIRE
SE tries to keep the same messages going through the network: one REG, one ASPAC, ... This is not acceptable since you can not treat an ASP with an SS7 application over it as a SG that only has to relay traffic. Different kinds of communication due to the different node needs.

DE addapts the existing messages to the ASP needs following the ASP philosophy showed in M3UAv9. All the ASPs have SS7 application running above M3UA and the have RK and those RKs have to be registrated in the other end (ASP or SGP).

> but on a network perspective it can be much larger.

Operation and Management can be almost impossible if you have to define the relations between each pair of ASs for all your network. This situation is even worse if you mix more than one operator...

> 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, 5 Nov 2001 09:28:03 -0600

Dennis,

Because you said it was not applicable to my simple 3 AS
IPSP-IPSP example.  Please demonstrate how your proposal
will work for the example if it is intended to address
IPSP-IPSP.

--brian

Dennis Niermann wrote:                                     (Mon, 05 Nov 2001 09:02:41)

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

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 5 Nov 2001 09:43:06 -0600

Javier,

Javier Pastor-Balbas (ECE) wrote:                          (Mon, 05 Nov 2001 16:05:43)
> Brian, can I see your approach ??

Already described in example.

> For DE only the RC of the receiving AS is necessary,

SUA (and M3UA for that matter) requires that the sending
AS be identified.

> as in the case of
> SG->AS communication. Hence you just need to send one RC within the DATA
> message so that you don't need to modify the M3UA message either...

The only way to not modify the message is to have RC identify both
AS (i.e., the traffic flow) as in the SE case.  I wonder why so
many changes are required for DE ;)

> SE also makes automatic registration impossible and go back the the
> client-server philosophy leaving away the peer-to-peer. It is not acceptable
> that one IPSP send the its own RK and the peer's RK to the peer IPSP in
> Registration receiving as a response a common RC. You have to preconfigure
> all the network. And it can be a big network... 

It is not acceptable for both sides to be misconfigured as in the
DE situation with no means for either side to detect the problem.

> 
> DE handles the registration in the same way as AS-SG.

No.  There are two messages instead of one and the RK is the wrong
RK (the local RK not the remote).

> All the ASs registrate their RK

But it is the wrong RK in Dennis' approach.

> and get a RC to be sent when sending data from the other peer to
> differenciate the receiving AS within one association.

But in Dennis' examples, he sends the other RC (not the one
that corresponds to the forward RK.)

> 
> PEER-TO-PEER
> As I have said peer to peer philosophy is lost in SE unless double
> configuration is done (the same for each peer). This makes REG useless DE
> support perfectly Peer2peer since any node can initiate communication with
> minimum configuration. It's also compatible with REG procedures.

These assertions have not be supported by example.

> 
> RC DEFINITION
> Meaning of RC is also lost in SE.

The meaning of RC (Routing Context <== read the words) are maintained
in SE: RC identifies a bidirectional traffic flow.  DE breaks this.

> RC defines one AS and not a communication between two ASs. 

RC defines communication between AS and SG.  For DE you would have
it identify a single AS and half a traffic flow.  That is unacceptable.

> DE define them per AS as they are defined in M3UAv09.

They are not defined per AS in M3UAv09.  Your assertion is incorrect.

> 
> RC UNICITY IN EACH NODE
> It has also been demonstrated for SE that in the simple scenario
> ASP1------ASP2-------ASP3, ASP2 can obtain two RC from ASP1 and ASP3 that
> are the same value. In that case another characteristic of RC (index of RK
> table) has been aniquilated.

ASPs do not have an RK table.  SGPs do.  At the SGP, the RC can be
viewed as an index into the RK table.  This was never the case at
the ASP.

> In DE as each ASP gives the RC for the peer RK being registrated, each ASP
> can control the unicity of RC and the "routing table index" feature.

But in Dennis' examples, he does not send the RC corresponding
to the forward RK with data, but sends the RC that DE is associating
with the "sending" AS instead.  Not to mention that you need to
include "both" DE RCs in DATA and SNMM for ASPTM.  There is no simple
way for the receiver of these "paired" RCs in DATA and SNMM to verify
the validity of the pairing.  Two RC values are used where a single
value will do.

> SE tries to keep the same messages going through the network: one REG, one
> ASPAC, ...

No, by collapsing the two RC values that DE would assign to one RC value,
it is no longer necessary to have twice as many messags: a nice benefit
of the approach.

> This is not acceptable since you can not treat an ASP with an SS7
> application over it as a SG that only has to relay traffic.

Relay is precluded in M3UAv09: point-to-point is all that is provided for.

> Different kinds of communication due to the different node needs.
> 
> DE addapts the existing messages to the ASP needs following the ASP
> philosophy showed in M3UAv9.

I only see one RC in DATA and SNMM.  I see statements that say that
the IPSP is like the ASP an only needs to use a single-ended procedure
for REG and the like.

> All the ASPs have SS7 application running above M3UA and the have RK and
> those RKs have to be registrated in the other end (ASP or SGP).

Registration is an OPTIONAL procedure.

--brian

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

---

---

From: [email-masked]
Date: Mon, 5 Nov 2001 07:47:07 -0800

Hi Javier,

I think you assume that it is not important, from which AS a message is
coming in IPSP case. According to me this is not acceptable because in the
draft IPSP-IPSP communication is described as point-to-point where
endpoints are ASs. Unless this is changed, for every message it should be
clear to which AS it is going and from which AS it has originated. DE
proposes 2RC in DATA where SE gives uniqie RC to every AS pair for this.

       Tolga

> From:   "Javier Pastor-Balbas (ECE)"
> <[email-masked]>
> Sent:   Monday, November 05, 2001 10:25 AM
> To:     "sigtran" <[email-masked]>
> Cc:
> Subject:     RE: IPSP-IPSP summary
>
>  Hi Dennis,
> For DE only the RC of the receiving AS is necessary, as in
> the case of SG->AS communication. Hence you just need to send
> one RC within the DATA message so that you don't need to
> modify the M3UA message either...
> SE also makes automatic registration impossible and go back
> the the client-server philosophy leaving away the
> peer-to-peer. It is not acceptable that one IPSP send the its
> own RK and the peer's RK to the peer IPSP in Registration
> receiving as a response a common RC. You have to preconfigure
> DE handles the registration in the same way as AS-SG. All the
> ASs registrate their RK and get a RC to be sent when sending
> data from the other peer to differenciate the receiving AS
> within one association.
> PEER-TO-PEER
> As I have said peer to peer philosophy is lost in SE unless
> double configuration is done (the same for each peer). This
> makes REG useless
> DE support perfectly Peer2peer since any node can initiate
> communication with minimum configuration. It's also
> compatible with REG procedures.
> RC DEFINITION
> It has also been demonstrated for SE that in the simple
> scenario   ASP1------ASP2-------ASP3, ASP2 can obtain two RC
> from ASP1 and ASP3 that are the same value. In that case
> another characteristic of RC (index of RK table) has been aniquilated.
> In DE as each ASP gives the RC for the peer RK being
> registrated, each ASP can control the unicity of RC and the
> "routing table index" feature.
> SE tries to keep the same messages going through the network:
> one REG, one ASPAC, ... This is not acceptable since you can
> not treat an ASP with an SS7 application over it as a SG that
> only has to relay traffic. Different kinds of communication
> due to the different node needs.
> DE addapts the existing messages to the ASP needs following
> the ASP philosophy showed in M3UAv9. All the ASPs have SS7
> application running above M3UA and the have RK and those RKs
> have to be registrated in the other end (ASP or SGP).
> >
> > IMPACT TO MESSAGE FLOW
> Operation and Management can be almost impossible if you have
> to define the relations between each pair of ASs for all your
> network. This situation is even worse if you mix more than
> one operator...
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > --
> You are currently subscribed to sigtran as: [email-masked]

---

---

From: Dennis Niermann <[email-masked]>
Date: Mon, 05 Nov 2001 09:42:20 -0600

Hi Javier,
Excellent additions.

Of course, I agree with you that the single-ended approach
that uses an RK to define each AS-AS pair is a management nightmare,
in addition to being different from the SG-ASP scenario.
It also implies that each RK MUST include both an OPC and a DPC
since the point codes of the two ASs in the pair are different.

I think that the right choice is very clear - double ended.
Double ended implies the natural routing logic of
 look up your destination (AS) and then determine the optimal path
 (remote IPSP).
Single ended does its initial lookup of a route (AS-AS pair) and this
leads to all the problems being identified.

/Dennis

---

---

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

Hi Tolga, 

I don't assume that. In fact it is important and it is part of the information it is passed to the SS7 user above M3UA. But at the M3UA layer, what you need is to know what AS this message is for. And that is what RC is all about there. If M3UA is interesting in knowing the procedence it can do it by looking at the RL inside the M3UA message. This will only happen when you have more than one remote AS in the other end or your SCTP association.

In this way, with DE, you only send one RC. No more is needed. 

Cheers // Javier.

> From: [email-masked] [mailto:[email-masked]]
> Sent: Monday, November 05, 2001 4:47 PM
> To: sigtran
> Subject: RE: RE: IPSP-IPSP summary
> 
> 
> Hi Javier,
> 

---

---

From: [email-masked]
Date: Mon, 5 Nov 2001 08:15:14 -0800

Hi,

By mistake I sent my message to personal address of JAvier so, the response
was sent just to me. Here it is.....

   Tolga

-----Original Message-----
From:     "Javier Pastor-Balbas (ECE)"
          <[email-masked]>
Sent:     Monday, November 05, 2001 10:55 AM
To:       "[email-masked]'" <[email-masked]>
Cc:
Subject:  RE: RE: IPSP-IPSP summary

 Hi Tolga,
I don't assume that. In fact it is important and it is part of the
information it is passed to the SS7 user above M3UA. But at the M3UA layer,
what you need is to know what AS this message is for. And that is what RC
is all about there. If M3UA is interesting in knowing the procedence it can
do it by looking at the RL inside the M3UA message. This will only happen
when you have more than one remote AS in the other end or your SCTP
association.
In this way, with DE, you only send one RC. No more is needed.
Cheers // Javier.
> Sent: Monday, November 05, 2001 4:46 PM
> To: Javier Pastor-Balbas (ECE)

---

---

From: Javier Pastor-Balbas <[email-masked]>
Date: Mon, 5 Nov 2001 07:17:10 -0800 (PST)

Hi Dennis, 

Very good summary. Only one minor remark and more aspects to assist in
comparation. See below...

Cheers // Javier.

> So yes, only the DE approach implies a change to an 

For DE only the RC of the receiving AS is necessary, as in the case of
SG->AS communication. Hence you just need to send one RC within the
DATA message so that you don't need to modify the M3UA message
either...

REGISTRATION
SE also makes automatic registration impossible and go back the the
client-server philosophy leaving away the peer-to-peer. It is not
acceptable that one IPSP send the its own RK and the peer's RK to the
peer IPSP in Registration receiving as a response a common RC. You have
to preconfigure all the network. And it can be a big network... 

DE handles the registration in the same way as AS-SG. All the ASs
registrate their RK and get a RC to be sent when sending data from the
other peer to differenciate the receiving AS within one association.

PEER-TO-PEER
As I have said peer to peer philosophy is lost in SE unless double
configuration is done (the same for each peer). This makes REG useless

DE support perfectly Peer2peer since any node can initiate
communication with minimum configuration. It's also compatible with REG
procedures.

RC DEFINITION
Meaning of RC is also lost in SE. RC defines one AS and not a
communication between two ASs. 

RC UNICITY IN EACH NODE
It has also been demonstrated for SE that in the simple scenario  
ASP1------ASP2-------ASP3, ASP2 can obtain two RC from ASP1 and ASP3
that are the same value. In that case another characteristic of RC
(index of RK table) has been aniquilated.

In DE as each ASP gives the RC for the peer RK being registrated, each
ASP can control the unicity of RC and the "routing table index"
feature.

KEEPING NODE NEEDS vs KEEPING NUMBER OF MESSAGES IN THE WIRE
SE tries to keep the same messages going through the network: one REG,
one ASPAC, ... This is not acceptable since you can not treat an ASP
with an SS7 application over it as a SG that only has to relay traffic.
Different kinds of communication due to the different node needs.

DE addapts the existing messages to the ASP needs following the ASP
philosophy showed in M3UAv9. All the ASPs have SS7 application running
above M3UA and the have RK and those RKs have to be registrated in the
other end (ASP or SGP).

> but on a network perspective it can be much larger.

Operation and Management can be almost impossible if you have to define
the relations between each pair of ASs for all your network. This
situation is even worse if you mix more than one operator...

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

---

---

From: Dennis Niermann <[email-masked]>
Date: Mon, 05 Nov 2001 10:31:34 -0600

In case there was previous interpretation problems
of which AS was to be identified in registration 
and activation messages for the double ended approach,
let me make my position as clear as possible.

When an IPSP registers a routing key it is one for a 
local AS. This is as it is clearly described in the text
of the M3UA spec for the ASP-SGP case as well.

When an IPSP activates or inactivates an AS, it is for
a local AS that it is serving. Once again, exactly as the 
spec describes.

/Dennis

---

---

From: [email-masked]
Date: Mon, 5 Nov 2001 11:43:43 -0500

Hi Javier,

Please see comments/questions below.

   Tolga

> Sent:   Monday, November 05, 2001 11:32 AM
> I don't assume that. In fact it is important and it is part
> of the information it is passed to the SS7 user above M3UA.
> But at the M3UA layer, what you need is to know what AS this
> message is for. And that is what RC is all about there. If
> M3UA is interesting in knowing the procedence it can do it by
[TOLGA] This is the key point. Is M3UA interested in it or not? If
point-to-point is understood with ASs as endpoints, then I don't see any
other way that M3UA should be interested in. Whether this is some usefull
information or not is another story. In fact if an AS cares about the
originator of a message, then it should put OPC in its route key. So, maybe
coding the originator of the message is not usefull at all, but in such a
case I would  like to see that IPSP communication is not described as
point-to-point in the draft where ASs are endpoints.
> looking at the RL inside the M3UA message. This will only
> happen when you have more than one remote AS in the other end
> or your SCTP association.

---

---

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

> From: Brian F. G. Bidulock [mailto:[email-masked]]
> Sent: Monday, November 05, 2001 4:43 PM
> To: sigtran
> Cc: [email-masked]
> Subject: Re: IPSP-IPSP summary
> 
> 
> Javier,
> 
Give a reference in the draft where is says that for M3UA.

Anyway, the SS7 application over M3UA can do it by looking at the routing parameters that M3UA passes to it. If M3UA and SUA wants also to need it, then you can do the same operation. Not too heavy...

> many changes are required for DE ;)
That's is impossible, since you change the RC meaning. Not acceptable. No change are needed for DE and also, it keeps the same concepts without the need of change.

> DE situation with no means for either side to detect the problem.
They are not misconfigured in DE and also you have the possibility of use REG procedures (as optional). In SE the only option you have is statical configuration using only the client-server philosophy. A step backwards.

> RK (the local RK not the remote).

Don't look at the wire, search for the meaning of the messages. After that, you'll get the reason...
> But it is the wrong RK in Dennis' approach.
Look at the example I sent. 

> These assertions have not be supported by example.
Those assertions are completely true...
> in SE: RC identifies a bidirectional traffic flow.  DE breaks this.

Read the definitions in the draft and tell me where that is stated... 

Routing Context - A value that uniquely identifies a Routing Key.
Routing Context values are either configured using a configuration 
management interface, or by using the routing key management procedures 
defined in this document.

Application Server (AS) - A logical entity serving a specific Routing 
Key. [...] The AS contains a set of 
one or more unique Application Server Processes, of which one or more 
is normally actively processing traffic.  Note that there is a 1:1 
relationship between an AS and a Routing Key.

1.4.2 Routing Contexts and Routing Keys

1.4.2.1 Overview

[...] 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.

[...]

An Application Server Process may be configured to process signalling 
traffic related to more than one Application Server, over a single SCTP 
Association.  In ASP Active and ASP Inactive management messages, the 
signalling traffic to be started or stopped is discriminated by the 
Routing Context parameter.  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.

There are also points as the "index of the RK table" that is not allowed by your model.

> it identify a single AS and half a traffic flow.  That is 
That is how it is used in M3UA. It represents an RK that represents an AS. By the transitive property an AS represents an AS.

> They are not defined per AS in M3UAv09.  Your assertion is incorrect.
Look my response above and you'll deduce it.

> viewed as an index into the RK table.  This was never the case at
This is always the case of a node communicating with an ASP. Whatever SGP or ASP.

> registrated, each ASP
You always have addressing information implicit in the message if want to do it.

> it is no longer necessary to have twice as many messags: a 
Changing meaning of things is not a good approach.

> Relay is precluded in M3UAv09: point-to-point is all that is 
You can think of SG as relying MTP3 message between two different domains (IP and SS7)

> the IPSP is like the ASP an only needs to use a single-ended procedure
I also see one RC in DATA.

SE cannot use REG procedures. They are useless.

> Registration is an OPTIONAL procedure.

Yes, but you have to support it.

Cheers // Javier.

> > Operation and Management can be almost impossible if you 
> have to define the relations between each pair of ASs for all 
> your network. This situation is even worse if you mix more 
> than one operator...
> > 
> > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > >  
> > > 
> > > 
> > >  
> > > 
> > >  
> > > 
> > > 
> > > 
> > > -- 

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 5 Nov 2001 10:50:22 -0600

tolga.asveren,

[email-masked] wrote:                        (Mon, 05 Nov 2001 08:15:14)
> do it by looking at the RL inside the M3UA message.

SUA cannot do this (no source data in CODT message).  M3UA ASPs/IPSPs
cannot be compelled to do this.  This was the reason for putting RC
in the DATA message in the first place for heaven's sake.

> This will only happen

Doesn't work for SUA or M3UA.

--brian

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

---

---

From: "Javier Pastor-Balbas (ECE)" <[email-masked]>
Date: Mon, 5 Nov 2001 17:54:06 +0100

Hi Brian, 

see below....

(snip)
> Already described in example.

(snip)

In your example I only see Routing tables but you don't explain the procedure. Could you please assist me in understanding your way of thinking a little bit more? Thanks.

I would also like to know how you solve the RC unicity in the example:

ASP1------ASP2-------ASP3, ASP2 can obtain two RC from ASP1 and ASP3 that are the same value. In that case another characteristic of RC (index of RK table) has been aniquilated.

Cheers / Javier.

---

---

From: Dennis Niermann <[email-masked]>
Date: Mon, 05 Nov 2001 11:05:00 -0600

Brian,
What I said was not applicable to your example was the use of 
the "pseudo AS".

I was covering the real world case of an IPSP that needs
to communicate with both other IPSPs and with SS7 destinations
via a SG. The "pseudo AS" was one possible approach to 
merging the two possibilities into a single lookup 
algorithm.  It was there to represent a real SS7 destination.
The other possiblity is to not introduce
a "pseudo AS" and just to two lookup cases in sequence -
first is it a AS at an IPSP and then is it a SS7 destination
accessible via a SGP.

At least these are two options available with double ended 
approach.

Does the single ended approach allow an IPSP to interact 
with both SGs and with other IPSPs?

/Dennis

---

---

From: Dennis Niermann <[email-masked]>
Date: Mon, 05 Nov 2001 11:35:24 -0600

Hi Brian,
I have already tried to explain this.
What was invalid is that you said that there were two RKs
        RK3  (OPC=PC1,DPC=PC3,SI=SI5)
        RK4  (OPC=PC2,DPC=PC3,SI=SI5)
but the network picture showed only one AS (AS3).

You have to start with the question -
Do I want one AS to service all the ISUP traffic with DPC of PC3?
Or, do I want a separate AS for each possible OPC?

If you answer "yes" to the first question then the network picture was 
correct, but your RK table was incorrect (there should be only
RK3 (DPC=PC3, SI=SI5).

If you answer "yes" to the second question then your RKs were correct,
but your network picture was not (it should show a second AS).

You tried to show a network picture unmatched to your RK data and
then claim that it demonstrated a problem with the DE approach.

/dennis

"Brian F. G. Bidulock" wrote:
> 
> Dennis,
> 
> On Mon, 05 Nov 2001, Dennis Niermann wrote:
> 
> > Brian,
> So please demonstrate the approach for the simple example
> which you evaded as saying that the RK definitions were
> somehow "invalid" yet they are provided for in the draft
> and the case is a real-world ISUP example.
> 
> >
> The draft excludes transfer/relay functions combined with IPSP
> (point-to-point only).  We pretty much agreed that trasfer/relay
> function combined with IPSP would be left to an extension draft
> as it is not a necessary component for IPSP operation.
> 
> --brian
> 
> >
> > /Dennis
> >
> > > > > > > > To unsubscribe send a blank email to [email-masked]
> > > > > > >
> > > > > > > --
> > > > > > > Brian F. G. Bidulock
> > > > > > > [email-masked]
> > > > > > > http://www.openss7.org/
> > > > > >
> > > > > > --
> > > > > > To unsubscribe send a blank email to [email-masked]
> > > > >
> > > > > --
> > > > > Brian F. G. Bidulock
> > > > > [email-masked]
> > > > > http://www.openss7.org/
> > > > >
> > > > > ---
> > > > > To unsubscribe send a blank email to [email-masked]
> > > >
> > > > --
> > > > To unsubscribe send a blank email to [email-masked]
> > >
> > > --
> > > Brian F. G. Bidulock
> > > [email-masked]
> > > http://www.openss7.org/
> >
> > --
> Brian F. G. Bidulock    ¦ The reasonable man adapts himself to the ¦
> [email-masked]    ¦ world; the unreasonable one persists in  ¦
> http://www.openss7.org/ ¦ trying  to adapt the  world  to himself. ¦
>                         ¦ Therefore  all  progress  depends on the ¦
>                         ¦ unreasonable man. -- George Bernard Shaw ¦

---

---

From: Javier Pastor-Balbas <[email-masked]>
Date: Mon, 5 Nov 2001 10:11:56 -0800 (PST)

Brian, 

Handle CO messages like when they reach the SG and have to be sent to
an ASP in the AS-SG model.

Just follow the model it is already explain. Don't need to invent
things.

It perfectly works.

Cheers // Javier.

--- "Brian F. G. Bidulock" <[email-masked]> wrote:
> > > I think you assume that it is not important, from which AS 

---

---

From: "Javier Pastor-Balbas (ECE)" <[email-masked]>
Date: Mon, 5 Nov 2001 19:21:23 +0100

> Sent: Monday, November 05, 2001 5:44 PM
> To: sigtran
> Subject: RE: RE: RE: IPSP-IPSP summary
> 
> 
> Hi Javier,
> 
> [TOLGA] This is the key point. Is M3UA interested in it or not? 

Not at all. If specific implementations want to do it for any purpose they can look at the originating address in the message.

> If point-to-point is understood with ASs as endpoints, then I 
> don't see any
> coding the originator of the message is not usefull at all, 

Right.

> but in such a

Sorry I don't get your point here....  :-)

Cheers // Javier.

> [email-masked]

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 5 Nov 2001 12:28:11 -0600

Dennis,

The current AS/SG model does not stop my from registering
two RKs for the same AS.  Why the restriction with DE?

--brian

Dennis Niermann wrote:                                     (Mon, 05 Nov 2001 11:35:24)
> To unsubscribe send a blank email to [email-masked]

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

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 5 Nov 2001 12:25:59 -0600

Dennis,

--brian

---

---

From: [email-masked]
Date: Mon, 5 Nov 2001 11:01:10 -0800

Brian,

Does SE approach require both local and RKs to be defined on a IPSP or not?
It seems to me yes, what is your view? And also below I again put how I see
your example from DE point of view.

   Tolga

PC1,SI5
    _____
   /     \
  |  AS1  |
   \_____/\                                  PC3,SI5
           \  _______           _______       _____
            \|       |  assoc  |       |     /     \
             | IPSP1 |---------| ISPS2 |----|  AS3  |
            /|_______|         |_______|     \_____/
    _____  /
   /     \/
  |  AS2  |
   \_____/
   PC2, SI5
[TOLGA] As also pointed out by Dennis, I don't agree with your RK table on
IPSP2 (assuming that they are RKs for outgoing traffic, i.e. remote RKs). I
think the solution is to keep local and remote RKs separetly.
Now on both nodes local and remote RKs :
local on IPSP1:
RK1 (DPC=PC1, SI=5)     RC1
RK2 (DPC=PC2, SI=5)     RC2
remote on IPSP1:
RK3 (DPC=PC3, SI=5)      RC3
local on IPSP2:
RK4 (DPC=PC3, SI=5)       RC3
remote on IPSP1:
RK5 (DPC=PC1, SI=5)       RC1
RK6 (DPC=PC2, SI=5)       RC2
If we want to make known the two endpoints of DATA in it, then in DE one
should put two RC values, taken from the tables above. And if we really
want
to code those two endpoints in DATA, is there any other way then knowing
both local and remote RKs on IPSPs. The local RC value can be obtained
implicitly based on the interface between AS and IPSP but how can we fill
the remote RC (or in SE case, will AS have different interfaces per
destination AS? if not again we have the same problem)? We have to know the
remote RKs, so we can analyze them and fill the corresponding RC value.

> From:   "Brian F. G. Bidulock" <[email-masked]>
> Sent:   Monday, November 05, 2001 1:53 PM
> [email-masked]
> [email-masked]
> [email-masked]

¦ The reasonable man adapts himself to the ¦

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 5 Nov 2001 13:04:11 -0600

Javier,

The ASP cannot identify the source AS from the CODT message contents
if the RC only provides the sent to AS.  Plain and simple your approach
does not work without two RCs in the messages.

--brian

Javier Pastor-Balbas wrote:                                (Mon, 05 Nov 2001 10:11:56)

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

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 5 Nov 2001 13:06:15 -0600

Javier,

Javier Pastor-Balbas (ECE) wrote:                          (Mon, 05 Nov 2001 19:21:23)
> Not at all. If specific implementations want to do it for any purpose they
> can look at the originating address in the message.

There is no originating address information in SUA CODT messages.

The purpose is ASPTM.  If a receiver ignores whether an AS is active
or not when it processes messages, there is no need for ASPAC/ASPIA
messages.

> > coding the originator of the message is not usefull at all, 

You believe that ASPAC/ASPIA is not useful at all either then.  Luckily
the draft does not agree with you.

--brian

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

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 5 Nov 2001 14:10:19 -0600

tolga.asveren,

[email-masked] wrote:                        (Mon, 05 Nov 2001 11:01:10)
> your example from DE point of view.

There is no requirement to maintain "local" RKs at all.

> Now on both nodes local and remote RKs :

You have changed the example.  The example had OPC in the routing key
as is normally the case for ISUP (SI=5).  I only see a need for the
following routing table:

  IPSP1:

       RK1 (OPC=PC1, DPC=PC3, SI=5)  RC1
       RK2 (OPC=PC2, DPC=PC3, SI=5)  RC2

  IPSP2:

       RK1 (OPC=PC3, DPC=PC1, SI=5)  RC1
       RK2 (OPC=PC3, DPC=PC2, SI=5)  RC2

> should put two RC values, taken from the tables above. And if we really want
> both local and remote RKs on IPSPs.

No there isn't another way.  This is why I hate DE.  Somehow the ASP
must know to couple these to RKs and these two RC values.  And, somehow
it must be able to discern when they are wrong, mismatched, half-activated.
SE has single labelling and no mismatch or half-activation can occur.

> The local RC value can be obtained implicitly based on the interface between
> AS and IPSP but how can we fill the remote RC (or in SE case, will AS have
> different interfaces per destination AS?

For the SE case, the RC value for local and remote RKs are the same.  (See
table above).  The ASP whose AS communicates with multiple remote AS, just
as in the multiple SG case (and DE), must apply the remote RK to determine
RC.  The main difference is that there is one RC value, not two.

> if not again we have the same problem)? We have to know the

The solution to all of this is to not to expose multiple AS across
the network for IPSP operation at all.  It is not needed.  Then no
RCs are required.  There is certainly no need for double ASPAC where
there are no RC values whatsoever.

This likens an IPSP more to an SG (albeit one without the transfer
function).

Then the example deteriortes to:

    IPSP2:
	RK1 (*, *, *)	IPSP2

    IPSP1:
	RK1 (*, *, *)	IPSP1

No RCs are required, ASPSM/TM is used for redundacny over multiple
ISPs (if you will) in the same IPSP only.  SNMM rules the day as
it must in an IPSP point-to-point configuration anyway.

Splitting IPSPs into AS at all is what causes problems.  If there
are AS (SS7-Users) let them be completely local to the IPSP.

We had pretty much agreed to this in our NA/RC discussion.  John S.
made the fair point that sub-PC RKs were not useful in IPSP.  With
point-to-point configuration an no sub-PC RKs, RKs reduce to the
MTP routing table (PC destination status) which must be maintained
by an IPSP anyways.  sub-PC RKs are only useful in the backhaul
case, because MTP/SCCP-Users are sub-PC entities.  IPSPs should
never be sub-PC entities.

The usefulness of the RC/AS concept is limited to the backhaul
case.  Registration is also pretty useless.

In effect, DE requires 2 RCs where 0 will do and requires twice
the ASPTM/SM messages.  There is no need for it.

--brian

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

---

---

From: Dennis Niermann <[email-masked]>
Date: Mon, 05 Nov 2001 15:46:41 -0600

Brian,
I can not believe that you are making the statement
that the current AS/SG model does not stop you from
registering two RKs for the same AS.
Where should I start?
How about the definition of an AS. From 1.2 Terminology,
first sentence:
"AS - A logical entity serving a specific Routing Key."
last sentence:
"Note there is a 1:1 relationship between an AS and a Routing Key."
I could continue with the rest of the spec, but I think that
should suffice.

Previously you tried to say that this 1:1 relationship between
an AS and a RK only held per association. 
Now you say it does not hold at all! Amazing!!!!!!

This just illustrates the complete incompatibility of the SE 
model with the AS/SG case.

/dennis

"Brian F. G. Bidulock" wrote:
> To unsubscribe send a blank email to [email-masked]

---

---

From: [email-masked]
Date: Mon, 5 Nov 2001 14:03:35 -0800

> > > http://www.openss7.org/ 

¦ trying  to adapt the  world  to
> himself. ¦

---

---

From: [email-masked]
Date: Mon, 5 Nov 2001 14:17:55 -0800

> persists in  

¦

---

---

From: Tolga Asveren <[email-masked]>
Date: Mon, 5 Nov 2001 14:20:44 -0800 (PST)

Hi Brian,

Please see comments/question below.

(This is my 3rd attempt , and somehoe mail server
chops down my mails :-( )

> Sent:	Monday, November 05, 2001 3:17 PM
> [email-masked] wrote:                       
(Mon, 05 
> Nov 2001 11:01:10)
> > Brian,
> >
> > Does SE approach require both local and RKs to be
defined 
> on a IPSP or not?
> > It seems to me yes, what is your view? And also
below I 
> again put how I see
> >    \_____/\                                 
PC3,SI5
> >            \  _______           _______      
_____
> >             \|       |  assoc  |       |     /    
\
> > [TOLGA] As also pointed out by Dennis, I don't
agree with 
> your RK table on
> > IPSP2 (assuming that they are RKs for outgoing
traffic, 
> i.e. remote RKs). I
[TOLGA] I just gave RKs according to the figure. If
OPC is going to be part of RKs, then there should be
different ASs per OPC, so AS4 on IPSP2.
> > If we want to make known the two endpoints of DATA
in it, 
> then in DE one
> > should put two RC values, taken from the tables
above. And 
> if we really want
> > to code those two endpoints in DATA, is there any
other way 
> then knowing
> must know to couple these to RKs and these two RC
values.  
> And, somehow
> it must be able to discern when they are wrong,
mismatched, 
> half-activated.
> > The local RC value can be obtained implicitly
based on the 
> interface between
> > AS and IPSP but how can we fill the remote RC (or
in SE 
> case, will AS have
> For the SE case, the RC value for local and remote
RKs are 
> the same.  (See
> table above).  The ASP whose AS communicates with
multiple 
> remote AS, just
[TOLGA] It is clear that SE uses one RC value for an
AS pair. But the question is how to fill it ? Based on
the interface a message is coming from AS to IPSP one
can decide for local AS but one should also figure out
the remote AS to find the corresponding RC value to
that AS pair. How can this be found in SE case without
defining RKs both local and remote on an IPSP?
> as in the multiple SG case (and DE), must apply the
remote RK 
> to determine
[TOLGA] If IPSP is to be limited to PC granularity,
why not use M2UA instead of it?

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Sun, 4 Nov 2001 17:44:28 -0600

Dennis,

--brian

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

---

---

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

Brian,

CODT send the Destination Local Reference Number. From that you can get the Connection Section and from that a relationship of the two ASs that are involve in the communication. You don't need more...

Cheers // Javier.

> Sent: Monday, November 05, 2001 8:04 PM
> To: sigtran
> Subject: Re: FW: RE: RE: IPSP-IPSP summary
> 
> 
> Javier,
> 
> > > [email-masked] wrote:                        (Mon, 
> 05 Nov 2001
> > > 08:15:14)
> > > > Hi,
> > > > 
> > > > By mistake I sent my message to personal address of 
> JAvier so, the
> > > response
> > > > what you need is to know what AS this message is for. 
> And that is
> > > what RC
> [email-masked]

---

---

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

Javier,

Please answer this question:

How does the receiving ASP know from which AS the CODT message
originated so that it can perform ASPTM?

--brian

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

---

---

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

Javier,

There is no connection section when the connection is decoupled.
As SUA cannot support SUA relay function yet, coupling is not
possible and point-to-point operation applies.  The receiving ASP
is not aware of the connection, only the AS is aware of the
connection.

Again: How from the message does the receiving ASP know from
which AS the message has originated?

--brian

Javier Pastor-Balbas (ECE) wrote:                          (Tue, 06 Nov 2001 09:47:32)
> Brian,
> 
> CODT send the Destination Local Reference Number. From that you can get the
> Connection Section and from that a relationship of the two ASs that are
> involve in the communication. You don't need more...
> 
> Cheers // Javier.
> 

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

---

---

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

Hi all,

Perhaps we must take better care of defining our RKs, in either direction.
For the case below, IPSP1 is expecting traffic with OPC=PC3 for either
DPC=PC1 or PC2; IPSP2 is expecting traffic from either OPC=PC1 or PC2 and
DPC=PC3. Give or take the SI value.

Now what (should) happen(s) ?

1) IPSP1 registering/activation :

REG (OPC=PC3, DPC=PC1, SI=x) for AS1; IPSP2 accepts and assigns RCa
REG (OPC=PC3, DPC=PC2, SI=x) for AS2; IPSP2 accepts and assigns RCb

In my view, this only tells IPSP2 it can send messages matching the AS1/2
criteria to IPSP1 (depending on traffic mode and other available IPSPs which
have registered with the same RK parameters to IPSP2). IPSP1 at the moment
doesn't have any destination available yet, and shouldn't assume IPSP2 is
game for any "reverse" RK. With reverse RKs the implicit assumption is made
that we'd always know what RK parameters to reverse and that these are
always present ...

IPSP2 is free to assign the same RCa or RCb to other IPSPs registering with
the same REG RK parameters (defining the same logical AS). The RC values
only need be unique per SCTP association, though.

2) IPSP2 registering/activation :

REG (OPC=PC1, DPC=PC3, SI=x) for AS3; IPSP1 accepts and assigns RCp
REG (OPC=PC2, DPC=PC3, SI=x) for AS4; IPSP1 accepts and assigns RCq

Now in direction IPSP2 -> IPSP1, only traffic with RC = either RCa or b are
used (for M3UA, this could be clear from the RL, but let's use the RC
approach consistently throughout; via SI "subPC" RKs are possible as for the
SUA).

And in direction IPSP1 -> IPSP2, only traffic with RC = either RCp or q is
flowing.

===> So IMHO :
- Register/activate only defines a "source-drain" relationship
point-to-point, the one who activates = drain. The IPSP makes an
advertisement, which is unidirectional by definition.
- RCa/b could be the same as RCp/q, it doesn't matter : what AS is meant is
clear from the direction of the message. But only a single RC value is
needed in any message in either direction.
- in ASP/SG case, it is assumed implicitly that SG is a drain for any
traffic destined for the SS7 network. Implicitly, the SGs have "advertised"
these capabilities to any ASP in the field.

Further, in the example below when IPSP2 isn't interested in the "source" of
the message (for whatever reason), it can make things easy and only register
REG (DPC=PC3, SI=x) to IPSP1. Then IPSP1 knows it is a (possible)
destination for any message with matching criteria DPC/SI.

Regards,

____________________________

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

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: maandag 5 november 2001 20:01
To: sigtran
Subject: RE: Re: IPSP-IPSP summary

Brian,

   Tolga

PC1,SI5
    _____
   /     \
  |  AS1  |
   \_____/\                                  PC3,SI5
           \  _______           _______       _____
            \|       |  assoc  |       |     /     \

---

---

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

Brian, 

Answer below.

> Sent: Tuesday, November 06, 2001 10:06 AM
> To: sigtran

With the help of the Local Destination Reference sent in CODT => Connection Section => Peer AS

Cheers // Javier.

---

---

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

Javier,

Javier Pastor-Balbas (ECE) wrote:                          (Tue, 06 Nov 2001 11:32:13)
> With the help of the Local Destination Reference sent in CODT => Connection

The ASP is unaware of the connection section.  How then?

--brian

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

---

---

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

Hi Gery, 

Thanks for participating in the thread. Comments below...

> From: Verwimp Gery [mailto:[email-masked]]
> Sent: Tuesday, November 06, 2001 11:00 AM
> To: sigtran

Yes. Each AS has to register and activate its own RK/RC.

> needed in any message in either direction.

At the ASP (as in the SGP) we should have the unicity in the relation RK/RC/AS 1:1:1 when talking about the remote AS (routing tables).

> these capabilities to any ASP in the field.

Right. I agree.

Cheers // Javier.

---

---

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

resending.....

Hi Brian,

(Mon, 05 
defined 
below I 
PC3,SI5
_____
\
agree with 
traffic, 
in it, 
above. And 
other way 
values.  
mismatched, 
based on the 
in SE 
RKs are 
multiple 
that AS pair. How can thi sbe found in SE case without
remote RK 
[TOLGA] If IPSP is to be limited to PC granularity,
why not use M2UA/M2PA instead of it?

---

---

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

Tolga,

Bottom line is the IPSP does not need to know about
remote AS.  Only local AS.  The remote IPSP is
responsible for collecting the availability of its
local users in to a management view toward other
IPSPs.  This can be accomplished with current SNMM
procedures and there is no need for RC to be exchanged
between IPSP.

A single ASPAC/IA (without RC) is all that is required
to activate the associations between IPSP clusters and
provide for traffic distribution and management within
the cluster.

Make sense?

--brian

Tolga Asveren wrote:                                        (Tue, 06 Nov 2001 05:51:15)

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

---

---

From: Tolga Asveren <[email-masked]>
Date: Tue, 6 Nov 2001 06:18:42 -0800 (PST)

Hi Gery,

Everything seems fine with what you have described.
But it does not allow the receiving IPSP to audit the
sender AS. If we want to receive traffic only from
active ASs, how can we achieve this then? It seems to
me that not having a reference for the sender would
also break the point-to-point approach if one sees ASs
as endpoints. Because in a point-to-point
communication receiver always knows who has sent the
message. There was a debate whether the sender AS can
be figured out from analyzing a message at the
receiving IPSP or not ( I thinkg it shouldn't be
possible for specific cases just basing my opinion on
former discussions on this topic where it was agreed
that for traffic coming from an ASP to SGP, it might
be not possible to find out the RK for some types of
RKs)
But maybe we can get rid of the idea of using IPSPs in
a point-to-point fashion with ASs as endpoints (or
maybe my interpretation is wrong)

    Tolga
--- Verwimp Gery <[email-masked]> wrote:
> defined on a IPSP or not?
> below I again put how I see
> traffic, i.e. remote RKs). I
> in it, then in DE one
> above. And if we really
> other way then knowing
> [email-masked]

---

---

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

Hi Tolga,

The receiving IPSP has built up it's view of the "remote" ASes by receiving
REGs and ASPACs for the corresponding RK/RC (RK parameters are identical per
AS, RC is assigned by the receiving IPSP as table index for this "remote"
AS/RK). As long as one such IPSP is up and active, the AS is up and active
etc.

And if we receive traffic from any IPSP, sorry, but first the receiving IPSP
itself has to have sent ASPAC for this RC first (or ASPAC without RC to
activate all at once for all I care) to the IPSP it is receiving from (and
this guy has acknowledged). This has little to do with the overall active
state of any AS. What's there to check about traffic the ASP/IPSP is
supposed to receive anyway ? It *is* part of it's "local" AS, so as long as
it's active, the AS is active ... it doesn't need to know the state of any
fellow IPSP that is prepared to handle the same traffic either.

Regards,

Gery Verwimp
Fax : +32 14 25 3212

-----Original Message-----
From: Tolga Asveren [mailto:[email-masked]]
Sent: dinsdag 6 november 2001 15:19
To: sigtran
Subject: RE: Re: IPSP-IPSP summary

Hi Gery,

    Tolga

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

---

---

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

Brian,

Hello, are we still speaking the same language here ?

The IPSP knows by definition, because

a) it has to know which IPSPs are eligable to receive said message (and thus
comprise the "remote" AS), where else to send it to ? "Default ASP" ??
b) which IPSP is the dominant one (override) here, or which IPSPs are
available for loadsharing/broadcast.

The "local" AS is trivial : as long as the IPSP itself is active, the AS is
active (because it is part of it, duh). If the IPSP is not active (and it
should know this about himself, doesn't it) it couldn't care less about the
overall AS state, until it is NOTIFYed of "insufficient resources" in case
of loadsharing mode or "AS pending" when it should take over from the
previously dominant IPSP for whatever reason.

Make sense ?

Gery Verwimp
Fax : +32 14 25 3212

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

Tolga,

Make sense?

--brian

Tolga Asveren wrote:                                        (Tue, 06 Nov
2001 05:51:15)

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

---

---

---

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

Gery,

Verwimp Gery wrote:   (Tue, 06 Nov 2001 16:19:13)
> The IPSP knows by definition, because

Knows what?

> comprise the "remote" AS), where else to send it to ? "Default ASP" ??

IPSP only needs to know for a message with DPC=3 that DPC=3 is
at the other end of an association in point-to-point configuration.

> available for loadsharing/broadcast.

It only needs to know IPSPs in the cluster to do this.  With an implicit
AS (one big one) all IPSPs that represent the same SPMC are part of the
loadsharing/override/broadcast.

> active (because it is part of it, duh).

The AS is an MTP-User/SCCP-User.  An MTP-User can be available indepedent
of the availability of the signalling point that provides it service.
This is essential to the MTP/MTP-User interface.  An MTP-User (AS) is
only known to MTP (IPSP) by the activity of its MTP/MTP-User interface.
Therefore, the AS can be inactive while the IPSP is active.  An MTP-User
can be unavailable while an MTP is available.

> If the IPSP is not active (and it should know this about himself, doesn't
> it) it couldn't care less about the overall AS state, until it is NOTIFYed
> of "insufficient resources" in case of loadsharing mode or "AS pending" when
> it should take over from the previously dominant IPSP for whatever reason.

Was it your intention to never use SNMM in the IPSP case?  If you intend
to use SNMM, what is the IPSP's basis for formulating a view of the
availability of a destination (point code)?  The availability of a user
part?

--brian

> Fax: +32 14 25 3212

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

---

---

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

Brian,

Look down ...

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

Gery,

Knows what?

[GV] : remote AS status.

[GV] : more than 1 IPSP may be registered for traffic to DPC=3. They belong
to the "AS, RK:DPC=3" or call it your SPMC cluster if you like.

[GV] : So ? The IPSP knows the AS or SPMC cluster state, doesn't it ?

[GV] : Your argument being ? If SCTP is down, there's no association. If the
IPSP wants to go out of service, it sends ASPDN. If the IPSP wants to
withdraw from a certain AS, either local to stop receiving traffic, or
remote to stop sending traffic, it sends ASPIA (RC). Where's the point code
in an ASPIA message ?

[GV] : ok, brace yourselves : the SNMM isn't needed in a point-to-point case
with all the ASP management stuff we already have. Where it would come in
handy is in transfer/relay IPSPs, broadcasting it to a concerned community
of IPSPs. And even with the use of the appropriate RCs !!

--gery

---

---

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

Gery,

Verwimp Gery wrote:                                       (Tue, 06 Nov 2001 17:27:40)
> [GV]: remote AS status.
> [GV]: more than 1 IPSP may be registered for traffic to DPC=3. They belong
> [GV]: So ? The IPSP knows the AS or SPMC cluster state, doesn't it ?
> 
> [GV]: Your argument being ? If SCTP is down, there's no association. If the

Don't need RC and don't need ASPAC/IA.  ASPUP/DN and SNMM will do.

> [GV]: ok, brace yourselves : the SNMM isn't needed in a point-to-point case

The MTP-User and SCCP-User expect the equivalents of SNMM indicated
across the user interface.  There is not an ASPTM equivalent for every
SNMM message (e.g., SCON, DRST)  and ASPTM cannot communicate status
(unequipped, inaccessible).  ASPTM can also not perform restart procedures
and does not allow audits (DAUD).

ASPTM is insufficient.  SNMM is both necessary and sufficient.

--brian

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

---