RFC 8455
Terminology for Benchmarking Software-Defined Networking (SDN) Controller Performance
Terminology for Benchmarking Software-Defined Networking (SDN) Controller Performance ✨
okay bestie, this is RFC 8455 🎀, published by the IETF in October 2018. It's an Informational doc, so it's not a Standards Track spec. It's here to share knowledge 🧚. The authors are V. Bhuvaneswaran and A. Basil (Veryx Technologies), M. Tassinari (Hewlett Packard Enterprise), V. Manral (NanoSec), and S. Banks (VSS Monitoring). Its ISSN is 2070-1721. The header doesn't list any RFCs it obsoletes or updates, so it's just doing its own thing 🦋.
Abstract
This doc defines terminology for benchmarking a Software-Defined Networking (SDN) controller's control-plane performance 🧠. It extends the terminology already defined in RFC 7426 for benchmarking SDN Controllers. The terms help you benchmark an SDN Controller's performance independently of the controller's supported protocols and/or network services 💅.
Status of This Memo
This doc is not an Internet Standards Track spec. It's published for informational purposes 📚.
It's a product of the Internet Engineering Task Force (IETF) and represents the consensus of the IETF community 🫶. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). Not every IESG-approved doc is a candidate for any level of Internet Standard, so see Section 2 of RFC 7841 🙈.
For the current status, any errata, and how to give feedback, check out https://www.rfc-editor.org/info/rfc8455 🌸.
Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved ©️.
This doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) as in effect on the date of publication 📜. Please read these carefully, because they explain your rights and restrictions with respect to this doc. Code Components extracted from this doc must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they're provided without warranty as described in the Simplified BSD License 🔥.
Table of Contents
1. Introduction ....................................................3
1.1. Conventions Used in This Document ..........................3
2. Term Definitions ................................................4
2.1. SDN Terms ..................................................4
2.1.1. Flow ................................................4
2.1.2. Northbound Interface ................................4
2.1.3. Southbound Interface ................................5
2.1.4. Controller Forwarding Table .........................5
2.1.5. Proactive Flow Provisioning Mode ....................5
2.1.6. Reactive Flow Provisioning Mode .....................6
2.1.7. Path ................................................6
2.1.8. Standalone Mode .....................................6
2.1.9. Cluster/Redundancy Mode .............................7
2.1.10. Asynchronous Message ...............................7
2.1.11. Test Traffic Generator .............................7
2.1.12. Leaf-Spine Topology ................................8
2.2. Test Configuration/Setup Terms .............................8
2.2.1. Number of Network Devices ...........................8
2.2.2. Trial Repetition ....................................8
2.2.3. Trial Duration ......................................9
2.2.4. Number of Cluster Nodes .............................9
2.3. Benchmarking Terms .........................................9
2.3.1. Performance .........................................9
2.3.1.1. Network Topology Discovery Time ............9
2.3.1.2. Asynchronous Message Processing Time ......10
2.3.1.3. Asynchronous Message Processing Rate ......10
2.3.1.4. Reactive Path Provisioning Time ...........11
2.3.1.5. Proactive Path Provisioning Time ..........12
2.3.1.6. Reactive Path Provisioning Rate ...........12
2.3.1.7. Proactive Path Provisioning Rate ..........13
2.3.1.8. Network Topology Change Detection Time ....13
2.3.2. Scalability ........................................14
2.3.2.1. Control Sessions Capacity .................14
2.3.2.2. Network Discovery Size ....................14
2.3.2.3. Forwarding Table Capacity .................15
2.3.3. Security ...........................................15
2.3.3.1. Exception Handling ........................15
2.3.3.2. Handling Denial-of-Service Attacks ........16
2.3.4. Reliability ........................................16
2.3.4.1. Controller Failover Time ..................16
2.3.4.2. Network Re-provisioning Time ..............17
3. Test Setup .....................................................17
3.1. Test Setup - Controller Operating in Standalone Mode ......18
3.2. Test Setup - Controller Operating in Cluster Mode .........19
4. Test Coverage ..................................................20
5. IANA Considerations ............................................21
6. Security Considerations ........................................21
7. Normative References ...........................................21
Acknowledgments ...................................................22
Authors' Addresses ................................................231. Introduction ✨
Software-Defined Networking (SDN) is a networking architecture where network control is decoupled from the underlying forwarding function and placed in a centralized spot called the SDN Controller 🎯. The SDN Controller gives you an abstraction of the underlying network and a global view of the whole network for applications and business logic 👑. So the SDN Controller lets you program, control, and manage network behavior dynamically through northbound and southbound interfaces, which is iconic 💖.
Since the network controls are logically centralized, benchmarking the SDN Controller's performance becomes super important 🔥. This doc defines terms for benchmarking various controller designs for performance, scalability, reliability, and security, independently of northbound and southbound protocols 🦋. A mechanism for benchmarking SDN Controller performance is defined in the companion methodology doc [RFC8456]. Together, these two docs give you methods for measuring and evaluating the performance of various controller implementations 🧚.
1.1. Conventions Used in This Document
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. Term Definitions 🎀
2.1. SDN Terms
The terms in this section extend the terms defined in [RFC7426] ("Software-Defined Networking (SDN): Layers and Architecture Terminology"). Read [RFC7426] before you try using this doc, bestie 🫶.
2.1.1. Flow
Definition: The definition of "flow" is the same as the definition of "microflows" provided in Section 3.1.5 of [RFC4689].
Discussion: A flow can be a set of packets with the same source address, destination address, source port, and destination port, or any combination of these items 🌈.
Measurement Units: N/A
2.1.2. Northbound Interface
Definition: The definition of "northbound interface" is the same as the definition of "service interface" provided in [RFC7426].
Discussion: The northbound interface lets SDN applications and orchestration systems program and retrieve network information through the SDN Controller 💜.
Measurement Units: N/A
2.1.3. Southbound Interface
Definition: The southbound interface is the application programming interface the SDN Controller provides to interact with SDN nodes ⭐.
Discussion: The southbound interface lets the controller interact with SDN nodes in the network to dynamically define traffic forwarding behavior 🍓.
Measurement Units: N/A
2.1.4. Controller Forwarding Table
Definition: A controller Forwarding Table holds flow entries that get learned in one of two ways 🧩. First, entries can be learned from traffic received through the data plane. Second, entries can be statically provisioned on the controller and distributed to devices via the southbound interface.
Discussion: The controller Forwarding Table has an aging mechanism, but it's applied only to dynamically learned entries ⏳.
Measurement Units: N/A
2.1.5. Proactive Flow Provisioning Mode
Definition: The controller programs flows in Network Devices based on the flow entries provisioned through the controller's northbound interface 🗂️.
Discussion: Network orchestration systems and SDN applications can define network forwarding behavior by programming the controller, using Proactive Flow Provisioning 🧁. The controller can then program the Network Devices with the pre-provisioned entries ✨.
Measurement Units: N/A
2.1.6. Reactive Flow Provisioning Mode
Definition: The controller programs flows in Network Devices based on the traffic it receives from Network Devices through the controller's southbound interface 📡.
Discussion: The SDN Controller dynamically decides forwarding behavior based on incoming traffic from the Network Devices 🏃♀️. The controller then programs the Network Devices, using Reactive Flow Provisioning 💫.
Measurement Units: N/A
2.1.7. Path
Definition: Refer to Section 5 in [RFC2330].
Discussion: None
Measurement Units: N/A
2.1.8. Standalone Mode
Definition: A single controller handles all control-plane functionalities without redundancy, so it can't provide high availability and/or automatic failover 😭.
Discussion: In standalone mode, one controller manages one or more network domains 🏠.
Measurement Units: N/A
2.1.9. Cluster/Redundancy Mode
Definition: In this mode, a group of two or more controllers handles all control-plane functionalities 🤝.
Discussion: In cluster mode, multiple controllers team up for load sharing and/or high availability 💪. Depending on the intended purpose, the controllers in the group may operate in active/standby (master/slave) or active/active (equal) mode 👯♀️.
Measurement Units: N/A
2.1.10. Asynchronous Message 📬
Definition: Any message from the Network Device that is generated for network events.
Discussion: Okay so control messages like flow setup request and response messages count as asynchronous messages 💅. The controller has to send back a response message. Also, the Network Device will not be in blocking mode, so it keeps sending and receiving other control messages while it waits. Iconic multitasking 🧚.
Measurement Units: N/A
2.1.11. Test Traffic Generator 🚦
Definition: The test traffic generator is an entity that generates and receives network traffic.
Discussion: It usually connects to Network Devices so it can send and receive real-time network traffic 🌊.
Measurement Units: N/A
2.1.12. Leaf-Spine Topology 🌿
Definition: "Leaf-Spine" is a two-layered network topology. A bunch of leaf switches form the access layer, and they're fully meshed to a bunch of spine switches that form the backbone layer. Very structured, very slay 💎.
Discussion: In a Leaf-Spine topology, every leaf switch is connected to each of the spine switches. No one gets left out 🫶.
Measurement Units: N/A
2.2. Test Configuration/Setup Terms ⚙️
2.2.1. Number of Network Devices 🔢
Definition: The number of Network Devices present in the defined test topology.
Discussion: The Network Devices in the test topology can be real hardware, or they can be emulated on hardware platforms. Both are giving valid vibes 🧪.
Measurement Units: Number of Network Devices.
2.2.2. Trial Repetition 🔁
Definition: The number of times the test needs to be repeated.
Discussion: The test has to run for multiple iterations so you can get a reliable metric 📊. It is recommended that this test SHOULD be performed for at least 10 iterations to increase confidence in the measured results. Run it again, bestie, it's worth it 💖.
Measurement Units: Number of trials.
2.2.3. Trial Duration ⏱️
Definition: Defines how long the test trials last for each iteration.
Discussion: The Trial Duration is the basis for the "stop" criteria in benchmarking tests. Trials that aren't completed within this time interval are considered incomplete. Not finished in time? Not counted, sorry bestie 🙈.
Measurement Units: Seconds.
2.2.4. Number of Cluster Nodes 🧩
Definition: Defines the number of controllers present in the controller cluster.
Discussion: This one matters when you're testing a controller's performance in clustering or teaming mode 👑. The number of nodes in the cluster MUST be greater than 1.
Measurement Units: Number of controller nodes.
2.3. Benchmarking Terms 📏
This section defines metrics for benchmarking the SDN Controller. The procedure for performing the defined metrics is defined in the companion methodology document [RFC8456]. Go read that one next, it's the how-to 📖✨.
2.3.1. Performance 🚀
2.3.1.1. Network Topology Discovery Time 🗺️
Definition: The time the controller(s) take to determine the complete network topology. It's measured from the first discovery message the controller(s) send on their southbound interface, until all features of the static topology have been determined.
Discussion: Topology discovery is key for the SDN Controller to provision and manage the network, so it matters how quickly the controller learns the current network state 👀. This benchmark is obtained by presenting a network topology (tree, mesh, or linear) with a specified number of nodes to the controller, then waiting for the discovery process to finish. The controller is expected to support a network discovery mechanism and use protocol messages for its discovery process. Main character discovery energy 🦋.
Measurement Units: Milliseconds.
2.3.1.2. Asynchronous Message Processing Time ⏳
Definition: The time the controller(s) take to process an asynchronous message. It starts with an asynchronous message from a Network Device after the controller(s) have discovered all the devices, and ends with a response message from the controller(s) on their southbound interface.
Discussion: For SDN to support dynamic provisioning, the controller has to react quickly to events from the network 🏃♀️. The event can be any notification a Network Device generates when a new flow arrives, a link goes down, and so on. This benchmark is obtained by sending asynchronous messages from every connected Network Device, one at a time, for the defined Trial Duration. This test assumes the controller will respond to the asynchronous messages it receives. Respond, queen 👑.
Measurement Units: Milliseconds.
2.3.1.3. Asynchronous Message Processing Rate 📈
Definition: The number of responses to asynchronous messages per second (a new flow arrival notification, a link down, etc.) for which the controller(s) did the processing and replied with a valid and productive (non-trivial) response message.
Discussion: SDN is all about flexible networks and agile provisioning, so it's important to know how many network events the controller can handle at once 🤯. This benchmark is measured by sending asynchronous messages from every connected Network Device at the rate the controller can process them without dropping any. This test assumes the controller responds to all the asynchronous messages it receives. (The messages can be designed to get individual responses.)
When you send asynchronous messages to the controller(s) at high rates, some messages or responses may be discarded or corrupted and need to be retransmitted to the controller(s) 😬. So a useful qualifier on the Asynchronous Message Processing Rate is whether the incoming message count equals the response count in each trial. This is called the Loss-Free Asynchronous Message Processing Rate 🫧.
Note that several of the early controller benchmarking tools didn't consider lost messages, and instead reported the maximum response rate. This is called the Maximum Asynchronous Message Processing Rate 🏎️.
To characterize both the Loss-Free and the Maximum Asynchronous Message Processing Rates, a test can start its first trial by sending asynchronous messages to the controller(s) at the maximum possible rate. It then records the message reply rate and the message loss rate. The message-sending rate is then decreased by the STEP size, and the message reply rate and message loss rate are recorded again. The test ends with a trial where the controller(s) process all of the asynchronous messages sent without loss. That's the Loss-Free Asynchronous Message Processing Rate 💖.
The trial where the controller(s) produced the maximum response rate is the Maximum Asynchronous Message Processing Rate. Of course, the first trial can also begin at a low sending rate with zero lost responses, then increase the rate until both the Loss-Free and the Maximum Asynchronous Message Processing Rates are found 🌈.
Measurement Units: Messages processed per second.
2.3.1.4. Reactive Path Provisioning Time ⚡
Definition: The time the controller takes to set up a path reactively between source and destination nodes. It's measured from the first flow provisioning request message the controller(s) receive, until the last flow provisioning response message they send on their southbound interface.
Discussion: Since SDN supports agile provisioning, it's important to measure how fast the controller provisions an end-to-end flow in the data plane 💨. The benchmark is obtained by sending traffic from a source endpoint to a destination endpoint, then finding the time difference between the first and last flow provisioning messages exchanged between the controller and the Network Devices for that traffic path. Speedrun energy 🏁.
Measurement Units: Milliseconds.
2.3.1.5. Proactive Path Provisioning Time 🔮
Definition: The time the controller takes to proactively set up a path between source and destination nodes. It starts with the first proactive flow provisioned on the controller(s) northbound interface, and ends with the last flow provisioning command message sent from the controller(s) on their southbound interface.
Discussion: For SDN to support pre-provisioning of the traffic path from an application, it's important to measure how fast the controller provisions an end-to-end flow in the data plane 🪄. The benchmark is obtained by provisioning a flow on the controller's northbound interface so the traffic can go from a source endpoint to a destination endpoint. Then you find the time difference between the first and last flow provisioning messages exchanged between the controller and the Network Devices for that path. Planned ahead, iconic 📅.
Measurement Units: Milliseconds.
2.3.1.6. Reactive Path Provisioning Rate 🛣️
Definition: The maximum number of independent paths a controller can concurrently establish per second between source and destination nodes, reactively. It's defined as the number of paths provisioned per second by the controller(s) on their southbound interface, for the flow provisioning requests received for path provisioning on that interface, between the start of the trial and the expiry of the given Trial Duration.
Discussion: For SDN to support agile traffic forwarding, it's important to measure how many end-to-end flows the controller can set up in the data plane 🦄. This benchmark is obtained by sending each traffic flow with a unique source and destination pair from the source Network Device, then determining the number of frames received at the destination Network Device.
Measurement Units: Paths provisioned per second.
2.3.1.7. Proactive Path Provisioning Rate 🌟
Definition: The maximum number of independent paths a controller can concurrently establish per second between source and destination nodes, proactively. It's defined as the number of paths provisioned per second by the controller(s) on their southbound interface, for the paths provisioned on their northbound interface, between the start of the trial and the expiry of the given Trial Duration.
Discussion: For SDN to support pre-provisioning of the traffic path for a larger network from the application, it's important to measure how many end-to-end flows the controller can set up in the data plane 🧁. This benchmark is obtained by sending each traffic flow with a unique source and destination pair from the source Network Device. Then you program the flows on the controller's northbound interface so traffic can reach from each of the unique source and destination pairs, and determine the number of frames received at the destination Network Device. Big network, big plans, big vibes 💜.
Measurement Units: Paths provisioned per second.
2.3.1.8. Network Topology Change Detection Time
Definition: The amount of time taken by the controller to detect any changes in the network topology, defined as the interval starting with the notification message received by the controller(s) at its southbound interface and ending with the first topology rediscovery messages sent from the controller(s) at its southbound interface.
Discussion: In order for the controller to support fast network failure recovery, it is critical to measure how fast the controller is able to detect any network-state change events. This benchmark is obtained by triggering a topology change event and measuring the time the controller takes to detect and initiate a topology rediscovery process.
Measurement Units: Milliseconds.
2.3.2. Scalability ✨
2.3.2.1. Control Sessions Capacity 🎀
Definition: The maximum number of control sessions the controller can maintain, defined as the number of sessions that the controller can accept from Network Devices, starting with the first control session and ending with the last control session that the controller(s) accepts at its southbound interface.
Discussion: Measuring the controller's Control Sessions Capacity is important for determining the controller's system and bandwidth resource requirements. This benchmark is obtained by establishing a control session with the controller from each of the Network Devices until the controller fails. The number of sessions that were successfully established will provide the Control Sessions Capacity.
Measurement Units: Maximum number of control sessions.
2.3.2.2. Network Discovery Size 🦋
Definition: The network size (number of nodes and links) that a controller can discover, defined as the size of a network that the controller(s) can discover, starting with a network topology provided by the user for discovery and ending with the number of nodes and links that the controller(s) can successfully discover.
Discussion: Measuring the maximum network size that the controller can discover is key to optimal network planning. This benchmark is obtained by presenting an initial set of Network Devices for discovery to the controller. Based on the initial discovery, the number of Network Devices is increased or decreased to determine the maximum number of nodes and links that the controller can discover.
Measurement Units: Maximum number of network nodes and links.
2.3.2.3. Forwarding Table Capacity 🧚
Definition: The maximum number of flow entries that a controller can manage in its Forwarding Table.
Discussion: It is important to measure the capacity of a controller's Forwarding Table to determine the number of flows that the controller can forward without flooding or dropping any traffic. This benchmark is obtained by continuously presenting the controller with new flow entries through the Reactive Flow Provisioning mode or the Proactive Flow Provisioning mode until the Forwarding Table becomes full. The maximum number of nodes that the controller can hold in its Forwarding Table will provide the Forwarding Table Capacity.
Measurement Units: Maximum number of flow entries managed.
2.3.3. Security 🔥
2.3.3.1. Exception Handling 💅
Definition: To determine the effect of handling error packets and notifications on performance tests.
Discussion: This benchmark is to be performed after obtaining the baseline measurement results for the performance tests defined in Section 2.3.1. This benchmark determines the deviation from the baseline performance due to the handling of error or failure messages from the connected Network Devices.
Measurement Units: Deviation from baseline metrics while handling Exceptions.
2.3.3.2. Handling Denial-of-Service Attacks 🛡️
Definition: To determine the effect of handling denial-of-service (DoS) attacks on performance and scalability tests.
Discussion: This benchmark is to be performed after obtaining the baseline measurement results for the performance and scalability tests defined in Sections 2.3.1 and 2.3.2. This benchmark determines the deviation from the baseline performance due to the handling of DoS attacks on the controller.
Measurement Units: Deviation from baseline metrics while handling DoS attacks.
2.3.4. Reliability 💜
2.3.4.1. Controller Failover Time 🫶
Definition: The time taken to switch from an active controller to the backup controller when the controllers operate in redundancy mode and the active controller fails, defined as the interval starting when the active controller is brought down and ending with the first rediscovery message received from the new controller at its southbound interface.
Discussion: This benchmark determines the impact of provisioning new flows when controllers are teamed together and the active controller fails.
Measurement Units: Milliseconds.
2.3.4.2. Network Re-provisioning Time 🌈
Definition: The time taken by the controller to reroute traffic when there is a failure in existing traffic paths, defined as the interval starting with the first failure notification message received by the controller and ending with the last flow re-provisioning message sent by the controller at its southbound interface.
Discussion: This benchmark determines the controller's re-provisioning ability upon network failures and makes the following assumptions:
- The network topology supports a redundant path between the source and destination endpoints.
- The controller does not pre-provision the redundant path.
Measurement Units: Milliseconds.
3. Test Setup 🍓
This section provides common reference topologies that are referred to in individual tests defined in the companion methodology document [RFC8456].
3.1. Test Setup - Controller Operating in Standalone Mode 👑
+-----------------------------------------------------------+
| Application-Plane Test Emulator |
| |
| +-----------------+ +-------------+ |
| | Application | | Service | |
| +-----------------+ +-------------+ |
| |
+-----------------------------+(I2)-------------------------+
|
| (Northbound Interface)
+-------------------------------+
| +----------------+ |
| | SDN Controller | |
| +----------------+ |
| |
| Device Under Test (DUT) |
+-------------------------------+
| (Southbound Interface)
|
+-----------------------------+(I1)-------------------------+
| |
| +-----------+ +-----------+ |
| | Network | | Network | |
| | Device 2 |--..-| Device n-1| |
| +-----------+ +-----------+ |
| / \ / \ |
| / \ / \ |
| l0 / X \ ln |
| / / \ \ |
| +-----------+ +-----------+ |
| | Network | | Network | |
| | Device 1 |..| Device n | |
| +-----------+ +-----------+ |
| | | |
| +---------------+ +---------------+ |
| | Test Traffic | | Test Traffic | |
| | Generator | | Generator | |
| | (TP1) | | (TP2) | |
| +---------------+ +---------------+ |
| |
| Forwarding-Plane Test Emulator |
+-----------------------------------------------------------+Figure 1 🦋
3.2. Test Setup - Controller Operating in Cluster Mode 🧚
Okay, this is the cluster-mode setup, the squad-goals version 🫶 Check out how the SDN controllers are lined up with the DUT and both test emulators 👀
+-----------------------------------------------------------+
| Application-Plane Test Emulator |
| |
| +-----------------+ +-------------+ |
| | Application | | Service | |
| +-----------------+ +-------------+ |
| |
+-----------------------------+(I2)-------------------------+
|
| (Northbound Interface)
+---------------------------------------------------------+
| |
| +------------------+ +------------------+ |
| | SDN Controller 1 | <--E/W--> | SDN Controller n | |
| +------------------+ +------------------+ |
| |
| Device Under Test (DUT) |
+---------------------------------------------------------+
| (Southbound Interface)
|
+-----------------------------+(I1)-------------------------+
| |
| +-----------+ +-----------+ |
| | Network | | Network | |
| | Device 2 |--..-| Device n-1| |
| +-----------+ +-----------+ |
| / \ / \ |
| / \ / \ |
| l0 / X \ ln |
| / / \ \ |
| +-----------+ +-----------+ |
| | Network | | Network | |
| | Device 1 |..| Device n | |
| +-----------+ +-----------+ |
| | | |
| +---------------+ +---------------+ |
| | Test Traffic | | Test Traffic | |
| | Generator | | Generator | |
| | (TP1) | | (TP2) | |
| +---------------+ +---------------+ |
| |
| Forwarding-Plane Test Emulator |
+-----------------------------------------------------------+
Figure 24. Test Coverage ✨
Here's the full map of what gets tested, sorted by lifecycle stage and category. It's giving organized 📋🌈
+-------------------------------------------------------------------+
| Lifecycle | Speed | Scalability | Reliability |
+------------+-------------------+---------------+------------------+
| | 1. Network |1. Network | |
| | Topology | Discovery | |
| | Discovery | Size | |
| | Time | | |
| | | | |
| | 2. Reactive Path | | |
| | Provisioning | | |
| | Time | | |
| | | | |
| | 3. Proactive Path | | |
| Setup | Provisioning | | |
| | Time | | |
| | | | |
| | 4. Reactive Path | | |
| | Provisioning | | |
| | Rate | | |
| | | | |
| | 5. Proactive Path | | |
| | Provisioning | | |
| | Rate | | |
| | | | |
+------------+-------------------+---------------+------------------+
| | 1. Maximum |1. Control |1. Network |
| | Asynchronous | Sessions | Topology |
| | Message | Capacity | Change |
| | Processing Rate| | Detection Time |
| | |2. Forwarding | |
| | 2. Loss-Free | Table |2. Exception |
| | Asynchronous | Capacity | Handling |
| | Message | | |
| Operational| Processing Rate| |3. Handling |
| | | | Denial-of- |
| | 3. Asynchronous | | Service Attacks|
| | Message | | |
| | Processing Time| |4. Network |
| | | | Re-provisioning|
| | | | Time |
| | | | |
+------------+-------------------+---------------+------------------+
| Teardown | | |1. Controller |
| | | | Failover Time |
+------------+-------------------+---------------+------------------+5. IANA Considerations 🎀
Good news bestie: this document has no IANA actions, so there's nothing to register or update here 💖
6. Security Considerations 💀
Okay, this section is serious business, so let's get into it 😭
The benchmarking tests in this document only look at how controllers perform in a lab, on isolated networks. That's the whole scope, so nobody gets to take it out of the lab 🙅♀️
The benchmarking network topology is its own independent test setup, and it MUST NOT be connected to devices that could forward the test traffic into a production network or misroute traffic to the test management network. Please, please keep the lab walls up 🚧🔥
Also, benchmarking is done "black-box" style, which means it only relies on measurements you can observe from outside the controller. Nothing sneaky, no peeking inside 🕵️♀️
One more thing, and this one is important 🌸 Special capabilities SHOULD NOT exist in the controller just for the sake of benchmarking. Any security implications coming from the controller SHOULD be identical in the lab and in production networks. No "lab-only" loopholes, ever 💅
7. Normative References 📚
These are the references the rest of the doc depends on, so here they are, complete and accounted for ✨
[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>.[RFC2330]Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, "Framework for IP Performance Metrics", RFC 2330, DOI 10.17487/RFC2330, May 1998,<https://www.rfc-editor.org/info/rfc2330>.[RFC4689]Poretsky, S., Perser, J., Erramilli, S., and S. Khurana, "Terminology for Benchmarking Network-layer Traffic Control Mechanisms", RFC 4689, DOI 10.17487/RFC4689, October 2006,<https://www.rfc-editor.org/info/rfc4689>.[RFC7426]Haleplidis, E., Ed., Pentikousis, K., Ed., Denazis, S., Hadi Salim, J., Meyer, D., and O. Koufopavlou, "Software-Defined Networking (SDN): Layers and Architecture Terminology", RFC 7426, DOI 10.17487/RFC7426, January 2015,<https://www.rfc-editor.org/info/rfc7426>.[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>.[RFC8456]Bhuvaneswaran, V., Basil, A., Tassinari, M., Manral, V., and S. Banks, "Benchmarking Methodology for Software-Defined Networking (SDN) Controller Performance", RFC 8456, DOI 10.17487/RFC8456, October 2018,<https://www.rfc-editor.org/info/rfc8456>.
Acknowledgments 🫶
Huge shoutout to Al Morton (AT&T), who made significant contributions to the earlier draft versions of this document 👑 The authors also want to thank these folks for their valuable comments on those earlier drafts: Sandeep Gangadharan (HP), M. Georgescu (NAIST), Andrew McGregor (Google), Scott Bradner, Jay Karthik (Cisco), Ramki Krishnan (VMware), and Boris Khasanov (Huawei) 💖
Authors' Addresses 🦋
Bhuvaneswaran Vengainathan
Veryx Technologies Inc.
1 International Plaza, Suite 550
Philadelphia, PA 19113
United States of America
Email: bhuvaneswaran.vengainathan@veryxtech.com
Anton Basil
Veryx Technologies Inc.
1 International Plaza, Suite 550
Philadelphia, PA 19113
United States of America
Email: anton.basil@veryxtech.com
Mark Tassinari
Hewlett Packard Enterprise
8000 Foothills Blvd.
Roseville, CA 95747
United States of America
Email: mark.tassinari@hpe.com
Vishwas Manral
NanoSec Co
3350 Thomas Rd.
Santa Clara, CA 95054
United States of America
Email: vishwas.manral@gmail.com
Sarah Banks
VSS Monitoring
930 De Guigne Drive
Sunnyvale, CA 94085
United States of America
Email: sbanks@encrypted.net📦 where this page comes from
- ietf: rfc8455 2018-10
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms