10G Ethernet arrives

In the beginning, Robert Metcalfe created Ethernet, and it was good. On the second day, the IEEE 802.3 committee created Fast Ethernet, and it was better.

The creation biz gets kind of addictive, so on the third day the IEEE created Gigabit Ethernet, and it was faster than Fast. And on the fourth day (OK, last week if you want to be literal), the IEEE blessed a new 10Gbps Ethernet standard.

The approval of 10 Gigabit Ethernet, officially IEEE 802.3ae, means vendors will be shipping products that move network traffic at 10 gigabits per second over single- and multi-mode optical fiber links, at distances of between 26 meters and 40 kilometers–depending on whether you’re using single- or multi-mode fiber, and the fiber’s core size and bandwidth.

Hardware vendors didn’t wait until the standard was finalized before unveiling products. Cisco, Extreme Networks, Force10 Networks, Foundry Networks, and Nortel Networks have all announced 10G products, and some of them have been shipping pre-standard products for as long as a year. Because the vendors have representatives on the standards committee, some of the products already comply with the ratified standard. Firmware fixes for products that don’t comply should be available shortly.

Unless you work for a telecommunications carrier, it isn’t likely that you’ll be buying 10G gear anytime soon. It’s not LAN equipment for the vast majority of networks today, given the volume of traffic that typical business LANs carry. It’s also not cheap: expect to pay $40,000 to $100,000 per port if you plan to become an early adopter. If the price curve follows the past examples of Fast and Gigabit Ethernet, costs won’t come down to reasonable price/performance realms for three or four years. At that point, the largest of enterprises may be able to turn to 10G for high-volume backbone switches.

Carriers, however, will be installing 10G routers, and that opens up some interesting possibilities for their customers. If you have two geographically dispersed locations, you could connect them across a single metropolitan area network (MAN). Such a topology will be faster, simpler, and possibly even cheaper than employing frame relay, T-1, or other older wide-area networks.

When will we see 100 Gigabit Ethernet? Don’t hold your breath. Bob Grow, chair of the IEEE 802.3 Working Group, former chair of the 10 Gigabit Ethernet Alliance and principal architect in Intel Communications Group’s CTO Office, says no call for interest (the first step in getting a new standards project) has been made for any higher Ethernet speed. We’ll just have to make do with 10 gigabits per second for now.

BREW battles Java

Envision a day when cellular phones are integral parts of your network. That day is coming sooner than you might think.

3G mobile phone networks will offer far more than voice capabilities, and even more than data services. They’ll offer the ability to roll out new applications that run directly on phones, for instant messaging, positional location, interactive commerce, and not-so-serious stuff like entertainment and games. Today, Qualcomm’s Binary Runtime Environment for Wireless (BREW) and Sun’s Java 2 Micro Edition (J2ME) are the best candidates for delivering and running applications on mobile platforms such as phone and PDAs.

BREW and Java will compete on a common execution platform, as well as through billing methods that charge for value-added services and applications at rates above and beyond simple airtime minutes.

But I believe J2ME has an early, overwhelming, and perhaps insurmountable lead in the developer community.

Developers need to write to a platform that can be deployed on virtually every phone. In that regard, BREW and Java are on equal footing: Both can be deployed on virtually all 3G devices and there are free software distribution kits for both, too. Developers also need the ability to monetize their work–that is, to distribute and sell their applications. Here, BREW has the edge. It provides both a software development kit and a distribution system.

J2ME lacks a distribution and billing system. Carriers have to build their own infrastructures for deploying Java apps and figure out how to bill for their use, or turn to third parties such as Tira Wireless to handle the task for them.

BREW appears to be better technology for monetizing mobile applications. It was conceived specifically for devices such as mobile phones–unlike Java, which is a more general tool. BREW actually works with Java; Java developers can use BREW APIs thanks to Qualcomm’s bundling of IBM’s J9 Java virtual machine with the software.

BREW could succeed on its merits, but the best technology doesn’t always win. In our industry, 100VG-AnyLAN was better technology than 100Base-T, but its developer, Hewlett-Packard, was unable to evangelize it and get it widely adopted. BREW seems to be cast from a similar mold. Verizon is about to roll out BREW services nationwide, but it’s the only major US carrier to do so. The others are focusing on Java, while Japan’s NTT DoCoMo has already begun offering Java services.

BREW’s chief virtue is that it puts a common development, deployment, and billing infrastructure in place so that carriers don’t have to build their own, allowing carriers and application developers to bring products to market quickly. That means that if BREW is to succeed, it must do so quickly, because in two or three years, US carriers will have an opportunity to build their own infrastructures just as NTT DoCoMo has done. Today, the most likely candidate for a base on which they’ll build them seems to be J2ME.

Java, on the other hand, has no such deadline. It has already achieved critical mass as a development platform. So while BREW may or may not be successful in the short term, J2ME looks like a winner in the long run.

Make instant messaging work for your company

Instant messaging software appeared on your network because it was fun to use and easy for even inexperienced users to install. But this seemingly frivolous application can be a full-fledged productivity tool, especially in the hands of an IT department that can manage its use and avoid its pitfalls. To do that, there are several issues you have to tackle.

The biggest concern with IM is its current lack of security. Flaws in several common IM applications may allow attackers to take over your PC, and viruses can bypass antivirus software when they hitch a ride in files transferred by IM. Organizations also worry that unencrypted messages can be eavesdropped on.

Most of those problems stem from a lack of corporate control over the public messaging networks of companies such as AOL, Yahoo, and MSN. Applications that use these networks require users to download a special client, but don’t require a server component on your network, because the vendors themselves run the services. The applications often employ TCP/IP ports that would not otherwise be opened in the corporate firewall, which makes some security administrators frown.

Unfortunately, there’s no effective way to fine-tune the security of commercially available IM. The typical choice is between allowing or banning IM. You can ban the application by corporate policy, by closing off the TCP ports each application uses, and by strong policy enforcement of the applications you allow users to run. If you allow IM, be sure your clients all run antivirus programs and, ideally, personal firewall software too. You may also want to consider running a program like Cordant’s IMScribe that logs all users’ messages, so you’ll at least have a rudimentary archive and audit trail.

If you want to implement an internal IM system, you can use a program that runs on a server in your organization. You manage the server, you authorize clients, and you set policies for what can pass through the system. This group includes products like Lotus Sametime, Jabber Software Foundation’s open-source Jabber, and Divine’s MindAlign. These programs tend to have higher-end features than the services, including searchable message stores, multi-person chat and broadcast messages, shared workspaces and files, voice, video, and encryption. However, the tradeoff for these extra features is that the programs require more time from corporate IT staff to set up and administer.

If you don’t lock down clients’ desktop configurations, users can still use third-party IM clients even if you implement an in-house program, which could raise security concerns. You should configure an in-house server not to communicate with outside IM systems.

Recently we’ve seen a third type of instant messaging: an application (generally written in Java) that you embed in a Web page. Such products include Bantu Messenger, JMD’s QuickSilver Instant Messenger, and Parlis. This blending of the Web and instant messaging offers some control, in that you can manage who uses the application, but users must have a Java virtual machine on their systems (most do; Windows XP doesn’t include the software, but you can download it later) and access the application from a Web browser.

Live chat on a Web page is well-suited for customer service applications, as well as communities that might like immediate discussion of the material on a particular site. Because it’s tied to a Web page, it’s not a compelling alternative to normal IM for most uses, however. One advantage of such applications is that you don’t have to download a new client application. A disadvantage, however, is that you must integrate these platforms into your Web pages, which requires more development effort than simply installing client software. If the application is hosted, you run into the same security concerns we’ve already discussed. If you install it on your own servers, you add to your administration workload.

Which IM product is right for you depends on how much time and money it will cost to roll out and manage. You need to determine which advanced features you’ll use beyond simple real-time text messaging. Start by surveying your current users. Knowing what features they currently use, and what features they would most like to have will help you target what specific business issues you want IM to address–and whether you need the additional security and administration load of an in-house IM server, along with its additional expense.

If all this indicates that an internal system may make sense, calculate what kind of return you’ll get for your IM expenditure. Some of that return is tangible–for instance, you may find that customer support reps average less time on calls when they’re able to IM colleagues for help. Much of the return is harder to quantify, however. The added camaraderie and connectivity IM provides, especially between users who don’t share physical office space, can do a lot to promote job satisfaction and organizational loyalty.

Whichever way you go, use the same common-sense approach you would take when rolling out any new application. Start small with a pilot group of users, monitor the deployment carefully, and use their feedback to refine the project before installing the system across the organization.