Skip to main content

Use Case of Tidal Network
draft-zzd-tvr-use-case-tidal-network-01

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 Li Zhang , Tianran Zhou , Jie Dong
Last updated 2023-07-09 (Latest revision 2023-03-25)
Replaces draft-zzl-tvr-use-case-tidal-network
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-zzd-tvr-use-case-tidal-network-01
TVR                                                        L. Zhang, Ed.
Internet-Draft                                                   T. Zhou
Intended status: Standards Track                                 J. Dong
Expires: 11 January 2024                                          Huawei
                                                            10 July 2023

                       Use Case of Tidal Network
                draft-zzd-tvr-use-case-tidal-network-01

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

Zhang, et al.            Expires 11 January 2024                [Page 1]
Internet-Draft          use case of tidal network              July 2023

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Requirements Language . . . . . . . . . . . . . . . . . .   2
   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.

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.

Zhang, et al.            Expires 11 January 2024                [Page 2]
Internet-Draft          use case of tidal network              July 2023

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

Zhang, et al.            Expires 11 January 2024                [Page 6]