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

From: "PELLAN,HERVE (HP-France,ex1)" <[email-masked]>
Date: Thu, 19 Dec 2002 09:28:52 +0100

Hi Brian,

> -----Original Message-----
> From: Brian F. G. Bidulock [mailto:[email-masked]]
> Sent: Wednesday, December 18, 2002 3:23 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 14:14:23)
> > 
> > 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".
> > 
> 

.....

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

....

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

....

You are completely right. My configuration was incorrect. The correct one
is:

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

There must be one RK for each local AS to allow per AS management.
But by asymetric, I just meant RKA12 does not have to embed remote PC (PC
for IPSP-B or IPSP-C)
So, adding another remote AS with ISUP (IPSP-D) would not modify or add RK
at IPSP-A.

                                        PC=4

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

If AS-B comes inactive, then IPSP-A internal routing table will be updated
and a MTP-PAUSE
will be generated for PC=2 at AS-A ISUP (and AS-A SCCP also possibly). This
will not affect
ISUP traffic to PC=4 nor AS-A SCCP.

Would SCCP be present at IPSP B, after the ASPIA sent by IPSP-D for ISUP, an
UPU would have been
generated for PC=2 at AS-A ISUP instead of MTP-PAUSE in the previous
scenario.

Herve

_______________________________________________
Sigtran mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/sigtran

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 19 Dec 2002 02:26:49 -0700

Herve,

PELLAN,HERVE (HP-France,ex1) wrote:          (Thu, 19 Dec 2002 09:28:52)
> You are completely right. My configuration was incorrect. The correct one

Again you have the routing keys listed beside the wrong IPSPs,
RKA1 is located at IPSP-B, RKA2 is located at IPSP-C, and both
RKB and RKC are located at IPSP-A.

> So, adding another remote AS with ISUP (IPSP-D) would not modify or add RK

You changed my example: my example was moving from this:

             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

to this:

             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

In the original example you are still faced with disrupting ISUP
traffic between IPSP-A and IPSP-C to add SCCP on IPSP-D and IPSP-C.
When you use RKs of same granularity, there is no problem.

--brian

-- 
Brian F. G. Bidulock
[email-masked]
http://www.openss7.org/