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

From: "Rohan Pascal S Goveas" <[email-masked]>
Date: Mon, 5 May 2003 19:25:03 +0530

All,
    As Pardeep suggested it will be a good idea to introduce a ERROR
messsage as with other protocols (IUA, M3UA). Moreover  manul intervention
is possible only when the proper error message is convyed.
   In my understanding of other protocols like IUA and M3UA the Error
messages are usually given to a Management entity like layer Management
which may have a interface to the craftperson. We can think on the similar
lines in case of M2PA also.
  If some one still thinks introduction of a ERROR message in M2PA will
serve of no purpose then can  any of the authors of IUA or M3UA give
justified reason for introduction ERROR message in IUA and M3UA ??

-Rohan

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

>
> Subject: Re: [Sigtran] Need for One More message Type in M2PA?
>
>
> > >
> > 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-)
>
> 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--
>
> >
> > 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.
>
> 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--
>
> >
> > 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.
> >
> 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--
>
>
> >
> > > On Mon, 28 Apr 2003, pardeep wrote:
> > >
> > > >
> > > >     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.
> >
> > --
> > * 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
> >
>
> _______________________________________________
> Sigtran mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/sigtran
>

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 5 May 2003 05:13:34 -0600

Rohan,

In M2PA the local craftsperson on the side detecting misconfiguration
can be notified without sending an ERROR message.  As M2PA is a true
peer to peer protocol, this is sufficient.

IUA and M3UA are client/server protocols rather than peer to peer
protocols.  To accomodate the special needs of the client/server
arrangement, it is desired that both client and server be able to
notify the local craftsperson (if one exists).

--brian

-- 
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: Tom George <[email-masked]>
Date: Mon, 05 May 2003 17:40:03 -0500

Pardeep,

I am not opposed to specifying what to do in case of a message received
on the wrong stream. But I am not convinced it is necessary, either. I
would suggest taking the link OOS. 

As for the wrong Message Class or Type, I still do not see the need for
an error message. This would be similar to an invalid field in an MTP2
message. For example, I could not find anything in Q.703 that says what
to do if an LSSU is received with an invalid Status Field. 

tomG.

pardeep wrote:
  [...] 
> 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
> 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
> I think by sending the ERROR we will help the peer in taking the corrective
  [...]