This module contains general type definitions and identities for optical transport models.
openconfig-platform-types
openconfig-extensions
openconfig-types
description:
Type for optical spectrum frequency values
type: uint64
units: MHz
description:
Administrative state modes for
logical channels in the transponder model.
type: enumeration
description:
Loopback modes for transponder logical channels
type: enumeration
default: NONE
description:
Base identity for frame mapping protocols that can be used
when mapping Ethernet, OTN or other client signals to OTN
logical channels.
description:
Asynchronous Mapping Procedure
base identity: FRAME_MAPPING_PROTOCOL
description:
Generic Mapping Procedure
base identity: FRAME_MAPPING_PROTOCOL
description:
Bit-synchronous Mapping Procedure
base identity: FRAME_MAPPING_PROTOCOL
description:
Constant Bit Rate Mapping Procedure
base identity: FRAME_MAPPING_PROTOCOL
description:
Transparent Generic Framing Protocol
base identity: FRAME_MAPPING_PROTOCOL
description:
Framed-Mapped Generic Framing Protocol
base identity: FRAME_MAPPING_PROTOCOL
description:
Base identity for tributary slot granularity for OTN
logical channels.
description:
The tributary slot with a bandwidth of approximately 1.25 Gb/s
as defined in ITU-T G.709 standard.
base identity: TRIBUTARY_SLOT_GRANULARITY
description:
The tributary slot with a bandwidth of approximately 2.5 Gb/s
as defined in ITU-T G.709 standard.
base identity: TRIBUTARY_SLOT_GRANULARITY
description:
The tributary slot with a bandwidth of approximately 5 Gb/s
as defined in ITU-T G.709 standard.
base identity: TRIBUTARY_SLOT_GRANULARITY
description:
Base identity for protocol framing used by tributary
signals.
description:
1G Ethernet protocol
base identity: TRIBUTARY_PROTOCOL_TYPE
description:
OC48 protocol
base identity: TRIBUTARY_PROTOCOL_TYPE
description:
STM 16 protocol
base identity: TRIBUTARY_PROTOCOL_TYPE
description:
10G Ethernet LAN protocol
base identity: TRIBUTARY_PROTOCOL_TYPE
description:
10G Ethernet WAN protocol
base identity: TRIBUTARY_PROTOCOL_TYPE
description:
OC 192 (9.6GB) port protocol
base identity: TRIBUTARY_PROTOCOL_TYPE
description:
STM 64 protocol
base identity: TRIBUTARY_PROTOCOL_TYPE
description:
OTU 2 protocol
base identity: TRIBUTARY_PROTOCOL_TYPE
description:
OTU 2e protocol
base identity: TRIBUTARY_PROTOCOL_TYPE
description:
OTU 1e protocol
base identity: TRIBUTARY_PROTOCOL_TYPE
description:
ODU 2 protocol
base identity: TRIBUTARY_PROTOCOL_TYPE
description:
ODU 2e protocol
base identity: TRIBUTARY_PROTOCOL_TYPE
description:
40G Ethernet port protocol
base identity: TRIBUTARY_PROTOCOL_TYPE
description:
OC 768 protocol
base identity: TRIBUTARY_PROTOCOL_TYPE
description:
STM 256 protocol
base identity: TRIBUTARY_PROTOCOL_TYPE
description:
OTU 3 protocol
base identity: TRIBUTARY_PROTOCOL_TYPE
description:
ODU 3 protocol
base identity: TRIBUTARY_PROTOCOL_TYPE
description:
100G Ethernet protocol
base identity: TRIBUTARY_PROTOCOL_TYPE
description:
100G MLG protocol
base identity: TRIBUTARY_PROTOCOL_TYPE
description:
OTU4 signal protocol (112G) for transporting
100GE signal
base identity: TRIBUTARY_PROTOCOL_TYPE
description:
OTU Cn protocol
base identity: TRIBUTARY_PROTOCOL_TYPE
description:
ODU Cn protocol
base identity: TRIBUTARY_PROTOCOL_TYPE
description:
ODU 4 protocol
base identity: TRIBUTARY_PROTOCOL_TYPE
description:
400G Ethernet protocol
base identity: TRIBUTARY_PROTOCOL_TYPE
description:
800G Ethernet protocol
base identity: TRIBUTARY_PROTOCOL_TYPE
description:
Optical tributary signal group protocol
base identity: TRIBUTARY_PROTOCOL_TYPE
description:
ODU Flex with CBR protocol
base identity: TRIBUTARY_PROTOCOL_TYPE
description:
FlexO protocol as defined in ITU-T G.709.1 and ITU-T G.709.3
base identity: TRIBUTARY_PROTOCOL_TYPE
description:
OTSI_A is the digital adaptation between the OTSi and the
FlexO-x, or the regenerator section layer of the FlexO
base identity: TRIBUTARY_PROTOCOL_TYPE
description:
ODU Flex with GFP protocol
base identity: TRIBUTARY_PROTOCOL_TYPE
description:
Base identity for identifying the type of pluggable optic
transceiver (i.e,. form factor) used in a port.
description:
C form-factor pluggable, that can support up to a
100 Gb/s signal with 10x10G or 4x25G physical channels
base identity: TRANSCEIVER_FORM_FACTOR_TYPE
description:
1/2 C form-factor pluggable, that can support up to a
200 Gb/s signal with 10x10G, 4x25G, or 8x25G physical
channels
base identity: TRANSCEIVER_FORM_FACTOR_TYPE
description:
CFP2 analog coherent optics transceiver, supporting
100 Gb, 200Gb, and 250 Gb/s signal.
base identity: TRANSCEIVER_FORM_FACTOR_TYPE
description:
1/4 C form-factor pluggable, that can support up to a
100 Gb/s signal with 10x10G or 4x25G physical channels
base identity: TRANSCEIVER_FORM_FACTOR_TYPE
description:
OriginalQuad Small Form-factor Pluggable transceiver that can
support 4x1G physical channels. Not commonly used.
base identity: TRANSCEIVER_FORM_FACTOR_TYPE
description:
Quad Small Form-factor Pluggable transceiver that can support
up to 4x10G physical channels.
base identity: TRANSCEIVER_FORM_FACTOR_TYPE
description:
QSFP pluggable optic with support for up to 4x28G physical
channels
base identity: TRANSCEIVER_FORM_FACTOR_TYPE
description:
QSFP-DD with electrical interfaces consisting of 8 lanes that operate at up to
25 Gbps with NRZ modulation
base identity: TRANSCEIVER_FORM_FACTOR_TYPE
description:
QSFP pluggable optic with support for up to 4x56G physical
channels
base identity: TRANSCEIVER_FORM_FACTOR_TYPE
description:
QSFP-DD quad small form factor pluggable double density
optic providing an 8 lane electrical interface
base identity: TRANSCEIVER_FORM_FACTOR_TYPE
description:
QSFP DD pluggable optic with support for up to 8x56G physical
channels. Type 1 uses eight optical and electrical signals.
base identity: TRANSCEIVER_FORM_FACTOR_TYPE
description:
QSFP DD pluggable optic with support for up to 4x112G physical
channels. Type 2 uses four optical and eight electrical
signals.
base identity: TRANSCEIVER_FORM_FACTOR_TYPE
description:
Cisco CPAK transceiver supporting 100 Gb/s.
base identity: TRANSCEIVER_FORM_FACTOR_TYPE
description:
Small form-factor pluggable transceiver supporting up to
10 Gb/s signal
base identity: TRANSCEIVER_FORM_FACTOR_TYPE
description:
Enhanced small form-factor pluggable transceiver supporting
up to 16 Gb/s signals, including 10 GbE and OTU2
base identity: TRANSCEIVER_FORM_FACTOR_TYPE
description:
Compact Small form-factor pluggable transceiver. It is a version
of SFP with the same mechanical form factor allowing two independent
bidirectional channels per port.
base identity: TRANSCEIVER_FORM_FACTOR_TYPE
description:
Small form-factor pluggable transceiver supporting up to
25 Gb/s signal
base identity: TRANSCEIVER_FORM_FACTOR_TYPE
description:
Small form-factor pluggable transceiver supporting up to
50 Gb/s signal
base identity: TRANSCEIVER_FORM_FACTOR_TYPE
description:
SFP-DD electrical interfaces will employ 2 lanes that operate up to
25 Gbps NRZ modulation or 56 Gbps PAM4 modulation, providing
solutions up to 50 Gbps or 112 Gbps PAM4 aggregate
base identity: TRANSCEIVER_FORM_FACTOR_TYPE
description:
A transceiver implementing the DSFP Transceiver specification
base identity: TRANSCEIVER_FORM_FACTOR_TYPE
description:
10 Gigabit small form factor pluggable transceiver supporting
10 GbE and OTU2
base identity: TRANSCEIVER_FORM_FACTOR_TYPE
description:
10 Gigabit small form factor pluggable transceiver supporting
10 GbE using a XAUI inerface and 4 data channels.
base identity: TRANSCEIVER_FORM_FACTOR_TYPE
description:
Octal small form factor pluggable transceiver supporting
400 Gb/s or 800 Gb/s.
base identity: TRANSCEIVER_FORM_FACTOR_TYPE
description:
Represents a port that does not require a pluggable optic,
e.g., with on-board optics like COBO
base identity: TRANSCEIVER_FORM_FACTOR_TYPE
description:
Represents a transceiver form factor not otherwise listed
base identity: TRANSCEIVER_FORM_FACTOR_TYPE
description:
Type of optical fiber connector
description:
SC type fiber connector
base identity: FIBER_CONNECTOR_TYPE
description:
LC type fiber connector
base identity: FIBER_CONNECTOR_TYPE
description:
MPO (multi-fiber push-on/pull-off) type fiber connector
1x12 fibers
base identity: FIBER_CONNECTOR_TYPE
description:
AOC (active optical cable) type fiber connector
base identity: FIBER_CONNECTOR_TYPE
description:
DAC (direct attach copper) type fiber connector
base identity: FIBER_CONNECTOR_TYPE
description:
Ethernet compliance codes (PMD) supported by transceivers
description:
Ethernet compliance code: ETH_1000BASE_LX10
base identity: ETHERNET_PMD_TYPE
description:
Ethernet compliance code: 10GBASE_LRM
base identity: ETHERNET_PMD_TYPE
description:
Ethernet compliance code: 10GBASE_LR
base identity: ETHERNET_PMD_TYPE
description:
Ethernet compliance code: 10GBASE_ZR
base identity: ETHERNET_PMD_TYPE
description:
Ethernet compliance code: 10GBASE_ER
base identity: ETHERNET_PMD_TYPE
description:
Ethernet compliance code: 10GBASE_SR
base identity: ETHERNET_PMD_TYPE
description:
Ethernet compliance code: 25GBASE_LR
base identity: ETHERNET_PMD_TYPE
description:
Ethernet compliance code: 25GBASE_SR
base identity: ETHERNET_PMD_TYPE
description:
Ethernet compliance code: 40GBASE_CR4.
This PMD is used in Direct Attach Cables (DAC)
and Active Optical Cables (AOC)
base identity: ETHERNET_PMD_TYPE
description:
Ethernet compliance code: 40GBASE_SR4
base identity: ETHERNET_PMD_TYPE
description:
Ethernet compliance code: 40GBASE_LR4
base identity: ETHERNET_PMD_TYPE
description:
Ethernet compliance code: 40GBASE_ER4
base identity: ETHERNET_PMD_TYPE
description:
Ethernet compliance code: 40GBASE_PSM4
base identity: ETHERNET_PMD_TYPE
description:
Ethernet compliance code: 4x10GBASE_LR
base identity: ETHERNET_PMD_TYPE
description:
Ethernet compliance code: 4x10GBASE_SR
base identity: ETHERNET_PMD_TYPE
description:
Ethernet compliance code: 100G_AOC
base identity: ETHERNET_PMD_TYPE
description:
Ethernet compliance code: 100G_ACC
base identity: ETHERNET_PMD_TYPE
description:
Ethernet compliance code: 100GBASE_SR10
base identity: ETHERNET_PMD_TYPE
description:
Ethernet compliance code: 100GBASE_SR4
base identity: ETHERNET_PMD_TYPE
description:
Ethernet compliance code: 100GBASE_LR4
base identity: ETHERNET_PMD_TYPE
description:
Ethernet compliance code: 100GBASE_ER4L
base identity: ETHERNET_PMD_TYPE
description:
Ethernet compliance code: 100GBASE_ER4
base identity: ETHERNET_PMD_TYPE
description:
Ethernet compliance code: 100GBASE_CWDM4
base identity: ETHERNET_PMD_TYPE
description:
Ethernet compliance code: 100GBASE_CLR4
base identity: ETHERNET_PMD_TYPE
description:
Ethernet compliance code: 100GBASE_PSM4
base identity: ETHERNET_PMD_TYPE
description:
Ethernet compliance code: 100GBASE_CR4.
This PMD is used in Direct Attach Cables (DAC)
and Active Optical Cables (AOC)
base identity: ETHERNET_PMD_TYPE
description:
Ethernet compliance code: 100GBASE_FR
base identity: ETHERNET_PMD_TYPE
description:
Ethernet compliance code: 100GBASE_DR
base identity: ETHERNET_PMD_TYPE
description:
Ethernet compliance code: 400GBASE_ZR
base identity: ETHERNET_PMD_TYPE
description:
Ethernet compliance code: 400GBASE_LR4
base identity: ETHERNET_PMD_TYPE
description:
Ethernet compliance code: 400GBASE_FR4
base identity: ETHERNET_PMD_TYPE
description:
Ethernet compliance code: 400GBASE_LR8
base identity: ETHERNET_PMD_TYPE
description:
Ethernet compliance code: 400GBASE_DR4
base identity: ETHERNET_PMD_TYPE
description:
Ethernet compliance code: 400GMSA_PSM4
base identity: ETHERNET_PMD_TYPE
description:
Ethernet compliance code: undefined
base identity: ETHERNET_PMD_TYPE
description:
Supported SONET/SDH application codes
description:
SONET/SDH application code: VSR2000_3R2
base identity: SONET_APPLICATION_CODE
description:
SONET/SDH application code: VSR2000_3R3
base identity: SONET_APPLICATION_CODE
description:
SONET/SDH application code: VSR2000_3R5
base identity: SONET_APPLICATION_CODE
description:
SONET/SDH application code: undefined
base identity: SONET_APPLICATION_CODE
description:
Supported OTN application codes
description:
OTN application code: P1L1_2D1
base identity: OTN_APPLICATION_CODE
description:
OTN application code: P1S1_2D2
base identity: OTN_APPLICATION_CODE
description:
OTN application code: P1L1_2D2
base identity: OTN_APPLICATION_CODE
description:
OTN application code: undefined
base identity: OTN_APPLICATION_CODE
description:
Rate of tributary signal _- identities will typically reflect
rounded bit rate.
description:
1G tributary signal rate
base identity: TRIBUTARY_RATE_CLASS_TYPE
description:
2.5G tributary signal rate
base identity: TRIBUTARY_RATE_CLASS_TYPE
description:
10G tributary signal rate
base identity: TRIBUTARY_RATE_CLASS_TYPE
description:
40G tributary signal rate
base identity: TRIBUTARY_RATE_CLASS_TYPE
description:
100G tributary signal rate
base identity: TRIBUTARY_RATE_CLASS_TYPE
description:
150G tributary signal rate
base identity: TRIBUTARY_RATE_CLASS_TYPE
description:
200G tributary signal rate
base identity: TRIBUTARY_RATE_CLASS_TYPE
description:
250G tributary signal rate
base identity: TRIBUTARY_RATE_CLASS_TYPE
description:
300G tributary signal rate
base identity: TRIBUTARY_RATE_CLASS_TYPE
description:
350G tributary signal rate
base identity: TRIBUTARY_RATE_CLASS_TYPE
description:
400G tributary signal rate
base identity: TRIBUTARY_RATE_CLASS_TYPE
description:
450G tributary signal rate
base identity: TRIBUTARY_RATE_CLASS_TYPE
description:
500G tributary signal rate
base identity: TRIBUTARY_RATE_CLASS_TYPE
description:
550G tributary signal rate
base identity: TRIBUTARY_RATE_CLASS_TYPE
description:
600G tributary signal rate
base identity: TRIBUTARY_RATE_CLASS_TYPE
description:
650G tributary signal rate
base identity: TRIBUTARY_RATE_CLASS_TYPE
description:
700G tributary signal rate
base identity: TRIBUTARY_RATE_CLASS_TYPE
description:
750G tributary signal rate
base identity: TRIBUTARY_RATE_CLASS_TYPE
description:
800G tributary signal rate
base identity: TRIBUTARY_RATE_CLASS_TYPE
description:
850G tributary signal rate
base identity: TRIBUTARY_RATE_CLASS_TYPE
description:
900G tributary signal rate
base identity: TRIBUTARY_RATE_CLASS_TYPE
description:
950G tributary signal rate
base identity: TRIBUTARY_RATE_CLASS_TYPE
description:
1000G tributary signal rate
base identity: TRIBUTARY_RATE_CLASS_TYPE
description:
1050G tributary signal rate
base identity: TRIBUTARY_RATE_CLASS_TYPE
description:
1100G tributary signal rate
base identity: TRIBUTARY_RATE_CLASS_TYPE
description:
1150G tributary signal rate
base identity: TRIBUTARY_RATE_CLASS_TYPE
description:
1200G tributary signal rate
base identity: TRIBUTARY_RATE_CLASS_TYPE
description:
1250G tributary signal rate
base identity: TRIBUTARY_RATE_CLASS_TYPE
description:
1300G tributary signal rate
base identity: TRIBUTARY_RATE_CLASS_TYPE
description:
1350G tributary signal rate
base identity: TRIBUTARY_RATE_CLASS_TYPE
description:
1400G tributary signal rate
base identity: TRIBUTARY_RATE_CLASS_TYPE
description:
1450G tributary signal rate
base identity: TRIBUTARY_RATE_CLASS_TYPE
description:
1500G tributary signal rate
base identity: TRIBUTARY_RATE_CLASS_TYPE
description:
1550G tributary signal rate
base identity: TRIBUTARY_RATE_CLASS_TYPE
description:
1600G tributary signal rate
base identity: TRIBUTARY_RATE_CLASS_TYPE
description:
1650G tributary signal rate
base identity: TRIBUTARY_RATE_CLASS_TYPE
description:
1700G tributary signal rate
base identity: TRIBUTARY_RATE_CLASS_TYPE
description:
1750G tributary signal rate
base identity: TRIBUTARY_RATE_CLASS_TYPE
description:
1800G tributary signal rate
base identity: TRIBUTARY_RATE_CLASS_TYPE
description:
1850G tributary signal rate
base identity: TRIBUTARY_RATE_CLASS_TYPE
description:
1900G tributary signal rate
base identity: TRIBUTARY_RATE_CLASS_TYPE
description:
1950G tributary signal rate
base identity: TRIBUTARY_RATE_CLASS_TYPE
description:
2000G tributary signal rate
base identity: TRIBUTARY_RATE_CLASS_TYPE
description:
2050G tributary signal rate
base identity: TRIBUTARY_RATE_CLASS_TYPE
description:
2100G tributary signal rate
base identity: TRIBUTARY_RATE_CLASS_TYPE
description:
2150G tributary signal rate
base identity: TRIBUTARY_RATE_CLASS_TYPE
description:
2200G tributary signal rate
base identity: TRIBUTARY_RATE_CLASS_TYPE
description:
2250G tributary signal rate
base identity: TRIBUTARY_RATE_CLASS_TYPE
description:
2300G tributary signal rate
base identity: TRIBUTARY_RATE_CLASS_TYPE
description:
2350G tributary signal rate
base identity: TRIBUTARY_RATE_CLASS_TYPE
description:
2400G tributary signal rate
base identity: TRIBUTARY_RATE_CLASS_TYPE
description:
2450G tributary signal rate
base identity: TRIBUTARY_RATE_CLASS_TYPE
description:
2500G tributary signal rate
base identity: TRIBUTARY_RATE_CLASS_TYPE
description:
2550G tributary signal rate
base identity: TRIBUTARY_RATE_CLASS_TYPE
description:
2600G tributary signal rate
base identity: TRIBUTARY_RATE_CLASS_TYPE
description:
2650G tributary signal rate
base identity: TRIBUTARY_RATE_CLASS_TYPE
description:
2700G tributary signal rate
base identity: TRIBUTARY_RATE_CLASS_TYPE
description:
2750G tributary signal rate
base identity: TRIBUTARY_RATE_CLASS_TYPE
description:
2800G tributary signal rate
base identity: TRIBUTARY_RATE_CLASS_TYPE
description:
2850G tributary signal rate
base identity: TRIBUTARY_RATE_CLASS_TYPE
description:
2900G tributary signal rate
base identity: TRIBUTARY_RATE_CLASS_TYPE
description:
2950G tributary signal rate
base identity: TRIBUTARY_RATE_CLASS_TYPE
description:
3000G tributary signal rate
base identity: TRIBUTARY_RATE_CLASS_TYPE
description:
3050G tributary signal rate
base identity: TRIBUTARY_RATE_CLASS_TYPE
description:
3100G tributary signal rate
base identity: TRIBUTARY_RATE_CLASS_TYPE
description:
3150G tributary signal rate
base identity: TRIBUTARY_RATE_CLASS_TYPE
description:
3200G tributary signal rate
base identity: TRIBUTARY_RATE_CLASS_TYPE
description:
Type of protocol framing used on the logical channel or
tributary
description:
Ethernet protocol framing
base identity: LOGICAL_ELEMENT_PROTOCOL_TYPE
description:
OTN protocol framing
base identity: LOGICAL_ELEMENT_PROTOCOL_TYPE
description:
Types of fiber jumpers used for connecting device ports
description:
Simplex fiber jumper
base identity: FIBER_JUMPER_TYPE
description:
One strand of a fiber jumper which contains multiple fibers
within it, such as an MPO based fiber jumper
base identity: FIBER_JUMPER_TYPE
description:
Type definition for optical transport port types
description:
Ingress port, corresponding to a signal entering
a line system device such as an amplifier or wavelength
router.
base identity: OPTICAL_PORT_TYPE
description:
Egress port, corresponding to a signal exiting
a line system device such as an amplifier or wavelength
router.
base identity: OPTICAL_PORT_TYPE
description:
Add port, corresponding to a signal injected
at a wavelength router.
base identity: OPTICAL_PORT_TYPE
description:
Drop port, corresponding to a signal dropped
at a wavelength router.
base identity: OPTICAL_PORT_TYPE
description:
Monitor port, corresponding to a signal used by an optical
channel monitor. This is used to represent the connection
that a channel monitor port is connected to, typically on a
line system device. This connection may be via physical cable
and faceplate ports or internal to the device
base identity: OPTICAL_PORT_TYPE
description:
Client-facing port on a terminal optics device (e.g.,
transponder or muxponder).
base identity: OPTICAL_PORT_TYPE
description:
Line-facing port on a terminal optics device (e.g.,
transponder or muxponder).
base identity: OPTICAL_PORT_TYPE
description:
Type definition for optical transport client mapping modes.
description:
1 x 100G client mapping mode.
base identity: CLIENT_MAPPING_MODE
description:
1 x 200G client mapping mode.
base identity: CLIENT_MAPPING_MODE
description:
1 x 400G client mapping mode.
base identity: CLIENT_MAPPING_MODE
description:
2 x 100G client mapping mode.
base identity: CLIENT_MAPPING_MODE
description:
2 x 200G client mapping mode.
base identity: CLIENT_MAPPING_MODE
description:
3 x 100G client mapping mode.
base identity: CLIENT_MAPPING_MODE
description:
4 x 100G client mapping mode.
base identity: CLIENT_MAPPING_MODE
description:
Type definition for transceiver module functional types.
description:
Standard optic using a grey wavelength (i.e. 1310, 1550, etc.)
and on-off-keying (OOK) modulation.
base identity: TRANSCEIVER_MODULE_FUNCTIONAL_TYPE
description:
Digital coherent module which transmits a phase / amplitude
modulated signal and uses a digital signal processor to receive
and decode the received signal.
base identity: TRANSCEIVER_MODULE_FUNCTIONAL_TYPE
This module defines data types (e.g., YANG identities) to support the OpenConfig component inventory model.
openconfig-types
openconfig-extensions
description:
A generic type reflecting whether a hardware component
is powered on or off
type: enumeration
description:
A generic type reflecting the component's redundanty role.
For example, a device might have dual supervisors components
for redundant purpose, with one being the primary and the
other secondary.
type: enumeration
description:
Records how the role switchover is triggered.
type: enumeration
description:
Records how the last power-off was triggered.
type: enumeration
description:
Base identity for hardware related components in a managed
device. Derived identities are partially based on contents
of the IANA Entity MIB.
description:
Chassis component, typically with multiple slots / shelves
base identity: OPENCONFIG_HARDWARE_COMPONENT
description:
Backplane component for aggregating traffic, typically
contained in a chassis component
base identity: OPENCONFIG_HARDWARE_COMPONENT
description:
Interconnect between ingress and egress ports on the
device (e.g., a crossbar switch).
base identity: OPENCONFIG_HARDWARE_COMPONENT
description:
Component that is supplying power to the device
base identity: OPENCONFIG_HARDWARE_COMPONENT
description:
Cooling fan, or could be some other heat-reduction component
base identity: OPENCONFIG_HARDWARE_COMPONENT
description:
Contains multiple fans that work in unison to cool the router components.
base identity: OPENCONFIG_HARDWARE_COMPONENT
description:
Controls the fan trays.
base identity: OPENCONFIG_HARDWARE_COMPONENT
description:
Physical sensor, e.g., a temperature sensor in a chassis
base identity: OPENCONFIG_HARDWARE_COMPONENT
description:
Replaceable hardware component that does not have a more
specific defined schema.
base identity: OPENCONFIG_HARDWARE_COMPONENT
description:
Linecard component, typically inserted into a chassis slot
base identity: OPENCONFIG_HARDWARE_COMPONENT
description:
A type of linecard whose primary role is management or control
rather than data forwarding.
base identity: OPENCONFIG_HARDWARE_COMPONENT
description:
Physical port, e.g., for attaching pluggables and networking
cables
base identity: OPENCONFIG_HARDWARE_COMPONENT
description:
Pluggable module present in a port
base identity: OPENCONFIG_HARDWARE_COMPONENT
description:
Processing unit, e.g., a management processor
base identity: OPENCONFIG_HARDWARE_COMPONENT
description:
A storage subsystem on the device (disk, SSD, etc.)
base identity: OPENCONFIG_HARDWARE_COMPONENT
description:
A special purpose processing unit, typically for traffic
switching/forwarding (e.g., switching ASIC, NPU, forwarding
chip, etc.)
base identity: OPENCONFIG_HARDWARE_COMPONENT
description:
A device that attaches to a an Ethernet network and creates a wireless
local area network
base identity: OPENCONFIG_HARDWARE_COMPONENT
description:
Base identity for software-related components in a managed
device
description:
Operating system running on a component
base identity: OPENCONFIG_SOFTWARE_COMPONENT
description:
An operating system update - which should be a subcomponent
of the `OPERATING_SYSTEM` running on a component. An update is
defined to be a set of software changes that are atomically
installed (and uninstalled) together. Multiple updates may be
present for the Operating System. A system should not list all
installed software packages using this type -- but rather
updates that are bundled together as a single installable
item
base identity: OPENCONFIG_SOFTWARE_COMPONENT
description:
Legacy BIOS or UEFI firmware interface responsible for
initializing hardware components and first stage boot loader.
base identity: OPENCONFIG_SOFTWARE_COMPONENT
description:
Software layer responsible for loading and booting the
device OS or network OS.
base identity: OPENCONFIG_SOFTWARE_COMPONENT
description:
A base identity for software modules installed and/or
running on the device. Modules include user-space programs
and kernel modules that provide specific functionality.
A component with type SOFTWARE_MODULE should also have a
module type that indicates the specific type of software module
base identity: OPENCONFIG_SOFTWARE_COMPONENT
description:
Current operational status of a platform component
description:
Component is enabled and active (i.e., up)
base identity: COMPONENT_OPER_STATUS
description:
Component is enabled but inactive (i.e., down)
base identity: COMPONENT_OPER_STATUS
description:
Component is administratively disabled.
base identity: COMPONENT_OPER_STATUS
description:
Base identity for FEC operational modes.
description:
FEC is administratively enabled.
base identity: FEC_MODE_TYPE
description:
FEC is administratively disabled.
base identity: FEC_MODE_TYPE
description:
System will determine whether to enable or disable
FEC on a transceiver.
base identity: FEC_MODE_TYPE
description:
Base identity for FEC operational statuses.
description:
FEC is operationally locked.
base identity: FEC_STATUS_TYPE
description:
FEC is operationally unlocked.
base identity: FEC_STATUS_TYPE
description:
Base entity for component reboot reasons.
description:
User initiated the reboot of the componenent.
base identity: COMPONENT_REBOOT_REASON
description:
The component reboots due to power failure.
base identity: COMPONENT_REBOOT_REASON
description:
The component reboots due to critical errors.
base identity: COMPONENT_REBOOT_REASON
This module describes a terminal optics device model for managing the terminal systems (client and line side) in a DWDM transport network.
Elements of the model:
physical port: corresponds to a physical, pluggable client port on the terminal device. Examples includes 10G, 40G, 100G (e.g., 10x10G, 4x25G or 1x100G) and 400G/1T in the future. Physical client ports will have associated operational state or PMs.
physical channel: a physical lane or channel in the physical client port. Each physical client port has 1 or more channels. An example is 100GBASE-LR4 client physical port having 4x25G channels. Channels have their own optical PMs and can be monitored independently within a client physical port (e.g., channel power). Physical client channels are defined in the model as part of a physical client port, and are modeled primarily for reading their PMs.
logical channel: a logical grouping of logical grooming elements that may be assigned to subsequent grooming stages for multiplexing / de-multiplexing, or to an optical channel for line side transmission. The logical channels can represent, for example, an ODU/OTU logical packing of the client data onto the line side. Tributaries are similarly logical groupings of demand that can be represented in this structure and assigned to an optical channel. Note that different types of logical channels may be present, each with their corresponding PMs.
optical channel: corresponds to an optical carrier and is assigned a wavelength/frequency. Optical channels have PMs such as power, BER, and operational mode.
Directionality:
To maintain simplicity in the model, the configuration is described from client-to-line direction. The assumption is that equivalent reverse configuration is implicit, resulting in the same line-to-client configuration.
Physical layout:
The model does not assume a particular physical layout of client and line ports on the terminal device (e.g., such as number of ports per linecard, separate linecards for client and line ports, etc.).
openconfig-types
openconfig-transport-types
openconfig-if-ethernet
openconfig-interfaces
openconfig-platform
openconfig-platform-transceiver
openconfig-lldp
openconfig-extensions
ietf-yang-types
openconfig-yang-types
description:
Top-level container for the terminal device
nodetype: container (rw)
description:
Configuration data for global terminal-device
nodetype: container (rw)
description:
Operational state data for global terminal device
nodetype: container (ro)
description:
Enclosing container the list of logical channels
nodetype: container (rw)
description:
List of logical channels
nodetype: list (rw)
list keys: [index]
description:
Reference to the index of the logical channel
nodetype: leaf (list key) (rw)
type: leafref
description:
Configuration data for logical channels
nodetype: container (rw)
description:
Index of the current logical channel
nodetype: leaf (rw)
type: uint32
description:
Description of the logical channel
nodetype: leaf (rw)
type: string
description:
Sets the admin state of the logical channel
nodetype: leaf (rw)
type: oc-opt-types:admin-state-type
description:
Rounded bit rate of the tributary signal. Exact bit rate
will be refined by protocol selection.
nodetype: leaf (rw)
type: identityref
description:
Protocol framing of the tributary signal. If this
LogicalChannel is directly connected to a Client-Port or
Optical-Channel, this is the protocol of the associated port.
If the LogicalChannel is connected to other LogicalChannels,
the TributaryProtocol of the LogicalChannels will define a
specific mapping/demapping or multiplexing/demultiplexing
function.
Not all protocols are valid, depending on the value
of trib-rate-class. The expectation is that the NMS
will validate that a correct combination of rate class
and protocol are specfied. Basic combinations are:
rate class: 1G
protocols: 1GE
rate class: 2.5G
protocols: OC48, STM16
rate class: 10G
protocols: 10GE LAN, 10GE WAN, OC192, STM64, OTU2, OTU2e,
OTU1e, ODU2, ODU2e, ODU1e
rate class: 40G
protocols: 40GE, OC768, STM256, OTU3, ODU3
rate class: 100G
protocols: 100GE, 100G MLG, OTU4, OTUCn, ODU4
nodetype: leaf (rw)
type: identityref
description:
The type / stage of the logical element determines the
configuration and operational state parameters (PMs)
available for the logical element
nodetype: leaf (rw)
type: identityref
description:
Sets the loopback type on the logical channel. Setting the
mode to something besides NONE activates the loopback in
the specified mode.
nodetype: leaf (rw)
type: oc-opt-types:loopback-mode-type
description:
When enabled the logical channel's DSP will generate a pseudo
randmon bit stream (PRBS) which can be used during testing.
nodetype: leaf (rw)
type: boolean
description:
The client side mapping mode internal to the device that
specifies the number of client electrical interfaces and
the data rate of each client electrical interface. For
example, a ZR+ transceiver with an optical line rate of 400G
could be configured to break out into four 100G client
signals which might connect to an interface or a
physical-channel. This would be configured on the aggregate
logical channel as MODE_4X100G. This is only valid on the
aggregate logical channel that is connected directly to the
optical-channel.
nodetype: leaf (rw)
type: identityref
description:
Operational state data for logical channels
nodetype: container (ro)
description:
Index of the current logical channel
nodetype: leaf (ro)
type: uint32
description:
Description of the logical channel
nodetype: leaf (ro)
type: string
description:
Sets the admin state of the logical channel
nodetype: leaf (ro)
type: oc-opt-types:admin-state-type
description:
Rounded bit rate of the tributary signal. Exact bit rate
will be refined by protocol selection.
nodetype: leaf (ro)
type: identityref
description:
Protocol framing of the tributary signal. If this
LogicalChannel is directly connected to a Client-Port or
Optical-Channel, this is the protocol of the associated port.
If the LogicalChannel is connected to other LogicalChannels,
the TributaryProtocol of the LogicalChannels will define a
specific mapping/demapping or multiplexing/demultiplexing
function.
Not all protocols are valid, depending on the value
of trib-rate-class. The expectation is that the NMS
will validate that a correct combination of rate class
and protocol are specfied. Basic combinations are:
rate class: 1G
protocols: 1GE
rate class: 2.5G
protocols: OC48, STM16
rate class: 10G
protocols: 10GE LAN, 10GE WAN, OC192, STM64, OTU2, OTU2e,
OTU1e, ODU2, ODU2e, ODU1e
rate class: 40G
protocols: 40GE, OC768, STM256, OTU3, ODU3
rate class: 100G
protocols: 100GE, 100G MLG, OTU4, OTUCn, ODU4
nodetype: leaf (ro)
type: identityref
description:
The type / stage of the logical element determines the
configuration and operational state parameters (PMs)
available for the logical element
nodetype: leaf (ro)
type: identityref
description:
Sets the loopback type on the logical channel. Setting the
mode to something besides NONE activates the loopback in
the specified mode.
nodetype: leaf (ro)
type: oc-opt-types:loopback-mode-type
description:
When enabled the logical channel's DSP will generate a pseudo
randmon bit stream (PRBS) which can be used during testing.
nodetype: leaf (ro)
type: boolean
description:
The client side mapping mode internal to the device that
specifies the number of client electrical interfaces and
the data rate of each client electrical interface. For
example, a ZR+ transceiver with an optical line rate of 400G
could be configured to break out into four 100G client
signals which might connect to an interface or a
physical-channel. This would be configured on the aggregate
logical channel as MODE_4X100G. This is only valid on the
aggregate logical channel that is connected directly to the
optical-channel.
nodetype: leaf (ro)
type: identityref
description:
Link-state of the Ethernet protocol on the logical channel,
SONET / SDH framed signal, etc.
nodetype: leaf (ro)
type: enumeration
description:
Top level container for OTU configuration when logical
channel framing is using an OTU protocol, e.g., OTU1, OTU3,
etc.
nodetype: container (rw)
description:
Configuration data for OTN protocol framing
nodetype: container (rw)
description:
Trail trace identifier (TTI) message transmitted
nodetype: leaf (rw)
type: string
description:
Trail trace identifier (TTI) message expected
nodetype: leaf (rw)
type: string
description:
Trail trace identifier (TTI) transmit message automatically
created. If true, then setting a custom transmit message
would be invalid.
nodetype: leaf (rw)
type: boolean
description:
Granularity value of OPUk or OPUCn tributary slots for OTN
signal allocation. The currently defined values follow the
existing ITU-T G.709 standard, which can be extended as
needed in future.
nodetype: leaf (rw)
type: identityref
description:
Operational state data for OTN protocol PMs, statistics,
etc.
nodetype: container (ro)
description:
Trail trace identifier (TTI) message transmitted
nodetype: leaf (ro)
type: string
description:
Trail trace identifier (TTI) message expected
nodetype: leaf (ro)
type: string
description:
Trail trace identifier (TTI) transmit message automatically
created. If true, then setting a custom transmit message
would be invalid.
nodetype: leaf (ro)
type: boolean
description:
Granularity value of OPUk or OPUCn tributary slots for OTN
signal allocation. The currently defined values follow the
existing ITU-T G.709 standard, which can be extended as
needed in future.
nodetype: leaf (ro)
type: identityref
description:
Trail trace identifier (TTI) message received
nodetype: leaf (ro)
type: string
description:
Remote defect indication (RDI) message received
nodetype: leaf (ro)
type: string
description:
The number of seconds that at least one errored blocks
occurs, at least one code violation occurs, loss of sync is
detected or loss of signal is detected
nodetype: leaf (ro)
type: yang:counter64
description:
The number of seconds that loss of frame is detected OR
the number of errored blocks, code violations, loss of sync
or loss of signal is detected exceeds a predefined
threshold
nodetype: leaf (ro)
type: yang:counter64
description:
The number of seconds during which the link is unavailable
nodetype: leaf (ro)
type: yang:counter64
description:
For ethernet or fiberchannel links, the number of 8b/10b
coding violations. For SONET/SDH, the number of BIP (bit
interleaved parity) errors
nodetype: leaf (ro)
type: yang:counter64
description:
The number of errored blocks. Error detection codes are
capable to detect whether one or more errors have occurred
in a given sequence of bits – the block. It is normally not
possible to determine the exact number of errored bits within
the block.
nodetype: leaf (ro)
type: yang:counter64
description:
The number of words that were uncorrectable by the FEC
nodetype: leaf (ro)
type: yang:counter64
description:
The number of bytes that were corrected by the FEC
nodetype: leaf (ro)
type: yang:counter64
description:
The number of bits that were corrected by the FEC
nodetype: leaf (ro)
type: yang:counter64
description:
The number of background block errors
nodetype: leaf (ro)
type: yang:counter64
description:
The number of blocks or frames that were uncorrectable by
the FEC
nodetype: leaf (ro)
type: yang:counter64
description:
Bit error rate before forward error correction -- computed
value with 18 decimal precision. Note that decimal64
supports values as small as i x 10^-18 where i is an
integer. Values smaller than this should be reported as 0
to inidicate error free or near error free performance.
Values include the instantaneous, average, minimum, and
maximum statistics. If avg/min/max statistics are not
supported, the target is expected to just supply the
instant value
nodetype: container (ro)
description:
The instantaneous value of the statistic.
nodetype: leaf (ro)
type: decimal64
units: bit-errors-per-second
description:
The arithmetic mean value of the statistic over the
time interval.
nodetype: leaf (ro)
type: decimal64
units: bit-errors-per-second
description:
The minimum value of the statistic over the time
interval.
nodetype: leaf (ro)
type: decimal64
units: bit-errors-per-second
description:
The maximum value of the statistic over the time
interval.
nodetype: leaf (ro)
type: decimal64
units: bit-errors-per-second
description:
If supported by the system, this reports the time interval
over which the min/max/average statistics are computed by
the system.
nodetype: leaf (ro)
type: oc-types:stat-interval
description:
The absolute time at which the minimum value occurred.
The value is the timestamp in nanoseconds relative to
the Unix Epoch (Jan 1, 1970 00:00:00 UTC).
nodetype: leaf (ro)
type: oc-types:timeticks64
description:
The absolute time at which the maximum value occurred.
The value is the timestamp in nanoseconds relative to
the Unix Epoch (Jan 1, 1970 00:00:00 UTC).
nodetype: leaf (ro)
type: oc-types:timeticks64
description:
Bit error rate after forward error correction -- computed
value with 18 decimal precision. Note that decimal64
supports values as small as i x 10^-18 where i is an
integer. Values smaller than this should be reported as 0
to inidicate error free or near error free performance.
Values include the instantaneous, average, minimum, and
maximum statistics. If avg/min/max statistics are not
supported, the target is expected to just supply the
instant value
nodetype: container (ro)
description:
The instantaneous value of the statistic.
nodetype: leaf (ro)
type: decimal64
units: bit-errors-per-second
description:
The arithmetic mean value of the statistic over the
time interval.
nodetype: leaf (ro)
type: decimal64
units: bit-errors-per-second
description:
The minimum value of the statistic over the time
interval.
nodetype: leaf (ro)
type: decimal64
units: bit-errors-per-second
description:
The maximum value of the statistic over the time
interval.
nodetype: leaf (ro)
type: decimal64
units: bit-errors-per-second
description:
If supported by the system, this reports the time interval
over which the min/max/average statistics are computed by
the system.
nodetype: leaf (ro)
type: oc-types:stat-interval
description:
The absolute time at which the minimum value occurred.
The value is the timestamp in nanoseconds relative to
the Unix Epoch (Jan 1, 1970 00:00:00 UTC).
nodetype: leaf (ro)
type: oc-types:timeticks64
description:
The absolute time at which the maximum value occurred.
The value is the timestamp in nanoseconds relative to
the Unix Epoch (Jan 1, 1970 00:00:00 UTC).
nodetype: leaf (ro)
type: oc-types:timeticks64
description:
Quality value (factor) in dB of a channel with two
decimal precision. Values include the instantaneous,
average, minimum, and maximum statistics. If avg/min/max
statistics are not supported, the target is expected
to just supply the instant value
nodetype: container (ro)
description:
The instantaneous value of the statistic.
nodetype: leaf (ro)
type: decimal64
units: dB
description:
The arithmetic mean value of the statistic over the
time interval.
nodetype: leaf (ro)
type: decimal64
units: dB
description:
The minimum value of the statistic over the time interval.
nodetype: leaf (ro)
type: decimal64
units: dB
description:
The maximum value of the statistic over the time
interval.
nodetype: leaf (ro)
type: decimal64
units: dB
description:
If supported by the system, this reports the time interval
over which the min/max/average statistics are computed by
the system.
nodetype: leaf (ro)
type: oc-types:stat-interval
description:
The absolute time at which the minimum value occurred.
The value is the timestamp in nanoseconds relative to
the Unix Epoch (Jan 1, 1970 00:00:00 UTC).
nodetype: leaf (ro)
type: oc-types:timeticks64
description:
The absolute time at which the maximum value occurred.
The value is the timestamp in nanoseconds relative to
the Unix Epoch (Jan 1, 1970 00:00:00 UTC).
nodetype: leaf (ro)
type: oc-types:timeticks64
description:
Electrical signal to noise ratio. Baud rate
normalized signal to noise ratio based on
error vector magnitude in dB with two decimal
precision. Values include the instantaneous, average,
minimum, and maximum statistics. If avg/min/max
statistics are not supported, the target is expected
to just supply the instant value
nodetype: container (ro)
description:
The instantaneous value of the statistic.
nodetype: leaf (ro)
type: decimal64
units: dB
description:
The arithmetic mean value of the statistic over the
time interval.
nodetype: leaf (ro)
type: decimal64
units: dB
description:
The minimum value of the statistic over the time interval.
nodetype: leaf (ro)
type: decimal64
units: dB
description:
The maximum value of the statistic over the time
interval.
nodetype: leaf (ro)
type: decimal64
units: dB
description:
If supported by the system, this reports the time interval
over which the min/max/average statistics are computed by
the system.
nodetype: leaf (ro)
type: oc-types:stat-interval
description:
The absolute time at which the minimum value occurred.
The value is the timestamp in nanoseconds relative to
the Unix Epoch (Jan 1, 1970 00:00:00 UTC).
nodetype: leaf (ro)
type: oc-types:timeticks64
description:
The absolute time at which the maximum value occurred.
The value is the timestamp in nanoseconds relative to
the Unix Epoch (Jan 1, 1970 00:00:00 UTC).
nodetype: leaf (ro)
type: oc-types:timeticks64
description:
Top level container for data related to Ethernet framing
for the logical channel
nodetype: container (rw)
description:
Configuration data for Ethernet protocol framing on
logical channels
nodetype: container (rw)
description:
Sets the client port behavior that defines if the actions
of automatic laser shutdown (als), ethernet fault
propagation, or nothing will be done upon the detection
of a failure on the line port or the upstream remote
client port.
nodetype: leaf (rw)
type: enumeration
default: ETHERNET
description:
The timer to delay the client-als actions on the client
port when a local or remote fault is detected on the line
port. The delay will only be valid when the client-als is
set to LASER_SHUTDOWN
nodetype: leaf (rw)
type: uint32
default: 0
units: milliseconds
description:
Operational state data for Ethernet protocol framing
on logical channels
nodetype: container (ro)
description:
Sets the client port behavior that defines if the actions
of automatic laser shutdown (als), ethernet fault
propagation, or nothing will be done upon the detection
of a failure on the line port or the upstream remote
client port.
nodetype: leaf (ro)
type: enumeration
default: ETHERNET
description:
The timer to delay the client-als actions on the client
port when a local or remote fault is detected on the line
port. The delay will only be valid when the client-als is
set to LASER_SHUTDOWN
nodetype: leaf (ro)
type: uint32
default: 0
units: milliseconds
description:
MAC layer control frames received on the interface
nodetype: leaf (ro)
type: oc-yang:counter64
description:
MAC layer PAUSE frames received on the interface
nodetype: leaf (ro)
type: oc-yang:counter64
description:
The total number of frames received that were
longer than 1518 octets (excluding framing bits,
but including FCS octets) and were otherwise
well formed.
nodetype: leaf (ro)
type: oc-yang:counter64
description:
The total number of frames received that were
less than 64 octets long (excluding framing bits,
but including FCS octets) and were otherwise well
formed.
nodetype: leaf (ro)
type: oc-yang:counter64
description:
Number of jabber frames received on the
interface. Jabber frames are typically defined as oversize
frames which also have a bad CRC. Implementations may use
slightly different definitions of what constitutes a jabber
frame. Often indicative of a NIC hardware problem.
nodetype: leaf (ro)
type: oc-yang:counter64
description:
The total number of frames received that were less than
64 octets in length (excluding framing bits but including
FCS octets) and had either a bad Frame Check Sequence
(FCS) with an integral number of octets (FCS Error) or a
bad FCS with a non-integral number of octets (Alignment
Error).
nodetype: leaf (ro)
type: oc-yang:counter64
description:
Number of 802.1q tagged frames received on the interface
nodetype: leaf (ro)
type: oc-yang:counter64
description:
The total number of frames received that
had a length (excluding framing bits, but
including FCS octets) of between 64 and 1518
octets, inclusive, but had either a bad
Frame Check Sequence (FCS) with an integral
number of octets (FCS Error) or a bad FCS with
a non-integral number of octets (Alignment Error)
nodetype: leaf (ro)
type: oc-yang:counter64
description:
The number of received errored blocks. Error detection codes
are capable of detecting whether one or more errors have
occurred in a given sequence of bits – the block. It is
normally not possible to determine the exact number of errored
bits within the block
nodetype: leaf (ro)
type: oc-yang:counter64
description:
The number of received errored frames due to a carrier issue.
The value refers to MIB counter for
dot3StatsCarrierSenseErrors
oid=1.3.6.1.2.1.10.7.2.1.11
nodetype: leaf (ro)
type: oc-yang:counter64
description:
The number of received errored frames due to interrupted
transmission issue. The value refers to MIB counter for
dot3StatsDeferredTransmissions
oid=1.3.6.1.2.1.10.7.2.1.7
nodetype: leaf (ro)
type: oc-yang:counter64
description:
The number of received errored frames due to late collision
issue. The value refers to MIB counter for
dot3StatsLateCollisions
oid=1.3.6.1.2.1.10.7.2.1.8
nodetype: leaf (ro)
type: oc-yang:counter64
description:
The number of received errored frames due to MAC errors
received. The value refers to MIB counter for
dot3StatsInternalMacReceiveErrors
oid=1.3.6.1.2.1.10.7.2.1.16
nodetype: leaf (ro)
type: oc-yang:counter64
description:
The number of received errored frames due to single collision
issue. The value refers to MIB counter for
dot3StatsSingleCollisionFrames
oid=1.3.6.1.2.1.10.7.2.1.4
nodetype: leaf (ro)
type: oc-yang:counter64
description:
The number of received errored frames due to symbol error.
The value refers to MIB counter for
in-symbol-error
oid=1.3.6.1.2.1.10.7.2.1.18
nodetype: leaf (ro)
type: oc-yang:counter64
description:
The total number frames received that are well-formed but
dropped due to exceeding the maximum frame size on the interface
(e.g., MTU or MRU)
nodetype: leaf (ro)
type: oc-yang:counter64
description:
MAC layer control frames sent on the interface
nodetype: leaf (ro)
type: oc-yang:counter64
description:
MAC layer PAUSE frames sent on the interface
nodetype: leaf (ro)
type: oc-yang:counter64
description:
Number of 802.1q tagged frames sent on the interface
nodetype: leaf (ro)
type: oc-yang:counter64
description:
The number of sent errored frames due to MAC errors
transmitted. The value refers to MIB counter for
dot3StatsInternalMacTransmitErrors
oid=1.3.6.1.2.1.10.7.2.1.10
nodetype: leaf (ro)
type: oc-yang:counter64
description:
The number of received bit interleaved parity (BIP) errors
at the physical coding sublayer (PCS). If the interface
consists of multiple lanes, this will be the sum of all
errors on the lane
nodetype: leaf (ro)
type: oc-yang:counter64
description:
The number of seconds that physical coding sublayer (PCS)
errors have crossed a sytem defined threshold indicating the
link is erroring
nodetype: leaf (ro)
type: oc-yang:counter64
description:
The number of seconds that physical coding sublayer (PCS)
errors have crossed a system defined threshold indicating the
link is severely erroring
nodetype: leaf (ro)
type: oc-yang:counter64
description:
The number of seconds that physical coding sublayer (PCS)
errors have crossed a system defined threshold indicating the
link is unavailable
nodetype: leaf (ro)
type: oc-yang:counter64
description:
The number of transmitted bit interleaved parity (BIP) errors
at the physical coding sublayer (PCS). If the interface
consists of multiple lanes, this will be the sum of all
errors on the lane
nodetype: leaf (ro)
type: oc-yang:counter64
description:
Number of FCS/CRC error check failures sent on the interface
nodetype: leaf (ro)
type: oc-yang:counter64
description:
The number of transmitted errored blocks. Error detection
codes are capable of detecting whether one or more errors have
occurred in a given sequence of bits – the block. It is
normally not possible to determine the exact number of errored
bits within the block
nodetype: leaf (ro)
type: oc-yang:counter64
description:
The number of blocks or frames that were uncorrectable by
the FEC
nodetype: leaf (ro)
type: yang:counter64
description:
Bit error rate before forward error correction -- computed
value with 18 decimal precision. Note that decimal64
supports values as small as i x 10^-18 where i is an
integer. Values smaller than this should be reported as 0
to inidicate error free or near error free performance.
Values include the instantaneous, average, minimum, and
maximum statistics. If avg/min/max statistics are not
supported, the target is expected to just supply the
instant value
nodetype: container (ro)
description:
The instantaneous value of the statistic.
nodetype: leaf (ro)
type: decimal64
units: bit-errors-per-second
description:
The arithmetic mean value of the statistic over the
time interval.
nodetype: leaf (ro)
type: decimal64
units: bit-errors-per-second
description:
The minimum value of the statistic over the time
interval.
nodetype: leaf (ro)
type: decimal64
units: bit-errors-per-second
description:
The maximum value of the statistic over the time
interval.
nodetype: leaf (ro)
type: decimal64
units: bit-errors-per-second
description:
If supported by the system, this reports the time interval
over which the min/max/average statistics are computed by
the system.
nodetype: leaf (ro)
type: oc-types:stat-interval
description:
The absolute time at which the minimum value occurred.
The value is the timestamp in nanoseconds relative to
the Unix Epoch (Jan 1, 1970 00:00:00 UTC).
nodetype: leaf (ro)
type: oc-types:timeticks64
description:
The absolute time at which the maximum value occurred.
The value is the timestamp in nanoseconds relative to
the Unix Epoch (Jan 1, 1970 00:00:00 UTC).
nodetype: leaf (ro)
type: oc-types:timeticks64
description:
Bit error rate after forward error correction -- computed
value with 18 decimal precision. Note that decimal64
supports values as small as i x 10^-18 where i is an
integer. Values smaller than this should be reported as 0
to inidicate error free or near error free performance.
Values include the instantaneous, average, minimum, and
maximum statistics. If avg/min/max statistics are not
supported, the target is expected to just supply the
instant value
nodetype: container (ro)
description:
The instantaneous value of the statistic.
nodetype: leaf (ro)
type: decimal64
units: bit-errors-per-second
description:
The arithmetic mean value of the statistic over the
time interval.
nodetype: leaf (ro)
type: decimal64
units: bit-errors-per-second
description:
The minimum value of the statistic over the time
interval.
nodetype: leaf (ro)
type: decimal64
units: bit-errors-per-second
description:
The maximum value of the statistic over the time
interval.
nodetype: leaf (ro)
type: decimal64
units: bit-errors-per-second
description:
If supported by the system, this reports the time interval
over which the min/max/average statistics are computed by
the system.
nodetype: leaf (ro)
type: oc-types:stat-interval
description:
The absolute time at which the minimum value occurred.
The value is the timestamp in nanoseconds relative to
the Unix Epoch (Jan 1, 1970 00:00:00 UTC).
nodetype: leaf (ro)
type: oc-types:timeticks64
description:
The absolute time at which the maximum value occurred.
The value is the timestamp in nanoseconds relative to
the Unix Epoch (Jan 1, 1970 00:00:00 UTC).
nodetype: leaf (ro)
type: oc-types:timeticks64
description:
Quality value (factor) in dB of a channel with two
decimal precision. Values include the instantaneous,
average, minimum, and maximum statistics. If avg/min/max
statistics are not supported, the target is expected
to just supply the instant value
nodetype: container (ro)
description:
The instantaneous value of the statistic.
nodetype: leaf (ro)
type: decimal64
units: dB
description:
The arithmetic mean value of the statistic over the
time interval.
nodetype: leaf (ro)
type: decimal64
units: dB
description:
The minimum value of the statistic over the time interval.
nodetype: leaf (ro)
type: decimal64
units: dB
description:
The maximum value of the statistic over the time
interval.
nodetype: leaf (ro)
type: decimal64
units: dB
description:
If supported by the system, this reports the time interval
over which the min/max/average statistics are computed by
the system.
nodetype: leaf (ro)
type: oc-types:stat-interval
description:
The absolute time at which the minimum value occurred.
The value is the timestamp in nanoseconds relative to
the Unix Epoch (Jan 1, 1970 00:00:00 UTC).
nodetype: leaf (ro)
type: oc-types:timeticks64
description:
The absolute time at which the maximum value occurred.
The value is the timestamp in nanoseconds relative to
the Unix Epoch (Jan 1, 1970 00:00:00 UTC).
nodetype: leaf (ro)
type: oc-types:timeticks64
description:
Electrical signal to noise ratio. Baud rate
normalized signal to noise ratio based on
error vector magnitude in dB with two decimal
precision. Values include the instantaneous, average,
minimum, and maximum statistics. If avg/min/max
statistics are not supported, the target is expected
to just supply the instant value
nodetype: container (ro)
description:
The instantaneous value of the statistic.
nodetype: leaf (ro)
type: decimal64
units: dB
description:
The arithmetic mean value of the statistic over the
time interval.
nodetype: leaf (ro)
type: decimal64
units: dB
description:
The minimum value of the statistic over the time interval.
nodetype: leaf (ro)
type: decimal64
units: dB
description:
The maximum value of the statistic over the time
interval.
nodetype: leaf (ro)
type: decimal64
units: dB
description:
If supported by the system, this reports the time interval
over which the min/max/average statistics are computed by
the system.
nodetype: leaf (ro)
type: oc-types:stat-interval
description:
The absolute time at which the minimum value occurred.
The value is the timestamp in nanoseconds relative to
the Unix Epoch (Jan 1, 1970 00:00:00 UTC).
nodetype: leaf (ro)
type: oc-types:timeticks64
description:
The absolute time at which the maximum value occurred.
The value is the timestamp in nanoseconds relative to
the Unix Epoch (Jan 1, 1970 00:00:00 UTC).
nodetype: leaf (ro)
type: oc-types:timeticks64
description:
LLDP data for logical channels
nodetype: container (rw)
description:
LLDP configuration data for logical channels
nodetype: container (rw)
description:
Enable or disable the LLDP protocol on the logical channel.
nodetype: leaf (rw)
type: boolean
default: false
description:
If true, LLDP PDUs are only received and processed on
the logical-channel, but are not originated by the local
agent. The PDUs are not dropped by the logical channel after
processing, but relayed to the downstream link layer
neighbors. The snooping mode is valid only when LLDP is
enabled on the logical channel. The snooping mode is useful
when a logical channel does not want its link layer neighbors
to discover itself since, for example, it is a lower-layer
logical channel.
nodetype: leaf (rw)
type: boolean
default: false
description:
LLDP operational state data for logical channels
nodetype: container (ro)
description:
Enable or disable the LLDP protocol on the logical channel.
nodetype: leaf (ro)
type: boolean
default: false
description:
If true, LLDP PDUs are only received and processed on
the logical-channel, but are not originated by the local
agent. The PDUs are not dropped by the logical channel after
processing, but relayed to the downstream link layer
neighbors. The snooping mode is valid only when LLDP is
enabled on the logical channel. The snooping mode is useful
when a logical channel does not want its link layer neighbors
to discover itself since, for example, it is a lower-layer
logical channel.
nodetype: leaf (ro)
type: boolean
default: false
description:
LLDP counters on each interface
nodetype: container (ro)
description:
The number of lldp frames received.
nodetype: leaf (ro)
type: yang:counter64
description:
The number of frames transmitted out.
nodetype: leaf (ro)
type: yang:counter64
description:
The number of LLDP frames received with errors.
nodetype: leaf (ro)
type: yang:counter64
description:
The number of LLDP frames received and discarded.
nodetype: leaf (ro)
type: yang:counter64
description:
The number of TLV frames received and discarded.
nodetype: leaf (ro)
type: yang:counter64
description:
The number of frames received with unknown TLV.
nodetype: leaf (ro)
type: yang:counter64
description:
Indicates the last time the counters were
cleared.
nodetype: leaf (ro)
type: yang:date-and-time
description:
The number of frame transmit errors on the
interface.
nodetype: leaf (ro)
type: yang:counter64
description:
Enclosing container for list of LLDP neighbors on
a logical channel
nodetype: container (ro)
description:
List of LLDP neighbors. If the implementation only
supports one neighbor, this would always be a list with
one item. If the device and neighbor supported multiple
neighbors, which can be achieved via LLDP forwarding, then
this would be supported
nodetype: list (ro)
list keys: [id]
description:
System generated identifier for the neighbor on
the logical channel.
nodetype: leaf (list key) (ro)
type: leafref
description:
Configuration data
nodetype: container (ro)
description:
Operational state data
nodetype: container (ro)
description:
The system name field shall contain an alpha-numeric string
that indicates the system's administratively assigned name.
The system name should be the system's fully qualified domain
name. If implementations support IETF RFC 3418, the sysName
object should be used for this field.
nodetype: leaf (ro)
type: string
description:
The system description field shall contain an alpha-numeric
string that is the textual description of the network entity.
The system description should include the full name and
version identification of the system's hardware type,
software operating system, and networking software. If
implementations support IETF RFC 3418, the sysDescr object
should be used for this field.
nodetype: leaf (ro)
type: string
description:
The Chassis ID is a mandatory TLV which identifies the
chassis component of the endpoint identifier associated with
the transmitting LLDP agent
nodetype: leaf (ro)
type: string
description:
This field identifies the format and source of the chassis
identifier string. It is an enumerator defined by the
LldpChassisIdSubtype object from IEEE 802.1AB MIB.
nodetype: leaf (ro)
type: oc-lldp-types:chassis-id-type
description:
System generated identifier for the neighbor on the
interface.
nodetype: leaf (ro)
type: string
description:
Age since discovery
nodetype: leaf (ro)
type: uint64
units: seconds
description:
Seconds since last update received.
nodetype: leaf (ro)
type: int64
description:
The time-to-live (TTL) is a mandatory TLV which indicates
how long information from the neighbor should be considered
valid.
nodetype: leaf (ro)
type: uint16
units: seconds
description:
The Port ID is a mandatory TLV which identifies the port
component of the endpoint identifier associated with the
transmitting LLDP agent. If the specified port is an IEEE
802.3 Repeater port, then this TLV is optional.
nodetype: leaf (ro)
type: string
description:
This field identifies the format and source of the port
identifier string. It is an enumerator defined by the
PtopoPortIdType object from RFC2922.
nodetype: leaf (ro)
type: oc-lldp-types:port-id-type
description:
The binary string containing the actual port identifier for
the port which this LLDP PDU was transmitted. The source and
format of this field is defined by PtopoPortId from
RFC2922.
nodetype: leaf (ro)
type: string
description:
The Management Address is a mandatory TLV which identifies a
network address associated with the local LLDP agent, which
can be used to reach the agent on the port identified in the
Port ID TLV.
nodetype: leaf (ro)
type: string
description:
The enumerated value for the network address type
identified in this TLV. This enumeration is defined in the
'Assigned Numbers' RFC [RFC3232] and the
ianaAddressFamilyNumbers object.
nodetype: leaf (ro)
type: string
description:
Enclosing container for list of custom TLVs from a
neighbor
nodetype: container (ro)
description:
List of custom LLDP TLVs from a neighbor
nodetype: list (ro)
list keys: [type] [oui] [oui-subtype]
description:
Reference to type list key
nodetype: leaf (list key) (ro)
type: leafref
description:
Reference to oui list key
nodetype: leaf (list key) (ro)
type: leafref
description:
Reference to oui-subtype list key
nodetype: leaf (list key) (ro)
type: leafref
description:
Configuration data
nodetype: container (ro)
description:
Operational state data
nodetype: container (ro)
description:
The integer value identifying the type of information
contained in the value field.
nodetype: leaf (ro)
type: int32
description:
The organizationally unique identifier field shall contain
the organization's OUI as defined in Clause 9 of IEEE Std
802. The high-order octet is 0 and the low-order 3 octets
are the SMI Network Management Private Enterprise Code of
the Vendor in network byte order, as defined in the
'Assigned Numbers' RFC [RFC3232].
nodetype: leaf (ro)
type: string
description:
The organizationally defined subtype field shall contain a
unique subtype value assigned by the defining organization.
nodetype: leaf (ro)
type: string
description:
A variable-length octet-string containing the
instance-specific information for this TLV.
nodetype: leaf (ro)
type: binary
description:
Top-level container for specifying references to the
source of signal for the logical channel, either a
transceiver, individual physical channels, or an interface
nodetype: container (rw)
description:
Configuration data for the signal source for the
logical channel
nodetype: container (rw)
description:
Reference to the transceiver carrying the input signal
for the logical channel. If specific physical channels
are mapped to the logical channel (as opposed to all
physical channels carried by the transceiver), they can be
specified in the list of physical channel references.
nodetype: leaf (rw)
type: leafref
description:
This list should be populated with references
to the client physical channels that feed this logical
channel from the transceiver specified in the 'transceiver'
leaf, which must be specified. If this leaf-list is empty,
all physical channels in the transceiver are assumed to be
mapped to the logical channel.
nodetype: leaf-list (rw)
type: leafref
description:
Reference to the interface carrying the input signal
for the logical channel. The ingress will specify an interface
in the case of a transceiver being utilized directly in a
router and bypassing a dedicated terminal device. When
specified, the other leaves in the ingress config must be
empty.
nodetype: leaf (rw)
type: oc-if:base-interface-ref
description:
Operational state data for the signal source for the
logical channel
nodetype: container (ro)
description:
Reference to the transceiver carrying the input signal
for the logical channel. If specific physical channels
are mapped to the logical channel (as opposed to all
physical channels carried by the transceiver), they can be
specified in the list of physical channel references.
nodetype: leaf (ro)
type: leafref
description:
This list should be populated with references
to the client physical channels that feed this logical
channel from the transceiver specified in the 'transceiver'
leaf, which must be specified. If this leaf-list is empty,
all physical channels in the transceiver are assumed to be
mapped to the logical channel.
nodetype: leaf-list (ro)
type: leafref
description:
Reference to the interface carrying the input signal
for the logical channel. The ingress will specify an interface
in the case of a transceiver being utilized directly in a
router and bypassing a dedicated terminal device. When
specified, the other leaves in the ingress config must be
empty.
nodetype: leaf (ro)
type: oc-if:base-interface-ref
description:
Enclosing container for tributary assignments
nodetype: container (rw)
description:
Logical channel elements may be assigned directly to
optical channels for line-side transmission, or can be
further groomed into additional stages of logical channel
elements. The grooming can multiplex (i.e., split the
current element into multiple elements in the subsequent
stage) or de-multiplex (i.e., combine the current element
with other elements into the same element in the subsequent
stage) logical elements in each stage.
Note that to support the ability to groom the logical
elements, the list of logical channel elements should be
populated with an entry for the logical elements at
each stage, starting with the initial assignment from the
respective client physical port.
Each logical element assignment consists of a pointer to
an element in the next stage, or to an optical channel,
along with a bandwidth allocation for the corresponding
assignment (e.g., to split or combine signal).
nodetype: list (rw)
list keys: [index]
description:
Reference to the index for the current tributary
assignment
nodetype: leaf (list key) (rw)
type: leafref
description:
Configuration data for tributary assignments
nodetype: container (rw)
description:
Index of the current logical client channel to tributary
mapping
nodetype: leaf (rw)
type: uint32
description:
Name assigned to the logical client channel
nodetype: leaf (rw)
type: string
description:
Each logical channel element may be assigned to subsequent
stages of logical elements to implement further grooming, or
can be assigned to a line-side optical channel for
transmission. Each assignment also has an associated
bandwidth allocation.
nodetype: leaf (rw)
type: enumeration
description:
Reference to another stage of logical channel elements.
nodetype: leaf (rw)
type: leafref
description:
Reference to the line-side optical channel that should
carry the current logical channel element. Use this
reference to exit the logical element stage.
nodetype: leaf (rw)
type: leafref
description:
Allocation of the logical client channel to the tributary
or sub-channel, expressed in Gbps. Please note that if the
assignment is to an OTN logical channel, the allocation must
be an integer multiplication to tributary-slot-granularity
of the OTN logical channel.
nodetype: leaf (rw)
type: decimal64
units: Gbps
description:
Indicates the first tributary slot index allocated to the
client signal or logical channel in the assignment. Valid
only when the assignment is to an OTN logical channel.
nodetype: leaf (rw)
type: int32
description:
Logical channel mapping procedure. Valid only when the
assignment is to an OTN logical channel.
nodetype: leaf (rw)
type: identityref
description:
Operational state data for tributary assignments
nodetype: container (ro)
description:
Index of the current logical client channel to tributary
mapping
nodetype: leaf (ro)
type: uint32
description:
Name assigned to the logical client channel
nodetype: leaf (ro)
type: string
description:
Each logical channel element may be assigned to subsequent
stages of logical elements to implement further grooming, or
can be assigned to a line-side optical channel for
transmission. Each assignment also has an associated
bandwidth allocation.
nodetype: leaf (ro)
type: enumeration
description:
Reference to another stage of logical channel elements.
nodetype: leaf (ro)
type: leafref
description:
Reference to the line-side optical channel that should
carry the current logical channel element. Use this
reference to exit the logical element stage.
nodetype: leaf (ro)
type: leafref
description:
Allocation of the logical client channel to the tributary
or sub-channel, expressed in Gbps. Please note that if the
assignment is to an OTN logical channel, the allocation must
be an integer multiplication to tributary-slot-granularity
of the OTN logical channel.
nodetype: leaf (ro)
type: decimal64
units: Gbps
description:
Indicates the first tributary slot index allocated to the
client signal or logical channel in the assignment. Valid
only when the assignment is to an OTN logical channel.
nodetype: leaf (ro)
type: int32
description:
Logical channel mapping procedure. Valid only when the
assignment is to an OTN logical channel.
nodetype: leaf (ro)
type: identityref
description:
Enclosing container for list of operational modes
nodetype: container (rw)
description:
List of operational modes supported by the platform.
The operational mode provides a platform-defined summary
of information such as symbol rate, modulation, pulse
shaping, etc.
nodetype: list (ro)
list keys: [mode-id]
description:
Reference to mode-id
nodetype: leaf (list key) (ro)
type: leafref
description:
Configuration data for operational mode
nodetype: container (ro)
description:
Operational state data for the platform-defined
operational mode
nodetype: container (ro)
description:
Two-octet encoding of the vendor-defined operational
mode
nodetype: leaf (ro)
type: uint16
description:
Vendor-supplied textual description of the characteristics
of this operational mode to enable operators to select the
appropriate mode for the application.
nodetype: leaf (ro)
type: string
description:
Identifier to represent the vendor / supplier of the
platform and the associated operational mode information
nodetype: leaf (ro)
type: string
This module defines configuration and operational state data for transceivers (i.e., pluggable optics). The module should be used in conjunction with the platform model where other physical entity data are represented.
In the platform model, a component of type=TRANSCEIVER is expected to be a subcomponent of a PORT component. This module defines a concrete schema for the associated data for components with type=TRANSCEIVER.
A transceiver will always contain physical-channel(s), however when a line side optical-channel is present (i.e. ZR+ optics) the physical-channel will reference its optical-channel. In this case, the optical-channels components must be subcomponents of the transceiver. The relationship between the physical-channel and the optical-channel allows for multiple optical-channels to be associated with a transceiver in addition to ensuring certain leaves (i.e. output-power) are not duplicated in multiple components.
If a transceiver contains a digital signal processor (DSP), such as with ZR+ optics, the modeling will utilize hierarchical components as follows: PORT --> TRANSCEIVER --> OPTICAL_CHANNEL(s) The signal will then traverse through a series of terminal-device/logical-channels as required. The first logical-channel connected to the OPTICAL_CHANNEL will utilize the assignment/optical-channel leaf to create the relationship. At the conclusion of the series of logical-channels, the logical-channel will be associated to its host / client side based on: * If the TRANSCEIVER is directly within a router or switch, then it will use the logical-channel ingress leaf to specify the interface it is associated with. * If the TRANSCEIVER is within a dedicated terminal (Layer 1) device, then it will use the logical-channel ingress leaf to specify a physical-channel within a TRANSCEIVER component (i.e. gray optic) that it is associated with.
ietf-yang-types
openconfig-platform
openconfig-platform-types
openconfig-platform-port
openconfig-interfaces
openconfig-transport-types
openconfig-types
openconfig-extensions
openconfig-yang-types
openconfig-alarm-types