[Sigtran] I-D draft-hunt-sigtran-iua-rate-message-00: IUA message backward compatibility

[<juan.harrison at bt.com>]

Hi all,

1.	Background

1.1	I-D "IUA Extension for Rate Control Message"
draft-hunt-sigtran-iua-rate-message-00 proposes an extension to IUA
[RFC4233] to support the use of an Overload Control Agent in the
Signalling Gateway.  A new IUA message (ASPCAR) and its corresponding
acknowledgement message (ASPCAR Ack) are defined along with a new
parameter and related procedures.

1.2	This extension is intended to be optional on each side [MGC and
SG] of the IUA interface.  Therefore, one of the procedural features
proposed in the I-D is that when a MGC supports the extension it should
be able to discover the corresponding capability of the SG.  This allows
the MGC to suppress unnecessary subsequent attempts to invoke the I-D
procedures and also allows the possibility of the MGC following
alternative overload control strategies (which are outside the scope of
I-D draft-hunt-sigtran-iua-rate-message-00).  A straightforward method
to achieve this aim might be based on the new (ASPCAR) message being
recognised or not by the SG.

1.3	Unfortunately, the IUA unsupported message type handling
procedure defined in RFC4233 (sub-clause 7.2.2) is rather weak.  True,
it is mandatory for an IUA entity to respond to receipt of an
unsupported message type by returning an ERR message with Error Code
value "unsupported message type".  But, as the Diagnostic Information
parameter in the ERR message remains optional, there is no mandatory
unambiguous correlation between the ERR "unsupported message type"
report and the offending unsupported message.  Without such direct
correlation the usefulness of the procedure remains limited.

1.4	Furthermore, the content of the Diagnostics Information field in
the Diagnostics Information parameter is not unambiguously defined by
RFC4233.

2.	Questions
In the light of the background summarised above, in order to review I-D
draft-hunt-sigtran-iua-rate-message-00 (in particular sub-clause 5.1), I
would very much appreciate your experience and views on the following
questions:

2.1	Is it the case that, if an existing implementation of IUA has to
invoke its unsupported message type procedure, it is likely (or not) to
include in the ERR message the Diagnostics Information identifying the
offending message?

2.2	If Diagnostics Information is included to identify the offending
unsupported message, is an existing implementation of IUA likely to:
a)	provide just the common message header of the offending message?
b)	provide the full offending message?
c)	provide any other "information germane to the error condition"
in addition to, or in place of, (a) or (b) above?

Thank you for you consideration of this matter.

Best regards,

Juan
BT Innovate & Design 
Tel: +44 (0) 2087262737 
Mob: +44 (0) 7801321140 
Email: juan.harrison at bt.com 
Web: www.bt.com 
This email contains BT information, which may be privileged or
confidential. It's meant only for the individual(s) or entity named
above. If you're not the intended recipient, note that disclosing,
copying, distributing or using this information is prohibited. If you've
received this email in error, please let me know immediately on the
email address above. Thank you.
We monitor our email system, and may record your emails. 
British Telecommunications plc
Registered office: 81 Newgate Street London EC1A 7AJ
Registered in England no: 1800000