Download Abstraction layers enable cross-platform, reusable software for next

S
P
E
C
I
A
L
F
E
A
T
U
R
E
LINUX
Abstraction layers enable cross-platform, reusable
software for next-generation networking equipment
By Michael Ward
Developers of network-based devices for
distributed network computing equipment
face many challenges in making their
products interoperate efficiently with
other devices across a network, whether
private or public. Networking technology
is evolving so fast that today’s advanced
networking devices may be obsolete in
a year or even six months. Developers
have to consider this rapid evolution and
plan their products for interoperability,
scalability, and high performance for
today and for the future.
Hardware and OS independence
Today’s networking software needs to be
independent of any specific hardware infrastructure. If you write software specifically
for a fixed configuration ASIC-based product with 24-ports and no system redundancy, you cannot port that software to a
network processor-based product housed in
a AdvancedTCA based chassis with full
hardware level redundancy. You would
have to invest a large block of time in
rewriting major portions of the software.
T
In addition, many companies leverage
multiple embedded operating systems
across a family of products to optimize the
performance/cost requirements for each
point within the product family. Network
vendors are producing low-end products
where costs are kept low by using royaltyfree Linux as the OS, while in the high end
of their product line that requires advanced
functionality they may use a commercial
RTOS such as VxWorks, or perhaps a mix
of VxWorks and Linux. To avoid rewriting
the interface for each product, you need
software that is OS-independent as well as
hardware independent.
The most crucial issue to be faced is the
need for interoperability between all network platforms, regardless of the type of
hardware and operating system used. A
network device vendor should select a set
of system components such as networking
silicon, CPUs, embedded OS, and chassis
and be confident that a system software
architecture can be rapidly integrated and
that they can reuse any previous application developed for a similar system.
There are a number of other important
issues facing system designers. Today’s network devices must support multiple standards including any future standards that
emerge. Network systems must be able to
incorporate new technology as it becomes
available, allowing the vendor to insert its
own value-added functions and accommodate unique customer requirements.
How does a manufacturer produce a system that will work with any other system,
anywhere? One proven approach is to use
a networking software framework that utilizes abstraction to make the system scalable and adaptable not only to any present
or future standard, but to any hardware
device and operating system as well. Such
an approach will allow the system designer to not only leverage the reuse of
internal software development, but also
rapidly incorporate components for other
sources, whether it be open-source or third
party commercial software.
Embedded Linux is a popular choice
among system designers for reasons beyond its royalty-free business model. The
availability of CPU and board support and
the increasing number of engineers who
are familiar with this operating environment are contributing to the Linux popularity. As well, the real-time extensions available through the Linux community and
commercial Linux vendors are bringing
users the same level of robustness that
many commercial RTOSs offer. Development tools offered from the open-source
community and commercial vendors make
Linux a cost effective and productive environment for the cross platform development required by networking vendors.
The solution to hardware and OS independence is to write the system software as
reusable building blocks using a set of
Reprinted from CompactPCI Systems / July-August 2003
abstractions that will detect the hardware
platform specifics and integrate with any
OS. A software architecture with abstraction layers allows you to preserve your
software application development investment as you move across the hardware
technology. This provides a common
interface between applications and other
programs. Since these abstraction interfaces interact primarily with the control
plane elements, there is little to no impact
on the overall system performance imposed by these layers.
For example, software can be designed to
allow all protocol applications to assume
that they are talking to a single network
device. There should be a layer that interprets a forwarding database modification
request and directs it to one or multiple
network forwarding elements (network
processors or ASIC/ASSPs), as appropriate. The forwarding hardware can even be
a different type of networking silicon and
reside in different devices.
By abstracting the control distribution
function, a protocol application writer can
develop complex software without needing to know the specifics of the system
that will use the software.
Network hardware independence can be
achieved by using an abstraction layer
such as LVL7’s FASTPATH Device
Transformation Layer (DTL), to write an
interface between application software and
network hardware. Where multiple networking silicon devices are used, the DTL
resolves the interface to the actual physical
port on a given network hardware device.
Core services such as add route, delete
route, enable port, disable port, get port
stats, and so on are mapped through as
APIs. While the DTL interface addresses
the abstraction between the application
protocol layers and the networking hardware specifics, it does not address platform
hardware issues, which are dealt with
using a system abstraction later.
©Copyright 2003
A system abstraction layer (called SYSAPI in LVL7’s FASTPATH software)
allows you to implement software that
is transparent to the RTOS, CPU, and
physical characteristics of the product
on which it runs. This layer contains the
board support package (BSP) or Linux
Support Package (LSP). Using common
generic interfaces, the higher-level software can access services such as a nonvolatile memory without knowing the
specifics of the hardware.
Common OS services such as task
management, memory management and
semaphores can be mapped through an
RTOS abstraction layer (called OSAPI
in LVL7’s FASTPATH software) so that
applications can be written to the OSAPI
APIs without making direct calls to a specific OS. By providing such an abstraction
layer, one can take advantage of the
numerous commercial and open source
based OSs or utilize an internal OS for
development. It is important to require the
applications to utilize the abstraction calls
and not the underlying OS API calls.
Services of the underlying operating systems’ IP network stack can be mapped
through as if they were OS services. For
example, socket calls can be mapped
through the OSAPI layer. Another option
is to consider the IP stack as a separate
entity and not capture it with the OS
abstraction interfaces.
API independence
Another key means to cross-platform
interoperability is a management system
abstraction layer (called the Unit Stack
Manager Database or USMDB in LVL7’s
FASTPATH software) that allows the user
interfaces to see the specific network ports
as interfaces without having to know the
specifics of where the physical port exists
or what type of port it is. This layer can
route the request to the proper subsystems
without involvement from the user interface.
The management system abstraction layer
provides a single interface between the
software applications and the managing
entities, allowing multiple user interfaces
to control the same underlying set of
application services regardless of the network processors or ASICs below. Every
data object that needs to be managed is
mapped through the management system
layer interface, resulting in the singular set
of access routines. This applies to both
protocol and application data (such as
OSPF interface info and L2 Bridge
entries) as well as any hardware specific
Figure 1
system data (such as port counters and
serial port speed).
gral facilities. Overall FASTPATH architecture is illustrated in Figure 1.
All user interfaces go through a common
set of APIs with the underlying applications, allowing a single set of interfaces
to be written for a function to set or get
configuration parameters or other data.
SNMP, CLI, Web, TL1, and XML all
access the management system interface
to get or set data. This is a huge advantage
over the traditional method of implementation where each management interface
had its own set of access routines to call
down to the application code or hardware
drivers to get information. The traditional
approach resulted in an unsustainable
code base that required an extensive effort
to add or extend a new function due to the
need to replicate essentially the same
effort for each management interface.
Designing the core networking protocols
and services as a part of the architecture
allows future protocols and applications
to be more easily integrated within
the overall system. When designing an
IP Routing subsystem, considering issues
of route leaking between multiple routing
protocols such as OSPF and RIP expose a
number of other issues that if properly
addressed, allow additional routing protocols to be more easily added. By providing a registration mechanism for
the various routing protocols to a single
Route Table Manager, a common point
is established for the distribution for new
route information to whatever routing
protocols or other system components
may require this information. Providing this protocol framework and registration mechanism through an abstract
API allows programmers new to the system to quickly understand how to extend
the software to provide the additional
functionality.
Support for multiple networking
protocol standards
Hardware and OS independence are not
enough, however. Because of the many
broadband communication standards that
already exist, as well as the continuing
emergence of new standards, it is imperative that embedded networking platforms
support multiple protocol standards. The
system software must be able to support
and interoperate with whatever standards
are being used on any given installation on
the network as well as those emerging
standards that will need to be supported
tomorrow. This is achieved by utilizing an
architecture that provides a base set of
protocols and facilities that allow for
enhanced protocols to be implemented
and underlying protocols to serve as inte-
Reprinted from CompactPCI Systems / July-August 2003
As any veteran of the networking industry
knows, the moment a product is shipped
to customers, a new set of protocols and
RFCs emerge that need to be supported by
the device. Many system designers find
that Embedded Linux is an attractive option for the system’s operating system due
to the vast amount of networking protocol
related software that exists within the
Linux and open source community. The
completeness and quality of this software
varies from component to component. In
many cases, this software can provide pro©Copyright 2003
S
P
E
C
duction quality functionality, or at a minimum serves as a viable option to utilize
during an early system prototype.
One aspect that must be considered when
pulling components from various distributions is the level of integration of these
components with one another. While certain higher level network applications
such as Trivial File Transfer Protocol
(TFTP) and Network Time Protocol
(NTP) clients can be treated as separate
applications, there is still a level of integration that is required to provide an
appropriate, unified user interface to the
system. In other cases, such as with Layer
2 Ethernet protocols including Spanning
Tree, 802.3AD Link Aggregation, and
Dynamic VLAN Registration (GVRP),
the protocols must provide a unified management interface as well as be tightly
integrated with one another. In these
cases, the system designer should carefully weigh the overall value of using
these minimally integrated components
available from various distributions versus
using a set of tightly integrated components provided from commercial source.
I
A
L
F
E
A
Flexibility in software maximizes
returns on hardware investments
If the network device vendor utilizes a
software architecture that is open and has
the necessary interfaces and hooks to allow
the addition of value-added functionalities,
the platform becomes attractive for end
manufacturers because it allows them to
add their own value-added features. The
network device vendor can then sell a single core platform to companies that are targeting vastly different markets. For example, one company may target the home
access market, but its device can also be
marketed to companies that focus on the
enterprise by adding multicast routing protocols. Indeed, by making devices configurable, scalable, and flexible via the software, a network device vendor can greatly
expand the markets for a given architecture, as well as reuse the software on future
generations of products. Since much of the
high-level functionality is implemented
through the software, the device can be
built with minimal investment and, with
simple upgrades, serve an extended and
profitable term in the market.
Reprinted from CompactPCI Systems / July-August 2003
T
U
R
E
Michael Ward is
Program Director,
Product Management for the FASTPATH product line
at LVL7 Systems.
Michael holds a
Masters of
Engineering with a concentration in
Computer Engineering from North
Carolina State University and is
currently pursuing an MBA from the
University of North Carolina.
For more information, contact
Michael at:
Michael Ward
LVL7 Systems
100 Perimeter Parkway
Suite H
Morrisville, NC 27560
Tel: 919-865-2707
Fax: 919-865-2703
E-mail: [email protected]
Web site: www.lvl7.com
©Copyright 2003