There was a time when standards had to be agreed upon before semiconductor vendors could implement them, but those days are long gone, to judge from today’s announcement by Mindspeed Technologies, a division of Conexant Systems Inc. (Nasdaq: CNXT)
Mindspeed says that it’s developed the first chip to support the proposed IEEE 802.17 Resilient Packet Ring (RPR) standard (see Mindspeed Offers Packet Ring Solution), a technology that aims to give low-cost Ethernet networks some of Sonet’s self-healing capabilities (see IEEE Tunes Ethernet for Telcos).
In fact, Mindspeed’s chip, the CX29950 RingMaker, implements technology called the spacial reuse protocol (SRP) that Cisco Systems Inc. (Nasdaq: CSCO) has been trying to get standardized for a couple of years. It forms the basis of Cisco’s Dynamic Packet Transport (DPT) equipment that’s already in use in Internet service providers’ points of presence, cable networks, and (oddly enough) some metropolitan area networks in China (see Cisco's Second String).
So, how can Mindspeed wave a magic wand and turn its SRP chip into an RPR one? And is this some sinister Cisco standards plot in the making?
Mindspeed says it’s nothing of the sort. It acknowledges that it might need to tinker with its chip to bring it into line with whatever standard comes out of the IEEE. “We will make any modifications required,” says Lauren Schlicht, product line manager for Mindspeed’s broadband internetworking systems unit.
However, Schlicht isn’t expecting major changes, because the IEEE is likely to limit the scope of the RPR standard to bridging between rings. The upshot is that proprietary technologies, such as Cisco's SRP, will continue to be used within rings. Carriers accept that they won't be able to mix equipment from different vendors on the same ring, according to Schlicht.
Cisco’s biggest competitor in this field, Nortel Networks Corp. (NYSE/Toronto: NT), has its own ring technology called Optera Packet Edge (see http://www.nortelnetworks.com/products/01/optera/packet_edge/doclib.html for details). Right now, Nortel has embedded its ring technology in some of its products but hasn’t encouraged other vendors to adopt it in the way Cisco has with SRP.
Schlicht says that Mindspeed is already working with nine vendors (in addition to Cisco) that are using its CX29950 RingMaker to develop equipment. So far, only one of them -- Riverstone Networks -- has announced an SRP-based product.
All the same, nine vendors developing SRP-based products equate to a fair amount of support for whatever Cisco submits to the IEEE working group developing the RPR standard.
One fly in the ointment could be that the current version of Cisco's DPT has a fundamental problem -- that it won't support DiffServ (differentiated services), a crucial standard for enabling service providers to offer different grades of service at different prices, according to Juha Heinanen, the CTO of Telia Finland (a subsidiary of Sweden's Telia AB) and an Internet infrastructure guru.
The problem stems from the fact that DPT only supports two traffic
classes that have a strict priority relationship, according to
Heinanen. "DiffServ requires more than two traffic classes, each with
its own configurable buffer space and scheduling weight," he says. "Also, within each class, it should be possible to assign
packets a different level of drop precedence." This isn't possible with DPT.
Heinanen also points to problems with the way in which DPT ensures that attached equipment doesn't hog access. "DPT's FDDI-like, node-based fairness concept would need to be redesigned in order to make RPR DiffServ compatible," he says.
It's clear that Dynarc downplays their use of DTM. They say that they will still use DTM internally and for special applications, but will otherwise focus on RPR.
I guess that this decision is from a marketing point of view - they noticed that the world isn't interested in a proprierty technology even if solves a lot of problems.
>It is not, believe me. It has been done on more >predictable connection-oriented, call-based >systems (StrataCom's IPX being an example) and >it was far from easy. Plus the caluclation tools >were only rough approximations. Not good enough >for a true service infrastructure.
Certainly, trying to calculate things to the nearest 1% on a circuit-oriented architecture is difficult.
We are not talking about a circuit-oriented network. This is a packet network based on MPLS (no RSVP setup end-to-end LSPs). Also, the granularity of incremental bandwidth we are discussion is 10Gb/s. So, are you saying you don't think you can calculate the size of intercity links to the nearest 10Gb?
>How do you do that with IP? Please tell us more >about the simplicity of IP backbone traffic >management. Without MPLS, too. You seem to know >something the rest of the IP industry doesn't. >It is far from simple. Even RSVP and DS do not >entirely seem to provide a theoretical, let >alone practical, framework to solve this.
We are talking about MPLS, but not because of its traffic-engineering potential. MPLS is utilized as an abstraction layer to allow other services to be layered on top (such as VPNs). If you are trying to calculate traffic to within some small fraction of accuracy, I would agree that it becomes near imposible. But, we are talking about getting it close enough to figure out how many 10Gb paths you want between each city pair.
One approach could be:
1) Start off with a network that is probably larger than you need (this network is probably already in place for existing carriers).
2) Using that network, build a traffic matrix of traffic between city pairs. Use sampling of traffic and routing tables at each city to build the matrix.
3) Build a model with the topology and costs of links in your network and overlay the traffic model. This can be done. Vendors are willing to do it for you if the in-house expertise doesn't exist. Nortel and Cisco were both willing to do this for me (even though I had in-house staff capable of it already).
4) Run through all of the failure scenarios you care about including interface failures, router failures, city failures, route cuts, etc. Each failure will predictably move the traffic to other links throughout your network based on your topology and the costs of your links. This is the same link-state algorithm that OSPF or IS-IS utilizes (your just running it offline).
5) From the results, you will be able to predict how large each link in your network needs to be to handle normal traffic plus all of the failure scenarios that you modeled.
Once the network is configured in this fashion, you will also be able to monitor link utilization on an on-going basis. You should find that many links are "under-utilized" under normal operating condition because thier capacity is there for the failure scenarios.
I don't think this is that hard. The model does not have to be perfect, just to the nearest 10Gb/sec link. Admittedly, if you want to attempt this in your own organization, you should have a staff of experienced model builders and simulation people. But, a few of these are cheap compared to the money you will save on the network design.
> ..This is a simple network capacity design > issue that can be calculated offline...
It is not, believe me. It has been done on more predictable connection-oriented, call-based systems (StrataCom's IPX being an example) and it was far from easy. Plus the caluclation tools were only rough approximations. Not good enough for a true service infrastructure.
> You calculate the maximum capacity you need on > any given link...
How do you do that with IP? Please tell us more about the simplicity of IP backbone traffic management. Without MPLS, too. You seem to know something the rest of the IP industry doesn't. :-)
It is far from simple. Even RSVP and DS do not entirely seem to provide a theoretical, let alone practical, framework to solve this.
>But there is the issue of QoS due to the >additional load. How will these destination >cope with the additional traffic?
This is a simple network capacity design issue that can be calculated offline. You calculate the maximum capacity you need on any given link based on every failure scenario you wish to protect the network from. You then size the links appropriately. Note, a network designed this way does not run all of its links at high capacity. But this is still far more efficient than any of the 1+x or circuit-based mesh mechanisms. This also does not require bandwidth allocation or real-time circuit-oriented re-routing.
I have not had enough exposure to the technology to truly be able to have an educated opinion/guess... I will probably come across it is the near future, though.
> Layer 3 re-routes packets during a link failure > to the "best" destination. Packets will get re- > routed out many interfaces at many routers > throughout the network ...
This is nothing new. Check something as old as Nortel's DPN-100 X.25 packet switches. They did all of this. The Internet is less revolutionary than most people seem to assume. This is done with vector routing tables, every n-th packet that passes ups the routing vector to the next destination. But there is the issue of QoS due to the additional load. How will these destination cope with the additional traffic?
This stuff is good for best effort service. I agree completely. But the Internet has to move away from that to truly become an infrastructure. That is the challenge we all have to deliver on for this industry to deliver on its current promises. And ss soon as you want to handle some QoS, though, it gets far more complex.
I have dealt with many Tier 1 Backbone routers. The Internet part of the network that I architected was in the top 10 tier 1 providers. I completely understand the problems of today's routers. Lets not confuse what is possible with todays implementation with what could be done with a little effort.
What is easier: Creating new Layer 1 protocols and swapping all of the interfaces to it, or simply updating the routing protocols to be more efficient in thier convergence? The papers I refer to are not papers from Universities, they are papers from the two largest vendors that implement the hardware. The Layer 3 mechanisms differ a great deal from the Layer 1 approach:
Layer 1 tends to re-route entire links around a link failure with another Layer 1 parallel path at the point of the failure with no knowledge of what is best for the Layer 3 protocols riding on top. Of course there are many variations: 4FBLSR, UPSR, Mesh, etc..
Layer 3 re-routes packets during a link failure to the "best" destination. Packets will get re-routed out many interfaces at many routers throughout the network. The re-routing is a distributed calculation. The result is a far better topology after a failure. This can be done while maintaining QOS. Notice that I am not talking about MPLS fast-reroute or any other statefull circuit-like-based algorithms. This is simply a speeded up version OSPF or IS-IS with QOS queuing implemented on every interface.
Since a close friend of mine works on the DPT thing, I truly wish it the best. But on the other hand, as I mentioned somewhere else, when you see Cisco kind of spreading its bet, you tend to get sceptical about the fate of DPT. I know it was kind of in crisis even among its closest supportetrs not long ago. It seems to have recovered.
I do agree with all you say. In my opinion, relaibility is something you can architect. There are different options, you pick to your needs. QoS is another matter, and that worries me, because personally I feel that is where the market might lose faith in the Optical Internet infrastructure. If all you can implement is $9.95 a month best effort internet access crap, I am sorry, but then as an industry we have been blowing smoke for way too long.
The blogs and comments are the opinions only of the writers and do not reflect the views of Light Reading. They are no substitute for your own research and should not be relied upon for trading or any other purpose.
To save this item to your list of favorite Light Reading content so you can find it later in your Profile page, click the "Save It" button next to the item.
If you found this interesting or useful, please use the links to the services below to share it with other readers. You will need a free account with each service to share an item via that service.
Digg
Del.icio.us
Reddit
