Child pages
  • Contributions

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

 

 

 

 

 

 

 

 

 

Version

Date

Description of Change

00

2017-11-04

Initial draft for discussion at the 6-10 November OIMT face to face meeting

01

2017-12-15

Update based on discussion at face to face meeting:

  • Changed client/server to dependent/supporting:
  • Added description of serial, parallel and compound cases
  • Added condition priority tables
  • Added Operational and Administrative states

02

2018-01-10

Updated based on discussion on the OIMT calls 2017-12-21 and 2018-01-10

  • Describes relationship to TR-512.3_v1.3
  • Improved description of the m:1 and m:n cases

 

 

IPR Declaration

Is there any IPR and/or Patentable Interest Declaration associated with this contribution NO

NOTICE: This contribution has been prepared to assist the ONF. This document is offered to the ONF as a basis for discussion and is not a binding proposal on ZTE or any other company. The requirements are subject to change in form and numerical value after more study. ZTE specifically reserves the right to add to, amend, or withdraw statements contained herein.

THE INFORMATION HEREIN IS PROVIDED “AS IS,” WITHOUT ANY WARRANTIES OR REPRESENTATIONS, EXPRESS, IMPLIED OR STATUTORY, INCLUDING WITHOUT LIMITATION, WARRANTIES OF NONINFRINGEMENT, MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

 


1        Work item description – Entity Lifecycle

       Purpose – Extend current model to include split/merge

       Specifically – Consider the merge and split of entities: Add further description on the use of the Entity lifecycle states as requested by TAPI

       Includes – Extensions to the lifecycle model

       Excludes – Consideration of the temporal model

       External Dependencies - None

       Assumptions - None

       Risks – Potential complexity of some merge cases (where the entities to be merged are in different lifecycle states)

1.1      Possible extensions/impacts of the work item

The relationship between the “lowest level” resource abstraction and the implementation (in hardware or software) that supports the resource needs to be examined.

This work also appears to be directly applicable to the operational state and the administrative state. It may also be relevant to the alarm/notifications from objects representing aggregated resources and to the definition of “port”.

1.2      Relationship to TR-512.3_v1.3

Section 3.2 of TR-512.3 describes the states and the relationship between states. The information in this document provides candidate material to be added to TR-512.3 in v1.4. primarily in section 3.2.6.

2        Model context

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

Figure 1

The object instances shown in the equipment model and software model represent either a field replaceable unit (FRU) or a running software module. 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).

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.

2.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 from the implementation (via the equipment/software objects?). 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 and the relationship to the implementation is not supported.

3        Instance relationships

Note: When integrated into TR-512.3 the precedence tables in section 4, 5 and 6 should be inserted before the text in section 3 .

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. The states are considered in the order of the precedence described below in section 4, 5 and 6.

3.1      Supporting:Dependent 1:1 Case

The state of the dependent instance is set based on the state of the supporting entity as described below.

3.2      Supporting:Dependent 1:n Case

The state of each of the dependent instances are set based on the state of the supporting entity as described below.

3.3      Supporting:Dependent m:1 Case

The state of the dependent instance is set to the state of the composite supporting entity as described below.

The m:1 case has two sub-cases:

3.3.1        Simple

The state of the composite supporting entity is based on the state of the supporting entities. The state 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.

This arrangement of supporting and composite entities is illustrated in figure 2 below.

Figure 2

3.3.1.1    Example of the application of resource policy

Using the lifecycle states in section 4.2, 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 composite state 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.3.2        Compound

This may be modelled by concatenating the appropriate set of simple cases described above. The composite state of each group is evaluated and then used as the input 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 component state when evaluating the state of the next level of composite entities. Figure 3 below shows an example where three levels of evaluation are used to map from the component states into the composite state. The sets of (intermediate) component entities that are grouped to form an intermediate composite entity is determined by the topological relationship between those entities. This 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.

 

Figure 3

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

4        TR512.3 Lifecycle states

In the logical resource model, the “entity” is an abstraction that represents an underlying resource. The most common abstractions that we encounter are LTPs, FDs and FCs.

The lifecycle state of an entity must be consistent with the composite lifecycle state of the underlying resource(s) that support that entity. In the (normal) case where we have recursive abstractions the lifecycle state must be consistent with the composite lifecycle state of the abstract entities that represent the resource.

4.1      Relationship between supporting and dependent abstractions

The server (controller) may provide more than one client (controller) with a view of a resource, in this case the PotentialAvailable and PotentialBusy states are provided to each client and are managed by the server (controller).

Supporting entity lifecycle state

Permitted dependent entity lifecycle states

Notes

Planned

Planned

 

Installed

Planned

 

Installed

 

PotentialAvailable; PotentialBusy

Only used if more than one client has a view of the same resource

PendingRemoval

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

PotentialAvailable

PotentialAvailable

 

PendingRemoval

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

PotentialBusy

PotentialBusy;

 

PendingRemoval

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

PendingRemoval

PendingRemoval

 

 

Table 1 – Server to client lifecycle state relationship

4.2      Lifecycle state priorities

The table below is used to determine the composite state of the supporting entity in the m:1 or m:n case as described in sections 3.3 and 3.4.

Lifecycle state

Precedence

Planned

Highest

PendingRemoval

 

PotentialBusy

 

PotentialAvailable

 

Installed

Lowest

 

5        Operational state

5.1      Relationship between supporting and dependent abstractions

Supporting entity
operational state

Dependent entity
operational state

Enabled

Enabled

Disabled

Disabled

5.2      Operational state priorities

Operational state

Precedence

Disabled

Highest

Enabled

Lowest

6        Administrative state

Note that the administrative state “shutting down” should not be used if the lifecycle states are supported.

6.1      Relationship between supporting and dependent abstractions

Supporting entity
administrative state

Dependent entity
administrative state

Notes

Locked

Locked

Traffic is blocked

Unlocked

Unlocked

 

Locked

Traffic is not blocked in the supporting entity

ShuttingDown

ShuttingDown

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

 

6.2      Administrative state priorities

Administrative state

Precedence

Locked

Highest

ShuttingDown

 

Unlocked

Lowest

 

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

 

8        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 below where the original client FD is split into two FDs (X and Y).

Figure 3

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.

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