Subject: [Sigtran] M3UA : Correlation Id in DATA

From: "Vikas" <[email-masked]>
Date: Mon, 25 Feb 2002 19:27:23 +0530

hi,
kindly help and/or confirm in following doubts related
to Correlation Id in DATA(M3UA):

1. should ASPs and SGPs include Correlation Id in all
DATA messages for broadcast mode AS.

2. i think at SG, one counter (for the purpose of
assigning increasing Correlation Ids) will be
maintained per broadcast mode AS. i think if the SG
has 3 SGP and all are serving this AS then the SGPs
will share the same counter instead of each SGP having
its own  counter for the AS.

3. let ASP1 is maintaining a counter for a broadcast
mode AS and let its current value is 2. now ASP1
receives DATA for same AS with Correlation Id = 4
(suppose on stream Id 1) and then it receives DATA for
for same AS with Correlation Id = 3 (suppose on stream
Id 2). now please suggest me how to handle? should
ASP1 buffer DATA with Correlation Id = 4 unless DATA
with Correlation Id = 3 is received or some
implementation timer expires.

With Advance Thanx.
Vikas.

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 25 Feb 2002 13:39:28 -0600

Vikas,

See comments below...

Vikas wrote:                                                (Mon, 25 Feb 2002 19:27:23)
>    DATA messages for broadcast mode AS.

No, that was not the intention.  It was the intention that
the first message sent in each stream (traffic flow, really)
to an ASP which has just become active for a broadcast AS
be tagged with a Correlation Id.  The ASP then knows where
in the broadcast traffic flow it has joined the AS.

>    its own  counter for the AS.

It is possible to share counters, however, an implementation
needs to derive a unique Correlation Id from this counter for
each traffic flow (e.g, add 2^24 for each of 256 traffic
flows).  But this is quite implementation dependent.

>    implementation timer expires.

It is not the intention that Correlation Id be used to
reorder data in M3UA for broadcast AS.  If you are interested
in an approach which permits failover between associations
and limits message loss, duplication and missequencing, see
draft-bidulock-sigtran-corrid-00.txt.

In the scenario you present, the receiving ASP has joined
the stream Id 1 traffic flow at message CID=4 and has joined
the stream Id 2 traffic flow at message CID=3.

--brian

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

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