SET EXTENDED CHECK OFF.

SAP SETEXTENDEDCHECK使用说明
最新推荐文章于 2020-03-23 20:31:58 发布
原创 最新推荐文章于 2020-03-23 20:31:58 发布 · 1.7k 阅读 · 0 ·
CC 4.0 BY-SA版权
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
文章标签：

#include #insert #function #sap

1.

SET EXTENDED CHECK OFF.

Effect
You use these statements tot switch the extended syntax check off or on.
If the extended syntax check (Transaction SLIN ) reports errors which you do not consider to be errors, and you want to suppress them in future, you can insert the above statements at the appropriate places in the program. A " SET EXTENDED CHECK OFF. " should be followed as soon as possible by a " SET EXTENDED CHECK ON. ", so that the check is only switched off for a short time.

These statements are not interpreted at runtime. You use them only to mark the source code.

During the extended syntax check, you can ignore these statements by using the additional function Include suppressed fields

 

2.

数据字典绑定T-code

在SM30中输入字典名字（首先要把此表弄成表可维护的，在表维护生成器里面弄），然后

3

SAP:常用的T-code

http://blog.youkuaiyun.com/bookroader/archive/2008/05/22/2469602.aspx

SAP 采购订单税码增强检查
heng0757的专栏
07-03 6442
原文地址：http://fengan321.blog.163.com/blog/static/61762371201212911542414/ 1、SE18查看ME_PROCESS_PO_CUST相关信息   2、SE19创建ME_PROCESS_PO_CUST的BADI实现类   注意类名称定义是按照以下规则： ZCL_IM_ + BADI 其中CL表示CLASS类的意思，
如何将SAP数据传输到其他系统（Transferring Data from SAP to Other Systems）
SAP BLOG--Jack Wu
01-25 6995
在sap里有GUI_DOWNLOAD 函数将sap的数据下载到客户端机器（presentation server），而Dataset则是将数据传输到应用服务器（Application server）。然而在有些时候需要将数据传输到第三方其他系统(3rd Party System)，这是我们就可以使用FTP命令来完成数据传输。1、相关函数HTTP_SCRAMBLEFTP_CONNECTFTP_R
[原]SET EXTENDED CHECK ON/OFF的用法
weixin_34337265的博客
07-01 488
扩展错误检查开启/关闭 我对这个理解的也不是很清楚，高手请指点 code: 　　 REPORTdemo_abap_events_1.　　SETEXTENDEDCHECKOFF.　　WRITE/'Anweisung'.　　FORMroutine.　　WRITE/'Unterprogramm'.　　ENDFORM. 二： 　　 REPORTdemo_aba...
extendedset-1.3.4.zip
10-11
spring-security-csrf-filter.zip,将现有csrf令牌值绑定到响应头的spring安全筛选器。将现有csrf令牌值绑定到响应头的spring安全筛选器。
abap 忽略扩展性检查
zhou5632290的专栏
01-22 1159
SET EXTENDED CHECK OFF. 中间的代码忽略扩展性检查 SET EXTENDED CHECK ON.
ABAP 扩展的语法检查
weixin_34163553的博客
06-20 184
T-CODE：SLIN此功能可以对程序进行检查，  
Drive Curve Lathe Drive Curve Lathe is used to drive a tool along a series of curves in an APT like manner utilizing drive and check curves. It does not use a part surface, since all tool movement is restricted to the XM-YM plane. You begin by defining a tool start-up position relative to two curves. You then "lead" the tool from curve to curve until you finish the machining process. The curves can be lines, arcs, conics, or splines. By default, each curve is extended along its tangency to define intersections for the purpose of finding drive and check curve positions. When the APT mode is enabled, arcs extend to full circles. The APT mode is enabled by setting the parameter CAM_dcl_typ to 1 in the CAM Default file (see CAM Defaults in the Manufacturing User Manual). Figure 1-7 Arc Extensions in Default vs. APT Mode To activate the drive curve lathe submodule, use the GPA &DCLATH. Use global lathe parameters to define the avoidance geometry. The part clearance and engage occur in the machining plane. All tool movements are restricted to the XM-YM plane of the machine coordinate system. Drive Curve Lathe Control Statements Control statements set up machining parameters for motion statements. They select the cutter, control the output of the tool path to the CLSF, and specify other machining parameters that affect the results of the motion statements. Name CUT - Cut Synopsis CUT/ Description CUT specifies that the current tool position and subsequent cutter positions generated in the tool path calculations are to be added to the CLSF. This statement is used in conjunction with the DNTCUT statement. At the beginning of a program, the system assumes that CUT is in effect. Consequently, a program does not require a Cut command until after a DNTCUT statement is programmed. Name DNTCUT - Do Not Cut Synopsis DNTCUT/ Description DNTCUT specifies that the following cutter positions should not be written into the CLSF. The Cut statement will cause the system to resume writing tool positions to the CLSF. Name CUTTER - Cutter Synopsis Description The Cutter statement allows you to specify the tool. You can use the name or entity variable of an existing tool. If the Cutter statement is not programmed, the Drive Curve Lathe machining uses the system defaults. CAUTION: You can only one tool per operation and you must program a new Parameters tool ent An existing tool entity used to generate the current tool path. 'tool name' A string or string variable representing the name of a tool which is used to generate the current tool path. Name FEDRAT - Feedrate Synopsis Description The Feedrate allows you to define a feed rate unit and value. The statement is output in the CLSF exactly as it is written in your GRIP program. NOTE: FEDRAT/... is valid only for Drive Curve Lathe and Sequential Milling submodules. It performs the same function as the &CUTUN and &CUTFED, which are valid for all submodules. &CUTUN, &CUTFED, and FEDRAT can overwrite each other. Therefore, the last FEDRAT or GPA values defined will always apply for Drive Curve Lathe. Parameters IPM A minor word indicating that the feed rate is in inches per minute. IPR A minor word indicating that the feed rate is in inches per revolution. MMPM A minor word indicating that the feed rate is in millimeters per minute. MMPR A minor word indicating that the feed rate is in millimeters per revolution. f A numerical value or variable representing the feed rate. Name INDIRV - In-Direction Vector Synopsis INDIRV/i,j,k Description The In-Direction Vector statement specifies the general direction of the next continuous path motion. INDIRV is used to direct the system when more than one direction is possible, or when you want a direction other than the most obvious one. INDIRV is used together with all continuous path motion statements. If, for example, the cutter is machining along a line that is perpendicular to a circle, the cutter will follow the intrinsic direction of the circle. An INDIRV statement before the next continuous pass motion statement allows you to specify the desired cutting direction. Parameters i,j,k Three numerical values or a three-position numerical array representing the components of a vector pointing in the general direction of the next continuous path motion. Name INTOL - Intol Synopsis INTOL/t Description INTOL specifies the maximum allowable distance the cutter may deviate from an arc, conic, or spline on the concave side of the geometry as the tool path approximates the curve with straight line segments. If the system is generating a circular interpolation record on an arc, the INTOL value is passed to the GPM. If the designated machine tool controller does not support circular interpolation, this value is used by the GPM to approximate the arc. Parameters t A numerical value representing the maximum deviation from the curve being machined. Name OUTTOL - Outtol Synopsis OUTTOL/t Description OUTTOL specifies the maximum allowable distance the cutter may deviate from an arc, conic, or spline on the convex side of the geometry as the tool path approximates the curve with straight line segments. If the system is generating a circular interpolation record on an arc, the OUTOL value is passed to the GPM. If the designated machine tool controller does not support circular interpolation, this value is used by the GPM to approximate the arc. Parameters t A numerical value representing the maximum deviation from the curve being machined. Name OPNAME - Operation Name Synopsis Description The Operation Name statement allows you to specify a string representing the name of the current tool path. OPNAME terminates the current operation and starts a new one. The system saves the operation, including the tool path, in the CLSF and the parameters (e.g., post commands, engage and retract vectors, etc.) used to generate the path. Parameters 'opname' A string or string variable representing the name of the current tool path. DEFLT A minor word indicating that the default operation name will be used. The default operation name is P(n), where n is the next available number. Name REFPNT - Reference Point Synopsis Description The Reference Point is used to position the tool to the drive and check curves. The Reference Point statement applies only to the next GO, GOLFT, GORGT, GOFWD, or GOBACK command. The Reference Point is not output to the CLSF. It establishes a position from which to determine the TO/ON/PAST condition in the GO commnd. In the figure below, the tool goes TO both curves. Refer to the GO statement for more information about TO/ON/PAST. The Reference Point statement is also used before a GOLFT, GORGT, GOFWD, or GOBACK command if multiple intersections exist between the drive and check curves. A Reference Point determines the desired intersection. The REFPNT command is not modal; i.e., a REFPNT command applies only to the next GO, GOLFT, GORGT, GOFWD, or GOBACK command. If a GO command is the first motion command in an operation, a REFPNT command must precede it. Parameters point An existing point representing the location of the Reference Point. x,y,z Three numerical values or a three-position numerical array representing the location, in the WCS, of the Reference Point. Name THICK - Thick Values Synopsis Description The Thick statement allows you to define a distance that the tool offsets away from any of the controlling curves. A positive value represents an offset toward the tool side of the curve. A negative value represents an offset, or "undercut", into the curve. THICK has no effect on curves whose tool position is set to ON. Parameters dcurve A numerical value or variable representing the distance that the tool is offset from the drive curve. ccurve A numeric value or variable representing the distance that the tool is offset from the check curve. OFF A minor word indicating that any current offsets are to be turned off. Name TLLFT - Tool Left Synopsis TLLFT Description The Tool Left statement specifies that the tool will travel along the left side of the drive curve for subsequent tool motions. If, for example, you are standing at the current tool position looking in the same direction as the next tool motion, you would be on the left side of the drive curve. CAUTION: TLLFT does not produce an error message or warning in situations where TLRGT is the correct condition. Name TLON - Tool On Synopsis TLON Description The Tool On statement specifies that the tool center lies on the drive curve for subsequent tool motions Name TLRGT - Tool Right Synopsis TLRGT Description The Tool Right statement specifies that the tool will travel along the right side of the drive curve for subsequent tool motions. If, for example, you are standing at the current tool position looking in the same direction as the next tool motion, you would be on the right side of the drive curve. CAUTION: TLRGT does not produce an error message or warning in situations where TLLFT is the correct condition. 学习这个文档并总结‘’
06-19
我们正在总结DriveCurveLathe的功能、控制语句及其参数。根据用户要求，需要包括CUT、DNTCUT、CUTTER、FEDRAT等语句的作用和使用方法。由于这是一个特定领域（数控车床编程）的知识，我们将根据一般数控车床编程知识...
An exception has occurred which is explained in more detail below. The exception is assigned to class 'CX_SY_READ_SRC_LINE_TOO_LONG' and was not caught in procedure "K_KKB_FIELDCAT_MERGE" "(FUNCTION)", nor was it propagated by a RAISING clause. Since the caller of the procedure could not have anticipated this exception, the current program was terminated. The reason for the exception is: An attempt was made to read program "ZFXS113" from the database. The READ REPORT statement allows you to copy a program text into an internal table. The occupied line length in the program text must not exceed the width of the internal table. Internal table "\FUNCTION=K_KKB_FIELDCAT_MERGE\DATA=L_ABAP_SOURCE[]" is 72 characters wide. The program line is 88 characters wide. 这段报错是什么意思
06-11
SET EXTENDED CHECK OFF. " 解除长度验证 ``` 1. 事务码 `SE38` → 程序属性 → 启用 "Unicode Checks Active" 2. 添加指令 `SET EXTENDED CHECK OFF`（需评估兼容性影响） --- ### 根本规避措施 1. **代码规范**...
/* * Copyright (c) 2016 SEBASTIEN DERONNE * * SPDX-License-Identifier: GPL-2.0-only * * Author: Sebastien Deronne <sebastien.deronne@gmail.com> */ #include "ns3/attribute-container.h" #include "ns3/boolean.h" #include "ns3/command-line.h" #include "ns3/config.h" #include "ns3/double.h" #include "ns3/enum.h" #include "ns3/he-phy.h" #include "ns3/internet-stack-helper.h" #include "ns3/ipv4-address-helper.h" #include "ns3/ipv4-global-routing-helper.h" #include "ns3/log.h" #include "ns3/mobility-helper.h" #include "ns3/multi-model-spectrum-channel.h" #include "ns3/on-off-helper.h" #include "ns3/packet-sink-helper.h" #include "ns3/packet-sink.h" #include "ns3/spectrum-wifi-helper.h" #include "ns3/ssid.h" #include "ns3/string.h" #include "ns3/udp-client-server-helper.h" #include "ns3/udp-server.h" #include "ns3/uinteger.h" #include "ns3/wifi-acknowledgment.h" #include "ns3/yans-wifi-channel.h" #include "ns3/yans-wifi-helper.h" // #include "ns3/wifi-remote-station-manager.h" // 必须包含的头文件 // #include "ns3/minstrel-ht-wifi-manager.h" // 若使用Minstrel-HT算法 // #include <fstream> // 用于文件输出 #include <algorithm> #include <functional> // This is a simple example in order to show how to configure an IEEE 802.11ax Wi-Fi network. // // It outputs the UDP or TCP goodput for every HE MCS value, which depends on the MCS value (0 to // 11), the channel width (20, 40, 80 or 160 MHz) and the guard interval (800ns, 1600ns or 3200ns). // The PHY bitrate is constant over all the simulation run. The user can also specify the distance // between the access point and the station: the larger the distance the smaller the goodput. // // The simulation assumes a configurable number of stations in an infrastructure network: // // STA AP // * * // | | // n1 n2 // // Packets in this simulation belong to BestEffort Access Class (AC_BE). // By selecting an acknowledgment sequence for DL MU PPDUs, it is possible to aggregate a // Round Robin scheduler to the AP, so that DL MU PPDUs are sent by the AP via DL OFDMA. using namespace ns3; NS_LOG_COMPONENT_DEFINE("wifi-one2one-he-rateselect"); int main(int argc, char* argv[]) { bool udp{true}; /* 支持tcp/udp切换 */ bool downlink{true}; /* 上下行控制 */ bool useRts{false}; bool useExtendedBlockAck{false}; Time simulationTime{"14s"}; /* 仿真时间 */ meter_u distance{1.0}; /* AP-STA距离，支持修改 */ double frequency{5}; // whether 2.4, 5 or 6 GHz std::size_t nStations{1}; std::string dlAckSeqType{"NO-OFDMA"}; bool enableUlOfdma{false}; bool enableBsrp{false}; std::string mcsStr; std::vector<uint64_t> mcsValues; int channelWidth{-1}; // in MHz, -1 indicates an unset value int guardInterval{-1}; // in nanoseconds, -1 indicates an unset value uint32_t payloadSize = 700; // must fit in the max TX duration when transmitting at MCS 0 over an RU of 26 tones std::string phyModel{"Yans"}; double minExpectedThroughput{0.0}; double maxExpectedThroughput{0.0}; int numAntennas = 2; /* 天线数 */ auto mcs = 0; uint8_t index = 0; double previous = 0; auto width = 20; /* 信道带宽 */ int gi = 800; const auto mcsMax = 11; /* 最大可支持MCS */ bool constSelect{true}; /* 支持动态静态速率选择算法切换 */ Time accessReqInterval{0}; CommandLine cmd(__FILE__); cmd.AddValue("width", "channel width", width); cmd.AddValue( "constSelect", "rate select, default mode is const rate selcet, if set, use minstr rate select mode", constSelect); cmd.AddValue("mcs", "if unset, default mcs is 3", mcs); cmd.AddValue("frequency", "Whether working in the 2.4, 5 or 6 GHz band (other values gets rejected)", frequency); cmd.AddValue("distance", "Distance in meters between the station and the access point", distance); cmd.AddValue("simulationTime", "Simulation time", simulationTime); cmd.AddValue("udp", "UDP if set to 1, TCP otherwise", udp); cmd.AddValue("downlink", "Generate downlink flows if set to 1, uplink flows otherwise", downlink); cmd.AddValue("useRts", "Enable/disable RTS/CTS", useRts); cmd.AddValue("useExtendedBlockAck", "Enable/disable use of extended BACK", useExtendedBlockAck); cmd.AddValue("nStations", "Number of non-AP HE stations", nStations); cmd.AddValue("dlAckType", "Ack sequence type for DL OFDMA (NO-OFDMA, ACK-SU-FORMAT, MU-BAR, AGGR-MU-BAR)", dlAckSeqType); cmd.AddValue("enableUlOfdma", "Enable UL OFDMA (useful if DL OFDMA is enabled and TCP is used)", enableUlOfdma); cmd.AddValue("enableBsrp", "Enable BSRP (useful if DL and UL OFDMA are enabled and TCP is used)", enableBsrp); cmd.AddValue( "muSchedAccessReqInterval", "Duration of the interval between two requests for channel access made by the MU scheduler", accessReqInterval); cmd.AddValue( "mcs", "list of comma separated MCS values to test; if unset, all MCS values (0-11) are tested", mcsStr); cmd.AddValue("channelWidth", "if set, limit testing to a specific channel width expressed in MHz (20, 40, 80 " "or 160 MHz)", channelWidth); cmd.AddValue("guardInterval", "if set, limit testing to a specific guard interval duration expressed in " "nanoseconds (800, 1600 or 3200 ns)", guardInterval); cmd.AddValue("payloadSize", "The application payload size in bytes", payloadSize); cmd.AddValue("phyModel", "PHY model to use when OFDMA is disabled (Yans or Spectrum). If 80+80 MHz or " "OFDMA is enabled " "then Spectrum is automatically selected", phyModel); cmd.AddValue("minExpectedThroughput", "if set, simulation fails if the lowest throughput is below this value", minExpectedThroughput); cmd.AddValue("maxExpectedThroughput", "if set, simulation fails if the highest throughput is above this value", maxExpectedThroughput); cmd.AddValue("numAntennas", "the antennas number, if unset, default value is 2", numAntennas); cmd.Parse(argc, argv); std::string widthStr = std::to_string(width); auto segmentWidthStr = widthStr; double prevThroughput[12] = {0}; std::cout << "MCS value" << "\t\t" << "Channel width" << "\t\t" << "GI" << "\t\t\t" << "Throughput" << '\n'; uint8_t minMcs = 0; uint8_t maxMcs = 11; if (mcsStr.empty()) { for (uint8_t mcs = minMcs; mcs <= maxMcs; ++mcs) { mcsValues.push_back(mcs); } } else { AttributeContainerValue<UintegerValue, ',', std::vector> attr; auto checker = DynamicCast<AttributeContainerChecker>(MakeAttributeContainerChecker(attr)); checker->SetItemChecker(MakeUintegerChecker<uint8_t>()); attr.DeserializeFromString(mcsStr, checker); mcsValues = attr.Get(); std::sort(mcsValues.begin(), mcsValues.end()); } int minChannelWidth = 20; int maxChannelWidth = frequency == 2.4 ? 40 : 160; if ((channelWidth != -1) && ((channelWidth < minChannelWidth) || (channelWidth > maxChannelWidth))) { NS_FATAL_ERROR("Invalid channel width: " << channelWidth << " MHz"); } if (channelWidth >= minChannelWidth && channelWidth <= maxChannelWidth) { minChannelWidth = channelWidth; maxChannelWidth = channelWidth; } int minGi = enableUlOfdma ? 1600 : 800; int maxGi = 3200; if (guardInterval >= minGi && guardInterval <= maxGi) { minGi = guardInterval; maxGi = guardInterval; } // for (const auto mcs : mcsValues) // {} if (!udp) { Config::SetDefault("ns3::TcpSocket::SegmentSize", UintegerValue(payloadSize)); } NodeContainer wifiStaNodes; wifiStaNodes.Create(nStations); NodeContainer wifiApNode; wifiApNode.Create(1); NetDeviceContainer apDevice; NetDeviceContainer staDevices; WifiMacHelper mac; WifiHelper wifi; std::string channelStr("{0, " + segmentWidthStr + ", "); StringValue ctrlRate; auto nonHtRefRateMbps = HePhy::GetNonHtReferenceRate(mcs) / 1e6; std::ostringstream ossDataMode; ossDataMode << "HeMcs" << mcs; if (frequency == 6) { ctrlRate = StringValue(ossDataMode.str()); channelStr += "BAND_6GHZ, 0}"; Config::SetDefault("ns3::LogDistancePropagationLossModel::ReferenceLoss", DoubleValue(48)); } else if (frequency == 5) { std::ostringstream ossControlMode; ossControlMode << "OfdmRate" << nonHtRefRateMbps << "Mbps"; ctrlRate = StringValue(ossControlMode.str()); channelStr += "BAND_5GHZ, 0}"; } else if (frequency == 2.4) { std::ostringstream ossControlMode; ossControlMode << "ErpOfdmRate" << nonHtRefRateMbps << "Mbps"; ctrlRate = StringValue(ossControlMode.str()); channelStr += "BAND_2_4GHZ, 0}"; Config::SetDefault("ns3::LogDistancePropagationLossModel::ReferenceLoss", DoubleValue(40)); } else { NS_FATAL_ERROR("Wrong frequency value!"); } wifi.SetStandard(WIFI_STANDARD_80211ax); /* 设置固定速率选择算法和动态速率选择算法 */ if (constSelect) { wifi.SetRemoteStationManager("ns3::ConstantRateWifiManager", "DataMode", StringValue(ossDataMode.str()), "ControlMode", ctrlRate); } else { wifi.SetRemoteStationManager("ns3::MinstrelHtWifiManager"); // wifi.SetRemoteStationManager("ns3::IdealWifiManager"); } // // Set guard interval wifi.ConfigHeOptions("GuardInterval", TimeValue(NanoSeconds(gi))); Ssid ssid = Ssid("ns3-80211ax"); auto channel = YansWifiChannelHelper::Default(); YansWifiPhyHelper phy; phy.SetPcapDataLinkType(WifiPhyHelper::DLT_IEEE802_11_RADIO); phy.SetChannel(channel.Create()); phy.Set("Antennas", UintegerValue(numAntennas)); phy.Set("MaxSupportedTxSpatialStreams", UintegerValue(numAntennas)); phy.Set("MaxSupportedRxSpatialStreams", UintegerValue(numAntennas)); mac.SetType("ns3::StaWifiMac", "Ssid", SsidValue(ssid), "MpduBufferSize", UintegerValue(useExtendedBlockAck ? 256 : 64)); phy.Set("ChannelSettings", StringValue(channelStr)); staDevices = wifi.Install(phy, mac, wifiStaNodes); mac.SetType("ns3::ApWifiMac", "EnableBeaconJitter", BooleanValue(false), "Ssid", SsidValue(ssid)); apDevice = wifi.Install(phy, mac, wifiApNode); int64_t streamNumber = 150; streamNumber += WifiHelper::AssignStreams(apDevice, streamNumber); streamNumber += WifiHelper::AssignStreams(staDevices, streamNumber); // mobility. MobilityHelper mobility; Ptr<ListPositionAllocator> positionAlloc = CreateObject<ListPositionAllocator>(); positionAlloc->Add(Vector(0.0, 0.0, 0.0)); positionAlloc->Add(Vector(distance, 0.0, 0.0)); mobility.SetPositionAllocator(positionAlloc); mobility.SetMobilityModel("ns3::ConstantPositionMobilityModel"); mobility.Install(wifiApNode); mobility.Install(wifiStaNodes); /* Internet stack*/ InternetStackHelper stack; stack.Install(wifiApNode); stack.Install(wifiStaNodes); streamNumber += stack.AssignStreams(wifiApNode, streamNumber); streamNumber += stack.AssignStreams(wifiStaNodes, streamNumber); Ipv4AddressHelper address; address.SetBase("192.168.1.0", "255.255.255.0"); Ipv4InterfaceContainer staNodeInterfaces; Ipv4InterfaceContainer apNodeInterface; staNodeInterfaces = address.Assign(staDevices); apNodeInterface = address.Assign(apDevice); /* Setting applications */ ApplicationContainer serverApp; auto serverNodes = downlink ? std::ref(wifiStaNodes) : std::ref(wifiApNode); Ipv4InterfaceContainer serverInterfaces; NodeContainer clientNodes; for (std::size_t i = 0; i < nStations; i++) { serverInterfaces.Add(downlink ? staNodeInterfaces.Get(i) : apNodeInterface.Get(0)); clientNodes.Add(downlink ? wifiApNode.Get(0) : wifiStaNodes.Get(i)); } /* 不同的速率选择算法采用不同maxload */ /* 固定速率选择算法直接采用MCS计算 */ /* 动态速率选择算法采用可支持最大MCS计算 */ mcs = ((1 == constSelect) ? mcs : mcsMax); const auto maxLoad = HePhy::GetDataRate(mcs, MHz_u{static_cast<double>(width)}, NanoSeconds(gi), numAntennas) / nStations; if (udp) { // UDP flow uint16_t port = 9; UdpServerHelper server(port); serverApp = server.Install(serverNodes.get()); streamNumber += server.AssignStreams(serverNodes.get(), streamNumber); serverApp.Start(Seconds(0)); serverApp.Stop(simulationTime + Seconds(1)); const auto packetInterval = payloadSize * 8.0 / maxLoad; for (std::size_t i = 0; i < nStations; i++) { UdpClientHelper client(serverInterfaces.GetAddress(i), port); client.SetAttribute("MaxPackets", UintegerValue(4294967295U)); client.SetAttribute("Interval", TimeValue(Seconds(packetInterval))); client.SetAttribute("PacketSize", UintegerValue(payloadSize)); ApplicationContainer clientApp = client.Install(clientNodes.Get(i)); streamNumber += client.AssignStreams(clientNodes.Get(i), streamNumber); clientApp.Start(Seconds(1)); clientApp.Stop(simulationTime + Seconds(1)); } } else { // TCP flow uint16_t port = 50000; Address localAddress(InetSocketAddress(Ipv4Address::GetAny(), port)); PacketSinkHelper packetSinkHelper("ns3::TcpSocketFactory", localAddress); serverApp = packetSinkHelper.Install(serverNodes.get()); streamNumber += packetSinkHelper.AssignStreams(serverNodes.get(), streamNumber); serverApp.Start(Seconds(0)); serverApp.Stop(simulationTime + Seconds(1)); for (std::size_t i = 0; i < nStations; i++) { OnOffHelper onoff("ns3::TcpSocketFactory", Ipv4Address::GetAny()); onoff.SetAttribute("OnTime", StringValue("ns3::ConstantRandomVariable[Constant=1]")); onoff.SetAttribute("OffTime", StringValue("ns3::ConstantRandomVariable[Constant=0]")); onoff.SetAttribute("PacketSize", UintegerValue(payloadSize)); onoff.SetAttribute("DataRate", DataRateValue(maxLoad)); AddressValue remoteAddress(InetSocketAddress(serverInterfaces.GetAddress(i), port)); onoff.SetAttribute("Remote", remoteAddress); ApplicationContainer clientApp = onoff.Install(clientNodes.Get(i)); streamNumber += onoff.AssignStreams(clientNodes.Get(i), streamNumber); clientApp.Start(Seconds(1)); clientApp.Stop(simulationTime + Seconds(1)); } } Simulator::Schedule(Seconds(0), &Ipv4GlobalRoutingHelper::PopulateRoutingTables); Simulator::Stop(simulationTime + Seconds(1)); Simulator::Run(); // When multiple stations are used, there are chances that association requests // collide and hence the throughput may be lower than expected. Therefore, we relax // the check that the throughput cannot decrease by introducing a scaling factor (or // tolerance) auto tolerance = 0.10; auto rxBytes = 0.0; if (udp) { for (uint32_t i = 0; i < serverApp.GetN(); i++) { rxBytes += payloadSize * DynamicCast<UdpServer>(serverApp.Get(i))->GetReceived(); } } else { for (uint32_t i = 0; i < serverApp.GetN(); i++) { rxBytes += DynamicCast<PacketSink>(serverApp.Get(i))->GetTotalRx(); } } auto throughput = (rxBytes * 8) / simulationTime.GetMicroSeconds(); // Mbit/s Simulator::Destroy(); std::cout << +mcs << "\t\t\t" << widthStr << " MHz\t\t" << (widthStr.size() > 3 ? "" : "\t") << gi << " ns\t\t\t" << throughput << " Mbit/s" << std::endl << '\n'; std::cout << "freq:" << frequency << (udp == 1 ? "; udp" : "; tcp") << "; apStadist:" << distance << "; antenNum:" << numAntennas << "; rateSelect:" << (constSelect == 1 ? "const" : "dyn") << '\n'; // test first element if (mcs == minMcs && width == 20 && gi == 3200) { if (throughput * (1 + tolerance) < minExpectedThroughput) { NS_LOG_ERROR("Obtained throughput " << throughput << " is not expected!"); exit(1); } } // test last element if (mcs == maxMcs && width == maxChannelWidth && gi == 800) { if (maxExpectedThroughput > 0 && throughput > maxExpectedThroughput * (1 + tolerance)) { NS_LOG_ERROR("Obtained throughput " << throughput << " is not expected!"); exit(1); } } // Skip comparisons with previous cases if more than one stations are present // because, e.g., random collisions in the establishment of Block Ack agreements // have an impact on throughput if (nStations == 1) { // test previous throughput is smaller (for the same mcs) if (throughput * (1 + tolerance) > previous) { previous = throughput; } else if (throughput > 0) { NS_LOG_ERROR("Obtained throughput " << throughput << " is not expected!"); exit(1); } // test previous throughput is smaller (for the same channel width and GI) if (throughput * (1 + tolerance) > prevThroughput[index]) { prevThroughput[index] = throughput; } else if (throughput > 0) { NS_LOG_ERROR("Obtained throughput " << throughput << " is not expected!"); exit(1); } } index++; return 0; } 这份代码的udp和tcp的速率接近，虽然这一份代码有很多配置，但都没有启用，请分析上一份代码和这一份代码的区别。
09-03
- 代码A：对于TCP流量，使用`OnOffHelper`，设置`DataRate`为最大理论负载（`maxLoad`），并且开启了持续发送（OnTime=1，OffTime=0）。这种方式会产生突发流量，可能导致TCP拥塞控制机制启动，从而降低吞吐量。 -...
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.能否提取到cpssDxChOamEntrySet适用于哪些机型，AC5调用哪个接口
最新发布
12-06
oamEntry.lmCountingMode = CPSS_DXCH_OAM_LM_COUNTING_MODE_EXTENDED_E; // 硬件加速LM oamEntry.timestampEnable = GT_TRUE; // 启用时间戳 // 调用端口组API GT_PORT_GROUPS_BMP portGroups = CPSS_PORT_GROUP_...
浅谈性能调协–实例分析
Welcome to Garywang's IT BLOG.
04-26 961
原文地址: http://www.abaptech.com/bobo/?p=706 遇到一个程序,在开发环境中运行,速度虽然缓慢,可是还能最终运行出结果,可是在测试系统中,运行非常慢,更有甚者,无法出结果. 客户方提出需要做性能优化. 我大概看了一下程序,实时分析中发现数据库访问非常耗费时间,占总时间的90%以上,于是找到对应的程序段进行优化,并附以记录. 示例一:
SAP增强总结
11-23
SAP增强总结,
SAP FTP相关
08-01 213
以下是SAP 标准FTP程序。在使用标准 functions前,确保已经安装SAPFTP.EXE。请先使用程序：RSFTP005 进行SAPFTP 检查。RSFTP001 - SAPFTP 版本检查RSFTP002 - 执行 F...
SAP ERP101 interface top definition
free_pop2k的专栏
04-16 488
  SPAN {font-family: "Courier New";font-size: 10pt;color: #000000;background: #FFFFFF;}.L1S31 {font-style: italic;color: #808080;}.L1S33 {color: #4DA619;}.L1S52 {color:
【转】采购订单行项目检查增强
少年休闲海
03-23 4216
采购订单行项目检查增强 使用BADI“ME_PROCESS_PO_CUST”的方法CHECK中增强，增加对采购订单行项目的校验，若发现错误，将这些错误消息按照行项目归集显示。 完整示例代码： METHODIF_EX_ME_PROCESS_PO_CUST~CHECK. INCLUDEMM_MESSAGES_MAC. DATA:LT_PO_ITEMTYPEPURCHA...
SAP采购订单税码增强检查
少年休闲海
09-05 2116
1、SE18查看ME_PROCESS_PO_CUST相关信息   2、SE19创建ME_PROCESS_PO_CUST的BADI实现类   注意类名称定义是按照以下规则： ZCL_IM_ + BADI 其中CL表示CLASS类的意思， IM表示Implement实现的意思； 3、SE24实现ZCL_IM_ME_PROCESS_PO_CUST 4、实现PROCESS_ITEM代
SAP ABAP 使用内存参数设置SET /GET PARAMTER ID
matinal 當冬夜漸暖 。公众号：matinal
12-03 8415
更多内容关注公众号：SAP Technical      SET /GET PARAMTER ID使用SPA/GPA 参数--SAP内存参数设置 这是在外部程序之间传送数据的最常用方法。使用EXPORT/IMPORT数据（ABAP/4内存）任何程序都可以使用EXPORT语句在ABAP/4内存中存储数据字段簇。因此，该数据就全局有效（使用IMPORT），在程序本身中以及任何被调事务、报表或...
ABAP代码检查-概览
dbtp16909的博客
08-29 1134
在ABAP开发中，除了基本的语法检查，还存在常用的检查工具 Extended Program Check----扩展程序检查 事务代码SLIN，可按需求设置定制的检查项，可保存变式 也可从代码编辑器启动，路径为：菜单栏-程序-检查-扩展程序检查 Code Inspector ---代码分析器 使用事务代码SCI执行，提供更为强大的检查功能 也可从代码编辑器启动，路径为：菜单栏...
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值