Internet DRAFT - draft-du-dyncast-service-info-updating-in-cnc
draft-du-dyncast-service-info-updating-in-cnc
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 <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.
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
<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.
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,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, DOI 10.17487/RFC4291, February
2006, <https://www.rfc-editor.org/info/rfc4291>.
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]
