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

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

Hi Brian, 

The need is because you need to be consistent with the already defined M3UA. You can also create a new protocol, but this out of the scope of this WG.

Each ASP registrates each RK and gets an RC not used in the other end. In this way we assure consistency of RC as an routing table index. 

Also, when sending data you send along the RC that the peer needs to discover the AS the message is sent to. No more information is needed. The peer, as it has unicity in RC (no two RC are equal) can inmediatly know the destination for the M3UA message. The SS7 application over it can also know the procedence of the M3UA message taking a look to the address parameters included in the M3UA message.

Registration procedures are the same as in the SG-AS model since each ASP registrates its AS's RK. In this way automatic configuration is completely allowed. And activation is also the same: An ASP can activate their own AS  in the other end. A real peer2peer model.

By the way the double messages, are just a very small part in all the communication with no weight at all. And you need them as well as a RC per AS to keep consistency and compability with M3UA. We can not create another protocol...

Cheers // Javier.

> -----Original Message-----
> From: Brian F. G. Bidulock [mailto:[email-masked]]
> Sent: Sunday, November 04, 2001 9:59 PM
> To: sigtran
> Cc: [email-masked]
> Subject: Re: [Fwd: Re: IPSP proposed text (1st approach)]]
> 
> 
> Javier,
> 
> Then why is there a need for twice as many RCs?  And twice
> as many messages?
> 
> --brian
> 
> Javier Pastor-Balbas wrote:                                
> (Sun, 04 Nov 2001 12:39:14)
> > Brian, 
> > 
> > One quick answer:
> > 
> > As IPSP2 registrates two RKs, it is serving to two ASs and 
> therefore it
> > gets two RCs... Always 1:1:1.
> > 
> > Cheers // Javier.
> > 
> > --- "Brian F. G. Bidulock" <[email-masked]> wrote:
> > > Javier,
> > > 
> > > But Javier, then we have
> > > 
> > >   IPSP1 uses RC1 for traffic from AS1 to AS3.
> > >   IPSP1 uses RC2 for traffic from AS2 to AS3.
> > > 
> > >   IPSP2 uses RC3 for traffic from AS3 to AS1.
> > >   IPSP2 uses RC4 for traffic from AS3 to AS2.
> > > 
> > > This is not what was being described as the RC is associated
> > > with the AS.  AS3 has two RC values (RC3 and RC4) in that
> > > case for the same assocation and the same pair of IPSPs.
> > > I thought you (or others) said that double-ended didn't
> > > require this?  I though you (or others) said that this is
> > > what made double-ended "like" the AS/SG case: that one
> > > RC identified an AS.  But here you have two RCs for AS3.
> > > If AS3 has similar RKs to 400 other AS, then AS3 will
> > > require 402 RC values?  Gee, one for each traffic flow?
> > > 
> > > This is not double-ended at all.  It just has one set
> > > of redundant RC values for the reverse direction.  With
> > > 400 more AS, this would require 804 RC values.
> > > 
> > > 
> > > In the single-ended case we have:
> > > 
> > >   IPSP1                       IPSP2
> > > 
> > >        REG REQ (RK2, RK1)
> > >     -------------------------->
> > >   
> > >        REG RESP (RC1, RC2)
> > >     <--------------------------
> > >   
> > > And,
> > > 
> > >   IPSP1 uses RC1 for traffic from AS1 to AS3;
> > >   IPSP1 uses RC2 for traffic from AS2 to AS3;
> > > 
> > >   IPSP2 uses RC1 for traffic from AS3 to AS1;
> > >   IPSP2 uses RC2 for traffic from AS3 to AS2;
> > > 
> > > Configuration need only be assigned at one end
> > > instead of both as in the double-ended case.
> > > There are half the messages, half the RC values
> > > and there is no case of activations that are
> > > stuck in half-duplex mode.
> > > 
> > > With 400 more AS, this would required only 402 RC
> > > values.
> > > 
> > > 
> > > Where is the value in the double-ended approach in
> > > this case?
> > > 
> > > --brian
> > > 
> > > 
> > > Javier Pastor-Balbas wrote:                               
>  (Sun, 04
> > > Nov 2001 12:20:32)
> > > > Brian, 
> > > > 
> > > > IPSP1 won't return the same value for RK3 and RK4 in 
> double-ended.
> > > It
> > > > will never happen...
> > > > 
> > > > 
> > > > 
> > > > IPSP1                       IPSP2
> > > > 
> > > >      REG REQ (RK2, RK1)
> > > >   -------------------------->
> > > > 
> > > >      REG RESP (RC1, RC2)
> > > >   <--------------------------
> > > > 
> > > > 
> > > >      REG REQ (RK3, RK4)
> > > >   <--------------------------
> > > >  
> > > >      REG RESP (RC3, RC4)
> > > >   -------------------------->
> > > > 
> > > > 
> > > > No violation here... 4AS:4RK:4RC
> > > > 
> > > > 
> > > > Examples of DATA msgs
> > > > 
> > > >        DATA (RC4)
> > > >   -------------------------->
> > > >        DATA (RC3)
> > > >   -------------------------->
> > > >        DATA (RC2)
> > > >   <--------------------------
> > > >        DATA (RC1)
> > > >   <--------------------------
> > > > 
> > > > 
> > > > 
> > > > 
> > > > Cheers  // Javier.
> > > > 
> > > > 
> > > > 
> > > > 
> > > > --- "Brian F. G. Bidulock" <[email-masked]> wrote:
> > > > > Javier,
> > > > > 
> > > > > > > > >   The routing table at IPSP1 is:
> > > > > > > > > 
> > > > > > > > > 	RC3 RK3
> > > > > > > > > 	RC3 RK4
> > > > > > > > > 
> > > > > > > > > Now, there is a problem.  This routing table 
> at IPSP1 is
> > > > > > > > > not valid: there is the same RC value (index) 
> for two RK
> > > > > > > > > entries.  How can this happen?  How will IPSP1 know to
> > > > > > > > > return the same RC value when RK1 and RK2 are 
> registered?
> > > > > > > > > This would also violate the key relationship 
> that there
> > > > > > > > > is a 1:1:1 relationship between RC, RK, and AS.
> > > > > 
> > > > > How can this happen?
> > > > > 
> > > > > --brian
> > > > > 
> > > > > -- 
> > > > > Brian F. G. Bidulock
> > > > > [email-masked]
> > > > > http://www.openss7.org/
> > > > 
> > > > 
> > > > __________________________________________________
> > > > Do You Yahoo!?
> > > > Find a job, post your resume.
> > > > http://careers.yahoo.com
> > > > 
> > > > 
> > > > ---
> > > > 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/
> > 
> > 
> > __________________________________________________
> > Do You Yahoo!?
> > Find a job, post your resume.
> > http://careers.yahoo.com
> > 
> > 
> > ---
> > 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]