Internet DRAFT - draft-zzd-tvr-use-case-tidal-network
draft-zzd-tvr-use-case-tidal-network
TVR L. Zhang, Ed.
Internet-Draft T. Zhou
Intended status: Standards Track J. Dong
Expires: 30 January 2024 Huawei
N. Nzima
MTN
29 July 2023
Use Case of Tidal Network
draft-zzd-tvr-use-case-tidal-network-02
Abstract
The tidal effect of traffic is very typical on our network, this
document introduces the time variant routing scenario in the tidal
network, and then describes the assumptions and routing impacts based
on the use case. Finally, an exempar of tidal network is provided.
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 30 January 2024.
Copyright Notice
Copyright (c) 2023 IETF Trust and the persons identified as the
document authors. All rights reserved.
Zhang, et al. Expires 30 January 2024 [Page 1]
Internet-Draft use case of tidal network July 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
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Routing Requirements . . . . . . . . . . . . . . . . . . . . 3
4. Exemplar . . . . . . . . . . . . . . . . . . . . . . . . . . 4
5. Security Considerations . . . . . . . . . . . . . . . . . . . 5
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
7. Normative References . . . . . . . . . . . . . . . . . . . . 5
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6
1. Introduction
The tidal effect of traffic is very typical on our network, and the
traffic volume varies greatly at different time. For example, in the
Chinese New Year, there are 200 million people move from their work
town to home town, and these people generate huge traffic on our
network. For the campus network, there are thousands of people go to
the Teaching buildings, libraries and labs in the daytime and go to
dormitory in the night. Therefore, the traffic of different places
in the campus fluctuate obviously and regularly.
In the previous scenarios, If the network maintains all the devices
up to guarantee the maximum throughput all the time, a lot of power
will be wasted. Therefore, it is an effective energy-saving method
to shut down some devices when the traffic is at a low level. Thus,
a scenario in which the network connection status can be predicted is
formed in the tidal network.
This document introduces the time variant routing scenario in the
tidal network, and then describes the assumptions and routing impacts
based on the use case. Finally, an exemplar of tidal network is
provided.
Zhang, et al. Expires 30 January 2024 [Page 2]
Internet-Draft use case of tidal network July 2023
1.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.
2. Assumptions
In order to reduuce energy consumption based on the regularity of
tidal traffic, the controller or other control device needs to know
the regularity of traffic changing. It is assumed that there is a
algorithm that can calculates which nodes and links should be
disabled or enabled under different traffic scales.
1. Knowing the regularity of tidal traffic, It is assumed that the
controller or other control device knows the regularity of tidal
traffic, and the change of traffic in the future can be
predicated. The regularity information may come from the manual
input or the results of computer's calculation.
2. An algorithm to calculate which nodes or links can be disabled or
enabled under different traffic scales. It is assumed that the
controller or other control device supports a algorithm to
calculate the minimal topology that satisfies the requirements of
traffic at different time. Based on that, it is known which
nodes or link should be disabled or enabled under different
traffic scales.
3. Routing Requirements
The change of link status will change the topology of network.
Furthermore, the data forwarding may be affected and result in packet
disorder or packet loss. In order to solve these problems, the
existing routing protocols need to provide the following
capabilities.
1. Data model with time-variant information. There is a need for
the nodes or controllers to deliver the predicated time-variant
information by specific data model or structure. For the tidal
network, the change of network topology usually has a regular
period but may has multiple regularities (For example, the
regularity of traffic in campus network is quite different on
weekdays and weekend).
Zhang, et al. Expires 30 January 2024 [Page 3]
Internet-Draft use case of tidal network July 2023
2. Collection and advertisement for the time-variant information of
each node and link. For the distributed routing protocols, each
node needs to calculate the routing table by itself, so each node
needs to advertise its own time-variant information to other
nodes (This step is not necessary when every node knows all of
the time-variant information about the topology). For the
centralized routing protocols, the controller is responsible for
the calculation of routing path, so the controller may need to
collect the time-variant information of all the nodes (It is also
not necessary when the controller knows all of the time-variant
information about the topology by other means).
3. Routing algorithm based on time-variant information. When the
routing calculator knows the time-variant information of each
node, a new algorithm is needed to calculate the routing paths
based on the time-variant information, it may be quite different
from the existing algorithms.
4. Routing path with time-variant information. The routing path is
calculated based on the time-variant topology, so the change of
topology will also affect the routing path. Therefore, the
routing path may need be expressed with a time-variant
information which is associated with the change of the topology
so that the node can schedule paths according to their time-
variant information.
4. Exemplar
One example of a network with tidal traffic is the campus network,
the traffic in the dormitory will raise in the evening and drop in
the morning. In contrast, the traffic in the library will raise in
the morning and almost drop to zero at night. the traffic of campus
changes with a significant period.
Consider a four nodes network for the dormitory, the traffic of the
network will raise at 12 o'clock and drop to the low level at 14
o'clock, then it will raise at 21 o'clock and drop to the low level
at 2 o'clock. The traffic at different time is shown in Figure 1.
T |
R | ------
A | ---- / \
F | / \ / \
F | / \ / \
I |/ ----------------- ----
C +---------++--------------++-----------++---
12 16 21 2
Time
Zhang, et al. Expires 30 January 2024 [Page 4]
Internet-Draft use case of tidal network July 2023
Figure 1: Traffic of the network at different time
The topology of network is shown in Figure 2
N1---------L1---------N2
| \ / |
| \ / |
| \ / |
| L6 L5 |
L2 \/ L3
| / \ |
| / \ |
| / \ |
| / \ |
N3--------L4----------N4
Figure 2: Topology of a four node network
In order to reduce the power consumption, some of the links may be
shut down when the traffic is at a low level. For example, link L5
and L6 can be shut down from 16:00 to 21:00 and from 2:00 to 12:00,
so the possible time-variant topology is as shown in Figure 3
N1---------L1---------N2 N1---------L1---------N2
| \ / | | |
| \ / | | |
| \ / | | |
| L6 L5 | | |
L2 \/ L3 L2 L3
| / \ | | |
| / \ | | |
| / \ | | |
| / \ | | |
N3---------L4---------N4 N3---------L4---------N4
Topology1 (12:00-16:00 and 21:00-2:00) Topology 2(16:00-21:00 and 2:00-12:00)
Figure 3: Time-variant topology
5. Security Considerations
TBD
6. IANA Considerations
TBD
7. Normative References
Zhang, et al. Expires 30 January 2024 [Page 5]
Internet-Draft use case of tidal network July 2023
[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>.
[RFC8174] Leiba, B., "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>.
Authors' Addresses
Li Zhang (editor)
Huawei
Beiqing Road
Beijing
China
Email: zhangli344@huawei.com
Tianran Zhou
Huawei
Email: zhoutianran@huawei.com
Jie Dong
Huawei
Email: jie.dong@huawei.com
Nkosinathi Nzima
MTN
Email: Nkosinathi.Nzima@mtn.com
Zhang, et al. Expires 30 January 2024 [Page 6]
