[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Routing drafts



Title: RE: Routing drafts

Greg

Yes I recall the discussions on this. The bandwidth summaries are
the minimal amount of information to make a routing decision. They
do not cover all of the detail that could be in a timeslot map.
Integers are definitely not dynamic enough. The issue is that even
if you have this detailed information you still have to augment
signaling with the capability to deal with glare conditions. So
our strategy was not to overburden routing with this information
but to put the capability in signaling.

Don

-----Original Message-----
>From: Bernstein, Greg [mailto:GregB@ciena.com]
>Sent: Monday, February 25, 2002 8:32 PM
>To: Fedyk, Don [BL60:1A00:EXCH]; Kireeti Kompella; ccamp@ops.ietf.org
>Subject: RE: Routing drafts.
>
>
>Actually floating point is overkill for TDM.  We'd like to use small
>integers to describe and update them more frequently. 
>The TDM multiplexing is straight forward but unforgiving.
>We had this same discussion when we decided to breakout the labels
>for SONET/SDH GMPLS signaling.  I want to know that I've got 14
>STS-1 of capacity, XX unused VT1.5, etc...  For those SONET/SDH
>systems that have to deal with timeslot inflexibility (i.e.,
>fragementations issues) more complete information on time slot
>usage is advantageous.  For example with rings that don't
>have Time Slot Interchange, a map of the timeslots could
>be helpful.  Eric and I had a bunch of stuff about this in
>our earlier routing drafts.
>
>Greg B.
>
>--------------------------------------------------------------------------------------
>Dr. Greg M. Bernstein, Sr. Director Technology, Ciena Corp.
 
>-----Original Message-----
>From: Don Fedyk [mailto:dwfedyk@nortelnetworks.com]
>Sent: Monday, February 25, 2002 4:07 PM
>To: Bernstein, Greg; Kireeti Kompella; ccamp@ops.ietf.org
>Subject: RE: Routing drafts
>
>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.
>>