Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

RE: [RPRWG] The potential RPR market



Dear Harmen,
 
    Related to the on-going preemption discussions and how
high priority, low-latency & jitter is handled, I agree
that high speed RPR ring does not need preemption, but the
lower speed one does.
 
    I would like to go back to "broad market potential"
requirements, and would like to hear from the Service Provider
community on this subject. 
     How many of the rings in the metro that already has OC3
     ~ OC12 rings in a SONET infrastructure will be retrofitted
     w/ RPR for packet services? 
 
    My assumption in this had been that if a vendor installs new
equipment, it would be the latest and fastest available box, because
installation and upgrade cost out-weigh box cost.  So the percentage
of the retrofit market is relatively minimal.  If this is the case,
lower speed MAC behavior could live outside of the standard.  If this
is not the case, then we must define a single preemption behavior
for all speeds of operation (again the second if, if the group
wants to entertain the objective of supporting this high priority
low latency & jitter class). 
 
    Would someone from the Service Provider community provide some
feedback on this retrofit market?
 
regards,
 
Yong.
 

============================================
Yongbum "Yong" Kim      Direct (408)922-7502
Technical Director      Mobile (408)887-1058
3151 Zanker Road        Fax    (408)922-7530
San Jose, CA 95134      Main   (408)501-7800
ybkim@xxxxxxxxxxxx      www.broadcom.com
============================================
 

-----Original Message-----
From: owner-stds-802-17@xxxxxxxx [mailto:owner-stds-802-17@xxxxxxxx]On Behalf Of Harmen van As
Sent: Friday, April 13, 2001 4:14 AM
To: Sanjay Agrawal
Cc: stds-802-17@xxxxxxxx
Subject: [RPRWG] The potential RPR market

Dear Sanjay
 
I am not worried about delays on super-high speed backbone and regional rings. Here I agree, there is not much to gain by implementing preemption. I am addressing a much and much larger market than telecommunication backbone and regional rings. That market comprises rings and backbone rings for small offices, hotels, major stores, small business centers, hospitals, companies, campus areas, manufactury plants, industrial plants, small public access areas, ships, airplaines, cars, interconnection of base stations of wireless networks, etc., etc.
 
The motivation to install RPR in that market will be resilience and QoS. That market needs also lower speeds rings,  for instance also 100 Mbit/s Ethernet and 155 Mbit/s SONET/SDH or other transmission links in that speed range. If IEEE 802.17 also gains that market, it will be extreme successful. A huge market for the telecomunnication, data and chip industries. I cannot imagine that including the lower speed range would seriously delay the completion of the standard, when there is a group of members that is interested to work out the corresponding details. To my opnion, IEEE 802.17 has nothing to loose by extending the application areas of RPRs.
 
The standard could for instance define that on rings in this lower speed range preemption is allowed and that products with and without preemption as well as cut-through and store-and-forward operations must interwork. On higher speed rings, there is no preemption and here products using cut-through or store-and-forward must operate together.
 
Best regards
Harmen
----- Original Message -----
Sent: Friday, April 13, 2001 5:29 AM
Subject: RE: [RPRWG] Additional comments on preemption, cut-through and store-and-forward

Jumbo frames which are only 9K at 10 Gig will only give you 7.2 micrsecond delay/per node. With 32 nodes this is only 230.4 Microsecond delay.
 
at 2.5 gig it is approximately 1Ms
 
at 40Gig it is only 57 microseconds.
 
For 100msec latency budget, with 50msec consumed by the circumfrence of earth, we still got 50ms of switching latency. What is a big deal in saving few micro seconds in RPR rings. 
 
Real latency we should consider is the queueing latency in rest of the network for voice applications. Class based queueing
with voice class scheduled first is the solution.
 
 
-Sanjay