Subject: Re: [Sigtran] Re: M3UA Congestion Procedures

From: [email-masked]
Date: Fri, 21 Mar 2003 18:29:28 +0530

Srini
Interface between M3UA (at SGP) and NIF is not standardized  so it is basically
implementation dependent, and nice implementation would not like to keep
redundant point code status information both at MTP3 and M3UA, that is why i
have not mentioned it in my draft.But no doubt flexibility should be provided
for all implementations, I can add a point on that in the next release of the
draft.
Regards
Kamesh
Hughes Software Systems

ksrinivas <[email-masked]> on 03/21/2003 05:31:59 PM

To:   Kamesh Kaul/HSS@HSS
cc:   [email-masked]

Subject:  Re: [Sigtran] Re: M3UA Congestion Procedures

Kamesh,

    So IMO, M3UA at SGP should maintain the status of the destination point
codes.

--Srini

[email-masked] wrote:

> Srini
>  In M3UA RFC no such primitive is given
>
> ksrinivas <[email-masked]> on 03/21/2003 05:07:10 PM
>
> To:   Kamesh Kaul/HSS@HSS
> cc:   [email-masked]
>
> Subject:  Re: [Sigtran] Re: M3UA Congestion Procedures
>
> Kamesh,
>
>   Is there any primitive defined by the M3UA RFC for informing NIF of the
> arrival of
> DAUD message in order to get the status of the destination point code?.
>
> --Srini
>
> [email-masked] wrote:
>
> > Srini
> >
> > In this case also MTP3 and NIF coordinating together will respond to audit
> > request by indicating M3UA at SGP with appropriate mtp3 pause if point code
> > status is down,mtp3 resume if point code status is UP and mtp3 status if
point
> > code status is restricted or congested . M3UA in turn sends corresponding
> > DUNA,DAVA,SCON and DRST to concerned AS list.
> >
> > Regards
> > Kamesh
> > Hughus Software Systems
> >
> > ksrinivas <[email-masked]> on 03/21/2003 04:25:17 PM
> >
> > To:   Kamesh Kaul/HSS@HSS
> > cc:   [email-masked]
> >
> > Subject:  Re: [Sigtran] Re: M3UA Congestion Procedures
> >
> > Kamesh,
> >
> > [email-masked] wrote:
> >
> > > Srini
> > >
> > > M3UA at SGP on receiving DATA message from ASP for congested DPC notifies
> NIF
> > > with mtp3 transfer primitive. As point code status is maintained by MTP3
> layer
> > > so it will be redundant for M3UA at SGP to maintain point code status.
> >
> > If the M3UA at SGP is not maintaining the point code status, How will it
> respond
> > to
> > the DAUD message.
> >
> > --Srini
> >
> > > It will
> > > be the responsibility of MTP3 and NIF combined to give mtp3 status
> indication
> > to
> > > M3UA with cause point code congested on receiving data message for
congested
> > > pointcode.M3UA in turn on receiving mtp3 status indication from NIF sends
an
> > > SCON message to concerned AS( ASP's serving it) list. It is covered in the
> > draft
> > > from this perspective in example section 4.1, as handling of mtp3 status
> > > primitive at SGP is clearly mentioned in RFC 3332 (sec 1.4.3.2) .
> > >
> > > Regards
> > > Kamesh
> > > Hughus Software Systems
> > >
> > > ksrinivas <[email-masked]> on 03/21/2003 02:49:51 PM
> > >
> > > To:   Kamesh Kaul/HSS@HSS
> > > cc:   [email-masked]
> > >
> > > Subject:  M3UA Congestion Procedures
> > >
> > > Kamesh,
> > >
> > >     Section 3.4.4 of RFC 3332 says:
> > >
> > > "The SCON message can be sent from an SGP to all concerned ASPs to
> > > indicate that an SG has determined that there is congestion in the SS7
> > > network to one or more destinations, or to an ASP in response to a DATA
> > > or DAUD message as appropriate." ...
> > >
> > > But your "draft-kamesh-m3ua-congestion-procedures-00.txt" does not talk
> > > about SGP sending a SCON message in response to a Data Message received
> > > from ASP. Why?.
> > >
> > > --Srini
> > >
> > >   ------------------------------------------------------------------------
> > >                   Name: att1.htm
> > >    att1.htm       Type: Hypertext Markup Language (text/html)
> > >               Encoding: base64
> > >            Description: Internet HTML
>
> _______________________________________________
> 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: ksrinivas <[email-masked]>
Date: Mon, 24 Mar 2003 10:33:52 +0530

Kamesh,

    Does not the section 1.6 of M3UA RFC mention the complete set of primitives?. Is
whatever mentioned in section 1.6, is only to give few examples of M3UA boundary
primitives?.

--Srini

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 24 Mar 2003 02:41:41 -0700

ksrinivas,

It is the case that Q.701/704 primitives do not describe all services provided
to MTP-Users by the MTP.  See for example Q.701 Section 8.5.

--brian

ksrinivas wrote:                                                                 (Mon, 24 Mar 2003 10:33:52)

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

---

From: ksrinivas <[email-masked]>
Date: Wed, 26 Mar 2003 09:58:25 +0530

Kamesh,

In section 3.2.2 of "draft-kamesh-m3ua-congestion-procedures-00.txt", the follwoing
text is provided:

.....M3UA at SGP may update the change in congestion status of affected SPMC
configured at SGP......

Since you have said may, does that mean, maintaining the congestion status of
affected SPMC at M3UA of SGP is implementation dependent?.

--Srini