Internet-Draft draft-fu-computing- notification-domain- October 2022
Fu Expires 27 April 2023 [Page]
Workgroup:
Inter-Domain Routing
Internet-Draft:
draft-fu-computing- notification-domain -00
Published:
Intended Status:
Informational
Expires:
Author:
Y. Fu
China mobile

Computing resource notification domain in network

Abstract

This document introduces the requirements of notification domain definition and the process of service scheduling decision based on the notification domain in the network.

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 27 April 2023.

Table of Contents

1. Introduction

In the existing computing information notification schemes, computing information status notification is made by extending BGP (Border Gateway Protocol) to the whole network, without defining the scope of the notification, so that all the routers on the whole network need to maintain the service computing information of the whole network, and the routing table is too large, which causes the burden to the network and routers. The shortcoming of the existing technology is that the existing computing information notification scheme increases the amount of information notification in the network.

This document introduces the requirements of notification domain definition and the process of service scheduling decision based on the notification domain in the network.

2. Requirements of the partitioning and adjustment of the notification domain

The CAN system contains the control plane and the forwarding plane. The control plane in the CAN network needs to obtain the computing information of the servers for a service, and monitor the tunnel/ policy statuses to the potential Egresses for the service. As described in [I-D.liu-dyncast-reqts], the representation and encoding of computing metric is crucial, which is conveyed to CAN system to support the CAN components to act upon. The representation needs to express the capabilities of computing resources accurately, the requirements contains several aspects as described below. o Support to determine the notification domain based on the computing service topology. o Support the notification domain is the division of adjacent domains into a notification domain based on geographical location, and/or the division of areas with the same service deployment into a notification domain based on service dimension. o Support that the notification domain is divided according to the geographical location and then the advertisement relationship between each autonomous domain is determined according to the existing AS domain in the IP protocol. o Support that when the size of the notification domain is determined, according to the network status information, the notification domain is expanded when the network status is good, and the notification domain is reduced when the network status is bad. o Support that when the notification domain is divided according to services, the size of the notification domain is determined according to the number of nodes deployed in the notification domain.

3. Process of service scheduling decision based on the notification domain

The computing information notification method is proposed to reduce the amount of computing notification information.

Step 1: The central controller determines the notification domain

Option 1: The central controller could determine the notification domain based on the computing service topology. The generation of computing service topology includes the identification information of computing service and the location information of computing service deployment, and advertising the service topology information; and then advertises service status information on the established service topology. During implementation, the computing service topology is generated based on the network topology and computing node topology generated by BGP-LS; and the service topology information is advertised through BGP-LS and DHCP by adding computing service information to the node attribute field.

Option 2: The central controller obtains the AS autonomous domain division strategy of the whole network and determines the size of the notification domain by combining the network status information of different regions. The network status information is reported by nodes to the central controller.

Option 3: The central controller receives the inter-domain router network state information, service deployment information, as well as generating capacity after list, according to the different domain partition strategy to subscribe to the node network status information or services generated after the deployment information, and distributed to the inter-domain router for its configuration.

Step 2: The central controller advertises the notification domain partitioning policy. The notification domain partitioning policy carried through Netconf and Yang management protocol is delivered. In practice, the notification domain is identified as follows:

 The number of AS through which the computational update information passes is set, and the hop limit is set to identify it. Or,

 Routers in the same advertisement domain are divided into the same community by using the BGP community attribute to identify the advertisement domain

Step 3: The central controller advertises computing information to nodes in the notification domain.

Step 4: When the central controller schedules service requests, it selects the computing nodes that need to obtain real-time service status information through the generated computing service topology and sends the detection packet of service status information.

Step 5: The notification domain adjustment policy generation When adjusting the size of the notification field, it further includes: The notification domain adjustment policy carried through Netconf and Yang management protocol is delivered based on one or a combination of the network status information, service scheduling result feedback information, and service deployment.

4. IANA Considerations

TBD

5. Security Considerations

TBD

6. Acknowledgements

TBD

7. Normative References

[RFC2119]
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels".

Author's Address

Yuexia Fu
China mobile
No.32 XuanWuMen West Street
Beijing
100053
China