-
Notifications
You must be signed in to change notification settings - Fork 151
zr_tunable_parameters_test
TRANSCEIVER-5: Configuration: 400ZR channel frequency, output TX launch power and operational mode setting.
Validate setting 400ZR tunable parameters channel frequency, output TX launch power and operational mode and verify corresponding telemetry values.
- Verify full C band frequency tunability for 100GHz line system grid.
- Verify full C band frequency tunability for 75GHz line system grid.
- Verify adjustable range of transmit output power across -13 to -9 dBm in steps of 1 dB.
- Verify that the ZR module Host Interface ID and Media Interface ID
combination to ZR module AppSel mapping can be configured through the OC
operational-mode
.operational-mode
is a construct in OpenConfig that masks features related to line port transmission. OC operational modes provides a platform-defined summary of information such as symbol rate, modulation, pulse shaping, etc.
Note For standard ZR, OIF 400ZR with C-FEC is the default mode however as we move to 400ZR++ and 800ZR, optic AppSel code would need to be configured explicitly through OC operational mode.
-
Connect two ZR interfaces using a duplex LC fiber jumper such that TX output power of one is the RX input power of the other module. Connection between the modules should pass through an optical switch that can be controlled through automation to simulate a fiber cut.
-
To establish a point to point ZR link ensure the following:
- Both transceivers states are enabled.
- Validate setting 400ZR optics module tunable laser center frequency across frequency range 196.100 - 191.400 THz for 100GHz grid.
- Validate setting 400ZR optics module tunable laser center frequency across frequency range 196.100 - 191.375 THz for 75GHz grid.
- Specific frequency details can be found in 400ZR implementation agreement under sections 15.1 ad 15.2 Operating frequency channel definitions. Link to IA below,
- Validate adjustable range of transmit output power across -13 to -9 dBm range in steps of 1dB. So the module’s output power will be set to -13, -12, -11, -10, -9 dBm in each step. As an example this can be validated for the module's default frequency of 193.1 THz.
-
With the ZR link established as explained above, for each configured frequency and TX output power value verify that the following ZR transceiver telemetry paths exist and are streamed for both the ZR optics.
- Frequency
- /components/component/optical-channel/state/frequency
- /components/component/optical-channel/state/carrier-frequency-offset/instant
- /components/component/optical-channel/state/carrier-frequency-offset/avg
- /components/component/optical-channel/state/carrier-frequency-offset/min
- /components/component/optical-channel/state/carrier-frequency-offset/max
- TX Output Power
- /components/component/optical-channel/state/output-power/instant
- /components/component/optical-channel/state/output-power/avg
- /components/component/optical-channel/state/output-power/min
- /components/component/optical-channel/state/output-power/max
- Operational Mode
- /components/component/optical-channel/state/operational-mode
- Frequency
-
With above streamed data verify
- For each center frequency, laser frequency offset should not be more than +/- 1.8 GHz max.
- For each center frequency, streamed value should be in Mhz units. Test should fail if the streamed value is in Hz or THz units. As an example 193.1 THz would be 193100000 in MHz.
- When set to a specific target output power, transmit power control absolute accuracy should be within +/- 1 dBm of the target value.
- For reported data check for validity: min <= avg/instant <= max
-
When the modules or the devices are still in a boot stage, they must not stream any invalid string values like "nil" or "-inf".
-
Frequency must be specified as uint64 in MHz. Streamed values for frequency offset must be of type decimal64.
-
TX Output power must be of type decimal64.
-
Verify that the optics Tunable Frequency and TX output power tunes back to the correct value as per configuration after the interface flaps.
- Enable a pair of ZR interfaces on the DUT as explained above.
- Verify the ZR optics frequency and TX output power telemetry values are set in the normal range.
- Disable or shut down the interface on the DUT.
- Verify with interfaces in down state both optics are still streaming configured value for frequency.
- Verify for the TX output power with interface in down state a decimal64 value of -40 dB is streamed.
- Re-enable the interfaces on the DUT.
- Verify the ZR optics tune back to the correct frequency and TX output power as per the configuration and related telemetry values are updated to the value in the normal range again.
-
With above test also verify
- Laser frequency offset should not be more than +/- 1.8 GHz max from the configured centre frequency.
- When set to a specific target output power, transmit power control absolute accuracy should be within +/- 1 dBm of the target configured output power.
- For reported data check for validity: min <= avg/instant <= max
-
Verify that the optics Tunable Frequency and TX output power tunes back to the correct value as per configuration after a fiber cut.
- Enable a pair of ZR interfaces on the DUT as explained above.
- Verify the ZR optics Frequency and TX output power telemetry values are in the normal range.
- Simulate a fiber cut using the optical switch that sits in-between the DUT ports.
- Verify with link in down state due to fiber cut both optics are streaming uint64 for frequency and decimal64 for TX output power.
- Re-enable the optical switch connection to clear the fiber cut fault.
- Verify the ZR optics is able to stay tuned to the correct frequency and TX output power as per the configuration.
-
With above test also verify
- Laser frequency offset should not be more than +/- 1.8 GHz max from the configured centre frequency.
- When set to a specific target output power, transmit power control absolute accuracy should be within +/- 1 dBm of the target configured output power.
- For reported data check for validity: min <= avg/instant <= max
Note: For min, max, and avg values, 10 second sampling is preferred. If 10 seconds is not supported, the sampling interval used must be communicated.
paths:
/components/component/transceiver/config/enabled:
platform_type: ["TRANSCEIVER"]
/components/component/optical-channel/config/frequency:
platform_type: ["OPTICAL_CHANNEL"]
/components/component/optical-channel/config/target-output-power:
platform_type: ["OPTICAL_CHANNEL"]
/components/component/optical-channel/config/operational-mode:
platform_type: ["OPTICAL_CHANNEL"]
/components/component/optical-channel/state/frequency:
platform_type: ["OPTICAL_CHANNEL"]
/components/component/optical-channel/state/carrier-frequency-offset/instant:
platform_type: ["OPTICAL_CHANNEL"]
/components/component/optical-channel/state/carrier-frequency-offset/avg:
platform_type: ["OPTICAL_CHANNEL"]
/components/component/optical-channel/state/carrier-frequency-offset/min:
platform_type: ["OPTICAL_CHANNEL"]
/components/component/optical-channel/state/carrier-frequency-offset/max:
platform_type: ["OPTICAL_CHANNEL"]
/components/component/optical-channel/state/output-power/instant:
platform_type: ["OPTICAL_CHANNEL"]
/components/component/optical-channel/state/output-power/avg:
platform_type: ["OPTICAL_CHANNEL"]
/components/component/optical-channel/state/output-power/min:
platform_type: ["OPTICAL_CHANNEL"]
/components/component/optical-channel/state/output-power/max:
platform_type: ["OPTICAL_CHANNEL"]
/components/component/optical-channel/state/operational-mode:
platform_type: ["OPTICAL_CHANNEL"]
rpcs:
gnmi:
gNMI.Set:
replace: true
gNMI.Subscribe:
on_change: true
FFF
-
Home
- Test Plans
- ACCTZ-1.1: Record Subscribe Full
- ACCTZ-2.1: Record Subscribe Partial
- ACCTZ-3.1: Record Subscribe Non-gRPC
- ACCTZ-4.1: Record History Truncation
- ACCTZ-4.2: Record Payload Truncation
- Authz: General Authz (1-4) tests
- CNTR-1: Basic container lifecycle via
gnoi.Containerz
. - CNTR-2: Container network connectivity tests
- Credentialz-1: Password console login
- Credentialz-2: SSH Password Login Disallowed
- Credentialz-3: Host Certificates
- Credentialz-4: SSH Public Key Authentication
- Credentialz-5: Hiba Authentication
- DP-1.2: QoS policy feature config
- DP-1.3: QoS ECN feature config
- DP-1.4: QoS Interface Output Queue Counters
- DP-1.7: One strict priority queue traffic test
- DP-1.8: Two strict priority queue traffic test
- DP-1.9: WRR traffic test
- DP-1.10: Mixed strict priority and WRR traffic test
- DP-1.11: Bursty traffic test
- DP-1.14: QoS basic test
- example-0.1: Topology Test
- FP-1.1: Power admin DOWN/UP Test
- gNMI-1.1: cli Origin
- gNMI-1.2: Benchmarking: Full Configuration Replace
- gNMI-1.3: Benchmarking: Drained Configuration Convergence Time
- gNMI-1.4: Telemetry: Inventory
- gNMI-1.5: Telemetry: Port Speed Test
- gNMI-1.8: Configuration Metadata-only Retrieve and Replace
- gNMI-1.9: Get requests
- gNMI-1.10: Telemetry: Basic Check
- gNMI-1.11: Telemetry: Interface Packet Counters
- gNMI-1.12: Mixed OpenConfig/CLI Origin
- gNMI-1.13: Optics Telemetry, Instant, threshold, and miscellaneous static info
- gNMI-1.14: OpenConfig metadata consistency during large config push
- gNMI-1.15: Set Requests
- gNMI-1.16: fabric redundancy test
- gNMI-1.17: Controller Card redundancy test
- gNMI-1.18: gNMI subscribe with sample mode for backplane capacity counters
- gNMI-1.19: ConfigPush after Control Card switchover
- gNMI-1.20: Telemetry: Optics Thresholds
- gNMI-1.21: Integrated Circuit Hardware Resource Utilization Test
- gNMI-1.22: Controller card port attributes
- gNMI-1.27: gNMI Sample Mode Test
- GNMI-2: gnmi_subscriptionlist_test
- gNOI-2.1: Packet-based Link Qualification
- gNOI-3.1: Complete Chassis Reboot
- gNOI-3.2: Per-Component Reboot
- gNOI-3.3: Supervisor Switchover
- gNOI-3.4: Chassis Reboot Status and Reboot Cancellation
- gNOI-4.1: Software Upgrade
- gNOI-5.1: Ping Test
- gNOI-5.2: Traceroute Test
- gNOI-5.3: Copying Debug Files
- gNOI-6.1: Factory Reset
- Health-1.1: Generic Health Check
- Health-1.2: Healthz component status paths
- MGT-1: Management HA solution test
- MTU-1.3: Large IP Packet Transmission
- OC-1.2: Default Address Families
- OC-26.1: Network Time Protocol (NTP)
- P4RT-1.1: Base P4RT Functionality
- P4RT-1.2: P4RT Daemon Failure
- P4RT-2.1: P4RT Election
- P4RT-2.2: P4RT Metadata Validation
- P4RT-3.1: Google Discovery Protocol: PacketIn
- P4RT-3.2: Google Discovery Protocol: PacketOut
- P4RT-3.21: Google Discovery Protocol: PacketOut with LAG
- P4RT-5.1: Traceroute: PacketIn
- P4RT-5.2: Traceroute Packetout
- P4RT-5.3: Traceroute: PacketIn With VRF Selection
- P4RT-6.1: Required Packet I/O rate: Performance
- P4RT-7.1: LLDP: PacketIn
- P4RT-7.2: LLDP: PacketOut
- Replay-1.0: Record/replay presession test
- Replay-1.1: Record/replay diff command trees test
- Replay-1.2: P4RT Replay Test
- RT-1.1: Base BGP Session Parameters
- RT-1.2: BGP Policy & Route Installation
- RT-1.3: BGP Route Propagation
- RT-1.4: BGP Graceful Restart
- RT-1.5: BGP Prefix Limit
- RT-1.7: Local BGP Test
- RT-1.10: BGP Keepalive and HoldTimer Configuration Test
- RT-1.11: BGP remove private AS
- RT-1.12: BGP always compare MED
- RT-1.14: BGP Long-Lived Graceful Restart
- RT-1.19: BGP 2-Byte and 4-Byte ASN support
- RT-1.21: BGP TCP MSS and PMTUD
- RT-1.23: BGP AFI SAFI OC DEFAULTS
- RT-1.24: BGP 2-Byte and 4-Byte ASN support with policy
- RT-1.25: Management network-instance default static route
- RT-1.26: Basic static route support
- RT-1.27: Static route to BGP redistribution
- RT-1.28: BGP to IS-IS redistribution
- RT-1.29: BGP chained import/export policy attachment
- RT-1.30: BGP nested import/export policy attachment
- RT-1.32: BGP policy actions - MED, LocPref, prepend, flow-control
- RT-1.33: BGP Policy with prefix-set matching
- RT-1.34: BGP route-distance configuration
- RT-1.51: BGP multipath ECMP
- RT-1.52: BGP multipath UCMP support with Link Bandwidth Community
- RT-1.53: prefix-list test
- RT-1.54: BGP Override AS-path split-horizon
- RT-1.55: BGP session mode (active/passive)
- RT-2.1: Base IS-IS Process and Adjacencies
- RT-2.2: IS-IS LSP Updates
- RT-2.6: IS-IS Hello-Padding enabled at interface level
- RT-2.7: IS-IS Passive is enabled at interface level
- RT-2.8: IS-IS metric style wide not enabled
- RT-2.9: IS-IS metric style wide enabled
- RT-2.10: IS-IS change LSP lifetime
- RT-2.11: IS-IS Passive is enabled at the area level
- RT-2.12: Static route to IS-IS redistribution
- RT-2.13: Weighted-ECMP for IS-IS
- RT-2.14: IS-IS Drain Test
- RT-2.15: IS-IS Graceful Restart Helper
- RT-3.1: Policy based VRF selection
- RT-3.2: Multiple <Protocol, DSCP> Rules for VRF Selection
- RT-4.10: AFTs Route Summary
- RT-4.11: AFTs Route Summary
- RT-5.1: Singleton Interface
- RT-5.2: Aggregate Interfaces
- RT-5.3: Aggregate Balancing
- RT-5.4: Aggregate Forwarding Viable
- RT-5.5: Interface hold-time
- RT-5.6: Interface Loopback mode
- RT-5.7: Aggregate Not Viable All
- RT-5.8: IPv6 Link Local
- RT-5.9: Disable IPv6 ND Router Arvetisment
- RT-5.10: IPv6 Link Local generated by SLAAC
- RT-6.1: Core LLDP TLV Population
- RT-7.1: BGP default policies
- RT-7.2: BGP Policy Community Set
- RT-7.3: BGP Policy AS Path Set
- RT-7.4: BGP Policy AS Path Set and Community Set
- RT-7.5: BGP Policy - Match and Set Link Bandwidth Community
- RT-7.8: BGP Policy Match Standard Community and Add Community Import/Export Policy
- RT-7.11: BGP Policy - Import/Export Policy Action Using Multiple Criteria
- RT-14.2: GRIBI Route Test
- SEC-3.1: Authentication
- SFLOW-1: sFlow Configuration and Sampling
- System-1: System testing
- TE-1.1: Static ARP
- TE-1.2: My Station MAC
- TE-2.1: gRIBI IPv4 Entry
- TE-2.2: gRIBI IPv4 Entry With Aggregate Ports
- TE-3.1: Base Hierarchical Route Installation
- TE-3.2: Traffic Balancing According to Weights
- TE-3.3: Hierarchical weight resolution
- TE-3.5: Ordering: ACK Received
- TE-3.6: ACK in the Presence of Other Routes
- TE-3.7: Base Hierarchical NHG Update
- TE-3.31: Hierarchical weight resolution with PBF
- TE-4.1: Base Leader Election
- TE-4.2: Persistence Mode
- TE-5.1: gRIBI Get RPC
- TE-6.1: Route Removal via Flush
- TE-6.2: Route Removal In Non Default VRF
- TE-8.1: DUT Daemon Failure
- TE-8.2: Supervisor Failure
- TE-9.2: MPLS based forwarding Static LSP
- TE-9.3: FIB FAILURE DUE TO HARDWARE RESOURCE EXHAUST
- TE-9: gRIBI MPLS Compliance
- TE-10: gRIBI MPLS Forwarding
- TE-11.1: Backup NHG: Single NH
- TE-11.2: Backup NHG: Multiple NH
- TE-11.3: Backup NHG: Actions
- TE-11.21: Backup NHG: Multiple NH with PBF
- TE-11.31: Backup NHG: Actions with PBF
- TE-13.1: gRIBI route ADD during Failover
- TE-13.2: gRIBI route DELETE during Failover
- TE-14.1: gRIBI Scaling
- TE-14.2: encap and decap scale
- TE-15.1: gRIBI Compliance
- TE-16.1: basic encapsulation tests
- TE-16.2: encapsulation FRR scenarios
- TE-16.3: encapsulation FRR scenarios
- TE-17.1: VRF selection policy driven TE
- TR-6.1: Remote Syslog feature config
- TRANSCEIVER-1: Telemetry: 400ZR Chromatic Dispersion(CD) telemetry values streaming
- TRANSCEIVER-3: Telemetry: 400ZR Optics firmware version streaming
- TRANSCEIVER-4: Telemetry: 400ZR RX input and TX output power telemetry values streaming.
- TRANSCEIVER-5: Configuration: 400ZR channel frequency, output TX launch power and operational mode setting.
- TRANSCEIVER-6: Telemetry: 400ZR Optics performance metrics (pm) streaming.
- TRANSCEIVER-7: Telemetry: 400ZR Optics inventory info streaming
- TRANSCEIVER-8: Telemetry: 400ZR Optics module temperature streaming.
- TRANSCEIVER-9: Telemetry: 400ZR TX laser bias current telemetry values streaming.
- TRANSCEIVER-10: Telemetry: 400ZR Optics FEC(Forward Error Correction) Uncorrectable Frames Streaming.
- TRANSCEIVER-11: Telemetry: 400ZR Optics logical channels provisioning and related telemetry.
- TRANSCEIVER-12: Telemetry: 400ZR Transceiver Supply Voltage streaming.
- TRANSCEIVER-13: Configuration: 400ZR Transceiver Low Power Mode Setting.
- TUN-1.4: Interface based IPv6 GRE Encapsulation
- TUN-1.9: GRE inner packet DSCP
- Test Plans