| Specifications |
| ************** |
| |
| |
| SDN Features |
| ============ |
| |
| - ONOS cluster of all-active N instances affording N-way redundancy and scale, where N = 3 or N = 5. |
| - Unified operations interface (GUI/REST/CLI) |
| - Centralized configuration – all configuration is done on controller instead of each individual switch |
| - Centralized role-based access control (RBAC) |
| - Automatic host (end-point) discovery – attached hosts, access-devices, appliances (PNFs), routers, etc. |
| based on ARP, DHCP, NDP, etc. |
| - Automatic switch, link and topology discovery and maintenance (keepalive, failure recovery) |
| |
| L2 Features |
| =========== |
| Various L2 connectivity and tunneling support |
| - VLAN-based bridging |
| |
| - Access, Trunk and Native VLAN support |
| - VLAN cross connect |
| |
| - Forward traffic based on outer VLAN id |
| - Forward traffic based on outer and inner VLAN id (QinQ) |
| - Pseudowire |
| |
| - L2 tunneling across the L3 fabric |
| - Support tunneling based on double tagged and single tagged traffic |
| |
| - Support VLAN translation of outer tag |
| |
| L3 Features |
| =========== |
| IP connectivity |
| - IPv4 and IPv6 unicast routing (internal use of MPLS Segment Routing) |
| - Subnetting configuration on all non-spine facing leaf ports; no configuration required on any spine port |
| - IPv6 router advertisement |
| - ARP, NDP, IGMP handling |
| - Number of flows in spines greatly simplified by MPLS Segment Routing |
| - Further reduction of per-leaf flows with route optimization logic |
| |
| DHCP Relay |
| ========== |
| DHCP L3 relay |
| - DHCPv4 and DHCPv6 |
| - DHCP server either directly attached to fabric leaves, or indirectly connected via upstream router |
| - DHCP client directly either attached to fabric leaves, or indirectly connected via LDRA |
| - Multiple DHCP servers for HA |
| |
| vRouter |
| ======= |
| vRouter presents the entire Trellis fabric as a single router (or dual-routers for HA), with disaggregated control/data plane |
| - Uses open-source protocol implementations like Quagga (or FRR) |
| - BGPv4 and BGPv6 |
| - Static routes |
| - Route blackholing |
| - ACLs based on port, L2, L3 and L4 headers |
| |
| Multicast |
| ========= |
| Centralized multicast tree computation, programming and management |
| - Support both IPv4 and IPv6 multicast |
| - Dual-homed multicast sinks for HA |
| - Multiple multicast sources for HA |
| |
| Troubleshooting & Diagnostics |
| ============================= |
| - Troubleshooting tool – T3: Trellis Troubleshooting Tool |
| - Diagnostics one-click collection tool `onos-diags` |
| |
| Topology |
| ======== |
| - Single leaf (ToR) or dual-ToR (dual-homing) |
| - Supports typical leaf-spine topology, 2 to 4 spines, up to 10 leaves |
| - Multi-stage leaf-spine fabric (leaf-spine-spine-leaf) |
| - Can start at the smallest scale (single leaf) and grow horizontally |
| |
| Resiliency |
| ========== |
| Provides HA in following scenarios |
| - Controller instance failure (requires 3 or 5 node ONOS cluster) |
| - Link failures |
| - Spine failure |
| Further HA support in following failure scenarios with dual-homing enabled |
| - Leaf failure |
| - Upstream router failure |
| - Host NIC failure |
| |
| Scalability |
| =========== |
| Trellis has been tested at the following scale. |
| |
| In Production |
| - Up to 80k routes (with route optimization) |
| - 170k Flows |
| - 600 direct-attached hosts |
| - 8 leaf switches |
| - 2 spine switches |
| |
| In Pre-Production |
| - Up to 120k routes (with route optimization) |
| - 250k flows |
| - 600 direct-attached hosts |
| - 8 leaf switches |
| - 2 spine switches |
| |
| Security |
| ======== |
| - TLS-secured connection between controllers and switches (premium feature) |
| - AAA 802.1x authentication |
| - MACSec (L2 encapsulation) |
| |
| P4-ready |
| ======== |
| - Support for Stratum, P4Runtime and gNMI and P4 programs |
| - Innovative services enabled by programmable pipeline |
| |
| - BNG – PPPoE, anti-spoofing, accounting and more |
| - GTP encap/decap |
| |
| Overlay Support |
| =============== |
| Can be used/integrated with 3rd party overlay networks (e.g. OpenStack Neutron, Kubernetes CNI) |
| |
| Orchestrator Support |
| ==================== |
| Can be integrated with external orchestrator, logging, telemetry and alarm service via REST apis and Kafka events |
| |
| Controller Server Specs |
| ======================= |
| Recommended (per ONOS instance) |
| - CPU: 32 Cores |
| - RAM: 128GB RAM. 65GB dedicated to ONOS JVM heap (based on 50K routes) |
| |
| Whitebox Switch Hardware |
| ======================== |
| - Multi-vendor: Edgecore, QCT, Delta, Inventec |
| - Multi-chipset |
| |
| - Broadcom Tomahawk, Trident2, Qumran |
| - Barefoot Tofino |
| - 1/10G, 25G, 40G to 100G |
| - Refer to :doc:`Supported Hardware <supported-hardware>` for the most up-to-date hardware list |
| |
| Whitebox Switch Software |
| ======================== |
| - Open source ONL, ONIE and Indigo OF client |
| |
| - (in production) OF-DPA software commercial version – contact Broadcom |
| |
| - (in labs/trials) OF-DPA software community version available from ONF (for |
| switch models based on Trident and Tomahawk, not Qumran) |
| |
| - (in labs/trials) Stratum available from ONF |