下载文档原格式
支持完整OF13协议的mininet平台搭建by mingming 早就在网上看到说mininet已支持OF13的mininet镜像，但是抓包发现连接建立根本就是按照OF10协议，后来终于在网上找到证据：现在openvswitch已有2.3.0版本，但是没有是用这个版本的openvswitch的mininet镜像，所以自己下载mininet和openvswitch 的源码搭建环境，终于搭建成功并且可以连接控制器，但是又发现没有链路，抓包发现只有控制器发的packet-out，没有交换机返回的packet-in，几经波折尝试各种方法重新搭建mininet，最后偶然发现是ODL的问题，下了最新版本的ODL就可以显示拓扑并且有packet-in包，在这期间成功搭建两种支持完整OF13的mininet：openvswitch版本和ofsoftswitch版本。
连接成功如下截图：下面我们就来搭建支持完整OF13协议的mininet参考：https:///view/Openflow_Protocol_Librar y:OpenVirtualSwitchhttps:///view/Openflow_Protocol_Librar y:OpenVirtualSwitch一、 Openvswitch2.3.0版本mininet1.下载openvswitch2.3.0(/releases/openvswitch-2.3.0.tar.gz) 解压：tar zxvf openvswitch*****2.依照~/openvswitch-2.3.0/INSTALL.Debian来建立Library (1)安装build-essential和fakerootsudo apt-get install build-essential fakeroot(2)进入到顶层目录(3)检查一下依赖有没有安装全sudo dpkg-checkbuilddeps 如果安装完全会什么都不打印出来，如没有安装全会提示unmet **** *** *** ,执行命令sudo apt-get install ******注：有可能会出现sudo apt-get install ***报错404，解决办法：sudo apt-get update（4）运行sudo fakeroot debian/rules binary注：可能会出现的错误dpkg-shlibdeps: error: no dependency information found for /usr/local*****，解决办法：sudo dpkg-buildpackage -rfakeroot -d -Bexport DEB_DH_MAKESHLIBS_ARG=--ignore-missing-info 具体参见：/questions/11238134/dpkg-shlibdeps-error-no-dependency-information-found-for（5）会产生如下包-rw-r--r-- 1 root root 831816 Oct 7 20:08 openvswitch-common_2.3.0-1_i386.deb-rw-r--r-- 1 root root 3230392 Oct 7 20:08 openvswitch-datapath-dkms_2.3.0-1_all.deb-rw-r--r-- 1 root root 3304788 Oct 7 20:08 openvswitch-datapath-source_2.3.0-1_all.deb-rw-r--r-- 1 root root 7641926 Oct 7 20:08 openvswitch-dbg_2.3.0-1_i386.deb-rw-r--r-- 1 root root 38656 Oct 7 20:08 openvswitch-ipsec_2.3.0-1_i386.deb-rw-r--r-- 1 root root 31710 Oct 7 20:08 openvswitch-pki_2.3.0-1_all.deb-rw-r--r-- 1 root root 2175596 Oct 7 20:08 openvswitch-switch_2.3.0-1_i386.deb-rw-r--r-- 1 root root 47578 Oct 7 20:08 openvswitch-test_2.3.0-1_all.deb-rw-r--r-- 1 root root 217712 Oct 7 20:08 openvswitch-vtep_2.3.0-1_i386.deb-rw-r--r-- 1 root root 90926 Oct 7 20:08 python-openvswitch_2.3.0-1_all.deb3.安装.deb包（1）安装Open vSwitch kernel module.参看debian/openvswitch-switch.README.Debian，给了四种方法，我们采用了第三种，可进一步参看/usr/share/doc/openvswitch-datapath-source/README.Debian，其中又给了三种方法，我们采用第一种：sudo module-assistant auto-install openvswitch-datapath 或者sudo m-a a-i openvswitch-datapath,注：可能会出现木有module-assistant这一命令，sudo apt-get install module-assistant（2）安装openvswitch-Switch和openvswitch-common包dpkg -i openvswitch-common_2.3.0-1_i386.debdpkg -i openvswitch-switch_2.3.0-1_i386.deb4.核实下是否安装成功sudo ovs-vsctl show若成功会显示类似如下bd38d7bd-7419-40d1-b80e-b48cf773c960ovs_version: "2.3.0"否则就没有安装成功，检查之前的步骤5.安装mininet 2.1.0（1）Install mininet:odluser@odl-vm:~\$ git clonegit:///mininet/mininetodluser@odl-vm:~\$ cd mininet/odluser@odl-vm:~\$ git checkout -b 2.1.0p1 2.1.0p1 odluser@odl-vm:~\$ # apply patch (patch -p0 < newOptions.patch)odluser@odl-vm:~\$ cd ./utilodluser@odl-vm:~\$ ./install.sh -fn（2）修改源码cd mininet/mininetvim node.pyWhere the patch to apply newOptions.patch is:--- mininet/node.py 2014-09-12 13:48:03.165628683 +0100+++ mininet/node.py 2014-09-12 13:50:39.021630236 +0100 @@ -952,6 +952,10 @@datapath: userspace or kernel mode (kernel|user)"""Switch.__init__( self, name, **params )self.failMode = failMode+ protKey = 'protocols'+ if self.params and protKey in self.params:+ print 'have protcol params!'+ self.opts += protKey + '=' +self.params[protKey]self.datapath = datapath@classmethod@@ -1027,8 +1031,9 @@if self.datapath == 'user':self.cmd( 'ovs-vsctl set bridge',self,'datapath_type=netdev' )int( self.dpid, 16 ) # DPID must be a hex string + print 'OVSswitch opts: ',self.optsself.cmd( 'ovs-vsctl -- set Bridge', self,- 'other_config:datapath-id=' + self.dpid )+ self.opts+'other_config:datapath-id=' + self.dpid )self.cmd( 'ovs-vsctl set-fail-mode', self, self.failMode )for intf in self.intfList():if not intf.IP():（3）核实mininet安装：sudo mn --test=pingall*** Creating network*** Adding controller*** Adding hosts:h1 h2*** Adding switches:s1*** Adding links:(h1, s1) (h2, s1)*** Configuring hostsh1 h2*** Starting controller*** Starting 1 switchess1 OVSswitch opts:*** Ping: testing ping reachabilityh1 -> h2h2 -> h1*** Results: 0% dropped (2/2 received) *** Stopping 1 switchess1 ..*** Stopping 2 hostsh1 h2*** Stopping 1 controllersc0*** Donecompleted in 0.541 secondsVerify mininet works for OF1.3:odluser@odl-vm:~\$ sudo mn--controller=remote,ip=192.168.128.132 --topo tree,2 --switch ovsk,protocols=OpenFlow13*** Creating network*** Adding controller*** Adding hosts:h1 h2 h3 h4*** Adding switches:have protcol params!s1 have protcol params!s2 have protcol params!s3*** Adding links:(h1, s2) (h2, s2) (h3, s3) (h4, s3) (s1, s2) (s1, s3) *** Configuring hostsh1 h2 h3 h4*** Starting controller*** Starting 3 switchess1 OVSswitch opts: protocols=OpenFlow13s2 OVSswitch opts: protocols=OpenFlow13s3 OVSswitch opts: protocols=OpenFlow13*** Starting CLI:注意：若运行到一半卡住，按Enter键不能出现mininet<，说明没有安装成功，还有情况可能会报错：Cannot find required executable ovs-controller. Please make sure that it is installed and available in your $PATH:***** 参考：/questions/21687357/mininet-ovs-con troller-can-t-be-loaded-and-run/questions/17341076/mininet-cannot-find-required-executable-controller(若不用到ovs-controller,不管它直接连接远端控制器其实也完全可以。
组织：中国互动出版网（/）RFC文档中文翻译计划（/compters/emook/aboutemook.htm）E-mail：********************译者：吕新阳（lv_xinyang *******************）译文发布时间：2002-5-3版权：本中文翻译文档版权归中国互动出版网所有。
可以用于非商业用途自由转载，但必须保留本文档的翻译及版权信息。
Network Working Group A. Robert Request for Comments: 2351 SITA Category: Informational May 1998航空订座、票务及报文数据流在IP网络上的映射（RFC 2351 ——Mapping of Airline Reservation, Ticketing,and Messaging Traffic over IP )本备忘录的状态本文档讲述了一种Internet社区的信息，它不特指任何一种Internet标准。
本备忘录的发布不受任何限制。
版权声明Copyright (C) The Internet Society (1998). All Rights Reserved.安全性声明本文未全面考虑安全性的问题。
本文所提供的协议本身没有包含任何安全机制，其原因在于，数据流可以通过使用静态标识的外部机制来认证或使用文本密码机制，任何一种机制提供可靠的安全保证。
本文也概括性的指出了通过使用IPSEC对数据流加密的方法，但此方法仅供参考。
摘要本文档介绍了一种用协议，用于在IP网络上传输封装有航空专用协议的数据包。
目录1.介绍 (2)2.术语及缩略语 (4)3.分层模型 (6)4. 流标识 (7)5. TCP端口分配 (7)6. MA TIP会话建立 (7)7. TYPEＡ及TYPE B包结构概览 (9)8. TYPEＡ会话流的MA TIP包结构 (9)8.1控制包格式 (9)8.1.1 打开会话格式(SO) (10)8.1.2 确认打开格式(OC) (11)8.1.3 关闭会话(SC) (13)8.2数据包格式 (13)9. TYPEＡ主机到主机数据流的MA TIP包结构 (14)9.1控制包格式 (14)9.1.1 打开会话格式(SO) (14)9.1.2确认打开格式(OC) (16)9.1.3 关闭会话(SC) (16)9.2数据包格式 (17)10. TYPE B数据流的MA TIP包结构 (18)10.1控制包格式 (18)10.1.1 打开会话格式(SO) (18)10.1.2 确认打开格式(OC) (19)10.1.3 关闭会话(SC) (20)10.2数据包格式 (20)11. 安全考虑 (20)12. 作者地址 (21)13. 版权说明 (21)1.介绍航空业全球性的数据网络应用已经超过40年,共两类主要的数据流类型:Transactional traffic:事务处理流它主要是用于在航空公司或旅游代理与中央主机系统的通信,进行座位预定和订票申请.通常方式是哑终端或PC通过数据网络访问中央主机系统(IBM或UNISYS). Messaging:报文这种数据流是一种e-mail应用,不要求实时性连接.但要保证高级别的安全.寻址方式使用IATA定义的国际标准格式,其中包含城市和航空公司代码.它又称为TYPE B,传输时有高级别的保护,多点寻址并共分4个优先级.在IATA标准中定义了TYPE A和TYPE B报文的完整格式.在底层,同步协议早在六十年代,即在OSI和SNA标准之前就已经建立了.目前,在世界范围内,还有大量的传统设备在许多航空公司使用.他们还没有决定马上用开放标准的现代设备来替换现有的终端,而是寻求更加经济的方式来连接其终端至定座系统.大多数航空公司愿意从航空专署协议转换到标准协议上来,这样就可以从低成本的新技术中获益,但由于下述因素的存在使得这种转换难以很快实现:⏹应用还没有转换过去.⏹使用航空协议P1024B(IBM ALC) 或P1024C(UNISYS UTS)的哑终端数目庞大.现在有许多不同的基于网关的专属解决方案用来利用低成本的网络,但是它们不易扩展且互不兼容.未来,TCP/IP一定会更广泛的用于传输这些数据,只是因为:⏹TCP/IP 是基于UNIX应用的标准协议⏹TCP/IP栈价格低廉⏹TCP/IP 可用于企业内部网.本文档的目的是定义在TCP/IP上传输的航空专用各类数据流的映射.航空公司的系统中必须安装TCP/IP栈以支持数据流交换,如下所示:!---- ! ( )! ! ---------- ( )!---- ! ( )Type B HOST ( NETWORK )( )( ) !---o!----! ( ) -------- ! D ! ---o Type A stations!----! ---------- ( ) !---o!----! ( )TYPE A HOST !!!!--------! !--------Network Messaging System(D) : Gateway Type A router本文讨论的不同的航空专属数据流包括:-TYPE A Host / Terminal (主机到终端)-TYPE A Host/ TYPE A host(主机到主机)-TYPE B Host/ Network messaging System(主机到网络报文系统)对哑终端而言,会话必须由终端发起以使得主机和路由器之间建立一个IP连接.而如果使用智能工作站的话,只要它与网络有直接的连接,有一个TCP/IP栈和终端仿真软件,就可以建立自己到中央主机的直接IP连接.2.术语及缩略语ALC航空线路协议: IBM 航空专属协议(见P1024B)ASCII美国标准信息交换码ASCU代理设备控制单元: 用户端的一个集群.AX.25航空X.25: X.25 OSI模型的航空应用(IATA制定)BAUDOTITU-T 5定义的字母表.使用5位表示.加入填充位的BAUDOT使用7位表示,最重要位(bit 7)用于区分,第六位设置为1.BA TAPType B应用到应用协议.它是对TYPE B数据流加密的协议.由SITA定义并由IATA出版(SCR V ol. 3).EBCDIC扩充二进制编码的十进制交换码Flow ID Traffic数据流标识,用于区分主机到主机数据流的类型.HLDHigh Level Designator: 用于指示网络中某区域的进入点或退出点.IA交换地址: P1024B协议的ASCU 标识IATA国际航空运输协会IP网际协议IPARS国际程序航空定座系统:ALC中使用的编码类型.HTH主机到主机(数据流)LSB最不重要位MATIP航空数据流在网际协议的映射MSB最重要位OC确认打开(MATIP命令)OSI开放标准接口P1024BSITA对ALC(IBM 航空专属协议)的定义.使用六位填充位的参数(IPARS)和IA/TA用于物理寻址.P1024CSITA对UTS(UNISYS终端协议)的定义.使用七位参数(ASCII)和RID/SID用于物理寻址.RFU为将来使用的保留部分RID远端标识: P1024C协议的ASCU标识.SC关闭会话(MATIP命令)SCR系统和通信参考.(IATA 文档)SID栈标识: P1024C协议的终端标识SITA国际航空电讯联盟SO打开会话(MATIP 命令)TA终端地址: P1024B协议的终端标识TCP传输控制协议TYPE A Traffic交互数据流或点对点TYPE B Traffic高可靠性的符合IATA格式的报文流UTS通用终端系统,Unisys专属,见P1024C3.分层模型MATIP是端到端的协议.它试图在TCP层和航空应用间建立一个与路由无关的映射标准.+-------------------------------+|Airline TYPE A | Airline TYPE B|| | Application || |---------------|| Application | BATAP |+-------------------------------+| MATIP A | MATIP B |+-------------------------------+| T.C.P |+-------------------------------+| I.P |+-------------------------------+| MEDIA |+-------------------------------+4. 流标识在TYPE A 会话流中,航空主机应用通过4字节(H1,H2,A1,A2)来识别ASCU.这些字节是由主机分配并唯一的标识每一个ASCU.这样主机能够不依赖于IP地址而动态识别ASCU.H1 H2 A1 A2 字节遵从下列情况:-只使用A1,A2,而H1 H2设置为0000.-H1,H2标识会话,而A1A2标识会话中的ASCU.-H1,H2,A1,A2标识ASCU.前两种情况与AX.25映射完全兼容,HiH2与HLD等价,为十六进制表示的2字节.第三种情况更加灵活但与AX.25不兼容.在TYPEＡ主机到主机流中，标识域为３字节的Ｈ1 H2 Flow ID(可选).H1H2保留用来标识远端主机(与IP无关)并必须同时分配.在TYPEＢ流中，端系统的标识可通过使用HLDs,或者直接由一对IP地址确定. 5. TCP端口分配IANA(Internet Assigned Numbers Authority)为MATIP TYPE A和TYPE B流分配了相应端口号:MATIP Type A TCP 端口: 350MATIP Type B TCP 端口: 351通过不同的TCP端口号就可以区分数据流是type A 还是B.6. MATIP会话建立在两个应用进行数据交换之前,一个MA TIP会话必须在TCP连接上建立以确认数据流属性,如:-TYPE A数据流的子类型(Type A host to host 还是Type A conversational)-使用的多路复用情况(用于Type A)-数据头-字符集对不同的参数集,必须建立不同的会话和TCP连接.(如:两点间的P1024B和P1024C数据流需要建立两个不同的会话.)MATIP会话的建立可以由任一端初始化.在MA TIP层没有keep-alive机制.会话超时由TCP 的超时参数来控制.三个命令用于管理MATIP会话:-打开会话(SO) 用来发一个建立会话的请求.-确认打开(OC)用来确认SO命令.-关闭会话(SC)用来关闭当前的会话.MATIP会话建立的前提是相关TCP连接已经建立.然而,当关闭MA TIP会话时并不需要关闭TCP连接.典型的交换情况:TCP session establishmentSession Open ---------><----------- Open confirmdata exchange----------------------><-------------------------...Session Close ----------------->...<------------------------- Session OpenOpen confirm ------------------->data exchange<----------------------------------------------->打开会话命令可能包含配置参数.如果收到一个打开会话命令,但是同一个会话已经打开(如:相同的IP地址和端口号),这是打开会话命令可以自动清除会话中的旧配置,而用新的打开会话命令中的信息来建立新配置.如上图所示,打开和关闭命令是成对出现的.对于type A 会话流而言,SO和OC命令包含确认ASCU和会话的信息.在一个会话中通过2或4字节的信息来指示ASCU.一个标志(flag)指示ASCU是通过4字节(H1H2A1A2)还是2字节(A1A2)确认.对后者(type b)而言,H1H2保留用于会话标识.发出SO指令是为了打开MATIP会话.在Type A会话流中,它包含了此会话配置的所有ASCU 的列表.OC命令对SO命令进行确认.它可以全部或条件性的拒绝或接受它.在Type A中,它包含了会话中被拒绝或被确认的ASCU的列表.7. TYPEＡ及TYPE B包结构概览MATIP头部的前4个字节遵从下述规则:0 1 2 30 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|0|0|0|0|0| Ver |C| Cmd | length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Ver这个域标识MATIP的版本.它的值必须为001,否则包被认为无效.C指示是否为控制包.值为1时,此包是控制包值为0时,此包是数据包Cmd如果标志C的值为1,这个域标识控制命令Length这个域指出整个包的长度(字节数),包含包头.注意: 标识为可选(Opt)的域如果没使用则不会传送.8. TYPEＡ会话流(CONVERSATIONAL)的MATIP包结构8.1 控制包格式在MA TIP层有3个控制包打开或关闭会话.8.1.1 打开会话格式(SO)为了能够在传送数据包之前确认会话,SO命令被发送.它可以由任一端发起.当发生冲突时,IP 地址较低的一端的要求被忽略.0 1 2 30 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|0|0|0|0|0| Ver |1|1 1 1 1 1 1 0| length |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|0 0|0 1|0| CD | STYP |0 0 0 0| RFU |MPX|HDR| PRES. |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| H1 | H2 | RFU ||-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Reserved | RFU | Nbr of ASCUs |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Nbr of ASCUs | ASCU list (opt) |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+RFU保留部分,必须设为零.CD指出编码格式000: 5位(填充型的baudot)010: 6位(IPARS)100: 7位(ASCII)110: 8位(EBCDIC)xx1: R.F.USTYP指出流的子类型(对TYPE A而言)0001: TYPE A 会话流MPX指出TCP会话中的多路复用方式.可能值有:00: ASCU组,每个ASCU由4字节标识(H1H2A1A2)01: ASCU组,每个ASCU由2字节标识(A1A2)10: TCP会话中的单个ASCU.HDR指出航空专用地址的哪一部分在会话传送的报文的前面.可能值有:00: ASCU 头= H1+H2+A1+A201: ASCU 头=A1+A210: 没有头部11: 未使用MPX和HDR必须一致.当ASCU多路复用,数据必须包含ASCU标识.下表总结了允许的组合:+--------------------------+| MPX | 00 | 01 | 10 |+--------------------------+| HDR | || 00 | Y | Y | Y || 01 | N | Y | Y || 10 | N | N | Y |+--------------------------+PRES指出表示格式0001: P1024B0010: P1024C0011: 3270H1 H2当MPX=00,这两个域逻辑上标识会话.如果此域不用的话,必须设置为0.如果在MPX不为00,HDR=00的会话中,数据包中的H1H2必须同SO命令中设置的值相同.Nbr of ASCUs此域必须存在且值为每个会话中的ASCU的个数.值为0表示无法确定.这种情况下,ASCU列表不出现在’会话打开’命令中,但必须由另一端的’确认打开’命令来发送.ASCU列表包含用于每个ASCU的标识的列表.如果MPX=00,此域用4字节(H1H2A1A2)表示每个ASCU,否则用2字节(A1A2)表示.8.1.2 确认打开格式(OC)OC命令作为对SO命令的回应,通过检查每个ASCU的配置决定据绝或者接受这个会话.对接受的情况而言,OC指出被拒绝的ASCU的数目和地址.同时,它指出配置在MATIP会话中的ASCU的列表,前提是SO命令提供的列表正确无误,或者在会话中配置的ASCU的数目未知(如:ASCU数为0).8.1.2.1 拒绝连接0 1 2 30 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|0|0|0|0|0| Ver |1|1 1 1 1 1 0 1|0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 1|+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| cause |+-+-+-+-+-+-+-+-+Cause此域指出拒绝此MA TIP会话的原因:00000001: 发送和接收方之间数据流类型不匹配00000010: SO头部的信息不一致10000100至11111111: 需应用支持其它值: 保留8.1.2.2 接受连接0 1 2 30 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|0|0|0|0|0| Ver |1|1 1 1 1 1 0 1| length |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|0 0 R 0 0 0 0 0| Nbr of ASCUs |Nbr of ASCU(opt| ASCU LIST |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+R标记位,指出SO命令中ASCU配置的错误NBR of ASCUs如果SO命令中的MPX值为00,此域为2字节,否则,为1字节长.如果设置了R标志位,此域表示错误的ASCU数目.否则,指出此MA TIP会话中定义的ASCU 数目.注意: 此域的长度不是1字节就是2字节.在SO命令的对应位置,长度总是2字节.这个区别是由于兼容AX25(见第4节)的要求造成的.在SO命令中,可以在AX25 call user data中使用一个多余字节.不幸的是,在AX25 clear user data中没有那样的字节.ASCU LIST取决于R标志位,指出ASCU的列表(A1A2或H1H2A1A2),它们或者是有错误,或者是此次会话所包含的.8.1.3 关闭会话(SC)SC(关闭会话)命令用来关闭一个存在的MATIP会话.0 1 2 30 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|0|0|0|0|0| Ver |1|1 1 1 1 1 0 0|0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 1|+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Close Cause |+-+-+-+-+-+-+-+-+Close Cause指出会话关闭的原因:00000000: 正常关闭10000100至11111111:需应用支持其它值: 保留8.2 数据包格式0 1 2 30 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|0|0|0|0|0| Ver |0|0 0 0 0 0 0 0| length |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| ID (optional) |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| || Payload || |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ID此域可选,且随会话建立过程中的HDR,PRES的值的不同而有不同的长度和格式.+------------------------------+-------------------------------+|HDR | PRES = P1024B and 3270 | PRES = P1024C |+------------------------------+-------------------------------+|00 |ID = 4 bytes H1-H2-A1-A2 | ID = 5 bytes H1-H2-A1-0x01-A2 |+------------------------------+-------------------------------+|01 |ID = 2 bytes A1-A2 | ID = 3 bytes A1-0x01-A2 |+------------------------------+-------------------------------+|10 |ID = 0 bytes | ID = 0 bytes |+------------------------------+-------------------------------+如果MPX值不为0,H1,H2的值必须同SO命令中的值匹配.Payload负载以终端标识起始:-一字节的终端标识(TA),P1024B协议使用-两字节的SID/DID终端标识,P1024C协议使用.-9. TYPEＡ主机到主机(HOST-TO-HOST)数据流的MATIP包结构9.1 控制包格式在MA TIP层共有3种控制包用来打开或关闭会话.9.1.1 打开会话格式(SO)打开会话命令用来在发数据包前确认会话的建立.它可以由任一端发起.当冲突发生时,忽略掉较低的IP地址一方的打开会话请求.0 1 2 30 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|0|0|0|0|0| Ver |1|1 1 1 1 1 1 0| length |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|0 0|0 1|0| CD | STYP |0 0 0 0| RFU |MPX|HDR|0 0 0 0|+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| H1 | H2 | RFU ||-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Flow ID(opt)|+-+-+-+-+-+-+-+-+RFU保留部分,必须设置为零.CD此域指出编码方式,同8.1.1.1部分说明.STYP指出数据流子类型(对Type A而言).0010: TYPE A IATA 主机到主机1000: SITA主机到主机MPX指出在TYPE A SITA 主机到主机的MATIP会话中使用的多路复用.可能值为:00: 无关01: 在TCP连接中为多数据流10: 在TCP连接中为单数据流HDR指出航空专用地址的哪一部分在会话传送的报文的前面.可能值有:00: 用于TYPE A SITA主机到主机的包头=H1+H2+Flow ID01: 用于TYPE A SITA主机到主机的包头=Flow ID10: 没有头部(默认为IA TA主机到主机)11: 未使用MPX和HDR必须一致.当数据流多路复用,数据必须包含数据流标识.下表总结了允许的组合:+---------------------+| MPX | 01 | 10 |+---------------------+| HDR | | || 00 | Y | Y || 01 | Y | Y || 10 | N | Y |+---------------------+H1 H2用来标识会话.如果不是用此域,值必须为0.如果HDR=00,数据包中的H1H2必须与SO命令中设置的值相同.Flow ID此域可选,指出数据流ID(范围3F –4F)9.1.2确认打开格式(OC)OC(确认打开)命令回应SO(打开会话)命令且用来接受或拒绝一个会话.9.1.2.1 拒绝连接0 1 2 30 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0|0|0|0|0| Ver |1|1 1 1 1 1 0 1|0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 1| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | cause |+-+-+-+-+-+-+-+-+Cause此域指出拒绝MATIP会话的原因:00000001: 在发送和接收方的数据流类型不匹配00000010: SO包头中的信息不匹配10000100至11111111: 需应用支持其它值:保留9.1.2.2 接受连接0 1 2 30 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0|0|0|0|0| Ver |1|1 1 1 1 1 0 1|0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 1| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 0 0 0 0 0|+-+-+-+-+-+-+-+-+9.1.3 关闭会话(SC)SC(关闭会话)命令用来关闭一个存在的MATIP会话.0 1 2 30 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0|0|0|0|0| Ver |1|1 1 1 1 1 0 0|0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 1| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Close Cause |+-+-+-+-+-+-+-+-+Close Cause指出会话关闭的原因:00000000: 正常关闭10000100至11111111: 需应用支持其它值: 保留9.2 数据包格式0 1 2 30 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0|0|0|0|0| Ver |0|0 0 0 0 0 0 0| length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ID (optional) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Payload | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ID此域可选, 且随会话建立过程中的HDR的值的不同而有不同的长度和格式.+-------------------------------+|HDR | I.D. |+-------------------------------+|00 |ID = 3 bytes H1-H2 FLOW ID|+-------------------------------+|01 |ID = FLOW ID |+-------------------------------+|10 |ID nor present |+-------------------------------+Payload packet负载格式同MATIP层有关.它是按照IATA主机到主机规则编排且由发送和接收双方共同遵从.10. TYPE B数据流的MATIP包结构10.1 控制包格式在MA TIP层交换Type B数据共使用3种控制包打开或关闭会话.10.1.1 打开会话格式(SO)在发送数据包之前,建议令系统之间建立一个会话以保证它们之间能够通信(即:两个系统都支持将通过连接发送的数据流属性).基于此点要求,在TCP层连接建立之后,要马上通过使用下面定义的会话命令建立一个双向的握手.任一端都可以初始此过程.当发生冲突时,忽略掉来自较低IP地址的一端的会话打开请求.0 1 2 30 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|0|0|0|0|0| Ver |1|1 1 1 1 1 1 0| length |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|0 0 0 0 0| C D | PROTEC| BFLAG | Sender HLD |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Recipient HLD |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Length此域指出整个命令的字节数,包含头部.可能的长度只有6字节或10字节.CD指出编码方式,同8.1.1.1部分说明.PROTEC指出端到端报文应答传输协议机制.0010: BATAP其它值: 可以使用.BFLAG(X指’任意,不计’X X 0 0 指示此包中不含’发送方HLD,接收方HLD’,这种情况下,包长度为6字节.X X 1 0 指示此包中的第9,10,11,12字节分别存放’发送方HLD,接收方HLD’, 这种情况下,包长度为10字节.0 0 X X 指示连接请求由主机发出(Mainframe system).0 1 X X 指示连接请求由网关发出)Sender HLDType B 系统的HLD,用以发出打开会话命令Recipient HLDType B系统中的HLD,它是会话打开命令的目的端.10.1.2 确认打开格式(OC)OC(确认打开)命令回应SO(打开会话)命令,并接受或拒绝一个会话.10.1.2.1 拒绝连接0 1 2 30 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0|0|0|0|0| Ver |1|1 1 1 1 1 0 1|0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 1| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0|1| Cause |+-+-+-+-+-+-+-+-+此包长度为5字节.Cause指出拒绝包的原因000001: 在接受和发送方的数据流类型不匹配.000010: SO头部的信息不一致000011: 安全机制类型不同000100至111111: 保留部分10.1.2.2 接受连接0 1 2 30 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0|0|0|0|0| Ver |1|1 1 1 1 1 0 1|0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 1| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 0 0 0 0 0|+-+-+-+-+-+-+-+-+包长度为5字节.10.1.3 关闭会话(SC)SC(关闭会话)命令用来关闭一个存在的MATIP会话.0 1 2 30 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|0|0|0|0|0| Ver |1|1 1 1 1 1 0 0|0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 1|+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Close Cause |+-+-+-+-+-+-+-+-+Close Cause指出会话关闭的原因:00000000:正常关闭10000100 至11111111: 需应用支持其它值: 保留10.2 数据包格式0 1 2 30 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|0|0|0|0|0| Ver |0|0 0 0 0 0 0 0| length |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| || Payload || | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Length此域指示整个包的字节数,包含头部.Payload按IATA标准编码的Type B 报文,并遵从应用的TYPE B服务的规则要求.11. 安全考虑对航空业来讲,数据安全异常重要.MA TIP使用者的安全机制可以在不同层实现:通过定义ASCU来保证与主机应用之间的会话.可以从两方面加以控制:通过静态配置在应用层定义ASCU地址(H1 H2 A1 A2),或使用用户账号/口令确认ASCU.大多数情况下,用户账号和口令可以通过中央主机中的软件来核实.同时他们还可以通过应用本身来检查.在TCP/IP中传输的MATIP会话可以通过防火墙.可以通过对网络(IP地址)层或TCP应用层施加控制来依赖防火墙机制保证安全性.对更高层的安全来说,所有应用可以通过对控制包实施IPSEC ESP加密实现.还可以使用重发保护,IPSEC ESP的强制加密器及NULL封装机制.数据包也可使用IPSEC ESP加密.禁止重法和使用IPSEC ESP强制加密器的完整性保护也可以使用.NULL 封装及其它的IPSEC ESP 要求的加密器也可以得到支持.12. 作者地址Alain RobertS.I.T.A.18, rue Paul Lafargue92904 PARIS LA DEFENSE 10FRANCEPhone: 33 1 46411491Fax: 33 1 46411277EMail: ****************.sita.int13. 版权说明Copyright (C) The Internet Society (1998). All Rights Reserved.This document and translations of it may be copied and furnished toothers, and derivative works that comment on or otherwise explain itor assist in its implementation may be prepared, copied, publishedand distributed, in whole or in part, without restriction of anykind, provided that the above copyright notice and this paragraph areincluded on all such copies and derivative works. However, thisdocument itself may not be modified in any way, such as by removingthe copyright notice or references to the Internet Society or otherInternet organizations, except as needed for the purpose ofdeveloping Internet standards in which case the procedures forcopyrights defined in the Internet Standards process must befollowed, or as required to translate it into languages other thanEnglish.The limited permissions granted above are perpetual and will not berevoked by the Internet Society or its successors or assigns.This document and the information contained herein is provided on an"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.。
Internet Message Access Protocol (IMAP) is an email retrieval protocol. It stores email messages on a mail server and enables the recipient to view and manipulate them as though they were stored locally on their device. IMAP was developed in the late 1980s and has since become one of the most widely used email retrieval protocols.The IMAP standard is defined in RFC 3501, which was published in 2003. This document provides a detailed description of the protocol's functionality, including its data formats, commands, and responses. The standard specifies how IMAP clients and servers should communicate with each other to enable the retrieval and manipulation of email messages.One of the key features of IMAP is its support for multiple clients accessing the same mailbox simultaneously. This is achieved through the use of a "shared" storage model, where all clients see the same set of messages and folders stored on the server. This allows users to access their email from different devices without having to worry about synchronizing their messages manually.Another important aspect of IMAP is its support for message organization and management. Clients can create, delete, and rename folders, as well as move messages between folders. They can also search for specific messages based on various criteria, such as sender, subject, or date.IMAP also provides a range of features for managing individual messages. Clients can mark messages as read or unread, flag them for follow-up, and even move them to a specific folder. They can also reply to messages, forward them to others, and generate replies or forwards with attachments.Overall, the IMAP standard provides a powerful and flexible framework for managing email messages. Its support for shared storage, message organization, and advanced message management features make it a popular choice for both personal and business email users.。
F5常用5种插入客户端源地址方法简述常旭2014年8月目录一、引言 (3)二、测试环境 (4)2.1、网络拓扑 (4)2.2、基础配置 (4)三、应用层常用方法 (5)3.1、X-Forwarded-For (5)3.1.1、配置步骤 (5)3.1.2、验证 (6)3.2、插入Header (7)3.2.1、配置步骤 (8)3.2.2、验证 (8)3.3、插入Cookie (9)3.3.1、配置步骤 (10)3.3.2、验证 (10)3.4、TCP-Option (11)3.4.1、配置步骤 (12)3.4.2、验证 (13)3.5、TCP-payload (15)3.5.1、配置步骤 (16)3.5.2、验证 (17)四、总结 (18)一、引言随着IT环境的高速发展,解决我们日常各种需求的应用像雨后春笋般以一个惊人的速度爆发式增长,而其中大部分应用为了抢占市场都存在开发周期短的问题。
如果基于这样的一个背景让应用开发人员将功能是否满足需求、可用性、应用性能、安全性、是否按时上线、后期维护复杂度等几个现实问题做优先级排序,那么安全性肯定会排在最后。
但实际上现在大多数应用在设计业务逻辑时就已经对安全有了一定要求。
比如最近一段时间经常在项目上遇见后端服务器需要查看客户端源IP地址的需求。
这实际上就是一个简单的安全手段,通过查看客户端源IP地址来达到审计的目的,或者通过ACL列表过滤客户端请求等。
我们在讨论如何让后端服务器看到客户端源IP地址前先来看一下F5的几种部署模式。
首先是三角传输(即npath模式),这是一种非常古老的部署模式,主要应用于响应包明显大于请求包的场景(如请求包大小为10k,服务器回包1000M!有点夸张),但随着设备性能的不断提高且该模式配置极其复杂(需要服务器开启loopback功能,并通过iptable关闭ARP响应功能,但不同Linux版本关闭iptable命令均不同)目前已经退出了历史舞台。
NGN实验工程测试规范第五分册协议测试(SIP、SIP-T部分）2002年4月编制说明本规范为四城市NGN试验工程中SIP、SIP-T协议测试规范。
测试共分为3部分大内容，分别为SIP测试和SIP-T测试，SIP/SIP-T与其它协议的互通。
SIP测试主要是检验各个功能实体对消息的处理过程、SIP终端的注册以及通过何种机制来保证信息的安全性。
重点考察测试设备的基本功能（proxy、redirect、fork proxy等），在基本功能具备的情况下，通过正常流程观察各个功能实体对消息的处理，观察设备能否根据消息中不同的参数来调整某些策略（如选路策略等）。
SIP-T测试主要是检验ISUP与SIP之间的互通、PSTN用户互通（通过MGC）时，设备对消息的处理。
重点考察互通的终端能否支持一些典型的补充业务（如呼叫等待、呼叫转移、呼叫保持等），在此基础上观察SIP消息与ISUP消息的映射。
SIP/SIP-T与其他协议的互通，主要考虑与H.323、H.248的互通。
目录1 适用范围 (1)2 引用标准 (1)3 测试说明 (1)3.1 测试分类 (1)3.2 测试结构 (1)4 测试项目 (3)4.1 SIP终端之间通信 (3)4.1.1 正常呼叫（成功呼叫） (3)4.1.2 正常呼叫（对存在session的修改） (21)4.1.3 不成功呼叫或异常情况 (26)4.1.4 定时器的检验 (35)4.2 ISUP与SIP之间的互通 (37)4.2.1 ISUP_SIP (37)4.2.2 SIP-ISUP (46)4.3 PSTN用户的通信（通过MGC） (51)4.3.1 成功的呼叫 (51)4.3.2 不成功呼叫或异常情况 (55)4.3.3 定时器的检验 (57)4.4 注册的检验 (58)4.5 安全性的检验 (64)4.6 消息体参数检验 (65)4.7 补充业务 (70)4.8 SIP与其他协议的互通 (75)4.8.1 SIP/SIP-T与H.323的互通 (75)4.8.2 SIP/SIP-T与H.248/MGCP的互通 (76)5 附件一： (77)6 附件二： (79)1适用范围本规范主要适用NGN实验工程中SIP、SIP-T协议的测试。
rfc相关设置及使用RFC（Request for Comments）是一种用于定义互联网协议、标准和相关问题的文档。
RFC的格式由互联网工程任务组（IETF）统一规定，它们记录了网络技术的发展和演进过程。
在本文中，我们将介绍RFC相关的设置和使用。
1. 了解RFC的作用和历史：RFC是由IETF组织制定的一种标准化文档，它记录了互联网协议的设计、开发和演化过程。
RFC起源于20世纪60年代的ARPANET，是一种社区驱动的文档，通过共享和讨论来推动互联网技术的发展。
RFC文档旨在提供指南、建议和最佳实践，帮助网络技术人员解决问题。
2. 寻找和阅读RFC文档：RFC文档可以在互联网上免费获取，IETF的官方网站和其他资源库都有存档。
这些文档按照顺序编号，并且以RFC开头，比如RFC 791定义了IPv4协议。
通过搜索引擎或在IETF网站上使用关键词搜索，可以找到特定主题的RFC文档。
阅读RFC文档时，应该注意文档的状态，有一些可能已经被更新或废弃。
3. 使用RFC文档：RFC文档在网络技术的发展过程中起着重要的指导作用。
它们提供了协议规范、算法实现、安全性和隐私等方面的建议。
网络管理员、网络工程师和开发人员可以使用RFC文档来了解和理解特定协议或标准的设计原理和要求。
此外，RFC文档还常用于进行互联网协议的实现、编程和配置。
4. 参与RFC的制定过程：RFC并不是静止的文件，而是一个持续演进的过程。
任何人都可以参与到RFC的制定过程中。
要参与RFC的制定，可以加入IETF并参与相关的工作组或邮件列表。
通过这种方式，个人可以提出改进建议，参与讨论和标准化的制定。
5. 遵循RFC的指导原则：在网络技术领域，遵循RFC的指导原则是至关重要的。
这些指导原则包括设计原则、协议分层、安全性和互操作性等要求。
遵循RFC的指导原则可以确保网络协议的正确性、稳定性和可靠性，同时也可以促进网络技术的发展和创新。
总结起来，RFC在互联网技术领域起着重要的作用，它们记录了互联网协议的发展历程和指导原则。
开源项目rfc流程开源项目RFC流程1. 什么是RFC？•RFC是”Request for Comments”的缩写，意为”征求意见”或”意见征集”。
•在开源项目中，RFC是一种协作流程，用于提出新的功能或更改现有功能的建议，并征求项目群体的意见。
2. RFC的目的与重要性•RFC流程为开源项目提供了一个包容性的环境，让所有人都有机会参与决策过程。
•通过RFC流程，项目团队可以更好地理解社区成员的需求，减少冲突和误解，并确保变更是基于共识和讨论的结果。
3. RFC流程的具体步骤•提出RFC：在项目的RFC存储库中创建一个新的RFC文件，并使用Markdown格式编写提案。
•反馈与讨论：项目群体和有兴趣的社区成员将参与讨论，提出问题、建议和其他反馈。
•修改与改进：根据收到的反馈，作者可以对RFC进行修改和改进，以更好地满足需求和解决问题。
•状态更新：在RFC的生命周期中，通过更新RFC文件的状态，作者可以向社区反馈进展情况。
•最终评审：项目核心团队将对RFC进行最终评审，并确认是否接受或拒绝提案。
•实施与跟踪：一旦RFC被接受并实施，作者需要跟踪变更的进展，并确保及时更新相关文档。
4. RFC文章的Markdown格式要求•使用Markdown格式可以更好地展示RFC的内容和结构。
•下面提供一些常用的Markdown格式要求：–标题：使用井号（#）表示不同级别的标题，以突出重点和组织结构。
–列表：使用横杠（-）或星号（*）创建无序列表，使用数字创建有序列表。
–引用：使用大于号（>）创建引用段落，用于引用他人意见或讨论。
–代码块：使用反引号（`）创建代码块，用于展示代码示例或命令。
–链接：使用方括号（[]）和圆括号（()）创建链接，以便在RFC中引用其他文件或资源。
5. 一些建议与注意事项•清晰明了地描述问题或需求，以便社区成员更好地理解和提供反馈。
•避免使用复杂的排版和格式，以保持RFC的易读性。
Network Working Group J. Quittek Request for Comments: 3917 NEC Europe Ltd. Category: Informational T. Zseby Fraunhofer FOKUS B. Claise Cisco Systems S. Zander Swinburne University October 2004 Requirements for IP Flow Information Export (IPFIX)Status of this MemoThis memo provides information for the Internet community. It doesnot specify an Internet standard of any kind. Distribution of thismemo is unlimited.Copyright NoticeCopyright (C) The Internet Society (2004).AbstractThis memo defines requirements for the export of measured IP flowinformation out of routers, traffic measurement probes, andmiddleboxes.Table of Contents1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . 32. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.1. IP Traffic Flow. . . . . . . . . . . . . . . . . . . . 3 2.2. Observation Point. . . . . . . . . . . . . . . . . . . 4 2.3. Metering Process . . . . . . . . . . . . . . . . . . . 4 2.4. Flow Record. . . . . . . . . . . . . . . . . . . . . . 5 2.5. Exporting Process. . . . . . . . . . . . . . . . . . . 52.6. Collecting Process . . . . . . . . . . . . . . . . . . 53. Applications Requiring IP Flow Information Export . . . . . . 6 3.1. Usage-based Accounting . . . . . . . . . . . . . . . . 6 3.2. Traffic Profiling. . . . . . . . . . . . . . . . . . . 7 3.3. Traffic Engineering. . . . . . . . . . . . . . . . . . 7 3.4. Attack/Intrusion Detection . . . . . . . . . . . . . . 73.5. QoS Monitoring . . . . . . . . . . . . . . . . . . . . 84. Distinguishing Flows. . . . . . . . . . . . . . . . . . . . . 8 4.1. Encryption . . . . . . . . . . . . . . . . . . . . . . 9 4.2. Interfaces . . . . . . . . . . . . . . . . . . . . . . 9 Quittek, et al. Informational [Page 1]4.3. IP Header Fields . . . . . . . . . . . . . . . . . . . 9 4.4. Transport Header Fields. . . . . . . . . . . . . . . . 10 4.5. MPLS Label . . . . . . . . . . . . . . . . . . . . . . 104.6. DiffServ Code Point. . . . . . . . . . . . . . . . . . 105. Metering Process. . . . . . . . . . . . . . . . . . . . . . . 10 5.1. Reliability. . . . . . . . . . . . . . . . . . . . . . 10 5.2. Sampling . . . . . . . . . . . . . . . . . . . . . . . 11 5.3. Overload Behavior. . . . . . . . . . . . . . . . . . . 11 5.4. Timestamps . . . . . . . . . . . . . . . . . . . . . . 12 5.5. Time Synchronization . . . . . . . . . . . . . . . . . 12 5.6. Flow Expiration. . . . . . . . . . . . . . . . . . . . 13 5.7. Multicast Flows. . . . . . . . . . . . . . . . . . . . 13 5.8. Packet Fragmentation . . . . . . . . . . . . . . . . . 135.9. Ignore Port Copy . . . . . . . . . . . . . . . . . . . 136. Data Export . . . . . . . . . . . . . . . . . . . . . . . . . 14 6.1. Information Model. . . . . . . . . . . . . . . . . . . 14 6.2. Data Model . . . . . . . . . . . . . . . . . . . . . . 16 6.3. Data Transfer. . . . . . . . . . . . . . . . . . . . . 16 6.3.1. Congestion Awareness. . . . . . . . . . . . . . 16 6.3.2. Reliability . . . . . . . . . . . . . . . . . . 17 6.3.3. Security. . . . . . . . . . . . . . . . . . . . 18 6.4. Push and Pull Mode Reporting . . . . . . . . . . . . . 18 6.5. Regular Reporting Interval . . . . . . . . . . . . . . 18 6.6. Notification on Specific Events. . . . . . . . . . . . 186.7. Anonymization. . . . . . . . . . . . . . . . . . . . . 187. Configuration . . . . . . . . . . . . . . . . . . . . . . . . 19 7.1. Configuration of the Metering Process. . . . . . . . . 197.2. Configuration of the Exporting Process . . . . . . . . 198. General Requirements. . . . . . . . . . . . . . . . . . . . . 20 8.1. Openness . . . . . . . . . . . . . . . . . . . . . . . 20 8.2. Scalability. . . . . . . . . . . . . . . . . . . . . . 208.3. Several Collecting Processes . . . . . . . . . . . . . 209. Special Device Considerations . . . . . . . . . . . . . . . . 2010. Security Considerations . . . . . . . . . . . . . . . . . . . 23 10.1. Disclosure of Flow Information Data. . . . . . . . . . 23 10.2. Forgery of Flow Records. . . . . . . . . . . . . . . . 2410.3. Denial of Service (DoS) Attacks. . . . . . . . . . . . 2411. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 2512. Appendix: Derivation of Requirements from Applications. . . . 2613. References . . . . . . . . . . . . . . . . . . . . . . . . . 31 13.1. Normative References . . . . . . . . . . . . . . . . . 3113.2. Informative References . . . . . . . . . . . . . . . . 3114. Authors’ Addresses . . . . . . . . . . . . . . . . . . . . . . 3215. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 33 Quittek, et al. Informational [Page 2]1. IntroductionThere are several applications that require flow-based IP trafficmeasurements. Such measurements could be performed by a router while forwarding the traffic, by a middlebox [RFC3234], or by a trafficmeasurement probe attached to a line or a monitored port. This memo defines requirements for exporting traffic flow information out ofthese boxes for further processing by applications located on otherdevices. They serve as input to the standardization of the IPFIXprotocol specifications.In section 3, a selection of such applications is presented. Thefollowing sections list requirements derived from these applications. In its early discussions the IPFIX Working Group chose to evaluateexisting flow export protocols at the same time it was developingthis ’requirements’ document.Flow export, however, is not performed by a protocol acting alone, it also requires a system of co-operating processes. In producing IPFIX requirements, therefore, the Working Group decided to specify whatwas required by these various processes - the metering process, theexporting process, etc. In these specifications we use lower-casefor the words must, may, and should, to indicate that IPFIXimplementors have some freedom as to how to meet the requirements.The Working Group’s goal is to produce standards-track RFCsdescribing the IPFIX information model and export protocol RFCs. As well as meeting the requirements set out in this document, theinformation model and protocol documents will provide a fullspecification of the IPFIX system, and will use uppercase keywords as in [RFC 2119].2. TerminologyThe following terminology is used in this document:2.1. IP Traffic FlowThere are several definitions of the term ’flow’ being used by theInternet community. Within this document we use the following one:A flow is defined as a set of IP packets passing an observation point in the network during a certain time interval. All packets belonging to a particular flow have a set of common properties. Each property is defined as the result of applying a function to the values of: Quittek, et al. Informational [Page 3]1. one or more packet header field (e.g., destination IP address), transport header field (e.g., destination port number), orapplication header field (e.g., RTP header fields [RFC3550])2. one or more characteristics of the packet itself (e.g., number of MPLS labels, etc.)3. one or more of fields derived from packet treatment (e.g., next hop IP address, the output interface, etc.)A packet is defined to belong to a flow if it completely satisfiesall the defined properties of the flow.This definition covers the range from a flow containing all packetsobserved at a network interface to a flow consisting of just a single packet between two applications with a specific sequence number.Please note that the flow definition does not necessarily match ageneral application-level end-to-end stream. However, an application may derive properties of application-level streams by processingmeasured flow data. Also, please note that although packetproperties may depend on application headers, there is no requirement defined in this document related to application headers.2.2. Observation PointThe observation point is a location in the network where IP packetscan be observed. Examples are a line to which a probe is attached, a shared medium such as an Ethernet-based LAN, a single port of arouter, or a set of interfaces (physical or logical) of a router.Note that one observation point may be a superset of several otherobservation points. For example one observation point can be anentire line card. This would be the superset of the individualobservation points at the line card’s interfaces.2.3. Metering ProcessThe metering process generates flow records. Input to the processare packet headers observed at an observation point and packettreatment at the observation point, for example the selected outputinterface. The metering process consists of a set of functions that includes packet header capturing, timestamping, sampling,classifying, and maintaining flow records.The maintenance of flow records may include creating new records,updating existing ones, computing flow statistics, deriving furtherflow properties, detecting flow expiration, passing flow records tothe exporting process, and deleting flow records.Quittek, et al. Informational [Page 4]The sampling function and the classifying function may be appliedmore than once with different parameters. Figure 1 shows thesequence in which the functions are applied. Sampling is notillustrated in the figure; it may be applied before any otherfunction.packet header capturing|timestamping|v+----->+| || classifying| |+------+|maintaining flow records|vFigure 1: Functions of the metering process2.4. Flow RecordA flow record contains information about a specific flow that wasmetered at an observation point. A flow record contains measuredproperties of the flow (e.g., the total number of bytes of allpackets of the flow) and usually characteristic properties of theflow (e.g., source IP address).2.5. Exporting ProcessThe exporting process sends flow records to one or more collectingprocesses. The flow records are generated by one or more meteringprocesses.2.6. Collecting ProcessThe collecting process receives flow records from one or moreexporting processes. The collecting process might store receivedflow records or further process them, but these actions are out ofthe scope of this document.Quittek, et al. Informational [Page 5]3. Applications Requiring IP Flow Information ExportThis section describes a selection of applications requiring IP flow information export. Because requirements for flow export listed infurther sections below are derived from these applications, theirselection is crucial. The goal of this requirements document is not to cover all possible applications with all their flow exportrequirements, but to cover applications which are considered to be of significant importance in today’s and/or future IP networks, and for which requirements can be met with reasonable technical effort.The list of applications should lead to a better understanding of the requirements which is particularly important when designing orimplementing traffic flow metering functions. A detailed overview of which requirement was derived from which application(s) is given inthe appendix.Please note that the described applications can have a large numberof differing implementations. Requirement details or requirementsignificance (required (must), recommended (should), optional (may)) could differ for specific implementations and/or for specificapplication scenarios. Therefore we derive the requirements from the general functionality of the selected applications. Some particular cases will even mandate more stringent requirements than the onesdefined in this document. For example, usage-based accounting iscertainly the application that will probably mandate the highestdegree of reliability amongst the applications discussed below. The reliability requirements defined in sections 5.1 and 6.3.2. are notsufficient to guarantee the level of reliability that is needed formany usage-based accounting systems. Particular reliabilityrequirements for accounting systems are discussed in [RFC2975].3.1. Usage-based AccountingSeveral new business models for selling IP services and IP-basedservices are currently under investigation. Beyond flat rateservices which do not need accounting, accounting can be based ontime or volume. Accounting data can serve as input for billingsystems. Accounting can be performed per user or per user group, it can be performed just for basic IP service or individually per high- level service and/or per content type delivered. For advanced/future services, accounting may also be performed per class of service, per application, per time of day, per (label switched) path used, etc. Quittek, et al. Informational [Page 6]3.2. Traffic ProfilingTraffic profiling is the process of characterizing IP flows by using a model that represents key parameters of the flows such as flowduration, volume, time, and burstiness. It is a prerequisite fornetwork planning, network dimensioning, trend analysis, businessmodel development, and other activities. It depends heavily on theparticular traffic profiling objective(s), which statistics, andwhich accuracy are required from the measurements. Typicalinformation needed for traffic profiling is the distribution of used services and protocols in the network, the amount of packets of aspecific type (e.g., percentage of IPv6 packets) and specific flowprofiles.Since objectives for traffic profiling can vary, this applicationrequires a high flexibility of the measurement infrastructure,especially regarding the options for measurement configuration andpacket classification.3.3. Traffic EngineeringTraffic Engineering (TE) comprises methods for measurement,modelling, characterization and control of a network. The goal of TE is the optimization of network resource utilization and trafficperformance [RFC2702]. Since control and administrative reaction to measurement results requires access to the involved network nodes, TE mechanisms and the required measurement function usually areperformed within one administrative domain. Typical parametersrequired for TE are link utilization, load between specific networknodes, number, size and entry/exit points of the active flows androuting information.3.4. Attack/Intrusion DetectionCapturing flow information plays an important role for networksecurity, both for detection of security violation, and forsubsequent defense. In case of a Denial of Service (DOS) attack,flow monitoring can allow detection of unusual situations orsuspicious flows. In a second step, flow analysis can be performedin order to gather information about the attacking flows, and forderiving a defense strategy.Intrusion detection is a potentially more demanding application which would not only look at specific characteristics of flows, but mayalso use a stateful packet flow analysis for detecting specific,suspicious activities, or unusually frequent activities. Suchactivities may be characterized by specific communication patterns,detectable by characteristic sequences of certain packet types. Quittek, et al. Informational [Page 7]3.5. QoS MonitoringQoS monitoring is the passive measurement of quality parameters forIP flows. In contrast to active measurements, passive measurementsutilize the existing traffic in the network for QoS analysis. Since no test traffic is sent, passive measurements can only be applied in situations where the traffic of interest is already present in thenetwork. One example application is the validation of QoS parameters negotiated in a service level specification. Note thatpassive/active measurement is also referred to as non-intrusive/intrusive measurement or as measurement ofobserved/synthetic traffic.Passive measurements cannot provide the kind of controllableexperiments that can be achieved with active measurements. On theother hand passive measurements do not suffer from undesired sideeffects caused by sending test traffic (e.g., additional load,potential differences in treatment of test traffic and real customer traffic).QoS monitoring often requires the correlation of data from multipleobservation points (e.g., for measuring one-way metrics). Thisrequires proper clock synchronization of the involved meteringprocesses. For some measurements, flow records and/or notifications on specific events at the different observation points must becorrelated, for example the arrival of a certain packet. For this,the provisioning of post-processing functions (e.g., the generationof packet IDs) at the metering processes would be useful. Since QoS monitoring can lead to a huge amount of measurement result data, itwould highly benefit from mechanisms to reduce the measurement data, like aggregation of results and sampling.Please note that not all requirements for QoS monitoring are covered by the IPFIX requirements specified in the following sections. TheIPFIX requirements are targeted at per flow information includingsummaries of per-packet properties for packets within a flow, but not per-packet information itself. For example jitter measurementrequires timestamping each packet and reporting of all timestamps of a flow, but the IPFIX requirements only cover timestamps of first and last packet of a flow.4. Distinguishing FlowsPackets are mapped to flows by evaluating their properties. Packets with common properties are considered to belong to the same flow. A packet showing at least one difference in the set of properties isconsidered to belong to a different flow.Quittek, et al. Informational [Page 8]The following subsections list a set of properties which a meteringprocess must, should, or may be able to evaluate for mapping packets to flows. Please note that requiring the ability to evaluate acertain property does not imply that this property must be evaluated for each packet. In other words, meeting the IPFIX requirementsmeans that the metering process in general must be able, via itsconfiguration, to somehow support to distinguish flows via all themust fields, even if in certain circumstances/for certainapplications, only a subset of the must fields is needed andeffectively used to distinguish flows.Which combination of properties is used for distinguishing flows and how these properties are evaluated depends on the configuration ofthe metering process. The configured choice of evaluated properties strongly depends on the environment and purpose of the measurementand on the information required by the collecting process. But inany case, a collecting process must be able to clearly identify, for each received flow record, which set of properties was used fordistinguishing this flow from other ones.For specific deployments, only a subset of the required propertieslisted below can be used to distinguish flows. For example, in order to aggregate the flow records and reduce the number of flow recordsexported. On the other hand, some other deployments will requiredistinguishing flows by some extra parameters, such as the TTL field of the IP header or the BGP Autonomous System number [RFC1771] of the IP destination address.4.1. EncryptionIf encryption is used, the metering process might not be able toaccess all header fields. A metering process must meet therequirements stated in this section 4 only for packets that have the relevant header fields not encrypted.4.2. InterfacesThe metering process must be able to separate flows by the incominginterface or by the outgoing interface or by both of them.4.3. IP Header FieldsThe metering process must be able to separate flows by the following fields of the IP header:1. source IP address2. destination IP addressQuittek, et al. Informational [Page 9]3. protocol type (TCP, UDP, ICMP, ...)For source address and destination address, separating by full match must be supported as well as separation by prefix match.The metering process should be able to separate flows by the IPversion number if the observation point is located at a device thatis supporting more than one IP version.4.4. Transport Header FieldsThe metering process must be able to separate flows by the portnumbers of the transport header in case of TCP or UDP being used astransport protocol. The metering process should be able to separate flows by the port numbers of the transport header in case of SCTP[RFC2960].For separation, both, source and destination port number must besupported for distinguishing flows, individually as well as incombination.4.5. MPLS LabelIf the observation point is located at a device supportingMultiprotocol Label Switching (MPLS, see [RFC3031]) then the metering process must be able to separate flows by the MPLS label.4.6. DiffServ Code PointIf the observation point is located at a device supportingDifferentiated Services (DiffServ) then the metering process must be able to separate flows by the DiffServ Code Point (DSCP, see[RFC2474]).5. Metering ProcessThe following are requirements for the metering process. Allmeasurements must be conducted from the point of view of theobservation point.5.1. ReliabilityThe metering process must either be reliable or the absence ofreliability must be known and indicated. The metering process isreliable if each packet passing the observation point is meteredaccording to the configuration of the metering process. If, e.g., Quittek, et al. Informational [Page 10]due to some overload, not all passing packets can be included intothe metering process, then the metering process must be able todetect this failure and to report it.5.2. SamplingSampling describes the systematic or random selection of a subset of elements (the sample) out of a set of elements (the parentpopulation). Usually the purpose of applying sampling techniques is to estimate a parameter of the parent population by using only theelements of the subset. Sampling techniques can be applied forinstance to select a subset of packets out of all packets of a flowor to select a subset of flows out of all flows on a link. Sampling methods differ in their sampling strategy (e.g., systematic orrandom) and in the event that triggers the selection of an element.The selection of one packet can for instance be triggered by itsarrival time (time-based sampling), by its position in the flow(count-based sampling) or by the packet content (content-basedsampling).The metering process may support packet sampling. If sampling issupported, the sampling configuration must be well defined. Thesampling configuration includes the sampling method and all itsparameters.If the sampling configuration is changed during operation, the newsampling configuration with its parameters must be indicated to allcollecting processes receiving the affected flow records. Changingthe sampling configuration includes: adding a sampling function tothe metering process, removing a sampling function from the metering process, change sampling method, and change sampling parameter(s).In case of any change in the sampling configuration, all flow records metered by the previous sampling configuration must be terminated and exported according to the export configuration. The metering process must not merge the flow records generated with the new samplingconfiguration with the flow records generated with the previoussampling configuration.5.3. Overload BehaviorIn case of an overload, for example lack of memory or processingpower, the metering process may change its behavior in order to cope with the lack of resources. Possible reactions include:Quittek, et al. Informational [Page 11]- Reduce the number of flows to be metered. This can beachieved by more coarse-grained flow measurement or by arestriction of the flow records to a subset of the set oforiginal ones.- Start sampling packets before they are processed by themetering process or - if sampling is already performed -reduce the sampling frequency.- Stop metering.- Reducing the resource usage of competing processes on thesame device. Example: reducing the packet forwardingthroughputOverload behavior is not restricted to the four options listed above. But in case the overload behavior induces a change of the meteringprocess behavior, the overload behavior must be clearly defined.For some flows, the change of behavior might have an impact on thedata that would be stored in the associated flow records after thechange, for example if the packet classification is changed or thesampling frequency. These flows must be considered as terminated and the associated flow records must be exported separately from new ones generated after the behavior change. The terminated flow records and new ones generated after the behavior change must not be merged bythe metering process. The collecting process must be able todistinguish the affected flow records generated before and after the change of behavior. This requirement does not apply to flows andassociated flow records not affected by the change of meteringprocess behavior.5.4. TimestampsThe metering process must be able to generate timestamps for thefirst and the last observation of a packet of a flow at theobservation point. The timestamp resolution must be at least the one of the sysUpTime [RFC3418], which is one centisecond.5.5. Time SynchronizationIt must be possible to synchronize timestamps generated by a metering process with Coordinated Universal Time (UTC).Note that the possibility of synchronizing timestamps of each single metering process with UTC implies the possibility of synchronizingtimestamps generated by different metering processes.Quittek, et al. Informational [Page 12]Note that this does not necessarily imply that timestamps generatedby the metering process are UTC timestamps. For example, thisrequirement can be met by using local system clock values astimestamps and adding an additional timestamp when exporting a report to a collecting process. Then the collecting process can synchronize the timestamps by calculating the offset between UTC and the systemclock of the metering process.5.6. Flow ExpirationThe metering process must be able to detect flow expirations. A flow is considered to be expired if no packet of this flow has beenobserved for a given timeout interval. The metering process maysupport means for detecting the expiration of a flow before a timeout occurs, for example by detecting the FIN or RST bits in a TCPconnection. The procedure for detecting a flow expiration must beclearly defined.5.7. Multicast FlowsFor multicast flows containing packets replicated to multiple output interfaces, the metering process should be able to maintain discrete flow records per different output interface. For example, themetering process should be able to report an incoming multicastpacket that is replicated to four output interfaces in four different flow records that differ by the output interface.5.8. Packet FragmentationIn case of IP packet fragmentation and depending on theclassification scheme, only the zero-offset fragment of a singleinitial packet might contain sufficient information to classify thepacket. Note that this fragment should be the first one generated by the router imposing the fragmentation [RFC791], but might not be the first one observed by the IPFIX device, due to reordering reasons.The metering process may keep state of IP packet fragmentation inorder to map fragments that do not contain sufficient headerinformation correctly to flows.5.9. Ignore Port CopyThe metering process may be able to ignore packets which aregenerated by a port copy function acting at the device where theobservation point of a flow is located.Quittek, et al. Informational [Page 13]。
