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

From: Dennis Niermann <[email-masked]>
Date: Sun, 04 Nov 2001 14:23:48 -0600

Hi Brian,
your questin answered below..

"Brian F. G. Bidulock" wrote:
> 
> 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?
They may be valid for the single ended case, but not
for the double ended case since it maintains a 1-1 relationship
from RK to AS. I already answered your question above.
I said that if OPC is to be included as a parameter of the RK
that means that there must be an AS for each possible OPC.
This is the same as for SG/AS. 

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

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