3 Oct 2002 14:26
Fw: M2PA v6: Two Out of Three Valid BSN
<anssharma <at> hss.hns.com>
2002-10-03 12:26:16 GMT
2002-10-03 12:26:16 GMT
Hi, -----Original Message----- From: "May, Howard" <howard.may <at> intel.com> To: <sigtran <at> ietf.org> Cc: "Tolga Asveren" <tolga.asveren <at> ss8.com> Sent: Thursday, October 03, 2002 3:22 PM Subject: RE: [Sigtran] M2PA v6: Two Out of Three Valid BSN Tolga, > -----Original Message----- > From: Tolga Asveren [mailto:tolga.asveren <at> ss8.com] > Sent: 30 September 2002 15:57 > To: sigtran <at> ietf.org > Subject: RE: [Sigtran] M2PA v6: Two Out of Three Valid BSN > > > Anshoo, > > > -----Original Message----- > > From: sigtran-admin <at> ietf.org > [mailto:sigtran-admin <at> ietf.org]On Behalf Of > > anssharma <at> hss.hns.com > > Sent: Monday, September 30, 2002 9:28 AM > > To: bidulock <at> openss7.org > > Cc: sigtran <at> ietf.org > > Subject: Re: [Sigtran] M2PA v6: Two Out of Three Valid BSN > > > > Hi Brian, > > > > Checksum failiure can cause any of the fields in the Message to > > be corrupt, > >
then why is the special consideration being given to BSN. > > The two out of three BSN scheme would have been suitable, had we > > been taking > > into the consideration the FSN/BSN values in the Link Status > > Messages as well. > > Since that is not the case, I am not sure how we would be > > deriving any benefit > > from this scheme. > [TOLGA] Why do you think this procedure exists for MTP2? Your > argument is > that there won't be any missequencing in SCTP, but similarly > one can argue, > there won't be any misseqiencing on a wire(for MTP2) either. [hmay] Is it not the case that in MTP2 there is more scope for misequenced BSNs on account of prioritised Link Status messages and the use of FISUs. Certainly misequencing on account of this is an implementation specific issue, but in the days when the processing able to be performed during single FISU emmission time was more limited, this kind of issue may be more common and thus 2 out of 3 safeguard more relevant. > > If I am missing anything here, please elaborate. > [TOLGA] At the beginning I also thought on bit errors, but > another reason, > why BSN does not have an expected value might be, that peer > M2PA (or MTP2 in > case of Q.703) fills it wrong. I tend to think, that is the > real reason for > that procedure, because bit errors are handled as described > in Q.703 10.2. > (With the procedure defined in Q.703 5.3.1 it is possible to > detect some > errors which are not detectable with checksum but I would > think, if there is > really something wrong on the link, there would be enough bit > errors, which > are detectable with checksum, to make the procedure in Q.703 > 10.2 to work.) [hmay] If (as I think you are suggesting) the 2 out of 3 procedure is now only of significant value to protect against M2PA implementation error, then without understanding why there is a specific risk of this error I don't currently see why we should complicate the spec with the procedure. [Anshoo] Even I would suggest the same. Since there seems to be no other reason besides covering implementation errors, can we please remove this procedure from the Draft. Regards Anshoo. DISCLAIMER: This message is proprietary to Hughes Software Systems Limited (HSS) and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. HSS accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus.