Dynamic-Anycast Architecture
draft-li-dyncast-architecture-00
dyncast Y. Li
Internet-Draft L. Iannone
Intended status: Informational D. Trossen
Expires: August 19, 2021 Huawei Technologies
P. Liu
China Mobile
February 15, 2021
Dynamic-Anycast Architecture
draft-li-dyncast-architecture-00
Abstract
This document describes a proposal for an architecture for the
Dynamic-Anycast (Dyncast). It includes an architecture overview,
main components that shall exist, and the workflow. An example of
workflow is provided, focusing on the load-balance multi-edge based
service use-case, where load is distributed in terms of both
computing and networking resources through the dynamic anycast
architecture.
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 August 19, 2021.
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
Li, et al. Expires August 19, 2021 [Page 1]
Internet-Draft Dyncast Architecture February 2021
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 . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 3
3. Architecture Main Concepts . . . . . . . . . . . . . . . . . 4
4. Dyncast Architecture Workflow . . . . . . . . . . . . . . . . 8
4.1. Service Notification/Metrics Update . . . . . . . . . . . 8
4.2. Service Demand Dispatch and Instance Affinity . . . . . . 9
4.2.1. Service Demand Dispatch and Instance Affinity on
D-Routers ingress . . . . . . . . . . . . . . . . . . 10
4.2.2. Service Demand Dispatch and Instance Affinity on
D-Forwarders ingress . . . . . . . . . . . . . . . . 11
5. Dyncast Control-plane vs Data-plane operations . . . . . . . 13
6. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
7. Security Considerations . . . . . . . . . . . . . . . . . . . 14
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
9.1. Informative References . . . . . . . . . . . . . . . . . 14
9.2. Informative References . . . . . . . . . . . . . . . . . 14
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14
1. Introduction
Edge computing is expanding from a single edge nodes to multiple
networked collaborating edge nodes to solve the issues like response
time, resource optimization, and network efficiency.
The current network architecture in edge computing provides
relatively static service dispatching, for example, to the closest
edge from an IGP perspective, or to the server with the most
computing resources without considering the network status, and even
sometimes just based on static configuration.
Networking taking into account computing resource metrics seems to be
an interesting paradigm that fits numbers of use-cases that would
benefit from such capability [I-D.liu-dyncast-ps-usecases]. Yet,
more investigation is still needed in key areas for this paradigm
and, to this end, this document aims at providing an architectural
framework, which will enable service notification, status update, and
service dispatch in edge computing..
Show full document text