Appendix A - ICAN-DI Standards Specification.pdf

For Official Use Only (FOUO)

Hardware / Software

Standards and Technical Specifications

FOR THE

DISN Enterprise Network (DISN-EN)

INSTALLATION CAMPUS AREA NETWORK

DESIGN & IMPLEMENTATION

FOR THE

IMPLEMENTERS OF THE DISN-EN INFRASTRUCTURE

Supporting NETMOD 2.0

Artifact Version 2.0 Release 1.1

12 February 2020

ICAN-DI HW/SW STANDARDS & SPECIFICATIONS DEVELOPED BY USARMY PEO-EIS/DCATS

VERSION 2.0 RELEASE 1.1 DATED 12 FEBRUARY 2020

UNCLASSIFIED

(Intentionally Left Blank)

Summary Requirements & Technical Specifications | DISN-EN Page For Official Use Only

TABLE OF CONTENTS

1 Purpose & Scope

2 Overarching System Standards & Requirements

2.1 System Manufacturing

2.2 System Compliance with the DoDIN UC APL

2.3 System Compliance with IPv6

2.4 System Compliance with IEEE Standards

2.5 System Compliance with IETF RFC Standards

2.5.1 Routing & Network Service Protocols

2.5.2 Internet Protocols

2.5.3 Management Protocols

3 General System Standards & Requirements

3.1 Hardware Requirements

3.1.1 All Systems

3.1.2 Chassis Based Systems

3.1.3 Stackable Systems

3.2 Performance

3.2.1 Performance - Ports

3.2.2 Performance – Stackable Devices

3.3 Modular Interfaces

3.3.1 Modular Interface Standards

3.3.2 Optical Interfaces

3.3.3 Copper Interfaces

3.4 Manageability and Supportability

3.5 Layer 2 Features

3.6 Layer 3 Features

3.7 Security Features

3.8 Software Defined Networking (SDN)

3.8.1 Software Defined LAN (SD-LAN)

3.8.2 Software Defined Network (SDN) Orchestration and Management

4 Specific System Standards & Requirements

4.1 Applicable IETF RFC Standards by System

4.2 Applicable General Standards by System

4.3 Applicable Physical Interface Support Requirements by System

4.3.1 Optical Interfaces

4.3.2 Copper Interfaces

4.4 EAS Specific System Requirements

4.4.1 Standard EAS Requirements

4.4.2 Compact EAS Requirements

4.5 ADS Specific System Requirements

4.5.1 Standard ADS Requirements

4.6 ACS Specific System Requirements

4.7 STES3 Specific System Requirements

4.7.1 STES3 EAS Requirements

4.7.2 STES3 ACS Requirements

4.8 BLR Specific System Requirements

4.9 DEM Specific System Requirements

4.10 SDN-OS Specific System Requirements

4.11 VTB Specific System Requirements

4.12 L2BS Specific System Requirements

4.13 TTRN Specific System Requirements

1 PURPOSE & SCOPE

The purpose of this document is to provide MILDEP Enterprise Infrastructure Campus Area Network

Design Implementation (ICAN-DI) Hardware/Software Standards and Specifications. MILDEP ICAN-DI

HW/SW Standards and Specifications enable the MILDEP and its integrators to implement from three authorized technical baselines instead of the single technical baseline that was offered under ICAN-DI

HW/SW Standards and Specifications Release 1.09F. This release of the ICAN-DI HW/SW Standards and

Specifications is applicable to material procurements for both the Unclassified (NIPR) and Classified up to Secret (SIPR) environments. The three authorized baselines supported by this document include:

• Technical Baseline 1: Spanning Tree Ethernet (SP-ETH)1

• Technical Baseline 2: Virtual Extensible Local Area Network (VXLAN) Ethernet (VX-ETH)2

• Technical Baseline 3: VXLAN Software Defined Networking (VX-SDN)3

The ICAN-DI HW/SW Standards and Specifications describe the following set of components:

o Common Systems for NIPR & SIPR:

▪ EAS & EAS Compact - Edge Access Switches

▪ ADS - Area Distribution Switches

▪ ACS - Area Core Switches

▪ STES3 - Synthetic Training Environment Specific Service Switches

• STES3 EAS (STE Specific EAS Devices)

• STES3 ACS (STE Specific ACS Devices)

▪ BLR - Border Leaf Router

▪ DEM - Device Element Manager

▪ SDN-OS - SDN Orchestration Suite o Unique Systems for NIPR Environments:

▪ VTB - VLAN Translation Block Switches

▪ L2BS - Layer 2 Bridging Switches o Unique Systems for SIPR Environments:

▪ TTRN - Top Tier Routing Nodes

Compliance with this artifact and reliance on the Joint Management System (JMS) through delegated Role Base Access Control (RBAC) permissions for operators by all DoD components enables the Joint Information Environment (JIE).

1 The SP-ETH Technical Baseline is using traditional Ethernet Network principles, employing Multi-Instance Spanning Tree (MST) for loop control and multiple MST regions for scalability within a Campus.

2 The VX-ETH Technical Baseline is using an Equal Cost Multi Path (ECMP) Layer-3 core with a VXLAN Layer-2 overlay across a virtual fence-line defined ICAN. VX-ETH allows Army to preposition for Software Defined Networking (SDN) but continue to operate through its existing management systems (SNMP based), without having an SDN Orchestrator and its automation scripting ready (key components of VX-SDN).

3 The VX-SDN Technical Baseline is the end state NETMOD technical baseline. It uses the VX-ETH IP delivery network and it adds vendor agnostic SDN Orchestration to replace traditional CLI/SNMP based management.

2 OVERARCHING SYSTEM STANDARDS & REQUIREMENTS

Overarching system standards & requirements apply to all ICAN-DI devices. All ICAN-DI devices must support the following requirements without the addition of hardware, software, firmware or licensing except where specified (i.e. Layer 3 Routing Features and Software Defined Networking Features MUST be offered as licensable software options, procurable either with licenses already included or without such licenses already included).

2.1 SYSTEM MANUFACTURING

➢ All devices at the time of award MUST provide a minimum of 8 years of OEM support before proposed products reach end of life (3 years manufacturing and 5 years support)

➢ All devices MUST be Assured Services Local Area Network (ASLAN) Certified as identified on the

DoDIN UC APL, except for the ICAN-DI EAS Compact device

➢ All devices MUST be certified as genuine by manufacturer's representative at time of receipt by government

2.2 SYSTEM COMPLIANCE WITH THE DODIN UC APL

➢ All devices MUST be on the DoDIN UC APL at time of award

➢ Equipment MUST be delivered with the latest DoDIN Unified Capabilities Approved Products List

(DoDIN UC APL) approved technology and software/firmware revisions installed o In the event that a newer version than the one listed on the APL is available or required then it may be installed provided it has been tested and approved by the MILDEP

2.3 SYSTEM COMPLIANCE WITH IPV6

➢ All hardware and associated software MUST be IPv6 capable. An IPv6 capable system or product MUST be capable of receiving, processing, transmitting and forwarding IPv6 packets while remaining interoperable with IPv4

➢ Specific criteria to be deemed IPv6 capable are:

o Devices MUST be able to implement IPv4/IPv6 dual-stack and built to determine which protocol layer to use depending on the destination host it is attempting to communicate with or establish a socket with o Devices MUST have availability of IPv6 technical support for system development, implementation and management o Devices MUST be interoperable with IPv4

2.4 SYSTEM COMPLIANCE WITH IEEE STANDARDS

ICAN-DI devices MUST comply with supporting Institute of Electrical and Electronics Engineers (IEEE) standards in accordance with the matrix below.

Figure 2-1 IEEE Compliance Matrix

2.5 SYSTEM COMPLIANCE WITH IETF RFC STANDARDS

A library of ICAN-DI relevant Internet Engineering Task Force (IETF) Request for Comments (RFC) standards have been categorized into referenceable sub-sections (i.e.: 2.5.x or 2.5.x.x), that are then utilized in defining individual ICAN-DI system level specifications. System requirement definitions located in Sections 4.x (Individual System Specifications) achieve communicating their applicable IETF

RFC requirements through a system specific IETF RFC Compliance Matrix. The below set of grouped IETF

RFC standards, therefore represent the library definition used in interpreting such references.

2.5.1 Routing & Network Service Protocols

Miscellaneous Network Services – All Devices

➢ IETF RFC 1035 – Domain Names – Implementation and Specification

Miscellaneous Network Services – Layer 2 Devices

➢ IETF RFC 5880 – Bidirectional Forwarding Detection (BFD)

➢ IETF RFC 5881 – BFD for IPv4 and IPv6 (Single Hop)

➢ IETF RFC 5883 – BFD for Multihop Paths

➢ IETF RFC 7419 – Common Interval Support in BFD

➢ IETF RFC 7880 – Seamless BFD (S-BFD)

➢ IETF RFC 8562 – BFD for Multipoint Networks

Miscellaneous Network Services – Layer 3 Devices

➢ IETF RFC 5798 – Virtual Router Redundancy Protocol (VRRP) version 3 for IPv4 and IPv6

➢ IETF RFC 5309 – Point-to-Point Operation over LAN in Link State Routing Protocols

Open Shortest Path First (OSPF)

➢ IETF RFC 1584 – Multicast Extensions to OSPF

➢ IETF RFC 2328 – Open Shortest Path First version 2 (OSPFv2)

➢ IETF RFC 3101 – The OSPF Not-So-Stubby Area (NSSA) Option

➢ IETF RFC 3623 – Graceful OSPF Restart

➢ IETF RFC 4811 – OSPF Out-of-Band Link State Database (LSDB) Resynchronization

➢ IETF RFC 4812 – OSPF Restart Signaling

➢ IETF RFC 5250 – The OSPF Opaque LSA Option

➢ IETF RFC 5340 – OSPF for IPv6

➢ IETF RFC 5613 – OSPF Link-Local Signaling

➢ IETF RFC 5709 – OSPFv2 HMAC-SHA Cryptographic Authentication

➢ IETF RFC 6549 – OSPFv2 Multi-Instance Extensions

➢ IETF RFC 6845 – OSPF Hybrid Broadcast and Point-to-Multipoint Interface Type

➢ IETF RFC 6860 – Hiding Transit-Only Networks in OSPF

➢ IETF RFC 6987 – OSPF Stub Router Advertisement

➢ IETF RFC 7038 – Use of OSPF-MDR in Single-Hop Broadcast Networks

➢ IETF RFC 7474 – Security Extension for OSPFv2 When Using Manual Key Management

➢ IETF RFC 7503 – OSPFv3 Autoconfiguration

➢ IETF RFC 7684 – OSPFv2 Prefix/Link Attribute Advertisement

➢ IETF RFC 7770 – Extensions to OSPF for Advertising Optional Router Capabilities

➢ IETF RFC 7884 – OSPF Extensions to Advertise S-BFD Target Discriminators

➢ IETF RFC 8042 – OSPF Two-Part Metric

➢ IETF RFC 8362 – OSPFv3 Link State Advertisement (LSA) Extensibility

➢ IETF RFC 8510 – OSPF Link-Local Signaling (LLS) Extensions for Local Interface ID Advertisement

Intermediate-System to Intermediate-System

➢ IETF RFC 1195 – Use of OSI IS-IS for Routing in TCP/IP and Dual Environments

➢ IETF RFC 5301 – Dynamic Hostname Exchange Mechanism for IS-IS

➢ IETF RFC 5302 – Domain-Wide Prefix Distribution with Two-Level IS-IS

➢ IETF RFC 5303 – Three-Way Handshake for IS-IS Point=to-Point Adjacencies

➢ IETF RFC 5304 – IS-IS Cryptographic Authentication

➢ IETF RFC 5305 – IS-IS Extensions for Traffic Engineering

➢ IETF RFC 5306 – Restart Signaling for IS-IS

➢ IETF RFC 5308 – Routing IPv6 with IS-IS

➢ IETF RFC 5310 – IS-IS Generic Cryptographic Authentication

➢ IETF RFC 5311 – Simplified Extension of Link State PDU (LSP) Space for IS-IS

➢ IETF RFC 6165 – Extensions to IS-IS for Layer-2 Systems

➢ IETF RFC 6232 – Purge Originator Identification TLV for IS-IS

➢ IETF RFC 6233 – IS-IS Registry Extensions for Purges

➢ IETF RFC 7142 – IS-IS Cryptographic Authentication

➢ IETF RFC 7602 – Extended Sequence Number TLV

➢ IETF RFC 7775 – IS-IS Route Preference for Extended IP and IPv6 Reachability

➢ IETF RFC 7794 – IS-IS Prefix Attribute for Extended IPv4 and IPv6 Reachability

➢ IETF RFC 7813 – IS-IS Path Control and Reservation

➢ IETF RFC 7883 – Advertising S-BFD Discriminators in IS-IS

➢ IETF RFC 8196 – IS-IS Autoconfiguration

➢ IETF RFC 8202 – IS-IS Multi-Instance

➢ IETF RFC 8570 – IS-IS Traffic Engineering (TE) Metric Extensions

Border Gateway Protocol (BGP)

➢ IETF RFC 4271 – A Border Gateway Protocol 4 (BGP-4)

➢ IETF RFC 4360 – BGP Extended Communities Attribute

➢ IETF RFC 4760 – Multiprotocol Extensions for BGP-4

➢ IETF RFC 5396 – Textual Representation of Autonomous System (AS) Numbers

➢ IETF RFC 6793 – BGP Support for Four-Octet Autonomous System (AS) Number Space

➢ IETF RFC 7153 – IANA Registries for BGP Extended Communities

➢ IETF RFC 7432 – BGP MPLS-Based Ethernet VPN

➢ IETF RFC 7606 – Revised Error Handling for BGP UPDATE Messages

➢ IETF RFC 8092 – BGP Large Communities Attribute

➢ IETF RFC 8205 – BGPsec Protocol Specification4

➢ IETF RFC 8206 – BGPsec Considerations for AS Migration4

➢ IETF RFC 8584 – Framework for Ethernet VPN Designated Forwarder Election Extensibility

➢ IETF RFC 8608 – BGPsec Algorithms, Key Formats, and Signature Formats4

Generic Routing Encapsulation

➢ IETF RFC 2784 – Generic Routing Encapsulation (GRE)

➢ IETF RFC 2890 – Key and Sequence Number Extensions to GRE

Multicast Routing

➢ IETF RFC 1112 – Multicast Routing

Multi-Protocol Label Switching (MPLS)

➢ IETF RFC 3107 – Carrying Label Information in BGP-4

➢ IETF RFC 3209 – RSVP-TE: Extensions to RSVP for LSP Tunnels

4 BGPsec support optional at acquisition but must have this capability on Vendor OS development roadmap.

➢ IETF RFC 3469 – Framework for Multi-Protocol Label Switching (MPLS)-based Recovery

➢ IETF RFC 3985 – Pseudo Wire Emulation Edge-to-Edge (PWE3) Architecture

➢ IETF RFC 4364 – BGP/MPLS IP Virtual Private Networks (VPNs)

➢ IETF RFC 4781 – Graceful Restart Mechanism for BGP with MPLS

➢ IETF RFC 4875 – Extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for

Point-to-Multipoint TE Label Switched Paths (LSPs)

➢ IETF RFC 5036 – LDP Specification

➢ IETF RFC 5443 – LDP IGP Synchronization

➢ IETF RFC 6510 – Resource Reservation Protocol (RSVP) Message Formats for Label Switched Path

(LSP) Attributes Objects

➢ IETF RFC 6513 – Multicast in MPLS/BGP IP VPNs

Virtual eXtensible Local Area Network (VXLAN)

➢ IETF RFC 7348 – Virtual eXtensible Local Area Network (VXLAN): A Framework for Overlaying Virtualized Layer 2 Networks over Layer 3 Networks

➢ IETF RFC 8293 – A Framework for Multicast in Network Virtualization over Layer 3

➢ IETF RFC 8365 – A Network Virtualization Overlay Solution Using Ethernet VPN (EVPN)

Network Time Protocol (NTP)

➢ IETF RFC 1305 – NTP version 3 (NTPv3) Specification, Implementation and Analysis 5

➢ IETF RFC 5905 – NTP version 4 (NTPv4): Protocol and Algorithms Specification

➢ IETF RFC 7822 – NTPv4 Extension Fields

➢ IETF RFC 8573 – Message Authentication Code for the Network Time Protocol

Quality of Service (QoS) Standards

➢ IETF RFC 2474 – DIFFSERV Field in the IPv4 and IPv6 Headers

➢ IETF RFC 2475 – Architecture for Differentiated Services

➢ IETF RFC 2597 – Assured Forwarding PHB Group

➢ IETF RFC 3246 – Expedited Forwarding PHB

2.5.2 Internet Protocols

Internet Protocol version 4 (IPv4) Standards

➢ IETF RFC 3021 – Using 31-Bit Prefixes on IPv4 Point-to-Point Links

➢ IETF RFC 6890 – Special-Purpose IP Address Registries

➢ IETF RFC 8190 – Updates to the Special-Purpose IP Address Registries

Internet Protocol version 6 (IPv6) Standards

➢ IETF RFC 2460 – IPv6 Specification

➢ IETF RFC 2461 – IPv6 Neighbor Discovery

➢ IETF RFC 2462 – IPv6 Stateless Address Auto-Configuration

➢ IETF RFC 2463 – ICMPv6

➢ IETF RFC 4291 – IPv6 Addressing Architecture

➢ IETF RFC 3587 – IPv6 Global Unicast Address Format

➢ IETF RFC 2375 – IPv6 Multicast Address Assignments

➢ IETF RFC 2464 – Transmission of IPv6 over Ethernet Networks

5 Only required to support interoperability with legacy time sources if a transition to NTPv4 is still required

➢ IETF RFC 3596 – DNS support

➢ IETF RFC 2893 – Transition Mechanisms for IPv6 Hosts and Routers

2.5.3 Management Protocols

Simple Network Management Protocol version 3 (SNMPv3)

➢ IETF RFC 3414 – User-based Security Model (USM) for version 3 of SNMPv3

➢ IETF RFC 5590 – Transport Subsystem for SNMPv3

➢ IETF RFC 7860 – HMAC-SHA-2 Authentication Protocols in USM for SNMPv3

YANG Data Model

➢ IETF RFC 6020 – YANG – A Data Modeling Language for the NETCONF Protocol

➢ IETF RFC 6022 – YANG Module for NETCONF Monitoring

➢ IETF RFC 6991 – Common YANG Data Types

➢ IETF RFC 7317 – A YANG Data Model for System Management

➢ IETF RFC 7407 – A YANG Data Model for SNMP Configuration

➢ IETF RFC 8341 – Network Configuration Access Control Model

➢ IETF RFC 8342 – Network Management Datastore Architecture (NMDA)

➢ IETF RFC 8343 – A YANG Data Model for Interface Management

➢ IETF RFC 8344 – A YANG Data Model for IP Management

➢ IETF RFC 8345 – A YANG Data Model for Network Topologies

➢ IETF RFC 8346 – A YANG Data Model for Layer 3 Topologies

➢ IETF RFC 8347 – A YANG Data Model for the Virtual Router Redundancy Protocol (VRRP)

➢ IETF RFC 8348 – A YANG Data Model for Hardware Management

➢ IETF RFC 8349 – A YANG Data Model for Routing Management (NMDA Version)

➢ IETF RFC 8431 – A YANG Data Model for the Routing Information Base (RIB)

➢ IETF RFC 8519 – YANG Data Model for Network Access Control Lists (ACLs)

➢ IETF RFC 8525 – YANG Library

➢ IETF RFC 8529 – YANG Data Models for Network Instances

➢ IETF RFC 8530 – YANG Model for Logical Network Elements

➢ IETF RFC 8531 – Generic YANG Data Model for Connection-Oriented OAM Protocols

➢ IETF RFC 8532 – Generic YANG Data Model for the Management of OAM Protocols

➢ IETF RFC 8533 – A YANG Data Model for Retrieval Methods for the Management of Operations, Administration, and Maintenance (OAM) Protocols That Use Connectionless Communications

➢ IETF RFC 8542 – A YANG Data Model for Fabric Topology in Data-Center Networks

➢ IETF RFC 8639 – Subscription to YANG Notifications

➢ IETF RFC 8640 – Dynamic Subscription to YANG Events and Datastores over NETCONF

➢ IETF RFC 8641 – Subscription to YANG Notifications for Datastore Updates

NETwork CONFiguration (NETCONF) Protocol

➢ IETF RFC 6241 – Network Configuration Protocol (NETCONF)

➢ IETF RFC 6242 – Using the NETCONF Protocol over Secure Shell (SSH)

➢ IETF RFC 7589 – Using the NETCONF Protocol over Transport Layer Security (TLS) with Mutual

X.509 Authentication

RESTful CONFiguration (RESTCONF) Protocol

➢ IETF RFC 8040 – RESTCONF Protocol

➢ IETF RFC 8527 – RESTCONF Extensions to Support the NMDA

Network Telemetry Proposed solutions must support Network Flow Telemetry through ONE of the below methodologies:

➢ IETF RFC 3176 – InMon Corporation's sFlow

➢ IETF RFC 3954 – Cisco Systems NetFlow Services Export Version 9

➢ IETF RFC 7011 – Specification of the IPFIX Protocol for the Exchange of Flow Information

➢ IETF RFC 7012 – Information Model for IPFIX

➢ IETF RFC 8038 – Exporting MIB Variables Using the IPFIX Protocol

3 GENERAL SYSTEM STANDARDS & REQUIREMENTS

3.1 HARDWARE REQUIREMENTS

3.1.1 All Systems

➢ All devices MUST provide hardware options for mounting in a 2 or 4 post, EIA standard 19-inch rack or cabinet o NOTE: Compact EAS may use a shelf to fulfill this requirement

3.1.2 Chassis Based Systems

➢ Control plane and data plane functions MUST be performed on physically separate hardware

➢ In the event of a component failure (e.g. interface modules and supervisor engines), data forwarding must continue uninterrupted on all other device components

➢ MUST support front-to-back airflow

➢ All supervisor engines and line cards MUST be field replaceable using a process that does NOT disrupt the system as a whole

3.1.3 Stackable Systems

➢ Individual switches within a stack MUST be 1RU/1.75” in height

➢ Switch stack MUST be capable of mixing models within the same product series

➢ All stackable devices in a switch stack MUST be field replaceable using a process that does NOT disrupt the system as a whole

3.2 PERFORMANCE

3.2.1 Performance - Ports

➢ All interfaces are defined as Backbone Links except for EAS user/device-facing (e.g. laptop, desktop, printer, VoIP phone, etc.), downlink ports.

➢ Each port MUST provide nonblocking performance up to the minimum specified quantity per blade or stackable switch type as specified below o Port capacity in excess of the minimum required need not be non-blocking o Non-blocking as defined in DoD UCR 2013 Change 2, section 7.2.1

➢ MUST be licensable to support 802.1AE-2018 MACSec in the following way:

o All Link Interfaces with 128-bit key standard at full line-rate forwarding speeds o Encryption with 256-bit key standard at full line-rate forwarding speeds is desired but not required at this time.

3.2.2 Performance – Stackable Devices

➢ All stackable devices MUST provide High-Availability through:

o Distributed forwarding across stacked devices o Centralized control plane functionality o Hot-standby for secondary control plane node with sub-second failover

▪ MUST detect device failure and perform failover operations in 100ms or less o Backbone Link-Aggregation using interfaces from different devices

3.3 MODULAR INTERFACES

At the time of writing, the de-facto standards for modular interfaces are SFP and QSFP. All requirements are specified in terms of these two form-factors. New form-factor options MUST be considered valid if, and only if the new standard is widely supported by no less than four vendors across 50% or more of their product lines.

3.3.1 Modular Interface Standards

➢ All interfaces MUST be interchangeable across ALL platforms for each form-factor category

➢ The two form-factor categories are as follows:

o SFP: MUST support interchangeable 1 and 10GbE interface modules o QSFP: MUST support interchangeable 40 and 100GbE interface modules 6

➢ All modular switch ports MUST use SFP or QSFP form-factors:

o Switches MUST NOT require an adapter to insert a 40/100GbE QSFP interface o Switches MUST ONLY require a QSFP-to-SFP adapter when using a 10GbE-SFP in a QSFP port o Solution MUST present optional QSFP-to-SFP adapters for use in ACSs and ADSs o 1GbE SFP interfaces MUST also be interchangeable on Fiber EAS downlink ports

➢ All modular interfaces MUST be configurable for both speed ratings per form-factor category o Requires the appropriate optical interface module inserted into the switch port 7

3.3.2 Optical Interfaces

Functional distances of optical interfaces MUST meet industry standards:

1. Short Reach (SR) - 100m on OM3 MMF

2. Long Reach (LR) - 10km on SMF

3. Extended Reach (ER) - 40km on SMF

4. Ultra-Extended Reach (ZR) - 80km on SMF

All switch platforms MUST support common optics as described below:

➢ The following requirements only apply to the ACS and ADS platforms:

o ALL QSFP switch ports MUST function at BOTH 40 and 100GbE with no loss in port-density o ALL QSFP switch ports MUST support a configuration of 4x10GbE breakout interfaces

▪ MUST provide a QSFP-MPO interface module with 4-pair SMF breakout cable option

• Only required to convert a single 40GbE QSFP port into 4x10GBASE-LR interfaces o 25% of the QSFP switch ports MUST be software configurable for 10GbE mode

▪ MUST provide a QSFP-to-SFP adapter option to use SFP optics in a QSFP port

• Only required in a QSFP-only, ACS or ADS for using 10GBASE-ER (ZR) optics

➢ All interface speeds MUST support optics in LR and ER options for all Backbone ports o ZR optics are highly desired and MUST be proposed as optional items if/when supported o 40GbE-to-4x10GbE breakout interfaces are NOT required to support ER options

➢ MUST support Time Domain Reflectometry (TDR) diagnostic testing capability

3.3.3 Copper Interfaces

➢ MUST support auto Media Dependent Interface/Crossover (MDI/MDIX)

6 EAS is not required to support interchangeable optics on Network Uplink Modules or 100GbE at this time 7 Does not apply to Fiber-EAS Downlink Ports

3.4 MANAGEABILITY AND SUPPORTABILITY

All platforms MUST support the following functions and features:

➢ Minimum hostname length of 63 characters per IETF RFC 1035

➢ Command Line Interface (CLI)

➢ Out-of-band management (OOBM) interface for remote management and troubleshooting capabilities o Dedicated OOBM port using 1Gbps minimum o Dedicated OOBM port using CLI-based console port o EAS, EAS-compact, STES3 EAS, VTB and L2BS MUST support a logical OOBM interface o All other network devices MUST support physical AND logical OOBM interfaces (Not required to simultaneously operate BOTH types)

➢ Management via a single IP interface per device (a stack is treated as one device)

➢ SNMP Version 3 w/AES Encryption and SHA Authentication

➢ SNMP MIB II

➢ Remote Monitoring (RMON)

➢ Support following APIs: YANG and NETCONF o IP-FIX and RESTCONF are not required, but are highly desired

➢ Support for Telemetry and Automation such as: 8 o On-platform scripting (e.g. Python, Perl, or Java) o OpenConfig Data Models for managing and configuring multi-vendor network environments o gRPC for bi-directional streaming telemetry data o gNMI for streaming telemetry data and configuration management information

➢ IPv6 Management

3.5 LAYER 2 FEATURES

All switches MUST perform the below listed Layer 2 functions as part of the default Operating System feature set.

➢ MUST perform all Layer 2 switching and forwarding at line rate

➢ MUST support IEEE 802.1AB – LLDP and LLDP-MED (Media Endpoint Discovery)

➢ MUST support Jumbo Ethernet frames of no less than 9000 bytes o ACS and ADS SHOULD support Jumbo Frame size of 9216 bytes o EAS SHOULD support Jumbo Frame sizes of 9198 bytes

➢ MUST support IEEE 802.1Q-2014 Bridges and Bridged Networks o MUST support 802.1Q VLAN tagging

▪ No less than 4090 configurable VLAN tag values

▪ ACS and ADS MUST support no less than 2000 concurrent VLAN IDs

▪ Standard EAS MUST support no less than 1000 concurrent VLAN IDs

▪ Compact EAS MUST support no less than 128 concurrent VLAN IDs

▪ MUST be able to change, remove, or disable the default VLAN ID o MUST support IEEE 802.1D Spanning-Tree Protocol (STP)

▪ IEEE 802.1s Multiple Spanning-Tree Protocol (MST)

• MUST support no less than 8 MST Instances, including instance 0

8 Not required to support all listed protocols. These are simply examples.

▪ IEEE 802.1w Rapid Spanning Tree Protocol (RSTP)

▪ MUST support Spanning-Tree Root Guard (STIG JIE-ICAN-057)

▪ MUST be configurable, at the system and port level, to:

• Filter STP Bridge-Protocol Data Units (BPDU)

• Detect and protect against STP BPDUs o MUST support IEEE 802.1p, Ethernet Class-of-Service (CoS) expedited forwarding

▪ Ability to mark CoS bits based on access port VLAN ID

▪ Ability to mark CoS bits based on IP Layer Differentiated Services Code Point (DSCP) bits

▪ Ability to prioritize traffic based on CoS markings

➢ MUST support Source Guard (STIG JIE-ICAN-061 and -062)

3.6 LAYER 3 FEATURES

All identified devices MUST be CAPABLE of performing the below listed Layer 3 functions as an additional component feature set of the Operating System. The listed Layer 3 features are primarily identified to support Software Defined LAN capabilities, further defined in section 3.8.

➢ MUST perform all Layer 3 routing and forwarding decisions at line rate

➢ MUST support all IETF RFC standards defined in section 2.5.1

➢ MUST support GRE encapsulation at line rate (maximum interface forwarding rate)

➢ MUST support VXLAN encapsulation and forwarding at line rate

➢ MUST provide separation between control plane and forwarding plane chipsets o Chipset architectures evolve over time. In a chassis-based system, forwarding plane silicon could reside on the Interface line-card itself or the Supervisor line-card. If the forwarding plane hardware resides on the Supervisor, the Supervisor line-card MUST have silicon dedicated to control plane functionality that is NOT shared with any forwarding plane functionality.

➢ MUST support IP Layer Quality-of-Service (QoS) features to include, but not limited to:

o A minimum of eight (8) QoS queues for traffic prioritization o Able to mark DIFFSERV Code Point by an IP ACL or per VRF o Able to assign traffic to queues by DSCP bits o Able to shape traffic bandwidth usage within each QoS queue

3.7 SECURITY FEATURES

DISA Security Technical Implementation Guides (STIGs) establish standards for port security subject to IA requirements. Refer to the DoD Cyber Exchange website (https://cyber.mil/stigs/) for a complete listing of applicable STIGS. All switches connected to the DISN-EN are bound by these STIGs and MUST support the following features and/or protocols:

➢ Denial of Service (DoS) Protection

➢ Transmission Control Protocol Synchronize (TCP SYN) or Smurf Attack Protection

➢ Internet Group Management Protocol (IGMP) Snooping

➢ Unknown Unicast Flood Block (UUFB) (STIG JIE-ICAN-060)

➢ Secure Shell (SSH v2)

➢ Secure Copy (SCP v2)

➢ Hyper Text Transfer Protocol Secure (HTTPS)

➢ Authentication, Authorization, and Accounting (AAA) o Remote Access Dial-In User Service (RADIUS) o Terminal Access Controller Access-Control System Plus (TACACS+)

➢ Various types of user authentication and authorization login methods such as:

o Username/Password (Challenge and Response) o User/machine digital certificate o Two-factor authentication (e.g. RSA token)

➢ Role Based Access Control (RBAC) o Default Standard and Privileged user access levels o Configurable for no less than eight (8) customizable user-groups o Each user-group MUST support specific command and/or command set assignments

➢ Harden other controls or features that would otherwise be vulnerable to malicious attacks o e.g. MUST restrict connections to the Console and VTY interfaces by IP subnet (typically accomplished using Access Control Lists (ACL))

➢ 802.1X-2010 - Port-Based Network Access Control, to include:

o EAP-TLS (Extensible Authentication Protocol – Transport Layer Security) using DoD PKI Machine Identity Certificates o EAP-MD5 (Message Digest 5) for backward compatibility with legacy devices that do not support Device Certificates but support username/password 802.1X o MAC authentication Bypass (MAB) for non-802.1X compliant devices o Multi-Domain support for separation of voice and data devices connected to the same access port o Configurable on a port-by-port basis with three enforcement levels:

▪ Required – Any device connecting to the port MUST authenticate via 802.1X or MAB

• RADIUS policy will determine if the device remains in the VLAN configured on the access port or is dynamically reassigned

▪ Optional – If a device fails to authenticate via DOT1X or MAB, it will be authorized in the VLAN configured on the access port

• Fail Open scenario for migrating a network to 802.1X enforcement

▪ Disabled –802.1X is configured but port remains in a disabled state regardless of device authentication success or failure

➢ IEEE 802.1AE-2018 Media Access Control (MAC) Security standard o MUST be licensable to support 128 Advanced Encryption Standard (AES) in Galois Counter Mode (GCM) both with and without extended packet numbering (XPN)

▪ 256-bit MACSEC is desired, but not required at this time o MUST be licensable to provide MACSec on ALL interfaces, to include:

▪ Backbone Ports: GCM-AES-128 for links up to and including 10Gbps, and GCM-AES-XPN-

128 for links greater than 10Gbps, on all ACS and ADS ports and EAS uplink ports, for Switch-to-Switch link encryption

▪ EAS Edge ports: GCM-AES-128 (GCM-AES-256 desired but not required) for Switch-to- Endpoint link encryption

▪ Endpoint link encryption MUST comply with IEEE 802.1X-2010 o MUST be licensable to support MACSec Key Agreement (MKA) protocol

▪ Between Switch and End-Device connected to an EAS downlink port

▪ Between two switches on backbone links

3.8 SOFTWARE DEFINED NETWORKING (SDN)

Software Defined Networking (SDN) is the long-term target architecture. MILDEPs require an SD-LAN solution that implements a Hierarchical Control Plane model such that each switch can make forwarding decisions WITHOUT requesting flow updates from the controller node for each new flow. However, a controller that provides network abstraction and a centralized flow database that is then distributed to each switch is an acceptable component of the architecture. The SD-LAN solution MUST also provide a centralized Orchestration, Workflow Automation, Management and Telemetry Toolset.

From a security perspective, the SDN solution MUST be capable of BOTH Macro and Micro segmentation across the SDN Fabric. Macro-Segmentation is natively accomplished through network virtualization using VLANs, VRFs, and VXLAN-VNs. Micro-Segmentation may be implemented through port based

VLAN or IP ACLs. Management of these policies MUST be abstracted from any command-line syntax to facilitate ease of creation and deployment for the Network Administrator. Finally, the fabric MUST support dynamic network assignment through a tightly integrated and included 802.1x solution which also enables the implementation of endpoint MACSec encrypted links during the security negotiation process.

All switches/routers MUST be CAPABLE of performing the below listed SDN functions as either an organic or licensed additional component feature set of the Operating System.

3.8.1 Software Defined LAN (SD-LAN)

➢ Operating Systems MUST include, but are not limited to, the following SD-LAN protocols:

o Rapid, Multiple Spanning-Tree (MST) (802.1s and 802.1w) o Dynamic Host Configuration Protocol (DHCP) forwarding o DHCP Relay Service o Virtual Routing and Forwarding (VRF) routing virtualization o Anycast Gateway routing o Point-to-Point (P2P) routed Uplink interfaces with 31-bit subnet masks o Open Shortest Path first versions 2 and 3 (OSPF/OSPFv3) routing o Intermediate-System to Intermediate-System (IS-IS) routing o Multi-Protocol Border Gateway Protocol version 4 (MP-BGPv4) routing o Virtual eXtensible Local Area Network (VXLAN)

➢ All devices (except the Compact-EAS) MUST be SDN-LAN ready to include, but not limited to, the following capabilities:

o Implement open, standards-based protocols 9 o Implement VXLAN as one possible overlay transport protocol o Enable a unified switching fabric o Support centralized management o Support centralized device configuration and orchestration o Support centralized, distributed, or hybrid control plane processing o Identify and prioritize Traffic Flows based on Layer 3 and Layer 4 information o Perform security filtering by traffic flow (L3/L4) o Perform packet Equal Cost Multi-Path (ECMP) forwarding in a switched/routed network

9A vendor’s SDN implementation MUST be based on open, standards approved protocols.

o Implement Traffic Engineering (TE) through software configuration

▪ e.g. bandwidth reservation, path selection/failover

▪ SDN-OS and/or DEM MUST be able to automate TE reconfiguration based on telemetry

➢ SDN solution MUST be interoperable across ALL switch devices 10

3.8.2 Software Defined Network (SDN) Orchestration and Management

➢ MUST centralize management and integrate with existing management tools

➢ MUST automate provisioning of network elements and services o i.e. End-to-End creation/attachment of a Virtual Network (VN) to the overlay network

➢ MUST provide the ability Zero-Touch Provisioning (ZTP) of Network Devices o During initial connection to the network, the orchestrator will

▪ Detect new devices when connecting to the network

▪ Assume management control of new assets

▪ Deploy initial baseline configurations to managed devices via Configuration Templates

▪ Add new devices to the appropriate network fabric

▪ Deploy appropriate VNs to new devices post fabric-integration

10 Most compact switches likely lack enough power and processing capability to fully support SDN protocols. The Compact EAS is NOT REQUIRED to support SDN, but MUST support centralized management and orchestration through the same toolset as ALL other device platforms

4 SPECIFIC SYSTEM STANDARDS & REQUIREMENTS

In this section, MILDEP ICAN-DI HW/SW Standards and Specifications are broken out by individual systems. Three compliance matrices have been constructed for reference in order to get the full set of requirements associated with any one system.

Compliance Matrix-1: System Compliance with IEEE Standards Compliance Matrix-2: Applicable IETF RFC Standards by System Compliance Matrix-3: Applicable General Standards by System

➢ MUST be compliant with Applicable General Standards by System

4.1 APPLICABLE IETF RFC STANDARDS BY SYSTEM

The following set of IETF RFC Standards apply to individual systems as indicated in the matrix below.

Figure 4-1 IETF RFC System Compliance Matrix

Device Element Management systems need not participate in section 2.5.1.1 through section 2.5.1.10

AND section 2.5.1.12 IETF RFC associated protocols, however they must be able to configure the identified protocols on managed devices.

4.2 APPLICABLE GENERAL STANDARDS BY SYSTEM

The following set of General Standards apply to individual systems as indicated in the matrix below.

Figure 4-2 General Standards & Requirements Compliance Matrix

4.3 APPLICABLE PHYSICAL INTERFACE SUPPORT REQUIREMENTS BY SYSTEM

Figure 3-3 Applicable Physical Interface Support Matrix

4.3.1 Optical Interfaces

System must support the following optical interfaces as specified below:

➢ 1GBASE-SX, SFP, Multi-mode Fiber (MMF), Duplex LC connector, and a reach of 550m

➢ 1GBASE-LX, SFP, Single-mode Fiber (SMF), Duplex LC connector, and a reach of 10 km

➢ 10GBASE-SR, SFP+, MMF, Duplex LC connector, and a reach of 300m

➢ 10GBASE-LR, SFP+, SMF, Duplex LC connector, and a reach of 10km

➢ 10GBASE-ER, SFP+, SMF, Duplex LC connector, and a reach of 40km

➢ 10GBASE-ZR, SFP+, SMF, Duplex LC connector, and a reach of 80km

➢ 40GBASE-SR4, QSFP+, OM3+ MMF, Duplex LC connector, and a reach of 100m

➢ 40GBASE-LR4, QSFP+, SMF, Duplex LC connector, and a reach of 10km

➢ 40GBASE-PLR4, QSFP+, SMF, MPO-12 connector, and a reach of 10km o Five meter (5m), SMF, MPO-4xLC breakout cable

➢ 40GBASE-ER4, QSFP+, SMF, Duplex LC connectors, and a reach of 40km

➢ 100GBASE-SR4, QSFP28, OM3+ MMF, Duplex LC connector, and a reach of 100m

➢ 100GBASE-LR4, QSFP28, SMF, Duplex LC connector, and a reach of 10km

➢ 100GBASE-ER4, QSFP28, SMF, Duplex LC connector, and a reach of 40km

➢ QSFP-to-SFP Adapter o To allow use of 10GBASE optics in a 40/100GbE QSFP port on ACS and ADS platforms

4.3.2 Copper Interfaces

System must support the following copper interfaces as specified below:

➢ 1GBASE-T, SFP, Copper media, RJ45 connectors, and rated reach of 100m

➢ 10GBASE-T, SFP+, Copper media, RJ45 connectors, and rated reach of 100m

4.4 EAS SPECIFIC SYSTEM REQUIREMENTS

Edge Access Switch (EAS) devices come in two form factors; the Standard EAS and the Compact EAS.

Each form factor is then also configurable for use on the NIPR (relying on copper user/downstream ports) and for use on the SIPR (relying on SFP based user/downstream ports).

4.4.1 Standard EAS Requirements

MUST support the following without the addition of hardware, software, firmware or licensing:

➢ MUST be compliant with System Compliance with IEEE Standards

➢ MUST be compliant with Applicable IETF RFC Standards by System

➢ MUST be compliant with Applicable General Standards by System

➢ MUST be available in the following device configurations:

o For ALL Standard EAS Devices:

▪ MUST support swappable network modules for backbone uplink ports

• Network Modules MUST be available in 1GbE, 10GbE, and 40GbE options

• MUST be Stackable, with stacking hardware included in proposed solution ♦ MUST provide dedicated stack ports for interconnecting devices ♦ Stack ports MUST not reduce Backbone uplink port capacity ♦ MUST provide no less than 320 Gbps across the backplane interconnections o For use with NIPR Environments:

▪ MINIMUM of 48, 10/100/1000BASE-T, RJ-45 Copper user/downlink ports

▪ Support Switch Stacking with 336-port minimum per stack o For use with SIPR Environments:

▪ MINIMUM of 24, 100/1000BASE-X, SFP Fiber user/downlink ports

▪ Support Switch Stacking with 168-port minimum per stack

➢ MUST be 19-inch rack mountable

➢ MUST be one rack unit (RU) in height (1RU=1.75inch).

➢ MUST have redundant and hot-swappable fans.

➢ MUST have hot-swappable power supplies.

o Input voltage capable of both 120/220 VAC or 48 VDC o Redundant power supplies (N+1 Redundancy).

➢ MUST maintain power redundancy, supporting control/data functions and simultaneous PoE+ on every client facing copper edge port in the event of a single power supply failure either via individual switch’s power redundancy11 or power redundancy within a switch stack configuration.

11 In a single switch use case, POE+ must be provided to 50% of the EAS total number of ports.

4.4.2 Compact EAS Requirements

MUST support the following without the addition of hardware, software, firmware or licensing:

➢ MUST be compliant with System Compliance with IEEE Standards o NOTE: MACSec requirements are waived for the Compact EAS

➢ MUST be compliant with Applicable IETF RFC Standards by System o NOTE: MACSec requirements are waived for the Compact EAS

➢ MUST be compliant with Applicable General Standards by System o NOTE: MACSec requirements are waived for the Compact EAS

➢ MUST be available in the following device configurations:

o For ALL Compact EAS Devices:

▪ MUST support separate uplink and downlink ports

• Minimum of two 1GbE SFP or SFP+ based uplink ports.

• Capable full line-rate bandwidth under full utilization o For use with NIPR Environments:

▪ MINIMUM of 12 10/100/1000BASE-T copper user/downlink ports o For use with SIPR Environments:

▪ MINIMUM of 8, 100/1000BASE-X, SFP Fiber user/downlink ports

➢ MUST include mounting hardware to install in EIA standard 19” rack or cabinet o MUST support options for mounting in non-standard and space constrained areas

▪ e.g. walls, ceilings, credenzas

➢ MUST be smaller than or equal to 1.75” (Height) x 12” (Width) x 10.5” (Depth)

➢ Input voltage capable of both 120/220 VAC o MUST support PoE+ on all user/downlink ports

4.5 ADS SPECIFIC SYSTEM REQUIREMENTS

Area Distribution Switch (ADS) devices come in a single form factor; the Standard ADS configuration which hosts 100% fiber switch ports. Area Distribution Switches (ADS) are used to aggregate multiple switches geographically dispersed in a building prior to reducing the number of uplinks needed between an ACS and EAS. A common use may be in a main telecommunication room (MTR) to aggregate the traffic from switches in secondary TRs. Where outside plant infrastructure exists, the preferred solution is to utilize the MTR as a Fiber Distribution Node (FDN) to connect EAS’ back to the appropriate ACS. An ADS capability should only be used when the outside plant cannot support EAS direct uplinks to the ACS.

4.5.1 Standard ADS Requirements

MUST support the following without the addition of hardware, software, firmware or licensing:

➢ MUST be compliant with System Compliance with IEEE Standards

➢ MUST be compliant with Applicable IETF RFC Standards by System

➢ MUST be compliant with Applicable General Standards by System

➢ MUST be available in the following device configurations:

o For ALL Standard ADS Devices:

▪ MUST include support for a MINIMUM of 256 VRF/VXLAN VNs

▪ MUST include support for a MINIMUM of 250 GRE tunnels

▪ MUST include support for container-based applications

▪ MUST support Virtual-Chassis inter-connect at no less than 800 Gbps throughput o For use with NIPR and SIPR Environments:

▪ MINIMUM of 24, 40/100GbE, QSFP ports

➢ MUST be Stackable or Chassis based o Stacking hardware MUST be included in proposed stackable solution o MUST support dedicated stacking ports separate from data ports

➢ MUST provide redundant Switching Fabric, N+1

➢ MUST have a non-blocking backplane

➢ MUST have redundant and hot-swappable fans (N+1 Redundancy)

➢ MUST have hot-swappable power supplies (N+1 Redundancy) o Input voltage capable of both 120/220 VAC or 48 VDC

➢ MUST be same OEM vendor as EAS devices for link layer integrity.

4.6 ACS SPECIFIC SYSTEM REQUIREMENTS

Area Core Switch (ACS) devices form the network spine of the ICAN, aggregating ADS and EAS uplinks.

The ACS comes in two flavors, either in a Low Density (LD) or High-Density (HD) configuration.

MUST support the following without the addition of hardware, software, firmware or licensing:

➢ MUST be compliant with System Compliance with IEEE Standards

➢ MUST be compliant with Applicable IETF RFC Standards by System

➢ MUST be compliant with Applicable General Standards by System

➢ MUST be available in the following device configurations:

o For ALL Standard ACS Devices:

▪ MUST include support for a MINIMUM of 256 VRF/VXLAN VNs

▪ MUST include support for a MINIMUM of 500 GRE tunnels

▪ MUST include support for container-based applications

▪ MUST support Virtual-Chassis inter-connect at no less than 800 Gbps throughput o For use with Low Density (LD) NIPR Environments:

▪ MINIMUM of 48 port of 40/100GbE, QSFP backbone ports o For use with High Density (HD) Environments:

▪ MINIMUM of 96 ports of 40/100GbE, QSFP backbone ports o Stacking hardware MUST be included in proposed stackable solution

➢ MUST support dedicated stacking ports separate from data ports

➢ MUST provide redundant Switching Fabric, N+1

➢ MUST have redundant switching engines/modules o Chassis MUST provide via two independent blades o Stackable MUST provide via:

▪ Redundant, built-in Route/Switch Processors (RSP)

▪ Redundant RSP across devices when in a stacked configuration

➢ MUST have a non-blocking backplane

➢ MUST have redundant and hot-swappable fans (N+1 Redundancy)

➢ MUST have hot-swappable power supplies (N+1 Redundancy)

➢ MUST be same OEM vendor as EAS devices for link layer integrity

4.7 STES3 SPECIFIC SYSTEM REQUIREMENTS

The Synthetic Training Environment Specific Service Switches (STES3) come in two flavors to address use cases specifically associated with the STE. STES3 EAS devices should be utilized when end user simulation devices or STE wireless access points want/need to uplink at multigigabit speeds (2.5Gbps or

5.0Gbps) to ensure STE throughput requirements are met. To enable untethered simulations, bandwidth to the point of need (personally worn STE devices) usually require wireless connectivity

(modern Access Points operate at multigigabit speeds). STES3 ACS devices should be utilized when a larger simulation environment is rolled out on an ICAN, where a dedicated STE ACS pair distinct from the operational network would improve STE performance and interconnectivity of all STE related components. When deploying STE Service Category 4, 5 or 6 environments, one or both type of STES3 components become necessary.

Figure 4-4 STE Service Categories

4.7.1 STES3 EAS Requirements

MUST support the following without the addition of hardware, software, firmware or licensing:

➢ MUST be compliant with System Compliance with IEEE Standards

➢ MUST be compliant with Applicable IETF RFC Standards by System

➢ MUST be compliant with Applicable General Standards by System

➢ MUST be available in the following device configurations:

o For ALL Standard STES3 EAS Devices:

▪ MUST support swappable network modules for backbone uplink ports

• Network Modules MUST be available in 1GbE, 10GbE, and 40GbE options

• MUST be Stackable, with stacking hardware included in proposed solution ♦ MUST provide dedicated stack ports for interconnecting devices ♦ Stack ports MUST not reduce Backbone uplink port capacity ♦ MUST provide no less than 320 Gbps across the backplane interconnections o For use with NIPR Environments:

▪ MINIMUM of 36, 10/100/1000BASE-T, RJ-45 Copper user/downlink ports

▪ MINIMUM of 12, 100/1000/2500/5000 Base-T RJ-45 Copper user/download ports

• MUST support 802.3bz (Multigigabit Ethernet) RJ45 edge

▪ Support Switch Stacking with 336-port minimum per stack o For use with SIPR Environments:

▪ Same as Standard SIPR EAS Requirements (see section 4.4.1)

STE Service

Category ID

STE Service

Category Label Latency

Training

Block Size

# of

Trainees

Per User

Bandwidth in Mbps

Total STE

Service Switch

Bandwidth in Gbps

01 Constructive / MCIS < 250 ms Company 150 5.2 0.76

02 Semi-Immersive (Thick Client / GPU) < 60 ms Company 150 25 3.66

03 Semi-Immersive (Thin/Zero Client) < 60 ms Company 150 50 7.32

04 Immersive Virtual Reality < 15 ms Company 150 75 10.99

05 Mixed Reality < 10 ms Company 150 300 43.95

06 Live Training <20 ms Brigade 1500 35 51.27

➢ MUST be one rack unit (RU) in height (1RU=1.75inch).

➢ MUST have redundant and hot-swappable fans.

➢ MUST have hot-swappable power supplies.

o Input voltage capable of both 120/220 VAC or 48 VDC o Redundant power supplies (N+1 Redundancy).

➢ MUST maintain power redundancy, supporting control/data functions and simultaneous PoE+ on every client facing copper edge port in the event of a single power supply failure either via individual switch’s power redundancy12 or power redundancy within a switch stack configuration.

4.7.2 STES3 ACS Requirements

MUST support the following without the addition of hardware, software, firmware or licensing:

o For use with NIPR & SIPR Environments:

▪ Same as Standard ACS Requirements (see section 4.6)

4.8 BLR SPECIFIC SYSTEM REQUIREMENTS

The Border Leaf Router (BLR) enables the extension of individual broadcast domains (VLANs) across a

VXLAN backbone and gracefully tie them into DISA’s JB CE routers to ensure VLANs map to WAN VRFs correctly. BLRs are utilized in VX-ETH and VX-SDN environments only. The BLR function requires a minimum of two (2) BLR devices (network egress points), whereby each JB-CE would be paired with a

BLR device.

o For use with NIPR & SIPR Environments:

▪ Same as Standard ADS Requirements (see section 4.5)

4.9 DEM SPECIFIC SYSTEM REQUIREMENTS

The Device Element Manager (DEM) collects, consolidates, normalizes fault, performance, and configuration data from network elements and transmits the data to the Network Management System

(NMS) and the SDN-OS. The DEM is the configuration intermediary through which network elements are actively managed as the SDN-OS effects automation and workflow orchestration requirements.

➢ DEM System Hosting Related Items o MUST be able to run as a Server Virtual Machine (VM) o MUST be able to run on Commodity Hardware

▪ Vendor MUST propose hosting platform hardware to support the SDN-OS

• Hardware Appliance platform is acceptable o MUST be manageable through remote network access

➢ Element Management Requirements:

o MUST provide Vendor Specific LEGACY compatibility Element Management Capability

▪ MUST support SNMPv3, SSH and HTTPS methods o MUST provide Vendor Specific MODERN Element Management Capability

12 In a single switch use case, POE+ must be provided to 50% of the EAS total number of ports.

▪ MUST support as least one of the following: NETCONF, RESTCONF or YANG o MUST be able to execute SDN-OS sent automation/configuration control instructions and configure managed elements to meet network re-configuration requirements.

o MUST allow for remote configuration and monitoring of software.

o MUST provide detailed logs of all administratively specified events.

o The system MUST provide an easy-to-use Graphical User Interface (GUI) that contains status and logging information, as well as controls for modifying policies and managing devices.

o The system MUST provide in-depth, detailed information about any monitored asset, service or function depicted on the GUI. This enables the ability to drill-down on any graphical representation (e.g., icon) to obtain specific relevant detailed information regarding its status.

o The system MUST support a role-based management structure where users/operators are assigned…