Adopting Software Engineering practices to network

Adopting Software Engineering practices to network processor devices Introducing the Domain Specific Modeling paradigm to the ForCES Framework Evangelos Haleplidis, Christos Tranoris, Spyros Denazis, Odysseas Koufopavlou Electrical & Computer Engineering Department University of Patras Rio, Greece [email protected], [email protected], [email protected], [email protected] Abstract— IETF’s new Forwarding and Control Element Separation (ForCES) architecture specifies the ForCES model providing an accurate description of the Forwarding Plane in an Object-Oriented fashion. However, the model is described totally in an XML Schema Definition (XSD): it is well-defined but purely machine oriented, being readable and usable, thus not human-friendly and difficult extending itself in the future. We argue that the ForCES model is actually a meta-model that is used to model ForCES components, e.g. Logical Function Blocks (LFBs), that later are used in ForCES applications. This paper presents a methodology based on a case study on how to automate the process of configuring the forwarding plane of network devices using state-of-the-art model-driven techniques in a tangible way while specifying a tool supported by a Domain Specific Language (DSL) for ForCES. We first consider describing the ForCES XSD based meta-model to a more manageable Ecore (MOF) based meta-model and then we create a DSL based on this Ecore meta-model. Then we target to transform automatically a Platform Independent ForCES model specified in the DSL to an executable target source code (Platform Specific: XML-ForCES compliant, C++, Java) able to communicate with the ForCES protocol. Keywords-ForCES model, Ecore, Domain Specific Languages, meta-modelling

I.

INTRODUCTION

The network processing can be divided into three distinct planes: forwarding, control, and management, with the forwarding plane being the time-critical processing path. Modeling of the forwarding plane complemented by a protocol allows control over the forwarding plane. This concept is not new, SNMP [1] being a very good example. One also could use this architecture to easily create static data paths for dynamic software architectures prior to run-time [2]. IETF’s ForCES (Forwarding and Control Element Separation) architecture [3], separates the Forwarding and the Control Plane, and specifies both a protocol [4] and a model [5]. The ForCES model is described in an XSD schema and is used to specify data path components responsible for packet processing functions. The benefits are accrued from the accompanied protocol which provides an interface for monitor, control and management. However XSD tends to be more

machine than human friendly and thus usability of modeling ForCES components could be improved. Model-Driven Software Development (MDSD) is currently a highly regarded development paradigm among developers and researchers. Models play a major role in MDSD, as well as also relations between a model and the system under study, meta-models and model transformations. MDSD is about using domain-specific languages to create models that express application structure or behavior in an efficient and domainspecific way. These models are subsequently transformed into executable code by a sequence of model transformations [6]. The mapping from the high-level domain concepts to implementation is possible because of the domain specificity: the language and code generators fit the requirements of a narrowly defined domain [7]. In this paper we present a methodology on automation of the process of configuration of the forwarding plane by considering an approach of adopting state-of-the-art modeldriven techniques while creating a set of tools making ForCES more usable. First we transfer the XSD ForCES meta-model into an Ecore meta-model. Then we create a DSL with a concrete syntax having as its abstract syntax the Ecore metamodel. We anticipate that defining ForCES entities realizing the Ecore meta-model in the DSL will be easier for a developer and therefore improve usability. Then we use this definition from the DSL and the instantiated model to automatically transform it into executable Forwarding Element source code that can communicate via the ForCES protocol. The paper is organized as follows: We first make a short presentation of the ForCES Framework and in the next section we discuss the need for defining the DSL and how we defined and build the DSL for ForCES, the tool and its syntax. We discuss how one can design full ForCES applications and finally we conclude with our future work. II.

FORCES FRAMEWORK

ForCES comes to cover the need of off-the-shelf network processor devices that implement the fast path or forwarding plane in network devices such as routers, by defining a framework and associated mechanisms to standardize information exchange between the control and forwarding plane allowing Control Elements (CEs) and Forwarding

Elements (FEs) to become physically separated standard components [8]. The separation will allow rapid innovation in both planes. Key elements in the ForCES Framework are the Control Elements and the Forwarding Elements. The current scope of the ForCES working group are the Forwarding Elements. Forwarding Elements are logical entities, residing in the Forwarding Plane and use the underlying hardware to provide per-packet processing and handling as directed/controlled by one Control Element via the ForCES protocol. The modeling of the Forwarding Elements, is based on Logical Function Blocks (LFBs). A Logical Function Block is a block of encapsulated fine-grained operation of the forwarding plane performing a well-defined action or computation on the packets passing through it. Classifiers, shapers and meters are all examples of such Logical Function Blocks [5]. Forwarding Elements may have a static topology or a dynamic topology. The Logical Function Block-based model is independent of the actual implementation of the FE; it only provides a view of its capabilities and state that can be acted upon using the ForCES protocol. In order to define a ForCES Logical Function Block one needs to follow a certain process. Prior to the actual Logical Function Block definition, the following information must be described or inherited from other Logical Function Block libraries: • Frames that can be handled by the Logical Function Block, like an IPv4 frame. • Data types. Atomic and compound. The atomic data types cover basic data types (char, floats, strings, etc.). The compound data types are created by combining atomic data types. New atomic and compound types can be defined to describe new data types. • Metadata which is state that is passed from one Logical Function Blocks to another alongside a packet assisting subsequent Logical Function Blocks. The actual Logical Function Block definition includes information regarding input and output ports, components, capabilities and events, which are notifications that a Control Element can subscribe to. As stated in [9], a meta-model is simply the model of a model, thus the ForCES model, which allows the definition of Logical Function Block models, is actually a meta-model. III.

A DOMAIN SPECIFIC LANGUAGE FOR FORCES AND SUPPORT TOOLING

As discussed in the previous section, the developer of Logical Function Blocks must describe them in an XML syntax based on the ForCES XSD schema. XML is mostly used for valid machine-oriented descriptions and is not targeted as a friendly human-oriented development language, while still human readable, makes the definition of Logical Function Block a rather tedious process. This paper sets to improve upon this.

For the definition of a Logical Function Block, we have adopted practices of Domain Specific Modeling, where the systematic use of textual or graphical Domain Specific Language (DSL) is involved, believing it improves the definition of a Logical Function Block. A DSL is defined as a specification language that offers, through appropriate notations and abstractions, expressive power focused on, and usually restricted to, a particular problem domain. To create a domain-specific language (DSL), developers must carefully analyze the domain to design the language and produce the supporting tooling infrastructure for editing, compiling, running, and analyzing instances of the language. Although ideal, DSL-based development processes can incur relatively high overhead with respect to overall project time and effort [10]. However we believe that the overhead is justified because the result of such an effort will improve usability and extensibility of how Logical Function Blocks are defined, as well as the overhead will occur only once. For the language definition an abstract syntax (the metamodel), a concrete syntax and semantics are needed. So, tooling is a necessary piece for constructing domain elements driven by models. Language Workbenches [11] seems to offer such tooling capabilities, with the most important being: i) the definition of new languages while users manipulate a DSL through a projectional editor ii) having as primary source of information a persistent abstract representation, iii) language designers define a DSL in three main parts: schema, editor(s), and generator(s). Eclipse [12] is a powerful Language Workbench with an extensible platform for tool integration, and a set of basic tools built on that platform. Eclipse is also an open source project which delivers the Eclipse technology. The key word in Eclipse is interoperability, since nearly everything is an extension to the platform. All the aforementioned Eclipse’s capabilities made it our Language Workbench choice. Eclipse Modeling Projects provide the basis for implementing DSL tools providing the Eclipse Modeling Framework (EMF) [13] and Eclipse Modeling Framework Technology (EMFT) [14] frameworks for using models, the Model-to-Model (M2M) Framework to create transformations between models, the Model-to-Text (M2T) framework to create text from models, Textual Modeling Framework (TMF) to generate model from Text and Model Development Tools (MDT) which includes Reference Implementations of OMG standards (UML, OCL, etc) [15], [16]. Building a Domain Specific Language tool based on the ForCES model, seems not a trivial task. Especially, if there is a need for a tool that offers definition and construction of new elements with validation capabilities, but also transformations and code generation for multiple targets. In Figure 1 we illustrate our approach towards tooling and automating the process of code generation. We first transform the ForCES XSD meta-model to a ForCES Ecore meta-model. Ecore is a variant of OMG’s Meta Object Facility (MOF) [17] that has been developed in the Eclipse Modeling Framework and is more or less aligned on OMG's Essential MOF (EMOF) [18]. This happen semi-automatically within our Eclipse

development environment: we import the XSD, Eclipse automatically transforms it to an ecore model and then we refine the model because we have some loss of information regarding naming but also constraints from the XSD.

LFBLibrary and then to define new Frame Definitions and Data types he will just use the LFBLibrary rule and proceed with defining the types inside. After defining the concrete textual syntax of our DSL the XText framework generates the necessary eclipse plug-ins that is used to instantiate our ForCES DSL editor. The editor is illustrated in Figure 3. We intentionally created some errors. The name “LFBPrototye” is repeated twice which is a conflict of the namespace. To achieve the same result in an XML editor, a developer would have to run an XML validator. In this case the error is made clear upon typing it.

Figure 1: ForCES meta-model and transformation

We then proceed on defining our DSL. For this we used Eclipse’s TMF and specifically the XText [19] framework. We define the concrete syntax in XText having the ecore model as the abstract syntax. The syntax consist of rules that are used later by the final user to define an Logical Function Block type based on the ForCES meta-model, this time utilizing our DSL textual definition. Part of the syntax is illustrated in Figure 2. The general structure of our DSL follows closely on the ForCES model. Notice from the syntax that we use the ForCES ecore meta-model with statements like:

Figure 3: Defining an LFBLibrary in ForCES DSL

Code versioning and other Eclipse features are immediately available, since our ForCES DSL editor is part of the Eclipse eco-system. Error control is one more advantage. For example, in the typeRef of the XML the correct values are the base atomic types, previously defined or inherited data types. In the XML however there can be no such check, while in the DSL no invalid values are allowed. Additionally by pressing control and space, code completion is activated and all the valid values are presented to the user to choose from. The next step is to enable the automatic code generation. As illustrated in Figure 1, we use model to text transformations to automatically generate ForCES Logical Function Block types in XML (compliant with the ForCES XSD model), in C++ and in Java. This is accomplished by utilizing the XPAND [20] language where we created language templates, being a mix of Xpand syntax and OCL. Thus the user defines all the entities in the ForCES DSL and with some defined workflows within Eclipse, the target code is automatically generated. IV. Figure 2: Defining the syntax of ForCES DSL import 'platform:/resource/LFBModel/model/LFB.ecore' as LFBmodel.

Later this is used to define the concrete syntax of the LFBLibrary rule. So, when a user wants to define a new

DESIGNING FORCES-ENABLED APPLICATIONS

The ForCES protocol is an open interface between a Control Element and a Forwarding Element. As such, creating a ForCES enabled application requires hardware or software for the role of the Forwarding Element(s), Control Element(s) which plays the role of the manager of the Forwarding Element(s), and a piece of software that can communicate with the Control Elements(s), using the ForCES protocol, and with the Forwarding Element(s).

The model describes the LFBs in an Object Oriented fashion. Using specific types or creating new based on existing ones and inheritance are all concepts of Object Oriented programming. Thus usage of Object Oriented methods for creating logical Forwarding Element [21] in a semi-automated fashion is feasible. This paper takes this approach one step further, utilizing the ForCES Domain Specific Language and the XPAND templates to create an almost automated approach to building logical Forwarding Elements. The ForCES model allows creation of new data types based on the base types. By having source code for each of the base types, the new data types can inherit from the base types all the protocol functionalities, except the code for the connection to the Forwarding Element, thus hiding all the complexities of handling the ForCES protocol messages. Similarly a Logical Function Blocks can inherit basic functionality from a parent Logical Function Block. With the aid of the language, a developer would have to specify the Logical Function Blocks, maybe import definitions from previously created files, and simply click a button. Eclipse will create based on pre-defined Xpand templates C and Java code, as well as XML code, leaving the function for interconnecting the software to the Forwarding Element to be inserted by the developer, since it is platform specific. To perform the same operations with the current ForCES model, a simple solution would be to create an XML parser and generate the source code based on the XML. However this solution does not offer the advantages of the MDSD methodology and the use of a DSL. V.

CONCLUSIONS AND FUTURE WORK

In order to create our ForCES DSL there is a need for the model. ForCES provides the model in an XSD schema file. The eclipse platform has tools to extract this model into an ecore model and automatically create an Xtext file with the DSL grammar. The generated editor provides highlighting, error correction, notations and importing other files, making writing a Logical Function Block much easier than manually. The reasons for creating the ForCES DSL are, as we articulated so far, many, but the outstanding benefit is the ability to easily extend the ForCES model using semantics that have already been specified. Other benefits include bringing the ForCES architecture in a broader audience while covering the complexities of the protocol and model, and being able to create Logical Function Blocks in a more reliable, automated and human-readable fashion. After running the automated generator we found that the generated files were populated with unnecessary details and lacking constraints that are described in the model document [5]. Thus, a parallel tentative effort started creating the ecore model from scratch. The initial results are encouraging. Also, having described the ForCES DSL, the following research areas are interesting to approach: ƒ

Extend the ForCES model itself to model more than Logical Function Blocks and the addition of

more semantics and restrictions that cannot be specified in the current xml schema. ƒ

Map specific Logical Function Blocks to existing architectures like the Click router [2] and automate further the building of ForCES enabled routers on these architectures. REFERENCES

[1] [2]

[3]

[4]

[5]

[6] [7]

[8] [9]

[10]

[11]

[12] [13] [14] [15]

[16] [17]

[18] [19] [20] [21]

Case, J., M. Fedor, M. Schoffstall, and J. Davin. "A Simple Network Management Protocol (SNMP)." RFC 1157. IETF, May 1990. Kohler, Eddie, Robert Morris, Benjie Chen, John Jannotti, and M. Frans Kaashoek. "The Click modular router." ACM Transactions on Computer Systems , 2000: 263-297. Lily Yang, Dantu Ram, Todd A. Anderson, and Ram Gopal. "Forwarding and Control Element Separation (ForCES) Framework." RFC 3746. IETF , April 2004. Avri Doria, Jamal Hadi Salim, Robert Haas, Horzmud Khosravi, Weiming Wang, Ligang Dong, Ram Gopal and Joel Halpern, "Forwarding and Control Element Separation (ForCES) Protocol Specification", RFC 5810, March 2010. Joel Halpern and J. Hadi Salim, "Forwarding and Control Element Separation (ForCES) Forwarding Element Model", RFC 5812, March 2010. Stahl, Thomas, and Markus Voelter. Model-Driven Software Development: Technology, Engineering, Management. Wiley, 2006. Sprinkle, Jonathan, Marjan Mernik, Juha-Pekka Tolvanen, and Diomidis Spinellis. "Guest Editors' Introduction: What Kinds of Nails Need a Domain-Specific Hammer?" IEEE Software, July/Aug 2009. IETF ForCES charter. "ForCES Charter" 2010. https://datatracker.ietf.org/wg/forces/charter/ (accessed June 01, 2010). Dave Steinberg, Frank Budinsky, Marcelo Paternostro, Ed Merks. "EMF: Eclipse Modeling Framework" Second Edition, Addison-Wesley Professional, 2008. Mernik, M., J. Heering, and A.M. Sloane. "When and how to develop domain-specific languages." ACM Computing Surveys (CSUR), December 2005: 316 - 344. Fowler, Martin. "Language Workbenches: The Killer-App for Domain Specific Languages?" http://martinfowler.com/. June 12, 2005. http://martinfowler.com/articles/languageWorkbench.html (accessed January 27, 2010). Eclipse, Modeling Project. "Eclipse Modeling Project." eclipse. 2010. http://www.eclipse.org/modeling/ (accessed 1 28, 2010). EMF. "Eclipse Modeling Framework" 2010. http://www.eclipse.org/modeling/emf/ (accessed June 01, 2010). EMFT. "Eclipse Modeling Framework Technology" 2010. http://www.eclipse.org/modeling/emft/ (accessed June 01, 2010) UML, OMG. "OMG Unified Modeling Language (UML) Specification:Infrastructure, Version 2.2, Final Available Specification." February 2009. http://www.omg.org/spec/UML/2.2/Infrastructure/PDF/ (accessed 1 27, 2010). OCL, OMG. "Object Constraint Language (OCL) Version 2.2." OMG. 2006. http://www.omg.org/spec/OCL/ (accessed 1 28, 2010). OMG website. Catalog of OMG Modeling and Metadata Specifications. [Online] Last cited: April 14, 2010 http://www.omg.org/technology/ documents/modeling_spec_catalog.htm EMF website. [Online] Last Cited: April 14, 2010 http://www.eclipse.org/modeling/ emf/?project=emf XText. "XText textual modeling framework." 2010. http://www.eclipse.org/XText (accessed March 4, 2010). Xpand. "Xpand" 2010. http://wiki.eclipse.org/Xpand/ (accessed June 01, 2010). Haleplidis, E., O. Koufopavlou, and S. Denazis. "ForCES Implementation Experience Draft - work in progress." draft-haleplidisforces-implementation-experience-00.txt. IETF, May 2010.