| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
In traditional TDM networks when a provider installed a OC-192 (for example) or upgraded to a OC-192 ring all nodes on it had to be OC-192 capable. This was a significant exercise, both in time and cost. With packet transmission, it is increasingly popular to have some links run at OC-192 while another section is still running at OC-48 (or even lower). The cost savings are enormous, and speed of installation has significantly improved. (I've read some articles about these, and I might be able to dig out info on it and pass around). When packet based transmission is used with dual rings, it becomes possible and it is easy to design rings where spans do not have equal bandwidth. Now providers can upgrade to a higher speed ring as and when and where needed, instead of worrying about node updates all over the ring. With destination stripping, layer 2 protocols can (with dual ring operation) operate at different bandwidth at different spans. Wrap-arounds may need to take into account different bandwidths on links. In addition, node adjacency discovery may also need to include information about bandwidth on downstream link following the adjacent node. Once these are taken into account, nodes on OC-192 can communicate among themselves at full OC-192 while still communicating with other nodes at OC-48 (or lower) bandwidth. Multicast issues also need to be addressed (depending on which node is RP of a tree, bandwidth implications will change, both for normal and wrap-around cases). Additionally, layer 2 may need a mechanism to propagate bandwidth information to higher layer protocols (maybe through a shim layer) to advise of available downstream & upstream bandwidth. This bandwidth information will equal to lowest of the available bandwidth of all spans between the node and the destination node. I do not have answers/solutions to these yet. I know RPR does not address these. But it should, IMHO. This is one of the benefits providers and users should get when they upgrade to use packet based transport (not just destination-stripping to free up bandwidth). This is a huge saving in installation and operation, and it is worth it. I've just begun working on a model to address bandwidth and multicast issues, following a small meeting a few of us had last week. I'll send out a document with analysis of these issues and a proposed mechanism and request suggestions. Comments are welcome. Regards, Pankaj K Jha
Khaled Amer wrote: Hi RPRers, I have a question:Are different links (spans) on the ring assumed to have equal bandwidth or is this not necessarily the case? Thanks.Khaled Amer |