rfc3176.InMon Corporation’s sFlow A Method for Monitoring Traffic in Switched and Routed Networks
华为 sFlow技术白皮书
采集器灵活、随需的部署：由于网络流的分析和统计工作由采集器完成，采集器 可以灵活的配置网络流特征进行统计分析，实现灵活、随需的部署。
1.2 参考标准和协议
本特性的参考资料清单如下：
文档 sFlow version 5 RFC 3176 RFC 1014
sFlow 采样
sFlow Agent 提供了两种采样方式供用户从不同的角度分析网络流量状况，分别为 Flow 采样以及 Counter 采样。
Flow 采样
Flow 采样是 sFlow Agent 设备在指定端口上按照特定的采样方向和采样比对报文进行 采样分析，用于获取报文数据内容的相关信息，Flow 采样支持获取的采样信息如表 11 所示。该采样方式主要是关注流量的细节，这样就可以监控和分析网络上的流行为。
字段内容
说明
Generic Interface Counters
通用接口统计信息，包括接口的基本信 息，通用的接口流量统计。
Ethernet Interface Counters
针对于 Ethernet 接口，用于统计 Ethernet 相关的流量统计信息。
Processor Information
Flow 采样是针对接口上报文的采样方式，目前仅支持报文随机采样模式。随机采样模 式是指针对每一个接口处理的报文给一个随机值（假定随机数的取值范围为 0～N）， 设置一个阈值 n（n 属于 0～N，范围包含 0 和 N），当报文的随机值小于这个阈值时， 报文采样，这样实际的采样比为 n/(N+1)。
IPv4 Data
针对 IPv4 报文，解析报文的 IPv4 头信息，将解析数据封装到 sFlow 报文中发送给 Collector。
sflow总结
目录8 sFlow8.1 介绍8.2 参考标准和协议8.3 可获得性8.4 原理描述8.4.1 sFlow Agent的基本原理8.5 应用8.5.1 sFlow典型应用8.6 术语与缩略语8 sFlow∙8.1 介绍∙8.2 参考标准和协议∙8.3 可获得性∙8.4 原理描述∙8.5 应用∙8.6 术语与缩略语8.1 介绍定义sFlow是Sampled Flow的简称，由Inmon提出，是一种用于监控数据网络上交换机或者路由器流量转发状况的技术。
sFlow系统包括若干sFlow Agent（内嵌于交换机或者路由器等转发设备）以及一个核心的sFlow Collector。
sFlow Agent通过特定的采样技术获取网络设备上的流量转发统计并实时地通过sFlow数据报文发送到Collector以供Collector进行分析，通过生成流量视图或者报表的形式，帮助网络管理员更加有效地管理整个站点（通常是企业级站点）的网络流量。
目的相对于电信级网络，企业级网络通常具有规模相对较小、组网灵活、易受攻击等特点，因此企业级网络更容易出现由组网或者攻击导致的流量业务异常，因此企业用户更需要一种以设备端口为基本采样单元的流量监控技术来实时监控流量状况以及及时发现异常流量以及攻击流量的源头，从而保证企业网络的正常稳定运行。
一个典型的sFlow系统提供了一组Agent以及一个Collector，Agent内嵌于网络设备，负责采集相关的流量统计信息；Collector的角色通常由专门的服务器充当，通过在服务器上运行sFlow trend等专门的sFlow Collector软件，收集Agent发送过来的统计数据，以图形化的统计信息汇总或者以报表的形式输出。
为企业用户特别是不设置专职网络管理员的企业用户的日常巡检维护提供了极大的方便。
8.2 参考标准和协议本特性的参考资料清单如下：8.3 可获得性License支持无需获得License许可，均可获得该特性的服务。
rfcomm_tutorial
RS-232serial ports have nine circuits, which can be used for transferring data and sig-nalling. RFCOMM can emulate the serial cable line settings and status of an RS-232 ser-ial port. RFCOMM provides multiple concurrent connections by relying on L2CAP to handle multiplexing over single connections, and to provide connections to multiple de-vices.RFCOMM relies on the Bluetooth baseband to provide reliable in-sequence deliv-ery of byte streams. It does not have any ability to correct errors. RFCOMM’s flow con-trol also uses the baseband’s capabilities.RFCOMM data rates will be limited in devices where there is a physical serial port involved (Type 2 devices). Implementations may optionally pace data on virtual serial ports (in Type 1 devices). In the absence of pacing, RFCOMM will deliver the highest possible data rate, although what the highest data rate is can be a complicated issue in the presence of multiple connections (see Chapter 18).RFCOMM is a simple, reliable transport protocol with framing, multiplexing, and the following additional provisions:•Modem status—RTS/ CTS, DSR/ DTR, DCD, ring.•Remote line status—Break, overrun, parity.•Remote port settings—Baud rate, parity, no of data bits etc.•Parameter negotiation (frame size).172Bluetooth: Connect Without CablesBy Jennifer Bray and Charles Thurman© 2001 by Prentice Hall PTRPrentice-Hall, Inc.Upper Saddle River, NJ 07458Types of RFCOMM Devices173 10.1SERIAL PORTS AND UARTSTypically, serial port transmit and receive data lines are connected to a UART (UniversalAsynchronous Receiver Transmitter). The job of the UART is to convert between theserial data sent down cables and the parallel data processing which devices use. UARTsuse buffers to convert between serial and parallel data. This allows them to reduce theload on the processor. Instead of the processor having to be interrupted for every singlebit that is sent down the cables, the UART transfers the bits between the cables andbuffers, then the processor only has to get involved when there is a whole buffer to dealwith.The signals from a UART are connected, so they appear in the system address map.Some processors reserve a special range of addresses for I/O; other systems can map theminto any part of normal memory. Because UARTs look like areas of memory to a micro-processor, it is possible to emulate a serial port in software by taking an area of memoryand setting values as they would appear if they were set by a UART.The Bluetooth RFCOMM specification talks about emulating the nine circuits of an RS-232 serial port, and specifies how a serial data stream can be emulated. But becausethe serial stream from an RS-232 port is viewed by the microprocessor after it has beenthrough a UART, software dealing with serial ports is actually handling parallel data.Similarly, RFCOMM software deals with parallel data delivered by the lower layers ofthe Bluetooth stack.A UART connects to some piece of hardware: wires or buffers. RFCOMM connectsup to the lower layers of the software stack via L2CAP.10.2TYPES OF RFCOMM DEVICESRFCOMM supports two types of devices:•Type 1—Internal emulated serial port(or equivalent).•Type 2—Intermediate device with physical serial port.A protocol stack for a Type 1 RFCOMM device is shown at the left of Figure 10–1.The port emulation entity maps a system specific communication interface (API) to the RFCOMM services. This can be used to connect to legacy applications as shown, or it canbe used to connect to applications specifically written for Bluetooth. A Type 1 devicewould usually be the end of a communication path, for example, a PC or printer.A protocol stack for a Type 2 RFCOMM device is shown at the right ofFigure10–1. The port proxy entity relays data from RFCOMM to an external RS-232 interface linked to another device. Type 2 devices are intermediate devices which sit in the middle of a communication path. A modem is an example of a Type 2device.10.3RFCOMM FRAME TYPESRFCOMM is based on GSM TS 07.10,which is an asymmetric protocol used by GSM cellular phones to multiplex several streams of data onto one physical serial cable. RFCOMM is symmetric, and sends TS 07.10 frames over L2CAP using a subset of TS 07.10 feature frames and commands. Some of TS 07.10’s features are adapted for Blue-tooth.RFCOMM communicates with frames. The RFCOMM frames become the data payload in L2CAP packets. There are five different frame types:•SABM—Start Asynchronous Balanced Mode (startup command).•UA—Unnumbered Acknowledgement (response when connected).•DISC—Disconnect (disconnect command).•DM—Disconnected Mode (response to a command when disconnected).•UIH—Unnumbered Information with Header check.SABM, UA, DM, and DISC are “low- level” control frames. RFCOMM uses chan-nels, each of which has a Data Link Connection Identifier (DLCI). UIH frames on DLCI = 0 are used to send control messages. UIH frames on DLCIs ≠0 are used to send data.174RFCOMMLegacy ApplicationPort Emulation EntityRFCOMMHost Controller InterfaceLink Manager Link ControllerRadioL2CAPDCE (e.g. A Modem)Port Proxy EntityRFCOMMHost Controller InterfaceLink Manager Link ControllerRadioL2CAPRS-232CableFigure 10–1Type 1 and Type 2 RFCOMM devices.Connecting and Disconnecting175 GSM TS 07.10 also has optional UI (Unnumbered Information) frames; RFCOMM doesn’t use these.10.4CONNECTING AND DISCONNECTINGBecause RFCOMM frames are carried in the payload of L2CAP packets, an L2CAP con-nection must be set up before an RFCOMM connection can be set up.RFCOMM has a reserved Protocol and Service Multiplexor (PSM) value for L2CAP. This is defined in the Bluetooth core specification as 0x0003. Any L2CAP frames received with this value in the PSM field will be sent to RFCOMM for processing.The first frame to be sent on an RFCOMM channel is a SABM frame; this is a Start Asynchronous Balanced Mode command. If the responding device’s RFCOMM is willing to connect, it goes into Asynchronous Balanced Mode (ABM), and sends back an UA frame. If the responding device’s RFCOMM doesn’t want to connect, it refuses the con-nection by sending a DM frame. Figure 10–2 shows an RFCOMM channel setup being refused in this way.RFCOMM has a 60s timer which is started when a command is sent. If an acknowl-edgement isn’t received when the timer elapses, the connection will be shut down. This is different from GSM 07.10, which resends the command when the timer elapses. In the case of RFCOMM, the Bluetooth baseband provides a reliable link, so if the command wasn’t acknowledged first time, it is not likely to be acknowledged a second time. For the SABM command, the timeout can be extended because security procedures might mean that this command takes longer to process than others. If RFCOMM ever times out and disconnects, it must send a DISC (disconnect) command frame on the same DLCI as the original SABM frame just in case the other side has come back into range and thinks the connection is still active. Figure 10–3 shows a channel being closed down because the ini-tiator timed out.If the connection succeeds, the responder replies to the SABM frame with a UA (un-numbered acknowledgement) frame. This is followed by a Parameter Negotiation (PN) command from the initiator and PN response from the responder, as shown in Figure 10–4.Set up L2CAP channel for RFCOMMwith PSM = 0x0003For first RFCOMM connection,try to start multiplexorResponder refusesL2CAP connection is not needed(because it uses PSM = 0x0003,it can’t be used for other services)Figure 10–2Refusing an RFCOMM connection.176RFCOMMSet up L2CAP channel for RFCOMM with PSM = 0x0003For first RFCOMM connection,try to start multiplexor Timeout and send DISC frame L2CAP connection is not needed (because it uses PSM = 0x0003,it can ’t be used for other services)Figure 10–3RFCOMM channel timeout.Set up L2CAP channel for RFCOMM with PSM = 0x0003For first RFCOMM connection,start multiplexorOptionally negotiate parameters for data link connectionOpen data link connection;optionally negotiate securityExchange modem status commands and responsesExchange data on the connectionFigure 10–4Message sequence chart for establishing an RFCOMM connection.Once a connection with DLCI = 0 has been set up, this is available for RFCOMM signalling. To transfer data, other RFCOMM channels must be set up. Figure 10–4 shows a second RFCOMM channel being set up to transfer data. In this case, the channel re-quires authentication, so there is a pause for LMP authentication and encryption between the SABM command frame and the UA response frame. Once the UA frame has been re-ceived, modem status commands are exchanged to communicate the state of the controlsignals. Data can then be transferred immediately as shown, or there could be an ex-change of PN command and response to configure the new connection’s parameters.The user data should include MSCs (Modem Status Commands), which communi-cate the state of serial port control signals.To shut down an RFCOMM connection, a DISC command is sent. When the last data link has been shut down, a DISC should be sent on DLCI=0 to shut down the multi-plexor. Then, whichever device shut down the multiplexor is responsible for disconnect-ing the L2CAP channel.10.5STRUCTURE OF RFCOMM FRAMESRFCOMM borrows its frame structure from the GSM 07.10 standard. Figure 10–5 shows the frame structure for the GSM 07.10 basic option. (There is also an advanced option,which lacks the length field; RFCOMM always uses the basic option.)Figure 10–6 shows the structure of an RFCOMM frame. This is identical to the GSM07.10 basic option frame except that RFCOMM misses out the start and end flags,and RFCOMM has to limit the number of bytes in a packet because of the limit on the size of L2CAP packets.RFCOMM doesn’t need the start and end flags because each RFCOMM frame is carried in a single L2CAP packet. There is no need to pick RFCOMM frames out of a data stream, so there is no need for flag bits to mark where the frames start and end.10.5.1Address FieldAn RFCOMM frame begins with an address field. This identifies which of the many mul-tiplexed channels the frame belongs to. The address field is split up as shown in Fig-ure 10–7.Structure of RFCOMM Frames 177FCSData (Integral Number of Bytes)Length or DataLengthControlAddress162432282012840Flag =10011111Flag =10011111Figure 10–5Structure of a GSM07.10 basic option frame.The EA (Extend Address) field can be used to extend an address. If EA=0, then more address octets follow; if EA=1, then this is the last octet of the address. Since the Bluetooth specification says that server applications are assigned a server channel number in the range 1 to 30 and an RFCOMM address frame has 5 bits for the server channel,there will never be any need to use extended addressing, so the EA bit will always be set to 1 in an RFCOMM address field.The C/R (Command/Response) bit says whether the frame is a command or a re-sponse. Its value depends not only on whether the frame carries a command or a response,but also on which end of the channel is sending the frame. The device which set up the connection (by sending a SABM command on DLCI 0) is called the initiator. The device which responded (by sending the UA response on DLCI 0) is called the responder. As long as the traffic follows this original pattern, the C/R bit is 1, so commands from the ini-tiator and responses from the responder have C/R = 1. For exchanges in the opposite di-rection, the C/R bit is 0, so commands from the responder and responses from the initiator have C/R = 0. When sending data, the initiator sets C/R = 1 and the responder sets C/R = 0. Figure 10–8 illustrates how the C/R bit is set.After the C/R bit comes the Data Link Connection Identifier (DLCI). In GSM TS0.10, this is one undivided field, but in RFCOMM, it is split up into a direction bit and a server channel number. The initiator always sets the direction bit to 1 (D=1); the respon-der always sets the direction bit to 0 (D=0). As with the C/R bits, who is the initiator and responder is defined by which device sent the SABM frame to start up the connection.The server channel number has 5 bits; this would give it a range from 0 to 31, but 0and 31 are reserved, so only 1 to 30 can be allocated as server channel numbers for ser-vices. Channel 0 is used for sending control information; channel 31 is reserved by TS 07.10. Bluetooth avoids using channels which are reserved by TS 07.10 to preserve com-patibility with TS 07.10 applications.178RFCOMM FCSData (0 - 32767 Bytes)Length or DataLengthControlAddress162432282012840Figure 10–6Structure of an RFCOMM frame.DServer ChannelC/REA =146875321Figure 10–7Address field.The DLCI is calculated once before the data link connection is established. The RFCOMM server channel number in the responding device is used for the DLCI. Because server channel numbers 1 to 30 are available, one device can have up to 30 services using RFCOMM.10.5.2Control FieldReferring back to Figure 10–6, the next field in an RFCOMM frame is the control field. This is used to identify the type of the frame. Table 10–1 shows the control field values used in RF-COMM frames. (These match the values used in the corresponding GSM TS 07.10 Frames.)P/F is the Poll/Final bit. In commands, it is called the P (Poll) bit; in responses, it is called the F (Final) bit.Structure of RFCOMM Frames 179For first RFCOMM connection,initiator starts multiplexor C/R = 1Command from initiator Response from responder C/R = 1Command from responder Response from initiator C/R = 0Data from responder Data from initiatorC/R set as for commandsFigure 10–8Settings of C/R bit in RFCOMM exchanges.Table 10–1Control Field ValuesControl Bit Number12345678SABM (Set Asynchronous 1111P/F 100Balanced Mode)UA (Unnumbered Acknowledgement)1100P/F 110DM (Disconnect Mode)1111P/F 000DISC (Disconnect)1100P/F 011UIH (Unnumbered Information with 1111P/F111Header Check)A command with its P bit set to 1 is used when a response or a series of responses is wanted from the device at the far end of the link. The responding device should send back its responses with the F bit set to 1. There should only ever be one command frame with P bit set to 1 waiting for a response.DM packets are processed regardless of the state of the P/F bit, but SABM or DISC commands and UA responses are thrown away if the P/F bit is set to zero.10.5.3Length FieldThe length field begins with an EA bit as shown in Figure 10–9. If this is 1, then it is fol-lowed by 7 bits of length, so the length field is one byte long. If the EA bit is 0, then it is followed by 15 bits of length, so the length field is two bytes long.The default length of an RFCOMM frame is 32 bytes; the maximum length is 32767.10.5.4DataThe data field is only present in UIH frames. There must be an integral number of bytes in the data up to 32767. The size limit is set by the Maximum Transmission Unit (MTU) on L2CAP packets, so if a system has a smaller L2CAP MTU, the size of RFCOMM data will also be restricted.10.5.5Frame Check SequenceTo calculate the FCS:Count up k,the number of bits the FCS will be calculated on. For SABM, DISC,UA, and DM frames, the frame check sequence is calculated on the address control and length fields. For UIH frames, it is calculated on the address and control fields.Then:(a)Calculate the remainder of x k ( x 7+ x 6x 5+ x 4+ x 3+ x 2+ x 1+ 1) divided modulo 2by the generator polynomial ( x 8+ x 2+ x + 1).(b)Take the contents of the frame that the FCS is calculated over before any start andstop elements have been inserted, and before any other extra bits have been in-serted. Multiply by x 8and divide by the generator polynomial ( x 8+ x 2+ x + 1).(c)Add the results of (a) and (b) modulo 2, and take the 1’s complement to get the FCS.180RFCOMM7 bits of Length FieldEA =1812161410642015 bits of Length FieldEA =0Figure 10–9Structure of RFCOMM length fields.Multiplexor Frames 181 Because UIH frames only calculate FCS on the address and control fields, their data field is not protected by the FCS. This might be a drawback for reliable data transmission,but it does have the advantage that the FCS patterns can be pre-calculated for all theDLCIs that are in use. This pre-calculation could be done when the channel is set up.10.6MULTIPLEXOR FRAMESMultiplexor commands and responses are sent on DLCI = 0. They are used to control theRFCOMM link. There are seven types of commands or responses:•PN—DLC parameter negotiation.•Test—Checks communication link.•FCon / FCoff—Aggregate flow control on all connections.•MSC—Modem status, used for flow control per connection.•RPN—Remote Port Negotiation.•RLS—Remote Line Status.•NSC—Non-Supported Command (response only).The multiplexor commands and responses are carried as messages inside an RFCOMM UIH frame as shown in Figure 10–10. It is possible to send several multi-plexor command messages in one RFCOMM frame, or to split a multiplexor commandmessage over more than one frame.10.6.1PN—DLC Parameter NegotiationThe PN command is used to negotiate the parameters of a data link connection. PN com-mands are exchanged before a new data link connection is opened, although this is not com-pulsory. If no PN commands are sent, default parameters will be used for the connection.A PN command is identified by the type field shown in Figure 10–11. This typefield is the first information byte in the UIH frame carrying the PN command (see Figure DLCI = 0Control = UIH Length Information FCSType Length Value 1Value 2 …Value NFigure 10–10Structure of an RFCOMM multiplexor control frame.10–11). The EA bit is 1 because the type field occupies one byte. The C/R bit is used to indicate whether the message is a command or a response.The length field in a PN message is always set to 8, and the value field contains 8bytes as shown in Figure 10–12. These bytes define the parameters which will be used on a data link connection as follows:•Six DLCI bits identify the data link connection for which parameters are being ne-gotiated.•Two padding bits which are always set to zero follow the DLCI; these are inserted to avoid splitting parameters across bytes.•Four I bits give the type of frames used to carry information on the channel. In RF-COMM UIH frames indicated by the value 0b1000 are used.182RFCOMMType = 000001C/REA =146875321Figure 10–11Type field for Parameter Negotiation (PN).0b00DLCICL (Convergence Layer to Use)=0b0000I (Type of Frame for Information)= 0b1000 for UIH Frames0b00P (priority)T (Value of Acknowledgement Timer)60-second Timer = 0b00000000N (Maximum Frame Size - 16 bits)NA (Maximum Number of Retransmissions) = 0b000000000b00000K (Error Recovery Window)=0b00046875321Figure 10–12Content of value bytes in a PN message.Multiplexor Frames183•Four CL bits give the convergence layer to used. RFCOMM uses Type 1 (unstruc-tured octet stream) = 0b0000 in versions after 1.0b this may also be set to 0x0F toenable credit based flow control.•Six P bits assign a priority to the data link connection: 0 is the lowest priority, 63 isthe highest.•Two padding bits which are always set to zero follow the P bits; these are insertedto avoid splitting parameters across bytes.•Eight T bits give the value of the acknowledgement timer, in GSM 07.10, thiswould be used to trigger a retransmit; in RFCOMM, if the timer elapses, the con-nection is closed down. The timer’s value is not negotiable, but is fixed at 60s. Thisfield is set to 0 to indicate that the timer is not negotiable.•Sixteen N bits give the maximum size of the frame.•Eight NA bits give the maximum number of retransmissions. Because the Bluetoothbaseband gives RFCOMM a reliable transport layer, RFCOMM will not retransmit,so this value is set to zero.•Three K bits define the window size for error recovery mode. RFCOMM uses basicmode, so these bits are not interpreted by RFCOMM.•Five padding bits set to zero fill the rest of the last value field to round up the valuesto an integral number of bytes.All parameters being negotiated are sent with the LSB in bit 1; this is the general rule for RFCOMM information.It is worth noting that RFCOMM follows the conventions of the GSM 07.10 stan-dard and numbers the bits in a frame from 1 for the least-significant bit to 8 for the most significant bit. This may be confusing to people who are used to seeing the bits in a byte numbered from 0 to 7.One device sends a PN message, and the other responds with another PN message.The response may not change the DLCI, the priority, the convergence layer, or the timer value. The response may send back a different timer value. In this case, the device which sent the first PN messages will still use the timer it proposed, but the device at the other end of the connection will use the value it sent in its message.The response may have a smaller value for the maximum frame size, but it may not propose a larger value for this parameter.In GSM 07.10, PN messages are optional. In RFCOMM, support of the PN message and its response are compulsory, although if default parameters are satisfactory, PN mes-sages do not have to be sent. PN messages may be exchanged until the device which sent the first message is happy with the parameters it gets sent back to it. Once it has a satis-factory set of parameters in the reply, it can go on to set up the connection.10.6.2TestThe test command is used to check the RFCOMM connection. As is normal, the length byte gives the number of value bytes which follow. The number of value bytes is not fixed, and is used to hold a test pattern. The remote end of the link echoes the same value bytes back.The type field for the test command is shown in Figure 10–13. Because only a sin-gle byte is used, the EA bit is set to 1. The C/R bit is used to indicate whether the message is a command or a response.10.6.3FCon / FCoff—Aggregate Flow Control on All ConnectionsRFCOMM has a flow control mechanism which applies to all channels between two RFCOMM entities. When either RFCOMM entity can’t receive RFCOMM information,it sends a Flow Control off (FCoff) command. When it is able to receive data again, it sends a Flow Control on (FCon) command.The structure of the type field for the two flow control commands is shown in Fig-ure 10–14. Both begin with an EA bit, which is 1 to indicate that there is only one byte in the command type. The length field in the frame carrying the command is set to zero be-cause there is no other data in the frame. The C/R bit is used to indicate whether the mes-sage is a command or a response.10.6.4MSC—Modem Status CommandRFCOMM also has a flow control mechanism which can be applied to just one channel at a time. This is the Modem Status Command (MSC), and it is indicated by the type field shown in Figure 10–15. The EA bit is 1 because the type field occupies one byte. The C/R bit is used to indicate whether the message is a command or a response.The command field of the MSC contains virtual V.24 control signals, that is to say the settings that the RS-232 control wires would have if the RFCOMM data were being transferred across wires rather than across a Bluetooth connection. The signals in the command field are as follows:•EA—Extended Address, set to 1 to indicate there is only 1 byte of command.•FC—Flow Control bit, set to 1 when a device is unable to accept any RFCOMM frames. When the device is able to receive again, it sends another MSC with the flow control bit set to 0.•RTC—Ready To Communicate bit, set to 1 when the device is ready to communi-cate.184RFCOMMType = 0b000100C/REA =146875321Figure 10–13Type field for test.•RTR—Ready To Receive bit, set to 0 when the device cannot receive data and 1when it can receive data.•IC—Incoming Call, 1 indicates an incoming call.•DV—Data Valid, set to 1 to indicate that valid data is being sent.These values may not seem to make sense when sent in a packet, but that is because they map onto the lines of an RS-232 interface. It might be obvious when a packet is sent that it is going to have valid data; who would bother to send a packet with invalid data?However, when dealing with physical serial port lines, such signals make more sense. A signal to say that valid data is being sent can be used to activate circuits to handle the data. The MSC command just mimics the values of the V.24 signals, which would be used on a wired RS-232 -interface.The signals from an MSC map onto RS-232 signals as follows:•RTC maps onto DSR (Data Set Ready) and DTR (Data Terminal Ready).•RTR maps onto RTS (Request To Send) and CTS (Clear To Send).•IC maps onto RI (Ring Indication).•DV maps onto DCD (Data Carrier Detect).Figure 10–16 shows how the signals are carried in the control field of the command. The MSC is sent on a connection before any data is sent to establish the state of the RS-232 control signals. It should also be sent whenever the signals need to be changed.In the MSC, the state of the signals in the device sending the command is sent. The response just carries a copy of the signals from the command.Multiplexor Frames185FC On = 0b000101C/REA =1FC Off = 0b000110C/R EA =146875321Figure 10–14Type fields for FCon and FCoff commands.Type = 0b000111C/REA =146875321Figure 10–15Type field for MSC command.186RFCOMMType = 0b001001C/REA =146875321Figure 10–17Type field for RPN.10.6.5RPN—Remote Port NegotiationThe Remote Port Negotiation (RPN) command is used to set communication settings at the remote end of a data link connection. If any of the communication settings need to be changed during a connection, the RPN command can be resent to change them.The RPN type field is shown in Figure 10–17.The EA bit is 1 because the type field occupies one byte. The C/R bit is used to in-dicate whether the message is a command or a response.The length byte in an RPN command is either 1 or 8. If the length is 1, then there is a single value byte which contains the DLCI for the connection, and the message is inter-preted as a request for the link’s parameters. In this case, the remote end replies with the current parameters on the link. If the length byte is set to 8, then eight bytes of link para-meters follow. If they are sent in a command, then they are a request to set up the link’s parameters.Figure 10–18 shows the order of values within an RPN command with length byte set to 8.The parameter mask defines which parameters are being changed by the message.Figure 10–19 shows the position of bits in the RPN parameter mask.In an RPN command, if a parameter mask bit is set to 1, it indicates a particular pa-rameter that should be changed. If it is set to 0, then the parameter is not being changed and the value can be ignored.In an RPN response, if a parameter mask bit is set to 0, then it means the proposal sent in an RLS has not been accepted. Conversely, a parameter mask bit set to 1 means the new value has been accepted, and the sender of the response is now using the new value.The values of the various fields in an RLS command have the same meanings as in GSM 07.10.ReservedFCEA =1RTRRTCDVIC46875321Figure 10–16MSC control signal field.。
rfc3232.Assigned Numbers RFC 1700 is Replaced by an On-line Database
Network Working Group J. Reynolds, Editor Request for Comments: 3232 RFC Editor Obsoletes: 1700 January 2002 Category: InformationalAssigned Numbers: RFC 1700 is Replaced by an On-line DatabaseStatus 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 (2002). All Rights Reserved. AbstractThis memo obsoletes RFC 1700 (STD 2) "Assigned Numbers", whichcontained an October 1994 snapshot of assigned Internet protocolparameters.DescriptionFrom November 1977 through October 1994, the Internet AssignedNumbers Authority (IANA) periodically published tables of theInternet protocol parameter assignments in RFCs entitled, "AssignedNumbers". The most current of these Assigned Numbers RFCs hadStandard status and carried the designation: STD 2. At this time,the latest STD 2 is RFC 1700.Since 1994, this sequence of RFCs have been replaced by an onlinedatabase accessible through a web page (currently, ).The purpose of the present RFC is to note this fact and to officially obsolete RFC 1700, whose status changes to Historic. RFC 1700 isobsolete, and its values are incomplete and in some cases may bewrong.We expect this series to be revived in the future by the new IANAorganization.Security ConsiderationsThis memo does not affect the technical security of the Internet. Reynolds Informational [Page 1]Author’s AddressJoyce K. ReynoldsRFC Editor4676 Admiralty WayMarina del Rey, CA 90292USAEMail: rfc-editor@Reynolds Informational [Page 2]Full Copyright StatementCopyright (C) The Internet Society (2002). All Rights Reserved.This document and translations of it may be copied and furnished toothers, and derivative works that comment on or otherwise explain it or 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 are included 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 ENGINEERINGTASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDINGBUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATIONHEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OFMERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.AcknowledgementFunding for the RFC Editor function is currently provided by theInternet Society.Reynolds Informational [Page 3]。
RFC3376_IGMPv3_中文版
备忘录状态
略
摘要
本文档说明了因特网组管理协议的第3版，IGMPv3。IGMP协议被IPv4系统用于向邻接的多播路由器报告它们的组成员关系。第3版的IGMP增加了对“源过滤”的支持，即系统能够报告它只对接收到的发往某一特定多播组的数据报中，某些来自特定源地址的数据感兴趣，或者是只对除了某些特定源地址之外的数据感兴趣。这个信息能够被多播路由协议用于避免把某些来自特定源地址的多播数据报发往对它不感兴趣的网络。
而离开操作等效于：
IPMulticastListen( socket，interface，multicast-address，INCLUDE {} );
这里{}表示一个空的源列表。
一个关于在该服务接口上提供兼容性的API的例子在[FILTER-API]中。
source-list是0个或多个未排序的IP多播地址的列表。这些地址是希望接收的或者是不希望接收的，这具体取决于filter-mode参数。一个具体的实现可能会对源列表的大小强加一个限制，但是这个限制不能小于每个列表64个地址。当一个操作引起源列表大小的限制被超出，服务接口必须返回一个错误。
请求接收同一个接口i上发往同一个多播地址m的来自源地址b,c,d的数据报。为了同时满足两个socket的接收需求，必须让接口i接收来自源地址a,b,c,d的发往多播地址m的所有数据报。这样的话，在这个例子中，接口i对于多播地址m的接收状态就是mode为INCLUDE，源地址列表为{a,b,c,d}。
多播侦听者发现(MLD)是IPv6系统采用的一种相似的方法，MLD第1版实现了IGMP第2版的功能，MLD第2版实现了IGMP第3版的功能。
2、用于IP多播接收的服务接口
中移动家庭网关终端技术规范v
中国移动通信企业标准QB-╳╳-╳╳╳-╳╳╳╳家庭网关终端技术规范T e c h n i c a l S p e c i f i c a t i o n f o r H o m e G a t e w a y版本号：3.0.0╳╳╳╳-╳╳-╳╳发布╳╳╳╳-╳╳-╳╳实施中国移动通信集团公司发布目录1. 范围 ................................................................................................................................................2. 规范性引用文件 .............................................................................................................................3. 术语、定义和缩略语 .....................................................................................................................4. 设备总体定义.................................................................................................................................4.1.设备在网络中的位置 ..................................................................................................................4.2.接口定义 ......................................................................................................................................4.3.设备类型 ......................................................................................................................................5. 接入型家庭网关 .............................................................................................................................5.1.接口要求 ......................................................................................................................................网络侧接口......................................................................................................................................网络侧接口描述..........................................................................................................................................网络侧以太网接口要求..............................................................................................................................接口要求 .......................................................................................................................................................接口要求 .......................................................................................................................................................接口要求 .......................................................................................................................................................用户侧接口......................................................................................................................................用户侧以太网接口要求..............................................................................................................................接口 ...............................................................................................................................................................接口（可选）................................................................................................................................................5.2.功能要求 ......................................................................................................................................数据通信要求..................................................................................................................................协议要求 .......................................................................................................................................................数据转发功能要求......................................................................................................................................功能要求 .......................................................................................................................................................地址管理及拨号管理功能要求....................................................................................................................地址管理及拨号管理功能要求....................................................................................................................要求 ...............................................................................................................................................................要求 ...............................................................................................................................................................组播要求 .....................................................................................................................................................其他功能要求..............................................................................................................................................安全要求..........................................................................................................................................防火墙 .........................................................................................................................................................登陆WEB页面的安全要求..........................................................................................................................设备安全性 .................................................................................................................................................要求....................................................................................................................................................功能要求............................................................................................................................................扩展及管理（可选）........................................................................................................................设备发现要求.........................................................................................................................................................................................................................................................................................................（可选） .......................................................................................................................................................支持WLAN的开启和禁用............................................................................................................................基本要求 .....................................................................................................................................................多SSID要求................................................................................................................................................安全要求 .......................................................................................................................................................5要求 ............................................................................................................................................................要求 ...............................................................................................................................................................基本应用要求................................................................................................................................... WLAN共享 ..................................................................................................................................................家庭存储（可选）......................................................................................................................................5.3.性能要求 ......................................................................................................................................路由转发性能要求..........................................................................................................................吞吐量 .........................................................................................................................................................地址学习 .....................................................................................................................................................缓存大小 (23)连接数量要求.............................................................................................................................................. 无线性能要求....................................................................................................................................吞吐量性能要求 (23)覆盖性能要求................................................................................................................................................接收灵敏度要求............................................................................................................................................5.4.管理和维护要求 (24)本地管理和配置要求......................................................................................................................本地管理基本要求......................................................................................................................................用户分级管理 (24)系统信息管理..............................................................................................................................................基本配置 .....................................................................................................................................................高级配置 .....................................................................................................................................................设备管理 .....................................................................................................................................................网络诊断 .....................................................................................................................................................设备认证注册功能......................................................................................................................................远程管理要求..................................................................................................................................远程管理基本要求......................................................................................................................................远程参数配置和性能监测..........................................................................................................................远程故障诊断功能......................................................................................................................................设备告警功能..............................................................................................................................................远程链路维持功能......................................................................................................................................软件远程管理..............................................................................................................................................业务部署和控制..........................................................................................................................................上行家庭网关远程管理实现方式 ................................................................................................................日志功能要求..................................................................................................................................5.5.预配置要求 ..................................................................................................................................预配置要求......................................................................................................................................5.6.硬件要求 ......................................................................................................................................基本要求..........................................................................................................................................硬件基本框图示例..........................................................................................................................5.7.软件要求 ......................................................................................................................................基本要求..........................................................................................................................................软件基本架构................................................................................................. 错误!未定义书签。
SFlow详解
网络监控
简介
sFlow 是由InMon、HP 和FoundryNetworks 于2001 年基于标准的最新 网络导出协议（RFC 3176）联合开发的一种网络监测技术，它采用数 据流随机采样技术，可提供完整的第二层到第四层，甚至全网络范围内 的流量信息，可以适应超大网络流量(如大于10Gbit/s)环境下的流量分 析，让用户详细、实时地分析网络传输流的性能、趋势和存在的问题。 通过将sFlow技术嵌入到网络路由器和交换机ASIC芯片中，sFlow已经 成为一项线速运行的“一直在线”技术。sFlow使用嵌入到网络设备中 的sFlow代理转发被采样数据包，与使用镜像端口、探针和旁路监测技 术的传统网络监视解决方案相比，sFlow能够大大降低实施费用，采用 它，一种面向每一个端口的全网络监视解决方案成为可能。
谢谢!
分布式IRF设备 [Device -e1/1] display sflow [chassis ch a s s is -n u m b e r slot slo tn u m b e r]
常见配置错误
故障现象： 远端connector无法收到sflow报文
故障分析： 设备和connector之间的网络物理中断 没有配置Agent IP或connector IP 没有端口使能sFlow 配置的connector IP和远端的Connector IP地址不一致 如果设备没有配置三层扣的ip地址或配置了ip地址段以此ip为源ip的UDP报文无法 到达connector； 故障排除： 1) 检查物理连接 2) 检查设备是否可以和Connector通讯 3) Display sflow查看相关配置是否正确
Байду номын сангаас
rfc4656.A One-way Active Measurement Protocol (OWAMP)
Network Working Group S. Shalunov Request for Comments: 4656 B. Teitelbaum Category: Standards Track A. Karp J. Boote M. Zekauskas Internet2 September 2006 A One-way Active Measurement Protocol (OWAMP)Status of This MemoThis document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions forimprovements. Please refer to the current edition of the "InternetOfficial Protocol Standards" (STD 1) for the standardization stateand status of this protocol. Distribution of this memo is unlimited.Copyright NoticeCopyright (C) The Internet Society (2006).AbstractThe One-Way Active Measurement Protocol (OWAMP) measuresunidirectional characteristics such as one-way delay and one-wayloss. High-precision measurement of these one-way IP performancemetrics became possible with wider availability of good time sources (such as GPS and CDMA). OWAMP enables the interoperability of these measurements.Table of Contents1. Introduction (2)1.1. Relationship of Test and Control Protocols (3)1.2. Logical Model (4)2. Protocol Overview (5)3. OWAMP-Control (6)3.1. Connection Setup (6)3.2. Integrity Protection (HMAC) (11)3.3. Values of the Accept Field (11)3.4. OWAMP-Control Commands (12)3.5. Creating Test Sessions (13)3.6. Send Schedules (18)3.7. Starting Test Sessions (19)3.8. Stop-Sessions (20)3.9. Fetch-Session (24)Shalunov, et al. Standards Track [Page 1]4. OWAMP-Test (27)4.1. Sender Behavior (28)4.1.1. Packet Timings (28)4.1.2. OWAMP-Test Packet Format and Content (29)4.2. Receiver Behavior (33)5. Computing Exponentially Distributed Pseudo-Random Numbers (35)5.1. High-Level Description of the Algorithm (35)5.2. Data Types, Representation, and Arithmetic (36)5.3. Uniform Random Quantities (37)6. Security Considerations (38)6.1. Introduction (38)6.2. Preventing Third-Party Denial of Service (38)6.3. Covert Information Channels (39)6.4. Requirement to Include AES in Implementations (39)6.5. Resource Use Limitations (39)6.6. Use of Cryptographic Primitives in OWAMP (40)6.7. Cryptographic Primitive Replacement (42)6.8. Long-term Manually Managed Keys (43)6.9. (Not) Using Time as Salt (44)6.10. The Use of AES-CBC and HMAC (44)7. Acknowledgements (45)8. IANA Considerations (45)9. Internationalization Considerations (46)10. References (46)10.1. Normative References (46)10.2. Informative References (47)Appendix A: Sample C Code for Exponential Deviates (49)Appendix B: Test Vectors for Exponential Deviates (54)1. IntroductionThe IETF IP Performance Metrics (IPPM) working group has definedmetrics for one-way packet delay [RFC2679] and loss [RFC2680] across Internet paths. Although there are now several measurement platforms that implement collection of these metrics [SURVEYOR] [SURVEYOR-INET] [RIPE] [BRIX], there is not currently a standard that would permitinitiation of test streams or exchange of packets to collectsingleton metrics in an interoperable manner.With the increasingly wide availability of affordable globalpositioning systems (GPS) and CDMA-based time sources, hostsincreasingly have available to them very accurate time sources,either directly or through their proximity to Network Time Protocol(NTP) primary (stratum 1) time servers. By standardizing a technique for collecting IPPM one-way active measurements, we hope to create an environment where IPPM metrics may be collected across a far broader mesh of Internet paths than is currently possible. One particularly compelling vision is of widespread deployment of open OWAMP servers Shalunov, et al. Standards Track [Page 2]that would make measurement of one-way delay as commonplace asmeasurement of round-trip time using an ICMP-based tool like ping.Additional design goals of OWAMP include: being hard to detect andmanipulate, security, logical separation of control and testfunctionality, and support for small test packets. (Being hard todetect makes interference with measurements more difficult forintermediaries in the middle of the network.)OWAMP test traffic is hard to detect because it is simply a stream of UDP packets from and to negotiated port numbers, with potentiallynothing static in the packets (size is negotiated, as well). OWAMPalso supports an encrypted mode that further obscures the traffic and makes it impossible to alter timestamps undetectably.Security features include optional authentication and/or encryptionof control and test messages. These features may be useful toprevent unauthorized access to results or man-in-the-middle attacksthat attempt to provide special treatment to OWAMP test streams orthat attempt to modify sender-generated timestamps to falsify testresults.In this document, the key words "MUST", "REQUIRED", "SHOULD","RECOMMENDED", and "MAY" are to be interpreted as described in[RFC2119].1.1. Relationship of Test and Control ProtocolsOWAMP actually consists of two inter-related protocols: OWAMP-Control and OWAMP-Test. OWAMP-Control is used to initiate, start, and stoptest sessions and to fetch their results, whereas OWAMP-Test is used to exchange test packets between two measurement nodes.Although OWAMP-Test may be used in conjunction with a controlprotocol other than OWAMP-Control, the authors have deliberatelychosen to include both protocols in the same RFC to encourage theimplementation and deployment of OWAMP-Control as a commondenominator control protocol for one-way active measurements. Having a complete and open one-way active measurement solution that issimple to implement and deploy is crucial to ensuring a future inwhich inter-domain one-way active measurement could become ascommonplace as ping. We neither anticipate nor recommend thatOWAMP-Control form the foundation of a general-purpose extensiblemeasurement and monitoring control protocol.OWAMP-Control is designed to support the negotiation of one-wayactive measurement sessions and results retrieval in astraightforward manner. At session initiation, there is aShalunov, et al. Standards Track [Page 3]negotiation of sender and receiver addresses and port numbers,session start time, session length, test packet size, the meanPoisson sampling interval for the test stream, and some attributes of the very general [RFC 2330] notion of packet type, including packetsize and per-hop behavior (PHB) [RFC2474], which could be used tosupport the measurement of one-way network characteristics acrossdifferentiated services networks. Additionally, OWAMP-Controlsupports per-session encryption and authentication for both test and control traffic, measurement servers that can act as proxies for test stream endpoints, and the exchange of a seed value for the pseudo-random Poisson process that describes the test stream generated bythe sender.We believe that OWAMP-Control can effectively support one-way active measurement in a variety of environments, from publicly accessiblemeasurement beacons running on arbitrary hosts to network monitoring deployments within private corporate networks. If integration withSimple Network Management Protocol (SNMP) or proprietary networkmanagement protocols is required, gateways may be created.1.2. Logical ModelSeveral roles are logically separated to allow for broad flexibility in use. Specifically, we define the following:Session-Sender The sending endpoint of an OWAMP-Test session;Session-Receiver The receiving endpoint of an OWAMP-Test session; Server An end system that manages one or more OWAMP-Test sessions, is capable of configuring per-sessionstate in session endpoints, and is capable ofreturning the results of a test session;Control-Client An end system that initiates requests forOWAMP-Test sessions, triggers the start of a set of sessions, and may trigger their termination;andFetch-Client An end system that initiates requests to fetchthe results of completed OWAMP-Test sessions. Shalunov, et al. Standards Track [Page 4]One possible scenario of relationships between these roles is shownbelow.+----------------+ +------------------+| Session-Sender |--OWAMP-Test-->| Session-Receiver |+----------------+ +------------------+^ ^| || || || +----------------+<----------------+| | Server |<-------+| +----------------+ || ^ || | || OWAMP-Control OWAMP-Control| | |v v v+----------------+ +-----------------+| Control-Client | | Fetch-Client |+----------------+ +-----------------+(Unlabeled links in the figure are unspecified by this document andmay be proprietary protocols.)Different logical roles can be played by the same host. For example, in the figure above, there could actually be only two hosts: oneplaying the roles of Control-Client, Fetch-Client, and Session-Sender, and the other playing the roles of Server and Session-Receiver. This is shown below.+-----------------+ +------------------+| Control-Client |<--OWAMP-Control-->| Server || Fetch-Client | | || Session-Sender |---OWAMP-Test----->| Session-Receiver |+-----------------+ +------------------+Finally, because many Internet paths include segments that transport IP over ATM, delay and loss measurements can include the effects ofATM segmentation and reassembly (SAR). Consequently, OWAMP has been designed to allow for small test packets that would fit inside thepayload of a single ATM cell (this is only achieved inunauthenticated mode).Shalunov, et al. Standards Track [Page 5]2. Protocol OverviewAs described above, OWAMP consists of two inter-related protocols:OWAMP-Control and OWAMP-Test. The former is layered over TCP and is used to initiate and control measurement sessions and to fetch their results. The latter protocol is layered over UDP and is used to send singleton measurement packets along the Internet path under test.The initiator of the measurement session establishes a TCP connection to a well-known port, 861, on the target point and this connectionremains open for the duration of the OWAMP-Test sessions. An OWAMPserver SHOULD listen to this well-known port.OWAMP-Control messages are transmitted only before OWAMP-Testsessions are actually started and after they are completed (with the possible exception of an early Stop-Sessions message).The OWAMP-Control and OWAMP-Test protocols support three modes ofoperation: unauthenticated, authenticated, and encrypted. Theauthenticated or encrypted modes require that endpoints possess ashared secret.All multi-octet quantities defined in this document are representedas unsigned integers in network byte order unless specifiedotherwise.3. OWAMP-ControlThe type of each OWAMP-Control message can be found after reading the first 16 octets. The length of each OWAMP-Control message can becomputed upon reading its fixed-size part. No message is shorterthan 16 octets.An implementation SHOULD expunge unused state to prevent denial-of-service attacks, or unbounded memory usage, on the server. Forexample, if the full control message is not received within somenumber of minutes after it is expected, the TCP connection associated with the OWAMP-Control session SHOULD be dropped. In absence ofother considerations, 30 minutes seems like a reasonable upper bound.3.1. Connection SetupBefore either a Control-Client or a Fetch-Client can issue commandsto a Server, it has to establish a connection to the server.First, a client opens a TCP connection to the server on a well-known port 861. The server responds with a server greeting:Shalunov, et al. Standards Track [Page 6]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+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| || Unused (12 octets) || ||+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Modes |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| || Challenge (16 octets) || || |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| || Salt (16 octets) || || |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Count (4 octets) |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| || MBZ (12 octets) || |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+The following Mode values are meaningful: 1 for unauthenticated, 2for authenticated, and 4 for encrypted. The value of the Modes field sent by the server is the bit-wise OR of the mode values that it iswilling to support during this session. Thus, the last three bits of the Modes 32-bit value are used. The first 29 bits MUST be zero. A client MUST ignore the values in the first 29 bits of the Modesvalue. (This way, the bits are available for future protocolextensions. This is the only intended extension mechanism.)Challenge is a random sequence of octets generated by the server; it is used subsequently by the client to prove possession of a sharedsecret in a manner prescribed below.Salt and Count are parameters used in deriving a key from a sharedsecret as described below.Salt MUST be generated pseudo-randomly (independently of anythingelse in this document).Count MUST be a power of 2. Count MUST be at least 1024. CountSHOULD be increased as more computing power becomes common.Shalunov, et al. Standards Track [Page 7]If the Modes value is zero, the server does not wish to communicatewith the client and MAY close the connection immediately. The client SHOULD close the connection if it receives a greeting with Modesequal to zero. The client MAY close the connection if the client’sdesired mode is unavailable.Otherwise, the client MUST respond with the following Set-Up-Response message: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+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Mode |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| |. .. KeyID (80 octets) .. .| |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| |. .. Token (64 octets) .. .| |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| |. .. Client-IV (16 octets) .. .| |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Here Mode is the mode that the client chooses to use during thisOWAMP-Control session. It will also be used for all OWAMP-Testsessions started under control of this OWAMP-Control session. InMode, one or zero bits MUST be set within last three bits. If it is one bit that is set within the last three bits, this bit MUSTindicate a mode that the server agreed to use (i.e., the same bitMUST have been set by the server in the server greeting). The first 29 bits of Mode MUST be zero. A server MUST ignore the values of the first 29 bits. If zero Mode bits are set by the client, the clientindicates that it will not continue with the session; in this case,the client and the server SHOULD close the TCP connection associated with the OWAMP-Control session.Shalunov, et al. Standards Track [Page 8]In unauthenticated mode, KeyID, Token, and Client-IV are unused.Otherwise, KeyID is a UTF-8 string, up to 80 octets in length (if the string is shorter, it is padded with zero octets), that tells theserver which shared secret the client wishes to use to authenticateor encrypt, while Token is the concatenation of a 16-octet challenge, a 16-octet AES Session-key used for encryption, and a 32-octet HMAC- SHA1 Session-key used for authentication. The token itself isencrypted using the AES (Advanced Encryption Standard) [AES] inCipher Block Chaining (CBC). Encryption MUST be performed using anInitialization Vector (IV) of zero and a key derived from the shared secret associated with KeyID. (Both the server and the client usethe same mappings from KeyIDs to shared secrets. The server, beingprepared to conduct sessions with more than one client, uses KeyIDsto choose the appropriate secret key; a client would typically havedifferent secret keys for different servers. The situation isanalogous to that with passwords.)The shared secret is a passphrase; it MUST not contain newlines. The secret key is derived from the passphrase using a password-based key derivation function PBKDF2 (PKCS #5) [RFC2898]. The PBKDF2 function requires several parameters: the PRF is HMAC-SHA1 [RFC2104]; the salt and count are as transmitted by the server.AES Session-key, HMAC Session-key and Client-IV are generatedrandomly by the client. AES Session-key and HMAC Session-key MUST be generated with sufficient entropy not to reduce the security of theunderlying cipher [RFC4086]. Client-IV merely needs to be unique(i.e., it MUST never be repeated for different sessions using thesame secret key; a simple way to achieve that without the use ofcumbersome state is to generate the Client-IV values using acryptographically secure pseudo-random number source: if this isdone, the first repetition is unlikely to occur before 2^64 sessions with the same secret key are conducted).Shalunov, et al. Standards Track [Page 9]The server MUST respond with the following Server-Start message: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+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| || MBZ (15 octets) || || +-+-+-+-+-+-+-+-+| | Accept |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| || Server-IV (16 octets) || || |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Start-Time (Timestamp) || |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| MBZ (8 octets) || |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+The MBZ parts MUST be zero. The client MUST ignore their value. MBZ (MUST be zero) fields here and after have the same semantics: theparty that sends the message MUST set the field so that all bits are equal to zero; the party that interprets the message MUST ignore the value. (This way, the field could be used for future extensions.)Server-IV is generated randomly by the server. In unauthenticatedmode, Server-IV is unused.The Accept field indicates the server’s willingness to continuecommunication. A zero value in the Accept field means that theserver accepts the authentication and is willing to conduct furthertransactions. Non-zero values indicate that the server does notaccept the authentication or, for some other reason, is not willingto conduct further transactions in this OWAMP-Control session. Thefull list of available Accept values is described in Section 3.3,"Values of the Accept Field".If a negative (non-zero) response is sent, the server MAY (and theclient SHOULD) close the connection after this message.Start-Time is a timestamp representing the time when the currentinstantiation of the server started operating. (For example, in amulti-user general purpose operating system, it could be the timewhen the server process was started.) If Accept is non-zero, Start-Shalunov, et al. Standards Track [Page 10]Time SHOULD be set so that all of its bits are zeros. Inauthenticated and encrypted modes, Start-Time is encrypted asdescribed in Section 3.4, "OWAMP-Control Commands", unless Accept is non-zero. (Authenticated and encrypted mode cannot be entered unless the control connection can be initialized.)Timestamp format is described in Section 4.1.2. The sameinstantiation of the server SHOULD report the same exact Start-Timevalue to each client in each session.The previous transactions constitute connection setup.3.2. Integrity Protection (HMAC)Authentication of each message (also referred to as a command in this document) in OWAMP-Control is accomplished by adding an HMAC to it.The HMAC that OWAMP uses is HMAC-SHA1 truncated to 128 bits. Thus,all HMAC fields are 16 octets. An HMAC needs a key. The HMACSession-key is communicated along with the AES Session-key duringOWAMP-Control connection setup. The HMAC Session-key SHOULD bederived independently of the AES Session-key (an implementation, ofcourse, MAY use the same mechanism to generate the random bits forboth keys). Each HMAC sent covers everything sent in a givendirection between the previous HMAC (but not including it) and up to the beginning of the new HMAC. This way, once encryption is set up, each bit of the OWAMP-Control connection is authenticated by an HMAC exactly once.When encrypting, authentication happens before encryption, so HMACblocks are encrypted along with the rest of the stream. Whendecrypting, the order, of course, is reversed: first one decrypts,then one checks the HMAC, then one proceeds to use the data.The HMAC MUST be checked as early as possible to avoid using andpropagating corrupt data.In open mode, the HMAC fields are unused and have the same semantics as MBZ fields.3.3. Values of the Accept FieldAccept values are used throughout the OWAMP-Control protocol tocommunicate the server response to client requests. The full set of valid Accept field values are as follows:0 OK.1 Failure, reason unspecified (catch-all).Shalunov, et al. Standards Track [Page 11]2 Internal error.3 Some aspect of request is not supported.4 Cannot perform request due to permanent resource limitations.5 Cannot perform request due to temporary resource limitations. All other values are reserved. The sender of the message MAY use the value of 1 for all non-zero Accept values. A message sender SHOULDuse the correct Accept value if it is going to use other values. The message receiver MUST interpret all values of Accept other than these reserved values as 1. This way, other values are available forfuture extensions.3.4. OWAMP-Control CommandsIn authenticated or encrypted mode (which are identical as far asOWAMP-Control is concerned, and only differ in OWAMP-Test), allfurther communications are encrypted with the AES Session-key (using CBC mode) and authenticated with HMAC Session-key. The clientencrypts everything it sends through the just-established OWAMP-Control connection using stream encryption with Client-IV as the IV. Correspondingly, the server encrypts its side of the connection using Server-IV as the IV.The IVs themselves are transmitted in cleartext. Encryption startswith the block immediately following the block containing the IV.The two streams (one going from the client to the server and onegoing back) are encrypted independently, each with its own IV, butusing the same key (the AES Session-key).The following commands are available for the client: Request-Session, Start-Sessions, Stop-Sessions, and Fetch-Session. The command Stop- Sessions is available to both the client and the server. (The server can also send other messages in response to commands it receives.)After the client sends the Start-Sessions command and until it bothsends and receives (in an unspecified order) the Stop-Sessionscommand, it is said to be conducting active measurements. Similarly, the server is said to be conducting active measurements after itreceives the Start-Sessions command and until it both sends andreceives (in an unspecified order) the Stop-Sessions command.While conducting active measurements, the only command available isStop-Sessions.These commands are described in detail below.Shalunov, et al. Standards Track [Page 12]3.5. Creating Test SessionsIndividual one-way active measurement sessions are established using a simple request/response protocol. An OWAMP client MAY issue zeroor more Request-Session messages to an OWAMP server, which MUSTrespond to each with an Accept-Session message. An Accept-Sessionmessage MAY refuse a request.Shalunov, et al. Standards Track [Page 13]The format of Request-Session message is as follows: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+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| 1 | MBZ | IPVN | Conf-Sender | Conf-Receiver |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Number of Schedule Slots |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Number of Packets |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Sender Port | Receiver Port |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Sender Address |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| || Sender Address (cont.) or MBZ (12 octets) || |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Receiver Address |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| || Receiver Address (cont.) or MBZ (12 octets) || |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| || SID (16 octets) || || |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Padding Length |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Start Time || |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Timeout, (8 octets) || |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Type-P Descriptor |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| MBZ (8 octets) || |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| || HMAC (16 octets) || || |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Shalunov, et al. Standards Track [Page 14]This is immediately followed by one or more schedule slotdescriptions (the number of schedule slots is specified in the"Number of Schedule Slots" field above):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+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Slot Type | |+-+-+-+-+-+-+-+-+ MBZ (7 octets) || |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Slot Parameter (Timestamp) || |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+These are immediately followed by HMAC: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+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| || HMAC (16 octets) || || |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+All these messages constitute one logical message: the Request-Session command.Above, the first octet (1) indicates that this is the Request-Session command.IPVN is the IP version numbers for Sender and Receiver. When the IP version number is 4, 12 octets follow the 4-octet IPv4 address stored in Sender Address and Receiver Address. These octets MUST be set to zero by the client and MUST be ignored by the server. Currentlymeaningful IPVN values are 4 and 6.Conf-Sender and Conf-Receiver MUST be set to 0 or 1 by the client.The server MUST interpret any non-zero value as 1. If the value is1, the server is being asked to configure the corresponding agent(sender or receiver). In this case, the corresponding Port valueSHOULD be disregarded by the server. At least one of Conf-Sender and Conf-Receiver MUST be 1. (Both can be set, in which case the server is being asked to perform a session between two hosts it canconfigure.)Shalunov, et al. Standards Track [Page 15]。
rfc 3174标准
rfc 3174标准RFC 3174标准介绍RFC（Request for Comments）3174是一项用于计算机网络中数据完整性校验的标准。
该标准定义了一种安全散列算法，即SHA-1（Secure Hash Algorithm 1）算法，用于验证数据在传输过程中是否被篡改。
SHA-1算法是美国国家安全局（NSA）设计的一种加密散列函数。
它将任意大小的数据块映射为一个固定长度的哈希值，通常为160位。
哈希值是一个数字指纹，用于唯一标识原始数据。
SHA-1算法使用了一系列复杂的位操作和逻辑函数来执行数据转换，以确保数据和哈希值之间的关联性。
RFC 3174标准的主要目的是提供一种机制来验证数据的完整性，以解决数据篡改的问题。
在现代互联网中，数据传输时存在被黑客篡改的风险。
如果数据在传输过程中被篡改，接收方将无法确定数据是否真实，从而产生安全隐患。
通过使用SHA-1算法，发送方可以将数据进行哈希运算并生成哈希值，然后将哈希值附加到数据中一起传输。
接收方可以使用相同的算法对接收到的数据进行计算，并将计算出的哈希值与附加的哈希值进行比较。
如果两个哈希值匹配，即可确认数据的完整性，并且可以安全地使用接收到的数据。
SHA-1算法具有以下特点，使其成为数据完整性校验的理想选择：1. 不可逆性：SHA-1算法将数据转换为固定长度的哈希值，不同的数据将生成不同的哈希值。
但是，无法通过哈希值推导出原始数据，使得黑客无法从哈希值中了解任何有关原始数据的信息。
2. 高度敏感性：SHA-1算法对数据的任何改动都会导致不同的哈希值。
即使是对原始数据进行微小的修改，也会显著改变哈希值，从而保证了数据完整性的检测。
3. 速度较快：SHA-1算法的计算速度较快，适用于大规模数据的处理。
这样可以确保数据的完整性校验不会成为传输过程中的瓶颈。
尽管SHA-1算法在数据完整性校验方面表现出色，但是随着计算能力的增强和密码破解技术的不断发展，SHA-1算法已经不再被认为是安全的加密散列函数。
sFlow RFC3176
sFlow V ersion 5AbstractThis memo defines 's sFlow system. sFlow is a technology formonitoring traffic in data networks containing switches and routers. In particular, it defines the traffic sampling mechanisms implemented in sFlow Agents, the sFlow MIB for configuring sFlow Agents, and the format of the sFlow Datagram that carries traffic measurement data from sFlow Agents to an sFlow Collector.这备忘录规定's sFlow系统.sFlow是一因为监视含有交换和路由器得数据网络的通讯流量得技术.特别是,它定义在sFlow代理身上执行流量取样机械设备,为配置sFlow代理器sFlow MIB和sFlow Datagram的格式,其一个sFlow搜集器的sFlow代理器带着从流量度量数据的.Table of Contents1. Overview (2)2. Terminology and Architecture (2)2.1 Terminology (2)2.2 sFlow Reference Model (4)3. Sampling Mechanisms (6)3.1 Packet Flow Sampling (6)3.2 Counter Sampling (7)4. sFlow MIB (8)4.1 The SNMP Management Framework (8)4.2 Structure of the sFlow MIB Module (9)4.2.1 The Receiver Group (9)4.2.2 The Flow Sampling Group (9)4.2.3 The Counter Polling Group (10)4.3 Definitions (11)5. sFlow Datagram Format (23)6. Security Considerations (43)6.1 Configuration (44)6.2 Transport (44)6.3 Confidentiality (44)7. References (45)8. Author's Addresses (47)Appendix A：Differences Between sFlow V ersions 1 and 2 (49)Appendix B：Random Number Generation (50)1. OverviewsFlow is a technology for monitoring traffic in data networks containing switches and routers. sFlow是一对含有交换机和路由器的网络流量数据进行得监视技术.The sFlow monitoring system consists of an sFlow Agent (embedded in a switch or router or in a standalone probe) and a central sFlow Collector. The architecture and sampling techniques used in the sFlow monitoring system were designed for providing continuous sitewide (and enterprise-wide) traffic monitoring of high speed switched and routed networks. This design specifically addresses issues associated with：sFlow监视系统由sFlow Agent(嵌入到交换机和路由器或单独的探测器中)和central sFlow Collector.使用在sFlow监视器系统的结构和采样技术都有计划的提供连续的网点范围（企业范围）的高速的交换和路由的网络工作的流量监视.o Accurately monitoring network traffic at Gigabit speeds and higher.准确得监视Gigabit速度及更高流量网络o Scaling to monitor tens of thousands of agents from a single sFlow Collector.依比例决定从单独得一个sFlow搜集器监视数以万计的代理器的.o Extremely low cost sFlow Agent implementation. 极其低价钱为sFlow代理工具The sFlow Agent uses sampling technology to capture traffic statistics from the device it is monitoring. sFlow Datagrams are used to immediately forward the sampled traffic statistics to an sFlow Collector for analysis.sFlow代理器使用取样技术捕获从它监视设备中进行流量统计.使用sFlow Datagrams为分析立即转发抽样检查流量统计给一个sFlow搜集器.This document describes the sampling mechanisms used by the sFlow Agent, the SFLOW MIB used by the sFlow Collector to control the sFlow Agent, and the sFlow Datagram Format used by the sFlow Agent to send traffic data to the sFlow Collector.这文件描绘经过sFlow代理器使用取样机制,SFLOW MIB经过sFlow搜集器通常控制sFlow 代理器,和sFlow Datagram格式经过sFlow代理器通常把流量数据寄给sFlow搜集器.This memo describes sFlow version 5. It replaces sFlow version 4 described in RFC 3176 [1]. The differences between sFlow versions 4 and 5 are described in Appendix A.这备忘录描绘sFlow版本5.它取代在RFC 3176[1]中描绘sFlow第4版.sFlow第4和5版之间的差异在附录A中被描绘.2. Terminology and ArchitectureThis section defines the elements of the sFlow system.这部分解释sFlow系统的基本原理2.1 TerminologyThe terms used to specify the sFlow architecture are defined here for reference.这些条款作为使用sFlow体系结构的参考.o Network Device：A piece of network equipment, such as a switch or router, that forwards data packets.网络设备：一台像交换器、路由器这样的转发数据包的网络设备o Data Source：A Data Source refers to a location within a Network Device that can make traffic measurements. Possible Data Sources include interfaces, physical entities within the device such as the backplane and VLANs. Each Data Source has access to a subset of the traffic flowing through the device. The type and number of Data Sources needed to completely monitor a device will depend on the internal architecture of that device. Typically a Data Source is defined for each physical interface on the device since this ensures that every packet transiting the device to be observed.数据源：在一定位置上能够产生流量检测的网络设备.可能数据源包括接口、在例如像backplane和VLANs这样的设备上的物理实体.每个数据源能够访问到通过设备数据流量的子集.一些类型和数量的数据源需要完整的监视设备将依赖设备的内部结构体系.典型的数据源为定义了每个设备上的物理接口以确保每个通过传输的包的观察设备o Packet Flow：A Packet Flow is defined as the path or trajectory that a packet takes througha Network Device (i.e. the path that a packet takes as it is received on one interface, is subject to a switching/routing decision and is then sent on another interface. In the case of a one-armed router, the source and destination interface could be the same. In the case of a broadcast or multicast packet there may be multiple destination interfaces).信息包流：定义为包通过网络设备的路径或轨迹（例如一个接口接受包，并由路由器或交换机决定是否发送给另外的接口的路径.在one_arm路由器的情况下，源和目的路由接口应当一样.在广播或多播包的情况下，这将多目的接口）o Packet Flow Sampling：Packet Flow Sampling refers to the random selection of a fraction of the Packet Flows observed at a Data Source.包流采样：在数据源上随机选择部分用来观察的包流.o Sampling Rate：The Sampling Rate specifies the ratio of packets observed at the Data Source to the samples generated. For example a sampling rate of 100 specifies that, on average, 1 sample will be generated for every 100 packets observed.采样率：采样包和观察源数据的比率.例如抽样率为100，那么平均从100个要观察的包中抽取1个包o Packet Flow Record：A Packet Flow Record describes the attributes of a Packet Flow. There are two types of information in a flow record：1 Information on the packet itself, typically a packet header, packet length and packet encapsulation.2 Information about the path the packet took through the device, including information relating to the selection of the forwarding path.包流记录：它描述了一个包流的特征.这里有2个信息在包流记录中：（1）包自己的信息，代表的有包头，包长度和包封装（2）关于包通过设备的路径信息，包含了相关的选择前向路径o Counter Sampling：Periodic sampling or polling of counters associated with a Data Source. 采样计数器：数据源关联的周期取样或者投票的计数器.o Sampling Interval：The time period between successive Counter Samples.取样时间间隔：连续计数采样之间的时间周期.o Counter Record：A record containing counter values associated with a Data Source at the end of a Sampling Interval.计数器记录：包含在采样周期结尾的与数据源关联的计数值的记录o sFlow Instance：An sFlow Instance refers to a measurement process associated with a Data Source.There may be one or more sFlow Instances associated with a single Data Source.Each sFlow Instance operates independently of other sFlow Instances, for example if Packet Flow Sampling instances each have their own Sampling Rates and Counter Sampling instaces have their own Sampling Interval.sFlow实例：与数据源关联的测量处理.可以提供一个或多个sFlow实例关联在一个数据源上.每个sFlow 实例独立于其他的sFlow 实例，例如，每个包采样实例都有他们自己的采样率和采样计数器在他们自己的采样周期中o sFlow Agent：The sFlow Agent provides an interface for configuring the sFlow Instances within a device. The sFlow Agent may support command line and/or SNMP based configuration.The agent is also responsible for maintaining measurement sessions with sFlow Collectors. It marshals data into sFlow Datagrams to send to sFlow Collectors. The sFlow Agent frees resources when a session expires.sFlow代理器：给设备中的sFlow实例的配置提供接口，它提供基于命令行或基于SNMP配置.它还负责对sFlow搜集器的维修测量对话.它整理数据到sFlow Datagram 发送到sFlow搜集器.sFlow代理在对话过期后释放资源.o sFlow Sub-Agent：In the case where sFlow is implemented on a distributed device architecture it may be desireable to distribute the sFlow Agent functionality. Each sFlow Sub-Agent is responsible for a particular subset of Data Sources.sFlow子代理器：在sFlow在分布结构设备上执行情况下可以是描述sFlow代理器的性能的愿望其sFlow有关一分配设备体系结构被执行.每一sFlow子代理依赖于数据源的特殊子集.o sFlow Collector：An sFlow Collector receives sFlow Datagrams from one or more sFlow Agents. The sFlow Collector may also configure sFlow Instances using the configuration mechanisms provided by the sFlow Agent.sFlow搜集器：一个sFlow搜集器从一个或更多sFlow代理器收到sFlow Datagrams.sFlow搜集器可以也配置sFlow实例使用经过sFlow代理器提供配置机械设备.o sFlow Datagram：The sFlow Datagram is a UDP datagram that contains the measurement data, and information about the measurement source and process. The format of the sFlow Datagram is defined in this document.sFlowDatagram：sFlow Datagram是一UDP datagram,其含有度量数据和关于度量来源和过程的信息的.sFlow Datagram的格式在这文件中被确定.2.2 sFlow Reference ModelThe figure below shows the relationships between the different entities within an sFlow system.下面图示展示了一sFlow系统内不同实体之间的关系.An sFlow Collector makes use of SNMP to communicate with an sFlow Agent in order toconfigure sFlow monitoring on a Network Device. The sFlow MIB describes the managed objects needed to configure an sFlow Agent. Packet Flow Sampling and Counter Sampling is performed by sFlow Instances associated with individual Data Sources within the sFlow Agent. In order to perform Packet Flow Sampling, an sFlow Instance is configured with a Sampling Rate. The Packet Flow sampling process results in the generation of Packet Flow Records. In order to perform Counter Sampling, an sFlow Instance is configured with a Sampling Interval. The Counter Sampling process results in the generation of Counter Records. The sFlow Agent collects Counter Records and Packet Flow Records and sends them in the form of sFlow Datagrams to sFlow Collectors.SFlow 搜集器为了配置sFlow 监视网络设备使用SNMP与sFlow 代理通讯. SFlow MIB 描述管理目标需要配置在sFlow Agent.包采样和计数采样在sFlow 代理上的一个个体数据源上的sFlow实例来执行.为了执行包流采样，要配置sFlow实例的采样率.包流采样处理结果由包流记录产生.为了执行计数器采样，sFlow实例配置采样间隔.计数器采样处理结果由计数器记录产生.sFlow代理搜集计数器记录和包流记录并以sFlow数据报形式发送他们到sFlow搜集器.3. Sampling MechanismsThe sFlow Agent uses two forms of sampling：statistical packet-based sampling of switched or routed Packet Flows, and time-based sampling of counters.sFlow代理用2种格式采样：基于包统计交换或路由包流的采样；基于时间和计数器的采样3.1 Packet Flow SamplingThe Packet Flow Sampling mechanism carried out by each sFlow Instance must ensure that any packet observed at a Data Source has an equal chance of being sampled, irrespective of the Packet Flow(s) to which it belongs.包流采样机制是由每个sFlow实例必须确认观察数据源上的任何包有平等的机会被抽样到.不考虑包流属于谁.Packet Flow Sampling is accomplished as follows：When a packet arrives on an interface, the Network Device makes a filtering decision to determines whether the packet should be dropped. If the packet is not filtered a destination interface is assigned by the switching/routing function. At this point a decision is made on whether or not to sample the packet. The mechanism involves a counter that is decremented with each packet.When the counter reaches zero a sample is taken. Whether or not a sample is taken, the counter Total_Packets is incremented.Total_Packets is a count of all the packets that could have been sampled.执行流程：当一个包到达接口，网络设备作出是否丢弃它的过滤.如果包没有被交换或路由功能过滤掉一个目的接口.在这指出决定是否采样包.这个机制包括计数器对每一个包递减.当计数器到到0，一个采样就产生.无论采样是否发生，计数器Total_Packts增加.Total_Packets是计算所有被采样的包数量Taking a sample involves either copying the packet's header, or extracting features from the packet.See sFlow Datagram Format for a description of the different forms of sample.Every time a sample is taken, the counter Total_Samples, is incremented. Total_Samples is a count of the number of samples generated.Samples are sent by the sFlow Instance to the sFlow Agent for processing.The sample includes the packet information, and the values of the Total_Packets and Total_Samples counters.The sFlow Agent may then use the samples to obtain additionalinformation about the packet's trajectory through the device. Such information depends on the forwarding functions of the device. Examples of trajectory information provided are source and destination interface, source and destination VLAN, next hop subnet, full AS path. Details of the forwarding information are given in the sFlow Datagram Format.包采样包括拷贝包的头或从包中提取特征.（看描述不同采样格式的sFlow数据报格式）.每次采样，计数器Total_samples都增加.Total_samples是统计采样发生数量的.采样发送到sFlow 代理的sFlow实例处理. 采样包括包信息和Total_Packets和Total_samples计数器.SFlow代理要用采样获得关于包通过设备路径的的另外信息.一些信息依赖设备的转发功能.路径信息的例子提供源和目的接口，源和目的VLAN，子网下一跳，全AS－path.详细的转发信息付给sFlow 数据报格式When a sample is taken, the counter indicating how many packets to skip before taking the next sample should be reset. The value of the counter should be set to a random integer where the sequence of random integers used over time should be such that：当采样发生，计数器指示出下一次采样发生前有多少个包跳过，计数器的值被设为随机的一个int型数，(1) Total_Packets/Total_Samples = Sampling RateAn alternative strategy for Packet Flow Sampling is to generate a random number for each packet, compare the random number to a preset threshold and take a sample whenever the random number is smaller than the threshold value. Calculation of an appropriate threshold value depends on the characteristics of the random number generator, however, the resulting sample stream must still satisfy包流采样的选择策略是每个包产生一个随机数，比较随机数和提前设定的阈值，如果小于阈值就采样.计算一个合适的阈值依赖于特定的随机数产生器,但是,随之发生采样结果必须去更加完善.Appendix B further discusses the requirements for the random number generator.附录B进一步讨论随机数产生的要求.3.2 Counter SamplingThe primary objective of the Counter Sampling is to efficiently, periodically export counters associated with Data Sources.计数器取样的基本目标是要高效的、周期性地输出把计数器和数据源联系起来.Typically a Data Source will be associated with each interface on the device that can be an ingress or egress interface for Packet Flows.These interface Data Sources will then be used to export counters relating to the interfaces.典型一数据源将被把和每一在能是一进入的设备上接口联系起来或者那时为包Flows.这些数据源接口将被使用出口数据.A maximum Sampling Interval is assigned to each sFlow Instance associated with an interface Data Source, but the sFlow Agent is free to schedule polling in order maximize internal efficiency. 给分配一最大取样时间间隔但是sFlow代理器是对顺序投票明细表自由使内部效率增至最大每一sFlow实例把和联系起来一接口数据源.Packet Flow Sampling and Counter Sampling are designed as part of an integrated system. Both types of sample are combined in sFlow Datagrams. Since Packet Flow Sampling will cause a steady, but random, stream of sFlow Datagrams to be sent to the sFlow Collector, counter samples may be taken opportunistically in order to fill these datagrams.包流动取样和计数器取样作为一综合系统的一部分被设计.两个类型的样品在sFlow Datagrams中被合并.自包流动取样将给一固定的异性朋友但是任意行动造成以来,为了填补这些,计数器样品可以机会主义地被拿datagrams股sFlow Datagrams把寄给sFlow搜集器.One strategy for counter sampling has the sFlow Agent keep a list of counter sources being sampled. When a Packet Flow Sample is generated the sFlow Agent examines the list and adds counters to the sample datagram, least recently sampled first. Counters are only added to the datagram if the sources are within a short period, 5 seconds say, of failing to meet the required Sampling Interval (see sFlowCounterSamplingInterval in SFLOW MIB). Whenever a counter source's statistics are added to a sample datagram, the time the counter source was last sampled is updated and the counter source is placed at the end of the list. Periodically, say every sec ond, the sFlow Agent examines the list of counter sources and sends any counters that need to be sent to meet the sampling interval requirement.一计数器取样的对策让一计数器来源的清单继续是抽样检查让sFlow代理器.当一包流动样品是产生的时候,sFlow代理器检查清单和添加和样品datagram相反最不近来首先抽样检查.5次品谈到未能遭遇需要取样时间间隔(在SFLOW MIB中看见sFlowCounterSamplingInter)说如果在一短时期以内,来源是,计数器仅被被加入datagram.每当一计数器来源的统计被被加入一样品datagram,计数器来源最后被抽样检查时间被更新在清单的末端和计数器来源被安置.周期性地,比如说每隔一sFlow代理器检查计数器来源的清单和寄送任何应该是的计数器寄送符合取样时间间隔要求If the sFlow Agent chooses to regularly schedule counter sampling, then it should schedule each counter source at a different start time (preferably randomly) so that counter sampling is not synchronised within an agent or between agents.如果sFlow代理器宁愿选择正常计划计数器取样,然后在不同出发时刻它应该计划每一计数器来源,(更可取地任意行动地)因此计数器取样在一个代理器心里或者在代理器之间不是synchronised.4. sFlow MIBThe sFlow MIB provides a standard mechanism for remotely controlling and configuring an sFlow Agent.sFlow MIB为远离控制和配置sFlow代理器提供一个标准机制.4.1 The SNMP Management Framework （SNMP管理框架）The SNMP Management Framework presently consists of five major components：SNMP管理框架不久由五个主要成分构成：o An overall architecture, described in RFC 2571 [2].在RFC 2571[2]中描绘一总体系结构.o Mechanisms for describing and naming objects and events for the purpose of management. The first version of this Structure of Management Information (SMI) is called SMIv1 and described in STD 16, RFC 1155 [3], STD 16, RFC 1212 [4] and RFC 1215 [5]. The second version, called SMIv2, is described in STD 58, RFC 2578 [6], STD58, RFC 2579 [7] and STD 58, RFC 2580 [8].机制描绘和目标命名及事件是为了实现管理.管理信息(SMI)的结构的第一版本被称为SMIv1是在STD 16,RFC 1155[3],STD 16,RFC 1212[4]和RFC 1215[5]中描绘.第二版本是在SMIv2在STD 58,RFC 2578[6],STD58,RFC 2579[7]和STD 58,RFC 2580[8]中被描绘.o Message protocols for transferring management information. The first version of the SNMP message protocol is called SNMPv1 and described in STD 15, RFC 1157 [9]. A second version ofthe SNMP message protocol, which is not an Internet standards track protocol, is called SNMPv2c and described in RFC 1901 [10] and RFC 1906[11]. The third version of the message protocol is called SNMPv3 and described in RFC 1906 [11], RFC 2572 [12] and RFC 2574 [13].因为搬管理知识o信息礼仪.SNMP信息礼仪的第一版本被认为是SNMPv1和在STD中描绘15,RFC 1157[9].认为是SNMPv2c在RFC 1901[10]和RFC 1906[11]中被和描绘一SNMP信息礼仪的第二版本,其不是一因特网标准轨迹礼仪的.认为是SNMPv3在RFC 1906[11],RFC 2572[12]和RFC 2574[13]中被和描绘信息礼仪的第三版本.o Protocol operations for accessing management information.The first set of protocol operations and associated PDU formats is described in STD 15, RFC 1157 [9]. A second set of protocol operations and associated PDU formats is described in RFC 1905 [14].information.第一为访问管理准备礼仪运算和结合PDU格式的o礼仪运算的在STD 15,RFC 1157[9]中被描绘.一第二套礼仪运算和结合PDU格式在RFC 1905[14]中被描绘.o A set of fundamental applications described in RFC 2573 [15] and the view-based access control mechanism described in RFC 2575 [16].o A套基本应用在RFC中描绘2573[15]和基于视野的接近的机会控制手段机械设备在RFC 中描绘2575[16].A more detailed introduction to the current SNMP Management Framework can be found in RFC 2570 [17].一更详细对当前SNMP管理框架的介绍能在RFC 2570[17]中被找出.Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. Objects in the MIB are defined using the mechanisms defined in the SMI.经由一个事实上信息存储被接近把管理目标称为管理信息基础或者MIB.在MIB中目标被规定使用在SMI中定义机械设备.This memo specifies a MIB module that is compliant to the SMIv2. A MIB conforming to the SMIv1 can be produced through the appropriate translations.The resulting translated MIB must be semantically equivalent, except where objects or events are omitted because no translation is possible (use of Counter64). Some machine readable information in SMIv2 will be converted into textual descriptions in SMIv1 during the translation process. However, this loss of machine readable information is not considered to change the semantics of the MIB.这备忘录对SMIv2顺从指定一是的MIB模数.一MIB遵从SMIv1能被生产通过适合translations.The随之发生翻译MIB一定是按语义地等于,因为没有翻译是可能,除了什么地方物件或者事件是删掉Counter64的使用.一些在SMIv2中机器可读信息将在翻译过程期间被把变成在SMIv1中原文的描绘.但是,不认为这机器可读信息的失败改变MIB的语义学.4.2 Structure of the SFLOW MIB Module（SFLOW MIB模数的结构）The MIB consists of three groups of objects：the receiver group, the flow sampling group and the counter polling group.MIB由三群物件构成：接受组,流动取样组和投票计数器组在一起.4.2.1 The Receiver GroupThe receiver group defines the set of objects used to maintain an sFlow session between an sFlow Agent and an sFlow Collector.接受组定义使用目标集在sFlow代理器和sFlow搜集器之间保持一个sFlow session.Before making any configuration changes, an sFlow Collector must first find a free row in the receiver table and then claim it by writing its owner string and a reservation time into a free row in the receiver table. A session will automatically time out, and the associated resources freed, unless it is periodically refreshed by the the collector. By periodically refreshing its receiver table entry, an sFlow Collector ensures that its address is learned by any bridges on the path to the sFlow Agent, minimizing the chances that the sFlow Datagrams will be flooded by a bridge.在有任何配置改变之前,一个sFlow搜集器首先必须在接受表中找出一个自由表然后通过写他自己的字符串何预定时间值声明它,一个session将自动time out,互联资源自动释放，除非搜集器会周期性的刷新.通过周期性地刷新它的接受表入口,一个sFlow搜集器保证它的地址被任何在通向sFlow代理器的路径上的网桥学习到，极小改变sFlow Datagrams将使网桥溢出.Entries cannot be added to or removed from the receiver group table. An sFlow Agent implementor should limit the number of entries to ensure that the number of concurrent sFlow sessions is limited to a number that will not exceed that capacity of the device.接受组表不能添加或删除条目.一个sFlow代理器使用工具者应该限制入口的数目,保证其限制同时发生的sFlow sessions的数目为一数那个将不超过那设备的容量的.Having acquired a row in the receiver table, the sFlow Collector specifies an address and port that it will use to receive sFlow Datagrams. The maximum size of sFlow Datagrams can be configured in order to prevent packet fragmentation.在已获得接受表的row中，sFlow搜集器指定一地址和port来接受sFlow Datagrams.为了防止分包, 要配置sFlow Datagrams的最大值.4.2.2 The Flow Sampling GroupThe flow sampling group defines a set of locations, or Data Sources, in the device that are capable of Packet Flow sampling.Data Sources may correspond to interfaces, VLANs or other entities within the device. The set of Data Sources advertised by an sFlow Agent depends on the device architecture. For example, a device may have packet sampling integrated into its interface ASICs, in which case it will advertise Data Sources for each interface. Alternatively, a software router may simply have one Data Source associated with the routing module.包流取样组定义一组可能做出包流取样的位置或数据源的集合.数据源对应于设备interfaces、VLANs或者其它实体.sFlow代理器为数据源集做广播取决于设备体系结构.例如,一设备可以有把包完整取样到它的接口ASICs,在这种情况下它将为每一接口为数据源登广播的.另一种选择,一个软件路由可以简单用路由模式联系一数据源.Each Data Source may be capable of supporting more than one independent sampling process, in which case there will be multiple sFlow Instances associated with each Data Source. Each sFlow Instance can have its own independent sampling rate.每一数据源可以是能支持一或多独立取样处理,在这种情况下将有把多重sFlow实例和每一数据源联系起来的.每一sFlow实例能有它的自己独立的抽样速率.Even if the Data Source hardware is only capable of generating a single stream of packet samples, it is possible for the sFlow Agent to use sub-sampling to create multiple sFlow Instances for the Data Source. For example, suppose there are two sFlow Instances, one configured with a Sampling Rate of 512 and the other with a rate of 1024. The hardware can be configured to sample at a rate of 512 and then these samples can be sub-sampled in software using a sampling rate of 2 to achieve the 1024 rate. Only allowing Sampling Rates that are powers of two is attractive since it allows the smallest configured Sampling Rate to be set in hardware and all other sampling ratescan be obtained in software by sub-sampling.即使数据源硬件是仅仅能产生一单一的包样品,sFlow代理器使用子取样为数据源建立多重sFlow实例是可能的.例如,假定有两sFlow实例,一个取样以512的速率配置，其他的以1024配置.硬件能被配置在一512的速度方面试样后显示结果然后能是子在软件中取这些样品的样品使用一2的取样速度取得1024速度自它允许被把最小配置取样嵌入硬件速度和所有的其它取样速度能在软件中被亚取样得到以来,仅允许抽样检查是二的力量的速度是有吸引力.An Flow Sampling Instance may have a minimum allowable Sampling Rate.Setting a conservative value that ensures that the sFlow Agent can never become overloaded with Packet Flow Samples under worst case traffic loads is not advisable. This yeilds minimum Sampling Rate values that are very high and don't reflect typical traffic levels. The Agent may implement an automated one-way backoff of the Sampling Rate that triggers whenever an excessive number of samples per second is generated. When the triggered the Agent can double the Sampling Rate. If the threshold is exceeded again, the Sampling Rate is doubled again. The Sampling Rate will quickly reach a value that is sustainable. The sampling rate must stay at its new value and never automatically return to the originally configured value. The value may be changed back manually through the command line interface or via the sFlow MIB. This scheme protects against poorly chosen Sampling Rates or unexpected changes in peak traffic rates, but still allows low Sampling Rates to be safely selected where appropriate.一流取样实例可以让一最低限度容许抽样检查Rate.Setting一保守价值不是明智,其保证能从不变得用在糟情况流量负担下包流动样品使sFlow代理器超载的.这yeilds最低限度瞄准,抽样检查速度价值观,其是非常高和不反映出典型流量的.代理器可以执行一取样速度的自动化单向的backoff,扳机产生,究竟什么时候一过分每秒样品的数目是的.什么时候松开扳柄代理器能把取样速度增加一倍.如果门槛再次被超过,再次把取样速度增加一倍.取样速度将迅速达到一是支撑得住的价值.取样速度必须在它的新价值方面留下和从不自动返回原来配置价值.价值可以回来通过指挥线接口或者经由sFlow MIB手工被改变.这计划避免身体不舒服的选择取样速度或者意想不到高峰流量速度的改变的危害但是仍然允许低样品安全适合的地方,被选择速度.4.2.3 The Counter Polling GroupThe counter polling group defines a set of locations, or Data Sources, in the device that can provide counter information. Typically the Data Sources will be the interfaces on the device. Each Data Source may be capable of supporting more than one independent polling process, in which case there will be multiple counter polling instances associated with each data source. Each counter polling instance can have its own independent polling interval.它定义一组在能提供计数器信息的设备中位置或者数据源.典型数据源将是在设备上接口.每一数据源可以是能支持一个或多个独立投票处理,在这种情况下将有多重计数器获得把情况和每一数据源联系起来的.每一计数器能独立的时间间隔投票.4.3 DefinitionsSFLOW-MIB DEFINITIONS ：：= BEGINIMPORTSMODULE-IDENTITY, OBJECT-TYPE, Integer32, enterprisesFROM SNMPv2-SMITEXTUAL-CONVENTIONFROM SNMPv2-TCSnmpAdminStringFROM SNMP-FRAMEWORK-MIBOwnerStringFROM RMON-MIBInetAddressType, InetAddressFROM INET-ADDRESS-MIBMODULE-COMPLIANCE, OBJECT-GROUPFROM SNMPv2-CONF;sFlowMIB MODULE-IDENTITYLAST-UPDA TED "200309240000Z" -- September 24, 2003 ORGANIZA TION ""CONTACT-INFO"Peter Phaalhttp：///Tel：+1-415-283-3260Email：peter.phaal@"DESCRIPTION"The MIB module for managing the generation and transportationof sFlow data records."---- Revision History--REVISION "200310180000Z" -- November 18, 2003 DESCRIPTION"V ersion 1.3 (draft 5)Allow set to SFlowReceiver if it doesn't changevalue."REVISION "200309240000Z" -- September 24, 2003 DESCRIPTION"V ersion 1.3 (draft 4)Default value of sFlowRcvrAddress should be '00000000' h.Default value of sFlowCpReceiver should be 0."REVISION "200304080000Z" -- April 8, 2003 DESCRIPTION"V ersion 1.3 (draft 3)Clarify semantics of counter polling interval,sFlowCpInterval."REVISION "200209170000Z" -- September 17, 2002DESCRIPTION"V ersion 1.3 (draft 2)Adds support for multiple sFlow samplers per sFlowDataSource. Moved to enterprise number.Splits flow sampling,counter polling and receiver specification into separate tables."添加支持为每sFlowDataSource多重sFlow取样员.去企业提议number.Splits流动取样,投票计数器和进入独立表收件规格说明.REVISION "200107310000Z" -- July 31, 2001DESCRIPTION"V ersion 1.2Brings MIB into SMI v2 compliance."REVISION "200105010000Z" -- May 1, 2001DESCRIPTION"V ersion 1.1Adds sfDatagramV ersion."：：= { enterprises sflow(14706) 1 }sFlowAgent OBJECT IDENTIFIER ：：= { sFlowMIB 1 }SFlowDataSource ：：= TEXTUAL-CONVENTIONSTA TUS currentDESCRIPTION"Identifies a source of sFlow data.The following data source types are currently defined：- ifIndex.<I>SFlowDataSources of this traditional form are called 'port-based'. Ideally the sampling entity will perform sampling on all flows originating from or destined to the specified interface. However, if the switch architecture only allows input or output sampling then the sampling agent is permitted to only sample input flows input or output flows. Each packet must only be considered once for sampling, irrespective of the number of ports it will be forwarded to. Note：Port 0 is used to indicate that all ports on the device are represented by a single data source. - sFlowFsPacketSamplingRate applies to all ports on the device capable of packet sampling.- smonVlanDataSource.<V>An SFlowDataSource of this form refers to a 'Packet-based VLAN'and is called a 'VLAN-based' dataSource. <V> is the VLANID as defined by the IEEE 802.1Q standard. Thevalue is between 1 and 4094 inclusive, and it representsan 802.1Q VLAN-ID with global scope within a givenbridged domain.Sampling is performed on all packets received that are partof the specified VLAN (no matter which port they arrived on).Each packet will only be considered once for sampling,irrespective of the number of ports it will be forwarded to.- entPhysicalEntry.<N>An SFlowDataSource of this form refers to a physical entitywithin the agent (e.g. entPhysicalClass = backplane(4)) andis called an 'entity-based' dataSource. Sampling is performedon all packets entering the resource (e.g. If the backplaneis being sampled, all packets transmitted onto the backplanewill be considered as single candidates for samplingirrespective of the number of ports they ultimately reach).Note：Since each SFlowDataSource operates independently apacket that crosses multiple DataSources may generatemultiple flow records."SYNTAX OBJECT IDENTIFIERSFlowInstance ：：= TEXTUAL-CONVENTIONSTA TUS currentDESCRIPTION"If more than one sFlow sampler is available for thisSFlowDataSource then individual samplers are distinguishedusing the SFlowInstance variable. The value ofSFlowInstance ranges from 1..n where n is the number ofsamplers associated with this SFlowDataSource.Note：Each sFlow sampler instance must operateindependently of all other instances. Settingan attribute of one sampler must not alter thethe behavior and settings of other samplerinstances."SYNTAX Integer32 (1..65535)SFlowReceiver ：：= TEXTUAL-CONVENTIONSTA TUS currentDESCRIPTION"Identify the sFlow receiver associated with this resource.A value of zero indicates that this resource is available.。
和SIP有关的RFC
RFC 3680 SIP Event Package for Registrations
RFC 3702 Authentication, Authorization, and Accounting Requirements for the SIP
RFC 3515 The Session Initiation Protocol (SIP) Refer Method
RFC 3578 Mapping of Integrated Services Digital Network (ISDN) User Part (ISUP) Overlap Signalling to the SIP
RFC 4244 An Extension to the SIP for Request History Information
RFC 4245 High-Level Requirements for Tightly Coupled SIP Conferencing
RFC 4320 Actions Addressing Identified Issues with the SIP's Non-INVITE Transaction
RFC 3581 An Extension to the SIP for Symmetric Response Routing
RFC 3603 Private SIP Proxy-to-Proxy Extensions for Supporting the PacketCable Distributed Call Signaling Architecture.
Resiprocate介绍
Resiprocate介绍Resiprocate介绍1.前⾔本⽂主要内容来⾃互联⽹，特此感谢Steven的⾟苦撰写和resiprocate开源组织的⽆私奉献以及sip协议的创造者Schulzrinne教授和Rosenberg⼤师的⾟勤⼯作。
2．从SIP谈起说明:不期待⼀次就把RFC3261或者其他的协议⽂档内容及其细节全部记住或者完全理解;把原理性的东西及其脉络厘清也许更重要;在调试程序和看协议栈源码的过程中我的做法是⼀直把RFC3261(经常的是那份中⽂⽂档?的⽂档打开;遇到忘记或者不是太明⽩的概念和内容就在⽂档中再搜索相关主题及内容来看看;经常会碰到这样的问题,我发个内容给SIP Proxy或者SIP Server,可是并没得到我希望的回复或者与期待的回复内容有出⼊,这时,我的经常做法是再去研读协议的相关定义,看看是不是我哪个细节并没理解深⼊或者引起注意,导致我发出去的内容与协议标准有出⼊或者我的流程与协议定义不吻合。
接下来的内容是前⼈的⽂档整理,只是个⼤概,如果没兴趣,完全可以跳过不看;协议栈部分基本上是分成DUM与Stack两部份可以先后看，也可以先看Stack部分。
补充说明：⽂档中的⼤部分图⽚都来⾃⽹上公开的资料，只有少数⼏幅是⾃绘，因此出现内容不清和误导，概不负责?特此感谢借鉴资料和图⽚的原创者们，虽然他们并不知道⼜误导了⼀个菜鸟。
2.1 SIP (Session Initiation Protocol) 简介最先由美国哥伦⽐亚⼤学的Henning Schulzrinne 教授在1998 年初开始发起，1999 年3 ⽉由IETF 的MMUSIC(Multipart MultimediaSession Control)⼯作⼩组制定正式标准成为RFC 2543， 1999 年9⽉IETF 成⽴新的⼯作⼩组 ,负责SIP新版本2.0 的制定 ,并于2000年7 ⽉释出初版RFC 2543bis，于2001 年发布了RFC 3261 。
SIP协议中的媒体协商
Reliable Provisional Responses、
EarlyMedia扩展需求
• 扩展目的
– 传递可靠的呼叫进展 – 传递被叫侧的媒体描述
• 扩展方法
– 扩展消息 PRACK
• 为1xx响应提供消息确认
– 扩展消息头 RSeq／RAck
• 保证PRACK与对应的1xx匹配
– 1xx响应扩展消息头：RSeq – PRACK请求扩展消息头：RAck
• PRACK是1xx的“最终响应”
– 如果INVITE-1xx完成了Offer-Answer，PRACK-200PRACK可 以完成进一步的Offer-Answer
• PRACK－200PRACK是可靠传输的
– 如果可靠的1xx携带Answer，则必须建立Session
• 一次Offer-Answer结束了 • Early Session
ANM
200
INVITE ACK
200 INVITE
ACK
64 T1 ACM
ANM
CPG ?
如何传递呼叫中事件
STATE KEY LABORATORY TELECOMMUNICATION NETWORK
需求的分析（续）
UserA
INVITE SDP 100
– 增加消息
STATE KEY LABORATORY OF SWITCHING TECHNOLOGY AND TELECOMMUNICATION NETWORK
与传统Telephony业务互通的努力
• IETF
– Session Initiation Protocol for Telephones – 俗称 SIP-T
• ITU-T
rfc4576.Using a Link State Advertisement (LSA) Options Bit to Prevent Looping in BGP MPLS IP Virtual
Network Working Group E. Rosen Request for Comments: 4576 P. Psenak Category: Standards Track P. Pillay-Esnault Cisco Systems, Inc. June 2006 Using a Link State Advertisement (LSA) Options Bit toPrevent Looping in BGP/MPLS IP Virtual Private Networks (VPNs) Status of This MemoThis document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions forimprovements. Please refer to the current edition of the "InternetOfficial Protocol Standards" (STD 1) for the standardization stateand status of this protocol. Distribution of this memo is unlimited. Copyright NoticeCopyright (C) The Internet Society (2006).AbstractThis document specifies a procedure that deals with a particularissue that may arise when a Service Provider (SP) provides "BGP/MPLS IP VPN" service to a customer and the customer uses OSPFv2 toadvertise its routes to the SP. In this situation, a Customer Edge(CE) Router and a Provider Edge (PE) Router are OSPF peers, andcustomer routes are sent via OSPFv2 from the CE to the PE. Thecustomer routes are converted into BGP routes, and BGP carries themacross the backbone to other PE routers. The routes are thenconverted back to OSPF routes sent via OSPF to other CE routers. As a result of this conversion, some of the information needed toprevent loops may be lost. A procedure is needed to ensure that once a route is sent from a PE to a CE, the route will be ignored by anyPE that receives it back from a CE. This document specifies thenecessary procedure, using one of the options bits in the LSA (LinkState Advertisements) to indicate that an LSA has already beenforwarded by a PE and should be ignored by any other PEs that see it. Rosen, et al. Standards Track [Page 1]Table of Contents1. Introduction (2)2. Specification of Requirements (3)3. Information Loss and Loops (3)4. Using the LSA Options to Prevent Loops (4)5. Security Considerations (5)6. Acknowledgements (5)7. Normative References (6)1. Introduction[VPN] describes a method by which a Service Provider (SP) can use its IP backbone to provide an "IP VPN" service to customers. In thatsort of service, a customer’s edge devices (CE devices) are connected to the provider’s edge routers (PE routers). Each CE device is in a single Virtual Private Network (VPN). Each PE device may attach tomultiple CEs of the same or of different VPNs. A VPN thus consistsof a set of "network segments" connected by the SP’s backbone.A CE exchanges routes with a PE, using a routing protocol to whichthe customer and the SP jointly agree. The PE runs that routingprotocol’s decision process (i.e., it performs the routingcomputation) to determine the set of IP address prefixes for whichthe following two conditions hold:- Each address prefix in the set can be reached via that CE.- The path from that CE to each such address prefix does NOTinclude the SP backbone (i.e., it does not include any PErouters).The PE routers that attach to a particular VPN redistribute routes to these address prefixes into BGP, so that they can use BGP todistribute the VPN’s routes to each other. BGP carries these routes in the "VPN-IPv4 address family", so that they are distinct fromordinary Internet routes. The VPN-IPv4 address family also extendsthe IP addresses on the left so that address prefixes from twodifferent VPNs are always distinct to BGP, even if both VPNs use the same piece of the private RFC 1918 address space. Thus, routes from different VPNs can be carried by a single BGP instance and can bestored in a common BGP table without fear of conflict.If a PE router receives a particular VPN-IPv4 route via BGP, and ifthat PE is attached to a CE in the VPN to which the route belongs,then BGP’s decision process may install that route in the BGP routetable. If so, the PE translates the route back into an IP route and Rosen, et al. Standards Track [Page 2]redistributes it to the routing protocol that is running on the link to that CE.This methodology provides a "peer model". CE routers peer with PErouters, but CE routers at different sites do not peer with eachother.If a VPN uses OSPFv2 as its internal routing protocol, it is notnecessarily the case that the CE routers of that VPN use OSPFv2 topeer with the PE routers. Each site in a VPN can use OSPFv2 as itsintra-site routing protocol while using BGP or RIP (for example) todistribute routes to a PE router. However, it is certainlyconvenient when OSPFv2 is being used intra-site to use it on the PE- CE link as well, and [VPN] explicitly allows this. In this case, aPE will run a separate instance of OSPFv2 for each VPN that isattached to the PE; the PE will in general have multiple VPN-specific OSPFv2 routing tables.When OSPFv2 is used on a PE-CE link that belongs to a particular VPN, the PE router must redistribute to that VPN’s OSPFv2 instance certain routes that have been installed in the BGP routing table. Similarly, a PE router must redistribute to BGP routes that have been installed in the VPN-specific OSPF routing tables. Procedures for this arespecified in [VPN-OSPF].The routes that are redistributed from BGP to OSPFv2 are advertisedin LSAs that are originated by the PE. The PE acts as an OSPF border router, advertising some of these routes in AS-external LSAs, andsome in summary LSAs, as specified in [VPN-OSPF].Similarly, when a PE router receives an LSA from a CE router, it runs the OSPF routing computation. Any route that gets installed in theOSPF routing table must be translated into a VPN-IPv4 route and then redistributed into BGP. BGP will then distribute these routes to the other PE routers.2. Specification of RequirementsThe key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT","SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.3. Information Loss and LoopsA PE, say PE1, may learn a route to a particular VPN-IPv4 addressprefix via BGP. This may cause it to generate a summary LSA or anAS-external LSA in which it reports that address prefix. This LSAmay then be distributed to a particular CE, say CE1. The LSA may Rosen, et al. Standards Track [Page 3]then be distributed throughout a particular OSPF area, reachinganother CE, say CE2. CE2 may then distribute the LSA to another PE, say PE2.As stated in the previous section, PE2 must run the OSPF routingcomputation to determine whether a particular address prefix,reported in an LSA from CE2, is reachable from CE2 via a path thatdoes not include any PE router. Unfortunately, there is no standard way to do this. The OSPFv2 LSAs do not necessarily carry theinformation needed to enable PE2 to determine that the path toaddress prefix X in a particular LSA from CE2 is actually a path that includes, say PE1. If PE2 then leaks X into BGP as a VPN-IPv4 route, then PE2 is violating one of the constraints for loop-freedom in BGP; viz., that routes learned from a particular BGP domain are notredistributed back into that BGP domain. This could cause a routing loop to be created.It is therefore necessary to have a means by which an LSA may carrythe information that a particular address prefix has been learnedfrom a PE router. Any PE router that receives an LSA with thisinformation would omit the information in this LSA from its OSPFrouting computation, and thus it would not leak the information back into BGP.When a PE generates an AS-external LSA, it could use a distinct tagvalue to indicate that the LSA is carrying information about anaddress prefix for whom the path includes a PE router. However, this method is not available in the case where the PE generates a Summary LSA. Per [VPN-OSPF], each PE router must function as an OSPF area 0 router. If the PE-CE link is an area 0 link, then it is possible for the PE to receive, over that link, a summary LSA that originated atanother PE router. Thus, we need some way of marking a summary LSAto indicate that it is carrying information about a path via a PErouter.4. Using the LSA Options to Prevent LoopsThe high-order bit of the LSA Options field (a previously unused bit) is used to solve the problem described in the previous section. Werefer to this bit as the DN bit. When a type 3, 5, or 7 LSA is sent from a PE to a CE, the DN bit MUST be set. The DN bit MUST be clear in all other LSA types.Rosen, et al. Standards Track [Page 4]+-------------------------------------+| DN | * | DC | EA | N/P | MC | E | * |+-------------------------------------+Options Field with DN Bit(RFC 2328, Section A.2)When the PE receives, from a CE router, a type 3, 5, or 7 LSA withthe DN bit set, the information from that LSA MUST NOT be used during the OSPF route calculation. As a result, the LSA is not translatedinto a BGP route. The DN bit MUST be ignored in all other LSA types. This prevents routes learned via BGP from being redistributed to BGP. (This restriction is analogous to the usual OSPF restriction thatinter-area routes that are learned from area 0 are not passed back to area 0.)Note that the DN bit has no other effect on LSA handling. Inparticular, an LSA with the DN bit set will be put in the topological database, aged, flooded, etc., just as if DN were not set.5. Security ConsiderationsAn attacker may cause the DN bit to be set, in an LSA traveling from CE to PE, when the DN bit should really be clear. This may cause the address prefixes mentioned in that LSA to be unreachable from othersites of the VPN. Similarly, an attacker may cause the DN bit to be clear, in an LSA traveling in either direction, when the DN bitshould really be set. This may cause routing loops for traffic that is destined to the address prefixes mentioned in that LSA.These possibilities may be eliminated by using cryptographicauthentication as specified in Section D of [OSPFv2].6. AcknowledgementsThe idea of using the high-order options bit for this purpose is due to Derek Yeung. Thanks to Yakov Rekhter for his contribution to this work. We also wish to thank Acee Lindem for his helpful comments. Rosen, et al. Standards Track [Page 5]7. Normative References[OSPFv2] Postel, J., "Suggested Telnet Protocol Changes", RFC 328, April 1972.[VPN] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual PrivateNetworks (VPNs)", RFC 4364, February 2006.[VPN-OSPF] Rosen, E., Psenak, P., and P. Pillay-Esnault, "OSPF as the Provider/Customer Edge Protocol for BGP/MPLS IP VirtualPrivate Networks (VPNs)", RFC 4577, June 2006.Authors’ AddressesEric C. RosenCisco Systems, Inc.1414 Massachusetts AvenueBoxborough, MA 01719EMail: erosen@Peter PsenakCisco SystemsBA Business Center, 9th FloorPlynarenska 1Bratislava 82109SlovakiaEMail: ppsenak@Padma Pillay-EsnaultCisco Systems3750 Cisco WaySan Jose, CA 95134EMail: ppe@Rosen, et al. Standards Track [Page 6]Full Copyright StatementCopyright (C) The Internet Society (2006).This document is subject to the rights, licenses and restrictionscontained in BCP 78, and except as set forth therein, the authorsretain all their rights.This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNETENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THEINFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIEDWARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual PropertyThe IETF takes no position regarding the validity or scope of anyIntellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described inthis document or the extent to which any license under such rightsmight or might not be available; nor does it represent that it hasmade any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can befound in BCP 78 and BCP 79.Copies of IPR disclosures made to the IETF Secretariat and anyassurances of licenses to be made available, or the result of anattempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of thisspecification can be obtained from the IETF on-line IPR repository at /ipr.The IETF invites any interested party to bring to its attention anycopyrights, patents or patent applications, or other proprietaryrights that may cover technology that may be required to implementthis standard. Please address the information to the IETF atietf-ipr@.AcknowledgementFunding for the RFC Editor function is provided by the IETFAdministrative Support Activity (IASA).Rosen, et al. Standards Track [Page 7]。
rfc5056.On the Use of Channel Bindings to Secure Channels
Network Working Group N. Williams Request for Comments: 5056 Sun Category: Standards Track November 2007 On the Use of Channel Bindings to Secure ChannelsStatus of This MemoThis document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions forimprovements. Please refer to the current edition of the "InternetOfficial Protocol Standards" (STD 1) for the standardization stateand status of this protocol. Distribution of this memo is unlimited. AbstractThe concept of channel binding allows applications to establish that the two end-points of a secure channel at one network layer are thesame as at a higher layer by binding authentication at the higherlayer to the channel at the lower layer. This allows applications to delegate session protection to lower layers, which has variousperformance benefits.This document discusses and formalizes the concept of channel binding to secure channels.Williams Standards Track [Page 1]Table of Contents1. Introduction (3)1.1. Conventions Used in This Document (4)2. Definitions (4)2.1. Properties of Channel Binding (6)2.2. EAP Channel Binding (9)3. Authentication and Channel Binding Semantics (10)3.1. The GSS-API and Channel Binding (10)3.2. SASL and Channel Binding (11)4. Channel Bindings Specifications (11)4.1. Examples of Unique Channel Bindings (11)4.2. Examples of End-Point Channel Bindings (12)5. Uses of Channel Binding (12)6. Benefits of Channel Binding to Secure Channels (14)7. IANA Considerations (15)7.1. Registration Procedure (15)7.2. Comments on Channel Bindings Registrations (16)7.3. Change Control (17)8. Security Considerations (17)8.1. Non-Unique Channel Bindings and Channel BindingRe-Establishment (18)9. References (19)9.1. Normative References (19)9.2. Informative References (19)Appendix A. Acknowledgments (22)Williams Standards Track [Page 2]1. IntroductionIn a number of situations, it is useful for an application to be able to handle authentication within the application layer, whilesimultaneously being able to utilize session or transport security at a lower network layer. For example, IPsec [RFC4301] [RFC4303][RFC4302] is amenable to being accelerated in hardware to handle very high link speeds, but IPsec key exchange protocols and the IPsecarchitecture are not as amenable to use as a security mechanismwithin applications, particularly applications that have users asclients. A method of combining security at both layers is therefore attractive. To enable this to be done securely, it is necessary to"bind" the mechanisms together -- so as to avoid man-in-the-middlevulnerabilities and enable the mechanisms to be integrated in aseamless way. This is the objective of "Channel Bindings".The term "channel binding", as used in this document, derives fromthe Generic Security Service Application Program Interface (GSS-API) [RFC2743], which has a channel binding facility that was intended for binding GSS-API authentication to secure channels at lower networklayers. The purpose and benefits of the GSS-API channel bindingfacility were not discussed at length, and some details were leftunspecified. Now we find that this concept can be very useful,therefore we begin with a generalization and formalization of"channel binding" independent of the GSS-API.Although inspired by and derived from the GSS-API, the notion ofchannel binding described herein is not at all limited to use by GSS- API applications. We envision use of channel binding by applications that utilize other security frameworks, such as Simple Authentication and Security Layer (SASL) [RFC4422] and even protocols that providetheir own authentication mechanisms (e.g., the Key DistributionCenter (KDC) exchanges of Kerberos V [RFC4120]). We also envisionuse of the notion of channel binding in the analysis of securityprotocols.The main goal of channel binding is to be able to delegatecryptographic session protection to network layers below theapplication in hopes of being able to better leverage hardwareimplementations of cryptographic protocols. Section 5 describes some intended uses of channel binding. Also, some applications maybenefit by reducing the amount of active cryptographic state, thusreducing overhead in accessing such state and, therefore, the impact of security on latency.Williams Standards Track [Page 3]The critical security problem to solve in order to achieve suchdelegation of session protection is ensuring that there is no man-in-the-middle (MITM), from the point of view the application, at the lower network layer to which session protection is to be delegated.There may well be an MITM, particularly if either the lower networklayer provides no authentication or there is no strong connectionbetween the authentication or principals used at the application and those used at the lower network layer.Even if such MITM attacks seem particularly difficult to effect, the attacks must be prevented for certain applications to be able to make effective use of technologies such as IPsec [RFC2401] [RFC4301] orHTTP with TLS [RFC4346] in certain contexts (e.g., when there is noauthentication to speak of, or when one node’s set of trust anchorsis too weak to believe that it can authenticate its peers).Additionally, secure channels that are susceptible to MITM attacksbecause they provide no useful end-point authentication are usefulwhen combined with application-layer authentication (otherwise theyare only somewhat "better than nothing" -- see Better Than NothingSecurity (BTNS) [BTNS-AS]).For example, Internet Small Computer Systems Interface (iSCSI)[RFC3720] provides for application-layer authentication (e.g., using Kerberos V), but relies on IPsec for transport protection; iSCSI does not provide a binding between the two. iSCSI initiators have to becareful to make sure that the name of the server authenticated at the application layer and the name of the peer at the IPsec layer match-- an informal form of channel binding.This document describes a solution: the use of "channel binding" tobind authentication at application layers to secure sessions at lower layers in the network stack.1.1. Conventions Used in This DocumentThe key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT","SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].2. Definitionso Secure channel: a packet, datagram, octet stream connection, orsequence of connections between two end-points that affordscryptographic integrity and, optionally, confidentiality to dataexchanged over it. We assume that the channel is secure -- if an attacker can successfully cryptanalyze a channel’s session keys,for example, then the channel is not secure.Williams Standards Track [Page 4]o Channel binding: the process of establishing that no man-in-the-middle exists between two end-points that have been authenticated at one network layer but are using a secure channel at a lowernetwork layer. This term is used as a noun.o Channel bindings: [See historical note below.]Generally, some data that "names" a channel or one or both ofits end-points such that if this data can be shown, at a higher network layer, to be the same at both ends of a channel, thenthere are no MITMs between the two end-points at that highernetwork layer. This term is used as a noun.More formally, there are two types of channel bindings:+ unique channel bindings:channel bindings that name a channel in a cryptographically secure manner and uniquely in time;+ end-point channel bindings:channel bindings that name the authenticated end-points, or even a single end-point, of a channel which are, in turn,securely bound to the channel, but which do not identify achannel uniquely in time.o Cryptographic binding: (e.g., "cryptographically bound") acryptographic operation that causes an object, such as a privateencryption or signing key, or an established secure channel, to"speak for" [Lampson91] some principal, such as a user, acomputer, etcetera. For example, a Public Key Infrastructure for X.509 Certificates (PKIX) certificate binds a private key to thename of a principal in the trust domain of the certificate’sissuer such that a possessor of said private key can act on behalf of the user (or other entity) named by the certificate.Cryptographic bindings are generally asymmetric in nature (not to be confused with symmetric or asymmetric key cryptography) in that an object is rendered capable of standing for another, but thereverse is not usually the case (we don’t say that a user speaksfor their private keys, but we do say that the user’s private keys speak for the user).Note that there may be many instances of "cryptographic binding" inan application of channel binding. The credentials that authenticate principals at the application layer bind private or secret keys tothe identities of those principals, such that said keys speak for Williams Standards Track [Page 5]them. A secure channel typically consists of symmetric session keys used to provide confidentiality and integrity protection to data sent over the channel; each end-point’s session keys speak for that end-point of the channel. Finally, each end-point of a channel bound to authentication at the application layer speaks for the principalauthenticated at the application layer on the same side of thechannel.The terms defined above have been in use for many years and have been taken to mean, at least in some contexts, what is stated below.Unfortunately this means that "channel binding" can refer to thechannel binding operation and, sometimes to the name of a channel,and "channel bindings" -- a difference of only one letter --generally refers to the name of a channel.Note that the Extensible Authentication Protocol (EAP) [RFC3748] uses "channel binding" to refer to a facility that may appear to besimilar to the one decribed here, but it is, in fact, quitedifferent. See Section 2.2 for mode details.2.1. Properties of Channel BindingApplications, authentication frameworks (e.g., the GSS-API, SASL),security mechanisms (e.g., the Kerberos V GSS-API mechanism[RFC1964]), and secure channels must meet the requirements and should follow the recommendations that are listed below.Requirements:o In order to use channel binding, applications MUST verify that the same channel bindings are observed at either side of the channel. To do this, the application MUST use an authentication protocol at the application layer to authenticate one, the other, or bothapplication peers (one at each end of the channel).* If the authentication protocol used by the application supports channel binding, the application SHOULD use it.* An authentication protocol that supports channel binding MUSTprovide an input slot in its API for a "handle" to the channel, or its channel bindings.* If the authentication protocol does not support a channelbinding operation, but provides a "security layer" with atleast integrity protection, then the application MUST use theauthentication protocol’s integrity protection facilities toexchange channel bindings, or cryptographic hashes thereof. Williams Standards Track [Page 6]* The name of the type of channel binding MUST be used by theapplication and/or authentication protocol to avoid ambiguityabout which of several possible types of channels is beingbound. If nested instances of the same type of channel areavailable, then the innermost channel MUST be used.o Specifications of channel bindings for any secure channels MUSTprovide for a single, canonical octet string encoding of thechannel bindings. Under this framework, channel bindings MUSTstart with the channel binding unique prefix followed by a colon(ASCII 0x3A).o The channel bindings for a given type of secure channel MUST beconstructed in such a way that an MITM could not easily force the channel bindings of a given channel to match those of another.o Unique channel bindings MUST bind not only the key exchange forthe secure channel, but also any negotiations and authenticationthat may have taken place to establish the channel.o End-point channel bindings MUST be bound into the secure channeland all its negotiations. For example, a public key as an end-point channel binding should be used to verify a signature of such negotiations (or to encrypt them), including the initial keyexchange and negotiation messages for that channel -- such a keywould then be bound into the channel. A certificate name as end- point channel binding could also be bound into the channel in asimilar way, though in the case of a certificate name, the binding also depends on the strength of the authentication of that name(that is, the validation of the certificate, the trust anchors,the algorithms used in the certificate path construction andvalidation, etcetera).o End-point channel bindings MAY be identifiers (e.g., certificatenames) that must be authenticated through some infrastructure,such as a public key infrastructure (PKI). In such cases,applications MUST ensure that the channel provides adequateauthentication of such identifiers (e.g., that the certificatevalidation policy and trust anchors used by the channel satisfythe application’s requirements). To avoid implementationdifficulties in addressing this requirement, applications SHOULDuse cryptographic quantities as end-point channel bindings, suchas certificate-subject public keys.o Applications that desire confidentiality protection MUST useapplication-layer session protection services for confidentiality protection when the bound channel does not provide confidentiality protection.Williams Standards Track [Page 7]o The integrity of a secure channel MUST NOT be weakened shouldtheir channel bindings be revealed to an attacker. That is, theconstruction of the channel bindings for any type of securechannel MUST NOT leak secret information about the channel. End- point channel bindings, however, MAY leak information about theend-points of the channel (e.g., their names).o The channel binding operation MUST be at least integrity protected in the security mechanism used at the application layer.o Authentication frameworks and mechanisms that support channelbinding MUST communicate channel binding failure to applications. o Applications MUST NOT send sensitive information, requiringconfidentiality protection, over the underlying channel prior tocompleting the channel binding operation.Recommendations:o End-point channel bindings where the end-points are meaningfulnames SHOULD NOT be used when the channel does not provideconfidentiality protection and privacy protection is desired.Alternatively, channels that export such channel bindings SHOULDprovide for the use of a digest and SHOULD NOT introduce newdigest/hash agility problems as a result.Options:o Authentication frameworks and mechanisms that support channelbinding MAY fail to establish authentication if channel bindingfails.o Applications MAY send information over the underlying channel and without integrity protection from the application-layerauthentication protocol prior to completing the channel bindingoperation if such information requires only integrity protection. This could be useful for optimistic negotiations.o A security mechanism MAY exchange integrity-protected channelbindings.o A security mechanism MAY exchange integrity-protected digests ofchannel bindings. Such mechanisms SHOULD provide for hash/digest agility.o A security mechanism MAY use channel bindings in key exchange,authentication, or key derivation, prior to the exchange of"authenticator" messages.Williams Standards Track [Page 8]2.2. EAP Channel BindingThis section is informative. This document does not update EAP[RFC3748], it neither normatively describes, nor does it imposerequirements on any aspect of EAP or EAP methods.EAP [RFC3748] includes a concept of channel binding described asfollows:The communication within an EAP method of integrity-protectedchannel properties such as endpoint identifiers which can becompared to values communicated via out of band mechanisms (suchas via a AAA or lower layer protocol).Section 7.15 of [RFC3748] describes the problem as one where aNetwork Access Server (NAS) (a.k.a. "authenticator") may lie to thepeer (client) and cause the peer to make incorrect authorizationdecisions (e.g., as to what traffic may transit through the NAS).This is not quite like the purpose of generic channel binding (MITMdetection).Section 7.15 of [RFC3748] calls for "a protected exchange of channel properties such as endpoint identifiers" such that "it is possible to match the channel properties provided by the authenticator via out-of-band mechanisms against those exchanged within the EAP method".This has sometimes been taken to be very similar to the genericnotion of channel binding provided here. However, there is a verysubtle difference between the two concepts of channel binding thatmakes it much too difficult to put forth requirements andrecommendations that apply to both. The difference is about thelower-layer channel:o In the generic channel binding case, the identities of either end of this channel are irrelevant to anything other than theconstruction of a name for that channel, in which case theidentities of the channel’s end-points must be established apriori.o Whereas in the EAP case, the identity of the NAS end of thechannel, and even security properties of the channel itself, maybe established during or after authentication of the EAP peer tothe EAP server.In other words: there is a fundamental difference in mechanics(timing of lower-layer channel establishment) and in purpose(authentication of lower-layer channel properties for authorizationpurposes vs. MITM detection).Williams Standards Track [Page 9]After some discussion we have concluded that there is no simple wayto obtain requirements and recommendations that apply to both generic and EAP channel binding. Therefore, EAP is out of the scope of this document.3. Authentication and Channel Binding SemanticsSome authentication frameworks and/or mechanisms provide for channel binding, such as the GSS-API and some GSS-API mechanisms, whereasothers may not, such as SASL (however, ongoing work is adding channel binding support to SASL). Semantics may vary with respect tonegotiation, how the binding occurs, and handling of channel binding failure (see below).Where suitable channel binding facilities are not provided,application protocols MAY include a separate, protected exchange ofchannel bindings. In order to do this, the application-layerauthentication service must provide message protection services (atleast integrity protection).3.1. The GSS-API and Channel BindingThe GSS-API [RFC2743] provides for the use of channel binding during initialization of GSS-API security contexts, though GSS-APImechanisms are not required to support this facility.This channel binding facility is described in [RFC2743] and[RFC2744].GSS-API mechanisms must fail security context establishment whenchannel binding fails, and the GSS-API provides no mechanism for the negotiation of channel binding. As a result GSS-API applicationsmust agree a priori, through negotiation or otherwise, on the use of channel binding.Fortunately, it is possible to design GSS-API pseudo-mechanisms that simply wrap around existing mechanisms for the purpose of allowingapplications to negotiate the use of channel binding within theirexisting methods for negotiating GSS-API mechanisms. For example,NFSv4 [RFC3530] provides its own GSS-API mechanism negotiation, asdoes the SSHv2 protocol [RFC4462]. Such pseudo-mechanisms are being proposed separately, see [STACKABLE].Williams Standards Track [Page 10]3.2. SASL and Channel BindingSASL [RFC4422] does not yet provide for the use of channel bindingduring initialization of SASL contexts.Work is ongoing [SASL-GS2] to specify how SASL, particularly its new bridge to the GSS-API, performs channel binding. SASL will likelydiffer from the GSS-API in its handling of channel binding failure(i.e., when there may be an MITM) in that channel bindingsuccess/failure will only affect the negotiation of SASL securitylayers. That is, when channel binding succeeds, SASL should selectno security layers, leaving session cryptographic protection to thesecure channel that SASL authentication has been bound to.4. Channel Bindings SpecificationsChannel bindings for various types of secure channels are notdescribed herein. Some channel bindings specifications can be found in:+--------------------+----------------------------------------------+ | Secure Channel | Reference | | Type | | +--------------------+----------------------------------------------+ | SSHv2 | [SSH-CB] | | | | | TLS | [TLS-CB] | | | | | IPsec | There is no specification for IPsec channel | | | bindings yet, but the IETF Better Than | | | Nothing Security (BTNS) WG is working to | | | specify IPsec channels, and possibly IPsec | | | channel bindings. | +--------------------+----------------------------------------------+ 4.1. Examples of Unique Channel BindingsThe following text is not normative, but is here to show how onemight construct channel bindings for various types of securechannels.For SSHv2 [RFC4251] the SSHv2 session ID should suffice as it is acryptographic binding of all relevant SSHv2 connection parameters:key exchange and negotiation.The TLS [RFC4346] session ID is simply assigned by the server. Assuch, the TLS session ID does not have the required properties to be useful as a channel binding because any MITM, posing as the server, Williams Standards Track [Page 11]can simply assign the same session ID to the victim client as theserver assigned to the MITM. Instead, the initial, unencrypted TLSfinished messages (the client’s, the server’s, or both) aresufficient as they are the output of the TLS pseudo-random function, keyed with the session key, applied to all handshake material.4.2. Examples of End-Point Channel BindingsThe following text is not normative, but is here to show how onemight construct channel bindings for various types of securechannels.For SSHv2 [RFC4251] the SSHv2 host public key, when present, shouldsuffice as it is used to sign the algorithm suite negotiation andDiffie-Hellman key exchange; as long the client observes the hostpublic key that corresponds to the private host key that the serverused, then there cannot be an MITM in the SSHv2 connection. Notethat not all SSHv2 key exchanges use host public keys; therefore,this channel bindings construction is not as useful as the one given in Section 4.1.For TLS [RFC4346]the server certificate should suffice for the samereasons as above. Again, not all TLS cipher suites involve servercertificates; therefore, the utility of this construction of channel bindings is limited to scenarios where server certificates arecommonly used.5. Uses of Channel BindingUses for channel binding identified so far:o Delegating session cryptographic protection to layers wherehardware can reasonably be expected to support relevantcryptographic protocols:* NFSv4 [RFC3530] with Remote Direct Data Placement (RDDP)[NFS-DDP] for zero-copy reception where network interfacecontrollers (NICs) support RDDP. Cryptographic sessionprotection would be delegated to Encapsulating Security Payload (ESP) [RFC4303] / Authentication Headers (AHs) [RFC4302].* iSCSI [RFC3720] with Remote Direct Memory Access (RDMA)[RFC5046]. Cryptographic session protection would be delegated to ESP/AH.* HTTP with TLS [RFC2817] [RFC2818]. In situations involvingproxies, users may want to bind authentication to a TLS channel between the last client-side proxy and the first server-side Williams Standards Track [Page 12]proxy ("concentrator"). There is ongoing work to expand theset of choices for end-to-end authentication at the HTTP layer, that, coupled with channel binding to TLS, would allow forproxies while not forgoing protection over public internets.o Reducing the number of live cryptographic contexts that anapplication must maintain:* NFSv4 [RFC3530] multiplexes multiple users onto individualconnections. Each user is authenticated separately, and users’ remote procedure calls (RPCs) are protected with per-user GSS- API security contexts. This means that large timesharingclients must often maintain many cryptographic contexts per-NFSv4 connection. With channel binding to IPsec, they couldmaintain a much smaller number of cryptographic contexts per-NFSv4 connection, thus reducing memory pressure andinteractions with cryptographic hardware.For example, applications that wish to use RDDP to achieve zero-copy semantics on reception may use a network layer understood by NICs to offload delivery of application data into pre-arranged memorybuffers. Note that in order to obtain zero-copy reception semantics either application data has to be in cleartext relative to this RDDP layer, or the RDDP implementation must know how to implementcryptographic session protection protocols used at the applicationlayer.There are a multitude of application-layer cryptographic sessionprotection protocols available. It is not reasonable to expect that NICs should support many such protocols. Further, some applicationprotocols may maintain many cryptographic session contexts per-connection (for example, NFSv4 does). It is thought to be simpler to push the cryptographic session protection down the network stack (to IPsec), and yet be able to produce NICs that offload other operations (i.e., TCP/IP, ESP/AH, and DDP), than it would be to add support inthe NIC for the many session cryptographic protection protocols inuse in common applications at the application layer.Williams Standards Track [Page 13]The following figure shows how the various network layers arerelated:+---------------------+| Application layer |<---+| |<-+ | In cleartext, relative+---------------------+ | | to each other.| RDDP |<---++---------------------+ || TCP/SCTP |<-++---------------------+ | Channel binding of app-layer| ESP/AH |<-+ authentication to IPsec+---------------------+| IP |+---------------------+| ... |+---------------------+6. Benefits of Channel Binding to Secure ChannelsThe use of channel binding to delegate session cryptographicprotection include:o Performance improvements by avoiding double protection ofapplication data in cases where IPsec is in use and applicationsprovide their own secure channels.o Performance improvements by leveraging hardware-accelerated IPsec. o Performance improvements by allowing RDDP hardware offloading tobe integrated with IPsec hardware acceleration.Where protocols layered above RDDP use privacy protection, RDDP offload cannot be done. Thus, by using channel binding toIPsec, the privacy protection is moved to IPsec, which islayered below RDDP. So, RDDP can address application protocol data that’s in cleartext relative to the RDDP headers.o Latency improvements for applications that multiplex multipleusers onto a single channel, such as NFS with RPCSEC_GSS[RFC2203].Delegation of session cryptographic protection to IPsec requiresfeatures not yet specified. There is ongoing work to specify:o IPsec channels [CONN-LATCH];Williams Standards Track [Page 14]。
RFC3489 -- STUN - Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translato
Network Working Group J. Rosenberg Request for Comments: 3489 J. Weinberger Category: Standards Track dynamicsoft C. Huitema Microsoft R. Mahy Cisco March 2003 STUN - Simple Traversal of User Datagram Protocol (UDP)Through Network Address Translators (NATs)Status of this MemoThis document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions forimprovements. Please refer to the current edition of the "InternetOfficial Protocol Standards" (STD 1) for the standardization stateand status of this protocol. Distribution of this memo is unlimited. Copyright NoticeCopyright (C) The Internet Society (2003). All Rights Reserved. AbstractSimple Traversal of User Datagram Protocol (UDP) Through NetworkAddress Translators (NATs) (STUN) is a lightweight protocol thatallows applications to discover the presence and types of NATs andfirewalls between them and the public Internet. It also provides the ability for applications to determine the public Internet Protocol(IP) addresses allocated to them by the NAT. STUN works with manyexisting NATs, and does not require any special behavior from them.As a result, it allows a wide variety of applications to work through existing NAT infrastructure.Table of Contents1. Applicability Statement (3)2. Introduction (3)3. Terminology (4)4. Definitions (5)5. NAT Variations (5)6. Overview of Operation (6)7. Message Overview (8)8. Server Behavior (10)8.1 Binding Requests (10)RFC 3489 STUN March 20038.2 Shared Secret Requests (13)9. Client Behavior (14)9.1 Discovery (15)9.2 Obtaining a Shared Secret (15)9.3 Formulating the Binding Request (17)9.4 Processing Binding Responses (17)10. Use Cases (19)10.1 Discovery Process (19)10.2 Binding Lifetime Discovery (21)10.3 Binding Acquisition (23)11. Protocol Details (24)11.1 Message Header (25)11.2 Message Attributes (26)11.2.1 MAPPED-ADDRESS (27)11.2.2 RESPONSE-ADDRESS (27)11.2.3 CHANGED-ADDRESS (28)11.2.4 CHANGE-REQUEST (28)11.2.5 SOURCE-ADDRESS (28)11.2.6 USERNAME (28)11.2.7 PASSWORD (29)11.2.8 MESSAGE-INTEGRITY (29)11.2.9 ERROR-CODE (29)11.2.10 UNKNOWN-ATTRIBUTES (31)11.2.11 REFLECTED-FROM (31)12. Security Considerations (31)12.1 Attacks on STUN (31)12.1.1 Attack I: DDOS Against a Target (32)12.1.2 Attack II: Silencing a Client (32)12.1.3 Attack III: Assuming the Identity of a Client 32 12.1.4 Attack IV: Eavesdropping (33)12.2 Launching the Attacks (33)12.2.1 Approach I: Compromise a LegitimateSTUN Server (33)12.2.2 Approach II: DNS Attacks (34)12.2.3 Approach III: Rogue Router or NAT (34)12.2.4 Approach IV: MITM (35)12.2.5 Approach V: Response Injection Plus DoS (35)12.2.6 Approach VI: Duplication (35)12.3 Countermeasures (36)12.4 Residual Threats (37)13. IANA Considerations (38)14. IAB Considerations (38)14.1 Problem Definition (38)14.2 Exit Strategy (39)14.3 Brittleness Introduced by STUN (40)14.4 Requirements for a Long Term Solution (42)14.5 Issues with Existing NAPT Boxes (43)14.6 In Closing (43)RFC 3489 STUN March 200315. Acknowledgments (44)16. Normative References (44)17. Informative References (44)18. Authors' Addresses (46)19. Full Copyright Statement (47)1. Applicability StatementThis protocol is not a cure-all for the problems associated with NAT. It does not enable incoming TCP connections through NAT. It allowsincoming UDP packets through NAT, but only through a subset ofexisting NAT types. In particular, STUN does not enable incoming UDP packets through symmetric NATs (defined below), which are common inlarge enterprises. STUN's discovery procedures are based onassumptions on NAT treatment of UDP; such assumptions may proveinvalid down the road as new NAT devices are deployed. STUN does not work when it is used to obtain an address to communicate with a peer which happens to be behind the same NAT. STUN does not work when the STUN server is not in a common shared address realm. For a morecomplete discussion of the limitations of STUN, see Section 14.2. IntroductionNetwork Address Translators (NATs), while providing many benefits,also come with many drawbacks. The most troublesome of thosedrawbacks is the fact that they break many existing IP applications, and make it difficult to deploy new ones. Guidelines have beendeveloped [8] that describe how to build "NAT friendly" protocols,but many protocols simply cannot be constructed according to thoseguidelines. Examples of such protocols include almost all peer-to-peer protocols, such as multimedia communications, file sharing andgames.To combat this problem, Application Layer Gateways (ALGs) have beenembedded in NATs. ALGs perform the application layer functionsrequired for a particular protocol to traverse a NAT. Typically,this involves rewriting application layer messages to containtranslated addresses, rather than the ones inserted by the sender of the message. ALGs have serious limitations, including scalability,reliability, and speed of deploying new applications. To resolvethese problems, the Middlebox Communications (MIDCOM) protocol isbeing developed [9]. MIDCOM allows an application entity, such as an end client or network server of some sort (like a Session Initiation Protocol (SIP) proxy [10]) to control a NAT (or firewall), in orderto obtain NAT bindings and open or close pinholes. In this way, NATs and applications can be separated once more, eliminating the need for embedding ALGs in NATs, and resolving the limitations imposed bycurrent architectures.RFC 3489 STUN March 2003 Unfortunately, MIDCOM requires upgrades to existing NAT andfirewalls, in addition to application components. Complete upgrades of these NAT and firewall products will take a long time, potentially years. This is due, in part, to the fact that the deployers of NATand firewalls are not the same people who are deploying and usingapplications. As a result, the incentive to upgrade these deviceswill be low in many cases. Consider, for example, an airportInternet lounge that provides access with a NAT. A user connectingto the NATed network may wish to use a peer-to-peer service, butcannot, because the NAT doesn't support it. Since the administrators of the lounge are not the ones providing the service, they are notmotivated to upgrade their NAT equipment to support it, using either an ALG, or MIDCOM.Another problem is that the MIDCOM protocol requires that the agentcontrolling the middleboxes know the identity of those middleboxes,and have a relationship with them which permits control. In manyconfigurations, this will not be possible. For example, many cableaccess providers use NAT in front of their entire access network.This NAT could be in addition to a residential NAT purchased andoperated by the end user. The end user will probably not have acontrol relationship with the NAT in the cable access network, andmay not even know of its existence.Many existing proprietary protocols, such as those for online games(such as the games described in RFC 3027 [11]) and Voice over IP,have developed tricks that allow them to operate through NATs without changing those NATs. This document is an attempt to take some ofthose ideas, and codify them into an interoperable protocol that can meet the needs of many applications.The protocol described here, Simple Traversal of UDP Through NAT(STUN), allows entities behind a NAT to first discover the presenceof a NAT and the type of NAT, and then to learn the addressesbindings allocated by the NAT. STUN requires no changes to NATs, and works with an arbitrary number of NATs in tandem between theapplication entity and the public Internet.3. TerminologyIn this document, the key words "MUST", "MUST NOT", "REQUIRED","SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119 [1] and indicate requirement levels for compliant STUNimplementations.RFC 3489 STUN March 2003 4. DefinitionsSTUN Client: A STUN client (also just referred to as a client)is an entity that generates STUN requests. A STUN client canexecute on an end system, such as a user's PC, or can run in anetwork element, such as a conferencing server.STUN Server: A STUN Server (also just referred to as a server)is an entity that receives STUN requests, and sends STUNresponses. STUN servers are generally attached to the publicInternet.5. NAT VariationsIt is assumed that the reader is familiar with NATs. It has beenobserved that NAT treatment of UDP varies among implementations. The four treatments observed in implementations are:Full Cone: A full cone NAT is one where all requests from thesame internal IP address and port are mapped to the same external IP address and port. Furthermore, any external host can send apacket to the internal host, by sending a packet to the mappedexternal address.Restricted Cone: A restricted cone NAT is one where all requestsfrom the same internal IP address and port are mapped to the same external IP address and port. Unlike a full cone NAT, an external host (with IP address X) can send a packet to the internal hostonly if the internal host had previously sent a packet to IPaddress X.Port Restricted Cone: A port restricted cone NAT is like arestricted cone NAT, but the restriction includes port numbers.Specifically, an external host can send a packet, with source IPaddress X and source port P, to the internal host only if theinternal host had previously sent a packet to IP address X andport P.Symmetric: A symmetric NAT is one where all requests from thesame internal IP address and port, to a specific destination IPaddress and port, are mapped to the same external IP address andport. If the same host sends a packet with the same sourceaddress and port, but to a different destination, a differentmapping is used. Furthermore, only the external host thatreceives a packet can send a UDP packet back to the internal host.RFC 3489 STUN March 2003 Determining the type of NAT is important in many cases. Depending on what the application wants to do, it may need to take the particular behavior into account.6. Overview of OperationThis section is descriptive only. Normative behavior is described in Sections 8 and 9./-----\// STUN \\| Server |\\ //\-----/+--------------+ Public Internet................| NAT 2 |.......................+--------------++--------------+ Private NET 2................| NAT 1 |.......................+--------------+/-----\// STUN \\| Client |\\ // Private NET 1\-----/Figure 1: STUN ConfigurationThe typical STUN configuration is shown in Figure 1. A STUN clientis connected to private network 1. This network connects to private network 2 through NAT 1. Private network 2 connects to the publicInternet through NAT 2. The STUN server resides on the publicInternet.STUN is a simple client-server protocol. A client sends a request to a server, and the server returns a response. There are two types of requests - Binding Requests, sent over UDP, and Shared SecretRequests, sent over TLS [2] over TCP. Shared Secret Requests ask the server to return a temporary username and password. This usernameand password are used in a subsequent Binding Request and BindingResponse, for the purposes of authentication and message integrity.RFC 3489 STUN March 2003 Binding requests are used to determine the bindings allocated byNATs. The client sends a Binding Request to the server, over UDP.The server examines the source IP address and port of the request,and copies them into a response that is sent back to the client.There are some parameters in the request that allow the client to ask that the response be sent elsewhere, or that the server send theresponse from a different address and port. There are attributes for providing message integrity and authentication.The trick is using STUN to discover the presence of NAT, and to learn and use the bindings they allocate.The STUN client is typically embedded in an application which needsto obtain a public IP address and port that can be used to receivedata. For example, it might need to obtain an IP address and port to receive Real Time Transport Protocol (RTP) [12] traffic. When theapplication starts, the STUN client within the application sends aSTUN Shared Secret Request to its server, obtains a username andpassword, and then sends it a Binding Request. STUN servers can bediscovered through DNS SRV records [3], and it is generally assumedthat the client is configured with the domain to use to find the STUN server. Generally, this will be the domain of the provider of theservice the application is using (such a provider is incented todeploy STUN servers in order to allow its customers to use itsapplication through NAT). Of course, a client can determine theaddress or domain name of a STUN server through other means. A STUN server can even be embedded within an end system.The STUN Binding Request is used to discover the presence of a NAT,and to discover the public IP address and port mappings generated by the NAT. Binding Requests are sent to the STUN server using UDP.When a Binding Request arrives at the STUN server, it may have passed through one or more NATs between the STUN client and the STUN server. As a result, the source address of the request received by the server will be the mapped address created by the NAT closest to the server. The STUN server copies that source IP address and port into a STUNBinding Response, and sends it back to the source IP address and port of the STUN request. For all of the NAT types above, this responsewill arrive at the STUN client.When the STUN client receives the STUN Binding Response, it compares the IP address and port in the packet with the local IP address andport it bound to when the request was sent. If these do not match,the STUN client is behind one or more NATs. In the case of a full-cone NAT, the IP address and port in the body of the STUN responseare public, and can be used by any host on the public Internet tosend packets to the application that sent the STUN request. Anapplication need only listen on the IP address and port from whichRFC 3489 STUN March 2003 the STUN request was sent. Any packets sent by a host on the publicInternet to the public address and port learned by STUN will bereceived by the application.Of course, the host may not be behind a full-cone NAT. Indeed, itdoesn't yet know what type of NAT it is behind. To determine that,the client uses additional STUN Binding Requests. The exactprocedure is flexible, but would generally work as follows. Theclient would send a second STUN Binding Request, this time to adifferent IP address, but from the same source IP address and port.If the IP address and port in the response are different from thosein the first response, the client knows it is behind a symmetric NAT. To determine if it's behind a full-cone NAT, the client can send aSTUN Binding Request with flags that tell the STUN server to send aresponse from a different IP address and port than the request wasreceived on. In other words, if the client sent a Binding Request to IP address/port A/B using a source IP address/port of X/Y, the STUNserver would send the Binding Response to X/Y using source IPaddress/port C/D. If the client receives this response, it knows it is behind a full cone NAT.STUN also allows the client to ask the server to send the BindingResponse from the same IP address the request was received on, butwith a different port. This can be used to detect whether the client is behind a port restricted cone NAT or just a restricted cone NAT.It should be noted that the configuration in Figure 1 is not the only permissible configuration. The STUN server can be located anywhere, including within another client. The only requirement is that theSTUN server is reachable by the client, and if the client is tryingto obtain a publicly routable address, that the server reside on the public Internet.7. Message OverviewSTUN messages are TLV (type-length-value) encoded using big endian(network ordered) binary. All STUN messages start with a STUNheader, followed by a STUN payload. The payload is a series of STUN attributes, the set of which depends on the message type. The STUNheader contains a STUN message type, transaction ID, and length. The message type can be Binding Request, Binding Response, Binding Error Response, Shared Secret Request, Shared Secret Response, or SharedSecret Error Response. The transaction ID is used to correlaterequests and responses. The length indicates the total length of the STUN payload, not including the header. This allows STUN to run over TCP. Shared Secret Requests are always sent over TCP (indeed, using TLS over TCP).RFC 3489 STUN March 2003 Several STUN attributes are defined. The first is a MAPPED-ADDRESSattribute, which is an IP address and port. It is always placed inthe Binding Response, and it indicates the source IP address and port the server saw in the Binding Request. There is also a RESPONSE-ADDRESS attribute, which contains an IP address and port. TheRESPONSE-ADDRESS attribute can be present in the Binding Request, and indicates where the Binding Response is to be sent. It's optional,and when not present, the Binding Response is sent to the source IPaddress and port of the Binding Request.The third attribute is the CHANGE-REQUEST attribute, and it contains two flags to control the IP address and port used to send theresponse. These flags are called "change IP" and "change port"flags. The CHANGE-REQUEST attribute is allowed only in the BindingRequest. The "change IP" and "change port" flags are useful fordetermining whether the client is behind a restricted cone NAT orrestricted port cone NAT. They instruct the server to send theBinding Responses from a different source IP address and port. TheCHANGE-REQUEST attribute is optional in the Binding Request.The fourth attribute is the CHANGED-ADDRESS attribute. It is present in Binding Responses. It informs the client of the source IP address and port that would be used if the client requested the "change IP"and "change port" behavior.The fifth attribute is the SOURCE-ADDRESS attribute. It is onlypresent in Binding Responses. It indicates the source IP address and port where the response was sent from. It is useful for detectingtwice NAT configurations.The sixth attribute is the USERNAME attribute. It is present in aShared Secret Response, which provides the client with a temporaryusername and password (encoded in the PASSWORD attribute). TheUSERNAME is also present in Binding Requests, serving as an index to the shared secret used for the integrity protection of the BindingRequest. The seventh attribute, PASSWORD, is only found in SharedSecret Response messages. The eight attribute is the MESSAGE-INTEGRITY attribute, which contains a message integrity check overthe Binding Request or Binding Response.The ninth attribute is the ERROR-CODE attribute. This is present in the Binding Error Response and Shared Secret Error Response. Itindicates the error that has occurred. The tenth attribute is theUNKNOWN-ATTRIBUTES attribute, which is present in either the Binding Error Response or Shared Secret Error Response. It indicates themandatory attributes from the request which were unknown. Theeleventh attribute is the REFLECTED-FROM attribute, which is present in Binding Responses. It indicates the IP address and port of theRFC 3489 STUN March 2003 sender of a Binding Request, used for traceability purposes toprevent certain denial-of-service attacks.8. Server BehaviorThe server behavior depends on whether the request is a BindingRequest or a Shared Secret Request.8.1 Binding RequestsA STUN server MUST be prepared to receive Binding Requests on fouraddress/port combinations - (A1, P1), (A2, P1), (A1, P2), and (A2,P2). (A1, P1) represent the primary address and port, and these are the ones obtained through the client discovery procedures below.Typically, P1 will be port 3478, the default STUN port. A2 and P2are arbitrary. A2 and P2 are advertised by the server through theCHANGED-ADDRESS attribute, as described below.It is RECOMMENDED that the server check the Binding Request for aMESSAGE-INTEGRITY attribute. If not present, and the server requires integrity checks on the request, it generates a Binding ErrorResponse with an ERROR-CODE attribute with response code 401. If the MESSAGE-INTEGRITY attribute was present, the server computes the HMAC over the request as described in Section 11.2.8. The key to usedepends on the shared secret mechanism. If the STUN Shared SecretRequest was used, the key MUST be the one associated with theUSERNAME attribute present in the request. If the USERNAME attribute was not present, the server MUST generate a Binding Error Response.The Binding Error Response MUST include an ERROR-CODE attribute with response code 432. If the USERNAME is present, but the serverdoesn't remember the shared secret for that USERNAME (because ittimed out, for example), the server MUST generate a Binding ErrorResponse. The Binding Error Response MUST include an ERROR-CODEattribute with response code 430. If the server does know the shared secret, but the computed HMAC differs from the one in the request,the server MUST generate a Binding Error Response with an ERROR-CODE attribute with response code 431. The Binding Error Response is sent to the IP address and port the Binding Request came from, and sentfrom the IP address and port the Binding Request was sent to.Assuming the message integrity check passed, processing continues.The server MUST check for any attributes in the request with valuesless than or equal to 0x7fff which it does not understand. If itencounters any, the server MUST generate a Binding Error Response,and it MUST include an ERROR-CODE attribute with a 420 response code.RFC 3489 STUN March 2003 That response MUST contain an UNKNOWN-ATTRIBUTES attribute listingthe attributes with values less than or equal to 0x7fff which werenot understood. The Binding Error Response is sent to the IP address and port the Binding Request came from, and sent from the IP address and port the Binding Request was sent to.Assuming the request was correctly formed, the server MUST generate a single Binding Response. The Binding Response MUST contain the same transaction ID contained in the Binding Request. The length in themessage header MUST contain the total length of the message in bytes, excluding the header. The Binding Response MUST have a message type of "Binding Response".The server MUST add a MAPPED-ADDRESS attribute to the BindingResponse. The IP address component of this attribute MUST be set to the source IP address observed in the Binding Request. The portcomponent of this attribute MUST be set to the source port observedin the Binding Request.If the RESPONSE-ADDRESS attribute was absent from the BindingRequest, the destination address and port of the Binding ResponseMUST be the same as the source address and port of the BindingRequest. Otherwise, the destination address and port of the Binding Response MUST be the value of the IP address and port in theRESPONSE-ADDRESS attribute.The source address and port of the Binding Response depend on thevalue of the CHANGE-REQUEST attribute and on the address and port the Binding Request was received on, and are summarized in Table 1.Let Da represent the destination IP address of the Binding Request(which will be either A1 or A2), and Dp represent the destinationport of the Binding Request (which will be either P1 or P2). Let Ca represent the other address, so that if Da is A1, Ca is A2. If Da is A2, Ca is A1. Similarly, let Cp represent the other port, so that if Dp is P1, Cp is P2. If Dp is P2, Cp is P1. If the "change port"flag was set in CHANGE-REQUEST attribute of the Binding Request, and the "change IP" flag was not set, the source IP address of theBinding Response MUST be Da and the source port of the BindingResponse MUST be Cp. If the "change IP" flag was set in the Binding Request, and the "change port" flag was not set, the source IPaddress of the Binding Response MUST be Ca and the source port of the Binding Response MUST be Dp. When both flags are set, the source IP address of the Binding Response MUST be Ca and the source port of the Binding Response MUST be Cp. If neither flag is set, or if theCHANGE-REQUEST attribute is absent entirely, the source IP address of the Binding Response MUST be Da and the source port of the BindingResponse MUST be Dp.RFC 3489 STUN March 2003 Flags Source Address Source Port CHANGED-ADDRESSnone Da Dp Ca:CpChange IP Ca Dp Ca:CpChange port Da Cp Ca:CpChange IP andChange port Ca Cp Ca:CpTable 1: Impact of Flags on Packet Source and CHANGED-ADDRESSThe server MUST add a SOURCE-ADDRESS attribute to the BindingResponse, containing the source address and port used to send theBinding Response.The server MUST add a CHANGED-ADDRESS attribute to the BindingResponse. This contains the source IP address and port that would be used if the client had set the "change IP" and "change port" flags in the Binding Request. As summarized in Table 1, these are Ca and Cp, respectively, regardless of the value of the CHANGE-REQUEST flags.If the Binding Request contained both the USERNAME and MESSAGE-INTEGRITY attributes, the server MUST add a MESSAGE-INTEGRITYattribute to the Binding Response. The attribute contains an HMAC[13] over the response, as described in Section 11.2.8. The key touse depends on the shared secret mechanism. If the STUN SharedSecret Request was used, the key MUST be the one associated with the USERNAME attribute present in the Binding Request.If the Binding Request contained a RESPONSE-ADDRESS attribute, theserver MUST add a REFLECTED-FROM attribute to the response. If theBinding Request was authenticated using a username obtained from aShared Secret Request, the REFLECTED-FROM attribute MUST contain the source IP address and port where that Shared Secret Request camefrom. If the username present in the request was not allocated using a Shared Secret Request, the REFLECTED-FROM attribute MUST containthe source address and port of the entity which obtained theusername, as best can be verified with the mechanism used to allocate the username. If the username was not present in the request, andthe server was willing to process the request, the REFLECTED-FROMattribute SHOULD contain the source IP address and port where therequest came from.The server SHOULD NOT retransmit the response. Reliability isachieved by having the client periodically resend the request, eachof which triggers a response from the server.。
RFC3376IGMPv3
RFC3376IGMPv3RFC3376 IGMPv31.简介1.1.IPv41.1.1.IGMPv1 RFC1112定义QueryReport1.1.2.IGMPv2 RFC2236增加Leave1.1.3.IGMPv3 RFC3376定义v3 Report，支持SSM（废弃Leave，统一采用Report）1.2.IPv6MLDv1（功能与IGMPv2相同）MLDv2（功能与IGMPv3相同）2.用于请求IP组播接收的服务接口系统服务接口操作要求IPMulticastListen( socket, interface, multicast-address,filter-mode, source-list )●Socket●Interface接收指定组播报文的网络接口ID。
接口可以是物理的（以太网接口）或者虚拟的（FR虚连续或IP-in-IP隧道）。
实现也许允许“未指定”值作为接口参数，此时，该请求应用在系统的第一个或者缺省接口（或●Multicast-addressIP多播地址或组。
如果给定接口要接收多个组播地址，每个组播地址调用IPMulticastListen。
●Filter-modeINCLUDE或者EXCLUDE。
在INCLUDE模式，仅接收IP源地址在source-list参数的报文。
在EXCLUDE模式，仅接收IP源地址不在source-list参数的报文。
●source-list未排序的零或者多个IP单播地址。
实现也许会限制IP地址个数，但不能小于64个。
当IP地址个数超过限制时，服务接口必须返回错误。
对于给定的socket、interface、multicast-address，每次仅能配置一种过滤模式和源列表。
但，后续的配置请求可以更改模式和列表。
以前版本的IGMP并不支持源过滤，仅支持加入和离开操作。
加入操作等效于IPMulticastListen(socket,interface,multicast-address,EXCLUDE,{})离开操作等效于IPMulticastListen(socket,interface,multicast-address,INCLUDE,{}){}表示空列表。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
Network Working Group P. Phaal Request for Comments: 3176 S. Panchen Category: Informational N. McKee InMon Corp. September 2001 InMon Corporation’s sFlow: A Method for Monitoring Traffic inSwitched and Routed NetworksStatus 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 (2001). All Rights Reserved. AbstractThis memo defines InMon Coporation’s sFlow system. sFlow is atechnology for monitoring traffic in data networks containingswitches and routers. In particular, it defines the samplingmechanisms implemented in an sFlow Agent for monitoring traffic, the sFlow MIB for controlling the sFlow Agent, and the format of sampledata used by the sFlow Agent when forwarding data to a central datacollector.Table of Contents1. Overview (2)2. Sampling Mechanisms (2)2.1 Sampling of Switched Flows (3)2.1.1 Distributed Switching (4)2.1.2 Random Number Generation (4)2.2 Sampling of Network Interface Statistics (4)3. sFlow MIB (5)3.1 The SNMP Management Framework (5)3.2 Definitions (6)4. sFlow Datagram Format (14)5. Security Considerations (25)5.1 Control (26)5.2 Transport (26)5.3 Confidentiality (26)6. References (27)7. Authors’ Addresses (29)Phaal, et al. Informational [Page 1]8. Intellectual Property Statement (30)9. Full Copyright Statement (31)1. OverviewsFlow is a technology for monitoring traffic in data networkscontaining switches and routers. In particular, it defines thesampling mechanisms implemented in an sFlow Agent for monitoringtraffic, the sFlow MIB for controlling the sFlow Agent, and theformat of sample data used by the sFlow Agent when forwarding data to a central data collector.The architecture and sampling techniques used in the sFlow monitoring system are designed to provide continuous site-wide (and network-wide) traffic monitoring for high speed switched and routed networks. The design specifically addresses issues associated with:o Accurately monitoring network traffic at Gigabit speeds and higher. o Scaling to manage tens of thousands of agents from a single point. o Extremely low cost agent implementation.The sFlow monitoring system consists of an sFlow Agent (embedded in a switch or router or in a stand alone probe) and a central datacollector, or sFlow Analyzer.The sFlow Agent uses sampling technology to capture trafficstatistics from the device it is monitoring. sFlow Datagrams areused to immediately forward the sampled traffic statistics to ansFlow Analyzer for analysis.This document describes the sampling mechanisms used by the sFlowAgent, the SFLOW MIB used by the sFlow Analyzer to control the sFlow Agent, and the sFlow Datagram Format used by the sFlow Agent to send traffic data to the sFlow Analyzer.2. Sampling MechanismsThe sFlow Agent uses two forms of sampling: statistical packet-based sampling of switched flows, and time-based sampling of networkinterface statistics.Phaal, et al. Informational [Page 2]2.1 Sampling of Switched FlowsA flow is defined as all the packets that are received on oneinterface, enter the Switching/Routing Module and are sent to another interface. In the case of a one-armed router, the source anddestination interface could be the same. In the case of a broadcast or multicast packet there may be multiple destination interfaces.The sampling mechanism must ensure that any packet involved in a flow has an equal chance of being sampled, irrespective of the flow towhich it belongs.Sampling flows is accomplished as follows: When a packet arrives onan interface, a filtering decision is made that determines whetherthe packet should be dropped. If the packet is not filtered adestination interface is assigned by the switching/routing function. At this point a decision is made on whether or not to sample thepacket. The mechanism involves a counter that is decremented witheach packet. When the counter reaches zero a sample is taken.Whether or not a sample is taken, the counter Total_Packets isincremented. Total_Packets is a count of all the packets that could have been sampled.Taking a sample involves either copying the packet’s header, orextracting features from the packet (see sFlow Datagram Format for a description of the different forms of sample). Every time a sampleis taken, the counter Total_Samples, is incremented. Total_Samplesis a count of the number of samples generated. Samples are sent bythe sampling entity to the sFlow Agent for processing. The sampleincludes the packet information, and the values of the Total_Packets and Total_Samples counters.When a sample is taken, the counter indicating how many packets toskip before taking the next sample should be reset. The value of the counter should be set to a random integer where the sequence ofrandom integers used over time should be such that(1) Total_Packets/Total_Samples = RateAn alternative strategy for packet sampling is to generate a randomnumber for each packet, compare the random number to a presetthreshold and take a sample whenever the random number is smallerthan the threshold value. Calculation of an appropriate thresholdvalue depends on the characteristics of the random number generator, however, the resulting sample stream must still satisfy (1).Phaal, et al. Informational [Page 3]2.1.1 Distributed SwitchingThe SFLOW MIB permits separate sampling entities to be associatedwith different physical or logical elements of the switch (such asinterfaces, backplanes or VLANs). Each sampling engine has its ownindependent state (i.e., Total_Packets, Total_Samples, Skip andRate), and forwards its own sample messages to the sFlow Agent. The sFlow Agent is responsible for packaging the samples into datagramsfor transmission to an sFlow Analyzer.2.1.2 Random Number GenerationThe essential property of the random number generator is that themean value of the numbers it generates converges to the requiredsampling rate.A uniform distribution random number generator is very effective.The range of skip counts (the variance) does not significantly affect results; variation of +-10% of the mean value is sufficient.The random number generator must ensure that all numbers in the range between its maximum and minimum values of the distribution arepossible; a random number generator only capable of generating evennumbers, or numbers with any common divisor is unsuitable.A new skip value is only required every time a sample is taken.2.2 Sampling of Network Interface StatisticsThe objective of the counter sampling is to efficiently, periodically poll each data source on the device and extract key statistics.For efficiency and scalability reasons, the sFlow System implementscounter polling in the sFlow Agent. A maximum polling interval isassigned to the agent, but the agent is free to schedule polling inorder maximize internal efficiency.Flow sampling and counter sampling are designed as part of anintegrated system. Both types of samples are combined in sFlowDatagrams. Since flow sampling will cause a steady, but random,stream of datagrams to be sent to the sFlow Analyzer, counter samples may be taken opportunistically in order to fill these datagrams.One strategy for counter sampling has the sFlow Agent keep a list of counter sources being sampled. When a flow sample is generated thesFlow Agent examines the list and adds counters to the sampledatagram, least recently sampled first. Counters are only added tothe datagram if the sources are within a short period, 5 seconds say, Phaal, et al. Informational [Page 4]of failing to meet the required sampling interval (seesFlowCounterSamplingInterval in SFLOW MIB). Whenever a countersource’s statistics are added to a sample datagram, the time thecounter source was last sampled is updated and the counter source is placed at the end of the list. Periodically, say every second, thesFlow Agent examines the list of counter sources and sends anycounters that need to be sent to meet the sampling intervalrequirement.Alternatively, if the agent regularly schedules counter sampling,then it should schedule each counter source at a different start time (preferably randomly) so that counter sampling is not synchronizedwithin an agent or between agents.3. sFlow MIBThe sFlow MIB defines a control interface for an sFlow Agent. Thisinterface provides a standard mechanism for remotely controlling and configuring an sFlow Agent.3.1 The SNMP Management FrameworkThe SNMP Management Framework presently consists of five majorcomponents:o An overall architecture, described in RFC 2571 [2].o Mechanisms for describing and naming objects and events for thepurpose of management. The first version of this Structure ofManagement Information (SMI) is called SMIv1 and described in STD 16,RFC 1155 [3], STD 16, RFC 1212 [4] and RFC 1215 [5]. The secondversion, called SMIv2, is described in STD 58, RFC 2578 [6], STD58, RFC 2579 [7] and STD 58, RFC 2580 [8].o Message protocols for transferring management information. Thefirst version of the SNMP message protocol is called SNMPv1 anddescribed in STD 15, RFC 1157 [9]. A second version of the SNMPmessage protocol, which is not an Internet standards trackprotocol, is called SNMPv2c and described in RFC 1901 [10] and RFC 1906 [11]. The third version of the message protocol is calledSNMPv3 and described in RFC 1906 [11], RFC 2572 [12] and RFC 2574 [13].Phaal, et al. Informational [Page 5]o Protocol operations for accessing management information. Thefirst set of protocol operations and associated PDU formats isdescribed in STD 15, RFC 1157 [9]. A second set of protocoloperations and associated PDU formats is described in RFC 1905[14].o A set of fundamental applications described in RFC 2573 [15] andthe view-based access control mechanism described in RFC 2575[16].A more detailed introduction to the current SNMP Management Framework can be found in RFC 2570 [17].Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. Objects in the MIB aredefined using the mechanisms defined in the SMI.This memo specifies a MIB module that is compliant to the SMIv2. AMIB conforming to the SMIv1 can be produced through the appropriatetranslations. The resulting translated MIB must be semanticallyequivalent, except where objects or events are omitted because notranslation is possible (use of Counter64). Some machine readableinformation in SMIv2 will be converted into textual descriptions inSMIv1 during the translation process. However, this loss of machine readable information is not considered to change the semantics of the MIB.3.2 DefinitionsSFLOW-MIB DEFINITIONS ::= BEGINIMPORTSMODULE-IDENTITY, OBJECT-TYPE, Integer32, enterprisesFROM SNMPv2-SMISnmpAdminStringFROM SNMP-FRAMEWORK-MIBOwnerStringFROM RMON-MIBInetAddressType, InetAddressFROM INET-ADDRESS-MIBMODULE-COMPLIANCE, OBJECT-GROUPFROM SNMPv2-CONF;sFlowMIB MODULE-IDENTITYLAST-UPDATED "200105150000Z" -- May 15, 2001ORGANIZATION "InMon Corp."CONTACT-INFOPhaal, et al. Informational [Page 6]"Peter PhaalInMon Corp./Tel: +1-415-661-6343Email: peter_phaal@"DESCRIPTION"The MIB module for managing the generation and transportation of sFlow data records."---- Revision History--REVISION "200105150000Z" -- May 15, 2001DESCRIPTION"Version 1.2Brings MIB into SMI v2 compliance."REVISION "200105010000Z" -- May 1, 2001DESCRIPTION"Version 1.1Adds sFlowDatagramVersion."::= { enterprises 4300 1 }sFlowAgent OBJECT IDENTIFIER ::= { sFlowMIB 1 }sFlowVersion OBJECT-TYPESYNTAX SnmpAdminStringMAX-ACCESS read-onlySTATUS currentDESCRIPTION"Uniquely identifies the version and implementation of this MIB. The version string must have the following structure:<MIB Version>;<Organization>;<Software Revision>where:<MIB Version> must be ’1.2’, the version of this MIB.<Organization> the name of the organization responsiblefor the agent implementation.<Revision> the specific software build of this agent.As an example, the string ’1.2;InMon Corp.;2.1.1’ indicatesthat this agent implements version ’1.2’ of the SFLOW MIB, that it was developed by ’InMon Corp.’ and that the software buildis ’2.1.1’.The MIB Version will change with each revision of the SFLOW Phaal, et al. Informational [Page 7]MIB.Management entities must check the MIB Version and not attemptto manage agents with MIB Versions greater than that for whichthey were designed.Note: The sFlow Datagram Format has an independent versionnumber which may change independently from <MIB Version>. <MIB Version> applies to the structure and semantics ofthe SFLOW MIB only."DEFVAL { "1.2;;" }::= { sFlowAgent 1 }sFlowAgentAddressType OBJECT-TYPESYNTAX InetAddressTypeMAX-ACCESS read-onlySTATUS currentDESCRIPTION"The address type of the address associated with this agent.Only ipv4 and ipv6 types are supported."::= { sFlowAgent 2 }sFlowAgentAddress OBJECT-TYPESYNTAX InetAddressMAX-ACCESS read-onlySTATUS currentDESCRIPTION"The IP address associated with this agent. In the case of amulti-homed agent, this should be the loopback address of theagent. The sFlowAgent address must provide SNMP connectivityto the agent. The address should be an invariant that does not change as interfaces are reconfigured, enabled, disabled,added or removed. A manager should be able to use thesFlowAgentAddress as a unique key that will identify thisagent over extended periods of time so that a history canbe maintained."::= { sFlowAgent 3 }sFlowTable OBJECT-TYPESYNTAX SEQUENCE OF SFlowEntryMAX-ACCESS not-accessibleSTATUS currentDESCRIPTION"A table of the sFlow samplers within a device."::= { sFlowAgent 4 }sFlowEntry OBJECT-TYPESYNTAX SFlowEntryPhaal, et al. Informational [Page 8]MAX-ACCESS not-accessibleSTATUS currentDESCRIPTION"Attributes of an sFlow sampler."INDEX { sFlowDataSource }::= { sFlowTable 1 }SFlowEntry ::= SEQUENCE {sFlowDataSource OBJECT IDENTIFIER,sFlowOwner OwnerString,sFlowTimeout Integer32,sFlowPacketSamplingRate Integer32,sFlowCounterSamplingInterval Integer32,sFlowMaximumHeaderSize Integer32,sFlowMaximumDatagramSize Integer32,sFlowCollectorAddressType InetAddressType,sFlowCollectorAddress InetAddress,sFlowCollectorPort Integer32,sFlowDatagramVersion Integer32}sFlowDataSource OBJECT-TYPESYNTAX OBJECT IDENTIFIERMAX-ACCESS read-onlySTATUS currentDESCRIPTION"Identifies the source of the data for the sFlow sampler.The following data source types are currently defined:- ifIndex.<I>DataSources of this traditional form are called ’port-based’.Ideally the sampling entity will perform sampling on all flowsoriginating from or destined to the specified interface.However, if the switch architecture only permits input oroutput sampling then the sampling agent is permitted to onlysample input flows input or output flows. Each packet mustonly be considered once for sampling, irrespective of thenumber of ports it will be forwarded to.Note: Port 0 is used to indicate that all ports on the deviceare represented by a single data source.- sFlowPacketSamplingRate applies to all ports on thedevice capable of packet sampling.- sFlowCounterSamplingInterval applies to all ports.- smonVlanDataSource.<V>A dataSource of this form refers to a ’Packet-based VLAN’and is called a ’VLAN-based’ dataSource. <V> is the VLANPhaal, et al. Informational [Page 9]ID as defined by the IEEE 802.1Q standard. Thevalue is between 1 and 4094 inclusive, and it representsan 802.1Q VLAN-ID with global scope within a givenbridged domain.Sampling is performed on all packets received that are partof the specified VLAN (no matter which port they arrived on).Each packet will only be considered once for sampling,irrespective of the number of ports it will be forwarded to.- entPhysicalEntry.<N>A dataSource of this form refers to a physical entity withinthe agent (e.g., entPhysicalClass = backplane(4)) and is calledan ’entity-based’ dataSource.Sampling is performed on all packets entering the resource (e.g. If the backplane is being sampled, all packets transmitted ontothe backplane will be considered as single candidates forsampling irrespective of the number of ports they ultimatelyreach).Note: Since each DataSource operates independently, a packetthat crosses multiple DataSources may generate multipleflow records."::= { sFlowEntry 1 }sFlowOwner OBJECT-TYPESYNTAX OwnerStringMAX-ACCESS read-writeSTATUS currentDESCRIPTION"The entity making use of this sFlow sampler. The empty stringindicates that the sFlow sampler is currently unclaimed.An entity wishing to claim an sFlow sampler must make surethat the sampler is unclaimed before trying to claim it.The sampler is claimed by setting the owner string to identifythe entity claiming the sampler. The sampler must be claimedbefore any changes can be made to other sampler objects.In order to avoid a race condition, the entity taking controlof the sampler must set both the owner and a value forsFlowTimeout in the same SNMP set request.When a management entity is finished using the sampler,it should set its value back to unclaimed. The agentmust restore all other entities this row to theirdefault values when the owner is set to unclaimed.This mechanism provides no enforcement and relies on thecooperation of management entities in order to ensure that Phaal, et al. Informational [Page 10]competition for a sampler is fairly resolved."DEFVAL { "" }::= { sFlowEntry 2 }sFlowTimeout OBJECT-TYPESYNTAX Integer32MAX-ACCESS read-writeSTATUS currentDESCRIPTION"The time (in seconds) remaining before the sampler is releasedand stops sampling. When set, the owner establishes controlfor the specified period. When read, the remaining time in the interval is returned.A management entity wanting to maintain control of the sampleris responsible for setting a new value before the old oneexpires.When the interval expires, the agent is responsible forrestoring all other entities in this row to their defaultvalues."DEFVAL { 0 }::= { sFlowEntry 3 }sFlowPacketSamplingRate OBJECT-TYPESYNTAX Integer32MAX-ACCESS read-writeSTATUS currentDESCRIPTION"The statistical sampling rate for packet sampling from thissource.Set to N to sample 1/Nth of the packets in the monitored flows. An agent should choose its own algorithm introduce varianceinto the sampling so that exactly every Nth packet is notcounted. A sampling rate of 1 counts all packets. A samplingrate of 0 disables sampling.The agent is permitted to have minimum and maximum allowablevalues for the sampling rate. A minimum rate lets the agentdesigner set an upper bound on the overhead associated withsampling, and a maximum rate may be the result of hardwarerestrictions (such as counter size). In addition not all values between the maximum and minimum may be realizable as thesampling rate (again because of implementation considerations). When the sampling rate is set the agent is free to adjust thevalue so that it lies between the maximum and minimum values Phaal, et al. Informational [Page 11]and has the closest achievable value.When read, the agent must return the actual sampling rate itwill be using (after the adjustments previously described). The sampling algorithm must converge so that over time the numberof packets sampled approaches 1/Nth of the total number ofpackets in the monitored flows."DEFVAL { 0 }::= { sFlowEntry 4 }sFlowCounterSamplingInterval OBJECT-TYPESYNTAX Integer32MAX-ACCESS read-writeSTATUS currentDESCRIPTION"The maximum number of seconds between successive samples of the counters associated with this data source. A sampling interval of 0 disables counter sampling."DEFVAL { 0 }::= { sFlowEntry 5 }sFlowMaximumHeaderSize OBJECT-TYPESYNTAX Integer32MAX-ACCESS read-writeSTATUS currentDESCRIPTION"The maximum number of bytes that should be copied from asampled packet. The agent may have an internal maximum andminimum permissible sizes. If an attempt is made to set thisvalue outside the permissible range then the agent shouldadjust the value to the closest permissible value."DEFVAL { 128 }::= { sFlowEntry 6 }sFlowMaximumDatagramSize OBJECT-TYPESYNTAX Integer32MAX-ACCESS read-writeSTATUS currentDESCRIPTION"The maximum number of data bytes that can be sent in a singlesample datagram. The manager should set this value to avoidfragmentation of the sFlow datagrams."DEFVAL { 1400 }::= { sFlowEntry 7 }sFlowCollectorAddressType OBJECT-TYPESYNTAX InetAddressTypeMAX-ACCESS read-writePhaal, et al. Informational [Page 12]STATUS currentDESCRIPTION"The type of sFlowCollectorAddress."DEFVAL { ipv4 }::= { sFlowEntry 8 }sFlowCollectorAddress OBJECT-TYPESYNTAX InetAddressMAX-ACCESS read-writeSTATUS currentDESCRIPTION"The IP address of the sFlow collector.If set to 0.0.0.0 all sampling is disabled."DEFVAL { "0.0.0.0" }::= { sFlowEntry 9 }sFlowCollectorPort OBJECT-TYPESYNTAX Integer32MAX-ACCESS read-writeSTATUS currentDESCRIPTION"The destination port for sFlow datagrams."DEFVAL { 6343 }::= { sFlowEntry 10 }sFlowDatagramVersion OBJECT-TYPESYNTAX Integer32MAX-ACCESS read-writeSTATUS currentDESCRIPTION"The version of sFlow datagrams that should be sent.When set to a value not support by the agent, the agent shouldadjust the value to the highest supported value less than therequested value, or return an error if no such values exist."DEFVAL { 4 }::= { sFlowEntry 11 }---- Compliance Statements--sFlowMIBConformance OBJECT IDENTIFIER ::= { sFlowMIB 2 }sFlowMIBGroups OBJECT IDENTIFIER ::= { sFlowMIBConformance 1 } sFlowMIBCompliances OBJECT IDENTIFIER ::= { sFlowMIBConformance 2 } sFlowCompliance MODULE-COMPLIANCESTATUS currentPhaal, et al. Informational [Page 13]DESCRIPTION"Compliance statements for the sFlow Agent."MODULE -- this moduleMANDATORY-GROUPS { sFlowAgentGroup }OBJECT sFlowAgentAddressTypeSYNTAX InetAddressType { ipv4(1) }DESCRIPTION"Agents need only support ipv4."OBJECT sFlowCollectorAddressTypeSYNTAX InetAddressType { ipv4(1) }DESCRIPTION"Agents need only support ipv4."::= { sFlowMIBCompliances 1 }sFlowAgentGroup OBJECT-GROUPOBJECTS { sFlowVersion, sFlowAgentAddressType, sFlowAgentAddress,sFlowDataSource, sFlowOwner, sFlowTimeout,sFlowPacketSamplingRate, sFlowCounterSamplingInterval,sFlowMaximumHeaderSize, sFlowMaximumDatagramSize,sFlowCollectorAddressType, sFlowCollectorAddress,sFlowCollectorPort, sFlowDatagramVersion }STATUS currentDESCRIPTION"A collection of objects for managing the generation andtransportation of sFlow data records."::= { sFlowMIBGroups 1 }ENDThe sFlow MIB references definitions from a number of existing RFCs[18], [19], [20] and [21].4. sFlow Datagram FormatThe sFlow datagram format specifies a standard format for the sFlowAgent to send sampled data to a remote data collector.The format of the sFlow datagram is specified using the XDR standard [1]. XDR is more compact than ASN.1 and simpler for the sFlow Agent to encode and the sFlow Analyzer to decode.Samples are sent as UDP packets to the host and port specified in the SFLOW MIB. The lack of reliability in the UDP transport mechanismdoes not significantly affect the accuracy of the measurementsobtained from an sFlow Agent.Phaal, et al. Informational [Page 14]o If counter samples are lost then new values will be sent duringthe next polling interval. The chance of an undetected counterwrap is negligible. The sFlow datagram specifies 64 bit octetcounters, and with typical counter polling intervals between 20 to 120 seconds, the chance of a long enough sequence of sFlowdatagrams being lost to hide a counter wrap is very small.o The net effect of lost flow samples is a slight reduction in theeffective sampling rate.The use of UDP reduces the amount of memory required to buffer data. UDP also provides a robust means of delivering timely trafficinformation during periods of intense traffic (such as a denial ofservice attack). UDP is more robust than a reliable transportmechanism because under overload the only effect on overall systemperformance is a slight increase in transmission delay and a greater number of lost packets, neither of which has a significant effect on an sFlow-based monitoring system. If a reliable transport mechanism were used then an overload would introduce long transmission delaysand require large amounts of buffer memory on the agent.While the sFlow Datagram structure permits multiple samples to beincluded in each datagram, the sampling agent must not wait for abuffer to fill with samples before sending the sample datagram.sFlow sampling is intended to provide timely information on traffic. The agent may at most delay a sample by 1 second before it isrequired to send the datagram.The agent should try to piggyback counter samples on the datagramstream resulting from flow sampling. Before sending out a datagramthe remaining space in the buffer can be filled with counter samples. The agent has discretion in the timing of its counter polling, thespecified counter sampling intervals sFlowCounterSamplingInterval is a maximum, so the agent is free to sample counters early if it hasspace in a datagram. If counters must be sent in order to satisfythe maximum sampling interval then a datagram must be sent containing the outstanding counters.The following is the XDR description of an sFlow Datagram:/* sFlow Datagram Version 4 *//* Revision History- version 4 adds support BGP communities- version 3 adds support for extended_url information*//* sFlow Sample types */Phaal, et al. Informational [Page 15]/* Address Types */typedef opaque ip_v4[4];typedef opaque ip_v6[16];enum address_type {IP_V4 = 1,IP_V6 = 2}union address (address_type type) {case IP_V4:ip_v4;case IP_V6:ip_v6;}/* Packet header data */const MAX_HEADER_SIZE = 256; /* The maximum sampled header size. *//* The header protocol describes the format of the sampled header */ enum header_protocol {ETHERNET-ISO8023 = 1,ISO88024-TOKENBUS = 2,ISO88025-TOKENRING = 3,FDDI = 4,FRAME-RELAY = 5,X25 = 6,PPP = 7,SMDS = 8,AAL5 = 9,AAL5-IP = 10, /* e.g., Cisco AAL5 mux */IPv4 = 11,IPv6 = 12,MPLS = 13}struct sampled_header {header_protocol protocol; /* Format of sampled header */unsigned int frame_length; /* Original length of packet beforesampling */opaque header<MAX_HEADER_SIZE>; /* Header bytes */}/* Packet IP version 4 data */struct sampled_ipv4 {Phaal, et al. Informational [Page 16]。