Internet DRAFT - draft-li-rtgwg-cfn-framework
draft-li-rtgwg-cfn-framework
RTGWG Y. Li
INTERNET-DRAFT J. He
Intended Status: Informational Huawei Technologies
Expires: May 7, 2020 L. Geng
P. Liu
China Mobile
Y. Cui
Tsinghua University
November 4, 2019
Framework of Compute First Networking (CFN)
draft-li-rtgwg-cfn-framework-00
Abstract
Compute First Networking (CFN) leverages both computing and
networking status to help determine the optimal edge among multiple
edge sites with different geographic locations to serve a specific
edge computing request. Requests for the same service can be
determined and dispatched to different edges based on service
requirements, network and computing resource conditions and other
factors to achieve better load balancing and system efficiency. The
request needs to be dispatched to the selected edge in real time and
the subsequent packets from the same flow should be served by the
same edge for flow affinity. This document describes a framework of
CFN to achieve the desired features.
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as
Internet-Drafts.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
Li, et al [Page 1]
INTERNET DRAFT Framework of CFN Nov 2019
http://www.ietf.org/shadow.html
Copyright and License Notice
Copyright (c) 2019 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
(http://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
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. CFN Framework . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1 CFN Service Overview . . . . . . . . . . . . . . . . . . . . 5
2.2 Generic Workflow . . . . . . . . . . . . . . . . . . . . . . 7
3. Control Plane and Data Plane . . . . . . . . . . . . . . . . . 7
3.1 Control plane . . . . . . . . . . . . . . . . . . . . . . . 7
3.2 Data plane . . . . . . . . . . . . . . . . . . . . . . . . . 9
4. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
5. Security Considerations . . . . . . . . . . . . . . . . . . . . 12
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 12
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
8.1 Normative References . . . . . . . . . . . . . . . . . . . 13
8.2 Informative References . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13
Li, et al [Page 2]
INTERNET DRAFT Framework of CFN Nov 2019
1. Introduction
Compute First Networking (CFN) scenarios and requirements document
[CFN-req] shows the usage scenarios that require an edge to be
dynamically selected from multiple edge sites with different
geographic locations to serve an edge computing request based on
computing resource consumption and network status in real time. For
instance, edge site in residential area receives low request volume
during working hours and high request volume during non-working
hours. And the request volume received by the edge site in industrial
park is the opposite. Such a pattern causes a big difference of
computing load on different edge sites. Traditional static or hashing
based service dispatch can not adapt to the unbalanced nature of
computing load or rapid change of it on different edge sites. One
edge such as the closest one to the client may have been overloaded
and at the same time the other edges may still have plenty of
computing resources to serve the requests. To efficiently leveraging
the computing resources hosted on all edges, service requests should
be dispatched and handled dynamically to make the computing and
network resources consumed in a balanced way.
CFN assumes there are multiple service equivalent edges to serve a
single service. A single edge has limited computing resources and
different edges may have different resources available for serving a
specific service at a specific time. In concept, multiple edges are
interconnected and collaborated with each other to balance the
service load in CFN. Computing resource available to serve a request
is the top metric to be considered when dispatching a request. At the
same time, the quality of the network path to an edge varies over
time. CFN is a network based approach so that the request is
dispatched to the optimal edge in terms of both computing resources
available and network status on the fly.
This document presents a CFN framework which can support service
equivalency and dynamics in edge computing to achieve better load
balancing with no application dependency.
1.1 Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
CFN: Computing First Networking
Li, et al [Page 3]
INTERNET DRAFT Framework of CFN Nov 2019
2. CFN Framework
Edge computing is expanding from a single edge site to networked and
collaborated multiple edge sites to solve the issues of low
efficiency and and low resource reuse. CFN enables large scale edge
interconnection and collaboration, providing optimal service access
and load balancing to adapt to service dynamics. Based on the real-
time computing capacity available and the network conditions, CFN
dynamically schedules computing request to appropriate service node,
thus the resource utilization and user experience is improved.
Figure 1 shows the network topology of CFN. CFN node is the basic
function entity in CFN network to provide the capability to exchange
the information about the computing resource consumption information
of service nodes attached to it and/or provide the CFN service access
to the clients. Edge site (edge for short) is normally the site where
the edge computing is hosted. CFN node can be a network virtual
function (NFV) co-located with service node in a server. CFN node's
function can also be provided by physical equipment like access
router in access ring or metro network.
Li, et al [Page 4]
INTERNET DRAFT Framework of CFN Nov 2019
edge site 1 edge site 2 edge site 3
+------------+
+------------+ +------------+ |
+-+----------+ | +-+----------+ |-+
|service node|-+ |service node|-+
+------------+ +------------+
| |
| |
+----------+ +----------+ +----------+
|CFN node 1| ------ |CFN node 2| ------- |CFN node 3| CFN
+----------+ +----------+ +----------+ layer
| |
| |
| |
+-----+ +-----+
+------+| +-----+|
|client|+ +-----+|+
+------+ +------+|+
|client|+
+------+
Figure 1. CFN Network Topology
2.1 CFN Service Overview
CFN uses Service ID (SID) to identify a particular service provided
by service nodes on multiple edges. The end devices always use SID to
initiate an access to a service. SID in current system is an anycast
address. Request to a single SID can potentially be served by
different edge sites. The end device does not know in advance which
edge to serve the request. The procedures to make such determination
is called the service dispatch. During service dispatch, the most
appropriate edge site (i.e. CFN egress) is selected and it is the
edge to which the service node that handles this specific request is
attached to. A binding IP (BIP) address to the requested SID is known
by CFN egress. BIP is a unicast IP address accessible to a particular
service node providing service SID.
As shown in figure 2, service with SID 2 can be served by either CFN
node 2 with binding IP BIP22 or CFN node 3 with BIP32. When the
service request from the end device to SID2 reaches the ingress CFN
(which is CFN node 1 in this case), the ingress CFN node should
determine on the fly which egress CFN this request should be sent to.
Then, the de facto service node is determined, and all the subsequent
Li, et al [Page 5]
INTERNET DRAFT Framework of CFN Nov 2019
data packets from the same flow to access this service should always
be sent to the binding IP of the selected service node.
edge 1 edge 2 edge 3
-----
+-----------------+ +-----------------+ /|\
+----------------+ |+-----+ +-----+ | |+-----+ +-----+ | |
|+-----+ +-----+| ||BIP21|--|SID1 | | ||BIP32|--|SID2 | | |
||BIP13|--|SID3 || |+-----+ +-----+ | |+-----+ +-----+ | |
|+-----+ +-----+| |+-----+ +-----+ | |+-----+ +-----+ | |
+--------+-------+ ||BIP22|--|SID2 | | ||BIP33|--|SID3 | | |
| |+-----+ +-----+ | |+-----+ +-----+ | |
| +-------+---------+ +-------+---------+ CFN
| | |
+----+-----+ +----+-----+ +----+-----+ |
|CFN node 1|------ |CFN node 2| ---------|CFN node 3| |
+----+-----+ +----------+ +----------+ |
| |
| |
+-----------+ |
|CFN adaptor| \|/
+-----------+ ------------
| /|\
| |
+----------+ client side
|end device| |
+----------+ \|/
-----------
Figure 2. CFN System Overview
CFN adaptor shown in figure 2 is an entity to help the end device
working with CFN in a way of keeping the binding information,
identifying the initial request packet, and so on. It can be
implemented as a part of CFN node (internal mode) or on a separate
equipment (external mode). Figure 2 shows an external mode of CFN
adaptor which can be deployed at the client side, on a virtual
gateway connecting multi user equipments (UEs), as a user Plane
Function (UPF) in the mobile network, or on Broadband Remote Access
Server (BRAS) in the fixed network. The reason to have such an
external mode is that CFN adaptor can be put closer to the clients,
and then CFN node is put at some aggregated point with multiple CFN
adaptors attached to it. Compared to the internal mode, external CFN
adaptor keeps less binding information of the clients. It results in
Li, et al [Page 6]
INTERNET DRAFT Framework of CFN Nov 2019
less memory requirements on CFN node. CFN adaptor has no control
plane.
2.2 Generic Workflow
The following procedures describe how CFN works in general.
1) CFN adaptor identifies a new service request from the end device,
possibly by the special anycast address range for a SID.
2) CFN adaptor sends the request to its attaching CFN node which is
CFN ingress.
3) CFN ingress determines the most appropriate CFN egress based on
the computing resource consumption of the service nodes, the network
status to the egress nodes and other information. CFN ingress
forwards the request to the selected CFN egress. CFN ingress can
select itself to serve the request. In this case, it is both ingress
and egress in concept.
4) CFN egress receives the request from the CFN ingress and
explicitly uses the binding IP BIP as destination address to access
the required service.
5) CFN adaptor of ingress keeps the binding information on (SID, CFN
egress) for the flow.
6) CFN ingress sends the subsequent packets for the same service from
the same flow to the bound CFN egress to ensure the flow affinity.
7) CFN nodes distribute the service nodes status like available
computing resources for specific services to each other on a regular
base.
3. Control Plane and Data Plane
3.1 Control plane
CFN node needs to notify each other about service IDs (SIDs)
attaching to it and the computing load information available
corresponding to each service ID. This is used for service discovery
and dispatch when a request to access a SID is received. Such
information can be carried in current BGP [RFC4760] /IGP routing
protocol extension. The network cost to a CFN node can be distributed
in the same way. A sample service status information to be stored on
Li, et al [Page 7]
INTERNET DRAFT Framework of CFN Nov 2019
a CFN edge is shown in figure 2.
+---------------+---------------+----------------+----------------+
| | Computing | | |
|Destination | Load | Network Cost | Next Hop |
+---------------+---------------+----------------+----------------+
| | | | CFN Egress |
|SID 1 | 3 | 5 | node 1 |
+---------------+---------------+----------------+----------------+
Figure 2. Example of service status information in CFN
Computing load can be calculated from different weighted dimensions,
e.g. CPU used, number of session being served, query per second,
computation delay and so on. Such information needs to be refreshed
regularly. In order to avoid fluctuation, it is distributed only when
the metrics variation exceeds a threshold or the updating timer is
expired. At the same time, the most appropriate egress node selected
by the CFN ingress does not necessarily mean the one with the lowest
load. Request can be sent to one selected from those egresses with
relatively low computing load to avoid fluctuation.
Since SID is an anycast address, CFN ingress determines which CFN
egress to forward the request to a specific SID to based on a
combination of computing load and network cost.
Figure 3 shows how CFN control plane works in general. It depicts
that CFN node 3 distributes computing information for service SID2.
CFN node 2 should distribute service SID 2 information in the similar
way as shown in figure 3. Definition and operations to extend control
plane routing protocol to support CFN information distribution, and
schemes/criteria to select CFN egress with anycast address from those
information are to be added.
Li, et al [Page 8]
INTERNET DRAFT Framework of CFN Nov 2019
CFN CFN CFN Edge Platform
Node 1 Node 2 Node 3 Manager
| | | |
| | | |
| | |<------------------|
| | | 1.Service info |
| | | registration/ |
| | | update/withdraw |
| | | (SID2, BIP32) |
| | | |
| | | |
| | |<------------------|
| | | 2.Computing load |
| | | update triggering |
| | | (SID2,computing |
| | | load information) |
| | | |
| | | |
| |<---------------------| |
| | | |
|<------------------------------| |
| | 3.BGP update for | |
| | computing load | |
| | (SID2, CFN node 3, | |
| | computing load info)| |
| | | |
Figure 3. CFN control plane
3.2 Data plane
The traditional anycast is normally used for single request single
response style communication as different requests may be sent to
different places when the network status changes. CFN used in edge
computing may require multiple request multiple response style
communication between the end device and the service node. Therefore
the data plane must maintain flow affinity to ensure that the
requests from the same flow are always processed by the same edge and
that edge is determined at the time when the first anycast request is
received by CFN ingress. The service access to the same SID from
different end hosts attaching to the same CFN ingress may be
dispatched to different CFN egresses. We call such a feature dynamic
anycast or Dyncast in this document.
Li, et al [Page 9]
INTERNET DRAFT Framework of CFN Nov 2019
Dyncast puts some requirements on the data plane. The flow affinity
table needs to be maintained by CFN ingress. On the other hand, large
number of end hosts may attach to a CFN node. Therefore CFN ingress
may require large memory space, such as tens of thousands of entries,
to maintain such a big table of (flow, service ID, egress CFN). It is
preferable to place such a binding table on an external CFN adaptor
as CFN adaptor only needs to maintain a much smaller table, usually
less than a hundred.
Figure 4 shows how CFN data plane works in general.
Li, et al [Page 10]
INTERNET DRAFT Framework of CFN Nov 2019
CFN node 1 CFN node 3 Service
client (CFN ingress) (CFN egress) Node for S
| | | |
|1.service req | | |
|------------->| | |
|dst=SID2 | | |
|src=client_IP | | |
| | | |
| +----------------+ | |
| |2.Select CFN | | |
| |egress & save it| | |
| +----------------+ | |
| | | |
| |3. encap & forward | |
| |---------------------> | |
| |outer: dst=CFN_Node_3 | |
| | src=CFN_Node_1 | |
| |inner: dst=SID2 | |
| | src=client_IP | |
| | +----------------+ |
| | |4.decap & map | |
| | |SID2 to BIP32 | |
| | +----------------+ |
| | |5. forward pkt |
| | |------------------>|
| | |dst=BIP32 |
| | | |
| | | 6. service rsp |
| | |<----------------- |
| | |src=BIP32 |
| | | |
| | +----------------+ |
| | |7.map BIP32 back| |
| | |to SID2 | |
| | +----------------+ |
| | | |
| |8. encap and forward | |
| |<--------------------- | |
| |outer: dst=CFN_Node_1 | |
| | src=CFN_Node_3 | |
| |inner: dst=client_IP | |
| | src=SID2 | |
| 9. decap | | |
| &forward | | |
|<-------------|
Figure 4. CFN data plane for the first request of a flow
Li, et al [Page 11]
INTERNET DRAFT Framework of CFN Nov 2019
The data plane supports the following functions.
- CFN ingress forwards the first service access request packet of a
flow to the selected CFN egress by encapsulation, source routing or
segment routing. Figure 4 shows the example of forwarding by
encapsulation.
- CFN ingress can inform the external CFN adaptor (if there is) about
the binding information on (flow, service ID, egress CFN).
- CFN adaptor (internal or external to CFN ingress) maintains the
binding information table for all end hosts attaching to it and
forwards the subsequent packets based on the binding information if
any.
4. Summary
This draft introduces a CFN framework that enables the service
request to be sent to an optimal edge to improve the overall system
load balancing. It can dynamically adapt to the computing resources
consumption and network status on edges and avoid overloading a
single load. CFN is a network based solution that supports a large
number of edges and is independent of the applications or services
hosted on the edge.
This present document is a strawman for defining CFN framework. A
routing protocol (BGP [RFC4760]/IGP based) extension to distribute
computing resource information and a late binding based dynamic
anycast are to be defined on control plane and data plane
respectively.
5. Security Considerations
The computing resource information changes over time very fast with
the creation and termination of service instance handlers. When such
information is carried in routing protocol, too many updates can make
the network fluctuate. Section 3.1 gives a brief idea on avoiding
sending too much updates.
6. IANA Considerations
No IANA action is required so far.
7. Acknowledgements
Li, et al [Page 12]
INTERNET DRAFT Framework of CFN Nov 2019
8. References
8.1 Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
8.2 Informative References
[RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter,
"Multiprotocol Extensions for BGP-4", RFC 4760, January
2007.
[CFN-req] Geng, L., et al, "Compute First Networking (CFN) Scenarios
and Requirements", draft-geng-rtgwg-CFN-req-00, November
2019.
Authors' Addresses
Yizhou Li
Huawei Technologies
Email: liyizhou@huawei.com
Jeffrey He
Huawei Technologies
Email: jeffrey.he@huawei.com
Liang Geng
China Mobile
Email: gengliang@chinamobile.com
Peng Liu
China Mobile
Email: liupengyjy@chinamobile.com
Yong Cui
Tsinghua University
Email: cuiyong@tsinghua.edu.cn
Li, et al [Page 13]
INTERNET DRAFT Framework of CFN Nov 2019
Li, et al [Page 14]
