RFC1365

合集下载

中移动家庭网关终端技术规范v3.0.0

中国移动通信企业标准家庭网关终端技术规范版本号：3.0.0中国移动通信集团公司发布╳╳╳╳-╳╳-╳╳发布 ╳╳╳╳-╳╳-╳╳实施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.术语、定义和缩略语 ....................................................................................... 错误!未指定书签。

USB扩展及管理（可选）................................................................................ 错误!未指定书签。

DLNA（可选）............................................................................................................... 错误!未指定书签。

5.6.硬件要求....................................................................................................... 错误!未指定书签。

设备面板标识要求........................................................................................... 错误!未指定书签。

操作管理 ...................................................................................................................... 错误!未指定书签。

imap rfc标准

Internet Message Access Protocol (IMAP) is an email retrieval protocol. It stores email messages on a mail server and enables the recipient to view and manipulate them as though they were stored locally on their device. IMAP was developed in the late 1980s and has since become one of the most widely used email retrieval protocols.The IMAP standard is defined in RFC 3501, which was published in 2003. This document provides a detailed description of the protocol's functionality, including its data formats, commands, and responses. The standard specifies how IMAP clients and servers should communicate with each other to enable the retrieval and manipulation of email messages.One of the key features of IMAP is its support for multiple clients accessing the same mailbox simultaneously. This is achieved through the use of a "shared" storage model, where all clients see the same set of messages and folders stored on the server. This allows users to access their email from different devices without having to worry about synchronizing their messages manually.Another important aspect of IMAP is its support for message organization and management. Clients can create, delete, and rename folders, as well as move messages between folders. They can also search for specific messages based on various criteria, such as sender, subject, or date.IMAP also provides a range of features for managing individual messages. Clients can mark messages as read or unread, flag them for follow-up, and even move them to a specific folder. They can also reply to messages, forward them to others, and generate replies or forwards with attachments.Overall, the IMAP standard provides a powerful and flexible framework for managing email messages. Its support for shared storage, message organization, and advanced message management features make it a popular choice for both personal and business email users.。

RFC文档阅读 1-100

RFC974_邮件路由与域名系统
RFC975_自治联邦
RFC976 UUCP 邮件互换格式标准
RFC985 Internet 网关要求 - 起草
RFC988 主机扩展用于IP多点传送
RFC文档阅读 1001-1500
RFC1050_RPC远程步骤呼叫协议说明书
RFC1055_在串行线路上传输IP数据报的非标准协议
RFC1134_+PPP协议：关于在点到点链路上进行多协议包传送的建议
RFC1142 OSI IS-IS 域内路由协议
RFC1144_低速串行链路上的TCPIP头部压缩
RFC1145 SNMPv2的管理模型
RFC1155_基于TCPIP网络的管理结构和标记
RFC1166_Internet数字
RFC1288_Finger用户信息协议
RFC1298_基于IPX协议的SNMP
RFC1321_MD5 信息-摘要算
RFC1332_PPP Internet 协议控制协议 (IPCP)
RFC1333_PPP 链接质量监控
RFC1355_网络中心数据库的保密和准确性问题
RFC1365 一种IP地址扩展提议
RFC1690 Internet工程与计划组（IEPG）介绍
RFC1691 康奈尔大学数字图书馆文档体系结构
RFC1696 用SMIv2定义的调制解调器MIB
RFC1713_DNS调试工具
RFC1715_地址分配效率比率H
RFC1723_路由信息协议（版本2）
RFC1724_RIP 版本 2 管理系统库(MIB) 扩展
RFC1370_OSPF适用范围声明
RFC1387_RIP（版本2）协议分析

Extreme Networks SLX 9640高性能固定路由器商品介绍说明书

ExtremeRouting? SLX 9640
Built to Suit Your Business Needs Ext rem e Elem ent s are t he b uild ing b locks t hat allow you t o t ailor your net w ork t o your sp ecific b usiness environm ent , g oals, and ob ject ives. They enab le t he creat ion of an A ut onom ous Net w ork t hat d elivers t he p osit ive exp eriences and b usiness out com es m ost im p ort ant t o your org anizat ion.
W W W.EXTREMENETW
1
Flexib le Bo rd er Ro ut ing w it h Int ernet Scale, Ult ra-Deep Buffers,
MPLS and EVPN
The SLX 964 0 is a very p ow erful com p act d eep b uffer Int ernet b ord er rout er, p rovid ing a cost -efficient solut ion t hat is p urp ose-b uilt for t he m ost d em and ing service p rovid er and ent erp rise d at a cent ers and MA N/ WA N ap p licat ions. The rob ust syst em archit ect ure sup p ort ed by SLX-OS and a versat ile feat ure set includ ing IPv4 , IPv6, and MPLS/ VPLS w it h Carrier Et hernet 2.0 and OA M cap ab ilit ies t o p rovid e d ep loym ent flexib ilit y.

RFC目录及对照表

ＲＦＣ930_Telnet 终端类型选项ＲＦＣ932_子网地址分配方案ＲＦＣ937_邮局协议( 版本 2) ＲＦＣ948_IP 数据包通过 IEEE 802.3 网络传输的两种方法ＲＦＣ949_FTP 未公开的独特命令ＲＦＣ951_引导协议(BOOTP) ＲＦＣ955_朝向一个处理过程应用的传输服务ＲＦＣ962_TCP-4 的最初ＲＦＣ968 “这是开动前的黑暗” ＲＦＣ974_邮件路由与域名系统ＲＦＣ975_自治联邦ＲＦＣ976 UUCP 邮件互换格式标准ＲＦＣ985 Internet 网关要求 - 起草ＲＦＣ988 主机扩展用于 IP 多点传送
中文 RFC 文档阅读 101-700
ＲＦＣ102 主机-主机协议故障清除委员会的说明ＲＦＣ103 中断键的执行ＲＦＣ104 连接 191 ＲＦＣ105 通过 UCSB 进行远程登录和远程输出返回的网络说明书ＲＦＣ106 用户/服务器站点协议的网络主机问卷ＲＦＣ107 主机-主机协议故障清除委员会的说明ＲＦＣ108 1971 年 2 月 17-19 日在 Urbana 举行的 NWG 会议的人员列表ＲＦＣ124 在ＲＦＣ107 中有印刷错误ＲＦＣ132 ＲＦＣ107 的排版错误ＲＦＣ148 ＲＦＣ123 的注释ＲＦＣ149 最好的铺设计划ＲＦＣ154 风格显示ＲＦＣ156 伊利诺斯州站点的状态: 响应ＲＦＣ116 ＲＦＣ179 连接的数字分配ＲＦＣ185 NIC 分发手册ＲＦＣ188 数据管理会议公告ＲＦＣ198 站点证明-林肯实验室 360/67 ＲＦＣ204_利用报路ＲＦＣ218 改变 IMP 状态报告设备ＲＦＣ228 澄清ＲＦＣ232 网络图形会议延缓ＲＦＣ245 预定网络工作组会议ＲＦＣ246 网络图形会议ＲＦＣ256 IMPSYS 变更通知ＲＦＣ276 NIC 过程ＲＦＣ285 网络图形ＲＦＣ324 RJE 协议会议ＲＦＣ335 新界面 - IMP/360 ＲＦＣ348_放弃过程ＲＦＣ404 文件迁移协议的注释ＲＦＣ405 给 TIP 用户的第二封信ＲＦＣ456 UCSB 的数据重置服务ＲＦＣ457_FTP 的服务器与服务器交互ＲＦＣ496 IMP/TIP 内存更新时间表(修订版 2) ＲＦＣ516 丢失消息的检测ＲＦＣ591 在 NVT ASCII UCSB 和在线系统之间的实验输入映象ＲＦＣ621 “注意圣诞节的时候要把长袜挂在烟囱下面” ＲＦＣ628 更深的数据语言的设计观念ＲＦＣ634 最近的网络图ＲＦＣ637 SU-DSL 网络地址的更改

极限交换机VDX6740和VDX6740T产品介绍说明书

VDX 674 0 T-1G Sw it ch
The VDX 674 0 T-1G ( Fig ure 3) offers 4 8 10 0 0 BA SE-T p ort s and t w o 4 0 Gb E QSFP+ p ort s. Each 4 0 Gb E p ort can b e b roken out int o four ind ep end ent 10 Gb E SFP+ p ort s, p rovid ing an ad d it ional eig ht 10 Gb E SFP+ p ort s for up link. A ll 4 8 10 0 0 BA SE-T p ort s can b e up g rad ed t o 4 8 10 GBA SE-T p ort s via t he Cap acit y on Dem and (CoD) soft w are license. Tw o 4 0 Gb E p ort s are enab led as p art of t he b ase license. The ad d it ional t w o 4 0 Gb E p ort s can b e up g rad ed via t he Port s on Dem and ( PoD) soft w are license.
- Meet s t od ay?s ap p licat ion d em and s w it h high perform ance and low latency
- Delivers line-rate t hroughput for all p ort s and p acket sizes
Dat a Sheet

轧钢加热炉二级系统说明书

3.2.1 服务器 .................................................................................................... 20 3.2.2 客户端..................................................................................................... 21
轧钢加热炉二级系统（RFC）
说明书
济钢集团自动化信息技术公司 2012 年 12 月
目录
一概述......................................................................................................................... 4 1.1 说明 ...................................................................................................................... 4 1.2 加热炉二级............................................................................. 4 1.2.1 二级定位.................................................................................................... 4 1.2.2 二级范围.................................................................................................... 4 1.2.3 关联系统.................................................................................................... 5 1.3 大棒加热炉描述.................................................................................................... 5 1.4 加热坯料............................................................................................................... 5 1.5 二级对控制系统的监管作用 .................................................................................. 6

T-REC-G.8265-201010-P!!PDF-E

INTERNATIONAL TELECOMMUNICATION UNIONITU-T G.8265/Y.1365 TELECOMMUNICATION(10/2010) STANDARDIZATION SECTOROF ITUSERIES G: TRANSMISSION SYSTEMS AND MEDIA, DIGITAL SYSTEMS AND NETWORKSPacket over Transport aspects – Quality and availability targetsSERIES Y: GLOBAL INFORMATION INFRASTRUCTURE, INTERNET PROTOCOL ASPECTS AND NEXT-GENERATION NETWORKSInternet protocol aspects – TransportArchitecture and requirements for packet basedfrequency deliveryCAUTION !PREPUBLISHED RECOMMENDATIONThis prepublication is an unedited version of a recently approved Recommendation.It will be replaced by the published version after editing. Therefore, there will be differences between this prepublication and the published version.FOREWORDThe International Telecommunication Union (ITU) is the United Nations specialized agency in the field of telecommunications, information and communication technologies (ICTs). The ITU Telecommunication Standardization Sector (ITU-T) is a permanent organ of ITU. ITU-T is responsible for studying technical, operating and tariff questions and issuing Recommendations on them with a view to standardizing telecommunications on a worldwide basis.The World Telecommunication Standardization Assembly (WTSA), which meets every four years, establishes the topics for study by the ITU-T study groups which, in turn, produce Recommendations on these topics.The approval of ITU-T Recommendations is covered by the procedure laid down in WTSA Resolution 1.In some areas of information technology which fall within ITU-T's purview, the necessary standards are prepared on a collaborative basis with ISO and IEC.NOTEIn this Recommendation, the expression "Administration" is used for conciseness to indicate both a telecommunication administration and a recognized operating agency.Compliance with this Recommendation is voluntary. However, the Recommendation may contain certain mandatory provisions (to ensure, e.g., interoperability or applicability) and compliance with the Recommendation is achieved when all of these mandatory provisions are met. The words "shall" or some other obligatory language such as "must" and the negative equivalents are used to express requirements. The use of such words does not suggest that compliance with the Recommendation is required of any party.INTELLECTUAL PROPERTY RIGHTSITU draws attention to the possibility that the practice or implementation of this Recommendation may involve the use of a claimed Intellectual Property Right. ITU takes no position concerning the evidence, validity or applicability of claimed Intellectual Property Rights, whether asserted by ITU members or others outside of the Recommendation development process.As of the date of approval of this Recommendation, ITU [had/had not] received notice of intellectual property, protected by patents, which may be required to implement this Recommendation. However, implementers are cautioned that this may not represent the latest information and are therefore strongly urged to consult the TSB patent database at http://www.itu.int/ITU-T/ipr/.ITU 2010All rights reserved. No part of this publication may be reproduced, by any means whatsoever, without the prior written permission of ITU.Recommendation ITU-T G.8265/Y.1365Architecture and requirements for packet based frequency deliverySummaryThis Recommendation describes the architecture and requirements for packet based frequency distribution in telecom networks. Examples of packet based frequency distribution include NTP and IEEE1588-2008 and are briefly described. Details necessary to utilize IEEE™-1588-2008 in a manner consistent with the architecture are defined in other Recommendations.Recommendation ITU-T G.8265/Y.1365Architecture and requirements for packet based frequency delivery1 ScopeThis recommendation describes the general architecture of frequency distribution using packet based methods. This version of the recommendation focuses on the delivery of frequency using methods such as NTP or the IEEE Std 1588™-2008 Precision Time Protocol (PTP). The requirements and architecture form a base for the specification of other functionality needed to achieve packet based frequency distribution in a carrier environment. The architecture described covers the case where protocol interaction is at the end points of the network only, between a packet master clock and a packet slave clock. Details of requirements for other architectures involving devices that participate between the packet master and packet slave clocks are for further study.2 ReferencesThe following ITU-T Recommendations and other references contain provisions, which, through reference in this text, constitute provisions of this Recommendation. At the time of publication, the editions indicated were valid. All Recommendations and other references are subject to revision; users of this Recommendation are therefore encouraged to investigate the possibility of applying the most recent edition of the Recommendations and other references listed below. A list of the currently valid ITU-T Recommendations is regularly published.The reference to a document within this Recommendation does not give it, as a stand-alone document, the status of a Recommendation.[1] Recommendation ITU-T G.8260 (2010), Definitions and terminology for synchronizationin packet networks[2] IEEE™1588-2008, Standard for a Precision Clock Synchronization Protocol forNetworked Measurement and Control Systems[3]Recommendation ITU-T G.8264, Amendment 1 (2010), Distribution of timing informationthrough packet networks.Network Time Protocol Version 4 Protocol And Algorithms Specification, June [4] RFC5905,20103 Definitions3.1 Terms defined elsewhere:This Recommendation uses the following terms defined elsewhere:3.1.1 Packet slave clock [G.8260]3.1.2 Packet master clock [G.8260]3.1.3 Packet timing signal [G8260]4 Abbreviations and acronymsThis Recommendation uses the following abbreviations and acronyms:CDMA Code Division Multiple AccessDSL Digital Subscriber LineEEC Ethernet Equipment ClockMasterGM GrandGNSS Global Navigation Satellite SystemLTE Long Term EvolutionMINPOLL Minimum Poll intervalNTP Network Time ProtocolPON Passive Optical NetworkPDV Packet Delay VariationPRC Primary Reference ClockPTP Precision Time ProtocolLevelQL QualityRTP Real Time ProtocolSDH Synchronous Digital HierarchySEC SDH equipment ClockSSM Synchronization Status MessageTDM Time Domain MultiplexingVLAN Virtual Local Area NetworkInteroperability for Microwave AccessWIMAX WorldwideLSP Label Switched Path5 ConventionsWithin this Recommendation, the term PTP refers to the PTP version 2 protocol defined in IEEE Std 1588™-2008. NTP refers to Network Time Protocol as defined in RFC5905.6 General introduction to packet based frequency distributionThe modern telecom network has relied on accurate distribution of frequency in order to optimize transmission and TDM cross-connection. In contrast, packet networks and packet services are highly buffered by their nature and, as a result, do not require accurate timing for their operation. The migration towards converged packet networks on the surface leads to the belief that frequency distribution will not be required as packet network technology becomes more prevalent in the network.While this may be true for certain services (Internet is one example), the underlying transport mechanism that deliver these timing agnostic services may require stringent timing requirements that must be provided in the new converged network paradigm. For example, in some cases, support of circuit emulation services over a packet based infrastructure requires the presence of a stable frequency reference to enable the service. Likewise, in wireless access technologies (e.g. GSM, LTE, WIMAX, CDMA, etc.) the air interface requirements have stringent synchronization requirements that need to be met, even thought the end-user service (e.g. mobile internet) may seemingly not require timing.In order to enable timing distribution in packet based networks, the ITU-T has developed specifications Synchronous Ethernet [G.8261, G.8262, G.8264] for the physical layer frequency distribution that is similar to what was provided by SDH. This recommendation describes the use of packet based mechanisms that are intended to be used to transport frequency over a packet network in the absence of physical layer timing.6.1 Requirements for packet timingPacket based mechanisms for frequency distribution must meet the following requirements:1.Mechanisms must be specified to allow interoperability between master and slave devices(clocks)2.Mechanisms must permit consistent operation over managed wide area telecom networks.3.Packet based mechanisms must allow interoperation with existing SDH and SynchronousEthernet based frequency synchronization networks.4.Packet based mechanisms must allow the synchronization network to be designed andconfigured in a fixed arrangement5.Protection schemes used by packet based systems must be based on standard telecomoperational practice and allow slave clocks the ability to take timing from multiplegeographically separate master clocks.6.Source [clock] selection should be consistent with existing practices for physical layersynchronization and permit source selection based on received QL level and priority.7.Packet based mechanisms must permit the operation of existing, standards-based securitytechniques to help ensure the integrity of the synchronization.7 Architecture of packet based frequency distributionIn contrast to physical layer synchronization, where the significant edges of a data signal define the timing content of the signal, packet-based methods rely on the transmission of dedicated ”event packets”. These “event packets” form the significant instants of a packet timing signal. The timing of these significant instances is precisely measured relative to a master time source, and this timing information is encoded in the form of a time-stamp which is a machine readable representation of a specific instance of time1. The time-stamp is generated at a packet master function and is carried over a packet network to a packet slave clock. As time is the integral of frequency, the time-stamps can therefore be used to derive frequency.7.1 Packet based frequency distribution1 Note, in some cases, frequency may be derived from the arrival rate of incoming packets where the packets do not contain a time-stamp, but rather, are generated at precise intervals. As this Recommendation deals with the use of time-based protocols, methods to derive frequency from the arrival rate of packets are outside the scope of this recommendation.The three main components are the packet master clock, the packet slave and the packet network. A packet timing signal generated by the packet master clock is transported over the packet network so that the packet slave clock can generate a clock frequency traceable to the input timing signal available at the packet master clock. The packet master clock is presented with a timing signal traceable to a PRC. The clock produced at the packet slave clock represents the clock traceable to PRC plus some degradation (δ) due to the packet network. The general architectural topology is shown in Figure 1. The synchronization flow is from the Master to Slave. In cases where the reference to the master is provided over a synchronization distribution network, additionaldegradation of the frequency signal may be present at the input to the master and therefore also present at the output of the slave.Figure 1/G.8265: General packet network timing architecture7.2. T iming protection7.2.1 Packet master protectionIn traditional synchronization networks, timing availability is enhanced by the use of timing protection where by the timing to a slave clock (e.g. SEC, or EEC) may be provided over one or more alternative network paths. In the case of the packet based timing architecture, the slave clocks may have visibility to two or more master clocks as show in Figure 2.In contrast to physical layer timing, where the selection of the clock is performed at the slave clock, selection of a secondary master clock may involve some communication and negotiation between the master and the slave and the secondary master and slave.PacketPacketPacket PacketReference 1: Note, the reference may be from a PRC directly, GNSS or via a synchronization networkPacket Timing Signals Slave Clock Slave ClockSlave clockPacket Network Master clock1F iF out +δ2F out + δ3F out +δ1Figure 2/G.8265: Packet network timing (frequency) protection(Note: for clarity, the network reference signals to masters are not shown)7.2.2 Packet Master / Slave Selection FunctionsFunctions required in order to support packet reference selection are described in the following clauses.7.2.2.1 Temporary Master Exclusion – Lock-out functionTo protect the downstream architecture it must be possible in the slaves to exclude temporarily a master from a list of candidate masters (lock-out functionality).7.2.2.2 Slave Wait to Restore Time functionTo protect the downstream architecture a Wait to Restore Time must be implemented in the slave. If a master fails or is unreachable, a slave will switch to a backup master. However, upon the recovery of the primary master, the slave will not switch back to the primary master until the wait to restore time expires.7.2.2.3 Slave non-reversion functionTo protect the downstream architecture a slave non-reversion function may be implemented to protect against slaves “flipping” between masters.In the slave this will ensure that if a master fails or is not anymore reachable, a slave will switch to a backup master but will not switch back to the primary master if the non-revertive mode is implemented and activated.7.2.2.4 Forced Traceability of Master functionIt must be possible to force the QL traceability value at the input of the packet master clock.Network implementations and scenarios making use of this functionality will need to be defined by the operator on a case by case basis and are dependent on the operator’s architecture.The function illustration is presented in Figure 3.Figure 3/G.8265: Example of use case where forcing the QL value at the input of the PTPv2 master is needed7.2.2.5 Packet Slave Clock QL Hold off functionIn the case where sufficient holdover performance exists within the Packet slave clock it must be possible to delay the transition of the QL value at the output of the slaves. This will allow the operator to limit downstream switching of the architecture under certain network implementations when traceability to the packet master is lost.Note: the QL hold off is highly dependent on the quality of the clock implemented in the slave and is for further study.These network implementations and scenarios will need to be defined by the operator on a case by case basis.The function illustration is presented in Figure 4.Figure 4/G.8265: Example of use case where the QL hold off at the output of the Packet slaveclock7.2.2.6 Slave Output Squelch functionNetwork PacketMasterClock ExternalinputReference(no QL)Packet Slave Clock QL value associated tothe external inputreference by the masterIn case the Packet slave provides an external output synchronization interface (e.g. 2 MHz) asquelch function must be implemented in order to protect the downstream architecture and certain end applications.This function is used under certain upstream packet timing signal failure conditions between the packet master and the packet slave.These network implementations and scenarios will need to be defined by the operator on a case by case basis. For example one application will be the case of a Packet slave external to the endequipment, such as base station, which may implement better holdover conditions compared to the Packet slave: in this case, it is recommended to squelch the signal at the output of the Packet slave in packet timing failure conditions so that the end equipment would switch into holdover rather than synchronizing the end equipment with the holdover of the Packet slave.Architectural implementations using this function are for further study. The function is illustrated in Figure 5.Figure 5/G.8265: Squelching at output of Packet Slave7.3 Packet network partitioningPacket networks may be partitioned into a number of different administrative domains. The transport of timing across the packet network must consider the partitioning of networks into different administration domains as illustrated in Figure 6. This could mean, for example, that packet master clocks may be located in different administrative domains. Operation in this configuration may be limited due to the protocol capabilities and is for further study .Figure 6/G.8265: Packet timing flow over partitioned network .Passing packet based timing between administrative domains is not currently specified in this version of the recommendation and is for further study. Issues surrounding the demarcation of the packet timing flow and the transferred performance between operators exist.Due to the operation of packet based networks and their impact on packet based timing recovery, especially under stress conditions, derived performance is difficult to characterise. Concerning the end to end recovery of timing from the packet timing flow, situations can exist where it is difficult to determine the location of performance problems especially if the packet timing is passing through multiple administrative domains.Network Packet MasterCloc Packet Slave ClocNetworkOperatorNetwork Operator Operator Clock Clock Timing FlowWhen multiple administrative domains are involved, other methods that are based on physical layer synchronization (for example, Synchronous Ethernet over OTN) may be applicable for frequency distribution. The details are outside the scope of this recommendation. Further information can be found in G.8264, Clause 11.7.4 Mixed technologiesPacket services may be carried over a packet switching network where the core and access are carried over different technologies which may impact packet delay variation performance and the ability of the slave clock to derive frequency. For example, within the core, packets containing time-stamps may traverse routers, switches or bridges interconnected by Ethernet links, while in the access portion interconnect may be xDSL or PON.A connection through a network may consist of a concatenation of different technologies. The PDV performance may be different based on these technologies. The aggregate PDV may therefore differ when mixes of different technologies are deployed. A slave clock may need to accommodate the impact of these different technologies.Details of the PDV contributions of individual transport technologies and the performance of slave clocks are for further study.8 Packet based protocols for frequency distribution8.1 Packet based protocolsAs noted in Clause 6, frequency transfer over packet networks is not inherent at the packet layer. In cases where frequency transfer is required, methods such as circuit emulation may be employed, which utilize either differential or adaptive clock recovery methods. (See RecommendationG.8261)Protocols for distribution of time exist such as NTP and IEEE1588™-2008 (PTP). Although the protocols are primarily intended for the distribution of time, it is also possible to derive frequency.A general description on the protocols as well as clarifications on the need to define further details when using these protocols for the purpose of frequency distribution is provided below. Note that the performance achievable may also depend on factors outside of the protocol definitions.8.2 PTP/IEEE™1588 general descriptionIEEE1588™-2008 describes the “Precision Time Protocol”, commonly referred to as PTP. The PTP protocol enables the accurate time-transfer between two entities (clocks) by the transmission of messages containing accurate timestamps representing an estimate of the time at which the packet is sent. The repeated transmission of messages also allows the derivation of frequency.The PTP protocol supports unicast and multi-cast operation. Additionally, the protocol provides the support for two clock modes, a one-step mode and a two-step mode, which involves the transmission of an additional Follow-up message. Additional messages are also defined for other purposes, such as Signaling and Management.While the first version IEEE1588™ was developed for industrial automation, the second version (IEEE1588™-2008) was extended to be applicable to other applications such as telecom. The protocol may be tailored to specific applications by the creation of “profiles” which specify which subset of functionality may be required, together with any related configuration settings, to satisfy a specific application. ITU-T is concerned with application to Telecom environments.IEEE1588™-2008 defines several types of clocks; ordinary, boundary and transparent clocks. While the standard defines clocks, these are only high level constructs. The performance achievable by the PTP protocol is based on factors that are outside the scope of the IEEE1588™-2008 standard.ITU-T Recommendation G.8265.1 contains a PTP profile applicable for telecom applications using ordinary clocks in a unicast environment. Profiles developed by the ITU-T are intended to meet all the high-level requirements specified in this Recommendation.8.3 NTP - general descriptionNTPv4 is defined in RFC 5905, which obsoletes both RFC 1305 (NTP v3), and RFC 4330 (SNTP). RFC5905 defines both a protocol and an algorithm to distribute time synchronization, however the NTP on-wire protocol can also be used to distribute a frequency reference. In this case, however, one must develop a specific algorithm to recover frequency and only the packet format and protocol aspects need to be considered. The specific implementation in the client for the purpose of frequency synchronization clock recovery can be considered similar to an implementation using other packet protocols.According to RFC5905, an SNTP client is not required to implement the NTP algorithms specified in RFC 5905. In particular RFC5905 notes that Primary servers and clients complying with a subset of NTP, called the Simple Network Time Protocol (SNTP), do not need to implement the mitigation algorithms described in the relevant sections of RFC5905. The SNTP client can operate with any subset of the NTP on-wire protocol, the simplest approach using only the transmit timestamp of the server packet and ignoring all other fields.Among the aspects to consider is that in some applications the required packet rate may need to be higher (lower MINPOLL value) than the limit currently suggested for the time synchronization algorithm specified in the RFC 5905. On this aspect the following is stated in RFC 5905 section 7.3 “Packet Header Variables”, with respect to the MINPOLL parameter: “These are in 8-bit signed integer format in log2 (log base 2) seconds.” and “Suggested default limits for minimum and maximum poll intervals are 6 and 10, respectively”.Note: the detailed way of using NTP for the specific application (e.g. including the method to support SSM according to the requirements of clause 6)., is for further study.More details on the use of timing packets (such as NTP) for the purpose of frequency transfer are provided in Appendix XII (Basic Principles of Timing over Packet Networks) in G.8261.9 Security aspectsUnlike traditional timing streams where frequency is carried over the physical layer, packet based timing streams may be observed at different points in the network. There may be cases where timing packets flow across multiple network domains which may introduce specific securityrequirements. There may also be aspects of security that may be related to both the network (e.g. authentication and/or authorization) and to the PTP protocol itself.It is important to permit the operation with existing, standards-based security techniques to help ensure the integrity of the synchronization. Examples may include encryption and/or authentication techniques, or network techniques for separating traffic, such as VLANs or LSPs. Specifically;-slaves should be prevented from connecting to rogue masters(this could be either by an authentication process or by using network separation toprevent rogue masters from accessing slaves)-masters should be prevented from providing service to unauthorised slavesIt may not be possible to implement some of these requirements without actually degrading the overall level of timing or system performance.Security aspects are for further study.Appendix IBibliography[B1] RFC1305 Network Time Protocol (Version 3) Specification, Implementation and Analysis, March 2009[B2] RFC 4330, Simple Network Time Protocol (SNTP) Version 4 for IPv4, IPv6 and OSI, January 2006[B3] RFC5905, Network Time Protocol Version 4: Protocol and Algorithms Specification, June 2010______________。

和SIP有关的RFC

RFC 3666 SIP Public Switched Telephone Network (PSTN) Call Flows.
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.

LTE典型信令过程

NAS: Attach Request NAS:PDN connectivity request NAS: Attach Request
NAS:PDN connectivity request
Authentication and NAS security procedure
S6a: Update Location request
S11: Modify bearer response S1AP: Path Switch Response
X2AP: UE Context Release
Flush DL Buffer
Data Forwarding End Marker
Switch DL Path
S1 Handover
➢This type of handover takes place when there is no X2 connectivity between source eNB and target eNB.
S10: Forward SRNS Context Notification
UE Detach from old cell and sync to new cell
S10: Forward SRNS Context Ack
S1AP: MME Status Transfer
RRC: Connection Reconfiguration Complete
➢The release of resources at the source side is directly triggered from the target eNB.
UE
S-eNB
RRC: Measurement Control

二十种兼容机设计专用配置方案

二十种兼容机设计专用配置方案第一种方案……对于专业画图软件的比如Solidworks，以及专门做室外设计也好室内装饰效果也好，不光是要求显卡性能高，而且同时要求CPU性能也高，最好是多核心的，在专业画图、设计、建模等等方面，目前在4000－7000元这个价位上，当然的以Intel Xeon E3-1230 v2为首选，其4核心8线程可满足专业绘图的巨大压力和要求，有效提升专业绘图的效率，大幅缩短制作时间。

具体的配置方案推荐你如下：CPU：Intel Xeon E3-1230 v2散装￥1290散热器：九州风神400黑玉至尊￥150主板：技嘉GA-B75M-D3V(rev.1.0)￥460内存：威刚8GB DDR3 1600（万紫千红）×2（注意必须要双条8GB组建双通道共16GB容量）￥470显卡：索泰GTX650Ti-1GD5 雷霆版PA￥1099硬盘：希捷Barracuda 1TB 7200转64MB 单碟￥450机箱：游戏悍将（Game Demon）核武器￥99电源：安耐美耐酷熊N80 450W￥280合计金额：￥4298对于E3 1230 V2这个U用不着配Z77、H77这些主板，以免浪费主板性能！这款U不可以超频，还是用性价比更高的主板好得多。

九州风神400黑玉至尊这款散热器可以有效为Intel Xeon E3-1230 v2降至30摄氏度左右，这有利于整机的稳定和CPU的寿命延长。

双通道内存是不可缺少的，对于专业绘图方面的应用来说，8GB×2的DDR3 1600G是最理想的选择。

容量小了难以满足复杂的图形绘制、建模渲染等高要求。

而索泰GTX650Ti-1GD5 雷霆版PA￥1099的价格比较亲民，在GTX650TI这一级别的独立显卡中性价比很突出的，当然，你也可以选择Inno3D GTX560Ti冰龙版1460元，以获得更加优异的绘图和游戏效果、成绩。

硬盘方面就没有什么可多说的了，SATA3是目前最新的数据读写传输速度标准，容量上肯定要1TB的了，否则大量的绘图成果会很快找不到存储空间了，这个容量的性价比非常好，才450元。

rfc中常用的测试协议

rfc中常用的测试协议引言在计算机网络领域中，为了确保网络协议的正确性和稳定性，测试协议起到了至关重要的作用。

RFC（Request for Comments）是一系列文件，用于描述互联网相关协议、过程和技术。

在RFC中，也包含了一些常用的测试协议，用于验证和评估网络协议的功能和性能。

本文将介绍RFC中常用的测试协议，并深入探讨其原理和应用。

二级标题1：PING协议三级标题1.1：概述PING协议是一种常用的网络测试协议，用于测试主机之间的连通性。

它基于ICMP （Internet Control Message Protocol）协议，通过发送ICMP Echo Request报文并等待目标主机的ICMP Echo Reply报文来判断目标主机是否可达。

三级标题1.2：工作原理PING协议的工作原理如下： 1. 发送方主机生成一个ICMP Echo Request报文，并将目标主机的IP地址作为目的地。

2. 发送方主机将报文发送到网络中。

3.中间路由器收到报文后，将报文转发到下一跳路由器。

4. 目标主机收到ICMP Echo Request报文后，生成一个ICMP Echo Reply报文，并将其发送回发送方主机。

5. 发送方主机收到ICMP Echo Reply报文后，通过比较报文中的标识符和序列号等字段，判断目标主机是否可达。

三级标题1.3：应用场景PING协议在网络中的应用非常广泛，常用于以下场景： - 测试主机之间的连通性，判断网络是否正常工作。

- 测试网络延迟，通过计算ICMP Echo Request报文的往返时间来评估网络质量。

- 排查网络故障，通过检查ICMP Echo Reply报文中的错误码来定位故障原因。

二级标题2：Traceroute协议三级标题2.1：概述Traceroute协议用于跟踪数据包从源主机到目标主机经过的路径。

它通过发送一系列的UDP报文，并在每个报文中设置不同的TTL（Time to Live）值来实现。

第二代支付系统报文交换标准

第二代支付系统报文交换标准【大额支付系统分册】（版本1.2）中国人民银行清算总中心2011年07月文档修订记录版本编号变化状态简要说明日期变更人批准日期批准人V0.1 A 新建2010.3.30 孔昭龙2010.3.30 贺铁林V0.5 M 修改2010.4.16 孔昭龙2010.4.16 贺铁林V0.9 M 修改2010.6.28 孔昭龙2010.6.28 贺铁林V1.0 M 修改2010.9.24 孔昭龙2010.9.24 贺铁林V1.1 M 修改2011.3.30 孔昭龙2011.3.30 贺铁林V1.2 M 修改2011.7.15 孔昭龙2011.7.15 贺铁林注：变化状态：A—增加，M—修改，D—删除目录修改记录 (1)1报文清单及概要 (3)1.1报文清单 (3)1.2数据类型 (4)2第二代支付系统报文（XML格式） (5)2.1（复用ISO20022报文）客户发起汇兑业务报文<HVPS.111.001.01> (5)2.2（复用ISO20022报文）金融机构发起汇兑业务报文<HVPS.112.001.01> (20)2.3（复用ISO20022报文）即时转账报文<HVPS.141.001.01> (26)2.4即时转账排队/撤销通知报文<HVPS.142.001.01> (37)2.5PVP结算申请信息报文<HVPS.143.001.01> (40)2.6PVP结算应答信息报文<HVPS.144.001.01> (47)2.7申请清算银行汇票资金报文<HVPS.151.001.01> (48)2.8银行汇票全额兑付通知报文<HVPS.152.001.01> (59)2.9银行汇票申请退回业务报文<HVPS.153.001.01> (61)2.10取现回执报文<HVPS.154.001.01> (64)2.11多边轧差净额结算报文<HVPS.631.001.01> (70)2.12多边轧差净额结算清算回执报文<HVPS.632.001.01> (79)2.13多边轧差净额结算借贷通知报文<HVPS.633.001.01> (81)2.14多边净额业务撤销申请报文<HVPS.634.001.01> (83)2.15多边净额业务撤销应答报文<HVPS.635.001.01> (84)2.16大额业务对账申请报文<HVPS.710.001.01> (86)2.17大额业务汇总核对报文<HVPS.711.001.01> (88)2.18大额业务明细核对申请报文<HVPS.712.001.01> (91)2.19大额业务明细核对应答报文<HVPS.713.001.01> (93)2.20大额业务下载申请报文<HVPS.714.001.01> (96)2.21大额业务下载应答报文<HVPS.715.001.01> (98)2.22大额预对账报文<HVPS.716.001.01> (99)2.23资金拆借信息下载报文<HVPS.717.001.01> (102)3业务组件 (104)修改记录序号修改日期修改说明1.2010-3-30 [C] 创建第一稿作为文档模板；2.2010-4-16 [M] 发布0.5版本；3.2010-6-28 [M] 发布0.9版本；4.2010-9-24 [M] 发布1.0版本；5.2010-11-24 [M] 修改“即时转账报文”中“出质行行号”的位置；6.2010-11-25 [A] 增加对“报文分片组件”分片规则的说明；7.2010-11-25 [A] 增加对“报文分片组件”组合规则的说明；8.2010-12-28 [M]1、删除“金融机构发起汇兑业务报文<hvps.112.001.01>”报文下的“拆借分类”字段；2、删除“资金拆借信息下载报文<hvps.717.001.01>” 报文下的“拆借分类”字段，新增“业务类型”和“业务种类”字段；9.2010-12-29 [M] 修改“客户发起汇兑业务报文<hvps.111.001.01>”中关于“关联业务参考号”的说明；10.2010-12-30 [M]1、将“支取发行基金”业务种类的报文说明由“客户发起汇兑业务报文<hvps.111.001.01>”移至“金融机构发起汇兑业务报文<hvps.112.001.01>”；2、“客户发起汇兑业务报文<hvps.111.001.01>”、“金融机构发起汇兑业务报文<hvps.112.001.01>”和“即时转账报文<hvps.141.001.01>”增加“付款人地址”和“收款人地址”要素；11.2010-01-04 [A] 增加“委托收款”与“托收承付”专用业务要素；12.2010-01-18 [A] 增加针对“PVP结算应答信息报文”与“银行汇票全额兑付通知报文”数字签名错或业务合法性错的处理场景图；13.2010-03-08 [A] 增加“取现回执报文”，“即时转账报文”中增加“借贷记标识”字段，“PVP结算申请信息报文”中增加“买入外汇币种”业务要素；14.2010-03-08 [M]1、修改“支取发行基金”的报文说明，2、业务类型与业务种类的调整；15.2010-03-10 [A] 增加“多边轧差净额结算报文、多边轧差净额结算清算回执报文、多边轧差净额结算借贷通知报文、多边净额业务撤销申请报文、多边净额业务撤销应答报文”；16.2010-03-11 [M] 汇总类金额由“ActiveCurrencyAndAmount”修改为“SummaryAmountText”。

参考文献_IPv6技术、部署与业务应用_[共2页]

参考文献[1] R. Maglione, A. Durand. RADIUS Extensions for Dual-Stack Lite. draft-ietf-softwire-dslite- radius-ext-01.txt, December 29, 2010.[2] R. Raghunarayan. Management Information Base for the Transmission Control Protocol (TCP). RFC 4022, March 2005.[3] R.Coltun, D. Ferguson, J. Moy, A. Lindem. OSPF for IPv6. RFC 5340, July 2008.[4] R.Despres. Rapid deployment of native IPv6 behind IPv4 NA T2 (6rd+). draft-despres-softwire-6rdplus-00，July 2010.[5] Rrasblog. How SSTP based VPN connection works. /b/rrasblog/archive/ 2007/01/10/how-sstp-based-vpn-connection-works.aspx, 2007.[6] S. Bhattacharyya. An Overview of Source-Specific Multicast (SSM). RFC 3569, 2003.[7] S. Blake, D. Black, M. Carlson, E. Davies, Z. Wang, W. Weiss. An Architecture for Differentiated Services. RFC 2475, December 1998.[8] S. Chakrabarti, E. Nordmark. Extension to Sockets API for Mobile IPv6. RFC 4584, July 2006.[9] S. Deering, R. Hinden. Internet Protocol, Version 6 (IPv6). RFC 2460, December 1998.[10] S. Gundavelli, K. Leung et al. Proxy Mobile IPv6. RFC 5213, August 2008.[11] S. Kent, K. Seo. Security Architecture for the Internet Protocol. RFC 4301, 2005.[12] S. Kent, R. Atkinson. Security Architecture for the Internet Protocol. RFC 2401, November 1998.[13] S. Lee, M-K. Shin, Y-J. Kim, E. Nordmark, A. Durand. Dual Stack Hosts Using Bump-in-the-API (BIA). RFC 3338, 2002.[14] S. Ooghe, B. Varga, W. Dec. IPv6 in the context of TR-101. TR-177, Nov. 2010.[15] S. Routhier. Management Information Base for the Internet Protocol (IP). RFC 4293, April 2006.[16] S. Thomson & T. Narten. IPv6 Stateless Address Autoconfiguration. RFC 2462, 1998.[17] S. Thomson, C. Huitema, V. Ksinant, M. Souissi. DNS Extensions to Support IP Version 6. RFC 3596, October 2003.[18] S. Varada, Ed. Transwitch, D. Haskin, and E. Allen. IP Version 6 over PPP. RFC 5072, September 2007.[19] T. Bates, R. Chandra, D Katz, Y. Rekhter. Multiprotocol Extensions for BGP-4. RFC 4760, January 2007.[20] T. Bates, Y. Rekhter, R. Chandra, D. Katz. Multiprotocol Extensions for BGP-4. RFC 2858，June 2000.[21] T. Tsou, C. Zhou, T. Taylor, Q. Chen. Gateway-Initiated 6rd. draft-tsou-softwire-gwinit-6rd- 02.txt, December 8, 2010.349。

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.。

McQuay Modbus用户手册V1.2(适用于D系列模块机)

数据内容 N*8bits
CRC16 校验码 16bits
设备地址：即机组地址，默认从 0x01 开始，如要修改详见<通讯地址设置>章节; 功能码：或读或写；数据内容：和功能码对应的读或写数据； CRC 校验：每帧数据错误校验方法。
2.4. 功能码的详细描述
详情请参阅 MODBUS 协议，下面介绍较常用的几则：
1：有效 0：无效设置温度：10-30℃
则查询命令包为：01 03 00 00 00 03 05 CB 响应命令包为：01 03 06 00 01 00 05 00 1A 8D 7F 响应命令包为为 1 号机组处亍开机状态、自劢模式下、设置温度为 26 度。 (备注：查询命令解释，以下命令不 03 功能码的命令规则一致。机组地址为 01，功能码为 03，寄存器起始地址高位为 00，低位为 00，寄存器数目高位为 00，低位为 03，然后是 CRC 校验位低位，CRC 校验位高位。)
2.4.1. 03#读取多个 Holding 寄存器................................................................................................................ 2 2.4.2. 04#读取多个 INPUT 寄存器 ................................................................................................................. 4 2.4.3. 06#预设单个寄存器................................................................................................................................ 4 2.4.4. 16#预设多个寄存器................................................................................................................................ 5 3. 通讯数据格式的设定 .............................................................................................................................................. 7 3.1. 出厂默认格式 .................................................................................................................................................. 7 4. 网络组网 ................................................................................................................................................................... 8 4.1. 组网接口说明 .................................................................................................................................................. 8 4.2. 组网注意事项 .................................................................................................................................................. 9 4.3. 通讯地址设置 .................................................................................................................................................. 9

RFC协议标准

标准参考文档链路层协议PPP(Point-to-Point Protocol)：RFC 1332： The PPP Internet Protocol Control Protocol (IPCP)RFC 1334： PPP Authentication ProtocolsRFC 1552： The PPP Internetworking Packet Exchange Control Protocol (IPXCP) RFC 1570： PPP LCP Extensions(实现了其中的callback选项)RFC 1661： The Point-to-Point Protocol (PPP)RFC 1877： PPP Internet Protocol Control Protocol Extensions for Name Server AddressesRFC 1990： The PPP Multilink Protocol (MP)RFC 1994： PPP Challenge Handshake Authentication Protocol (CHAP)RFC 2509： IP Header Compression over PPPRFC 1962： The PPP Compression Control Protocol (CCP)RFC 1974： PPP Stac LZS Compression ProtocoldX25、LAPB(Link Access Protocol Balanced)：RFC1613：Cisco Systems X.25 over TCP(XOT)RFC1598：PPP in X.25RFC1461：SNMP MIB extension for MultiProtocol Interconnect over X.25RFC1382： SNMP MIB Extension for the X.25 Packet LayerRFC1381： SNMP MIB Extension for X.25 LAPBRFC1356： Multiprotocol Interconnect on X.25 and ISDN in the Packet ModeRFC1236： IP to X.121 Address Mapping for DDNRFC1226： Internet Protocol Encapsulation of AX.25 FramesRFC1090： SMTP on X.25RFC1086： ISO-TP0 bridge between TCP and X.25RFC874： Critique of X.25RFC1236： IP to X.121 Address Mapping for DDNRFC1133： Routing between the NSFNET and the DDNCisco-HDLC：Cisco-HDLC是CISCO自己设计的一个协议,没有可参考的标准Frame Relay：RFC1294/1490： Multiprotocol Interconnect over Frame RelayRFC1293： Inverse Address Resolution Protocol(INARP)RFC1315： Management Information Base for Frame Relay DTEsITU-T Q933附录A：帧中继本地管理接口（LMI）协议ANSI T1.617附录D：帧中继本地管理接口（LMI）协议ISDN(Integrated Services Digital Network)：ITU-T Q.931建议(网络层)ITU-T Q.921建议(链路层)IP层协议RFC791： Internet Protocol. (IP)RFC792： Internet Control Message Protocol (ICMP)RFC793： TRANSMISSION CONTROL PROTOCOL (TCP)RFC896： Congestion Control in IP/TCP InternetworksRFC768： User Datagram Protocol (UDP)RFC 826： An Ethernet Address Resolution Protocol (ARP)Socket： Unix标准路由协议RIP(Routing Information Protocol)：RFC1058： Routing Information ProtocolRFC1723： RIP Version 2RFC2082： RIP-2 MD5 AuthenticationOSPF(Open Shortest Path First)：RFC2328： OSPF Version 2RFC1793： Extending OSPF to Support Demand CircuitsIGRP(Interior Gateway Routing Protocol)：IGRP协议无标准RFC，与CISCO保持兼容BGP(Border Gateway Protocol)：RFC1771： A Border Gateway Protocol 4(BGP-4)RFC1772： Application of the Border Gateway Protocol in the Internet (BGP-4) RFC1965： Autonomous System Confederations for BGPRFC1966： BGP Route Reflection -- An alternative to full mesh IBGPRFC1997： BGP Community AttributeRFC2439： BGP Route Flap Damping网络安全RADIUS(Remote Authentication Dial In User Service)：RFC2138： Remote Authentication Dial In User Service (RADIUS)RFC2139： RADIUS AccountingGRE(Generic Routing Encapsulation)：RFC1701： Generic Roouting Encapsulation (老版本)RFC1702： Generic Routing Encapsulation over IPv4 networksRFC2784： Generic Roouting Encapsulation (新版本)RFC2667： IP Tunnel MIBIPSEC(IP Security)：RFC1825： Security Architechure for the Internet Protocol (老版本)RFC2401： Security Architechure for the Internet Protocol (新版本)AH(Authentication Header)协议：RFC2402： IP Authentication HeaderRFC1321： The MD5 Message-Digest AlgorithmRFC2104： HMAC: Keyed-Hashing for Message AuthenticationRFC2085： IP Authentication with Replay PreventionRFC2403： The Use of HMAC-MD5-96 within ESP and AHRFC2404： The Use of HMAC-SHA-1-96 within ESP and AHESP(Encapsulating Security Payload)：RFC2406： IP Encapsulating Security Payload (ESP)RFC2405： The ESP DES-CBC Cipher Algorithm With Explicit IVIKE(Internet Key Exchange)：RFC2408：Internet Security Association and Key Management Protocol (ISAKMP) RFC2409：The Internet Key Exchange (IKE)RFC2407：The Internet IP Security Domain of Interpretation for ISAKMP (IPSEC DOI)L2TP(Layer 2 Tunnel Protocol)：RFC2661：Layer 2 Tunnel ProtocolNAT(Network Address Translator)：RFC1631：The IP Network Address Translator (NAT)RFC2663：IP Network Address Translator (NAT) Terminology and Considerations 网络管理SNMP(Simple Network Management Protocol)：RFC 1157： Simple Network Management Protocol (SNMP)。