Question regarding the IEEE floating point format used in RFC 363 0

["Nelke, Jens" <[e-mail]>]

Hi everybody,

I have some questions on the IEEE floating point format. The format contains
a mantissa of 23 Bits. As I understood the floating point format is
calculated by using the 23 Bits beginning with the most significant Bit of a
value together with an appropriate exponent. All values which can be stored
within the 23 Bits (0x7FFFFF->) will be precise, larger values may lead to
rounding errors. Let me show you an example for unreserved bandwidth of what
I mean:

Gigabit Ethernet Interface -> 1000000000 Bits/s -> 125000000 Bytes/s ->
0x7735940 Bytes/s this value fits into the 23 Bit long mantissa.

On this interface a 1 MBit/s LSP is established:

1 MBit/s -> 1000000 Bits/s -> 125000 Bytes/s -> 0x1E848 Bytes/s

After establishing the LSP the unreserved bandwidth would be:

Unreserved Bandwidth -> 124875000 Bytes/s -> 0x77170F8 Bytes/s we would need
a mantissa of 24 Bits to represent this value correct. Because we only have
23 Bits available the value stored in the floating point format would be:

0x77170F0 Bytes/s -> 124874992 Bytes/s

This value would be passed to all other OSPF-TE routers in the network and
would lead to a wrong picture of the bandwidth available.

Does anybody know if during the standardization process this fact was taken
into concern? And how large the bandwidth changes were estimated to be, am I
thinking to small ;-)?

The second problem with the IEEE floating point format is the maximum size
of the interface. Future networks will contain not just 100 MBit and Gigabit
interfaces but also be 10 or 100 Gigabit interfaces. Even 10 Gigabit
interfaces cannot be used correctly with the current format. Example:

10 Gigabit interface -> 10000000000 Bits/s -> 1250000000 Bytes/s ->
0x4A817C80 Bytes/s this leads to 24 Bits being needed to represent this
value. A neighbor would see the following unreserved bandwidth:

0x4A817C00 Bytes/s -> 1249999872 Bytes/s -> 9999998976 Bits/s

This problem is the same as shown above and leads to errors during bandwidth
calculation.

Why weren't the values stored in unsigned long with the units Kilobits/s if
I remember correct this kind of encoding is used in some of the MPLS TE
MIBs.

Is there currently any work done on this issue?

I know that some of the problems can be reduced by using rounding
calculations, but the nicer solution in my opinion would be to use kilobits
per second as a unit for the bandwith stored in a 32 Bit value.

Regards

Jens

----------------------------------------------------------------------------
----------------
Dipl.-Ing. Jens Nelke             KEYMILE GmbH
Entwicklung                         Wohlenbergstr. 3, 30179 Hannover
----------------------------------------------------------------------------
----------------
Phone:   [phone]
Fax:  [phone]       < mailto:[e-mail]
<mailto:[e-mail]> >
< http://keymile.com/ <http://keymile.com/> >
----------------------------------------------------------------------------
----------------