Network Working Group Z. Du Internet-Draft China Mobile Intended status: Informational December 23, 2021 Expires: June 26, 2022 Service Information Updating in Computing and Network Convergence draft-du-dyncast-service-info-updating-in-cnc-00 Abstract This document introduces a service information updating method in the scenario of computing and network convergence. 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 [RFC2119]. 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 June 26, 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 Du Expires June 26, 2022 [Page 1] Internet-Draft Service Information Updating in CNC December 2021 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. General Procedure . . . . . . . . . . . . . . . . . . . . . . 3 3. Service Information Informing on the Control Plane . . . . . 4 4. Service Information Updating on the Data Plane . . . . . . . 4 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 6. Security Considerations . . . . . . . . . . . . . . . . . . . 5 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 8.1. Normative References . . . . . . . . . . . . . . . . . . 5 8.2. Informative References . . . . . . . . . . . . . . . . . 5 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction One of the evolvement directions of the network is to converge with the service. In the scenarios of Computing and Network Convergence (CNC) or Computing Force Network (CFN), the network is aware of the service information, and can make a better choice in the traffic steering. In this situation, both the network metric and the service-specific metric are considered instead of only the network metric. Thus, the network resource and the computing resource can be utilized more efficiently. In fact, the scheduling mechanism in the cloud scenarios can also support load balance according to the load of different servers for the same service. However, the decision point for the traffic steering is relatively high. The mechanism described in [I-D.li-dyncast-architecture] can support that the decision point is on the network node. One of the advantages of this mechanism is that the network node is on the data path, and can respond more quickly than the centralized mechanism. However, this cross-layer designation may cause some problems as mentioned in [I-D.liu-dyncast-ps-usecases]. One of the problems is that the service-specific metric is more dynamic. It is hard to refresh the status on the network nodes frequently. In this document, we introduce a mechanism that can update service information on the network nodes more efficiently. In the mechanism, we notify the service information on the control plane, and for some parameters that change frequently, we refresh them on the data plane. Du Expires June 26, 2022 [Page 2] Internet-Draft Service Information Updating in CNC December 2021 2. General Procedure As described in Figure1, the MEC1/2/3 can all support Service1, and announce the anycast IP address . In the network, the ingress node will have the route for . According to the current anycast mechanism, one of the egress nodes will be the next hop for the on the ingress. For example, Egress2 is the next hop on the ingress node for the . _______ _______ _________________________| | | | | |Egress1| --- | MEC1 | | | | | | | ------- ------- | | Service1 ______ _______ _______ _______ | | | | | | | | |Client|---|Ingress| |Egress2| --- | MEC2 | | | | | | | | | ------ ------- ------- ------- | | Service1 | _______ _______ | | | | | | |Egress3| --- | MEC3 | | | | | | | ------- ------- | Network | Service1 ------------------------------- Figure 1: Load balance among MECs in CNC or CFN In the first step, the client which wants to access Service1 will send a packet with the pairs as . In the second step, the Ingress node receives the packet, and encapsulates the packet in a tunnel as . In the third step, the Egress2 decapsulates the packet and send it to the MEC2. In the fourth step, the server in the MEC2 will response a packet with the pairs as . Here, the source address is a normal IP address, and is not the anycast address. Du Expires June 26, 2022 [Page 3] Internet-Draft Service Information Updating in CNC December 2021 In the fifth step, the Egress2 encapsulates the packet in a tunnel as . In the sixth step, the Ingress decapsulates the packet and send it to the MEC2, with the pairs as . In the seventh step, the client receives the packet, correlates with the packet , and then uses as the destination address to continue the communication. The main point of the CNC is in Step 2. In the current mechanism, the target for is relatively static. In the CNC, the Ingress should support dynamic load balance according to the computing load in MEC1/2/3, and the latency to the Egress1/2/3. For example in the CNC, if the MEC2 has a heavy load, the Ingress may steer the traffic with the destination address to Egress1/3. 3. Service Information Informing on the Control Plane In the CNC mechanism, the Egress1/2/3 should be able to collect the load information for ServiceID1, and inform the service information to the Ingress on the control plane. For example, the service information can be carried in the BGP message that announces the anycast IP address . However, if the load information for ServiceID1 changes frequently, we should not send too many BGP messages into the network. 4. Service Information Updating on the Data Plane In this document, we suggest updating the service information that changes frequently based on the data plane programming. The reason is that it is more efficient to do this kind of simple and repeated actions on the data plane. For example, the Egress 1/2/3 can monitor the packets targeting to the Ingress, and add the service information in the DoH of the packets [RFC4291]. Then, the Ingress can monitor the changes of the load of Service1 in the MECs. Other insertion methods can also be considered here. The information can also be inserted by the server into some place of the IPv6 extension headers. Du Expires June 26, 2022 [Page 4] Internet-Draft Service Information Updating in CNC December 2021 5. IANA Considerations TBD. 6. Security Considerations TBD. 7. Acknowledgements TBD. 8. References 8.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, DOI 10.17487/RFC4291, February 2006, . 8.2. Informative References [I-D.li-dyncast-architecture] Li, Y., Iannone, L., Trossen, D., and P. Liu, "Dynamic- Anycast Architecture", draft-li-dyncast-architecture-00 (work in progress), February 2021. [I-D.liu-dyncast-ps-usecases] Liu, P., Willis, P., and D. Trossen, "Dynamic-Anycast (Dyncast) Use Cases & Problem Statement", draft-liu- dyncast-ps-usecases-01 (work in progress), February 2021. Author's Address Zongpeng Du China Mobile No.32 XuanWuMen West Street Beijing 100053 China Email: duzongpeng@foxmail.com Du Expires June 26, 2022 [Page 5]