Java Patterns and Network Management

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:

• LSP
• LSPTrafficEngineering

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

• Sample code for this article

Stephen B. Morris s the CTO of Omey Communications, in Ireland.

Return to ONJava.com.