TR255 Resource Function Activation and Configuration R17.5.1 PDF
TR255 Resource Function Activation and Configuration R17.5.1 PDF
TR255 Resource Function Activation and Configuration R17.5.1 PDF
Resource Function -
Activation and Configuration
TR255
Release 17.5.1
April 2018
Notice
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.
of intellectual property rights will at any time be complete, or that any claims in such list
are, in fact, Essential Claims.
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
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.
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.
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
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.
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.
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.
The API defined in this document (TR255) looks to support various aspects of dynamic
APIs (as noted in various subsections that follow).
• 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.
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.
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.
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 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.
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.
• In Progress
• Paused – Consumer Input Required
• Paused – Manual Intervention Required
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:
• Capacity Exceeded
• Duplicate (can only happen when the RFC selects the RF
identifier)
• Atomic Transaction Failure
• Already In Post Condition
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:
• Capacity Exceeded
• Duplicate (can only happen when the RFC selects the RF
identifier)
• Entity Not Found (with regard to referenced components)
• Atomic Transaction Failure
• Not In Valid State (with regard to referenced components)
• Object In Use (with regard to referenced components)
• Already In Post Condition
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
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:
• Capacity Exceeded
• Entity Not Found
• Atomic Transaction Failure
• Not In Valid State
• Object In Use
• Already In Post Condition
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
partially modified but is not in the state and configuration
requested by the RFC.
In case of failure: the resource function is not created.
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:
• Capacity Exceeded
• Entity Not Found (could apply to the RF or components
referenced in the request)
• Atomic Transaction Failure
• Not In Valid State (could apply to the RF or components
referenced in the request)
• Object In Use (could apply to the RF or components
referenced in the request)
• Already In Post Condition
End When The use case ends when the RFP responds to the RFC.
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.
Exceptions If the RFP is performing some action on the resource function
(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.
Applicable Common Exceptions:
• Entity Not Found
• Atomic Transaction Failure
• Not In Valid State
• Object In Use
End When The use case ends when the RFP responds to the RFC.
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
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.
Exceptions Applicable Common Exceptions:
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.
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
End When The use case ends when the subscribed NotfCs have received
the resource function modification notification.
Post-
Conditions
Exceptions Communication between the NotfP and some (or all) of the
NotfCs is “down”
Traceability
End When The use case ends when the subscribed NotfCs have received
the resource function termination notification.
End When The NotfP replies to the NotfC with an indication that the
subscription request has been successful.
Post-
Conditions
Exceptions Applicable Common Exceptions:
• Unable To Notify
• Filter Not Supported
• Already In Post Condition
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.
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
End When The use case ends when the RFP responds to the RFC.
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.
Exceptions Applicable Common Exceptions:
• Capacity Exceeded
• Entity Not Found
• Atomic Transaction Failure
• Not In Valid State
• Object In Use
• Already In Post Condition
Traceability
End When The use case ends when the RFP responds to the RFC.
Traceability
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.
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.
In case of partial success (e.g., best effort): the resource function
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
• Entity Not Found
• Atomic Transaction Failure
• Already In Post Condition
Traceability
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.
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
Output parameters:
Source
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 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. This overwrites (replaces) the existing set of
schedules (if any).
• Completion mode – either “best effort” or “atomic”
• Overall characteristics
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 best-effort, it is possible to get less than what was
requested, e.g., only some of the requested SAP removals
were successful.
Source
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)
• 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
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
Source
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
Output parameters:
• Success/failure message – the message, that
subscription to Resource Function[s] is successful or
not, is returned to the RFC.
Source
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)
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
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
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
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.
• For best-effort, it is possible to get less than what was
requested, e.g., only some of the SAPs have been migrated.
Source
Source
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.
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.
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.
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
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.
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.
Release 1
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
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