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

From: Schwarzbauer Hanns Juergen <[email-masked]>
Date: Mon, 5 May 2003 14:01:15 +0200

dear all,

especially in case of a peer-to-peer protocol whith almost certainly two different craftspersons involved, not only the side detecting problems has to be infomed but also the peer. 
Therefore I support the proposal of Rohan.

HannsJuergen

> -----Ursprüngliche Nachricht-----
> Von: Brian F. G. Bidulock [mailto:[email-masked]]
> Gesendet: Montag, 5. Mai 2003 13:14
> An: Rohan Pascal S Goveas
> Cc: pardeep; Tom George; SIGTRAN e-mail list
> Betreff: Re: [Sigtran] Need for One More message Type in M2PA?
> 
> 
> 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
> 
> On Mon, 05 May 2003, Rohan Pascal S Goveas wrote:
> 
> > 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
> 
> -- 
> 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
> 
_______________________________________________
Sigtran mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/sigtran

---

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

Schwarzbauer,

M2PA provides an SS7 link.  There is no such message or function
in SS7.  The local craftsperson has no information about version
incompatibility of SS7 links.  As the SS7 management system provides
no mechanism in SS7 MIB for notifying local craftsperson of such an
even, there is no need for M2PA to provide such a signal.

M2UA, M3UA, etc have their own defined LM entity which includes many
features outside the scope of SS7 MIBs necessitated by the nature
of the protocol.  M2PA does not define a spearate LM entity and it is
expected that the SS7 LM entity will be used as defined and that M2PA
will just be another "link".

Providing such a signal would require the definition of a new LM entity
for M2PA or expanding the Q.752.1/ANSI T1.116/... MIBs.  MTP3b Q.2140
SSCOP based links do not expand these MIBs.

Compatibility rules for SS7 links are such that an older version must
interwork with a newer version (forward compatability) and a newer
version must interwork with an older version (backward compatability).
It is clear that the same expectation can be placed on M2PA because of
the special needs of SS7 adminstration regardless of the policies of
the IETF concerning version compatability.  With SS7 version compatability
principles (see Q.700) such an error must never be generated (because
all version are compatible).

IMO no such ERROR message is necessary or desirable.

--brian