TR255 Resource Function Activation and Configuration R17.5.1 PDF

TM Forum Technical Report
Resource Function -
Activation and Configuration
TR255
Release 17.5.1
April 2018
Latest Update: TM Forum Release 17.5.1 TM Forum Approved

Version 0.7.5 IPR Mode: RAND
TM Forum 2018. All Rights Reserved.

Resource Function - Activation and Configuration
Notice
Copyright © TM Forum 2018. All Rights Reserved.
This document and translations of it may be copied and furnished to others, and
derivative works that comment on or otherwise explain it or assist in its implementation
may be prepared, copied, published, and distributed, in whole or in part, without
restriction of any kind, provided that the above copyright notice and this section are
included on all such copies and derivative works. However, this document itself may
not be modified in any way, including by removing the copyright notice or references to
TM FORUM, except as needed for the purpose of developing any document or
deliverable produced by a TM FORUM Collaboration Project Team (in which case the
rules applicable to copyrights, as set forth in the TM FORUM IPR Policy, must be
followed) or as required to translate it into languages other than English.
The limited permissions granted above are perpetual and will not be revoked by TM
FORUM or its successors or assigns.
This document and the information contained herein is provided on an “AS IS” basis
and TM FORUM DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY OWNERSHIP RIGHTS OR ANY
IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR
PURPOSE.
TM FORUM invites any TM FORUM Member or any other party that believes it has
patent claims that would necessarily be infringed by implementations of this TM Forum
Standards Final Deliverable, to notify the TM FORUM Team Administrator and provide
an indication of its willingness to grant patent licenses to such patent claims in a
manner consistent with the IPR Mode of the TM FORUM Collaboration Project Team
that produced this deliverable.
The TM FORUM invites any party to contact the TM FORUM Team Administrator if it is
aware of a claim of ownership of any patent claims that would necessarily be infringed
by implementations of this TM FORUM Standards Final Deliverable by a patent holder
that is not willing to provide a license to such patent claims in a manner consistent with
the IPR Mode of the TM FORUM Collaboration Project Team that produced this TM
FORUM Standards Final Deliverable. TM FORUM may include such claims on its
website but disclaims any obligation to do so.
TM FORUM takes no position regarding the validity or scope of any intellectual

property or other rights that might be claimed to pertain to the implementation or use of
the technology described in this TM FORUM Standards Final Deliverable or the extent
to which any license under such rights might or might not be available; neither does it
represent that it has made any effort to identify any such rights. Information on TM
FORUM's procedures with respect to rights in any document or deliverable produced
by a TM FORUM Collaboration Project Team can be found on the TM FORUM
website. Copies of claims of rights made available for publication and any assurances
of licenses to be made available, or the result of an attempt made to obtain a general
license or permission for the use of such proprietary rights by implementers or users of
this TM FORUM Standards Final Deliverable, can be obtained from the TM FORUM
Team Administrator. TM FORUM makes no representation that any information or list
© TM Forum 2018. All Rights Reserved. Page 2 of 85

of intellectual property rights will at any time be complete, or that any claims in such list
are, in fact, Essential Claims.
Direct inquiries to the TM Forum office:
4 Century Drive, Suite 100

Parsippany, NJ 07054 USA
Tel No. +1 973 944 5100
Fax No. +1 973 944 5110
TM Forum Web Page: www.TM Forum.org

Table of Contents
Notice.................................................................................................................................... 2
Table of Contents ................................................................................................................ 4
Executive Summary ............................................................................................................ 6
1. Introduction ...................................................................................................................... 7
2. Conventions and Terminology R17.5.0 ......................................................................... 8
3. General Concepts and Use Cases R17.5 ....................................................................... 9
3.1. Use Case Template ........................................................................................ 9
3.2. General Concepts ......................................................................................... 10
3.2.1. Instantiation Approaches for Resource Functions .................................... 10
3.2.2. Dynamic APIs ........................................................................................... 16
3.2.3. Relationship to Orders .............................................................................. 16
3.2.4. Scaling and Modification ........................................................................... 17
3.2.5. Completion Mode...................................................................................... 17
3.2.6. Infrastructure Connectivity ........................................................................ 18
3.2.7. State Model............................................................................................... 20
3.2.8. Scheduling ................................................................................................ 22
3.2.9. Context or Role for Components in a Composite RF ............................... 22
3.2.10. Status of Tasks ........................................................................................ 22
3.3. Create Resource Function: intent-based ...................................................... 23
3.4. Create Resource Function: detailed-based .................................................. 25
3.5. Modify Resource Function: intent-based ...................................................... 27
3.6. Modify resource function: detailed-based ..................................................... 29
3.7. Terminate resource function: intent-based ................................................... 31
3.8. Terminate resource function: detailed-based ............................................... 32
3.9. Resource Function Healing........................................................................... 33
3.10. Resource Function Notifications ................................................................... 36
3.10.1. RF Creation Notification .......................................................................... 36
3.10.2. RF Modification Notification ..................................................................... 37
3.10.3. RF Termination Notification ..................................................................... 38
3.10.4. Subscribe to RF Notifications .................................................................. 39
3.11. Connectivity Management ............................................................................ 40
3.11.1. Create Infrastructure Connectivity ........................................................... 40
3.12. Migrate Resource Function: intent-based ..................................................... 42
3.13. Migrate Resource Function: detailed-based ................................................. 44
3.14. Scale Resource Function .............................................................................. 46
3.15. Retain Components when Terminating a Composite Resource Function .... 48
4. Requirements R17.5.0 ................................................................................................... 51

4.1. Resource Function - Basic Operations ......................................................... 51

4.1.1. Create Resource Function: intent-based .................................................. 51
4.1.2. Create Resource Function: detailed-based .............................................. 52
4.1.3. Modify Resource Function: intent-based .................................................. 54
4.1.4. Modify Resource Function: detailed-based .............................................. 55
4.1.5. Terminate Resource Function: intent-based ............................................ 57
4.1.6. Terminate Resource Function: detailed-based ........................................ 57
4.1.7. Subscribe to Resource Function Notifications .......................................... 57
4.2. Resource Function - Advanced Operations .................................................. 58
4.2.1. Resource Function Healing ...................................................................... 58
4.2.2. Scale Resource Function ......................................................................... 59
4.2.3. Migrate Resource Function: intent-based ................................................ 60
4.2.4. Migrate Resource Function: detailed-based ............................................. 61
5. Information Model R17.5 ............................................................................................... 64
5.1. Overview ....................................................................................................... 64
5.2. Resource Function ........................................................................................ 64
5.2.1. Attributes ................................................................................................... 64
6. Notifications R17.5 ......................................................................................................... 68
6.1. RF Notifications ............................................................................................. 68
6.2. RF Specification Notifications ....................................................................... 68
7. Service Interfaces R17.5................................................................................................ 69
8. Open Issues and Future Work R17.5 ........................................................................... 70
9. Glossary R17.5 ............................................................................................................... 71
10. 10 Administrative Appendix TR255 R17.5.......................................................... 79
10.1. Document History ......................................................................................... 79
10.1.1. Version History ........................................................................................ 79
10.1.2. Release History ....................................................................................... 83
10.2. Acknowledgments ......................................................................................... 84
10.2.1. Release 1.0 ............................................................................................. 84
10.2.2. Release 2.0 ............................................................................................. 84
10.2.3. Release 3.0 ............................................................................................. 84

Executive Summary
The purpose of this document is to define use cases and requirements for the
provisioning and life cycle management of Resource Functions (RF). Examples of RFs
are VNFs and Network Services (as defined in ETSI NFV), Service Functions and
Service Function Chains (as defined in IETF), and physical network functions such as
routers and Content Delivery Networks (CDNs). The use cases and requirements are
intended to drive the definition of an associated TM Forum API.
The use cases and requirements are divided into two basic kinds, i.e., intent-based and
detailed-based. In the case of intent-based, the consumer does not have a view or the
ability to directly affect the components of a given entity. For the detailed-based, the
opposite is true.

1. Introduction
The purpose of this document is to define use cases and requirements for the
provisioning and life cycle management of Resource Functions (RF). Examples of RFs
are VNFs and Network Services (as defined in ETSI NFV), Service Functions and
Service Function Chains (as defined in IETF), and physical network functions such as
routers and Content Delivery Networks (CDNs). The use cases and requirements are
intended to drive the definition of an associated TM Forum API.
The use cases and requirements are divided into two basic kinds, i.e., intent-based and
detailed-based. In the case of intent-based, the consumer does not have a view or the
ability to directly affect the components of a given entity. For the detailed-based, the
opposite is true.
Very generic terms are used for the actors in the various use cases, e.g., Resource
Function Consumer and Resource Function Provider. Definition of a functional block
architecture, such as ETSI NFV reference architecture framework is avoided, since
reference architectures can lead to misinterpretation where the functional blocks are
seen as system boundaries and typically limit the possible use of a given API. This in
turn leads to very slow and contentious standardization. The view taken in this
document authors is to first define use cases and requirements for an API, and then
(as needed) profile / specialize the API for a given reference point.
The various operations in the associated API can be packaged in various ways to suit
product needs. However, not all subsets of operations may make sense for a given
product. In the end, what subset of operations to use is an implementation decision to
be made by the user of the API associated with the use cases and requirements in this
document.
TR255 has several associated documents, i.e.,
• TR255A Connectivity Patterns for Virtualization Management (this was previously
released as IG1147)
• TR255B Specification Requirements for Resource Functions
• TR255C TOSCA Representation of Virtual Firewall
• TMF664 Resource Function Activation and Configuration API
• TR262E Context Management.

2. Conventions and Terminology R17.5.0

This API specification introduces Resource Function which is used to represent a
Network Service as well as a Network Function as defined in NFV.
Initial analysis, in TR244 TM Forum Information Framework Enhancements to Support
ZOOM R15.0.1 (now deprecated), was intended to extend concepts from the SID
addenda on Logical Resource and Service to cover the NFV concepts of Network
Service (NS) and Network Function (NF). Subsequent work to fully incorporate TR244
requirements into the GB922 Logical and Compound Resource Computing and
Software revealed some undesirable consequences arising from the original TR244
recommendations:
• The distinction between NS and NF was deemed to be artificial, and it was decided
that the same functionality could be handled by one or the other.
• There was an issue with the word “Network" as this limits the scope. Resource
Function is more general as “Resource" can refer to “Network" but also other types
of resources such as storage and compute.
• Further, the concept of Resource Function was designed to cover VNF Forwarding
Graph, and the SDN concepts of Service Function and Service Function Chain.
Consequently, the term Resource Function (RF) has been used to replace Network
Service (NS) and Network Function. Moreover, it was decided that RF composite
would be used to replace NS (both atomic and composite) and composite NFs, and RF
atomic would be used to replace atomic NFs. It was decided that having atomic and
composite NS and NF is redundant.
The concept of Resource Function Specification is defined in the TM Forum
GB922_Logical_and_Compound_Resource_Computing_and_Software_R17.0 SID
guide book. From this document (with some minor editing):
A ResourceFunction specifies a function as a behavior to transform inputs of any
nature into outputs of any nature independently from the way it is provided. It is
typically created by a function designer who may not have specific knowledge on
realization architecture (for example using English text explanations with diagrams, as
in RFC standards, or preferably a machine interpretable language). NetworkFunction,
OfficeFunction as well as GameFunction are examples of specialization (of
ResourceFunction).
A ResourceFunctionSpec is associated to a ResourceFunction in order to indicate
the expected mandatory and optional characteristics.
The functional block that makes requests to (for example) create an RF is referred to
as a consumer (typically not the end customer but more likely, a functional block
internal to the service provider).
The functional block that fulfills requests concerning RFs (e.g., creates or modifies
RFs) is referred to as a provider. Occasionally, the term producer is used
interchangeably with provider. An example of an RF provider would be the Hybrid
Infrastructure Platform (HIP) defined by the TM Forum in several other documents,
e.g., TR262.

3. General Concepts and Use Cases R17.5
3.1. Use Case Template

The following template is used for the use cases:
Use Case
Name
Summary
Actor(s) e.g., Requesting OS, Target OS
Pre- This property defines the conditions that have to be true before
Conditions the operation can be started.
Begins When An indication of when the use case starts
Description This section contains the details of the use case.
The description is provided in steps.
End When An indication of when the use case ends:
Post- In case of success: the expected state of the affected entities
Conditions In case of partial success (e.g., best effort): the state of the
affected entities
In case of failure: the state of the affected entities
Exceptions This lists the ways in which the use case can fail, i.e., a list of
exceptions.
Some common, reusable exceptions:
• Capacity Exceeded
• Entity Not Found
• Atomic Transaction Failure
• Already In Post Condition
• Duplicate
• Not In Valid State
• Object In Use
• Unable To Notify
• Filter Not Supported
Traceability Mapping to associated requirements

3.2. General Concepts

3.2.1. Instantiation Approaches for Resource Functions
Case 1: Fully Intent-based

In this approach, the consumer of a given Resource Function (RF) declares what they
require but not how to accomplish the task. For the particular API described in this
document, the intent-based request for an RF has the following structure:
• Overall Characteristics (both functional and non-functional) - these characteristics
apply to the entire RF. It is also possible to have characteristics at the feature group
or feature level as noted below.
• Feature Group (sequence of Feature)
o Characteristics (both functional and non-functional) - these characteristics
are per feature group.
• Features - there can also be features that are not part of a feature group. In fact,
some RFs may not have any feature groups.
o Characteristics (both functional and non-functional)
For a given type of RF, some of the characteristics, features and feature groups could
be mandatory while other are optional. There could also be dependencies among the
characteristics, features and feature groups, e.g., "in order to request Feature C,
Feature A and B must also be present in a given RF." Optionality and dependency
information needs to be captured in the descriptor / specification associated with a
given RF type.
There needs to be two descriptors / specifications or at least two aspects of the
descriptor / specification:
• One aspect of the descriptor is focused on the consumer of the RF and contains
information relevant to the consumer, e.g., allowable feature combinations, feature
groups, allowable combinations of characteristics, definitions of the characteristics
including default values and value ranges.
• The other aspect of the descriptor is focused on deployment of the resource
function. The deployment aspects of the RF type are defined so that it can be
instantiated in various environments, thus ensuring RF portability.
Mapping to Underlying Support

There can be many combinations of feature groups, features and associated
characteristics for each RF. Clearly, there does need to be a mapping between each
feature group / feature / characteristic combination for a given RF instance, and the
required underlying support. In the case of composite RFs, the first step in the mapping
would be to component RFs (which can be atomic or composite RFs). The mapping
could require several steps until one reaches the leaves of the decomposition, i.e., the
atomic RFs. The atomic RFs are mapped to software deployment units and associated
connectivity among the software deployment units. Further, there needs to be a
mapping between the software deployment units and the required compute and
storage.
The mappings can either be predetermined (solely based on consumer input) or
computed in real-time based on the current state of the infrastructure / environment
(plus the consumer input). The result of such a mapping is referred to as a

deployment scenario. Deployment scenarios and associated requirements are

provided in TR255B Specification Requirements for Resource Functions.
Intent-based for Composite RFs

The intent-based approach (described above) applies to both composite and atomic
RFs. In the case of atomic RFs, the approach is straightforward. For composite RFs,
there is several options regarding the definition of feature groups and features:
• (Abstraction) Define an abstracted set of feature groups and features for the
composite RF.
• (Pass Through) Expose the feature groups and features from the top-level
components (i.e., first level of decomposition).
• (Mixture) In this case, some of the feature groups and features from the top-level
components are exposed by the composite RF, while other feature groups and
features are abstracted and recast for exposure by the composite RF.
Case 2: Fully Detailed-based

In this approach, the consumer can potentially provide all the details (regarding
constituent components) for a given RF instantiation, down to the level of virtualized
storage, compute and network in the infrastructure (if desired). The required
information in the creation request is of the form
1. (By Reference) References to existing components to be used to instantiate the
given resource function
2. (By Value) The required parameters to instantiate components to be used to
instantiate the given resource function.
3. Overall characteristics (i.e., not specific to any component) for the resource
function.
It is possible to use a combination of the two options (by reference and by value). In
terms of the associated descriptor / specification for the resource function, at a
minimum the following would need to be listed:
• the components that must be specified by the consumer and how many of each
(could be a range)
• the components that may (optionally) be specified by the consumer and how many
of each (could be a range). There are two options here, i.e.,
o if the consumer does not specific a given component, the provider will (so
only optional from the point of view of the consumer)
o if the consumer does not specific a given component, the provider will not
either (truly optional).
Case 3: Flavor-based Approaches

Based on the analysis of Case 1, it is recommended that neither Case 3a nor 3b be
supported as such. Rather, it is recommended to use feature groups if the supplier of
the resource function wants to restrict the possible instantiation options in a way similar
to the ETSI NFV deployment flavor concept.
However, as is further explained in TR255B, a deployment scenario (similar in
information to deployment flavor) can be computed based on information contained in
an intent-based request. The deployment scenario is used by the provider of the intent-
based API (TMF664 in this case) to instantiate a given RF. The main point is that the
deployment scenario is not part of the intent-based request but rather computed using

information in the intent-based request and possibly other information (e.g., the current
state of the network / infrastructure).
Case 3a: Deep Flavor-based – in this approach, the consumer can select from one or
more flavors concerning the instantiation of a given resource function. A given flavor
specifies all the required components, down to the level of the virtual compute, storage
and network.
• Each flavor provides an option concerning the underlying components supporting a
given resource function.
• It may be possible to infer the supported features for a given flavor.
• In addition to the flavor, non-functional characteristics may also be provided (e.g.,
the ETSI NFV instantiation level). The non-functional characteristics may also affect
the resulting decomposition of the given resource function.
• There are degrees to which a flavor specifies the components supporting a given
resource function, e.g.,
o In ETSI NFV, the concept of a deployment flavor is used. As the name
suggests, a deployment flavor specifies the supporting components for a
given resource function (VNF or resource function, in the case of ETSI NFV)
down to the level of the virtual resources (compute, storage and network)
that support the software images that effectively comprise the given
resource function.
o However, it is possible to stop short of predetermining all the constituents
down to the virtual resource level. This option should also be allowed and is
further elaborated below (see Case 3b).
In the figure below, a composite RF (RF A) is depicted, along with its components. The
consumer selects Flavor #7 and Size “Large.” The rest of the details are predetermined
by the specification (“descriptor” to use the ETSI NFV term). The attributes shown in
yellow are predetermined by the descriptor based on the selected Flavor and Size for
RF A. (It is not critical to the example, but still should be noted that VNF X is shared by
RF B and RF C.)

Alternately, the specification for RF A (or more precisely for the type of which RF A is
an instance) might only predetermine the components down to the level of the nested
NSs (NSs B and C in this case) and not mention the VNFs at all. This leads to a
variation of this case (i.e., Case 3b below).
Case 3b: Shallow Flavor-based – in this approach, the consumer can select from one
or more flavors concerning the instantiation of a given resource function. A given flavor
specifies all the required components, but not necessarily down to the level of the
virtual compute, storage and network.
If full details for the decomposition of a given resource function (for a given flavor and
non-functional characteristics) are not provided, then how can one ensure there is
sufficient detail to deploy instances of the entity type in various cloud environments?
• Recommended solution: Storage, compute and network characteristics are
specified for the bottom-tier components in the decomposition. However, specific
object instances for storage, compute and network are not be visible by the Hybrid
Infrastructure Platform (HIP), i.e., it is an internal detail.
Case 4: Mixtures of Cases 1, 2 and 3

In this approach, the consumer may
• requests some components, either by reference or by value (detailed-based)
• requests some components by an intent-based approach. In this case, all
components supporting (below) the given component are handled by the producer
and not exposed to the consumer.
• requests some components using a deployment flavor approach. In this case, the
consumer can choose from several fixed configurations (i.e., deployment flavors).
So, in this case, details can be seen below a given component but the consumer
has limited control of the internal configuration for a given component. As noted,
this approach is not recommended but is described here for completeness.
Example 1: Mixture of Detailed-based and Intent-based

In the figure below, entity A (a composite resource function) is to be instantiated. The
consumer is required to select the orange components either by referencing an existing
component of the appropriate type or providing sufficient information to create a new
component. Creation of the bottom level orange components (A.2, A.5, A.7 and A.8) is
intent-based, i.e., the consumer selects some desired features (and characteristics)
and the producer creates the required subtending components (shown in gray). The
gray components are not exposed to the consumer. Component A.1 is hybrid in the
sense that one type of component (of which A.5 is an instance) can be selected by the
consumer but another type of component (of which A.6 is an instance) is determine by
the producer and hidden from the consumer.

Example 2: Mixture of Detailed-based and Flavor-based (not recommended)

In this approach, the consumer of a given composite resource function can select from
several flavors. The figure below shows how resource function A can be implemented
using various flavors, i.e., Flavor #1, Flavor #2 or Flavor #3. In the ETSI NFV approach
(see specifications ETSI NFV IFA013 and IFA014), the consumer can select
• a flavor for the resource function to be instantiated
• an instantiation level (a non-functional characteristic that can impact the
deployment flavor implementation, e.g., fewer or more instances of a given
component, within the ranges defined in the deployment flavor)
• existing components (other resource functions, either composite or atomic) to be
used in the composite resource function (this is the detailed-based aspect).
In this example, once a flavor is selected for the entity to be instantiated, the flavors for
all the components are predetermined (as defined in the specification / descriptor). As
noted earlier, this is the ETSI NFV approach. Other flavor-based approaches are
possible where the constituent components are only partially predetermined by a
flavor.

Mapping of Flavor-based Approach to Intent-based Approach

From the perspective of the consumer of a resource function, the external details of a
given deployment flavor can be made visible as features and feature groups without
going into the deployment details (at least not in the RF creation request). This
effectively maps a deployment flavor approach to an intent-based approach (at least
from the perspective of the consumer of the resource function).
The following table summarizes how to map from the ETSI NFV deployment flavor
approach to an intent-based approach.
Deployment Flavor based Intent-based

Deployment Flavor Map each deployment flavor to an
overall feature group that consist of
other feature groups or features,
with the VDU mappings as follows:
• If the software image associated
with a VDU has one capability,
then map the VDU to a single
feature.
• If the software image associated
with a VDU has several
capabilities, then map the VDU to
a feature group.
This assumes that in the deployment

flavor approach a capability / feature
is assigned to only one VDU and not
distributed across VDUs. As noted,
the above mapping does assume
that a VDU can support several
capabilities / features.
Instantiation Level One or more non-functional
Characteristics at the RF-level
VNFD Element Group – from ETSI GS This would seem to only apply to
NFV IFA011: “A VNFD Element Group is composite RFs.
a mechanism for associating elements of This could be represented by a
a VNFD (VDUs and feature group that references
VnfVirtualLinkDesc(s)) for a certain several features and connectivity
purpose, for example, scaling aspects.” elements that collectively have some
behavior assigned to them, e.g.,
"scale together" or "heal as a unit."

However, the above assumes that the deployment flavors have a fairly direct mapping
to externally visible features (i.e., visible to the consumer of the RF). This assumption
may very well not be true in many cases (see the Firewall example in IG1150). In such
cases (and assuming deployment flavors have already been defined for a type of RF
and there is a desire to migrate to an intent-based approach), it will be necessary to
1. determine the various features and feature groups (which may be buried in the
details of the deployment flavors)
2. define an internal (to the RF) mapping between the various combination of features
and feature groups that can be selected by the RF consumer and the various
deployment flavors.
3. expose the identified features and feature groups to the consumer via the
associated API for RF instantiation.
3.2.2. Dynamic APIs

The concept of a dynamic API (aka polymorphic API) is discussed in TMF254,
Dynamic API Technical Recommendation. As noted in TMF254, there is a need for
both the consumer and producer to be able to exchange data dynamically, without
having to modify their APIs every time a new service is added or a business interaction
changes. This challenge is addressed by dynamic APIs.
Key characteristics / aspects of dynamic APIs are as follows:
• Loose coupling requires that schemas are retrieved and interpreted on-the-fly at
runtime and not at design time. So, there is a need to automate the notification of
change to messages – metadata
• Bring definition of data in-band so documentation can be looked up at runtime to
facilitate changed mappings between systems – links
• Provide information necessary to support automation of message negotiation and
delivery – constraints.
The API defined in this document (TR255) looks to support various aspects of dynamic
APIs (as noted in various subsections that follow).
3.2.3. Relationship to Orders

The various use cases that follow and the associated operation requirements do not
specifically mention orders (such as Resource Orders and Service Orders). The
concept of an order is supplementary to the use cases and requirements defined in this
document, i.e.,
• Orders (via order items) allows one to bundle several provisioning requests
together. Further, one can bundle a provisioning request with operations from other
APIs, e.g., turn-off performance monitoring for an RF, heal the RF and then resume
(turn back "on" performance monitoring for the RF). It should be emphasized that a
general order is needed here as the bundling may entail order items for resource
provisioning, service provisioning, assurance procedures such as healing and other
management aspects (e.g., turn billing "on" or "off").
o For TR255, the bundling aspect of orders is less needed since some of the
use cases (e.g., Create resource function: detailed-based) allow for
"reference by value" which essentially allow the consumer to request that a
composite RF and several of its components be created / modified as part
of a single operation.

• In cases where a provisioning request may not be fulfilled immediately, then the
request needs to be tracked and possibly aborted if it takes too long. In such cases,
it is recommended to embed the provisioning request in an order and use the order
mechanisms to track and control the request.
3.2.4. Scaling and Modification

The concept of scaling is popular in ETSI NFV (for VNFs and resource functions) and
in many industry solutions. In this document, "scaling" specifically refers to cases
where discrete steps have been predefined for the modification of a given type of
resource function. The following points summarize the various use cases that follow
concerning scaling and modification:
• If the desire is to remove or add specific components from / to a composite RF,
then the "Modify Resource Function: detailed-based" use case applies.
• If the desire is to drive a resource function into a given configuration, then the
"Modify Resource Function: intent-based" use case applies.
• If the desire is to do a "bottom-up" scale of a resource function (i.e., scale individual
components), then this would be handled by individual requests on the
components. The bundling of several such requests into a resource or service
order is also possible.
One other important point on scaling, i.e., the complexity grows exponentially as the
number of components that comprise a given entity grows. So, while scaling may seem
quite reasonable for say an atomic resource function, it may be very difficult to
abstract-out capacity attributes for composite RFs with many components. In such
cases, a finer-grained scale (or just update) of the components may be preferable.
3.2.5. Completion Mode

In what follows, the terms “best effort” and “atomic” are used in conjunction with the
completion mode of a given operation. The following definitions are used for these two
terms:
• atomic (all or nothing) – this means that a given operation is completed exactly as
requested, and if not, the operation is completely rolled back.
• best effort (partial fulfillment) – this means that a given operation may succeed
while not providing all that is requested. The threshold for what needs to succeed in
order for a best effort operation not to be rejected is something that can be defined
in the catalog item for the given RF to be provisioned, in the operation itself or in a
policy rule associated with the object class under consideration.
o As an example, a best effort request (for example) to create an RF could
succeed without the RF being fully provisioned (e.g., some component RFs
may be missing). Subsequently, requests (create RF, if we allow for
idempotency, or modify RF) can be used to eventually get the RF fully
provisioned and operational.
One way to handle best effort operations is to support intermediate states for the
particular entity that is (for example) being created. There can be states such as
Pending, with sub-states such as “Awaiting Consumer Input” and “Awaiting Provider
Action.”
For both cases, semantic integrity is to be upheld by the provider of the operation.

3.2.6. Infrastructure Connectivity

Prior to embarking on the details of the infrastructure connectivity use cases, it is
important to consider a number of aspects of the problem space that may change the
specific needs for this use case and other use cases in general.
Assertions
• All connectivity can be considered as providing a service to something, e.g.,
o Direct to an end user
o To a higher level of infrastructure
• The essential connectivity service is apparent adjacency (the effect) and the
representation is connectivity (the component/resource). For this document,
“adjacency” is defined as the ability for a set of entities to communicate.
• Any connectivity request (even at the lowest level of abstraction) is a constraint-
based request where the constraints describe the need and where once accepted
by the provider the constraints should be satisfied on an ongoing basis. Hence, any
accepted connectivity request can be considered as intent-based
• Any request for a forwarding service is essentially a connectivity request.
• A service request may be for connectivity or for other functions or for a hybrid of
connectivity and other functions (e.g., various storage and compute functions).
• The infrastructure is comprised of connectivity and other functions and hence there
may be requests for infrastructure connectivity and for other infrastructure services,
e.g., firewalls.
• The service request should be able to deal with a hybrid as should the
infrastructure request. There is no benefit in distinguishing between the request
forms as there is essentially a continuum. [An operator may expose their full
network detail for the right price.]
• A generalized intent-based request use case and realization pattern, including a
negotiation phase and a commit/accept phase, should be equally applicable to a
client requests and an internal request for infrastructure
• A request for service results in the providing of service where the service is
represented as a set of resources that can be manipulated.
• The intent-based service request in a sophisticated environment can only be
carried out in the context of an understanding of the constraints of the environment.
See TR263E Context Management for further details on contexts.
o These constraints are best represented as an apparent network (a view).
o The intent-based request should operate in the context of this apparent
network.
• The representation of an apparent network need be no different from the
representation of real network.
General comments
Consider the following distinct services:
• A transfer (forwarding) service where the intention is that “what goes in comes out”
so the input information is unchanged.

• A transform (processing) service where the intention is that “information is

assimilated and used to provide some result” so the input information is
transformed.
This is a simplification as many real services are combinations of both. For example, a
classic stylized “VoIP” service has a forwarding aspect between the two callers and a
transform aspect interpreting the call setup request.
In a real environment:
• Transfer service
– Achieved by transforming the representation of the information to enable it to be
conveyed
– To determine whether transfer has been successful.
• Transform service
– Achieved by transferring information between transform points.
All aspects can be considered as components in a Component – System recursion
where a system is an assembly of components that can itself be viewed as a
component (as per IG1118).
Considering existing forwarding models there are clearly processing aspect
encapsulated, e.g.,
• decision to throw a protection switch
• decision to discard a packet (various reasons)
Forwarding is itself a somewhat dull processing function.
The user may primarily need information to be transferred or may primarily need
information to be transformed:
• Information transfer necessarily has as its outer most representation a Forwarding
Construct (see IG1118)
• Information transform necessarily has as it outer most representation a Processing
Construct (see IG1118)
There appear to be essentially three distinct, basic behaviors, i.e., transfer/forwarding,
transform/processing and storage (the last being ignored here).
Key observations and remarks:
– Essentially infrastructure connectivity (or transformation) is a specific type of RF and
should use the same use cases. A given RF may be shared by other NSs and viewed
as infrastructure to the NSs using it.
– An RF for infrastructure connectivity will be created in some context of interconnect-
able points. This context is conveyed by the Forwarding Domain.
– The generalized case is formulated using a Processing Construct (PC) that can cover
any function, including Forwarding and VNFs. All cases are simply constrained PCs.
– FCs encapsulate VNFs and VNFs encapsulate FCs (PCs encapsulate PCs).
– The resource function is really a statement of intent for one or more PCs where intent
is stated in terms of constraints that lead to a set of viable outcomes.
– A request for something abstract, i.e., in a view, will lead to the “creation” of many
underlying parts, all of which could be considered as infrastructure. Indeed, everything
is infrastructure from some perspective.

• Note that creation / instantiation is actually just configuration of an existing

capability - the thing (that is apparently created) is emergent from the configuration.
– There is no reason why the request for the parts of something (e.g., an NS) could not
be of the same form as the request for the whole (as the representation of the parts
can be the same as the representation of the whole).
3.2.7. State Model

The following state machine applies to both atomic and composite RFs:
The states are defined as below.

Note: "entity" is used to refer to both atomic and composite RFs.
• Planning phase
o During the Planning phase, the entity is scheduled for deployment in
accordance with a specific plan.
o During this phase, the entity is assigned the composite state value of
“Planning.”
• Installing phase
o During this phase, the entity undergoes a full commissioning process until it
is finally ready for work
o During this phase, the entity is assigned the composite Inventory state value
of “Installing.”
o Resources may also be installed in the network regardless of any specific
plan.
• Operating phase
o The entity is fully provisioned and ready to support consumers (assuming
the entity is administratively activated and operationally working).
• Retiring phase
o During this phase, the entity undergoes all necessary procedures for its
decommissioning and phasing out.
o During this phase, the entity is assigned the composite state value
“Retiring.”

The states (or “phases,” to be more precise) can be decomposed into sub-states.
Currently, only the Planning and Operating phases are divided into sub-states. In the
future releases of TR255, additional phases may be further decomposed.
The sub-states for the Planning phase are as follows:
• Proposed - a requirement for the entity has been identified, and the entity has
been proposed to address the requirement, but entity characteristics or deployment
details have not been agreed.
• Feasibility Checked – a check has been to be done to see if the proposed entity
can be instantiated as requested. At this point, the design of the entity is not
complete and nothing has been ordered with regard to the given entity.
• Designed – the characteristics of the entity and its deployment have been
completely identified but nothing exists in the network at this point in support of the
resource. Firm agreement has been reached to satisfy a requirement using the
resource.
• Ordered – an order for delivery of an entity type or an instance of an existing entity
type has been agreed.
The sub-states for the Operating phase are as follows:

• Administrative sub-states - the states listed below are typically set by a
management / control system or by some policy (e.g., automatically put the entity in
Deactivated sub-state once it reaches Installing / Accepted).
o Activated- the entity is working, has been configured and activated and can
be used by client(s). The entity is fully operation in the sense that it can
meet all requirements for which it was designed.
o Deactivated - the entity is working, but cannot be used by a client.
• Operational sub-states - the Operational sub-state gives an indication of how well
(or how full) the entity is functioning.
o Working – the entity is completely working as intended.
o Meeting All SLAs – the entity is presently meeting all the SLAs promised to
each of its clients, but is not completely functional.
 An example would be an entity (say a VNF) that when fully
operational can support 5 clients but presently can only support 3
clients. However, the VNF currently only has 3 three clients and the
VNF is providing the promised SLA to those 3 clients.
o Meeting Some SLAs – the entity is meeting only some of the SLAs
promised to its clients
o Meeting No SLAs – the entity is meeting none of the SLAs promised to its
clients
o Not Working – the entity is completely non-functionally.
The above definition of operational sub-states is a departure from earlier work based
on ITU-T X.731 and similar work in the IETF where there are only two values for the
operational (i.e., enabled and disabled). In general, but in particular for virtualized
networks, it is recognized that a consideration of the SLA with respect to the resource

is needed (and thus the expanded set of values in the operational sub-state in this
document).
Complementary approach is taken in TM Forum GB917-2, SLA Management
Handbook – Volume 2, where the concepts of a Service Degradation Factor (SDF) is
introduced. The SDF is defined to be between 0 and 1, which can be interpreted as
sort of a continuous attribute (compared to the discrete Non-working sub-states defined
above). The SDF appears to be more appropriate as a performance measurement
rather than an attribute of the RF or NF classes.
3.2.8. Scheduling
Some of the operations (such as Create Resource Function) allow for scheduling with
respect to the provisioning of the TF. The general idea is that a schedule and desired
configuration for the RF is provided, e.g., every Tuesday at 5 AM put RF X into
Configuration Y (essentially value settings for some subset of the RF X's attributes).
Some examples:
• Activate an RF on a given schedule and deactivate the same RF on another
schedule. In this case, two schedules would be needed.
• Similar to the previous example but rather than activate and deactivate, some other
characteristic of the RF would be changed, e.g., increase bandwidth at 12 AM and
decrease bandwidth at 3 AM every weekday.
The basic requires for scheduling are as follows:

• It shall be possible to associate a schedule with a desired state of an RF.
• The schedule can be periodic or nonperiodic.
• At any one point in time, it shall be possible to associate several schedules with a
given RF.
With auto-scaling and other proactive techniques for capacity management, scheduling
may be needed less in fully virtualized networks. However, even in fully virtualized
networks, the service provider (or more precisely their monitoring software) may
determine times of peak-load (and valleys) for various infrastructure RFs, and schedule
infrastructure support accordingly.
3.2.9. Context or Role for Components in a Composite RF

In some cases, it is clear from the descriptor / specification and location information
how a given component fits into a composite RF. In other cases, the descriptor /
specification and location information may not be sufficient. For example, consider an
RF that requires several component RFs of the same type and at the same location but
each RF plays a different role. The RF provider may need more information in such
cases, and thus a role parameter is allowed for each component in the detailed-based
operations for create and modify.
An RF can be shared (be a component of) several composite RFs. Thus, it is possible
for a given entity to play different roles at the same time.
3.2.10. Status of Tasks

The heal, scale and migrate operations will typically be long-lived. Consequently, the
consumer will be able to request the status of the operation. The following possible
status values apply to heal, scale and migrate for Resource Functions:

• In Progress
• Paused – Consumer Input Required
• Paused – Manual Intervention Required
3.3. Create Resource

Function: intent-based
Use Case Create Resource Function: intent-based

Name
Summary This use case entails the creation of a resource function. The
resource function may be a composite or atomic resource
function. The operation may be atomic or best effort.
The RFC only provides intent-based information about the
requested resource function, e.g., Service Access Points (SAPs).
The RFC does not provide information about the internals of the
RF such as references to specific components that are to be
used in the RF creation. The request is about “what” and not
about “how.”
As noted earlier in this section, the intent is described in terms of
overall characteristics, feature groups and features.
Actor(s) Resource Function Consumer (RFC), Resource Function
Provider (RFP)
Pre- None
Conditions
Begins RFC sends a create resource function request to the RFP
When
Description 1. The RFC sends a create resource function request to the
RFP. The request will
a. have a reference to the catalog item for the type of
resource function (an instance of which is to be
created).
b. contain information about what is needed, e.g., SAP
locations and characteristics.
c. various policies can be assigned to the NS, e.g.,
deletion policy concerning what type of components
are to be retained when the RF is terminated.
2. The RFP decomposes the request from the RFC. If the
resource function is composite, it is first decomposed into

Use Case Create Resource Function: intent-based

Name
(eventually) atomic resource functions. Further decomposition
of the atomic resource functions into logical and physical
resources may be done by the RFP or can be delegated by
the RFP to other functional blocks. In any event, all delegation
is transparent to the RFC. The RFP also takes care to
orchestrate connectivity that is needed among the
components of the resource function, as allowed by the RF
specification.
3. The RFP responds to the request from the RFC, with an
indication of failure or success, and in the case of success,
the resource function is returned. However, if the RFC also
wants the structures for the components comprising the
resource function, then a query is needed.
a. If the request was atomic, then either the resource
function will be created as requested or the entire
operation will be rolled-back.
b. If the request was best effort, the RFP may return a
resource function that is not fully operational. The RFP
may return the state of the partially configured RF and
allow further requests to make the RF fully operational.
End When The use case ends when the RFP responds to the RFC.
Post- In case of success: the resource function is in the state and
Conditions configuration requested by the RFC.
In case of partial success (e.g., best effort): the resource function
exists but is not in the state and configuration requested by the
RFC.
In case of failure: the resource function is not created.
Exceptions Applicable Common Exceptions:
• Duplicate (can only happen when the RFC selects the RF
identifier)
Traceability Section 4.1.1, Create Resource Function: intent-based

3.4. Create Resource

Function: detailed-
based
Use Case Create Resource Function: detailed-based

Name
Summary This use case entails the creation of a resource function. The
(By Value) The RFC can provide details concerning the
components to be used in the creation of the resource function.
(By Reference) This can also involve references to existing
resource functions to be used in the RF that is to be created.
Provider (RFP)
Pre- It is assumed that any referenced (component) resource
Conditions functions already exist.
Begins RFC sends a create resource function request to the RFP
When
Description 1. The RFC sends a create resource function request to the
a. have a reference to the catalog item for the type of
resource function (an instance of which is to be
created).
b. contain information about what is needed, e.g., SAP
locations and characteristics
c. have at least some of the internal details for the
resource function, e.g., references to components
(other resource functions) that are to be used in the
resource function, and specific internal connectivity
directives. Components (RF instances) to be used in
the given RF can already exist (in which case, they are
referenced by Id) or may not yet exist (in which case,
they are referenced by value, i.e., the information
needed to create the component is provided in the
create request for the composite RF).
d. various policies can be assigned to the RF, e.g.,
deletion policy concerning what type of components
are to be retained when the RF is terminated.
2. The RFP decomposes the request from the RFC, while
making use of referenced components. If the resource
function is composite, it is first decomposed into (eventually)

Use Case Create Resource Function: detailed-based

Name
atomic resource functions. Further decomposition of the
atomic resource functions into logical and physical resources
may be done by the RFP or can be delegated by the RFP to
other functional blocks. In any event, all delegation is
transparent to the RFC. The RFP also takes care to
orchestrate connectivity that is needed among the
specification.
the resource function is returned. However, if the RFC also
wants the structures for the components comprising the
resource function, then a query is needed.
function will be created as requested or the entire
resource function that is not fully operational. In this
case, further processing will be needed.
exists but is not in the state and configuration requested by the
RFC
In case of failure: the resource function is not created
• Duplicate (can only happen when the RFC selects the RF
identifier)
• Entity Not Found (with regard to referenced components)
• Not In Valid State (with regard to referenced components)
• Object In Use (with regard to referenced components)
Traceability Section 4.1.2, Create Resource Function: detailed-based

3.5. Modify Resource

Use Case Modify Resource Function: intent-based

Name
Summary This use case entails the modification of a resource function. The
requested resource function modification, i.e., describe how the
resource function is to look from an external view as a result of
the operation. The RFC does not provide information about the
internals of the RFC such as references to specific Resource
Functions that are to be used in the RFC. The request is about
“what” to modify and not about “how” to modify the existing
Resource Function.
As noted earlier in this section, the intent is described in terms of
overall characteristics, feature groups and features.
Provider (RFP)
Pre- The resource function to be modified must already exist.
Conditions
Begins RFC sends a modify resource function request to the RFP
When
Description 1. The RFC sends a modify resource function request to the
RFP. The request will contain information about what needs
to be modified, e.g., add/remove SAPs, modify SAP
characteristics and modify resource function characteristics.
2. The RFP decomposes the request from the RFC. The modify
request may, in turn, require updates to the components
(other resource functions) supporting the resource function.
The modify request may also involve the addition or removal
of components. The RFP also takes care to orchestrate any
connectivity that is needed among the components of the
resource function, as allowed by the RF specification.
the resource function is returned.

Use Case Modify Resource Function: intent-based

Name
function will be modified as requested or the entire
b. If the request was best effort, the RFP may perform
only some of the requested modifications to the
resource function. In this case, further processing may
be needed.
has been partially modified but is not in the state and
configuration requested by the RFC.
In case of failure: the resource function is not changed at all.
Exceptions If the RFP is performing some action on the resource function
(either an internally triggered action, such as an auto-scaling, or
an external triggered action, e.g., still processing a previous
modification request), then the current request may be rejected.
Applicable Common Exceptions:
• Object In Use
Traceability Section 4.1.3, Modify Resource Function: intent-based

3.6. Modify resource

function: detailed-
based
Use Case Modify Resource Function: detailed-based

Name
Summary This use case entails the modification of a resource function. The
The RFC can provide details concerning the components to be
used in the resource function modification, i.e., usage of existing
connectivity or other resource functions.
Provider (RFP)
Pre- The resource function to be modified already exists.
Conditions It is assumed that any referenced (component) resource
functions already exist.
Begins RFC sends a modify resource function request to the RFP
When
Description 1. The RFC sends a modify resource function request to the
RFP. The request will:
a. reference an existing resource function
b. may contain some abstracted information about what
needs to be modified, (this would be similar to an
intent-based modify)
c. have at least some of the internal details concerning
the resource function modification, e.g., references to
other resource functions that are to be used in the
resource function modification. Components (RF
instances) to be used in the given RF can already exist
(in which case, they are referenced by Id) or may not
yet exist (in which case, they are referenced by value,
i.e., the information needed to create the component is
provided in the create request for the composite RF).
d. (for the components to be removed from the resource
function as part of the modify) provide an indication of
whether the removed entities are to be retained for
future use or terminated.
making use of referenced components. The RFP also takes
care to orchestrate any connectivity that is needed among the
specification.

Use Case Modify Resource Function: detailed-based

Name
the resource function is returned.
function will be modified as requested or the entire
resource function that is only partially modified. In this
case, further processing will be needed.
partially modified but is not in the state and configuration
requested by the RFC.
In case of failure: the resource function is not created.
(either an internally triggered action, such as an auto-scaling, or
an external triggered action, e.g., still processing a previous
modification request), then the current request may be rejected.
• Entity Not Found (could apply to the RF or components
referenced in the request)
• Not In Valid State (could apply to the RF or components
• Object In Use (could apply to the RF or components
Traceability Section 4.1.4, Modify Resource Function: detailed-based

3.7. Terminate resource

function: intent-based
Use Case Terminate resource function: intent-based

Name
Summary This use case entails the termination of a resource function.
Provider (RFP)
Pre- The RF to be terminated already exists.
Conditions
Begins RFC sends a terminate resource function request to the RFP
When
Description 1. The RFC sends a terminate resource function request to the
RFP.
2. The RFP decomposes the request from the RFC and, based
on its internal policies, starts to terminate or possibly retain
(some or all) the various components that are currently
supporting the resource function.
3. The RFP responds to the request from the RFC but does not
provide any detail concerning what components have been
terminated or retained.
Post- In case of success: the resource function is terminated and no
Conditions longer accessible / usable by the RFC. There is no assumption
as to whether the RFP also terminates the components
supporting the resource function.
In case of failure: the resource function is not terminated.
(either an internally triggered action, such as an auto-
modification, or an external triggered action, e.g., still processing
a previous modification request), then the current request may
be rejected.
• Object In Use

Use Case Terminate resource function: intent-based

Name
Traceability Section 4.1.5, Terminate Resource Function: intent-based
3.8. Terminate resource

function: detailed-
based
Use Case Terminate resource function: detailed-based

Name
Summary This use case entails the termination of a resource function.
Provider (RFP)
Pre- The RF to be terminated already exists.
Conditions
Begins RFC sends a terminate resource function request to the RFP
When
Description 1. The RFC sends a terminate resource function request to the
RFP. The RFC may, in addition, request that some of the
components of the resource function be retained for future
use.
2. The RFP decomposes the request from the RFC and, based
on its internal policies and the input from the RFC, starts to
terminate or possibly retain the various components that are
currently supporting the resource function.
3. The RFP responds to the request from the RFC and indicates
which of the components (out of those visible to the RFC)
have been retained.
Post- In case of success: the resource function is terminated and no
Conditions longer accessible / usable by the RFC, and all the components,
that the RFC had requested to be retained, have been retained.
For all other components (not mentioned in the RFC terminate
request, it is up to the RFP whether to retain the component or

Use Case Terminate resource function: detailed-based

Name
not), e.g., components shared by several composite RFs will
likely need to be retained.
In case of partial success: the resource function is terminated
and no longer accessible / usable by the RFC, and at least some
the components, that the RFC had requested to be retained,
have been retained.
In case of failure: the resource function is not terminated and
remains as it was before the request.
(either an internally triggered action, such as an auto-
modification, or an external triggered action, e.g., still processing
a previous modification request), then the current request may be
rejected.
• Object In Use
Traceability Section 4.1.6, Terminate Resource Function: detailed-based
3.9. Resource Function

Healing
In what follows, a use case is provided for resource function healing.
Use Case Resource Function Healing

Name
Summary This use case entails the RFC directing the RFP to heal an RF
that is not performing as agreed (i.e., not meeting the SLA or
more likely, an OLA). The basic assumption here is that the RFC
detects the issue with the RF before the RFP, or the RFP detects
the issue with the RF first but given the nature of the issue,
defers to the RFC for instructions on how to address the issue.


Name
While typically the RFP will detect RF issues first, there are
cases where the RFC will first know about a problem with a RF,
e.g.,
• The end customer for a CFS complains about an issue with
the CFS. The problem is isolated to a given RF by the RFC
which then directs the associated RFP to heal the RF.
• An RF (call it RF X) is part of a CFS which has an issue with
another component (call it RF Y). For the example here, RF X
is managed by the RFP in question (call it RFP A) but RF Y is
managed by another RFP (call it RFP B). Assume that RF Y
is fixed by changing some of the SAPs and now RF X is no
longer properly connected to RF Y. RFP B would need to
inform the RFC of the SAP changes to RF Y and the RFC
would then direct RFP A to (effectively) heal RF X by
attaching to the new SAPs of RF Y.

Providers (RFPs)
Pre- The RF to be healed already exists.
Conditions
Begins RFC detects a problem with a RF. The term “problem” is used to
When mean the SLA for the RF is not being met (so this is not
necessarily a fault).
Description 1. The RFC detects a problem with a RF, e.g., failure,
performance degradation or not meeting SLA.
2. The RFC decides on the (predefined) recovery policy to be
used.
3. (Option 1: Single heal request based on pre-defined script)
a. The RFC sends a RF heal request to the RFP. The
request may include:
i. Target resource function information
ii. Heal action: this is basically a pointer to a
predefined script, e.g., “Return RF attributes to
default values”
iii. Heal policy: minimize network latency for the
RF, minimize cost, and/or some location
preference (if the RF needs to be moved to
perhaps a sub-optimal location)
iv. Cause: a reason for why the heal is being
requested (e.g., customer complaint)


Name
v. Start time
vi. Healing parameters: specific parameters that
may be needed to qualify the heal request
b. The RFP decomposes the request from RFC, and then the
RFP orchestrates the RF heal, based on the received heal
directive.
c. The RFP responds to the request from RFC with the status of
the heal. If the heal is not immediately complete (i.e., in time for
the initial response), the RFC may poll for the status of the heal.
4. (Option 2: Several re-configuration requests from the RFC to
the RFP)
1. In this case, the RFC does not request execution of a pre-
defined script by the RFP but rather sends one or more re-
configuration requests to the RFP (which effectively
accomplish healing of the RF).
2. The RFP responds to each of the re-configuration requests
from the RFC.
5. (Option 3: The RFC can pinpoint the affected RF, but it does
not have the knowledge of how to fix it.)
1. In this, the RFC issues a trouble ticket that references the
“broken” RF. The trouble ticket is either sent directly to the
RFP or to a separate functional block which then informs the
RFP of the problem.
2. The RFP attempts to heal the RF via internal healing logic.
The RFP updates the trouble ticket accordingly, e.g., the RF
has been fixed, or with an indication that healing was
attempted but the problem could not be fixed.
End When In Option 1: the use case ends when the RFP responds to the RF
healing request from the RFC
In Option 2: the use case ends when the RFP responds to the
last RF re-configuration request from the RFC
In Option 3: the use case ends when the RFP closes the trouble
ticket (with an indication that the RF has been healed)
Post- In case of success: the resource function is healed and now in
Conditions compliance with the SLA
In case of failure: the resource function is not healed and not in
compliance with the SLA.


Name
• Object In Use
Traceability Section 4.1.7, Resource Function Healing
Another option is to make the use case more interactive (along the lines of a dynamic
API). For example,
• The RFC tells the RFP (via a trouble ticket) that there is an issue with a given RF.
• The RFP replies back to the RFC with an indication that it is trying to solve the
problem.
• Perhaps, at some point, the RFP determines it cannot solve the problem and
updates the trouble ticket.
• At this point, the RFC could try various healing scenarios with feedback from the
RFP at each step along the way.

Notifications
Notifications are used by the RFP to report on the creation, modification and
termination of resource functions. Modification notifications cover two basic cases, i.e.,
state changes and changes to other attributes (typically called Attribute Value Changes
(AVCs)).
Composite Event Occurrences are not supported for this version of TR255, only atomic
Event Occurrences are in scope.
3.10.1. RF Creation Notification
Use Case RF Creation Notification

Name
Summary This use case entails the reporting of a newly created resource
function
Actor(s) Notification Consumers (NotfC), Notification Provider (NotfP)

Use Case RF Creation Notification

Name
Pre- The NotfC has already subscribed to receive resource function
Conditions creation notifications.
Begins A resource function has been created
When
Description 1. A new resource function is created.
2. The NotfP becomes aware of the resource function creation.
3. The NotfP distributes notifications concerning the resource
function creation to the NotfCs that have previously
subscribed to such notifications. The entire RF object is sent
in the notification.
End When The use case ends when the subscribed NotfCs have received
the resource function creation notification.
Post-
Conditions
Exceptions Communication between the NotfP and some (or all) of the
NotfCs is “down”
Traceability
3.10.2. RF Modification Notification
Use Case RF Modification Notification

Name
Summary This use case entails the reporting of a resource function
modification. The use case includes reports on both state-related
attributes (e.g., admin and operational state changes) and
changes to non-state-related attributes. Some standards
distinguish between state change notifications and attribute value
change notifications but that is not the case here.
Conditions modification notifications.
Begins A resource function has been modified
When
Description 1. An existing resource function has been modified.

Use Case RF Modification Notification

Name
2. The NotfP becomes aware of the resource function
modification.
function modification to the NotfCs that have previously
subscribed to such notifications. The entire RF object is sent
in the notification. Sending the entire RF and not just the
modified attributes is a good inventory synchronization
practice.
the resource function modification notification.
Post-
Conditions
Traceability
3.10.3. RF Termination Notification
Use Case RF Termination Notification

Name
Summary This use case entails the reporting of a resource function
termination.
Conditions termination notifications.
Begins When A resource function has been terminated
Description 1. A resource function has been terminated.
2. The NotfP becomes aware of the resource function
termination.
function termination to the NotfCs that have previously
subscribed to such notifications.
the resource function termination notification.

Use Case RF Termination Notification

Name
Post-
Conditions
Traceability
3.10.4. Subscribe to RF Notifications
Use Case Subscribe to RF Notifications

Name
Summary This use case entails subscription to RF notifications (creation,
modification and/or termination)
Pre-
Conditions
Begins A NotfC sends a subscribe request to a NotfP
When
Description 1. A NotfC sends a subscribe request to a NotfP. The request
will typically have one or more filters that the NotfP will use to
sort out notifications that are not of interest to the NotfC.
2. The NotfP replies to the NotfC with an indication that it has
now subscribed to RF notifications based on the supplied
filters from the NotfC.
End When The NotfP replies to the NotfC with an indication that the
subscription request has been successful.
Post-
Conditions
• Unable To Notify
• Filter Not Supported
Traceability

3.11. Connectivity
Management
As noted earlier in this document, infrastructure connectivity is but one example of an
RF and so, the use case that follows is simply a specialization of the basic Create
resource function use case. Further details (beyond what are provided in the use case
below) can be found in TR225A Connectivity Patterns for Virtualization Management.
3.11.1. Create Infrastructure Connectivity
Use Case Create Infrastructure Connectivity

Name
Summary This use case entails the creation of infrastructure connectivity
(which is essentially an example of an RF). The infrastructure
connectivity may be:
• Basic
o Simple point-to-point
o Complex multi-point
• Composite
o Multi-layer
o Multi-flow.
The operation may be a mix of atomic and best effort statements.
The operation to fulfill the request may or may not take a
significant amount of time.
The request may be for infrastructure connectivity to be created
at some point in the future, and for some duration or at some
periodicity.
The infrastructure connectivity request provides intent-based
information about the requested infrastructure, e.g., building
source and destination. The infrastructure connectivity request
may also provide a degree of detail down to the level of a precise
route (constrained only by the degree of knowledge shared by
the infrastructure controller). Information will always be at some
level of abstraction (the request is never in terms of transistors to
be used). The request may entail a mix of “what” (intent) and
“how” (details).
Actor(s) Infrastructure Connectivity Consumer (ICC), Infrastructure
Connectivity Provider (ICP)
Pre- Potential activities prior to the request:
Conditions • Negotiation and achievement of agreement that such a
request may be made


Name
• The ICP will have presented a view of resources that the ICC
can reference in its subsequent requests for infrastructure
connectivity.
Begins ICC sends an infrastructure connectivity intent request to the ICP

When
Description 1. The ICC sends an infrastructure connectivity intent request to
the ICP. The request will
a. have a reference to the specification (catalog item) for
the type of infrastructure connectivity required
b. contain information about what is needed, e.g.,
termination locations and characteristics. The request
may reference specific resource functions
(components) depending upon the degree of shared
knowledge.
2. The ICP decomposes the request from the ICC making
appropriate use of all referenced resource functions. If the
infrastructure connectivity is composite, it is first decomposed
into (eventually) atomic infrastructure connectivity. The ICP
takes care to orchestrate all connectivity that is needed
among the components of the infrastructure connectivity while
fulfilling any directives and constraints provided.
3. If the operations necessary to create the Infrastructure
connectivity will take significant time, the ICP will respond with
progress indications and allow for pause and abort, etc.
4. If the request is for future/periodic connectivity, the ICP will
evaluate the resources with a view of future time and may
choose to reserve resources or simply gamble on them being
present at the right time.
5. Depending upon the mix of mandatory and best effort
elements, the activities to satisfy the request will be:
a. Fully successful
b. Partially satisfied with unsuccessful and off-optimum
best elements identified
c. Completely unsatisfied
6. The ICP responds to the request from the ICC, providing
information on the degree of success.
a. Where there are elements created, the internal details
of the infrastructure connectivity will be exposed to
whatever level is appropriate with respect to the


Name
degree of shared knowledge and expectation stated
during the request. The details may:
i. Be exposed in detail
ii. Be exposed in abstract
iii. Not be revealed at all
b. The external characteristics such as SAPs are
revealed.
End When The use case ends when the ICP responds to the ICC.
Post- In case of success: the requested connectivity infrastructure will
Conditions have been established.
In case of partial success: some part or aspect of the requested
connectivity infrastructure will have been established.
In case of failure: no part or aspect of the requested connectivity
infrastructure will have been established.
Exceptions
Traceability
3.12. Migrate Resource

In addition to this and the following use case, there is another way to accomplish
migration of an NS, i.e.,
• the RFC requests creation of a new RF that shares some of the components of the
RF that is to be migrated
• the new RF is successfully created
• the old RF (the RF that was to be migrated) is then terminated.
Use Case Migrate Resource Function: intent-based

Name
Summary This use case entails the migration of a resource function. The
requested resource function, e.g., Service Access Points (SAPs).
The RFC does not provide information about the internals of the


Name
RF such as references to specific network functions that are to
be used in the resource function migration. The request is about
“what” and not about “how.”
Provider (RFP)
Pre-
Conditions
Begins RFC sends a migrate resource function request to the RFP
When
Description 1. The RFC sends a migrate resource function request to the
a. Have reference to the resource function instance which
needs to be migrated.
b. Contain information about what is needed, e.g., SAP
locations and characteristics.
2. The RFP decomposes the request from the RFC. If the
resource function is composite, it is first decomposed into
(eventually) atomic resource functions. Further decomposition
of the atomic resource functions into resource functions and
in turn, logical and physical resources may be done by the
RFP or can be delegated by the RFP to other functional
blocks. In any event, all delegation is transparent to the RFC.
The RFP also takes care to orchestrate all connectivity that is
needed among the components of the resource function to be
migrated.
3. RFP will also read the current resource function instance
“Context Variables” and parameters which might be required
to migrate the resource function. This will be internally done
by the RFP and will be required to maintain the continuity of
resource function after migration.
indication of failure or success. In the cases of success, the
resource function is returned. However, if the RFC also wants
the structures for the components comprising the resource
function, then a query is needed.
function will be migrated as requested or the entire
migrated resource function that is not fully operational.


Name
The RFP may return the state of the service and allow
further requests to make the service fully operational.
Post- In case of success: the resource function is migrated as
Conditions requested by RFC and is fully operational.
In case of partial success (e.g., best effort): the migrated
resource function exists but is not in the state and configuration
requested by the RFC
In case of failure: the resource function is not migrated.
• Object In Use
Traceability
3.13. Migrate Resource

Function: detailed-
based
Use Case Migrate resource function: detailed-based

Name
Summary This use case entails the migration of a resource function. The
The RFC can provide details concerning the components to be
used in the migration of the resource function. This can involve
references to existing resource functions. Additionally, the RFC
can also provide existing (or desired) attribute values for the RF


Name
to be migrated. This input will be used by RFP to create the
resource function at the migrated location.
Provider (RFP)
Pre- It is assumed that any referenced (component) resource
Conditions functions already exist.
Begins RFC sends a migrate resource function request to the RFP
When
Description 1. The RFC sends a migrate resource function request to the
a. Have a reference to the resource function instance
which needs to be migrated.
b. Contain information about what is needed, e.g., SAP
locations and characteristics
c. Have at least some of the internal details for the
resource function, e.g., references to other
components that are to be used in the resource
function, and internal connectivity directives.
d. It can also provide existing (or desired) attribute values
for the RF to be migrated.
making use of the referenced components. If the resource
function is composite, it is first decomposed into (eventually)
atomic resource functions. The RFP also takes care to
orchestrate all connectivity that is needed among the
components of the resource function, while fulfilling any
connectivity directives that are provided in the request.
3. The RFP responds to the request from the RFC. In the case
of success, the resource function is returned. However, if the
RFC also wants the structures for the components comprising
the resource function, then a query is needed.
function will be migrated as requested or the entire
resource function that is not fully operational. In this
case, further processing (with regard to the migration)
will be needed.


Name
Post- In case of success: the resource function is migrated as
Conditions requested by RFC and is fully operational.
In case of partial success (e.g., best effort): the migrated
resource function exists but is not in the state and configuration
requested by the RFC.
In case of failure: the resource function is not migrated, nor is any
part of the resource function migrated
• Object In Use
Traceability
3.14. Scale Resource

Function
In cases where there are pre-defined steps for increasing or decreasing some aspect
of a resource function, the scale use case applies. By nature, this is an intent-based
approach.
The following items are not covered in this use case:
• If the desire is to remove or add specific components from / to a resource function,
then the "Modify resource function: detailed-based" use case applies.
• If the desire is to drive a resource function into a given configuration, then the
"Modify resource function: intent-based" use case applies.
• If the desire is to do a "bottom-up" scale of a composite resource function (i.e.,
scale individual components), then this would be handled by individual requests on
the components. The bundling of several such requests into an order is also
possible.
Use Case Scale Resource Function

Name
Summary This use case applies when pre-defined steps are available for a
given type of resource function. The RFC (based on its decision


Name
processes) requests that the RFP either scale up or down a
given resource function. The operation may be atomic or best
effort.
Provider (RFP)
Pre- • The resource function exists
Conditions • The resource function is of a type that has predefined scaling
steps
Begins The RFC sends a scale resource function request to the RFP.
When
Description 1. The RFC requests that the RFP scale a given (existing)
resource function. The following information is provided:
a. Reference to the resource function to be scaled
b. An indication of what aspect of the resource function is
to be scale, e.g., a vCDN resource function might have
aspects such as quick access memory for frequently
used content.
c. Direction of the scale (i.e., up or down) and the number
of scaling steps
d. Characteristics - in some cases, specific characteristics
(and associated values) may need to be provided for
specific type of scale and perhaps on a per aspect
basis.
e. Schedule for the scale (if not provided, the scale is to
be done immediately) - this can be used to defer the
scale to a later point in time (either once or several
times). In cases where multiple scales are requested
on some schedule (e.g., scale-up aspect Z by two
steps every Tuesday at 2 AM), there would typically
need to be another operation that scales back the
resource function (for the given example, scale-down
aspect Z by two steps every Tuesday at 6 AM).
f. Scaling parameters: various parameters needed to
qualify the scale request
2. The RFP analyzes the request and attempts to scale the
resource function as requested. If the request is best effort, it
is allowed for the RFC to scale the resource function less than
requested.


Name
3. The RFP responds to the RFC with details concerning the
scale.
End When The RFP responds to the scale resource function request.
Post- In case of success: the resource function is scaled as requested
Conditions by RFC.
is scaled up (or down) less than requested but not zero scaling.
In case of failure: the resource function is not scaled at all (no
change to the original configuration before the use case started).
Exceptions • Capacity Exceeded
Traceability
3.15. Retain Components

when Terminating a
Composite Resource
Function
Use Case Retain Components when Terminating a Composite

Name
Summary This use case expands on the previous termination use cases
which only mention the possibility of retaining components when
a given composite RF is terminated.
Actor(s) Consumer, Provider
Pre- The entity to be terminated exists
Conditions In the case where policy is used, the consumer has requested
that a terminate policy be associated with the entity to
(eventually) be terminated. The terminate policy indicates the
conditions under which a component is to be retained (e.g., the
component is of a given type) and what to do with the retained
component (e.g., if of Type X, add to Holding RF instance Y).


Name
Begins Consumer decides to terminate an entity with components (i.e.,
When composite NF or NS) and wants to retain some of the
components after termination of the given entity.
Description Approach #1: Holding RF
1. For the components to be retained, the consumer adds the
components to a Holding RF (i.e., an RF other than the one
being terminated). The Holding RF may already exist or it can
be created at this time. The purpose of the Holding RF is to
hold components for later using in other composite RFs. It
should be emphasized that, at this point, the components
added to the Holding RF are still part of the RF that is to be
terminated. So, these components are now shared by at least
two RFs.
2. The consumer then requests that the given RF be terminated.
The components that are to be retained are not terminated
since they are still part of the Holding RF.
3. The provider terminates the given RF and all components that
are not otherwise shared with another composite RFs.
Approach #2: Retention via Policy

1. The consumer requests that the provider terminate a given
RF.
2. The provider follows the policy associated with the given RF
(e.g., upon termination of the given RF adding several of the
components to one or more Holding RFs) and then
terminates the given RF. The components that have been
added to the Holding RF were previously used the RF to be
terminated, and are retained in the Holding RF once the given
RF is terminated.
3. The provider responds back to the consumer with an
indication that the RF has been terminated.
End When The provider responds to the entity termination request.

Post- In case of success: the entity is terminated and the desired
Conditions components are retained.
In case of failure: the entity is not terminated.
Exceptions • Entity Not Found
• Object In Use


Name
Traceability

4. Requirements R17.5.0
The following section contains requirements that are derived from the use cases in the
previous section.
While a decision has been made not to classify every operation parameter as
mandatory or optional, it was decided to mark critical parameter with an E (for
Essential). An “E” is placed next to parameters that are essential for the operation to
work in any scenario. For specific scenarios (i.e., when this generic interface is applied
to a specific reference point), additional parameters may be classified as Essential.
4.1. Resource Function -

Basic Operations
This section contains basic operations for RF management, i.e., create, modify,
terminate and subscribe to notifications.
4.1.1. Create Resource Function: intent-based
Create The Interface shall support the capability for a Resource

Resource Function Consumer (RFC) to request the creation of a Resource
Function: Function via an intent-based operation.
intent-based Input parameters:
• Type of the RF to be created (E)
• Initial admin state – an indication of the desired (start-up)
state of the RF (either “locked” or “unlocked”)
• Name - user friendly designation for the RF
• Description - descriptive text for the given RF
• SAP information (location, connectivity and bandwidth
requirements)
• Priority – this is an integer from 1 to N (N may vary per type
of Resource Function). It gives an indication to the Resource
Function Provider (RFP) of the importance of the given
request. The RFP can preempt lower priority Resource
Functions in fulfilling a request for a higher priority Resource
Function. Specific actions to be taken depend on the
Resource Function and prior agreement between the RFC
and RFP.
• Schedules – a list of schedule / Resource Function pairs
where each pair indicates that the Resource Function is to
be put in the desired (specified) configuration at each point in
the schedule. It is typical to only specific values for a subset

of the Resource Function, e.g., could just be the admin state

that is modified on a given schedule.
• Completion mode – either “best effort” or “atomic”
• Auto-modification – a list of the kinds of auto-modification
that are to be applied to the Resource Function.
• Location (aka "Place" in the APIs) – the desired location of
the RF. This may not be useful in the case of a distributed
RF. In such cases, the location of the SAPs may be more
useful.
• Overall Characteristics (both functional and non-functional) -
these characteristics apply to the entire RF.
• Feature Groups
o Characteristics (both functional and non-functional) -
these characteristics are per feature group.
• Features
o Characteristics (both functional and non-functional)
Output parameters:
• The Resource Function is returned to the RFC. The RFC
may subsequently retrieve the structures for the components
comprising the Resource Function.
• For best-effort, it is possible to get less than what was
requested, e.g., lower-bandwidth than requested.
Source
4.1.2. Create Resource Function: detailed-based
Create The Interface shall support the capability for a Resource

Resource Function Consumer (RFC) to request the creation of a
Function: Resource Function via detailed-based operation.
detailed- Input parameters:
based
• Type of the RF to be created (E)
• Initial admin state – an indication of the desired (start-up)
state of the RF (either “locked” or “unlocked”)
• Name - user friendly designation for the RF
• Description - descriptive text for the given RF

• SAP information (location, connectivity and bandwidth

requirements)
• Internal details of the Resource Function, e.g., references to
existing entities to be used such as component Resource
Functions, resource functions and internal connectivity
among the components. It is also possible to request the
creation of new components to be used in the RF (this is
referred to as "reference by value"). This can be a partial list
(i.e., not all the components needed in support of the RF),
with other aspect being left to the Resource Function
Provider (RFP).
o This could involve a step beforehand to update the
components so that they could be used in the given
Resource Function, or possibly the RFP could do this
automatically.
o For each internal component, one may provide a
location and role (if need be)
of Resource Function). It gives an indication to the RFP of
the importance of the given request. The RFP can preempt
lower priority Resource Functions in fulfilling a request for a
higher priority Resource Function. Specific actions to be
taken depend on the Resource Function and prior
agreement between the RFC and RFP.
• Schedules – a list of schedule / Resource Function pairs
where each pair indicates that the Resource Function is to
be put in the desired (specified) configuration at each point
in the schedule. It is typical to only specific values for a
subset of the Resource Function, e.g., could just be the
admin state that is modified on a given schedule.
• Auto-modification – a list of the kinds of auto-modification
that are to be applied to the Resource Function.
• Location (aka "Place" in the APIs) – the desired location of
the RF. This may not be useful in the case of a distributed
RF. In such cases, the location of the RF components and/or
SAPs may be more useful.
• Characteristics specific to the given type of Resource
Function, e.g., storage requirements and compute
requirements. As noted in Section 3.2.4, capacity (or
scaling) attributes are one category of attributes to be
considered.
Output parameters:

• The Resource Function is returned to the RFC. The RFC

may subsequently retrieve the structures for the components
comprising the Resource Function.
requested, e.g., some of the referenced components in the
request might not be used.
Source
4.1.3. Modify Resource Function: intent-based
Modify The Interface shall support the capability for a Resource Function
Resource Consumer (RFC) to request the modification of an existing
Function: Resource Function via an intent-based operation. The operation is
intent-based not idempotent, i.e., if the RFC requests that an RF be put into to a
state / configuration in which it already is, then an exception
should be returned.
Input parameters:
• Identifier of the RF to be modified (E)
• Admin state modification – to either “locked”, “unlocked” or
“shutting down” (as defined in ITU-T Rec. X.731)
• SAP modification
o Identifiers of SAPs to be removed from the RF
o Information concerning SAPs to added to the RF
o Information concerning existing SAPs to be modified
• Priority – this is an integer from 1 to N (N may vary per type of
Resource Function). It gives an indication to the Resource
Function. Specific actions to be taken depend on the Resource
Function and prior agreement between the RFC and RFP.
• Schedules – a list of schedule / Resource Function pairs where
each pair indicates that the Resource Function is to be put in
the desired (specified) configuration at each point in the
schedule. This overwrites (replaces) the existing set of
schedules (if any).
• Overall characteristics

o Modification of the values for characteristics that have

already been set with respect to the given RF
o Adding / assigning new characteristics to the given RF
• Feature Groups can be added, removed (if they are optional)
and the associated characteristics can be modified
• Features can be added, removed (if they are optional) and the
associated characteristics can be modified
Output parameters:
• An indication of success or failure is provided. In the case of
success, the structure for the modified Resource Function is
returned.
requested, e.g., only some of the requested SAP removals
were successful.
Source
4.1.4. Modify Resource Function: detailed-based
Modify The Interface shall support the capability for a Resource Function
Resource Consumer (RFC) to request the modification of an existing
Function: Resource Function via a detailed-based operation. The operation
detailed- is not idempotent, i.e., if the RFC requests that an RF be put into to
based a state / configuration in which it already is, then an exception
should be returned.
Input parameters:
• Identifier of the RF to be modified (E)
“shutting down” (as defined in ITU-T Rec. X.731)
• SAP modification
o Information concerning SAPs to added to the RF
o Information concerning existing SAPs to be modified
o Modifications to the internal details of the Resource
Function
 Adding components – such components may first
need to be modified before they can be used in
the given RF (this is a possible step before the
modify RF is requested or the Resource Function

Provider (RFP) could automatically adjust the

referenced component). If the components
already exist, they are just referenced by Id. It is
also possible to request the creation of new
components to be used in the RF modification
(this is referred to as "reference by value"). For
each added component, one may provide a
location and role (if need be).
 Removing components
 Modifying components - in addition to modifying
the attributes of a component, one may change
the location and/or role.
o Priority – this is an integer from 1 to N (N may vary per
type of Resource Function). It gives an indication to the
RFP of the importance of the given request. The RFP
can preempt lower priority Resource Functions in
fulfilling a request for a higher priority Resource
Resource Function and prior agreement between the
RFC and RFP.
o Schedules – a list of schedule / Resource Function pairs
where each pair indicates that the Resource Function is
to be put in the desired (specified) configuration at each
point in the schedule. This overwrites (replaces) the
existing set of schedules (if any). – this allows the RFC
to either replace the existing schedule for an RF, or
apply a schedule to the RF, if the RF does not yet have a
schedule.
o Completion mode – either “best effort” or “atomic”
o Characteristics
 Modification of the values for characteristics that
have already been set with respect to the given
RF
 Adding / assigning new characteristics to the
given RF
Output parameters:
• An indication of success or failure is provided. In the case of
success, the structure for the modified Resource Function is
returned.
• For intent-based, the internal details of the Resource Function
are not provided. For best-effort, it is possible to get less than
what was requested, e.g., only some of the requested new
SAPs are added.

Source
4.1.5. Terminate Resource Function: intent-based
Terminate The Interface shall support the capability for a Resource

Resource Function Consumer (RFC) to request the termination of an
Function: existing Resource Function via an intent-based operation. The
intent-based operation is considered to be atomic (all or nothing). The
Resource Function Provider (RFP) decide what, if any, of the
components from the RF to retain.
Input parameters:
• Identifier of the RF to be terminated (E)
Output parameters:
• An indication of whether or not the operation was successful
(E)
Source
4.1.6. Terminate Resource Function: detailed-based
Terminate The Interface shall support the capability for a Resource

Resource Function Consumer (RFC) to request the termination of an
detailed-based operation may be either atomic or best effort.
Input parameters:
• Identifier of the RF to be terminated (E)
• Identifiers of the components to be retained after the RF is
terminated. Other components (not in the retain list) are
retained or not based on the policies of the RFP.
Output parameters:
• An indication of whether or not the operation was
successful (E). In the case of best effort, only some of the
identified components to be retain may actually be retained.
Source
4.1.7. Subscribe to Resource Function Notifications

Subscribe to The Interface shall support the capability for a Resource

Resource Function Function Consumer (RFC) to subscribe to Resource
Notifications Function notifications (creation, modification and/or
termination)
Input parameters:
• Id[s] of the RF to which the RFC wants to subscribe
(E)
• Filter to be used by the RFP to identify which
notifications need to be sent or which are not to be
sent to the given subscriber
Output parameters:
• Success/failure message – the message, that
subscription to Resource Function[s] is successful or
not, is returned to the RFC.
Source
4.2. Resource Function -

Advanced Operations
This section contains more advanced and specialized operations for resource
functions.
4.2.1. Resource Function Healing
Resource The Interface shall support the capability for a RFC to request that
Function an RFP heal an RF. This can be done via a single RF heal
Healing request that references a predefined script to be executed by the
RFP, or the heal can be accomplished via several RF modify
requests. This is also a candidate for policy-based rule exchange
across (a dynamic API feature).
In the case of the single heal request:
Input parameters:
• Identifier of the RF to be healed (E)
• Heal action: this is basically a pointer to a pre-defined script,
e.g., “Return RF to default configuration”, “Return RF to a
restore point” (this would require identification of the restore
point)

• Heal policy: minimize network latency for the RF, minimize

cost, location (if the RF needs to be move to perhaps a sub-
optimal location), etc.
• Cause: a reason for why the heal is being requested (e.g.,
customer complaint)
• Start time
• Healing parameters: specific parameters that may be needed
to qualify the heal request
Output parameters:
• Heal status: An indication of the status of the heal. In some
cases, the heal process may that some time and the
associated heal status may change. In such cases, the RFC
may retrieve the current heal status.
• In any case, the RFC may want to retrieve the Resource
Function and its components to see what modifications have
been made, if any.
Source
4.2.2. Scale Resource Function
Scale The Interface shall support the capability for a RFC to request that
Resource an RFP scale an RF to a desired level.
Function In the case of the single heal request:
Input parameters:
• Identifier of the Resource Function to be scaled
• Aspect- an indication of what aspect of the Resource Function
is to be scale, e.g., a vCDN Resource Function might have
aspects such as quick access memory for frequently used
content.
• Direction of the scale (i.e., up or down) and the number of
scaling steps [Editor's note: this could be done with a single
integer. For example, 2 means "two steps up" and -3 means
"three steps down."]
• Characteristics - in some cases, specific characteristics (and
associated values) may need to be provided for specific type
of scale and perhaps on a per aspect basis.
• Schedule for the scale (if not provided, the scale is to be done
immediately) - this can be used to defer the scale to a later
point in time (either once or several times). In cases where

multiple scales are requested on some schedule (e.g., scale-

up aspect Z by two steps every Tuesday at 2 AM), there would
typically need to be another operation that scales back the
Resource Function (for the given example, scale-down aspect
Z by two steps every Tuesday at 6 AM).
Output parameters:
• An indication of whether or not the operation was successful.
In some cases, the scaling process may that some time and
the associated scale status may change. In such cases, the
RFC may retrieve the current scale status.
• In any case, the RFC may want to retrieve the Resource
Function and its components to see what modifications have
been made, if any.
Source
4.2.3. Migrate Resource Function: intent-based
Migrate The Interface shall support the capability for a Resource

Resource Function Consumer (RFC) to request the migration of an
intent-based operation is not idempotent, i.e., if the RFC requests that an RF
be put into to a state / configuration in which it already is, then
an exception shall be returned.
Input parameters:
• Identifier of the RF to be migrated (E)
“shutting down” (as defined in ITU-T Rec. X.731). This is the
desired state of the RF after the successful migration.
• SAP Information
o Information concerning SAPs to added to the RF and
desired location information.
of Resource Function). It gives an indication to the Resource

Resource Function and prior agreement between the RFC

and RFP.
• Start Time – if the migration is not to start immediately, this
parameter is used to indicate a future date / time for when to
start the migration.
• Location – this is a reference to an object that specifies the
desired location of the migration. This pertains to the overall
location for the RF (e.g., new data center).
• Characteristics
o Adding / assigning new characteristics to the given
RF.
Output parameters:
• An indication of whether or not the operation was successful.
In some cases, the migration process may that some time
and the associated migration status may change. In such
cases, the RFC may retrieve the current migration status,
e.g., Stalled - Manual Intervention Required.
requested, e.g., only some of the SAPs have been migrated.
Source
4.2.4. Migrate Resource Function: detailed-based
Migrate The Interface shall support the capability for a Resource

Resource Function Consumer (RFC) to request the migration of an existing
Function: Resource Function via a detail-based operation. The operation is
intent-based not idempotent, i.e., if the RFC requests that an RF be put into to
a state / configuration in which it already is, then an exception
should be returned.
Input parameters:
• Identifier of the RF to be migrated (E)
“shutting down” (as defined in ITU-T Rec. X.731). This is the
desired state of the RF after the successful migration.
• SAP Information


o Information concerning SAPs to added to the RF and
desired location information.
• Modifications to the internal details of the Resource Function
during migration
o Adding internal components – such components may
first need to be added during migration (this is a
possible step could be applied Resource Function
Provider (RFP) during migration of Resource
Function).
 Desired location for new components
o Removing internal components
o Modifying internal components - can entail new
location.
of Resource Function). It gives an indication to the RFP of
the importance of the given request. The RFP can preempt
lower priority Resource Functions in fulfilling a request for a
higher priority Resource Function. Specific actions to be
taken depend on the Resource Function and prior agreement
between the RFC and RFP.
• Schedule – this allows the RFC to either replace the existing
schedule for an RF, or apply a schedule to the RF, if the RF
does not yet have a schedule.
• Characteristics
o Adding / assigning new characteristics to the given RF
Instance Information
o
 Current instance information of RF (Context
variables and parameters) for continuity of
service.
Output parameters:
• An indication of whether the operation was successful. In
some cases, the migration process may that some time and
the associated migration status may change. In such cases,
the RFC may retrieve the current migration status, e.g., In
Progress.


requested, e.g., only some of the components of the
Resource Function are migrated.
Source

5. Information Model R17.5
5.1. Overview
The details for the Resource Function class are provided in the section below.
The background and details for the Resource Function Specification class are provided
in the TR255B.

Resource Function is covered in GB922 Logical and Compound Resource Computing
and Software. However, some of the attributes listed below have not yet (as of R17.5)
not been added to the SID model.
5.2.1. Attributes
The attributes listed below have been identified as being needed for Resource
Function as a result of an analysis of the use cases in this document.
name datatype properties description

id Integer • Multiplicity The id of the resource
is 1 function generated at
• mandatory the time of provisioning.
It is to be used when
retrieving the resource
function for performing
other operations on it
e.g. scale, migrate
name String • multiplicity User friendly moniker for
is 1 the resource function
• optional
href String • multiplicity reference of an entity

is 1
• optional
description String • multiplicity A statement concerning

• optional
• AVC
enabled

sAP SAP • multiplicity The Service Access

is 1..* Points (SAPs) of the
• mandatory resource function
Several SAPs are
• AVC
related to the resource
enabled
function via aggregation.
priority Integer (1 • multiplicity The gives a measure of

to N) is 1 the importance of the
• mandatory resource function
relative to other
resource functions. It
can be used, for
example, to make sure
that high priority
resource functions (e.g.,
national security,
medical emergency) are
given preference over
lower priority resource
functions.
The value of N is
defined in the catalog
item for the given
resource function type.
schedule Array • multiplicity A list of schedule /
is * resource function pairs
where each pair
• optional
indicates that the
• AVC resource function is to
enabled be put in the desired
(specified) configuration
at each point in the
schedule. It is typical to
only specific values for a
subset of the resource
function, e.g., could just
be the admin state that
is modified on a given
schedule.
autoModification List of • multiplicity This is a list of the kinds
String is * of auto-modification that
are applied to a given
• optional
resource function.


• AVC
enabled
role String • multiplicity This attribute is used

is 1 when the resource
• mandatory function is a component
of a composite resource
• AVC function and it is not
enabled clear from the descriptor
/ specification and
location information how
the given resource
function fits into the
composite.
Further, it should be
noted that a resource
function can be shared
(be a component of)
several composites.
Thus, it is possible for a
given resource function
to play several roles at
the same time.
characteristic Any • multiplicity This is for the type-
is * specific attributes of the
resource function.
• optional
• AVC
enabled
type String • Multiplicity The type/category of the

is 1 resource function
• mandatory
version String • Multiplicity To be used for

is 1 identifying upgrades to
the resource function
• optional
location Object • Multiplicity The desired location of

• optional

state Enum • Multiplicity Possible values are

is 1 planning, installing,
• mandatory operating and retiring
substate String • Multiplicity Each of the states may

is 1 have a qualifying
substate. Possible
• optional
values for this string are
defined in Section 3.2.7
of this document.
connectivity Adjacency • Multiplicity Defines an adjacency
Graph as is 1 graph among Resource
defined Functions (RFs) within a
• mandatory
TR255A composite RF
See the detailed
discussion on
connectivity in TR255A.
relatedParty Reference • Multiplicity This can be used to (for
to Related is 1 example) indicate the
Party consumer that owns the
• optional
RF or a management
entity responsible the
RF.
resourceFunctionSpecification Reference • Multiplicity This is a reference to the
to a RF is 1 RF spec from which the
Spec • mandatory RF was created.
supportingResourceFunction Resource • multiplicity This is a list of

Function is * composite and atomic
resource functions from
• optional
which this resource
function is composed.
These are all the
vertices of the adjacency
graph (noted in the
connectivity attribute).
The type/category of the resource function

6. Notifications R17.5
6.1. RF Notifications
The following requirements apply to RFs:
1. It shall be possible to generate a notification when an RF is created.
2. It shall be possible to generate a notification when an RF is modified.
a. The modify notification is to be used to report on modifications related to
scaling, healing and migration. The need for separate scale, heal and
migration notifications is for further study.
b. The modify notification is to be used to report on state changes for an RF.
3. It shall be possible to generate a notification when an RF is terminated.
4. Via an implementation agreement, it shall be possible to limit notifications for
composite RF.
a. This is needed to prevent notification storms for complex RFs (e.g., virtual
routers) that have many components. In such cases, it may be desirable to
only report on the composite RF and allow the consumer to retrieve details
concerning the components via an inventory request.
5. It shall be possible for consumers to subscribe to lifecycle notifications (i.e., create,
modify and terminate) for RFs.
6.2. RF Specification
Notifications
The following requirements apply to RF specifications:
1. It shall be possible to generate a notification when an RF specification is created.
2. It shall be possible to generate a notification when an RF specification is modified.
3. It shall be possible to generate a notification when an RF specification is
terminated.
4. It shall be possible for consumers to subscribe to lifecycle notifications (i.e., create,
modify and terminate) for RF specifications.

7. Service Interfaces R17.5
The details of the services interfaces are recorded as Swagger schemas and can be
found at the following URL:
https://app.swaggerhub.com/apis/tmforum/ResourceFunctionProvisioningAPI/1.2.0

8. Open Issues and Future Work R17.5
The following open issues and possible future work have been identified:
1. Security for the API and associated operations needs to be addressed. A general
solution for all the TM Forum APIs is recommended.
2. The relationship between the provisioning requests in this document and both
service and resource orders needs to be studied further.

9. Glossary R17.5
The following is a list of a few key terms used in TR255. A more comprehensive list of
terms can be found in TMF071 Terminology for Zero-touch Orchestration, Operations
and Management.
Term Definition Source

Connection a Resource Function (RF) that TR255A
Point does termination processing
(sometimes related to connectivity.
Termination
Point)
Connection is used to describe the GB922_Logical_and_Compound_
Point Spec information/data input to a Resource_Computing_and_Softw
ResourceFunctionSpec or are_R17.0
output from a
ResourceFunctionSpec.This
description is captured
independently from the way it is
realized.
SoftConnectionPointSpec and
ElectronicConnectionPointSpec
are realization of Connection
Points either as software
Programming Interfaces (API)
or as Electronic interface
(signal processing).
Detailed- In this approach, the consumer TR255
based can potentially provide all the
details (regarding constituent
components) for a given RF
instantiation, down to the level
of virtualized storage, compute
and network in the
infrastructure (if desired). The
required information in the
creation request is of the form
Feature (TM Forum) An RF exposes its TR255B, ONAP
capabilities to consumers via
features.
• Unlike an RF, a feature
cannot be independently
deployed.


• Some feature may be
mandatory while others can
be selected or not by the
consumer (for a given
instantiation).
• Features may have
characteristics which are
settable by the consumer
(at instantiation time and/or
during the lifetime of the
RF).
• Composite RFs do not
necessarily (directly)
expose the features of the
constituent RFs. In such
cases, the composite RF
can abstract, rearrange,
and reformulate and
augment the features of the
constituent RFs.
(ONAP) The selectable
capabilities (functionality) of the
software. Some may be
optional or required.
Feature is a collection of Features. TR255B
Group
Function A mechanism that transforms Inspired from Wikipedia and
inputs and generates outputs. deliberately kept very simple
Hosting is used to represent the GB922 Logical and Compound
Platform common characteristics and Resource Computing and
Requirements associations of resources in the Software R17.0.0
Spec infrastructure (e.g. compute,
storage, network).
Identifier A single UUID be used as the TR224
immutable, globally unique
identifier for every Entity in the
management model. Where
possible, these identifiers
should also be stored in the
actual network elements.
Where there are parts of an
Entity and a separate UUID is
not desired, then a compound
identifier comprising the parent


UUID with a single contextual
identifier can be used.
• For example, if we had a
two-ended Link (with ‘A’ and
‘Z’ ends, then the LinkEnd
identifiers could be
UUID+’A’ and UUID+’Z’). If
a contextual identifier is
used, then the model needs
to have a mandatory
composition relationship
from the entity with the
UUID to the entity with the
contextual identifier.
Installed consists of encoded GB922 Logical and Compound

Software information or computer Resource Computing and
instructions deployed on a Software R17.0.0
machine such that it can be
executed.
An InstalledSoftware is a
SoftwareSpecification deployed
using the
SoftwareSupportPackage and
HostingPlatformRequirements.
Intent-based In this approach, the consumer TR255
of a given Resource Function
(RF) declares what they require
but not how to accomplish the
task.
Name In TR224, "Name" is not TR224
defined but several
characteristics of Name are
provided, i.e.,
• That we provide for many
names, by having a Set of
names for an Entity.
• Because names can’t be
guaranteed to be globally
unique, each name will
have its context (scope)
stored with it.


• A name should be unique
within its defining context.
• It should also have a
reference to its naming
authority.
Network Slice Network slice is a logical IG1152

network serving a defined
business purpose or customer,
consisting of all required
network resources configured
together. It is created, changed
and removed by management
functions.
• End-to-end within a provider
• Enabler for services, not a
service
• Mobile and fixed
• Resources may be physical
or virtual, dedicated or
shared
• Independent / Isolated but
may share resources
• May integrate services from
other providers, facilitating
e.g. aggregation and
roaming
Open API Open APIs which are the units TR262

of interoperability that realize
Platform Capabilities and can
be conformance and
interoperability tested.
Open APIs Open APIs are the units of TR262
interoperability that realize
(in context of
Platform Capabilities, and can
Platform
Capabilities) be conformance and
interoperability tested.
Platform Instances are units of TR262
deployment defined by
enterprises using templates
defined by Standards Defining


Organizations (SDO), including
the TM Forum. They are 'Black
box like', can be Vendor /
Operator specific, allow for
internal evolution and
innovation, and whose
implementation can be agile
and flexible i.e. time varying.
Platform Platform Capabilities are TR262
Capabilities exposed by a Platform and are
the units of integration used to
create composed capabilities
from multiple Platform
Capabilities / Platforms.
Platform Capabilities define the
rules and best practices for
using the combination of Open
APIs used to realize them.
Resource specifies a function as a TR255
Function (RF) behavior to transform inputs of (adapted from GB922 Logical and
any nature into outputs of any Compound Resource Computing
nature independently from the and Software R17.0.0)
way it is provided. It is typically
created by a function designer
who may not have specific
knowledge on realization
architecture (for example using
English text explanations with
diagrams, as in RFC
standards, or preferably a
machine interpretable
language). NetworkFunction,
OfficeFunction as well as
GameFunction are examples of
specialization (of
ResourceFunction).
Examples of RFs from ETSI
NFV are VNF (an atomic RF)
and Network Service (a
composite RF).
Examples of RFs from IETF /
SDN are Service Function and
Service Function Chain.


Resource a specification for a type of
Function Resource Function.
Spec
Resource A collection of Resource
Slice Functions (RF) that are
assigned to a given consumer
(tenant) of a platform. The RF
instances may either be
dedicated to the consumer, or
in some cases, shared by
several consumers.
Service is a kind of RF that handles TR255A
Access Point access into and out of another
(SAP) RF (such as an application RF
or virtualized appliance RF)
Service Level A service-level agreement Wikipedia
Agreement (SLA) is defined as an official
(SLA) commitment that prevails
between a service provider and
a client. Particular aspects of
the service – quality,
availability, responsibilities –
are agreed between the
service provider and the
service user. The most
common component of SLA is
that the services should be
provided to the customer as
agreed upon in the contract. As
an example, Internet service
providers and telcos will
commonly include service level
agreements within the terms of
their contracts with customers
to define the level(s) of service
being sold in plain language
terms. In this case the SLA will
typically have a technical
definition in mean time
between failures (MTBF), mean
time to repair or mean time to
recovery (MTTR); identifying
which party is responsible for
reporting faults or paying fees;
responsibility for various data


rates; throughput; jitter; or
similar measurable details.
Software In software engineering and Wikipedia
Factory enterprise software
architecture, a software factory
is a software product line that
configures extensive tools,
processes, and content using a
template based on a schema to
automate the development and
maintenance of variants of an
archetypical product by
adapting, assembling, and
configuring framework-based
components.
Since coding requires a
software engineer (or the
parallel in traditional
manufacturing, a skilled
craftsman) it is eliminated from
the process at the application
layer, and the software is
created by assembling
predefined components instead
of using traditional IDE's.
Traditional coding is left only
for creating new components or
services. As with traditional
manufacturing, the engineering
is left to creation of the
components and the
requirements gathering for the
system. The end result of
manufacturing in a software
factory is a composite
application.
Software represents the package GB922 Logical and Compound
Support acquired by a consumer from a Resource Computing and
Package software vendor. It can be Software R17.0.0
materialized as one or several
files (data) downloaded online
or copied on a physical
support. It contains all files
required for deployment and
installation such as installation
manager and at minimum, one


of the files constitutes the set of
machine readable instructions
that will be executed
automatically after it is
installed.
Software specifies properties or GB922 Logical and Compound
Specification associated information that Resource Computing and
characterizes a software, such Software R17.0.0
as:
• the release number, the
status of the release,
license conditions...
• hosting platform
requirements such as OS,
disk and memory space...
• input and output
configuration and
requirements
• includes all files required for
deployment and installation
such as installation
manager.
Topology an arrangement of resource TR255A

functions (not necessarily
connected to each other) that
represent a particular
viewpoint.

10. 10 Administrative Appendix TR255 R17.5
10.1. Document History

10.1.1. Version History
The document was edited on Confluence after Release 1.0.0 and it is not easy to
indication versions on Confluence. So, for subsequently releases there is just one
change log for the release.
Release 1
Version Date Modified by: Description of changes

Number Modified
0.1 to 0.7 November Stephen Fratini Initial creation of document
and Input of material for review concern
December
network service provisioning
2015
0.8 4 January Stephen Fratini Added use case on NS healing
2016 using input
from Masanori
Miyazawa
0.9 11 January Stephen Fratini Added NF create and modify use
2016 using input cases from Atif
from Syed Atif
Husain
0.10 18 January Stephen Fratini Incorporated input from Atif
2016 using input (requirements for NF create and
from Atif and modify) and from Babu Pawar (use
Babu cases of NF terminate and
notifications)
0.11 10 February Stephen Fratini Added definition for atomic and best
2016 effort execution of an operation
Added an “E” next to a very few
parameters in Section 4
Clarified the auto-modification
parameter in the requirements
Added another possible NS Heal
action, i.e., “Return NS to a restore
point”
Noted that for NS and NF termination,
it is up to the provider as to whether
the components are also terminated
(with the exception of explicit requests


Number Modified
from the consumer to retain specific
components)
0.12 3 March Stephen Fratini Many editorial updates and corrections
2016 using input based on review by Cliff Faurer
from Nigel, Cliff Added requirements subsections (from
and Atif Atif) on NF termination (intent and
detailed based) and NF notification
subscription
Added a requirements subsection NS
notification subscription
Added Section 3.2.5 on Infrastructure
Connectivity (from Nigel)
Added Section 3.19 on Create
Infrastructure Connectivity (from Nigel)
0.13 17 March Stephen Fratini Added note about inventory/query
2016 being needed in support of entity
provisioning but not being covered in
this document
Populated Section 5.2 concerning the
info model for Network Function
Added open issue concerning heal for
NFs (from Yuval)
Add Option 3 (the NSC can pinpoint
the affected service, but it does not
have the knowledge of how to fix it) to
the NS heal use case (from Yuval)
Added NS Migrate use cases (from
Abinash)
Added NS Migrate requirements (from
Abinash)
Add a location parameter to the create
NS and NF requirements
0.14 8 April 2016 Stephen Fratini Added service state model from
TMF640 to Section 3.2.7
Added reference to MTOSI enhanced
resource state model in Section 3.28
Add some terms to the previously
empty Glossary


Number Modified
Added common exceptions to all the
use cases (based on the TIP common
exceptions)
1.0.0 9 May 2016 Alicja Kawecki, Updated cover, minor formatting/style
TM Forum edits prior to publication for Fx16
Change Log for Release 2

• (20 July 2016 - Stephen Fratini) Modified Sections 3.4., Create Network Service:
detailed-based and 3.6., Modify Network Service: detailed-based, to indicated that
the components (other NSs or NFs) can be referenced by Id (i.e., they already
exist) or by value (i.e., they do not yet exist and need to be created). Release 1.0 of
TR255 only allowed for “reference by Id.” Associated changes were also made in
Sections 4.1.2., Create Network Service: detailed-based, and 4.1.4. Modify
Network Service: detailed-based.
• (20 July 2016 - Stephen Fratini) Noted in both Section 3.3., Create Network
Service: intent-based, and 3.4., Create Network Service: detailed-based, that it is
possible assign policies to an NS. Did not make a similar change to the Create NF
operations since no policies have yet been identified for the NFs.
• (29 August 2016 - Stephen Fratini) Added support for scaling
o Updated Section 3.2.4 to explain when scaling is used versus when
modification is used. In Release 1, it was decided that modification would
cover scaling but this decision was changed for Release 2 (based on the
joint ZOOM / API session during action week in Vancouver, July 2016).
o Added Section 3.21 on Scale NS use case
o Added Section 3.22 on Scale NF use case
• (1 September 2016 - Stephen Fratini) Replace Section 3.23 (in v1) concerning
bundling of operations, with a more general section on the relationship between
entity provisioning and ordering (with bundling as one aspect of ordering)
• (14 September 2016 - Balamurugan Amirthalingam) Modified Network State model
diagram as per the Generic Entity State model.
• (15 September 2016 - Stephen Fratini) Added Retain Components when
Terminating an Entity
• (19 September 2016 - Stephen Fratini) Added Name and Description parameters to
NS create and NF create operations.
• (22 September 2016) - Stephen Fratini) Added combined (service / resource) state
model to Section 3.2.7 (based on contribution that was discussed and agree on
Blue stream call on 21 September 2016).
• (7 October 2016 - Stephen Fratini) Based on comments from Milind Bhagwat,
made some fixes to the migration NS operation (added location to SAP and also to
the components in the detailed version of the operation)
• (19 October 2016 - Stephen Fratini)

o Multiple updates to indicate that only the NS or NF identifier is returned in

the response to a create or modify operation. The consumer can retrieve
the entire structure in a subsequent request if need be.
o Added Role attribute for the components in a composite NS or NF.
o Added a desired NS (or NF) configuration in conjunction with the schedule
in create and modify operations
• (8 November 2016) - Stephen Fratini)
o After talking with milind bhagwat, needed to change the output for the
various create and modify operations since the pattern used by the API
project is to return the entire structure. However, if the consumer wants the
structures for the components within the composite, a query is needed.
• (15 November 2016) - Alicja Kawecki)
o Updated cover, minor formatting/cosmetic edits prior to publication for
Fx16.5.
Release 3
Version Date Modified Description of changes
Number Modified by:
0.1 14 Feb Stephen Incorporated contribution entitled "Instantiation
2017 Fratini Options for Composite Entities" v7 (see JIRA
itemZOOM-174 - Authenticate to see issue
details ), as discussed and agreed during the
TM Forum action week in Cascais, Portugal
(February 2017). The contribution was insert
(with some editorial modifications) into Section
3.2.1.
Also, as agreed during the action week noted
above, the document title has been changed to
Provisioning for Resource Functions.
0.2 20 April Stephen Many small changes in Sections 1, 2 and 3 to
2017 Fratini reflect the replacement of Network Service and
Network Function with the new Resource
Function concept in TR264.
0.3 25 April Michel Many small changes in Sections 4.2 and 4.2 to
2017 Besson reflect the replacement of Network Service and
Network Function with the new Resource
Function concept in TR264
Removed section 4.3.
0.4 circa 25 Syed Atif Updated Section 5 to reflect new terminology
April 2017 Husain (i.e., Resource Function)
0.5 30-31 Stephen Updates to align Section 5 with Resource
May 2017 Fratini Function in the associated API spec, i.e.,
TMF664

Version Date Modified Description of changes

Number Modified by:
0.6 05 July Alan Corrected reference to TMF664 in Introduction
2017 Pope
0.7.0 11 July Alicja Minor formatting/style edits prior to publication
2017 Kawecki for Fx17
0.7.1 17 Nov Adrienne Updated to reflect TM Forum Approved Status
2017 Walcott
0.7.2 20 Nov David Comments and several type / wording fixes
2017 Milham
0.7.3 21 Nov Stephen Many small updates to address comments from
2017 Fratini Dave Milham
0.7.4 28 Dec Adrienne Formatting/style edits prior to publishing
2017 Walcott
0.7.5 06 Apr Adrienne Updated to reflect TM Forum Approved Status
2018 Walcott
10.1.2. Release History
Release Date Modified by: Description of changes

Number Modified
16.0.0 8 April 2016 Stephen Description e.g. first issue of
Fratini document
16.5.0 November Stephen R16.5
2016 Fratini
17.0.0 May 2017 Stephen R17.0
Fratini
17.0.1 November Adrienne Updated to reflect TM Forum
2017 Walcott Approved Status
17.5.0 December Stephen R17.5
2017 Fratini
17.5.1 06 Apr 2018 Adrienne Updated to reflect TM Forum
Walcott Approved Status

10.2. Acknowledgments
10.2.1. Release 1.0
This document was prepared by the members of the TM Forum ZOOM Foundations
Interfaces sub-team:
• Stephen Fratini, Ericsson, Editor and ZOOM Blue stream co-leader
• Syed Atif Husain, Infosys
• Masanori Miyazawa, KDDI R and D Laboratories, Inc.
• Babu Pawar, Tech Mahindra
• Cliff Faurer, EnterpriseWeb
• Nigel Davis, Ciena
• Yuval Stein, TEOCO
• Abinash Vishwakarma, Netcracker Technology
Additional input was provided by the following people:

• Dave Milham, TM Forum
• Jean-Marie Calmel, Alcatel-Lucent
• Tayeb Ben Meriem, Orange
• George Glass, BT
• Milind Bhagwat, BT
10.2.2. Release 2.0

• Stephen Fratini, Ericsson, Editor and ZOOM Blue stream co-leader
• Balamurugan Amirthalingam, Infosys
Additional input was provided by the following people:

• Pierre Gauthier, TM Forum
• Nigel Davis, Ciena
• Dave Milham, TM Forum
10.2.3. Release 3.0

• Stephen Fratini, Editor and ZOOM Blue stream co-leader
• Cecile Ludwichowski, Orange

• Syed Husain, Infosys

• Michel Besson, TM Forum
This Appendix provides additional background material about the TM Forum and this
document. In general, sections may be included or omitted as desired; however, a
Document History must always be included.

TR255 Resource Function Activation and Configuration R17.5.1 PDF

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

TR255 Resource Function Activation and Configuration R17.5.1 PDF

Uploaded by

Copyright:

Available Formats

TM Forum Technical Report

Latest Update: TM Forum Release 17.5.1 TM Forum Approved

TM Forum 2018. All Rights Reserved.

Copyright © TM Forum 2018. All Rights Reserved.

TM FORUM takes no position regarding the validity or scope of any intellectual

© TM Forum 2018. All Rights Reserved. Page 2 of 85

Direct inquiries to the TM Forum office:

4 Century Drive, Suite 100

© TM Forum 2018. All Rights Reserved. Page 3 of 85

© TM Forum 2018. All Rights Reserved. Page 4 of 85

4.1. Resource Function - Basic Operations ......................................................... 51

© TM Forum 2018. All Rights Reserved. Page 5 of 85

© TM Forum 2018. All Rights Reserved. Page 6 of 85

© TM Forum 2018. All Rights Reserved. Page 7 of 85

2. Conventions and Terminology R17.5.0

© TM Forum 2018. All Rights Reserved. Page 8 of 85

3. General Concepts and Use Cases R17.5

3.1. Use Case Template

Traceability Mapping to associated requirements

© TM Forum 2018. All Rights Reserved. Page 9 of 85

3.2. General Concepts

Case 1: Fully Intent-based

Mapping to Underlying Support

© TM Forum 2018. All Rights Reserved. Page 10 of 85

deployment scenario. Deployment scenarios and associated requirements are

Intent-based for Composite RFs

Case 2: Fully Detailed-based

Case 3: Flavor-based Approaches

© TM Forum 2018. All Rights Reserved. Page 11 of 85

© TM Forum 2018. All Rights Reserved. Page 12 of 85

Case 4: Mixtures of Cases 1, 2 and 3

Example 1: Mixture of Detailed-based and Intent-based

© TM Forum 2018. All Rights Reserved. Page 13 of 85

Example 2: Mixture of Detailed-based and Flavor-based (not recommended)

© TM Forum 2018. All Rights Reserved. Page 14 of 85

Mapping of Flavor-based Approach to Intent-based Approach

Deployment Flavor based Intent-based

This assumes that in the deployment

© TM Forum 2018. All Rights Reserved. Page 15 of 85

3.2.2. Dynamic APIs

3.2.3. Relationship to Orders

© TM Forum 2018. All Rights Reserved. Page 16 of 85

3.2.4. Scaling and Modification

3.2.5. Completion Mode

© TM Forum 2018. All Rights Reserved. Page 17 of 85

3.2.6. Infrastructure Connectivity

© TM Forum 2018. All Rights Reserved. Page 18 of 85

• A transform (processing) service where the intention is that “information is

© TM Forum 2018. All Rights Reserved. Page 19 of 85

• Note that creation / instantiation is actually just configuration of an existing

3.2.7. State Model

The states are defined as below.

© TM Forum 2018. All Rights Reserved. Page 20 of 85

The sub-states for the Operating phase are as follows:

© TM Forum 2018. All Rights Reserved. Page 21 of 85

The basic requires for scheduling are as follows:

3.2.9. Context or Role for Components in a Composite RF

3.2.10. Status of Tasks

© TM Forum 2018. All Rights Reserved. Page 22 of 85

3.3. Create Resource

Use Case Create Resource Function: intent-based

© TM Forum 2018. All Rights Reserved. Page 23 of 85

Use Case Create Resource Function: intent-based