Subject: [Sigtran] Need for One More message Type in M2PA?

From: "pardeep" <[email-masked]>
Date: Mon, 28 Apr 2003 22:18:10 +0530

There are some issues, which M2PA_draft 0.8 isn't addressing. Few of these are
 1. Behavior of M2PA if it receives messages with Invalid Message Class (other than 11) or invalid message_type or invalid message_length or invalid state from peer. 

    Draft is saying that stack should discard these messages. How the peer will come to know what's the problem? It will         keep on sending messages without getting any reply from peer. This may result in bringing the link OOS (in case of any     timer expiry) again in service (in case problem is with user data message type only) & again OOS (on T7 expiry).

 2. Link Status messages received on stream 1 & user data messages received on stream 0.

             Draft isn't discussing this problem.

 3. Resolving the incompatible version.

       Draft is saying that "If a Link Status Alignment message with an unsupported Version is received by the newer                  version, the receiving end's M2PA SHOULD reply with a Link Status Out of Service message and not complete the             alignment procedure".

 How the end with "unsupported version" will come to know about the problem? What's the logic in keeping the association with such a peer & not completing the alignment with it & not telling the peer about the problem? 

 For all the above cases draft 0.8 isn't discussing any mechanism so that affected end can take a corrective action.

 In these scenarios I suggest one more message type "ERROR" with decimal value 3. It will have Common message header, M2PA Header & ERROR CODE. Error Code may have following values 

                        Invalid Version (0x01)

                      Invalid Message Class (0x02)

                        Invalid Message Type (0x03)

                    Unexpected Data (0x04)

 In all the above scenarios M2PA stack can send the message with message type ERROR to peer so that peer can take the appropriate corrective action at his side.

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 28 Apr 2003 14:10:53 -0600

pardeep,

IMO there is no need for another message.

--brian

On Mon, 28 Apr 2003, pardeep wrote:

>     1.  Behavior  of  M2PA  if  it receives messages with Invalid Message
>    Class   (other   than   11)   or   invalid   message_type  or  invalid
>    message_length or invalid state from peer.
> 
>         Draft is saying that stack should discard these messages. How the
>    peer  will  come  to  know what's the problem? It will         keep on
>    sending  messages without getting any reply from peer. This may result
>    in  bringing  the  link OOS (in case of any     timer expiry) again in
>    service  (in case problem is with user data message type only) & again
>    OOS (on T7 expiry).
> 
>            Draft  is saying that "If a Link Status Alignment message with
>    an     unsupported     Version    is    received    by    the    newer
>    version,  the receiving end's M2PA SHOULD reply with a Link Status Out
>    of  Service  message  and  not  complete  the                alignment
>    procedure".
> 
>     How  the  end  with "unsupported version" will come to know about the
>    problem?  What's the logic in keeping the association with such a peer
>    &  not  completing  the alignment with it & not telling the peer about
>    the problem?
> 
>     For  all  the above cases draft 0.8 isn't discussing any mechanism so
>    that affected end can take a corrective action.
> 
>     In  these  scenarios  I  suggest  one  more message type "ERROR" with
>    decimal  value  3.  It  will have Common message header, M2PA Header &
>    ERROR CODE. Error Code may have following values
> 
>                            Invalid Version (0x01)
> 
>     In  all  the  above  scenarios  M2PA  stack can send the message with
>    message  type  ERROR  to  peer  so  that peer can take the appropriate
>    corrective action at his side.

-- 
Brian F. G. Bidulock    ¦ The reasonable man adapts himself to the ¦
[email-masked]    ¦ world; the unreasonable one persists in  ¦
http://www.openss7.org/ ¦ trying  to adapt the  world  to himself. ¦
                        ¦ Therefore  all  progress  depends on the ¦
                        ¦ unreasonable man. -- George Bernard Shaw ¦
_______________________________________________
Sigtran mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/sigtran

---

From: "pardeep" <[email-masked]>
Date: Tue, 29 Apr 2003 10:24:41 +0530

pardeep,

--brian
As I have written some scenarios where it can be useful & informing the peer
will help him to take the corrective actions. Could you please explain for
each scenario why its not required?

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 29 Apr 2003 03:28:00 -0600

pardeep,

Because all it would be indicative of would be a configuration error which
would require manual correction anyway.

--brian

---

From: Tom George <[email-masked]>
Date: Tue, 29 Apr 2003 13:40:23 -0500

Pardeep,

Brian is right. Even if the sender received an error message back, these
problems are so severe that they would require manual intervention
anyway. 

Maybe it would help to think of it in terms of what M2PA would do it
received an error message from its peer. Suppose the error message said
"you are sending status and data on the wrong streams". If you have code
to take care of that, you should have just gotten it right in the first
place. 8-)

If a 2nd version of M2PA is written, it should have its compatibility
with version 1 "designed in". It finds out during alignment (another use
for the alignment procedure) and should not send version 1 anything it
cannot handle.

OTOH, if the implementation of M2PA is so wrong it is sending messages
on the wrong streams of sending messages with bad Message Classes, then
it should not be running. 

tomG.

-- 
* Tom George       PB7-24001 (near B-21)      [email-masked]  *
* 972-519-3168   Intranet:  http://www.ssd.usa.alcatel.com/~tgeorge/  *
* Alcatel;  3400 West Plano Pkwy,  MS PB7-SWPRO;  Plano, Texas 75075  *
* I actively disclaim speaking for Alcatel USA, Inc. I do not purport *
* to advertise or represent its position,  operations, or activities. *
_______________________________________________
Sigtran mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/sigtran

---

From: "pardeep" <[email-masked]>
Date: Tue, 22 Apr 2003 21:02:06 +0530

Subject: Re: [Sigtran] Need for One More message Type in M2PA?

> to take care of that, you should have just gotten it right in the first

I am thinking that Error message in M2PA will help in same way as it is
helping in other Protocols (like IUA, SIP, MEGACO etc) i.e to notify a peer
of an error event associated with an incoming message. As per draft 0.8 M2PA
is just discarding the message (in case of messages on wrong streams it is
not telling what to do.. may be discarding of messages in this case also).
So in these cases Local M2PA (receiver of error message) is neither taking
any action (corrective) at its end nor it is reporting to peer about this.
This may lead to Loop Conditions.

Let I again discuss the error scenarios like receiving messages with Wrong
Message Class, Wrong Message Type & On Wrong Streams.

All these scenarios tell that there is severe problem at peer. I don't think
that there should be any reason to continue with this type of peer until he
takes some corrective action at his end. So instead of just keeping quite,
M2PA can send error message to peer & can break the association. I think
that breaking the association is required in all these cases because in
future also peer will send wrong messages (until he takes some corrective
action & correcting the M2PA code is the only corrective action which peer
can take).

I think by sending the ERROR we will help the peer in taking the corrective
action in the most expeditious way possible.

--Pardeep--

> for the alignment procedure) and should not send version 1 anything it

I was talking of incompatible older version & I think that M2PA peers can
resolve the version before alignment starts. I would like to discuss it.

Let we take the case in which Older Version M2PA starts the alignment
procedure.As per Draft 0.8 after finding that older version is incompatible,
Newer version may or mayn't send Status "OS" to the Older Version. If it
sends then also during T2 Timer older version will ignore it & T2 will
expire in both the cases. Now neither MTP3 or M2PA will come to know why
this happened. They will again try ....again....again & again (we don't know
for how long.. Loop Condition).

Now my suggestion is M2PA peers should resolve the version immediately after
making the association. After establishing the association M2PA peers will
exchange Status "OS". At this time only Newer version will come to know that
Older Version is incompatible. So Newer Version can send the proposed ERROR
message & can break the association. In this case also keeping the
association is of no use until older version upgrades itself. Keeping the
association will be wastage of resources only.

So I think this will also be a good use of ERROR message type. This will be
more efficient also because M2PA's are not waiting till alignment start,
they are resolving it immediately after SCTP association establishes.

--Pardeep--

> it should not be running.
I agree with you that it shouldn't be running & hopeful that in network this
kind of bad implementation will never come. But unfortunately if something
like this comes in network then i think that telling the error & closing the
association will be the good way than just discarding the message.

--Pardeep--

> > >     There  are some issues, which M2PA_draft 0.8 isn't addressing. Few
of
> > >    these are
> > >     2.  Link  Status  messages  received on stream 1 & user data
messages
> > >    received on stream 0.