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

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

Javier,

Javier Pastor-Balbas (ECE) wrote:                          (Tue, 06 Nov 2001 12:55:23)
> Brian, 
> 
> Only one comment. You misinterpreted my answer....
> 
> > -----Original Message-----
> > From: Brian F. G. Bidulock [mailto:[email-masked]]
> > Sent: Tuesday, November 06, 2001 12:50 PM
> > To: Javier Pastor-Balbas (ECE)
> > Cc: sigtran
> > Subject: Re: [Fwd: Re: IPSP proposed text (1st approach)]]
> > 
> > 
> > Javier,
> > 
> > Javier Pastor-Balbas (ECE) wrote:                          
> > (Tue, 06 Nov 2001 12:35:05)
> > > 
> > > 
> > > > -----Original Message-----
> > > > From: Brian F. G. Bidulock [mailto:[email-masked]]
> > > > Sent: Tuesday, November 06, 2001 12:21 PM
> > > > To: sigtran
> > > > Cc: [email-masked]
> > > > Subject: Re: [Fwd: Re: IPSP proposed text (1st approach)]]
> > > > 
> > > > 
> > > > Javier,
> > > > 
> > > > Javier Pastor-Balbas (ECE) wrote:                          
> > > > (Tue, 06 Nov 2001 11:57:41)
> > > > > 
> > > > > 
> > > > > > -----Original Message-----
> > > > > > From: Brian F. G. Bidulock [mailto:[email-masked]]
> > > > > > Sent: Tuesday, November 06, 2001 11:39 AM
> > > > > > To: sigtran
> > > > > > Cc: [email-masked]
> > > > > > Subject: Re: [Fwd: Re: IPSP proposed text (1st approach)]]
> > > > > > 
> > > > > > 
> > > > > > Javier,
> > > > > > 
> > > > > > Javier Pastor-Balbas (ECE) wrote:                          
> > > > > > (Tue, 06 Nov 2001 11:22:13)
> > > > > > > 
> > > > > > > (snip)
> > > > > > > > > 
> > > > > > > > > Solve me this example where ASP1 and ASP2 belongs to 
> > > > > > > > different operators
> > > > > > > > > with no communications between them and with 
> > prefixed RC=3:
> > > > > > > > 
> > > > > > > > > ASP1------ASP2-------ASP3, ASP2 can obtain two 
> > RC from ASP1 
> > > > > > > > and ASP3 that
> > > > > > > > > are the same value.
> > > > > > > > 
> > > > > > > > So can DE.  ASP2 is not in control of the RC that 
> > either ASP1
> > > > > > > > or ASP3 provide it.
> > > > > > > > 
> > > > > > > 
> > > > > > > In my proposal (call it whatever) It is ASP2 the one who 
> > > > > > decides what RC
> > > > > > > gives to ASP1 and ASP3 and ASP2 assures that both RCs are 
> > > > > > different. There's
> > > > > > > no need of previous ASP1-ASP3 communication.
> > > > > > 
> > > > > > But you need two RC values in DE.  One is assigned by 
> > > > ASP1 and another
> > > > > > assigned by ASP3.  They can be the same without ASP1-ASP3 
> > > > > > communication.
> > > > > > Same situation in DE.
> > > > > > 
> > > > > 
> > > > > The RC (RC23) that is assigned to the RK register by ASP2 
> > > > in ASP3 (call it
> > > > > RK23) is the index in ASP3 table of the RK23. When the 
> > > > application part in
> > > > > ASP3 wants to send a msg to ASP2, it will perform a search 
> > > > in its Routing
> > > > > Table where all the RCx3 are unique as well, because ASP3 
> > > > assures that all
> > > > > RCx3 are unique since it assign them to each new AS 
> > that wants to
> > > > > communicate to ASP3.
> > > > > 
> > > > > What each ASP needs to do is finding the unique RC that it 
> > > > gave to the peer
> > > > > to identify the peer AS in order to the peer ASP to 
> > > > differenciate what AS
> > > > > the message is for.
> > > > 
> > > > There is no need.  When an ASP registers with multiple 
> > SGs it gets the
> > > > can get the same RC value back from both SG for different 
> > > > routing keys.
> > > 
> > > Yes, but inside the SGP you have RC unicity.
> > 
> > It is not necessary.  The SGP can handle separate RK tables
> > per association.
> 
> How can you know what association routing table you have to use with only
> the routing parameters that you have receive from the SS7 part? First find
> RK -> RC/AS -> ASP -> association
> 
> This is the only possible order.

RK -> ASP/Assoc -> RC/AS.

> 
> > 
> > > 
> > > In the same way in IPSP, an ASP can get RC that are related 
> > to its local RK
> > > that are the same. But those RC are used only for msg 
> > distribution, and you
> > > can start searching by the Association Id in that case, 
> > since you have the
> > > association the mesg came from.
> > 
> > The same is true for SGP at the other end.  It can have separate
> > RK table per association.  It does not matter if the index for
> > one RK table is the same as another.  They are distinguished by
> > association.  Big deal.
> > 
> 
> Brian, I was talking about sending a msg from the SGP to ASP. There is no
> association information until you get it from the RK/RC/AS... 

RK -> ASP/Assoc -> RC/AS.

--brian

> 
> Cheers // Javier.
> 
> > > 
> > > 
> > > > The RC value is a local thing that pertains only to the 
> > entity that is
> > > > providing it. 
> > > 
> > > RC belongs to both, but it is a reference of the RK that 
> > belongs to the
> > > entity that is providing it.
> > 
> > For the association over which it is exchanged.
> > 
> > > 
> > > > When you consider that IPSPs are performing SG routing
> > > > functions, it is not a stretch for the ASP to receive 
> > > > different RC values
> > > > for the same routing key from different IPSPs.  There is no 
> > > > problem here.
> > > > It fits the data model for the ASP just fine.  SE will do.
> > > > 
> > > > --brian
> > > > 
> > > 
> > > The RC is an index to the RKs table (also called routing 
> > table) and the SGP
> > > needs to have the 1:1:1 relationship.
> > 
> > At an SGP for a given ASP.  Anything more is unnecessary.
> > 
> > > When an ASP sends a msg to the remote peer it has to behave 
> > in the same way
> > > SGP do.
> > 
> > SGP are permitted to give out the same RC values on different 
> > associations
> > to different ASPs for different RKs.  They can do this today.
> > 
> > > In that way upon the reception of the message by the peer 
> > ASP it will behave
> > > as ASP does in the SG-AS model. With the existing model in 
> > M3UA everything
> > > works fine.
> > 
> > Gee, you are so worried about making an IPSP *be* an ASP, yet act
> > like an SGP.  Get rid of the ASP and just make the IPSP an SGP.
> > IPSP is just SGPs talking peer-to-peer.  This is consistent with
> > the SIGTRAN architecture.  An IPSP is an SG/SGP.
> > 
> > If you want to distribute a bunch of ASs, distribute them on
> > ASP on the back-end per the SIGTRAN architecture and have them 
> > talk to the IPSPs as SGPs.
> > 
> > --brian
> > 
> > > 
> > > 
> > > Cheers // Javier.
> > > 
> > > 
> > > > 
> > > > > 
> > > > > > > 
> > > > > > > Your proposal can not solve it without ASP1-ASP3 
> > > > > > communication. And that
> > > > > > > communication can be impossible if we are talking of 
> > > > > > different operators...
> > > > > > 
> > > > > > Your proposal does not solve it either.
> > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > > > > In that case another characteristic of  RC (index of RK
> > > > > > > > > table) has been aniquilated.
> > > > > > > > 
> > > > > > > > No difference SE to DE here.  It is still an 
> > index into the
> > > > > > > > RK table, one is the index into the RK table for ASP1, the
> > > > > > > > other is the index into the RK table for ASP2.  
> > RKs and RCs
> > > > > > > > are acquired on a per-association basis.  This is true for
> > > > > > > > AS/SG as well.
> > > > > > > > 
> > > > > > > > Example SGP1(SG1)---ASP2---SGP3(SG2).  Again the 
> > ASP is not
> > > > > > > > in control of the RC value provided it.
> > > > > > > > 
> > > > > > > > Also for, SGP1---ASP2---SGP2.  There is noting 
> > stopping SGP1
> > > > > > > > from returning the same RC value as SGP2 (it even 
> > SHOULD for
> > > > > > > > the same RK).
> > > > > > > > 
> > > > > > > 
> > > > > > > Let's focus in that example. There is a big difference 
> > > > > > here. At SGP there
> > > > > > > are not more than one RC with the same value. SGP needs to 
> > > > > > have this unicity
> > > > > > > since it is using RC/RK/AS table to route towards the right 
> > > > > > AS. When SGP is
> > > > > > > sending a message to an AS it looks at the addressing 
> > > > > > information and match
> > > > > > > a RK. That RK has associated an AS and that AS a RC. 
> > > > > > Afterthat, it can send
> > > > > > > out the message to the right IP address.
> > > > > > > 
> > > > > > > ASP is only using the receiving RC (optionally) to pass the 
> > > > > > message to the
> > > > > > > right AS and it can do it by association. When an ASP 
> > > > > > receives a mesg it
> > > > > > > gets the AS from both inputs RC and association identifier 
> > > > > > (in the case it
> > > > > > > serves more than one AS).
> > > > > > > 
> > > > > > > As you see there are different tables for different 
> > purposes.
> > > > > > > 
> > > > > > > > For double ended:  ASP1---ASP2---ASP3  The RC is an index
> > > > > > > > into the ASP1 RK table and that index can be the same as
> > > > > > > > the index into ASP3's RK table.
> > > > > > > > 
> > > > > > > 
> > > > > > > In my proposal the RC is an index into the Routing table 
> > > > > > ASP has as M3UA
> > > > > > > draft says. 
> > > > > > 
> > > > > > The draft says for the SGP.
> > > > > 
> > > > > Yes, when you send a message to an ASP. Same case.
> > > > > 
> > > > > > 
> > > > > > > 
> > > > > > > The work ASP sends a message to another ASP has to work in 
> > > > > > the same way it
> > > > > > > works when an SG sends a message to an ASP. From the 
> > > > > > information given by
> > > > > > > the user part to send a message to the M3UA layer, M3UA 
> > > > > > will find a RK
> > > > > > > associated with an unique RC associated with a unique AS 
> > > > > > associated with and
> > > > > > > Association Id. RC in the Routing Table is unique since 
> > > > > > although ASP1 and
> > > > > > > ASP3 don't have communication between them, it's ASP2 the 
> > > > > > one who assigns
> > > > > > > the RC for their RK. And these are the unique RC that ASP 
> > > > > > sends to the peer
> > > > > > > ASP along with DATA. The table keeps the consistency of 
> > > > > > RK-RC-AS as 1:1:1. 
> > > > > > 
> > > > > > But these are not unique across SGs.  An there is no 
> > > > reason to expect
> > > > > > then to be unique across IPSPs either (DE or SE).  
> > > > Independent IPSPs
> > > > > > cannot avoid another IPSP's RC values.
> > > > > > 
> > > > > 
> > > > > Message distribution is per SGP in the AS-SG communication.
> > > > > Message distribution is per IPSP in the IPSP communication.
> > > > > 
> > > > > In SGP and IPSP, the RCs that identify the remote AS shall 
> > > > be unique. Remember 1:1:1.
> > > > > 
> > > > > 
> > > > > Cheers // Javier.
> > > > > 
> > > > > 
> > > > > 
> > > > > > > 
> > > > > > > When ASP receives the message, it works exactly the same as 
> > > > > > in the SG-AS
> > > > > > > model.
> > > > > > > 
> > > > > > > There is no way of having this RC unicity with your model 
> > > > > > if there is no
> > > > > > > previous communication between ASP1 and ASP3. Imagine if we 
> > > > > > increase the
> > > > > > > number of ASPs that wants to communicate with ASP2.... It's 
> > > > > > even harder for
> > > > > > > you..
> > > > > > 
> > > > > > There is no way in DE either.
> > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > > > Sorry, you'll have to do better than that.
> > > > > > > > 
> > > > > > > 
> > > > > > > Brian, I'm not trying to do it better or worse, just trying 
> > > > > > to reflect the
> > > > > > > reasons why I think your model doesn't work. And the worst 
> > > > > > thing is that you
> > > > > > > are trying to change basic concepts as RC definition/use, 
> > > > > > the needs an ASP
> > > > > > > and its user part have, etc. I don't know what kind of 
> > > > > > implementation you
> > > > > > > are doing (if any). But for big networks, it doesn't work 
> > > > > > efficiently: think
> > > > > > > about O&M, and also you try to change M3UA basic concepts.
> > > > > > 
> > > > > > You are blind to the same deficiencies in DE.  SE is 
> > just DE with
> > > > > > one RC value per pair and single message exchange.
> > > > > > 
> > > > > > --brian
> > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > > Cheers // Javier.
> > > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > > ---
> > > > > > > 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]
> > > > > > 
> > > > > 
> > > > > 
> > > > > ---
> > > > > 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]
> > > > 
> > > 
> > > 
> > > ---
> > > 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]

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