Internet DRAFT - draft-fu-idr-computing-info-notification-domain
draft-fu-idr-computing-info-notification-domain
Inter-Domain Routing Y. Fu
Internet-Draft China mobile
Intended status: Informational 20 October 2023
Expires: 22 April 2024
Computing resource notification domain in network
draft-fu-idr-computing-info-notification-domain-01
Abstract
This document introduces the definiation and the requirements of
notification domain, and also introduces 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 22 April 2024.
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.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
Fu Expires 22 April 2024 [Page 1]
Internet-Draft draft-fu-idr-computing-info-notification October 2023
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. Definition and Requirements of the notification domain . . . 3
3. Process of service scheduling based on the notification
domain . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
5. Security Considerations . . . . . . . . . . . . . . . . . . . 5
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5
7. Normative References . . . . . . . . . . . . . . . . . . . . 5
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5
1. Introduction
With the new services arising, the computing and network convergence
has become a new trend. The network could schedule the service
traffic considering the computing metric.There are several ways to
get the computing information. By the computing information
notification schemes, the routers in the network can synchronize
their connected local computing information among themselves,
eventually forming a global complete computing information. There
may be multiple computing information notification schemes, one is
that computing information status notification could 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 computing information of the
whole network, and the routing table is large, which causes the
burden to the network and routers. Exending BGP without limiting the
scope of computing information notification increases the amount of
computing information notification in the network, while the service
traffic steering is always among near area. So to reduce the useless
computing information notification in the network, and to improve the
effciency of the computing information notification scheme is
important.
This document introduces the definiation and the requirements of
notification domain, and also introduces the process of service
scheduling decision based on the notification domain in the network.
Fu Expires 22 April 2024 [Page 2]
Internet-Draft draft-fu-idr-computing-info-notification October 2023
2. Definition and Requirements of the notification domain
The routing system contains the control plane and the forwarding
plane. To achieve the computing and network coordination, the
control plane 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.yao-cats-
ps-usecases], the representation and encoding of computing metric is
crucial, which is conveyed to routing system to support the
components to act upon. The routers send the computing information
to the routers located in the given notification domain. If router 1
is outside of the notification domain of router 2, then router 2 will
not send computing information to router 1. The notification domain
needs to be defined accurately, the requirements contains several
aspects as described below. o Should support to determine the
notification domain based on the computing service topology. The
computing service topology contains information about the identity of
the computing service, as well as information about the location
where the computing service is deployed .o Should support to
determine the 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 Should support to
determine the notification domain according to the geographical
location and then the notification relationship between each
autonomous domain is determined according to the existing AS domain
in the IP protocol. o Should 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 Should 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 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. The notification domain could be defined based on the
Fu Expires 22 April 2024 [Page 3]
Internet-Draft draft-fu-idr-computing-info-notification October 2023
division of areas with the same service deployment into a
notification domain based on service dimension. 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 notification domain could be defined based on the
division of adjacent domains into a notification domain based on
geographical location, and 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:
o The number of AS through which the computational update information
passes is set, and the hop limit is set to identify it. Or,
o 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
Fu Expires 22 April 2024 [Page 4]
Internet-Draft draft-fu-idr-computing-info-notification October 2023
information, and service deployment. 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. 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.
4. IANA Considerations
This document makes no request of IANA.
Note to RFC Editor: this section may be removed on publication as an
RFC.
5. Security Considerations
TBD
6. Acknowledgements
TBD
7. 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>.
Author's Address
Yuexia Fu
China mobile
No.32 XuanWuMen West Street
Beijing
Beijing, 100053
China
Email: fuyuexia@chinamobile.com
Fu Expires 22 April 2024 [Page 5]
