x
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 2 / 6   >   >>
wrobeljas 12/5/2012 | 3:54:26 AM
re: BT Issues 21CN Ethernet RFP On the recent Lightspeed conference I had a chance to speak with a guy who was familiar with Ethernet in carrier networks, and I asked him about MPLS as a solution. He has given me the 21CN project, as an example of a case when MPLS is simply way too costly. He said that initial plan was to use MPLS up to the customer, but lack of HW, and high cost of possible solution, caused BT to heavily revise their plans and go with just Ethernet.

You do not like the idea of cost saving... That is what 21CN is all about !
dask 12/5/2012 | 3:54:24 AM
re: BT Issues 21CN Ethernet RFP I think the fact that ethernet frames are self describing, i.e. where they are coming from and where they are going to, and the fact that there is no label swapping for PBT surely makes PBT more "friendly" to debug and analyze a problem, much more so than MPLS.
desiEngineer 12/5/2012 | 3:54:24 AM
re: BT Issues 21CN Ethernet RFP Petabit: "You really aren't up to date with Ethernet hardware are you? Go and look at the recent vendor press releases, and see that all of those features either already exist, or are due in the next 12 months. While you are at it, it wouldn't hurt you to go and find out how PBT really works rather than just sling wild accusations at it."


What wild accusations? That the OAM is not ready? That the OAM has been visited and revisited? That OAM isn't quite as easy as it sounds and requires more than hardware to get it right?

Or was it that PBT is a manually provisioned SDH type network where the VLAN is not a VLAN but a tag like the generalized label of GMPLS?

Hey, after you've done your provisioning of the network with your SDH OSS tweaked for ethernet, stuck in K1 and K2, modified LAG to look like BLSR, and fixed up whatever you use to do offline traffic engineering, call me if you want a signalled approach to network service establishment.

And you call that a 21st century network :-(

-desi
davallan 12/5/2012 | 3:54:22 AM
re: BT Issues 21CN Ethernet RFP desiEngineer

PBT and VLAN swapping shouldn't be confused. Different ways of manipulating Ethernet...PBT uses VID and MAC together untranslated...

PBT is about how an Ethernet bridge can be a simple L2 cross connect managed or otherwise. GMPLS extensions to add a control plane to do same are fairly trivial. The OAM coming down the pipe means the control plane is optional, not mandatory.


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

You should post your own RFP!

What I will suggest to you is do not assume PBT operation and bridging must mutually exclusive. Key point here is PBT adds to Ethernet capability, it does not re-define it.

MACinMAC does add to the solution space with roughly the same overhead as VPLS/MPLS. This is in addition to being able to ethertype mux just about any protocol on the planet...

As for your final question simply use dataplane resilience as the first line of defence, control plane to back up against multiple failure scenarios.
metroman 12/5/2012 | 3:54:17 AM
re: BT Issues 21CN Ethernet RFP Someone explain to me how this would work in PBT:

A BCB node fails - how does the service recover?
The same node come back on line - how do you return the PBT tunnels through this BCB? Assuming many hundreds of tunnels, how long does this take to do?
How do you deliver different levels of QoS in a PBT tunnel?
As PBT does not forward unknown unicasts, and filters Broadcast and multicast in order to avoid loops, how do you:
a, Create anything other than pt-to-pt bridged services?
b, allow a customer to run an IGP over the PBT?(OSPF uses multicast)
c, Allow for other L2 protocols (STP etc) to run over the PBT tunnel?

How does PBT solve VLAN scaling any better than QinQ - surely you will need a number of PBT tunnels, (each consuming a B-VID) for every business service you offer in order to deliver complete service transparency? If MAC-in-MAC is the answer then what hardware enhancements would be needed to support such a large header construct and what encaps overhead does this create?

Final question - If PBT is only being considered because MPLS is too expensive then how can an operator buy cheap hardware and expect to deliver Carrier Grade services when the technology relies upon an offline management tool to setup services and manage failures/recoveries.....

I fail to be convinced on PBT yet!

Metroman
davallan 12/5/2012 | 3:54:16 AM
re: BT Issues 21CN Ethernet RFP Simplest form is 1:1 protection switching...
metroman 12/5/2012 | 3:54:16 AM
re: BT Issues 21CN Ethernet RFP davallan

Thanks for your reply:

I was reading a paper on PBT and it does seem to suggest that it redefines some aspects of Ethernet. Forwarding, addressing and learning and rooted trees for a start.

What do you mean by "dataplane resilience"? As far as I can see, as you have no spanning tree and all mappings are static you have no method of offering resilisance, what in PBT is offering dataplane resilience?

Metroman
desiEngineer 12/5/2012 | 3:54:15 AM
re: BT Issues 21CN Ethernet RFP PBT has started from way down at the zero-function level. That's how you get cheap.

If you took a pseudo-wire the way it's defined in PWE3, and abstracted the concept, turned off all signalling, you would get PBT.

1. B-VID = PW label (service demarc)
2. MAC-in-MAC = tunnel encap
3. no learning, no flooding (get rid of the major carrier fear of STP, and nail down paths)

What is the particular advantage in PBT, given the scale, say, of BT's operation? Yes, you get rid of MPLS, i.e., the signalling protocol. But you replace that with manual provisioning of everything. That's supposed to be cheap.

What MPLS gives you: self-healing through re-routing paths or global revertive LSP signalling, traffic-engineering, Diffserv-TE, fast re-route: is the claim you don't need that functionality, or is the claim that you can do all those manually because it is still cheaper?

How big is this ethernet service? Does it span the network, i.e., is it just a little ethernet aggregation, or is it connecting a customer site hanging off one PoP to another site hanging off another PoP? Do you build a parallel PBT network to carry the ethernet traffic? That is supposed to be cheap.

If it's just for a local aggregation layer, then, heck, don't wait for PBT, just use existing ethernet switches.

-desi
desiEngineer 12/5/2012 | 3:54:15 AM
re: BT Issues 21CN Ethernet RFP Actually, I may have got the terms mixed up. Is it B-VID + MAC = tunnel encap and whatever the VID (C-VID?) that comes with the customer frame is the PW label.

Incidentally, check out how you can make PBT more expensive by introducing some MPLS into it:

http://www.ietf.org/internet-d...

-desi
<<   <   Page 2 / 6   >   >>
HOME
Sign In
SEARCH
CLOSE
MORE
CLOSE