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

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

Hi Tolga, 

For some time I thought there were practical problems... It is good that we all agree on these terms to talk the same language. And if some of the terms are not well defined, we should clarify them also in the document.  :-)

Cheers // Javier.

> -----Original Message-----
> From: Tolga Asveren [mailto:[email-masked]]
> Sent: Friday, May 31, 2002 4:37 PM
> To: [email-masked]
> Subject: RE: [Sigtran] IPSP vs AS (was RE: sg-sg communication)
> 
> 
> Javier,
> 
> As long as we can reach a consensus on practical issues , I 
> don't think
> there is a need to argue about theory of it -unless it 
> creates a problem on
> practical level- , hence no comments on your "extended 
> explanation" :-) .
> 
>    Tolga
> 
> > -----Original Message-----
> > From: Javier Pastor-Balbas (ECE)
> > [mailto:[email-masked]]
> > Sent: Friday, May 31, 2002 10:18 AM
> > To: [email-masked]'; Tolga Asveren
> > Cc: [email-masked]
> > Subject: RE: [Sigtran] IPSP vs AS (was RE: sg-sg communication)
> >
> >
> > 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
> > >
> 
> 
> _______________________________________________
> Sigtran mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/sigtran
> 

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