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

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 17 Apr 2002 10:43:55 -0500

Javier,

Javier Pastor-Balbas (ECE) wrote:               (Wed, 17 Apr 2002 16:42:22)
> Hi Brian, 
> 
> My personal view is that all you are saying is not clearly stated in the
> draft (otherwise, say the section where it is). I know it was previously
> discussed but someone not familiar with the discussion that were held in the
> mailing list will probably not understand what you state after reading the
> spec.
> 
> What it is clear is that DATA messages MUST be sent thru any stream
> different to stream #0 (section 4.1.1). And also that you can send and ERROR
> if a management message is received from any stream different to #0 (section
> 3.8.1). But it is not explained what are those management messages... Does
> it refer to MGMT messages class or to ASPSM or to ASPTM?

"Management messages" in the RFC always refers to other
than SSNM, and DATA, which includes ASPSM, ASPTM, MGMT,
RKMM.

Section 4.2.1:

" All non-Transfer and non-SSNM, messages, except BEAT and BEAT Ack, 
" SHOULD be sent with sequenced delivery to ensure ordering.  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.
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

ASPTM and BEAT are clear from the passage above.  Its too bad that
BEAT was not made an ASPTM message becase it would have made stating
these things easier, but there it is.

> 
> It is not either explained or recommended to have a stream separation per
> AS. It is just recommended to send sequenced traffic messages thru the same
> stream (section 1.4.7).

So?

> 
> Therefore, IMO:
>
> - We should specify which are those "management messages" staed in section
> 3.8.1

See section 4.2.1.

>
> - We should leave the option of assigning streams per AS open but not
> mandatory

See section 1.4.7.

> 
> Therefore it seems that the only mandatory messages to be transported thru
> stream zero would be ASPUP/ASPUP_ACK and RKM messages since the rest of the
> management messages (ASPDN, ASPTM, MGMT, SSNM) could be related to a
> specific AS and therefore sent thru any of the streams reserved for that AS.

Could you explain just how ASPDN/Ack can be related to a specific AS?
When ASPUP/Ack cannot?

> This last group of messages could also be optionally sent thru stream #0.
> DATA messages will be never sent thru stream 0 and sequence should be
> ensured when required.
> 
> Do you agree on the general idea of this last paragraph ?

I agree with the statements in the RFC.  We had much discussion about these
three passages.

> 
> If agreed I go along with Umesh about updating this in the Implementor's
> Guide. What do others think?

I don't have a problem with clarifying it in the IG, as long as
it does not change the requirements from the RFC (like moving ASPDN
from one group to another).

--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: Wed, 17 Apr 2002 16:42:22 +0200

Hi Brian, 

My personal view is that all you are saying is not clearly stated in the draft (otherwise, say the section where it is). I know it was previously discussed but someone not familiar with the discussion that were held in the mailing list will probably not understand what you state after reading the spec.

What it is clear is that DATA messages MUST be sent thru any stream different to stream #0 (section 4.1.1). And also that you can send and ERROR if a management message is received from any stream different to #0 (section 3.8.1). But it is not explained what are those management messages... Does it refer to MGMT messages class or to ASPSM or to ASPTM?

It is not either explained or recommended to have a stream separation per AS. It is just recommended to send sequenced traffic messages thru the same stream (section 1.4.7).

Therefore, IMO:
- We should specify which are those "management messages" staed in section 3.8.1
- We should leave the option of assigning streams per AS open but not mandatory

Therefore it seems that the only mandatory messages to be transported thru stream zero would be ASPUP/ASPUP_ACK and RKM messages since the rest of the  management messages (ASPDN, ASPTM, MGMT, SSNM) could be related to a specific AS and therefore sent thru any of the streams reserved for that AS. This last group of messages could also be optionally sent thru stream #0. DATA messages will be never sent thru stream 0 and sequence should be ensured when required.

If agreed I go along with Umesh about updating this in the Implementor's Guide. What do others think?

Cheers // Javier.

> -----Original Message-----
> From: Brian F. G. Bidulock [mailto:[email-masked]]
> Sent: Tuesday, April 16, 2002 3:12 PM
> 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/
>