Framework for Deriving Interface Data Schema from UML Information Models
draft-betts-netmod-framework-data-schema-uml-00

Abstract

This draft describes a framework for how interface protocol specific data schema can be systematically derived from an underlying common information model, focusing upon the networking and forwarding domain. The benefit of using such an approach in interface specification development is to promote convergence, interoperability, and efficiency.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on April 27, 2015.

Copyright Notice

Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

Table of Contents

• 1. Introduction
• 1.1. Requirements Language
• 2. Basic Concepts
• 3. Information Modeling
• 3.1. Unified Modeling Language
• 3.2. Standard UML Information Model
• 4. From UML IM to Data Schema Definition
• 4.1. Common Information Model
• 4.2. Common Information Model View for a Specific Purpose
• 4.3. Data Schema
• 5. Acknowledgements
• 6. Contributors
• 7. IANA Considerations
• 8. Security Considerations
• 9. References
• 9.1. Normative References
• 9.2. Informative References
• Appendix A. Additional Stuff
• Authors' Addresses

1. Introduction

Interface specifications are often generated as point solutions where the designer codes a particular interface from domain (problem space) concepts that may not be explicitly captured, may be defined using localized terminology that is subject to ambiguity in interpretation, and is highly focussed on a particular use-case/application. The designer typically provides a representation of the interface schema in the form of a data schema [RFC3444](i.e., data structures conveyed over the interface), which only exposes the view of the domain relevant at that specific interface. As this data schema is a simple statement of the particular interface, it solely describes relationships relevant to the specific realization, having no inherent relationship to other interfaces in the system.

Approaching the development of interface specifications on a per use-case/application basis tends to promote unnecessary variety through a proliferation of similar interfaces, resulting in unnecessary divergences that limit interoperability. It also risks confusion of representational artifacts with fundamental characteristics of the information to be conveyed across the interface. There is also a risk that conflicting representations of the same information may be generated. Finally, each such interface appears to stand alone, thereby failing to capture relationships to other aspects of the same (or different) domains that are not explicitly needed for the interface.

This draft describes a framework for how data schema and their associated purpose-specific interfaces/APIs can be systematically derived from an underlying common information model, focusing upon the networking and forwarding domain. The benefit of using such an approach in the development of interface specifications is to promote convergence, interoperability, and efficiency.

1.1. Requirements Language

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].

2. Basic Concepts

An information model condenses domain knowledge and insights to provide a representation of its essential concepts, structures, and interrelationships. In capturing domain understanding, such a model offers a coherent and consistent terminology and structure, expresses the semantics of the domain, and interrelates all relevant aspects of the domain. It enables a consistent expression of information that improves interoperability between software components at interfaces derived from it. A "good" information model should capture domain best practices, and be designed to support domain variety as well as extensibility and evolution. Examples of domains include networking and forwarding, storage, etc. A single industry information model is the assembly of all domain information models, which inter-relate at "touch points".

There may be several relevant views of any particular domain, depending upon the perspective of the viewer, all of which are interrelated and involve subsets of the information model, and none of which contradict each other. (It should be noted that one view provides the information model representation of the overall domain.) To form a particular view, some elements of the model may be pruned. Additionally, for efficiency, some systematic refactoring of the information model may also occur.

In this draft, the term data schema is used in the context of either: (i) a specific protocol that is used to implement a purpose specific interface, or (ii) a programming language that is used to invoke a purpose specific API.

While a purpose specific interface/API is not a simple direct encoding of the information model of the overall domain, it is by its nature based on a relevant view of the information model of the domain. It must be completely and consistently traceable to this view and should use the associated domain terminology. Depending on its application, a particular view may lead to a number of encoded forms at various types of interfaces/APIs. The information model does not dictate the encoded form, which will depend upon such factors as necessary capability, interaction style, and programming language.

3. Information Modeling

This section introduces the Unified Modeling Language (UML), which has been used to model application structure, behavior, and architecture (in addition to business process and data structure). It also provides references to existing and ongoing work on standard information models based on UML.

3.1. Unified Modeling Language

The information model is expressed in terms of the Unified Modeling Language (UML) [OMG_UML], which was developed by the Object Management Group. It is a general-purpose modeling language in the field of software engineering. In 2000 the Unified Modeling Language was also accepted by the International Organization for Standardization (ISO) as an approved ISO standard [ISO_IEC_UML]. UML may be used in four ways:

• To define a set of objects (instantiated classes that, if organized, describe a data model)
• As an information model
• As a metamodel (used to create an information model)
• As a meta-metamodel

UML defines a number of basic model elements (UML artefacts), such as object classes, attributes, associations, interfaces, operations, operation parameters, data types, etc. In order to assure a consistent and harmonized modelling approach, and to ensure uniformity in the application of UML to a problem domain, a subset of the basic model artefacts should be selected according to guidelines for creating an information model expressed in UML [ONF_UML_Guide]. The guidelines are generic; i.e., they are not specific to any particular domain that the information model is addressing, nor are they restricted to any particular protocol interface data schema.

3.2. Standard UML Information Model

Information models expressed in UML, primarily focused upon the networking and forwarding domain, have been, and are in the process of being, developed in ITU-T, TM Forum, NGMN, 3GPP, MEF, ONF, and others.

ITU-T Recommendations are focused on understanding the telecommunications problem space and developing information models addressing network and network element considerations. Some examples of available standard ITU-T information models relevant to the networking and forwarding domain include:

• ITU-T G.874.1 (2012), Optical transport network: Protocol-neutral management information model for the network element view [ITU-T_G.874.1]
• ITU-T G.8052/Y.1346 (2013), Protocol-neutral management information model for the Ethernet Transport capable network element [ITU-T_G.8052]
• ITU-T G.8152/Y.1375 (draft in progress), Protocol-neutral management information model for the MPLS-TP network element [ITU-T_G.8152]
• ITU-T G.gim (draft in progress), Generic protocol-neutral management Information Model for transport resources [ITU-T_G.gim]

The above information models are developed from ITU-T Recommendations that define the respective transport technology functional models and management requirements.

The TM Forum community has likewise developed extensive models of the same space from the network level management perspective [TMF_MTNM] [TMF_MTOSI] [TMF_TR225]. The basis for all functions made available to the network level management is defined in the protocol-neutral network element level management work done in ITU-T. Its models thus complement the ITU-T information models. In further collaboration with 3GPP, considerable joint effort has been devoted to develop a consistent and coherent approach to that space.

The NGMN has published a document called Next Generation Converged Operations Requirements (NGCOR) [NGMN_NGCOR], with the expressed purpose of taking these requirements into account when converged management interfaces for mobile and fixed networks are being standardized in the SDOs. An ongoing collaboration called the Multi-SDO Project on Converged Management is taking care that the requirements are considered during the specification of new interfaces. It includes participants from ETSI, NGMN, TMF, 3GPP, and other SDOs, equipment vendors, OS vendors and service providers.

4. From UML IM to Data Schema Definition

This section outlines the steps to be taken in deriving data schema from the information model specifications.

Figure 1 below provides an overview of the structure of a common information model and how purpose specific IM views and data schema may be derived from it.

The common information model is a library of model artefacts organized into a number of information model fragments, to facilitate the independent development of technology and application specific extensions. The core model fragment refers to information model artefacts that could be commonly used regardless of the specific technology or application domain. The forwarding technology specific model fragment refers to technology specific extensions; e.g., for OTN, Ethernet, SDH, etc. The application specific fragment refers to extensions for supporting particular applications. For purposes of navigability, the core information model fragment is itself structured as a series of modules. For example, a module on artefacts for identifiers and naming, a module on artefacts for forwarding aspects that are independent of the specific forwarding technologies, etc.

+-------------------------+
|Common Information Model |
|+-----------------------+|
||Core model fragment    ||
||* module-1             ||
||* module-2             ||                                         
||* ...                  ||                            +-----------+
||* module-n             ||                            |Protocol 1 |
|+-----------------------+|          +----------+ Map  |Interface  |
|+-----------------------+|          |View of   |---+\ |data schema|
||Forwarding technology  ||--------\ |the       |---+/ +-----------+
||specific model fragment|| Prune/  \|Common IM |           
|+-----------------------+| refactor/|for a     |---+\ +-----------+
|+-----------------------+|--------/ |particular|--.+/ |Protocol 2 |
||Application            ||      .   |purpose   || .   |Interface  |
||specific model fragment||--------\ +----------+|  .  |data schema|
|+-----------------------+| Prune/  \ |          ||  . +-----------+
|            .            | refactor/ +----------+|  .
|            .            |--------/   |          |  .
|            .            |   .  .     +----------+  .
|+-----------------------+|    . .        .          .
||xxx                    ||     ..       .           .
||specific model fragment||      .      .            .
|+-----------------------+|       .    .             .
|                         |        .  .              .
+-------------------------+         ..               . 
                 .  .               ..                .
                .    .             .  .                .
               .      .           .    .                .
+-------------.--------.---------.------.----------------.---------- 
|Guidelines  .          .       .        .                .         \
|           .            .     .          .         +-------------  |
| +-----------      +-----------    +-----------    | protocol    \ |
| | Model     \     | Use of    \   | Common    \   | specific    | |
| | structure |     | UML       |   | process   |   | mapping rule| |
| +-----------+     +-----------+   +-----------+   +-------------+ |
+-------------------------------------------------------------------+

            

            Eve Varma
            Alcatel-Lucent
            USA
            email eve.varma@alcatel-lucent.com
	
	  

            Dave Hood
            Ericsson
            USA
            email dave.hood@ericsson.com