Child pages
  • Contributions

 

 

 

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.3.1
 

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

©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 [MB1]

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 the Foundation Model

3 CoreFoundationModel

3.1 Naming and identifiers

3.1.1 Key considerations

3.1.2 Classes and attributes

3.1.2.1 Address

3.1.2.2 ConditionalPackage

3.1.2.3 Extension

3.1.2.4 GlobalClass

3.1.2.5 Label

3.1.2.6 LocalClass

3.1.2.7 Name

3.1.2.8 NameAndValueAuthority

3.1.2.9 UniversalIdAuthority

3.1.3 DataTypes

3.1.3.1 Address

3.1.3.2 AddressElement

3.1.3.3 LocalIdAndClass

3.1.3.4 NameAndClass

3.1.3.5 NameAndValue

3.1.3.6 UniversalId

3.1.4 Use of names, identifiers and addresses

3.2 States

3.2.1 Classes and attributes

3.2.1.1 AdministrativeState

3.2.1.2 OperationalState

3.2.1.3 LifecycleState

3.2.1.4 State_Pac

3.2.2 Enumerations

3.2.2.1 AdministrativeState

3.2.2.2 OperationalState

3.2.2.3 LifecycleState

3.2.3 Relationship between states in the same context

3.2.4 State transition diagrams

3.2.4.1 Administrative State

3.2.4.2 Operational State

3.2.4.3 Lifecycle State

3.2.5 Use of states

3.2.5.1 Model context

3.2.5.2 Instance relationships

3.2.5.3 Protected entities

3.2.5.4 Split entities

3.2.5.5 Merged entities

List of Figures

Figure 3-1 Class Diagram for Naming and Identifier of Objects

Figure 3-2 Sketch of names, identifiers and addresses for various entities

Figure 3-3 States for all Objects

Figure 3-4 Administrative State

Figure 3-5 Operational State

Figure 3-6 Lifecycle State

Document History

Version

Date

Description of Change

1.0

March 30, 2015

Initial version of the base document of the "Core Information Model" fragment of the ONF Common Information Model (ONF-CIM).

1.1

November 24, 2015

Version 1.1

1.2

September 20, 2016

Version 1.2 [Note Version 1.1 was a single document whereas 1.2 is broken into a number of separate parts]

1.3

September 2017

Version 1.3 [Published via wiki only]

1.3.1

January 2018

Addition of text related to approval status.

1.4.0.d00

2018/03/06

First draft of v1.4.0
Added information on entity life cycle from oimt2017.MB.001.02.entity-lifecycle.docx
Proposed updates to the LifecycleState Property for the “states”

1.4.d01

2018/03 /14

Edited during review in London

1.4.0.d02

2018/0 4 / 20

Updated following review at the London interim meeting

  • Proposed updates to the Lifecy cleState Property for names and identifiers
  • Changed description of “ SHUTTING_DOWN ” and added PENDING_REMOVAL_INUSE ” and “ PENDING_REMOVAL_FREE ” to allow a server to indicate to a client that a resource will be withdrawn.

 


1        Introduction

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

2        Introduction to the Foundation Model

The focus of this document is the parts of Core Foundation Model of the ONF-CIM that deal with naming, identifiers and state.

The CoreFoundationModel covers all aspects of naming and addressing for all classes in the ONF-CIM. The focus of this document is:

  • Definition of terminology related to naming and identity
  • Description of the model for naming and identifiers that is inherited by other models
  • Description of the state model

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

3        CoreFoundationModel

This Model includes all aspects of the core that are relevant to all other parts of the ONF CIM such as identifiers, naming and states.

3.1      Naming and identifiers

3.1.1      Key considerations

To communicate about a thing it is necessary to have some way of referring to that thing, i.e., to have some reference. Terms such as name and identifier are often used when describing the reference. Unfortunately these terms in general usage have ambiguity in their definition that leads to erroneous system behavior. To ensure that the controller system behavior is not erroneous, the model will adopt the following principal definitions:

  • Entity [1] : Has identity, defined boundary, properties, functionality and lifecycle in a global context.
  • Entity Feature [2] : An inseparable, externally distinguishable part of an entity.
    • Examples: A pin in connector (see TR-512.6 ), the ports of a FC (see TR-512.2 ), a face of a cube, the handle of a cup.
    • Note that this is important from a modeling perspective as the representation appears similar to that of an Entity
    • Represented using a UML class
  • Role: A specific structure of responsibilities, knowledge, skills, and attitudes in the context of some activity or greater structure. The role has an identity and identifier.
  • Identifier: A property of an entity/role with a value that is unique within an identifier space, where the identifier space is itself globally unique, and immutable. An identifier carries no semantics with respect to the purpose or state of the entity.
  • Universally Unique Identifier [3] (UUID): An identifier that is universally unique.
  • Local ID: An identifier that is unique in the context of some scope that is less than the global scope.
  • Name: A property of an entity with a value that is unique in some namespace but may change during the life of the entity. A name carries no semantics with respect to the purpose of the entity.
  • Label: A property of an entity with a value that is not expected to be unique and is allowed to change. A label carries no semantics with respect to the purpose of the entity and has no effect on the entity behavior or state.
    • A label can be used to carry a freeform text string for any operator purpose. The contents of a label in one view may happen to be the value of a name or identifier in another view. From the perspective of the view with the label there is no expectation other than the value is a string.
  • Place: Where something is located
  • Address: A structure of named values [4] in some address space that defines a location (a volume in that address space) where the structure is a nested hierarchy.
    • A named value may be a name or identifier, the name of the value may be a name or identifier
  • Route: the way (via specified intermediate locations and paths) to get to one location from another.
  • Property: A quality associated with a thing, structure or location.
  • Semantics: Meaning.
  • Reference: Data in a communication between two applications that allows a shared understanding of the individual things.
    • This could be an identifier (including a UUID), a name, an address, or a route, depending upon the needs

Note:

  • An entity may be known to be at a place in some functional or physical structure.
  • A role may be known to be at a place in some process or behavioral structure.

The figure below illustrates the naming/identifier-related attributes defined in the ONF-CIM. They are Universally Unique ID (UUID), Local ID, Name and Label.

The model includes two abstract classes that provide names and identifiers, the GlobalClass and the LocalClass. [5] A GlobalClass represents a type of thing that has instances which can exist in their own right (independently of any others). A LocalClass represents a type of thing that is inseparable from a GlobalClass, but that is a distinct feature of that GlobalClass such that the instances of LocalClass are able to have associations with other instances. The mandatory LocalId of the LocalClass instance is unique in the context of the GlobalClass instance, from which it is inseparable.

The model also includes Extension which is not related to naming/identification. Extension provides an opportunity to define properties not declared in the class that extend the class enabling a realization with simple ad-hoc extension of standard classes to be conformant.

Note that a UUID is applicable only to global type object classes (i.e., subclass of GlobalClass) that their instances can exist on their own right, e.g., LTP, FD, Link, and FC , and NetworkElement . The other naming/identifier-related attributes are applicable to both global type object classes and local type object classes (i.e., subclass of LocalClass). [6]

 

CoreModel diagram: Foundation-CommonPackagesNoNotes

Figure 3 - 1 Class Diagram for Naming and Identifier of Objects

3.1.2      Classes and attributes

3.1.2.1    Address

Qualified Name: CoreModel::CoreFoundationModel::SuperClassesAndCommonPackages::ObjectClasses::Address

Provides an opportunity to state the location of the entity via one or more hierarchies of narrowing contexts.

This class is abstract.

Table 1 : Attributes for Address

Attribute Name

Lifecycle Stereotype (empty = Mature)

Description

address

  Experimental

 

One or more descriptions of the location.

 

 

 

 

3.1.2.2    ConditionalPackage

Qualified Name: CoreModel::CoreFoundationModel::SuperClassesAndCommonPackages::ObjectClasses::ConditionalPackage

The base class for conditional packages.

This class is abstract.

 

Inherits properties from:

  • Label
  • Extension

This class is Experimental.

 

3.1.2.3    Extension

Qualified Name: CoreModel::CoreFoundationModel::SuperClassesAndCommonPackages::ObjectClasses::Extension

Extension provides an opportunity to define properties not declared in the class that extend the class enabling a realization with simple ad-hoc extension of standard classes to be conformant.

This class is abstract.

Table 2 : Attributes for Extension

Attribute Name

Lifecycle Stereotype (empty = Mature)

Description

extension

 

List of simple name-value extensions.

 

 

 

 

3.1.2.4    GlobalClass

Qualified Name: CoreModel::CoreFoundationModel::SuperClassesAndCommonPackages::ObjectClasses::GlobalClass

Represents a type of thing (an Entity) that has instances which can exist in their own right (independently of any others).

Entity: Has identity, defined boundary, properties, functionality and lifecycle in a global context.

(This should be considered in the context of a Class: (usage) The representation of a thing that may be an entity or an inseparable Entity Feature).

This class is abstract.

 

Inherits properties from:

  • Address
  • Name
  • Label
  • State_Pac
  • Extension

Table 3 : Attributes for GlobalClass

Attribute Name

Lifecycle Stereotype (empty = Mature)

Description

localId

 

An identifier that is unique in the context of some scope that is less than the global scope.

(This should be considered in the context of Identifier: A property of an entity/role with a value that is unique within an identifier space, where the identifier space is itself unique, and immutable. The identifier therefore represents the identity of the entity/role. An identifier carries no semantics with respect to the purpose of the entity.)

 

 

uuid

 

UUID: An identifier that is universally unique

(This should be considered in the context of Identifier: A property of an entity/role with a value that is unique within an identifier space, where the identifier space is itself globally unique, and immutable. An identifier carries no semantics with respect to the purpose or state of the entity)
The uuid should be treated as opaque by the user.

 

 

 

 

3.1.2.5    Label

Qualified Name: CoreModel::CoreFoundationModel::SuperClassesAndCommonPackages::ObjectClasses::Label

A property of an entity with a value that is not expected to be unique and is allowed to change. A label carries no semantics with respect to the purpose of the entity and has no effect on the entity behavior or state.

This class is abstract.

Table 4 : Attributes for Label

Attribute Name

Lifecycle Stereotype (empty = Mature)

Description

label

 

List of labels.

 

 

 

 

3.1.2.6    LocalClass

Qualified Name: CoreModel::CoreFoundationModel::SuperClassesAndCommonPackages::ObjectClasses::LocalClass

A LocalClass represents a Feature of an Entity. It is inseparable from a GlobalClass but is a distinct feature of that GlobalClass such that the instances of LocalClass are able to have associations to other instances.
Feature of an Entity: An inseparable, externally distinguishable part of an entity.
The mandatory LocalId of the LocalClass instance is unique in the context of the GlobalClass from which it is inseparable.
(This should be considered in the context of a Class: (usage) The representation of a thing that may be an entity or an inseparable feature of an entity.)
 

This class is abstract.

 

Inherits properties from:

  • Address
  • Name
  • Label
  • State_Pac
  • Extension

Table 5 : Attributes for LocalClass

Attribute Name

Lifecycle Stereotype (empty = Mature)

Description

localId

 

An identifier that is unique in the context of some scope that is less than the global scope.

(This should be considered in the context of Identifier: A property of an entity/role with a value that is unique within an identifier space, where the identifier space is itself unique, and immutable. The identifier therefore represents the identity of the entity/role. An identifier carries no semantics with respect to the purpose of the entity.)

 

 

 

 

3.1.2.7    Name

Qualified Name: CoreModel::CoreFoundationModel::SuperClassesAndCommonPackages::ObjectClasses::Name

Name: A property of an entity with a value that is unique in some namespace but may change during the life of the entity. A name carries no semantics with respect to the purpose of the entity.

This class is abstract.

Table 6 : Attributes for Name

Attribute Name

Lifecycle Stereotype (empty = Mature)

Description

name

 

List of names.

 

 

 

 

3.1.2.8    NameAndValueAuthority

Qualified Name: CoreModel::CoreFoundationModel::SuperClassesAndCommonPackages::ObjectClasses::NameAndValueAuthority

Represents the authority that controls the legal values for the names and values of a name/value attribute.

This class is abstract.

This class is Preliminary.

Table 7 : Attributes for NameAndValueAuthority

Attribute Name

Lifecycle Stereotype (empty = Mature)

Description

uuid

 

The UUID for the NameAndValueAuthority.

 

 

 

 

3.1.2.9    UniversalIdAuthority

Qualified Name: CoreModel::CoreFoundationModel::SuperClassesAndCommonPackages::ObjectClasses::UniversalIdAuthority

Represents the authority that controls the allocation of UUIDs.

This class is abstract.

This class is Preliminary.

Table 8 : Attributes for UniversalIdAuthority

Attribute Name

Lifecycle Stereotype (empty = Mature)

Description

uuid

 

The UUID for the UUID authority.

 

 

 

 

3.1.3      DataTypes [MB2] [MB3]

3.1.3.1    Address

Qualified Name: CoreModel::CoreFoundationModel::SuperClassesAndCommonPackages::TypeDefinitions::Address

A description of location via a hierarchy of narrowing contexts.

 

Table 9 : Attributes for Address

Attribute Name

Lifecycle Stereotype (empty = Mature)

Description

addressName

  Preliminary   Experimental

 

The name of the address (to allow the specific hierarchy to be distinguished from others for the same entity).

 

 

addressElement

Preliminary Experimental

 

The elements of the address that form the recursive scope narrowing.

 

 

 

 

3.1.3.2    AddressElement

Qualified Name: CoreModel::CoreFoundationModel::SuperClassesAndCommonPackages::TypeDefinitions::AddressElement

One element of a hierarchy of elements.
Note that the element must have one and only one value chosen from a list of potential value types.

 

Table 10 : Attributes for AddressElement

Attribute Name

Lifecycle Stereotype (empty = Mature)

Description

addressElementName

 

The name of the address element (e.g. "shelf" as an element of a shelf/slot/port addressing scheme).
The remainder of the structure has the reference for the shelf.
 

 

 

localId

 

If the element is a localId (where the element above in the hierarchy must be the context in which the specific localId is relevant).

 

 

uuid

 

If the element is a uuid (where this element could be the top of a hierarchy but may also be at some level in the hierarchy where address navigation is considered necessary to assist in location of the UUID).

 

 

name

 

If the element is a name.

 

 

_address

 

See referenced class

 

arbitraryElement

 

Where the element is from some external model that is not formally represented in this model.

 

 

 

 

3.1.3.3    LocalIdAndClass

Qualified Name: CoreModel::CoreFoundationModel::SuperClassesAndCommonPackages::TypeDefinitions::LocalIdAndClass

The localId and the class of entity that it identifies.

 

Table 11 : Attributes for LocalIdAndClass

Attribute Name

Lifecycle Stereotype (empty = Mature)

Description

classOfInstance

Preliminary Experimental

 

The class to which the name refers.

 

 

localId

Preliminary   Experimental

 

The localId of the entity.

 

 

 

 

3.1.3.4    NameAndClass

Qualified Name: CoreModel::CoreFoundationModel::SuperClassesAndCommonPackages::TypeDefinitions::NameAndClass

The name and the class of entity that it names.

 

Table 12 : Attributes for NameAndClass

Attribute Name

Lifecycle Stereotype (empty = Mature)

Description

classOfInstance

Preliminary   Experim ental

 

The class to which the name refers.

 

 

name

Preliminary   Experimental

 

If the element is a name.

 

 

 

 

3.1.3.5    NameAndValue

Qualified Name: CoreModel::CoreFoundationModel::SuperClassesAndCommonPackages::TypeDefinitions::NameAndValue

A scoped name-value pair.

 

Table 13 : Attributes for NameAndValue

Attribute Name

Lifecycle Stereotype (empty = Mature)

Description

valueName

 

The name of the value. The value need not have a name.

 

 

value

 

The value.

 

 

_nameAndValueAuthority

 

The authority that defines the named value.

 

 

_globalClass

 

The scope of the name uniqueness.

 

 

_localClass

 

The scope of the name uniqueness.

 

 

 

 

3.1.3.6    UniversalId

Qualified Name: CoreModel::CoreFoundationModel::SuperClassesAndCommonPackages::TypeDefinitions::UniversalId

The universal ID value where the mechanism for generation is defined by some authority not directly referenced in the structure.
An example structure is [IETF RFC4122].

 

Table 14 : Attributes for UniversalId

Attribute Name

Lifecycle Stereotype (empty = Mature)

Description

value

 

The specific value of the universal id.

 

 

 

 

3.1.4      Use of names, identifiers and addresses

The following figure provides various examples of naming and identifier. The figure is currently under development. The figure includes diagram element from TR-512.5 and TR-512.6 .

Figure 3 - 2 Sketch of names, identifiers and addresses for various entities

3.2      States

The Core Foundation Model also defines a State_Pac artifact, which provides state attributes. The work on states is preliminary at this stage (it is derived from [ITU-T X.731]). The State_Pac is inherited by GlobalClass and LocalClass object classes. The use of these states provides a consistent way represent the overall operability, usability and current usage of the resource.

It should be noted that the states are « Mature » / «Preliminary» / « Experimental » .

 

[MB4]

CoreModel diagram: State-FullModel

Figure 3 - 3 States for all Objects

The states described above ap ply to individual abstractions , it is also important to understand how the states of an abstraction are related to the states of the supporting abstraction s . The relationship between abstractions is illustrated in Figure 3-3a below and in fur ther described in section 3.2.5.

  Figure 3 - 3 a Relationship between abstractions

 

3.2.1      Classes and attributes

3.2.1.1    AdministrativeState

Qualified Name: CoreModel::CoreFoundationModel::StateModel::StateMachines::AdministrativeState::AdministrativeState

This class is Experimental Mature .

 

3.2.1.2    LifecycleState

Qualified Name: CoreModel::CoreFoundationModel::StateModel::StateMachines::LifecycleState::LifecycleState

This class is Experimental.

 

3.2.1.3    OperationalState

Qualified Name: CoreModel::CoreFoundationModel::StateModel::StateMachines::OperationalState::OperationalState

This class is Experimental Mature .

 

3.2.1.4    LifecycleState

Qualified Name: CoreModel::CoreFoundationModel::StateModel::StateMachines::LifecycleState::LifecycleState

This class is Experimental Pre liminary .

 

3.2.1.5    State_Pac

Qualified Name: CoreModel::CoreFoundationModel::StateModel::ObjectClasses::State_Pac

Provides general state attributes.

This class is abstract.

This class is Preliminary Mature .

Table 15 : Attributes for State_Pac

Attribute Name

Lifecycle Stereotype (empty = Mature)

Description

operationalState

  Preliminary Mature

 

The operational state is used to indicate whether or not the resource is installed and working.

 

 

administrativeControl

  Experimental

 

The administrativeControl state provides control of the availability of specific resources without modification to the provisioning of those resources.
The value is the current control target. The actual administrativeState may or may not be at target.

[MB5]

 

administrativeState

  Preliminary Mature

 

Shows whether or not the client has permission to use or has a prohibition against using the resource.
The administrative state expresses usage permissions for specific resources without modification to the provisioning of those resources.

 

 

lifecycleState

  Preliminary

 

Used to track the planned deployment, allocation to clients and withdrawal of resources.

 

 

 

 

3.2.2      Enumerations

3.2.2.1    AdministrativeControl

Qualified Name: CoreModel::CoreFoundationModel::StateModel::TypeDefinitions::AdministrativeControl

Reflects the current control action when the entity is not in the desired state.

 

Applied stereotypes:

  • Experimental

 

Contains Enumeration Literals:

  • UNLOCK:
    • The intention is for the entity to become unlocked.
      The entity may already be UNLOCKED.
    • Applied stereotypes:
      • Experimental
  • LOCK_PASSIVE:
    • The intention is for the entity to become locked but no effort is expected to move to the Locked state (the state will be achieved once all users stop using the resource).
      The entity may be LOCKED.
    • Applied stereotypes:
      • Experimental
  • LOCK_ACTIVE:
    • The intention is for the entity to become locked and it is expected that effort will be made to move to the Locked state (users will be actively removed).
      The entity may already be LOCKED.
    • Applied stereotypes:
      • Experimental
  • LOCK_IMMEDIATE:
    • The intention is for the entity to become locked and it is expected to move to the Locked state immediately (users will be force removed).
      The entity may already be LOCKED.
    • Applied stereotypes:
      • Experimental
  • QUIESCENT:
    • The administrative state is at a stable value (LOCKED/UNLOCKED) and no action is being taken.
    • Applied stereotypes:
      • Experimental

 

3.2.2.2    AdministrativeState

Qualified Name: CoreModel::CoreFoundationModel::StateModel::TypeDefinitions::AdministrativeState

The administrative state is used to show whether use of a resource is allowed or prohibited.
The administrative state can be observed and directly controlled by a certain operational roles.
Typically, only a user (in the provider context) with administrative privileges is allowed to write the administrative state, any other users are restricted to read only.

 

Applied stereotypes:

  • Preliminary Mature

 

Contains Enumeration Literals:

  • LOCKED:
    • Users are administratively prohibited from making use of the resource.
    • Applied stereotypes:
      • Preliminary Mature
  • UNLOCKED:
    • Users are allowed to use the resource.
    • Applied stereotypes:
      • Preliminary Mature
  • SHUTTING_DOWN:
    • Indicates that T t he suppo rting entity will to transition to LOCKED and requests the dependent entity to stop using the resource is administratively restricted to existing instances of use only. There may be specific actions to remove existing uses. No new instances of use can be enabled .
      The resource automatically transitions to "locked" when the last user quits.
      The administrative state is not visible in the client context.
      The lifecycle state "pending removal" should be used to indicate to the client that the provider intends to permanent ly remove the resource.
    • Applied stereotypes:

 

3.2.2.3    LifecycleState

Qualified Name: CoreModel::CoreFoundationModel::StateModel::TypeDefinitions::LifecycleState

This state is used to track the planned deployment, allocation to clients and withdrawal of resources.

 

Applied stereotypes:

  • Experimental

 

Contains Enumeration Literals:

  • PLANNED:
    • The resource is planned but is not present in the network.
      Should include a "time" when the resources are expected to be installed.
    • Applied stereotypes:
      • Experimental
  • POTENTIAL_AVAILABLE:
    • The supporting resources are present in the network but are shared with other clients; or require further configuration before they can be used; or both.
      (1) When a potential resource is configured and allocated to a client it is moved to the INSTALLED state for that client.
      (2) If the potential resource has been consumed (e.g. allocated to another client) it is moved to the POTENTIAL BUSY state for all other clients.
    • Applied stereotypes:
      • Experimental
  • POTENTIAL_BUSY:
    • The supporting resources are present in the network but have been allocated to other clients.
    • Applied stereotypes:
      • Experimental
  • INSTALLED:
    • The resource is present in the network and is capable of providing the service.
    • Applied stereotypes:
      • Experimental
  • PENDING_REMOVAL:
    • The resource has been marked for removal.  Should include a "time" when the resources are expected to be removed.
    • Applied stereotypes:
      • Experimental

 

3.2.2.4    OperationalState

Qualified Name: CoreModel::CoreFoundationModel::StateModel::TypeDefinitions::OperationalState

The operational state is used to indicate whether or not the resource is installed and working.

 

Applied stereotypes:

  • Preliminary Mature

 

Contains Enumeration Literals:

  • DISABLED:
    • The resource is unable to meet the SLA of the user of the resource.
      If no (explicit) SLA is defined the resource is disabled if it is totally inoperable and unable to provide service to the user.
    • Applied stereotypes:
      • Mature Preliminary
  • ENABLED:
    • The resource is partially or fully operable and available for use.
    • Applied stereotypes:
      • Mature Preliminary

3.2.2.5    [MB9]   LifecycleState

Qualified Name: CoreModel::CoreFoundationModel::StateModel::TypeDefinitions::LifecycleState

This state is used to track the planned deployment, allocation to clients and withdrawal of resources.

 

Applied stereotypes:

  • Experimental Preliminary

 

Contains Enumeration Literals:

  • PLANNED:
    • The resource is planned but is not present in the network.
      Should include a "time" when the resources are expected to be installed.
    • Applied stereotypes:
      • Experimental Preliminary
  • POTENTIAL_AVAILABLE:
    • The supporting resources are present in the network but are shared with other clients; or require further configuration before they can be used; or both.
      (1) When a potential resource is configured and allocated to a client it is moved to the INSTALLED state for that client.
      (2) If the potential resource has been consumed (e.g. allocated to another client) it is moved to the POTENTIAL BUSY state for all other clients.
    • Applied stereotypes:
      • Experimental Preliminary
  • POTENTIAL_BUSY:
    • The supporting resources are present in the network but have been allocated to other clients.
    • Applied stereotypes:
      • Experimental Preliminary
  • POTENTIAL_ NOT_INSTALLED :
    • The supporting resources are present in the network but have not been fully configured .
    • Applied stereotypes:
  • INSTALLED:
    • The resource is present in the network and is capable of providing the service.
    • Applied stereotypes:
      • Experimental Prelimiary
  • PENDING_REMOVAL:
    • Only used in a supporting entity
    • The resource has been marked for removal   in the supporting entity .  Should include a "time" when the resources are expected to be removed.
    • Applied stereotypes:
      • Experimental Preliminary
  • PENDING_REMOVAL _INUSE :
    • Only used in a dependent entity
    • The resource has been marked for removal   by the supporting   entity , but the dependent entity has not yet released the resource.
    • Applied stereotypes:
      • Preliminary
  • PENDING_REMOVAL_F REE :
    • Only used in a dependent entity
    • The resource , in a dependent entity   is not c urrently in use and no future use is planned. The resource may be withdrawn by the supporting entity .
    • Applied stereotypes:

 

3.2.3      Relationship between states in Provider the same context

If the lifecycleState is PLANNED or POTENTIAL_NOT_INSTALLED   then the operationalState must be DISABLED [MB12] and the administrativeState should be LOCKED.

If the lifecycle State is POTENTIAL_BUSY or POTENTIAL_AVAILBALE the administrativeState should be LOCKED. [MB13]

In all other circumstances the states are independent.

3.2.4      Relationship between states in the client and provider context

The table below lists the states in the provider context that influence the states in the client context. The client does not have direct visibility of the provider states but does perceive effect through the operationalState.

Table 16 : Influence of Provider state on Client state

Provider State

Value

Client State

Value

operationalState

DISABLED

operationalState

DISABLED

administrativeState

SHUTTING_DOWN

operationalState

DISABLED

administrativeState

LOCKED

operationalState

DISABLED

lifecycleState

PLANNED

operationalState

DISABLED

lifecycleState

POTENTIAL_BUSY

operationalState

DISABLED

 

No other states in the client context have a dependency on the state in the provider context.

None of the states in the client context   influence the states in the provider context.

The administrativeState in the provider context is not visible in the client context. The client context may maintain an independent administrativeState.

The provider controls the lifecycleState that is visible to the client context.

3.2.5      State transition diagrams

These state transition diagrams are experimental preliminary [MB14] [MB15]   sketches [MB16] that will may be refined in following releases.

3.2.5.1    Administrative State

[MB17] [MB18]

Figure 3 - 4 Administrative State

The shutting down state is used in a supporting entity when a dependent entity is in the Life Cycle state of installed (i.e. a client may be using the resource) . I n this case , to avoid a service disruption, the client of the supported entity should stop using the resource and then transition to locked. After the supported entity has tr ansitioned to locked the supporting entity can transition to locked and should change the lifecycle state to Potenti al Busy .

3.2.5.2    Operational State

Figure 3 - 5 Operational State

The operat ional state is controlled by the supporting hardware or software and is read only. The operational state of a dependent instance or a client instance must match the operational state of the supporting entity.

3.2.5.3    Lifecycle State

Figure 3 - 6 Lifecycle State

If a resource is shared by two or more dependent entities when the supporting entity moves to Installed the dependent entities   transitions from Planned to PotentialAvailbable or Potential Busy. A resource may be PotentialAvailable in all of the dependent entities or Installed in one dependent entity   and PotentialBusy in all other dependent entities.

A resource in a supporting entity is moved to PendingRemoval when the manager of the entity intends to withdraw the resource from the dependent entit ies .

A resource in a dependent entity is moved to PendingRemoval Inuse when the supporting entity is moved to PendingRemoval and the re source is in the dependent entity is in use (i.e. was Installed) .

A resource in a dependent entity   is moved to PendingRe moval Free   when the manager of that resource is not currently using the resource and has no intention of using that resource in the future.

3.2.6      Use of states

Notes:

  • Imported from TR-512.3_MB_states_updates_v1.4.0.d01.docx with some rearrangement and minor edits to fit in this document.
  • Change bars have were   not been used in the initial version of section 3.2.5.

3.2.6.1    Model context

Figure 3-7 below is a sketch of the relationship between the “platform,” that supports the functions, the logical resource model, that provides a view of the logical resources and the equipment and software models, that provide a view of the implementation platform. Note that this figure shows a highly simplified view of the equipment model and software model, only the major relationships of interest are shown. The equipment model is in TR-512. 6   t he software model is in TR-512. 12 .

 

Figure 3-7 Relationship between entities and abstractions

Figure 3-7 illustrates the relationship between the logical resource model and the supporting hardware or software platform, it does not show the full hardware or software model, The [MB19] [MB20] object instances shown in In the equipment model and software model represent either a field replaceable unit (FRU) or a running software module is represented by an object instance . These object instances support one of more of the artefacts in the logical resource model. In the logical resource model, the lowest level object instances are the aggregation of one or more of the artefacts. T he object instances in a server context are referred to as the “supporting abstraction and the object instances in the client context are referred to as the dependent abstraction . The states of an object instance in a server context (the dependent abstraction) must be consistent with both state of the supporting object instance(s) and the state of the object instance in the corresponding client context (client abstraction) .

Example:

  • An interface card on an Ethernet switch (a single FRU) may support 10 * 1GE interfaces and thus 10 “Ethernet” LTPs.
  • The PHY of each of the Ethernet interfaces may be on a separate pluggable module (FRU) so each Ethernet LTP is supported by both the interface card (FRU) and the pluggable module (FRU).

Within a controller, the object instances “directly” representing the implementation or those in a server context (e.g. Controller n+1 in the figure above) may be aggregated into a single object instance in a client context that is “mirrored” in the server context of the client controller.

3.2.6.1.1              Alarms, fault isolation and control

The “lowest level” object instances in the resource model are “directly connected” to the implementation and have access to the forwarding namespace. They can configure the resources that implement the logical functions and receive alarm/status information directly from the implementation. Fault location, to the level required for FRU replacement, can only be performed with information from this lowest level which provides access to the resource and physical name spaces.

When an object instance is presented in a client context, the alarm/status information is abstracted and aggregated, the relationship to the implementation is not visible from the client context.

3.2.6.2    Instance relationships

As described above, the supporting entity may be a “platform” or a managed object instance. The dependent entity is always a managed object instance. The relationships between the supporting and dependent entities may be:

Number of
supporting entities

Number of
dependent abstractions

1

1

1

n

m

1

m

n

The state of a dependent abstraction must be consistent with the state of the supporting entities. For the m:1 and m:n cases the states are considered in the order of the precedence described below in section 3.2.5.2.

3.2.6.2.1              Supporting:Dependent 1:1 Case and 1:n Case

The state of the dependent instances is set based on the state of the supporting entity and in some cases may be modified by the local controller as described below. For the 1:n case local modifications are made independently on each of the dependent entities.

Administrative state

Supporting entity
administrative state

Dependent entity
administrative state

Notes

Locked

Locked [MB21] [MB22] [MB23]

Traffic is blocked in the supporting entity

Unl o cked

Local modification :
Traffic is blocked in the supporting entity

Unlocked

Unlocked

 

Locked

Local modification :
Traffic is not blocked in the supporting entity

ShuttingDown

ShuttingDown

This state should not be used if the lifecycle states are supported

Locked

Local modification :
Indicates that the supporting entity can move to
Locked without disruption

 

Operational state

Supporting entity
operational state

Dependent entity
operational state

Enabled

Enabled

Disabled

Disabled

 


Lifecycle state

Supporting entity lifecycle state

Permitted dependent entity lifecycle states

Notes

Planned

Planned

 

PotentialNotInstalled

PotentialNotInstalled

A request to configure an abstraction has not been completed

Planned

Local modification

Installed

Planned

Local modification

Installed

 

PotentialAvailable;

Controlled by the entity managing the supporting entity :
Only used if more than one client has a view of the same resource
Local modification
The client may
move from Installed to PotentialAvailable to indicate that it is no longer using the resource

PotentialBusy

Controlled by the entity managing the supporting entity :
Only used if more than one client has a view of the same resource

PendingRemoval Free

Local modification :
Resource being removed from this client. No impact on the supporting entity

PotentialAvailable

PotentialAvailable

 

PendingRemoval Free

Local modification :
Resource being removed from this client. No impact on the supporting entity

PotentialBusy

PotentialBusy;

 

PendingRemoval Free

Local modification :
Resource being removed from this client. No impact on the supporting entity

PendingRemoval

PendingRemoval Busy

D ependent resource was “Installed”

PendingRemoval Free

D ependent resource “Potenti alAvailable”, “PotentialBusy” or the client is no longer using the resource

 

3.2.6.2.2              Supporting:Dependent m:1 Case

The state of the dependent instance is set based on the state of the composite supporting instance as described below. The precedence of the states in the tables below are used to determine the state of the composite supporting entity.

Administrative state

Administrative state

Precedence

Locked

Highest

ShuttingDown

 

Unlocked

Lowest

 

Operational state

Operational state

Precedence

Disabled

Highest

Enabled

Lowest

 

Lifecycle state

Lifecycle state

Precedence

Planned

Highest

PotentialNotInstalled

 

PendingRemoval

 

PotentialBusy

 

PotentialAvailable

 

Installed

Lowest

 

The m:1 case has two sub-cases:

3.2.6.2.2.1      Simple

This arrangement of supporting entity and composite abstraction is illustrated in figure 3-8 below.

Figure 3-8 Component composite relationship

The state of the composite abstraction is determined by making a list of the states of the component supporting entities and arranging that list of states from the lowest to highest precedence. The resource policy defines the number of component supporting entities that must be in a given state (or in a lower precedence state) for the composite entity to be in that state.

3.2.6.2.2.1.1                       Example of the application of resource policy

Using the lifecycle states as an example, then in the case of six component supporting entities with the following states:

Entity

A

B

C

D

E

F

State

Planned

Installed

PotentialAvailable

Installed

PotentialBusy

PotentialAvailable

 

Rearranging into an ordered list:

 

Entity

State

1

B

Installed

2

D

Installed

3

C

PotentialAvailable

4

F

PotentialAvailable

5

E

PotentialBusy

6

A

Planned

The state of the composite abstraction is determined by applying the resource policy for the number of component supporting entities that must be in a given state (or in a lower precedence state) for the composite entity to be in that state. If the policy only requires 1 the composite state will be Installed: If the policy requires 3 the composite state will be PotentialAvailable; If the policy requires 6 the composite state will be Planned.

3.2.6.2.2.2      Compound

This may be modelled by concatenating the appropriate set of simple cases described above. The state of the intermediate composite is evaluated for each (simple) group and is used to define the state of the intermediate component for the next stage of evaluation. That is, each of sets of “lower” components are evaluated, using the rules described above, to determine the intermediate composite states. These intermediate composite states are then used as the intermediate component state when evaluating the state of the next level of composite entities. Figure 3-9 below shows an example where three levels of evaluation used to map from the component states into the composite state. The sets of component entities that are grouped to form an intermediate composite abstraction is determined by the topological relationship between those entities. The compound case could, for example, be used to derive the state of a forwarding domain that is supported by a set of forwarding domains and links (each with its own intermediate composite state).

Figure 3-9 Compound component composite relationships

3.2.6.2.3              Supporting:Dependent m:n case

Note: This does not represent a m:n protection scheme.

The state of the m component entities are mapped into a single composite state as described above in 3.3. Thus the m:n case can be treated in the same way as the 1:n case described above in 3.2. This would be used for example when a forwarding domain that is supported by forwarding domains and links is shared between n clients.

3.2.6.3    Protected entities

The state of an abstraction that is representing a protected resource is determined by the C&SC that is managing/representing the protection scheme. Note that a client (controller) may have a view of both the protected resource and the (unprotected) resources that support it.

3.2.6.4    Split entities

The view (abstractions) presented to a client controller cannot provide a more detailed view than that offered by the lowest level instances that have been created. When a client (controller) view of an entity is “split” as shown in the example in figure 3-10 below where the original client FD is split into two FDs (X and Y).

Figure 3-10 Split entity example

The links 2, 3 and LTPs 4, 5, 6, 7 are now exposed to the client. The client must retain the context of the parent FD to understand the link between Client FD X and Client FD Y.

The states of the dependent resources provided by the server (controller) must reflect the states of the supporting resources as described above.

The new client FDs should be provided with new identifiers so that the identifier for the parent FD can be retained.

3.2.6.5    Merged entities

The state of the merged entity must be consistent with the state of the supporting resources as described above.

Considering the example above where the server controller is required to “merge” client FD X and client FD Y into a single FD. We have two cases:

  • The parent FD is already visible (with an identifier) in the client context, in this case no further action is required.
  • The parent FD is not visible in the client context. In this case a new ID for the parent FD should be created. This option must be used if the client has the option of viewing either level of abstraction (i.e. FD X, Y and Parent FD). The ID of either FD X or FD Y could be used for the parent FD. However, this is not recommended since it precludes the possibility of leaving FD X and FD Y visible to the client.

 

End of document


[1] An Entity is represented using a UML class

[2] A Feature of an Entity is represented using a UML class

[3] The term GUID was used in the previous version of the model. The change is in recognition of the more generally applicability of UUID

[4] A named value is simply a tuple with two terms, one being a value and the other being the name of that value. For example in a street address a value may be “London” and the name of that value would be “City”.

[5] The model also provides ConditionalPackage to supply names and identifiers to _Pac classes but this is currently experimental.

[6] The intention is that only classes from the Core Model are shown in the figure. The classes shown are essentially illustrative. There is another figure in the model that captures Core Model inheritance in detail. All classes from all fragments should inherit from GlobalClass, LocalClass or ConditionalPackage. There is no issue with model dependency as the inheritance association is maintained with the class that is inheriting properties. Although not mandatory, it would seem advisable to maintain a figure per fragment that shows all classes from that fragment and their inheritance.


[MB1] Updated in d02

[MB2] Upgrade from experimental to preliminary?

[MB3] Agreed in London, changed in d002

[MB4] Update figure to align with stereotypes with text:
Remove admin control:

[MB5] Replaced by lifecycleState

[MB6] Used by the supporting entity to indicate the intention to transition to locked.

[MB7] Replaced by LifecycleState

[MB8] Need to use this state to allow a non-disruptive move to locked.

[MB9] Moved to keep the order consistent

[MB10] Added in d01

[MB11] Added in d02 to indicate if the supporting entity can withdraw the resource without disruption.

[MB12] Issue: If the supporting entity is installed but the dependent entity is locally set to planned the operation state of the dependent entity should reflect the state of the supporting entity i.e. it may be enabled.

[MB13] Added in d02

[MB14] Mature?

[MB15] Leave preliminary

[MB16] Need to provide description of the state transitions.

[MB17] Remove ShuttingDown

[MB18] Keep shutting down to allow a supporting entity to communicate with a dependent abstraction.

[MB19] Check alignment with software document…

[MB20] Added text in d02

[MB21] Should we allow unlocked / blocked

[MB22] Added to table in d02

[MB23] I do not support this addition