Internet-Draft An Autonomic Mechanism for Resource-base December 2021
Dang, et al. Expires 30 June 2022 [Page]
Workgroup:
ANIMA
Internet-Draft:
draft-ietf-anima-network-service-auto-deployment-00
Published:
Intended Status:
Standards Track
Expires:
Authors:
J. Dang, Ed.
Huawei
S. Jiang
Huawei
Z. Du
China Mobile
Z. Zhou, Ed.
Huawei

An Autonomic Mechanism for Resource-based Network Services Auto-deployment

Abstract

This document specifies an autonomic mechanism for resource-based network services deployment through the Autonomic Control Plane (ACP) in a network. This mechanism uses the GeneRic Autonomic Signaling Protocol (GRASP) in [RFC8990] to exchange the information among the autonomic nodes so that the resource along the service path can be coordinated.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on 30 June 2022.

Table of Contents

1. Introduction

With the network development, a class of services with resource requirements (such as bandwidth, queue, and priority) are already emerging, such as video, LR, VR, and so on. To ensure the normal operation of these services, the network needs to divide enough resources. An autonomous network must have an appropriate mechanism to negotiate the network resource.

From the network perspective, this kind of service has a source IP address and a destination IP address. Therefore, once the kind of service is delivered by a domain network, this service clearly has an access node and a departure node in the network. In an autonomic resources negotiation mechanism, the resources are being negotiated between the access node and departure node. The original purpose of this document was to validate the design of the Autonomic Networking Infrastructure (ANI) for a realistic use case. It shows how the ANI can be applied to negotiate the resource information for network service auto-deployment.

The goal of this document is to complete the resource-based self-adaptation among service and network nodes via GRASP. This document defines an autonomic technical objective for resource-based network services auto-deployment. The document reduces human operation difficulty and avoids the problem of specification limitation and slow response in centralized systems, to improve service deployment efficiency. The GeneRic Autonomic Signaling Protocol (GRASP) is specified by [RFC8990] and can make use of the technical objective to provide a solution for resource-based network services auto-deployment. The present document is to use it for validating the design of GRASP and other components of the ANI as described in [RFC8993].

2. Requirements Language

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 [RFC2119][RFC8174] .

3. Terminology & Abbreviations

RRM ASA: Requester ResourceManager ASA. A kind of ResourceManager ASA which start to request resource in the network.

PRM ASA: Provider ResourceManager ASA. A kind of ResourceManager ASA which provid resource in the network.

APE: Access Provider Edge is the first access provider edge where the service initiator connects to the network or where the path-dependent and resource-based network service starts.

DPE: Departure PE is the last provider edge where the path-dependent and resource-based network service ends.

Transmit node: A transmit node in the domain network.

ASBR: AS Border Router is an edge node of the domain in the cross-domain scenario. It may also be a PE node.

4. Resource-based Network Services Auto-deployment Solution

This section describes the internal architecture of resource-based network services auto-deployment. As noted in Section 1, this is not a complete description of a solution, which will depend on the detailed design of the relevant Autonomic Service Agents (ASAs). It uses the generic discovery and negotiation protocol defined by [RFC8990] and the relevant GRASP objectives are defined in Section 5.

The procedures described below are carried out by an ASA in each device that participates in the solution. We will refer to this as the ResourceManager ASA. If a device containing a ResourceManager ASA is used up its resource, it can request more resources according to its requirements. It should decide the type and value of the requested resource and request it via the mechanism described in Section 6.

4.1. ResourceManager ASA Discovery

A ResourceManager ASA that needs additional resources should firstly discover peers that may be able to provide extra resources. The ASA should send out a GRASP Discovery message that contains a ResourceManager Objective option to discover peers also supporting that option.

A GRASP device that receives a Discovery message with a ResourceManager Objective option should respond with a GRASP Response message if it contains a ResourceManager ASA. If it does not contain ResourceManager ASA, the device ignores this message. Further details of the discovery process are described in Section 2.5.4 of [RFC8990].

4.2. Resource Negotiation

After the discovery step, the RRM ASA (Requesting ResourceManager ASA) will act as a GRASP negotiation initiator by sending a GRASP Request message with a ResourceManager Objective option. The RRM ASA indicates in this option the value of the requested resource. And ResourceManager GRASP Objective allows multiple types of resources to be requested simultaneously.

When the PRM ASA (Provider ResourceManager ASA) 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 ASA.

During the negotiation, the RRM ASA will decide at each step how large a resource needs to offer. That decision, and the decision to end the negotiation, are implementation choices. As to the PRM ASA responses how large resources they can offer and reserve enough resources during this negotiation step. A resource shortage may cause a device to indicate the existing available value within a ResourceManager Objective option to the RRM ASA. The RRM ASA compares whether the resource data received is the same locally. If they are not the same, the RRM ASA might decide whether to accept the request of the resource. If not, the RRM ASA might terminate the negotiation via Negotiation End messages with an error code string.

As described in Section 2.8.8 of [RFC8990], negotiation will continue until either end stops it with a Negotiation End message. If the negotiation succeeds, the ASA that provides the resource will remove the negotiated resource from its pool, and the requesting ASA will add it. If the negotiation fails, the party sending the Negotiation End message may include an error code string.

4.3. Behavior after Negotiation

Upon receiving a GRASP Negotiation End message that indicates that the acceptable resource is available. The resource-providing device removes the acceptable resource from its resource pool and the requesting device may use the negotiated resource without further messages.

5. Autonomic Resource Management Objectives

This section defines the GRASP technical objective options that are used to support autonomic resource management.

The ResourceManager Objective option is a GRASP Objective option conforming to the GRASP specification [RFC8990]. 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) [RFC8949], the format of the ResourceManager Objective option is described in the Concise Data Definition Language (CDDL) [RFC8610] as follows:

objective = ["ResourceManager", objective-flags, loop-count, [restype, resval]]

loop-count = 0..255 ; as in the GRASP specification

objective-flags /= ; as in the GRASP

resourcetype /= 0...4; 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.

6. Process of Network Service Auto-deployment

The network service auto-deployment system includes Service Initiator(SI), Service Terminator(ST), RRM ASA, PRM ASA and even ASBR.

The service initiator is the resource demander, which ensures the connection of services through negotiation resources with ResourceManager ASA in the domain network. Service Terminator is the end of service. APE represents the first access provider edge where the service initiator connects to the network or where the path-dependent and resource-based network service starts. There may be multiple Transmit nodes between APE and Service Terminator in the network or even cross multiple network domains through ASBRs. RRM ASA starts a negotiation process to get enough resources in the network. After RRM ASA gets the result about the resource, it sends a response message to Service Initiator. And PRM ASA manages resources from APE to ST hop-by-hop.

6.1. An example of End-to-End Service

In an End-to-End service, Service Initiator is a kind of access terminal of the network. And the End-to-End service initiator uses ResourceManager ASA to negotiate resources with the ResourceManager ASA in the APE. Figure 2 shows the architecture of the End-to-End service. In the figure, the RRM ASA in SI will act as a GRASP negotiation initiator by sending a GRASP Request message with a ResourceManager Objective option. The RRM ASA indicates in this option the value of the requested resource. When this RRM ASA 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 with the resource value offered to the PRM ASA.

 +---------+ Negotiation Resource  +---------+
 | RRM ASA |<--------------------->| PRM ASA |
 +---------+                       +---------+    +------+    +------+
 |   SI    | --------------------->|   APE   |--->| Node |--->|  ST  |
 +---------+   Transmit data       +---------+    +------+    +------+

Figure-1: An example of End-to-End Service

PRM ASA processes receive resource requests and ensure the nodes resource it can manage. If PRM ASA can't manage all nodes in the data transport root or can't have enough resources, PRM ASA should act as a GRASP negotiation initiator to negotiate resources with other ASA in the network.

When the RRM ASA receives a Negotiation response message, it should check whether the resource value within the Negotiate message is the same as the resource value requested. If it is the same, the RRM ASA should send GRASP Negotiation End messages indicating that the negotiation was successful. If it is not the same, the RRM ASA should communicate with Service Initiator about the result and decide whether to accept this negotiation. If accepting this negotiation, RRM ASA should send GRASP Negotiation End messages indicating that the negotiation was successful. If not accepting this negotiation, it should send GRASP Negotiation End messages indicating that the negotiation fails.

6.2. An example of multiple rounds

In the process of automatic resource management mechanism, RRM ASA and PRM ASA are allowed to negotiate resources for multiple rounds. A very common situation is that the network resources can not 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 PRM ASA using Resource Management Objectives contains the resources that the network can provide to the service at present in the response message. The RRM ASA changes the resource requirements according to the specific requirements of the received resources and services, to carry out the next round of service negotiation.

6.3. An example of multiple domain network

In a multiple network, PRM ASA doesn't have the resource status of other domains. So PRM ASA should negotiate with ASBR PRM ASA before response RRM ASA. The PRM ASA should send a Confirm Waiting message to the RRM ASA, to extend its timeout. When the new resource becomes available confirmed by ASBR, the PRM ASA responds with a GRASP Negotiate message with a resource value offered. The process as Figure 2 shows. The Confirm Waiting message is described in Section 2.8.9 of [RFC8990].

 +----------+      +---------+
 | RRM ASA  |<---->| PRM ASA |
 +----------+      +---------+        +--------------+
                   | RRM ASA |<------>| ASBR PRM ASA |
                   +---------+        +--------------+
  Request Negotiation Message
  ---------------------->
  Waiting message
  <----------------------
                          Request Negotiation Message
                         ------------------->
                          Negotiation message
                         <------------------
  Negotiation message
  <----------------------

Other processes between APE and ASBR are the same as between Service Initiator and APE.

Figure-2: An example of a path-based resource negotiation

7. Compatibility with Other Technologies

A gateway device is used between the GRASP network and the MPLS network. As is known, the RSVP belongs to the distribution mechanism for resource reservation, but it is only coupled with MPLS. Then this device uses the GRASP protocol in the GRASP network, and the MPLS protocol in the MPLS network, so that resource information can be shared.

8. Security Considerations

It complies with GRASP security considerations. Relevant security issues are discussed in [RFC8990]. The preferred security model is that devices are trusted following the secure bootstrap procedure [RFC8995] and that a secure Autonomic Control Plane (ACP) [RFC8994] is in place.

9. IANA Considerations

This document defines a new GRASP Objective option names: "ResourceManager" which is need to be added to the "GRASP Objective Names" registry.

10. Acknowledgements

Valuable comments were received from Michael Richardson and Brian Carpenter.

11. Normative References

[I-D.ietf-mpls]
"Multiprotocol Label Switching Architecture", <https://www.rfc-editor.org/info/rfc3031>.
[I-D.ietf-spring-segment-routing]
"Segment Routing Architecture", <https://www.rfc-editor.org/info/rfc8402>.
[RFC2119]
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <https://www.rfc-editor.org/info/rfc2119>.
[RFC8990]
"GeneRic Autonomic Signaling Protocol (GRASP)", <https://www.rfc-editor.org/info/rfc8990>.
[RFC8993]
"A Reference Model for Autonomic Networking", <https://www.rfc-editor.org/info/rfc8993>.

Authors' Addresses

Joanna Dang (editor)
Huawei
No.156 Beiqing Road
Beijing
P.R. China, 100095
China
Sheng Jiang
Huawei
No.156 Beiqing Road
Beijing
P.R. China, 100095
China
Zongpeng Du
China Mobile
32 Xuanwumen West St
Beijing
P.R. China, 100053
China
Yujing (editor)
Huawei
No.156 Beiqing Road
Beijing
P.R. China, 100095
China