openflow openflow协议
openflow协议
?of 协议支持三种消息类型：controller-to-switch，asynchronous（异步）和symmetric（对称），每一类消息又有多个子消息类型。
?controller-to-switch 消息由控制器发起，用来管理或获取switch 状态；?asynchronous 消息由switch 发起，用来将网络事件或交换机状态变化更新到控制器；?symmetric 消息可由交换机或控制器发起。
controller-to-switch
?Features
?在建立传输层安全会话（Transport Layer Security Session）的时候，控制器发送feature请求消息给交换机，交换机需要应答自身支持的功能。
?Configuration
?控制器设置或查询交换机上的配置信息。交换机仅需要应答查询消息。?Modify-state
?控制器管理交换机流表项和端口状态等。
?Read-state
?控制器向交换机请求一些诸如流、网包等统计信息。
?Send-packet
?控制器通过交换机指定端口发出网包。
?Barrier
?控制器确保消息依赖满足，或接收完成操作的通知
asynchronous
?Packet-in
?交换机收到一个网包，在流表中没有匹配项，则发送Packet-in 消息给控制器。如果交换机缓存足够多，网包被临时放在缓存中，网包的部分内容（默认128 字节）和在交换机缓存中的的序号也一同发给控制器；如果交换机缓存不足以存储网包，则将整个网包作为消息的附带内容发给控制器。
?Flow-removed
?交换机中的流表项因为超时或修改等原因被删除掉，会触发Flow-removed 消息。
?Port-status
?交换机端口状态发生变化时（例如down 掉），触发Port-status 消息。
symmetric
?Hello
?交换机和控制器用来建立连接。
?Echo（）
?交换机和控制器均可以向对方发出Echo 消息，接收者则需要回复Echo reply。该消息用来测量延迟、是否连接保持等。?Vendor
?交换机提供额外的附加信息功能。为未来版本预留。
ofpt 协议头
?struct ofp_header {
?uint8_t version; /* 协议版本*/
?uint8_t type; /* 消息类型*/
?uint16_t length; /* 消息长度*/
?uint32_t xid;/* 该报文的ID，要求返回的报文ID相同，以使它们配对*/
?};
代码的大体结构
?涉及报文传输与生成的mian函数?udatapath.c 负责datapat ?controller.c 负责controller ?secchan.c 负责安全通道?dpctl.c 负责管理dp
接受报文后的处理
?secchan负责连接controller和udatapath，controller和switch的数据交互要经过secchan。
?如果网络的拓扑结构发生变化，导致IP地址的变化，secchan调用ofp-discover重新连接IP变化的peer
?dpctl.c可以发出任何协议包，所以它可以用来修改switch的一些状态，比如生成树什么的。echo只能由dpctl发出。setting的参数由它设置。
controller协议报文相关
?controller的大体流程
调用do_switching(struct switch_ *sw)/*返回发出的报文总数、读取报文、分析header、处理报文、并且维护连接。
调用lswitch_process_packet(sw-
>lswitch, sw->rconn, msg)
读取报文，根据报文的类型处理报文
?type为：OFPT_ECHO_REQUEST
调用：process_echo_request（…，…，*rp）调用queue_tx()排队，最多排10对
调用make_echo_reply()创建一个
echo_reply的消息，这个消息跟rp中的消息匹配
?OFPT_FEATURES_REPLY
调用：process_switch_features 交换机返回自身状态datapath_ID、能力
调用：process_phy_port了解交换机的port状态
stp：listening、learning、forwarding、blocking、disable
non-stp：forwarding
?OFPT_PACKET_IN
调用函数process_packet_in 根据报文的长度判断报文打给controller的原因：流表项指定发给controller（max-len）；查不到匹配流表项（miss-send-len字节）。
源端口是保留的广播地址、stp显示源端口不能接受节点、源端口和目的端口是同一个端口时，drop it。
若成功，发出，setup new flow
交换机有无缓存报文
不setup flow 只能指定一次
?报文为：OFPT_PORT_STATUS 调用process_port_status
调用process_phy_port 修改port的状态port为stp时：P_LISTENING、
P_LEARNING、P_FORWARDING、
P_BLOCKING、P_DISABLED。
非stp：P_FORWARDING
报文头部：OFPT_STATS_REPLY（流、网
包等统计信息的反馈）
调用process_stats_reply(读取交换机的信息，比如最后reply的时间)
调用process_flow_stats（根据读取的信
息判断流表是否应该删除）
调用make_openflow以及rconn_send发出type为（OFPT_FLOW_MOD或者OFPFC_DELETE_STRICT的报文）
报文头部为：OFPT_FLOW_REMOVED NUll
udatapath.c ?udatapath.c大体流程
?调用dp-run()
调用netdev-recv 接收报文，放入buffer中调用fed-port-input （接受报文，遍历流表寻找匹配的流表项，没有就发给controller）调用run-flow-through-table（遍历流表，并且处理报文）
调用dp-output-control 负责组建ofp-packet-in 报文、确定发多少数据给controller(根据reason和switch的缓存能力)
调用remote-run（做一些保持连接的处理，并且接受remote发来的报文并且处理它们，最高迭代50次，以防止其他进程饿死。）调用fwd-controller-input读取报文，分析报文头部，判断是否是来自controller的报文，并且处理来自controller的报文
?报文头部：OFPT_BARRIER_REQUEST 调用recv_barrier_request
先make_barrier_reply
后send_openflow_buffer分析接受数据，判断Send back to the sender或者是Broadcast to all remotes
?OFPT_FEATURES_REQUEST
调用recv_features_request
调用dp_send_features_reply
先make_openflow_reply
后将sw的状态放入报文datapath_id、n_tables 、n_buffers、capabilities、actions
send_openflow_buffer
保密协议 本保密协议（以下简称“本协议”）于【】由以下双方签订： 【】（以下简称“甲方”），是一家根据中华人民共和国法律依法设立，并合法存续的公司，公司地址为：【】 与 【】（以下简称“乙方”），是一家根据中华人民共和国法律依法设立，并合法存续的公司，公司地址为：【】。 鉴于，甲乙双方希望就股权投资之交易或合作事宜（以下简称“交易”）进行讨论和磋商，在此过程中，双方将互相披露本协议中所涉及的保密信息，双方对这些信息应当予以严格保密。 为此，甲乙双方在自愿接受本协议规定的义务约束前提下，达成如下协议： 第一条、保密信息的定义 1.1 本协议中所称“保密信息”指，协议任一方所拥有的、不为公众所知的 所有信息或数据，无论该信息为有形的或无形的，也无论何时以何种方 式披露，保密信息应当包括： (1)任何与协议方及其子公司与关联公司过去、现在和未来的商业活动有 关的市场策略、计划、财务信息、发展规划、运营规划、销售数据、 商业计划、运营成果； (2)与商品或服务有关的计划，及顾客与供应商名录； (3)任何科学技术方面的信息、发明、设计、流程、配方、改进、技术及
方法； (4)任何概念、报告、数据、专业技能、在制产品、设计、研发工具、技 术规格、计算机软件、源代码、目标代码、流程图、数据库、及商业 秘密； (5)其他由协议方合理列为保密信息的信息。 上述所有信息均应被视为保密信息，无论在披露时该信息是否被标记保密字样。 1.2 保密信息不应包括： (1)在披露时已经被接收披露的一方知悉的信息； (2)非因接收披露的一方的错误行为造成的被公众所知悉的信息； (3)接收披露的一方从第三方合理获取的不负有保密义务的信息； (4)由接收披露的一方员工、顾问或代理人，在不违背本保密协议义务的 情况下独立探索得到的本协议所称的保密信息。 第二条、保密信息的披露 协议双方同意，自对任何保密信息披露之日起的三年内，任何一方不得向任何第三方泄露由对方披露的保密信息，不得将获得的保密信息用于对本次交易利益权衡目的之外的其他目的。双方应当： (1)仅向涉及双方商业合作事宜的，有需要知悉该保密信息的董事、管理人 员、雇员、代理人、代表人（以下统称“代表人”）披露保密信息； (2)向代表人告知保密信息的所有权属性，向其告知本方在本协议下的保密 义务，并要求代表人对保密信息予以保密； (3)对所获得的保密信息严格保密，并给予与保护本方所属的保密信息所给 予的同等、合理的注意。
OpenFlow 交换机规范(概要) Version 1.3.0 （June 25, 2012） 1 介绍 本文档介绍的OpenFlow 交换机的要求。规范包括交换机的组件和基本功能，和OpenFlow 的协议，通过一个远程控制器来管理一个OpenFlow 的交换机。 2 交换机组成 OpenFlow 的交换机包括一个或多个流表和一组表，执行分组查找和转发，和到一个外部控制器OpenFlow 的信道（图1）。该交换机与控制器进行通信，并通过OpenFlow 的协议控制器管理的交换机。 控制器使用OpenFlow 的协议，它可以添加、更新和删除流流表中的表项，既主动或者被动响应数据包。 在交换机中的每个流表中包含的一组流 表项;每个流表项包含匹配字段，计数器和一组指令，用来匹配数据包（见5.2）。 匹配开始于第一个流程表，并可能会继续额外的流表 (见 5.1）。 流表项匹配数据包按照优先级的顺序，从每个表的第一个匹配表项开始（见5.3）。如果找到匹配的项，那么具体流表项按照指令去执行。 如果在流表中未找到 匹配项 ，结果取决于漏表的流表项配置：（例如， 数据包可被转发到OpenFlow 的信道控制器、丢弃、或者可以继续到下一个的流表，见5.4）。 指令与每个包含行动或修改流水线处理的流表项相联系（见 5.9）。 行动描述了数据包转发，数据包的修改和组表 处理。 流水线处理的指令允许数据包被发送到后面的表进行进一步的 处理 ， 并允许信息以元数据的形式在表之间进行通信。当与一个匹配的流表项相 N.J.C.H
关联的指令集没有指向下一个表的时候，表流水线处理停止，这时该数据包通常被修改和 转发（见5.10）。 流表项可能包含数据包转发到某个端口。这通常是一个物理端口，但它也可能是由交换机 定义的一个逻辑端口或通过本规范中定义的一个保留的端口（见 4.1）。保留端口可以指 定通用的转发行为，如发送到控制器、泛洪、或使用非OpenFlow的方法转发。如 “ 普通” 交换机转发处理（见4.5）；而交换机定义的逻辑端口，可以指定链路汇聚组，隧道或环回 接口（见4.4）。 流表项相关的行动，也可直接把数据包发送到组，进行额外的处理（见 5.6）。组表示一 组泛洪的指令集，以及更复杂的转发（如多路径，快速重路由，链路聚合）。作为间接的通 用层，组也使多个流表项转发到一个单一的标识符（例如一个共同的下一跳的IP转发）。 这种抽象的行为使相同的输出行动非常有效。 组表包含组表项，每个组表项包含了一系列依赖于组类型的特定规范的行动存储段（见5.6.1）。一个或多个操作的行动用来使数据包发送到该组。 假如将正确的匹配和指令规范保护起来，交换机设计者可以任意的实现内部结构。例如， 如果需要使用一个流表项将所有的组转发到多个端口，交换机设计师可以在硬件转发表中 用一个单一的位掩码去实现。另一个例子是匹配; 如果OpenFlow交换机使用用不同数量 的硬件表物理实现，那么流水线就会被暴露出来。 3 名词解释 本节介绍了关键OpenFlow的规范条款： ?字节：一个8位字节。 ?数据包：以太网帧，包括报头和有效载荷。 ?端口：数据包进入和退出OpenFlow的流水线地方（见4.1）。可以是一个物理端口，由 交换机定义一个逻辑端口，或由OpenFlow的协议定义一个保留端口。 ?流水线：在一个openflow交换机中提供匹配、转发和数据包修改功能的流表连接集合。 ?流表：流水线的一个阶段，包含若干流表项。 ?流表项：在流表中用于匹配和处理数据包的一个元素。它包含用于匹配数据包的匹配字段、匹配次序的优先级，跟踪数据包的计数器，以及对应的的指令集。 ?匹配字段：用来匹配数据包的字段，包括包头，进入端口，元数据值。匹配字段可能会 进行通配符匹配（匹配任何值）或者在某些情况下通过位掩码进行匹配。 ?元数据：一个可屏蔽寄存器的值，用于携带信息从一个表到下一个。 ?指令：指令存在于流表项中，描述报文匹配流表项时OpenFlow的处理方式。指令可以修 改流水线处理，如指导包匹配另一个流表，也可以包含一系列添加到行动集的行动，还可
╳╳系统 源码授权使用保密协议 甲方: 珠海市联进高技术有限公司 乙方: 签订地点： 一、协议背景 ╳╳系统是珠海市联进高技术有限公司(以下简称甲方)为╳╳(以下简称乙方)承建的。兹双方确认甲方拥有╳╳系统全部源代码的版权，为了便于乙方更好的进行系统维护工作，并考虑到今后的业务需求变更后，对业务系统可能提出的修改要求，甲方把与业务系统相关的源代码授权乙方使用，同时双方达成以下协议。协议条款标的内容： 甲方提供给乙方的源代码，是现行╳╳系统的应用程序部分。甲方保证所提供的部分源代码与系统当前正在运行的前台程序是同一版本，利用所提供的源代码及相关资源可以直接编译生成当前系统的应用程序部分。 二、用途限定 甲方授权乙方使用源代码的方式仅限于对现行系统的程序改进之用途;乙方有义务对源代码进行保密，在任何情况下，未经甲方同意，乙方不得将此源代码提供给任何第三方。乙方并应限制有关源代码的具体使用范围，使之仅限于现行系统的维护/升级等系统开发用途，仅为直接开发人员所了解和使用，不应在同行业其他项目使用，不得用于其他用途。 三、知识产权归属 甲方拥有╳╳系统全部源代码的版权。 乙方可以对源代码进行改变，由此衍生的有关程序及源代码的知识产权由双方共同拥有。未经甲方许可，乙方不得将修改后的源代码提供给任何第三方。甲方原则上没有义务向乙方提供对源代码及其相关资讯的技术支持和培训，但双方另有协议除外。 对于由乙方使用修改后程序所引起的故障和损失，根据是初始程序内BUG 引起的还是由于乙方的不当修改造成，分清责任，并视责任情况承担各自的责任。对于假若不修改程序就不会出现的故障，甲方不承担责任。在乙方使用有关源代
源代码授权使用保密协议 甲方: 普宁华侨医院 乙方: 根据我国《计算机软件保护条例》规定，计算机软件是指计算机程序及其有关文档，计算机程序包括源程序(source code)和目标程序。而源程序（又称源代码）是由一组数据所编写的一个程序，源代码(非自由软件)属于享有著作权的作品。 ××系统软件是××××××公司(以下简称乙方)为普宁华侨医院(以下简称甲方)承建安装（或升级改造）项目。 乙方应合法获得××系统软件著作权人许可甲方使用××系统软件源代码使用权、复制权、修改权，一切非法和侵权的责任均由乙方承担，与甲方无关。 为了便于甲方更好的进行该系统软件维护工作，并考虑到今后的业务需求变更后，对该业务系统软件可能提出的修改、升级等要求，乙方把与该业务系统软件相关的源代码授权甲方使用、复制、修改，双方达成以下协议： 一、对软件源代码的相关约定 1、甲方向乙方购买××系统软件应用程序的使用权，乙方同时授权甲方使用、复制、修改××系统的软件源代码，该××系统的软件源代码的使用权、复制权、修改权应属甲方收权所有，乙方须无条件如实提供。 2、乙方授权提供给甲方的源代码，是现行××系统的软件应用程序部分, 乙方保证所提供的该业务系统软件源代码与该系统当前
正在运行的软件程序是同一版本，利用所提供的源代码及相关资源可以直接编译生成当前系统的软件应用程序部分。 3、甲方于后续的信息系统建设与完善的过程中，如乙方按本协议要求，合法、如实的提供给甲方已购买相关系统软件源代码使用权、复制权、修改权，那么在相近或同等条件下，甲方后续信息系统建设可优先考虑乙方。｛或乙方可享有参与甲方后续信息系统建设的优先权。注：享有优先权的说法对一家公司适应，二家以上可能不利于甲方，建议修改｝ 4、于××系统的软件应用程序的质保期内、外或有偿服务期间，应用授权给甲方的源代码对甲方的相关系统进行修改、维护、升级、程序的二次开发等，每次的修改、维护、升级、程序的二次开发等所衍生的相关程序及源代码（包括与衍生源代码一起提供给甲方的附属文档、数据资料和其他程序），乙方应无损、如实备份给甲方，甲乙双方须书面确认，作为甲方合法拥有（使用）的法律依据。 5、合同或协议款项的支付：甲方对所购买的有关信息网络系统或信息网络系统集成升级改造等项目，须于项目完成验收并收到（授权）校验无误的该项目系统软件源代码才支付该合同或协议款项，质保金仍按该合同或协议条款执行。 二、用途及保密约定 乙方授权甲方使用源代码的方式仅限于对甲方现行系统的程序进行修改、维护、升级、程序的二次开发等之用途, 甲方有义务对源代码进行保密，在任何情况下，未经乙方同意，甲方不得将此初始源代码和所衍生的相关程序、源代码提供给任何第三方；甲方应限制有
OpenFlow通信流程解读 前言 接触了这么久的SDN，OpenFlow协议前前后后也读过好多遍，但是一直没有时间总结一下自己的一些见解。现在有时间了，就写一写自己对OpenFlow协议通信流程的一些理解。SDN中Switch和controller 在SDN中很重要的两个实体是Switch跟Controller。Controller在网络中相当于上帝，可以知道网络中所有的消息，可以给交换机下发指令。Switch就是一个实现Controller指令的实体，只不过这个交换机跟传统的交换机不一样，他的转发规则由流表指定，而流表由控制器发送。 switch组成与传统交换机的差异 switch组成 switch由一个Secure Channel和一个flow table组成，of1.3之后table变成多级流表，有256级。而of1.0中table只在table0中。 ?Secure Channel是与控制器通信的模块，switch和controller之间的连接时通过socket 连接实现。 ?Flow table里面存放这数据的转发规则，是switch的交换转发模块。数据进入switch 之后，在table中寻找对应的flow进行匹配，并执行相应的action，若无匹配的flow 则产生packet_in（后面有讲） of中sw与传统交换机的差异 ?匹配层次高达4层，可以匹配到端口，而传统交换机只是2层的设备。 ?运行of协议，实现许多路由器的功能，比如组播。 ?求补充！！（如果你知道，请告诉我，非常感谢！） OpenFlow的switch可以从以下方式获得 ?实体of交换机，目前市场上有一些厂商已经制造出of交换机，但是普遍反映价格较贵！性能最好。 ?在实体机上安装OVS，OVS可以使计算机变成一个OpenFlow交换机。性能相对稳定。 ?使用mininet模拟环境。可以搭建许多交换机，任意拓扑，搭建拓扑具体教程本博客有一篇。性能依赖虚拟机的性能。 controller组成 控制器有许多种，不同的语言，如python写的pox,ryu，如java写的floodlight等等。从功能层面controller分为以下几个模块： ?底层通信模块：OpenFlow中目前controller与switch之间使用的是socket连接，所以控制器底层的通信是socket。 ?OpenFlow协议。socket收到的数据的处理规则需按照OpenFlow协议去处理。 ?上层应用：根据OpenFlow协议处理后的数据，开发上层应用，比如pox中就l2_learning,l3_learning等应用。更多的应用需要用户自己去开发。 OpenFlow通信流程 以下教程环境为：mininet+自编简单控制器+scapy封装 建立连接 首先启动mininet，mininet会自行启动一个default拓扑，你也可以自己建立你的拓扑。sw 建立完成之后，会像controllerIP:controllerport发送数据。 controller启动之后，监听指定端口，默认6633，但是好像以后的都改了，因为该端口被其他协议占用。
软件源码授权员工保密协议新编完整版 In the case of disputes between the two parties, the legitimate rights and interests of the partners should be protected. In the process of performing the contract, disputes should be submitted to arbitration. This paper is the main basis for restoring the cooperation scene. 【适用合作签约/约束责任/违约追究/维护权益等场景】 甲方：________________________ 乙方：________________________ 签订时间：________________________ 签订地点：________________________
软件源码授权员工保密协议新编完 整版 下载说明：本协议资料适合用于需解决双方争议的场景下，维护合作方各自的合法权益，并在履行合同的过程中，双方当事人一旦发生争议，将争议提交仲裁或者诉讼，本文书即成为复原合作场景的主要依据。可直接应用日常文档制作，也可以根据实际需要对其进行修改。 甲方： 法定代表人： 联系电话： 乙方： 性别： 身份证件号码： 户籍地址： 通讯地址： 联系方式： 鉴于甲方在乙方任职，并获得乙方
支付的相应报酬，双方当事人就甲方在任职期间及离职以后保守乙方商业秘密的有关事项，订定下列条款共同遵守：第一条秘密信息 1、双方确认，甲方在乙方任职期间，因履行职务或者主要是利用乙方的物质技术条件、业务信息等产生的发明创造、技术秘密或其它商业秘密，有关的知识产权均属于乙方享有。乙方可以在其业务范围内充分自由地利用这些发明创造、技术秘密或其它商业秘密，进行生产、经营或者向第三方转让。甲方应当依乙方的要求，提供一切必要的信息和采取一切必要的行动，包括申请、
Openflow协议通信流程解读 前言 接触了这么久的SDN，Openflow协议前前后后也读过好多遍，但是一直没有时间总结一下自己的一些见解。现在有时间了，就写一写自己对Openflow协议通信流程的一些理解。 SDN中Switch和controller 在SDN中很重要的两个实体是Switch跟Controller。Controller在网络中相当于上帝，可以知道网络中所有的消息，可以给交换机下发指令。Switch就是一个实现Controller 指令的实体，只不过这个交换机跟传统的交换机不一样，他的转发规则由流表指定，而流表由控制器发送。
switch组成与传统交换机的差异 switch组成 switch由一个Secure Channel和一个flow table组成，of1.3之后table变成多级流表，有256级。而of1.0中table只在table0中。 ?Secure Channel是与控制器通信的模块，switch和controller之间的连接时通过socket连接实现。 ?Flow table里面存放这数据的转发规则，是switch的交换转发模块。数据进入switch之后，在table中寻找对应的flow进行匹配，并执行相应的action，若无匹配的flow则产生packet_in（后面有讲） of中sw与传统交换机的差异 ?匹配层次高达4层，可以匹配到端口，而传统交换机只是2层的设备。 ?运行of协议，实现许多路由器的功能，比如组播。 ?求补充！！（如果你知道，请告诉我，非常感谢！） openflow的switch可以从以下方式获得 ?实体of交换机，目前市场上有一些厂商已经制造出of交换机，但是普遍反映价格较贵！性能最好。 ?在实体机上安装OVS，OVS可以使计算机变成一个openflow交换机。性能相对稳定。
openflow openflow协议
openflow协议 ?of 协议支持三种消息类型：controller-to-switch，asynchronous（异步）和symmetric（对称），每一类消息又有多个子消息类型。 ?controller-to-switch 消息由控制器发起，用来管理或获取switch 状态；?asynchronous 消息由switch 发起，用来将网络事件或交换机状态变化更新到控制器；?symmetric 消息可由交换机或控制器发起。
controller-to-switch ?Features ?在建立传输层安全会话（Transport Layer Security Session）的时候，控制器发送feature请求消息给交换机，交换机需要应答自身支持的功能。 ?Configuration ?控制器设置或查询交换机上的配置信息。交换机仅需要应答查询消息。?Modify-state ?控制器管理交换机流表项和端口状态等。 ?Read-state ?控制器向交换机请求一些诸如流、网包等统计信息。 ?Send-packet ?控制器通过交换机指定端口发出网包。 ?Barrier ?控制器确保消息依赖满足，或接收完成操作的通知
asynchronous ?Packet-in ?交换机收到一个网包，在流表中没有匹配项，则发送Packet-in 消息给控制器。如果交换机缓存足够多，网包被临时放在缓存中，网包的部分内容（默认128 字节）和在交换机缓存中的的序号也一同发给控制器；如果交换机缓存不足以存储网包，则将整个网包作为消息的附带内容发给控制器。 ?Flow-removed ?交换机中的流表项因为超时或修改等原因被删除掉，会触发Flow-removed 消息。 ?Port-status ?交换机端口状态发生变化时（例如down 掉），触发Port-status 消息。
源代码保密协议 鉴于甲乙双方已签订编号为：的协议（以下简称“主协议”），乙方授权甲方使用乙方相关产品源代码。 本保密协议由（简称“甲方”）与 xx软件有限公司（简称“乙方”）于年月日签订。 一、保密信息定义： 本协议“保密信息”指，不论在本保密协议签署日之前或在此之后，乙方的任何以下信息（不论以口头、书面或电子形式或以其他方式）： 1.1乙方相关产品源代码。 1.2乙方相关产品源代码有关的附属文档、数据资料和其他程序。 但是“保密信息”不包括以下范围内的文件、信息、数据或专有技术： 1.1在披露时为甲方所公开知晓的信息。 1.2能够证明甲方或其雇员或其专业顾问在非保密的基础上从第三方合法获得的信息，且据甲方所知，第三方提供该等信息并不违反该第三方对乙方所承担的保密义务。 二、守约义务： 甲方保证： 2.1仅为主协议、本协议之目的使用保密信息。 2.2不得将保密信息投入以盈利为目的市场销售或贩卖等商业活动或交付第三方用于商业用途。 2.3对保密信息或保密信息衍生的信息，未经乙方事先书面许可，甲方不得向任何第三方包括但不限于甲方的关联企业， 或允许向任何第三方包括但不限于甲方的关联企业直接或间接地透露保密信息或保密信息衍生的信息。“关联企业”应包括下列任何公司： 2.3.1由甲方直接或间接拥有或控制的公司，或者 2.3.2直接或间接拥有或控制甲方的公司，或者与甲方共同被其他方直接或间接拥有或控制的公司。 2.3.3所有权或控制将通过下列方式存在：直接或间接的拥有一家公司超过50 %的股份，或者直接或间接的不论以何种 方式有权选举一家公司的多数董事或履行类似职责的人。 2.4对保密信息保密，并采取所有必要的预防措施（包括但不限于甲方采取的用于保护自身保密信息的措施）防止未经授权地使用及透露保密信息。 2.5参与主协议业务的甲方员工从此协议约定项目转向与乙方直接竞争的项目，则甲方应确保立即终止该员工获得乙方保密信息和信息源的途径，并要求该员工签署保密协议。 三、保密信息的管理： 仅可向为评估、结构设计或谈判项目目的而需要知晓该等信息的甲方雇员、关联公司和/或专业咨询人员披露甲方收到的 来自乙方的保密信息。 四、本协议内容的保密： 4.1关于保密信息以及本保密协议的任何公开陈述应由甲乙双方协议一致后做岀。 4.2除非乙方事先书面同意，甲方不得向任何第三方或者公众披露已获得保密信息以及项目正在进行谈判与磋商的事实。 五、损害赔偿： 5.1甲方应承担违反本保密协议义务所产生的责任。就任何未经授权而使用或披露保密信息而产生的损害、损失、成本或责任，甲方应对乙方进行补偿并使其免受损害。 5.2如甲方违反本合同所描述之相关约定，乙方将保留追究甲方法律责任的权力，如甲方违反本保密协议第2条约定的
合同编号：_________
软件源码授权员工保密协议
甲方：_________________________ 乙方：_________________________ 签订日期：______年_____月_____日
第1页共7页
甲方：
软件源码授权员工保密协议
法定代表人：
联系电话：
乙方：
性别：
身份证件号码：
户籍地址：
通讯地址：
联系方式：
鉴于甲方在乙方任职，并获得乙方支付的相应报酬，双方当事人就 甲方在任职期间及离职以后保守乙方商业秘密的有关事项，订定下列条 款共同遵守：
风险提示： 用人单位有权采取措施保护商业秘密，但在订立 保密协议时应注意不能侵犯劳动者的合法权利——劳动者有择业 的自由，但在行使权利时同样不得损害用人单位的商业秘密。保密 协议跟其它协议一样，首先必须遵循公平、平等原则，才具有法律 效力，否则该协议无效。
第2页共7页
第一条秘密信息
1、双方确认，甲方在乙方任职期间，因履行职务或者主要是利用 乙方的物质技术条件、业务信息等产生的发明创造、技术秘密或其它商 业秘密，有关的知识产权均属于乙方享有。乙方可以在其业务范围内充 分自由地利用这些发明创造、技术秘密或其它商业秘密，进行生产、经 营或者向第三方转让。甲方应当依乙方的要求，提供一切必要的信息和 采取一切必要的行动，包括申请、注册、登记等，协助乙方取得和行使 有关的知识产权。
2、甲方在乙方任职期间所完成的、与乙方业务相关的发明创造、 技术秘密或其它商业秘密，甲方主张由其本人享有知识产权的，应当及 时向乙方申明。经乙方核实，认为确属于非职务成果的，由甲方享有知 识产权，乙方不得在未经甲方明确授权的前提下利用这些成果进行生 产、经营，亦不得自行向第三方转让。
第二条 对秘密信息的保密
1、甲方在乙方任职期间，必须遵守乙方规定的任何成文或不成文 的保密规章、制度，履行与其工作岗位相应的保密职责。
2、乙方的保密规章、制度没有规定或者规定不明确之处，甲方亦 应本着谨慎、诚实的态度，采取任何必要、合理的措施，维护其于任职 期间知悉或者持有的任何属于乙方或者虽属于第三方但乙方承诺有保 密义务的技术秘密或其它商业秘密信息，以保持其机密性。
3、乙方保证除非为了甲方项目的工作需要交流此种秘密信息外，
第3页共7页
Openflow协议通信流程解读 分类：openflow协议分析 2013-12-30 19:01887人阅读评论(1)收藏举报 目录(?)[-] 1前言 2SDN中Switch和controller 2switch组成与传统交换机的差异 2switch组成 2of中sw与传统交换机的差异 2openflow的switch可以从以下方式获得 2controller组成 3Openflow通信流程 3建立连接 3OFPT_HELLO 3OFPT_ERROR 3OFPT_ECHO 3OFPT_FEATURES 3OFPT_FEATURES_REQUEST 3OFPT_FEATURES_REPLY 3OFPT_PACKET_IN 3OFPT_PACKET_OUT 3OFPT_FLOW_MOD 3OFP_HEADER 3WILDCARDS 3MATCH
3FLOW_MOD 3command里面的类型决定了flow_mod的操作是添加 修改还是删除等类型如下 3两个时间参数idle_timeout idle_timeout 3priority 3buffer_id 3out_port 3flags 3ACTION 3OFPT_BARRIER_REQUEST REPLY 3OFPT_FLOW_REMOVED 3OFPT_STATS_REQUEST REPLY 3OFPT_STATS_REQUEST 3OFPT_STATS_REPLY 4后续 4ERROR 4Type 4Code 前言 接触了这么久的SDN，Openflow协议前前后后也读过好多遍，但是一直没有时间总结一下自己的一些见解。现在有时间了，就写一写自己对Openflow协议通信流程的一些理解。 SDN中Switch和controller 在SDN中很重要的两个实体是Switch跟Controller。Controller在网络中相当
保密协议 甲方： 乙方： 鉴于： 甲乙双方在履行《xxx》项目开发过程中，甲方将向乙方披露其保密信息（包括甲方部数据），以及双方在合作过程中乙方已经或者将要知悉甲方的保密信息，为明确甲乙双方的保密义务，保护甲方的商业秘密不受侵犯，经协商一致，达成如下协议： 第一条保密信息的围 1、保密信息是指由甲方通过文字、电子或数字方式或媒介向乙方提供的，在提供时明确标记有“保密”的，以及虽未标记为“保密”但属于甲方的生产经营数据、报表、图幅、报告及技术信息。口头传达并在传达同时认定为属于保密的信息应当视为保密信息。甲方相关的业务和技术方面有保密要求的资料信息。 保密信息还包括本项目研发中形成的双方共有技术、产权、软件成果、研究思路。保密信息包括但不限于： （1）数据库所有的数据； （2）客户或潜在客户的身份及其他相关信息、客户联系方式和客户销售策略等； （3）市场研究结果，市场渗透资料，及其他市场信息； （4）销售和市场计划、规划及策略； （5）销售额、成本和其他财务数据；
（6）经营秘密、技术秘密、设计及专有的经营和技术信息，与本协议所涉及产品及其程序设计、源码等有关的方法、经验、程序、步骤； （7）产品、零件及服务的供应源； （8）任何其他秘密工艺、配方或方法； （9）本项目研发形成的双方共有技术、产权、软件成果、研究思路在成果申报之前。 2、保密信息不包括以下信息： （1）甲方已经公布于众的资料，但不包括甲乙双方或其代表违反本协议规定未经授权所披露的； （2）乙方已经独立开发的及未曾违反任何法律、法规或甲方的任何权利的信息，并且该等信息是在乙方依照本协议条款从甲方获悉该等信息之前独立开发的； （3）乙方在依照本协议条款从甲方获悉之前已经占有的信息，并且就乙方所知乙方并不需要对该等信息承担任何具有约束力的保密义务； （4）在双方签订本协议以后并非由于乙方的过错而被公众所知的信息； （5）乙方在未违反其对甲方承担的任何义务的情况下从第三方获得的信息。 第二条保密信息的使用 1、乙方应使所有保密信息得到最严格的保密，并且除为促进软件新产品发展，或本协议允许的用途外，不得使用该等保密信息。
OpenFlow交换机规范(概要) Version1.3.0（June25,2012） 1介绍 本文档描述了对OpenFlow交换机的要求。此规范内容包括交换机的组件和基本功能，和一个远程控制器管理一个OpenFlow交换机的协议：OpenFlow。 2交换机部件 OpenFlow的交换机包括一个或多个流表和一个组表，执行分组查找和转发，和到一个外部控制器OpenFlow的信道（图1）。该交换机与控制器进行通信，控制器通过OpenFlow协议来管理交换机。 控制器使用OpenFlow协议，可以添加、更新和删除流流表中的表项，主动或者被动响应数据包。在交换机中的每个流表中包含的一组流表项;每个流表项包含匹配字段，计数器和一组指令，用来匹配数据包（见5.2）。 匹配从第一个流表开始，并可能会继续匹配其它流表(见5.1）。流表项匹配数据包是按照优先级的顺序，从每个表的第一个匹配项开始（见5.3）。如果找到一个匹配项，那么与流表项相关的指令就会去执行。如果在流表中未找到匹配项，结果取决于漏表的流表项配置：（例如，数据包可能通过OpenFlow信道被转发到控制器、丢弃、或者可以继续到下一个的流表，见5.4）。 与流表项相关联的指令包含行动或修改流水线处理（见5.9）。行动指令描述了数据包转发，数据包的修改和组表处理。流水线处理指令允许数据包被发送到后面的表进行进一步的处理，并允许信息以元数据的形式在表之间进行通信。当与一个匹配的流表项相关联的指令集没有指向下一个表的时候，表流水线停止处理，这时该数据包通常会被修改和转发（见5.10）。 流表项可能把数据包转发到某个端口。这通常是一个物理端口，但它也可能是由交换机定义的一个逻辑端口或通过本规范中定义的一个保留的端口（见4.1）。保留端口可以指定通用的转发行为，如发送到控制器、泛洪、或使用非OpenFlow的方法转发，如“普通”交换机转发处理（见4.5）；而交换机定义的逻辑端口，可以是指定的链路汇聚组、隧道或环回接口（见4.4）。 与流表项相关的行动，也可直接把数据包发送到组，进行额外的处理（见5.6）。组表示一组泛洪的指令集，以及更复杂的转发（如多路径，快速重路由，链路聚合）。作为间接的通用层，组也使多个流表项转发到同一个标识者（例如IP转发到一个共同的下一跳）。这种抽象的行为使相同的输出行动非常有效。 组表包含若干组表项，每个组表项包含一系列依赖于组类型的特定含义行动存储段（见
知识产权保密协议书范文 甲方： 法定代表人： 电话： 地址： 乙方：性别： 身份证号码：邮箱： 固定电话：移动电话： 身份证住址： 在京居住地址： 鉴于甲方同意聘用乙方在甲方工作，同时乙方愿意受聘; 鉴于乙方对公司应承担的责任; 鉴于乙方在受聘工作期间，将在其职务工作中做出一些研究及开发结果，并将因业务需要接触到甲方拥有的各项研究、开发结果以及有关技术、市场等方面的各种商业秘密，这些研究、开发结果以及有关的商业秘密都是属于甲方的财产，对于甲方具有一定的商业价值。 为了维护甲方的商业利益，并明确乙方作为甲方员工所负有的保密义务，甲、乙双方在遵循诚实、信用、平等、自愿的原则上，就乙方在任职期间及离职以后保守甲方商业信息秘密的有关事项，经协商一致，达成如下协议。 第一条定义 (一) 职务开发结果 所谓职务开发结果是指乙方在受聘甲方期间，为履行自己的职务所完成的或者所构想的所有研究及开发结果，包括(但不限于) 1、产品设计、工模具设计、制造方法、工艺流程、材料配方、经验公式、实验数据; 2、项目方案、项目建议书、需求说明、设计文档、计算机软件及其算法、设计、程序源码、目标码、运行程序、用户手册; 3、商标设计、标志设计等;以及虽不属于自己职务范围但属于甲方业务范围的所有上述研究、开发结果，以及对甲方现有研究及开发结果的改造; 4、"乙方利用甲方的设备、资源和有关工作条件进行的创作、研究、开发成果"亦归属甲方。
(二) 商业秘密 所谓商业秘密是指由甲方提供的，或者乙方在甲方内了解到的，或者乙方为履行自己的职务而开发出来的，与甲方业务有关的，具有商业价值的，非公知的所有信息。包括(但不限于)以下这些类型： 1、关于甲方现有的、以及正在开发或者构思之中的产品设计、客户资源、项目方案、项目建议书、需求说明、设计文档、程序源码、目标码、运行程序、用户手册、工具模具、制造方法、工艺过程、材料配方、经验公式、实验数据、设计等方面的信息、资料、图纸、模型及样品等; 2、甲方现有的以及正在开发或者构想之中的服务项目的信息和资料; 3、甲方现有的或者正在开发之中的质量管理方法、定价方法、销售方法等业务活动方法; 4、甲方的业务计划、产品开发计划、财务情况、内部业务规程以及供应商、经销商和客户的名单等业务活动的信息; 5、甲方的各种管理规章、制度及经营管理的各种文档、资料及计算机中存储的有关信息; 6、甲方企业内部网上的所有应用系统的个人id文件、帐号名及口令; 7、按照法律和协议，甲方对第三方负有保密责任的第三方的商业秘密。 第二条职务开发结果的权利归属 (一)乙方同意，自己作出的所有职务开发结果应立即按甲方所要求的形式首先向甲方报告。 (二)乙方认可，任何职务开发结果的所有知识产权归属甲方，包括(但不限于) 1、任何发明、实用新型或外观设计的专利权和专利申请权; 2、设计图纸、计算机软件、商标设计和标志设计的著作权; 3、对商业秘密的权利，对商品名称和商标的专用权等。 4、本协议第一条第(一)款及第(二)款项下所列明的各项权利。 (三)乙方同意按照甲方的要求采取甲方认为取得和保持上述职务开发结果知识产权所需的一切法律行为，包括申请、注册、登记等;并同意按照甲方的要求出具必要的文件，采取必要的措施以确认甲方的上述职务开发结果的知识产权归属甲方。 (四)乙方同意在未获甲方事先书面同意时，决不把有关上述职务开发结果的信息向任何第三方透露。
业务合作保密协议 协议编号： 甲方: 地址： 电话： 乙方: 地址： 电话： 甲乙双方拟针对项目在商业、技术领域开展合作，鉴于双方在合作过程中涉及有关各自产品以及生产的信息交接，现经双方友好协商，就有关合作期间的保密事宜达成以下协议。 第一条机密信息的定义。在本协议中，“机密信息”系指： １、与本协议任何当事方之业务及其现有、未来和拟开发之产品和服务有关的一切技术类和非技术类信息，包括但不限于协议双方各自有关研发的信息、设计详情和规范、财务信息、采购要求、工程和生产信息、客户清单、商业前景预测、销售信息和营销方案； ２、本协议任何一方可能在本协议下提供的任何源代码、固件或其它可机读或人工读取的软件代码，以及其中包含的商业机密； ３、协议一方已经从其他方处获得且该方有义务保密的信息； 第二条仅在符合以下规定时，协议一方（以下称为“披露方”）披露的此等信息方可被对方（以下称为“接收方”）视为披露方的机密信息： １、该信息是以有形或书面形式（例如纸张、磁盘或电子邮件）提供的，且显著标记有“机密”标识（或其它类似文字标志）； ２、在披露之时，被与披露方从事相同行业且业务类似的理性自然人视为机密信息的信息。 第三条保密义务。
１、接收方不得使用、复制、摘取、反译、散播或以任何方式向任何人、企业或公司披露方的机密信息，除非是为了用于与披露方进行谈判、讨论和磋商而必需的内部评估（以下称为“用途”）。 ２、机密信息不得下载到或用于接收方的设备中，除非该行为是“用途”所不可或缺的，此时必需事先得到披露方的明确书面同意和许可。接收方不得将机密信息用于创造“衍生作品”，也不得将机密信息发布到公共网络上。 ３、此外，未经对方事先书面批准，任何一方均不得将双方之间正在进行的任何谈判、商讨或磋商的存在披露给任何形式的公共媒体。接收方应对披露方的所有机密信息予以严格保密对待，谨慎程度应当与接收方对自己的机密信息所持的谨慎程度相同，但在任何情况下接收方所给予的谨慎程度均不得低于合理水平。 ４、接收方仅可将披露方的机密信息向确有必要知晓此等信息的接收方员工、顾问和承包商进行披露。接收方特此声明，每位此等员工、顾问和承包商均已同意受限于一定保密条款和条件（无论是作为雇佣的前提条件还是为了获取披露方的机密信息），且此等条款和条件的严格程度不低于接收方在本协议下应遵守的适用条款和条件之严格程度。如得知任何对披露方之机密信息的非授权使用或披露，接收方应立即通知披露方。接收方应协助披露方纠正此等对披露方之机密信息的非授权使用或擅自披露行为。 第四条保密义务的免责情形。 １、接收方在本协议第三条下的义务不适用于能够被接收方以书面证据证明属于以下情况的披露方机密信息： （a）在披露方将机密信息告知给接收方之时或此后，已经进入（且并非是因接收方的过失而导致进入）公知领域的信息； （b）在披露方将机密信息告知给接收方之时或此后，已经由接收方合法持有且无任何保密义务的信息； （c）由接收方的员工或代理人在不参考任何披露方机密信息的前提下独立开发出来的信息； （d）由披露方告知给非关联第三方且该第三方无任何保密义务的信息。 接收方对任何披露方机密信息的披露，如果是（１）应法庭或其他政府机构的有效命令而做出的；（２）是法律要求做出的；或（３）是行使本协议下任何协议方之权利所必要的，则该披露不应被视为接收方对本协议的违约；但在此等情况中，接收方应事先向披露方给予及时的书面通知，以使披露方能够寻求保护令或其它阻止此等披露的方法。 第五条机密信息和其它材料的所有权和退还。 １、所有披露方的机密信息及其“衍生作品”，无论是由该披露方还是接收方创造的，均属于披露方的财产，披露方未向接收方授予或暗示给予关于此等机密信息或衍生作品的任何许可或其它权利。
OpenFlow Switch Speci?cation Version0.8.9(Wire Protocol0x97) December2,2008 Current Maintainer:Brandon Heller(brandonh@https://www.doczj.com/doc/5f2391167.html,) 1Introduction This document describes the requirements of an OpenFlow Switch.We rec-ommend that you read the latest version of the OpenFlow whitepaper before reading this speci?cation.The whitepaper is available on the OpenFlow Con-sortium website(https://www.doczj.com/doc/5f2391167.html,).This speci?cation covers the components and the basic functions of the switch,and the OpenFlow protocol to manage an OpenFlow switch from a remote controller. OpenFlow Switches will be of“Type0”or“Type1”,depending on their ca-pabilities.Type0represents the minimum requirements for any conforming OpenFlow Switch.Type1requirements will be a superset of Type0,and re-main to be de?ned.It is expected that commercial OpenFlow Switches will initially be of Type0,evolving to Type1;and that vendors will support addi-tional features over time.However,all switches are expected to use the same OpenFlow Protocol for communication between switch and controller.For the remainder of this version of the document,unless otherwise speci?ed,all refer-ences to an OpenFlow Switch refer to Type0. Version1.0of this document will be the?rst to specify a Type0switch suit-able for implementation.Versions before Version1.0will be marked“Draft”, and will include the header:“Do not build a switch from this speci?cation!”We hope to generate feedback from versions prior to Version1.0from switch designers and network researchers. 2Switch Components An OpenFlow Switch consists of a?ow table,which performs packet lookup and forwarding,and a secure channel to an external controller(Figure1).The con-troller manages the switch over the secure channel using the OpenFlow protocol. 1