Nortel Networks, Inc.

OpenetLab Technology

The design of the OpenetLab technology is driven by some very broad requirements and constraints. This section briefly describes some of the more important ones:

  • The primary goal of the OpenetLab project is to make it possible for clients to execute code on the network infrastructure itself, and to deploy it there in a dynamic fashion. At the same time, opening up the network elements in this way must not compromise the performance, reliability or safety of the devices or the network as a whole. A key to ensuring this safety is that the system must be highly suspicious of any code that is dynamically deployed, and should extend minimal trust to it.

  • Another desirable goal is that it should be possible to implement the services without being faced with unnecessary platform-specific details. For example, details of the network element's underlying operating system and CPU, as well as of how the control and data planes are organized should be hidden from the service wherever possible.

  • Similarly, where platform-specific information is exposed to the services, it should be done in a way that makes it possible to write the services portably. For example, the MIB can be made available through a generic set of APIs. In this way services can be deployed that work on radically different kinds of platforms.

  • Furthermore, it is important that the OpenetLab technology can support multiple clients simultaneously without requiring them necessarily to be aware of each other or to coordinate their behavior. In other words, although it is quite reasonable for the clients to cooperate and make use of each other's services at their own convenience, the system must not require this kind of cooperation. Indeed, by default the clients should be mutually suspicious and should not extend too much trust to each other.

  • It should be possible to control the lifecycle of the services. They can be deployed dynamically and made available, and then they can be removed from the network element when they are no longer required. All of this must be done without taking the device off-line.

The approach that OpenetLab has taken is to base the technology on the Java™ virtual machine. Some of the benefits of using Java that help to satisfy the constraints listed above include:

  • Platform independent compact binary format
  • Supports dynamic loading of code
  • Good fundamental security:
    • Memory protection
    • Garbage collection
    • Type-safe
    • Flexible security manager
  • Wide acceptance in software industry
  • Multithreaded
  • Rich set of standard APIs
  • Support for code signing and authentication
  • A standard interface for accessing native code

OpenetLab is providing a JVM for each supported platform, as well as a small kernel that manages the lifecycle of the downloaded code. Services are deployed in units called oplets and the system that supports them is called the Oplet Runtime Environment (ORE). The ORE is itself written in Java, and is distributed along with the JVM as the main application that is started automatically.

OpenetLab also provides a small set of standard services and oplets that will be useful to third parties. Also provided are some more substantial services that provide access to the MIB and the control plane data structures. These standard services will be improved and expanded over time.

In some unusual cases, an OpenetLab service might have some of its components implemented with native code support. This will require special treatment because the native code must be distributed as a part of the network element's boot image. This might be done for performance-critical code, or because there simply is no other mechanism of gaining access to the resource in question. This option is not available for third-parties.


Send mail to webmaster@openetlab.com with questions or comments about this web site.
Copyright © 1999 - 2005 Nortel Networks, Inc.
Last modified: $Date: 2003/03/10 19:45:06 $