x

Carriers Face Ethernet 'Black Hole'

Ethernet may be a hot topic in telecom at the moment, but carriers face an OSS black hole when it comes to provisioning and billing for Ethernet-based services.

This was one of the main messages to come out of the Light Reading LIVE! event, "Ethernet Services: A Carrier Class," held in Atlanta last week (see Carriers Converge on Ethernet).

Presenters made a strong case for deploying Ethernet services, but the audience, containing representative from more than 100 carriers, voiced concerns that back-office systems to automate service fulfillment, assurance, and billing simply didn't exist at present. As a result, pioneers in this field faced the prospect of having to use manual processes to undertake these tasks -- something that would have an adverse effect on both operating costs and customer relations.

One attendee at the event, Fred Cook, principal network design engineer at Sprint Corp. (NYSE: FON), told Boardwatch that being first to offer Ethernet services had other downsides. Carriers might benefit from pent-up customer demand, but they faced paying twice as much for their equipment as competitors that hung back until volume shipments had started driving down prices.

Read the full story on Boardwatch. — Ray Le Maistre, International Editor, Boardwatch

Page 1 / 5   >   >>
heisenberg 12/4/2012 | 11:55:36 PM
re: Carriers Face Ethernet 'Black Hole' "and call it VNDL - Virtual Net Definition Language- TM"

And get sued by Wandel (or whatever they ar ecalled) guys.
literight 12/4/2012 | 11:55:49 PM
re: Carriers Face Ethernet 'Black Hole' .....

If you define a modeling language that allows for answers to these questions, you can fairly completely describe almost any collection of network devices, services, and topologies.
------------------------------------------
beautiful!

did you say you were a provider? should be able to make it better as a s/w vendor :)
------------------------------------------
and call it VNDL - Virtual Net Definition Language- TM
literight 12/4/2012 | 11:55:49 PM
re: Carriers Face Ethernet 'Black Hole' .....

If you define a modeling language that allows for answers to these questions, you can fairly completely describe almost any collection of network devices, services, and topologies.
------------------------------------------
beautiful!

did you say you were a provider? should be able to make it better as a s/w vendor :)
route_66 12/4/2012 | 11:55:55 PM
re: Carriers Face Ethernet 'Black Hole' heisenberg wrote:
"Let me ask you this though. You said that you have very flexible metadata for representing objects that your system does care about. Does that mean you have some basic abstract constructs for things like, let's say, connections, vlans, cards, ports, cables etc.?"
---
Yep, you've just named a bunch of the basic building blocks. The most basic classes of objects defined in the metadata include those above, as well as containers such as hub and region. These are extensible as well.

A useful way to think about such modeling is to ask the following questions:
* What fields should be collected about this element?
* To what class of devices does this element belong?
* To what other devices/containers can it be attached?
* Can it be used to connect elements?

If you define a modeling language that allows for answers to these questions, you can fairly completely describe almost any collection of network devices, services, and topologies.

--kirby
heisenberg 12/4/2012 | 11:55:57 PM
re: Carriers Face Ethernet 'Black Hole' Kirby,

thank you so much for shedding some light on how provisionning systems should be done. In my opinion, you guys really have it done right. This is truly stunning especially considering the fact of how many people out there are attemting to build "off-shelf" provisionning systems that do not come anywhere close to what you guys have done.. I just don't understand what is so difficult about these concepts. To me it all sounds like common sense.. Why can't those NMS vendors build something worthwhile?

Let me ask you this though. You said that you have very flexible metadata for representing objects that your system does care about. Does that mean you have some basic abstract constructs for things like, let's say, connections, vlans, cards, ports, cables etc.?

H
route_66 12/4/2012 | 11:55:58 PM
re: Carriers Face Ethernet 'Black Hole' heisenberg wrote:
---
What you need to have is a connectivity model (I know I say it again and people will throw stones at me) that is very extensible and flexible, yet provides a rigid framework. That should govern common behaviours of most or all of your managed objects.

On the bottom of the stack you should have fairly simple mediation mappers. Those would map network element specifics into the nice object-oriented model. This layer should be invoked for polling/audit (resyncs) and for activation or deployment (whatever you call them) functions.
...
Have you ever heard anything about Masergy's network managemnt system? It's completely home cooked, but it's great and is based around concepts I've been talking about in my last X posts here. Most importantly it's completely based on a generic model....
------------------------
As the architect of that system, I can provide some insight on our implementation experience.

We started with an extremely flexible schema for representing our object model. The model itself is defined in a custom regular grammar (metadata). This is the key to vendor- and functionally-independent systems. The entire storage and user interface are data-driven based upon metadata designed by engineers, not software developers.

The second important thing decision was to use a sparse data model. This is where most standards go wrong (CIM, TMN, DEN, etc.) Storing lots of random physical hardware and inventory data, or trying to accurately model every possible routing feature lead to both infinite development cycles and unauditable data. We model only things we can verify.

Once you have strongly audited data, and collect exactly the vendor-independent configuration information required to strongly model configurations, hierarchy and connectivity, you can drive all other configuration management (CM) and fault management (FM) activities.

We've talked to literally dozens of CM vendors (Dorado, Orchestream, Network Mantra...), and seen none that start with true vendor and service abstraction, or allow significant flexibility in designing your service activation automation.

Face it, you can't get COTS systems to do this work for you -- not that we haven't tried. Designing the system ourselves has given us the ability to provide customer-facing automation, completely audited network configurations, and rapid service deployment.

--kirby
jim_smith 12/4/2012 | 11:56:01 PM
re: Carriers Face Ethernet 'Black Hole' ... is the root of the problem that hasn't been mentioned: organizational "fiefdoms".

... must be turned into a written procedure.


These are somewhat related.

Fiefdoms are not the root of the problem: they are the fruit. The root of the problem is what some have mentioned before: no one has figured out a way to automate network operations. If it is possible to run a complex 10,000 node network with a small staff, then fiefdoms will be out of the question.

The IT departments across the industry are also facing a very similar problem. IBM and others have started a consotium that is trying to come up with computer systems that can "heal" themselves, i.e., it doesn't take an army of IT professionals to keep the systems running smoothly. I don't know how successful that is going to be, but I think that's the only way out of the fiefdom issue.

Take Google for example. Their search engine consists of a large network of Linux (or is it BSD?) machines. Apparently, whenever a node in this network fails, they simply remove the machine and replace it with another one. They can do that because they were really smart when they designed the system. Of course, they are dealing with a much simpler solution than a Telco network, but unless technology becomes mature enough to allow such simple operational procedures, fiefdoms will exist.

Engineers cannot write exhaustive procedures because the technology is so damn complex. Operations is more likely to be "lazy" than "stupid". Part of the laziness is because they are unionized and don't have an incentive to go the extra mile.
gbennett 12/4/2012 | 11:56:03 PM
re: Carriers Face Ethernet 'Black Hole' Hi heisenberg,

what if your application framework allows you to manage other boxes, but at the moment you manage only your box?

Hmmm. OK, but this sounds a bit like a company that makes a network adapter. They write device drivers for a bunch of operating systems. At first all is well, but after a while they find they're having to support so many operating systems that their support staff is getting overloaded.

Worse still is that they aren't getting much revenue to fund this support model. Who pays Vendor A (the folks who write the management apps) to support networks elements made by vendors B..Z? Probably not vendors B..Z, or at least not all of them, because they may make competitive network elements, and competitive (but perhaps inferior) NMS's.

And, unfortunately, not the customer. Many customers expect the NMS to come "for free" with the network elements. I'd agree that this is less true in the carrier OSS space, but it's often true in the enterprise market (unless things have changed in the last couple of years I've been out of it). In the carrier space, customers often use "home grown" systems they've kludged together from some third party OSS packages plus a lot of scripting files.

Personally I've always thought that if you want a good OSS you have to be prepared to pay for it. Have carriers accepted this yet?

Cheers,
Geoff

PS. I don't feel qualified to comment on the data models and underlying framework issues, but (from my limited understanding) I think you're right about getting these right in a standards context. Do you see it happening though? Which standards body is making progress here? Certainly not the IETF, other than going through the motions of writing MIBs.
heisenberg 12/4/2012 | 11:56:03 PM
re: Carriers Face Ethernet 'Black Hole' "Hmmm. OK, but this sounds a bit like a company that makes a network adapter. They write device drivers for a bunch of operating systems. At first all is well, but after a while they find they're having to support so many operating systems that their support staff is getting overloaded."

Yes and no. Adaptation layer should be VERY simple, stateless and quite dumb. It's just data translation. That's it. However, if you have two vendors achieving cooperation there is practically impossible, especially of one has to come up with some $$$ to fund the project.

As for NMS systems coming for free, yeah, the crappy ones that cause nothing by headache do. Really. However, it does not mean that SP customer would not try to get it for free. It's all about your value propposition, if it's something that solves real problems, SPs would pay for it.

You do have to be always prepared to pay for something that's good and solves real problems. I personally would not pay a penny for most of the NMSs out there. Be it vendor specific or third-party. However, there are a couple of notable exceptions. This is not rocket science, if you put your mind to it, you can come up with at least a relevant useful product. But you have to get out of the check-list mentality..

Standards. I'd hope so. I think technology side of things should settle prior to those standards emerging. It's just too much of a moving target at the moment. And then, who would be defining these standards? Folks that haven't done this sort of thing in a while, big guys, marketing people? The polictical state of the system, would most likely prevent from anything useful happenning... Unless people see the light.. How likely is that?
gbennett 12/4/2012 | 11:56:04 PM
re: Carriers Face Ethernet 'Black Hole' Hi rjmcmahon,

Re your post # 31. I think we're on the same page here. I totally agree we need to encourage the creation of real jobs, with higher levels of skills, and that those jobs require people to think, and not count beans :-)

I was speaking to an old friend today who is about to be laid off. This person deliberately said they'd be avoiding looking for work in the core router space. This is partly because it's pretty much dead in the water at the moment (which will hopefully change in the near future), but mainly because it's "tending towards commodity". I found it surprising because this is a person who truly understands stuff like BGP, and all it takes to keep it chugging away happily. I suspect they don't want to be condemned to a job counting beans ;-)

Cheers,
Geoff
Page 1 / 5   >   >>
HOME
Sign In
SEARCH
CLOSE
MORE
CLOSE