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

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

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

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