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

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 5 Nov 2001 10:48:04 -0600

Javier,

Javier Pastor-Balbas (ECE) wrote:                          (Mon, 05 Nov 2001 17:05:57)
> Hi Brian, 
> 
> The need is because you need to be consistent with the already defined M3UA.

I think you need to read the current draft.

> You can also create a new protocol, but this out of the scope of this WG.

That is what DE is: a new protocol with new messages
with two RCs in 'em.  The current draft has a message
with one RC that is used to indentify the traffic flow
in both directions.

If you want a DE approach, please write it up as an
extension draft as there are too many changes to the
existing single-ended operation.

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

That is not what Dennis showed.  Can you please show us an
example of this.  You origianl proposal also somehow modified
the REG REQ message to include a LRC (what was that?  why
was it needed?)

> 
> Also, when sending data you send along the RC that the peer needs to
> discover the AS the message is sent to.

Hello:  SUA and M3UA need to know both the AS that the message is
being sent to and the AS that the message is being sent from.
This is so that the EXISTING M3UAv09 ASPTM procedures can be
performed.  You cannot get away with only identifying half a
direction.  SUA has an RC which is necessary to place both source
and destination into context (gee... it's a Routing CONTEXT after
all), M3UA also needs source RC to determine whether the message
originates from an ACTIVE or INACTIVE AS.

> No more information is needed.

The originating AS must also be identified.

> The peer, as it has unicity in RC (no two RC are equal) can inmediatly know
> the destination for the M3UA message.

In SE, no two RCs are equal either.

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

It is not required to example SS7 address parameters in the AS/SG case
and this is why RC identifies both directions of traffic flow.

I have said this about ten times to you know and you seem unable to
understand that SUA does not include source address parameters in
messages because they are implied by the RC.  The RC MUST identify
the source AS as well.

> 
> Registration procedures are the same as in the SG-AS model since each ASP
> registrates its AS's RK.

Dennis shows the opposite.  Also, there are RK's for which there are
no "reverse" RK's (SUA AMF).  As such, the RK does not identify the
traffic flow.  Only RC identifies the traffic flow.  SUA CO works in
this way.  SE works for SUA and M3UA as well, DE does not.

> In this way automatic configuration is completely allowed.

You are taking a very myopic view.  Please demonstrate how this
works for SUA CO with GT.

> And activation is also the same: An ASP can activate their own AS
> in the other end. A real peer2peer model.

Not necessary.

> 
> By the way the double messages, are just a very small part in all the
> communication with no weight at all.

Well, they activate half a traffic flow which is disasterous
for point-to-point SS7.

> And you need them as well as a RC per AS to keep consistency

SE is more consistent with AS/SG as it does not
require changing messages to include two RCs.

>and compability with M3UA.

SE is more compatible because it doesn't require
an ASP to operation in one mode or the other and
maintain different datastructures for the same pupose
in different modes.

> We can not create another protocol...

The please don't.  DE is another protocol.  SE is already
provided for in the draft.

--brian

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

-- 
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: Mon, 5 Nov 2001 10:48:04 -0600

Javier,

Not necessary.

--brian

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

---