Internet DRAFT - draft-dang-anima-network-service-auto-deployment
draft-dang-anima-network-service-auto-deployment
ANIMA J. Dang, Ed.
Internet-Draft S. Jiang
Intended status: Standards Track Huawei
Expires: 12 April 2022 Z. Du
China Mobile
Z. Zhou, Ed.
Huawei
9 October 2021
An Autonomic Mechanism for Resource-based Network Services Auto-
deployment
draft-dang-anima-network-service-auto-deployment-01
Abstract
This document specifies an autonomic mechanism for resource-based
network services deployment through the Autonomic Control Plane (ACP)
in an Autonomic Network. This mechanism uses the GRASP in [RFC8990]
to exchange the information among the autonomic nodes so that the
resource among 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 12 April 2022.
Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
Dang, et al. Expires 12 April 2022 [Page 1]
Internet-Draft An Autonomic Mechanism for Resource-base October 2021
and restrictions with respect to this document. Code Components
extracted from this document must include Simplified BSD License text
as described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3
3. Terminology & Abbreviations . . . . . . . . . . . . . . . . . 3
4. Resource-based Network Services Auto-deployment Solution . . 4
4.1. ResourceManager ASA Discovery . . . . . . . . . . . . . . 4
4.2. Resource Negotiation . . . . . . . . . . . . . . . . . . 4
4.3. Behavior after Negotiation . . . . . . . . . . . . . . . 5
5. Autonomic Resource Management Objectives . . . . . . . . . . 5
6. Process of Network Service Auto-deployment . . . . . . . . . 6
6.1. Process between Service Initiator and APE . . . . . . . . 6
6.2. Process between APE and ASBR . . . . . . . . . . . . . . 7
7. Compatibility with Other Technologies . . . . . . . . . . . . 7
8. Security Considerations . . . . . . . . . . . . . . . . . . . 8
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8
11. Normative References . . . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8
1. Introduction
With the network development, a class of services with resource
requirements (such as bandwidth, latency, and jitter) are already
emerging, such as video, LR, VR and so on. From network perspective,
this kind of service clearly has a source IP address and a
destination IP address. Therefore, once the kind of service is
delivered by a network, this network service clearly has an access
node and a departure node in the network. Here, the access node is
called APE, and the departure node is called DPE. Actually there may
be multiple Transmit nodes between APE and DPE in a network domain,
and even cross multiple network domains through ASBRs. Then, the
deployment of network services needs to negotiate network resources.
As is surveyed, the resource in campus network are more uneven than
in the operator's network, such as wireless connections. Ideally, as
a centralized system, the controller can automatically perform
resource discovery and overall allocation. Actually, all devices in
the campus network cannot be conveniently, availably communicated
with one controller, such as, some sensors with complex installation
environment, the network devices from different vendors. Therefore,
a new distributed mechanism in network is required to negotiate the
resource information for network service auto-deployment.
Dang, et al. Expires 12 April 2022 [Page 2]
Internet-Draft An Autonomic Mechanism for Resource-base October 2021
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.
This document defines an autonomic technical objectives for Resource-
based Network Services Auto-deployment. 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. An important purpose of the
present document is to use it for validation of the design of GRASP
and other components of the ANI as described in [RFC8993].
The goal of this document is to complete the resource-based self-
adaptation among service and network nodes via GRASP. And this
document is not a complete functional specification of an autonomic
system of Resource-based Network Services Auto-deployment, and it
does not describe all detailed aspects of the GRASP objective
parameters and Autonomic Service Agent (ASA) procedures necessary to
build a complete system. Instead, it describes the architectural
framework utilizing the components of the ANI, outlines the different
deployment options and aspects, and defines GRASP objectives for use
in building the system. It also provides some basic parameter
examples.
2. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119.
3. Terminology & Abbreviations
Service Initiator(SI): It may be an end user, a Customer Edge (CE),
or a controller that initiates a path-dependent and resource-based
network service.
Provider Edge (PE): Provider Edge node where the network service
starts or ends.
Access PE (APE): A first provider edge where the service initiator
connects to the network or where the path-dependent and resource-
based network service starts.
Departure PE (DPE): A last provider edge where the path-dependent and
resource-based network service ends.
Transmit node: A transmit node between APE and DPE.
Dang, et al. Expires 12 April 2022 [Page 3]
Internet-Draft An Autonomic Mechanism for Resource-base October 2021
AS Border Router (ASBR): AS Border Router which 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 which is used up its resource, it can request more resource
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 resource should firstly
discover peers that may be able to provide extra resource. The ASA
should send out a GRASP Discovery message that contains a
ResourceManager Objective option in order to discover peers also
supporting that option. Then, it should choose one such peer, most
likely the first to respond.
A 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 ignore this message. Further details
of the discovery process are described in [RFC8990].
4.2. Resource Negotiation
After discover step, the requesting ResourceManager ASA will act as a
GRASP negotiation initiator by sending a GRASP Request message with a
ResourceManager Objective option. The requesting ResourceManager ASA
indicates in this option the value of the requested resource. This
starts a GRASP negotiation process.
Dang, et al. Expires 12 April 2022 [Page 4]
Internet-Draft An Autonomic Mechanism for Resource-base October 2021
When the 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 requesting ResourceManager ASA will
decide at each step how large resource need to offer. That decision,
and the decision to end the negotiation, are implementation choices.
As to the provider ResourceManager ASA responses how large resource
they can offer and reserve enough resource during this negotiation
step. A resource shortage may cause a device to indicate the
existing available value within a ResourceManager Objective option to
the requesting ASA. The requesting ASA compares whether the resource
data received is the same locally. If they are not the same, the
requesting ASA might decide whether to accept the resource. If not,
the requesting ASA might terminate the negotiation via Negotiation
End messages with an error code string.
As described in [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
remove 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:
Dang, et al. Expires 12 April 2022 [Page 5]
Internet-Draft An Autonomic Mechanism for Resource-base October 2021
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, latency or jitter.
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, APE, DPE, and even ASBR.
The network service clearly has a APE and a DPE in the network.
Actually there may be multiple Transmit nodes between APE and DPE in
a single network domain, or even cross multiple network domains
through ASBRs. In a single network domain, APE holds all resource
information to DPE. In multiple domain network domains, APE holds
all resource information to ASBR, and ASBR holds all resource
information to DPE.
The Service Initiator initiates resource negotiation for a certain
network service to APE. If in one single domain, APE should respond
to the message with the resource valued offered. If in multiple
domain network domains, APE should initiates resource negotiation to
ASBR, and respond to the message with the resource valued offered
until receiving ASBR's response.
6.1. Process between Service Initiator and APE
The Service Initiator containing a ResourceManager ASA should send
out a GRASP Discovery message that contains a ResourceManager
Objective option in order to discover APE also supporting that
option. The APE that receives a Discovery message with a
ResourceManager Objective option should respond with a GRASP Response
message if it contains a ResourceManager ASA.
The ASA in the Service Initiator will act as a GRASP negotiation
initiator by sending a GRASP Request message with a ResourceManager
Objective option. The ASA indicates in this option the value of the
requested resource.
Dang, et al. Expires 12 April 2022 [Page 6]
Internet-Draft An Autonomic Mechanism for Resource-base October 2021
When this ASA in the APE 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 requesting ASA.
If in a single network domain, this ASA in the APE check whether the
local resource data meets the requirements of the request. If it
meets the requested requirement, the APE should respond with a GRASP
Negotiate messages with the resource type and the resource value
requested. If it doesn't meet the requested requirement, the APE
should respond with a GRASP Negotiate messages with the resource
value offered.
If in the multiple network domain, this ASA in the APE should act a
GRASP negotiation initiator described in Section 6.2.
When the ASA in the Service Initiator receives a Negotiate message,
it should check whether the resource value within the Negotiate
message is the same as the resource value requested. If it is same,
the Service Initiator should send GRASP Negotiation End messages
indicating that the negotiation was successful. If it is not same,
the Service Initiator should decide whether to accept this
negotiation. If accepting this negotiation, it send 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. Process between APE and ASBR
The ASA in the APE should send a Confirm Waiting message to the
Service Initiator, to extend its timeout. When the new resource
becomes available confirmed by ASBR, the APE responds with a GRASP
Negotiate message with a resource value offered.
Other processes between APE and ASBR are the same as between Service
Initiator and APE.
7. Compatibility with Other Technologies
A gateway device gateway device is adopted between the GRASP network
and the MPLS network. As is known, the RSVP belong to the
distributed 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.
Dang, et al. Expires 12 April 2022 [Page 7]
Internet-Draft An Autonomic Mechanism for Resource-base October 2021
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, March 1997,
<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
Dang, et al. Expires 12 April 2022 [Page 8]
Internet-Draft An Autonomic Mechanism for Resource-base October 2021
Joanna Dang (editor)
Huawei
No.156 Beiqing Road
Beijing
P.R. China, 100095
China
Email: dangjuanna@huawei.com
Sheng Jiang
Huawei
No.156 Beiqing Road
Beijing
P.R. China, 100095
China
Email: jiangsheng@huawei.com
Zongpeng Du
China Mobile
32 Xuanwumen West St
Beijing
P.R. China, 100053
China
Email: duzongpeng@chinamobile.com
Yujing (editor)
Huawei
No.156 Beiqing Road
Beijing
P.R. China, 100095
China
Email: zhouyujing3@huawei.com
Dang, et al. Expires 12 April 2022 [Page 9]