rfc3421.Select and Sort Extensions for the Service Location Protocol (SLP)
RFC1242
Internet RFC/STD/FYI/BCP ArchivesRFC1242[ Index | Search | What's New | Comments | Help ]Network Working Group S. Bradner, Editor Request for Comments: 1242 Harvard University July 1991Benchmarking Terminology for Network Interconnection DevicesStatus of this MemoThis memo provides information for the Internet community. It does not specify an Internet standard. Distribution of this memo isunlimited.AbstractThis memo discusses and defines a number of terms that are used indescribing performance benchmarking tests and the results of suchtests. The terms defined in this memo will be used in additionalmemos to define specific benchmarking tests and the suggested format to be used in reporting the results of each of the tests. This memo is a product of the Benchmarking Methodology Working Group (BMWG) of the Internet Engineering Task Force (IETF).1. IntroductionVendors often engage in "specsmanship" in an attempt to give theirproducts a better position in the marketplace. This usually involves much "smoke & mirrors" used to confuse the user. This memo andfollow-up memos attempt to define a specific set of terminology and tests that vendors can use to measure and report the performancecharacteristics of network devices. This will provide the usercomparable data from different vendors with which to evaluate these devices.2. Definition formatTerm to be defined. (e.g., Latency)Definition:The specific definition for the term.Discussion:A brief discussion about the term, it's applicationand any restrictions on measurement procedures.Measurement units:The units used to report measurements of thisterm, if applicable.Issues:List of issues or conditions that effect this term.See Also:List of other terms that are relevant to the discussion of this term.3. Term definitions3.1 Back-to-backDefinition:Fixed length frames presented at a rate such that there is the minimum legal separation for a given mediumbetween frames over a short to medium period of time,starting from an idle state.Discussion:A growing number of devices on a network can producebursts of back-to-back frames. Remote disk serversusing protocols like NFS, remote disk backup systemslike rdump, and remote tape access systems can beconfigured such that a single request can result ina block of data being returned of as much as 64K octets. Over networks like ethernet with a relatively small MTU this results in many fragments to be transmitted. Since fragment reassembly will only be attempted if allfragments have been received, the loss of even onefragment because of the failure of some intermediatenetwork device to process enough continuous frames can cause an endless loop as the sender repetitivelyattempts to send its large data block.With the increasing size of the Internet, routingupdates can span many frames, with modern routers able to transmit very quickly. Missing frames of routinginformation can produce false indications ofunreachability. Tests of this parameter are intendedto determine the extent of data buffering in thedevice.Measurement units:Number of N-octet frames in burst.Issues:See Also:3.2 BridgeDefinition:A system which forwards data frames based on information in the data link layer.Discussion:Measurement units:n/aIssues:See Also:bridge/router (3.3)router (3.15)3.3 bridge/routerDefinition:A bridge/router is a network device that can selectively function as a router and/or a bridge based on theprotocol of a specific frame.Discussion:Measurement units:n/aIssues:See Also:bridge (3.2)router (3.15)3.4 Constant LoadDefinition:Fixed length frames at a fixed interval time.Discussion:Although it is rare, to say the least, to encountera steady state load on a network device in the realworld, measurement of steady state performance maybe useful in evaluating competing devices. Theframe size is specified and constant. All deviceparameters are constant. When there is a checksumin the frame, it must be verified.Measurement units:n/aIssues:unidirectional vs. bidirectionalSee Also:3.5 Data link frame sizeDefinition:The number of octets in the frame from the first octet following the preamble to the end of the FCS, ifpresent, or to the last octet of the data if thereis no FCS.Discussion:There is much confusion in reporting the framesizes used in testing network devices or networkmeasurement. Some authors include the checksum,some do not. This is a specific definition for usein this and subsequent memos.Measurement units:octetsIssues:See Also:3.6 Frame Loss RateDefinition:Percentage of frames that should have been forwardedby a network device under steady state (constant)load that were not forwarded due to lack ofresources.Discussion:This measurement can be used in reporting theperformance of a network device in an overloadedstate. This can be a useful indication of how adevice would perform under pathological networkconditions such as broadcast storms.Measurement units:Percentage of N-octet offered frames that are dropped. To be reported as a graph of offered load vs frame loss.Issues:See Also:overhead behavior (3.11)policy based filtering (3.13)MTU mismatch behavior (3.10)3.7 Inter Frame GapDefinition:The delay from the end of a data link frame as defined in section 3.5, to the start of the preamble of thenext data link frame.Discussion:There is much confusion in reporting the betweenframe time used in testing network devices. Thisis a specific definition for use in this and subsequent memos.Measurement units:Time with fine enough units to distinguish between2 events.Issues:Link data rate.See Also:3.8 LatencyDefinition:For store and forward devices:The time interval starting when the last bit of theinput frame reaches the input port and ending whenthe first bit of the output frame is seen on theoutput port.For bit forwarding devices:The time interval starting when the end of the firstbit of the input frame reaches the input port andending when the start of the first bit of the outputframe is seen on the output port.Discussion:Variability of latency can be a problem.Some protocols are timing dependent (e.g., LAT and IPX). Future applications are likely to be sensitive tonetwork latency. Increased device delay can reducethe useful diameter of net. It is desired toeliminate the effect of the data rate on the latencymeasurement. This measurement should only reflect the actual within device latency. Measurements should betaken for a spectrum of frame sizes without changingthe device setup.Ideally, the measurements for all devices would be fromthe first actual bit of the frame after the preamble. Theoretically a vendor could design a device thatnormally would be considered a store and forwarddevice, a bridge for example, that begins transmitting a frame before it is fully received. This type ofdevice is known as a "cut through" device. Theassumption is that the device would somehow invalidate the partially transmitted frame if in receiving theremainder of the input frame, something came up that the frame or this specific forwarding of it was inerror. For example, a bad checksum. In this case,the device would still be considered a store andforward device and the latency would still befrom last bit in to first bit out, even though thevalue would be negative. The intent is to treatthe device as a unit without regard to the internalstructure.Measurement units:Time with fine enough units to distinguish between2 events.Issues:See Also:link speed mismatch (3.9)constant load (3.4)back-to-back (3.1)policy based filtering (3.13)single frame behavior (3.16)3.9 Link Speed MismatchDefinition:Speed mismatch between input and output data rates.Discussion:This does not refer to frame rate per se, it refers to the actual data rate of the data path. For example,an Ethernet on one side and a 56KB serial link on the other. This is has also been referred to as the "fire hose effect". Networks that make use of serial links between local high speed networks will usually havelink speed mismatch at each end of the serial links.Measurement units:Ratio of input and output data rates.Issues:See Also:constant load (3.4)back-to-back (3.1)3.10 MTU-mismatch behaviorDefinition:The network MTU (Maximum Transmission Unit) of theoutput network is smaller than the MTU of the inputnetwork, this results in fragmentation.Discussion:The performance of network devices can be significantly affected by having to fragment frames.Measurement units:Description of behavior.Issues:See Also:3.11 Overhead behaviorDefinition:Processing done other than that for normal data frames.Discussion:Network devices perform many functions in additionto forwarding frames. These tasks range from internal hardware testing to the processing of routinginformation and responding to network managementrequests. It is useful to know what the effect ofthese sorts of tasks is on the device performance.An example would be if a router were to suspendforwarding or accepting frames during the processingof large routing update for a complex protocol likeOSPF. It would be good to know of this sort ofbehavior.Measurement units:Any quantitative understanding of this behavior is by the determination of its effect on other measurements.Issues:bridging and routing protocolscontrol processingicmpip options processingfragmentationerror processingevent logging/statistics collectionarpSee Also:policy based filtering (3.13)3.12 Overloaded behaviorDefinition:When demand exceeds available system resources.Discussion:Devices in an overloaded state will lose frames. The device might lose frames that contain routing orconfiguration information. An overloaded state isassumed when there is any frame loss.Measurement units:Description of behavior of device in any overloadedstates for both input and output overload conditions.Issues:How well does the device recover from overloaded state? How does source quench production effect device?What does device do when its resources are exhausted? What is response to system management in overloadedstate?See Also:3.13 Policy based filteringDefinition:Filtering is the process of discarding receivedframes by administrative decision where normaloperation would be to forward them.Discussion:Many network devices have the ability to beconfigured to discard frames based on a numberof criteria. These criteria can range from simplesource or destination addresses to examiningspecific fields in the data frame itself.Configuring many network devices to performfiltering operations impacts the throughputof the device.Measurement units:n/aIssues:flexibility of filter optionsnumber of filter conditionsSee Also:3.14 Restart behaviorDefinition:Reinitialization of system causing data loss.Discussion:During a period of time after a power up orreset, network devices do not accept and forwardframes. The duration of this period of unavailabilitycan be useful in evaluating devices. In addition,some network devices require some form of resetwhen specific setup variables are modified. If thereset period were long it might discourage networkmanagers from modifying these variables on productionnetworks.Measurement units:Description of device behavior under various restartconditions.Issues:Types:power onreload software imageflush port, reset buffersrestart current code image, without reconfurationUnder what conditions is a restart required?Does the device know when restart needed (i.e., hungstate timeout)?Does the device recognize condition of too frequentauto-restart?Does the device run diagnostics on all or some resets?How may restart be initiated?physical interventionremote via terminal line or login over networkSee Also:3.15 RouterDefinition:A system which forwards data frames based oninformation in the network layer.Discussion:This implies "running" the network level protocolrouting algorithm and performing whatever actionsthat the protocol requires. For example, decrementingthe TTL field in the TCP/IP header.Measurement units:n/aIssues:See Also:bridge (3.2)bridge/router (3.3)3.16 Single frame behaviorDefinition:One frame received on the input to a device.Discussion:A data "stream" consisting of a single frame canrequire a network device to do a lot of processing.Figuring routes, performing ARPs, checkingpermissions etc., in general, setting up cache entries. Devices will often take much more time to process asingle frame presented in isolation than it would ifthe same frame were part of a steady stream. Thereis a worry that some devices would even discard a single frame as part of the cache setup procedure under theassumption that the frame is only the first of many.Measurement units:Description of the behavior of the device.Issues:See Also:policy based filtering (3.13)3.17 ThroughputDefinition:The maximum rate at which none of the offered framesare dropped by the device.Discussion:The throughput figure allows vendors to report asingle value which has proven to have use in themarketplace. Since even the loss of one frame in adata stream can cause significant delays whilewaiting for the higher level protocols to time out,it is useful to know the actual maximum datarate that the device can support. Measurements should be taken over a assortment of frame sizes. Separatemeasurements for routed and bridged data in thosedevices that can support both. If there is a checksum in the received frame, full checksum processing mustbe done.Measurement units:N-octet input frames per secondinput bits per secondIssues:single path vs. aggregateloadunidirectional vs bidirectionalchecksum processing required on some protocolsSee Also:frame loss rate (3.6)constant load (3.4)back-to-back (3.1)4. AcknowledgementsThis memo is a product of the IETF BMWG working group:Chet Birger, Coral NetworksScott Bradner, Harvard University (chair)Steve Butterfield, independant consultantFrank Chui, TRWPhill Gross, CNRIStev Knowles, FTP Software, Inc.Mat Lew, TRWGary Malkin, FTP Software, Inc.K.K. Ramakrishnan, Digital Equipment Corp.Mick Scully, Ungerman BassWilliam M. Seifert, Wellfleet Communications Corp.John Shriver, Proteon, Inc.Dick Sterry, MicrocomGeof Stone, Network Systems Corp.Geoff Thompson, SynOpticsMary Youssef, IBMSecurity ConsiderationsSecurity issues are not discussed in this memo.Author's AddressScott BradnerHarvard UniversityWilliam James Hall 123233 Kirkland StreetCambridge, MA 02138Phone: (617) 495-3864EMail: SOB@Or, send comments to: bmwg@.[ Index | Search | What's New | Comments | Help ] Comments/Questions about this archive ? Send mail to rfc-admin@。
RFC4028中文版
SIP会话定时器摘要本文定义了SIP的一种扩展机制，该扩展通过发送一个re-INVITE或UPDATE请求来周期性的更新SIP会话。
通过更新用户代理和代理服务器可以判断会话是否还活动着。
该扩展定义了两个新的头字段：Session-Expires，用来传达会话的寿命，Min-SE，用来传达会话定时器允许的最小值。
引论会话初始化协议（SIP）并没有为所建立的会话定义存活机制。
尽管用户代理可以通过会话特定的机制判断会话是否超时，但是代理服务器却做不到这点。
如此一来，有状态代理服务器有时会无法判断会话是否还是活动的。
例如，当一个用户代理在会话结束时发送BYE消息失败，或者由于网络问题BYE消息丢失，有状态代理服务器将不会知道会话已经结束。
在这种情况下，有状态代理服务器将保持呼叫的状态并且无法知道呼叫状态信息何时失效。
为了解决这个问题，本扩展为SIP会话定义了一种存活机制。
用户代理周期性的发送re-INVITE或UPDATE请求（参见会话更新请求）用来保持会话的活动。
会话更新请求的间隔通过本文定义的协商机制决定。
如果在间隔内没有收到会话更新请求，该会话被认为已经终止。
用户代理会发送一个BYE消息，有状态代理服务器则将该呼叫的所有状态移除。
这种更新机制还有一些附加的应用。
一个用户代理和一个代理服务器出于同一个目的，都想知道会话是否还活动着，可以在用户代理上作出判断而无需使用SIP层的机制；对于音频会话，周期性的RTCP报文充当着会话活动的指示。
无论如何，将SIP会话的活动指示从特定会话的细节中分离出来是合理的。
会话定时器的另一个应用是SIP网络地址转换（NAT）应用层网关（ALG）的构造。
内嵌在NAT中的ALG需要在呼叫持续期间维护状态。
最终这个状态必须被删除。
依赖于发送BYE 消息来触发状态的删除，除了状态已经不可靠之外，还引入了潜在的拒绝服务攻击。
本文提供了一种SIP扩展机制用于定义会话期满机制。
通过re-INVITE或UPDATE的周期性更新被用来保持会话的活动性。
中国移动统一DPI设备技术规范标准-LTE信令采集解析服务器接口规范标准v2.0.9-LTE各接口XDR规范标准
中国移动通信企业标准QB-╳╳-╳╳╳-╳╳╳╳中国移动统一D P I设备技术规范-L T E信令采集解析服务器接口规范Te c h n i c a l S p e c i f i c a t i o n o f D e e p P a c k e tI n s p e c t i o n E q u i p m e n t f o r C M C C(L T E S i g n a l l i n g C o l l e c t i o n S e r v e r I n t e r f a c eP a r t)版本号：2.0.9╳╳╳╳-╳╳-╳╳发布╳╳╳╳-╳╳-╳╳实施中国移动通信集团公司发布目录1 范围 (3)2 规范性引用文件 (3)3 术语、定义和缩略语 (4)4 接口在网络中的位置 (6)5 LTE接口XDR数据构成方式 (8)5.1. XDR编号与上报要求 (8)6 Uu接口XDR数据结构 (9)6.1. 公共信息 (9)6.2. Uu接口信息 (11)6.3. Uu接口Keyword 1字段定义 (15)6.4. Uu接口事件流程开始/结束标识 (17)7 X2接口XDR数据结构 (17)7.1. 公共信息 (17)7.2. X2接口信息 (17)7.3. X2接口事件流程开始/结束标识 (23)8 UE_MR XDR数据结构 (23)8.1. 公共信息 (23)8.2. UE_MR信息 (23)9 Cell_MR XDR数据结构 (27)9.1. 公共信息 (27)9.2. Cell_MR信息 (27)10 S1-MME接口XDR数据结构 (28)10.1. 公共信息 (28)10.2. S1-MME接口信息 (28)10.3. S1-MME接口Keyword 1字段定义 (38)10.4. S1-MME接口Keyword 2字段定义 (40)10.5. S1-MME接口事件流程开始/结束标识 (47)11 S1-U接口XDR数据结构 (47)12 S6a 接口XDR数据结构 (47)12.1. 公共信息 (47)12.2. S6a接口信息 (48)13 S10、S11接口XDR数据结构 (50)13.1. 公共信息 (50)13.2. S10、S11接口信息 (50)14 S5/S8-C接口XDR数据结构 (57)14.1. 公共信息 (57)14.2. S5/S8-C接口信息 (57)15 SGs接口XDR数据结构 (61)15.1. 公共信息 (61)15.2. SGs接口信息 (62)16 Gn-C接口XDR数据结构 (65)16.1. 公共信息 (65)16.2. Gn-C接口信息 (65)17 基于XDR的原始码流上报 (68)17.1. 原始码流上报功能 (68)17.2. 基于XDR上报原始码流的格式 (68)17.3. 按帧封装的原始码流要求 (69)17.3.1. 通用包头格式 (70)17.3.2. 专用包头格式 (71)17.3.3. 原始数据 (71)18 接口协议 (71)18.1. SDTP协议概述 (72)18.2. 消息类型 (73)18.3. 消息结构 (74)18.4. 连接管理流程 (75)18.5. 连接管理消息 (77)18.5.1. 版本协商verNego (77)18.5.1.1. 请求 (77)18.5.1.2. 应答 (77)18.5.2. 链路认证linkAuth (78)18.5.2.1. 请求 (78)18.5.2.2. 应答 (79)18.5.3. 链路检测linkCheck (80)18.5.3.1. 请求 (80)18.5.3.2. 应答 (80)18.5.4. 链路数据发送校验linkDataCheck (80)18.5.4.1. 请求 (80)18.5.4.2. 应答 (81)18.5.5. 链路释放linkRel (82)18.5.5.1. 请求 (82)18.5.5.2. 应答 (82)18.6. 数据传输消息 (82)18.6.1. XDR数据传输notifyXDRData (83)18.6.1.1. 请求 (83)18.6.1.2. 应答 (83)18.6.2. XDR对应原始码流传输XDRRawDataSend (83)18.6.2.1. 请求 (83)18.6.2.2. 应答 (83)19 编制历史 (84)附录A：Uu/X2接口XDR事件流程和关键信令点 (85)附录B：S1-MME接口XDR事件流程和关键信令点 (85)前言本规范对中国移动网内使用的深度包检测（DPI）设备的功能和性能提出要求，是部署统一DPI设备需要遵从的技术文件。
极限交换机VDX6740和VDX6740T产品介绍说明书
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
rfc3281中文
3
2.术语
为了方便起见，在这个说明中我们使用了术语“客户端”和“服务器端” 。这不表示属 性证书只能用于 C/S 环境。例如，属性证书可以用于 S/MIME v3，在这种环境中使用这些 术语时，邮件客户代理既代表“客户端” ，同时也代表“服务器端” 。 术语 AA AC AC user AC verifier AC issuer AC holder Client Proxying PKC 含义 属性管理机构，颁发属性证书的实体，在本文档中和 AC issuer 同义 属性证书 解析或处理属性证书的实体 检查属性证书有效性的实体并且决定最后如何使用属性证书 签发属性证书的实体，在本文档中和 AA 同义 属性证书持有者字段中(可能是间接的)对应的实体 发出请求动作的实体，请求动作需要接受权限检查 在本文档中，Proxying 通常是指应用服务器端充当应用客户端，代表一个用 户的情况，并不是指授权机构的授权 公钥证书——使用 ASN.1 标准，在 X.509 中定义的证书格式和 RFC2459 中 定义的框架。使用这个(不规范的)缩略词是为了避免与术语“X.509 证书”混 淆 要求进行权限检查的实体
2
这意味着构造这样的应用只要求一次处理一个属性证书。 需要处理超过一个属性证书的 话， 一个接一个地处理。 然而要注意， 属性证书的有效性可能依赖于 PKCs 证书链的有效性， PKCs 证书链有效性的定义请参考[PKIXPROF]。
1.2 属性证书的分发(“推”和“拉”)
如上面讨论， 属性证书提供了一种机制， 这种机制安全地提供了授权信息来实现例如访 问控制决策等功能。然而，属性证书还有很多种可能的通信路径。 在一些环境下，比较适合的方法是从客户端“推”一个属性证书到服务器端。这样客户 端和服务器端不需要建立新的连接， 服务器端没有附加的搜索负担， 这样就改进了性能而且 属性证书验证者只提取“需要知道”的内容。 “推”模式适合于客户端的权限被分配在客户 端的“home”域以内的情况。 另一种情况， 它更适合于服务器端对客户端的简单鉴别， 服务器端从属性证书颁发者请 求或“拉”客户端的属性证书。使用“拉”模式主要的好处是它可以在不改变客户端或者客 户端/服务器端协议的情况下实现。 “拉”模式适合于客户端的权限被分配在服务器的域中， 而不是在客户端的域的情况。 可以交互信息的实体有三个：客户端，服务器端，还有属性证书颁发者。此外，为支 持属性证书检索还应该有一个目录服务器或者其他证书仓库。 图 1 描述了在各个实体间的交互信息（包括属性证书）的抽象视图。本文档没有对这 些交互规定特定的协议。
SIM卡应用技术规范【范本模板】
中国移动通信集团公司业务卡管理体系SIM卡应用技术规范中国移动通信集团公司二○○一年十一月1 范围 (5)2 引用标准 (5)3 符号和缩略语 (8)4 SIM卡应用工具箱概述 (9)4.1 概要信息下载 (9)4.2 主动式SIM卡 (9)4.3 下载数据到SIM卡 (10)4。
4 菜单选择 (10)4.5 SIM卡呼叫控制 (10)4.6 SIM卡的MO短消息控制 (10)4.7 事件下载 (10)4。
8 安全 (11)5 概要信息下载 (11)5.1 过程 (11)5。
2 TERMINAL PROFILE的结构和编码： (11)6 主动式SIM卡 (15)6。
1 概述 (15)6。
2 主动式SIM卡命令描述 (18)6。
2。
1 DISPLAY TEXT (18)6。
2。
1.1 命令和过程 (18)6。
2.1。
2 FETCH（DISPLAY TEXT）命令结构 (20)6。
2.2 GET INKEY (21)6.2。
2.1 命令和过程 (21)6.2.2。
2 FETCH（GET INKEY)命令结构 (23)6。
2。
3 GET INPUT (23)6。
2。
3。
1 命令和过程 (23)6.2.3。
2 FETCH（GET INPUT)命令结构 (25)6.2.4 MORE TIME (26)6。
2.4。
1 命令和过程 (26)6。
2.4.2 FETCH（MORE TIME）命令结构 (26)6.2。
5 PLAY TONE (26)6。
2。
5。
1 命令和过程 (26)6.2。
5。
2 FETCH（PLAY TONE）命令结构 (28)6.2。
6 POLL INTERVAL (30)6.2.6。
1 命令和过程 (30)6.2。
6。
2 FETCH(POLL INTERV AL）命令结构 (30)6。
2.7 REFRESH (30)6.2。
7.1 命令和过程 (30)6.2.7.2 FETCH(REFRESH）命令结构 (33)6。
MIME协议及邮件格式分析
电子邮件也许是一个Internet上的流行最广泛的应用。
也是我们现在的大多数网络办公流程的基础。
各种邮件服务器很多,但都大都遵循以1982年出版的RFC822--《ARPA网络文本信息格式标准(STANDARD FOR THE FORMAT OF ARPA INTERNET TEXT MESSAGES)》为基础的一系列邮件格式的规定。
RFC（The Requests for Comments）是用来规定互联网工作标准的文档。
我们使用的时候并没有注意到这些协议在我们的邮件通信过程中默默的发挥着的作用，这丝毫也不能减低这些作用的重要性。
邮件内部还有很多不为人知的秘密。
在RFC822中规定一封信包括一个必须的多个头部域（header fields）和一个可选的体部（body）组成。
从一封信头开始至第一个空行都是头部。
头部定义了一个邮件的各项基本要素，路由信息等内容。
在Outlook Express中选定一封信看它的属性。
在详细资料选项卡中显示的就是这封邮件的头部内容。
也可以选定一封信，另存为一个.eml文件。
由于文件是一个纯文本文件，用一般的编辑器打开就可以看到邮件的内容。
头部有各个头部域组成，每一个头部域都包括域名（field-name）和域体（field-body），它们之间以"："分隔。
每一个头部域都可以看作由ASCII码字符组成的独立的文本。
常见的头部域包括："Return-Path", "Received", "Date", "From", "Subject", "Sender","To", "cc","MIME-Version"等。
各头部域之间没有规定顺序。
就像各个域的名字一样。
他们表示的具体意义也不同。
OpenSips构建电话通信系统资料
目录使用OpenSER构建电话通信系统 (1)第一章：SIP介绍（Introduction to SIP） (1)第二章：SIP快速路由器（The SIP Express Router） (28)第三章：OpenSER安装（OpenSER Installation） (42)第四章：OpenSER标准配置（OpenSER Standard Configuration） (58)第五章：用MySQL添加认证（Adding Authentication with MySQL） (85)第六章：使用SerMyAdmin构建用户入口 (121)第七章：与PSTN的连通（Connectivity to the PSTN） (138)第八章：通话前转和语音邮件（call forward and voice mail） (177)使用OpenSER构建电话通信系统Building Telephony Systems with OpenSER第一章：SIP介绍（Introduction to SIP）会话初始化协议是互联网工程任务组（IETF）制定的协议标准，在多个RFC （Request for Comments）文档中被进行了描述说明。
RFC3261是最近的一个RFC，一般称它为SIP版本2。
SIP是一个应用层的协议，用来建立，修改，终止会话（sessions）或是多媒体通话（multimedia calls）。
这些会话可以会议（conferences），e-learning，网络电话和一些相似的应用。
它是同HTTP协议相类似的文本协议并且被设计用来发起，保持，关闭用户之间的交互会话。
目前SIP已经是VoIP领域被广泛使用的协议之一了，市场上几乎每一台IP电话都会支持它。
本章结束的时候你将能够：●描述SIP是什么●描述SIP是干什么的●描述SIP的框架●解释SIP主要部件的意义●理解并比较主要SIP消息●描述INVITE和REGISTER请求消息头部的处理过程在建立和关闭多媒体通话的过程中，SIP协议支持五种要素。
中文RFC文档阅读 2501-3000
中文RFC文档阅读2501-3000ＲＦＣ2508 低速串行链路下IP/UDP/RTP数据包头的压缩ＲＦＣ2511 Internet X.509认证请求消息格式ＲＦＣ2516 在以太网上传输PPP的方法（PPPoE）ＲＦＣ2526 IPv6保留的子网任意传送地址ＲＦＣ2541 DNS 安全操作考虑ＲＦＣ2547 BGP/MPLS VPNsＲＦＣ2554 SMTP服务认证扩展ＲＦＣ2560 x.509因特网公钥基础设施在线证书状态协议——OCSPＲＦＣ2570 标准互联网络管理框架第三版介绍ＲＦＣ2577 FTP 安全考虑ＲＦＣ2581 TCP拥塞控制ＲＦＣ2582 TCP的快速恢复算法NewReno修正ＲＦＣ2585 Internet X.509 公共键底部结构操作协议: FTP和HTTPＲＦＣ2597 确定的面向PHB组ＲＦＣ2598 面向加速PHBＲＦＣ2618 RADIUS 身份验证客户端管理系统库(MIB)ＲＦＣ2629 用XML 写I-Ds 和ＲＦＣ文档ＲＦＣ2633 S/多用途网际邮件扩充协议(MIME) 版本3 信息说明书ＲＦＣ2644 更改直接广播在路由器上的缺省值ＲＦＣ2669 DOCSIS 电缆设备管理系统库(MIB) 电缆设备管理信息基础用于DOCSIS 适应性电缆调制解调器和电缆调制解调器中断系统ＲＦＣ2670 音频频率(RF)界面管理信息基础用于MCNS/DOCSIS适应性RF界面ＲＦＣ2685 虚拟专用网标志符ＲＦＣ2702 基于MPLS的流量工程要求ＲＦＣ2706 ECML v1:电子商务字段名ＲＦＣ2713 LDAP（轻型目录存取协议）目录中JAVATM对象的表征模式ＲＦＣ2714 LDAP（轻型目录存取协议）目录中的CORBA对象参考方案ＲＦＣ2731 Dublin核心元数据在HTML上的编码ＲＦＣ2732 文本IPv6地址在URL上的格式ＲＦＣ2733 RTP有效载荷格式用于普通正向错误更正ＲＦＣ2736 RTP有效载荷格式说明书作者的指导方针ＲＦＣ2754 RPS IANA的发布ＲＦＣ2756 超文本缓存协议(HTCP/0.0)ＲＦＣ2764 IP VPN的框架体系ＲＦＣ2773 使用KEA和SKIPJACK加密ＲＦＣ2774 HTTP 扩展框架ＲＦＣ2781 UTF-16,ISO 10646的一种编码ＲＦＣ2784 通用路由封装（GRE）ＲＦＣ2788 网络服务监视MIBＲＦＣ2793 用于文本交谈的RTP负载ＲＦＣ2796 BGP路由映象ＲＦＣ2809 通过RADIUS的L2TP强制通道的执行ＲＦＣ2810 Internet 延迟交谈:体系结构ＲＦＣ2811 Internet延迟交谈：通道管理ＲＦＣ2813 Internet 延迟交谈:服务器协议ＲＦＣ2817 在HTTP/1.1中升级到TLSＲＦＣ2818 TLS之上的HTTPＲＦＣ2824 呼叫过程语言框架和要求ＲＦＣ2825 复杂网络:I18N的发布,域名,和其它Internet协议ＲＦＣ2829 LDAP的身份验证方法ＲＦＣ2830 轻量级目录访问协议(v3): 传输层安全扩展ＲＦＣ2833 用于DTMF数字信号、电话音和电话信号的RTP负载格式ＲＦＣ2854 text/html 媒体类型ＲＦＣ2855 IEEE 1394的DHCPＲＦＣ2861 TCP 拥塞窗口检验ＲＦＣ2862 用于实时指针的RTP负载格式ＲＦＣ2866 RADIUS（远程用户拨号认证系统）记帐协议ＲＦＣ2867 RADIUS 账目管理修改用于通道协议支持ＲＦＣ2868 RADIUS 属性用于协议支持ＲＦＣ2869 RADIUS 扩展ＲＦＣ2871 一个IP电话路由框架ＲＦＣ2873 在Ipv4优先域中的TCP过程ＲＦＣ2874 支持IPv6地址集合和重编号的DNS 扩展ＲＦＣ2882 网络访问服务要求: 扩展范围实践ＲＦＣ2887 可靠的多点传送设计空间用于大的数据传送ＲＦＣ2889 基准方法论用于局域网交换设备ＲＦＣ2890 GRE中Key和SequenceNumber扩展ＲＦＣ2893 IPv6 主机和软件路由器转换机制ＲＦＣ2898 PKCS #5: 基于密码的密码系统说明书版本 2.0. BＲＦＣ2906 AAA 授权要求ＲＦＣ2914 拥塞控制原理ＲＦＣ2917 核心MPLS IP VPN 体系结构ＲＦＣ2918 BGP-4（边界网关协议）的路由刷新功能ＲＦＣ2920 SMTP 针对命令流水线的服务扩展ＲＦＣ2923 TCP的路径MTU发现问题ＲＦＣ2932 IPv4 多点传送路由管理系统库(MIB)ＲＦＣ2935 Internet开放贸易协议(IOTP)HTTP 补充ＲＦＣ2939 新DHCP选项和信息类型的定义步骤和IANA指导方针ＲＦＣ2945 SRP身份验证和键交换系统ＲＦＣ2946 Telnet 数据加密选项ＲＦＣ2947 Telnet加密：DES3 64位密码回馈ＲＦＣ2948 Telnet加密：DES3 64位输出回馈ＲＦＣ2949 Telnet加密:CAST-128 64比特输出回馈ＲＦＣ2950 Telnet加密:CAST-128 64比特密码回馈ＲＦＣ2951 使用KEA和SKIPJACK进行TELNET身份验证ＲＦＣ2952 Telnet加密：DES 64位密码回馈ＲＦＣ2953 Telnet加密:DES 64比特输出回馈ＲＦＣ2957 The 应用/whoispp-请求目录-类型ＲＦＣ2958 The 应用/whoispp-回答目录-类型ＲＦＣ2959 实时传输协议管理信息库ＲＦＣ2964 超文本传输协议(HTTP)状态管理的应用ＲＦＣ2971 Internet信息访问协议(IMAP4)的标识符扩展ＲＦＣ2976 SIP信息方法ＲＦＣ2983 有区别的协议和通道ＲＦＣ2984 CAST-128密码算法在CMS中的使用ＲＦＣ2987 字符集注册和语言媒体特征标签ＲＦＣ2988 计算TCP重传时间的定时器ＲＦＣ2991 多路径分发在Unicast上和多点传送下一路程段选择ＲＦＣ2992 等值多-路径算法的分析ＲＦＣ2994 MISTY1加密算法的描述。
rfc2045.txt
N. Freed Innosoft N. Borenstein First Virtual November 1996
Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies Status of this Memo This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. Abstract STD 11, RFC 822, defines a message representation protocol specifying considerable detail about US-ASCII message headers, and leaves the message content, or message body, as flat US-ASCII text. This set of documents, collectively called the Multipurpose Internet Mail Extensions, or MIME, redefines the format of messages to allow for (1) textual message bodies in character sets other than US-ASCII, an extensible set of different formats for non-textual message bodies, multi-part message bodies, and textual header information in character sets other than US-ASCII.
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
Network Working Group W. ZhaoRequest for Comments: 3421 H. SchulzrinneCategory: Experimental Columbia University E. Guttman Sun Microsystems C. Bisdikian W. Jerome IBM November 2002
Select and Sort Extensions for the Service Location Protocol (SLP)Status of this Memo This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.
Copyright Notice Copyright (C) The Internet Society (2002). All Rights Reserved.Abstract This document defines two extensions (Select and Sort) for the Service Location Protocol (SLP). These extensions allow a User Agent (UA) to request that the Uniform Resource Locator (URL) entries in a Service Reply (SrvRply) be limited to the specified number, or be sorted according to the specified sort key list. Using these two extensions together can facilitate discovering the best match, such as finding a service that has the maximum speed or the minimum load.
1. Introduction This document defines two extensions (Select and Sort) for SLP [RFC2608]. These extensions allow a UA to request that the URL entries in a SrvRply be limited to the specified number, or be sorted according to the specified sort key list. A Directory Agent (DA) or Service Agent (SA) that supports the Select and/or Sort extensions MUST include the attribute keyword "select-enabled" and/or "sort- enabled" in its advertisement (DAAdvert or SAAdvert). A UA SHOULD check these attributes of the contacting DA/SA before it uses the Select and/or Sort extensions to query the DA/SA.
Zhao, et. al. Experimental [Page 1]RFC 3421 Select and Sort Extensions for SLP November 2002 Using the Select extension, a UA can opt for finding just a few (not necessarily all) matching services, which is useful if the UA uses a low-bandwidth channel. Using the Sort extension, a UA can ask the DA/SA to sort matching URL entries, which helps the UA to choose a service from multiple candidates. Sorting by the server is more efficient than sorting by the client since for sorting purposes, the former does not need to pass the attributes of matching URLs to the client. Furthermore, using the Select and Sort extensions together can facilitate discovering the best match, such as finding a service that has the maximum speed or the minimum load, or has a speed closest to a reference value.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted according to in BCP 14, RFC 2119 [RFC2119].
2. Select Extension 0 1 2 3 0 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Select Extension ID = 0x4002 | Next Extension Offset (NEO) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NEO, cont’d | Number of URL Entries | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1. Select Extension The format of the Select extension is shown in Figure 1. A UA uses this extension in a Service Request (SrvRqst) to limit the maximum number (say, n) of URL entries to be returned. When a DA/SA receives a SrvRqst with a Select extension, it MUST use a Select extension in the corresponding SrvRply to indicate the total number (say, m) of matching URL entries if the DA/SA supports this extension, otherwise the DA/SA MUST set the error code in the corresponding SrvRply to OPTION_NOT_UNDERSTOOD [RFC2608]. If n < m, then only the first n matching URL entries are returned, else all m matching URL entries are returned. As a special case, a UA may set n to zero to obtain the number of matching URL entries without retrieving the entries themselves.
We denote a Select extension as Select(number). Thus, Select(3) means that the corresponding SrvRply can have at most three URL entries.
Zhao, et. al. Experimental [Page 2]RFC 3421 Select and Sort Extensions for SLP November 20023. Sort Extension 0 1 2 3 0 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sort Extension ID = 0x4003 | Next Extension Offset (NEO) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NEO, cont’d | length of |\ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+