Internet DRAFT - draft-du-coordination-for-serivce-ip-in-mec

draft-du-coordination-for-serivce-ip-in-mec







Network Working Group                                              Z. Du
Internet-Draft                                              China Mobile
Intended status: Informational                           16 January 2023
Expires: 20 July 2023


       Coordination for Service IP in Multi-access Edge Computing
             draft-du-coordination-for-serivce-ip-in-mec-00

Abstract

   This document describes a coordinatable mechanism for the Service IP
   in Multi-access Edge Computing.  The Service IP means that an IP
   address is associated with a specific service in the network.  For
   example, the IP address is deployed as an anycast address for
   Computing Aware Networking (CAN).

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

Copyright Notice

   Copyright (c) 2023 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.



Du                        Expires 20 July 2023                  [Page 1]

Internet-Draft     Coordination for Service IP in MEC       January 2023


   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.  Problem Statement . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Coordinatable CAN . . . . . . . . . . . . . . . . . . . . . .   4
   4.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   5
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   5
   6.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   5
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   5
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .   5
     7.2.  Informative References  . . . . . . . . . . . . . . . . .   5
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   6

1.  Introduction

   In Computing Aware Networking (CAN), the network nodes need to be
   aware of the statues of the service, so as to do a more reasonable
   Load Balancing (LB) job in a distributed way for the service as
   mentioned in [I-D.liu-can-gap-reqs] and [I-D.liu-can-ps-usecases].
   In this situation, the destination address of a CAN packet is a
   service IP or called a service ID, because it is not only an IP
   address for the location, but also an ID related to a specific
   service.

   In CAN, it is assumed that multiple places including the cloud and
   the MECs in the network have deployed a specific service, and
   multiple places will announce the route for the service IP which
   works as an anycast address.  In the traditional anycast mechanism,
   the network will forward an anycast packet to a nearest server
   normally in a cloud without considering whether the server is busy or
   not.  In the MEC scenarios, the computing ability is limited, and
   thus there is a higher possibility that the server is busy in the
   MEC.  Therefore, in the CAN mechanism, the anycast mechanism is
   extended to enable the network to be aware of the service
   information, so as to make a better LB.

   However, comparing to the centralized mechanism, in which we assume
   that a central scheduler is aware of all the service statuses in
   different places, the distributed mechanisms in CAN are short of
   coordination abilities among different service places.





Du                        Expires 20 July 2023                  [Page 2]

Internet-Draft     Coordination for Service IP in MEC       January 2023


   In this document, we introduce a mechanism to coordinate different
   service points that are providing the same service associated with
   the service IP, and thus can improve the resource utilization.



2.  Problem Statement

   We assume that three servers in different MECs are providing the same
   service associated with the same service IP.  In the CAN mechanism,
   the Ingress node in the network can obtain the service information,
   and forward the CAN packet targeted to the Server IP to a proper
   Egress and server.


 +--------+   +---------+   +-------+   +---------+   +----------------+
 | Client |---| Ingress |---| Nodes |---| Egress1 |---|  MEC1 (Server1 |
 +--------+   +---------+   +-------+   +---------+   | with Service1) |
                             |   |                    +----------------+
                             |   |      +---------+   +----------------+
                             |   |------| Egress2 |---|  MEC2 (Server2 |
                             |          +---------+   | with Service1) |
                             |                        +----------------+
                             |          +---------+   +----------------+
                             |----------| Egress3 |---|  MEC3 (Server3 |
                                        +---------+   | with Service1) |
                                                      +----------------+
  Figure 1: Topology for the Coordinatable CAN network in which the
              servers in the MEC can be active or inactive


   In the CAN mechanism, the Egress nodes can obtain the service
   information in the MEC.  The Ingress can obtain the service
   information from the Egress nodes by using BGP for example.  Thus,
   the Ingress node can make a LB with considering both the network and
   the service information.

   The information on the Ingress will be updated continuingly, so that
   if a specific server is heavy load, the Ingress node can change the
   target Egress and server.  In the situation that many clients are
   accessing the Service1, the Ingress node will make a LB among the
   servers in different MECs because the "best" server is dynamic.

   If there are fewer clients of Service1, an MEC, such as MEC3, may
   close the Service1 instance, so that it can provide other services
   better or save the electricity.  In this situation, the Ingress node
   will not forward any CAN packet to Egress3.




Du                        Expires 20 July 2023                  [Page 3]

Internet-Draft     Coordination for Service IP in MEC       January 2023


   However, if there are more clients need to access Service1 in the
   network again, we need to reactivate the Server3.  In a centralized
   mechanism, a central scheduler can reactivate the Server3 after
   detecting the load statuses of the Server1 and the Server2.  As a
   comparison, we have no mechanism currently to reactivate the Server3
   in the MEC3 in the distributed scenarios in which we do not have a
   central scheduler that knows all the statuses.


3.  Coordinatable CAN

   In fact, the Egress3 or the Ingress can monitor the computing or
   service load information for Service1 announced by the Egress1 and
   the Egress2.  After it detects the MEC2 and the MEC3 are both heavy
   load, it can trigger the reactivation of the Service1 in the Server3.
   As we announce the service information from Egress nodes to Ingress
   nodes by using BGP [RFC4217], we need to support the trigger in BGP,
   too.  In addition, if the Egress and the gateway of the MEC are also
   communicating the service information by using BGP, the Egress can
   also send the reactivation trigger to the gateway.

   For the reactivation trigger, we propose a general mechanism by using
   BGP for it.  The main procedures are as follows:

   Step1: Egress1 and Egress2 will notify that they can support Service1
   and the service information, such as the server load.  Egress3 should
   notify that it can support Service1, but it is inactive now.

   Step2: After receiving the information from the Egress nodes,
   accordingly, Ingress will only use the Egrees1 and Egress2 to make
   the LB process.

   Step3: When necessary, the decision point, which wants to active the
   Service1 in the Server3, triggers the reactivation of the Service1 in
   the Server3 by sending a message to Egress3.  Further, the Egress3
   may trigger the reactivation of the Service1 in the Server3 by
   sending a message to the gateway of the MEC3.  The way of
   communications between the gateway and the Server3 is out of scope of
   this document.

   Step4: The Service1 instance is reactivated in the Server3, and the
   Egress3 receives the service information in the Server3.

   Step5: Egress3 notifies the Ingress that it can support the Service1,
   and the related service information.  In the notification, the active
   Flag should be changed from inactive to active.





Du                        Expires 20 July 2023                  [Page 4]

Internet-Draft     Coordination for Service IP in MEC       January 2023


   Step6: After receiving the information from the Egress3, accordingly,
   Ingress will use the Egrees1, Egress2, and Egress3 to make the LB
   process.

   As there is no message for service reactivation in BGP currently, we
   suggest enhancing the BGP Refresh message to notify the service
   reactivation demand.  In this situation, the enhanced BGP Refresh
   message should target to a specific service IP, and a specific Flag
   should be occupied to indicate the service reactivation demand.

4.  IANA Considerations

   TBD.

5.  Security Considerations

   TBD.

6.  Acknowledgements

   TBD.

7.  References

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

   [RFC4217]  Ford-Hutchinson, P., "Securing FTP with TLS", RFC 4217,
              DOI 10.17487/RFC4217, October 2005,
              <https://www.rfc-editor.org/info/rfc4217>.

7.2.  Informative References

   [I-D.liu-can-gap-reqs]
              Liu, P., Jiang, T., Eardley, P., Trossen, D., Li, C., and
              D. Huang, "Computing-Aware Networking (CAN) Gap Analysis
              and Requirements", Work in Progress, Internet-Draft,
              draft-liu-can-gap-reqs-00, 23 October 2022,
              <https://www.ietf.org/archive/id/draft-liu-can-gap-reqs-
              00.txt>.

   [I-D.liu-can-ps-usecases]
              Liu, P., Eardley, P., Trossen, D., Boucadair, M.,
              Contreras, L. M., Li, C., and Y. Li, "Computing-Aware



Du                        Expires 20 July 2023                  [Page 5]

Internet-Draft     Coordination for Service IP in MEC       January 2023


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

Author's Address

   Zongpeng Du
   China Mobile
   No.32 XuanWuMen West Street
   Beijing
   100053
   China
   Email: duzongpeng@foxmail.com





































Du                        Expires 20 July 2023                  [Page 6]