A bit late, Nortel

From a strategic perspective, this is a good idea for Nortel - spearhead a (for now) a proprietary alternative technology instead of competing with heavy-hitters like CSCO and JNPR on their own turf.

However, it seems that Nortel has a message problem of exactly where this fits in and what its true benefits are, if any.

In addition, I think there is quite a bit of skepticism on the part of Service Providers about putting too much faith in Nortel's ability to deliver and support new features in a timely manner. Betting on PBT will tie you closely to NT whether you like it not - a shaky proposition based on demonstrated performance over the last 6-7 years.

In general, people just don't trust Nortel's technical savvy the way they do Cisco's and Juniper's.

Jim,

I read with great interest your article, "Is MPLS alternative DOA?" I appreciate the disclaimer upfront that you were at an MPLS show and that some competitors went to great lengths to keep the focus on MPLS at the expense of PBT.

I'm sure it comes as no surprise that Nortel would disagree with the theoretical contention that PBT is "DOA." We also do not consider ourselves as a lone wolf either. Other firms in addition to Nortel and Hatteras, including Siemens, Extreme, T-Pack, Meriton, Anda, and Soapstone have all expressed plans to support PBT. As well, when PBT was officially approved as an IEEE project at that body's meeting in March (giving it the name PBB-TE, and the number IEEE 802.1Qay), the vote to do so was unanimous. So while our representative at the Futurenet panel may have been the lone PBT advocate on this panel, Nortel does not stand alone in the industry by any means.

With PBT, we do have a simpler solution that also provides operational advantages, and that will translate to cost savings for providers as they migrate to Ethernet. As you pointed out in your article, PBT metros and MPLS/VPLS cores can in fact co-exist, which is exactly how Nortel views the situation as well.

Thank you for your consideration,

Pat Cooper
PR, Metro Ethernet Networks

My company use the MPLS for the Metro aggrgation about five years. Now, we plan to rapidly expand the network for residential customer internet service. The PBT seem a good solution. Before the PBT solve the point2multipoint problems. We plan to connect the point 2 point serive(internet) from dslam to PBT switch, and still remain the multipoint service in the MPLS vpls domain.

Actually I am shocked that this is still going on. All of these technologies are trying to accomplish what ATM accomplished long ago. I find it even more amusing that most of the MPLS networks I have seen or read about use ATM or Frame to get to the MPLS cloud.

With IP, they came up with RTP so that small voice packets could be prioritized. (IP is a 20 byte header instead of ATM's 5 bytes) If a large frame makes it to an interfaces buffer before and RTP packet does then the traffic still has to wait on the buffer to transmit the large frame. Hello Jitter.

Now in MPLS and other protocols they are attempting to build special Asics that will switch frames with connection oriented intelligence and scheduling.

Personally I think that a good carrier would offer the same service the US Military has come to depend on when they do there global combat simulations.

Here is what I would like to see. A carrier with the engineering knowledge to implement a strong ATM network that includes VBR-RT SVC services that not only allow me to make a perfect voice call but let me do a video call too. All of this is done with similar signaling as what they use in the PSTN and zero of the voice and video data inside IP packets, encrypted if you like! Let us get back to real layer 2 transport by the carrier. Then engineers can get back to capacity planning based on circuit usage and not processor load.

If I had that then I could also have:
* a UBR PVC to an internet pop.
* A VBR-NRT PVC for access to the enterprise network

All of these things were available years ago.
Here are a few myths:

*ATM is limited in bandwidth
False ATM interfaces have been tested up to 40Gbit. They could be faster with the development of better Asics.

*ATM has too much overhead
-Well we are adding 20 bytes of overhead for RTP. This is fine for a LAN but why on the WAN?
- MPLS - Here we are doing a 4 byte header but its IP inside there so 20 + 4 is 24 bytes for and RTP packet and we still have no guarantee of delay variation because the MPLS packet is variable length and you can't do statistical time division with variable length frames. IE if a large frame makes it to the interface buffer before the RTP frame you are waiting. On a congested path if that happens on to many successive hops on the path then I notice on my call.

Also, would somebody please tell the marketing department that solutions to problems come from inventors and engineers, not the marketing and sales?

Actually I am shocked that this is still going on. All of these technologies are trying to accomplish what ATM accomplished long ago. I find it even more amusing that most of the MPLS networks I have seen or read about use ATM or Frame to get to the MPLS cloud.

With IP, they came up with RTP so that small voice packets could be prioritized. (IP is a 20 byte header instead of ATM's 5 bytes) If a large frame makes it to an interfaces buffer before and RTP packet does then the traffic still has to wait on the buffer to transmit the large frame. Hello Jitter.

Now in MPLS and other protocols they are attempting to build special Asics that will switch frames with connection oriented intelligence and scheduling.

Personally I think that a good carrier would offer the same service the US Military has come to depend on when they do there global combat simulations.

Here is what I would like to see. A carrier with the engineering knowledge to implement a strong ATM network that includes VBR-RT SVC services that not only allow me to make a perfect voice call but let me do a video call too. All of this is done with similar signaling as what they use in the PSTN and zero of the voice and video data inside IP packets, encrypted if you like! Let us get back to real layer 2 transport by the carrier. Then engineers can get back to capacity planning based on circuit usage and not processor load.

If I had that then I could also have:
* a UBR PVC to an internet pop.
* A VBR-NRT PVC for access to the enterprise network

All of these things were available years ago.
Here are a few myths:

*ATM is limited in bandwidth
False ATM interfaces have been tested up to 40Gbit. They could be faster with the development of better Asics.

*ATM has too much overhead
-Well we are adding 20 bytes of overhead for RTP. This is fine for a LAN but why on the WAN?
- MPLS - Here we are doing a 4 byte header but its IP inside there so 20 + 4 is 24 bytes for and RTP packet and we still have no guarantee of delay variation because the MPLS packet is variable length and you can't do statistical time division with variable length frames. IE if a large frame makes it to the interface buffer before the RTP frame you are waiting. On a congested path if that happens on to many successive hops on the path then I notice on my call.

Also, would somebody please tell the marketing department that solutions to problems come from inventors and engineers, not the marketing and sales?

Actually I am shocked that this is still going on. All of these technologies are trying to accomplish what ATM accomplished long ago. I find it even more amusing that most of the MPLS networks I have seen or read about use ATM or Frame to get to the MPLS cloud.

With IP, they came up with RTP so that small voice packets could be prioritized. (IP is a 20 byte header instead of ATM's 5 bytes) If a large frame makes it to an interfaces buffer before and RTP packet does then the traffic still has to wait on the buffer to transmit the large frame. Hello Jitter.

Now in MPLS and other protocols they are attempting to build special Asics that will switch frames with connection oriented intelligence and scheduling.

Personally I think that a good carrier would offer the same service the US Military has come to depend on when they do there global combat simulations.

Here is what I would like to see. A carrier with the engineering knowledge to implement a strong ATM network that includes VBR-RT SVC services that not only allow me to make a perfect voice call but let me do a video call too. All of this is done with similar signaling as what they use in the PSTN and zero of the voice and video data inside IP packets, encrypted if you like! Let us get back to real layer 2 transport by the carrier. Then engineers can get back to capacity planning based on circuit usage and not processor load.

If I had that then I could also have:
* a UBR PVC to an internet pop.
* A VBR-NRT PVC for access to the enterprise network

All of these things were available years ago.
Here are a few myths:

*ATM is limited in bandwidth
False ATM interfaces have been tested up to 40Gbit. They could be faster with the development of better Asics.

*ATM has too much overhead
-Well we are adding 20 bytes of overhead for RTP. This is fine for a LAN but why on the WAN?
- MPLS - Here we are doing a 4 byte header but its IP inside there so 20 + 4 is 24 bytes for and RTP packet and we still have no guarantee of delay variation because the MPLS packet is variable length and you can't do statistical time division with variable length frames. IE if a large frame makes it to the interface buffer before the RTP frame you are waiting. On a congested path if that happens on to many successive hops on the path then I notice on my call.

Also, would somebody please tell the marketing department that solutions to problems come from inventors and engineers, not the marketing and sales?