ANIMA J. Dang, Ed. Internet-Draft S. Jiang Intended status: Standards Track Huawei Expires: January 8, 2022 Z. Du China Mobile July 7, 2021 An Auto-deployment Mechanism for Resource-based Network Services draft-dang-anima-network-service-auto-deployment-00 Abstract This document specifies an auto-deployment mechanism that deploys resource-based network services 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 January 8, 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 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 Dang, et al. Expires January 8, 2022 [Page 1] Internet-Draft July 2021 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. Architecture and components . . . . . . . . . . . . . . . . . 3 5. GRASP Option for Network Service Auto-deployment . . . . . . 4 6. Processes of Network Service Auto-deployment . . . . . . . . 7 6.1. Path-based Resource Negotiation . . . . . . . . . . . . . 7 7. Compatibility with Other Technologies . . . . . . . . . . . . 9 8. Security Considerations . . . . . . . . . . . . . . . . . . . 9 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 11. Normative References . . . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 1. Introduction A network service is a service carried by a network. A system of network service development includes a service initiator, a network and a service terminator. And a network is between a service initiator and a service terminator. From network perspective, this network service clearly has a source IP address and a destination IP address. Therefore, once a network service is delivered by a network, this network service clearly has an access node and a departure node in the network. Here, this access node is called UPE, and the departure node is called PE. Actually there may be multiple P nodes between UPE and PE in a single domain, and even cross multiple domains connections through ASBRs. And there may be one or more paths between UPE and PE for this network service. With the development of the network services, a class of services with resource requirements (such as bandwidth, latency, and jitter) are already emerging, such as video, LR, VR and so on. To collect resource information of network nodes along a path, the network managers must analyse whether there are available resources to allocate on the path. This is very demanding for network managers. Along with the increasing scale of the network and the increasing types of network services, the manual way have become increasingly difficult to operate. There are two directions to solve this problem. One is that network nodes perform the resource-based negotiation and calculation along the path, and the other is that the centralized control system perform network resource-based calculations for the path. The former is faster and is not limited by the number of nodes; the latter has better global calculation Dang, et al. Expires January 8, 2022 [Page 2] Internet-Draft July 2021 results. Based on the principle that the two methods can complement each other, the former is focused on in this document. This document specifies an auto-deployment mechanism for resource- based network services on the autonomic nodes in [RFC8993] to reduce human operation difficulty and avoid the problem of specification limitation and slow response in centralized systems, for the purpose of improving service deployment efficiency. The following chapters describe the architecture and functional components, the definition of GRASP options and processes. 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: It may be an end user, a Customer Edge (CE), or a controller that initiates a path-dependent and resource-based network service. SPE: A first hop network node where the service initiator connects to the network or where the path-dependent and resource-based network service starts. PE: Provider Edge node where the network service starts or ends. P: A transmit node between SPE and PE. 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. Architecture and components This section describes the internal architecture of an auto- deployment mechanism for resource-based network services. As Figure 1 shows, a functional system of network service auto- development includes Autonomic Network Service (ANS) Request, ANS Deployment Function and ANS Response. 1. First, the network resource initiator sends an ANS Request to a UPE on the edge of network. Dang, et al. Expires January 8, 2022 [Page 3] Internet-Draft July 2021 2. Then, the UPE starts to establish a resource-based path to the network service according to the network service requirements. A resource-based path is an LSP within [I-D.ietf-spring-segment-routing] or [I-D.ietf-mpls]. If the path is successfully established, UPE will automatically configure the LSP. The specific configuration command lines are not in the scope of this document. 3. Finally, UPE sends back an ANS Response with the deployment result to the network service initiator. Network Service Network Service Initiator Terminator +--------+ +--------+ | | | | +--------+ +--------+ | +--------+ +--------+ +--------+ | +-------| SPE |--------| P |--...--| PE |+------+ +--------+ +--------+ +--------+ Network Network Network Node1 Node2 NodeN 1.ANS Request ------------> 2.ANS Deployment Function <-------------------------------------------> 3. ANS Response <------------ Figure-1: Architecture and Components These messages including ANS Request, ANS Deployment Function and ANS Response are exchanged between or in autonomic nodes through GRASP. The chapter 5 defines the optional fields of GRASP for this function, and the chapter 6 introduces the process. 5. GRASP Option for Network Service Auto-deployment The GRASP enables autonomic nodes to dynamically discover peers, to synchronize state with each other, and to negotiate parameter settings with each other. So an objective option is used to identify objectives for the purposes of discovery, negotiation, or synchronization. So a new objective option is defined for Network Service Auto-deployment as follows. objective-name = EX10 All objectives MUST be in the following format, described in fragmentary CDDL. Dang, et al. Expires January 8, 2022 [Page 4] Internet-Draft July 2021 objective = [objective-name, objective-flags, loop-count, ?objective- value] The 'objective-value' field expresses the actual value of a negotiation or synchronization objective. So a new objective-value named n-s-deployment-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. objective-value = n-s-deployment-value loop-count = 0..255 An n-s-deployment-value is defined as Figure-2. n-s-deployment-value + service-identification + service-identification-type + service-identification-value + resource-information + resource-type + resource-value + n-s-deployment-type + status Figure-2: Format of n-s-deployment-value n-s-deployment-value = [ service-identification 1, service- identification 2, ..., service-identification n ] More than one auto-deployed network services can share a GRASP channel. service-identification = [ service-identification-type, service- identification-value, ?path-identification-type, ?path- identification-value, resource-information, n-s-deployment-type, ?n-s-status ] resource-information = [ resource-type, resource-value ] The detailed fields of n-s-deployment-value are defined as follows. service-identification-type: 3 bits, which is used to identify different services within a Request Negotiation message or a Negotiation message. o 1 = MAC Dang, et al. Expires January 8, 2022 [Page 5] Internet-Draft July 2021 o 2 = VLAN o 3 = IP address o 4 = Label o 5~6 is reserved service-identification-value: TBD, which is used to identify different network services within a Request Negotiation message or a Negotiation message. path-identification-type: 3 bits, which is related to the network. o 1 = LSP o 2~6 is reserved path-identification-value: TBD path-identification-value, 3 bits o MAC o Or VLAN o Or 5 tuple o Or label resource-type: 2 bits, one service may have a type of resource information or more than one type of resource information. o 1 = bandwidth o 2 = latency o 3 = jitter n-s-deployment-type: 2 bits o 1 = network service establishment o 2 = network service withdrawal o 3 = network service update including resource information update n-s-status: 2 bits only in a Negotiation message Dang, et al. Expires January 8, 2022 [Page 6] Internet-Draft July 2021 o 0, default o 1, which indicates that the negotiation was successful. o 2, which indicates that the negotiation failed 6. Processes of Network Service Auto-deployment The GRASP within objective-name for network service auto-deployment enables autonomic nodes which are a service initiator, a network and a service terminator. During the negotiation process, the service initiator first sends a Request Negotiation message with a service-identification to the SPE. After receiving the Request Negotiation message, the SPE records the service-identification and creates the related data block. Next, the SPE starts to establish a resource-based path based on the resource information within service-identification. 6.1. Path-based Resource Negotiation If the s-deployment-type within the Request Negotiation message is 1 which indicates network service establishment, the resource-based path establishment is started. If s-deployment-type is 3 which indicates network service update, the process directly skips to the processes of the path-based resource negotiation. The UPE must check whether the network path is reachable based on addressing information from service-identification. The addressing information may be destination MAC address in layer 2 networks, or destination IP address in layer 3 networks, or label in MPLS or SR networks , and so on. A path is an LSP within [I-D.ietf-spring-segment-routing] or [I-D.ietf-mpls]. o If a reachable path is found out from the existing free path, the SPE will initiate path resource negotiation. o If a reachable path isn't found out from the existing free path, the SPE will start path-based auto-configuration before resource negotiation. If the path configuration still fails, the SPE will send back a Negotiation Message that the service deployment failed to the service initiator. After finding out a network reachable path, the SPE initiates a path- based resource negotiation based on its resource information as figure-3. Dang, et al. Expires January 8, 2022 [Page 7] Internet-Draft July 2021 +-----+ +----+ +----+ +-----+ | SPE |------| P |------| P |------| PE + +-----+ +----+ +----+ +-----+ Request Negotiation Message ------------> Request Negotiation Message ------------> Request Negotiation Message ------------> Negotiation message <------------ Negotiation message <------------ Negotiation message <------------ Figure-3: An example of a path-based resource negotiation o Every autonomic network node along the path need to calculate the available resources. If receiving the path Request Negotiation message, it obtains resource information from the Request Negotiation message, and calculate whether its own resources related to this path meet the requirements. o * If they do, network autonomic node needs to send a path Request Negotiation message to the downstream node before related resources is occupies by this path. If the negotiation message reaches the last node of the path and resources are available, the autonomic node will send a Negotiation message with successful negotiation back to the upstream node. If the SPE receives a path Negotiation message indicating that the path resource negotiation is successful, it will send back to a service Negotiation message to the service initiator. * If they do not, it will terminate this message and response a Negotiation message with failed resource negotiation to its upstream node. If receiving it, the upstream node also response a path Negotiation message with failed resource negotiation to its upstream node. The SPE will send back to the service Negotiation message failed resource negotiation to the service initiator after receiving this path Negotiation message. If s-deployment-type within the Request Negotiation message is 3 which indicates network service update, the path update based on its resource requirement is started. It should be emphasized that the Dang, et al. Expires January 8, 2022 [Page 8] Internet-Draft July 2021 nodes occupy the sum of the existing and updated resources before the nodes along the path have successfully completed the path negotiation. If the update is successful, the existing resource along the path will be released. If the update fails, the existing resource along the path will be kept. If s-deployment-type within the Request Negotiation message is 2 which indicates network service withdrawal, the nodes along the path will release the relevant configuration and resources before receiving this message. 7. Compatibility with Other Technologies It is worth emphasizing that the resource allocation and calculation methods of network nodes are different on the type of different resource requirements. Now it is explained in terms of bandwidth. If in the MPLS network, the RSVP protocol system has the complete signaling mechanism and bandwidth resource calculation functions. The bandwidth negotiation of the network-side path can be completed by RSVP. For latency and jitter, the GRASP mechanism is needed to complete. For example, the network node collects links, forwarding and queue scheduling delays, and performs delay or calculations. If the calculated delay meets the service requirements, the other node is notified through the GRASP protocol. The same principle applies to jitter. 8. Security Considerations It complies with GRASP security consideration. 9. IANA Considerations A new GRASP Objective Name is especially for network service deployment. The Objective-name of n-s-deployment-value need to be defined. 10. Acknowledgements TBD 11. Normative References [I-D.ietf-mpls] "Multiprotocol Label Switching Architecture", . Dang, et al. Expires January 8, 2022 [Page 9] Internet-Draft July 2021 [I-D.ietf-spring-segment-routing] "Segment Routing Architecture", . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8990] "GeneRic Autonomic Signaling Protocol (GRASP)", . [RFC8993] "A Reference Model for Autonomic Networking", . Authors' Addresses 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 Dang, et al. Expires January 8, 2022 [Page 10]