Subject: RE: [Sigtran] IPSP vs AS (was RE: sg-sg communication)

From: "Javier Pastor-Balbas (ECE)" <[email-masked]>
Date: Fri, 31 May 2002 16:46:46 +0200

Brian, 

You'll need to define a new parameter to include two OPC/DPCs in your explanation of SE. It seems that SE have some privileges in nere... Why don't you do the same for DE? In any case it is not compatible with the current RFC: just one OPC or/and DPC per RK.

Cheers // Javier.

> -----Original Message-----
> From: Brian F. G. Bidulock [mailto:[email-masked]]
> Sent: Friday, May 31, 2002 4:37 PM
> To: Javier Pastor-Balbas (ECE)
> Cc: Tolga Asveren; [email-masked]
> Subject: Re: [Sigtran] IPSP vs AS (was RE: sg-sg communication)
> Importance: High
> 
> 
> Javier,
> 
> No, if you want to start wildcarding, for SE you dont even need an
> RC value at all (because the point-to-point relation is implied by
> the asssociation).  Therefore the routing key is implied (there is
> only 1 RK for SE when wildcarding).  When comparing wildcarding,
> you have:
> 	
> DE: Four strange reverse routing keys:
> 
> DE IPSP1	RK1: OPC=1-1-1 DPC=*-*-*
>         	RK2: OPC=2-2-2 DPC=*-*-*
>    IPSP2	RK3: OPC=3-3-3 DPC=*-*-*
>         	RK4: OPC=4-4-4 DPC=*-*-*
> 
> SE: One implied routing key
> 
> SE IPSP1        RK1: OPC=1-1-1, 2-2-2 DPC=3-3-3, 4-4-4
>    IPSP2        RK1: OPC=3-3-3, 4-4-4 DPC=1-1-1, 2-2-4
> 
> Voila.  SE still has half the routing keys of DE.  Gee, would
> that be what "single" and "double" implies? ;)
> 
> 
> --brian
> 
> 
> Javier Pastor-Balbas (ECE) wrote:               (Fri, 31 May 
> 2002 16:17:59)
> > Hi Tolga/Brian, 
> > 
> > The Tolga's approach for RKs is the good one because you 
> don't need to
> > include OPC in the DE. The problem comes up in the SE; as 
> you only have one
> > exchange you need to include both routing parameters: origin and
> > destination. SE does not work with oranges, only with 
> apples while DE allow
> > both, but oranges are cheaper. I mentioned in one mail that 
> for n IPSPs per
> > AS, in SE you have n*n RKs and 2n in DE. What depending on 
> the number n
> > means that one or the other approach can be considered as 
> having less RKs.
> > 
> > As you didn't comment anything on my extended-explanation 
> of AS vs IPSP,
> > should I consider that you accept it? It is nothing 
> mentioned there about
> > physicallity of AS...  I also showed there a simpler model for AS
> > realization that is valid for both AS-AS and AS-SG. There 
> you can see that
> > the complication of SGPF+ASPF is definitely not needed.
> > 
> > Cheers // Javier.
> > 
> > 
> > > -----Original Message-----
> > > From: Brian F. G. Bidulock [mailto:[email-masked]]
> > > Sent: Friday, May 31, 2002 4:04 PM
> > > To: Tolga Asveren
> > > Cc: [email-masked]
> > > Subject: Re: [Sigtran] IPSP vs AS (was RE: sg-sg communication)
> > > Importance: High
> > > 
> > > 
> > > Tolga,
> > > 
> > > Your mis-counting routing keys for the DE case again.  There 
> > > is no reason
> > > to use wildcarded RKs for the DE example and non-wildcarded 
> > > RKs for the
> > > SE example.  In fact, as IPSP is point to point and 
> > > statically provisioned,
> > > DE has 8 routing keys:
> > > 
> > > At IPSP1          RK1: OPC=1-1-1 DPC=3-3-3
> > >                   RK2: OPC=1-1-1 DPC=4-4-4
> > >                   RK2: OPC=2-2-2 DPC=3-3-3
> > >                   RK2: OPC=2-2-2 DPC=4-4-4
> > > 
> > > At IPSP2          RK1: OPC=3-3-3 DPC=1-1-1
> > >                   RK2: OPC=3-3-3 DPC=2-2-2
> > >                   RK2: OPC=4-4-4 DPC=1-1-1
> > >                   RK2: OPC=4-4-4 DPC=2-2-2
> > > 
> > > When you compare apples to apples (instead of oranges) DE 
> > > always has twice
> > > the number of RKs (and RC values) as SE.
> > > 
> > > Thus the waste.
> > > 
> > > --brian
> > > 
> > > Tolga Asveren wrote:                             (Fri, 31 May 
> > > 2002 09:32:08)
> > > > Javier,
> > > > 
> > > > 
> > > > You can have your view that AS corresponds to something 
> > > physical, for me it
> > > > is just a traffic range. In the past, there were a lot of 
> > > comments saying
> > > > that definition of AS in M3UA draft is misleading because 
> > > it might give the
> > > > impression that it is something physical. In my view, it is 
> > > strange to think
> > > > that AS is talking to SG. Peer of an AS can be only another 
> > > AS or a layer4
> > > > entity(ISUP/SCCP) in SS7 domain (in fact one call call them 
> > > also AS in the
> > > > context of this discussion) ASP just serves AS and 
> > > transfers a specific
> > > > traffic range.
> > > > 
> > > > > > There is a
> > > > > > huge difference between those two approaches. Basically this
> > > > > > is the main
> > > > > > difference between "double-ended" and "single-ended"
> > > > > > approaches, it is not
> > > > > > just whetehr ASPUP (or ASPAC) is sent from one side or 
> > > from two sides.
> > > > >
> > > > > How can AS-AS vs ASP-ASP explain the difference between 
> > > SE and DE? :-/.
> > > > [TOLGA] Double ended approach : ASP-ASP
> > > > There are local and remote RKs. A RK defines a traffic 
> > > range just on one end
> > > > 
> > > >  AS1: DPC=1-1-1              AS3: DPC=3-3-3
> > > >  AS2: DPC=2-2-2              AS4: DPC=4-4-4
> > > >  +---------+                 +---------+
> > > >  |         |                 |         |
> > > >  |         |                 |         |
> > > >  |IPSP1    |                 |         |
> > > >  |         +-----------------+IPSP2    |
> > > >  |         |                 |         |
> > > >  |         |                 |         |
> > > >  +---------+                 +---------+
> > > > There will be 4 RKs. RK1: DPC=1-1-1 local to IPSP1 and 
> > > remote to IPSP2
> > > >                      RK2: DPC=2-2-2 local to IPSP1 and 
> > > remote to IPSP2
> > > >                      RK3: DPC=3-3-3 local to IPSP2 and 
> > > remote to IPSP1
> > > >                      RK4: DPC=4-4-4 local to IPSP2 and 
> > > remote to IPSP1
> > > >                      (Those 4 RKs will be defined at both 
> > > of the IPSPs)
> > > > In this approach, it is obvious that 2 ASPACs are necessary 
> > > (and not to
> > > > break symmetry 2 ASPUPs are also making sense, which will 
> > > enable to model
> > > > this as SGPF+ASPF) Because for RK1/RK2 IPSP1 behaves like 
> > > ASP and IPSP2
> > > > behaves like SGP and for RK3/RK4 it is the opposite. That 
> > > is the reason, why
> > > > I am saying, this is nothing else than SGPF+ASPF. One of 
> > > course does not
> > > > need the MTP3 related interworking etc... of SGPs, but 
> > > those are not part of
> > > > the protocol. The protocol defines just the state machines 
> > > and messaging
> > > > between M3UA entities.
> > > > 
> > > > Single-ended approach: AS-AS
> > > > There is only one type of RK (unlike ASP-ASP case where we 
> > > have local and
> > > > remote RKs). A RK defines a traffic range in both ends.
> > > > There will be 8 RKs: RKs at IPSP1
> > > >                      RK1: DPC=1-1-1 OPC=3-3-3
> > > >                      RK2: DPC=1-1-1 OPC=4-4-4
> > > >                      RK3: DPC=2-2-2 OPC=3-3-3
> > > >                      RK4: DPC=2-2-2 OPC=4-4-4
> > > > 
> > > >                      RKs at IPSP2
> > > >                      RK5: DPC=3-3-3 OPC=1-1-1
> > > >                      RK6: DPC=3-3-3 OPC=2-2-2
> > > >                      RK7: DPC=4-4-4 OPC=1-1-1
> > > >                      RK8: DPC=4-4-4 OPC=2-2-2
> > > > 
> > > > (In fact one can think that there are only 4 RKs, because 
> > > RK1/RK5, RK2/RK6,
> > > > RK3/RK7, RK4/RK8 are symmetrical)
> > > > With this approach, one ASPAC is enough to activate the 
> > > traffic in both
> > > > directions. Probably, it makes sense to give the same RC 
> > > values to symmetric
> > > > RKs at both IPSP.
> > > > 
> > > > 
> > > > _______________________________________________
> > > > Sigtran mailing list
> > > > [email-masked]
> > > > https://www1.ietf.org/mailman/listinfo/sigtran
> > > 
> > > -- 
> > > Brian F. G. Bidulock
> > > [email-masked]
> > > http://www.openss7.org/
> > > 
> > > _______________________________________________
> > > Sigtran mailing list
> > > [email-masked]
> > > https://www1.ietf.org/mailman/listinfo/sigtran
> > > 
> 
> -- 
> 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: Fri, 31 May 2002 10:12:29 -0500

Javier,

Section 3.6.1 Registration Request (REG REQ)

"Note: The Destination Point Code, Service Indicators, Originating Point
Code List and Circui Range List parameters MAY be repeated as a grouping
within the Routing Key parameter, in the structure shown above."

--brian

Javier Pastor-Balbas (ECE) wrote:               (Fri, 31 May 2002 16:46:46)
> Brian, 
> 
> You'll need to define a new parameter to include two OPC/DPCs in your
> explanation of SE. It seems that SE have some privileges in nere... Why
> don't you do the same for DE? In any case it is not compatible with the
> current RFC: just one OPC or/and DPC per RK.
> 
> Cheers // Javier.

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 31 May 2002 10:06:57 -0500

Javier,

> explanation of SE.

Check the RFC: we included multple OPCs some time ago even for dynamic
registration (which is not required in this case because the RK is implied).

> It seems that SE have some privileges in nere... Why

Check again.  We allowed multiple OPC and multiple DPC some time ago
for dynamic registration, and it is certainly not forbidden for static.

--brian

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