Based on TCP / IP networks 1. Introduction This article describes general structures and methods for managing TCP / IP networks. This article does not explain the specific solution, nor the protocol and data structure, and if you need this, please refer to the description of SNMP and MIB. In the IEEE, there is an article about Internet management structure and methods. This article basically comes from this article, but there is different: that article mainly shows the management of the OSI type network, and does not apply for SNMP. This article has to achieve two goals: versatility and scalability, although network management has been launched for many years, but the depth and breadth of understanding of this problem are not necessarily. By giving a universal SMI, you can lay a foundation for future development. 2. Structure and Marking Management Objects Structure and Marking Access by virtual information, we call this structure to manage information libraries or MIBs. The objects in the MIB are defined by ASN.1. Each object has its own name, syntax, and encoding. The name is like an object tag, which is a name of management management. The request of the object type defines the abstract data structure that is consistent with the object type. Although this can be defined by ASN.1, it still limits in this article. This limitation is more general for the definition. Object Type Coding Description Object Type of instances are expressed by the type of object of the object. The syntax and encoding of the object are usually connected through the definition of the object, which is also the form of the object to transmit on the network. As for the definition of MIB or management protocols, this is not the work of this article, this article is just a general principle of a generality. Of course, at some time, the definition has also been restricted, which is for a particular manner, which can be used without tuberculosis when specific implementation. 2.1 Name Name is used to mark management objects. The object tag concept is used to define. Regardless of the semantics of the object, the object mark is a method of determining certain objects. Object markers are based on overall strings. This tree is connected to some marked nodes. Each node has a sub-node. Our understanding of object markers should be based on the overall trees. A marker is a simple text description and an integer. The root node is not marked, it must be at least three sub-nodes, a sub-node is managed by international standardized organization, marked as ISO (1); another is managed by ccitt, marked as ccitt (0); third by two To manage, marked as: Joint-ISO-CCITT (2). Under ISO (0), ISO has a subtree for other international organizations, org (3), for sub-nodes, two left to US National Standards and Technical Bureau, another transfer from NIST to US Department of Defense DOD (6). For this paper, DOD does not specify how it manages its own object marker subtree. This article assumes that the DOD will be divided into the Internet, which manages by IAB by the following manner: Internet Object Identifier :: = {Iso ORG (3) DOD (6) 1} That is, the object marked Internet subtree is 1.3. 6.1 Start. This paper shows the standard of IAB agreed by the IAB, indicating the strategy of managing object marking subtro. Initially, the four nodes is such that: directory OBJECT IDENTIFIER :: = {internet 1} mgmt OBJECT IDENTIFIER :: = {internet 2} experimental OBJECT IDENTIFIER :: = {internet 3} private OBJECT IDENTIFIER :: = {internet 4 } 2.1.1. Directory Directory (1) How the child is remaining after the OSI directory is used as an Internet directory. 2.1.2. MGMT MGMT (2) Sub tree is used to mark objects defined in the IAB file.
For example, if the RFC of the initial Internet standard MIB is specified as a Manage Document No. 1, this RFC can be used as an object tag: {mgmt 1} or 1.3.6.1.2.1 to define the Internet standard MIB. The second half of this article will define a new MIB standard. 2.1.3. Experimental Experimental (3) The subtree defines the objects used for Internet experiments. For example, the experimenter may receive the definition number 17, which is: {Experimental 17} or 1.3.6.1.3.17. IANA is made on how to use this subtree. 2.1.4. Private private (4) Sub tree is used to define other objects. This subtree has only one child: Enterprises Object Identifier :: = {Private 1} You can allow a mechanism for providing a network subsystem to register a model of the product when using Enterprises Object Identifier :: = {Private 1}. When receiving a subtree, a company can define a new MIB object in the subtree. And this company should also register its network subsystem under this subtree, which can be effectively managed in the management protocol. For example, if "FlintStones, Inc." produces the network subsystem, it requires a node under the corporate sub-tree, which may be numbered as follows: 1.3.6.1.4.1.42, it may be registered here Its own router is: 1.3.6.1.4.1.42.1.1 2.2. Syndrome syntax is to define an object structure according to the object type, define the use of ASN.1, but some of the generalization needs in ASN.1 needs to be restricted. ObjectSyntax defines syntax available for different object types. 2.2.1. Original type in the original type ASN.1 includes Integer, OcTet String, Object Identifier, and Null. If an enumeration integer is listed as an object type, the name of the owner 0 should not appear in the enumeration list and cannot be used. 2.2.2. SEQUENCE in the configuration type ASN.1 is available, use it to build a column or table. For columns, the syntax is as follows: Sequence {
2.3. After the instance of the object type, its value can transmit the basic coding rules of ASN.1 for the syntax of the object type. 3. Management Object This article does not define the MIB object, but this article specifies a format that can be used by other articles. An object definition typically includes the following five domains: Object: is a string name, called Object Descriptor, which specifies the object type, which corresponds to Object Identifier. Grammar: Abstract syntax of object types. It must be resolved on an instance of ASN.1 type ObjectSyntax. Definition: Text description of the semantic semantics of the object type. Implementation must ensure that the object's instance meets this definition, as this MIB is used in multi-vendor environment, to take care of them. Objects have the same significance on different machines. Access: Take read read, read and write, write or not access these four values. Status: Mandatory, optional or Obsolete. Other domains may be defined in future documents. 3.1. The object name cannot be 0 in the object name in the MIB in the Internet standard, and this value is left as an extension. Object Descriptor of each and object types should have unique, memory and printed characters. This is very beneficial for people's reading and development of object user interfaces. 3.2. Object type and instance an object type is a definition of a class of manageable objects, and the object instance is an instance of an object type, and this instance already has a value. For example, the definition of the routing table entry has been defined in the MIB, this definition, and an object type, the value in the single entry of the given routing table is an example of the object type. Many object types are defined in the MIB, each type through the Object Identifier tag, and there is a text name called Object Descriptor. This indicates that data in the MIB is determined by a particular protocol without being specified by a particular protocol. An object type can be defined in the MIB, such an instance of an object type can represent a collection of some information and is also represented by instances of some secondary object type models. For example, suppose the following objects are defined in the MIB: OBJECT: atIndex {atEntry 1} Syntax: INTEGERDefinition: Physical interface number address Access: read-write.Status: mandatory OBJECT:. AtPhysAddress {atEntry 2} Syntax: OCTET STRINGDefinition : The physical address associated with the media Access: read-write.status: Mandatory. Object: atnetdress {facentry 3} Syntax: NetworkAddressDefinition: Network Address: Read-Write.status: Mandatory. Fourth object types may be defined in the MIB: OBJECT: atEntry {atTable 1} Syntax: atEntry :: = SEQUENCE {atIndexINTEGER, atPhysAddressOCTET STRING, atNetAddressNetworkAddress} Definition: entry in the address mapping table Access: read-write.Status: mandatory Each object type is the information that is represented by the first three object type instances. Type this defined object type is called a list (List). Similarly, a collection of list types can make a table (Table).
For example, the definition of the fifth object is as follows: Object: attable {at 1} Syntax: Sequence of ATENTRYDEFINITION: Add-Write.status: read-write.status: Mandatory. The address mapping table above is composed of a collection of ATENTRY. Let us think about how to get objects in the table. Let's take an example below, below is an object type: {atphysaddress} and below is an object instance related to the protocol: {atnetdress} = {Internet "10.0.0.52"} The two amounts of this two amounts will be able to refer to Atphysaddress Example. The atphyaddress here is part of any address mapping table entry with atnetAddress correlation value {Internet "10.0.0.52}. Let's see how to access the collection object (list) in a package, name the object type: {aTentry} The object instance related to the protocol is then specified: {atNetAddress} = {Internet "10.0.52"} The above object instance accesss all instances of the entrance in the table, where the table is related to the value {Internet "10.0.0.52"} of AtnetAddress. The management protocol provides a mechanism for accessing non-collection object types, and each management protocol also illustrates whether it supports access to a collection object type. Moreover, the protocol must specify if an object type / instance is returned when accessing multiple types of instances Which instance. To support different management protocols, all information enabled by the object can be distinguished by the object type instance of the object type. 3.3. Management object macro can use the Object-Type macro to process the definition in the MIB. This macro allows one The main access of the object type takes a unified representation.
Object-type macro :: = begintype notation :: = "Syntax" Type (Type Objectsyntax "Access" attess "status" statusvalue notation :: = value (value Objectname) Access :: = "read-only" | Read- Write | "Write-Only" | "not-accessible" status :: = "mandatory" | "OPTIONAL" | "OBSOLETE" END According to the object type defined above, we can see the definition below defined in the MIB: AtIndex OBJECT-TYPESYNTAX INTEGERACCESS read-writeSTATUS mandatory :: = {atEntry 1} atPhysAddress OBJECT-TYPESYNTAX OCTET STRINGACCESS read-writeSTATUS mandatory :: = {atEntry 2} atNetAddress OBJECT-TYPESYNTAX NetworkAddressACCESS read-writeSTATUS mandatory :: = {atEntry 3} atEntry OBJECT -TYPESYNTAX AtEntryACCESS read-writeSTATUS mandatory :: = {atTable 1} atTable OBJECT-TYPESYNTAX SEQUENCE OF AtEntryACCESS read-writeSTATUS mandatory :: = {at 1} atEntry :: = SEQUENCE {atIndexINTEGER, atPhysAddressOCTET STRING, atNetAddressNetworkAddress} 4. MIB extensions each The Internet standard MIB document marks the previous document as an outdated. The name marked in the following marks is not changed when changing the version: {mgmt version-number} The new version can announce the old object type, but do not delete their name; by adding non-collection object types to list (List) The object type is extended to define the definition of an object type; or if you define a new object. The new version cannot change the semantics of the object without changing the name of the object. This ensures that the same name will have the same semantics in different versions, so that it is more convenient to implement it. However, management representatives may return an object, which is a supercoming of the object. Considering robustness, the management procedure should ignore these additional information. But we have to pay attention: If an instance does not have the same syntax with the hoped object type, the control will fail. In the case of monitoring and control, the object name returned by an operation must be consistent with the object name of the operation requirements.
The definition of RFC1155-SMI DEFINITIONS :: = BEGINEXPORTS - EVERYTHINGinternet, directory, mgmt, experimental, private, enterprises, OBJECT-TYPE, ObjectName, ObjectSyntax, SimpleSyntax, ApplicationSyntax, NetworkAddress, IpAddress, Counter, Gauge, TimeTicks, Opaque; - - the path to the rootinternet OBJECT IDENTIFIER :: = {iso org (3) dod (6) 1} directory OBJECT IDENTIFIER :: = {internet 1} mgmt OBJECT IDENTIFIER :: = {internet 2} experimental OBJECT IDENTIFIER :: = { internet 3} private OBJECT IDENTIFIER :: = {internet 4} enterprises OBJECT IDENTIFIER :: = {private 1} - definition of object typesOBJECT-tYPE MACRO :: = BEGINTYPE NOTATION :: = "SYNTAX" type (tYPE ObjectSyntax) "ACCESS "Access" status "statusvalue notation :: = value (value Objectname) Access :: =" read-only "|" read-write "|" write-only "|" not-accessible "status :: =" MANDATORY "| "OPTIONAL" | "Obsolete" end-- names of objects in the mibibjectname :: = Object Identifier - syntax of objects in the mibibjectsyntax :: = choاax :: = choiefsystem {SimpleSimpleSystemax, - Note That simple SEQUENCEs are not directly-- mentioned here to keep things simple (ie, - prevent mis-use). However, application-wide-- types which are IMPLICITly encoded simple-- SEQUENCEs may appear in the following CHOICEapplication-wideApplicationSyntax} SimpleSyntax :: = CHOICE {numberINTEGER, stringOCTET STRING, objectOBJECT IDENTIFIER, emptyNULL} ApplicationSyntax :: = CHOICE {addressNetworkAddress, counterCounter, gaugeGauge, ticksTimeTicks, arbitraryOpaque-- other application-wide types, as they are-- defined, will be added here} - Application-Wide TypesNetworkAddress :: =
