wdiff rfc8455.original rfc8455.txt

Internet-Draft
Internet Engineering Task Force (IETF) V. Bhuvaneswaran Vengainathan
Network Working Group Anton
Request for Comments: 8455 A. Basil
Intended Status:
Category: Informational Veryx Technologies
Expires: November 25, 2018 Mark
ISSN: 2070-1721 M. Tassinari
Hewlett-Packard
Vishwas
Hewlett Packard Enterprise
V. Manral
Nano Sec
Sarah
NanoSec
S. Banks
VSS Monitoring
May 25,
October 2018

Terminology for Benchmarking SDN Software-Defined Networking (SDN)
Controller Performance
draft-ietf-bmwg-sdn-controller-benchmark-term-10

Abstract

This document defines terminology for benchmarking an SDN a Software-Defined
Networking (SDN) controller's control plane control-plane performance. It extends
the terminology already defined in RFC 7426 for the purpose of
benchmarking SDN
controllers. Controllers. The terms provided in this document
help to benchmark an SDN controller's Controller's performance independent independently of
the controller's supported protocols and/or network services.

Status of this This Memo

This Internet-Draft document is submitted in full conformance with the
provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents not an Internet Standards Track specification; it is
published for informational purposes.

This document is a product of the Internet Engineering Task Force
(IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list It represents the consensus of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current.

Internet-Drafts are draft documents valid the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Not all documents
approved by the IESG are a maximum candidate for any level of Internet
Standard; see Section 2 of RFC 7841.

Information about the current status of six
months this document, any errata,
and how to provide feedback on it may be updated, replaced, or obsoleted by other documents obtained 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 November 25, 2018.
https://www.rfc-editor.org/info/rfc8455.

This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info)
(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 Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.

Table of Contents

1. Introduction...................................................4 Introduction ....................................................3
1.1. Conventions Used in This Document ..........................3
2. Term Definitions...............................................4 Definitions ................................................4
2.1. SDN Terms.................................................4 Terms ..................................................4
2.1.1. Flow.................................................4 Flow ................................................4
2.1.2. Northbound Interface.................................5 Interface ................................4
2.1.3. Southbound Interface.................................5 Interface ................................5
2.1.4. Controller Forwarding Table..........................5 Table .........................5
2.1.5. Proactive Flow Provisioning Mode.....................6 Mode ....................5
2.1.6. Reactive Flow Provisioning Mode......................6 Mode .....................6
2.1.7. Path.................................................7 Path ................................................6
2.1.8. Standalone Mode......................................7 Mode .....................................6
2.1.9. Cluster/Redundancy Mode..............................7 Mode .............................7
2.1.10. Asynchronous Message................................8 Message ...............................7
2.1.11. Test Traffic Generator..............................8 Generator .............................7
2.1.12. Leaf-Spine Topology.................................9 Topology ................................8
2.2. Test Configuration/Setup Terms............................9 Terms .............................8
2.2.1. Number of Network Devices............................9 Devices ...........................8
2.2.2. Trial Repetition.....................................9 Repetition ....................................8
2.2.3. Trial Duration......................................10 Duration ......................................9
2.2.4. Number of Cluster nodes.............................10 Nodes .............................9
2.3. Benchmarking Terms.......................................10 Terms .........................................9
2.3.1. Performance.........................................11 Performance .........................................9
2.3.1.1. Network Topology Discovery Time................11 Time ............9
2.3.1.2. Asynchronous Message Processing Time...........11 Time ......10
2.3.1.3. Asynchronous Message Processing Rate...........12 Rate ......10
2.3.1.4. Reactive Path Provisioning Time................13 Time ...........11
2.3.1.5. Proactive Path Provisioning Time...............13 Time ..........12
2.3.1.6. Reactive Path Provisioning Rate................14 Rate ...........12
2.3.1.7. Proactive Path Provisioning Rate...............14 Rate ..........13
2.3.1.8. Network Topology Change Detection Time.........15 Time ....13
2.3.2. Scalability.........................................16 Scalability ........................................14
2.3.2.1. Control Sessions Capacity......................16 Capacity .................14
2.3.2.2. Network Discovery Size.........................16 Size ....................14
2.3.2.3. Forwarding Table Capacity......................17 Capacity .................15
2.3.3. Security............................................17 Security ...........................................15
2.3.3.1. Exception Handling.............................17 Handling ........................15
2.3.3.2. Denial of Service Handling.....................18 Handling Denial-of-Service Attacks ........16
2.3.4. Reliability.........................................18 Reliability ........................................16
2.3.4.1. Controller Failover Time.......................18 Time ..................16
2.3.4.2. Network Re-Provisioning Time...................19 Re-provisioning Time ..............17
3. Test Setup....................................................19 Setup .....................................................17
3.1. Test setup Setup - Controller working Operating in Standalone Mode.......20 Mode ......18
3.2. Test setup Setup - Controller working Operating in Cluster Mode..........21 Mode .........19
4. Test Coverage.................................................22 Coverage ..................................................20
5. References....................................................23
5.1. Normative References.....................................23
5.2. Informative References...................................23
6. IANA Considerations...........................................23
7. Considerations ............................................21
6. Security Considerations.......................................23
8. Acknowledgements..............................................24
9. Considerations ........................................21
7. Normative References ...........................................21
Acknowledgments ...................................................22
Authors' Addresses............................................24 Addresses ................................................23

1. Introduction

Software Defined

Software-Defined Networking (SDN) is a networking architecture in
which network control is decoupled from the underlying forwarding
function and is placed in a centralized location called the SDN
controller.
Controller. The SDN controller Controller provides an abstraction of the
underlying network and offers a global view of the overall network to
applications and business logic. Thus, an SDN controller Controller provides
the flexibility to program, control, and manage network behaviour behavior
dynamically through northbound and southbound interfaces. Since the
network controls are logically centralized, the need to benchmark the
SDN controller Controller's performance becomes significant. This document
defines terms to benchmark various controller designs for
performance, scalability, reliability reliability, and security, independent independently of
northbound and southbound protocols. A mechanism for benchmarking
the performance of SDN controllers Controllers is defined in the companion
methodology document [I-D.sdn-controller-benchmark-meth]. [RFC8456]. These two documents provide a method to measure methods
for measuring and evaluate evaluating the performance of various controller
implementations.

1.1. Conventions used Used in this document 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 defined in this section are extensions to the terms defined
in [RFC7426] "Software-Defined ("Software-Defined Networking (SDN): Layers and
Architecture Terminology". That RFC Terminology"). Readers should be referred refer to [RFC7426] before
attempting to make use of this document.

2.1.1. Flow

Definition:
The definition of Flow "flow" is the same as microflows defined the definition of
"microflows" provided in [RFC4689] Section 3.1.5. 3.1.5 of [RFC4689].

Discussion:
A flow can be a set of packets having the same source address,
destination address, source port port, and destination port, or any
combination of these
combinations. items.

Measurement Units:
N/A

See Also:
None

2.1.2. Northbound Interface

Definition:
The definition of northbound interface "northbound interface" is the same as the Service Interface
defined
definition of "service interface" provided in [RFC7426].

Discussion:
The northbound interface allows SDN applications and orchestration
systems to program and retrieve the network information through
the SDN controller. Controller.

Measurement Units:
N/A

See Also:
None

2.1.3. Southbound Interface

Definition:
The southbound interface is the application programming interface
provided by the SDN controller Controller to interact with the SDN nodes.

Discussion:
Southbound
The southbound interface enables the controller to interact with
the SDN nodes in the network for dynamically defining the traffic
forwarding
behaviour. behavior.

Measurement Units:
N/A

See Also:
None

2.1.4. Controller Forwarding Table

Definition:
A controller forwarding table Forwarding Table contains flow entries learned in one
of two ways: first, entries could can be learned from traffic received
through the data plane, or second, these entries could can be statically
provisioned on the controller and distributed to devices via the
southbound interface.

Discussion:
The controller forwarding table Forwarding Table has an aging mechanism which that will
be applied only for dynamically learned entries.

Measurement Units:
N/A

See Also:
None

2.1.5. Proactive Flow Provisioning Mode

Definition:
Controller programming 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 the
network forwarding behaviour behavior by programming the controller controller, using
proactive flow provisioning.
Proactive Flow Provisioning. The controller can then program the
Network Devices with the pre-provisioned entries.

Measurement Units:
N/A

See Also:
None

2.1.6. Reactive Flow Provisioning Mode

Definition:
Controller programming flows in Network Devices based on the
traffic received from Network Devices through the controller's
southbound
interface interface.

Discussion:
The SDN controller Controller dynamically decides the forwarding behaviour behavior
based on the incoming traffic from the Network Devices. The
controller then programs the Network Devices Devices, using Reactive Flow
Provisioning.

Measurement Units:
N/A

See Also:
None

2.1.7. Path

Definition:
Refer to Section 5 in [RFC2330] [RFC2330].

Discussion:
None

Measurement Units:
N/A

See Also:
None

2.1.8. Standalone Mode

Definition:
Single
A single controller handling handles all control plane control-plane functionalities
without redundancy, or the ability and it is unable to provide high availability
and/or automatic failover.

Discussion:
In standalone mode, one controller manages one or more network
domains.

Measurement Units:
N/A

See Also:
None

2.1.9. Cluster/Redundancy Mode

Definition:
A
In this mode, a group of 2 two or more controllers handling handles all control plane
control-plane functionalities.

Discussion:
In cluster mode, multiple controllers are teamed together for the
purpose of load sharing and/or high availability. The controllers
in the group may work operate in active/standby (master/slave) or
active/active (equal) mode mode, depending on the intended purpose.

Measurement Units:
N/A

See Also:
None

2.1.10. Asynchronous Message

Definition:
Any message from the Network Device that is generated for network
events.

Discussion:
Control messages like flow setup request and response message is messages are
classified as asynchronous message. messages. The controller has to return
a response message. Note that the Network Device will not be in
blocking mode and continues to send/receive other control
messages.

Measurement Units:
N/A

See Also:
None

2.1.11. Test Traffic Generator

Definition:
Test Traffic Generator
The test traffic generator is an entity that generates/receives
network traffic.

Discussion:
Test Traffic Generator
The test traffic generator typically connects with Network Devices
to send/receive real-time network traffic.

Measurement Units:
N/A

See Also:
None

2.1.12. Leaf-Spine Topology

Definition:
Leaf-Spine
"Leaf-Spine" is a two layered two-layered network topology, where a series of
leaf switches, switches that form the access layer, layer are fully meshed to a
series of spine switches that form the backbone layer.

Discussion:
In the Leaf-Spine Topology, topology, every leaf switch is connected to each
of the spine switches in the topology.

Measurement Units:
N/A

See Also:
None

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 defined in the test topology can be deployed
using real hardware or can be emulated in hardware platforms.

Measurement Units:
Number of network devices

See Also:
None

2.3.1.4. Reactive Path Provisioning Time

Definition:
The time taken by the controller to setup set up a path reactively
between source and destination node, nodes, defined as the interval
starting with the first flow provisioning request message received
by the
controller(s), controller(s) and ending with the last flow provisioning
response message sent from the controller(s) at its Southbound southbound
interface.

Discussion:
As SDN supports agile provisioning, it is important to measure how
fast that the controller provisions an end-to-end flow in the
dataplane.
data plane. The benchmark is obtained by sending traffic from a
source endpoint to the destination endpoint, endpoint and finding the time
difference between the first and the last flow provisioning message
exchanged between the controller and the Network Devices for the
traffic path.

Measurement Units:
Milliseconds.

See Also:
None

2.3.1.5. Proactive Path Provisioning Time

Definition:
The time taken by the controller to proactively setup set up a path
between source and destination node, nodes, defined as the interval
starting with the first proactive flow provisioned in the
controller(s) at its
Northbound interface, northbound interface and ending with the last
flow provisioning command message sent from the controller(s) at
its Southbound southbound interface.

Discussion:
For SDN to support pre-provisioning of the traffic path from the
application, it is important to measure how fast that the controller
provisions an end-to-end flow in the dataplane. data plane. The benchmark is
obtained by provisioning a flow on the controller's northbound
interface for the traffic to reach from a source to a destination endpoint,
endpoint and finding the time difference between the first and the
last flow provisioning message exchanged between the controller
and the Network Devices for the traffic path.

Measurement Units:
Milliseconds.

See Also:
None

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, defined as the number of paths provisioned per
second by the controller(s) at its Southbound southbound interface for the
flow provisioning requests received for path provisioning at its
Southbound
southbound interface between the start of the trial and the expiry
of the given trial duration. Trial Duration.

Discussion:
For SDN to support agile traffic forwarding, it is important to
measure how many end-to-end flows that the controller could setup can set up in the dataplane.
data plane. This benchmark is obtained by sending traffic each traffic
flow with unique source and destination pairs from the source
Network Device and determine determining the number of frames received at
the destination Network Device.

Measurement Units:
Paths provisioned per second.

See Also:
None

2.3.1.7. Proactive Path Provisioning Rate

Definition:
Measure the
The maximum number of independent paths a controller can
concurrently establish per second between source and destination
nodes proactively, defined as the number of paths provisioned per
second by the controller(s) at its Southbound southbound interface for the
paths provisioned in its Northbound northbound interface between the start of
the trial and the expiry of the given trial duration. Trial Duration.

Discussion:
For SDN to support pre-provisioning of the traffic path for a
larger network from the application, it is important to measure
how many end-to-end flows that the controller could setup can set up in the dataplane.
data plane. This benchmark is obtained by sending traffic each traffic
flow with unique source and destination pairs from the source
Network Device. Program the flows on the controller's northbound
interface for traffic to reach from each of the unique source and
destination pairs pairs, and determine the number of frames received at
the destination Network Device.

Measurement Units:
Paths provisioned per second.

See Also:
None

2.3.1.8. Network Topology Change Detection Time

Definition:
The amount of time required for 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,
southbound interface and ending with the first topology
rediscovery messages sent from the controller(s) at its Southbound 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 re-discovery
rediscovery process.

Measurement Units:
Milliseconds

See Also:
None

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 test is to be performed after obtaining the baseline
performance of
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 of from baseline metrics while handling Exceptions.

See Also:
None

2.3.3.2. Denial of Service Handling Denial-of-Service Attacks

Definition:
To determine the effect of handling denial of service denial-of-service (DoS)
attacks on performance and scalability tests.

Discussion:
This benchmark test is to be performed after obtaining the baseline
performance of
measurement results for the performance and scalability tests
defined in
section Sections 2.3.1 and section 2.3.2. This benchmark determines
the deviation from the baseline performance due to the handling of
denial of service
DoS attacks on the controller.

Measurement Units:
Deviation of from baseline metrics while handling Denial of Service
Attacks.

See Also:
None

2.3.4.2. Network Re-Provisioning Re-provisioning Time

Definition:
The time taken to re-route the traffic by the Controller, controller to reroute traffic when there is
a failure in existing traffic paths, defined as the interval
starting from with the first failure notification message received by
the
controller, controller and ending with the last flow re-provisioning
message sent by the controller at its Southbound southbound interface.

Discussion:
This benchmark determines the controller's re-provisioning ability
upon network failures. This benchmark test assumes failures and makes the following: following assumptions:

1. Network The network topology supports a redundant path between the
source and destination endpoints.

2. Controller The controller does not pre-provision the redundant path.

Measurement Units:
Milliseconds.

See Also:
None

3. Test Setup

This section provides common reference topologies that are later referred
to in individual tests defined in the companion methodology
document. document
[RFC8456].

3.1. Test setup Setup - Controller working Operating in Standalone Mode

+-----------------------------------------------------------+
| Application Plane Application-Plane Test Emulator |
| |
| +-----------------+ +-------------+ |
| | Application | | Service | |
| +-----------------+ +-------------+ |
| |
+-----------------------------+(I2)-------------------------+
|
| (Northbound interface) Interface)
+-------------------------------+
| +----------------+ |
| | SDN Controller | |
| +----------------+ |
| |
| Device Under Test (DUT) |
+-------------------------------+
| (Southbound interface) 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 Forwarding-Plane Test Emulator |
+-----------------------------------------------------------+

Figure 1

3.2. Test setup Setup - Controller working Operating in Cluster Mode

+-----------------------------------------------------------+
| Application Plane Application-Plane Test Emulator |
| |
| +-----------------+ +-------------+ |
| | Application | | Service | |
| +-----------------+ +-------------+ |
| |
+-----------------------------+(I2)-------------------------+
|
| (Northbound interface) Interface)
+---------------------------------------------------------+
| |
| ------------------ ------------------ +------------------+ +------------------+ |
| | SDN Controller 1 | <--E/W--> | SDN Controller n | |
| ------------------ ------------------ +------------------+ +------------------+ |
| |
| Device Under Test (DUT) |
+---------------------------------------------------------+
| (Southbound interface) 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 Forwarding-Plane Test Emulator |
+-----------------------------------------------------------+

Figure 2

4. Test Coverage

+ -----------------------------------------------------------------+

5. References

5.1. IANA Considerations

This document has no IANA actions.

6. Security Considerations

The benchmarking tests described in this document are limited to the
performance characterization of controllers in a lab environment with
isolated networks.

The benchmarking network topology will be an independent test setup
and MUST NOT be connected to devices that may forward the test
traffic into a production network or misroute traffic to the test
management network.

Further, benchmarking is performed on a "black-box" basis, relying
solely on measurements observable external to the controller.

Special capabilities SHOULD NOT exist in the controller specifically
for benchmarking purposes. Any implications for network security
arising from the controller SHOULD be identical in the lab and in
production networks.

7. Normative References

[RFC7426] E. Haleplidis, K. Pentikousis, S. Denazis, J. Hadi Salim,
D. Meyer, O. Koufopavlou "Software-Defined Networking
(SDN): Layers and Architecture Terminology", RFC 7426,
January 2015.

[RFC4689] S. Poretsky, J. Perser, S. Erramilli, S. Khurana
"Terminology

[RFC2119] Bradner, S., "Key words for Benchmarking Network-layer Traffic
Control Mechanisms", use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 4689, October 2006. 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.

[RFC2330] V. Paxson, G. V., Almes, J. G., Mahdavi, J., and M. Mathis,
"Framework for IP Performance Metrics", RFC 2330,
DOI 10.17487/RFC2330, May 1998.

[RFC2119] 1998,
<https://www.rfc-editor.org/info/rfc2330>.

[RFC4689] Poretsky, S., Perser, J., Erramilli, S., and S. Bradner, "Key words Khurana,
"Terminology for use in RFCs to Indicate
Requirement Levels", Benchmarking Network-layer Traffic
Control Mechanisms", RFC 2119, March 1997. 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] B. Leiba, B., "Ambiguity of Uppercase vs Lowercase in
RFC 2119 Key Words", BCP 14, RFC 8174,
DOI 10.17487/RFC8174, May 2017.

[I-D.sdn-controller-benchmark-meth] Bhuvaneswaran.V, Anton 2017,
<https://www.rfc-editor.org/info/rfc8174>.

[RFC8456] Bhuvaneswaran, V., Basil,
Mark.T, Vishwas A., Tassinari, M., Manral, Sarah Banks V.,
and S. Banks, "Benchmarking Methodology for SDN Software-
Defined Networking (SDN) Controller Performance",
draft-ietf-bmwg-sdn-controller-benchmark-meth-09
(Work in progress), May 25, 2018

5.2. Informative References

[OpenFlow Switch Specification] ONF,"OpenFlow Switch Specification"
Version 1.4.0 (Wire Protocol 0x05),
RFC 8456, DOI 10.17487/RFC8456, October 14, 2013.

6. IANA Considerations

This document does not have any IANA requests.

7. Security Considerations

Security issues are not discussed in this memo.

8. Acknowledgements 2018,
<https://www.rfc-editor.org/info/rfc8456>.

Acknowledgments

The authors would like to acknowledge Al Morton (AT&T) for the his
significant contributions to the earlier draft versions of this
document. The authors would like to thank the following individuals
for providing their valuable comments to the earlier draft versions
of this document: Sandeep Gangadharan (HP), M. Georgescu (NAIST),
Andrew McGregor (Google), Scott Bradner , Bradner, Jay Karthik (Cisco), Ramakrishnan
(Dell),
Ramki Krishnan (VMware), and Khasanov Boris (Huawei).

Authors' Addresses

Bhuvaneswaran Vengainathan
Veryx Technologies Inc.
1 International Plaza, Suite 550
Philadelphia
Philadelphia, PA 19113
United States of America

Email: bhuvaneswaran.vengainathan@veryxtech.com

Anton Basil
Veryx Technologies Inc.
1 International Plaza, Suite 550
Philadelphia
Philadelphia, PA 19113
United States of America

Email: anton.basil@veryxtech.com

Mark Tassinari
Hewlett-Packard,
Hewlett Packard Enterprise
8000 Foothills Blvd, Blvd.
Roseville, CA 95747
United States of America

Email: mark.tassinari@hpe.com

Vishwas Manral
Nano Sec,CA
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, Drive
Sunnyvale, CA 94085
United States of America

Email: sbanks@encrypted.net