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

From: Dennis Niermann <[email-masked]>
Date: Fri, 02 Nov 2001 08:12:36 -0600

Hi Brian and Tolga,
I have some comments below.

"Brian F. G. Bidulock" wrote:
> 
> Tolga,
> 
> [email-masked] wrote:                        (Thu, 01 Nov 2001 19:53:26)
> > Hi,
> >
> > According to me the difference between allocation of RCs in two proposals
> > is not that one needs to take associations into account and the other one
> > not, but that one tries to code the two ends of traffic with a single RC
> > whereas the other one uses separate RCs (this is in fact obvious, one of
> > them uses one ASPAC, the other one two ASPACs)
> >
> > To neutralize the affect of different associations, let's consider the
> > following example:
> >     +-------+                                    +------+
> >     |       |                                    |      |
> >     | AS1   +-----------+          +-------------+ AS5  |
> >     |       |           |          |             |      |
> >     +-------+           |          |             +------+
> >                         |          |
> >                         |          |
> >     +-------+           |          |
> >     |       +---------+ |          |             +--------+
> >     | AS2   |         | |          | +-----------+ AS6    |
> >     |       |         |-+--\      /+-+-\         |        |
> >     +-------+        /      \    /      \        |        |
> >                     | IPSP1  +--+ IPSP2  |       +--------+
> >                      \      /    \      /
> >     +-------+         |---+/      \--+-|         +--------+
> >     |       |         |   |          | |         |        |
> >     | AS3   +---------+   |          | +---------|  AS7   |
> >     |       |             |          |           |        |
> >     +-------+             |          |           +--------+
> >                           |          |
> >     +-------+             |          |           +---------+
> >     |       |             |          |           |         |
> >     | AS4   +-------------+          +-----------+  AS8    |
> >     |       |                                    |         |
> >     +-------+                                    +---------+
> >
> > For double ASPAC proposal , I would expect a RC table like this for IPSP1:
> >
> >      Outgoing Traffic
> >      =================
> >      AS1 ===> RC1
> >      AS2 ===> RC2
> >      AS3 ===> RC3
> >      AS4 ===> RC4
> >
> >      Incoming Traffic
> >      ================
> >      AS5 <=== RC5
> >      AS6 <=== RC6
> >      AS7 <=== RC7
> >      AS8 <=== RC8
> 
> Your table seems to be lacking some information:
> 
> How does IPSP1 know to which AS this incoming
> traffic is to be offered?
I think that this a labelling problem.
The first set of RCs known at IPSP1 are used for
outgoing SSNM messages (when indicating your own AS
is necessary) and is received on incoming DATA messages
(when identifing the remote AS is required).

> 
> It is only labeled with the RC of where it is
> coming from not where it is going to.  That is
> not my understanding of the double-ended
> approach.
According to the draft 9, DATA messages may include
the RC "to identify the receiver of the traffic
flow to assist in the internal distribution of 
Data message". For SSNM messages the RC is used to 
"identify the Application Server of the sending ASP".
This is still the case for the double ended approach,
at least in my view.

> 
> If IPSP1 were an ASP and IPSP2 were an SGP,
> IPSP1 would register RKs towards AS1, AS2, AS3
> and AS4 (RK1 to 4) and receive RC1 to 4 in
> return.  The RK is an outgoing RK (not
> incoming).
> 
> So I think you mean that the table should look like this:
> 
>        Outgoing Trafic       Incoming Traffic
> 
>        AS1 => AS5    RC5     AS1 <= AS5   RC1
>        AS1 => AS6    RC6     AS1 <= AS6   RC1
>        AS1 => AS7    RC7     AS1 <= AS7   RC1
>        AS1 => AS8    RC8     AS1 <= AS8   RC1
>        AS2 => AS5    RC5     AS2 <= AS5   RC2
>        AS2 => AS6    RC6     AS2 <= AS6   RC2
>        AS2 => AS7    RC7     AS2 <= AS7   RC2
>        AS2 => AS8    RC8     AS2 <= AS8   RC2
>        AS3 => AS5    RC5     AS3 <= AS5   RC3
>        AS3 => AS6    RC6     AS3 <= AS6   RC3
>        AS3 => AS7    RC7     AS3 <= AS7   RC3
>        AS3 => AS8    RC8     AS3 <= AS8   RC3
>        AS4 => AS5    RC5     AS4 <= AS5   RC4
>        AS4 => AS6    RC6     AS4 <= AS6   RC4
>        AS4 => AS7    RC7     AS4 <= AS7   RC4
>        AS4 => AS8    RC8     AS4 <= AS8   RC4
> 
> But that is not the double-ended procedure
> either.
> 
> For outgoing traffic the AS is applying an
> outgoing routing key (the one that was
> registered) to apply the outgoing RC.
True.

> 
> But this doesn't quite work for incoming at
> IPSP1 because IPSP1 cannot tell the sending AS
> for incoming traffic.  IPSP1 needs to know if
> the incoming traffic is from an ACTIVE or
> INACTIVE AS on IPSP2 (particularly to avoid
> duplication, loss and missequencing in multiple
> IPSP scenarios).  Therefore, IPSP1 will have to
> apply a reverse RK to incoming traffic to
> determine the AS of origin.  However, for some
> RKs there is no "reverse" RK so the originator
> of the incoming traffic would remain a mystery
> unless a separate RC value is assigned to each
> traffic flow.  This means that incoming traffic
> to AS1 must be identified with 4 different RC
> values even though it originates from AS5.
This use of the RC is not described in the M3UA spec.
If it is required to verify that the originating 
AS is really active then I think the answer is to 
include the RC of the originating AS as a second 
parameter. Then the RC for the destination AS can
be used to help identify the AS at the receiving IPSP
as currently described in the spec. And, the RC
for the originating AS can be used to verify its
active state.

> 
> I should remind you that this procedure needs to
> work for SUA as well.  SUA does not identify the
> source of the message for connection oriented
> messages, just the detination.  It is impossible
> to apply a reverse routing key to these messages
> because the originator is implicit to the
> connection (bidirectional traffic).  If the RC
> included in the message only identifies the
> destination endpoint of a message, it will be
> impossible to determine the source AS of the
> message.  In which case you might as well get
> rid of ASPAC altogether, because INACTIVE and
> ACTIVE states will be treated the same by ASPTM
> procedures.  It will also be impossible to
> determine old messages from ASPs that were
> previously active for an AS, but which have
> switched over to another ACTIVE AS.  There is a
> long host of problems that result here.
> 
> Because you cannot distiguish traffic flows
> between AS, what you have is two AS here with
> the following table being all that is necessary:
> 
> Double-ended:
> 
>         Outgoing            Incoming
> 
>         AS1234 => RC1234    AS5678 => RC5678
> 
> And the same situation without distinguishing
> traffic flows in the single-ended case is:
> 
> Single-ended:
> 
>         Incoming-Outgoing
> 
>         AS1234-AS5678 <===> RC1
> 
> Neither case needs RC in ASPAC at all (it is
> implicit to the association in both directions).
> 
> Double ended needs 4 messages exchanged, single
> needs 2.
> 
> Double needs 2 RC values if provided, Single
> needs 1.
> 
> Q.E.D.
> 
> >
> > For single ASPAC proposal , again for IPSP1:
> >      Incoming-Outgoing Traffic
> >      =========================
> >      AS1-AS5 <===> RC1
> >      AS1-AS6 <===> RC2
> >      AS1-AS7 <===> RC3
> >      AS1-AS8 <===> RC4
> >      AS2-AS5 <===> RC5
> >      AS2-AS6 <===> RC6
> >      AS2-AS7 <===> RC7
> >      AS2-AS8 <===> RC8
> >      AS3-AS5 <===> RC9
> >      AS3-AS6 <===> RC10
> >      AS3-AS7 <===> RC11
> >      AS3-AS8 <===> RC12
> >      AS4-AS5 <===> RC13
> >      AS4-AS6 <===> RC14
> >      AS4-AS7 <===> RC15
> >      AS4-AS8 <===> RC16
> 
> Here it is obvious both at ISPS1 and IPSP2 to
> which AS (both local and remote) the traffic
> belongs traffic in either direction but it is
> not necessary to separate all of these traffic
> flows, only if each traffic flow needs to be
> independenly activated.  In the double-ended
> case it is impossible to determine to which
> traffic flow an message belongs.
> 
> >
> > It seems to me that the single ended approach uses M3UA point-to-point
> > between ASs, whereas double ended approach uses it point-to-point between
> > IPSPs.
> 
> Think about it again.  In your example you are
> using RC's in your odd double-ended tables as
> though they are merely one of the two AS (i.e.
> SS7-SAP) addresses.  You both originating and
> terminating RK analysis going on (wastefull)
> are using the RC values in th opposite direction
> of the direction for which they are registered.
> You seem to imply some digging in messages for
> this information, but in SUA and even in M3UA
> for some routing keys below full point code
> granularity, we know that there is is no reverse
> RK that can be applied.  In the single ended
> case only a forward routing key need be applied
> to obtain the RC such as in:
> 
>         AS1 => RK4 -> RC1
>                RK5 -> RC2
>                RK6 -> RC3
>                RK7 -> RC4
> 
>         ...
> 
>         AS4 => RK4 -> RC13
>                RK5 -> RC14
>                RK6 -> RC15
>                RK7 -> RC16
> 
> The routing function at the originating IPSP
> knows the originating AS implicitly and can
> apply the routing key explicitly.
> 
> You also seem to assume some "connectionless"
> paradigm where AS1 can send messages to all
> other AS.  This is not the case even for M3UA
> with ISUP routing keys.  ISUP routing keys
> are only valid for a PC/PC/CIC.  So, for
> example,  if the following is true in your
> example:
> 
>         AS1  RK  OPC=1, DPC=8, SI=5 CIC=100
>         AS2  RK  OPC=2, DPC=7, SI=5 CIC=100
>         AS3  RK  OPC=3, DPC=6, SI=5 CIC=100
>         AS4  RK  OPC=4, DPC=5, SI=5 CIC=100
>         AS5  RK  OPC=5, DPC=4, SI=5 CIC=100
>         AS6  RK  OPC=6, DPC=3, SI=5 CIC=100
>         AS7  RK  OPC=7, DPC=2, SI=5 CIC=100
>         AS8  RK  OPC=8, DPC=1, SI=5 CIC=100
> 
> Only the following traffic flows are valid:
> 
>         AS1 <--> AS8
>         AS2 <--> AS7
>         AS3 <--> AS6
>         AS4 <--) AS5
> 
> The single-ended routing table would look like:
> 
>         AS1 <--> AS8  RC1
>         AS2 <--> AS7  RC2
>         AS3 <--> AS6  RC3
>         AS4 <--) AS5  RC4
> 
> The double ended would look like (well, at least
> following the way you labelled it):
> 
> >      Outgoing Traffic
> >      =================
> >      AS1 ===> RC1
> >      AS2 ===> RC2
> >      AS3 ===> RC3
> >      AS4 ===> RC4
> >
> >      Incoming Traffic
> >      ================
> >      AS5 <=== RC5
> >      AS6 <=== RC6
> >      AS7 <=== RC7
> >      AS8 <=== RC8
> 
> So, now, let's look at a message arriving at
> IPSPa in the single-ended case:
> 
>         RC1 --> AS1
>         RC2 --> AS2
>         RC3 --> AS3
>         RC4 --> AS4
> 
> The RC value determines the AS.  For outgoing
> messages in the single-ended case:
> 
>         AS1 --> RC1
>         AS2 --> RC2
>         AS3 --> RC3
>         AS4 --> RC4
> 
> And no RK analysis is required.
> 
> The arriving RC always indicates the AS to which
> the message applies and the RC value attached to
> a message is implicit to the AS originating the
> message.  JUST AS IN THE AS/SG CASE.
> 
> Look at a message arriving at IPSP1 in the
> double-ended case:
> 
>         RC5 --> AS4
>         RC6 --> AS3
>         RC7 --> AS2
>         RC8 --> AS1
> 
> For message outgoing:
> 
>         AS1 --> RC1
>         AS1 --> RC2
>         AS1 --> RC3
>         AS1 --> RC4
> 
> So, in the single ended case there are 4 RC
> values and in the double ended case there
> are 8 RC values for the same traffic.
> 
> Q.E.D.
> 
> M3UA only provides for point-to-point
> (MTP/SCCP-User to MTP/SCCP-User) which are AS
> (not IPSPs).  Attempting to use n IPSP as a
> "tranfer/relay" node in the middle between
> these ASs it a subject in the disussion of
> whether IPSP STPs are needed.  I though we
> deferred this to extension draft.
> 
> In point-to-point an IPSP needs to represent
> a single signalling end point (with maybe alias
> addresses).  So when there is only one IPSP
> as in your example, there is never a need for
> more than one AS per IPSP and RCs are not
> needed at all.
> 
> Follow?
> 
> --brian
> 
> >
> >     Tolga
> >
> > > -----Original Message-----
> > > From: Dennis Niermann <[email-masked]> On Behalf Of Dennis
> > > Niermann <exudpn
> > > Sent: Thursday, November 01, 2001 1:04 PM
> > > To: "sigtran" <sigtran
> > > Subject: Re: [Fwd: Re: IPSP proposed text (1st approach)]]
> > >
> > >
> > > Hi Brian,
> > >
> > > I think we used different interpretations
> > > for the meaning of column "L->R".
> > > I interpretted it to mean "the RC used to
> > > address the remote AS". You must have meant it
> > > to mean "the RC used to refer to the local AS"
> > > My intention was to use the following mapping
> > > of AS to RC:
> > >   AS200 = 1
> > >   AS201 = 2
> > >   AS100:3 = 3
> > >   AS100:4 = 4
> > >   AS100:5 = 5
> > > So, if I change the two double ended column labels
> > > to match your meaning, the table would be like this.
> > > >
> > > > >
> > > > >                                       RC Values
> > > > >                                  ==========    ======
> > > > >                                    Double      Single
> > > > >      IPSP/    Remote    Local      Ended        Ended
> > > > >       Assoc     AS       AS      L->R  R-L     L<->R
> > > > >      -------  -------   -----    ----  ----     -----
> > > > >         1      100:4     200      1     4         1
> > > > >         1      100:4     201      2     4         2
> > > > >         1      100:3     200      1     3         3
> > > > >         1      100:3     201      2     3         4
> > > > >         2      100:3     200      1     3         1
> > > > >         2      100:3     201      2     3         2
> > > > >         2      100:5     200      1     5         3
> > > > >         2      100:5     201      2     5         4
> > > >
> > >
> > > Plus, see my comments below.
> > >
> > >
> > > "Brian F. G. Bidulock" wrote:
> > > >
> > > > Dennis,
> > > >
> > > > Please see comments below....
> > > >
> > > > Dennis Niermann wrote:
> > > (Thu, 01 Nov 2001
> > > 07:57:57)
> > > > > Hi Brian,
> > > > > Your example of RC value assignments was a
> > > > > very clear explanation of how you see things.
> > > > > So, in that sense it helped a lot. Thanks.
> > > > >
> > > > > But, I have two points.
> > > > >
> > > > > First, I think that the RC values given for the double
> > > > > ended case are not accurate. I believe that in the double
> > > > > ended case there would always be a particular RC value used for a
> > > > > particular AS (1-1 mapping from AS to RC) and so then values
> > > > > would be as such:
> > > >
> > > > I said it was one example.
> > > >
> > > > >
> > > > >                                       RC Values
> > > > >                                  ==========    ======
> > > > >                                    Double      Single
> > > > >      IPSP/    Remote    Local      Ended        Ended
> > > > >       Assoc     AS       AS      R->L  L->R     L<->R
> > > > >      -------  -------   -----    ----  ----     -----
> > > > >         1      100:4     200      1     4         1
> > > > >         1      100:4     201      2     4         2
> > > > >         1      100:3     200      1     3         3
> > > > >         1      100:3     201      2     3         4
> > > > >         2      100:3     200      1     3         1
> > > > >         2      100:3     201      2     3         2
> > > > >         2      100:5     200      1     5         3
> > > > >         2      100:5     201      2     5         4
> > > > >
> > > >
> > > > This will not work: your table has some glaring
> > > > errors in it.  How does IPSP3 indicate to IPSP1
> > > > that it has inactivated only AS201?
> > > By using RC=2. ("L->R" interpretation issue)
> > > > There needs
> > > > to be separate L->R RC values for AS200 and
> > > > AS201.  Also, (your own question), how does
> > > > IPSP1 indicate the inactivity of just AS100:3?
> > > By using RC=3. Another label interpretatin issue.
> > >
> > > > You have assigned the same R->L RC value to both
> > > > AS100:3 and AS100:4 for IPSP1 on Association 1.
> > > > Only 1 RC value is communicated in ASPAC, not a
> > > > pairing.
> > > Yet another label interpretatin issue. AS100:3 has RC=3,
> > > AS100:4 has RC=4.
> > >
> > > >
> > > > >
> > > > > Second, I do not believe that the single ended case
> > > > > has half the RC values to keep track of.
> > > >
> > > > My table shows the ASP keeping track of two
> > > > values per AS (this is the minimum).  Worst
> > > > case, there will be two "values" per AS per
> > > > association.  It looks like you want to number
> > > > them so that, in your example, the ASP has to
> > > > keep track of 4 values per AS (one for the local
> > > > AS and 3 for the remotes for each AS) per
> > > > assocation.  It does not change the fact that in
> > > > the SG/AS case, the ASP only need track 1 RC
> > > > value per AS per association, nor the fact that
> > > > single-ended is both consistent with the SG/AS
> > > > approach, as well as being sufficient in this
> > > > regard.
> > > >
> > > > > In terms of
> > > > > "values" the single ended case uses from 1-4 and the
> > > > > double ended case uses from 1-5.
> > > >
> > > > You have not shown worst case.  Each
> > > > registration could yield a different value.
> > > > (And your table is full of errors.)
> > > >
> > > > > But, that is not
> > > > > important. What is important if the number of "meanings"
> > > > > of RC values to keep track of.  In the double ended case
> > > > > there is 5 (same as the total number of ASs).
> > > >
> > > > No, at IPSP3 there are 8 traffic flows as listed
> > > > in the table.  In double ended, those 8 traffic
> > > > flows require 2 RCs to be maintained per flow for a
> > > > worst case situation of 16 RC values.  For
> > > > single ended 1 RC per flow for a worst case of 8
> > > > RC values.  Get your table correct first and
> > > > then count 'em for the worst case (different RC
> > > > returned on each association for each
> > > > registration in each direction.)
> > > >
> > > > > Whereas in
> > > > > the single ended case there is 8.
> > > >
> > > > Well, you got one figure right.  Worst case 8.
> > > >
> > > > >This is because in the
> > > > > single case an RC has meaning only in the context of a
> > > > > particular association (the second RC 1 is unrelated
> > > > > to the first RC 1).
> > > >
> > > > This might be your oversight that caused you to
> > > > place errors in your table.  It is no different
> > > > for the double ended case.  In the double ended
> > > > case, each RC is just assigned per direction,
> > > > and twice the values can occur.
> > >
> > > I think that this is the fundamental issue.
> > > And the source of the different perspectives.
> > >
> > > In the case of static configurations there is no need
> > > to use more than one RC per AS (not one per AS per association
> > > as you would have it). It may be possible, but not necessary.
> > > And I believe that it is very unadviceable due to the extra
> > > complexity that it would bring. Plus, the document clearly gives
> > > examples and suggestions (not MUSTs) of having a unique
> > > RC per RK (AS) at an SG.
> > >
> > > Even in the case of dynamic registration there is an implication
> > > that at an SG that a RC would have a unique meaning for the node
> > > (refer to a single RK). There would be no reason to have the RC
> > > allocated by the SG and returned to the ASP unless it had
> > > significance beyond a single association. (The ASP knows as well
> > > as the SGP what RCs are in use on that one association).
> > > Of course, the ASP does have to handle the case that a different
> > > RC used for its local AS for each SG that it has an association
> > > with, that is a disadvantage of dynamic registration.
> > >
> > > If you prefer dynamic configurations, how would the REG REQ and
> > > REG RSP look for the single ended case? It seems like you need
> > > both the local and the remote AS information to unique identify
> > > a RC.
> > >
> > >
> > > >
> > > > >
> > > > > At a given node, in the double ended case the number of
> > > > > RCs to keep track of equals the number of ASs in the entire
> > > > > network (known at that node).
> > > >
> > > > This is not even true for the best case.  The
> > > > best case is better as we have already
> > > > discussed: no RCs.  If your IPSPs would
> > > > communicate with each other and support the same
> > > > ASs as their peers, no RCs are required in
> > > > either case.
> > > >
> > > > > Whereas in the single ended
> > > > > case the number of RCs to keep track of is equal to the
> > > > > number of associations times the number of ASs per association.
> > > > > one particular node).
> > > >
> > > > No, your assertion is false here.  We have
> > > > already presented cases where no RCs are
> > > > required for either single-ended or
> > > > double-eneded.  Go back in the mail thread.
> > > >
> > > > > So, if we were to extend the example to include the
> > > > > associations for IPSP4,
> > > > > the double ended would have exactly 6 RCs with unique
> > > > > meanings and single ended would have 16 RCs with unique
> > > > > meanings.
> > > >
> > > > Not with correct tables....  Try filling them
> > > > out again after answering your own questions.
> > > >
> > > > --brian
> > > >
> > > > >
> > > > > Regards,  Dennis
> > > > >
> > > > >
> > > > >
> > > > > "Brian F. G. Bidulock" wrote:
> > > > > >
> > > > > > Dennis,
> > > > > >
> > > > > > Your example does not highlight any differences
> > > > > > between the single-ended and double-ended approaches.
> > > > > >
> > > > > >       +------+                                  +------+
> > > > > >       |      |                                  |      |
> > > > > >       | AS   |                                  | AS   |
> > > > > >       | 100:4|                                  | 201  |
> > > > > >       |      | \                              / |      |
> > > > > >       +------+   \  +-----+   IP   +-----+  /   +------+
> > > > > >                    /       \------/       \
> > > > > >       +------+     | IPSP1 |      | IPSP3 |     +------+
> > > > > >       |      +- - -\       /-+   /\       /- - -+      |
> > > > > >       | AS   |      +-----+   \ /  +-----+      | AS   |
> > > > > >       | 100:3|                 \                | 200  |
> > > > > >       |      |      +-----+   / \  +-----+      |      |
> > > > > >       |      +- - -/       \-+   \/       \- - -+      |
> > > > > >       +------+     | IPSP2 |      | IPSP4 |     +------+
> > > > > >                    \       /------\       /
> > > > > >       +------+   /  +---- +        +-----+  \   +------+
> > > > > >       |      | /                              \ |      |
> > > > > >       | AS   |                                  | AS   |
> > > > > >       | 100:5|                                  | 202  |
> > > > > >       |      |                                  |      |
> > > > > >       +------+                                  +------+
> > > > > >
> > > > > > Consider example RC assignment for both the
> > > > > > single-ended and double ended cases at IPSP3
> > > > > > in the following table:
> > > > > >
> > > > > >                                      RC Values
> > > > > >                                 ==========    ======
> > > > > >                                   Double      Single
> > > > > >     IPSP/    Remote    Local      Ended        Ended
> > > > > >      Assoc     AS       AS      R->L  L->R     L<->R
> > > > > >     -------  -------   -----    ----  ----     -----
> > > > > >        1      100:4     200      4     1         1
> > > > > >        1      100:4     201      3     2         2
> > > > > >        1      100:3     200      2     3         3
> > > > > >        1      100:3     201      1     4         4
> > > > > >        2      100:3     200      4     1         1
> > > > > >        2      100:3     201      3     2         2
> > > > > >        2      100:5     200      2     3         3
> > > > > >        2      100:5     201      1     4         4
> > > > > >
> > > > > > As you can see, the same AS pairings occur for both
> > > > > > cases.  With the single-ended approach, IPSP3 has half
> > > > > > the RC values to keep track of.  That's it.
> > > > > >
> > > > > > When IPSP1 loses activation of AS100:3 in the double-
> > > > > > ended case it would send ASPIA RC=4 (from the table)
> > > > > > to IPSP3.  If IPSP3 loses activation of AS200 it would
> > > > > > send ASPIA (RC=1,3) to IPSP1.
> > > > > >
> > > > > > When IPSP1 loses activation of AS100:3 in the single-
> > > > > > ended case it would send ASPIA RC=1 (from the table)
> > > > > > to IPSP3.  If IPSP3 loses activation of AS200 it would
> > > > > > send ASPIA (RC=1,3) to IPSP1.
> > > > > >
> > > > > > The same information is conferred, but in the single-
> > > > > > ended case you need half the RC values and do not have
> > > > > > to worry about half-duplex relationships between AS.
> > > > > >
> > > > > > Does this make things perfectly clear to you?
> > > > > >
> > > > > > There is absolutely no point in a double-ended
> > > > > > procedure.  Double-ended procedures add overhead and
> > > > > > complexity where not required.
> > > > > >
> > > > > > --brian
> > > > > >
> > > > > > Dennis Niermann wrote:
> > >    (Wed, 31 Oct
> > > 2001 10:11:03)
> > > > > > >
> > > > > > > Brian,
> > > > > > >
> > > > > > > I don't think that what you suggest is workable.
> > > > > > > If one RC value is used that identifies both
> > > > > > > ASs in a pair then problems arise.
> > > > > > >
> > > > > > > If IPSP1 sends an ASPIA to IPSP3 using RC=3 to
> > > > > > > indicate that it is no longer serving AS100:3,
> > > > > > > which of the ASs that IPSP3 is serving need to
> > > > > > > also use RC3 on that association?
> > > > > > > Both AS200 and AS201?
> > > > > > > Or, just one of them?
> > > > > > > If both AS200 and AS201 use RC3 then there is no way
> > > > > > > distinguish between them.
> > > > > > > If just one of them use RC3, then it breaks your rule
> > > > > > > that the same RC value should be used by the ASs on
> > > > > > > each side of the association.
> > > > > > >
> > > > > > > /Dennis
> > > > > > >
> > > > > >
> > > > > > --
> > > > > > 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]
> > >
> > > --
> > > ---------------------------------------------------------------
> > >  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]
> >
> >
> >
> >
> > ---
> > 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]

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