jedellnniu's profileWelcome my space's@jedel...PhotosBlogListsMore Tools Help

Blog


    January 30

    IETF RC 1213/RFC1213 MIB-Ⅱ

    发表于:2008年1月8日 13时19分38秒阅读(0)评论(0)特效:[图]
    本文链接: http://user.qzone.qq.com/249433686/blog/1199769578
    IETF RFC 1213/RFC1213
    链接地址: http://www.rfc-archive.org/getrfc.php?rfc=1213
    IETF RFC 1213 / RFC1213
     Management Information Base for Network Management of TCP/IP-based internets:MIB-II
    Network Working Group                                      K. McCloghrie
    Request for Comments: 1213                      Hughes LAN Systems, Inc.
    Obsoletes: RFC 1158                                              M. Rose
                                           Performance Systems International
                                                                     Editors
                                                                  March 1991

               Management Information Base for Network Management
                           of TCP/IP-based internets:
                                     MIB-II
     Status of this Memo
       This memo defines the second version of the Management Information
       Base (MIB-II) for use with network management protocols in TCP/IP-
       based internets.  This RFC specifies an IAB standards track protocol
       for the Internet community, and requests discussion and suggestions
       for improvements.  Please refer to the current edition of the "IAB
       Official Protocol Standards" for the standardization state and status
       of this protocol.  Distribution of this memo is unlimited.
     Table of Contents
       1. Abstract...............................................    2
       2. Introduction ..........................................    2
       3. Changes from RFC 1156 .................................    3
       3.1 Deprecated Objects ...................................    3
       3.2 Display Strings ......................................    4
       3.3 Physical Addresses ...................................    4
       3.4 The System Group .....................................    5
       3.5 The Interfaces Group .................................    5
       3.6 The Address Translation Group ........................    6
       3.7 The IP Group .........................................    6
       3.8 The ICMP Group .......................................    7
       3.9 The TCP Group ........................................    7
       3.10 The UDP Group .......................................    7
       3.11 The EGP Group .......................................    7
       3.12 The Transmission Group ..............................    8
       3.13 The SNMP Group ......................................    8
       3.14 Changes from RFC 1158 ................. .............    9
       4. Objects ...............................................   10
       4.1 Format of Definitions ................................   10
       5. Overview ..............................................   10
       6. Definitions ...........................................   12
       6.1 Textual Conventions ..................................   12
       6.2 Groups in MIB-II .....................................   13
       6.3 The System Group .....................................   13
    SNMP Working Group                                          Page 1 

    RFC 1213                         MIB-II                       March 1991

       6.4 The Interfaces Group .................................   16
       6.5 The Address Translation Group ........................   23
       6.6 The IP Group .........................................   26
       6.7 The ICMP Group .......................................   41
       6.8 The TCP Group ........................................   46
       6.9 The UDP Group ........................................   52
       6.10 The EGP Group .......................................   54
       6.11 The Transmission Group ..............................   60
       6.12 The SNMP Group ......................................   60
       7. Acknowledgements ......................................   67
       8. References ............................................   69
       9. Security Considerations ...............................   70
       10. Authors' Addresses ...................................   70
    1.  Abstract
       This memo defines the second version of the Management Information
       Base (MIB-II) for use with network management protocols in TCP/IP-
       based internets.  In particular, together with its companion memos
       which describe the structure of management information (RFC 1155)
       along with the network management protocol (RFC 1157) for TCP/IP-
       based internets, these documents provide a simple, workable
       architecture and system for managing TCP/IP-based internets and in
       particular the Internet community.
    2.  Introduction
       As reported in RFC 1052, IAB Recommendations for the Development of
       Internet Network Management Standards [1], a two-prong strategy for
       network management of TCP/IP-based internets was undertaken.  In the
       short-term, the Simple Network Management Protocol (SNMP) was to be
       used to manage nodes in the Internet community.  In the long-term,
       the use of the OSI network management framework was to be examined.
       Two documents were produced to define the management information: RFC
       1065, which defined the Structure of Management Information (SMI)
       [2], and RFC 1066, which defined the Management Information Base
       (MIB) [3].  Both of these documents were designed so as to be
       compatible with both the SNMP and the OSI network management
       framework.
       This strategy was quite successful in the short-term: Internet-based
       network management technology was fielded, by both the research and
       commercial communities, within a few months.  As a result of this,
       portions of the Internet community became network manageable in a
       timely fashion.
       As reported in RFC 1109, Report of the Second Ad Hoc Network
       Management Review Group [4], the requirements of the SNMP and the OSI
     
    SNMP Working Group                                          Page 2 

    RFC 1213                         MIB-II                       March 1991

       network management frameworks were more different than anticipated.
       As such, the requirement for compatibility between the SMI/MIB and
       both frameworks was suspended.  This action permitted the operational
       network management framework, the SNMP, to respond to new operational
       needs in the Internet community by producing this document.
       As such, the current network management framework for TCP/IP- based
       internets consists of: Structure and Identification of Management
       Information for TCP/IP-based internets, RFC 1155 [12], which
       describes how managed objects contained in the MIB are defined;
       Management Information Base for Network Management of TCP/IP-based
       internets: MIB-II, this memo, which describes the managed objects
       contained in the MIB (and supercedes RFC 1156 [13]); and, the Simple
       Network Management Protocol, RFC 1098 [5], which defines the protocol
       used to manage these objects.
    3.  Changes from RFC 1156
       Features of this MIB include:
       (1)  incremental additions to reflect new operational
            requirements;
       (2)  upwards compatibility with the SMI/MIB and the SNMP;
       (3)  improved support for multi-protocol entities; and,
       (4)  textual clean-up of the MIB to improve clarity and
            readability.
       The objects defined in MIB-II have the OBJECT IDENTIFIER prefix:
          mib-2      OBJECT IDENTIFIER ::= { mgmt 1 }
       which is identical to the prefix used in MIB-I.
    3.1.  Deprecated Objects
       In order to better prepare implementors for future changes in the
       MIB, a new term "deprecated" may be used when describing an object.
       A deprecated object in the MIB is one which must be supported, but
       one which will most likely be removed from the next version of the
       MIB (e.g., MIB-III).
       MIB-II marks one object as being deprecated:
          atTable

    SNMP Working Group                                          Page 3 

    RFC 1213                         MIB-II                       March 1991

       As a result of deprecating the atTable object, the entire Address
       Translation group is deprecated.
       Note that no functionality is lost with the deprecation of these
       objects: new objects providing equivalent or superior functionality
       are defined in MIB-II.
    3.2.  Display Strings
       In the past, there have been misinterpretations of the MIB as to when
       a string of octets should contain printable characters, meant to be
       displayed to a human.  As a textual convention in the MIB, the
       datatype
          DisplayString ::=
              OCTET STRING
       is introduced.  A DisplayString is restricted to the NVT ASCII
       character set, as defined in pages 10-11 of [6].
       The following objects are now defined in terms of DisplayString:
          sysDescr
          ifDescr
       It should be noted that this change has no effect on either the
       syntax nor semantics of these objects.  The use of the DisplayString
       notation is merely an artifact of the explanatory method used in
       MIB-II and future MIBs.
       Further it should be noted that any object defined in terms of OCTET
       STRING may contain arbitrary binary data, in which each octet may
       take any value from 0 to 255 (decimal).
    3.3.  Physical Addresses
       As a further, textual convention in the MIB, the datatype
          PhysAddress ::=
              OCTET STRING
       is introduced to represent media- or physical-level addresses.
       The following objects are now defined in terms of PhysAddress:
          ifPhysAddress
          atPhysAddress
          ipNetToMediaPhysAddress
     
    SNMP Working Group                                          Page 4 

    RFC 1213                         MIB-II                       March 1991

       It should be noted that this change has no effect on either the
       syntax nor semantics of these objects.  The use of the PhysAddress
       notation is merely an artifact of the explanatory method used in
       MIB-II and future MIBs.
     
    ...............

    RFC(Request for Comments)

     发表于:2008年1月8日 12时24分13秒阅读(0)评论(1)
    本文链接:http://user.qzone.qq.com/249433686/blog/1199766253RFC及RFC编辑者:
      RFC(Request For Comments)-意即“请求注解”,包含了关于Internet的几乎所有重要的文字资料。
    如果你想成为网络方面的专家,那么RFC无疑是最重要也是最经常需要用到的资料之一,所以RFC享有网络知识圣经之美誉。
    通常,当某家机构或团体开发出了一套标准或提出对某种标准的设想,想要征询外界的意见时,就会在Internet上发放一份RFC,
    对这一问题感兴趣的人可以阅读该RFC并提出自己的意见;绝大部分网络标准的指定都是以RFC的形式开始,
    经过大量的论证和修改过程,由主要的标准化组织所指定的,但在RFC中所收录的文件并不都是正在使用或为大家所公认的,
    也有很大一部分只在某个局部领域被使用或并没有被采用,一份RFC具体处于什么状态都在文件中作了明确的标识
      
           RFC由一系列草案组成,起始于1969年(第一个RFC文档发布于1969年4月7日,参见“RFC30年”,RFC2555”),
    RFC文档是一系列关于Internet(早期为ARPANET)的技术资料汇编。这些文档详细讨论了计算机网络的方方面面,
    重点在网络协议,进程,程序,概念以及一些会议纪要,意见,各种观点等。
      “RFC编辑者”是RFC文档的出版者,它负责RFC最终文档的编辑审订。“RFC编辑者”也保留有RFC的主文件,称为RFC索引,
    用户可以在线检索。在RFC近30年的历史中,“RFC编辑者”一直由约翰?普斯特尔(Jon Postel)来担任,而现在“RFC编辑者”
    则由一个工作小组来担任,这个小组受到“因特网社团”(Internet Society)的支助。
      RFC编辑者负责RFC以及RFC的整体结构文档,并维护RFC的索引。Internet协议族的文档部分(由Internet工程委员会“因特网工程师任务组”IETF
    以及IETF 下属的“因特网工程师指导组”IESG 定义),也做为RFC文档出版。因此,RFC在Internet相关标准中有着重要的地位。
      RFC编辑者的职责是由Internet 中的大家提议形成的,所出版的语言也就和Internet一样。IETF和ISOC是代表了世界各地的国际性组织,
    英语是IETF的第一工作语言,也是IETF的正式出版语言。RFC 2026 "The Internet Standards Process -- Revision 3" 允许RFC翻译成其他不同的语言。
    但是不能保证其翻译版本是否正确。因此,RFC编辑不对非英语的版本负责,而只是指明了哪里有非英语的版本,将这些信息列在WEB页上。
    RFC处理过程:
      一个RFC文件在成为官方标准前一般至少要经历三个阶段:建议标准、草案标准、因特网标准。
    第一步RFC的出版是作为一个Internet 草案发布,可以阅读并对其进行注释。准备一个RFC草案,我们要求作者先阅读IETF的一个文档"Considerations for Internet Drafts". 它包括了许多关于RFC以及Internet草案格式的有用信息。作者还应阅读另外一个相关的文档RFC 2223 "Instructions to Authors"。
      一旦文档有了一个ID号后,你就可以向rfc-editor@rfc-editor.org发送e-mail ,说你觉得这个文档还可以,能够作为一个有价值或有经验的RFC文档 。RFC编辑将会向IESG请求查阅该文档并给其加上评论和注释。你可以通过RFC队列来了解你的文档的进度。一旦你的文档获得通过,RFC编辑就会将其编辑并出版。如果该文档不能出版,则会有email通知作者是什么原因。作者有48个小时来校对RFC编辑的意见。我们强烈建议作者要检测拼写错误和丢字的错误,应该确保有引用,联系和更新相关的信息。如你的文档是一个MIB,我们则要你对你的代码作最后一次检测。一旦RFC文档出版,我们就不会对其进行更改,因此你应该对你的文档仔细的检查。
      有时个别的文档会被正从事同一个项目的IETF工作组收回,如是这种情况,则该作者会被要求和IETF进行该文档的开发。在IETF中, Area Directors (ADs) 负责相关的几个工作组。这些工作者所开发的文档将由ADs 进行校阅,然后才作为RFC的出版物。
    如要获得关于如何写RFC文档和关于RFC的Internet标准制定过程的更多详细信息,请各位参见:
    RFC 2223 "Instructions to RFC Authors"。
    RFC 2026 "The Internet Standards Process -- Revision 3"。
      实际上,在Internet上,任何一个用户都可以对Internet某一领域的问题提出自己的解决方案或规范,作为Internet草案(Internet Draffs,ID)提交给Internet工程任务组(IETF)。草案存放在美国、欧洲和亚太地区的工作文件站点上,供世界多国自愿参加的IETF成员进行讨论、测试和审查。最后,由Internet工程指导组(IESG)确定该草案是否能成为Internet的标准。
      如果一个Internet草案在IETF的相关站点上存在6个月后仍未被IESG建议作为标准发布,则它将被从上述站点中删除。事实上,在任何时候,一个Internet 草案都有可能被新的草案版本所替换掉,并重新开始6个月的存放期。
    如果一个Internet草案被IESG确定为Internet的正式工作文件,则被提交给Internet体系结构委员会(IAB),并形成具有顺序编号的RFC文档,由Internet协会(ISOC)通过Internet向全世界颁布。每个Internet标准文件在被批准后都会分配一个独立于RFC的永久编号,这就是STD编号。有一个不断被更新的文件RFC-INDEX.TXT按照RFC的编号来索引所有的文件,对于因特网标准文件还列出了其相应的STD编号。
    RFC文档必须被分配RFC编号后才能在网络上发布。例如,RFC2026的内容是“Internet标准进程-修订版3”、RFC1543的内容为“RFC作者指导”等等。需要时,可以复制或打印这些联机文档。用户也可以通过遍布全世界的数个联机资料数据库中获得RFC文档。例如,可以使用路径名RFC/RFCnnnn.TXT通过FTP的方式从ds.internic.net站点获得RFC,其中“nnnn”指的是RFC的编号。在这里,使用FTP登录时,所用的用户名和口令分别为“anonymous”和你的电子邮件地址。此外,用户还可以通过Internet网络信息中心(InterNIC)的目录服务功能、电子邮件、WWW等方式获得RFC文档.
      作为标准的RFC又分为几种,第一种是提议性的,就是说建议采用这个作为一个方案摆出来,Draft是已经有一部分在用了,希望被采用为正式的标准,还有一种就是完全被认可的标准,这种是大家都在用,而且是不应该改变的。还有一种就是现在的最佳实践法,它相当于一种介绍。这些文件产生的过程是一种从下往上的过程,而不是从上往下,也就是说不是一个由主席,或者由工作组负责人的给一个指令,说是要做什么,要做什么,而是有下边自发的提出,然后在工作组里边讨论,讨论了以后再交给刚才说的工程指导委员会进行审查。但是工程指导委员会只做审查不做修改,修改还是要打回到工作组来做。IETF工作组文件的产生就是任何人都可以来参加会议,任何人都可以提议,然后他和别人进行讨论,大家形成了一个共识就可以产出这样的文件。
    January 29

    [顶]FCAPS的解释

    表于:2008年1月8日 11时22分39秒阅读(1)评论(0)
    文链接:http://user.qzone.qq.com/249433686/blog/1199762559
     
    fcaps是国际电联的标准模型,为企业管理水平。
    The five FCAPS domains are:五fcaps领域分别是:
    F ault Management f ault      故障管理
    C onfiguration Management   配置管理
    A ccounting Management A ccounting      计费管理
    P erformance Management p erformance     性能管理
    S ecurity Management     安全管理
     
    Fault Management故障管理
    Fault management is the domain where network problems are discovered and corrected.故障管理是域网络的地方,发现问题和纠正。
    Steps are then taken to prevent them from occurring or recurring.步骤,然后采取,以防止他们发生或复发。
    By doing so, the network remains operational and downtime is minimized.这样,网络仍然是业务和停机时间减少到最低限度。
    Configuration Management配置管理
    Configuration management is where daily operations are monitored and controlled.配置管理是日常运作进行监控和控制。
    All hardware and programming changes are coordinated.所有的硬件和节目的变化,重视协调发展。
    In addition, new programs, new equipment, modification of existing systems and the removal of obsolete systems and programs are also coordinated.此外,新节目,新设备,改造现有的制度和去除过时的制度和程序也相协调。
    Accounting Management 计费管理
    Accounting management is devoted to determining how to optimally distribute resources among enterprise subscribers.会计管理,是专门以确定如何以最佳方式分配资源,其中企业用户。
    This helps to minimize the cost of operations by making the most effective use of the systems available.这有利于最大限度地减少经营成本,使最有效地利用该系统提供的。
    This level is also responsible for ensuring the appropriate billing of users.这一级也有责任确保适当的计费用户。
    Performance Management 性能管理
    Performance management is involved in managing the overall performance of the enterprise network.绩效管理是参与管理的整体表现,企业网络。 Potential problems are identified, throughput is maximized and bottlenecks are identified.潜在问题,确定后,吞吐量最大化和瓶颈确定。 Improvements that will yield the greatest enhancement to overall performance are identified.改善,将能取得最大的提升,以整体表现确定。
    Security Management安全管理
    Security management is responsible for protecting the network from unauthorized users and physical and electronic sabotage.安全管理是负责保护网络免受未经授权的用户和物理和电子破坏。
    Security management is responsible for user authentication and authorization.安全管理部门负责用户认证和授权。
    It also maintains the confidentiality of user information.它也保持了保密的用户信息。