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

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 5 Nov 2001 13:03:12 -0600

Javier,

Javier Pastor-Balbas (ECE) wrote:                          (Mon, 05 Nov 2001 18:57:47)
> 
> Hi Brian, 
> 
> See below....
> 
> > -----Original Message-----
> > From: Brian F. G. Bidulock [mailto:[email-masked]]
> > Sent: Monday, November 05, 2001 5:48 PM
> > To: Javier Pastor-Balbas (ECE)
> > Cc: sigtran
> > Subject: Re: [Fwd: Re: IPSP proposed text (1st approach)]]
> > 
> > 
> > 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.
> > 
> 
> You don't need it. It is completely superfluous. But if you insist,  just
> look to the addressing information and get the origin. Very easy.

Can you read?  SUA does not have the source addressing information in CODT.
It is impossible (not easy at all).

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

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.

Sorry, you'll have to do better than that.

> 
> 
> > > 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.
> > 
> 
> M3UA sends them within Routing Label.
> Read also Chapter 3.2.1 of SUA and you will find Source Address as mandatory.
> 
> Source addresses are always sent... Your argument is not valid.

Not in SUA CODT.  Please point out the source address. (I save you
the look, it's not there, just destination address.)   Also if IPSP
is ever to support transfer/relay, the OPC is not sufficient.  The
ASP must also know the route upon which the message was received
(i.e., the identification of the originating AS which is independent
of originating OPC).

Your argument that one can just dig in the RL is extremely limited
and does not address the issue.  Take a look at the M3UA example
networks that were provided for the SG/AS case in the Routing Context
and Network Appearance discussion.  It provides examples of network
configuration where NA/OPC/DPC is insufficient for determining the
traffic flow in question.  RC in DATA and SNMM has served to make
these configuration workable and DE will break that by reinterpreting
RC as something different than traffic flow.

> > > 
> > > 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.
> > 
> Review Section 1.2 Terminology of SUA.

See discussion on decoupled support for CO messages.  (SUA Issue #14).

> 
> > > 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.
> > 
> 
> Registration is the same for either CO or CL.

No.  See SUA Issue #14.

> The RK that has been exchanged during the REG is used to analyze the
> destination address of the CORE message to establish the signaling
> conection.  The rest of CO operations are done following the methods
> defined in ITU Rec Q.714 i.e. based in the information related to the source
> and destination reference numbers which is localy stored.

Source numbers and addresses are not included in either CODT or DT1/DT2.

See SUAv8 Section 3.3.1 Connection Oriented Data Transfer (CODT).
There is no source address or source reference number information in
the message.  Only the RC identifies the source.

> As you can imagine, it's the same procedure as for ASP-SGP, once again but
> doubled. Just read it and apply them directly to IPSP.
> 
> Take always this simple rules: 
>  1. Act as SG when receiving ASPTM and ASPSM msgs and like ASP when sending
>  ASPTM and ASPSM msgs. 
>  2. Send always DATA msgs as if you were a SG to include the RC that allows
>  the peer to identify the AS the msg is directed to.

How is the sending AS identified?  (See CODT Section 3.3.1 for lack of
source info in message.)

> > > And activation is also the same: An ASP can activate their own AS
> > > in the other end. A real peer2peer model.
> > 
> > Not necessary.
> > 
> 
> Yours it is client-server  :-(.

So what.  Works for TCP and SCTP.

> 
> > > 
> > > 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.
> > 
> I'm afraid you don't know that SS7 Routes are unidirectional.... Of course
> SS7 links aren't, in the same way as ethernet cables are not....

SS7 relies on the fact that if the forward route is available that
the reverse route is also available.  TFA/TFP/UPU applies for both
directions, not just one.

> 
> > > 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.
> 
> Neither does DE.

DE requires two RCs in CODT: one to identify source AS, the other destination
AS.  SE only requires one which identifies the traffic flow between two AS
and can be used to identify either the source or destination AS.

--brian

> 
> 
> 
> Cheers // Javier.
> 
> 
> 
> 
> 
> > 
> > >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]

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