RE: Conflict in IUA and DUA management message for messagetype 5

Hey Ankur, Michael, all

Yes, something has to change, looking at the timeline of events in this
class :-


Starting with RFC3057, the MGMT class was :-

    Management (MGMT) Messages

       0        Error (ERR)
       1        Notify (NTFY)
       2        TEI Status Request
       3        TEI Status Confirm
       4        TEI Status Indication
     5 to 127   Reserved by the IETF
   128 to 255   Reserved for IETF-Defined MGMT extensions

DUA RFC4129, then extended this by adding :-

        5        DLC Status Request
        6        DLC Status Confirm
        7        DLC Status Indication

RFC4233 comes out with :-

    Management (MGMT) Messages

       0        Error (ERR)
       1        Notify (NTFY)
       2        TEI Status Request
       3        TEI Status Confirm
       4        TEI Status Indication
       5        TEI Query Request
     6 to 127   Reserved by the IETF
   128 to 255   Reserved for IETF-Defined MGMT extensions



Oops - RFC4233 should be :-

    Management (MGMT) Messages

       0        Error (ERR)
       1        Notify (NTFY)
       2        TEI Status Request
       3        TEI Status Confirm
       4        TEI Status Indication
     5 to 7     Defined in RFC4129 (DUA Status)
       8        TEI Query Request
     9 to 127   Reserved by the IETF
   128 to 255   Reserved for IETF-Defined MGMT extensions

Not exactly pretty, but correct.

In the meantime, there is a decision to resolve as to how to handle
implementations that use (or share) the MGMT Type 6. 
(ie, is it a DUA Status Request or a TEI Query Request)?

The SCTP Payload ID could be used, but is not a 100% guarantee.
(Consider ASP with some Q931 and some DPNSS interfaces, if the
implementation is good, then the SCTP PPID would reflect the type of
interface as the message relates to an InteraceID)
IMO, I wouldn't trust this too much, but would aid in decision making.

I've looked DLCI encoding to see if there is a difference there, but no
avail.

In DUA, the DLCI field has a different format, in accordance with the
   ND1301:2001/03 (formerly BTNR 188) [2].

         0                   1
         0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |0 0 0 0 0 0 0|V|0|Channel No.|1|
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

RFC4233 (S = SPR)

         0                   1
         0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |    SAPI     |S|0|     TEI   |1|
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


No 100% way to resolve it in the spec from what I can see, your decision
in how to handle it would have to be based on the provisioning of the
interface.

Cheers,
Mike



-----Original Message-----
From: Michael Tuexen [mailto:[email protected]] 
Sent: 10 June 2006 10:40
To: ankur arora
Cc: [email protected]
Subject: Re: [Sigtran] Conflict in IUA and DUA management message for
messagetype 5

This is a bug... I would suggest to change the number for DUA or IUA in
an Implementers guide. I also don't know how to handle it in
Wireshark...

Best regards
Michael

On Jun 10, 2006, at 8:39 AM, ankur arora wrote:

> Hi,
>
> The IUA latest RFC (RFC 4233) introduced a new management message "TEI

> query request" with message type 5.
> Also, DUA RFC have "DLC Status Reuest" message with same message type 
> 5.
> So, Management messages for IUA (RFC 4233) and DUA have an overlap 
> i.e. the same message type has been used twice.
> Message Group 0 & Message Type 5
> IUA - TEI query request, and
> DUA - DLC status request.
>
> Also according to DUA rfc ,section 4
> "As an option, the IUA value for SCTP Payload Protocol ID MAY also be 
> used for DUA, for instance, if one wanted to backhaul ISDN and DPNSS 
> over the same SCTP association."
> Then how it can be identified whether message received from SCTP with 
> message type 5 is an IUA "TEI query request" or a DUA "DLC Status 
> Reuest".
>
> Regards
> Ank Arora
> __________________________________________________
> Do You Yahoo!?
> Tired of spam? Yahoo! Mail has the best spam protection around 
> http://mail.yahoo.com
>
> _______________________________________________
> Sigtran mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/sigtran


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