A Generic Autonomic Deployment and Management Mechanism
for Resource-based Network ServicesHuaweiNo.156 Beiqing RoadBeijing100095ChinaP.R. Chinazhouyujing3@huawei.comHuaweiNo.156 Beiqing RoadBeijing100095ChinaP.R. Chinadangjuanna@huawei.comBeijing University of Posts and
TelecommunicationsNo. 10 Xitucheng RoadHaidian District, BeijingBeijingChinashengjiang@bupt.edu.cnChina Mobile32 Xuanwumen West StreetBeijing100053ChinaP.R. Chinaduzongpeng@chinamobile.com
Operations and Management
ANIMAself-deployment, self-managementautonomic networkingThis document specifies an autonomic mechanism for resource-based
network services deployment and management, using the GeneRic Autonomic
Signaling Protocol (GRASP) defined in to
dynamically exchange the information among the autonomic nodes. It
supports the coordination and consistently operations within an
autonomic network domain. This mechanism is generic for most, if not
all, of kinds of network resources, although this document only defines
the process of quality transmission service deployment and management.
It can be easily extended to support network services deployment and
management that is based on other types ofnetwork resources.Traditionally, IP networks are based on the best-efforts model. The
IP layer does not reserve resources for upper-layer applications.
However, more and more emerging applications that require quality
services, such as video, VR, AR, and so on. They need supports from
steady network resources, such as bandwidth, queue, memory, priority,
computational resources, etc. On another side, from network side, more
and more generic services, such as quality transmission services,
in-network data cache services and computing services, etc., are
starting to be deployed so that networks can serve these
resource-consumption applications well. These network services are
strongly based on the availibility and steadibility of network
resources.To enable these resource-based applications and services, IETF have
developed many resource reservation mechanisms, such as RSVP that is mainly to reserve bandwidth only and
path-oriented, etc. However, most of them are mainly for reservation
during the deployment only and are rigid for dynamic adjustment.
Furthermore, most of them are dedicated for a certain type of network
resources.This document introduces an enhanced and extensible mechanism that
supports dynamically dispatching of network resources, using the GeneRic
Autonomic Signaling Protocol (GRASP) defined in
to dynamically exchange the information among the autonomic nodes. Its
dynamic adjust ability is mainly enabled by the negotiation ability
defined by .This mechanism is generic for most, if not all, of kinds of network
resources. It can be easily extended to support network services
deployment and management that is based on other network resources. It
can be used, but no limited, in below network services scenarios:Quality transmission services. The quality could means quaranteed
bandwidth, or jitter, etc. In order guarantee the quality of
transmission services, the network should reserve transmission
resource, particularly bandwidth or queues, on a selected path from
the ingress to the egress node. The dynamic resource dispatching
mechanism should ensure the consistent of reserved resources on all
the nodes in this path, particularly, when dynamic changes are
operated on this path.Difference transmission services. The netwowrk may provide
different transmission services by putting the user packets into
different processes that have different resources, such as
bandwidth, queue length, piority, etc. The results would be
different user experience in delay and jitter, or even packet lose
rate.In network cache/storage services.The network may provide cache
or storage service by memory in the network devices or attached
devices. The idle memory space is the resource that need to be
request and managed. The location or distance of the memory is also
relevant to user experience.Computing services. More and more spare computational resources
are from network providers. They may be idle computational cycles on
the network devices or deployed computational servers. The occuption
of these computational resources are time-sensitive. Also, the
location or distance of the computational resource is relevant to
user experience.Information services. In some scenarios, network may be the best
information provider. It may be the information are from or
generated by network itself. Or the network has the best location to
provide the infromation.The Autonomic Control Plane (ACP) and the
Bootstrapping Remote Secure Key Infrastructure (BRSKI) provide the secure precondition for this
mechanism.This document defines an Autonomic Resource Management Objective in
. Three new corresponding registries are defined in
. This document defines the process
of quality transmission service deployment and management in .The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP 14
and .This document uses terminology defined in .RM ASA: the Resource Manager ASA on an autonomic nodes. It manages
the local resources on the node, such as bandwidth, queue, memory,
priority, computational resources, etc. The RM ASA communicate with
other counterpart RM ASAs in order to dynamically dispatch network
resources within the autonomic network domain. This document assumes all
autonomic nodes have a RM ASA.Service Initiator: the autonomic node that initiates and manages a
network service. It requests and dynamically adjusts the resources of
this network service through its RM ASA. Normally, a network service
SHALL have one service initiator within an autonomic network domain.
However, multiple Service Initiators model MAY also operational if there
were good synchronous or coordinate mechanisms among them.Service Responser: the autonomic node that responses to the requests
from the Service Initiator. It receives the requests through its RM ASA,
checks or operates on its local resources, and responds the results to
the Service Initiator. Typically, a network service MAY involve multiple
Service Responser. The consistency among them are the responsibility of
the Service Initiator.This section describes the generic procedures of autonomic deployment
and management of the resource-based network services, as Figure1 shows.
The detailed implementation or internal algorithms of the
ResourceManager ASAs are out of scope of this document. This section
does not cover the specific details that depend on certain network
services or certain type of network resources. The prepositive operation
that indicates the Service Initiator to start the service deployment are
out of scope. The information or reasons that trigger the dynamic
service changes are also out of scope.The Service Initiator MAY first discover the relevant newwork nodes
according to the service setup in order to reduce the node range of
sending GRASP Discovery message . It may be all the nodes on a giving
path or nodes that have idle resource avaible for giving service
condition, etc. The node discover methods can be pre-configed, outband
discover, path detection, etc.The Service Initiator SHOULD send out a GRASP Discovery message
that contains a ResourceManager Objective option defined in , in which the network service is described. The
Discovery message SHOULD send to the reduced range nodes, by
abovementioned mechanism, or all nodes within the AN domain.A RM ASA that receives the Discovery message with the
ResourceManager Objective option SHOULD check its satification against
the service description. If meet, the node is a proper Service
Responser. It SHOULD respond a GRASP Response message back to the
Service Initiator.Defined in the section 2.5.5.1 of , the
Discovery message MAY combine with the below negotiation process, if
the rapid negotiation function has been enabled network wide. If the
rapid negotiation function has been disabled, the process would fall
back to the normal discovery-only process.In principle, any operations on resources MUST be authoried. The
Service Responser SHOULD check the authentication of the Service
Initiator and the authorization information for the operation it
requests. This document assumes all autonomic nodes within the AN
domain have been authenticated and their requested operations are
authorized, giving the Autonomic Control Plane (ACP) and the Bootstrapping Remote Secure Key
Infrastructure (BRSKI) has provided the
secure environment for this mechanism.After the discovery step, the RM ASA on the Service Initiator sends
a GRASP Request message with a ResourceManager Objective option, in
which the value of the requested resource is indicated.When the RM ASA on a Service Responser receives a subsequent
Request message, it SHOULD conduct a GRASP negotiation sequence, using
Negotiate, Confirm Waiting, and Negotiation End messages as
appropriate. The Negotiate messages carry a ResourceManager Objective
option, which will indicate the resource type and value offered to the
requesting RM ASA.During the negotiation, the RM ASA on the Service Responser will
decide at each step how much resource can be offered. That decision,
and the decision to end the negotiation, are implementation choices. A
resource shortage on the Service Responser may cause it to indicate
the existing available value within a ResourceManager Objective option
back to the Service Initiator. The Service Initiator might decide
whether to accept the request of the resource. If not, the RM ASA on
the Service Initiator MAY terminate the negotiation via Negotiation
End messages.Upon completion of the negotiation, the Service Responser reserves
its local resources. The Service Initiator may use the negotiated
resource after receiving synchronization message without further
messages.Normally, a network service SHALL have one service initiator within
an autonomic network domain. It is the Service Initiator's
responsibility to manage the service and coordinate among multiple
Service Responsers to ensure the consistent of reserved resources.After the process of automatic resource management mechanism, RM
ASAs are allowed to change and negotiate the resource requirements. In
the lifetime of network services, there may be many reasons that the
service has to be changed upon with its reserved resources.
ResourceManager ASA needs to be able to handle resource changes in a
timely manner to meet service requirements.During the renegotiation process, RM ASA on the Service Initiator
resends the service's resource requirements by using ResourceManager
GRASP Objective. RM ASA on the Service Responser receives the resource
negotiation message and makes the determination. If the resource
requirements are lower than those allocated or/and less lifetime than
previous, the Service Responser SHOULD directly confirm the
information and release the excess resources. If more resources or
lifetime are required, RM ASA on the Service Responser SHOULD treat it
as a brand-new request and make decision or further negotiation. The
bottom line is the Service Responser MUST allow the Service Initiator
fall back to previous allocated resource, both on volume and
lifetime.RM ASAs on the Service Responsers MUST NOT change existing resource
allocation until the new negotiation on resource changes is
complete.After the service is completed or expired, the reserved network
resources MUST be released so that network resources can be used more
efficiently. If the service lifetime expires, the Service Responser
MUST release its local resources and MAY send a Synchronization
message to the Service Initiator to notify the state change of its
local resources. If the Service Initiator wants to end the service
before the service lifetime expires, the Service Initiator MUST send a
negotiation message to the Service Responsers to request the network
resource to be changed to zero. Upon completion of the negotiation,
the Service Responser releases the resources occupied by the
service.This section defines the GRASP technical objective options that are
used to support autonomic resource management. ResourceManager GRASP
Objective allows multiple types of resources to be requested
simultaneously.The ResourceManager Objective option is a GRASP Objective option
conforming to the GRASP specification . Its name
is "ResourceManager", and it carries the following data items as its
value: the resource value. Since GRASP is based on CBOR (Concise Binary
Object Representation) , the format of the
ResourceManager Objective option is described in the Concise Data
Definition Language (CDDL) as follows:objective = ["ResourceManager", objective-flags, loop-count,
?objective-value]objective-name = "ResourceManager"objective-flags = uint .bits objective-flag ; as in the GRASP
specificationloop-count = 0..255 ; as in the GRASP specificationThe 'objective-value' field expresses the actual value of a
negotiation or synchronization objective. So a new objective-value named
autonomic-network-service-value is defined for Network Service
Auto-deployment as follows. The autonomic node can know that it is
serving Network Service Auto-deployment according to the objective-value
after receiving the GRASP message. The 'objective value' contains two
parts, one represents the information of the service itself, and the
other represents the requirements of resources.objective-value = autonomic-network-service-value; An
autonomic-network-service-value is defined as Figure-2.service-information = [ service-type, service-id, service-lifetime,
service-tag ]The combination service-type and the service-id MUST uniquely
represent a network service within the network. The uniqueness of the
combination service-type and the service-id SHOULD be guaranteed by an
allocation mechanism that is out of scope of this document.service-lifetime = 0..4294967295 ; in millisecondsThe allocation of resources MUST specify the lifetime. The
service-lifetime represents the usage time of the resources required by
the service.The service-tag contains other information that describes the
service. This information is not necessary, but will affect the policy
for RM ASA resource reservation.resource-information = [ resource-requirement-pair 1,
resource-requirement-pair 2, ... , resource-requirement-pair n ]Resource requirements of different types can be described in an
objective option. The ResourceManager objective option supports
multi-faceted resource requirements and negotiation. These resource
requirements are all in pairs, described by resource type and resource
value.resource-requirement-pair = [ resourcet-type, resval ]resource-type /= 0…16; requested or offered resource type,
such as bandwidth, queue, and priority.resval /= 1…1000000; If the restype is bandwidth, the value
ranges in Mbit/s; If the restype is latency, the value ranges in
microsecond; If the restype is jitter, the value ranges in
microsecond.The quality transmission service scenario is the most important
resource negotiation scenario. In this scenario, RM ASAs negotiate the
resource that will affect the transmission quality. The basic resource
is bandwidth and other types of resources such as queue can be
required at the same time.The autonomic deployment and management of the quality transmission
service includes the Service Initiator and the Service Resopnsers all
have RM ASA. The Service Initiator is the resource demander, which
ensures the connection of services through negotiation resources with
RM ASAs in the domain network. Service Responsers are the nodes which
packets are forwarded in the transmission scenario and Service
Initiator asks resource from them. These nodes can be discovered
through RM ASA discovery precess or path discovery methods.Figure-3 shows how RM ASAs negotiate resources and how
Service Initiator forwards packages. The RM ASA on the Service
Initiator negotiates resources with the RM ASAs on the Service
Responsers one by one.In the process of negotiation, Service Initiator negotiates
resources with Service Responsers and ensures resources enough. RM
ASAs are allowed to negotiate resources for multiple rounds. It often
happens that the network resources on one node cannot meet the
resources required by the service, but the service is willing to
reduce its resource requirements to ensure the successful deployment
of the service. The RM ASAs on the Service Responsers feedback the
maximum available resources using Resource Management Objectives in
the response message. The RM ASA on the Service Initiator changes the
resource requirements according to the specific requirements of the
received resources and services, to carry out the next round of
service negotiation.Figure-4 shows an example of negotiation process. In the
first negotiation round, RM ASA on the Service Initiator wants to get
resource from RM ASA on the Service Responsers. In this example, the
service type is TransimisionService and service-id is 36732. The
service will last 3600 seconds and only ask for one kind of resource
10 Mbit/s bandwith. So, the autonomic-network-service-value is
[[0,36732,3600000,[]][[0,10]]].When RM ASA on the Service Responser Node receives the message, if
the RM ASA thinks the network can offer this required resource, it
will response the ACCEPT. But if it does not meet the request, it will
give how much resource it can offer. In this example, the Service
Responser can offer 8 Mbit/s. The next step, RM ASA on the Service
Initiator needs to decide whether to change its resource requirements
according to the reply, and sends a next round negotiation. Then, RM
ASA on the Service Responser finds the new resource requirement, it
can meet. So, it will response ACCEPT. This is an example how ASAs
negotiate resources.The Service Initiator decides a coordinated value of resource and
negotiates with multiple Service Responsers that need to reduce the
locked resource. The Service Responsers reserve resources for service
according to the negotiation results. If the operation is successful,
the Service Responser reply success message to the Service Initiator.
If it fails, reply failure message to the Service Initiator. And the
Service Initiator will restart negotiation step.When the Service Initiator receives the success message from all
the Service Responsers, the service can start to transmit the
message.When the service is ended, it is the responsibility of Service
Initiator to release all reserved resources through the dialogue with
the RM ASA on the Service Responser. And if the service lifetime is
exceeded, the Service Initiator SHOULD also release reserved resource
although the Service Responsers may release the reserved resource by
themselves.It complies with GRASP security considerations. Relevant security
issues are discussed in . The preferred security
model is that devices are trusted following the secure bootstrap
procedure and that a secure Autonomic Control
Plane (ACP) is in place.This document defines a new GRASP Objective option names:
"ResourceManager" which need to be added to the "GRASP Objective Names"
registry defined by . And this document defines
a new registry tables "service-type" and "resource-type" under the
"ResourceManager" GRASP Objective. The following subsections describe
the new parameters.IANA has set up the "service-type" registry, which contains 4-bit
value. The service-type defines the type of service which is used to
describe the type of resource requirements.0 : TransimisionService1 : ComputingServiceIANA has set up the "resource-type" registry, which contains 4-bit
value.0 : bandwidth1 : queue2 : memery3 : priority4 : cache5 : computingValuable comments were received from Michael Richardson and Brian
Carpenter.