Child pages
  • Contributions

<config>
<output path=’ C:\Users\ndavis\git\OnfInfoModelOutput\ ModelDescriptions\TR-512.2_v1.3_OnfCoreIm-ForwardingAndTermination.docx' />
</config>

<context model=’ C:\Users\ndavis\git\ONFInfoModel\OnfModel\ CoreModel.uml' element=’{0}’ importedBundles='gmf;papyrus' searchMetamodels='true'/>

<gendoc><drop/>

Change path substrings above from “ {path for output files}\ ” to your local path for the output files and “ {path for CoreModel}\ ” to your local path for the Core Model. <drop/>

DELETE: Prior to publishing this –gd.docx (including for review), change path substrings above from “ C:\Users\ndavis\git\OnfInfoModelOutput\ ” to “ {path for output files}\ ” and from “ C:\Users\ndavis\git\ONFInfoModel\OnfModel\ ” to “ {path for CoreModel}\ ” <drop/> [A1]

 

SUE Projects:1306 ONF Misc:5-Templates:5-21 MS Word - Spec:links:ONF-horiz-med.tif  

 

 

 

 

 

 

 

 

 

 

SUE Projects:1306 ONF Misc:5-Templates:5-21 MS Word - Spec:links:bottom-shape-cyan.jpg

ONF Document Type: Technical Recommendation

ONF Document Name: Core Information Model version 1.4
 

Disclaimer

THIS SPECIFICATION IS PROVIDED “AS IS” WITH NO WARRANTIES WHATSOEVER, INCLUDING ANY WARRANTY OF MERCHANTABILITY, NONINFRINGEMENT, FITNESS FOR ANY PARTICULAR PURPOSE, OR ANY WARRANTY OTHERWISE ARISING OUT OF ANY PROPOSAL, SPECIFICATION OR SAMPLE.

Any marks and brands contained herein are the property of their respective owners.

 

Open Networking Foundation

2275 E. Bayshore Road, Suite 103, Palo Alto, CA 94303

www.opennetworking.org

 

©2017 Open Networking Foundation. All rights reserved.

 

Open Networking Foundation, the ONF symbol, and OpenFlow are registered trademarks of the Open Networking Foundation, in the United States and/or in other countries. All other brands, products, or service names are or may be trademarks or service marks of, and are used to identify, products or services of their respective owners.   

 

Finalizing this document once generated… delete this text prior to publication:

-           Replace “{{..}}” with square brackets (which trip up Gendoc)

-           Select text in document from beginning of table of contents (first line) to end of document

  • Click menu item “Update Field” (on this large block of text)
    • if “Update Table…” dialogue appears select “Update entire table”
  • Repeat “update fields” 2 more times (on the same large block of text)
    • if “Update Table…” dialogue appears select “Update entire table”

-           Remove reviewer comment

Note that the table of contents and figures need to be updated several times as the table length changes the page numbering and the cross references will need to be re-updated.


Table of Contents

Disclaimer

Open Networking Foundation

Document History

1 Introduction

2 References

3 Definitions

4 Conventions

5 Introduction to the Core Network Model

5.1 Understanding the figures

6 Forwarding and Termination model detail

6.1.1.1 LogicalTerminationPoint (LTP)

6.1.1.2 LayerProtocol (LP)

6.1.2 Forwarding

6.1.2.1 ForwardingDomain (FD)

6.1.2.2 ForwardingConstruct (FC)

6.1.2.3 FcPort

6.1.2.4 Link

6.1.2.5 LinkPort

6.1.3 NetworkElement, NetworkControlDomain and SdnController

7 Explanatory Figures

7.1 Forwarding

7.1.1 Basic Forwarding

7.1.2 Forwarding the topology

7.2 Termination

7.3 Directionality

8 Fragment: Insert class <drop/>

9 Fragment: Insert standard diagram <drop/>

10 Fragment: Insert small diagram <drop/>

11 Fragment: Insert attribute row brief <drop/>

12 Fragment: Start attribute table brief <drop/>

13 Fragment: Insert Attribute table brief (old) <drop/>

14 Fragment: Insert Attribute table brief <drop/>

15 Fragment: Insert Ten Specified Attribute table brief <drop/>

List of Figures

Figure 1-1 Methodology of IM and DS Development

Document History

Version

Date

Description of Change

1.4

March 2018

Version 1.4 (Initial Version)

 

 

 

 

 

 

 

 

 

 


1        Introductio [A2] n

This document is an addendum to the TR-512_v1.4 ONF Core Information Model and forms part of the description of the ONF-CIM. For general overview material and references to the other parts refer to TR-512.1 ONF Core IM - Overview .

1.1      References

For a full list of references see TR-512.1 .

1.2      Definitions

For a full list of definition see TR-512.1 .

1.3      Conventions

See TR-512.1 for an explanation of:

  • UML conventions
  • Lifecycle Stereotypes
  • Diagram symbol set

1.4      Viewing UML diagrams

Some of the UML diagrams are very dense. To view them either zoom (sometimes to 400%) or open the associated image file (and zoom appropriately) or open the corresponding UML diagram via Papyrus (for each figure with a UML diagram the UML model diagram name is provided under the figure or within the figure).

1.5      Understanding the figures

Figures showing fragments of the model using standard UML symbols and also figures illustrating application of the model are provided throughout this document. Many of the application-oriented figures also provide UML class diagrams for the corresponding model fragments (see TR-512.1 for diagram symbol sets). All UML diagrams depict a subset of the relationships between the classes, such as inheritance (i.e. specialization), association relationships (such as aggregation and composition), and conditional features or capabilities. Some UML diagrams also show further details of the individual classes, such as their attributes and the data types used by the attributes.

1.6      Appendix Overview

This document is part of the Appendix to TR-512. An overview of the Appendix is provided in TR-512.A.1 .

 


2        Introduction to this Appendix document

This document provides various examples of the use of the CIM processing construct model to represent complex functions.

The examples in this document extend the simple examples given in TR-512.1 [A3] 2 - Software .

3        General Examples

3.1      Routing ‘Process’ on a Router

Here we have a scenario where an OSPF software process can support multiple OSPF instances.

The software is installed as a single binary (unit of installation).

The device lists the running processes, so we can track the routing software process.

 


3.2      Simple Host with Host OS VMM

This is a more complex example because we also have the VMM/VM virtualization layer to represent.

We will assume that we have a host that runs a VMM as a process (rather than a bare metal VMM). The host is also running other normal software processes. The VMM is running many VMs.

One thing to note is that we have two separate ‘namespaces’ (which can be conveniently represented using a ConstraintDomain).

Note that both the guest and the host operating systems can have separate files such as c:\word\myDoc.doc because these are in different FileSystems. Also the guest and the host operating systems can both have separate software processes with the same process id.

 

Note also that because we don’t have a storage model, we have related the FileSystem instance directly to the ConstraintDomain (FileSystemWithinCD). If a storage model is added in the future, then this needs to be removed and replaced with an association to the storage function.

We will explore the control point of view in a later example and have deliberately omitted it from these earlier examples to simplify the diagrams and help focus on the software aspects.


3.3      Simple Host with Container Engine and Containers

This is very similar to the VMM / VM case


3.4      CPU, Memory & Storage Example

We now have all of the model concepts that we need to show how we can link software processes to hardware.

Assume that we have a chassis holding compute blades. Each blade is essentially separate, so we can create a constraint domain relating to each physical blade boundary.

 

Note that at this stage, we don’t have classes to represent CPU or Memory (or Storage) in the ONF CIM, so what we are showing below are just placeholder instances showing how future classes could link in.

 

3.5      FPGA Example

In this example we will focus on a single physical blade and then focus on a FPGA within that blade.

There could be many variations in an actual implementation, so this example should be seen as  ‘illustrative’ rather than ‘definitive’.

Assuming that our physical unit is a blade server in a chassis, it will be represented as in our previous example.

We then create a new ConstraintDomain for our FPGA and represent the software and functions within the FPGA. Note that the information available from the FPGA may be limited or comprehensive, depending on the implementation.

 

 

 


3.6      Soft Switch Example

There are a number of soft switches available, both vendor proprietary and open source.

We will use Open vSwitch for our example because it is well known and has useful documentation.

Our open vSwitch could be running directly on a server or via a VM or container. This example shows the direct case, but it can be combined with the previous examples for the other cases.

 

We can see from the documentation extracts above that the vSwitch process can support many bridges (the functional switch blocks).

Our block diagram is consistent with our previous examples, but now we are also showing detail within each ProcessingConstruct and the related ForwardingDomain and its ports and the related LTP.

Note that in this case the legacy NetworkElement concept has been used to define the constraint boundary – of course a physical boundary or ControlDomain constraint boundary will also work.

 

[A4]

 


3.7      Constraint Domain Example

Now we will look at how the software model aligns with the ControlConstruct concept.

The figure below shows a diagram modified from our previous “Simple Host with Host OS VMM” example.

We can see that adding the control information adds a lot of complexity to the diagram (which is why it has been left off the previous examples).

There may be a number of variations to this example, but a common scenario is where we have :

  • a management interface to manage the host operating system
  • a separate management interface to manage the VMM and to enable the creation, configuration and removal of VMs (often provided with the VMM software)
  • a management interface to manage each of the guest operating systems

 

Note that the diagram highlights the information available from each ControlConstruct. The references that cross the ControlDomain boundaries are the ones that a network management system will need to stitch together to provide a consistent end-to-end view.

 

End of Document


[A1] Nigel to fix

[A2] To the reviewer

-           Hypertext document references “TR-512…” will not work at this point (as they reference the .pdf files that have not yet been generated).

-           There are some comments in some documents please consider the comments as you review.

-           If you have proposals to change text (typos or small rewordings for grammar errors), please modify the text with change tracking enabled.

-           If you have major concerns or questions or general comments please use word comments (like this)

 

[A3] Nigel to fix link

[A4] And LTP from software process ?