Home > Operations, Administration, and Maintenance (OAM) Engine > OAM Engine Configuration
OAM Engine Configuration
The OAM engine configuration requires common infrastructure settings that affect all OAM flows. For each OAM flow, the application must configure the OAM Table attributes that define the flow behavior. This is achieved by setting the fields of the OAM Engine table. This table has 2K rules and it must be partitioned between Ingress and Egress OAM engines. The OAM engine table record is described in the CPSS_DXCH_OAM_ENTRY_STC structure. The flow configuration is described in details in OAM Engine Single Flow Configuration.
The OAM engine detects various exceptions. The device also maintains special counters and indications of the exceptions. Exception handling configuration is described in OAM Exception – Configuration, Indications, Counters, and Recovery. Exception recovery is described in Exception Recovery.
Using stage Parameter in OAM APIs
Most of the CPSS APIs described in this section have a parameter called stage that defines if the API is applicable to either Ingress or Egress OAM processing.
The Ingress and Egress processing is defined by the CPSS_DXCH_OAM_STAGE_TYPE_ENT type.
To set the OAM processing to Ingress stage, use constant CPSS_DXCH_OAM_STAGE_TYPE_INGRESS_E.
To set the OAM processing to Egress stage, use constant CPSS_DXCH_OAM_STAGE_TYPE_EGRESS_E.
If the stage parameter is omitted, the API is applicable to both Ingress and Egress stages.
OAM Engine Initialization
To enable the Ingress or Egress OAM processing, call cpssDxChOamEnableSet.
The OAM Engine table has 2K flow entries. The application may need to allocate continuous areas for OAM Ingress and Egress flows in the OAM table. To set the basic flow offset for each stage, call cpssDxChOamTableBaseFlowIdSet. All other OAM APIs rely on this setting for accessing the OAM table.
Keepalive Functionality Configuration
The OAM engine uses the keepalive daemon for monitoring the connectivity with a peer device. Each flow in the OAM table defines keepalive attributes. The built-in aging daemon applies them. To detect LOC, the daemon uses up to 8 configurable timers. Each timer is used to measure the time between successful keepalive message arrivals. The LOC timeout for a single flow is defined as the number of times the timer elapsed. A keepalive exception is raised if there was no packet for the configured time. Each timer can be set to a different period. Each flow can use any of the 8 timers.
To enable keepalive detection on the device, call cpssDxChOamAgingDaemonEnableSet.
Set the enable parameter to GT_TRUE to enable the aging daemon. If the daemon is enabled, the periodic keepalive check will be performed on entries according to the aging settings in the OAM Engine table. Otherwise, the Ingress or Egress keepalive check will be globally disabled.
The device supports 8 different aging timers per stage to provide a greater granularity.
To configure each one of the 8 aging timers, call cpssDxChOamAgingPeriodEntrySet. The timers are configured in units of 40 ns. The applicable range of time units is 0 to 0x3FFFFFFFF. Therefore, the maximal time that can be set equals to ~10 minutes. The timers are referenced in the OAM Table entry field agingPeriodIndex described in LOC Detection Configuration.
An application may configure a keep-alive engine to process dropped keep-alive packets. There is a separate configuration for soft-dropped and hard-dropped packets. To enable processing of dropped packets, call cpssDxChOamKeepaliveForPacketCommandEnableSet.
Reporting LOC Event
Set OAM engine to report LOC events by calling cpssDxChOamAgingBitmapUpdateModeSet with mode set to CPSS_DXCH_OAM_AGING_BITMAP_UPDATE_MODE_ONLY_FAILURES_E. This ensures aging bitmap is updated only upon flow failure.
Setting mode to CPSS_DXCH_OAM_AGING_BITMAP_UPDATE_MODE_ALL_E, allows updating aging bitmap to OK as well as to failure.
Enabling Protection LOC
The OAM Engine can trigger protection switching upon a LOC event. To enable a protection switching update, set the of CPSS_DXCH_OAM_ENTRY_STC, when calling cpssDxChOamEntrySet or cpssDxChOamPortGroupEntrySet. The protection switching configuration is described in Protection Switching. Note that the protection LOC update must be configured in the OAM Engine table at the same row as the row of the LOC table that implements the protection switch.
Monitoring Payload
In some cases, it is desired to validate the packet payload beyond verifying that the message had arrived with the correct header. The OAM engine provides the ability to monitor the packet payload for correctness. This is implemented by comparing the hashed value calculated for the monitored packet fields with the configured one.
The OAM engine can optionally report the changes in the monitored packet data fields. To configure a continuous area of up to 12 bits that will be monitored by the hash mechanism, call cpssDxChOamHashBitSelectionSet. This setting will be used by the OAM engine as described in Packet Header Correctness Detection.
OAM Table Related Configuration
For a TCAM action to assign a flow ID to an OAM packet, the respective entry in the OAM table requires configuring using the cpssDxChOamEntrySet API. In addition, additional configurations are required for proper processing of OAM packets, as described below.
Packet Command Profile Configuration
The OAM engine uses the Packet Opcode table to apply commands and set CPU codes for packets trapped to the CPU. To access entries in the Opcode to Packet Command table is a lookup table, use the following two indexes:
The 8-bit opcode from the CFM packet header
The profile ID – The packetCommandProfile field of CPSS_DXCH_OAM_ENTRY_STC, set by the cpssDxChOamEntrySet API
Call cpssDxChOamEntrySet to set the opcodeParsingEnable field of CPSS_DXCH_OAM_ENTRY_STC set to GT_TRUE, in order to enable access to the Opcode to Packet Command table.
The contents of the table is a packet command of the CPSS_PACKET_CMD_ENT type, including CPSS_PACKET_CMD_LOOPBACK_E as a possible command. It is recommended to configure the table prior to enabling the OAM functionality.
To configure the profile table, call cpssDxChOamOpcodeProfilePacketCommandEntrySet. If the packet command is drop or forward to CPU, cpssDxChOamOpcodeProfilePacketCommandEntrySet is also used to configure the CPU/DROP code to be sent to the CPU.
Multicast packets can be automatically assigned (profile ID +1) for accessing the Packet Opcode table. In this way, an application can enable different handling for Multicast and Unicast flows. In order to enable a dedicated profile for Multicast traffic, use cpssDxChOamOpcodeProfileDedicatedMcProfileEnableSet.
Dual-Ended Loss Measurement Command
To define a packet command for Dual-Ended Loss Measurement packets, call cpssDxChOamDualEndedLmPacketCommandSet. The structure CPSS_PACKET_CMD_END describes the command types.
CPU Code Configuration for Trapped Packets
All trapped packets contain the CPU code that can be used by the application for further processing. The opcode is constructed dynamically for each packet from 3 configured values as follows:
CPU_result_code=<OAM_CPU_Code_Base>+ (OAM_Table_Flow_Cpu_Code_Offset> << 2) + (Opcode_Packet_Command_Table_CPU_Code_Offset)
where:
OAM_CPU_Code_Base is the value configured by cpssDxChOamCpuCodeBaseSet.
OAM Table_Cpu OAM_Table_Flow_Cpu_Code_Offset is the value configured for a specific flow in the OAM Engine table. For more details, see OAM Engine Single Flow Configuration.
Opcode_Packet_Command_Table_CPU_Code_Offset is the value from the Opcode to Packet command table to be set by calling cpssDxChOamOpcodeProfilePacketCommandEntrySet.
The available CPU code offset constants are defined by the CPSS_NET_RX_CPU_CODE_ENT enumeration type.
Timestamp Configuration
CPSS provides APIs that enable time stamping in OAM frames and configure the offset where the time stamp must be inserted. To enable time stamping parsing for the incoming frames, call cpssDxChOamTimeStampParsingEnableSet. To configure Ethertype to be inserted into outgoing DM frames, call cpssDxChOamTimeStampEtherTypeSet.
Timestamping can be done anywhere within OAM packets using the PTP Timestamp table. To insert a timestamp:
Call cpssDxChOamEntrySet to set the timestampEnable and oamPtpOffsetIndex fields of CPSS_DXCH_OAM_ENTRY_STC. If the packet is not DM, turn off (set to GT_FALSE) opcodeParsingEnable.
Call cpssDxChPtpTsCfgTableSet to configure the entry of index oamPtpOffsetIndex from Step 1.
Set the entry of type CPSS_DXCH_PTP_TS_CFG_ENTRY_STC to be used as a parameter of cpssDxChPtpTsCfgTableSet to:
tsMode = CPSS_DXCH_PTP_TS_TIMESTAMPING_MODE_DO_ACTION_E
Set tsAction of type CPSS_DXCH_PTP_TS_ACTION_ENT to the required timestamp type, for example CPSS_DXCH_PTP_TS_ACTION_ADD_INGRESS_TIME_E
packetFormat = CPSS_DXCH_PTP_TS_PACKET_TYPE_Y1731_E
ptpTransport = CPSS_DXCH_PTP_TRANSPORT_TYPE_ETHERNET_E
Set L3 offset of timestamp insertion
Packet to Opcode Table Usage
Some OAM packets are processed as known types of OAM messages (LM, DM, CCM Keep Alive). OAM types with dedicated processing are listed in CPSS_DXCH_OAM_OPCODE_TYPE_ENT.
Packet are classified by opcode-matching with predefined OAM opcode types listed in the Opcode table. Upon finding an opcode match, an internal OAM process (not an OAM Action) is triggered. Call cpssDxChOamOpcodeSet to set the table per stage and per OAM opcode type (keepalive message, LM, DM).it triggers
The following figure illustrates the common format for all OAM PDUs.
Figure 299: Common OAM PDU Format
Set opcodeType to CPSS_DXCH_OAM_OPCODE_TYPE_LM_SINGLE_ENDED_E to configure opcode for the single-ended LM opcode. Set opcodeType to CPSS_DXCH_OAM_OPCODE_TYPE_LM_DUAL_ENDED_E to define an opcode for dual-ended loss measurement. Set opcodeType to CPSS_DXCH_OAM_OPCODE_TYPE_KEEPALIVE_E to define an opcode for keepalive monitoring.
Note, that if the opcode does not match CPSS_DXCH_OAM_OPCODE_TYPE_DM_E, even though opcode parsing is enabled and timestampEnable is set, no timestamp is added to the packet.
Each flow in the OAM table is configured to either attempt opcode matching or skip it. To enable OAM Engine matching of packet opcode to a configured one, call cpssDxChOamEntrySet, and set the field opcodeParsingEnable in CPSS_DXCH_OAM_ENTRY_STC.
Loss Measurements Configuration – Destination Offset
There is a special LM Offset table that contains a packet destination offset. The OAM engine accesses the LM Offset table to determine the offset in the packet and insert the LM counters data.
This table is accessed according to the index configured in the OAM Engine table, as described in Loss Measurements (LM) Configuration.
To configure the LM Offset table, call cpssDxChOamLmOffsetTableSet. The parameter entryIndex defines the table row. The parameter offset contains the offset value.
IETF MPLS-TP OAM Support
The OAM engine determines the packet command according to 8-bit opcode values retrieved from OAM packets. However, in the MPLS TP, the OAM is represented by a 16-bit MPLS Control Word value.
The device provides a flexible way of mapping MPLS -TP Control Word to 8-bit opcode values used by the OAM engine. This is done by using 16 profiles.
To map an MPLS Channel Type to a profile, call cpssDxChOamMplsCwChannelTypeProfileSet. To configure mapping profiles, call cpssDxChPclOamChannelTypeProfileToOpcodeMappingSet.
OAM Exception – Configuration, Indications, Counters, and Recovery
Exception Overview
There are 7 OAM exceptions that may occur during OAM processing.
Keepalive Aging Exception – Occurs when OAM flows age out and Loss of Continuity occurs.
Excess Keepalive Exception – Occurs when an excess number of keepalive messages is received in one of the flows.
RDI Status Exception – Occurs when an OAM message is received with an RDI value that is different than the current RDI status of the corresponding OAM Table entry.
Tx Period Exception – Occurs when the transmission period of an OAM message differs from the configured transmission period in the corresponding OAM Table entry.
Invalid Keepalive Exception – Occurs when the hash verification of a received OAM packet fails.
MEG Level Exception – Occurs when the MEG Level of the received OAM message is lower than expected.
Source Interface Exception – Occurs when the source interface of the OAM message is different from the one expected.
The device also maintains a summary exception indication. It is set if any of the above exceptions occurs.
The CPSS_DXCH_OAM_EXCEPTION_TYPE_ENT type must be used to define the exception type in any of the exception related APIs described in this section.
Exception Action Configuration
CPSS provides an API that defines the command to apply on a packet upon exception and the data to forward to the CPU if CPU TRAP was asserted upon exception.
To bind a command and the CPU code to an exception, call cpssDxChOamExceptionConfigSet. The structure CPSS_DXCH_OAM_EXCEPTION_CONFIG_STC defines the command and CPU data for each exception. The commands to apply on the packet upon exception are listed by CPSS_PACKET_CMD_ENT. The codes to pass to the CPU are listed by CPSS_NET_RX_CPU_CODE_ENT.
Exception Counters Access
The device maintains counters for each exception type at the device level (cumulative counter for exceptions that occurred in all 2K flows).
Call cpssDxChOamExceptionCounterGet to obtain the current value of the device level exception counter for the specified exception type. Note, the exception counters are not cleared on read, and wrap around upon reaching the maximal value (232-1).
Counter types are listed by CPSS_DXCH_OAM_EXCEPTION_TYPE_ENT.
Exception Recovery
At times, exception state toggles from Fail to Pass. In such cases, it is possible to assign a pre-configured Recovery Packet Command and CPU/drop code to the packet that triggered the state change. This allows notifying the application of flow recovery by assigning a MIRROR command to the packet.
To achieve that, call cpssDxChOamExceptionRecoveryConfigSet with exceptionCommandPtr (CPSS_DXCH_OAM_EXCEPTION_COMMAND_CONFIG_STC) set to the desired exception recovery configuration per the specified exception type and OAM direction/stage (ingress/egress).
Exception Storm Suppression
This section is applicable for Falcon family of devices
CPSS allows suppressing exception storms for OAM exceptions, though it is possible to still assign command and CPU code (the latter, for packets marked as TO CPU) to the respective packets.
To suppress exception storm for exceptions:
Enable exception suppression for the desired exception type in the relevant OAM table entry (CPSS_DXCH_OAM_ENTRY_STC). The following fields are available:
Keepalive aging – keepaliveAgingStormSuppressEnable
Invalid keepalive hash – invalidHashKeepaliveStormSuppressEnable
MEG level – megLevelStormSuppressEnable
Source interface – sourceInterfaceStormSuppressEnable
Tx period – txPeriodStormSuppressEnable
NOTE: For explanation on each of these exception types, see OAM Exception – Configuration, Indications, Counters, and Recovery.
Call cpssDxChOamExceptionSuppressConfigSet with exceptionCommandPtr (CPSS_DXCH_OAM_EXCEPTION_COMMAND_CONFIG_STC) set to the desired packet OAM handling configuration per the specified exception type and OAM direction/stage (ingress/egress).
Exception Status Indication
The device maintains 2 structures per each exception type—the device exception status vector, and flows exception status table.
Device Exception Status Access
The device exception status vector has 64 bits where each bit represents the cumulative exception status of 32 consecutive flows. For example, if bit 3 is set to 1, there is an exception in one of the flows, from flow 96 up to flow 127. To read the device exception status vector of all 2K flows, call cpssDxChOamExceptionGroupStatusGet. Set the exceptionType parameter to indicate the required exception type.
Single-Flow Exception Status Access
For each of the above exceptions, the device maintains an exception status indications table.
The exception status indication table has 64 rows. Each row has 32 bits—one bit per OAM flow. When an exception occurs for flow i, the OAM engine sets bit i in the corresponding exception table row.
Figure 300: Calculation of Flow ID with Exception
To get the status of 32 flow exceptions, call cpssDxChOamExceptionStatusGet and provide the exception type and row index that contains the required flow exception. The cpssDxChOamExceptionGroupStatusGet API provides the row IDs to be used as inputs to cpssDxChOamExceptionStatusGet.
In Falcon devices, obtain the exception status by calling cpssDxChOamPortGroupEntryGet.
To detect which flow caused the exception, call cpssDxChOamExceptionGroupStatusGet. The indexes to set bits in the returned vector groupStatusArr must be used as input parameters to cpssDxChOamExceptionStatusGet.
An example shown in the previous figure explains how to calculate the flow ID that caused the exception.
OAM Engine Single Flow Configuration
The OAM engine provides building blocks to implement any of the CFM protocols defined by the Ethernet OAM standards 802.1ag/Y.1731, MPLS OAM ITU-T Y.1711 standard, and others.
The CFM supports 3 protocols with 3 message types:
Linktrace Protocol with Linktrace Message (LTM)
Continuity Check Protocol with Continuity Check Message (CCM)
Loopback Protocol with Loopback Message LBM
The standards also introduce the requirements for filtering CFM messages, Delay Measurements (DM) and Loss Measurements (LM) as well as for sending and detecting indications of local alarms. (RDI). The above requirements can be supported by configuring the entry in OAM Engine table.
To configure an OAM Engine table entry, call cpssDxChOamEntrySet or cpssDxChOamPortGroupEntrySet. All the settings are configured through the CPSS_DXCH_OAM_ENTRY_STC structure field. The fields described in this section are assumed to be members of this structure.
The OAM Engine table is configured for each OAM flow and consists of the following:
OAM Packet Parsing
MEG Level Filtering Configuration
Source Interface Filtering Configuration
Keepalive Monitoring Configuration
Delay Measurement (DM) Configuration
Loss Measurements (LM) Configuration
OAM Packet Parsing
Set opcodeParsingEnable to GT_TRUE to use the packet Opcode to determine the packet command. This field is typically enabled for OAM flows of the 802.1ag / Y.1731 / MPLS-TP OAM, and is typically disabled for flows of other OAM protocols, such as BFD or Y.1711. If set, the packet command is determined using the Opcode-to-packet-command table.
For the LM and DM processing, set this field to apply the LM and DM actions only to packets with opcode that matches the configured opcodes. If opcodeParsingEnable is not set, the DM or LM action is applied to any packet that passes the TTI or PCL classification and is referred to OAM processing. For details on the DM processing, see Delay Measurement (DM) Configuration. For details on the LM processing, see Loss Measurements (LM) Configuration.
MEG Level Filtering Configuration
The IEEE 802.1ag l standard specifies that OAM messages of the level below the level configured must be dropped.
In the following example, the device is configured to process OAM packets for portId =5, MEG level =3 and VID =10. Packets with MEG levels 0,1, and 2 must be dropped while packets with levels above 3 must be forwarded.
Set the megLevelCheckEnable parameter to GT_TRUE to enable MEG filtering.
Set megLevel = 3.
CFM packets from any MEG level for port 0 and VID =10 will be classified for the OAM engine. The OAM engine will drop all packets below level 3 while the CFM frames above level 3 will be forwarded. The CFM packets of MEG level 3 will undergo OAM processing according to the Opcode to Packet command mapping table configuration.
The MEG Level exception occurs when the MEG level of the received OAM message is lower than expected.
Multiple MEG Level Filtering
The same IEEE 802.1ag standard specifies that multiple MEG levels may be defined for a single interface. The following example explains how to configure 2 separate Maintenance Points (MP).
There are 2 MP for the same service—one at level (3) and another one at Level (5).
Port=0, VID=7, MEG Level=3
Port=0, VID=7, MEG Level=5
In this case, 2 separate OAM Table entries are created, one for each of these MPs:
The first entry must not perform MEG filtering.
megLevelCheckEnable = GT_FALSE
The second entry – filtering enabled for MEG Level=5.
megLevelCheckEnable = GT_TRUE
megLevel = 5
Two corresponding TCAM rules are created for these flows: (either in the TTI or in the PCL)
First rule – EtherType=CFM, Port=0, VID=7, MEG Level=3.
Second rule (must appear after the first one) – EtherType=CFM, Port=0, VID=7, MEG Level=*
The first rule binds the OAM flow with MEG Level=3 to the corresponding OAM entry. The second rule binds the OAM flow to the second OAM entry, resulting in a MEG Level filtering. The OAM packets with MEG level 3 will be matched by the first TCAM entry and will be processed by the OAM engine’s first rule.
The other OAM packets with MEG levels other than 3 will be matched by the second TCAM rule, and will be processed by the second OAM entry.
Thus, the following MEG Levels are dropped: 0, 1, 2, 4, while all packets in MEG Levels above 5 are forwarded.
Source Interface Filtering Configuration
Source interface filtering is defined in IEEE 802.1ag. The device can be configured to detect source interface violations. The Source Interface exception occurs when the source interface of the OAM message is different than the one configured, as explained further. If classification rules do not use the source interface as the classification parameter, the OAM frames may arrive from different interfaces.
Set sourceInterfaceCheckEnable to enable source interface filtering. Set sourceInterface to define the filtering interface. To enable packet filtering from any port except for the configured one, set sourceInterfaceCheckMode to CPSS_DXCH_OAM_SOURCE_INTERFACE_CHECK_MODE_MATCH_E.
Set sourceInterfaceCheckMode to CPSS_DXCH_OAM_SOURCE_INTERFACE_CHECK_MODE_NO_MATCH_E to raise an exception if an OAM packet arrives from the interface other than the one set in the sourceInterface field.
Multiple Interface Filtering
It is possible to configure filtering of multiple interfaces on the same device. Multiple MEPs can be defined within a single switch, with the same VID and MEG level, but with different interfaces.
The following example shows how to configure processing of OAM packets from 2 different interfaces, while dropping OAM packets from any other interface.
For example, 2 separate Down Maintenance Points (MP) may be defined as follows:
ePort=0, VID=7, MEG Level=3
ePort=1, VID=7, MEG Level=3
In this case, 2 separate OAM Table entries are created, one for each of these MPs.
First entry – the set source interface filtering is disabled.
sourceInterfaceCheckEnable = GT_FALSE;
Second entry – source interface filtering is enabled in the following way:
sourceInterfaceCheckEnable = GT_TRUE;
sourceInterface.portNum = 1;
sourceInterfaceCheckMode = CPSS_DXCH_OAM_SOURCE_INTERFACE_CHECK_MODE_MATCH_E;
Two corresponding TCAM rules are created for these flows (either in TTI or PCL).
First rule – EtherType=CFM, ePort=0, VID=7.
Second rule (must appear after the first one) – EtherType=CFM, ePort=*, VID=7.
The first rule binds the OAM flow with ePort=0 to the corresponding OAM entry. The second rule binds the OAM flow to the second OAM entry, resulting in a source interface filtering. Thus, OAM packets with VID=7 from ePorts 0 or 1 are not dropped, while packets from other ports are dropped.
Keepalive Monitoring Configuration
Keepalive monitoring provides the following configurable functionalities:
LOC Detection Configuration
Packet Header Correctness Detection
Excess Keep Alive Message Detection
LOC Detection Configuration
To define the keepalive timeout for the flow, set the agingPeriodIndex field to point to one of the 8 aging timers described in Keepalive Functionality Configuration. Set the agingThreshold field to configure the number of periods of the selected aging timer. LOC is detected if there is no CCM packet during the time period defined by agingThreshold. The Keepalive Aging exception occurs when an OAM flow ages out and LOC occurs.
To configure the LOC timeout period for 100 ms using the aging timer of 1 ms, set agingThreshold =100. The Keepalive exception occurs if a message does not arrive within 100 ms.
Packet Header Correctness Detection
The device can be configured to detect the correctness of a packet header.
Set the hashVerifyEnable field to enable detection. If enabled, the packet header is verified against the hash value that is set in the flowHash field. This field can be either configured by an API or can be dynamically set, according to the first OAM packet, by the device. To use the configured value, set the lockHashValueEnable field to GT_TRUE. Otherwise, the OAM engine will control this field. The packet header correctness check is based on monitoring a 12-bit hash value out of the 32-bit hash value computed by the hash generator. To select packet fields and a hash method, see Hash Modes and Mechanism.
The configuration of a continuous area of up to 12 bits that will be monitored by the hash mechanism is described in Monitoring Payload.
Excess Keep Alive Message Detection
The OAM engine can be configured to detect excess keep alive messages. The excess keep alive detection algorithm causes the exception if for the configured detection time the expected number of keep alive messages is above the threshold.
Set excessKeepaliveDetectionEnable to detect excess keepalive messages. To configure the detection time, set excessKeepalivePeriodThreshold to the number of aging timer periods and excessKeepaliveMessageThreshold to the minimal number of messages expected during the configured period. The Excess Keepalive exception occurs when an excess number of keepalive messages is received.
Set the following fields to detect excess keepalive frames in 100 ms, using a minimal amount of messages (4), if the aging timer is configured to period of 1 ms.
excessKeepalivePeriodThreshold =100;
excessKeepaliveMessageThreshold =4;
The OAM engine may be set to compare the period of received keepalive packets with the configured one. To enable this check, set the periodCheckEnable field and set the expected period in the keepaliveTxPeriod field.
The Tx Period exception occurs when the transmission period of an OAM message differs from the configured transmission period in the corresponding OAM Table entry.
RDI Check Configuration
The OAM engine can be configured to compare the RDI field in the packet to the configured one in the OAM engine table. To enable this check, set the rdiCheckEnable field. The RDI check is performed only if the keepaliveAgingEnable field is set. The OAM Engine monitors the RDI bit that was extracted into UDB according to the profile. The expected location RDI must be set by calling cpssDxChPclOamRdiMatchingSet. The RDI Status exception occurs when an OAM message is received with an RDI value that is different than the current RDI status of the corresponding OAM Table entry.
Delay Measurement (DM) Configuration
The OAM Engine provides a convenient way to configure time stamping for implementing an accurate delay measurement functionality. The device maintains an internal Time of Day (ToD) counter that is used for time stamping. This ToD counter can be synchronized to a network Grandmaster clock using the Precision Time Protocol (PTP) or to a time server using the Network Time Protocol (NTP). For details on synchronizing the ToD, see Time Synchronization and Timestamping.
The OAM engine uses the offset table defined in Time Synchronization and Timestamping to read the offset of the packet in which the time stamp must be inserted. The OAM Engine entry is configured with the index to the offset table.
To enable time stamping in the OAM packets serviced by a flowId entry of the OAM engine, call cpssDxChOamEntrySet and set following fields:
Set the opcodeParsingEnable field to GT_TRUE
Set the timestampEnable field to GT_TRUE.
Configure the offset of the packet where the time stamp is copied by setting the offsetIndex field to point to the offset table with the configured offset.
The time stamping will be performed only for packets with an opcode matched to one of the 16 opcodes available in the DM Opcodes table. To configure 16 DM opcodes, call cpssDxChOamOpcodeSet. Set the opcodeType parameter to CPSS_DXCH_OAM_OPCODE_TYPE_DM_E and set 16 DM opcodes in opcodeValue.
The opcodeIndex parameter defines the required index in the DM opcodes table.
If opcodeParsingEnable is set to GT_FALSE, the timestamps are set to any packet classified to the OAM flow.
Loss Measurements (LM) Configuration
Loss Measurement (LM) is performed by reading billing and policy counters and inserting them into OAM frames.
All the service counters are assigned using the TTI or PCL classification rules, as defined in a. The TTI, IPCL, or EPCL engine rules must be set to bound the traffic to counters. Only a green conforming counter out of 3 billing counters is used for LM. For more details on configuring counters in the TTI engine, see TTI Rules and Actions. For more details on configuring counters in a PCL lookup, see Policy Action.
An OAM Engine Table rule defines where to insert LM counters into a frame. The OAM engine maintains a table that allows setting LM values into a different offset depending on the packet opcode.
The LM configuration is explained in detail further in this section.
The OAM packets are identified and classified into flows in the TTI (see TTI Rules and Actions).
The relevant rule action must have the following fields set:
oamProcessEnable + flowId – Bind the packet to a specific entry in the OAM table.
bindToPolicer – This field must be enabled in the action entry if LM counting is enabled for this flow.
policerIndex – Specifies the index of the LM counting entry when Bind To Policer Counter is set.
To bind the Policer counter to the OAM, call cpssDxChPclRuleSetas defined in Policy Action.
To define LM counting, call cpssDxChOamEntrySet and set following fields in structure CPSS_DXCH_OAM_ENTRY_ST:
To enable counting of OAM packets in LM, set lmCountingMode = CPSS_DXCH_OAM_LM_COUNTING_MODE_ENABLE_E.
To insert an Egress counter into the packet as defined in the LM table, set the lmCounterCaptureEnable to GT_TRUE.
To define an offset for inserting the LM data, set offsetIndex to point to the LM Offset table (see Loss Measurements Configuration – Destination Offset).
CPU Code Offset Configuration
To configure the value to be added to the CPU code value for packets trapped or mirrored to the CPU, configure the cpuCodeOffset field.
Copyright© 2025 Marvell Confidential
Doc. No. MV-S800962-00
Last Modified:
该博客是Linux 2.4 Packet Filtering HOWTO的简体中文版，介绍了在Linux 2.4内核中如何使用iptables过滤不正确的包，还提及了文档的修订信息、译者及感谢人员。
扫一扫
608
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
