ONJava.com    
 Published on ONJava.com (http://www.onjava.com/)
 See this if you're having trouble printing code examples


Java Patterns and Network Management Java Patterns and Network Management

by Stephen B. Morris
08/25/2004

Ever wonder why programming always seems to take longer than expected? Or why what appears to be a simple task often ends up being very difficult? I have a theory that many developers don't use programming patterns nearly as often as they should. Too much wheel re-invention! This article briefly introduces Multiprotocol Label Switching (MPLS) network management and shows how two Java patterns can be applied to this complex area. You'll see that the use of patterns is quite straightforward and that knowledge of them helps in rapidly solving common application problems.

An unexpected benefit of the use of patterns is that it moves programmers up the value chain and allows for more beneficial interaction with designers and strategists. If all parties understand patterns, then there is greater scope for mutual understanding and stronger software solutions.

Back to the Past

The networking industry often reminds me of the 1980s pre-IBM PC software sector -- you can have anything as long as it's a proprietary solution! Characterized by many competing vendors, the networking industry now labors under the burden of non-standard, multi-vendor architectures. This is seen in service-provider and enterprise networks in the form of a rich mix of devices (switches, routers, hubs, etc.) cobbled together to provide a growing range of services. Traditional service revenues are shrinking as demand for bandwidth and new realtime services is growing. This is a tough industry living in interesting times.

Cisco is emerging as the dominant vendor, but its products are still de facto standards. It is this lack of a standard platform that is complicating the migration to converged IP-based networks. As in the 1980s software industry, the problem is the need for a convergence technology that provides a standard platform (just as the IBM PC with the DOS operating system did back then).

Today, MPLS is the best candidate for providing such a platform, and it is being deployed worldwide by hundreds of service providers. Why is MPLS so special, compared to its predecessors ATM and Frame Relay (FR)? In a nutshell, ATM and FR have scalability problems and they don't provide easy integration with IP. MPLS succeeds by leveraging proven IP protocols and separating control and forwarding into distinct components.

Related Reading

Rick Gallaher's MPLS Training Guide
Building Multi Protocol Label Switching Networks
By Rick Gallaher

Componentizing control and forwarding means that the former can be made arbitrarily complex without compromising the packet-forwarding mechanism. The control component can be used to enact complex algorithms on incoming IP traffic, such as performing queue assignment and path selection while leaving the forwarding component untouched. This separation means that forwarding can be performed in hardware, if required. Let's now take the dime tour of MPLS.

MPLS Nuts and Bolts

MPLS provides the following major elements:

We'll see most of these in the following discussion. Figure 1 illustrates a corporate HQ with a remote branch office interconnected by a service provider network. The HQ site enterprise architecture supports a range of applications, including voice over IP (VoIP), video over IP, email, etc. Access to these applications is available over the MPLS-based service provider network.

Figure 1

Figure 1. Multisite Enterprise using IP/MPLS Service Provider

Figure 1 illustrates two LSPs (LSP 1 and LSP 2). Both LSPs have been configured with explicit route objects (EROs): LSP 1 follows the path made up of the interfaces (d, e, f, g, h, i) on nodes (LER A, LSR A, LSR B, LER B).

LSP 2 follows the path made up of the interfaces (c, j, k, l) on nodes (LER A, LSR C, LER B). Typically, the above interfaces would be recorded as IP addresses (e.g., d = 10.81.1.1) -- I use symbols just for simplicity. Selecting paths that optimize network-resource utilization in advance of circuit creation is called traffic engineering. One of the Java patterns I'll use illustrates TE.

LSP 1 has also been configured to reserve bandwidth (in a process called QoS provisioning) along its path of 2Mbps (i.e., 2,000,000 bits/second). This means that the VoIP and video-over-IP traffic can be MPLS-encapsulated and pushed onto this path. LSP 1 terminates on LER B, where any MPLS information is stripped from the packets. At this point, a normal IP lookup occurs and the realtime traffic is forwarded to either the adjacent transit service provider or the branch office, via CE2.

LSP 2 has no bandwidth resources reserved -- it offers a best effort (or standard IP) QoS. This LSP is used to forward the SMTP (email) traffic across the core to LER B. Again, at LER B, the MPLS information is stripped off, and normal IP lookup occurs. The traffic then forwarded to CE Router 2 in the direction of the branch office site.

CE, PE and P Routers

Figure 1 illustrates three different types of nodes: customer edge (CE), provider edge (PE), and provider core (P). CEs reside on the customer premises and can be basic IP routers. PEs reside at the edge or point of ingress of the provider network, and function as an "on ramp" to the MPLS core. Ps are found inside of the core and may be basic ATM/FR switches that are running MPLS protocols.

A major strength of MPLS is that it uses proven IP protocols to replace existing legacy technologies, such as ATM and Frame Relay. Network management (NM) is a key element of this evolution.

MPLS Network Management: FCAPS

NM is traditionally divided into the five major functional areas called FCAPS, or "fault, configuration, accounting, performance, and security." A network management system (NMS) operates in conjunction with the managed network elements (NEs) to fulfill the FCAPS. This is typically done using a combination of NE command-line interfaces (CLI) and SNMP entities. The CLI is the NE user-level menu system, typically accessed using telnet or a serial interface on the device. SNMP is a message-oriented protocol from the TCP/IP suite. In Figure 1, the NMS can use either CLI or SNMP on the various NEs. One advantage of SNMP is that it is a standard protocol.

Faults (or informational events) can occur at any time on devices embedded deep within the network. SNMP provides a mechanism by which fault information can be communicated to an NMS. The NMS operator (or the NMS itself) can then take appropriate action. Configuration is the process by which the settings on NEs can be retrieved or updated. In many commercial NMS products, this is done using the CLI. Accounting (or billing) is the process by which managed network resources are financially analyzed; e.g., the generation of departmental or user bills. Performance information is crucial to network operators to determine if the network is fulfilling contractual service-level agreements or even just to determine if NEs are experiencing congestion or the onset of failure. Finally, security is required to ensure protection of the NEs and the data in transit over them. For a more thorough description of the FCAPS functional areas, see "Network Management and MPLS."

SNMP

SNMP facilitates FCAPS support in the form of Management Information Bases (MIBs, described below) and a simple messaging protocol. Messages are provided that allow retrieval and configuration of NE data, as well as access to fault data. Fault (or informational) data is typically emitted autonomously by the NEs as and when problems occur. Accounting and performance data can also be derived from MIB objects. SNMPv3 provides strong security and authentication features. More information on SNMP can be found in SNMP, SNMPv2, SNMPv3, and RMON 1 and 2, 3rd Edition, by William Stallings, Pearson Education 1998 and Network Management, MIBs & MPLS: Principles, Design & Implementation, by Stephen B. Morris, Prentice Hall 2003.

Many commercial packages provide SNMP API -- one that I've used is Sun Microsystems' JDMK.

MIBs

A principal component of network management is the MIB. This is the schema used by the NMS to understand the data maintained by the managed NEs. Think of a MIB as a large collection of defined data objects that are of interest to network management. The MIB is shared by both the NMS and the NEs, but the NEs actually implement and maintain the values of the managed object instances. The NMS uses the MIB schema to understand the NE-resident MIB objects.

NMS

The cornerstone of network management is the NMS. Typically packaged as a client/server (or N-tier) application suite, the NMS features thin clients and simple topological GUIs. Clients interact with the topology (e.g., the network in Figure 1) using the various NMS server components (see Network Management, MIBs & MPLS: Principles, Design & Implementation by Stephen B. Morris, Prentice Hall 2003). The code examples that follow are of software elements that would typically fit into the NMS server code base. Let's now look at our Java patterns.

Java Patterns for MPLS Network Management

The two Java patterns I want to describe are Abstract Factory and Prototype. The sample code illustrating these patterns is available in the resources section at the end of the article.

Abstract Factory

The Abstract Factory pattern is used for defining and creating objects such as the LSPs and EROs in Figure 1. The following lists VirtualCircuitFactory.java and illustrates this pattern as an interface with two methods:

public interface VirtualCircuitFactory
{
	// Create a generic virtual circuit
	public VirtualCircuit createVirtualCircuit();
	// Creates TE data for the generic virtual circuit
	public TrafficEngineering createTrafficEngineering();
	//public QualityOfService createQualityOfService();
}

The third method, createQualityOfService(), is commented out and is a placeholder for adding extra capability to the class.

The VirtualCircuitFactory interface is implemented by LSPFactory.java:

public class LSPFactory implements VirtualCircuitFactory
{
	public VirtualCircuit createVirtualCircuit()
	{
	return new LSP();
	}

	public TrafficEngineering createTrafficEngineering(){
	return new LSPTrafficEngineering();
	}
}

LSPFactory.java uses the VirtualCircuit.java abstract class. VirtualCircuit provides network node endpoints for a generic virtual circuit type (the latter can be ATM, FR, MPLS, etc.). LSPFactory specializes the behavior of VirtualCircuit by adding MPLS-specific attributes. Similarly, to model ATM or FR virtual circuits, you just have to add an associated factory class. The two methods in LSPFactory return the following two objects:

Please note: the factory classes in this article are not implemented as singletons and don't contain static methods, so there can be many factory instances. In a typical NMS application, this might well occur. However, at the point where data is created on network devices, it is generally necessary to impose some type of locking action. This can be achieved via the database. An alternative is implementing the factories as singletons so that all network data-affecting actions are handled in instance only.

The LSP class extends the VirtualCircuit class with the addition of LSP-specific attributes, such as MIB index variables. The latter are used to distinguish between the other LSPs that originate on the same network node; i.e., LSP 1 and LSP 2.

public class LSP extends VirtualCircuit {
	private int index;
	private int instanceIndex;

	// Add many more items here as per the MPLS MIB tunnel table

	private static final String TYPE = "STANDARD MPLS";
	private static final String COMMA = ",";

	public int getIndexValue(){ return index; }
	public int getInstanceIndexValue(){ return instanceIndex; }
	public String getVirtualCircuitType(){ return TYPE; }
	public void setIndexValue(int newIndex){ index = newIndex; }
	public void setInstanceIndexValue(int newInstanceIndex){
			instanceIndex = newInstanceIndex; }

	public String getLSPDetails(){
		return getIndexValue() + SPACE +
		getInstanceIndexValue() + SPACE +
		getVCEndpoints() + EOL_STRING +
		getVirtualCircuitType() + EOL_STRING;
	}
}

It's important to note that there are many more attributes associated with an LSP than those indicated here. The MPLS-TE MIB illustrates the relevant attributes in the mplsTunnelTable object. The LSP class sits at the bottom of our pattern hierarchy and provides us with Java code for manipulating LSPs.

As noted above, an important attribute of an LSP is TE data; i.e., the path taken by the LSP as it traverses the network. This is modelled by the class LSPTrafficEngineering.java that provides type and route data.

The above classes are combined in RunPattern.java, where the virtual circuit factory is used to instantiate an LSP object. Next, the attributes of the LSP are set -- in this case, the two MIB index values (1 and 0) and the originating and terminating node details (LER A-10.1.1.1 and LER B-20.1.1.1). The traffic engineering details are then set up for this LSP using the setRouteData() method. The output below illustrates the executed pattern.

E:\Abstract Factory>java RunPattern

LSP creation example using the AbstractFactory pattern

 (I use the VirtualCircuit and TrafficEngineering classes when writing
  almost all of the code. This allows you to produce a
  generic framework, and plug in Concrete Factories
  and Products to specialize the behavior of the code.
  The LSP and LSPTrafficEngineering classes provide
  the required behavior specialization in this case.)

Creating LSP and TrafficEngineering objects:
LSP Data (MIB index values):
1 0 LER A-10.1.1.1 LER B-20.1.1.1

STANDARD MPLS

LSP Traffic Engineering Data: (please see Figure 1 for the details)
Traffic Engineering Data is typically defined in terms of IP addresses.
We just use node and interface names for simplicity.
LER A(d) + LSR A(e,f) + LSR B(g,h) + LER B(i)
ERO - Explicit

Once these objects have been created (e.g., under the direction of a GUI client user), they can be written to a database or provisioned to the network (such as in Figure 1). These require access to specific back-end technology; e.g., JDBC for the database and JDMK for SNMP.

LSP 1 in Figure 1 could be created using this pattern. The Prototype pattern that we discuss next could be used to create LSP 2.

The Prototype Pattern

A common NMS requirement is the ability to clone an existing object. Very often, NMS objects require a lot of configuration -- in many cases, dozens of variables must be set. It's a little like setting up a new PC! Some examples are when you want to create a backup LSP to protect an existing LSP, or if you want to create a new LSP that is similar to an existing one, as in Figure 1. Cloning provides the ability to inherit the benefits of your hard work!

The Prototype pattern gives us a convenient way of providing cloning. I've added to the AbstractFactory example to show how this can be done. First, I provide the Copyable interface, which has a single method, copy(). The copy() method must be implemented by LSP.java. In addition, I added a default constructor and a non-default constructor to LSP.java. The non-default constructor is called when a client wants to clone an LSP by calling the copy() method.

The executed pattern is shown in the output below.

E:\prototype>java RunPattern
  Example of the Prototype pattern

  I use the AbstractFactory to create an LSP.
  This is then cloned to create a copy.
  The new LSP can then be modified as required.

Creating LSP and TrafficEngineering objects:
LSP Data:
1 0 LER A-10.1.1.1 LER B-20.1.1.1
STANDARD MPLS

LSP Traffic Engineering Data: (please see Figure 1 for the details)
Traffic Engineering Data is typically defined in terms of IP addresses.
We just use node and interface names for simplicity.
LSP Traffic Engineering Data:
LER A(d) + LSR A(e,f) + LSR B(g,h) + LER B(i)
ERO - Explicit

Creating second LSP using the clone() method.
Second LSP created.
1 0 LER A-10.1.1.1 LER B-20.1.1.1
STANDARD MPLS

The Prototype pattern makes it easy to create new LSPs based on existing ones. Clearly, this applies to other varieties of managed objects, as well.

Conclusion

There is considerable scope for using Java patterns in network management. In many cases, network management infrastructure is developed late in the project lifecycle of NE features. So when a given MPLS feature is being added to a NE platform, the associated MIBs, and SNMP entities are only added once the core device code has been written. This misses an opportunity for adding value by parallel development of device and network-management software. Even with this, the merit of using Java patterns is the speed at which code can be produced. The code for this article took no more than a day to write. I tried to write it to accommodate generic base classes (e.g., the VirtualCircuit class provides just endpoints) with more specialized behavior provided by subclasses (e.g., the LSP class). Similarly, other virtual-circuit-oriented technologies, such as ATM/FR, can be supported by just providing associated subclasses. It is easy to then expand this LSP class to support other desirable features, such as cloning.

Some of the benefits of Java patterns in network management are quicker development and more maintainable NMS software. More information on MPLS can be found in the article "Network Management and MPLS" and the book MPLS: Technology and Applications by Bruce Davie and Yakov Rekhtker.

Resources

Stephen B. Morris is an independent writer/consultant based in Ireland.


Return to ONJava.com.

Copyright © 2009 O'Reilly Media, Inc.