Subject: RE: SUA, M3UA: Usage of Correlation ID

From: Vairagare Nitin <[email-masked]>
Date: Tue, 11 Dec 2001 15:09:55 -0500

Hi,

Was there any resolution about correlation ID text?
Even in M3UA 10, same ambiguious text appears as earlier.

Needs more clarification and exact procedure on how and when
to use it. if required, seperate ASP and SGP procedures would
be required.

Regards,
Nitin

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]]
Sent: Thursday, November 15, 2001 1:19 PM
To: sigtran
Cc: [email-masked]
Subject: Re: SUA, M3UA: Usage of Correlation ID

John,

Yes, it probably needs clarification for M3UA and SUA.  The
texts is originally from M2UA, where a traffic flow and a stream
are always identical (one link runks on one stream).  In M2UA
it is sufficient that unique Correlation Id identifying the DATA
message be tagged on the first DATA message sent on a stream to
a newly active ASP in the broadcast group.

For M3UA/SUA there is no such relationship between stream and
traffic flow.  The Correlation Id would then have to consist of
a vector of traffic flows and a vector of message identifiers,
such as high 16-bits for traffic flow and low 16-bits for message
id or some such.  Where, I suppose a traffic flow is something
that "could" be placed in its own stream.

Perhaps we should reword the section to use the term "traffic
flow" instead of "stream", and leave the details of Correlation
Id assignment to the implementation.  (It also has a similar
use for Override and Loadshare for avoiding duplication of
messages during failover between associations.)

--brian

John Loughney wrote:                                         (Thu, 15 Nov
2001 15:37:54)
> Hi Samahajan & Brian,
>
> Do you feel like this requires any additional text to the
> drafts?
>
> John
>
>
> >
> > [email-masked] wrote:                            (Thu,
> > 15 Nov 2001 14:41:50)
> > >
> > >
> > >
> > > Hi,
> > >
> > > Usage of Correlation ID parameter is not clear from the
> > following definition, Pl
> > > see some questions below.
> > > "Whenever an ASP in a Broadcast mode AS becomes ASP-ACTIVE, the SGP
> > > MUST tag the first DATA message broadcast in each SCTP stream with
> > > a unique Correlation Id parameter.  The purpose of this
> > > Id is to permit the newly active ASP to synchronize its processing
> > > of traffic in each ordered stream with the other ASPs in the
> > > broadcast group"
> > >
> > > 1) As SGPs within an SG can also be in broadcast Mode, Does
> > the ASP need to
> > > include this parameter when sending data to newly included
> > SGPs in Broadcast
> > > Mode ?
> >
> > I would say yes.
> >
> > > 2) Definition talks about tagging Data in each SCTP stream
> > with a Correlation
> > > ID. Does that mean that if there are multiple ASPs in
> > Broadcast AS and M3UA/SUA
> > > is sending Data to that AS, M3UA/SUA needs to send this
> > Data on the same stream
> > > ID of all the associations towards all those ASPs ? Also
> > Does that imply that
> > > all associations towards ASPs of a Broadcast AS should have
> > same number of
> > > streams ?
> >
> > I would say yes, and yes the way it is stated.  If the Correlation ID
> > parameter is sent to tag each flow (and the ASP and SGP know what a
> > flow is), then it would be independent of the number of streams.  But
> > this is stuff for a later load selection extension draft.
> >
> > > 3) Whenever a new ASP becomes Active in Broadcast Mode and
> > next Data message is
> > > sent to that AS, should M3UA/SUA include Correlation ID in
> > Data message towards
> > > that newly Active ASP only Or in Data message towards all
> > ASPs in that AS?
> >
> > It is only necessary for newly active ASPs so that newly
> > active ASPs can
> > tell where they are "coming into" the broadcast group.
> >
> > > 4) Is there a requirement for the policy of choosing unique
> > value of Correlation
> > > ID? Is it reasonable to choose one of following two policies?
> > >     a) Send same value of correlation ID in Data message
> > (may be equal to RC of
> > > AS)  whenever a ASP becomes Active in a Broadcast AS
> > >     b) Choose a default value of Correlation ID at the time
> > of provision of AS (
> > > Static or dynamic). Increment it while sending it in Data
> > message, whenever a
> > > ASP becomes Active in a Broadcast AS.
> >
> > The intention was that when the first ASP becomes active that
> > the SGP tag
> > data messages in streams (flows) to that ASP.  The receiving ASP would
> > increment the correlation id for each subsequent message
> > received and the
> > SG would increment for each message sent.  When a newly
> > active ASP joins
> > the broadcast group, the SG would tag the first messages sent
> > in each stream
> > (flow) with the current count (Correlation Id) for that
> > message so that
> > the joining ASP can tell where in the data stream it have joined the
> > broadcast group.  This gives the newly joining ASP the
> > ability to determine
> > whether particular messages were processed by another ASP in
> > the group and
> > coordinate its entry point into processing messages in a given flow.
> >
> > Saying "unique Correlation Id parameter" doesn't really say
> > that.  What
> > I describe is that the SG tags the messages to a newly Active ASP with
> > the Correlation Id referenced to what was tagged to other ASPs already
> > active in the broadcast group.
> >
> > --brian
> >
> > >
> > >
> > > Best Regards,
> > > -Sandeep
> > >
> > >
> > >
> > >
> > >
> > > ---
> > > You are currently subscribed to sigtran as: [email-masked]
> > > To unsubscribe send a blank email to
> > [email-masked]
> >
> > --
> > Brian F. G. Bidulock
> > [email-masked]
> > http://www.openss7.org/
> >
> >
> > ---
> > You are currently subscribed to sigtran as: [email-masked]
> > To unsubscribe send a blank email to
> > [email-masked]
> >
>
>
> ---
> You are currently subscribed to sigtran as: [email-masked]
> To unsubscribe send a blank email to
[email-masked]

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

---
You are currently subscribed to sigtran as: [email-masked]
To unsubscribe send a blank email to
[email-masked]

---
You are currently subscribed to sigtran as: [email-masked]
To unsubscribe send a blank email to [email-masked]