Media Coverage

Carrier Class Ethernet Transport

By Sean Buckley, Telecommunications Online

Mick Reeve knows a thing or two about carrier Ethernet will have on today’s service provider network. As a former 35-year veteran of BT, who was most recently the chief architect of BT’s 21CN initiative. Reeve, who now heads up Mixtel, an independent telecommunications consulting agency, sat down with Telecommunications Magazine Editor Sean Buckley to discuss how emerging technologies such as CET (Carrier Ethernet Transport) and the emerging IEEE PBB-TE (Provider Backbone Bridging)-Tunnel Engineering standard and the complementary PBT (Provider Backbone Transport) element will make an impact on the service provider’s next-gen transport network architecture.

TM: As the former architect of BT’s 21CN, you were at the forefront of one of the most groundbreaking network transitions in the telecom industry. What is the significance of CET in the movement to the next-generation network?

Reeve: It’s useful to make distinction between Ethernet as a customer service and Ethernet as transport. Both of them have been growing gangbusters. As broadband has taken off so rapidly via ADSL, ADSL2+, VDSL and even FTTH, backhaul speeds have gone up enough, and the efficiency of carrying those backhaul speeds back from DSLAMs to the core of the network over SONET/SDH has been in question. When you reach Gigabit Ethernet speeds, it becomes costly to do that with SDH, so people start to look at Ethernet as a lower cost transport technology for broadband and business services.

The other [trend] is the growth of Ethernet services. As DSL has taken off you get customers replacing E1/T1 links with DSL and what would you carry over DSL would carry over that DSL but Ethernet. Maybe you would not get quite the timing and bandwidth assurance you get out of T1, but it would be a hell of a lot cheaper. That’s been one of the drivers for move over from low-speed TDM circuits to carrier Ethernet. As you increase the amounts of those speeds that drives faster backhaul speeds. The true Ethernet requirements came from small enterprises up through corporate that want 10-100 Mbps connections to their enterprise, and the lowest cost way of doing that was with Ethernet. Tier one [carriers] saw competitive operators offering those services below the cost of their SDH/SONET-based services. Each of those [trends] tend to be slightly separate, but they all conspire together to move you towards an Ethernet-based network.

The expectation is that carriers would be able to ride on the installed-based of enterprise switching to produce a lower-cost alternative than SONET, ATM, Frame, or even MPLS. Some of that logic may be dubious. Nevertheless, if you look at the cost of an Ethernet switch versus the cost of a router, Ethernet switches are considerably cheaper. When you are looking at transport versus services, there’s a push towards Ethernet, which initially had a number of deficiencies to act as a carrier-class transport [mechanism] or service. PBT came in as part of the story to fix those deficiencies.

TM: One of the emerging nuances driving CET is PBT (Packet Backbone Transport) and PBB-TE, an emerging IEEE standard. From where you sit, what’s driving the need for PBB-TE/PBT?

Reeve: If you look at what tends to happen with Ethernet as a service and transport, carriers were looking for ways to separate one customer from another and route by customer and service. Typically the way that would happen is they would use VLAN tags, and if the VLAN tags embedded in the MAC header the customer gave over then there was a lack of transparency because the customer might want to use those. As a result, other VLAN tags were added or they would add MPLS headers and carry over MPLS.

In both of those cases, BT saw a difficulty in the sense that both of those headers are quite short, and that means you don’t have the ability to have true source/destinations in those headers. You would then end up swapping every link. That’s how MPLS and VLAN headers work today. An Ethernet packet comes in from a customer and then a carrier adds a VLAN tag or a MPLS tag. In the case of the MPLS tag, they were short and were swapped every link, so the ability to trace the route through the network when you’re trying to assure an SLA was dependent on those VLAN or MPLS swapping tables not being corrupted. If they were corrupted, you would certainly trace the wrong route.

BT saw that problem could be fixed by having a somewhat larger header. PBT chooses a MAC header to do that so you would not need to change because like an IP header it would stay the same for the duration of the route. PBT turns off all the MAC learning and broadcast that builds the routing table and populates the routing tables from a management system. The MAC learning and broadcast was one of the scalability issues of Ethernet.

As the scale of the network gets bigger it becomes a limit that leads to huge amounts of signaling, broadcast storms, and maybe delays as networks change. Simply turning that off and configuring the routing table for the management system, which is what PBT does, means you set the routes up through the network very much as you would do for an SDH or ATM route. It gives the operator an Ethernet-based transport with many of the same sorts of characteristics of SONET/SDH. You can set up resilient routes and develop fixed routes where you have planned maintenance to do. It’s a very comfortable thing for an operator and it does not have the scalability limits Ethernet had in its original format.

At some point in the future, you may go back to a control plane to set up those tables more automatically in the same people are doing for optical routes.

As a first step, [BT] wanted to get them under a management system control and therefore to avoid the scalability issues of Ethernet. Because you were turning stuff off, the expectation it would and not lead to higher prices for the hardware. You have to add that management system, and the expectation at BT was that we could repurpose the SDH management system we had already.

TM: What’s your sense of the various vendor approaches to CET and PBB-TE?

Reeve: To answer that question, we need to understand the synergies between Ethernet and optical. There was work at BT that said you would always need three modes: the bottom was a circuit-switched optical domain, the middle was a connection packet, and the top was a connectionless packet. We had been debating the connection-oriented packet, which was a mess because we had ATM, FR, MPLS and PBT. We were pushing for PBT. In the circuit domain you had SONET/SDH, and the question was what would the future be? I was looking at G.709, which used to be called digital wrapping, which was a way to add SDH-like framing to anything. If you think about taking PBT and granularity in the Gigabit layer or above, then carrying those channels over G.709 rather than having a SONET/SDH layer, it becomes a relatively simple higher bandwidth future.

There was a synergy emerging on the way you switch at the optical layer and at Layer-2 packet layer. If you begin to layer those in a correct way then you potentially end up with a simple network structure that can scale very high and forms a lower cost structure than say an SDH-based structure. When you look at what Meriton is doing, they are aiming in that direction from a ROADM structure switching from a G.709 future and TDM in the middle to a PBT-like switching structure at Layer 2. That forms a very synergistic transport approach that I quite like and we’ll probably see others doing as well. What we would of said in BT is that the service layer is really IP. At the IP layer, you’re seeing the real end-user services such as VoIP, and the connection-oriented packets and the circuit switch are basic transport services and things that carry users. There’s quite a lot of synergy between how you arrange the connection-oriented packet and the circuit switch, which is something that Meriton is pioneering.

TM: Certainly, no standards effort is easy. How is the PBB-TE standard effort progressing within the IEEE?

Reeve: I had a long call recently with the chair of the PBB-TE group, and what we’re seeing is that the battle lines being drawn. Some vendors are supporting and some vendors are against it. In practice there’s quite a bit of work to do and transport MPLS is ahead, but, and it’s quite a big but, when you look what to do in both in PBT there’s some very minor tweaks to how the packets are routed. The IEEE guys don’t expect that to be a big piece of work. What is a big piece of work is working out operations and maintenance issues. The interesting thing is that the transport MPLS standard has exactly the same stuff to do. Still, the standards bodies are telling me that they think in order to get to stable silicon, PBT could be finishing up by the end of this year.

The other area where T-MPLS is slightly ahead is the way that different sorts of services are mapped into MPLS such as ATM, FR and Ethernet. I think PBT can reuse that stuff. In many ways the way we are seeing PBT being proposed to be used in pure Ethernet networks, you don’t need those mappings anyway. I think the answer is we could see PBT be standardized for silicon guys to be comfortable. I think the message is there’s work to do in the standards.