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

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Sun, 4 Nov 2001 13:40:39 -0600

Dennis,

Dennis Niermann wrote:                                     (Sun, 04 Nov 2001 13:19:28)
> Hi Brian,
> See my responses below...
> 
> "Brian F. G. Bidulock" wrote:
> > 
> > Dennis,
> > 
> > Dennis Niermann wrote:                                     (Fri, 02 Nov 2001 17:38:08)
> > 
> > > > Dennis, this is not what the table says above:
> > > > it says that message from AS1 have RC1, meaning
> > > > that they are labelled with the AS from which the
> > > > message is sent, in reverse to that of the draft
> > > > for AS/SG case.  These are completely reversed.
> > > > If you place the other RC in the message, then
> > > > the question arrises where the message came from
> > > > and how to apply ASPTM on imcoming messages.
> > 
> > > OK, then I think it is a table interpretation issue.
> > 
> > I think the table provided as very clear and not
> > open to interpretation.
> > 
> > > What I believe for the ASP/SGP case is what I said
> > > in the previous paragraph. But I left out the case
> > > of DATA from the ASP to the SGP. The fact is that the RC
> > > value is included in DATA messages for different reasons
> > > when it flows ASP to SGP versus SGP to ASP. There has
> > > probably been a previous discussion as to why it is helpful
> > > to receive RC at the ASP "to assist in internal distribution".
> > 
> > There was a disccusion about why it was necessary, not
> > why it was "helpful".  Please refer to any long thread
> > in the archive in the last 4 mo. that has "Network Appearance"
> > or "Routing Context" in the subject line.  You are comming
> > into this discussion rather late.  It might be helpful to
> > ask questions before making assertions coming in so late.
> Brian, I am not trying to re-open or refute any previous 
> discussion concerning RC in DATA messages. But, ultimately
> discussion threads do not matter if the conclusion is not
> manifested in the M3UA specification.

You will need to wait for M3UA-10 as the conclusion to 
require RC in DATA when not implied by the association was
made just after M3UA-09 was released.  Read the threads.

> The latest draft 
> indicates that the RC parameter in the DATA message is optional.
> If it is necessary, why doesn't the spec either show it as 
> a mandatory parameter or use language like "the RC parameter
> MUST be used in DATA messages when the association is used by
> more than one AS/RC/RK"? (That's a question, not an assertion :) ).

The language has been added... to M3UA-10.  It would
help if you would look at the previous discussion and
conclusions on Routing Context and Network Appearance.

> 
> > 
> > > I don't understand why the SI isn't used to distribute
> > > the message to the right M3UA user, but I'll accept that
> > > there is probably some reason.
> > 
> > Refer to the threads on Network Appearance and Routing
> > Context for detail technical discussion of the reasons
> > for the REQUIREMENT that RC be place in the DATA in both
> > directions where not implied by the association.
> Once again, I am neither supporting nor arguing this use
> of RC in DATA messages. But, if it is a requirement then
> the specificatin should say so, and preferably in th section 
> that describes the RC parameter in the DATA message.

It will.  See discussion on Routing Context and Network
Appearance.

> 
> > 
> > > I also accept your explantion that the RC should be used
> > > at the SGP to verify the AS is active.
> > 
> > Good.
> (Although the spec makes no reference to this of RC in 
> DATA messages.)

See discussion.

> 
> > 
> > I am not convinced that the double-ended approach that
> > you describe can even work.  Perhaps you (or Javier or
> > Tolga or someone) could describe how the ASPs obtain
> > their RC values in the following very simple example:
> > 
> > (I don't agree yet that an IPSP has any need to support
> > multiple AS in a point-to-point arrangement, however,
> > this is the example.)
> > 
> >    PC1,SI5
> >     _____
> >    /     \
> >   |  AS1  |
> >    \_____/\                                  PC3,SI5
> >            \  _______           _______       _____
> >             \|       |  assoc  |       |     /     \
> >              | IPSP1 |---------| ISPS2 |----|  AS3  |
> >             /|_______|         |_______|     \_____/
> >     _____  /
> >    /     \/
> >   |  AS2  |
> >    \_____/
> > 
> >    PC2, SI5
> > 
> > You would have IPSPs send a pair of RC values in each
> > message where one RC value corresponds to the sending
> > AS and the other RC value corresponds to the receiving
> > AS.
> > 
> > Now, let there be no ambiguity in the table:
> > 
> >   When IPSP1 sends messages from AS1 to AS3 it uses
> >   the RC values RC1,RC3.
> > 
> >   When IPSP1 sends messages from AS2 to AS3 it uses
> >   the RC values RC2,RC3.
> > 
> >   When IPSP2 sends messages from AS3 to AS1 it uses
> >   the RC values RC3,RC1.
> > 
> >   When IPSP2 sends messages from AS3 to AS2 it uses
> >   the RC values RC3,RC2.
> OK so far.
> 
> > 
> >   We have the following routing keys at IPSP2:
> > 
> >         RK1  (OPC=PC3,DPC=PC1,SI=SI5)
> >         RK2  (OPC=PC3,DPC=PC2,SI=SI5)
> For this example, these RKs are legal, but they are overkill.
> In this case, only the DPC is required to uniquely identify 
> AS1 and AS2.
> Including the OPC is only appropriate if you really want to 
> limit the traffic to this AS from only one PC and if you
> intend to add another AS at IPSP1 for each possible OPC.
> Especially, if the example was for SCCP traffic (funny how you
> chose SI=5 instead), the use of OPC in the RK would not be advisable. 
> I understand that it is necessary in the single-end approach, 
> but not in the double-ended.  
> 
> > 
> >   We have the following routing keys at IPSP1:
> > 
> >         RK3  (OPC=PC1,DPC=PC3,SI=SI5)
> >         RK4  (OPC=PC2,DPC=PC3,SI=SI5)
> No. This is incorrect.
> There is only one external AS and that AS must have a
> unique RK. It would need to be:
>           RK3  (DPC=PC3 [,SI=5])
> If want to have routing keys that distinguish by
> OPC then there must also be an AS4. 
> In the double ended approach, an AS always has a unique RK. 
> 
> The rest of your questions do not apply because of this
> fundamental flaw in the example.

The routing keys are valid.  Disinguishing by OPC is very
valid for ISUP for M3UA.  How do you propose to handle this
defficiency of the double-ended approach?  AS/SG does not
have this defficiency...  What did you change?

--brian

> 
> 
> > 
> >   Now let's take a look at the routing tables (as described
> >   in the draft, where the RC can be viewed as an index into
> >   a table containing the Routing Keys.)
> > 
> >   The routing table at IPSP2 is:
> > 
> >         RC1 RK1
> >         RC2 RK2
> > 
> >   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 do you expect this to work?  Differently than the
> > current RC/RK/AS approach for SG/AS???
> > 
> > Note that this prolem does not occur if you do point-to-
> > point: that is, if there is one association per AS pair.
> > Nor does it occur for the signle-ended case.
> > 
> > In the single ended case, we have two traffic flows: RC1
> > and RC2.
> > 
> > The table at IPSP2 is:
> > 
> >         RC1 RK1
> >         RC2 RK2
> > 
> > The table at IPSP1 is:
> > 
> >         RC1 RK3
> >         RC2 RK4
> > 
> > Please describe how you see this working in the double-ended
> > case.
> > 
> > --brian
> > 
> > --
> > 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]
> 
> -- 
> ---------------------------------------------------------------
>  Dennis Niermann              [email-masked]
>  Ericsson Network Systems   
>  Richardson, Tx 75081
> 
> 
> ---
> 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]