Subject: Re: [Fwd: Re: IPSP proposed text (1st approach)]]

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 2 Nov 2001 19:59:57 -0600

Dennis,

Please see comments below...

Dennis Niermann wrote:                                     (Fri, 02 Nov 2001 18:19:45)
> Brian, 
> More comments..
> 
> 
> "Brian F. G. Bidulock" wrote:
> > 
> > Dennis,
> > 
> > Dennis Niermann wrote:  (Fri, 02 Nov 2001 14:56:23)
> > > Hi Tolga,
> > > Here are my reasons for disagreeing with your conclusion that it
> > > is better to define the RC as representing a pair of AS's.
> > >
> > > 1. It makes the definition of AS semantically different for the
> > > IPSP-IPSP case (a pair of AS's) versus the ASP-SGP case (where the
> > > RC must still represent a single AS because the AS is not paired
> > > up with another).
> > 
> > The definition of AS does not change.  An RC is used to identify a
> > forward routing key describing traffic towards an AS.  This does not
> > change.  At the originator, the RC is still obtained by applying the
> > forward RK to the message and obtaining the RC of the AS to which
> > is is being routed.  The ASP performs this function in the same way
> > as the SGP routes ougoing message.  There is no change.
> I made a mistake in my text. I meant to say that it makes the definition
> of RC different (not AS). I agree with you completely about the 
> logic.
> 
> > 
> > > 2. It changes the semantics of the ASPAC request from its current
> > > meaning of "to tell a remote M3UA that this ASP is ready to
> > > process signalling traffic for a particular AS" to something else
> > > that I am not even sure makes any sense.
> > 
> > This is why the RC must represent the incoming AS as well so that
> > the receiver of the message can verify that the sending AS is
> > ACTIVE.  This does not change from the AS/SG case where the SGP
> > makes the same determination based on a single RC value. There is
> > no change.
> The change is in the meaning of the RC. From identifying the only
> sender's AS in the AS/SG case to identifying two AS's in your way
> for IPSP-IPSP.

RC is more than that.  There is a 1:1:1 relationship between an RC
an RK (at an SG) and an AS (at an ASP).  As such, the current RC
identifies a traffic flow (RK) to and from an AS.  Read the words:
"Routing Context".  This does not say "AS Identifier".  The purpose
of RC is so that traffic can be managed in association with AS using
ASPTM procedures.  AS are only indirectly identified by the traffic
that flows to and from them.  An RC is a local thing between ASP and
SGP.  It is used to identify a portion of the traffic on an association
between ASP and SGP for an AS.  Where there are not multiple traffic
flows on an association, RC need not be provided in any message.

None of that changes for single-ended.  Between IPSPs an RC is still
used to identify traffic flows on the association and the AS to and
from which the traffic flows.

It is double-ended that changes things by trying to introduce two
RC values to identify one traffic flow by mangling the ASPTM
procedures (two ASPACs where one will do).  RC suddenly is identifying
half a traffic flow (half-duplex) where in the AS/SG case it identifies
the full traffic flow (full-duplex).

That change is not only unacceptable it breaks the RK tables and routing
procedures as well, and breaks the registration procedures too.
Get rid of it.

> > > 3. It breaks the ability to use the registration messages and
> > > procedures in their current form since they depend on a RC value
> > > to be assigned to a single routing key (one AS).
> > 
> > Nothing breaks.  In a point to point network only a single routing
> > key is required.
> I did not realize until now that you were proposing that
> in addition to one RC for the pair of AS's, that the two AS's would
> also be identified by a single routing key.
> Obviously, there would need to be a different RK for each AS pair.
> And, the RK would almost certainly have to include both a OPC and
> a DPC (in addition to possibly SI and others) in order to uniquely
> identify the pair of ASs. Thus, an AS would be associated with 
> multiple RKs - one for each AS pair that it belonged to.
> 
> To me, this adds yet another fundamental
> change of definition. The one that states that there is a 1-1 
> relationship between a RK and a AS.  

There is still a 1:1:1 relationship between an RC:RK:AS at each
IPSP.  Nobody said this relationship held across the entire system.
This is a local relationship at an SGP or ASP.  In each IPSP this
relationship still holds.

> From the 1.2 Terminology section:  a routing key 
> "uniquely defines the range of signalling traffic to be handled by
> a particular Application Server".

And the RC can be viewed as an index into the RK table. This is
the 1:1:1 relationship between RC and RK and AS).  You would
have us break this relationship and make it 2:1:1.

> 
> 
> > 
> > > 4. I believe that it is much easier to manage and understand RCs
> > > assigned to AS's than to pairs of AS's. An RC per AS grows
> > > linearly with the number of AS's, whereas an RC per AS-AS pair
> > > grows exponentially.  It is true that for the simple case of a
> > > single AS serviced by a single IPSP that this is all a non-issue
> > > since in both the single ended and the double ended case you don't
> > > even need to use an RC, it is only interesting when you consider
> > > the more complicated cases.  Even though between any two pairs of
> > > AS's it is point-to-point.
> > 
> > For one point-to-point connection per association, there are no
> > RC values required.  You only need a lot of RC values if you are
> > trying to run a whole bunch of point to point connections over
> > the same association, but this is really not in fitting with the
> > concept of a point to point network.  In practice, there will
> > likely be one or more associations per point to point relationship.
> > Even SS7 has this (F-links).
> > 
> > > It is also true that a given IPSP is certainly going to have
> > > associations with many other IPSPs and/or SGPs. And, its AS(s) is
> > > going to be paired up with many other ASs.
> > 
> > If it has associations with many other IPSPs, there will be no
> > need for RC on the associations because the point-to-point traffic
> > will be implicit.
> The RC can be implicit if there is only one AS per IPSP.

You miss the case where both sides know which AS the other has
been preconfigured for and neither side cares to distinguish
traffic between them and they are all either active or inactive
at the same time.

> 
> > 
> > > 5. I think that it is a mistake to create specialized behavior and
> > > semantics for when communicating with another IPSP versus
> > > communicating with a SG.
> > 
> > This approach permits the ASP to be unaware of whether it is
> > communicating with an SG or another ASP.  You are write: double-
> > ended is so specialized that it requires the ASP to know it is in
> > IPSP mode to change to the double-ended procedure.  Single-ended
> > relieves this obligation from the ASP and is the simpler approach.
> I do not agree with this. I agree with what you said earlier:
> "The ASP performs this function in the same way as the SGP 
> routes ougoing message."
> In other words the ASP needs to know whether it is talking with
> a SGP or an IPSP. And when it is send data to an IPSP it 
> uses logic of an SGP.  This is true for either approach.
> I believe that the double ended is able to retain more of
> the fundamental meanings of what already exists for SG/AS.
> 
> I believe that all my reasons above still apply as to why double 
> ended is better.

It cannot be better if it doesn't work.  See simple example in
other mail on this thread.

> In addition, I think that breaking the 
> 1-1 relationship between a RK and an AS is an even more serious
> argument against single ended. 

There is no breaking of this relationship for single-ended.
Double-ended breaks the 1:1 relationship between RC and RK
(makeing it 2:1) and that is why all the other procedures break
as well.  Double-ended cannot work anything like the SG/AS case.

--brian

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

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