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   >   >>
Honestly 12/5/2012 | 3:53:52 AM
re: BT Issues 21CN Ethernet RFP http://www.byteandswitch.com/d...
davallan 12/5/2012 | 3:53:53 AM
re: BT Issues 21CN Ethernet RFP Hi Metroman:

Don't think you're groking the difference between path placement to manage the traffic matrix vs using a routing system or STP, aka altruistic mode of operation. ULtimately comes down to how far you are sweating the assets, and as I noted before you'd not combine high over subscription, same class and fast OAM togther, no business rationalization for that combination of attributes.

The sky is not falling...

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

It's not about keeping it apart, that is easy. It's about ensuring that even though the total amount of traffic on your network is not great, you will have points of congestion. You still have to remember that these are Ethernet switches you are proposing to use - they do not have complex QoS mechanisms (multiple levels of WRED for example).

I am not sure if you have personally implemented any of these kind of devices but they are not that robust and you need to treat them with kid gloves. when you are dealing with 10s of milliseconds you need to be 100% sure that you will never have congestion issues otherwise you may suffer a cascade of failures. In this case you may flap some PBT sessions (perhaps only unideirectionally) resulting in loading other parts of the network, this could cause a chain reaction of load that takes the whole network down. I am not saying that this is a likely scenario, but you have to err on the side of caution. I personally think that this will give operators many sleepless nights and create an OPEX overhead that is impossible to manage.

The result - vendors come up with more and more robust systems to handle the traffic and control load..... history repeating.

As for AIS on the edge. What I mean is on the BEB. The BEB is inside the OAM domain, it's connected access layer devices such as CPE or DSLAM etc might not run any OAM with the BEB. If the BEB can detect link down then it can signal to the remote BEBs using AIS that its link to the device has failed and to use a different route. Basically signalling into the OAM domain about failures of devices attached to the domain. Within the domain, you have connection verification working in any case so do you need AIS also? Perhaps the trace and loopback tools are a better bet?

The whole PBT argument is a bit of a smokescreen I am beginning to believe. I think that operators have started to understand just how tough it is to run MSTP networks (that's why many who started with MSTP are migrating or have migrated to MPLS based approaches) that some people have come up with a way of doing something that is Ethernet but without *STP. The truth is that with the limitations in PBT of Multicast, Broadcast and multipoint, there will be limited use for PBT.

davallan 12/5/2012 | 3:53:55 AM
re: BT Issues 21CN Ethernet RFP Hi again metroman...

You guessed right for BEB (backbone edge bridge), but it is 802.1ah not a Nortel specific term. I'd not seen it such that I remembered it...

AIS does alarm management as well as notification. In essence "someone already knows this is broken so if you detect a problem as well, do not alarm". A means of controlling alarm storms at the NE level...

I'm not getting your reference to needing "AIS running on the edge device"...

Class marking is how you'd keep non-PBT and PBT traffic apart IF you chose to run STP (for example) side by side with PBT... Which is pretty close to the same toolkit you get running E-LSPs and LDP side by side... If that is scary to you, the problem is bigger than you think..

metroman 12/5/2012 | 3:53:55 AM
re: BT Issues 21CN Ethernet RFP BEB is how Nortel refer to the Ingress/Egress bridge of a PBBN network. They did not have a glossary in the document I have from them but the Diagrams have a BEB es the edge device (Backbone Edge Bridge??) and a BCB as the provider babckbone bridge.

It is not my own reference to AIS origination and in fact it has nothing to do with the cost. AIS holds a link down, the recommended 1 second allows the network to be sure that when a "MEP" fails to see an AIS message for 3.5 times the timer it will restore the connection. You don't want to restore connections prematurely so having a 1 second timer seems appropriate to me also.

When you have CCM, why would you need AIS? I would think that AIS was of more use as a means of identifying a connected device that was not down but not participating in the OAM interactions in the provider network. This would allow other devices to flush MAC tables and fail over to other links even though the PBT circuit was operational. AIS therefore needs to be running on the edge device.

What do you think is a real world target for failover between PBT tunnels?

I think you fail to note one key espect of these networks - not all traffic will be PBT - this means that however you attempt to manage capacity, your instances of STP will certainly cause congestion points even if you do not over subscribe. The lack of TE in these networks is scary - sure if you just ran PBT then fine, but you cannot.

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

Glad you did your homework...;-)

1) Database is an entry per source MEP, which for PBT is no different than 802.1ag would require now, the delta is a source will originate more packets for p2p vs. mp2mp (fairly effortless endeavour) but the destination load is no different, and for anything less than full mesh, actually reduced.

2) Yo0u made a lot of references to the cost of AIS origination. IMO fairly trivial as this is simply originating copies of the same message. Also it only is really occuring when there is nothing else to do, when things are broken...

AIS reception is mutually exclusive of CCM reception so load is not cumulative, you'd get one OR the other for a given peer MEP.

Finally as AIS is sent only when things are broken, there is little to impede the message, the upstream tap got turned off...

3) PBT is targeted at an engineered traffic matrix. If you choose to run your network at significant oversubscription AND 3.5msec CCM periodicity AND common priority for both traffic and OAM you MAY run into problems, heck its obvious you'd run into problems. I cannot imagine that combination making business sense.

4) PBT is infrastructure, a.k.a 802.1ah B-MAC layer, so I'm not sure where you get the idea that an Ethernet layer DOS attack can happen. Customer forwarding information only plays at the edge (wrap and ship for ELINE).

5) References to PBT and CPE in the same sentence do not make sense to be, there is no PBT UNI envisioned.

6) IMO BFD already has additional overhead due to the IP/UDP encap. and most implementations pre-disposition to maintaining that even when it makes no sense...

Incidentally, you seem to like the term BEB? Which in this context does not appear to be Binary Exponential Backoff, (which is what BEB+Ethernet googles to). Care to enlighten me (us?)


metroman 12/5/2012 | 3:53:56 AM
re: BT Issues 21CN Ethernet RFP SO I should have done this research before I started asking questions:

As far as I can tell the following is true:

In the Ethernet OAM standards the key element is a Continuity Check Message (CCM) which is sent by one managed entity to another (BEB to BEB in PBT terms). These use either a Multicast address to reach all managed entities or a unicast address for point to point services. Clearly we are talking about unicast here as PBT is point to point. CCM can be sent every 3.3msec to 10 minutes. If the sending entity does not receive CCM for 3.5 times it's own configured sending rate it determines that the service is down.
Therefore the quickest possible identification of loss of connectivity is 11.55msec. The end systems need to process each CCM and populate a CCM database associated with every destination entity.

(There are a large number of other OAM options in Y.1731 - loopback messages, RDI, test signals etc)

AIS in used to signal when a failure has happened. The managing entity will send AIS frames away from the point of failure every 3.3msec - 10 minutes - the recommendation is 1 every second. These AIS messages are unicast and can only be used in Point to Point services. So an Ethernet switch adjacent to a failure will send an AIS message every second to all entry points of all services that pass through it.... this could be a very large number as these are aggregation/core deployed devices.

The devices initiating the CCM messages will have to create them and packetise them and send them with exceptionally accurate regularity in order to achieve these numbers. As I suggested in a previous message these CCM messages are sent in the standard dataplane (with a unicast DA MAC) and therefore need to be delivered as though they were high priority control plane frames. Any network architecture with Head of line blocking issues, congestion issues or poor QoS will see these frames go missing and PBT sessions will flap. Any DoS attack to an intermediate device/s could cause sessions to flap.

The ingress BEB will have to handle many PBT sessions and all of the MSTP control plane processing plus other SNMP and related operational control requirements. If there is any mixing of dataplane and control plane data you are likely to see process performance degradation and the need to throttle back the CCM messages. In addition to this operators need to allow for double the processing capacity at least to allow for BEB failure and the need to maintain backup PBT sessions. CCM transmission speeds are a global parameter so they cannot be configured differently per service to deliver different failover rates.

The problem here is one of scalability. AIS I guess is most likely to be implemented at the BEB to signal a loss of connectivity to a CPE or DSLAM etc. I doubt, given that CCM exists, wether AIS will be used in the operator network as it adds process load where it is not required.

So the BEB has to handle enough process capacity for probably >100 PBT sessions (plus another >100 sessions as backup), all of the MSTP for Multicast, Broadcast and multipoint services, AIS for CPE/CLE failure and all other control and management functions. Any device which has any dataplane/control plane mixing needs to be analysed very carefully. Process priority is critical. My guess is that CCM frames will be sent at a rate of 1-3 seconds (much like BFD or aggresively throttled IGPs are today) giving a failover in the range of 4-11 seconds.

I would like to understand how the failure of a BEB would be handled when a dual-homed CPE/CLE/DSLAM is connected - how do you determine the primary BEB and how does failover actually happen? I assume some combination of the CCM/AIS and spanning tree?


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

OK - the messages are relayed at each hop rather than processed. Thanks - these are the words I have been struggling for.

Ethernet switches do not relay anything - I am not sure what, in the architecture of an Ethernet switch would allow it to relay anything?

If this is being relayed in the dataplane as you suggest then are you saying that:

AIS data is sent by the ingress with a destination address of the B-VID/B-MAC so that it follows the path of that PBT session. The data is simply forwarded as a standard packet based on the static filters in place?

As far as I know this is the only way that an Ethernet switch could relay anything.

By doing this you will need to prioritise these AIS frames to ensure that they arrive with limited jitter and no loss. Otherwise in congestion conditions you will start flapping links. After what period of AIS frame loss does the destination BEB decide that the link is down? I assume that as this AIS is bi-directional the ingress and egress BEBs will failover at almost the same time - but not at exactly the same time - this will be dependent upon network dimensions?

This is the special sauce I was refering to.... AFAIK Ethernet switches do not behave this way - they are mostly "store and forward" devices. It would also make sense that they work in the way I describe as they will need to determine which PBT tunnels to take down so the AIS needs to be linked to each PBT and the PBT is identified by the B-VID/B-MAC tuple. - If not, how does the AIS follow the same path? - why don't you just forward the packets this way....?


davallan 12/5/2012 | 3:53:56 AM
re: BT Issues 21CN Ethernet RFP Hi Belakinabale...

The issue is not queuing delay, it is that control plane messages are terminated and the content processed at each hop...instead of simply relayed.

This introduces an awful lot of latency in the propagation time for any individual token of information...

ockham 12/5/2012 | 3:53:58 AM
re: BT Issues 21CN Ethernet RFP all,

Guess most of us agree that MPLS-based solution is much more scalable, carrier-grade & standard/interoperable than this new PBT thing.
The ONLY dirver I can see for BT is the cost; from they own words "we are concerned about the cost of MPLS"

From my experience in Telecom, the way this will be resolved is quite easy: MPLS-vendors will be forced to squeeze their prices/margins to reach PBT price level (nearby), letting everyone happy, BT will get high-tech HW gear @lower prices and they will keep their market share and business while keeping/killing NT attempt to enter into the Metro Ethernet arena.

BT is just using NT to introduce price pressure on the incumbent providers (CSCO & ALA).

Lets says, this is my prediction, need to admit you do not need to be so smart to came up with this analysis.. ;-)

<<   <   Page 2 / 6   >   >>
Sign In