Subject: RE: [Sigtran] IPSP double exchange mode of operation

From: "PELLAN,HERVE (HP-France,ex1)" <[email-masked]>
Date: Wed, 18 Dec 2002 14:14:23 +0100

Brian,

see my comments inline:

> -----Original Message-----
> From: Brian F. G. Bidulock [mailto:[email-masked]]
> Sent: Wednesday, December 18, 2002 12:56 PM
> To: PELLAN,HERVE (HP-France,ex1)
> Cc: [email-masked]'; Javier Pastor-Balbas (ECE);
> [email-masked]
> Subject: Re: [Sigtran] IPSP double exchange mode of operation
> 
> 
> Herve,
> 
> PELLAN,HERVE (HP-France,ex1) wrote:                           
>                 (Wed, 18 Dec 2002 12:27:27)
> > Hi Sandeep and Brian,
> > 
> > Leaving the RFC as it is is OK for us. 
> > 
> > However, to benefit from people experience on IPSP, I think 
> this would be
> > valuable to add a few comments (in section 4.4.3 ?) on 
> where one might
> > better adapted than the other. All the discussions were 
> about this aspect.
> > The purpose is here not to give rules. The exact text is to 
> be defined but
> > basically the main lines are:
> 
> Clarifications are fine, but there are some problems with the 
> following:
> 
> > 
> > - Single exchange: RK basically consist of <OPC,DPC> i.e. 
> symetric RK.
> 
> All RKs (MTP-SAP bindings) are symmetrical in SS7.  OPC/DPC/SI, even
> OPC/DPC/SI=5/CIC (ISUP binding) is symmetrical in SS7.
> 
> In fact, it would be better to say that in DE all RKs must be made
> symmetrical and must be registered in symmetrical pairs, otherwise
> user parts will be unable to perform their functions.
> 
> > - Dynamic Registration, when used on both end, requires 
> double exchange. 
> 
> Write it the other way: when dynamic registration is used in SE, one
> side should statically configure the routing key and the 
> other dynamically
> register (gee, sounds like the definition of SE).
> 
> > - Double exchange: may provide additional flexibility when 
> several AS are
> > located on one peer while corresponding remote AS are 
> spreaded on several
> > ones. Generally speaking, DE is more appropriate with 
> dissymetric RK as OPC
> > may not have to be specified.
> 
> All SS7 RKs are symmetrical: even "PC to anywhere" is 
> symmetrical to "anywhere
> to PC".  Can you provide an example of where an MTP User 
> needs a truly 
> asymmetrical routing key?
> 

In the substance you are right. But as defined in the RFC, and especially
for the ASP (See 1.4.2.1 a the end of section: "At an ASP, the Routing
Context parameter uniquely identifies the range of signalling traffic
associated with each Application Server that the ASP is configured to
received"), the RK appears to be focused on the inbound traffic to the AS.
In our implementation on the ASP/IPSP, we have clearly separated this
inbound filter defined by the M3UA RK, and what we use to route the outbound
traffic. 

This split of inbound/outbound filtering/distribution appears more obvious
when looking at the dynamic registration in DE in the following
configuration:

                                        PC=2
        +---------+                  +-----------+
ISUP ---|         |------------------| IPSP B    |--- ISUP
SCCP----| IPSP-A  |-------+          +-----------+
        +---------+       |          +-----------+
           PC=1           +----------| IPSP C    |--- SCCP
                                     +-----------+
                                        PC=3
RKA = <PC=1>
                                       RKB= <PC=2,ISUP>
                                       RKC= <PC=3,SCCP>

So, basically the RK send through REG REQ/or configured statically tells the
other end: "send me anything that relates to my RK". The registration
(static or dynamic) of the remote end will configure the routes to the
remote AS.

We would have done that differently with SE, where we would have configured
two RK1=<PC1,PC2,ISUP> and RK2=<PC1,PC3,SCCP>.

I hope this would have clarified what I was meaning by "symetric RK" and
"asymetric RK".

Herve

> --brian
> -- 
> Brian F. G. Bidulock
> [email-masked]
> http://www.openss7.org/
_______________________________________________
Sigtran mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/sigtran

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 18 Dec 2002 07:23:29 -0700

Herve,

PELLAN,HERVE (HP-France,ex1) wrote:                                           (Wed, 18 Dec 2002 14:14:23)
> when looking at the dynamic registration in DE in the following

Unfortunately it does not.  Your diagram appears incorrect.  A
routing key is used for outbound traffic.  Therefore, IPSP-A
must hold RKB and RKC, and IPSP-B must hold RKA and IPSP-C must
hold RKA as well.  This is 4 routing keys as is necessary for DE
with two traffic flows.  So, rediagramming (if there is such a
word):

             RKB=<PC=2,ISUP> RKA=<PC=1>   PC=2
          +---------+                  +-----------+
  ISUP ---|         |------------------| IPSP B    |--- ISUP
  SCCP----| IPSP-A  |-------+          +-----------+
          +---------+       |          +-----------+
             PC=1           +----------| IPSP C    |--- SCCP
                                       +-----------+
             RKC=<PC=3,SCCP> RKD=<PC=1>   PC=3

So,

   IPSP-A uses RKB to route ISUP traffic to IPSP-B.
   IPSP-A uses RKC to route SCCP traffic to IPSP-C.
   IPSP-B uses RKA to route ISUP traffic to IPSP-A.
   IPSP-C uses RKD to route SCCP traffic to IPSP-A.

When you register:

   IPSP-A registers RKA=<PC=1> with IPSP-B.
   IPSP-A registers RKD=<PC=1> with IPSP-C.
   IPSP-B registers RKB=<PC=2,ISUP> with IPSP-A.
   IPSP-C registere RKC=<PC=2,SCCP> with IPSP-A.

This is natural: DE takes twice as many RKs and twice as many RCs as SE.

SE would permit two routing keys as you say:

   <PC=1,PC=2,ISUP> and <PC=1,PC=2,SCCP>

But, notice that IPSP-B never routes anything but ISUP using RKA
and IPSP-C never routes anything but SCCP using RKD, so, there
is no difference between this and having:

  RKA=<PC1,ISUP>
  RKD=<PC1,SCCP>

Also, notice that because IPSP-A never routes anything to IPSP-B
but ISUP and never routes anything to IPSP-A except SCCP, there
is no difference between this and having:

  RKB=<PC2>

and

  RKA=<PC3>

So you traffic flows are symmetrical, you have just chosen your
routing keys to be a superset of the actual flow.

Suppose you add ISUP PC=2 to IPSP-B.  Then you have 5 routing
keys and then I can show you some of the problems with mixed
granularity.

             RKE=<PC=2,SCCP>
             RKB=<PC=2,ISUP> RKA=<PC=1>   PC=2
          +---------+                  +-----------+--- SCCP
  ISUP ---|         |------------------| IPSP B    |--- ISUP
  SCCP----| IPSP-A  |-------+          +-----------+
          +---------+       |          +-----------+
             PC=1           +----------| IPSP C    |--- SCCP
                                       +-----------+
             RKC=<PC=3,SCCP> RKD=<PC=1>   PC=3

Although RKA seems to span both SCCP and ISUP to IPSP-A, in fact
RKE and RKA(SCCP portion) and RKB and RKA (ISUP portion) are
inexhorably tied together.  If one direction of traffic flow
stops, the other must as well or the user parts will break.

So, IPSP-B must know that it cannot activate AS-B or AS-E until
AS-A has been activated with it.  This makes the state of two
AS's at IPSP-B dependent on the state of one AS at IPSP-A.  If
you start mixing CIC ranges into this it will become quite
complicated.

All in all, mixing granularities of routing keys for IPSPs is a
stylistic difference and not a functional one.  RKA still only
routes ISUP traffic for AS-B and only routes SCCP traffic for
AS-E.

Mixing granularities can become difficult to manage in a live
network as well.  Consider moving between these two network
configurations:

             RKB=<PC=2,ISUP> RKA=<PC=1>   PC=2
          +---------+                  +-----------+
  ISUP ---|         |------------------| IPSP B    |--- ISUP
          | IPSP-A  |-------+          +-----------+
          +---------+       |          +-----------+
             PC=1           +----------| IPSP C    |--- ISUP
                                       +-----------+
             RKC=<PC=3,ISUP> RKD=<PC=1>   PC=3

             RKB=<PC=2,ISUP> RKA=<PC=1>   PC=2
          +---------+                  +-----------+
  ISUP ---|         |------------------| IPSP B    |--- ISUP
          | IPSP-A  |-------+          +-----------+
          +---------+       |          +-----------+
             PC=1           +----------| IPSP C    |--- ISUP
                            +----------+-----------+--- SCCP
             RKC=<PC=3,ISUP>|RKD=<PC=1>   PC=3
          +---------+       |
  SCCP ---|         |-------+
          | IPSP-D  |
          +---------+
             PC=1

It is not possible for me to add in SCCP on IPSP-D and SCCP on
IPSP C without breaking out RKD and disrupting traffic.  For a
smooth path to reconfigure the network, one would have been
better to start with RKD=<PC1,ISUP> rather than the stylistic
RKD=<PC1>.

For single-ended, not only are there fewer routing keys and
there is not need to keep track of half-flows, but this smooth
upgrade is ensured because traffic flows are treated as
symmetric (which is what they are to MTP-Users).  For the above
example:

      RK1=<PC=1,PC=2,ISUP> between IPSP-A and IPSP-B
      RK2=<PC=1,PC=3,ISUP> between IPSP-A and IPSP-C

can be expanded by simply adding:

      RK2=<PC=1,PC=3,SCCP> between IPSP-D and IPSP-C

So, I would say that SE doesn't let you fool yourself into
thinking that traffic flows can be defined in an asymmetric
fashion while retaining any flexibility in network
configuration.  This is what I meant that it would be wise to
put a note in the IG saying that DE IPSPs that dynamically
register must register, activate and deactivate their
symmetrical keys and ASs together: otherwise, the user parts
will break.

In this diagram,

             RKE=<PC=2,SCCP>
             RKB=<PC=2,ISUP> RKA=<PC=1>   PC=2
          +---------+                  +-----------+--- SCCP
  ISUP ---|         |------------------| IPSP B    |--- ISUP
  SCCP----| IPSP-A  |-------+          +-----------+
          +---------+       |          +-----------+
             PC=1           +----------| IPSP C    |--- SCCP
                                       +-----------+
             RKC=<PC=3,SCCP> RKD=<PC=1>   PC=3

IPSP-A must know that if AS-B is down or inactive, that it
cannot accept ISUP traffic with RC-A and must return DUPU for
it, otherwise the ISUP user parts will break on both IPSP-A and
IPSP-B.  (Note that an MTP-User cannot send MTP-STATUS, only
receive it).  Knowing when to resplit user part traffic arriving
on RC-A at IPSP-A is far from trivial.  Also, IPSP-A would have
to perform this splitting and DUPU function throughout all the
partial stages of registration and activation and across
failures.  IPSP-A would have been better to register one RK for
ISUP and another for SCCP just so that this respitting traffic
and merging of AS state would not be necessary as IPSP-B would
label these two traffic flows already with two different RC
values (RC-A(ISUP) and RC-A(SCCP)) and there would be separate
AS to register, activate, deactivate, and fail based on separate
RC values as well.

To summarize, I don't see mixing of granularities of routing
keys as terribly useful.  In fact it throws more complexity into
the arrangement with no functional gain.  This was the result
from the last long ladders on the topic: that DE IPSPs should
stick to same-granularity routing keys.

So, there is no real asymmetrical situation, just contrived
ones.  Careful you don't paint yourself in a corner with mixed
granularity DE.

--brian