Subject: RE: [Sigtran] m3ua: ipspcomm

From: "Schantz, John" <[email-masked]>
Date: Wed, 29 May 2002 14:23:33 -0500

Tolga,
	I'm not sure if I can sympathize with the RK problem.  This is IPSP-IPSP (which I think is about the problem as SG-SG).  

	I come from the SS7 school of thought where a node does its own traffic filtering, not its adjacent node (as is the case allowed in the AS-SG case with RK/RCs). Network traffic routing is based on PC and I think this is applicable to the IPSP-IPSP and SG-SG cases.  Why should I expect an adjacent signalling point (IPSP) to filter/separate traffic to me based on an RC/RK (something finer than a PC).  This is an extra capability that I don't want to implement in my own signalling end-point (SEP)(IPSP), therefore I don't want to force it into anyone else's SEP/IPSP.

John

> -----Original Message-----
> From: Tolga Asveren [mailto:[email-masked]]
> Sent: Wednesday, May 29, 2002 10:25 AM
> To: [email-masked]
> Subject: RE: [Sigtran] m3ua: ipspcomm
> 
> 
> John,
> 
> But apart from traffic initiation, there are also other 
> aspects of this
> issue, at least in my mind.
> "Double ended" approach assumes RKs have meaning only in one 
> direction, i.e.
> one has local and remote RKs. For "single ended" the RK has 
> meaning for both
> AS on each side.
> (This is more or less the point, where we have stopped in the 
> intiial IPSP
> discussions) That is the reason, why I was saying, those are 
> representing
> two different ways of doing things. In my opinion, if one 
> chooses one of
> those two methods, then agreeing on how traffic should be 
> started shouldn't
> be a major task.
> 
>    Tolga
> 
> 
> > -----Original Message-----
> > From: Schantz, John [mailto:[email-masked]]
> > Sent: Wednesday, May 29, 2002 11:00 AM
> > To: Javier Pastor-Balbas (ECE); Tolga Asveren; [email-masked]
> > Subject: RE: [Sigtran] m3ua: ipspcomm
> >
> >
> > Hi Guys,
> >
> > I assume that you are talking about whether both ends send ASP UP
> > and ASP Active (and of course the ACKs).  I was looking at the
> > RFC recently and there were a number of conclusions I go from it.
> >
> > 	1) There is no indication or way to indicate what one of
> > the sides of the association is going to do - single or 
> double handshake.
> > 	2) At minimum, the single handshake must be supported.
> > 	3) If one side wants to do the double handshake, then the
> > other side must provide "courtesy" ACKs to the ASP UP and 
> ASP ACTIVE.
> > 	4) Even in the single handshake case, who starts it?
> >
> > At first I was going to say is that we only need the single
> > handshake.  But if you don't want to configure which side starts!
> >  Then a combination of the two should solve the "glare" condition.
> >
> > If one of the sides receives an ASP UP before it has sent one,
> > then a single handshake should be used with the "receiving" side
> > just ACKing the other side that was first to send the ASP UP.
> >
> > If one of the sides receives an ASP UP after it has already sent
> > one, then a double handshake should be used.  It would be easier
> > to do this than to figure out who should be the initiator 
> and responder.
> >
> > If you MUST only have one, then give the SCTP initiator side the
> > M3UA initiation responsibility too.
> >
> > John
> >
> >
> > > -----Original Message-----
> > > From: Javier Pastor-Balbas (ECE)
> > > [mailto:[email-masked]]
> > > Sent: Wednesday, May 29, 2002 8:08 AM
> > > To: 'Tolga Asveren'; [email-masked]
> > > Subject: RE: [Sigtran] m3ua: ipspcomm
> > >
> > >
> > > Hi Tolga,
> > >
> > > If this is what people think and Lyndon agrees, I have no 
> problem  :-)
> > >
> > > Do any people want both approaches??
> > >
> > > Cheers // Javier.
> > >
> > > > -----Original Message-----
> > > > From: Tolga Asveren [mailto:[email-masked]]
> > > > Sent: Wednesday, May 29, 2002 2:42 PM
> > > > To: [email-masked]
> > > > Subject: [Sigtran] m3ua: ipspcomm
> > > >
> > > >
> > > > Javier,
> > > >
> > > > What is the reason to continue with two approaches? I think,
> > > > first of all,
> > > > we should decide, whether this is really we want or not and
> > > > if we want to go
> > > > with one of them, we should choose which one. "Double" and
> > > > "single" ended
> > > > approaches are representing two different philosophies.
> > > >
> > > >    Tolga
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > _______________________________________________
> > > > 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: Wed, 29 May 2002 15:46:59 -0400

John,

Correct me if I am wrong, you want the communication in PC granularity, not
less than this, for IPSP-IPSP and SG-SG? For SG-SG I can say, it is for sure
in PC granularity. I also think PC granularity in most of the cases will be
enough, that is the reason, why I think SG-SG might be utilized also for
communication between IP-SEPs. For IPSP case, to be honest I don't know. I
think this is something to be discussed. What do the others think?

    Tolga

> Sent: Wednesday, May 29, 2002 3:24 PM
> To: Tolga Asveren; [email-masked]
> 	I'm not sure if I can sympathize with the RK problem.  This
> is IPSP-IPSP (which I think is about the problem as SG-SG).
>
> 	I come from the SS7 school of thought where a node does its
> own traffic filtering, not its adjacent node (as is the case
> allowed in the AS-SG case with RK/RCs). Network traffic routing
> is based on PC and I think this is applicable to the IPSP-IPSP
> and SG-SG cases.  Why should I expect an adjacent signalling
> point (IPSP) to filter/separate traffic to me based on an RC/RK
> (something finer than a PC).  This is an extra capability that I
> don't want to implement in my own signalling end-point
> (SEP)(IPSP), therefore I don't want to force it into anyone
> else's SEP/IPSP.
>
> John
>