Subject: RE: [Sigtran] M3UA-v02 Last Call Comment

From: Tolga Asveren <[email-masked]>
Date: Fri, 7 May 2004 14:39:46 -0700 (PDT)

Hi Antonio,

What I tried to was also almost the same with you:
Describing necessary procedures in M3UAv02, when
association/stream to be used for certain group of
messages changes -queuing those messages for certain
period, again I was not referring to using
correlationId in messages-. Maybe the only difference
is, that I think it should be a bit more than just
referring to MTP3 specs -explaining briefly what needs
to be done when-.

    Tolga 
--- Antonio_Cañete_(ML/EEM)
<[email-masked]> wrote:
> Hi Tolga,
> 
> Mmm, the problem is that Brian's draft expired long
> time ago and it should be an RFC to be able to have
> it as a normative reference in the M3UA RFC. In
> addition, in order to work, it requires a new
> parameter "Correlation Id" in the ASPAC, ASPAC-ACK,
> DATA, BEAT and BEAT-ACK messages, which is not
> understood by M3UA v01 compliant implementations.
> 
> On the other hand, the procedures I mentioned can be
> used by any implementation without impacting the
> protocol. Regardless of the terminology used in
> MTP3, the mechanism is applicable to our purposes.
> 
> Best regards/
> Antonio
> 
> -----Original Message-----
> From: Tolga Asveren [mailto:[email-masked]]
> Sent: jueves, 06 de mayo de 2004 16:18
> To: Antonio Cañete (ML/EEM); [email-masked]
> Subject: RE: [Sigtran] M3UA-v02 Last Call Comment
> 
> 
> (original message did not make it to SIGTRAN list
> for
> some reason)
> 
> Hi Antonio,
> 
> I also was referring to the procedures you mentioned
> (not to using correlationId).
> 
> But personally I believe it is worth mentioning
> about
> this issue in M3UAv02 with a few sentences for the
> following reasons:
> *It really is a function of M3UA itself
> *The terminology used in M3UA and the one used for
> MTP3 are not the same and in fact they speak about
> different things -one about a MTP3/MTP3-User
> relationship whereas the other one is a MTP3-MTP3
> relationship-
> 
> I know for educated reader of the spec, probably not
> too necessary but for completeness I personally
> would
> prefer to see such a paragraph.
> 
>     Tolga
> 
> --- Antonio_Cañete_(ML/EEM)
> <[email-masked]> wrote:
> > Hi,
> > 
> > Another solution is to use the same mechanism as
> in
> > MTP: at failover, you can buffer messages for a
> > short time to allow on-the-fly messages to reach
> its
> > destination before new messages arrive on the
> > alternate path. The changeover/changeback
> mechanisms
> > are detailed e.g. in ITU-T Q.704.
> > 
> > Regards,
> > Antonio
> > 
> >  -----Original Message-----
> > From: 	[email-masked]
> > [mailto:[email-masked]]  On Behalf Of
> Tolga
> > Asveren
> > Sent:	jueves, 29 de abril de 2004 6:47
> > To:	[email-masked]
> > Subject:	Re: [Sigtran] M3UA-v02 Last Call Comment
> > 
> > As far as I recall, such procedures were defined
> in
> > one of Brian's drafts -cordId(?)-. I also think,
> > mentioning about this briefly might be a good
> idea. 
> > 
> > BTW, this also applies for ASP->SGP direction.
> > Basically whenever the SCTP association (or
> stream)
> > used for a group of messages changes, care should
> be
> > taken to decrease possibility of missequencing.
> > 
> >    Tolga
> > --- [email-masked] wrote:
> > > 
> > > 
> > > 
> > > 
> > > Hi,
> > > 
> > >    The list of ASPs in an AS is assumed to be
> > > dynamic, taking into
> > >    account the availability, traffic handling
> > > capability and congestion
> > >    status of the individual ASPs in the list.
> How
> > > does one avoid
> > >    missequence of Signalling traffic in case one
> > of
> > > the active ASP
> > >    transitions from ACTIVE to INACTIVE and
> > > vice-versa.
> > > 
> > >    Are there any controlled rerouting procedures
> > > specified in current
> > >    M3UA v02 draft.
> > > 
> > > Regards
> > > Kamesh
> > > 
> > > "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."
> > > 
> > > 
> > > _______________________________________________
> > > Sigtran mailing list
> > > [email-masked]
> > > https://www1.ietf.org/mailman/listinfo/sigtran
> > 
> > 
> > 	
> > 		
> > __________________________________
> > Do you Yahoo!?
> > Win a $20,000 Career Makeover at Yahoo! HotJobs  
> >
> http://hotjobs.sweepstakes.yahoo.com/careermakeover 
> > 
> > _______________________________________________
> > Sigtran mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/sigtran
> 
> 
> 
> 	
> 		
> __________________________________
> Do you Yahoo!?
> Win a $20,000 Career Makeover at Yahoo! HotJobs  
> http://hotjobs.sweepstakes.yahoo.com/careermakeover 

		
__________________________________
Do you Yahoo!?
Win a $20,000 Career Makeover at Yahoo! HotJobs  
http://hotjobs.sweepstakes.yahoo.com/careermakeover 

_______________________________________________
Sigtran mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/sigtran

---

From: Antonio Cañete (ML/EEM)<[email-masked]>
Date: Fri, 7 May 2004 15:49:57 +0200

Hi Tolga,

Mmm, the problem is that Brian's draft expired long time ago and it should be an RFC to be able to have it as a normative reference in the M3UA RFC. In addition, in order to work, it requires a new parameter "Correlation Id" in the ASPAC, ASPAC-ACK, DATA, BEAT and BEAT-ACK messages, which is not understood by M3UA v01 compliant implementations.

On the other hand, the procedures I mentioned can be used by any implementation without impacting the protocol. Regardless of the terminology used in MTP3, the mechanism is applicable to our purposes.

Best regards/
Antonio

-----Original Message-----
From: Tolga Asveren [mailto:[email-masked]]
Sent: jueves, 06 de mayo de 2004 16:18
To: Antonio Cañete (ML/EEM); [email-masked]
Subject: RE: [Sigtran] M3UA-v02 Last Call Comment

(original message did not make it to SIGTRAN list for
some reason)

Hi Antonio,

But personally I believe it is worth mentioning about

I know for educated reader of the spec, probably not
too necessary but for completeness I personally would
prefer to see such a paragraph.

    Tolga

--- Antonio_Cañete_(ML/EEM)
<[email-masked]> wrote:
> Hi,
> 
> Another solution is to use the same mechanism as in
> short time to allow on-the-fly messages to reach its
> alternate path. The changeover/changeback mechanisms
> [mailto:[email-masked]]  On Behalf Of Tolga
> Asveren
> As far as I recall, such procedures were defined in
> mentioning about this briefly might be a good idea. 
> 
> Basically whenever the SCTP association (or stream)
> used for a group of messages changes, care should be
> >    status of the individual ASPs in the list. How
> > does one avoid
> > "DISCLAIMER: This message is proprietary to Hughes
> > Software Systems Limited

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 13 May 2004 18:48:26 -0600

Antonio,

The draft was removed in January, not so long ago.  I will submit a
updated draft (just updated references, version number and dates).

You will find interworking with nodes not supporting CORID described in
detail in section 4.3 of the draft.  Also, the use of a procedure
similar to the time-controlled changeover or change back procedure of
Q.704 is detailed in section 4.1.6.1.2 and 4.1.6.2 of the draft and can
be used for interworking to previous versions of M3UA.

Unfortunately, if the full procedures are not used, it is more difficult
to obtain MTP objectives for message loss, duplication and
mis-sequencing.  See section 1.4.3 and 1.4.5 of the draft for details.
Less than the full procedures are inadequate, when mis-sequencing and
duplication can be eliminated to the extent made possible by MTP's
sequenced changeover and change back procedures.

Q.704's sequence changeover and change back procedures are not for
cosmetic purposes.  M3UA cannot efficiently approach MTP performance
objectives without similar procedures.

This issue was outstanding at the time that M3UA was first to be
advanced to RFC (and SUA as well).  The WG chair assured us that if we
advanced the draft that these outstanding issues could be resolved by
extension draft.  As the industry was clamoring for a solution at the
time, (and draft versions of the documents where being referenced by
other standards bodies).  M3UA draft 12 dated February 2002 was
advanced.  The first CORID draft is dated January 2002.  The CORID draft
has been available in largely the same form for 28 months.  M3UA draft
12 was approved RFC 3332 in September 2002.

The IG started life as an errata document rather than an extension
draft, and wound up only addressing a few errors or clarifications to
the original protocol.  Aside from the registration extensions described
in draft-bidulock-sigtran-regext-00.txt (first released January 2003),
also incorporated by SUA, the IG has not incorporated any extension
drafts.

There are certainly not the same reasons to advance M3UA v02 as there
were for M3UA v01.  It would certainly be good to resolve these major
issues that have been outstanding from before v01, before advancing
another technically deficient version.

--brian

Antonio Cañete (ML/EEM) wrote:                                                     (Fri, 07 May 2004 15:49:57)
> Hi Tolga,
> 
> Mmm, the problem is that Brian's draft expired long time ago and it should
> be an RFC to be able to have it as a normative reference in the M3UA RFC. In
> addition, in order to work, it requires a new parameter "Correlation Id" in
> the ASPAC, ASPAC-ACK, DATA, BEAT and BEAT-ACK messages, which is not
> On the other hand, the procedures I mentioned can be used by any
> implementation without impacting the protocol. Regardless of the terminology
> used in MTP3, the mechanism is applicable to our purposes.
> 
> Best regards/
> Antonio
> 

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