OpenDaylight开发基础概论
软件定义网络SDN基础教程教案
课程名称：软件定义网络（SDN）基础教程总学时、学分：教学目的与要求：●目的：培养高素质、拥有创新能力的网络设计人才和高级网络管理人才。
●要求：本课程的教学目标是使学生理解SDN网络的基本概念和原理，并掌握运用所学知识建设、配置、管理和维护网络的技能，以及培养学生在网络上获取、加工、发布信息的能力。
具体来讲，就是使学生能够“懂、建、管、用”网络：“懂”是理解网络原理、相关协议和标准；“建”是掌握组建网络的工程技术；“管”是学会管理、配置和维护网络；“用”是在学会基本应用的基础上，学会使用将网络作为信息发布和管理的平台。
教材及参考书目：●教材：《软件定义网络（SDN）基础教程》●参考书目：1.张娇，黄韬，刘韵洁等．走近SDN/NFV[M]．北京：人民邮电出版社，2020．2.雷葆华等．SDN核心技术剖析和实战指南[M]．北京：电子工业出版社，2013．3.杨泽卫，李呈等．重构网络：SDN架构与实现[M]．北京：电子工业出版社，2017．4.鞠卫国，张云帆，乔爱锋等．SDN/NFV：重构网络架构建设未来网络[M]．北京：人民邮电出版社，2017．5.黄韬，刘江，魏亮等．软件定义网络核心原理与应用实践[M]．北京：人民邮电出版社，2014．考核方式及成绩计算方法：●考核方式：闭卷●成绩计算方法：期未考试成绩70%,平时成绩20%,实验成绩10%。
课程教学日历课程名称：软件定义网络（SDN）基础教程授课学期：2022~2023第一学期第一章教学安排的说明章节题目：第1章SDN基础知识1.1 SDN概述1.2 SDN的定义和架构1.3 SDN特征——数据控制分离1.4 SDN特征——网络可编程1.5 本章小结1.6 本章练习学时分配：总4学时第1~2学时：1.1 ~ 1.2第3~4学时：1.3 ~ 1.6本章教学目的与要求：软件定义网络（Software Defined Network，SDN）是由美国斯坦福大学Clean Slate项目组提出的一种新型网络架构。
ESP32-S2 ESP-IDF 编程指南 Release v4.3.3说明书
ESP32-S2ESP-IDF编程指南Release v4.3.3乐鑫信息科技2022年06月02日Table of contentsTable of contents i 1快速入门31.1概述 (3)1.2准备工作 (3)1.3开发板简介 (4)1.3.1ESP32-S2-Saola-1 (4)1.3.2ESP32-S2-DevKitM-1(U) (9)1.3.3ESP32-S2-DevKitC-1 (15)1.3.4ESP32-S2-Kaluga-1套件v1.3 (19)1.4详细安装步骤 (54)1.4.1设置开发环境 (54)1.4.2创建您的第一个工程 (54)1.5第一步：安装准备 (54)1.5.1Windows平台工具链的标准设置 (54)1.5.2Linux平台工具链的标准设置 (59)1.5.3macOS平台工具链的标准设置 (60)1.6第二步：获取ESP-IDF (61)1.6.1Linux和macOS操作系统 (61)1.6.2Windows操作系统 (61)1.7第三步：设置工具 (61)1.7.1Windows操作系统 (62)1.7.2Linux和macOS操作系统 (62)1.7.3下载工具备选方案 (62)1.7.4自定义工具安装路径 (63)1.8第四步：设置环境变量 (63)1.8.1Windows操作系统 (63)1.8.2Linux和macOS操作系统 (63)1.9第五步：开始创建工程 (64)1.9.1Linux和macOS操作系统 (64)1.9.2Windows操作系统 (64)1.10第六步：连接设备 (64)1.11第七步：配置 (64)1.11.1Linux和macOS操作系统 (64)1.11.2Windows操作系统 (65)1.12第八步：编译工程 (65)1.13第九步：烧录到设备 (66)1.13.1烧录过程中可能遇到的问题 (66)1.13.2常规操作 (67)1.14第十步：监视器 (67)1.15更新ESP-IDF (68)1.16相关文档 (68)1.16.1与ESP32-S2创建串口连接 (69)1.16.2Eclipse IDE创建和烧录指南 (74)1.16.3VS Code IDE快速入门 (75)1.16.4IDF监视器 (75)i1.16.5工具链的自定义设置 (79)2API参考852.1连网API (85)2.1.1Wi-Fi (85)2.1.2以太网 (166)2.1.3IP网络层协议 (181)2.1.4应用层协议 (197)2.2外设API (197)2.2.1Analog to Digital Converter (197)2.2.2Digital To Analog Converter (221)2.2.3通用定时器 (225)2.2.4GPIO&RTC GPIO (234)2.2.5Dedicated GPIO (252)2.2.6HMAC (257)2.2.7Digital Signature (260)2.2.8I2C驱动程序 (265)2.2.9I2S (277)2.2.10LED PWM控制器 (287)2.2.11Pulse Counter (300)2.2.12RMT (308)2.2.13SD SPI Host Driver (326)2.2.14Sigma-delta Modulation (330)2.2.15SPI Master Driver (333)2.2.16SPI Slave Driver (349)2.2.17SPI Slave Half Duplex (355)2.2.18ESP32-S2Temperature Sensor (361)2.2.19触摸传感器 (363)2.2.20Touch Element (385)2.2.21TWAI (409)2.2.22UART (425)2.2.23USB Driver (447)2.3应用层协议 (454)2.3.1mDNS服务 (454)2.3.2ESP-TLS (462)2.3.3ESP HTTP Client (474)2.3.4ESP WebSocket Client (488)2.3.5HTTP服务器 (495)2.3.6HTTPS server (516)2.3.7ICMP Echo (518)2.3.8ASIO port (523)2.3.9ESP-MQTT (523)2.3.10ESP-Modbus (534)2.3.11ESP Local Control (539)2.3.12ESP Serial Slave Link (548)2.3.13ESP x509Certificate Bundle (560)2.3.14IP网络层协议 (562)2.4配网API (563)2.4.1Unified Provisioning (563)2.4.2Protocol Communication (566)2.4.3Wi-Fi Provisioning (577)2.5存储API (593)2.5.1SPI Flash API (593)2.5.2SD/SDIO/MMC驱动程序 (615)2.5.3非易失性存储库 (623)2.5.4NVS分区生成程序 (642)2.5.5虚拟文件系统组件 (646)2.5.6FAT文件系统 (657)ii2.5.7磨损均衡API (661)2.5.8SPIFFS文件系统 (665)2.5.9量产程序 (668)2.6System API (672)2.6.1App Image Format (672)2.6.2Application Level Tracing (677)2.6.3The Async memcpy API (682)2.6.4控制台终端 (685)2.6.5eFuse Manager (692)2.6.6Error Codes and Helper Functions (711)2.6.7ESP HTTPS OTA (713)2.6.8ESP-pthread (716)2.6.9Event Loop Library (719)2.6.10FreeRTOS (735)2.6.11FreeRTOS Additions (828)2.6.12Heap Memory Allocation (844)2.6.13Heap Memory Debugging (855)2.6.14High Resolution Timer (866)2.6.15Call function with external stack (870)2.6.16Interrupt allocation (872)2.6.17Logging library (877)2.6.18Miscellaneous System APIs (882)2.6.19空中升级(OTA) (890)2.6.20Performance Monitor (900)2.6.21电源管理 (902)2.6.22Sleep Modes (907)2.6.23Watchdogs (916)2.6.24System Time (920)2.6.25Internal and Unstable APIs (924)2.7Project Configuration (924)2.7.1Introduction (924)2.7.2Project Configuration Menu (924)2.7.3Using sdkconfig.defaults (925)2.7.4Kconfig Formatting Rules (925)2.7.5Backward Compatibility of Kconfig Options (925)2.7.6Configuration Options Reference (926)2.7.7Customisations (1094)2.8Error Codes Reference (1094)3ESP32-S2H/W硬件参考11013.1ESP32-S2系列模组和开发板 (1101)3.1.1模组 (1101)3.1.2相关文档 (1101)3.2ESP32-S2模组与开发板（历史版本） (1101)3.2.1模组 (1101)3.2.2开发板 (1102)3.2.3相关文档 (1102)3.3Chip Series Comparison (1102)3.3.1Related Documents (1104)4API指南11054.1应用层跟踪库 (1105)4.1.1概述 (1105)4.1.2运行模式 (1105)4.1.3配置选项与依赖项 (1105)4.1.4如何使用这个库 (1106)4.2应用程序的启动流程 (1112)4.2.1一级引导程序 (1113)iii4.2.2二级引导程序 (1113)4.2.3应用程序启动阶段 (1113)4.3引导加载程序（Bootloader） (1114)4.3.1引导加载程序兼容性 (1114)4.3.2恢复出厂设置 (1114)4.3.3从测试应用程序分区启动 (1115)4.3.4从深度睡眠中快速启动 (1115)4.3.5自定义引导程序 (1115)4.4构建系统（CMake版） (1115)4.4.1概述 (1116)4.4.2使用构建系统 (1116)4.4.3示例项目 (1119)4.4.4项目CMakeLists文件 (1120)4.4.5组件CMakeLists文件 (1121)4.4.6组件配置 (1123)4.4.7预处理器定义 (1123)4.4.8组件依赖 (1124)4.4.9组件CMakeLists示例 (1128)4.4.10自定义sdkconfig的默认值 (1131)4.4.11Flash参数 (1132)4.4.12构建Bootloader (1132)4.4.13选择目标芯片 (1132)4.4.14编写纯CMake组件 (1133)4.4.15组件中使用第三方CMake项目 (1133)4.4.16组件中使用预建库 (1134)4.4.17在自定义CMake项目中使用ESP-IDF (1134)4.4.18ESP-IDF CMake构建系统API (1135)4.4.19文件通配&增量构建 (1138)4.4.20构建系统的元数据 (1139)4.4.21构建系统内部 (1139)4.4.22从ESP-IDF GNU Make构建系统迁移到CMake构建系统 (1141)4.5Deep Sleep Wake Stubs (1142)4.5.1Rules for Wake Stubs (1143)4.5.2Implementing A Stub (1143)4.5.3Loading Code Into RTC Memory (1143)4.5.4Loading Data Into RTC Memory (1143)4.6Device Firmware Upgrade through USB (1144)4.6.1Building the DFU Image (1145)4.6.2Flashing the Chip with the DFU Image (1145)4.7错误处理 (1146)4.7.1概述 (1146)4.7.2错误码 (1147)4.7.3错误码到错误消息 (1147)4.7.4ESP_ERROR_CHECK宏 (1147)4.7.5错误处理模式 (1148)4.7.6C++异常 (1148)4.8ESP-MESH (1148)4.8.1概述 (1149)4.8.2简介 (1149)4.8.3ESP-MESH概念 (1149)4.8.4建立网络 (1155)4.8.5管理网络 (1159)4.8.6数据传输 (1161)4.8.7信道切换 (1163)4.8.8性能 (1166)4.8.9更多注意事项 (1167)4.9Core Dump (1167)4.9.1Overview (1167)iv4.9.2Configurations (1167)4.9.3Save core dump toflash (1168)4.9.4Print core dump to UART (1168)4.9.5ROM Functions in Backtraces (1168)4.9.6Dumping variables on demand (1169)4.9.7Running espcoredump.py (1169)4.10Event Handling (1170)4.10.1Wi-Fi,Ethernet,and IP Events (1170)4.10.2Mesh Events (1171)4.10.3Bluetooth Events (1171)4.11片外RAM (1172)4.11.1简介 (1172)4.11.2硬件 (1172)4.11.3配置片外RAM (1172)4.11.4片外RAM使用限制 (1173)4.12严重错误 (1174)4.12.1概述 (1174)4.12.2紧急处理程序 (1174)4.12.3寄存器转储与回溯 (1175)4.12.4GDB Stub (1176)4.12.5Guru Meditation错误 (1177)4.12.6其它严重错误 (1178)4.13Flash加密 (1179)4.13.1概述 (1179)4.13.2Flash加密过程中使用的eFuse (1180)4.13.3Flash的加密过程 (1180)4.13.4设置Flash加密的步骤 (1181)4.13.5Flash加密的要点 (1187)4.13.6使用加密的Flash (1187)4.13.7更新加密的Flash (1188)4.13.8关闭Flash加密 (1188)4.13.9Flash加密的局限性 (1189)4.13.10Flash加密与安全启动 (1189)4.13.11使用无安全启动的Flash加密 (1189)4.13.12Flash加密的高级功能 (1189)4.13.13技术细节 (1190)4.14ESP-IDF FreeRTOS SMP Changes (1191)4.14.1Overview (1191)4.14.2Tasks and Task Creation (1191)4.14.3Scheduling (1192)4.14.4Critical Sections&Disabling Interrupts (1194)4.14.5Task Deletion (1195)4.14.6Thread Local Storage Pointers&Deletion Callbacks (1195)4.14.7Configuring ESP-IDF FreeRTOS (1195)4.15Hardware Abstraction (1195)4.15.1Architecture (1196)4.15.2LL(Low Level)Layer (1197)4.15.3HAL(Hardware Abstraction Layer) (1198)4.16High-Level Interrupts (1199)4.16.1Interrupt Levels (1199)4.16.2Notes (1199)4.17JTAG调试 (1200)4.17.1引言 (1200)4.17.2工作原理 (1201)4.17.3选择JTAG适配器 (1201)4.17.4安装OpenOCD (1202)4.17.5配置ESP32-S2目标板 (1202)4.17.6启动调试器 (1207)v4.17.7调试范例 (1207)4.17.8从源码构建OpenOCD (1207)4.17.9注意事项和补充内容 (1211)4.17.10相关文档 (1215)4.18链接脚本生成机制 (1240)4.18.1概述 (1240)4.18.2快速上手 (1240)4.18.3链接脚本生成机制内核 (1243)4.19lwIP (1247)4.19.1Supported APIs (1247)4.19.2BSD Sockets API (1248)4.19.3Netconn API (1252)4.19.4lwIP FreeRTOS Task (1252)4.19.5esp-lwip custom modifications (1252)4.19.6Performance Optimization (1253)4.20应用程序的内存布局 (1254)4.20.1IRAM（指令RAM） (1254)4.20.2IROM（代码从Flash中运行） (1255)4.20.3RTC快速内存 (1255)4.20.4DRAM（数据RAM） (1255)4.20.5DROM（数据存储在Flash中） (1255)4.20.6RTC慢速内存 (1256)4.21DMA能力要求 (1256)4.22分区表 (1257)4.22.1概述 (1257)4.22.2内置分区表 (1257)4.22.3创建自定义分区表 (1258)4.22.4生成二进制分区表 (1260)4.22.5烧写分区表 (1260)4.22.6分区工具(parttool.py) (1260)4.23RF calibration (1262)4.23.1Partial calibration (1262)4.23.2Full calibration (1262)4.23.3No calibration (1262)4.23.4PHY initialization data (1263)4.24Secure Boot V2 (1263)4.24.1Background (1263)4.24.2Advantages (1263)4.24.3Secure Boot V2Process (1263)4.24.4Signature Block Format (1264)4.24.5Verifying the signature Block (1264)4.24.6Bootloader Size (1265)4.24.7eFuse usage (1265)4.24.8How To Enable Secure Boot V2 (1265)4.24.9Restrictions after Secure Boot is enabled (1266)4.24.10Generating Secure Boot Signing Key (1266)4.24.11Remote Signing of Images (1266)4.24.12Secure Boot Best Practices (1267)4.24.13Key Management (1267)4.24.14Multiple Keys (1267)4.24.15Key Revocation (1267)4.24.16Technical Details (1268)4.24.17Secure Boot&Flash Encryption (1268)4.24.18Signed App Verification Without Hardware Secure Boot (1269)4.24.19Advanced Features (1269)4.25Thread Local Storage (1269)4.25.1Overview (1270)4.25.2FreeRTOS Native API (1270)vi4.25.3Pthread API (1270)4.25.4C11Standard (1270)4.26工具 (1270)4.26.1Downloadable Tools (1270)4.26.2IDF Docker Image (1279)4.26.3IDF Windows Installer (1281)4.26.4IDF Component Manager (1282)4.27ULP协处理器编程 (1283)4.27.1ESP32-S2ULP coprocessor instruction set (1283)4.27.2Programming ULP coprocessor using C macros(legacy) (1299)4.27.3安装工具链 (1303)4.27.4编译ULP代码 (1303)4.27.5访问ULP程序变量 (1304)4.27.6启动ULP程序 (1305)4.27.7ESP32-S2ULP程序流 (1306)4.28ULP-RISC-V协处理器编程 (1307)4.28.1安装ULP-RISC-V工具链 (1307)4.28.2编译ULP-RISC-V代码 (1307)4.28.3访问ULP-RISC-V程序变量 (1308)4.28.4启动ULP-RISC-V程序 (1308)4.28.5ULP-RISC-V程序流 (1309)4.29ESP32-S2中的单元测试 (1309)4.29.1添加常规测试用例 (1310)4.29.2添加多设备测试用例 (1310)4.29.3添加多阶段测试用例 (1311)4.29.4应用于不同芯片的单元测试 (1312)4.29.5编译单元测试程序 (1312)4.29.6运行单元测试 (1313)4.30USB OTG Console (1314)4.30.1Hardware Requirements (1314)4.30.2Software Configuration (1314)4.30.3Uploading the Application (1314)4.30.4Limitations (1315)4.31Wi-Fi驱动程序 (1316)4.31.1ESP32-S2Wi-Fi功能列表 (1316)4.31.2如何编写Wi-Fi应用程序 (1316)4.31.3ESP32-S2Wi-Fi API错误代码 (1317)4.31.4初始化ESP32-S2Wi-Fi API参数 (1317)4.31.5ESP32-S2Wi-Fi编程模型 (1317)4.31.6ESP32-S2Wi-Fi事件描述 (1318)4.31.7ESP32-S2Wi-Fi station一般情况 (1321)4.31.8ESP32-S2Wi-Fi AP一般情况 (1323)4.31.9ESP32-S2Wi-Fi扫描 (1323)4.31.10ESP32-S2Wi-Fi station连接场景 (1330)4.31.11找到多个AP时的ESP32-S2Wi-Fi station连接 (1334)4.31.12Wi-Fi重新连接 (1334)4.31.13Wi-Fi beacon超时 (1334)4.31.14ESP32-S2Wi-Fi配置 (1334)4.31.15Wi-Fi Easy Connect™(DPP) (1338)4.31.16无线网络管理 (1339)4.31.17无线资源管理 (1339)4.31.18Wi-Fi Location (1339)4.31.19ESP32-S2Wi-Fi节能模式 (1340)4.31.20ESP32-S2Wi-Fi吞吐量 (1340)4.31.21Wi-Fi80211数据包发送 (1341)4.31.22Wi-Fi Sniffer模式 (1342)4.31.23Wi-Fi多根天线 (1343)4.31.24Wi-Fi信道状态信息 (1344)vii4.31.25Wi-Fi信道状态信息配置 (1345)4.31.26Wi-Fi HT20/40 (1345)4.31.27Wi-Fi QoS (1345)4.31.28Wi-Fi AMSDU (1346)4.31.29Wi-Fi分片 (1346)4.31.30WPS注册 (1346)4.31.31Wi-Fi缓冲区使用情况 (1346)4.31.32如何提高Wi-Fi性能 (1347)4.31.33Wi-Fi Menuconfig (1350)4.31.34故障排除 (1353)4.32Wi-Fi Security (1358)4.32.1ESP32-S2Wi-Fi Security Features (1358)4.32.2Protected Management Frames(PMF) (1358)4.32.3WPA3-Personal (1359)5Libraries and Frameworks13615.1Cloud Frameworks (1361)5.1.1AWS IoT (1361)5.1.2Azure IoT (1361)5.1.3Google IoT Core (1361)5.1.4Aliyun IoT (1361)5.1.5Joylink IoT (1361)5.1.6Tencent IoT (1361)5.1.7Tencentyun IoT (1362)5.1.8Baidu IoT (1362)6Contributions Guide13636.1How to Contribute (1363)6.2Before Contributing (1363)6.3Pull Request Process (1363)6.4Legal Part (1364)6.5Related Documents (1364)6.5.1Espressif IoT Development Framework Style Guide (1364)6.5.2Install pre-commit Hook for ESP-IDF Project (1370)6.5.3编写代码文档 (1371)6.5.4文档的附加工具和扩展功能指南 (1380)6.5.5创建示例项目 (1383)6.5.6API Documentation Template (1384)6.5.7Contributor Agreement (1386)7ESP-IDF版本简介13897.1发布版本 (1389)7.2我该选择哪个版本？ (1389)7.3版本管理 (1389)7.4支持期限 (1390)7.5查看当前版本 (1391)7.6Git工作流 (1392)7.7更新ESP-IDF (1392)7.7.1更新至一个稳定发布版本 (1393)7.7.2更新至一个预发布版本 (1393)7.7.3更新至master分支 (1393)7.7.4更新至一个发布分支 (1393)8资源13958.1PlatformIO (1395)8.1.1What is PlatformIO? (1395)8.1.2Installation (1395)8.1.3Configuration (1396)8.1.4Tutorials (1396)viii8.1.5Project Examples (1396)8.1.6Next Steps (1396)8.2有用的链接 (1396)9Copyrights and Licenses13979.1Software Copyrights (1397)9.1.1Firmware Components (1397)9.1.2Build Tools (1398)9.1.3Documentation (1398)9.2ROM Source Code Copyrights (1398)9.3Xtensa libhal MIT License (1399)9.4TinyBasic Plus MIT License (1399)9.5TJpgDec License (1399)10关于本指南1401 11切换语言1403索引1405索引1405ix这里是乐鑫IoT开发框架(esp-idf)的文档中心。
深入解析OPEN-FLOW SDN
深入浅出解析OpenFlowOpenFlow所面临的挑战OpenFlow标准的不成熟，在控制层面也有不少体现，尽管体现的不如转发层面那么明显。
根据对OpenFlow标准的分析以及一些实际部署案例的反馈，OpenFlow在控制面还存在如下不足：∙Master（主）和Slave（备）Controller的选举机制还不够成熟，都没有标准来定义。
∙Controller的集中式控制，理论上肯定会有可扩展性问题，分布式控制又跟SDN的原则有些冲突，到底应该如何把握好这个平衡？∙流表配置的速度比较慢，特别是网络比较大的时候，要配置这么多设备的这么多流，速度跟不上，有严重的性能问题。
∙仅凭现有的OpenFlow接口，还有很多配置无法完成，需要很多私有扩展，这会导致不兼容性。
∙安全性还不能得到充分保证，需要进一步的安全机制。
∙原来的所有控制面协议都在每一台设备里面，现在都集中到了Controller上，这是否合理？是不是有些东西还应该保留在交换机上？Google进行了OpenFlow实践之后，在总结报告里面就提到了这个问题，哪些东西该放在交换机上、哪些东西该放在Controller上并不是一个容易回答的问题。
跟转发面的挑战不同，转发面如果有功能性问题，直接会导致OpenFlow设备没法用（因为不能满足功能需求），而控制面的挑战更多在于网络健壮性、稳定性、可扩展性、安全性，也就是说做实验网络或者小型商用网络没问题，但是一旦要用在大中型网络等情况复杂的网络中，控制面的问题就会变得很突出。
这就像很多时候在实验室里面验证网络设备的时候，大多数问题都出在功能上面，网络管理系统的故障很容易解决并稳定下来，但是一旦到了商业网络里面，很多控制管理面的问题就暴露出来了。
跟传统的协议一样，OpenFlow技术要想成熟稳定，必须经过大量的实践检验，ONF需要尽最大可能去避免OpenFlow走入一个“标准不成熟→缺少商用案例→无从反馈→标准仍然不成熟”的恶性循环。
Teigha.NET开发入门1-Teigha介绍
开发⼊门1-Teigha 介绍 开发⼊门1-Teigha 介绍对于CAD 开发，⽆疑较强⼤的⽅式是Lisp 、AutoCAD ⼆次开发，且学习资源丰富，依靠强⼤的AutoCAD 的环境可以⼲很多事，省很多⼒。
但若要脱离AutoCAD 环境，那就当属Teigha 了。
名称问题Teigha （我读着"胎压"，没有标准语⾳）是ODA 的⼀个产品名称。
ODA （Open Design Alliance ）,开放设计联盟，于1998年创建，⼀个致⼒于实现CAD 数据格式交换和共享的⾮盈利国际组织，它的Teigha 是⼀套⾯向对象的⽀持多平台、多版本、多格式的CAD ⽂件的类库，可脱离AutoCAD 环境实现读写操作、绘制渲染和转换输出等。
Teigha for .dwg （曾⽤名OpenDWG 、DWGdirect ）是Teigha 的⼀个⼦集，除操作dwg ⽂件外，它还有操作BIM(revit),Civil, Architecture, Mechanical 等⼦集。
也就是说对于Autodesk 公司的产品，它基本都有相应的SDK 。
刚接触它很容易被它的名称搞晕。
2010年，ODA 将其所有的软件统⼀命名为" Teigha"，⽽在2018年9⽉官⽅宣布将弃⽤"Teigha"这个产品名。
这是他们的LOGO 和标语，我不作评论。
在没改名前，它们的类库依赖关系是：其中， 是我们接下来要讲的⼀套基于.NET 读写CAD ⽂件的类库。
收费问题同名称⼀样，这是很多⼈都没搞清楚的问题。
ODA 是⼀个会员制的组织，会员由软件公司、软件开发⼈员以及使⽤者组成。
所以我们⾮会员⽆法下载类库、查看帮助⽂档等（官⽹ ）。
会员负责向联盟和其他会员提供ODA 技术平台、创建图形化应⽤程序的⼯具等。
在版权⽅⾯，对于⾮商业应⽤，可以⾃由使⽤ODA 提供的⼯具和软件包；对于商业应⽤，需要交纳会员注册费⽤。
SDN核心技术剖析和实战指南---读书笔记
SDN核⼼技术剖析和实战指南---读书笔记第⼀章SDN定义如下：SDN是⼀种新兴的基于软件的⽹络架构及技术，其最⼤的特点在于具有松耦合的控制平⾯与数据平⾯、⽀持集中化的⽹络状态控制、实现底层⽹络设施对上层应⽤的透明。
SDN和NFV：ONF（开发⽹络基⾦会）从⽤户⾓度定义SDN架构，ETSI（欧洲电信标准化协会）从⽹络运营商⾓度出发提出的NFV（⽹络功能虚拟化）架构。
ONF提出的SDN架构图如下：分为三层：应⽤层---包括各种不同的业务和应⽤；控制层---负责处理数据平⾯资源的编排，维护⽹络拓扑、状态信息等；基础设施层---负责数据处理、转发和状态收集。
应⽤层与控制层通过北向接⼝API连接，控制层与基础设施层通过南向接⼝OpenFlow等连接。
ETSI提出的NFV⽹路架构草案图如下：NFV相对于SDN的⽐较：相同点：都实现了转发层⾯与控制层⾯的分离，并在控制层⾯上提出了类似SDN中应⽤层的虚拟化架构的管理和编排层。
不同点：NFV在南向接⼝上，除了ONF倡导的OpenFlow协议之外，还包含了ForCES、PCE-P等之前已经在IETF等传统⽹络标准化组织中获得认可的接⼝；NFV将控制层⾯进⾏了更细致的划分，提出了端到端的⽹络控制层。
OpenDaylight开源项⽬架构图如下：OpenDaylight开源项⽬的主要内容包括SDN控制器开发、南北向接⼝API的扩展、⽤于多个控制器关联的东西向协议实现等。
SDN三⼤基本特征：1.集中控制：逻辑上集中的控制能⽀持获得⽹络资源的全局信息并根据业务需求进⾏资源的全局调配和优化，例如流量⼯程、负载均衡等。
同时，集中控制还使得整个⽹络可在逻辑上被视作是⼀台设备进⾏运⾏和维护，⽆须对物理设备进⾏现场配置，从⽽提升了⽹络控制的便捷性。
2.开放接⼝：通过开放的南向和北向接⼝，能够实现应⽤和⽹路的⽆缝集成，使得应⽤能告知⽹络如何运⾏才能更好地满⾜应⽤的需求，⽐如业务的带宽、时延需求，计费对路由的影响等。
SDN软件定义网络之南向协议——OpenFlow协议
SDN软件定义网络之南向协议——OpenFlow协议一、引言软件定义网络（Software-Defined Networking，SDN）是一种新兴的网络架构，通过将网络控制平面（control plane）与数据转发平面（data plane）分离，实现网络的灵活性和可编程性。
南向协议（Southbound Protocol）是SDN架构中控制器与网络设备之间的通信协议，用于实现控制器对网络设备的管理和控制。
本协议旨在详细描述SDN中最常用的南向协议之一——OpenFlow协议。
二、OpenFlow协议概述OpenFlow协议是SDN架构中最具代表性的南向协议之一，由Open Networking Foundation（ONF）开发和维护。
该协议定义了控制器与交换机之间的通信方式，使得控制器可以直接控制和管理交换机的数据转发行为。
三、OpenFlow协议架构1. 控制平面（Control Plane）：控制器负责管理和控制网络设备，向交换机发送控制指令，并接收交换机的状态信息。
2. 数据平面（Data Plane）：交换机负责实际的数据包转发和处理，根据控制器的指令进行相应的操作。
3. OpenFlow通道（OpenFlow Channel）：控制器与交换机之间的双向通信通道，用于传输控制消息和状态信息。
四、OpenFlow协议消息格式OpenFlow协议定义了多种消息类型，用于控制器与交换机之间的通信。
每个消息由消息头和消息体组成。
1. 消息头（Message Header）：包含消息类型、消息长度等信息，用于标识和解析消息。
2. 消息体（Message Body）：根据消息类型的不同，包含不同的字段和参数，用于传递具体的控制指令或状态信息。
五、OpenFlow协议交互过程1. 握手阶段（Handshake）：控制器与交换机建立连接，进行协议版本的协商和能力的交换。
2. 特征请求阶段（Features Request）：控制器向交换机发送特征请求消息，获取交换机的基本信息和能力。
SDN软件定义网络之南向协议——OpenFlow协议 (2)
SDN软件定义网络之南向协议——OpenFlow协议一、引言1.1 背景随着云计算、大数据、物联网等技术的快速发展，传统网络架构面临着许多挑战，例如网络管理复杂、可扩展性差、灵便性不足等。
为了解决这些问题，软件定义网络（Software Defined Networking，SDN）应运而生。
SDN通过将网络控制平面与数据转发平面分离，实现了网络的集中控制和灵便管理。
1.2 目的本协议的目的是定义SDN中南向协议的标准格式，特殊是OpenFlow协议的相关规范和要求，以便确保各厂商和组织在实施SDN时能够达到互操作性和兼容性。
二、OpenFlow协议概述2.1 定义OpenFlow是一种开放的、基于标准化的南向协议，用于在SDN架构中实现控制器与数据平面之间的通信。
OpenFlow协议定义了控制器和交换机之间的消息格式和交互方式，允许控制器对数据平面进行直接编程和控制。
2.2 功能OpenFlow协议提供了以下主要功能：- 控制器与交换机之间的通信：控制器可以通过OpenFlow协议与交换机进行通信，发送命令和配置信息。
- 流表管理：控制器可以通过OpenFlow协议向交换机下发流表项，实现流量的转发和处理。
- 路由控制：控制器可以通过OpenFlow协议向交换机下发路由信息，实现网络的路由控制和优化。
- QoS管理：控制器可以通过OpenFlow协议向交换机下发QoS策略，实现对流量的优先级和带宽的管理。
三、OpenFlow协议消息格式3.1 消息类型OpenFlow协议定义了多种消息类型，用于控制器和交换机之间的通信。
常见的消息类型包括Hello消息、Echo消息、错误消息、配置消息等。
3.2 消息结构每一个OpenFlow消息由消息头和消息体组成。
消息头包含了消息类型、消息长度等信息，消息体则包含了具体的命令和配置信息。
3.3 消息交互OpenFlow协议采用了请求-响应的消息交互机制。
控制器发送请求消息给交换机，交换机接收并处理请求消息后，发送响应消息给控制器。
某新产品开发流程概述
产品开发依不同时期的任务，共分为七个阶段：DR1﹕开发可行性评估 (Feasibility)DR2﹕设计规划与细部设计 (Planning & Design)DR3﹕产品功能验证 (EVT)DR4﹕设计验证 (DVT)DR5﹕产试行验证 (PVT)DR6﹕量产 (Mass Production)DR7﹕顾客回馈 (Customer Feedback)
DR2 Planning & Design (主导单位: RD)8.IP Survey & IP Application (Owner: IP)9.Engineering Spec. Preparation (Owner: EE)EE 整合ID, ME, EE, F/W, DQA, EMC/Safety, PE等单位所提出的产品工程规格草案，制作第一版的[Engineering Spec.],并透过DCC发行。IP人员依据新产品外观设计，展开专利可行性分析 (参考[豪恩专利管制作业办法])Engineering Spec.:A. Operation SpecificationsB. Electrical and Optical Characteristics and PerformanceC. Input / Output Signal SpecificationsD. Function SpecificationsE. Reliability SpecificationsF. MechanicalG. PackageH. Marking and Identification
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
OF1.3 Hello [Proto = 0x04] OF1.3 Hello [Proto = 0x04]
OF1.3 Feature Request OF1.3 Feature Reply OF1.3 Set Config
https:///view/OpenDaylight_Controller:MD-SAL:Architecture
从AD-SAL到MD-SAL
https:///view/OpenDaylight_Controller:MD-SAL:FAQ
NorthBound
REST API
YANG model defined NBI
NBI
Hale Waihona Puke ControllerData Collection Network Programing
SAL
Device Discovery Capability Abstract
MD-SAL
AD-SAL
rpc
notification
OpenDaylight架构框架
https:///view/OpenDaylight_Controller :Architectural_Framework#Service_Abstraction_Layer
OpenDaylight Hydrogen技术架构
TCP [Sync, Ack] TCP [Ack]
对于那些通过YANG模型生成的java接口、类和方 法：
• 控制器下发的信息：利用setter方法对照协议写进 去即可
• 控制器收到的信息：利用getter方法对照协议将字 节流解析存储，也即存到YANG模型的data-store （data tree）里
Plugin 开发流程
https:///view/OpenDaylight_Controller:MD-SAL:FAQ
YANG模型
YANG模型是什么？
YANG模型是一种数据建模语言，其产生是为了对NETCONF协议所操作的数据进行 建模。最初的网络管理协议SNMP也有对应的建模语言SMI。
notification
OpenFlow Plugin rpc OpenFlowJava
OpenFlow1.0
OpenFlow1.3
OpenFlow1.0
OpenFlow1.3
OpenFlow1.0
OpenFlow1.3 OpenFlow1.0
Network Equipment
• YANG 模型是 MD-SAL的灵魂， 而MD-SAL为 OpenDaylight 所推广
器北向接口API的应用可以以一种原生格式与数据模型一起调用（YIN&plugin） • 利用一种模式语言简化控制器元素和应用的开发。模块中提供功能的开发者可以定
义一个模型，从而可以创建对于所提供功能的更简单的、数据类型的API。因此降低 了通过服务抽象层提供的数据结构的错误交互。（YIN&java files）
基于MD-SAL连接建立（OpenFlow v1.3）
当交换机与控制器通过协议校验，控制器会向交换 NE
Ctrl
机请求一系列信息（端口信息、链路信息等）
TCP [Sync] [Dest Port 6633]
不管是控制器下发的Request消息，还是网元回复 的reply消息，在控制器中都是采用YANG模型来定 义的
MD-SAL
MD-SAL
对于服务抽象层的Model-driven方法体现出一种统一北向和南向API以及SDN控制 器中多种服务和元素中所使用的数据结构。
为了描述控制器元素所提供的数据结构，YANG模型作为一种服务和数据抽象的建 模语言就起到了作用。
YANG模型特性： • 建模XML格式数据并由控制器元素提供功能（YIN&plugin） • 定义语义元素和他们的关系（data tree） • 模拟所有的元素作为一个系统（data tree） • YANG数据模型的XML特性提供了一种自表述数据的方式，控制器元素和采用控制
目录
OpenDayLight
• OpenDaylight架构框架
• OpenDaylight Hydrogen技术架构
• OpenDaylight Hydrogen工程架构
MD-SAL
• 从AD-SAL到MD-SAL
• 基于MD-SAL连接建立（OpenFlow v1.3）
• Plugin 开发流程
https:///view/OpenDaylight_Controller:Hydrogen_Developer_Guide
OpenDaylight Hydrogen工程架构
蓝色箭头为 MD-SAL方式
红色箭头为 AD-SAL方式
Web APP
REST API/RestConf Protocol
• “Add Flow” 示例
YANG模型
• YANG，NETCONF，RESTCONF
• YANG模型语法详解
• Data store两种形式
• Data tree
https:///view/OpenDaylight_Controller
OpenDaylight
YANG模型通过树形结构的节点定义描述了数据模型的层级嵌套结构以及各属性的 数据类型。YANG具有自己的语法格式，也可以无差别地转换为XML格式，称之为 YIN。可以使用第三方工具pyang进行转换。pyang地址：/twiki/pub/Main/YangTools/pyang.1.html
OF1.3 Multipart Request [PORT_DESC] <body=null>
OF1.3 Multipart Reply [PORT_DESC] array[<ofp_port>]
“Add Flow” 示例
https:///view/OpenDaylight_Controller:MD-SAL:FAQ