Greg you wrote:
> (b) Big issue -- The parameters for representing bandwidth on
> a link are not
> very appropriate for TDM signals or WDM signals. I've
> included below some
> more explanation taken from the IPO working group draft.
> However, this is
> the same thing that led to us breaking out the traffic
> descriptor stuff in
> GMPLS signaling for the SONET/SDH case. This is really
> needed here too.
>
These bandwidths in our draft are exact floating point numbers.
Are you saying that the resolution of the floating point is an issue
with optical? Or are you implying that bandwidths are percentages ?
The text below is implying that statistical multiplexing can use
inexact bandwidth but optical can (and should) use exact bandwidths.
I did not see problems with the floating point range or our draft.
Don
> (From IPO working group draft on Inter-domain optical routing)
> 2.3 Differences between MPLS and Optical Circuit routing
>
> The bandwidth accounting needed in optical circuit-switched
> networks is also
> different than in packet networks. In packet networks using
> either ATM QoS
> or MPLS-TE, complex statistical measures are used to
> characterize the load
> on a link, often with varying degrees of accuracy. The
> inexactness of such
> measures and the "compressibility" of statistically
> multiplexed traffic
> imply that a small percentage change in link utilization can
> usually be
> absorbed by the network.
>
> By contrast, if an OC-192 link has just one STS-1 path
> occupied (less than
> 1% of the link bandwidth), it cannot accommodate an STS-192c
> path. Due to
> the relatively simple finite multiplex structures currently
> use in optical
> networks tracking bandwidth resources is much easier than
> packet switched
> networks, however much stricter bandwidth accounting is
> required on circuit
> switched links. In particular, it is expected that an
> individual optical
> circuit switched link can be fully utilized, while due to
> queuing effects a
> packet switched link on average can never be run at full
> capacity and is
> typically run at less then 80% of capacity.
>
> Greg B.
>
>
>