Internet-Draft Service Information Updating in CNC December 2021
Du Expires 26 June 2022 [Page]
Network Working Group
Intended Status:
Z. Du
China Mobile

Service Information Updating in Computing and Network Convergence


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

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 4 June 2022.

Table of Contents

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

2. General Procedure

As described in Figure1, the MEC1/2/3 can all support Service1, and announce the anycast IP address <ServiceID1>. In the network, the ingress node will have the route for <ServiceID1>. According to the current anycast mechanism, one of the egress nodes will be the next hop for the <ServiceID1> on the ingress. For example, Egress2 is the next hop on the ingress node for the <ServiceID1>.

                                           _______       _______
                 _________________________|       |     |       |
                |                         |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 <source, destination> pairs as <ClientIP, ServiceID1>.

In the second step, the Ingress node receives the packet, and encapsulates the packet in a tunnel as <IngressIP, EgressIP2><ClientIP, ServiceID1>.

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 <source, destination> pairs as <ServerIP2, ClientIP>. Here, the source address is a normal IP address, and is not the anycast address.

In the fifth step, the Egress2 encapsulates the packet in a tunnel as <EgressIP2, IngressIP><ServerIP2, ClientIP>.

In the sixth step, the Ingress decapsulates the packet and send it to the MEC2, with the <source, destination> pairs as <ServerIP2, ClientIP>.

In the seventh step, the client receives the packet, correlates with the packet <ClientIP, ServiceID1>, and then uses <ServerIP2> 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 <ServiceID1> 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 <ServiceID1> 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 <ServiceID1>.

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.

5. IANA Considerations


6. Security Considerations


7. Acknowledgements


8. References

8.1. Normative References

Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <>.
Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, DOI 10.17487/RFC4291, , <>.

8.2. Informative References

Li, Y., Iannone, L., Trossen, D., and P. Liu, "Dynamic-Anycast Architecture", Work in Progress, Internet-Draft, draft-li-dyncast-architecture-00, , <>.
Liu, P., Willis, P., and D. Trossen, "Dynamic-Anycast (Dyncast) Use Cases & Problem Statement", Work in Progress, Internet-Draft, draft-liu-dyncast-ps-usecases-01, , <>.

Author's Address

Zongpeng Du
China Mobile
No.32 XuanWuMen West Street