RE: Affected SPC is a mandatory parameter in SUA SCON
"Haresign Lincoln" <[email protected]>
| Newsgroups | gmane.ietf.sigtran |
|---|---|
| Message-ID | <849535E338E99741B7F7413F73253EDB04D5E265@us-nj-mail1.comverse.com> |
I agree, the draft that Brian put out looked good for resolving this issue. Does it make any sense to combine this draft with the SUA implementor's guide as that discussion seems to be going on, or is that too complicated? Regards, Lincoln -----Original Message----- From: Tolga Asveren [mailto:[email protected]] Sent: Monday, October 02, 2006 9:36 AM To: [email protected] Subject: RE: [Sigtran] Affected SPC is a mandatory parameter in SUA SCON Ilie, IMHO, an elegant solution would be to (finally) define ASPCONG (or whatever we call it) as a new ASPTM, to indicate congestion related with a spoecific AS on a an ASP or IPSP. We had some discussions about this on the list and Brian even put a draft together but I don't know whether work still continues about this issue. I think, this is a missing piece and it is a good idea to have that message and corresponding procedures defined. Thanks, Tolga > -----Original Message----- > From: Ilie Glib [mailto:[email protected]] > Sent: Sunday, October 01, 2006 8:05 AM > To: sigtran > Subject: [Sigtran] Affected SPC is a mandatory parameter in SUA SCON > > > Hello Folks, > > On the one hand, according to SUA RFC, an IPSP MAY indicate local > congestion to an SUA peer with an SCON message. On the other hand, > Affected SPC is a mandatory parameter in SCON. Therefore, in case the > IPSP serves a hostname or IP address, and does not serve an SPC, the > IPSP has to use a dummy SPC, which shall be interpreted as an > indication that own nodal congestion is experienced in the IPSP > originating the SCON message. > > To avoid use of dummy SPCs in SCONs, it would be good to change the > SUA RFC, and make the Affected SPC an optional parameter in SCON > exchanged by IPSPs. > > I believe RC parameter is sufficient in SCON, and Affected SPC can be > made optional in that case. This is because DPC is not mandatory in > the RK definition of IPSPs. > > Perhaps, the same could apply to M3UA, if DPC was optional in the RK > definition. > > > Any opinions? > > Thank you in advance > > -- > Ilie > > _______________________________________________ > Sigtran mailing list > [email protected] > https://www1.ietf.org/mailman/listinfo/sigtran _______________________________________________ Sigtran mailing list [email protected] https://www1.ietf.org/mailman/listinfo/sigtran