Please note that owing to the unidirectional nature of the SCTP streams
the outgoing APSTM and incoming acknowledge will have to use different
streams even if the outgoing and incoming streams share a same integer
value say 1.
Hence I agree with Brain.
Regards,
Prabind
-----Original Message-----
From: Kolomaznik Jan [mailto:[email protected]]
Sent: Tuesday, May 30, 2006 12:38 PM
To: [email protected]
Cc: [email protected]
Subject: RE: [Sigtran] Notices to ASPTM message mapping
Ad 1) I think, it will be better if any recommendation word (like
SHOULD) will be used in talking about a possibility of ASPTM messages
mapping on any SCTP stream carrying data traffic. I agree that in
situations where more than one data traffic streams are used the
minimization of possible packet loss cannot be so high, but in cases
where only one data traffic stream is used it is 100%.
Ad 2) If ASTPM Ack messages will use a data traffic SCTP stream, I do
not see any practical reason for this type of restriction. - But if
ASPTM Ack messages will be transmitted on SCTP stream 0, there is a
theoretical possibility that ASPTM message will be evaluated earlier
than previously sent data message(s). This possibility could happen both
in ASP Active and ASP Inactive procedures. So my meaning is, when a
ASPTM not Ack message used data traffic SCTP stream, the ACK message
should use data traffic SCTP stream also.
The second thing is that from protocol theory point of view the Ack on
different stream than acknowledged message looks not good. So if there
is not any practical reason for changing of stream for Ack message, the
Ack message should use the same stream.
Jan Kolomaznik
-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email protected]]
Sent: Monday, May 29, 2006 8:21 PM
To: Kolomaznik Jan
Cc: [email protected]
Subject: Re: [Sigtran] Notices to ASPTM message mapping
Kolomaznik,
Kolomaznik Jan wrote:
(Mon, 29 May 2006 13:16:15)
>
> Hello,
>
> I would like to share any findings we have made during
implementation
> of SUA in IPSP environment. Our work has been based on RFC 3868
and
> draft-ietf-sigtran-sua-implementor-guide-03.txt. Please send
comments
> if you find out we are not true.
>
>
> 1) Problem with mapping of ASPTM messages on SCTP stream. -
Which
> stream number to use? ... there are two relevant paragraphs in
RFC
> 3868, sua-implementor-guide-03 does not solve this question.
>
> RFC 3868, section 4.2.1:
>
> "All non-Transfer messages, with the exception of ASPTM, BEAT and
BEAT
> Ack messages SHOULD be sent on SCTP stream '0'. ASPTM messages MAY
be
> sent on one of the streams used to carry data traffic related to
the
> Routing Context(s), to minimize possible message loss."
>
> RFC 3868, section 4.3.4.3:
>
> "It is possible for the ASP to receive Data message(s) before the
ASP
> Active Ack message as the ASP Active Ack and Data messages from an
SG
> or IPSP may be sent on different SCTP streams. Message loss
is
> possible, as the ASP does not consider itself in the ASP-ACTIVE
state
> until reception of the ASP Active Ack message."
>
>
> So ASPTM messages MAY be sent on any SCTP stream, but generally it
is
> better to send they on any traffic stream (not on SCTP stream 0).
It
> practically means, a sending entity MAY send it on any SCTP stream
and
> a receiving entity SHOULD be prepared to receive it on any
SCTP
> stream.
Yes. In general, an implementation should be prepared to receive any
message
on any stream.
>
>
> 2) Mapping of ASPTM Ack messages on SCTP stream ... I think it
is
> general principle to be received message acknowledged on the
same
> stream as an acknowledged message has been received - but this
general
> principle is not enforced in RFC 3868 or
> sigtran-sua-implementor-guide-03. This situation may leads to
the
> situation following the next example:
>
> ------------ ASP Active/SCTP stream 1 ----->
>
> <-------- ASP Active Ack/SCTP stream 0 ----
Yes, that is possible. Did you see any reason why it would be necessary
to
restrict the situtation further?
--brian
--
Brian F. G. Bidulock
[email protected]
http://www.openss7.org/
_______________________________________________
Sigtran mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/sigtran
lmpx.com only provides a reader for public news (NNTP) servers. It is not
affiliated with the servers or forums shown here and is not responsible for
the content of articles, which is written by their respective authors.