A Generic Autonomic Deployment and Management Mechanism for Resource-based Network Services

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 availability and stability 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 guaranteed 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 network may provide different transmission services by putting the user packets into different processes that have different resources, such as bandwidth, queue length, priority, 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 occupation 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 information. 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 when, and only when, they appear in all capitals, as shown here.

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

| +-----------------+ +-----------------+ | RM ASA | | RM ASA | |Service Initiator| |Service Responser| +-----------------+ ASA Discovery +-----------------+ |----------------------------------->| | Authentication and Authorization | |----------------------------------->| | M_RESPONSE | |<-----------------------------------| | | | Multiple rounds Negotiation | |<---------------------------------->| | on Resource Availability | | | | reserve the local resource | | ... ... | Coordination with other RM ASAs | |<---------------------------------->| ... ... | Service Ending | |<---------------------------------->| | release resources ]]> Figure-1: generic procedures of autonomic deployment and management

The Service Initiator MAY first discover the relevant network 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 available for giving service condition, etc. The node discover methods can be pre-configured, outbound discover, path detection, etc. The Service Initiator SHOULD send out a GRASP Discovery message that contains a Resource Manager 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 Resource Manager Objective option SHOULD check its satisfaction 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 authorized. 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 Resource Manager 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 Resource Manager 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 Resource Manager 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. Resource Manager 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 Resource Manager 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. Resource Manager GRASP Objective allows multiple types of resources to be requested simultaneously. The Resource Manager Objective option is a GRASP Objective option conforming to the GRASP specification . Its name is "Resource Manager", 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 Resource Manager Objective option is described in the Concise Data Definition Language (CDDL) as follows: objective = ["Resource Manager", objective-flags, loop-count, ?objective-value] objective-name = "Resource Manager" objective-flags = uint .bits objective-flag ; as in the GRASP specification loop-count = 0..255 ; as in the GRASP specification The '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.

Figure-2: Format of autonomic-network-service-value-value service-type = 0..7 service-id = uint service-lifetime = 0..4294967295 ; in milliseconds service-tag = [ *service-tag-info] 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. The 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. The resource-requirement-pair describes the resource requirements and it is defined as Figure-3. Resource requirements of different types can be described in an objective option. The Resource Manager objective option supports multi-faceted resource requirements and negotiation. These resource requirements are all in pairs, described by resource type and resource value.

Figure-3: Format of resource-requirement-pair resource-type = 0..7 resource-value = uint

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 Responsers 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 process or path discovery methods.

| RM ASA | | RM ASA | | RM ASA | +--------+ +---------+ +---------+ +---------+ | SI | -------------------->| SR Node |-->| SR Node |-->| SR Node | +--------+ Transmit data +---------+ +---------+ +---------+ ]]> Figure-3: Negotiation procedure of a transmission service 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.

| | [[0,36732,3600000,[]][[0,8]]] | |<-------------------------------------------| | [[0,36732,3600000,[]][[0,8]]] | |------------------------------------------->| | Negotiation End (ACCEPT) | |<-------------------------------------------| ]]> Figure-4: an example of a negotiation process Figure-4 shows an example of a 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 Transmission Service and service-id is 36732. The service will last 3600 seconds and only ask for one kind of resource 10 Mbit/s bandwidth. 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: "Resource Manager" 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 "Resource Manager" 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 : Transmission Service 1 : Computing Service

IANA has set up the "resource-type" registry, which contains 4-bit value. 0 : bandwidth 1 : queue 2 : memery 3 : priority 4 : cache 5 : computing

Valuable comments were received from Michael Richardson and Brian Carpenter. Contributions to early versions of this document was made by Yujing Zhou.