Child pages
  • Contributions

cid:image003.png@01D47AB3.2CCAF460

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

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 draft- 1.5 - d0 4 2 3 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
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 [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 LifecycleState

3.2.1.3 OperationalState

3.2.1.4 State_Pac

3.2.2 Enumerations

3.2.2.1 AdministrativeState

3.2.2.2 LifecycleState

3.2.2.3 OperationalState

3.2.3 Relationship between states in the same context

3.2.4 Relationship between states in the client context and server context

3.2.5 State transition diagrams

3.2.5.1 Administrative State

3.2.5.2 Operational State

3.2.5.3 Lifecycle State

3.2.6 Use of states

3.2.6.1 Model context

3.2.6.2 Instance relationships

3.2.6.3 Protected entities

3.2.6.4 Split entities

3.2.6.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 Relationship between abstractions

Figure 3-5 Administrative State

Figure 3-6 Operational State

Figure 3-7 Lifecycle State

Figure 3-8 Relationship between entities and abstractions

Figure 3-9 Component composite relationship

Figure 3-10 Compound component composite relationships

Figure 3-11 Alternate intermediate aggregates

Figure 3-12 Split entity example

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

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

Figure 3-3 States for all Objects ............................................................................................. 18

Figure 3-4 Administrative State ............................................................................................. 24

Figure 3-5 Operational State .................................................................................................. 24

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

November 2018

No changes.

1.5-d01

May 2019

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

Updated following review at the London interim meeting

  • Proposed updates to the LifecycleState Property for names and identifiers

Changed description of “ SHUTTING_DOWN ShuttingDown ” and added “ PENDING_REMOVAL_INUSE PendingRemovalInUse ” and “ PENDING_REMOVAL_FREE PendingRemovalFree ” to allow a server to indicate to a client that a resource will be withdrawn.

1.5-d02

August 2019

Updates to address comments made on the 2019/06/20 OIMT call:

Note this revision only provides additional material on “states”.

Changes to reflect agreements on inheritance and use of UUID in Local Class will be made in version 2.0.

1.5-d03

September 2019

Update to address comment on email from Chris Hartley sent 19 th August

Updated to use of UpperCamelCase for all artefacts

1.5-d04

December 2019

Upd at e following discussion at the San Jose face to face meeting

1.5-d04

March 2020

Update following discussion on OITM call 2020/03/05

 


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), [MB2] 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:

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) [MB4] that their instances can exist on their own right, e.g., LTP, FD, Link, FC, and ConstraintDomain 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] [MB5]

 

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 [MB6] properties from:

  • Extension
  • Label

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.

 

Inherit [MB7] s properties from:

  • Extension
  • State_Pac
  • Label
  • Address
  • Name

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.

 

Inherit [MB8] s properties from:

  • Extension
  • State_Pac
  • Label
  • Address
  • Name

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

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.

[MB9]

 

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   Experimental

 

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. [MB10] 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 ».

 

[MB11]

CoreModel diagram: State-FullModel

Figure 3 - 3 States for all Objects

The states described above apply 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 the states of the abstractions is illustrated in Figure 3- 4 below and in further described in section 3.2. 6 .

Figure 3 - 4 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 Preliminary .

 

3.2.1.3      OperationalState

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

This class is Experimental Mature .

 

3.2.1.4    State_Pac

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

Provides general state attributes.

This class is abstract.

This class is Mature Preliminary .

Table 15 : Attributes for State_Pac

Attribute Name

Lifecycle Stereotype (empty = Mature)

Description

operationalState

  Mature Preliminary

 

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

 

 

administrativeControl [MB12]

  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.

 

 

administrativeState

  Mature Preliminary

 

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

  • Mature Preliminary

 

Contains Enumeration Literals:

  • LOCKED:
    • Users are administratively prohibited from making use of the resource.
    • Applied stereotypes:
      • Mature Preliminary
  • UNLOCKED:
    • Users are allowed to use the resource.
    • Applied stereotypes:
      • Mature Preliminary
  • SHUTTING_DOWN:
    • The entity 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 permanently remove the resource.
    • Applied stereotypes:
      • Experimental Obsolete Preliminary

 

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 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:
      • Experimental
  • INSTALLED:
    • The resource is present in the network and is capable of providing the service.
    • Applied stereotypes:
      • Experimental Preliminary
  • PENDING_REMOVAL:
    • Only used in a supporting entity abstraction
    • The resource has been marked for removal .   in the supporting entity abstraction . 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 abstraction or a client abstraction
    • The resource has been marked for removal   by the as PendingRemoval PENDING_REMOVAL in t he supporting   entity abstraction , but the dependent entity client has not yet released the resource.
    • Applied stereotypes:
      • Preliminary
  • PENDING_REMOVAL_FREE:
    • Only used in a dependent abstraction or a client abstraction entity
    • The resource, in a dependent entity client abstraction is not currently in use and no future use is planned. The resource may be withdrawn by the supporting entity abstraction .
    • Applied stereotypes:
      • Preliminary

 

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.3      Relationship between states in Provider the same context

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

If the l ifecycleState is POTENTIAL_BUSY or POTENTIAL_AVAILBALE the administrativeState should be LOCKED.

If the admi nistrativeState is SHUTTING_DOWN the lifecycleState should be PENDING_REMOVAL.

In all other circumstances the states are independent.

3.2.4      Relationship between states in the client context and provider server   context

The table s below list s the states in the provider server context that influence the states in the client context in the same controller . The states in the server context of the n+1 controller should track the states in the corr esponding client context in n controller. 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

 

Note: Tables below moved from section 3.2.6.2.1

Administrative state

Supporting entity abstraction
a A dministrative s S tate

Dependent entity abstraction
a A dministrative s S tate

Notes

Locked

Locked

Traffic is blocked in by the supporting entity abstraction

Unlocked

Unlocked

 

Locked

Local modification :
Traffic is not blocked in the supporting entity abstraction

ShuttingDown

ShuttingDown

 

Locked

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

 

Operational state

Supporting entity abstraction
operational S s tate

Dependent entity abstractio n
operational S s tate

Enabled

Enabled

Disabled

Disabled

 

Lifecycle state

Supporting entity abstraction   l L ifecycle s S tate

Permitted dependent entity abstraction   l L ifecycle S s tate s

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 abstraction :
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 abstraction :
Only used if more than one client has a view of the same resource

PendingRemovalFree

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

PotentialAvailable

PotentialAvailable

 

PendingRemovalFree

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

PotentialBusy

PotentialBusy;

 

PendingRemovalFree

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

PendingRemoval

PendingRemovalBusy PendingRemoval InUse

Local modification :
Dependent resource was “Installed” and in use.

PendingRemovalFree

Local modification :
Dependent resource “PotentialAvailable”, “PotentialBusy” or t T he client is no longer using the resource

 

No other states in the dependent abstraction (in the client context ) have a dependency on the state of the supporting abstraction ( in the provider context ) .

The states in the client abstractio n None of the states ( in the client server context of the n+1 co ntroller     as shown in figure 3-4 ) should track the states of the dependent abstraction influence the states ( in the provider client context of the “n” controller – as shown in figure 3-4 ) except for the PendingRemovalFree state which is controlled by the client abstraction and tracked by the depen dent abstraction .

The a A dministrativeState in the provider context is not visible in the client context. The client context may maintain an independent a A dministrativeState.

The provider controls the l L ifecycleState that is visible to the client context as described in the table above .

3.2.5      State   transition diagrams [MB13]

These state transition diagrams are experimental preliminary sketches that will may be refined in following releases.

3.2.5.1    Administrative State

Figure 3 - 5 4 Administrative State

The shutting down state is used in a supporting     entity abstraction   when a dependent entity abstraction is in the Life   [MB14] [MB15] C c ycle state of i I nstalled (i.e. a client may be using the resource). The S hutting D own state is not visible in to the dependent entity abstraction . The supporting entity should change the Life C c ycle s S tate   of the supporting abstraction should be changed   to PENDING_REMOVAL PendingRemoval when the AdministrativeState transitions to ShuttingDown . After the Life C c ycle s S tate of the dependent entity abstraction has transitioned to PENDING_REMOVAL PendingRemoval Free _FREE the A dministrative S tate of the supporting entity abstraction can transition to LOCKED Locked and should change the l L ifecycle s S tate   of to the dependent abstraction   should be changed to POTENTIAL_BUSY PotentialBusy .

3.2.5.2    Operational State

Figure 3 - 6 5 Operational State

The o perational S tate is controlled by the supporting hardware or software and is read only. The o perational S tate of a dependent instance abstraction   in the INSTALLED state must match the operational S tate of the supporting entity abstraction .

3.2.5.3    Lifecycle State

Figure 3 - 7 6 Lifecycle State

If a resource is shared by two or more dependent abstractions entities when the supporting entity abstraction   moves changes to INSTALLED the dependent entities abstraction transitions from Planned to POTENTIAL_ AVAILABLE ,   or   POTENTIAL_BUSY or Installed INSTALLED . A resource may be POTENTIALLY_AVAILABLE in all of the dependent entities abstractions or INSTALLED in one dependent entity abstraction and POTENTIALLY_BUSY in all other dependent entities abstractions .

A resource in a supporting entity abstraction is moved to PENDING_REMOVAL when the manager of th e at   supporting entity abstraction   intends to withdraw the resource from the dependent entities abstractions .

A resource in a dependent entity abstraction   is moved changes to PENDING _REMOVAL_IN_USE when the supporting entity abstraction   is moved changes to PENDING_REMOVAL and the resource is in the dependent entity abstraction was I NSTALLED .

A resource in a dependent entity client   abstraction is moved to PENDING_REMOVAL_FREE   when the manager of that resource is not currently using the resource and has no intention of using that resource in the future. This causes the corresponding resource in the client context (the dep endent abstraction) to transition to PENDING_REMOVAL_FREE PendingRemovalFree .

When the resource in the dependent entity abstraction moves to PENDING_REMOVAL_FREE the a dministrativeState of the supporting entity abstraction   should transition may be changed to L OCKED .   The dependent abstraction should be changed to PotentialBusy POTENTIAL_BUSY or the abstraction may be deleted.

Note that an abstraction in a provider context my pla y the role on both the client abstraction (when viewed from the perspective of controller n in figure 3 - 4)   and the supporting abstraction (when vie wed from the perspective of controller n+1 in figure 3 - 4). In this case the PotentialAvailable POTNETIAL_AVAILABLE and PotentialBusy POTENTIAL_BUSY states are used in the supporting abstraction.

3.2.6      Use of states

Examples to be added.

Notes:

  • Since the text in section 3.2.6 is new change bars were not been used in the initial version of section 3.2.6.
  • Change bars in section 3.2.6 indicate changes from draft 1.5-01 and draft 1.5-02 .
  • Text imported from TR-512.3_MB_states_updates_v1.4.0.d01.docx with some rearrangement and minor edits to fit in this document.

3.2.6.1    Model context

Figure 3- 7   8 below is a n informal 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 client context and server context may be represented by constrain d omains. The equipment model is in TR-512.6 the software model is in TR-512.12.

 

Figure 3 - 8 Relationship between entities and abstractions

Figure 3- 7 8 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 . , In the equipment model and software model 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.

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

  The 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 client context (the dependent abstraction) must should be consistent with both the state of the corresponding supporting object instance(s) in the server context (in the same controller) . Also and the state of the object instance in the corresponding client server context in the n+1 controller (client abstraction)   should track the state of the object in the co rresponding client context (in the n controller) . Note that when the state of one or more of the supporting abstractions changes the state of the dependent abstraction and client abstract ion will not be consistent until that change has been processed .   In a recursive hierarchy, the client abstraction will play the role of supporting abstraction in the next level of the hierarchy.

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 (e.g. in the server context in Controller n in figure 3-8) should support the Administrative   State. When the administrative S s tate is set to locked LOCKED the implementation prevents the resource from being used. Abstraction in any other context (e.g. in the client context in controller n or server context in controller n+1) support of the administrative state is optional. Setting the administrative S s ta t e   to locked LOCKED does not have any influence on the resource and it will continue to function normally.

or those in The resources in a server context ( e.g. Controller n+1 in the figure 3-8 above i.e. the supporting abstractions ) may be aggregated into a single object instance in a client context that is “mirrored” in the server context of the client controller by the client abstraction .

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 abstractions may be:

Number of supporting entities abstractions/resources

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 abstraction (s) . For the m:1 and m:n cases the states are considered in the order of the precedence described below in section 3.2.6.2   below .

The state of the client abstraction (in the server context of controller n+1 ) should match the state of the dependent abs traction (in the client context of controller n).

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 abstraction and in some cases may be modified by the local controller as described below in 3.2.4 . For the 1:n case local modifications are made independently on each of the dependent entities abstractions .

Note: tables below moved to 3.2.4

Administrative state

Supporting entity
administrative state

Dependent entity
administrative state

Notes

Locked

Locked

Traffic is blocked in the supporting entity

Unlocked

Unlocked

 

Locked

Local modification :
Traffic is not blocked in the supporting entity

ShuttingDown

ShuttingDown

 

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

PendingRemovalBusy

D ependent resource was “Installed”

PendingRemovalFree

D ependent resource “PotentialAvailable”, “PotentialBusy” or t he 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 abstraction .

Administrative state

A a dministrative S s tate

Precedence

Locked LOCKED

Highest

ShuttingDown SHUTTING_DOWN

 

Unlocked UNLOCKED

Lowest

 

Operational state

Operational s S tate

Precedence

Disabled DISABLED

Highest

Enabled ENABLED

Lowest

 

Lifecycle state

L l ifecycle s S tate

Precedence

PLANNED

Highest

POTENTIAL _ NOT _ INSTALLED

 

PENDING _ REMOVAL _ FREE

 

PENDING _ REMOVAL

 

POTENTIAL _ BUSY

 

POTENTIAL _ AVAILABLE

 

PENDING _ REMOVAL _ IN _ USE

 

INSTALLED

Lowest

 

The m:1 case has two sub-cases:

3.2.6.2.2.1      Simple

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

Figure 3 - 9 Component composite relationship

The state of the composite abstraction is determined by making a list of the states of the component supporting entities abstractions   and arranging that list of states from the lowest to highest precedence. The resource policy defines the number of component supporting entities abstractions   that must be in a given state (or in a lower precedence state) for the composite entity abstraction   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 abstractions   with the following states:

Entity
Abstraction

A

B

C

D

E

F

State

PLANNED

INSTALLED

POTENTIAL _ AVAILABLE

INSTALLED

POTENTIAL _ BUSY

POTENTIAL _ AVAILABLE

 

Rearranging into an ordered list:

 

Entity Abstraction

State

1

B

INSTALLED

2

D

INSTALLED

3

C

POTENTIAL _ AVAILABLE

4

F

POTENTIAL _ AVAILABLE

5

E

POTENTIAL _ BUSY

6

A

PLANNED

The state of the composite abstraction is determined by applying the resource policy for the number of component supporting entities abstraction s   that must be in a given state (or in a lower precedence state) for the composite entity abstraction   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 POTENTIAL _ AVAILABLE; 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 abstractions . Figure 3- 9   10   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 abstractions   that are grouped to form an intermediate composite abstraction is determined by the topological relationship between those entities abstractions . 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 - 10 Compound component composite relationships

S ome ( or all) of the intermediate composite entities abstractions may be exposed to a client . Also ,   alternate intermediate aggregates of the same component resources may be exposed to a client as illustrated in figure 3-1 1 below.

 

Figure 3 - 11 Alternate intermediate aggregates

In this case it is important that the state of the composite derived via intermediate aggregation 1 is the same as the state derived via intermediate aggregation 2.

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 abstractions   are mapped into a single composite state as described above in 3.2.6.2.2. Thus the m:n case can be treated in the same way as the 1:n case described above in 3.2.6.2.1. 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   12   below where the original client FD is split into two FDs (X and Y).

Figure 3 - 12 11 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] Table of contents updated

[MB2] Inheritance removed - See task 41.

Update in v2.0

[MB3] Inheritance removed - See task 41

Update in v2.0

[MB4] Need to align with the recent agreements on local classes in the Sydney minutes 1.1

Update in v2.0

[MB5] Need to update footnote: Inheritance removed - See task 41

Update in v2.0

[MB6] Inheritance removed - See task 41

Update in v2.0

[MB7] Inheritance removed - See task 41

Update in v2.0

[MB8] Inheritance removed - See task 41

Update in v2.0

[MB9] See minutes of Sydney meeting – task 41

[MB10] Inheritance removed - See task 41

Update in v2.0

[MB11] Update figure to align stereotypes with text:
Update all Pacs and attributes to upper CamelCase
Remove admin control:

Add PendingRemovalInUse and
PendingRemovalFree
to the LifeCycleState

[MB12] Replaced by lifecycle state

[MB13] Update sterotype in figures to Preliminary.

[MB14] Check against text in DD

[MB15] The Data Dictionary states that the shutting down state is not visible to the dependent entity. The intention to withdraw a resource is shown using the lifecycle states.