Skip to main content

Dynamic-Anycast Architecture
draft-li-dyncast-architecture-06

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Expired".
Authors Yizhou Li , Luigi Iannone , Dirk Trossen , Peng Liu , Cheng Li
Last updated 2023-01-16
RFC stream (None)
Formats
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-li-dyncast-architecture-06
rtgwg                                                              Y. Li
Internet-Draft                                                L. Iannone
Intended status: Standards Track                              D. Trossen
Expires: 20 July 2023                                Huawei Technologies
                                                                  P. Liu
                                                            China Mobile
                                                              C. Li, Ed.
                                                     Huawei Technologies
                                                         16 January 2023

                      Dynamic-Anycast Architecture
                    draft-li-dyncast-architecture-06

Abstract

   This document describes an architecture for the Dynamic-Anycast
   (Dyncast).  It includes an architecture overview, main components,
   and the workflow of control plane and dataplane.

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 20 July 2023.

Copyright Notice

   Copyright (c) 2023 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

Li, et al.                Expires 20 July 2023                  [Page 1]
Internet-Draft            Dyncast Architecture              January 2023

   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 include Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
     2.1.  Requirements Language . . . . . . . . . . . . . . . . . .   4
   3.  Architecture and Components . . . . . . . . . . . . . . . . .   4
   4.  Dyncast Architecture Workflow . . . . . . . . . . . . . . . .   7
     4.1.  Service Announcements . . . . . . . . . . . . . . . . . .   7
     4.2.  Metric Distributions  . . . . . . . . . . . . . . . . . .   7
     4.3.  Service Demand Handling . . . . . . . . . . . . . . . . .   8
     4.4.  Instance Affinity . . . . . . . . . . . . . . . . . . . .   9
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   9
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  10
   7.  Contributors  . . . . . . . . . . . . . . . . . . . . . . . .  10
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  10
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .  10
     8.2.  Informative References  . . . . . . . . . . . . . . . . .  10
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  10

1.  Introduction

   Edge computing has been expanding from 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, often 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.

   As described in [I-D.liu-can-ps-usecases],traffic steering that takes
   into account computing resource metrics would benefit several use-
   cases, such as AR/VR.  This document provides an architectural
   framework, which will enable compute- and network-aware traffic
   steering decisions in edge computing.

Li, et al.                Expires 20 July 2023                  [Page 2]
Internet-Draft            Dyncast Architecture              January 2023

   The Dyncast architecture proposed in this document is an ingress-
   based overlay architecture for the selection of a suitable service
   instance from a set of possibly several ones, where 'suitable' may be
   determined through a combination of networking and computing related
   metrics.

   Dyncast assumes that there are multiple service instances running on
   different edge nodes, globally providing one single service.  A
   single edge may have limited computing resources available, and
   different edges likely have different resources available, such as
   CPU or GPU.

   The main principle of Dyncast is that multiple edge nodes are
   interconnected and collaborate with each other to achieve a holistic
   objective of dispatching service demands, by taking into account both
   service instances status as well as network state (e.g., paths
   length, price and their congestion).

   This document describes an architecture to realize Dyncast, the
   workflow of main procedures in control and data plane.

2.  Terminology

   *  Dyncast: As defined in [I-D.liu-can-ps-usecases], Dynamic Anycast,
      taking the dynamic nature of computing resource metrics into
      account to steer an anycast routing decision.

   *  Service: As defined in [I-D.liu-can-ps-usecases], a monolithic
      functionality that is provided by an endpoint according to the
      specification for said service.  A composite service can be built
      by orchestrating monolithic services.

   *  Service instance: As defined in [I-D.liu-can-ps-usecases], running
      environment (e.g., a node) that makes the functionality of a
      service available.  One service can have several instances running
      at different network locations.

   *  D-Router: A node supporting Dyncast functionalities as described
      in this document.  Namely it is able to understand both network-
      related and service-instances-related metrics, take forwarding
      decision based upon and maintain instance affinity, i.e., forwards
      packets belonging to the same service demand to the same instance.

   *  Ingress D-Router: a service access point for Dyncast clients.  It
      makes the routing decision to encapsulate the service packets into
      an overlay path to an Egress D-Router linked to the most suitable
      edge site/instance.

Li, et al.                Expires 20 July 2023                  [Page 3]
Internet-Draft            Dyncast Architecture              January 2023

   *  Egress D-Router: An Egress D-Router is the egress endpoint of an
      overlay path.

   *  D-MA: Dyncast Metric Agent (D-MA): A dyncast specific agent able
      to gather and send metric updates (from both network and instance
      perspective) but not performing forwarding decisions.  May run on
      a D-Router, but it can be also implemented as a separate module
      (e.g., a software library) collocated with a service instance.

   *  D-SID: Dyncast Service ID, an identifier representing a service,
      which the clients use to access said service.  Such identifier
      identifies all of the instances of the same service, no matter on
      where they are actually running.  D-SID is independent of which
      service instance serves the service demand.  Usually multiple
      instances provide a (logically) single service, and service
      demands are dispatched to the different instance through an
      anycast model, i.e., choosing one instance among all available
      instances.

   *  D-BID: Dyncast Binding ID, an address to reach a service instance
      for a given D-SID.  It is usually a unicast IP where service
      instances are attached.  Different service instances provide the
      same service identified through D-SID but with different Dyncast
      Binding IDs.

   *  Service demand: The demand for a specific service and addressed to
      a specific D-SID.

   *  Service request: The request for a specific service instance.

2.1.  Requirements Language

   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.

3.  Architecture and Components

   Dyncast assumes that there are multiple equivalent service instances
   running on different edge sites, providing one single service which
   is represented by D-SID.  The network will take forwarding decision
   for the service demand from the client according to both service
   instances status as well as network status.  The architecture is
   shown below.

Li, et al.                Expires 20 July 2023                  [Page 4]
Internet-Draft            Dyncast Architecture              January 2023

       edge site 1                              edge site 2

        +------------+                          +------------+
      +------------+ |                        +------------+ |
      |  service   | |                        |  service   | |
      |  instance  |-+                        |  instance  |-+
      +------------+                          +------------+
            |                                        |
       +----------+                                  |
       |   D-MA   |                                  |
       +----------+                                  |
            |                                   +----------+
            |           +-----------------+     |   D-MA   |
       +----------+     |     Underlay    |     +----------+
       |D-Router 1| ----|  Infrastructure |---- |D-Router 3|
       +----------+     |                 |     +----------+
                        +-----------------+
                                 |
                                 |
                            +----------+
          +---------------- |D-Router 2|--------------+
          |                 +----------+              |
          |                       |                   |
          |                       |                   |
         +-----+              +------+            +------+
       +------+|            +------+ |          +------+ |
       |client|+            |client|-+          |client|-+
       +------+             +------+            +------+

                      Figure 1: Dyncast Architecture.

   Edge sites (edges for short) are normally the sites where edge
   computing is performed.  Service instances are initiated at different
   edge sites.  Thus, a single service can actually have a significant
   number of instances running on different edges.  A Dyncast Service ID
   (D-SID) is used to uniquely identify a service (e.g., a matrix
   computation for face recognition, or a game server).  Service
   instances can be hosted on servers, virtual machines, access routers
   or gateway in edge data center.

   Close to (one or more) Service instances is the Dyncast Metric Agent
   (D-MA).  This element has the task to gather information about
   resources and status of the different instances as well as network-
   related information.  The information of resource and status will be
   presented as one or more metrics and associate with the D-SID.  D-MAs
   also need to send the D-SID routes with computing-related metrics to
   the Egress D-Routers proactively.  A D-MA may also run in a dyncast-
   enable router (named D-Router), while other deployment scenarios may

Li, et al.                Expires 20 July 2023                  [Page 5]
Internet-Draft            Dyncast Architecture              January 2023

   lead to this element running separately on edge nodes.  In the case
   of running in a D-Router, the D-SID routes with computing-related
   metrics can be synchronized up within the system.

   The D-Router is the main element in a Dyncast network.  There are two
   types of D-Routers: Egress D-Router and Ingress D-Router.

   *  Egress D-Router: An Egress D-Router is the egress endpoint of an
      overlay path.  It distributes information on D-SID metrics, as
      well as information of identifying the Egress D-Router, to the
      associated Ingress D-Routers.  Normally, a site may be linked to
      one or more Egress D-routers.

   *  Ingress D-Router: a service access point for Dyncast clients.  It
      will receive the information on D-SIDs metrics and egress
      D-Routers as distributed from associated Egress D-Routers, and
      generate the routing decision based on the network-related and
      computing-related metrics.  Some network metrics can be learned on
      the ingress D-Router by detecting, such as the latency and
      bandwidth from the ingress to an egress D-Router.  Usually, the
      routing decision will indicate the Ingress D-Router to encapsulate
      the service packets into an overlay path to an Egress D-Router
      linked to the most suitable edge site/instance.

   Note: Depending on deployment requirements, per-instance computing-
   related metrics or per-site aggregated computing-related metrics can
   be used in routing decision.  In deployment, using per-site
   aggregated computing-related metrics is a more practical choice.

   When a service packet is decapsulated on an Egress D-Router, it will
   be sent to the service instance within the edge site by looking up
   the destination address in the FIB.

   Within the edge site, Load balancing and/or NAT may be used if
   needed.  When using NAT, the D-SID will be translated into a unicast
   address associated to a specific service instance, and this unicast
   address is called D-BID(Dyncast Binding ID).  There is no needed to
   configure a B-SID for a service instance if NAT is not needed.

   In Figure 1, the "underlay infrastructure" indicates the general IP
   infrastructure that does not need to support Dyncast.  The Dyncast
   routes will be distributed amomg the overlay D-Routers, and will not
   affect the underlay nodes.

   The above text describe a distributed architecture of Dyncast.
   However, a centralized architecture can also work.  In the
   centralized architecture, the computing-related metrics from the
   Egress D-Routers or D-MAs are collected by a centralized controller/

Li, et al.                Expires 20 July 2023                  [Page 6]
Internet-Draft            Dyncast Architecture              January 2023

   PCE.  Considering both the network-related metrics and computing-
   related metrics, the Controller/PCE can calculate the best path for a
   D-SID and send it to the related Ingress D-Router.

4.  Dyncast Architecture Workflow

   The following section provides an overview of how the Dyncast
   solution works in the distributed architecture.

4.1.  Service Announcements

   Normally, a service is associated with an IP address, which can be an
   IPv6 address.  In Dyncast, this IP address is called D-SID, and it
   can be used by multiple service instances, which makes it as an
   Anycast address in routing.  This address can be learned via DNS
   resolution or other mechanisms, this document will not limit this.

4.2.  Metric Distributions

   As described above, a D-MA will collect computing-related metrics and
   associates the metrics to a related D-SID route.  It will also send
   the D-SID route with the metrics to the connected Egress D-Router.
   The Egress D-Router will distribute the D-SID route with the metrics
   to the related Ingress D-Routers.  The metrics include the computing-
   related metrics and potential other network metrics if needed.

   As explained in the problem statement document
   [I-D.liu-can-ps-usecases], computing metrics may change very
   frequently, when and how frequent such information should be
   distributed should be determined also in accordance with the
   distribution protocol used for such purpose.  A spectrum of
   approaches can be employed,such as interval based updates, threshold
   triggered updates, policy based updates, etc.

   The following example is provided for better understanding of how
   Dyncast metrics are distributed.  Routes of D-SID1 and D-SID2 with
   related metrics are sent from the D-MA to D-Router 2.  D-Router 2
   generates overlay routes of D-SID1 and D-SID2, and distribute them to
   the associated Ingress D-Router 1.

Li, et al.                Expires 20 July 2023                  [Page 7]
Internet-Draft            Dyncast Architecture              January 2023

 D-SID: Dyncast Service ID
                                                       +-------+
                                                     +-------+ |
                                                     |Clients|-+         +-------+
                                                     +-------+        +--|D-SID 1| instance 1
                                                         |            |  +-------+
                                                   +----------+----+  |              Edge 2
                                                   |D-Router 2|D-MA|--|
          Dyncast Forwarding Table                 +----------+----+  |  +-------+
 D-SID 1, <metrics>, overlay path to D-router 2          |            +--|D-SID 2| instance 2
 D-SID 2, <metrics>, overlay path to D-router 2  +----------------+      +-------+
 D-SID 1, <metrics>, overlay path to D-router 3  |                |
 D-SID 2, <metrics>, overlay path to D-router 3  |                |
 +------+     +----------+                       |    Underlay    |
 |Client|-----|D-Router 1|-----------------------| Infrastructure |
 +------+     +----------+                       |                |
                                                 |                |
                                                 |                |        +-------+
                                                 +----------------+    +---|D-SID 2| instance 3
                                                         |             |   +-------+
                                                   +----------+     +------+            Edge 3
                                                   |D-Router 3|-----| D-MA |
                                                   +----------+     +------+
                                                                       |   +-------+
                                                                       +---|D-SID 1| instance 4
                                                                           +-------+
                   <--------------------------------        <--------------
                 (Overlay route of D-SID 1, <metrics>)      (D-SID 1, <metrics>)
                 (Overlay route of D-SID 2, <metrics>)      (D-SID 2, <metrics>)
                     Service overlay route with metrics     Service route with metrics

                Figure 2: Dyncast deployment example.

4.3.  Service Demand Handling

   Ingress D-Routers can make their routing decision based on the
   received routes and metrics.  The metrics include network-related
   metrics and computing-related metrics, while the network metrics can
   be learned by detecting on the ingress D-Router, and the computing-
   related metrics are learned from the received D-SID's routes.  This
   document will not define any algorithm of making the routing
   decision.  The routing decision may indicate the Ingress D-Router to
   encapsulate the service packets into an overlay path towards to the
   'best' Egress D-Router.  In the example provided in above figure, the
   Ingress D-Router 1 generate the routes of D-SID1 and D-SID2 with next
   hop as an overlay path to a specific Egress D-router 2 or D-Router 3.

Li, et al.                Expires 20 July 2023                  [Page 8]
Internet-Draft            Dyncast Architecture              January 2023

   When a new service transaction starts, an initial service packet is
   sent from the client to its Dyncast Ingress D-Router.  Upon receiving
   the service packet, the ingress will forward the packets to the
   'best' egress D-Router through an overlay path.  When the service
   packet reaches the egress D-router, the outer header of the overlay
   encapsulation will be decapsulated and the inner service packet will
   be sent to the 'best' service instance.

4.4.  Instance Affinity

   Instance affinity is one of the key features that Dyncast should
   support.  It means that packets from the same 'flow' for a service
   should always be sent to the same egress to be processed by the same
   service instance.  The affinity is determined at the time of newly
   formulated service demand.

   Note: Different services may have different notions of what
   constitutes a 'flow' and may thus identify a flow differently.
   Typically a flow is identified by the 5-tuple value.  However, for
   instance, an RTP video streaming may use different port numbers for
   video and audio, and it may be identified as two flows if 5-tuple
   flow identifier is used.  However they certainly should be treated by
   the same service instance.  Therefore a 3-tuple based flow identifier
   is more suitable for this case.  Hence, it is desired to provide
   certain level of flexibility in identifying flows, or from a more
   general perspective, in identifying the set of packets for which to
   apply instance affinity.  More importantly, the means for identifying
   a flow for the purpose of ensuring instance affinity must be
   application-independent to avoid the need for service-specific
   instance affinity methods.

   Specifically, Instance affinity information should be configurable on
   a per-service basis.  For each service, the information can include
   the flow/packets identification type and means, affinity timeout
   value, and etc.

   This document will not define the specific mechanism of affinity, and
   it can be discussed in specific solution drafts.

5.  Security Considerations

   The computing resource information changes over time very frequent
   with the creation and termination of service instance.  When such
   information is carried in routing protocol, too many updates can make
   the network fluctuate.  Control plane approach should take it into
   considerations.

Li, et al.                Expires 20 July 2023                  [Page 9]
Internet-Draft            Dyncast Architecture              January 2023

6.  IANA Considerations

   TBD

7.  Contributors

   *  Huijuan Yao, yaohuijuan@chinamobile.com, China Mobile

   *  Xia Chen, jescia.chenxia@huawei.com, Huawei

   *  Jianwei Mao, maojianwei@huawei.com

   *  Hang Shi, shihang9@huawei.com, Huawei

8.  References

8.1.  Normative References

   [RFC2119]  Bradner, S. and RFC Publisher, "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>.

   [RFC8174]  Leiba, B. and RFC Publisher, "Ambiguity of Uppercase vs
              Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174,
              DOI 10.17487/RFC8174, May 2017,
              <https://www.rfc-editor.org/info/rfc8174>.

8.2.  Informative References

   [I-D.liu-can-ps-usecases]
              Liu, P., Eardley, P., Trossen, D., Boucadair, M.,
              Contreras, L. M., Li, C., and Y. Li, "Computing-Aware
              Networking (CAN) Problem Statement and Use Cases", Work in
              Progress, Internet-Draft, draft-liu-can-ps-usecases-00, 23
              October 2022, <https://www.ietf.org/archive/id/draft-liu-
              can-ps-usecases-00.txt>.

   [I-D.liu-dyncast-ps-usecases]
              Liu, P., Eardley, P., Trossen, D., Boucadair, M.,
              Contreras, L. M., Li, C., and Y. Li, "Dynamic-Anycast
              (Dyncast) Problem Statement and Use Cases", Work in
              Progress, Internet-Draft, draft-liu-dyncast-ps-usecases-
              04, 8 July 2022, <https://www.ietf.org/archive/id/draft-
              liu-dyncast-ps-usecases-04.txt>.

Authors' Addresses

Li, et al.                Expires 20 July 2023                 [Page 10]
Internet-Draft            Dyncast Architecture              January 2023

   Yizhou Li
   Huawei Technologies
   China
   Email: liyizhou@huawei.com

   Luigi Iannone
   Huawei Technologies
   Email: Luigi.iannone@huawei.com

   Dirk Trossen
   Huawei Technologies
   Email: dirk.trossen@huawei.com

   Peng Liu
   China Mobile
   China
   Email: liupengyjy@chinamobile.com

   Cheng Li (editor)
   Huawei Technologies
   China
   Email: c.l@huawei.com

Li, et al.                Expires 20 July 2023                 [Page 11]