Re: SE-IPSP definition

Tolga,

Tolga Asveren wrote:                                                                 (Wed, 09 Nov 2005 13:59:49)
> Brian,
> 
> > -----Original Message-----
> > From: Brian F. G. Bidulock [mailto:[email protected]]
> > Sent: Wednesday, November 09, 2005 2:03 PM
> > To: Tolga Asveren
> > Cc: [email protected]
> > Subject: Re: [Sigtran] SE-IPSP definition
> >
> >
> > Tolga,
> >
> > Tolga Asveren wrote:
> >                    (Wed, 09 Nov 2005 13:33:22)
> > > 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?
> >
> > 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.
> [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).
> >
> > 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.
> [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."

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


> >
> > 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.
> [TOLGA]RC is mandatory in RKs, and RKs can't span SPMCs. This is specified
> in the document.
> >
> > >
> > > As far as I can see only SCON has a use case, and hopefully
> > with ASPCONG it
> > > won't be necessary as well.
> >
> > They all have "Use Cases".
> [TOLGA]The specification does not allow them

Where?!  The specification allows them by not forbidding 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.

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
> >
> > --
> > Brian F. G. Bidulock
> > [email protected]
> > http://www.openss7.org/
> >
> 
> 
> 
> _______________________________________________
> Sigtran mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/sigtran

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