Child pages
  • Contributions

 

 

cid:image003.png@01D47AB3.2CCAF460

 

 

 

 

 

 

 

 

 

 

 


ONF Document Type: Technical Recommendation

ONF Document Name: Core Information Model version 1.5
 

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
1000 El Camino Real, Suite 100, Menlo Park, CA 94025
www.opennetworking.org

©2018 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.   

 

Important note

This Technical Recommendations has been approved by the Project TST, but has not been approved by the ONF board.  This Technical Recommendation is an update to a previously released TR specification, but it has been approved under the ONF publishing guidelines for 'Informational' publications that allow Project technical steering teams (TSTs) to authorize publication of Informational documents.  The designation of '-info' at the end of the document ID also reflects that the project team (not the ONF board) approved this TR.

 


Table of Contents

Disclaimer

Important note

Document History

1 Introduction

1.1 References

1.2 Definitions

1.3 Conventions

1.4 Viewing UML diagrams

1.5 Understanding the figures

2 Introduction to Location

3 Location model detail

3.1 Location Model

3.1.1 AsymmetricLocationRelationship

3.1.2 GeographicAddress

3.1.3 GeographicGeometry

3.1.4 GeographicLocation

3.1.5 GeographicPoint

3.1.6 GeographicPosition

3.1.7 GeographicSite

3.1.8 LocalAddress

3.1.9 LocalGeometry

3.1.10 ............................................................................................ LocalLocation

3.1.11 ............................................................................................. LocalPosition

3.1.12 .................................................................................. LocalReferencePoint

3.1.13 ..................................................................................... LocalRelativePoint

3.1.14 .................................................................................................... Location

3.1.15 .................................................................................. LocationRelationship

3.1.16 ........................................................................... LocationRelationshipType

3.1.17 ............................................................................................. LocationRole

3.1.18 ...................................................................................... LocationRoleType

3.1.19 .......................................................................... SimpleGeographicAddress

3.1.20 ................................................................................... SimpleLocalAddress

3.1.21 .................................................................. SymmetricLocationRelationship

3.2 Further detail

4 Location model examples

4.1 Site Contact

4.2 Global and Local Location Options

4.3 Device Location

4.4 Wifi Heat Map

4.5 Complex Address

List of Figures

Figure 3-1 Location Model

Figure 3 2 Location Model

Figure 3 3 Equipment Location Association

Figure 4 1 Simple Site Contact Example

Figure 4 2 Site Contact Party Roles

Figure 4 3 Primary and Secondary Site Contact Example

Figure 4 4 Global and Local Address

Figure 4 5 Global and Local position

Figure 4 6 Site with local locations

Figure 4 7 Device Location Example

Figure 4 8 Heat Map Example

Figure 4 9 Heat Map Instance Diagram

Document History

Version

Date

Description of Change

1.0

December 2019

Initial Version


1        Introduction [A1]

This document is an addendum to the TR-512 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 .

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 as well as 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.

2        Introduction to Location

The focus of this document is on concepts that relate to 'where' something is.

This topic is a common one, but unlike party, there are no good models that can be leveraged.

One approach that could be used in a model is just to add location (site) name and address attributes spread throughout the model as required. The problem is that name is often not a good identifier and address formats can be quite complex and different spellings can make it hard to compare them and then updating the data will become very complex.

The best approach is to factor out all location related information into a separate set of classes and to reference it from the rest of the model as required, and this is the approach taken in this document.

In the past, most location information was textual based, but now a lot more information systems also support map based locations and our model needs to support this too.

Another complication is that locating things 'internally' to a building is often done differently from 'outside' locations, so this model will cover both these cases.

This model covers the most common alternatives for external location:

  • (named) site
  • (postal) Address
  • (Geospatial) position (such as GPS coordinates)

For internal locations, the model will cover:

  • Local address (such as a bin location in a warehouse)
  • (local) position (often relative to an internal reference point, and more accurate than GPS)

 

Note also that this document doesn't propose a full, robust enterprise grade location model as it is targeted at supporting a network management environment only.

The model is however designed to be easily extended, for example by adding further geographic geometries or different geographic address formats.

 

A data dictionary that sets out the details of all classes, data types and attributes is also provided ( TR-512.DD ).


3        Location model detail

 

GeographicPoint – a point location as would be returned from a GPS unit. Note that the projection etc. details aren't shown – WGS84 can be assumed. Note that a GeographicPoint can be related to a LocalReferencePoint to allow conversion between global and local reference systems. [DN2]

 

 

 

[DN3]

 

CoreModel diagram: Location

Figure 3 - 1 Location Model

 

 

Figure 3 2 Location Model

 

3.1      Location Model

….

3.1.1      AsymmetricLocationRelationship

Qualified Name: Location::AsymmetricLocationRelationship

An abstract class used when a relationship contains two roles, such as "parent-child".
Concrete subclasses should be created as required.

This class is abstract.

 

Inherits properties from:

  • LocationRelationship

This class is Experimental.

Table 1 : Attributes for AsymmetricLocationRelationship

Attribute Name

Lifecycle Stereotype (empty = Mature)

Description

_toLocationRole

  Experimental

 

See referenced class

 

_fromLocationRole

  Experimental

 

See referenced class

 

 

 

3.1.2      GeographicAddress

Qualified Name: Location::GeographicAddress

An abstract class used to parent different global addressing options.

 

Inherits properties from:

  • GeographicLocation

This class is Experimental.

 

3.1.3      GeographicGeometry

Qualified Name: Location::GeographicGeometry

An abstract class used to parent different geographic options.
For example a location could be represented as a point or as a region.
At this stage, only the point option has been added to the model.
Note also that each geometry is given an identifier.
There are a number of reasons for this, one of which is that the measurement errors and precision (of floating numbers) means that some sort of buffer region is needed around each of the locations to determine if they are equal.
Also if regions are added as an option, this makes the calculation of 'equality' even more complex – just comparing uuid strings is much more efficient.

This class is abstract.

 

Inherits properties from:

  • GlobalClass

This class is Experimental.

 

3.1.4      GeographicLocation

Qualified Name: Location::GeographicLocation

An abstract class representing locations that are located using global definitions (often these are 'outside' locations).
A GeographicLocation can be related to zero, one or more geographic representations.

This class is abstract.

 

Inherits properties from:

  • Location

This class is Experimental.

Table 2 : Attributes for GeographicLocation

Attribute Name

Lifecycle Stereotype (empty = Mature)

Description

_geographicGeometry

 

See referenced class

 

 

 

3.1.5      GeographicPoint

Qualified Name: Location::GeographicPoint

To be provided

 

Inherits properties from:

  • GeographicGeometry

Table 3 : Attributes for GeographicPoint

Attribute Name

Lifecycle Stereotype (empty = Mature)

Description

latitude

  Experimental

 

To be provided

 

longitude

  Experimental

 

To be provided

 

elevation

  Experimental

 

To be provided

 

 

 

3.1.6      GeographicPosition

Qualified Name: Location::GeographicPosition

Represents just the geographic information (via an inherited association) so it needs no attributes

 

Inherits properties from:

  • GeographicLocation

This class is Experimental.

 

3.1.7      GeographicSite

Qualified Name: Location::GeographicSite

Represents a well-known named location, such as a service provider's central office

 

Inherits properties from:

  • GeographicLocation

This class is Experimental.

 

3.1.8      LocalAddress

Qualified Name: Location::LocalAddress

An abstract class used to parent different local addressing options.
For example it may represent a bin location in a warehouse "aisle 2/ bay 7/ level 6/ bin 23"

 

Inherits properties from:

  • LocalLocation

This class is Experimental.

 

3.1.9      LocalGeometry

Qualified Name: Location::LocalGeometry

An abstract class used to parent different local geometric options.
For example a local location could be represented as a point or as a region.
At this stage, only the point option has been added to the model.
Note also that each geometry is given an identifier using similar reasoning as for GeographicGeometry.

This class is abstract.

 

Inherits properties from:

  • GlobalClass

This class is Experimental.

 

3.1.10 LocalLocation

Qualified Name: Location::LocalLocation

An abstract class, representing locations that use local definitions (often these are locations inside a building).
A LocalLocation can be related to zero, one or more local geometric representations.

This class is abstract.

 

Inherits properties from:

  • Location

This class is Experimental.

Table 4 : Attributes for LocalLocation

Attribute Name

Lifecycle Stereotype (empty = Mature)

Description

_geographicLocation

  Experimental

 

See referenced class

 

_localGeometry

  Experimental

 

See referenced class

 

 

 

3.1.11 LocalPosition

Qualified Name: Location::LocalPosition

Represents just the local geometric information (via an inherited association) so it needs no attributes

 

Inherits properties from:

  • LocalLocation

This class is Experimental.

 

3.1.12 LocalReferencePoint

Qualified Name: Location::LocalReferencePoint

Defines the datum point and orientation (angles theta, pi, psi from north and straight up) of the local reference system.
Then LocalRelativePoints are defined as an offset from it.
Note also that the LocalReferencePoint can be related back to a GeographicPoint, allowing the local and geographic points to be merged into one seamless representation.

 

Inherits properties from:

  • LocalGeometry

This class is Experimental.

Table 5 : Attributes for LocalReferencePoint

Attribute Name

Lifecycle Stereotype (empty = Mature)

Description

x

  Experimental

 

To be provided

 

y

  Experimental

 

To be provided

 

z

  Experimental

 

To be provided

 

theta

  Experimental

 

To be provided

 

pi

  Experimental

 

To be provided

 

psi

  Experimental

 

To be provided

 

_geographicPoint

  Experimental

 

See referenced class

 

 

 

3.1.13 LocalRelativePoint

Qualified Name: Location::LocalRelativePoint

To be provided

 

Inherits properties from:

  • LocalGeometry

This class is Experimental.

Table 6 : Attributes for LocalRelativePoint

Attribute Name

Lifecycle Stereotype (empty = Mature)

Description

x

  Experimental

 

To be provided

 

y

  Experimental

 

To be provided

 

z

  Experimental

 

To be provided

 

_localReferencePoint

  Experimental

 

See referenced class

 

 

 

3.1.14 Location

Qualified Name: Location::Location

An abstract class that allows for decoupling of the model

This class is abstract.

 

Inherits properties from:

  • GlobalClass

This class is Experimental.

Table 7 : Attributes for Location

Attribute Name

Lifecycle Stereotype (empty = Mature)

Description

_locationRole

  Experimental

 

See referenced class

 

 

 

3.1.15 LocationRelationship

Qualified Name: Location::LocationRelationship

Allows the LocationRoles to be related.
So that a bank 'branch office' may be related to a bank 'main office' (parent-child relationship).
Note that this is used instead of a recursive composite style relationship.
In the Party model, roles are expected to be a strong concept. In the location model, roles are a weaker concept and shouldn't be overused.

This class is abstract.

 

Inherits properties from:

  • GlobalClass

This class is Experimental.

Table 8 : Attributes for LocationRelationship

Attribute Name

Lifecycle Stereotype (empty = Mature)

Description

_locationRelationshipType

  Experimental

 

See referenced class

 

 

 

3.1.16 LocationRelationshipType

Qualified Name: Location::LocationRelationshipType

To be provided

This class is Experimental.

 

3.1.17 LocationRole

Qualified Name: Location::LocationRole

Represents location contextual behavior, allowing the core concept to be reused in different situations.
For example a central office site may be a 'trunk hub' for fiber transmission and a 'delivery location' for given material orders.

 

Inherits properties from:

  • LocalClass

This class is Experimental.

Table 9 : Attributes for LocationRole

Attribute Name

Lifecycle Stereotype (empty = Mature)

Description

_locationRoleType

 

See referenced class

 

 

 

3.1.18 LocationRoleType

Qualified Name: Location::LocationRoleType

To be provided

This class is Experimental.

 

3.1.19 SimpleGeographicAddress

Qualified Name: Location::SimpleGeographicAddress

An address that doesn't try and break up the address string into all of its semantic parts.
It just opaquely represents the address as three lines of text.

 

Inherits properties from:

  • GeographicAddress

This class is Experimental.

Table 10 : Attributes for SimpleGeographicAddress

Attribute Name

Lifecycle Stereotype (empty = Mature)

Description

addressLine1

  Experimental

 

To be provided

 

addressLine2

  Experimental

 

To be provided

 

addressLine3

  Experimental

 

To be provided

 

 

 

3.1.20 SimpleLocalAddress

Qualified Name: Location::SimpleLocalAddress

A local address that just opaquely represents the local address as a single line of text.
A more complex subclass of LocalAddress could also be added that splits up the structure of the address.

 

Inherits properties from:

  • LocalAddress

This class is Experimental.

Table 11 : Attributes for SimpleLocalAddress

Attribute Name

Lifecycle Stereotype (empty = Mature)

Description

localAddress

  Experimental

 

To be provided

 

 

 

3.1.21 SymmetricLocationRelationship

Qualified Name: Location::SymmetricLocationRelationship

Used when a relationship contains one role, such as "alternative", this avoids having to create a relationship like "alternative-alternative".
Note that this class is concrete, unlike AsymmetricLocationRoleRelationship which is abstract.

 

Inherits properties from:

  • LocationRelationship

This class is Experimental.

Table 12 : Attributes for SymmetricLocationRelationship

Attribute Name

Lifecycle Stereotype (empty = Mature)

Description

_locationRole

  Experimental

 

See referenced class

 

_location

  Experimental

 

See referenced class

 

 

 


3.2      Further detail

To link the Location model into the CIM core, it makes sense to decouple the network function classes from the Location model. The network functions deliberately don't have an abstract parent (for modularity reasons) which means that the best approach is to link the inventory model to the Location model via ConstraintDomain. This decouples the two modules (reducing the number of associations) and allows inventory items to be grouped before relating them to a Location, reducing the number of association instances to be managed and also giving more sensible semantics.

 

Linking local and geographic locations is a common need, and roles don't really play a factor, so a special association is provided for that case, simplifying the number of instances required.

 

Figure 3 3 Equipment Location Association

 

Locating Equipment is a special case that deserves an optimized solution and for that case an association EquipmentLocatedAt is provided.

 


4        Location model examples

4.1      Site Contact

A site contact is the person who would be contacted to gain access to a Site.

We could create a special PartyRole of "site-contact" or we could just allow all employees to be site contacts.

The example below shows the latter option.

 

Figure 4 1 Simple Site Contact Example

 

If many people play roles in relation to the group of sites, then the ConstraintDomain should be made more generic, say to "Adelaide North Central Offices" and then specific site related roles can be used. This is better than creating and maintaining many equivalent groupings.


Below is shown another option.

Here, we have defined primary and secondary site contact Party roles.

Figure 4 2 Site Contact Party Roles

So now we can show that Irma is the primary contact and Fred is the secondary contact for the "Adelaide North Central Offices" group of Locations.

Figure 4 3 Primary and Secondary Site Contact Example

 


4.2      Global and Local Location Options

The global and local locations have been deliberately decoupled, so that they can be 'mixed and matched' as required.

This allows for various options, some of which are shown below.

 

Figure 4 4 Global and Local Address

 

Figure 4 5 Global and Local position


In the example below, we have a GeographicSite that is related to an address and a point on a map.

Two LocalPositions are defined in the Site, one is a local reference point and the other is a local point measured relative to that local reference point.

Figure 4 6 Site with local locations

 

 

 

 


4.3      Device Location

For Equipment, a special association is provided so that its representation can be optimized.

 

 

Figure 4 7 Device Location Example

 

Note that for SimpleLocalAddress, we are just using a single string with some sort of structure and delimiters.

If required, a more complex local address, such as one that had fields for each level in the local address could be added as a subclass. The issue is that the naming is likely to be company specific and may not follow simple rules, so it can't really be added to this document.


 

4.4      Wifi Heat Map

 

A common task is to be able to show a WiFi 'heat map".

In the diagram below, assume that the grid is a 1 meter spacing and that the local reference point is at the bottom left of the diagram and that the Y axis is aligned with north and the Z axis point straight up.

Figure 4 8 Heat Map Example

 


For this example, assume that the reference point is at floor level on the fifth floor of the building, and the access points are mounted on the ceiling (which is 4.0m from the floor).

Note that in this example, a structured local address of the form suite/rack/panel/slot is not appropriate, relative position is the best way of representing where the APs are.

 

Figure 4 9 Heat Map Instance Diagram


4.5      Complex Address

As well as the current simple address, the model could be extended by adding a more detailed address class as a subclass of GeographicAddress.

For example in MEF standard 57.1, they define a Fielded address with attributes

  • Fielded Address Identifier
  • Street Number
  • Street Number Suffix
  • Street Number Last
  • Street Number Suffix Last
  • Street Name
  • Street Type
  • Street Suffix
  • Locality
  • City
  • Postal Code
  • Postal Code Extension
  • State Or Province
  • Country
  • Sub Unit List
  • Level Type
  • Level Number
  • Building Name
  • Private Street Number
  • Private Street Name

As well as a FormattedAddress (which is similar to our SimpleGogrraphicAddress) with attributes

  • Formatted Address Identifier
  • Locality
  • City
  • Postal Code
  • Postal Code Extension
  • State Or Province
  • Country
  • Address Line 1
  • Address Line 2

 

Another definition of a complex address can be found in IETF RFCs

  • RFC 5774
  • RFC 5139
  • RFC 5491
  • RFC 7459
  • RFC4776


 

 

End of Document

 

 

 

 


[A1] 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)

[DN2] Chris: We do not have a class to represent this in the model.

[DN3] Your original diagram