Framework for Deriving Interface Data Schema from UML Information Models
draft-betts-netmod-framework-data-schema-uml-00
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Expired".
|
|
|---|---|---|---|
| Authors | Malcolm Betts , Nigel Davis , Hing-Kam Lam , Bernd Zeuner , Scott Mansfield , Paul Doolan | ||
| Last updated | 2014-10-24 | ||
| RFC stream | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-betts-netmod-framework-data-schema-uml-00
Netmod Working Group M. Betts, Ed.
Internet-Draft ZTE
Intended status: Informational N. Davis, Ed.
Expires: April 27, 2015 Ciena
K. Lam, Ed.
Alcatel-Lucent
B. Zeuner, Ed.
Deutsche Telekom
S. Mansfield, Ed.
Ericsson
P. Doolan, Ed.
Coriant
October 24, 2014
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.
Betts, et al. Expires April 27, 2015 [Page 1]
Internet-Draft Data Schema from UML Model October 2014
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 . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. Basic Concepts . . . . . . . . . . . . . . . . . . . . . . . 3
3. Information Modeling . . . . . . . . . . . . . . . . . . . . 4
3.1. Unified Modeling Language . . . . . . . . . . . . . . . . 4
3.2. Standard UML Information Model . . . . . . . . . . . . . 5
4. From UML IM to Data Schema Definition . . . . . . . . . . . . 6
4.1. Common Information Model . . . . . . . . . . . . . . . . 8
4.2. Common Information Model View for a Specific Purpose . . 8
4.3. Data Schema . . . . . . . . . . . . . . . . . . . . . . . 9
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10
6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 10
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
8. Security Considerations . . . . . . . . . . . . . . . . . . . 10
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
9.1. Normative References . . . . . . . . . . . . . . . . . . 10
9.2. Informative References . . . . . . . . . . . . . . . . . 10
Appendix A. Additional Stuff . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
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
Betts, et al. Expires April 27, 2015 [Page 2]
Internet-Draft Data Schema from UML Model October 2014
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
Betts, et al. Expires April 27, 2015 [Page 3]
Internet-Draft Data Schema from UML Model October 2014
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:
o To define a set of objects (instantiated classes that, if
organized, describe a data model)
o As an information model
o As a metamodel (used to create an information model)
o As a meta-metamodel
Betts, et al. Expires April 27, 2015 [Page 4]
Internet-Draft Data Schema from UML Model October 2014
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:
o ITU-T G.874.1 (2012), Optical transport network: Protocol-neutral
management information model for the network element view
[ITU-T_G.874.1]
o ITU-T G.8052/Y.1346 (2013), Protocol-neutral management
information model for the Ethernet Transport capable network
element [ITU-T_G.8052]
o ITU-T G.8152/Y.1375 (draft in progress), Protocol-neutral
management information model for the MPLS-TP network element
[ITU-T_G.8152]
o 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
Betts, et al. Expires April 27, 2015 [Page 5]
Internet-Draft Data Schema from UML Model October 2014
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.
Betts, et al. Expires April 27, 2015 [Page 6]
Internet-Draft Data Schema from UML Model October 2014
+-------------------------+
|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| |
| +-----------+ +-----------+ +-----------+ +-------------+ |
+-------------------------------------------------------------------+
High-level methodology for deriving interface protocol specific data
schema from UML information model
Figure 1
The aforementioned guideline document [ONF_UML_Guide] also provides
guidelines for creating a common information model view for a
specific purpose. Guidelines are under development for conversion
(mapping) from an UML information model into various protocol
Betts, et al. Expires April 27, 2015 [Page 7]
Internet-Draft Data Schema from UML Model October 2014
specific interface data schema such as REST/JSON, Netconf/YANG
interface, etc.
Applying such guidelines, protocol-specific interface data schema may
be derived from existing, and emerging, standard UML information
models addressing the forwarding and networking domains. Examples
include MEF 38 [MEF_38] and MEF 39 [MEF_39], which provide YANG
modules derived from UML information models G.8052 [ITU-T_G.8052] and
MEF 7.1 [MEF_7.1] for Service OAM Fault and Performance Monitoring,
respectively. YANG models could be derived for OTN in a similar way
using the G.874.1 [ITU-T_G.874.1] UML information model as a base.
The following subsections provide further elaboration of the high-
level methodology described above.
4.1. Common Information Model
A common information model includes the objects/packages, their
properties (represented as attributes), relationships, etc. that are
necessary to describe the domain for the applications being
developed. It will be necessary to continually expand and refine the
common model over time as new forwarding technologies, capabilities
and applications are encompassed and new insights are gained. To
allow these extensions to be made in a seamless manner, the common
information model is structured into a number of model fragments.
o Core model structured as a set of modules, each addressing a
specific topic to allow for easier navigation.
o Forwarding plane technology specific or application specific model
fragments, which contain objects, attributes and associations that
relate solely to their area of expertise.
This modelling approach enables application specific and forwarding
plane technology specific extensions to be developed independently.
4.2. Common Information Model View for a Specific Purpose
The next step is the development of a purpose specific information
model view, which is a subset of the common information model. It is
developed by:
o Pruning to remove the objects/packages/attributes that are not
required.
- Selecting the required object classes from the common IM (all
mandatory attributes and packages must be included)
Betts, et al. Expires April 27, 2015 [Page 8]
Internet-Draft Data Schema from UML Model October 2014
- Selecting the required conditional packages and optional
attributes (note that, where appropriate, conditional packages
and optional attributes may be declared mandatory)
- Removing any optional associations that are not required
o Refactoring to reduce association flexibility, such as:
- Reducing multiplicity (e.g., from [1..*] to [1])
- Where possible, reducing the depth of the inheritance (i.e.,
specialization), where possible (e.g., by combining object
classes)
- Adding reverse navigation, if useful for the client
- Constraining attribute definitions
4.3. Data Schema
The data schema (DS) is constructed by mapping of the purpose
specific information model view and adding the interface protocol
specific operations and notifications. The operations should include
data structures taken directly from the purpose specific information
model view with no further adjustment.
The development of the data schema should consider the following:
o The operations should act on the information in a way consistent
with the modeled object lifecycle interdependency rules.
- Lifecycle dependencies to ensure sensible interface operation
structuring and interface flow rules
- Usage of transaction approach style of interface to account for
lifecycle dependencies of the model
o The operations should abide the attribute properties. Read only
attributes should not be included in data related to creation of
an object (e.g., not in createData) or in specification of a
desired object structure outcome.
o Usage of ranges, etc. to allow "effort" statement, optionality and
negotiation to be supported by the interface.
Betts, et al. Expires April 27, 2015 [Page 9]
Internet-Draft Data Schema from UML Model October 2014
5. Acknowledgements
6. Contributors
Eve Varma
Alcatel-Lucent
USA
email eve.varma@alcatel-lucent.com
Dave Hood
Ericsson
USA
email dave.hood@ericsson.com
7. IANA Considerations
This memo includes no request to IANA.
8. Security Considerations
TBD
9. References
9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3444] Pras, A. and J. Schoenwaelder, "On the Difference between
Information Models and Data Models", RFC 3444, January
2003.
9.2. Informative References
[ISO_IEC_UML]
ISO/IEC, "ISO/IEC 19505-1:2012 - Information technology -
Object Management Group Unified Modeling Language (OMG
UML) - Part 1: Infrastructure. Iso.org.2012-04-20.
Retrieved 2014-04-10", 2012.
[ITU-T_G.8052]
ITU-T, "ITU-T G.8052/Y.1346 (2013), Protocol-neutral
management information model for the Ethernet Transport
capable network element", 2013,
<http://www.itu.int/rec/T-REC-G.8052/en>.
Betts, et al. Expires April 27, 2015 [Page 10]
Internet-Draft Data Schema from UML Model October 2014
[ITU-T_G.8152]
ITU-T, "ITU-T G.8152/Y.1375 (draft in progress), Protocol-
neutral management information model for the MPLS-TP
network element", 201x.
[ITU-T_G.874.1]
ITU-T, "ITU-T G.874.1 (2012), Optical transport network:
Protocol-neutral management information model for the
network element view", 2012,
<http://www.itu.int/rec/T-REC-G.874.1/en>.
[ITU-T_G.gim]
ITU-T, "Generic protocol-neutral management Information
Model for transport network resources", 201x.
[MEF_38] MEF, "Service OAM Fault Management YANG Modules", 2012, <h
ttp://www.metroethernetforum.org/Assets/Technical_Specific
ations/PDF/MEF_38.pdf>.
[MEF_39] MEF, "Service OAM Performance Monitoring YANG Module",
2012, <http://www.metroethernetforum.org/Assets/Technical_
Specifications/PDF/MEF_39.pdf>.
[MEF_7.1] MEF, "Carrier Ethernet Management Information Model
[superseded by MEF 7.2, which supports additional sets of
service attributes defined in recent MEF specifications]",
2009, <http://www.metroethernetforum.org/Assets/Technical_
Specifications/PDF/MEF7.1.pdf>.
[NGMN_NGCOR]
NGMN Alliance, "Next Generation Converged Operations
Requirements (NGCOR)", 2013,
<http://www.ngmn.org/uploads/media/
NGMN_Next_Generation_Converged_Operations_Requirements_-
_Final_Deliverable.pdf>.
[OMG_UML] OMG, "OMG Unified Modelling Language (UML),
Infrastructure, Version 2.4.1", 2011.
[ONF_UML_Guide]
ONF, "onf2014.491.03 UML Modeling Guidelines", 2014.
[TMF_MTNM]
TM Forum, "TM Forum Multi Technology Network Management,
Release 3.5", 2009,
<http://www.tmforum.org/MTNM/1689/www.tmforum.org/
DownloadCenter/7549/home.html#mtnm>.
Betts, et al. Expires April 27, 2015 [Page 11]
Internet-Draft Data Schema from UML Model October 2014
[TMF_MTOSI]
TM Forum, "TM Forum Multi Technology OS Interface, Release
3.0", 2012,
<http://www.tmforum.org/MTNM/1689/www.tmforum.org/
DownloadCenter/7549/home.html#mtosi>.
[TMF_TR225]
TM Forum, "TM Forum TR225, Logical Resource: Network
Function Model", 2014.
Appendix A. Additional Stuff
TBD
Authors' Addresses
Malcolm Betts (editor)
ZTE
Canada
Phone: +1 678 534 2542
Email: malcolm.betts@zte.com.cn
Nigel Davis (editor)
Ciena
UK
Email: ndavis@ciena.com
Kam Lam (editor)
Alcatel-Lucent
USA
Phone: +1 732 331 3476
Email: kam.lam@alcatel-lucent.com
Bernd Zeuner (editor)
Deutsche Telekom
Germany
Phone: +49 6151 58 12086
Email: b.zeuner@telekom.de
Betts, et al. Expires April 27, 2015 [Page 12]
Internet-Draft Data Schema from UML Model October 2014
Scott Mansfield (editor)
Ericsson
USA
Phone: +1 724 931 9316
Email: scott.mansfield@ericsson.com
Paul Doolan (editor)
Coriant
Germany
Phone: +1 972 357 5822
Email: paul.doolan@coriant.com
Betts, et al. Expires April 27, 2015 [Page 13]