My $0.02
Pankaj K Jha wrote:
>
>
> 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.
During upgrade the network operator can build a
second ring span by span that replaces the original
ring. However, the moving of data from 1 ring to
the other must be accomplished by the box and cannot
be done by the RPR network card. Some boxes will
have a single card that does both east and west. Other
boxes might split this up into 2 cards, but the east
and west cards require a passthru path for the traffic
continuing around the ring. It is not easy to provide
a method that allows different rate cards to be
hooked up. However, at the box level the appropriate
queuing mechanisms can exist to handle the rate mismatch
appropriately.
>
> 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).
For mesh networks this can be true. However, for a metro
area the customer's we're talking to tend to roll out the
highest BW available everywhere to provide them with
maximum lifetime before an upgrade.
>
> 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.
If the idea is to have a simple MAC chip that does the
transit operation without HUGE buffers or lots of
packet loss I do not agree that it is easy. I agree
that it can be built, but I do not believe that is
what we should be building.
I disagree with most of what is below, but if the whole
thing driving this is making network upgrade easier
I think its a solved problem so I do not understand the
need for additional complexity.
I look forward to reading the paper.
mike
>
> 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
> Principal Architect
> Data Communications Division
> Cypress Semiconductor
> (408) 432 7091
>
> 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
> > President, AmerNet
> > Architecture Analysis and Performance Modeling
> > Specialists
> > Phone: (949)552-1114
13711 Solitaire Way,
> > Irvine, CA 92620
> > Fax: (949)552-1116
e-mail:
> > khaledamer@xxxxxxx