Subject: Re: Consensus Call - Routing Key

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

Dennis,

Dennis Niermann wrote:                                     (Tue, 06 Nov 2001 17:54:23)
> Hi Brian,
> Thanks for your answer, see below...
> 
> "Brian F. G. Bidulock" wrote:
> > 
> > Dennis,
> > 
> > In the AS/SG case the AS and SGP are concerned about both
> > directions of traffic.  The RK is used to forward route
> > the traffic from the SGP to the AS, but there is not always
> > a "reverse RK" so the RC is implicitly associated with
> > the AS at the ASP and used to identify traffic in the reverse
> > direction.
> OK. I think that this RK defintion is consistent with the 
> definiton #1 that I defined, so I agree.
> For the RC, I may have worded it slightly differently to 
> say that for traffic sent to the ASP, the RC identifies the AS
> that the DATA message is being sent to and for
> traffic from the ASP the RC identifies the AS sending the 
> DATA message. Based on your next paragraph, I think that
> you would agree.
> 
> > 
> > In this situation, RK separates traffic at the SGP
> > and allows it to be assigned an RC value in the SGP to AS
> > direction.  In the AS to SGP direction, the RC is implicitly
> > associated with the AS (but could be a different "value"
> > depending on the outgoing association) and used to identify
> > for the SGP the traffic in the AS to SGP direction by
> > assigning it the same RC value that the SGP would assign
> > for the SGP to ASP direction for the same AS.
> > 
> > So, RK identifies traffic in one direction, but the RC
> > value identifies traffic in both directions.  Understand?
> I think so. This may seem trivial, but becomes more 
> significant when talking IPSP-IPSP later. So long as by 
> "both directons" we mean "to the AS" and "from the AS",
> i.e. in both cases identifying the AS.
> 
> > 
> > There is no reason why this must change at the AS.  The
> > AS always knows implicity that traffic it sends belongs
> > to it.  The ASP labels the traffic the AS sends with the
> > RC that the SGP would use when sending traffic towards
> > the AS for the same association.
> OK.
> 
> > 
> > This is no different for a (OPC=*,DCP=x) RK than any other.
> > When an AS (PC=x) sends data it uses the RC values that
> > the SGP would use for sending data from anywhere to the
> > AS.  This ensure that RKs that have no reverse (e.g., SUA
> > CODT) can yeild an RC value that indicates the traffic
> > in both directions.
> > 
> > At the SGP, applying a "reverse RK" to incoming data to
> > determine the AS source was unacceptable because such
> > "reverse RK" does not always exist.  The AS can always
> > implicity label with RC in this way.
> OK. A key point is that you say that at the SGP the RC is 
> identifying the AS source. I agree.
> 
> > 
> > For the IPSP case, there is no need to expose the AS
> > concept to the remote as the AS is a local concept only
> > the the IPSP node.  The status of user parts and point
> > codes must be communicated to the IPSP peer using SNMM
> > when an association is available, and no distinction
> > of anything at the sub-PC level is necessary with ASPTM.
> Seven paragraphs so far and this is my first disagreement 
> with you. I think that we are making some real progress here! :)
> If a sub-PC level AS at the IPSP is never required, then you 
> are correct that SNMM would suffice. But, I believe that 
> there is no reason to make that limitation. 
> 
> As for as being a requirement... I think that if sub-PC level
> AS's are useful in the case of communicating with 
> real SS7 destinations, then they are equally useful when 
> communicating with other M3UA-based AS's. 
>  
> As for as being workable... I think that sub-PC level AS's
> are equally workable for the IPSP-IPSP case as they are for
> the SGP-ASP case. I believe that previous concerns that you
> have expressed are just as relevant for the SGP-ASP case. 

See my response to Amish.  The criss-crossed case (A) which
is the IPSP-IPSP case that you are trying to say is workable
bears little similarity to the AS/SG case.  In the AS/SG
case, the SGP is only responsible for tracking the state of
AS (Users) that are local to it.  Your IPSP approach requires
that the IPSP (SGP function at the IPSP) track the AS state
of all remote AS.  That is what makes it unworkable.

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

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

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

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

See also my response to Amish on this thread.

--brian

> 
>  
> 
> 
> > 
> > --brian
> > 
> > Dennis Niermann wrote:                                     (Tue, 06 Nov 2001 13:20:53)
> > > Brian,
> > > Respectfully, this is another non-answer since it
> > > does not distinguish between the key difference
> > > articulated in definitions #1 and #2 below.
> > > I unequivically subscribe to definition #1 below.
> > > Previously, you have advocated definition #2.
> > > Is that still true?
> > >
> > > If it is still true then I don't see a consensus
> > > happening.
> > > If you no longer strongly feel that a single RK
> > > should represent routing for both directions
> > > then a consensus should be possible.
> > >
> > > /Dennis
> > >
> > >
> > > "Brian F. G. Bidulock" wrote:
> > > >
> > > > Dennis,
> > > >
> > > > Dennis Niermann wrote:                                     (Tue, 06 Nov 2001 11:16:30)
> > > > > Brian,
> > > > > I see no answer to the original question.
> > > > >
> > > > >    1) Does a routing key define traffic for an AS?
> > > > >
> > > > >    2) Or, does a routing key define two-way traffic
> > > > >       between a pair network entities, i.e. a route?
> > > > >
> > > > > If neither of these matches what you think a routing
> > > > > key is, then please explain your definition.
> > > >
> > > > An RK is a pattern that can be matched against messages
> > > > to separate traffic.  What did you think it was?
> > > >
> > > > --brian
> > > >
> > >
> > > [SNIP]
> > >
> > >
> > > ---
> > > You are currently subscribed to sigtran as: [email-masked]
> > > 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]
> 
> -- 
> ---------------------------------------------------------------
>  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]

-- 
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: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 7 Nov 2001 02:31:01 -0600

Dennis,

I should point out several things about RK that were agreed
for the AS/SG that are not applicable for IPSP.

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

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

Because each IPSP needs to maintain RKs and perform NA/variant
specific analysis, the IPSP might as well perform this on
*incoming* messages instead of *outgoing* messages.  When this
is performed, no RC needs to be placed in the DATA messages.
The local AS at the IPSP is determined for incoming messages
by performing RK analysis on the incoming data messages using
local knowledge of AS configuration.  In this way, the IPSP
does not need to maintain or register RC values and RC values
never need to be communicated, registered or configured
between IPSPs.

On received messages, the IPSP performs internal analysis on
the contents of messages to determine the SS7-User (AS) to
which to propagate the message.  Outgoing messages from the
IPSP are routed using normal SS7 routing tables and techniques
(based on the availability of associations to other IPSPs and
the receipt of SNMM messages) and need not be labelled with
RC.

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

I hope this clears up RKs and RCs for you.

--brian

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

---