rfc1401.Correspondence between the IAB and DISA on the use of DNS throughout the Internet
信息系统项目经理继续教育中级C组考试谜底真题
信息技术篇一、单选题1.在某企业中LVS和Piranha服务器http或者https方式访问Piranha的web管理界面Linux服务器可以远程通过SSH管理为满足如上通讯要求C A.80B.3636C. 22 D .4432.在与Piranha Web管理器进行安全通讯时D口 A.443B.80C.8080D.33893.下列哪些算法不属于LVS常用的调度算法A A.轮叫算法Round RobinB.加权轮叫Weighted Round RobinC.轮询算法Round AskD.最少链接Least Connection4.为保证Piranhaa Wed服务器的安全通讯SSL/TLS技术来加固通讯取安全通讯D服务器 A.CAB.DNSC.WebD.SNMP5.对于LVS服务器而言VS/NAT方式VS/DR方式均需打开A使得Linux服务器可以进行IP数据包转发A.路由 B.地址转换 C.包转发 D.以上均不是6.在LVS架构中LVS服务器作为Web站点集群的负载均衡调度器VS/DR 的通讯架构Web服务器而言D A.1B.2C.3D.47.在LVS架构中LVS服务器作为Web站点集群的负载均衡调度器Web服务器而言C A.1 B.2C.3D.48.如果要对Piranha的web站点部署SSL/TLS技术以加密通讯Web服务器需要获取DHTTPS访问的支持A.SSH服务器 B.DNS服务器 C.服务器证书D.客户端证书9.为了保证LVS的Web管理工具Piranha的安全访问(B)设置A.高可用B.高性能 C.访问控制 D.优化10.在LVS部署架构中LVS作为负载均衡调度器C台LVS主机 A.1 B.2 C.3 D.4 11.为部署VS/NA T类型的LVS服务器A A.1B.2C.3D.412.使用Linux做LVS服务器时Linux系统的包转发功能C文件来实现 A../etc/sysctl.confB./etc/hostsC./etc/ipforward.confD./etc/forward.conf13.下列哪项不属于集群技术种类中的分类B A.高可用集群High Available ClusterB.负载均衡集群Load Balance ClusterC.多通道集群Multi-Path ClusterD.网格计算Grid Computing14.下面哪组不属于集群系统文件系统(D)A.IBM GPFS B.NFS C.RedHat GFSD.MS CSV15.Piranha实际使用Linux的apache来提供web管理页面apache进行管理配置A apache软件A.rpm-ivh apacheB.rpm-i apache C.rpm-qa丨grep apache D.rpm-qt丨grep apache16.Linux中可以使用AA.chkconfigB.pingC.vinconfig17.RHEL中实现LVS时A A.DNS 服务 B.DHCP服务 C.SSH服务 D.Wed服务18.计算机集群技术时使用非常广泛的一种大规模计算技术B A.远程协助 B.高性能计算 C.提供高可用计算 D.网格计19.LVS的全称是D A.Logical V olume Server B.Logical Virtual Server C.Linux Virtual Server D.Linux V olume Server20.目前各地电信运营商建成了许多市地级的宽带IP城域网。
rfc2661.Layer Two Tunneling Protocol L2TP
Network Working Group W. Townsley Request for Comments: 2661 A. Valencia Category: Standards Track cisco Systems A. Rubens Ascend Communications G. Pall G. Zorn Microsoft Corporation B. Palter Redback Networks August 1999 Layer Two Tunneling Protocol "L2TP"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 (1999). All Rights Reserved.AbstractThis document describes the Layer Two Tunneling Protocol (L2TP). STD 51, RFC 1661 specifies multi-protocol access via PPP [RFC1661]. L2TP facilitates the tunneling of PPP packets across an interveningnetwork in a way that is as transparent as possible to both end-users and applications.Table of Contents1.0 Introduction (3)1.1 Specification of Requirements (4)1.2 Terminology (4)2.0 Topology (8)3.0 Protocol Overview (9)3.1 L2TP Header Format (9)3.2 Control Message Types (11)4.0 Control Message Attribute Value Pairs (12)4.1 AVP Format (13)4.2 Mandatory AVPs (14)4.3 Hiding of AVP Attribute Values (14)Townsley, et al. Standards Track [Page 1]4.4.1 AVPs Applicable To All Control Messages (17)4.4.2 Result and Error Codes (18)4.4.3 Control Connection Management AVPs (20)4.4.4 Call Management AVPs (27)4.4.5 Proxy LCP and Authentication AVPs (34)4.4.6 Call Status AVPs (39)5.0 Protocol Operation (41)5.1 Control Connection Establishment (41)5.1.1 Tunnel Authentication (42)5.2 Session Establishment (42)5.2.1 Incoming Call Establishment (42)5.2.2 Outgoing Call Establishment (43)5.3 Forwarding PPP Frames (43)5.4 Using Sequence Numbers on the Data Channel (44)5.5 Keepalive (Hello) (44)5.6 Session Teardown (45)5.7 Control Connection Teardown (45)5.8 Reliable Delivery of Control Messages (46)6.0 Control Connection Protocol Specification (48)6.1 Start-Control-Connection-Request (SCCRQ) (48)6.2 Start-Control-Connection-Reply (SCCRP) (48)6.3 Start-Control-Connection-Connected (SCCCN) (49)6.4 Stop-Control-Connection-Notification (StopCCN) (49)6.5 Hello (HELLO) (49)6.6 Incoming-Call-Request (ICRQ) (50)6.7 Incoming-Call-Reply (ICRP) (51)6.8 Incoming-Call-Connected (ICCN) (51)6.9 Outgoing-Call-Request (OCRQ) (52)6.10 Outgoing-Call-Reply (OCRP) (53)6.11 Outgoing-Call-Connected (OCCN) (53)6.12 Call-Disconnect-Notify (CDN) (53)6.13 WAN-Error-Notify (WEN) (54)6.14 Set-Link-Info (SLI) (54)7.0 Control Connection State Machines (54)7.1 Control Connection Protocol Operation (55)7.2 Control Connection States (56)7.2.1 Control Connection Establishment (56)7.3 Timing considerations (58)7.4 Incoming calls (58)7.4.1 LAC Incoming Call States (60)7.4.2 LNS Incoming Call States (62)7.5 Outgoing calls (63)7.5.1 LAC Outgoing Call States (64)7.5.2 LNS Outgoing Call States (66)7.6 Tunnel Disconnection (67)8.0 L2TP Over Specific Media (67)8.1 L2TP over UDP/IP (68)Townsley, et al. Standards Track [Page 2]9.0 Security Considerations (69)9.1 Tunnel Endpoint Security (70)9.2 Packet Level Security (70)9.3 End to End Security (70)9.4 L2TP and IPsec (71)9.5 Proxy PPP Authentication (71)10.0 IANA Considerations (71)10.1 AVP Attributes (71)10.2 Message Type AVP Values (72)10.3 Result Code AVP Values (72)10.3.1 Result Code Field Values (72)10.3.2 Error Code Field Values (72)10.4 Framing Capabilities & Bearer Capabilities (72)10.5 Proxy Authen Type AVP Values (72)10.6 AVP Header Bits (73)11.0 References (73)12.0 Acknowledgments (74)13.0 Authors’ Addresses (75)Appendix A: Control Channel Slow Start and CongestionAvoidance (76)Appendix B: Control Message Examples (77)Appendix C: Intellectual Property Notice (79)Full Copyright Statement (80)1.0 IntroductionPPP [RFC1661] defines an encapsulation mechanism for transportingmultiprotocol packets across layer 2 (L2) point-to-point links.Typically, a user obtains a L2 connection to a Network Access Server (NAS) using one of a number of techniques (e.g., dialup POTS, ISDN,ADSL, etc.) and then runs PPP over that connection. In such aconfiguration, the L2 termination point and PPP session endpointreside on the same physical device (i.e., the NAS).L2TP extends the PPP model by allowing the L2 and PPP endpoints toreside on different devices interconnected by a packet-switchednetwork. With L2TP, a user has an L2 connection to an accessconcentrator (e.g., modem bank, ADSL DSLAM, etc.), and theconcentrator then tunnels individual PPP frames to the NAS. Thisallows the actual processing of PPP packets to be divorced from thetermination of the L2 circuit.One obvious benefit of such a separation is that instead of requiring the L2 connection terminate at the NAS (which may require along-distance toll charge), the connection may terminate at a (local) circuit concentrator, which then extends the logical PPP session over Townsley, et al. Standards Track [Page 3]a shared infrastructure such as frame relay circuit or the Internet.From the user’s perspective, there is no functional difference between having the L2 circuit terminate in a NAS directly or using L2TP.L2TP may also solve the multilink hunt-group splitting problem.Multilink PPP [RFC1990] requires that all channels composing amultilink bundle be grouped at a single Network Access Server (NAS).Due to its ability to project a PPP session to a location other thanthe point at which it was physically received, L2TP can be used tomake all channels terminate at a single NAS. This allows multilinkoperation even when the calls are spread across distinct physicalNASs.This document defines the necessary control protocol for on-demandcreation of tunnels between two nodes and the accompanyingencapsulation for multiplexing multiple, tunneled PPP sessions.1.1 Specification of RequirementsThe key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT","SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in thisdocument are to be interpreted as described in [RFC2119].1.2 TerminologyAnalog ChannelA circuit-switched communication path which is intended to carry3.1 kHz audio in each direction.Attribute Value Pair (AVP)The variable length concatenation of a unique Attribute(represented by an integer) and a Value containing the actualvalue identified by the attribute. Multiple AVPs make up ControlMessages which are used in the establishment, maintenance, andteardown of tunnels.CallA connection (or attempted connection) between a Remote System and LAC. For example, a telephone call through the PSTN. A Call(Incoming or Outgoing) which is successfully established between a Remote System and LAC results in a corresponding L2TP Sessionwithin a previously established Tunnel between the LAC and LNS.(See also: Session, Incoming Call, Outgoing Call).Townsley, et al. Standards Track [Page 4]Called NumberAn indication to the receiver of a call as to what telephonenumber the caller used to reach it.Calling NumberAn indication to the receiver of a call as to the telephone number of the caller.CHAPChallenge Handshake Authentication Protocol [RFC1994], a PPPcryptographic challenge/response authentication protocol in which the cleartext password is not passed over the line.Control ConnectionA control connection operates in-band over a tunnel to control the establishment, release, and maintenance of sessions and of thetunnel itself.Control MessagesControl messages are exchanged between LAC and LNS pairs,operating in-band within the tunnel protocol. Control messagesgovern aspects of the tunnel and sessions within the tunnel.Digital ChannelA circuit-switched communication path which is intended to carrydigital information in each direction.DSLAMDigital Subscriber Line (DSL) Access Module. A network device used in the deployment of DSL service. This is typically a concentrator of individual DSL lines located in a central office (CO) or local exchange.Incoming CallA Call received at an LAC to be tunneled to an LNS (see Call,Outgoing Call).Townsley, et al. Standards Track [Page 5]L2TP Access Concentrator (LAC)A node that acts as one side of an L2TP tunnel endpoint and is apeer to the L2TP Network Server (LNS). The LAC sits between anLNS and a remote system and forwards packets to and from each.Packets sent from the LAC to the LNS requires tunneling with theL2TP protocol as defined in this document. The connection fromthe LAC to the remote system is either local (see: Client LAC) or a PPP link.L2TP Network Server (LNS)A node that acts as one side of an L2TP tunnel endpoint and is apeer to the L2TP Access Concentrator (LAC). The LNS is thelogical termination point of a PPP session that is being tunneled from the remote system by the LAC.Management Domain (MD)A network or networks under the control of a singleadministration, policy or system. For example, an LNS’s Management Domain might be the corporate network it serves. An LAC’sManagement Domain might be the Internet Service Provider that owns and manages it.Network Access Server (NAS)A device providing local network access to users across a remoteaccess network such as the PSTN. An NAS may also serve as an LAC, LNS or both.Outgoing CallA Call placed by an LAC on behalf of an LNS (see Call, IncomingCall).PeerWhen used in context with L2TP, peer refers to either the LAC orLNS. An LAC’s Peer is an LNS and vice versa. When used in context with PPP, a peer is either side of the PPP connection.POTSPlain Old Telephone Service.Townsley, et al. Standards Track [Page 6]Remote SystemAn end-system or router attached to a remote access network (i.e.a PSTN), which is either the initiator or recipient of a call.Also referred to as a dial-up or virtual dial-up client.SessionL2TP is connection-oriented. The LNS and LAC maintain state foreach Call that is initiated or answered by an LAC. An L2TP Session is created between the LAC and LNS when an end-to-end PPPconnection is established between a Remote System and the LNS.Datagrams related to the PPP connection are sent over the Tunnelbetween the LAC and LNS. There is a one to one relationshipbetween established L2TP Sessions and their associated Calls. (See also: Call).TunnelA Tunnel exists between a LAC-LNS pair. The Tunnel consists of aControl Connection and zero or more L2TP Sessions. The Tunnelcarries encapsulated PPP datagrams and Control Messages betweenthe LAC and the LNS.Zero-Length Body (ZLB) MessageA control packet with only an L2TP header. ZLB messages are usedfor explicitly acknowledging packets on the reliable controlchannel.Townsley, et al. Standards Track [Page 7]2.0 TopologyThe following diagram depicts a typical L2TP scenario. The goal is to tunnel PPP frames between the Remote System or LAC Client and an LNS located at a Home LAN.[Home LAN][LAC Client]----------+ |____|_____ +--[Host]| | |[LAC]---------| Internet |-----[LNS]-----+| |__________| |_____|_____ :| || PSTN |[Remote]--| Cloud |[System] | | [Home LAN]|___________| || ______________ +---[Host]| | | |[LAC]-------| Frame Relay |---[LNS]-----+| or ATM Cloud | ||______________| :The Remote System initiates a PPP connection across the PSTN Cloud to an LAC. The LAC then tunnels the PPP connection across the Internet, Frame Relay, or ATM Cloud to an LNS whereby access to a Home LAN isobtained. The Remote System is provided addresses from the HOME LANvia PPP NCP negotiation. Authentication, Authorization and Accounting may be provided by the Home LAN’s Management Domain as if the userwere connected to a Network Access Server directly.A LAC Client (a Host which runs L2TP natively) may also participatein tunneling to the Home LAN without use of a separate LAC. In thiscase, the Host containing the LAC Client software already has aconnection to the public Internet. A "virtual" PPP connection is then created and the local L2TP LAC Client software creates a tunnel tothe LNS. As in the above case, Addressing, Authentication,Authorization and Accounting will be provided by the Home LAN’sManagement Domain.Townsley, et al. Standards Track [Page 8]3.0 Protocol OverviewL2TP utilizes two types of messages, control messages and datamessages. Control messages are used in the establishment, maintenance and clearing of tunnels and calls. Data messages are used toencapsulate PPP frames being carried over the tunnel. Controlmessages utilize a reliable Control Channel within L2TP to guarantee delivery (see section 5.1 for details). Data messages are notretransmitted when packet loss occurs.+-------------------+| PPP Frames |+-------------------+ +-----------------------+| L2TP Data Messages| | L2TP Control Messages |+-------------------+ +-----------------------+| L2TP Data Channel | | L2TP Control Channel || (unreliable) | | (reliable) |+------------------------------------------------+| Packet Transport (UDP, FR, ATM, etc.) |+------------------------------------------------+Figure 3.0 L2TP Protocol StructureFigure 3.0 depicts the relationship of PPP frames and ControlMessages over the L2TP Control and Data Channels. PPP Frames arepassed over an unreliable Data Channel encapsulated first by an L2TP header and then a Packet Transport such as UDP, Frame Relay, ATM,etc. Control messages are sent over a reliable L2TP Control Channelwhich transmits packets in-band over the same Packet Transport.Sequence numbers are required to be present in all control messagesand are used to provide reliable delivery on the Control Channel.Data Messages may use sequence numbers to reorder packets and detect lost packets.All values are placed into their respective fields and sent innetwork order (high order octets first).3.1 L2TP Header FormatL2TP packets for the control channel and data channel share a common header format. In each case where a field is optional, its space does not exist in the message if the field is marked not present. Notethat while optional on data messages, the Length, Ns, and Nr fieldsmarked as optional below, are required to be present on all controlmessages.Townsley, et al. Standards Track [Page 9]This header is formatted:0 1 2 30 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|T|L|x|x|S|x|O|P|x|x|x|x| Ver | Length (opt) |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Tunnel ID | Session ID |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Ns (opt) | Nr (opt) |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Offset Size (opt) | Offset pad... (opt)+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 3.1 L2TP Message HeaderThe Type (T) bit indicates the type of message. It is set to 0 for a data message and 1 for a control message.If the Length (L) bit is 1, the Length field is present. This bitMUST be set to 1 for control messages.The x bits are reserved for future extensions. All reserved bits MUST be set to 0 on outgoing messages and ignored on incoming messages.If the Sequence (S) bit is set to 1 the Ns and Nr fields are present. The S bit MUST be set to 1 for control messages.If the Offset (O) bit is 1, the Offset Size field is present. The Obit MUST be set to 0 (zero) for control messages.If the Priority (P) bit is 1, this data message should receivepreferential treatment in its local queuing and transmission. LCPecho requests used as a keepalive for the link, for instance, should generally be sent with this bit set to 1. Without it, a temporaryinterval of local congestion could result in interference withkeepalive messages and unnecessary loss of the link. This feature is only for use with data messages. The P bit MUST be set to 0 for allcontrol messages.Ver MUST be 2, indicating the version of the L2TP data message header described in this document. The value 1 is reserved to permitdetection of L2F [RFC2341] packets should they arrive intermixed with L2TP packets. Packets received with an unknown Ver field MUST bediscarded.The Length field indicates the total length of the message in octets. Townsley, et al. Standards Track [Page 10]Tunnel ID indicates the identifier for the control connection. L2TPtunnels are named by identifiers that have local significance only.That is, the same tunnel will be given different Tunnel IDs by eachend of the tunnel. Tunnel ID in each message is that of the intended recipient, not the sender. Tunnel IDs are selected and exchanged asAssigned Tunnel ID AVPs during the creation of a tunnel.Session ID indicates the identifier for a session within a tunnel.L2TP sessions are named by identifiers that have local significanceonly. That is, the same session will be given different Session IDsby each end of the session. Session ID in each message is that of the intended recipient, not the sender. Session IDs are selected andexchanged as Assigned Session ID AVPs during the creation of asession.Ns indicates the sequence number for this data or control message,beginning at zero and incrementing by one (modulo 2**16) for eachmessage sent. See Section 5.8 and 5.4 for more information on usingthis field.Nr indicates the sequence number expected in the next control message to be received. Thus, Nr is set to the Ns of the last in-ordermessage received plus one (modulo 2**16). In data messages, Nr isreserved and, if present (as indicated by the S-bit), MUST be ignored upon receipt. See section 5.8 for more information on using thisfield in control messages.The Offset Size field, if present, specifies the number of octetspast the L2TP header at which the payload data is expected to start. Actual data within the offset padding is undefined. If the offsetfield is present, the L2TP header ends after the last octet of theoffset padding.3.2 Control Message TypesThe Message Type AVP (see section 4.4.1) defines the specific type of control message being sent. Recall from section 3.1 that this is only for control messages, that is, messages with the T-bit set to 1. Townsley, et al. Standards Track [Page 11]This document defines the following control message types (seeSection 6.1 through 6.14 for details on the construction and use ofeach message):Control Connection Management0 (reserved)1 (SCCRQ) Start-Control-Connection-Request2 (SCCRP) Start-Control-Connection-Reply3 (SCCCN) Start-Control-Connection-Connected4 (StopCCN) Stop-Control-Connection-Notification5 (reserved)6 (HELLO) HelloCall Management7 (OCRQ) Outgoing-Call-Request8 (OCRP) Outgoing-Call-Reply9 (OCCN) Outgoing-Call-Connected10 (ICRQ) Incoming-Call-Request11 (ICRP) Incoming-Call-Reply12 (ICCN) Incoming-Call-Connected13 (reserved)14 (CDN) Call-Disconnect-NotifyError Reporting15 (WEN) WAN-Error-NotifyPPP Session Control16 (SLI) Set-Link-Info4.0 Control Message Attribute Value PairsTo maximize extensibility while still permitting interoperability, a uniform method for encoding message types and bodies is usedthroughout L2TP. This encoding will be termed AVP (Attribute-ValuePair) in the remainder of this document.Townsley, et al. Standards Track [Page 12]4.1 AVP FormatEach AVP is encoded as:0 1 2 30 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|M|H| rsvd | Length | Vendor ID |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Attribute Type | Attribute Value...+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+[until Length is reached]... |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+The first six bits are a bit mask, describing the general attributes of the AVP.Two bits are defined in this document, the remaining are reserved for future extensions. Reserved bits MUST be set to 0. An AVP receivedwith a reserved bit set to 1 MUST be treated as an unrecognized AVP. Mandatory (M) bit: Controls the behavior required of animplementation which receives an AVP which it does not recognize. If the M bit is set on an unrecognized AVP within a message associatedwith a particular session, the session associated with this messageMUST be terminated. If the M bit is set on an unrecognized AVP within a message associated with the overall tunnel, the entire tunnel (and all sessions within) MUST be terminated. If the M bit is not set, an unrecognized AVP MUST be ignored. The control message must thencontinue to be processed as if the AVP had not been present.Hidden (H) bit: Identifies the hiding of data in the Attribute Value field of an AVP. This capability can be used to avoid the passing of sensitive data, such as user passwords, as cleartext in an AVP.Section 4.3 describes the procedure for performing AVP hiding.Length: Encodes the number of octets (including the Overall Lengthand bitmask fields) contained in this AVP. The Length may becalculated as 6 + the length of the Attribute Value field in octets. The field itself is 10 bits, permitting a maximum of 1023 octets ofdata in a single AVP. The minimum Length of an AVP is 6. If thelength is 6, then the Attribute Value field is absent.Vendor ID: The IANA assigned "SMI Network Management PrivateEnterprise Codes" [RFC1700] value. The value 0, corresponding toIETF adopted attribute values, is used for all AVPs defined withinthis document. Any vendor wishing to implement their own L2TPextensions can use their own Vendor ID along with private Attribute Townsley, et al. Standards Track [Page 13]values, guaranteeing that they will not collide with any othervendor’s extensions, nor with future IETF extensions. Note that there are 16 bits allocated for the Vendor ID, thus limiting this featureto the first 65,535 enterprises.Attribute Type: A 2 octet value with a unique interpretation acrossall AVPs defined under a given Vendor ID.Attribute Value: This is the actual value as indicated by the Vendor ID and Attribute Type. It follows immediately after the AttributeType field, and runs for the remaining octets indicated in the Length (i.e., Length minus 6 octets of header). This field is absent if the Length is 6.4.2 Mandatory AVPsReceipt of an unknown AVP that has the M-bit set is catastrophic tothe session or tunnel it is associated with. Thus, the M bit shouldonly be defined for AVPs which are absolutely crucial to properoperation of the session or tunnel. Further, in the case where theLAC or LNS receives an unknown AVP with the M-bit set and shuts down the session or tunnel accordingly, it is the full responsibility ofthe peer sending the Mandatory AVP to accept fault for causing annon-interoperable situation. Before defining an AVP with the M-bitset, particularly a vendor-specific AVP, be sure that this is theintended consequence.When an adequate alternative exists to use of the M-bit, it should be utilized. For example, rather than simply sending an AVP with the M- bit set to determine if a specific extension exists, availability may be identified by sending an AVP in a request message and expecting a corresponding AVP in a reply message.Use of the M-bit with new AVPs (those not defined in this document)MUST provide the ability to configure the associated feature off,such that the AVP is either not sent, or sent with the M-bit not set.4.3 Hiding of AVP Attribute ValuesThe H bit in the header of each AVP provides a mechanism to indicate to the receiving peer whether the contents of the AVP are hidden orpresent in cleartext. This feature can be used to hide sensitivecontrol message data such as user passwords or user IDs.The H bit MUST only be set if a shared secret exists between the LAC and LNS. The shared secret is the same secret that is used for tunnel authentication (see Section 5.1.1). If the H bit is set in any Townsley, et al. Standards Track [Page 14]AVP(s) in a given control message, a Random Vector AVP must also bepresent in the message and MUST precede the first AVP having an H bit of 1.Hiding an AVP value is done in several steps. The first step is totake the length and value fields of the original (cleartext) AVP and encode them into a Hidden AVP Subformat as follows:0 1 2 30 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Length of Original Value | Original Attribute Value ...+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+... | Padding ...+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Length of Original Attribute Value: This is length of the OriginalAttribute Value to be obscured in octets. This is necessary todetermine the original length of the Attribute Value which is lostwhen the additional Padding is added.Original Attribute Value: Attribute Value that is to be obscured.Padding: Random additional octets used to obscure length of theAttribute Value that is being hidden.To mask the size of the data being hidden, the resulting subformatMAY be padded as shown above. Padding does NOT alter the value placed in the Length of Original Attribute Value field, but does alter thelength of the resultant AVP that is being created. For example, If an Attribute Value to be hidden is 4 octets in length, the unhidden AVP length would be 10 octets (6 + Attribute Value length). After hiding, the length of the AVP will become 6 + Attribute Value length + sizeof the Length of Original Attribute Value field + Padding. Thus, ifPadding is 12 octets, the AVP length will be 6 + 4 + 2 + 12 = 24octets.Next, An MD5 hash is performed on the concatenation of:+ the 2 octet Attribute number of the AVP+ the shared secret+ an arbitrary length random vectorThe value of the random vector used in this hash is passed in thevalue field of a Random Vector AVP. This Random Vector AVP must beplaced in the message by the sender before any hidden AVPs. The same random vector may be used for more than one hidden AVP in the same Townsley, et al. Standards Track [Page 15]message. If a different random vector is used for the hiding ofsubsequent AVPs then a new Random Vector AVP must be placed in thecommand message before the first AVP to which it applies.The MD5 hash value is then XORed with the first 16 octet (or less)segment of the Hidden AVP Subformat and placed in the Attribute Value field of the Hidden AVP. If the Hidden AVP Subformat is less than 16 octets, the Subformat is transformed as if the Attribute Value field had been padded to 16 octets before the XOR, but only the actualoctets present in the Subformat are modified, and the length of theAVP is not altered.If the Subformat is longer than 16 octets, a second one-way MD5 hash is calculated over a stream of octets consisting of the shared secret followed by the result of the first XOR. That hash is XORed with the second 16 octet (or less) segment of the Subformat and placed in the corresponding octets of the Value field of the Hidden AVP.If necessary, this operation is repeated, with the shared secret used along with each XOR result to generate the next hash to XOR the next segment of the value with.The hiding method was adapted from RFC 2138 [RFC2138] which was taken from the "Mixing in the Plaintext" section in the book "NetworkSecurity" by Kaufman, Perlman and Speciner [KPS]. A detailedexplanation of the method follows:Call the shared secret S, the Random Vector RV, and the AttributeValue AV. Break the value field into 16-octet chunks p1, p2, etc.with the last one padded at the end with random data to a 16-octetboundary. Call the ciphertext blocks c(1), c(2), etc. We will also define intermediate values b1, b2, etc.b1 = MD5(AV + S + RV) c(1) = p1 xor b1b2 = MD5(S + c(1)) c(2) = p2 xor b2. .. .. .bi = MD5(S + c(i-1)) c(i) = pi xor biThe String will contain c(1)+c(2)+...+c(i) where + denotesconcatenation.On receipt, the random vector is taken from the last Random VectorAVP encountered in the message prior to the AVP to be unhidden. The above process is then reversed to yield the original value.Townsley, et al. Standards Track [Page 16]。
rfc140
Wicker Room for private meetings or whatever. It is reserved thru
Thursday afternoon.
NWG Steve Crocker
RFC - 140 UCLA
NIC - 6725 4 May 71
will discuss how to organize interaction among various academic efforts,
including those not within the ARPA community.
[Page 2]
TIME: Monday afternoon
TITLE: File Transfer, TIP, Network Planning (RFC's 114, 122, 133, 136)
and other ARPA Projects
[Page 1]
interprocess communication facilities in operating systems. From time
to time it is suggested that there would be some payoff in studying
these matters from an academic point of view, not quite so tied to the
Below are the topics to be discussed in each meeting and the list
简述is-is报文类型及其作用。
简述is-is报文类型及其作用。
IS-IS(Intermediate System to Intermediate System)是一种用于路由选择的协议,它使用IS-IS报文来交换路由信息。
IS-IS报文类型包括以下几种:1. Hello报文:用于建立和维护邻居关系,包括邻居的IP地址、路由器ID等信息。
2. Link State Request(LSR)报文:用于请求邻居发送某个LSA(Link State Advertisement)。
3. Link State Update(LSU)报文:用于发送LSA。
4. Link State Acknowledgment (LSAck)报文:用于确认收到LSU报文。
IS-IS报文的作用是在网络中传递路由信息,以便路由器可以选择最佳路径来转发数据包。
IS-IS协议使用链路状态路由算法(Link State Routing Algorithm),它将网络拓扑信息分发到所有路由器中,每个路由器都可以计算出到达目的地的最佳路径。
IS-IS报文的交换使得路由器可以动态地适应网络拓扑的变化,从而提高网络的可靠性和性能。
SmartClass Ethernet测试仪 用户手册
第1章
开始..................................................................................................... 1
装箱清单.............................................................. 2
底部面板介绍.......................................................... 7
启动设备.............................................................. 7
关闭设备.............................................................. 7
不能将此产品作为市政污染废料进行处理,并且根据当地国家相关规则单独收集 处理。在欧盟地区,所有从 JDSU 公司 2005.8.13 日之后购买的设备可以在设 备使用寿命完毕时返回处理。JDSU 公司确保所有返回的废弃设备能够以环境友 好型方式进行重新使用、回收或处理,这些操作都要符合所有国家和国际废料处 理标准。
SmartClass Ethernet 测试仪用户手册
v
目录
第2章 第3章
vi
数据输入屏 ....................................................................................................10 结果屏............................................................................................................10 使用键盘 ............................................................ 11 选择菜单选项或配置设置............................................................................... 11 返回到上一级菜单.......................................................................................... 11 输入数字值 ....................................................................................................11 输入文本 ........................................................................................................11
3GPP TS 36.331 V13.2.0 (2016-06)
3GPP TS 36.331 V13.2.0 (2016-06)Technical Specification3rd Generation Partnership Project;Technical Specification Group Radio Access Network;Evolved Universal Terrestrial Radio Access (E-UTRA);Radio Resource Control (RRC);Protocol specification(Release 13)The present document has been developed within the 3rd Generation Partnership Project (3GPP TM) and may be further elaborated for the purposes of 3GPP. The present document has not been subject to any approval process by the 3GPP Organizational Partners and shall not be implemented.This Specification is provided for future development work within 3GPP only. The Organizational Partners accept no liability for any use of this Specification. Specifications and reports for implementation of the 3GPP TM system should be obtained via the 3GPP Organizational Partners' Publications Offices.KeywordsUMTS, radio3GPPPostal address3GPP support office address650 Route des Lucioles - Sophia AntipolisValbonne - FRANCETel.: +33 4 92 94 42 00 Fax: +33 4 93 65 47 16InternetCopyright NotificationNo part may be reproduced except as authorized by written permission.The copyright and the foregoing restriction extend to reproduction in all media.© 2016, 3GPP Organizational Partners (ARIB, ATIS, CCSA, ETSI, TSDSI, TTA, TTC).All rights reserved.UMTS™ is a Trade Mark of ETSI registered for the benefit of its members3GPP™ is a Trade Mark of ETSI registered for the benefit of its Members and of the 3GPP Organizational PartnersLTE™ is a Trade Mark of ETSI currently being registered for the benefit of its Members and of the 3GPP Organizational Partners GSM® and the GSM logo are registered and owned by the GSM AssociationBluetooth® is a Trade Mark of the Bluetooth SIG registered for the benefit of its membersContentsForeword (18)1Scope (19)2References (19)3Definitions, symbols and abbreviations (22)3.1Definitions (22)3.2Abbreviations (24)4General (27)4.1Introduction (27)4.2Architecture (28)4.2.1UE states and state transitions including inter RAT (28)4.2.2Signalling radio bearers (29)4.3Services (30)4.3.1Services provided to upper layers (30)4.3.2Services expected from lower layers (30)4.4Functions (30)5Procedures (32)5.1General (32)5.1.1Introduction (32)5.1.2General requirements (32)5.2System information (33)5.2.1Introduction (33)5.2.1.1General (33)5.2.1.2Scheduling (34)5.2.1.2a Scheduling for NB-IoT (34)5.2.1.3System information validity and notification of changes (35)5.2.1.4Indication of ETWS notification (36)5.2.1.5Indication of CMAS notification (37)5.2.1.6Notification of EAB parameters change (37)5.2.1.7Access Barring parameters change in NB-IoT (37)5.2.2System information acquisition (38)5.2.2.1General (38)5.2.2.2Initiation (38)5.2.2.3System information required by the UE (38)5.2.2.4System information acquisition by the UE (39)5.2.2.5Essential system information missing (42)5.2.2.6Actions upon reception of the MasterInformationBlock message (42)5.2.2.7Actions upon reception of the SystemInformationBlockType1 message (42)5.2.2.8Actions upon reception of SystemInformation messages (44)5.2.2.9Actions upon reception of SystemInformationBlockType2 (44)5.2.2.10Actions upon reception of SystemInformationBlockType3 (45)5.2.2.11Actions upon reception of SystemInformationBlockType4 (45)5.2.2.12Actions upon reception of SystemInformationBlockType5 (45)5.2.2.13Actions upon reception of SystemInformationBlockType6 (45)5.2.2.14Actions upon reception of SystemInformationBlockType7 (45)5.2.2.15Actions upon reception of SystemInformationBlockType8 (45)5.2.2.16Actions upon reception of SystemInformationBlockType9 (46)5.2.2.17Actions upon reception of SystemInformationBlockType10 (46)5.2.2.18Actions upon reception of SystemInformationBlockType11 (46)5.2.2.19Actions upon reception of SystemInformationBlockType12 (47)5.2.2.20Actions upon reception of SystemInformationBlockType13 (48)5.2.2.21Actions upon reception of SystemInformationBlockType14 (48)5.2.2.22Actions upon reception of SystemInformationBlockType15 (48)5.2.2.23Actions upon reception of SystemInformationBlockType16 (48)5.2.2.24Actions upon reception of SystemInformationBlockType17 (48)5.2.2.25Actions upon reception of SystemInformationBlockType18 (48)5.2.2.26Actions upon reception of SystemInformationBlockType19 (49)5.2.3Acquisition of an SI message (49)5.2.3a Acquisition of an SI message by BL UE or UE in CE or a NB-IoT UE (50)5.3Connection control (50)5.3.1Introduction (50)5.3.1.1RRC connection control (50)5.3.1.2Security (52)5.3.1.2a RN security (53)5.3.1.3Connected mode mobility (53)5.3.1.4Connection control in NB-IoT (54)5.3.2Paging (55)5.3.2.1General (55)5.3.2.2Initiation (55)5.3.2.3Reception of the Paging message by the UE (55)5.3.3RRC connection establishment (56)5.3.3.1General (56)5.3.3.1a Conditions for establishing RRC Connection for sidelink communication/ discovery (58)5.3.3.2Initiation (59)5.3.3.3Actions related to transmission of RRCConnectionRequest message (63)5.3.3.3a Actions related to transmission of RRCConnectionResumeRequest message (64)5.3.3.4Reception of the RRCConnectionSetup by the UE (64)5.3.3.4a Reception of the RRCConnectionResume by the UE (66)5.3.3.5Cell re-selection while T300, T302, T303, T305, T306, or T308 is running (68)5.3.3.6T300 expiry (68)5.3.3.7T302, T303, T305, T306, or T308 expiry or stop (69)5.3.3.8Reception of the RRCConnectionReject by the UE (70)5.3.3.9Abortion of RRC connection establishment (71)5.3.3.10Handling of SSAC related parameters (71)5.3.3.11Access barring check (72)5.3.3.12EAB check (73)5.3.3.13Access barring check for ACDC (73)5.3.3.14Access Barring check for NB-IoT (74)5.3.4Initial security activation (75)5.3.4.1General (75)5.3.4.2Initiation (76)5.3.4.3Reception of the SecurityModeCommand by the UE (76)5.3.5RRC connection reconfiguration (77)5.3.5.1General (77)5.3.5.2Initiation (77)5.3.5.3Reception of an RRCConnectionReconfiguration not including the mobilityControlInfo by theUE (77)5.3.5.4Reception of an RRCConnectionReconfiguration including the mobilityControlInfo by the UE(handover) (79)5.3.5.5Reconfiguration failure (83)5.3.5.6T304 expiry (handover failure) (83)5.3.5.7Void (84)5.3.5.7a T307 expiry (SCG change failure) (84)5.3.5.8Radio Configuration involving full configuration option (84)5.3.6Counter check (86)5.3.6.1General (86)5.3.6.2Initiation (86)5.3.6.3Reception of the CounterCheck message by the UE (86)5.3.7RRC connection re-establishment (87)5.3.7.1General (87)5.3.7.2Initiation (87)5.3.7.3Actions following cell selection while T311 is running (88)5.3.7.4Actions related to transmission of RRCConnectionReestablishmentRequest message (89)5.3.7.5Reception of the RRCConnectionReestablishment by the UE (89)5.3.7.6T311 expiry (91)5.3.7.7T301 expiry or selected cell no longer suitable (91)5.3.7.8Reception of RRCConnectionReestablishmentReject by the UE (91)5.3.8RRC connection release (92)5.3.8.1General (92)5.3.8.2Initiation (92)5.3.8.3Reception of the RRCConnectionRelease by the UE (92)5.3.8.4T320 expiry (93)5.3.9RRC connection release requested by upper layers (93)5.3.9.1General (93)5.3.9.2Initiation (93)5.3.10Radio resource configuration (93)5.3.10.0General (93)5.3.10.1SRB addition/ modification (94)5.3.10.2DRB release (95)5.3.10.3DRB addition/ modification (95)5.3.10.3a1DC specific DRB addition or reconfiguration (96)5.3.10.3a2LWA specific DRB addition or reconfiguration (98)5.3.10.3a3LWIP specific DRB addition or reconfiguration (98)5.3.10.3a SCell release (99)5.3.10.3b SCell addition/ modification (99)5.3.10.3c PSCell addition or modification (99)5.3.10.4MAC main reconfiguration (99)5.3.10.5Semi-persistent scheduling reconfiguration (100)5.3.10.6Physical channel reconfiguration (100)5.3.10.7Radio Link Failure Timers and Constants reconfiguration (101)5.3.10.8Time domain measurement resource restriction for serving cell (101)5.3.10.9Other configuration (102)5.3.10.10SCG reconfiguration (103)5.3.10.11SCG dedicated resource configuration (104)5.3.10.12Reconfiguration SCG or split DRB by drb-ToAddModList (105)5.3.10.13Neighbour cell information reconfiguration (105)5.3.10.14Void (105)5.3.10.15Sidelink dedicated configuration (105)5.3.10.16T370 expiry (106)5.3.11Radio link failure related actions (107)5.3.11.1Detection of physical layer problems in RRC_CONNECTED (107)5.3.11.2Recovery of physical layer problems (107)5.3.11.3Detection of radio link failure (107)5.3.12UE actions upon leaving RRC_CONNECTED (109)5.3.13UE actions upon PUCCH/ SRS release request (110)5.3.14Proximity indication (110)5.3.14.1General (110)5.3.14.2Initiation (111)5.3.14.3Actions related to transmission of ProximityIndication message (111)5.3.15Void (111)5.4Inter-RAT mobility (111)5.4.1Introduction (111)5.4.2Handover to E-UTRA (112)5.4.2.1General (112)5.4.2.2Initiation (112)5.4.2.3Reception of the RRCConnectionReconfiguration by the UE (112)5.4.2.4Reconfiguration failure (114)5.4.2.5T304 expiry (handover to E-UTRA failure) (114)5.4.3Mobility from E-UTRA (114)5.4.3.1General (114)5.4.3.2Initiation (115)5.4.3.3Reception of the MobilityFromEUTRACommand by the UE (115)5.4.3.4Successful completion of the mobility from E-UTRA (116)5.4.3.5Mobility from E-UTRA failure (117)5.4.4Handover from E-UTRA preparation request (CDMA2000) (117)5.4.4.1General (117)5.4.4.2Initiation (118)5.4.4.3Reception of the HandoverFromEUTRAPreparationRequest by the UE (118)5.4.5UL handover preparation transfer (CDMA2000) (118)5.4.5.1General (118)5.4.5.2Initiation (118)5.4.5.3Actions related to transmission of the ULHandoverPreparationTransfer message (119)5.4.5.4Failure to deliver the ULHandoverPreparationTransfer message (119)5.4.6Inter-RAT cell change order to E-UTRAN (119)5.4.6.1General (119)5.4.6.2Initiation (119)5.4.6.3UE fails to complete an inter-RAT cell change order (119)5.5Measurements (120)5.5.1Introduction (120)5.5.2Measurement configuration (121)5.5.2.1General (121)5.5.2.2Measurement identity removal (122)5.5.2.2a Measurement identity autonomous removal (122)5.5.2.3Measurement identity addition/ modification (123)5.5.2.4Measurement object removal (124)5.5.2.5Measurement object addition/ modification (124)5.5.2.6Reporting configuration removal (126)5.5.2.7Reporting configuration addition/ modification (127)5.5.2.8Quantity configuration (127)5.5.2.9Measurement gap configuration (127)5.5.2.10Discovery signals measurement timing configuration (128)5.5.2.11RSSI measurement timing configuration (128)5.5.3Performing measurements (128)5.5.3.1General (128)5.5.3.2Layer 3 filtering (131)5.5.4Measurement report triggering (131)5.5.4.1General (131)5.5.4.2Event A1 (Serving becomes better than threshold) (135)5.5.4.3Event A2 (Serving becomes worse than threshold) (136)5.5.4.4Event A3 (Neighbour becomes offset better than PCell/ PSCell) (136)5.5.4.5Event A4 (Neighbour becomes better than threshold) (137)5.5.4.6Event A5 (PCell/ PSCell becomes worse than threshold1 and neighbour becomes better thanthreshold2) (138)5.5.4.6a Event A6 (Neighbour becomes offset better than SCell) (139)5.5.4.7Event B1 (Inter RAT neighbour becomes better than threshold) (139)5.5.4.8Event B2 (PCell becomes worse than threshold1 and inter RAT neighbour becomes better thanthreshold2) (140)5.5.4.9Event C1 (CSI-RS resource becomes better than threshold) (141)5.5.4.10Event C2 (CSI-RS resource becomes offset better than reference CSI-RS resource) (141)5.5.4.11Event W1 (WLAN becomes better than a threshold) (142)5.5.4.12Event W2 (All WLAN inside WLAN mobility set becomes worse than threshold1 and a WLANoutside WLAN mobility set becomes better than threshold2) (142)5.5.4.13Event W3 (All WLAN inside WLAN mobility set becomes worse than a threshold) (143)5.5.5Measurement reporting (144)5.5.6Measurement related actions (148)5.5.6.1Actions upon handover and re-establishment (148)5.5.6.2Speed dependant scaling of measurement related parameters (149)5.5.7Inter-frequency RSTD measurement indication (149)5.5.7.1General (149)5.5.7.2Initiation (150)5.5.7.3Actions related to transmission of InterFreqRSTDMeasurementIndication message (150)5.6Other (150)5.6.0General (150)5.6.1DL information transfer (151)5.6.1.1General (151)5.6.1.2Initiation (151)5.6.1.3Reception of the DLInformationTransfer by the UE (151)5.6.2UL information transfer (151)5.6.2.1General (151)5.6.2.2Initiation (151)5.6.2.3Actions related to transmission of ULInformationTransfer message (152)5.6.2.4Failure to deliver ULInformationTransfer message (152)5.6.3UE capability transfer (152)5.6.3.1General (152)5.6.3.2Initiation (153)5.6.3.3Reception of the UECapabilityEnquiry by the UE (153)5.6.4CSFB to 1x Parameter transfer (157)5.6.4.1General (157)5.6.4.2Initiation (157)5.6.4.3Actions related to transmission of CSFBParametersRequestCDMA2000 message (157)5.6.4.4Reception of the CSFBParametersResponseCDMA2000 message (157)5.6.5UE Information (158)5.6.5.1General (158)5.6.5.2Initiation (158)5.6.5.3Reception of the UEInformationRequest message (158)5.6.6 Logged Measurement Configuration (159)5.6.6.1General (159)5.6.6.2Initiation (160)5.6.6.3Reception of the LoggedMeasurementConfiguration by the UE (160)5.6.6.4T330 expiry (160)5.6.7 Release of Logged Measurement Configuration (160)5.6.7.1General (160)5.6.7.2Initiation (160)5.6.8 Measurements logging (161)5.6.8.1General (161)5.6.8.2Initiation (161)5.6.9In-device coexistence indication (163)5.6.9.1General (163)5.6.9.2Initiation (164)5.6.9.3Actions related to transmission of InDeviceCoexIndication message (164)5.6.10UE Assistance Information (165)5.6.10.1General (165)5.6.10.2Initiation (166)5.6.10.3Actions related to transmission of UEAssistanceInformation message (166)5.6.11 Mobility history information (166)5.6.11.1General (166)5.6.11.2Initiation (166)5.6.12RAN-assisted WLAN interworking (167)5.6.12.1General (167)5.6.12.2Dedicated WLAN offload configuration (167)5.6.12.3WLAN offload RAN evaluation (167)5.6.12.4T350 expiry or stop (167)5.6.12.5Cell selection/ re-selection while T350 is running (168)5.6.13SCG failure information (168)5.6.13.1General (168)5.6.13.2Initiation (168)5.6.13.3Actions related to transmission of SCGFailureInformation message (168)5.6.14LTE-WLAN Aggregation (169)5.6.14.1Introduction (169)5.6.14.2Reception of LWA configuration (169)5.6.14.3Release of LWA configuration (170)5.6.15WLAN connection management (170)5.6.15.1Introduction (170)5.6.15.2WLAN connection status reporting (170)5.6.15.2.1General (170)5.6.15.2.2Initiation (171)5.6.15.2.3Actions related to transmission of WLANConnectionStatusReport message (171)5.6.15.3T351 Expiry (WLAN connection attempt timeout) (171)5.6.15.4WLAN status monitoring (171)5.6.16RAN controlled LTE-WLAN interworking (172)5.6.16.1General (172)5.6.16.2WLAN traffic steering command (172)5.6.17LTE-WLAN aggregation with IPsec tunnel (173)5.6.17.1General (173)5.7Generic error handling (174)5.7.1General (174)5.7.2ASN.1 violation or encoding error (174)5.7.3Field set to a not comprehended value (174)5.7.4Mandatory field missing (174)5.7.5Not comprehended field (176)5.8MBMS (176)5.8.1Introduction (176)5.8.1.1General (176)5.8.1.2Scheduling (176)5.8.1.3MCCH information validity and notification of changes (176)5.8.2MCCH information acquisition (178)5.8.2.1General (178)5.8.2.2Initiation (178)5.8.2.3MCCH information acquisition by the UE (178)5.8.2.4Actions upon reception of the MBSFNAreaConfiguration message (178)5.8.2.5Actions upon reception of the MBMSCountingRequest message (179)5.8.3MBMS PTM radio bearer configuration (179)5.8.3.1General (179)5.8.3.2Initiation (179)5.8.3.3MRB establishment (179)5.8.3.4MRB release (179)5.8.4MBMS Counting Procedure (179)5.8.4.1General (179)5.8.4.2Initiation (180)5.8.4.3Reception of the MBMSCountingRequest message by the UE (180)5.8.5MBMS interest indication (181)5.8.5.1General (181)5.8.5.2Initiation (181)5.8.5.3Determine MBMS frequencies of interest (182)5.8.5.4Actions related to transmission of MBMSInterestIndication message (183)5.8a SC-PTM (183)5.8a.1Introduction (183)5.8a.1.1General (183)5.8a.1.2SC-MCCH scheduling (183)5.8a.1.3SC-MCCH information validity and notification of changes (183)5.8a.1.4Procedures (184)5.8a.2SC-MCCH information acquisition (184)5.8a.2.1General (184)5.8a.2.2Initiation (184)5.8a.2.3SC-MCCH information acquisition by the UE (184)5.8a.2.4Actions upon reception of the SCPTMConfiguration message (185)5.8a.3SC-PTM radio bearer configuration (185)5.8a.3.1General (185)5.8a.3.2Initiation (185)5.8a.3.3SC-MRB establishment (185)5.8a.3.4SC-MRB release (185)5.9RN procedures (186)5.9.1RN reconfiguration (186)5.9.1.1General (186)5.9.1.2Initiation (186)5.9.1.3Reception of the RNReconfiguration by the RN (186)5.10Sidelink (186)5.10.1Introduction (186)5.10.1a Conditions for sidelink communication operation (187)5.10.2Sidelink UE information (188)5.10.2.1General (188)5.10.2.2Initiation (189)5.10.2.3Actions related to transmission of SidelinkUEInformation message (193)5.10.3Sidelink communication monitoring (195)5.10.6Sidelink discovery announcement (198)5.10.6a Sidelink discovery announcement pool selection (201)5.10.6b Sidelink discovery announcement reference carrier selection (201)5.10.7Sidelink synchronisation information transmission (202)5.10.7.1General (202)5.10.7.2Initiation (203)5.10.7.3Transmission of SLSS (204)5.10.7.4Transmission of MasterInformationBlock-SL message (205)5.10.7.5Void (206)5.10.8Sidelink synchronisation reference (206)5.10.8.1General (206)5.10.8.2Selection and reselection of synchronisation reference UE (SyncRef UE) (206)5.10.9Sidelink common control information (207)5.10.9.1General (207)5.10.9.2Actions related to reception of MasterInformationBlock-SL message (207)5.10.10Sidelink relay UE operation (207)5.10.10.1General (207)5.10.10.2AS-conditions for relay related sidelink communication transmission by sidelink relay UE (207)5.10.10.3AS-conditions for relay PS related sidelink discovery transmission by sidelink relay UE (208)5.10.10.4Sidelink relay UE threshold conditions (208)5.10.11Sidelink remote UE operation (208)5.10.11.1General (208)5.10.11.2AS-conditions for relay related sidelink communication transmission by sidelink remote UE (208)5.10.11.3AS-conditions for relay PS related sidelink discovery transmission by sidelink remote UE (209)5.10.11.4Selection and reselection of sidelink relay UE (209)5.10.11.5Sidelink remote UE threshold conditions (210)6Protocol data units, formats and parameters (tabular & ASN.1) (210)6.1General (210)6.2RRC messages (212)6.2.1General message structure (212)–EUTRA-RRC-Definitions (212)–BCCH-BCH-Message (212)–BCCH-DL-SCH-Message (212)–BCCH-DL-SCH-Message-BR (213)–MCCH-Message (213)–PCCH-Message (213)–DL-CCCH-Message (214)–DL-DCCH-Message (214)–UL-CCCH-Message (214)–UL-DCCH-Message (215)–SC-MCCH-Message (215)6.2.2Message definitions (216)–CounterCheck (216)–CounterCheckResponse (217)–CSFBParametersRequestCDMA2000 (217)–CSFBParametersResponseCDMA2000 (218)–DLInformationTransfer (218)–HandoverFromEUTRAPreparationRequest (CDMA2000) (219)–InDeviceCoexIndication (220)–InterFreqRSTDMeasurementIndication (222)–LoggedMeasurementConfiguration (223)–MasterInformationBlock (225)–MBMSCountingRequest (226)–MBMSCountingResponse (226)–MBMSInterestIndication (227)–MBSFNAreaConfiguration (228)–MeasurementReport (228)–MobilityFromEUTRACommand (229)–Paging (232)–ProximityIndication (233)–RNReconfiguration (234)–RNReconfigurationComplete (234)–RRCConnectionReconfiguration (235)–RRCConnectionReconfigurationComplete (240)–RRCConnectionReestablishment (241)–RRCConnectionReestablishmentComplete (241)–RRCConnectionReestablishmentReject (242)–RRCConnectionReestablishmentRequest (243)–RRCConnectionReject (243)–RRCConnectionRelease (244)–RRCConnectionResume (248)–RRCConnectionResumeComplete (249)–RRCConnectionResumeRequest (250)–RRCConnectionRequest (250)–RRCConnectionSetup (251)–RRCConnectionSetupComplete (252)–SCGFailureInformation (253)–SCPTMConfiguration (254)–SecurityModeCommand (255)–SecurityModeComplete (255)–SecurityModeFailure (256)–SidelinkUEInformation (256)–SystemInformation (258)–SystemInformationBlockType1 (259)–UEAssistanceInformation (264)–UECapabilityEnquiry (265)–UECapabilityInformation (266)–UEInformationRequest (267)–UEInformationResponse (267)–ULHandoverPreparationTransfer (CDMA2000) (273)–ULInformationTransfer (274)–WLANConnectionStatusReport (274)6.3RRC information elements (275)6.3.1System information blocks (275)–SystemInformationBlockType2 (275)–SystemInformationBlockType3 (279)–SystemInformationBlockType4 (282)–SystemInformationBlockType5 (283)–SystemInformationBlockType6 (287)–SystemInformationBlockType7 (289)–SystemInformationBlockType8 (290)–SystemInformationBlockType9 (295)–SystemInformationBlockType10 (295)–SystemInformationBlockType11 (296)–SystemInformationBlockType12 (297)–SystemInformationBlockType13 (297)–SystemInformationBlockType14 (298)–SystemInformationBlockType15 (298)–SystemInformationBlockType16 (299)–SystemInformationBlockType17 (300)–SystemInformationBlockType18 (301)–SystemInformationBlockType19 (301)–SystemInformationBlockType20 (304)6.3.2Radio resource control information elements (304)–AntennaInfo (304)–AntennaInfoUL (306)–CQI-ReportConfig (307)–CQI-ReportPeriodicProcExtId (314)–CrossCarrierSchedulingConfig (314)–CSI-IM-Config (315)–CSI-IM-ConfigId (315)–CSI-RS-Config (317)–CSI-RS-ConfigEMIMO (318)–CSI-RS-ConfigNZP (319)–CSI-RS-ConfigNZPId (320)–CSI-RS-ConfigZP (321)–CSI-RS-ConfigZPId (321)–DMRS-Config (321)–DRB-Identity (322)–EPDCCH-Config (322)–EIMTA-MainConfig (324)–LogicalChannelConfig (325)–LWA-Configuration (326)–LWIP-Configuration (326)–RCLWI-Configuration (327)–MAC-MainConfig (327)–P-C-AndCBSR (332)–PDCCH-ConfigSCell (333)–PDCP-Config (334)–PDSCH-Config (337)–PDSCH-RE-MappingQCL-ConfigId (339)–PHICH-Config (339)–PhysicalConfigDedicated (339)–P-Max (344)–PRACH-Config (344)–PresenceAntennaPort1 (346)–PUCCH-Config (347)–PUSCH-Config (351)–RACH-ConfigCommon (355)–RACH-ConfigDedicated (357)–RadioResourceConfigCommon (358)–RadioResourceConfigDedicated (362)–RLC-Config (367)–RLF-TimersAndConstants (369)–RN-SubframeConfig (370)–SchedulingRequestConfig (371)–SoundingRS-UL-Config (372)–SPS-Config (375)–TDD-Config (376)–TimeAlignmentTimer (377)–TPC-PDCCH-Config (377)–TunnelConfigLWIP (378)–UplinkPowerControl (379)–WLAN-Id-List (382)–WLAN-MobilityConfig (382)6.3.3Security control information elements (382)–NextHopChainingCount (382)–SecurityAlgorithmConfig (383)–ShortMAC-I (383)6.3.4Mobility control information elements (383)–AdditionalSpectrumEmission (383)–ARFCN-ValueCDMA2000 (383)–ARFCN-ValueEUTRA (384)–ARFCN-ValueGERAN (384)–ARFCN-ValueUTRA (384)–BandclassCDMA2000 (384)–BandIndicatorGERAN (385)–CarrierFreqCDMA2000 (385)–CarrierFreqGERAN (385)–CellIndexList (387)–CellReselectionPriority (387)–CellSelectionInfoCE (387)–CellReselectionSubPriority (388)–CSFB-RegistrationParam1XRTT (388)–CellGlobalIdEUTRA (389)–CellGlobalIdUTRA (389)–CellGlobalIdGERAN (390)–CellGlobalIdCDMA2000 (390)–CellSelectionInfoNFreq (391)–CSG-Identity (391)–FreqBandIndicator (391)–MobilityControlInfo (391)–MobilityParametersCDMA2000 (1xRTT) (393)–MobilityStateParameters (394)–MultiBandInfoList (394)–NS-PmaxList (394)–PhysCellId (395)–PhysCellIdRange (395)–PhysCellIdRangeUTRA-FDDList (395)–PhysCellIdCDMA2000 (396)–PhysCellIdGERAN (396)–PhysCellIdUTRA-FDD (396)–PhysCellIdUTRA-TDD (396)–PLMN-Identity (397)–PLMN-IdentityList3 (397)–PreRegistrationInfoHRPD (397)–Q-QualMin (398)–Q-RxLevMin (398)–Q-OffsetRange (398)–Q-OffsetRangeInterRAT (399)–ReselectionThreshold (399)–ReselectionThresholdQ (399)–SCellIndex (399)–ServCellIndex (400)–SpeedStateScaleFactors (400)–SystemInfoListGERAN (400)–SystemTimeInfoCDMA2000 (401)–TrackingAreaCode (401)–T-Reselection (402)–T-ReselectionEUTRA-CE (402)6.3.5Measurement information elements (402)–AllowedMeasBandwidth (402)–CSI-RSRP-Range (402)–Hysteresis (402)–LocationInfo (403)–MBSFN-RSRQ-Range (403)–MeasConfig (404)–MeasDS-Config (405)–MeasGapConfig (406)–MeasId (407)–MeasIdToAddModList (407)–MeasObjectCDMA2000 (408)–MeasObjectEUTRA (408)–MeasObjectGERAN (412)–MeasObjectId (412)–MeasObjectToAddModList (412)–MeasObjectUTRA (413)–ReportConfigEUTRA (422)–ReportConfigId (425)–ReportConfigInterRAT (425)–ReportConfigToAddModList (428)–ReportInterval (429)–RSRP-Range (429)–RSRQ-Range (430)–RSRQ-Type (430)–RS-SINR-Range (430)–RSSI-Range-r13 (431)–TimeToTrigger (431)–UL-DelayConfig (431)–WLAN-CarrierInfo (431)–WLAN-RSSI-Range (432)–WLAN-Status (432)6.3.6Other information elements (433)–AbsoluteTimeInfo (433)–AreaConfiguration (433)–C-RNTI (433)–DedicatedInfoCDMA2000 (434)–DedicatedInfoNAS (434)–FilterCoefficient (434)–LoggingDuration (434)–LoggingInterval (435)–MeasSubframePattern (435)–MMEC (435)–NeighCellConfig (435)–OtherConfig (436)–RAND-CDMA2000 (1xRTT) (437)–RAT-Type (437)–ResumeIdentity (437)–RRC-TransactionIdentifier (438)–S-TMSI (438)–TraceReference (438)–UE-CapabilityRAT-ContainerList (438)–UE-EUTRA-Capability (439)–UE-RadioPagingInfo (469)–UE-TimersAndConstants (469)–VisitedCellInfoList (470)–WLAN-OffloadConfig (470)6.3.7MBMS information elements (472)–MBMS-NotificationConfig (472)–MBMS-ServiceList (473)–MBSFN-AreaId (473)–MBSFN-AreaInfoList (473)–MBSFN-SubframeConfig (474)–PMCH-InfoList (475)6.3.7a SC-PTM information elements (476)–SC-MTCH-InfoList (476)–SCPTM-NeighbourCellList (478)6.3.8Sidelink information elements (478)–SL-CommConfig (478)–SL-CommResourcePool (479)–SL-CP-Len (480)–SL-DiscConfig (481)–SL-DiscResourcePool (483)–SL-DiscTxPowerInfo (485)–SL-GapConfig (485)。
射频卡协议ISO14443- 全文中文精编版
中国金融集成电路(IC)卡与应用无关的非接触式规范中国金融集成电路(IC)卡标准修订工作组二零零四年九月目次1 范围 (1)2 参考资料 (2)3 定义 (3)3.1 集成电路Integrated circuit(s)(IC) (3)3.2 无触点的Contactless (3)3.3 无触点集成电路卡Contactless integrated circuit(s) card (3)3.4 接近式卡Proximity card(PICC) (3)3.5 接近式耦合设备Proximity coupling device(PCD) (3)3.6 位持续时间Bit duration (3)3.7 二进制移相键控Binary phase shift keying (3)3.8 调制指数Modulation index (3)3.9 不归零电平NRZ-L (3)3.10 副载波Subcarrier (3)3.11 防冲突环anticollision loop (3)3.12 比特冲突检测协议bit collision detection protocol (3)3.13 字节byte (3)3.14 冲突collision (3)3.15 基本时间单元(etu)elementary time unit(etu) (3)3.16 帧frame (3)3.17 高层higher layer (4)3.18 时间槽协议time slot protocol (4)3.19 唯一识别符Unique identifier(UID) (4)3.20 块block (4)3.21 无效块invalid block (4)4 缩略语和符号表示 (5)5 物理特性 (8)5.1 一般特性 (8)5.2 尺寸 (8)5.3 附加特性 (8)5.3.1 紫外线 (8)5.3.2 X-射线 (8)5.3.3 动态弯曲应力 (8)5.3.4 动态扭曲应力 (8)5.3.5 交变磁场 (8)5.3.6 交变电场 (8)5.3.7 静电 (8)5.3.8 静态磁场 (8)5.3.9 工作温度 (9)6 射频功率和信号接口 (9)6.1 PICC的初始对话 (9)6.2 功率传送 (9)6.2.1 频率 (9)6.2.2 工作场 (9)6.3 信号接口 (9)6.4 A类通信信号接口 (10)6.4.1 从PCD到PICC的通信 (10)6.4.2 从PICC到PCD的通信 (12)6.5 B类通信信号接口 (13)6.5.1 PCD到PICC的通信 (13)6.5.2 PICC到PCD的通信 (13)6.6 PICC最小耦合区 (14)7 初始化和防冲突 (15)7.1 轮询 (15)7.2 类型A-初始化和防冲突 (15)7.2.1 字节、帧、命令格式和定时 (15)7.2.2 PICC状态 (19)7.2.3 命令集 (20)7.2.4 选择序列 (21)7.3 类型B 初始化和防冲突 (26)7.3.1 比特、字节和帧的定时 (26)7.3.2 CRC_B (28)7.3.3 防冲突序列 (28)7.3.4 PICC状态描述 (29)7.3.5 命令集合 (31)7.3.6 ATQB和Slot-MARKER响应概率规则 (31)7.3.7 REQB命令 (31)7.3.8 Slot-MARKER命令 (33)7.3.9 ATQB(请求应答-类型B)响应 (33)7.3.10 ATTRIB命令 (34)7.3.11 对A TTRIB命令的应答 (36)7.3.12 HALT命令及应答 (36)8 传输协议 (38)8.1 类型A PICC的协议激活 (38)8.1.1 选择应答请求 (40)8.1.2 选择应答 (40)8.1.3 协议和参数选择请求 (43)8.1.4 协议和参数选择响应 (45)8.1.5 激活帧等待时间 (45)8.1.6 差错检测和恢复 (45)8.2 类型B PICC的协议激活 (46)8.3 半双工块传输协议 (46)8.3.1 块格式 (46)8.3.2 帧等待时间(FWT) (49)8.3.3 帧等待时间扩展 (49)8.3.4 功率水平指示 (50)8.3.5 协议操作 (50)8.4 类型A和类型B PICC的协议停活 (52)8.4.1 停活帧等待时间 (53)8.4.2 差错检测和恢复 (53)9 数据元和命令 (54)9.1 关闭非接触通道命令 (54)9.1.1 定义和范围 (54)9.1.2 命令报文 (54)9.1.3 命令报文数据域 (54)9.1.4 响应报文数据域 (54)9.1.5 响应报文状态码 (54)9.2 激活非接触通道命令 (55)9.2.1 定义和范围 (55)9.2.2 命令报文 (55)9.2.3 命令报文数据域 (55)9.2.4 响应报文数据域 (55)9.2.5 响应报文状态码 (55)附录 A:标准兼容性和表面质量 (56)A.1. 标准兼容性 (56)A.2. 印刷的表面质量 (56)附录 B: ISO/IEC其他卡标准参考目录 (57)附录 C:类型A的通信举例 (58)附录 D: CRC_A和CRC_B的编码 (60)D.1. CRC_A编码 (60)D.1.1. 通过标准帧发送的比特模式举例 (60)D.2. CRC_B编码 (60)D.2.1. 通过标准帧传送的比特模式实例 (60)D.2.2. 用C语言写的CRC计算的代码例子 (61)附录 E:类型A_时间槽-初始化和防冲突 (64)E.1. 术语和缩略语 (64)E.2. 比特、字节和帧格式 (64)E.2.1. 定时定义 (64)E.2.2. 帧格式 (64)E.3. PICC状态 (64)E.3.1. POWER-OFF状态 (64)E.3.2. IDLE状态 (65)E.3.3. READY状态 (65)E.3.4. ACTIVE状态 (65)E.3.5. HALT状态 (65)E.4. 命令/响应集合 (65)E.5. 时间槽防冲突序列 (65)附录 F:详细的类型A PICC状态图 (67)附录 G:使用多激活的举例 (69)附录 H:协议说明书 (70)H.1. 记法 (70)H.2. 无差错操作 (70)H.2.1. 块的交换 (70)H.2.2. 等待时间扩展请求 (70)H.2.3. DESELECT (70)H.2.4. 链接 (71)H.3. 差错处理 (71)H.3.1. 块的交换 (71)H.3.2. 等待时间扩展请求 (72)H.3.3. DESELECT (74)H.3.4. 链接 (74)附录 I:块和帧编码概览 (77)1 范围本规范包括以下主要内容:-物理特性:规定了接近式卡(PICC)的物理特性。
RFC3918协议测试——网络测试仪实操
三、测试配置..................................................................................................................................... 4 3.1 准备工作: 添加机框............................................................................................................4 3.2 准备工作: 预约端口............................................................................................................5 3.3 选择向导............................................................................................................................... 5 3.4 选择混合吞吐量测试...........................................................................................................6 3.5 选择端口............................................................................................................................... 6 3.6 配置接口............................................................................................................................... 7 3.7 向导配置接口.......................................................................................................................7 3.8 向导配置 关键-MAC.......................................................................................................... 8 3.9 向导配置 关键-IP................................................................................................................8 3.10 向导接口配置结果.............................................................................................................9 3.11 选择接口............................................................................................................................. 9 3.12 配置组播流量...................................................................................................................10 3.13 配置组播参数................................................................................................................... 11 3.14 关键参数........................................................................................................................... 11 3.15 选择测试参数...................................................................................................................12 3.16 配置 混合吞吐................................................................................13 3.17 关键参数...........................................................................................................................14 3.18 配置单播流量...................................................................................................................15 3.19 配置单播流-选择端口..................................................................................................... 15 3.20 配置单播流量-选择流量接口......................................................................................... 16 3.21 配置单播流-常规............................................................................................................. 16 3.22 配置单播流-配置帧......................................................................................................... 17 3.23 配置单播流.......................................................................................................................17 3.24 开始测试...........................................................................................................................18
RFC逻辑定律
RFC逻辑定律SAP 高级应用开发 - RFCRFC Remote function Call 远程功能调用, 是SAP系统之间以及非SAP系统之间程序通信的基本接口技术. 例如BAPI , ALE都是基于RFC实现的RFC连接类型:1.类型2: R/2连接2.类型3: ABAP连接或R/3连接,指定主机名和通信服务3.类型I:内部连接,与当前系统连接到同一ABAP系统中,预定义无法修改,与SM51中所显示的应用服务器名相同4.类型L:逻辑目标,通常工作流系统指定过程中配置的RFC目标即为该类型的逻辑目标5.类型X:指定安装了特殊的ABAP设备驱动程序的系统,必须制定ABAP设备驱动程序名6.类型S:通过SNA或APPC启动的外部程序连接7.类型M:通过CMC到ABAP系统的异步RFC连接8.类型T:通过TCP/IP并使用RFC库或SAP连接器的外部程序连接;分为启动(指定主机名、程序路径名)和注册(RFC服务器程序)两种连接模式。
9.类型G:定义外部系统到本地HTTP连接10.类型H:定义ABAP系统到本地的HTTP连接远程调用RFM:1.远程目标可以是文字或变量,其值为SAP系统中一直的远程目标系统。
2.若远程系统是当前系统中的SAP应用服务器,也可以直接指定应用服务器名称,则SM59中的I类型目标3.SM59定义的RFC目标是区分大小写的。
DESTINATION附加项中目标变量的值必须与其完全一致通过CALL FUNCTION语句进行远程功能调用时,可形成不同的调用模式:1. CALL FUNCTION DESTINATION 以同步RFC方式实现RFM 调用,若后面无其他附加项,则形成同步RFC调用,调用程序等待远程调用结果以继续执行2. CALL FUNCTION STARTING NEW TASK 以异步RFC方式实现RFM调用,调用程序不等待远程调用结果继续执行,结果将在回调子程序(callback subroutine)中接收3. CALL FUNCTION IN BACKROUND TASK 以事务性RFC方式实现RFM调用,远程功能暂不开始执行,等待COMMIT WORK 语句出现时,一次性执行一个或多个远程功能远程功能调用时,仅允许通过值传递参数,不能进行引用传递,因为在RFC过程中,可以传递参数,并返回结果,但不能改变调用程序的上下文对表类型参数,在本地普通功能调用中默认为引用传递,不需要创建内表的本地副本,但RFC不支持引用传递机制,将进行隐式的值传递调用,必须在RFC客户和RFC服务器之间交换整个表,只传输实际表格,如果没有指定表参数,则在被调用功能中使用空表RFC 创建连接类型时:1.LOAD BALANCING选择NO:指定TARGET HOST,SYSTEM NUMBER2. LOAD BALANCING选择YES,要指定TARGET SYSTEM (SM51),MESSAGE SERVER(RZ03),GROUP(SMLG)除去SM59定义的远程目标之外,SAP提供两个预定义目标,可以再CALL FUNCTION 语句的DESTINATION附加附件中使用:l目标NONE,将运行当前程序的应用服务器作为目标系统,调用过程将通过RFC接口实现,并拥有RFC上下文,应用于任意调用类型l目标BACK,用于被远程调用的RFM内部的CALL FUNCTION 语句中的目标制定,通过已建立的RFC连接反过来调用该模块的调用者或已载入的其他功能模块SAP ABAP 系统间的RFC实现(通过RFM实现)远程调用RFM:1.远程目标可以是文字或变量,其值为SAP系统中一直的远程目标系统。
RFC1994(CHAP)中文
RFC1994【PPP CHAP】中文翻译1.简介为了在点到点链路上建立通信,PPP链路的每一端在链路建立阶段必须首先发送LCP包进行数据链路配置。
链路建立之后,PPP提供可选的认证阶段,可以在进入NLP阶段之前实行认证。
缺省情况下,认证并非是强制执行的,如果需要链路认证,PPP实现必须在链路建立阶段指定“认证协议配置选项”。
这些认证协议主要用于主机和路由器,这些主机和路由器一般通过交换电路线或者拨号线连在PPP网络服务器上,但是也可以通过专线实现。
服务器可以用主机或路由器的连接身份来作为网络层协商的选项。
本文定义了PPP认证协议。
链路建立阶段和认证阶段以及“认证协议配置选项”都已经在PPP【1】中定义。
1.1.要求规范在本文中,用以下几个词表示规范描述要求,这几个词经常用大写标明。
MUST “必须”,也就是形容词“必需的”,意思是该项是本规范的绝对要求。
MUST NOT “不得”,意思是该项是本规范所绝对禁止的。
SHOULD “应该”,也就是形容词“推荐的”,意思是在某些场合可能由于某种原因忽略该项,但是协议的完全实现必须能够理解该项,在决定其他方式之前要经过仔细考虑。
MAY “可以”,也就是形容词“可选的”,意思是该项可以作为可选集使用,不包含该选项的协议实现必须能够和包含了该选项的实现交互协作。
1.2.术语本文频繁使用的术语包括以下几个:Authenticator(认证者)链路要求认证的一端,认证者在链路建立阶段的Configure-Request中指定认证协议。
Peer(对端)点到点链路的另一端;由认证者认证的一端。
silently discard(静静丢弃)协议实现直接丢弃数据包,不作进一步处理。
实现应该提供记录错误的能力——包括被静静丢弃的包的内容,还应该在统计计数器里记录事件。
2.挑战握手认证协议挑战握手认证协议(CHAP)通过三次握手周期性的认证对端的身份。
这在初始链路建立时完成,并且可以在链路建立之后的任何时候重复进行。
RFC2616_cn
Network Working Group(网络工作组) R. Fielding Request for Comments: 2616 UC Irvine Obsoletes(过时弃用): 2068 J. Gettys Category: Standards Track (类别:标准组) Compaq/W3CJ. MogulCompaqH. FrystykW3C/MITL. MasinterXeroxP. LeachMicrosoftT. Berners-LeeW3C/MITJune 1999超文本传输协议-HTTP/1.1本备忘录状况本文档说明了用于互联网社区的标准化跟踪协议,但还需要讨论和建议以便更加完善。
请参考"互联网官方协议标准"(STD1)来了解本协议的标准化状态。
分发散布本文是不受限制的。
版权声明Copyright (C) The Internet Society (1999). All Rights Reserved.摘要超文本传输协议(HTTP)是一种应用于分布式、协作式、超媒体信息系统的应用层协议。
它是一种通用的,状态无关的协议,可以用于除了超文本以外,还可以通过扩展它的请求方法,错误代码和报头[47]来完成更多任务,比如名称服务和分布对象管理系统。
HTTP的一个特点是数据表示方式的典型性(可输入的)(typing)和可协商性,允许建立独立于被传输数据的系统。
HTTP在1990年WWW全球信息刚刚起步的时候就得到了应用。
本规范定义了HTTP/1.1协议,这是RFC 2068的升级版[33]。
[页码1]------------------------------------------------------------------------目录1 Introduction (介绍) (7)1.1 Purpose(目的) (7)1.2 Requirements (要求) (8)1.3 Terminology (术语) (8)1.4 Overall Operation (概述) (12)2 Notational Conventions and Generic Grammar(标志转换及通用语法) (14)2.1 Augmented BNF (扩充的范式) (14)2.2 Basic Rules (基本规则) (15)3 Protocol Parameters (协议参数) (17)3.1 HTTP Version (版本) (17)3.2 Uniform Resource Identifiers (统一资源标识) (18)3.2.1 General Syntax (通用语法) (19)3.2.2 http URL (19)3.2.3 URI Comparison (URI对比) (20)3.3 Date/Time Formats (时间日期格式) (20)3.3.1 Full Date (完整日期) (20)3.3.2 Delta Seconds (21)3.4 Character Sets (字符集) (21)3.4.1 Missing Charset (不见了的字符集) (22)3.5 Content Codings (内容编码) (23)3.6 Transfer Codings (传输编码) (24)3.6.1 Chunked Transfer Coding (大块数据传输编码) (25)3.7 Media Types (媒介类型) (26)3.7.1 Canonicalization and Text Defaults (27)3.7.2 Multipart Types (复合类型) (27)3.8 Product Tokens (产品记号) (28)3.9 Quality Values (质量值) (29)3.10 Language Tags (语言标签) (29)3.11 Entity Tags (实体标签) (30)3.12 Range Units (范围单位) (30)4 HTTP Message (HTTP 消息) (31)4.1 Message Types (消息类型) (31)4.2 Message Headers (消息头) (31)4.3 Message Body (消息主体) (32)4.4 Message Length (消息长度) (33)4.5 General Header Fields (通用头字段) (34)5 Request (请求) (35)5.1 Request-Line (请求行) (35)5.1.1 Method (方法) (36)5.1.2 Request-URI (请求-URI) (36)5.2 The Resource Identified by a Request (38)5.3 Request Header Fields (请求头字段) (38)6 Response (应答) (39)6.1 Status-Line (状态行) (39)6.1.1 Status Code and Reason Phrase (状态码和原因短语) (39)6.2 Response Header Fields (应答头字段) (41)[页码2]------------------------------------------------------------------------7 Entity (实体) (42)7.1 Entity Header Fields (实体头字段) (42)7.2 Entity Body (实体主体) (43)7.2.1 Type (类型) (43)7.2.2 Entity Length (实体长度) (43)8 Connections (连接) (44)8.1 Persistent Connections (持久连接) (44)8.1.1 Purpose (目的) (44)8.1.2 Overall Operation(概述) (45)8.1.3 Proxy Servers (代理服务器) (46)8.1.4 Practical Considerations (实践中的考虑) (46)8.2 Message Transmission Requirements (消息传送请求) (47)8.2.1 Persistent Connections and Flow Control(持久连接和流程控制) (47)8.2.2 Monitoring Connections for Error Status Messages(出错状态消息的监测连接) (48)8.2.3 Use of the 100 (Continue) Status(状态号100的使用) (48)8.2.4 Client Behavior if Server Prematurely Closes Connection(如果服务器过早关闭连接,客户端的行为) (50)9 Method Definitions (方法的定义) (51)9.1 Safe and Idempotent Methods (安全和幂等方法) (51)9.1.1 Safe Methods (安全方法) (51)9.1.2 Idempotent Methods (幂等方法) (51)9.2 OPTIONS (选项) (52)9.3 GET (命令:GET) (53)9.4 HEAD (命令:HEAD) (54)9.5 POST (命令:POST) (54)9.6 PUT (命令:PUT) (55)9.7 DELETE (命令:DELETE) (56)9.8 TRACE (命令:TRACE) (56)9.9 CONNECT (命令:CONNECT) (57)10 Status Code Definitions (状态码定义) (57)10.1 Informational 1xx (报告:1XX) (57)10.1.1 100 Continue (100 继续) (58)10.1.2 101 Switching Protocols(交换协议) (58)10.2 Successful 2xx (成功:2XX) (58)10.2.1 200 OK (200 正常) (58)10.2.2 201 Created (201 已建立) (59)10.2.3 202 Accepted (202 已接受) (59)10.2.4 203 Non-Authoritative Information (无认证信息) (59)10.2.5 204 No Content (无内容) (60)10.2.6 205 Reset Content (重置内容) (60)10.2.7 206 Partial Content (部分内容) (60)10.3 Redirection 3xx (3XX 重定向) (61)10.3.1 300 Multiple Choices (复合选择) (61)10.3.2 301 Moved Permanently (永久转移) (62)10.3.3 302 Found (找到) (62)10.3.4 303 See Other (访问其他) (63)10.3.5 304 Not Modified (304 没有更改) (63)10.3.6 305 Use Proxy (305 使用代理) (64)10.3.7 306 (Unused) (306 未使用) (64)[页码3]------------------------------------------------------------------------10.3.8 307 Temporary Redirect (暂时重定向) (65)10.4 Client Error 4xx (客户端错误) (65)10.4.1 400 Bad Request (错误请求) (65)10.4.2 401 Unauthorized (未认证) (66)10.4.3 402 Payment Required (支付请求) (66)10.4.4 403 Forbidden (禁止) (66)10.4.5 404 Not Found (没有找到) (66)10.4.6 405 Method Not Allowed (方法不容许) (66)10.4.7 406 Not Acceptable (不可接受) (67)10.4.8 407 Proxy Authentication Required (要求代理认证) (67)10.4.9 408 Request Timeout (请求超时) (67)10.4.10 409 Conflict (冲突) (67)10.4.11 410 Gone (离开) (68)10.4.12 411 Length Required (长度请求) (68)10.4.13 412 Precondition Failed (预处理失败) (68)10.4.14 413 Request Entity Too Large (请求的实体太大了) (69)10.4.15 414 Request-URI Too Long (请求URI太长了) (69)10.4.16 415 Unsupported Media Type (不支持的媒提类型) (69)10.4.17 416 Requested Range Not Satisfiable (请求范围未满足) (69)10.4.18 417 Expectation Failed (期望失败) (70)10.5 Server Error 5xx (服务器错误 5XX) (70)10.5.1 500 Internal Server Error (内部错误) (70)10.5.2 501 Not Implemented (未实现) (70)10.5.3 502 Bad Gateway (错误网关) (70)10.5.4 503 Service Unavailable (服务不可用) (70)10.5.5 504 Gateway Timeout (网关超时) (71)10.5.6 505 HTTP Version Not Supported (版本不支持) (71)11 Access Authentication (访问认证) (71)12 Content Negotiation (内容协商) (71)12.1 Server-driven Negotiation (服务器驱动协商) (72)12.2 Agent-driven Negotiation (客户端驱动协商) (73)12.3 Transparent Negotiation (透明协商) (74)13 Caching in HTTP (缓存) (74)13.1.1 Cache Correctness (缓存正确性) (75)13.1.2 Warnings (警告) (76)13.1.3 Cache-control Mechanisms (缓存控制机制) (77)13.1.4 Explicit User Agent Warnings (直接用户代理警告) (78)13.1.5 Exceptions to the Rules and Warnings (规则和警告的异常).78 13.1.6 Client-controlled Behavior(客户控制的行为) (79)13.2 Expiration Model (过期模式) (79)13.2.1 Server-Specified Expiration (服务器指定过期) (79)13.2.2 Heuristic Expiration (启发式过期) (80)13.2.3 Age Calculations (年龄计算) (80)13.2.4 Expiration Calculations (过期计算) (83)13.2.5 Disambiguating Expiration Values (消除歧义的过期值) (84)13.2.6 Disambiguating Multiple Responses (消除歧义的复合应答)..84 13.3 Validation Model (确认模式) (85)13.3.1 Last-Modified Dates (最后更改日期) (86)[页码4]------------------------------------------------------------------------13.3.2 Entity Tag Cache Validators (实体标签缓存确认) (86)13.3.3 Weak and Strong Validators (强弱确认) (86)13.3.4 Rules for When to Use Entity Tags and Last-Modified Dates当使用实体标签和最后更改日期字段时候的规则 (89)13.3.5 Non-validating Conditionals (不可确认的条件) (90)13.4 Response Cacheability (应答缓存功能) (91)13.5 Constructing Responses From Caches (从缓存构造应答) (92)13.5.1 End-to-end and Hop-by-hop Headers (端对端和逐跳的头) (92)13.5.2 Non-modifiable Headers (不可以更改的报头) (92)13.5.3 Combining Headers (组合报头) (94)13.5.4 Combining Byte Ranges (组合字节范围) (95)13.6 Caching Negotiated Responses (缓存协商过的应答) (95)13.7 Shared and Non-Shared Caches (共享和非共享缓存) (96)13.8 Errors or Incomplete Response Cache Behavior(错误或不完整应答缓存行为) (97)13.9 Side Effects of GET and HEAD (GET和HEAD的单方影响) (97)13.10 Invalidation After Updates or Deletions(更新和删除后的失效) (97)13.11 Write-Through Mandatory (强制写通过) (98)13.12 Cache Replacement (缓存替换) (99)13.13 History Lists (历史列表) (99)14 Header Field Definitions (头字段定义) (100)14.1 Accept (接受) (100)14.2 Accept-Charset (接受的字符集) (102)14.3 Accept-Encoding (接受的编码方式) (102)14.4 Accept-Language (接受的语言) (104)14.5 Accept-Ranges (接受的范围) (105)14.6 Age (年龄,生存期) (106)14.7 Allow (容许) (106)14.8 Authorization (认证) (107)14.9 Cache-Control (缓存控制) (108)14.9.1 What is Cacheable (什么可以缓存) (109)14.9.2 What May be Stored by Caches (什么将被缓存存储) (110)14.9.3 Modifications of the Basic Expiration Mechanism基本过期机制的更改 (111)14.9.4 Cache Revalidation and Reload Controls缓存重确认和重载控制 (113)14.9.5 No-Transform Directive (不可转换指示) (115)14.9.6 Cache Control Extensions (缓存控制扩展) (116)14.10 Connection (连接) (117)14.11 Content-Encoding (内容编码) (118)14.12 Content-Language (内容语言) (118)14.13 Content-Length (内容长度) (119)14.14 Content-Location (内容位置) (120)14.15 Content-MD5 (内容的MD5校验) (121)14.16 Content-Range (内容范围) (122)14.17 Content-Type (内容类型) (124)14.18 Date (日期) (124)14.18.1 Clockless Origin Server Operation (无时钟服务器操作)..125 14.19 ETag (标签) (126)14.20 Expect (期望) (126)14.21 Expires (过期) (127)14.22 From (来自) (128)[页码5]------------------------------------------------------------------------14.23 Host (主机) (128)14.24 If-Match (如果匹配) (129)14.25 If-Modified-Since (如果自从某个时间已经更改) (130)14.26 If-None-Match (如果没有匹配) (132)14.27 If-Range (如果范围) (133)14.28 If-Unmodified-Since (如果自从某个时间未更改) (134)14.29 Last-Modified (最后更改) (134)14.30 Location (位置) (135)14.31 Max-Forwards (最大向前量) (136)14.32 Pragma (语法) (136)14.33 Proxy-Authenticate (代理鉴别) (137)14.34 Proxy-Authorization (代理授权) (137)14.35 Range (范围) (138)14.35.1 Byte Ranges (字节范围) (138)14.35.2 Range Retrieval Requests (范围重获请求) (139)14.36 Referer (引用自) (140)14.37 Retry-After (一会重试) (141)14.38 Server (服务器) (141)14.39 TE (142)14.40 Trailer (追踪者) (143)14.41 Transfer-Encoding(传输编码) (143)14.42 Upgrade (改良) (144)14.43 User-Agent (用户代理) (145)14.44 Vary (变更) (145)14.45 Via (经由) (146)14.46 Warning (警告) (148)14.47 WWW-Authenticate (WWW鉴别) (150)15 Security Considerations (对安全的考虑) (150)15.1 Personal Information(个人信息) (151)15.1.1 Abuse of Server Log Information (服务日志信息的滥用) (151)15.1.2 Transfer of Sensitive Information (敏感信息传输) (151)15.1.3 Encoding Sensitive Information in URI's(对URI中的敏感信息编码) (152)15.1.4 Privacy Issues Connected to Accept Headers(可接受头的秘密问题) (152)15.2 Attacks Based On File and Path Names基于文件名和路径的攻击 (153)15.3 DNS Spoofing (DNS欺骗) (154)15.4 Location Headers and Spoofing (位置头和欺骗) (154)15.5 Content-Disposition Issues (内容部署问题) (154)15.6 Authentication Credentials and Idle Clients(信用鉴定与空闲客户) (155)15.7 Proxies and Caching (代理与缓存) (155)15.7.1 Denial of Service Attacks on Proxies(对代理的服务拒绝攻击) (156)16 Acknowledgments (致谢) (156)17 References (参考) (158)18 Authors' Addresses (作者地址) (162)19 Appendices (附录) (164)19.1 Internet Media Type message/http and application/http(网络媒体类型:消息/HTTP和应用/HTTP) (164)19.2 Internet Media Type multipart/byteranges(网络媒体类型:多部分/字节范围) (165)19.3 Tolerant Applications (容错的应用) (166)19.4 Differences Between HTTP Entities and RFC 2045 Entities(HTTP的实体和RFC2045中实体的区别) (167)[页码6]------------------------------------------------------------------------19.4.1 MIME-Version (MIME版本) (167)19.4.2 Conversion to Canonical Form (语言形式转变) (167)19.4.3 Conversion of Date Formats (日期格式的转变) (168)19.4.4 Introduction of Content-Encoding (内容编码的介绍) (168)19.4.5 No Content-Transfer-Encoding (不要内容传输编码) (168)19.4.6 Introduction of Transfer-Encoding (传输编码的介绍) (169)19.4.7 MHTML and Line Length Limitations(MHTML与行长度限制) (169)19.5 Additional Features (附加的一些性质) (169)19.5.1 Content-Disposition (内容部署) (170)19.6 Compatibility with Previous Versions (与久版本的兼容性) (170)19.6.1 Changes from HTTP/1.0 (自HTTP/1.0的更改) (171)19.6.2 Compatibility with HTTP/1.0 Persistent Connections(与HTTP/1.1持久连接的兼容性) (172)19.6.3 Changes from RFC 2068 (自RFC268的更改) (172)20 Index (索引) (175)21 Full Copyright Statement (完整版权声明) (176)1 概述1.1 目的超文本传输协议(HTTP)是一种应用于分布式、合作式、多媒体信息系统的应用层协议。
rfc9334远程证明标准
rfc9334远程证明标准
摘要:
1.远程证明标准的背景和重要性
2.rfc9334 远程证明标准的具体内容
3.rfc9334 标准在网络安全领域的应用
4.我国对rfc9334 远程证明标准的采纳和实施
5.总结与展望
正文:
远程证明标准是网络安全领域中一个至关重要的组成部分,它为远程身份验证提供了统一的规范和指导。
其中,rfc9334 远程证明标准是当前被广泛接受和应用的一种标准。
rfc9334 远程证明标准是由IETF(互联网工程任务组)制定的,于2016 年发布。
该标准定义了一种通用的、可扩展的远程证明协议,用于在网络设备之间进行身份验证和授权。
具体来说,rfc9334 标准定义了一种名为“TLS 远程证明”的协议,该协议基于传输层安全(TLS)协议,可以提供强加密、数据完整性和认证服务。
在网络安全领域,rfc9334 远程证明标准被广泛应用于各种场景,如服务器认证、客户端认证、网络设备认证等。
通过使用该标准,可以有效降低网络攻击的风险,提高网络安全性。
我国对rfc9334 远程证明标准的采纳和实施也在逐步推进。
我国相关政府部门和标准化组织已经积极参与到rfc9334 标准的制定和完善过程中,并在我
国网络安全法规和标准中提出明确要求,鼓励和指导国内企业采用rfc9334 标准。
总之,rfc9334 远程证明标准为网络安全领域提供了重要支持。
随着网络攻击手段的不断升级,远程证明标准将发挥越来越重要的作用。
rfc 规则 -回复
rfc 规则-回复什么是RFC规则?RFC规则(Request for Comments) 是一种用于文档化Internet标准、协议、过程等的机制。
RFC最早由互联网工程任务组(IETF) 创建,现已发展成为面向整个互联网技术社区的一种通用标准。
RFC规则的主要作用是促进协议和标准的发展和交流,以确保互联网的统一性和互操作性。
目前,RFC规则成为了推动各类互联网标准化工作必不可少的一环,对于新标准和协议的提出、讨论、修改和最终认可都有着重要的影响。
那么,RFC规则是如何产生和演化的呢?如何确保规则的严谨性和有效性?接下来,我们将详细介绍RFC规则的产生和发展过程。
1. RFC的起源和发展RFC的起源可以追溯到20世纪60年代末,当时美国国防部高级研究计划局(ARPA) 正在进行一个名为ARPANET的项目,旨在构建一个分布式的计算机网络。
为了促进网络上各种标准和协议的制定和发展,ARPANET 的相关负责人制定了一个名为"Request for Comments"的机制,用于发布网络协议的设计和实现文档,并邀请来自世界各地的技术专家提出反馈和建议。
由于RFC规则的成功应用于ARPANET项目,它也被采纳为一种通用的标准化规范机制。
随着互联网的快速发展,RFC规则也逐渐成为促进互联网技术标准化的主要途径。
2. RFC的书写和提交RFC规则的书写和提交是一个开放的过程,任何人都可以通过填写RFC 表单来提交自己的标准、协议、技术报告或其他相关文档。
RFC规则要求提交的文档需经过严格的审查和讨论,确保其内容准确、一致、易于理解,并有利于互联网的发展。
一篇RFC规则文档通常包括以下几个部分:- 文档的标识和版本信息- 文档的摘要和目的- 相关术语和定义- 提出的标准或协议的描述和技术细节- 安全性、互操作性和性能等方面的考虑- 影响和建议的总结- 参考资料和相关链接提交的文档经过初步审查后,将被分配一个RFC编号,并发布在互联网上供公众查阅和讨论。
IXIA网络测试仪使用说明
IXIA网络测试仪使用说明(仅供内部使用)格林耐特技术有限公司GreenNet Technologies Co., Ltd.版权所有侵权必究All rights reservedIXIA网络测试仪操作规程目录1. IXIA网络测试仪操作规程 ..................................................................... (3)2. IXIA网络测试仪使用说明 ..................................................................... (4)2.1. IXIA测试仪简介 ..................................................................... .......................................................4 2.2. 测试原理 ..................................................................... . (4)2.3. 硬件安装和配置 ..................................................................... . (5)2.3.1. 检查包装...................................................................... .. (5)2.3.2. 硬件连接...................................................................... .. (5)2.3.3. 配置TCP/IP协议 ..................................................................... ...........................................6 2.4. 软件安装 ..................................................................... . (7)2.5. 测试操作 ..................................................................... . (8)2.5.1. 1.测试注意事项...................................................................... ..............................................83. IxExplorer使用说明 ..................................................................... . (9)4. ScriptMate使用说明 ..................................................................... .. (11)4.1. RFC2544测试 ..................................................................... . (13)4.2. RFC2285测试 ..................................................................... . (14)4.2.1. RFC2285测试配置参数一览表 ..................................................................... ...................14 4.3. Advanced Tcl Script Suite(ATSS) ................................................................. .. (17)版权所有侵权必究 All Rights Reserved. Page 2 of 17IXIA网络测试仪操作规程1. IXIA网络测试仪操作规程为加强IXIA测试仪的使用管理,保障设备运行安全,提高设备的完好率和使用率,特制定本规程。
rfc 1421标准
rfc 1421标准
RFC 1421是Internet工程任务组(IETF)发布的一份文件,标准名称为“IP Payload Compression Protocol (IPComp)”,即IP载荷压缩协议。
这份文件规定了压缩算法的用法和实施,主要为了在IP网络中减少传输的数据量,提高数据传输效率。
IPComp可以应用于IP、ICMP、IGMP、UDP和TCP等协议。
此外,RFC 1421还规定了压缩方法,包括使用通用压缩库和可选的端到端压缩。
该标准主要基于已有的压缩算法,例如LZS和LZ77。
需要注意的是,随着技术的发展和网络环境的变化,RFC 1421可能已经过时或被其他更新的标准所取代。
因此,在实际应用中,建议查阅最新的标准和技术文档,以确保使用的技术和方法符合当前的最佳实践和标准。
Hessian协议解析
Hessian协议解析协议名称:Hessian协议解析一、背景介绍Hessian协议是一种基于二进制的轻量级远程调用协议,用于在分布式系统中进行跨语言的通信。
它使用简单的二进制格式来序列化和反序列化数据,并支持多种编程语言,如Java、C#、Python等。
本协议旨在详细解析Hessian协议的结构、数据类型和通信流程,以便更好地理解和使用该协议。
二、协议结构Hessian协议采用二进制格式进行数据传输,其结构可以分为请求部分和响应部分。
1. 请求部分请求部分由请求头和请求体组成。
1.1 请求头请求头包含以下字段:- 协议版本:指示所使用的Hessian协议的版本号。
- 请求类型:指示请求的类型,如调用远程方法、获取远程对象等。
- 请求方法:指示具体的远程方法名或对象名。
- 请求ID:用于标识请求的唯一ID,用于匹配请求和响应。
1.2 请求体请求体是实际的数据载荷,可以是方法参数、对象序列化数据等。
2. 响应部分响应部分由响应头和响应体组成。
2.1 响应头响应头包含以下字段:- 协议版本:指示所使用的Hessian协议的版本号。
- 响应类型:指示响应的类型,如成功、失败等。
- 请求ID:与请求部分的请求ID对应,用于匹配请求和响应。
2.2 响应体响应体是实际的数据载荷,可以是方法返回值、对象反序列化数据等。
三、数据类型Hessian协议支持多种数据类型的序列化和反序列化,包括基本数据类型、数组、字符串、日期、集合等。
1. 基本数据类型Hessian协议支持的基本数据类型包括整型、浮点型、布尔型、字符型等。
2. 数组Hessian协议支持一维和多维数组的序列化和反序列化,可以是基本数据类型的数组或对象数组。
3. 字符串Hessian协议支持字符串的序列化和反序列化,使用UTF-8编码。
4. 日期Hessian协议支持日期类型的序列化和反序列化,使用标准的ISO 8601日期格式。
5. 集合Hessian协议支持集合类型的序列化和反序列化,包括列表、集合、映射等。
- 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。
Network Working Group Internet Architecture Board Request for Comments: 1401 Lyman Chapin, Chair January 1993 Correspondence between the IAB and DISA on the use ofDNS throughout the InternetStatus of this MemoThis memo provides information for the Internet community. It doesnot specify an Internet standard. Distribution of this memo isunlimited.AbstractThis memo reproduces three letters exchanged between the InternetActivities Board (IAB) and the Defense Information Systems Agency(DISA) regarding the importance of using the Domain Name System (DNS) throughout the Internet, and phasing out the use of older host nameto address tables, such as "hosts.txt".IAB [Page 1]1. Letter from the IAB to DISA30 March, 1992To: Members of the Federal Networking Council,Members of the Federal Networking Advisory Council,Colonel Ken Thomas, Chairman,DoD Protocol Standards Steering Group, DISA/Center forStandardsCC: C. J. Pasquariello, Associate Director, Center for Standards,LCDR, David Chappell, Executive Secretary,PSSG, DISA/Center for StandardsEduardo Schonborn, Dep Director/DDN PMOAs the IAB, together with others in the Internet Engineering andResearch Task Forces, contemplates the challenges inherent in dealing with an exponentially expanding Internet, the critical need forwidespread adoption of a uniform Domain Name service is veryapparent.The attached memorandum is offered by the Internet Activities Boardfor your consideration regarding technical policy concerning domainnaming in the US portion of the Internet. The proposed technicalpolicy is recommended world-wide and will be offered as an RFC forthat purpose. Adoption of such a policy would, we believe, muchenhance the operational efficiency of the existing world-wideInternet backbone and major networks dependent upon it, including the DDN Milnet.Your consideration of this policy question is urged in the strongest possible terms. We would much appreciate hearing the views of theProtocol Standards Steering Group by April 20, 1992.Regards,A. Lyman ChapinChairman, Internet Activities BoardIAB [Page 2]AttachmentThe Domain Name System is an Internet NecessityInternet Activities BoardFebruary 1992Over the last several years, the Internet has evolved in size soextensively that it has become infeasible to provide directoryservices through a database maintained at a single, centralrepository. Both the size and the dynamics of the required data make such an approach impractical. Recognizing this problem several years ago [1], the Internet community has adopted the Domain Name System[2-5] as the principal means of achieving host name to IP addressmappings. During this time, almost the entire Internet has converted from the use of the static name-to-address mapping tables thus farcentrally maintained at the DDN Network Information Center, to theuse of the more dynamic, up-to-date address mapping provided by DNSmechanism.There are still large fractions of the Internet community which rely on the use of a centrally-maintained file ("hosts.txt") to accomplish this mapping function. The MILNET community appears to havesubstantial pockets of dependence on table-driven mappings, forexample. Although a plan for achieving a MILNET transition to use of the Domain Name System was worked out in 1987, the transition isincomplete and, as a result, naming services (i.e., host name lookups on the MILNET) are many times still provided via static tables rather than the distributed, and far more accurate, Domain Name System.Ironically, most of the commercial, off-the-shelf software for TCP/IP supports the user of the Domain Name System, so a policy of uniformsupport and application of DNS would go a long way toward improvingthe Defense Department data communication infrastructure, insofar as it is dependent on TCP/IP to interconnect hosts on LANs and WANs.The use of different means for name-to-address mappings by different parties in the network community leads to unsynchronized andinconsistent databases, which inevitably result in reachabilityfailures by users attempting to connect to network resources.Moreover, the special facilities of the Domain Name System, such asthe MX (Mail eXchange) record, make it possible to include systemsnot directly on the Internet into the universe of addressableparties. MX records also allow a network administrator to prioritize a list of alternative e-mail relays in case the final destination is not reachable. Systems which do not support MX records, but ratherstill depend on the "hosts.txt" information, pose a serious obstacle to network connectivity, as well as to the operation and management IAB [Page 3]of the highly connected Internet.Non-DNS systems on the Internet will eventually be confronted withthe need to decide whether they want to continue as a part of thelarger Internet community, or remain a rather small, non-conformingsubset. Should they choose not to conform to the otherwise accepted Domain Name System, they will have to accept the ramifications ofthis decision. In particular, they will have to accept that the rest of the community may, indeed has already started to, essentiallyignore those static files which reflect the principal non-DNS naming service. The larger community has evolved so extensively beyondthese configurations, that these files are not only obsolete as atechnology, but also incomplete and often inaccurate in the presentimplementation. Upon connecting a new host to the Internet, thegreat majority of the Internet community no longer considers theregistration of host name/address updates to the NIC database anecessity, and rather focuses on updating the Domain name System.Therefore, today’s NIC database, and the "hosts.txt" file generatedfrom it, largely reflects only the non-DNS community, a tiny subsetof the hundreds of thousands of entities configured into the Internet name space via the DNS.If the non-DNS users maintain a requirement for the use of staticmapping tables, at least some mechanism should exist to augment theNIC data sets with additional information represented by the DomainName System. These more comprehensive tables, accompanied by amethod to guarantee synchronization with the DNS, would significantly improve the accuracy of the information which non-DNS users apply to map between names and addresses. However, this solution will notaddress the need for support of the richer DNS functionality by theNIC’s system. At a minimum, the incorporation of MX information into the NIC database is imperative for compatibility between the"hosts.txt" file and the DNS. Network subcommunities which choose to maintain a separate and incompatible mapping system will have apartitioning effect on the subcommunities themselves, but also adetrimental impact on overall Internet operations. Both end-usersand system and network administrators will inevitably find themselves devoting considerable attention to tracing inconsistency problemsarising from the discrepancy in mapping methods.The Internet Activities Board, recognizing the need for universalinteroperability and consistent naming mechanisms, and benefittingfrom several years of experience with the Domain Name System, isadvocating a policy that all connected components of the Internetcommunity should adopt the DNS, and urges parties having policy-setting authority to adopt the same position and undertake to setdeadlines for conversion to uniform use of DNS.IAB [Page 4]References1. J.B. Postel and J.K. Reynolds, Domain Requirements, RFC 920,October 1984.2. P.V. Mockapetris, Domain Names - Concepts and Facilities,RFC 1034, November 1987.3. P.V. Mockapetris, Domain Names - Implementation and Specification, RFC 1035, November 1987.4. M.K. Stahl, Domain Administrators Guide, RFC 1032, November 1987.5. M. Lottor, Domain Administrators Operations Guide, RFC 1033,November 1987.6. W.D. Lazear, MILNET Name Domain Transition, RFC 1031,November 1987.IAB [Page 5]16 APR 1992Mr. Lyman ChapinChairman, Internet Activities BoardBBN CommunicationsDivision of Bolt Beranek and Newman, Inc.150 Cambridge Park Dr.Chambridge, MA 02140Dear Mr. Chapin:We have received you letter concerning the adoption and use of theDomain Name System (DNS) throughout the Internet. Since the DoDmakes significant use of the Internet, we are very concerned withissues such as the DNS that potentially affect both performance andinteroperability. We have agreed to staff this issue to consider all the technical and economical impacts on DoD systems. We will inform you of the decisions reached as the result of our reviews as son asthey are completed.Sincerely,Kenneth A. ThomasColonel, USAChairman, Protocol StandardsSteering Group (PSSG)Copy to:Mr. Pasquariello, Associate Director, Center for StandardsMr. Schonborn, Deputy Director/DDN PMOIAB [Page 6]19 May, 1992Colonel Kenneth ThomasChairman, Protocol Standards Steering GroupDefense Information Systems AgencyFort Monmouth, NJ 07703-5613Dear Colonel Thomas,Thank you for your response to my letter concerning the adoption and use of the Domain Name System throughout the Internet. I appreciate your willingness to devote resources to consider this issue, and look forward to hearing the results of the study.As LCDR David Chappell has suggested, it would be useful for us toarrange a meeting to discuss issues of mutual concern to DISA and the IAB. I do not yet know if it will be feasible for me to arrange tomeet with you in Ft. Monmouth in the near future (my travel schedule being somewhat oversubscribed), but will get in touch with you soonto find a suitable date and location.Regards,A. Lyman ChapinChairman, Internet Activities BoardBBN Communications 20/5b150 Cambridge Park DriveCambridge, MA 02140IAB [Page 7]Security ConsiderationsSecurity issues are not discussed in this memo.Author’s AddressA. Lyman ChapinBBN Communications Corporation150 Cambridge Park DriveCambridge, MA 02140Phone: 617-873-3133Fax: 617-873-4086Email: Lyman@IAB [Page 8]。