Ethernet equipment

BT Issues 21CN Ethernet RFP

BT Group plc (NYSE: BT; London: BTA) has issued a major Ethernet equipment Invitation to Tender (ITT) for its £10 billion (US$18.7 billion) 21CN next-generation network project, Light Reading has learned.

Having finally signed deals with its eight "preferred suppliers" for IP, transmission, and access equipment, the British carrier has now issued its ITT -- more commonly known as an RFP (request for proposal) -- for the systems that will power its future Ethernet services. (See Vendors Sign BT 21CN Contracts and BT Closes 21CN Deals, Touts IPTV.)

News that the ITT is already in circulation among vendors comes just days after Matt Beal, the 21CN program director, told the audience at Light Reading's Ethernet Expo: Europe 2006 that "Ethernet is across the entirety of 21CN, with reach through more than 5,500 exchanges, and Ethernet over optical. Ethernet is seen as the racehorse in the network now that it has reach and capacity capabilities not previously thought possible." (See 21CN: It's an Ethernet Thing.)

A year ago, BT's CTO Matt Bross also eulogized about Ethernet and the role it will play in BT's future. (See BT's Bross: Ethernet Will Deliver.)

BT says this new ITT process is completely separate from the initial network equipment tender and procurement process and covers the full range of carrier Ethernet capabilities, thereby opening the 21CN door for vendors that missed out on the initial contract awards.

And it's likely that the Ethernet sector's vendors will be falling over themselves to get involved. While BT is playing hardball with its suppliers in terms of pricing, making it a tough project to be involved in financially, the 21CN program is probably the most high-profile and radical telecom network overhaul process in the world, and provides the systems suppliers involved with an unparalleled shop window for their NGN technology. (See BT's Learning From Google.)

Details about the ITT's detail -- the potential value of the available deals and the exact technical requirements -- are scarce, as the vendors stick to BT's non-disclosure requirements for fear of being ousted from the process. BT says it is spending about £3.4 billion ($6.3 billion) of its £10 billion ($18.7 billion) 21CN budget on the initial contracts with its eight "preferred suppliers," but it is not giving any guidance about the planned capital expenditure to be used on Ethernet gear.

It's also not known when BT will select and name its Ethernet suppliers, or when shipping and deployment will begin. The carrier plans to switch off its current multiple networks and run all its services on the 21CN in 2010, but there are already signs that such an aggressive timetable might be subject to change. (See BT Says 21CN Deadline Hasn't Moved.)

Some vendors, under condition of anonymity, confirmed that the ITT document is wide-ranging in terms of its requirements, and shows that BT is preparing to deploy a number of different technologies to enable Ethernet services for corporate and, ultimately, residential customers.

Specialist Ethernet vendors, though, may already be resigned to playing a secondary role, at best, in the equipment supply process. One firm told Light Reading that BT's procurement policies mean the major infrastructure vendors will almost certainly be handed the contracts, and that any specialist Ethernet firms will then have to collaborate with those major suppliers.

That's the way BT approached its initial equipment deals: Eight major vendor partners were chosen and are delivering products and services from multiple partners as well as their own wares. (See Fujitsu Shares Its 21CN Success, BT's 21CN: Metro Partners Under Wraps , Ericsson to Bring Partners to 21CN Party, Alcatel Names Its 21CN Partners, and Siemens Unveils 21CN Partners.)

The list of specialist Ethernet vendors that could respond to BT's ITT document is long, but if they need to team up with a major vendor to get a foot in the door, then Alcatel (NYSE: ALA; Paris: CGEP:PA), Ciena Corp. (NYSE: CIEN), Cisco Systems Inc. (Nasdaq: CSCO), Ericsson AB (Nasdaq: ERIC), Lucent Technologies Inc. (NYSE: LU), and Nortel Networks Ltd. would be the most likely partners. Alcatel is well placed, having recently provided BT with technology for its existing Virtual Private LAN service. (See BT Picks Alcatel VPLS .)

News of the Ethernet RFP comes days after SIP application server firm Ubiquity Software Corp. (London: UBQ) announced its involvement in the "common capabilities," or service creation and development platform, stage of the 21CN process. (See Ubiquity Leads New Round of 21CN Deals.)

This means BT Wholesale, the division of BT that is managing the 21CN program, is juggling a number of different 21CN processes that it needs to run and develop in tandem:

  • The deployment and testing of the access, IP, and transmission systems as specified in the initial round of equipment contracts. The first 21CN metro region, in South Wales, is set to switch to a VOIP-only platform in March 2007. (See BT Takes 21CN 'Baby Step' and BT Says 21CN Deadline Hasn't Moved.)

  • The procurement and ordering of Ethernet-specific systems that will need to be integrated with the first round of new hardware.

  • The "common capabilities" process -- BT is set to announce deals with multiple specialist service creation platform specialists that will provide the building blocks for new services and applications.

  • The integration of, and migration to, a number of new multiservice OSS platforms that will ultimately replace the multiple legacy operational and business support systems that underpin each of BT's current services, of which there are hundreds. (See BT Uses JDSU for 21CN, Tektronix Joins 21CN, BT Awards Monster OSS Deal, BT Pins Down OSS Deals, and BT Uses MetaSolv OSS.)

  • The rollout and integration of video-over-broadband systems. BT is to launch video-on-demand (VOD) services later this year over its current DSL access network, but the video systems supporting those services will need to be deployed and planned with a view to 21CN integration. (See Microsoft Wins at BT.)
— Ray Le Maistre, International News Editor, Light Reading

<<   <   Page 3 / 6   >   >>
mtb826 12/5/2012 | 3:54:14 AM
re: BT Issues 21CN Ethernet RFP We are missing a significant point here. Let's say that PBT and MPLS are equal, they are not, but let's just pretend for a minute. That doesn't make legacy L2 switches carrier grade products for NGN deployments. There is no buffering, separation, per subscriber accounting, per service accounting, high availability features, separation of FIBs, adequate resiliency methods. You can't throw Black Diamonds, BigIrons, or a 6500s and expect to have a carrier class network TEE HEE (couldnGÇÖt resist). You still need to architect a next-gen product to support this immature protocol.

No the Neptune isn't it, that's just NT trying to re-spin a product that has failed many times over.

In the end you'll still need a carrier class product and that costs $$$. There are Ethernet MPLS boxes out there that are << then M series and GSRs, for example the 7600s or 7450s. IGÇÖm sure Juniper will be introducing a similar product within the year. You'll need something similar to scale PBT, PBB, MAC-in-MAC or whatever you want to call it.

There has been work done on PBT, but the protocol is still in its infancy. You wouldn't have deployed carrier class services over MPLS in its inception and you aren't going to do it with PBT. It's several years away from prime time and in the meantime MPLS is building momentum.

I wish BT luck.
davallan 12/5/2012 | 3:54:14 AM
re: BT Issues 21CN Ethernet RFP desi:

I think you lost the plot...

PBT/Ethernet is a PSN replacement. Ethernet is going to be there anyway, so ask a bit more of it and delayer the network.

PWoPBT ironically looks just like PHPd MPLS on the wire except that I get full instrumentation of the PSN as it now extends e2e more or less for free. As PWs are already not really optimal, there seemed no point in re-inventing them, but lets be clear it is a common adaptation onto Ethernet, does not alter the ethernet equation itself...

Finally PBT is pretty much Ethernet, it is just static configuration of the forwarding database by management or a control plane, so your suggestion of "why not just use Ethernet switches" rings perhaps truer than you thought...

metroman 12/5/2012 | 3:54:12 AM
re: BT Issues 21CN Ethernet RFP OK - if you are talking about LACP you are suggesting either the use of CWDM or 2 pairs to deliver reslilience? Between every node? By doing that you will also use double the number of physical ports. That's not cheap.

If you are talking about path protection, this means you have to create 2 PBT tunnels from the source to the destination (per class of service, per service (per subscriber in business services)) and you need to find a way of determining when the primary tunnel is down and switching to the backup. Is there a keepalive defined for these tunnels? If not then I assume you are looking for symptoms (local link failures etc) to determine the link is down? What is the retry timer? How long before you really state that the tunnel is down? How long before the backup is forwarding packets? 10 seconds? 20?

You also have double the number of static entries to populate to create the topology.

I am not sure how this is either cheap or simple!

davallan 12/5/2012 | 3:54:12 AM
re: BT Issues 21CN Ethernet RFP Metroman

1:1 Ethernet path switching, also known as global repair in MPLS speak...not L1/L0 resilience

PBT is about Ethernet switched paths...

metroman 12/5/2012 | 3:54:12 AM
re: BT Issues 21CN Ethernet RFP mtb826

At last - someone who sees the wood for the trees!

Now - can anyone actually answer my questions or do I assume that PBT cannot cut it?

Oh and 1:1 protection switching assumes you have a transmission layer... to carry your cheap Ethernet....So you need a nice expensive optical layer to mirror your Black Diamonds, 6500s, Big Irons etc...to make it reliable. Why not use fast re-route and throw the optical gear away?

tmc1 12/5/2012 | 3:54:11 AM
re: BT Issues 21CN Ethernet RFP davallan,

I still have to say that this is another lame attempt by your company (NT) to introduce more protocols that nobody needs (remember CR-LDP?). If there were NOT existing, proven, interoperable solutions that are deployed today that already provide all of this functionality and more I would say fine, let's do it.

However, this is obviously yet another NT attempt to reposition the market because they were unable to build competitive equipment in the current accepted technologies. NT have convinced some people at BT that this is viable by waving the money carrot in front of them. By the time they figure out all the extra costs and you add all the "additional" required features onto this product it will be only marginally cheaper than existing solutions... and more years will have passed. Making this product do everything BT wants for cheap is a complete fantasy.

From a technology standpoint I see these IEEE/NT protocols as a complete distraction.

davallan 12/5/2012 | 3:54:11 AM
re: BT Issues 21CN Ethernet RFP Metroman

802.1ag/Y.1731 gives us the e2e OAM transactions and resiliency triggers.

802.1P/ad marking gives us equivalent of E-LSPs at least as far as strict priority is concerned.

802.1ah means we are carrying multiple services with a single trunk

Two paths popped into the forwarding tables is hardly onerous w.r.t. state or amount of effort. All PS schemes consume at least as much (FRR detours, global repair etc). And they can be node diverse and do not need extra ports.

Desintation based forwarding means core scales O(N), not n**2

Protection switching times are a function of heartbeat rates and/or notifications. Can be < 50 msec. without working up a sweat


metroman 12/5/2012 | 3:54:09 AM
re: BT Issues 21CN Ethernet RFP davallan

<50ms? I would like to understand how you achieve this? As there is no link or node protection in PBB/PBT you are suggesting the use of 802.1ag/Y.1731 to trigger path failover.

Now I have been in this industry for a few years and have seen a great number of attempts to achieve end-to-end path protection in this time and no-one has ever achieved it. Local repairs can happen in this time but there is no local repair in this instance.

Protocol/heartbeat tuning is a very tough issue, make it too aggressive and you get instability, make it too passive and you get slow failover.

You are asking me to believe that using basic Ethernet switches you will trust a heartbeat protocol to reliably and consistently deliver 50ms end-to-end protection? Someone needs to explain how the BCB and BEB devices are to be optimised for such a task (ensuring that every heartbeat frame passes between BCBs and how the BEB has the right amount of CPU capacity and process priority to cope with the volume of messages that need to be handled) Basic ethernet switches have a problem with Spanning tree if you implement too many instances...

Let's take your example - just 2 PBT tunnels (n)from the BEB to other BEBs on the network. (one for best effort and one for delay sensitive) Let's say that you have 15 BEBs (a) on the network that you need to connect to. You have a PBT tunnel backing up each other tunnel (b) this results in: (n*b)*a=60 - so in this relatively small topology you need to maintain heartbeat for 60 sessions and deliver 50ms failover "without working up a sweat"? Oh, and these messages are bi-directional right? So you are sending on 60 sessions and receiving on 60 sessions......

Add to this the need in a PBB environment to maintain MSTP for the remaining VLANs that are not PBT (those required for local services and to handle Broadcast, Multicast and unknown unicast).

This meant to be deployed so that you replace transport mechanisms - this means PBT should be deployed in such a way as to traverse a core network - BT should think about this as they will have thousands of PBT sessions if they deploy in this manner - There is a reason why networks and protocols are built with heirarchies. There is a reason why even MPLS routers cannot achieve 50ms path protection and rely upon FRR to deliver this.

What you are suggesting defies all experience in this industry and I challenge you to explain in detail what "special sauce" you think has been invented and how you continue to retain carrier grade service with cheap Ethernet switches.

davallan 12/5/2012 | 3:54:08 AM
re: BT Issues 21CN Ethernet RFP Metroman

You realize we are discussing with heartbeats a 6 Kbyte flow for trunk carrying multiple services, and with dataplane notifications - AIS - (somthing MPLS does not have) that can be dialed back while still achieving the same response. That's 2-3% of a T1 to put it in context...

MPLS used the control plane for fault propagation, so notification needed to be forwarded and processed hop by hop, and did not propagate with only the latency of the path, that is what FRR is a response to.

Petabit 12/5/2012 | 3:54:07 AM
re: BT Issues 21CN Ethernet RFP What are BEB and BCB, I cannot find them in 802.1ag?

<<   <   Page 3 / 6   >   >>
Sign In