下载文档原格式
RFC1058 Routing Information Protocol1. 简介该文档描述了基于Bellman-Ford(距离向量)算法的一系列路由协议的一种协议。
从早期的ARPANET开始，该算法已经在计算机网络中用于路由计算。
本文描述的特定包格式和协议都基于程序”Routed”，该程序包含在Unix 的伯克利分发中。
”routed”已经成为事实的标准，用于在主机和网关间交换路由信息。
它被大多数商业IP网关的提供者实现。
然而，请注意，这些提供者中的很多都有自己的协议，用于自己的网关。
该协议常常被用作内部网关协议。
在一个国际级的网络，如当前的因特网，没有一个单个路由协议作为整个网络的协议使用。
网络被组织成很多的自治系统。
一个自治系统通常被一个管理实体，或者至少有一些技术或者管理控制。
这些在不同的自治系统间是不同的。
用在自治系统内部的协议叫做内部网关协议，或者“IGP”。
在自治系统间采用独立的协议。
最早的这种协议，依然在网络上使用，叫做外部网关协议“EGP”。
这种协议用作AS间的路由协议。
RIP设计工作在中等规模的网络，适用于很多校园或者区域网络的IGP。
RIP协议并不打算应用在更复杂的缓急国内下。
RIP是距离向量算法中的一个。
最早描述该算法的是作者Ford和Fulkerson。
因为这些，这个也叫做Ford-Fulkerson算法。
术语Bellman-Ford 也在使用。
它来源于事实，这个算法基于Bellman等式，动态编程的基础。
RIP用于基于IP的网络。
1.1.协议限制该协议并没有解决每一个路由问题。
如上所述，RIP的主要目的是用在IGP，适当的网络规模。
初次之外，下面的限制要注意：●该协议限制在网络最长距离15跳。
设计者相信这个基本的协议不适应大型的网络。
●协议依靠“计数到无限”来解决特定不常用的情况。
如果网络系统包含几百个网络，路由环回会形成。
环回的解决需要大量时间（如果路由更新频率受限），或者带宽（当检测到更新发送更新变化）。
5g 基站射频杂散协议,空载rssi 协议5G基站射频杂散协议和空载RSSI协议是5G通信网络中关键的技术规范，对于确保网络通信质量和稳定性至关重要。
下面将详细介绍这两个协议的基本概念和作用。
首先，我们来了解一下5G基站射频杂散协议。
射频杂散是指在5G 基站工作过程中，由于一些外部环境因素或设备本身的问题导致的信号干扰和泄漏。
这些杂散信号会严重影响基站的正常工作，甚至会对通信质量产生负面影响。
因此，5G基站射频杂散协议就是为了限制和控制这些杂散信号而制定的一系列技术规范和标准。
5G基站射频杂散协议主要包括以下几个方面的内容：1.射频信号调理：通过对射频信号进行调理和优化，减少信号的泄漏和干扰，提高信号的传输效率和稳定性。
2.杂散信号监测：建立杂散信号监测系统，及时发现和定位杂散信号源，并采取相应措施予以处理。
3.杂散信号抑制：采用各种技术手段，如滤波器、射频屏蔽等，抑制杂散信号的产生和传播，保障基站的正常工作。
4.杂散信号检测报警：建立杂散信号检测报警机制，一旦发现杂散信号异常，及时发出警报，并采取相应措施进行处理。
通过5G基站射频杂散协议的规范，可以有效减少基站工作中的杂散信号干扰，提高通信质量和稳定性，保障用户的通信需求得到满足。
接下来，我们来介绍一下5G空载RSSI协议。
空载RSSI是指在5G 基站空载情况下的接收信号强度指示（Received Signal Strength Indication）。
空载状态是指基站在没有进行通信时的工作状态，而RSSI则是指接收信号的强度指示。
5G空载RSSI协议的主要作用是对基站的空载信号进行监测和评估，以确保基站在没有通信的情况下也能保持良好的接收信号质量。
通过空载RSSI协议的规范，可以及时发现和处理基站空载信号中可能存在的问题，保证基站在通信空闲时也能正常工作。
5G空载RSSI协议主要包括以下几个方面的内容：1.空载信号监测：建立基站空载信号监测系统，实时监测和评估基站的空载接收信号强度，发现异常情况并及时处理。
TCP常⽤⽹络和⽊马使⽤端⼝对照表，常⽤和不常⽤端⼝⼀览表【开始-运⾏- CMD ，输⼊ netstat -an 然后回车就可以查看端⼝】 端⼝：0 服务：Reserved 说明：通常⽤于分析操作系统。
这⼀⽅法能够⼯作是因为在⼀些系统中“0”是⽆效端⼝，当你试图使⽤通常的闭合端⼝连接它时将产⽣不同的结果。
⼀种典型的扫描，使⽤IP地址为0.0.0.0，设置ACK位并在以太⽹层⼴播。
端⼝：1 服务：tcpmux 说明：这显⽰有⼈在寻找SGI Irix机器。
Irix是实现tcpmux的主要提供者，默认情况下tcpmux在这种系统中被打开。
Irix机器在发布是含有⼏个默认的⽆密码的帐户，如：IP、GUEST UUCP、NUUCP、DEMOS 、TUTOR、DIAG、OUTOFBOX等 端⼝：7 服务：Echo 说明：能看到许多⼈搜索Fraggle放⼤器时，发送到X.X.X.0和X.X.X.255的信息。
端⼝：19 服务：Character Generator 说明：这是⼀种仅仅发送字符的服务。
UDP版本将会在收到UDP包后回应含有垃圾字符的包。
TCP连接时会发送含有垃圾字符的数据流直到连接关闭。
HACKER利⽤IP欺骗可以发动DoS攻击。
伪造两个chargen服务器之间的UDP包。
同样Fraggle 端⼝：21 服务：FTP 说明：FTP服务器所开放的端⼝，⽤于上传、下载。
最常见的攻击者⽤于寻找打开anonymous的FTP服务器的⽅法。
这些服务器带有可读写的⽬录。
⽊马Doly Trojan、Fore、Invisible FTP、WebEx、WinCrash和Blade Runner所开放的端⼝。
端⼝：22 服务：Ssh 说明：PcAnywhere建⽴的TCP和这⼀端⼝的连接可能是为了寻找ssh。
这⼀服务有许多弱点，如果配置成特定的模式，许多使⽤RSAREF库的版本就会有不少的漏洞存在。
端⼝：23 服务：Telnet 说明：远程登录，⼊侵者在搜索远程登录UNIX的服务。
RFC821 简单邮件传输协议（SMTP）(RFC821 SIMPLE MAIL TRANSFER PROTOCOL)目录1. 介绍 22. SMTP模型 33. SMTP过程 43.1. MAIL 43.2. 转发 53.3. 确认和扩展 63.4. 发送信件(mailing)和获得信件(sending) 7 3.5. 打开和关闭73.6. 转发 83.7. 域93.8. 改变角色94. SMTP说明94.1. SMTP命令94.1.1. 命令语法94.1.2. COMMAND语法格式134.2. SMTP响应154.3. 命令和应答序列164.4. 状态图174.5. 详细内容184.5.1. 最小实现184.5.2. 透明性194.5.3. 大小19附录 A TCP传输服务19附录 B NCP传输服务20附录 C NITS 20附录 D X.25传输服务 20附录 E 应答码构成方法20附录 F 一些例子22参考资料361. 介绍简单邮件传输协议（SMTP）的目标是可靠高效地传送邮件，它独立于传送子系统而且仅要求一条可以保证传送数据单元顺序的通道。
附录A，B，C和D描述了不同传送服务下SMTP的使用。
在名词表中还定义了本文档中使用的术语。
SMTP的一个重要特点是它能够在传送中接力传送邮件，传送服务提供了进程间通信环境（IPCE），此环境可以包括一个网络，几个网络或一个网络的子网。
理解到传送系统（或IPCE）不是一对一的是很重要的。
进程可能直接和其它进程通过已知的IPCE通信。
邮件是一个应用程序或进程间通信。
邮件可以通过连接在不同IPCE上的进程跨网络进行邮件传送。
更特别的是，邮件可以通过不同网络上的主机接力式传送。
2. SMTP模型SMTP设计基于以下通信模型：针对用户的邮件请求，发送SMTP建立与接收SMTP之间建立一个双向传送通道。
接收SMTP可以是最终接收者也可以是中间传送者。
SMTP命令由发送SMTP发出，由接收SMTP接收，而应答则反方面传送。
ietfrfc3551—2003
RFC 3551是实时传输协议（RTP）的标准，它定义了互联网音频和视频传输的标准格式。
该标准主要应用于实时传输数据，例如音频、视频或仿真数据。
RTP本身不提供服务质量保证（QoS），也不提供资源预留功能，但可以通过一个控制协议（RTCP）进行扩展，对数据传输进行监测和控制。
RTCP 可以升级到大型的多点传送（多播）网络，并提供最小限度的控制和鉴别功能。
RTP和RTCP被设计成与下面的传输层和网络层无关，这意味着它们可以与不同的传输层协议（如TCP或UDP）和不同的网络层协议（如IPv4或IPv6）一起使用。
此外，RTP标准还支持RTP标准的转换器和混合器的使用。
以上内容仅供参考，如需了解更多信息，建议查阅RFC 3551的官方文档或咨询专业技术人员。
欧洲猫系统的二次代码分配韩卓臣（中国民用航空中南地区空中交通管理局技术保障中心，广东广州510000）摘要：二次代码是航空器的身份识别的一个组成部分。
对现代航空器与空管系统而言，二次代码的分配至关重要。
在不同的情况下，二次代码的分配又分为自动分配和人工分配。
关键词：二次代码；自动分配；人工分配中图分类号：V355.12文献标识码：A文章编号：1673-1131（2019）04-0270-02The Allocation of SSR Code for Euro-cat SystemAbstract:SSR code is a part comprising identification of aircraft.For modern aircraft and air traffic management system,the all-ocation of SSR code is essential.In various circumstances,the allocation of SSR code is implemented in different categories as automatic allocation and manual allocation.1二次代码概述二次代码用于标识不同的航空器，并与飞行计划、航班号相关，提供航空器的身份识别。
目前用于运营飞机都装备有二次代码应答机，用于向地面雷达发送航迹识别。
二次代码，即二次监视雷达代码（SSR,Second Surveillance Radar Code）,是一组四位八进制数码，每位取值为0-7。
二次代码又分为二位代码和四位代码两种类型。
两种代码都各由两对八进制代码组成。
二位代码开始两位数值为00-77，后两位数值保持为00。
四位代码开始两位为00-77，后两位为01-77。
二次代码按不同的数值又可划分为离散型与非离散型代码，具体数值由下线参数文件定义。
千兆交换机性能测试的九项指标简介文章发布人：gxy 共98人阅读文字大小：[ 大中小 ] 文字背景色：交换机作为企业网络的核心连接设备，它的性能是保障企业网络速度的主要标准。
为了帮助读者比较清楚地了解交换机的性能全貌，我们利用业界先进的IXIA1600测试仪器对涉及交换机性能中的9项主要指标进行了测试，当然，测试条件相对于实际工作环境来说是相当严酷的。
我们进行性能测试的主要依据是RFC2544和RFC2285，测试中主要选择了64字节、512字节和1518字节三种常用的以太网帧长度。
1．吞吐量作为用户选择和衡量交换机性能最重要的指标之一，吞吐量的高低决定了交换机在没有丢帧的情况下发送和接收帧的最大速率。
在测试时，我们在满负载状态下进行。
该测试配置为一对一映射。
2．帧丢失率该测试决定交换机在持续负载状态下应该转发，但由于缺乏资源而无法转发的帧的百分比。
帧丢失率可以反映交换机在过载时的性能状况，这对于指示在广播风暴等不正常状态下交换机的运行情况非常有用。
3.Back-to-Back 该测试考量交换机在不丢帧的情况下能够持续转发数据帧的数量。
该参数的测试能够反映数据缓冲区的大小。
4.延迟该项指标能够决定数据包通过交换机的时间。
延迟如果是FIFO(First in and First Out),即指的是被测设备从收到帧的第一位达到输入端口开始到发出帧的第一位达到输出端口结束的时间间隔。
最初将发送速率设定为吞吐量测试中获得的速率，在指定间隔内发送帧，一个特定的帧上设置为时间标记帧。
标记帧的时间标签在发送和接收时都被记录下来，二者之间的差异就得出延迟时间。
5．错误帧过滤该测试项目决定交换机能否正确过滤某些错误类型的帧，比如过小帧、超大帧、CRC错误帧、Fragment、Alignment 错误和Dribble错误，过小帧指的是小于64字节的帧，包括16、24、32、63字节帧，超大帧指的是大于1518字节的帧，包括1519、2000、4000、8000字节帧，Fragment指的是长度小于64字节的帧，CRC错误帧指的是帧校验和错误，Dribble帧指的是在正确的CRC校验帧后有多余字节，交换机对于Dribble帧的处理通常是将其更正后转发到正确的接收端口，Alignment结合了CRC错误和dribble错误，指的是帧长不是整数的错误帧。
Network Working Group H. Schulzrinne Request for Comments: 3551 Columbia University Obsoletes: 1890 S. Casner Category: Standards Track Packet DesignJuly 2003RTP Profile for Audio and Video Conferenceswith Minimal ControlStatus of this MemoThis document specifies an Internet standards track protocol for theInternet 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.Network Communication Protocol Map. To order: /map.html Easy to use sniffing tool: /packet.htmlCopyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved.AbstractThis document describes a profile called "RTP/AVP" for the use of thereal-time transport protocol (RTP), version 2, and the associatedcontrol protocol, RTCP, within audio and video multiparticipantconferences with minimal control. It provides interpretations ofgeneric fields within the RTP specification suitable for audio andvideo conferences. In particular, this document defines a set ofdefault mappings from payload type numbers to encodings.This document also describes how audio and video data may be carriedwithin RTP. It defines a set of standard encodings and their nameswhen used within RTP. The descriptions provide pointers to referenceimplementations and the detailed standards. This document is meantas an aid for implementors of audio, video and other real-timemultimedia applications.This memorandum obsoletes RFC 1890. It is mostly backwards-compatible except for functions removed because two interoperableimplementations were not found. The additions to RFC 1890 codifyexisting practice in the use of payload formats under this profileand include new payload formats defined since RFC 1890 was published.Table of Contents1. Introduction (3)1.1 Terminology (3)2. RTP and RTCP Packet Forms and Protocol Behavior (4)3. Registering Additional Encodings (6)4. Audio (8)4.1 Encoding-Independent Rules (8)4.2 Operating Recommendations (9)4.3 Guidelines for Sample-Based Audio Encodings (10)4.4 Guidelines for Frame-Based Audio Encodings (11)4.5 Audio Encodings (12)4.5.1 DVI4 (13)4.5.2 G722 (14)4.5.3 G723 (14)4.5.4 G726-40, G726-32, G726-24, and G726-16 (18)4.5.5 G728 (19)4.5.6 G729 (20)4.5.7 G729D and G729E (22)4.5.8 GSM (24)4.5.9 GSM-EFR (27)4.5.10 L8 (27)4.5.11 L16 (27)4.5.12 LPC (27)4.5.13 MPA (28)4.5.14 PCMA and PCMU (28)4.5.15 QCELP (28)4.5.16 RED (29)4.5.17 VDVI (29)5. Video (30)5.1 CelB (30)5.2 JPEG (30)5.3 H261 (30)5.4 H263 (31)5.5 H263-1998 (31)5.6 MPV (31)5.7 MP2T (31)5.8 nv (32)6. Payload Type Definitions (32)7. RTP over TCP and Similar Byte Stream Protocols (34)8. Port Assignment (34)9. Changes from RFC 1890 (35)10. Security Considerations (38)11. IANA Considerations (39)12. References (39)12.1 Normative References (39)12.2 Informative References (39)13. Current Locations of Related Resources (41)14. Acknowledgments (42)15. Intellectual Property Rights Statement (43)16. Authors' Addresses (43)17. Full Copyright Statement (44)1. IntroductionThis profile defines aspects of RTP left unspecified in the RTPVersion 2 protocol definition (RFC 3550) [1]. This profile isintended for the use within audio and video conferences with minimal session control. In particular, no support for the negotiation ofparameters or membership control is provided. The profile isexpected to be useful in sessions where no negotiation or membership control are used (e.g., using the static payload types and themembership indications provided by RTCP), but this profile may also be useful in conjunction with a higher-level control protocol.Use of this profile may be implicit in the use of the appropriateapplications; there may be no explicit indication by port number,protocol identifier or the like. Applications such as sessiondirectories may use the name for this profile specified in Section11.Other profiles may make different choices for the items specifiedhere.This document also defines a set of encodings and payload formats for audio and video. These payload format descriptions are included here only as a matter of convenience since they are too small to warrant separate documents. Use of these payload formats is NOT REQUIRED to use this profile. Only the binding of some of the payload formats to static payload type numbers in Tables 4 and 5 is normative.1.1 TerminologyThe key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [2] andindicate requirement levels for implementations compliant with this RTP profile.This document defines the term media type as dividing encodings ofaudio and video content into three classes: audio, video andaudio/video (interleaved).2. RTP and RTCP Packet Forms and Protocol BehaviorThe section "RTP Profiles and Payload Format Specifications" of RFC 3550 enumerates a number of items that can be specified or modified in a profile. This section addresses these items. Generally, this profile follows the default and/or recommended aspects of the RTPspecification.RTP data header: The standard format of the fixed RTP dataheader is used (one marker bit).Payload types: Static payload types are defined in Section 6.RTP data header additions: No additional fixed fields areappended to the RTP data header.RTP data header extensions: No RTP header extensions aredefined, but applications operating under this profile MAY usesuch extensions. Thus, applications SHOULD NOT assume that theRTP header X bit is always zero and SHOULD be prepared to ignore the header extension. If a header extension is defined in thefuture, that definition MUST specify the contents of the first 16 bits in such a way that multiple different extensions can beidentified.RTCP packet types: No additional RTCP packet types are definedby this profile specification.RTCP report interval: The suggested constants are to be used forthe RTCP report interval calculation. Sessions operating underthis profile MAY specify a separate parameter for the RTCP traffic bandwidth rather than using the default fraction of the sessionbandwidth. The RTCP traffic bandwidth MAY be divided into twoseparate session parameters for those participants which areactive data senders and those which are not. Following therecommendation in the RTP specification [1] that 1/4 of the RTCP bandwidth be dedicated to data senders, the RECOMMENDED defaultvalues for these two parameters would be 1.25% and 3.75%,respectively. For a particular session, the RTCP bandwidth fornon-data-senders MAY be set to zero when operating onunidirectional links or for sessions that don't require feedback on the quality of reception. The RTCP bandwidth for data senders SHOULD be kept non-zero so that sender reports can still be sent for inter-media synchronization and to identify the source byCNAME. The means by which the one or two session parameters for RTCP bandwidth are specified is beyond the scope of this memo.SR/RR extension: No extension section is defined for the RTCP SRor RR packet.SDES use: Applications MAY use any of the SDES items describedin the RTP specification. While CNAME information MUST be sentevery reporting interval, other items SHOULD only be sent everythird reporting interval, with NAME sent seven out of eight times within that slot and the remaining SDES items cyclically taking up the eighth slot, as defined in Section 6.2.2 of the RTPspecification. In other words, NAME is sent in RTCP packets 1, 4, 7, 10, 13, 16, 19, while, say, EMAIL is used in RTCP packet 22.Security: The RTP default security services are also the defaultunder this profile.String-to-key mapping: No mapping is specified by this profile.Congestion: RTP and this profile may be used in the context ofenhanced network service, for example, through Integrated Services (RFC 1633) [4] or Differentiated Services (RFC 2475) [5], or they may be used with best effort service.If enhanced service is being used, RTP receivers SHOULD monitorpacket loss to ensure that the service that was requested isactually being delivered. If it is not, then they SHOULD assume that they are receiving best-effort service and behaveaccordingly.If best-effort service is being used, RTP receivers SHOULD monitor packet loss to ensure that the packet loss rate is withinacceptable parameters. Packet loss is considered acceptable if a TCP flow across the same network path and experiencing the samenetwork conditions would achieve an average throughput, measured on a reasonable timescale, that is not less than the RTP flow is achieving. This condition can be satisfied by implementingcongestion control mechanisms to adapt the transmission rate (or the number of layers subscribed for a layered multicast session), or by arranging for a receiver to leave the session if the lossrate is unacceptably high.The comparison to TCP cannot be specified exactly, but is intended as an "order-of-magnitude" comparison in timescale and throughput. The timescale on which TCP throughput is measured is the round-trip time of the connection. In essence, this requirement states that it is not acceptable to deploy an application (using RTP or any other transport protocol) on the best-effort Internet whichconsumes bandwidth arbitrarily and does not compete fairly withTCP within an order of magnitude.Underlying protocol: The profile specifies the use of RTP overunicast and multicast UDP as well as TCP. (This does not preclude the use of these definitions when RTP is carried by other lower- layer protocols.)Transport mapping: The standard mapping of RTP and RTCP totransport-level addresses is used.Encapsulation: This profile leaves to applications thespecification of RTP encapsulation in protocols other than UDP.3. Registering Additional EncodingsThis profile lists a set of encodings, each of which is comprised of a particular media data compression or representation plus a payload format for encapsulation within RTP. Some of those payload formats are specified here, while others are specified in separate RFCs. It is expected that additional encodings beyond the set listed here will be created in the future and specified in additional payload format RFCs.This profile also assigns to each encoding a short name which MAY be used by higher-level control protocols, such as the SessionDescription Protocol (SDP), RFC 2327 [6], to identify encodingsselected for a particular RTP session.In some contexts it may be useful to refer to these encodings in the form of a MIME content-type. To facilitate this, RFC 3555 [7]provides registrations for all of the encodings names listed here as MIME subtype names under the "audio" and "video" MIME types through the MIME registration procedure as specified in RFC 2048 [8].Any additional encodings specified for use under this profile (orothers) may also be assigned names registered as MIME subtypes with the Internet Assigned Numbers Authority (IANA). This registryprovides a means to insure that the names assigned to the additional encodings are kept unique. RFC 3555 specifies the information that is required for the registration of RTP encodings.In addition to assigning names to encodings, this profile alsoassigns static RTP payload type numbers to some of them. However,the payload type number space is relatively small and cannotaccommodate assignments for all existing and future encodings.During the early stages of RTP development, it was necessary to use statically assigned payload types because no other mechanism had been specified to bind encodings to payload types. It was anticipatedthat non-RTP means beyond the scope of this memo (such as directory services or invitation protocols) would be specified to establish adynamic mapping between a payload type and an encoding. Now,mechanisms for defining dynamic payload type bindings have beenspecified in the Session Description Protocol (SDP) and in otherprotocols such as ITU-T Recommendation H.323/H.245. These mechanisms associate the registered name of the encoding/payload format, along with any additional required parameters, such as the RTP timestampclock rate and number of channels, with a payload type number. This association is effective only for the duration of the RTP session in which the dynamic payload type binding is made. This associationapplies only to the RTP session for which it is made, thus thenumbers can be re-used for different encodings in different sessions so the number space limitation is avoided.This profile reserves payload type numbers in the range 96-127exclusively for dynamic assignment. Applications SHOULD first usevalues in this range for dynamic payload types. Those applications which need to define more than 32 dynamic payload types MAY bindcodes below 96, in which case it is RECOMMENDED that unassignedpayload type numbers be used first. However, the statically assigned payload types are default bindings and MAY be dynamically bound tonew encodings if needed. Redefining payload types below 96 may cause incorrect operation if an attempt is made to join a session without obtaining session description information that defines the dynamicpayload types.Dynamic payload types SHOULD NOT be used without a well-definedmechanism to indicate the mapping. Systems that expect tointeroperate with others operating under this profile SHOULD NOT make their own assignments of proprietary encodings to particular, fixed payload types.This specification establishes the policy that no additional static payload types will be assigned beyond the ones defined in thisdocument. Establishing this policy avoids the problem of trying to create a set of criteria for accepting static assignments andencourages the implementation and deployment of the dynamic payload type mechanisms.The final set of static payload type assignments is provided inTables 4 and 5.4. Audio4.1 Encoding-Independent RulesSince the ability to suppress silence is one of the primarymotivations for using packets to transmit voice, the RTP headercarries both a sequence number and a timestamp to allow a receiver to distinguish between lost packets and periods of time when no data was transmitted. Discontiguous transmission (silence suppression) MAY be used with any audio payload format. Receivers MUST assume thatsenders may suppress silence unless this is restricted by signaling specified elsewhere. (Even if the transmitter does not suppresssilence, the receiver should be prepared to handle periods when nodata is present since packets may be lost.)Some payload formats (see Sections 4.5.3 and 4.5.6) define a "silence insertion descriptor" or "comfort noise" frame to specify parameters for artificial noise that may be generated during a period of silence to approximate the background noise at the source. For other payload formats, a generic Comfort Noise (CN) payload format is specified in RFC 3389 [9]. When the CN payload format is used with anotherpayload format, different values in the RTP payload type fielddistinguish comfort-noise packets from those of the selected payload format.For applications which send either no packets or occasional comfort- noise packets during silence, the first packet of a talkspurt, that is, the first packet after a silence period during which packets have not been transmitted contiguously, SHOULD be distinguished by setting the marker bit in the RTP data header to one. The marker bit in all other packets is zero. The beginning of a talkspurt MAY be used to adjust the playout delay to reflect changing network delays.Applications without silence suppression MUST set the marker bit to zero.The RTP clock rate used for generating the RTP timestamp isindependent of the number of channels and the encoding; it usuallyequals the number of sampling periods per second. For N-channelencodings, each sampling period (say, 1/8,000 of a second) generates N samples. (This terminology is standard, but somewhat confusing, as the total number of samples generated per second is then the sampling rate times the channel count.)If multiple audio channels are used, channels are numbered left-to- right, starting at one. In RTP audio packets, information fromlower-numbered channels precedes that from higher-numbered channels.For more than two channels, the convention followed by the AIFF-Caudio interchange format SHOULD be followed [3], using the following notation, unless some other convention is specified for a particular encoding or payload format:l leftr rightc centerS surroundF frontR rearchannels description channel1 2 3 4 5 6_________________________________________________2 stereo l r3 l r c4 l c r S5 Fl Fr Fc Sl Sr6 l lc c r rc SNote: RFC 1890 defined two conventions for the ordering of four audio channels. Since the ordering is indicated implicitly by the number of channels, this was ambiguous. In this revision, the order described as "quadrophonic" has been eliminated toremove the ambiguity. This choice was based on the observation that quadrophonic consumer audio format did not become popular whereas surround-sound subsequently has.Samples for all channels belonging to a single sampling instant MUST be within the same packet. The interleaving of samples fromdifferent channels depends on the encoding. General guidelines are given in Section 4.3 and 4.4.The sampling frequency SHOULD be drawn from the set: 8,000, 11,025, 16,000, 22,050, 24,000, 32,000, 44,100 and 48,000 Hz. (Older Apple Macintosh computers had a native sample rate of 22,254.54 Hz, which can be converted to 22,050 with acceptable quality by dropping 4samples in a 20 ms frame.) However, most audio encodings are defined for a more restricted set of sampling frequencies. Receivers SHOULD be prepared to accept multi-channel audio, but MAY choose to onlyplay a single channel.4.2 Operating RecommendationsThe following recommendations are default operating parameters.Applications SHOULD be prepared to handle other values. The ranges given are meant to give guidance to application writers, allowing aset of applications conforming to these guidelines to interoperatewithout additional negotiation. These guidelines are not intended to restrict operating parameters for applications that can negotiate a set of interoperable parameters, e.g., through a conference control protocol.For packetized audio, the default packetization interval SHOULD have a duration of 20 ms or one frame, whichever is longer, unlessotherwise noted in Table 1 (column "ms/packet"). The packetization interval determines the minimum end-to-end delay; longer packetsintroduce less header overhead but higher delay and make packet loss more noticeable. For non-interactive applications such as lectures or for links with severe bandwidth constraints, a higherpacketization delay MAY be used. A receiver SHOULD accept packetsrepresenting between 0 and 200 ms of audio data. (For framed audio encodings, a receiver SHOULD accept packets with a number of frames equal to 200 ms divided by the frame duration, rounded up.) Thisrestriction allows reasonable buffer sizing for the receiver.4.3 Guidelines for Sample-Based Audio EncodingsIn sample-based encodings, each audio sample is represented by afixed number of bits. Within the compressed audio data, codes forindividual samples may span octet boundaries. An RTP audio packetmay contain any number of audio samples, subject to the constraintthat the number of bits per sample times the number of samples perpacket yields an integral octet count. Fractional encodings produce less than one octet per sample.The duration of an audio packet is determined by the number ofsamples in the packet.For sample-based encodings producing one or more octets per sample, samples from different channels sampled at the same sampling instant SHOULD be packed in consecutive octets. For example, for a two-channel encoding, the octet sequence is (left channel, first sample), (right channel, first sample), (left channel, second sample), (right channel, second sample), .... For multi-octet encodings, octetsSHOULD be transmitted in network byte order (i.e., most significant octet first).The packing of sample-based encodings producing less than one octet per sample is encoding-specific.The RTP timestamp reflects the instant at which the first sample in the packet was sampled, that is, the oldest information in thepacket.4.4 Guidelines for Frame-Based Audio EncodingsFrame-based encodings encode a fixed-length block of audio intoanother block of compressed data, typically also of fixed length.For frame-based encodings, the sender MAY choose to combine several such frames into a single RTP packet. The receiver can tell thenumber of frames contained in an RTP packet, if all the frames have the same length, by dividing the RTP payload length by the audioframe size which is defined as part of the encoding. This does not work when carrying frames of different sizes unless the frame sizes are relatively prime. If not, the frames MUST indicate their size.For frame-based codecs, the channel order is defined for the wholeblock. That is, for two-channel audio, right and left samples SHOULD be coded independently, with the encoded frame for the left channel preceding that for the right channel.All frame-oriented audio codecs SHOULD be able to encode and decode several consecutive frames within a single packet. Since the frame size for the frame-oriented codecs is given, there is no need to use a separate designation for the same encoding, but with differentnumber of frames per packet.RTP packets SHALL contain a whole number of frames, with framesinserted according to age within a packet, so that the oldest frame (to be played first) occurs immediately after the RTP packet header. The RTP timestamp reflects the instant at which the first sample in the first frame was sampled, that is, the oldest information in the packet.4.5 Audio Encodingsname of sampling defaultencoding sample/frame bits/sample rate ms/frame ms/packet__________________________________________________________________DVI4 sample 4 var. 20G722 sample 8 16,000 20G723 frame N/A 8,000 30 30G726-40 sample 5 8,000 20G726-32 sample 4 8,000 20G726-24 sample 3 8,000 20G726-16 sample 2 8,000 20G728 frame N/A 8,000 2.5 20G729 frame N/A 8,000 10 20G729D frame N/A 8,000 10 20G729E frame N/A 8,000 10 20GSM frame N/A 8,000 20 20GSM-EFR frame N/A 8,000 20 20L8 sample 8 var. 20L16 sample 16 var. 20LPC frame N/A 8,000 20 20MPA frame N/A var. var.PCMA sample 8 var. 20PCMU sample 8 var. 20QCELP frame N/A 8,000 20 20VDVI sample var. var. 20Table 1: Properties of Audio Encodings (N/A: not applicable; var.:variable)The characteristics of the audio encodings described in this document are shown in Table 1; they are listed in order of their payload type in Table 4. While most audio codecs are only specified for a fixed sampling rate, some sample-based algorithms (indicated by an entry of "var." in the sampling rate column of Table 1) may be used withdifferent sampling rates, resulting in different coded bit rates.When used with a sampling rate other than that for which a staticpayload type is defined, non-RTP means beyond the scope of this memo MUST be used to define a dynamic payload type and MUST indicate the selected RTP timestamp clock rate, which is usually the same as the sampling rate for audio.4.5.1 DVI4DVI4 uses an adaptive delta pulse code modulation (ADPCM) encodingscheme that was specified by the Interactive Multimedia Association (IMA) as the "IMA ADPCM wave type". However, the encoding definedhere as DVI4 differs in three respects from the IMA specification:o The RTP DVI4 header contains the predicted value rather than the first sample value contained the IMA ADPCM block header.o IMA ADPCM blocks contain an odd number of samples, since the first sample of a block is contained just in the header (uncompressed), followed by an even number of compressed samples. DVI4 has aneven number of compressed samples only, using the `predict' word from the header to decode the first sample.o For DVI4, the 4-bit samples are packed with the first sample inthe four most significant bits and the second sample in the four least significant bits. In the IMA ADPCM codec, the samples are packed in the opposite order.Each packet contains a single DVI block. This profile only defines the 4-bit-per-sample version, while IMA also specified a 3-bit-per- sample encoding.The "header" word for each channel has the following structure:int16 predict; /* predicted value of first samplefrom the previous block (L16 format) */u_int8 index; /* current index into stepsize table */u_int8 reserved; /* set to zero by sender, ignored by receiver */Each octet following the header contains two 4-bit samples, thus the number of samples per packet MUST be even because there is no means to indicate a partially filled last octet.Packing of samples for multiple channels is for further study.The IMA ADPCM algorithm was described in the document IMA Recommended Practices for Enhancing Digital Audio Compatibility in MultimediaSystems (version 3.0). However, the Interactive MultimediaAssociation ceased operations in 1997. Resources for an archivedcopy of that document and a software implementation of the RTP DVI4 encoding are listed in Section 13.4.5.2 G722G722 is specified in ITU-T Recommendation G.722, "7 kHz audio-coding within 64 kbit/s". The G.722 encoder produces a stream of octets,each of which SHALL be octet-aligned in an RTP packet. The first bit transmitted in the G.722 octet, which is the most significant bit of the higher sub-band sample, SHALL correspond to the most significant bit of the octet in the RTP packet.Even though the actual sampling rate for G.722 audio is 16,000 Hz,the RTP clock rate for the G722 payload format is 8,000 Hz becausethat value was erroneously assigned in RFC 1890 and must remainunchanged for backward compatibility. The octet rate or sample-pair rate is 8,000 Hz.4.5.3 G723G723 is specified in ITU Recommendation G.723.1, "Dual-rate speechcoder for multimedia communications transmitting at 5.3 and 6.3kbit/s". The G.723.1 5.3/6.3 kbit/s codec was defined by the ITU-T as a mandatory codec for ITU-T H.324 GSTN videophone terminalapplications. The algorithm has a floating point specification inAnnex B to G.723.1, a silence compression algorithm in Annex A toG.723.1 and a scalable channel coding scheme for wirelessapplications in G.723.1 Annex C.This Recommendation specifies a coded representation that can be used for compressing the speech signal component of multi-media services at a very low bit rate. Audio is encoded in 30 ms frames, with anadditional delay of 7.5 ms due to look-ahead. A G.723.1 frame can be one of three sizes: 24 octets (6.3 kb/s frame), 20 octets (5.3 kb/s frame), or 4 octets. These 4-octet frames are called SID frames(Silence Insertion Descriptor) and are used to specify comfort noise parameters. There is no restriction on how 4, 20, and 24 octetframes are intermixed. The least significant two bits of the first octet in the frame determine the frame size and codec type:bits content octets/frame00 high-rate speech (6.3 kb/s) 2401 low-rate speech (5.3 kb/s) 2010 SID frame 411 reserved。
Network Working Group D. Thaler Request for Comments: 3559 Microsoft Category: Standards Track June 2003 Multicast Address Allocation MIBStatus of this MemoThis document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions forimprovements. Please refer to the current edition of the "InternetOfficial Protocol Standards" (STD 1) for the standardization stateand status of this protocol. Distribution of this memo is unlimited. Copyright NoticeCopyright (C) The Internet Society (2003). All Rights Reserved. AbstractThis memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for managingmulticast address allocation.Table of Contents1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 22. The Internet-Standard Management Framework . . . . . . . . . . 23. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 3.1. Protocol-independent objects . . . . . . . . . . . . . . 33.2. Protocol-specific objects. . . . . . . . . . . . . . . . 34. Definitions. . . . . . . . . . . . . . . . . . . . . . . . . . 45. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 326. Security Considerations. . . . . . . . . . . . . . . . . . . . 337. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 348. Intellectual Property Statement. . . . . . . . . . . . . . . . 349. References . . . . . . . . . . . . . . . . . . . . . . . . . . 35 9.1. Normative References . . . . . . . . . . . . . . . . . . 359.2. Informative References . . . . . . . . . . . . . . . . . 3510. Author’s Address . . . . . . . . . . . . . . . . . . . . . . . 3611. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 37 Thaler Standards Track [Page 1]1. IntroductionThis document defines a Management Information Base (MIB) module for managing multicast address allocation in a protocol-independentmanner, as well as for managing specific protocols used in allocating multicast addresses. The protocol-independent objects in this MIBapply to all multicast address allocation servers (MAASs) andclients, as described in [ARCH], including those that allocatesource-specific multicast addresses for the local machine.The protocol-specific objects in this MIB include objects related to the Multicast Address Dynamic Client Allocation Protocol (MADCAP)[MADCAP]. Interactions with the Multicast-scope Zone AnnouncementProtocol (MZAP) [MZAP] are also noted where appropriate.2. The Internet-Standard Management FrameworkFor a detailed overview of the documents that describe the currentInternet-Standard Management Framework, please refer to section 7 of RFC 3410 [RFC3410].Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. MIB objects are generallyaccessed through the Simple Network Management Protocol (SNMP).Objects in the MIB are defined using the mechanisms defined in theStructure of Management Information (SMI). This memo specifies a MIB module that is compliant to the SMIv2, which is described in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580[RFC2580].3. OverviewThe purpose of this MIB module is to provide the ability to configure and monitor the status of multicast address allocation within thelocal domain.Some important monitoring questions which can be answered by this MIB module include:o How full is scope X?o Who’s using up the space?o Who allocated a given address A?o Are requests being met?Thaler Standards Track [Page 2]This MIB module is divided into two primary sections:o Protocol-independent objects relevant to all multicast address allocation servers and clients.o Protocol-specific objects related to the MADCAP client-serverprotocol.3.1. Protocol-independent objectsThe protocol-independent objects consist of one "capabilities" scalar and five tables. The tables are:o The Scope Table contains information on the multicast scopesknown to a multicast address allocation server. This tableallows configuring scopes, and viewing what scopes are known to the local system after being configured elsewhere.o The Scope Name Table contains the names of the multicastscopes. This table logically extends the Scope Table with the list of scope names in various languages for each scope.o The Allocation Range Table contains the address ranges out ofwhich the device may allocate addresses. It also allowsanswering the questions "How full is scope X?" and "Arerequests being met?"o The Request Table contains the requests for addressallocations, and allows answering the question "Who’s using up the space?"o The Address Table contains the blocks of addresses which havebeen allocated, and together with the Request Table, allowsanswering the question "Who allocated a given address A?"3.2. Protocol-specific objectsThe MADCAP objects consist of a group of (scalar) configurationparameters, and a group of (scalar) statistics.Thaler Standards Track [Page 3]4. DefinitionsMALLOC-MIB DEFINITIONS ::= BEGINIMPORTSMODULE-IDENTITY, OBJECT-TYPE, OBJECT-IDENTITY, mib-2,Unsigned32, Gauge32, Counter32 FROM SNMPv2-SMIRowStatus, TruthValue, StorageType FROM SNMPv2-TCMODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONFInetAddress, InetAddressType FROM INET-ADDRESS-MIBLanguageTag FROM IPMROUTE-STD-MIBSnmpAdminString FROM SNMP-FRAMEWORK-MIBIANAscopeSource, IANAmallocRangeSource FROM IANA-MALLOC-MIB; mallocMIB MODULE-IDENTITYLAST-UPDATED "200306090000Z" -- June 9, 2003ORGANIZATION "IETF MALLOC Working Group"CONTACT-INFO" WG-EMail: malloc@Subscribe: malloc-request@Archive: /pub/multicast/malloc/Co-chair/editor:Dave ThalerMicrosoft CorporationOne Microsoft WayRedmond, WA 98052EMail: dthaler@Co-chair:Steve HannaSun Microsystems, Inc.One Network DriveBurlington, MA 01803EMail: steve.hanna@"DESCRIPTION"The MIB module for management of multicast addressallocation.Copyright (C) The Internet Society (2003). This version of this MIB module is part of RFC 3559; see the RFC itself for full legal notices."Thaler Standards Track [Page 4]-- revision logREVISION "200306090000Z" -- June 9, 2003DESCRIPTION"Initial version, published as RFC 3559."::= { mib-2 101 }mallocMIBObjects OBJECT IDENTIFIER ::= { mallocMIB 1 }malloc OBJECT IDENTIFIER ::= { mallocMIBObjects 1 }madcap OBJECT IDENTIFIER ::= { mallocMIBObjects 2 }---- scalars--mallocCapabilities OBJECT-TYPESYNTAX BITS {startTime(0),serverMobility(1),retryAfter(2)}MAX-ACCESS read-onlySTATUS currentDESCRIPTION"This object describes the capabilities which a client orserver supports. The startTime bit indicates thatallocations with a future start time are supported. TheserverMobility bit indicates that allocations can be renewed or released from a server other than the one granting theoriginal allocation. The retryAfter bit indicates supportfor a waiting state where the client may check back at alater time to get the status of its request."::= { malloc 1 }---- the Scope Table--mallocScopeTable OBJECT-TYPESYNTAX SEQUENCE OF MallocScopeEntryMAX-ACCESS not-accessibleSTATUS currentDESCRIPTION"The (conceptual) table containing information on multicast scopes from which addresses may be allocated. Entries inthis table may be dynamically discovered via some other Thaler Standards Track [Page 5]protocol, such as MZAP, or may be statically configured,such as in an isolated network environment. Each scope isassociated with a range of multicast addresses, and rangesfor different rows must be disjoint."::= { malloc 2 }mallocScopeEntry OBJECT-TYPESYNTAX MallocScopeEntryMAX-ACCESS not-accessibleSTATUS currentDESCRIPTION"An entry (conceptual row) containing the information on aparticular multicast scope."INDEX { mallocScopeAddressType, mallocScopeFirstAddress }::= { mallocScopeTable 1 }MallocScopeEntry ::= SEQUENCE {mallocScopeAddressType InetAddressType,mallocScopeFirstAddress InetAddress,mallocScopeLastAddress InetAddress,mallocScopeHopLimit Unsigned32,mallocScopeStatus RowStatus,mallocScopeSource IANAscopeSource,mallocScopeDivisible TruthValue,mallocScopeServerAddressType InetAddressType,mallocScopeServerAddress InetAddress,mallocScopeSSM TruthValue,mallocScopeStorage StorageType}mallocScopeAddressType OBJECT-TYPESYNTAX InetAddressTypeMAX-ACCESS not-accessibleSTATUS currentDESCRIPTION"The type of the addresses in the multicast scope range.Legal values correspond to the subset of address familiesfor which multicast address allocation is supported."::= { mallocScopeEntry 1 }mallocScopeFirstAddress OBJECT-TYPESYNTAX InetAddress (SIZE(0..20))MAX-ACCESS not-accessibleSTATUS currentDESCRIPTION"The first address in the multicast scope range. The typeof this address is determined by the value of themallocScopeAddressType object."Thaler Standards Track [Page 6]::= { mallocScopeEntry 2 }mallocScopeLastAddress OBJECT-TYPESYNTAX InetAddress (SIZE(0..20))MAX-ACCESS read-createSTATUS currentDESCRIPTION"The last address in the multicast scope range. The type of this address is determined by the value of themallocScopeAddressType object."::= { mallocScopeEntry 3 }mallocScopeHopLimit OBJECT-TYPESYNTAX Unsigned32 (0..255)MAX-ACCESS read-createSTATUS currentDESCRIPTION"The default IPv4 TTL or IPv6 hop limit which applicationsshould use for groups within the scope."DEFVAL { 255 }::= { mallocScopeEntry 4 }mallocScopeStatus OBJECT-TYPESYNTAX RowStatusMAX-ACCESS read-createSTATUS currentDESCRIPTION"The status of this row, by which new entries may becreated, or old entries deleted from this table. If writeaccess is supported, the other writable objects in thistable may be modified even while the status is ‘active’."::= { mallocScopeEntry 5 }mallocScopeSource OBJECT-TYPESYNTAX IANAscopeSourceMAX-ACCESS read-onlySTATUS currentDESCRIPTION"The method by which this entry was learned."::= { mallocScopeEntry 6 }mallocScopeDivisible OBJECT-TYPESYNTAX TruthValueMAX-ACCESS read-createSTATUS currentDESCRIPTION"If false, the server may allocate addresses out of theentire range. If true, the server must not allocateThaler Standards Track [Page 7]addresses out of the entire range, but may only allocateaddresses out of a subrange learned via another method.Creating or deleting a scope which is not divisible has the side effect of creating or deleting the corresponding entry in the mallocAllocRangeTable. Deleting a scope which isdivisible has the side effect of deleting any corresponding entries in the mallocAllocRangeTable, and themallocRequestTable."DEFVAL { false }::= { mallocScopeEntry 7 }mallocScopeServerAddressType OBJECT-TYPESYNTAX InetAddressTypeMAX-ACCESS read-createSTATUS currentDESCRIPTION"The type of the address of a multicast address allocationserver to which a request may be sent."DEFVAL { unknown }::= { mallocScopeEntry 8 }mallocScopeServerAddress OBJECT-TYPESYNTAX InetAddressMAX-ACCESS read-createSTATUS currentDESCRIPTION"The address of a multicast address allocation server towhich a request may be sent. The default value is an zero- length address, indicating that no server is known. Thetype of this address is determined by the value of themallocScopeServerAddressType object."DEFVAL { ’’h } -- the empty string::= { mallocScopeEntry 9 }mallocScopeSSM OBJECT-TYPESYNTAX TruthValueMAX-ACCESS read-createSTATUS currentDESCRIPTION"Indicates whether the scope is a Source-Specific Multicast (SSM) range."DEFVAL { false }::= { mallocScopeEntry 10 }mallocScopeStorage OBJECT-TYPESYNTAX StorageTypeMAX-ACCESS read-createSTATUS currentThaler Standards Track [Page 8]"The storage type for this conceptual row. Conceptual rows having the value ’permanent’ need not allow write-access to any columnar objects in the row."DEFVAL { nonVolatile }::= { mallocScopeEntry 11 }---- the Scope Name Table--mallocScopeNameTable OBJECT-TYPESYNTAX SEQUENCE OF MallocScopeNameEntryMAX-ACCESS not-accessibleSTATUS currentDESCRIPTION"The (conceptual) table containing information on multicast scope names. Entries in this table may be dynamicallydiscovered via some other protocol, such as MZAP, or may be statically configured, such as in an isolated networkenvironment."::= { malloc 3 }mallocScopeNameEntry OBJECT-TYPESYNTAX MallocScopeNameEntryMAX-ACCESS not-accessibleSTATUS currentDESCRIPTION"An entry (conceptual row) containing the information on aparticular multicast scope name."INDEX { mallocScopeAddressType, mallocScopeFirstAddress,IMPLIED mallocScopeNameLangName }::= { mallocScopeNameTable 1 }MallocScopeNameEntry ::= SEQUENCE {mallocScopeNameLangName LanguageTag,mallocScopeNameScopeName SnmpAdminString,mallocScopeNameDefault TruthValue,mallocScopeNameStatus RowStatus,mallocScopeNameStorage StorageType}mallocScopeNameLangName OBJECT-TYPESYNTAX LanguageTag (SIZE(1..94))MAX-ACCESS not-accessibleSTATUS currentThaler Standards Track [Page 9]"The RFC 3066 language tag for the language of the scopename."::= { mallocScopeNameEntry 1 }mallocScopeNameScopeName OBJECT-TYPESYNTAX SnmpAdminStringMAX-ACCESS read-createSTATUS currentDESCRIPTION"The textual name associated with the multicast scope. The value of this object should be suitable for displaying toend-users, such as when allocating a multicast address inthis scope. If the scope is an IPv4 scope, and no name isspecified, the default value of this object should be thestring 239.x.x.x/y with x and y replaced appropriately todescribe the address and mask length associated with thescope. If the scope is an IPv6 scope, and no name isspecified, the default value of this object shouldgenerically describe the scope level (e.g., site)."::= { mallocScopeNameEntry 2 }mallocScopeNameDefault OBJECT-TYPESYNTAX TruthValueMAX-ACCESS read-createSTATUS currentDESCRIPTION"If true, indicates a preference that the name in theassociated language should be used by applications if noname is available in a desired language."DEFVAL { false }::= { mallocScopeNameEntry 3 }mallocScopeNameStatus OBJECT-TYPESYNTAX RowStatusMAX-ACCESS read-createSTATUS currentDESCRIPTION"The status of this row, by which new entries may becreated, or old entries deleted from this table. If writeaccess is supported, the other writable objects in thistable may be modified even while the status is ‘active’."::= { mallocScopeNameEntry 4 }mallocScopeNameStorage OBJECT-TYPESYNTAX StorageTypeMAX-ACCESS read-createSTATUS currentThaler Standards Track [Page 10]DESCRIPTION"The storage type for this conceptual row. Conceptual rows having the value ’permanent’ need not allow write-access to any columnar objects in the row."DEFVAL { nonVolatile }::= { mallocScopeNameEntry 5 }---- the Allocation Range Table--mallocAllocRangeTable OBJECT-TYPESYNTAX SEQUENCE OF MallocAllocRangeEntryMAX-ACCESS not-accessibleSTATUS currentDESCRIPTION"The (conceptual) table containing information on subranges of addresses from which the device may allocate addresses,if it is a MAAS. If the device is a Prefix Coordinator, any ranges which the device is advertising to MAAS’s will be in this table. Note that the device may be both a MAAS and aPrefix Coordinator.Address ranges for different rows must be disjoint, and must be contained with the address range of the corresponding row of the mallocScopeTable.Deleting an allocation range has the side effect of deleting any entries within that range from the mallocAddressTable." ::= { malloc 4 }mallocAllocRangeEntry OBJECT-TYPESYNTAX MallocAllocRangeEntryMAX-ACCESS not-accessibleSTATUS currentDESCRIPTION"An entry (conceptual row) containing the information on aparticular allocation range."INDEX { mallocScopeAddressType, mallocScopeFirstAddress,mallocAllocRangeFirstAddress }::= { mallocAllocRangeTable 1 }MallocAllocRangeEntry ::= SEQUENCE {mallocAllocRangeFirstAddress InetAddress,mallocAllocRangeLastAddress InetAddress,mallocAllocRangeStatus RowStatus,mallocAllocRangeSource IANAmallocRangeSource,mallocAllocRangeLifetime Unsigned32,mallocAllocRangeMaxLeaseAddrs Unsigned32,Thaler Standards Track [Page 11]mallocAllocRangeMaxLeaseTime Unsigned32,mallocAllocRangeNumAllocatedAddrs Gauge32,mallocAllocRangeNumOfferedAddrs Gauge32,mallocAllocRangeNumWaitingAddrs Gauge32,mallocAllocRangeNumTryingAddrs Gauge32,mallocAllocRangeAdvertisable TruthValue,mallocAllocRangeTotalAllocatedAddrs Gauge32,mallocAllocRangeTotalRequestedAddrs Gauge32,mallocAllocRangeStorage StorageType}mallocAllocRangeFirstAddress OBJECT-TYPESYNTAX InetAddress (SIZE(0..20))MAX-ACCESS not-accessibleSTATUS currentDESCRIPTION"The first address in the allocation range. The type ofthis address is determined by the value of themallocScopeAddressType object."::= { mallocAllocRangeEntry 1 }mallocAllocRangeLastAddress OBJECT-TYPESYNTAX InetAddress (SIZE(0..20))MAX-ACCESS read-createSTATUS currentDESCRIPTION"The last address in the allocation range. The type of this address is determined by the value of themallocScopeAddressType object."::= { mallocAllocRangeEntry 2 }mallocAllocRangeStatus OBJECT-TYPESYNTAX RowStatusMAX-ACCESS read-createSTATUS currentDESCRIPTION"The status of this row, by which new entries may becreated, or old entries deleted from this table. If writeaccess is supported, the other writable objects in thistable may be modified even while the status is ‘active’."::= { mallocAllocRangeEntry 3 }mallocAllocRangeSource OBJECT-TYPESYNTAX IANAmallocRangeSourceMAX-ACCESS read-onlySTATUS currentDESCRIPTION"The means by which this entry was learned."Thaler Standards Track [Page 12]::= { mallocAllocRangeEntry 4 }mallocAllocRangeLifetime OBJECT-TYPESYNTAX Unsigned32UNITS "seconds"MAX-ACCESS read-createSTATUS currentDESCRIPTION"The number of seconds remaining in the lifetime of the(sub)range out of which addresses are being allocated. Avalue of 0 indicates that the range is not subject toaging."DEFVAL { 0 }::= { mallocAllocRangeEntry 5 }mallocAllocRangeMaxLeaseAddrs OBJECT-TYPESYNTAX Unsigned32MAX-ACCESS read-createSTATUS currentDESCRIPTION"The maximum number of addresses which the server is willing to grant for each future request in this range. A value of 0 means that no specific limit is enforced, as long as theserver has valid addresses to allocate."DEFVAL { 0 }::= { mallocAllocRangeEntry 6 }mallocAllocRangeMaxLeaseTime OBJECT-TYPESYNTAX Unsigned32UNITS "seconds"MAX-ACCESS read-createSTATUS currentDESCRIPTION"The maximum lifetime which the server will grant for future requests in this range. A value of 0 means that noadditional limit is enforced beyond that ofmallocAllocRangeLifetime."DEFVAL { 0 }::= { mallocAllocRangeEntry 7 }mallocAllocRangeNumAllocatedAddrs OBJECT-TYPESYNTAX Gauge32MAX-ACCESS read-onlySTATUS currentDESCRIPTION"The number of addresses in the range which have beenallocated. This value can be used to determine the current address space utilization within the scoped range. This Thaler Standards Track [Page 13]should match the total number of addresses for this scopecovered by entries in the mallocAddressTable."::= { mallocAllocRangeEntry 8 }mallocAllocRangeNumOfferedAddrs OBJECT-TYPESYNTAX Gauge32MAX-ACCESS read-onlySTATUS currentDESCRIPTION"The number of addresses in the range which have beenoffered. This number should match the sum ofmallocRequestNumAddrs for all entries in themallocRequestTable in the offered state. Together withmallocAllocRangeNumAllocatedAddrs andmallocAllocRangeNumTryingAddrs, this can be used todetermine the address space utilization within the scopedrange in the immediate future."::= { mallocAllocRangeEntry 9 }mallocAllocRangeNumWaitingAddrs OBJECT-TYPESYNTAX Gauge32MAX-ACCESS read-onlySTATUS currentDESCRIPTION"The number of addresses in the range which have beenrequested, but whose state is waiting, while the serverattempts to acquire more address space."::= { mallocAllocRangeEntry 10 }mallocAllocRangeNumTryingAddrs OBJECT-TYPESYNTAX Gauge32MAX-ACCESS read-onlySTATUS currentDESCRIPTION"The number of addresses in the scope covered by entries in the mallocRequestTable in the trying state."::= { mallocAllocRangeEntry 11 }mallocAllocRangeAdvertisable OBJECT-TYPESYNTAX TruthValueMAX-ACCESS read-createSTATUS currentDESCRIPTION"The value of this object is true if the range is eligibleto be advertised to other MAASs. When the row is firstcreated, the default value of this object is true if thescope is divisible, and is false otherwise."::= { mallocAllocRangeEntry 12 }Thaler Standards Track [Page 14]mallocAllocRangeTotalAllocatedAddrs OBJECT-TYPESYNTAX Gauge32MAX-ACCESS read-onlySTATUS currentDESCRIPTION"The approximate number of addresses in the range which have been allocated by any MAAS, as determined by a PrefixCoordinator. This object need only be present ifmallocAllocRangeAdvertisable is true. If the number isunknown, a value of 0 may be reported."::= { mallocAllocRangeEntry 13 }mallocAllocRangeTotalRequestedAddrs OBJECT-TYPESYNTAX Gauge32MAX-ACCESS read-onlySTATUS currentDESCRIPTION"The approximate number of addresses in the range for which there is potential demand among MAASs, as determined by aPrefix Coordinator. This object need only be present ifmallocAllocRangeAdvertisable is true. If the number isunknown, a value of 0 may be reported."::= { mallocAllocRangeEntry 14 }mallocAllocRangeStorage OBJECT-TYPESYNTAX StorageTypeMAX-ACCESS read-createSTATUS currentDESCRIPTION"The storage type for this conceptual row. Conceptual rows having the value ’permanent’ need not allow write-access to any columnar objects in the row."DEFVAL { nonVolatile }::= { mallocAllocRangeEntry 15 }---- the Request Table--mallocRequestTable OBJECT-TYPESYNTAX SEQUENCE OF MallocRequestEntryMAX-ACCESS not-accessibleSTATUS currentDESCRIPTION"The (conceptual) table containing information on allocation requests, whether allocated or in progress. This table may also be used to determine which clients are responsible for high address space utilization within a given scope.Thaler Standards Track [Page 15]Entries in this table reflect requests dynamically received by an address allocation protocol."::= { malloc 5 }mallocRequestEntry OBJECT-TYPESYNTAX MallocRequestEntryMAX-ACCESS not-accessibleSTATUS currentDESCRIPTION"An entry (conceptual row) containing the information on aparticular allocation request."INDEX { mallocRequestId }::= { mallocRequestTable 1 }MallocRequestEntry ::= SEQUENCE {mallocRequestId Unsigned32,mallocRequestScopeAddressType InetAddressType,mallocRequestScopeFirstAddress InetAddress,mallocRequestStartTime Unsigned32,mallocRequestEndTime Unsigned32,mallocRequestNumAddrs Unsigned32,mallocRequestState INTEGER,mallocRequestClientAddressType InetAddressType,mallocRequestClientAddress InetAddress,mallocRequestServerAddressType InetAddressType,mallocRequestServerAddress InetAddress,mallocRequestLeaseIdentifier OCTET STRING}mallocRequestId OBJECT-TYPESYNTAX Unsigned32 (1..4294967295)MAX-ACCESS not-accessibleSTATUS currentDESCRIPTION"An arbitrary value identifying this row."::= { mallocRequestEntry 1 }mallocRequestScopeAddressType OBJECT-TYPESYNTAX InetAddressTypeMAX-ACCESS read-onlySTATUS currentDESCRIPTION"The type of the first address of the scope to which therequest applies. Legal values correspond to the subset ofaddress families for which multicast address allocation issupported."::= { mallocRequestEntry 2 }Thaler Standards Track [Page 16]mallocRequestScopeFirstAddress OBJECT-TYPESYNTAX InetAddressMAX-ACCESS read-onlySTATUS currentDESCRIPTION"The first address of the scope to which the requestapplies. This must match mallocScopeFirstAddress for somerow in the mallocScopeTable. The type of this address isdetermined by the value of the mallocRequestScopeAddressType object."::= { mallocRequestEntry 3 }mallocRequestStartTime OBJECT-TYPESYNTAX Unsigned32UNITS "seconds"MAX-ACCESS read-onlySTATUS currentDESCRIPTION"The number of seconds remaining before the start time ofthe request. A value of 0 means that the allocation iscurrently in effect."::= { mallocRequestEntry 4 }mallocRequestEndTime OBJECT-TYPESYNTAX Unsigned32UNITS "seconds"MAX-ACCESS read-onlySTATUS currentDESCRIPTION"The number of seconds remaining before the end time of the request."::= { mallocRequestEntry 5 }mallocRequestNumAddrs OBJECT-TYPESYNTAX Unsigned32MAX-ACCESS read-onlySTATUS currentDESCRIPTION"The number of addresses requested. If the addresses havebeen allocated, this number should match the total number of addresses for this request covered by entries in themallocAddressTable."::= { mallocRequestEntry 6 }mallocRequestState OBJECT-TYPESYNTAX INTEGER {allocated(1),offered(2), -- tentatively allocatedThaler Standards Track [Page 17]waiting(3), -- waiting for more spacetrying(4) -- working on allocating}MAX-ACCESS read-onlySTATUS currentDESCRIPTION"The state of the request. A value of allocated(1)indicates that one or more entries for this request arepresent in the mallocAddressTable. A value of offered(2)indicates that addresses have been offered to the client(e.g. via a MADCAP OFFER message), but the allocation hasnot been committed. A value of waiting(3) indicates thatthe allocation is blocked while the server attempts toacquire more space from which it can allocate addresses. A value of trying(4) means that no addresses have been offered to the client, but that an attempt to allocate is inprogress."::= { mallocRequestEntry 7 }mallocRequestClientAddressType OBJECT-TYPESYNTAX InetAddressTypeMAX-ACCESS read-onlySTATUS currentDESCRIPTION"The type of the address of the client that (last) requested this allocation."::= { mallocRequestEntry 8 }mallocRequestClientAddress OBJECT-TYPESYNTAX InetAddressMAX-ACCESS read-onlySTATUS currentDESCRIPTION"The address of the client that (last) requested thisallocation. The type of this address is determined by thevalue of the mallocRequestClientAddressType object."::= { mallocRequestEntry 9 }mallocRequestServerAddressType OBJECT-TYPESYNTAX InetAddressTypeMAX-ACCESS read-onlySTATUS currentDESCRIPTION"The type of the address of the server to which the request was (last) sent."::= { mallocRequestEntry 10 }Thaler Standards Track [Page 18]。
