Subject: RE: [Sigtran] M3UA : Messages and Streams

From: "Vats, Umesh" <[email-masked]>
Date: Tue, 16 Apr 2002 08:05:38 -0700

Hi  Brian/Javier

Some explanation of stream mapping is already 
present in draft but its still ambiguous for some
message classes. Can we add following things
clearly in the draft so that everyone has the 
same understanding ?

a. Stream mapping for each message class
b. Some reasoning for this stream mapping

Umesh 

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]]
Sent: Tuesday, April 16, 2002 6:12 AM
To: Javier Pastor-Balbas (ECE)
Cc: Vats, Umesh; [email-masked]'
Subject: Re: [Sigtran] M3UA : Messages and Streams

Javier,

Javier Pastor-Balbas (ECE) wrote:                          (Tue, 16 Apr 2002
14:52:16)
> Hi guys, 
> 
> Reading the RFC again, I can not see a place where all these statements
are clearly stated.
> 
> Sections: 1.4.7, 3.8.1 and 4.1.1 say something about that, 
> 
> Do you think we should complete section 1.4.7 with saying that
>  - DATA message must not be sent thru stream 0 and that 
>  - MGMT (BEAT and NOTIFY) messages MUST be sent thru stream 0
>  - Other messages may be sent thru stream 0 when not correlation is needed
or thru the corresponding stream different of zero when correlation is
required.
> ?
> 
> IMO, since the main reason to send BEAT is to ensure that the M3UA peer is
> alive (independent of AS) it should be sent thru stream 0.

BEAT was excluded from ASPSM and permitted to be sent over streams other
that stream `0' so that a UA could send BEAT with particular heartbeat
data and then know that when the BEAT Ack was received that the data from
the stream upon which it was sent has been flushed to the peer.  This
parallels changeback procedures in MTP3.  BEAT must remain on stream

There is also a purpose to sending NTFY messages on a stream corresponding
to the AS to which they refer.  (For the same reason that ASPTM is sent on
other than stream `0'.)  This is particularly important if per-stream
congestion controls are instituted.

Actually we went to great trouble to ensure that the wording in the
RFC was correct, even if it is not collected together nicely.

--brian

> -----Original Message-----
> From: Brian F. G. Bidulock [mailto:[email-masked]]
> Sent: Tuesday, April 16, 2002 1:50 AM
> To: Vats, Umesh
> Cc: [email-masked]'
> Subject: Re: [Sigtran] M3UA : Messages and Streams
> 
> 
> Umesh,
> 
> Its my understanding that ASPSM and RKM messages *are*
> management messages and must be sent on stream `0'.
> Except for BEAT and BEAT Ack which might be sent on
> a stream corresponding to an AS, depending on the
> reason for the BEAT/Ack.
> 
> IMO ASPTM messages should be sent on the stream that
> corresponds to the AS in question, as should SSNM.
> Where SSNM corresponds to multiple AS (has multiple RCs)
> it could either be sent on stream `0' or another stream
> corresponding to one or more of the AS.
> 
> The RFC is consistent with this interpretation.
> 
> --brian
> 

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

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

---

From: "Javier Pastor-Balbas (ECE)" <[email-masked]>
Date: Thu, 18 Apr 2002 16:48:06 +0200

If everyone is happy with what is stated in the RFC, then this will not be added to the Implementor's Guide.

> Sent: Wednesday, April 17, 2002 11:42 PM
> To: Vats, Umesh
> Cc: Javier Pastor-Balbas (ECE); [email-masked]'
> Vats,
> What's in the RFC works for me.
> 
> --brian
> 
> 
> Vats, Umesh wrote:                                          
> (Wed, 17 Apr 2002 13:58:18)
> > Hi  Brian
> > 
> > I see following references to the message class/stream mappings
> > in draft 12. 
> > 
> > 1. The "Invalid Stream Identifier" error is sent if a 
> message is received 
> >    on an unexpected SCTP stream (e.g., a Management message 
> was received 
> >    on a stream other than "0").
> > 
> > 2. DATA messages MUST be sent on an SCTP stream
> >    other than stream '0'.
> > 
> > 3. ASPTM messages MAY be sent on one of the streams used to 
> carry the data 
> >    traffic related to the Routing Context(s), to minimize 
> possible message 
> >    loss.  BEAT and BEAT Ack messages MAY be sent using out-of-order 
> >    delivery, and MAY be sent on any stream.
> > 
> > >From these three references, one can draw following conclusions :
> > 1. DATA is never sent on stream 0.
> > 2. Management messages (Class 0 messages only as specified in 
> >    section 3.1.2) can be sent on stream 0 only.
> > 3. All other messages (ASPSM, RKM, ASPTM, SSNM) can be sent on any 
> >    stream.
> > 
> > If this is not the intended stream mapping, then some more
> > text is needed in the draft to clarify this. 
> > 
> > Umesh
> > 
> 
> -- 
> Brian F. G. Bidulock
> [email-masked]
> http://www.openss7.org/
>

---

From: "Vats, Umesh" <[email-masked]>
Date: Thu, 18 Apr 2002 08:45:45 -0700

Hi Javier

I  believe that the text in draft 12 is 
ambiguous. Some clarification should be there in
implementor's guide.

No where in the draft it is specified that MGMT messages
must be sent on stream 0. But an example in the ERROR messages
refers to error code  "Invalid Stream Identifier" to be sent
if MGMT message is not received on stream 0?

Some people think MGMT messages comprise of ASPSM and 
RKM messages also. But this is not the understanding of
every one.

IMHO, some clarification is needed.

Umesh

-----Original Message-----
From: Javier Pastor-Balbas (ECE)
[mailto:[email-masked]]
Sent: Thursday, April 18, 2002 7:48 AM
To: [email-masked]'; Vats, Umesh
Cc: Javier Pastor-Balbas (ECE); [email-masked]'
Subject: RE: [Sigtran] M3UA : Messages and Streams

If everyone is happy with what is stated in the RFC, then this will not be
added to the Implementor's Guide.

---

From: "Javier Pastor-Balbas (ECE)" <[email-masked]>
Date: Thu, 18 Apr 2002 17:48:42 +0200

Umesh, 

I also have the same view. We'll work on that.

Cheers // Javier.

> From: Vats, Umesh [mailto:[email-masked]]
> Sent: Thursday, April 18, 2002 5:46 PM
> To: 'Javier Pastor-Balbas (ECE)'; [email-masked]'; Vats, Umesh
> Cc: [email-masked]'