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

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

Hi Tolga, 

Let me explain it in more detail...

---------------------o START of extended explanation

AS Definition
--------------

RFC's definition: AS is a logical entity serving a specific Routing Key.

An AS is an M3UA concept. AS is the virtual SS7 application from the M3UA point of view. It is virtual because it is not the SS7 application itself. It is the M3UA part that is used as the layer below the SS7 application. And it is the interface the SS7 aplication uses to send/receive messages. It's virtual because it does not physically exist (not real). But one ASP exists as minimum that implements physically the AS concept. An ASP is the AS physical realization. 

It is the virtual access point of an SS7 application that is seen in the IP domain from a remote node. 

From the point of view of an SS7 application in the IP domain, AS is an abstraction. A particular application node can see the remote application which it wants to talk to, as a whole, independently of how it is implemented. The representation of this whole is an AS, and each physical node represents that AS. In that sense every ASP represents an AS. An AS is addressed by means of a RK , i.e. a set of parameters, which is a traffic range at the same time. It doesn't matter how it is implemented at this level.

AS physical realization
-----------------------

1. An AS can be physically implemented as an ASP. And ASP serves one RK, what basically means that is handling a traffic range. ASP implements the needed functions to make possible the communication of an AS with the another SS7 application thru a SG.
 
2. But an AS can also be physically implemented as an IPSP. You can say that an IPSP also serves on RK, what basically means that it handles a traffic range. AN operative example is the case where the IPSP serves a complete SPC. The SS7 application on top of it is hadling all the traffic for that SPC. IPSP implements the needed functions to make possible the communication of an AS with another AS. Of course that the AS should be implemented by means of at least one IPSP. An IPSP is by definition, basically an ASP. 

3. What about an AS that wants to talk to an SG but also to another AS? Then the AS should be implemented like a mixture of an ASP and an IPSP. In this way it has all the capabilities needed to talk in both ways..

                               +-----------------------+
               M3UA            |                       |
               Layer:          | Functions common to   |
               ASP/IPSP        |                       |
               implementation  |       ASP/IPSP        |
                               |                       |
                               |-----------+-----------|
                               |   ASP     |   IPSP    |
                               | Specific  |  Specific |
                               |  Funcs.   |   Funcs.  |
                               +-----------+-----------+

The implementation of an AS that can talk with either another AS or an SG is as shown above. It can be seen as an extension of an ASP to include the case of point to point communication, also called IPSP communication.

-------------o END of extended explanation

Although I think this explains your doubts, you can see below the comments on yours...

Cheers // Javier.

> -----Original Message-----
> From: Tolga Asveren [mailto:[email-masked]]
> Sent: Thursday, May 30, 2002 7:34 PM
> To: [email-masked]
> Subject: RE: [Sigtran] RE: sg-sg communication
> 
> 
> Javier,
> 
> 
> > -----Original Message-----
> > From: Javier Pastor-Balbas (ECE)
> > [mailto:[email-masked]]
> > Sent: Thursday, May 30, 2002 1:13 PM
> > To: 'Tolga Asveren'
> > Subject: RE: [Sigtran] RE: sg-sg communication
> >
> >
> > Tolga,
> >
> > IPSP communication was made to allow that two ASes can talk to
> > each other. If one AS wants to talk to a SG it should use AS-SG
> > communication.
> [TOLGA] You should make up your mind, is IPSP AS-AS or 
> ASP-ASP? 

IPSP communication is about AS-AS. As you can see IPSP as an extension of an ASP, you could say that is communication between two extended-ASPs. But at this time, I think is better not to mix concepts. So let's call it simply IPSP.

> 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? :-/.

> >
> > BTW. Could you explain me what serving one AS means for you? :-)
> [TOLGA] It means just handling traffic for it, not being a 
> part of it. AS is
> nothing else than a traffic range. If you think it 
> corresponds to something
> physicall, I strongly disagree. On the other hand SG really 
> consist of SGPs,
> and so indirectly corresponds to a physicall entity.

How can you explain then that an example of an AS is a vittual switch element handling all call processing for a unique range of PSTN trunks? Or that an AS can be a virtual database element, handling all HLR transaction for a particular SS7 addressing paramenters combination?

Is the "virtual" word what makes it just a traffic range for you?

Cheers // Javier.

> >
> > Cheers // Javier.
> >
> > > -----Original Message-----
> > > From: Tolga Asveren [mailto:[email-masked]]
> > > Sent: Thursday, May 30, 2002 7:21 PM
> > > To: [email-masked]
> > > Subject: RE: [Sigtran] RE: sg-sg communication
> > >
> > >
> > > Javier,
> > >
> > > AS is not consisting of ASPs (or IPSPs), ASPs are just
> > > serving one or more
> > > AS. It is for sure that AS does not correspond to something
> > > physical but is
> > > just an abstraction. The relationship between AS/ASP and
> > > SG/SGP is not the
> > > same. Anyway, this is not the main discussion. How IPSPs 
> are going to
> > > communicate with SGPs? That is the main question. Because
> > > both of those are
> > > physically existing and are exchanging messages.
> > >
> > >    Tolga
> > >
> > > > -----Original Message-----
> > > > From: Javier Pastor-Balbas (ECE)
> > > > [mailto:[email-masked]]
> > > > Sent: Thursday, May 30, 2002 12:30 PM
> > > > To: 'Tolga Asveren'; [email-masked]
> > > > Subject: RE: [Sigtran] RE: sg-sg communication
> > > >
> > > >
> > > > Hi Tolga,
> > > >
> > > > An AS is basically what you call an SPC (Cosidering SPC
> > > > grnularity) in IP. That SPC can talk to a SG and it can be
> > > > implemented as a set of ASP for redundancy purposes 
> being able of
> > > > being configured following the n+k model defined in the RFC. But
> > > > also that AS can talk with another AS and it can be implemented
> > > > by one or more IPSPs (or ASP with the capability of talking to
> > > > another peer ASP).
> > > >
> > > > An AS has sense and it can be composed of ASPs (when 
> talking with
> > > > SG), IPSPs (Talking with other ASes) or ASP/IPSPs (talking
> > > with both).
> > > >
> > > > And the realisation of an AS is the M3UA peer of another AS or
> > > > SG. For me, it is easier to understand it in the simple case:
> > > > when there is only one ASP per AS and an SGP per SG. The ASP is
> > > > the implementation of the AS. In this case you can see that SG
> > > > (non distributed SG) is talking with an AS (a non distributed
> > > > AS). I would conclude with the example:
> > > >
> > > >  - AS is peer of an SG
> > > >  - SGP is peer of ASP
> > > >
> > > >
> > > > Cheers // Javier.
> > > >
> > > > > -----Original Message-----
> > > > > From: Tolga Asveren [mailto:[email-masked]]
> > > > > Sent: Thursday, May 30, 2002 6:13 PM
> > > > > To: [email-masked]
> > > > > Subject: RE: [Sigtran] RE: sg-sg communication
> > > > >
> > > > >
> > > > > Javier,
> > > > >
> > > > > Because in my opinion they are not peers. SG is consisting of
> > > > > SGPs, but AS
> > > > > is not consisting of ASPs. AS does not correspond to
> > > > > something physical and
> > > > > is a pure abstraction.
> > > > >
> > > > >      Tolga
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Javier Pastor-Balbas (ECE)
> > > > > > [mailto:[email-masked]]
> > > > > > Sent: Thursday, May 30, 2002 11:52 AM
> > > > > > To: 'Tolga Asveren'; [email-masked]
> > > > > > Subject: RE: [Sigtran] RE: sg-sg communication
> > > > > >
> > > > > >
> > > > > > Tolga,
> > > > > >
> > > > > > Why don't you see SG and AS as peers ?? Could you 
> explain more?
> > > > > >
> > > > > > Cheers //Javier.
> > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: Tolga Asveren [mailto:[email-masked]]
> > > > > > > Sent: Thursday, May 30, 2002 6:00 PM
> > > > > > > To: [email-masked]
> > > > > > > Subject: RE: [Sigtran] RE: sg-sg communication
> > > > > > >
> > > > > > >
> > > > > > > Javier,
> > > > > > >
> > > > > > > Then you need to put both IPSP and ASP 
> functionality in your
> > > > > > > node. Isn't
> > > > > > > this against your strategy of having one entity? I also
> > > > > > > strongly disagree to
> > > > > > > see AS and SGs as peers, in my opinion they aren't.
> > > > > > >
> > > > > > >    Tolga
> > > > > > >
> > > > > > > > -----Original Message-----
> > > > > > > > From: Javier Pastor-Balbas (ECE)
> > > > > > > > [mailto:[email-masked]]
> > > > > > > > Sent: Thursday, May 30, 2002 11:39 AM
> > > > > > > > To: 'Tolga Asveren'; [email-masked]
> > > > > > > > Subject: RE: [Sigtran] RE: sg-sg communication
> > > > > > > >
> > > > > > > >
> > > > > > > > Hi Tolga,
> > > > > > > >
> > > > > > > > My understanding is that you have an IP node, what we
> > > > > call AS. An
> > > > > > > > AS can communicate to both: another AS or an SG. If
> > > the AS is
> > > > > > > > communicating to an SG you are using the AS-SG
> > > communication. If
> > > > > > > > the AS is talking to another AS you use the IPSP
> > > > > communication.  :-D
> > > > > > > >
> > > > > > > > Cheers // Javier.
> > > > > > > >
> > > > > > > > > -----Original Message-----
> > > > > > > > > From: Tolga Asveren [mailto:[email-masked]]
> > > > > > > > > Sent: Thursday, May 30, 2002 5:43 PM
> > > > > > > > > To: [email-masked]
> > > > > > > > > Subject: RE: [Sigtran] RE: sg-sg communication
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > Javier,
> > > > > > > > >
> > > > > > > > > For SGPF+ASPF case, we have different 
> opinions because we
> > > > > > > > > have different
> > > > > > > > > understanding of what a protocol should 
> define and what it
> > > > > > > > > shouldn't. But
> > > > > > > > > apart from this, if IPSP can't speak to SGPs as
> > > ASP, it won't
> > > > > > > > > be something
> > > > > > > > > very usefull for the reason Brian pointed out.
> > > > > > > > >
> > > > > > > > >    Tolga
> > > > > > > > >
> > > > > > > > > > -----Original Message-----
> > > > > > > > > > From: Javier Pastor-Balbas (ECE)
> > > > > > > > > > [mailto:[email-masked]]
> > > > > > > > > > Sent: Thursday, May 30, 2002 11:25 AM
> > > > > > > > > > To: 'Tolga Asveren'; [email-masked]
> > > > > > > > > > Subject: RE: [Sigtran] RE: sg-sg communication
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > Hi Tolga,
> > > > > > > > > >
> > > > > > > > > > See below,
> > > > > > > > > >
> > > > > > > > > > > -----Original Message-----
> > > > > > > > > > > From: Tolga Asveren [mailto:[email-masked]]
> > > > > > > > > > > Sent: Thursday, May 30, 2002 5:35 PM
> > > > > > > > > > > To: [email-masked]
> > > > > > > > > > > Subject: RE: [Sigtran] RE: sg-sg communication
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > Hi Javier,
> > > > > > > > > > >
> > > > > > > > > > > > -----Original Message-----
> > > > > > > > > > > > From: Javier Pastor-Balbas (ECE)
> > > > > > > > > > > > [mailto:[email-masked]]
> > > > > > > > > > > > Sent: Thursday, May 30, 2002 11:16 AM
> > > > > > > > > > > > To: 'Tolga Asveren'; [email-masked]'
> > > > > > > > > > > > Subject: RE: [Sigtran] RE: sg-sg communication
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > Hi Tolga,
> > > > > > > > > > > >
> > > > > > > > > > > > Comments below...
> > > > > > > > > > > >
> > > > > > > > > > > > > -----Original Message-----
> > > > > > > > > > > > > From: Tolga Asveren 
> [mailto:[email-masked]]
> > > > > > > > > > > > > Sent: Thursday, May 30, 2002 5:15 PM
> > > > > > > > > > > > > To: [email-masked]
> > > > > > > > > > > > > Subject: RE: [Sigtran] RE: sg-sg communication
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > > Javier,
> > > > > > > > > > > > >
> > > > > > > > > > > > > > -----Original Message-----
> > > > > > > > > > > > > > From: Javier Pastor-Balbas (ECE)
> > > > > > > > > > > > > > 
> [mailto:[email-masked]]
> > > > > > > > > > > > > > Sent: Thursday, May 30, 2002 10:53 AM
> > > > > > > > > > > > > > To: 'Tolga Asveren'; [email-masked]
> > > > > > > > > > > > > > Subject: RE: [Sigtran] RE: sg-sg 
> communication
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Hi Tolga,
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > A small comment on yours...
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > > -----Original Message-----
> > > > > > > > > > > > > > > From: Tolga Asveren
> > > [mailto:[email-masked]]
> > > > > > > > > > > > > > > Sent: Thursday, May 30, 2002 4:56 PM
> > > > > > > > > > > > > > > To: [email-masked]
> > > > > > > > > > > > > > > Subject: [Sigtran] RE: sg-sg communication
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Reshma,
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > -----Original Message-----
> > > > > > > > > > > > > > > > From: reshma
> > > [mailto:[email-masked]]
> > > > > > > > > > > > > > > > Sent: Thursday, May 30, 2002 10:35 AM
> > > > > > > > > > > > > > > > To: Tolga Asveren
> > > > > > > > > > > > > > > > Cc: [email-masked]
> > > > > > > > > > > > > > > > Subject: sg-sg communication
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Hi  Tolga,
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >     Thanks for your reply some more
> > > doubts :-(
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >  [Reshma] Okay now its clear. But
> > > > > how does SG1
> > > > > > > > > > > knows whether
> > > > > > > > > > > > > > > > the data is
> > > > > > > > > > > > > > > > > > from SG2 or from ASPs?
> > > Depending on which he
> > > > > > > > > > > might have to
> > > > > > > > > > > > > > > > act as relay
> > > > > > > > > > > > > > > > > > point or a normal SG?
> > > > > > > > > > > > > > > > > [TOLGA] With the same method, it can
> > > > > > > know, whether a
> > > > > > > > > > > > > message is
> > > > > > > > > > > > > > > > from ASP1
> > > > > > > > > > > > > > > > or
> > > > > > > > > > > > > > > > > ASP2, this is implemention 
> dependent (but
> > > > > > > > > most probably
> > > > > > > > > > > > > > > based on the
> > > > > > > > > > > > > > > > source
> > > > > > > > > > > > > > > > > address of the SCTP message)
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > [Reshma] As per M3UA draft , m3ua
> > > can act as an
> > > > > > > > > > > SGP,ASP,IPSP.
> > > > > > > > > > > > > > > > When it acts its an IPSP the peer is
> > > > > always assumed
> > > > > > > > > > > to be IPSP.
> > > > > > > > > > > > > > > [TOLGA] No, IPSP will behaeve as ASP
> > > against SGPs.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > This is not true. IPSP has a specific
> > > behavior as
> > > > > > > > > Reshma says.
> > > > > > > > > > > > > > And if we consider SE even the State Machine
> > > > > > > changes...  :-)
> > > > > > > > > > > > > [TOLGA] I disagree with this. In my opinion,
> > > > > IPSP needs to
> > > > > > > > > > > > > behaeve as ASP
> > > > > > > > > > > > > against SGPs.
> > > > > > > > > > > >
> > > > > > > > > > > > If you are handling received ASPUP or ASPAC, you
> > > > > > > are not acting
> > > > > > > > > > > > as an ASP. IPSP acts different to an ASP.
> > > > > > > > > > > [TOLGA] This is what it does against another IPSP
> > > > > (and still
> > > > > > > > > > > there are so
> > > > > > > > > > > many issues to discuss there). Well, maybe it
> > > is better to
> > > > > > > > > > > put ASPF+SGPF in
> > > > > > > > > > > a box, so that ASPF can communicate with any
> > > SGP without
> > > > > > > > > problems ;-)
> > > > > > > > > >
> > > > > > > > > > If you read the mail I sent yesterday, you will
> > > get all the
> > > > > > > > > > problems this modelling arises...  ;-)
> > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > Cheers // Javier.
> > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > And when it is SG it knows the peer
> > > is ASP .And
> > > > > > > > > hence there
> > > > > > > > > > > > > > > was a set
> > > > > > > > > > > > > > > > of messages defined in the draft
> > > which they can
> > > > > > > > > receive and
> > > > > > > > > > > > > > > send for each
> > > > > > > > > > > > > > > > one.
> > > > > > > > > > > > > > > > But now we have SG-SG 
> communication other
> > > > > > > than SG-ASP
> > > > > > > > > > > > > communication
> > > > > > > > > > > > > > > > The initial behavior that SG 
> should have is
> > > > > > > > > > > different for SG-SG
> > > > > > > > > > > > > > > > communication and SG-ASP
> > > communication  ie SG
> > > > > > > > > expects a SSNM
> > > > > > > > > > > > > > > > followed by TAL
> > > > > > > > > > > > > > > > meessage in SG-SG communication
> > > whereas in case
> > > > > > > > > of SG-ASP
> > > > > > > > > > > > > > > has ASPUP and
> > > > > > > > > > > > > > > > ASPAC procedures.So it should 
> be configured
> > > > > > > initially
> > > > > > > > > > > > > > > ..which all ASPs and
> > > > > > > > > > > > > > > > SGs will be connected and which peer is
> > > > > an ASP/SG
> > > > > > > > > > > ?(and behave
> > > > > > > > > > > > > > > > differently?) OR SG should be
> > > > > configured to either
> > > > > > > > > > > behave as STP
> > > > > > > > > > > > > > > > or as SEP?
> > > > > > > > > > > > > > > [TOLGA] This is configuration.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > Also once the TAL message is sent if
> > > > > > > any PC is not
> > > > > > > > > > > > > > > available then does
> > > > > > > > > > > > > > > > one
> > > > > > > > > > > > > > > > > > SG send DUNA to the other SG? How
> > > > > it is handled?
> > > > > > > > > > > > > > > > > [TOLGA] After TAL, if one PC becomes
> > > > > available,
> > > > > > > > > > > SG1 will send
> > > > > > > > > > > > > > > > DAVA to SG2.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > [Reshma] But the draft says "4.3
> > > Traffic Allowed
> > > > > > > > > > > Message(TAL)
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >    TAL is used to indicate to a peer the
> > > > > > > end of SSNM "
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Which is confusing
> > > > > > > > > > > > > > > [TOLGA] The draft says "TAL is used
> > > to indicate
> > > > > > > > > to a peer the
> > > > > > > > > > > > > > > end of SSNM ,
> > > > > > > > > > > > > > > which are sent
> > > > > > > > > > > > > > >    to declare list of not 
> allowed/restricted
> > > > > > > point codes,
> > > > > > > > > > > > > after a SCTP
> > > > > > > > > > > > > > >    association is established. ". 
> I have the
> > > > > > > > > impression, we
> > > > > > > > > > > > > > > will change how
> > > > > > > > > > > > > > > traffic is started and availability
> > > information
> > > > > > > > > is exchanged
> > > > > > > > > > > > > > > but still to be
> > > > > > > > > > > > > > > discussed.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Thanks,
> > > > > > > > > > > > > > > > reshma
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >
> > > > > > > _______________________________________________
> > > > > > > > > > > > > > > > > > > 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
> > > > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > _______________________________________________
> > > > > > > > > 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
> > > > >
> > >
> > >
> > > _______________________________________________
> > > 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

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

---

From: "Tolga Asveren" <[email-masked]>
Date: Fri, 31 May 2002 09:32:08 -0400

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.

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 31 May 2002 09:03:46 -0500

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)

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

---

From: "Tolga Asveren" <[email-masked]>
Date: Fri, 31 May 2002 10:24:42 -0400

Brian,

> From: Brian F. G. Bidulock [mailto:[email-masked]]
> Sent: Friday, May 31, 2002 10:04 AM
> To: Tolga Asveren
> Cc: [email-masked]
> Subject: Re: [Sigtran] IPSP vs AS (was RE: sg-sg communication)
> Importance: High
>
>
> Tolga,
>
[TOLGA] Why do we need OPC for DE case? For DE it is true that one needs to
enter 8 RKs (because each RK will be configured at both IPSPs), but there
will be 4 different types of RK for the configuration I draw. The reason why
one might use "wildcarded" RKs in DE is, because RKs have meaning only for
one end, for SE, it has meaning for both ends, so both ends should be
specified. In my opinion, this is really ASP-ASP vs. AS-AS and I think we
should choose one of those approaches.

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 31 May 2002 09:44:40 -0500

Tolga,

Tolga Asveren wrote:                             (Fri, 31 May 2002 10:24:42)
> should choose one of those approaches.

Consider at IPSP1

		RK1: OPC=1-1-1, 2-2-2, DPC=3-3-3, 4-4-4

and at IPSP2 the symmetrical

		RK2: OPC=3-3-3, 4-4-4, DPC=1-1-1, 2-2-2
	
As there is only one (symmetrical) RK here, there is no need for any
RC values at all (AS is implied by the association).  This is how point
to point works.  There is no relaying.  There is never any other way to
get to 3-3-3 or 4-4-4 except over this association.

DE always requires more RKs than SE because it must use 2 RKs to describe
one full duplex traffic flow.  SE only requires 1 RK to describe the same
flow.

--brian

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