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

["Naidu, Venkata" <[e-mail]>]

Jens,

-> 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?

  Yes, there were some drafts proposed to solve this, for example:
  http://www.watersprings.org/pub/id/draft-ma-ospf-isis-te-00.txt
  But, this draft is proposed after the IGP TEs are standardized.

  I don't think the granularity and accuracy of the bandwidth
  is an important issue. Because, the dynamics of network changes
  and router re-optimizations (for example, average sampling
  over a period of time) don't depict the exact amount of
  bandwidth of a link somewhere in the network, any way.

  Yes, increasing and space to represent future high-speed
  links is an issue to consider.

Venkata.