Subject: RE: [Sigtran] SE-IPSP definition

From: "Holland, Peter Michael (Peter)" <[email-masked]>
Date: Wed, 9 Nov 2005 16:29:33 -0000

Tolga,
Concerning text clean up I see a couple of references to 
C-IPSP/D-IPSP that I assume should be removed.
I also noticed several English problems with the numbered 
items at the start of 4.3. I can send updated text if you 
would like.

Reading this thread the problem I see with SE procedures was
identified in a mail where Brian said:
>If you want both IPSPs to each have an AS an traffic mode, use DE instead
of SE.
Thus I understand there are situations where SE mode cannot be
used. This is not clear in RFC.

Concerning the inapplicability of SSNM message in IPSP mode, I definately
think it would help if this was explicitly stated - this has been a
subject on significant discussion in some fora.

Thanks
Pete

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On
> Behalf Of Tolga Asveren
> Sent: 09 November 2005 14:56
> To: [email-masked]
> Subject: RE: [Sigtran] SE-IPSP definition
> 
> 
> Shashank,
> 
> I don't think there is as significant issue as you mention. 
> As far as I can
> see, some text cleanup is the only thing we need-to get rid 
> of C/SE-IPSP ,
> S/SE-IPSP distinction-.
> 
> The original problem you mentioned -having traffic mode bothways- is
> something useful IMO as well. That can be added to the 
> document but it does
> not change anything architecturally in terms of IPSP as defined in the
> document.
> 
> What other issues do you consider as problems associated with IPSP?
> 
>    Tolga
> 
> > -----Original Message-----
> > From: Prasad, Shashank S (Shashank) [mailto:[email-masked]]
> > Sent: Wednesday, November 09, 2005 10:08 AM
> > To: 'Ken A Morneault (kmorneau)'; Tolga Asveren; [email-masked]
> > Subject: RE: [Sigtran] SE-IPSP definition
> >
> >
> > Ken,
> > There is a serious issue in understanding the differences 
> in IPSP and what
> > it means.
> > I am sure that u would have gone thru the mails where serious
> > issues of IPSP
> > understanding is evident.
> >
> > I feel that it should be resolved in the next draft before 
> anything else.
> > An extention draft must include IPSP considerations.
> >
> > shashank
> >
> >
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]]On
> > Behalf Of Ken A Morneault (kmorneau)
> > Sent: Wednesday, November 09, 2005 8:12 PM
> > To: Tolga Asveren; [email-masked]
> > Subject: RE: [Sigtran] SE-IPSP definition
> >
> >
> >
> >
> > Hi Tolga,
> >
> > Sorry for the delayed response.  I took some time off.
> >
> > Regarding the IPSP text, that is an area that Javier
> > updated.  At this point, I'm not sure if we will be
> > able to change the text.  The document is supposed to
> > be heading to the Editor's queue to be published.
> >
> > Regards,
> >
> > Ken
> >
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]] On
> > Behalf Of Tolga Asveren
> > Sent: Tuesday, November 08, 2005 9:13 AM
> > To: [email-masked]
> > Subject: RE: [Sigtran] SE-IPSP definition
> >
> > A few typo scorrected below.
> >
> > > -----Original Message-----
> > > From: [email-masked] [mailto:[email-masked]]On
> > > Behalf Of Tolga Asveren
> > > Sent: Tuesday, November 08, 2005 8:35 AM
> > > To: [email-masked]
> > > Subject: [Sigtran] SE-IPSP definition
> > >
> > >
> > > Brian,
> > >
> > > -changed the subject of the thread-
> > >
> > > Ken, I re-checked and current bis document seems to be updated
> > > partially
> > > (4.3 has the definition I copy/pasted below -which is fine-, OTOH
> > > still there is text mentioning about C-IPSP, D-IPSP for 
> SE-model. The
> > > idea probably was to assign roles to IPSPS per 
> "transaction", i.e. a
> > > message pair like ASPAC/ASPAC-ACK, ASPIA/ASPIA-ACK, but I 
> believe the
> > > concept of "client"
> > > and "server" can be misleading because it can be considered as one
> > > IPSP always playing client or server role while 
> communicating with a
> > > certain peer IPSP. IMHO, the terms C-IPSP/D-IPSP confuse 
> rather than
> > > clarify.
> > >
> > > Brian, more comments below.
> > >
> > >    Tolga
> > >
> > > > -----Original Message-----
> > > > From: [email-masked] 
> [mailto:[email-masked]]On
> > > > Behalf Of Brian F. G. Bidulock
> > > > Sent: Monday, November 07, 2005 7:52 PM
> > > > To: Tolga Asveren
> > > > Cc: [email-masked]
> > > > Subject: Re: [Sigtran] M3UA: 1IPSP - multiple IPSPs traffic flow
> > > >
> > > >
> > > > Tolga,
> > > >
> > > > Tolga Asveren wrote:
> > > >                    (Mon, 07 Nov 2005 14:36:07)
> > > >
> > > > --X--snip--X--
> > > >
> > > > > [TOLGA]If you look to " M3UAbis - consensus on comment
> > > resolution - Part
> > > > > 1&2" thread -which has happened later than the thread you
> > > > mentioned ;-) -,
> > > > > you will see that everybody involved in the discussion
> > > > "Valerie, you, myself
> > > > > and Javier" agreed to return to the original SE-IPSP 
> model. The
> > > > conclusion
> > > > > was to use the text proposed by Valerie. It seems the bis
> > > > document is not
> > > > > updated accordingly. Ken, was there a technical 
> objection for that
> >
> > > > > change -actually I would call it reverting back to 
> the original
> > > > model- or is
> > > > > this just an oversight?
> > > >
> > > > Really?  Did you mean in "M3UAbis - consensus on 
> comment resolution"
> >
> > > > 23 Aug 2004 where Valerie says:
> > > >
> > > >  IPSP-SE behaviour:
> > > >  The IPSP acting as the SGP must sends ASPAC-ack only 
> when its side
> > > > of the RK is  ready.  The IPSP acting as the ASP is 
> responsible to
> > > > retry the ASPAC until the  remote peer is ready.
> > > >  When the IPSP acting as the SGP wants to stop 
> application traffic
> > > > from its side,  it must send ASPIA-ack.
> > > [TOLGA] No, what I mean is  the message on 08/30/2004 "M3UAbis -
> > > consensus on comment resoluti on-Part 1&2"
> > >
> > > 1- IPSP Single Exchange (SE) model. Only a single 
> exchange of ASPTM
> > >       or ASPSM messages is needed to change the IPSP 
> state. This means
> > >       that a set of request from one end and acknowledge from the
> > other
> > >       will be enough. The RK must define both sides of the traffic
> > flow.
> > >       Each exchange of ASPTM or ASPSM messages can be initiated by
> > either
> > >       IPSP. For this exchange, the initiating IPSP follows the
> > procedures
> > >       described in section 4.3.1.
> > >
> > > The above is the original concept we defined for SE-IPSP mode.
> > > There are no
> > > predefined client/server relationship, a pure peer-to-peer
> > relationship.
> > > >
> > > > Or did you mean where we agreed to back out of the v03 changes
> > > > (which is what I think you are referring to with the 
> IPSPF) and go
> > > > back to the
> > > > v02 description
> > > > (which is the same as RFC 3332 and the SGPF/ASPF approach).
> > > [TOLGA]No, what I mean as "IPSPF approach is v02 
> definition. As long
> > > as the problem is how you and I name it, there is no problem from
> > > specification point of view but I would call it IPSPF 
> because it has a
> >
> > > different machine
> >
> > ^^^^^^^^^
> >                                                             
>       state
> > machine
> > > than SGPF and ASPF and does not send/receive messages. I believe
> >                                                ^^^^^^^^^
> >                                          certain messages, e.g. SSNM
> > > you use the
> > > term SGPF in the context of a "transaction" not inthe 
> context of the
> > > overall realtionship between two peer IPSPs.
> > > >
> > > > --brian
> > > >
> > > > >
> > > > > Considering the way it is supposed to work, i.e. according to
> > > > the text we
> > > > > had concensus on, we can't speak of exact SGPF semantics for
> > > > SE-IPSP even
> > > > > from basic message exchange point of view, e.g. SGPF does not
> > > > send ASPAC,
> > > > > can't receive ASPAC-ACK, sends SSNM etc...With SE-IPSP both
> > > > sides can send
> > > > > ASPAC/ASPAC-ACK and they don't send SSNM and they have a
> > > > > peer-to-peer relationship, not a client/server relationship.
> > > >
> > > > See Valerie's description above.  As I have mantained, 
> it is clear
> > > > that one IPSP acts in an SGP role and the other in an ASP role.
> > > >
> > > > >
> > > > > Regarding the issue we are discussing in this thread -being
> > > > able to support
> > > > > traffic mode in both directions-I think it is a nice thing to
> > > > have, because
> > > > > we have application logic at both sides, which may want to
> > > use different
> > > > > traffic .
> > > >
> > > > Again, the IPSP acting as an SGP in SE mode is not 
> required to have
> > > > a traffic mode.
> > > >
> > > > In the normal ASP/SGP exchange, the SGP does not have a 
> traffic mode
> >
> > > > to place in the ASPAC Ack.  Any traffic distribution 
> towards the SGP
> >
> > > > is an SG-wide attribute and does not differ from AS to 
> AS, nor ASP
> > > > to ASP.
> > > >
> > > > --brian
> > > >
> > > > --
> > > > 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
> >
> > _______________________________________________
> > 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, 9 Nov 2005 11:23:16 -0500

Pete,

> From: Holland, Peter Michael (Peter) [mailto:[email-masked]]
> Sent: Wednesday, November 09, 2005 11:30 AM
> To: 'Tolga Asveren'; [email-masked]
[TOLGA]Ken/Javier are the authors, i.e. the text is not under my control.
OTOH based on Ken's last message, I have the impression that we can't have
non-editorial changes anymore(?) Otherwise I would like to see C-IPSP/D-IPSP
to be cleaned up as well.
> used. This is not clear in RFC.
[TOLGA]No, this is not true, one can use SE-IPSP for any scenario. IMO, that
traffic mode can't be specified bothways is something we need to add to the
specification.
> subject on significant discussion in some fora.
[TOLGA]Ken, is it possible to have the following modification:
In 3.1.2 Message Classes and Types:
  SS7 Signalling Network Management (SSNM) Messages (See Section
      3.4)(Note: SSNM is not used for IPSP communication)

I believe the above change could be considered as "editorial". ;-)

It could be better to a a few sentectes why they are not used and how
availability etc.. is to be handled for IPSP case but I don't know whether
we are already too late for that. If not, I can provide text.

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 9 Nov 2005 11:34:31 -0700

Tolga,

Tolga Asveren wrote:                                                                 (Wed, 09 Nov 2005 11:23:16)
> I believe the above change could be considered as "editorial". ;-)

The change is not editorial and I disagree with the change in semantics.
There is no reason why an IPSP cannot send SNMM as the RFC permitted at
WGLC.

--brian

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 9 Nov 2005 11:42:24 -0700

Holland,,

Holland, Peter Michael (Peter) wrote:                                             (Wed, 09 Nov 2005 16:29:33)
> C-IPSP/D-IPSP that I assume should be removed.

It was agreed at WGLC that the terms C-IPSP and D-IPSP would be removed.
If it is still possible to do so, it is an editorial change.

> used. This is not clear in RFC.

No, there are not situations where SE mode cannot be used.  What I was
saying was that if one pedantically requies that both peers have and
exchange a traffic mode (which they don't need in the first place) that
one should use the DE mode.

SE can work quite fine in all situations with one side not having an ASP
traffic mode.  No change is required.

> subject on significant discussion in some fora.

All SSNM messages are applicable to IPSPs.  No change is required.

--brian

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

---

From: "Tolga Asveren" <[email-masked]>
Date: Wed, 9 Nov 2005 13:28:35 -0500

Brian,

> From: Brian F. G. Bidulock [mailto:[email-masked]]
> Sent: Wednesday, November 09, 2005 1:35 PM
> To: Tolga Asveren
> Cc: [email-masked]
> Subject: Re: [Sigtran] SE-IPSP definition
>
>
> Tolga,
>
> Tolga Asveren wrote:
>                    (Wed, 09 Nov 2005 11:23:16)
[TOLGA]As far as I can see, the current text explicitly defines that DUNA is
sent from SG and SCON from SG and ASP in 3.4.1 and 3.4.4 respectively. OTOH,
1.4.6 mentions about sending SCON for IPSP case as well. So,

a)For DUNA, the existing specification does not allow its usage for IPSP.

b)For SCON, there is inconsistency in the document. With ASPCONG, I don't
think there will be a need for SCON for IPSP case. I believe, for the sake
of completiness, it can be kept in the document for now(?).

---

From: "Tolga Asveren" <[email-masked]>
Date: Wed, 9 Nov 2005 13:33:22 -0500

Brian,

[..snip..]
> All SSNM messages are applicable to IPSPs.  No change is required.
[TOLGA]I couldn't disagree more. Could you please tell why they are needed?

Availability of remote ends is managed by the state of AS.

As far as I can see only SCON has a use case, and hopefully with ASPCONG it
won't be necessary as well.

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 9 Nov 2005 11:56:04 -0700

Tolga,

Tolga Asveren wrote:                                                                 (Wed, 09 Nov 2005 13:28:35)
> a)For DUNA, the existing specification does not allow its usage for IPSP.

Where does it say that DUNA cannot be sent from an IPSP?

I interpret sending DUNA from an SGP to mean that it can be sent from the
SE-IPSP acting like an SGP.

(And, DAVA and DUPU and DRST.)

> of completiness, it can be kept in the document for now(?).

While you're making all these changes, why not scrap IPSP altogether?
It hasn't turned into a very useful part of the specification.

--brian

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

---

From: "Tolga Asveren" <[email-masked]>
Date: Wed, 9 Nov 2005 13:39:43 -0500

For everybody interested in that topic, I would suggest also to read
"1.4.3.2 SS7 and M3UA Interworking at the SG" and "1.4.3.4 IPSP
Considerations".

"1.4.3.4 IPSP Considerations

   Since IPSPs use M3UA in a point-to-point fashion, there is no concept
   of routing of messages beyond the remote end.  Therefore, SS7 and
   M3UA interworking is not necessary for this model."

> From: Tolga Asveren [mailto:[email-masked]]
> Sent: Wednesday, November 09, 2005 1:33 PM
> To: [email-masked]
> As far as I can see only SCON has a use case, and hopefully with
> ASPCONG it won't be necessary as well.

---

From: "Tolga Asveren" <[email-masked]>
Date: Wed, 9 Nov 2005 13:41:55 -0500

Brian,

> Sent: Wednesday, November 09, 2005 1:56 PM
> To: Tolga Asveren
> Cc: [email-masked]
>                    (Wed, 09 Nov 2005 13:28:35)
> > Brian,
> >
[TOLGA]That wouldn't be an IPSP, that would be an SGP. An IPSP is supposed
to work according to IPSP procedures defined in the specification.
> It hasn't turned into a very useful part of the specification.
[TOLGA]I think SE-IPSP works fine, just the text needs to be cleaned up.

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 9 Nov 2005 12:03:15 -0700

Tolga,

Tolga Asveren wrote:                                                                 (Wed, 09 Nov 2005 13:33:22)
> [TOLGA]I couldn't disagree more. Could you please tell why they are needed?

Because they correspond to MTP-User primitives that need to be delivered
to the AS, regardless of whether the AS is at an ASP or IPSP.

To use your words, it is required by the "Application Logic" for the peer to
be able to indicate things such as MTP-STATUS.

--brian

> Availability of remote ends is managed by the state of AS.

No it cannot in all cases.  For example, if an entire PC RK is used between
IPSP, the IPSP can use DUPU to signal the availabiltiy of individual user
parts to the peer that cannot be accomplished with ASP activation state.

Another case is where NA is used as a RK and multiple point codes are used at
either end.  I know that you do not agree with this arrangement, but there is
nothing in the current spec forbidding it.

> won't be necessary as well.

They all have "Use Cases".

--brian

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 9 Nov 2005 12:08:17 -0700

Tolga,

I an not talking about SNMM used to indicate the status of remote point
codes, etc.  I am talking about SNMM used to indciate the status of local
point codes, etc. for the sending IPSP.

Also, it might not be necessary (in all cases), it might not even be very
useful (in some cases), but it is currently not prohibited.

--brian

Tolga Asveren wrote:                                                                 (Wed, 09 Nov 2005 13:39:43)

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 9 Nov 2005 12:05:26 -0700

Tolga,

Tolga Asveren wrote:                                                                 (Wed, 09 Nov 2005 13:41:55)
> to work according to IPSP procedures defined in the specification.

And there are places where we said that the IPSP follows the SGP side of
the procedures, which would include sending SNMM.

--brian

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

---

From: "Tolga Asveren" <[email-masked]>
Date: Wed, 9 Nov 2005 13:59:49 -0500

Brian,

> Sent: Wednesday, November 09, 2005 2:03 PM
> To: Tolga Asveren
> Cc: [email-masked]
>                    (Wed, 09 Nov 2005 13:33:22)
> > Brian,
> >
> > [..snip..]
> > >
[TOLGA]To generate those primitives AS status is enough for IPSP case
(considering the addition of ASPCONG, otherwise SCON may be necessary if
SCTP congestion is not enough).
> parts to the peer that cannot be accomplished with ASP activation state.
[TOLGA]An AS is not supposed to be partially active or inactive. It acts as
a single entity. So, the configuration you mentioned is impractical to be
used for IPSP case. If one has RK defined on PC granularity, that PC becomes
avalable/unavailable as a whole, not in bits and pieces. Please check your
reply on "M3UA User Part's Management" thread on 10/10/2005, where you
explain the situation very clearly -where you are answering a question about
managing user parts for IPSP case-:

"To provide M3UA with information about the availability
of an MTP User Part requires that the AS be no larger
than a User part.  You are runnign into difficulties
because your AS is too large.  Define an AS per user
and your difficulties should go away."
> nothing in the current spec forbidding it.
[TOLGA]RC is mandatory in RKs, and RKs can't span SPMCs. This is specified
in the document.
> They all have "Use Cases".
[TOLGA]The specification does not allow them and they are not necessary
(except maybe for SCON -for now). IPSP communication relies on ASPTM. BTW, I
noticed that there is also no text chnage necessary, there is enough text in
the existing speicification disallowing SSNM -except SCON- for IPSP case.

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 9 Nov 2005 12:18:20 -0700

Tolga,

See Section 4.6 in RFC 3332, bottom of page 92.  An IPSP will have a
hard time acting as proscribed without sending SNMM.

I think that your idea of IPSP is your own personal one derived from
SG-SG work rather than what is described in and permitted by the RFC.

--brian

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 9 Nov 2005 12:23:48 -0700

Tolga,

Tolga Asveren wrote:                                                                 (Wed, 09 Nov 2005 13:59:49)
> and your difficulties should go away."

That is for the ASP/SGP scenario where the ASP does not send DUPU.

In the IPSP case the IPSP acting as SGP can send DUPU and the arragement
is possible.

--brian

> [TOLGA]The specification does not allow them

Where?!  The specification allows them by not forbidding them.

> and they are not necessary

See Section 4.6 where the reverse of your view is stated.  It states that an
IPSP can follow SGP behavior with regard to SSNM.

--brian

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

---

From: "Tolga Asveren" <[email-masked]>
Date: Wed, 9 Nov 2005 14:29:04 -0500

Brian,

-I will try to consolidate my replies as much as I can-
> Sent: Wednesday, November 09, 2005 2:08 PM
> To: Tolga Asveren
> Cc: [email-masked]
[TOLGA]ASPTM should be enough for that purpose. If one wants to be notified
about remote user part status for IPSP case, one should have RKs defined in
User Part granularity. For availability/unavailability there is ASPAC/ASPIA.
We only miss the congestion message in ASPTM, which hopefully should be
ready soon.
> useful (in some cases), but it is currently not prohibited.
a)I am not speaking of SG-SG at all, what I am saying has nothing to do with
it. You also know that actually it is SG-SG, which is SSNM based -and which
makes sense considering the services it needs to provide-, but this is not
hte topic right now.

b)Your answer in  "M3UA User Part's Management" thread was about IPSP
communication, if you want, you can check the original question in that
thread. ;-)

c)The section you mention in "4.6 MTP3 Restart" is really really wrong and
needs an update IMHO. An IPSP does not have MTP3 layer. One obviously can
build a box which provides both SGP and IPSP services but IPSP functionality
itself has nothing to do with MTP3. IPSP will host only local application
logic which communicates directly with another application hosted byt a peer
IPSP. Remote endpoint in traditional SS7 domain will be responsibility of
SGP and MTP3 restart is applicable only for SGP, not for IPSP.

For the sake of making progress here is what I think:
a)People are confused about use of SSNM for IPSP (I think we agree about
this)
b)SSNM is not necessary for IPSP case -except for SCON, which needs further
study, i.e. ASPCONG-. If there is a situation where we *really* need it,
let's try to figure out whether it can be handled with ASPTM. (This is my
position. AFAICS, you also think that it is probably not a good idea to use
SSNM either but you think that the document does not disallow this.)

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 9 Nov 2005 18:18:55 -0700

Tolga,

I think that you are talking about something completely different
than RFC 3332.

Might I suggest a new IPSP draft that has things the way that you
want them?

--brian

Tolga Asveren wrote:                           (Wed, 09 Nov 2005 14:29:04)

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