INTERNET-DRAFT Liu Yunxin Tsinghua University, P.R.China Zhang Yaoxue Tsinghua University, P.R.China December 2000 A Home Network Management Protocol (HNMP) Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Copyright Notice Copyright (C) The Internet Society (2000). All Rights Reserved. Abstract This memo defines Home Network Management Protocol (HNMP) as an application-level protocol, by which users can monitor and control the statuses and attributes of home network devices remotely. Together with our extensions of the Internet-standard MIB [1], the HNMP provides a simple, workable and flexible manner to manage and control home network. This document explains the HNMP model, the extensions of the Internet-standard MIB and the HNMP specification. Terminology In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in RFC 2119. Table of Contents 1. Introduction 2. The HNMP Model 2.1 The Architecture of the HNMP Model 2.2 Features of the HNMP Model 3. Management Information Base 3.1 Common Management Objects 3.2 The hnmpPrivate Subtree 3.3 The hnmpEnterprises Subtree 3.4 References to Management Objects 3.4.1 Resolution of Ambiguous MIB References 3.4.2 Resolution of References across MIB Versions 3.4.3 Identification of Object Instances 4. Protocol Specification 4.1 Message Exchange 4.2 Common Constructs 4.3 The Register-PDU 4.4 The Update-PDU 4.5 The Set-PDU 4.6 The Response-PDU 4.7 The Trap-PDU 4.7.1 The restart Trap 4.7.2 The linkDown Trap 4.7.3 The linkUp Trap 4.7.4 The enterpriseSpecific Trap 5. Definitions 5.1 Definitions of Management Objects 5.2 Definitions of the HNMP 6. Acknowledgements 7. References 8. Security Considerations 9. Author's Address 1. Introduction In a home environment, generally there are electrical appliances, electronic appliances, communication appliances and information appliances, such as microwave oven, VCR (Video Casstte Recorder), telephone, computer and so on. With the increasing development of embedded technology and network technology, more and more electrical and electronic devices (or called consumer electronics) have embedded operating systems running on. They can communicate with each other in various transport manners and compose a digital home network. With a home gateway, a home network is connected to Internet. In a home network, it is very important to manage and control the attributes and actions of all kinds of devices. Furthermore, it will be very convenient if we can manage and control home network devices remotely. For example, when you are in office, you may expect your recorder to record your favorite TV programs, so that you can enjoy them when you return. There are some technologies for home network devices interconnection and management, such as HAVi, Jini and so on. However, these technologies are very complex and require that the managed devices have strong computing ability. Furthermore, these technologies aren't focused on managing and controlling devices remotely, but on the interoperating between devices. In this specification, we define an application-level protocol, Home Network Management Protocol (HNMP), to manage and control home network devices. In particular, using this protocol along with the relevant management information base, a user can monitor and control all home network devices remotely. 2. The HNMP Model Before discussing the HNMP, it is appropriate to introduce the HNMP model firstly. 2.1 The Architecture of the HNMP Model The HNMP model is a model which manages home network by use of the HNMP. It is composed of a home network management station, some managed devices, a management information base and the HNMP. The home network management station executes management application, called HNMP manager, which monitors and controls all the home network devices. Still, it should have a management interface (in command line manner or WWW manner) for users. Managed devices refer to devices in a home network, such as digital TV, intelligent refrigerator, and so on, which have HNMP agents responsible for registering and updating management information with the HNMP manager and performing the management functions requested by the HNMP manager. The management information base stores the management information that describes the attributes and actions of managed devices. It is maintained by the HNMP manager. The Home Network Management Protocol (HNMP) is used to exchange management information between the HNMP manager and HNMP agents. The HNMP manager and HNMP agents should completely trust each other entirely and no authentication is needed between them. 2.2 Features of the HNMP Model The first feature of the HNMP model is simplicity, which means it minimizes the complexity of management functions implemented by the HNMP agent itself. In the HNMP model, the management information base is maintained by the HNMP manager, and HNMP agents are only needed to finish the most necessary work. For some devices, such as a desk lamp, it is impossible to run a complex system, so simplicity is important and necessary. The HNMP model provides a uniform and simple manner to manage all kinds of home network devices, thus it can reduce the development cost for HNMP agent software necessary to support the HNMP. The second feature of the HNMP model is extensibility. There are various network devices in a home network, and each kind of device has different functions and attributes, so the functional paradigm for management and control should be sufficiently extensible to accommodate various home network devices. By extending the Internet-standard MIB with a proper method, we can assure the extensibility. In addition, the HNMP model is independent of the architecture and mechanisms of particular software or hardware platforms. It can be implemented based on TCP/IP protocols or other network protocols. Furthermore, it doesn't care about which kind of physical medium is used. 3. Management Information Base To describe the attributes and actions of various network devices in home network, we have to extend the Internet-standard MIB. Following the rules requested in RFC 1155, we define an hnmp subtree under the mib-2 node. All object types relating to home network management are defined under the hnmp subtree: hnmp OBJECT IDENTIFIER ::= { mib-2 xx } Here, xx is the number of the hnmp subtree. It should be assigned by the Internet Activities Board. 3.1 Common Management Objects We define six common object types under the hnmp subtree to describe the most common attributes and actions of home network devices. Implementation of these six objects is mandatory for all systems. OBJECT: ------- hnmpSysDescr { hnmp 1 } Syntax: DisplayString (SIZE (0..255)) Definition: A textual description of the device. This value should include the full name and version identification of the system's hardware type, software operating-system, and networking software. It is mandatory that this only contains printable ASCII characters. Access: read-only. Status: Mandatory. OBJECT: ------- hnmpSysObjectID { hnmp 2 } Syntax: OBJECT IDENTIFIER Definition: The vendor's authoritative identification of the network management subsystem on the device. This value is allocated within the hnmpenterprises subtree (1.3.6.1.2.1.12.8) and provides an easy and unambiguous means for determining "what kind of box" is being managed. For example, if vendor "RedStar, Inc." was assigned the subtree 1.3.6.1.2.1.12.8.42, it could assign the identifier 1.3.6.1.2.1.12.8.42.1.1 to its "RedStar Air-condition". Access: read-only. Status: Mandatory. OBJECT: ------- hnmpSysUpTime { hnmp 3 } Syntax: TimeTicks Definition: The time (in hundredths of a second) since the network management portion of the system was last re-initialized. Access: read-only. Status: Mandatory. OBJECT: ------- hnmpSysName { hnmp 4 } Syntax: DisplayString (SIZE (0..255)) Definition: An administratively-assigned name for the managed device. Access: read-write. Status: Mandatory. OBJECT: ------- hnmpSysStatus { hnmp 5 } Syntax: INTEGER { play(1), stop(2), pause(3) } Definition: The running states of the managed device. Access: read-write. Status: Mandatory. OBJECT: ------- hnmpIpAddress { hnmp 6 } Syntax: IpAddress Definition: The IP address of the managed device. Access: read-only. Status: Mandatory. 3.2 The hnmpPrivate Subtree To describe the special attributes and actions of each kinds of home network device, we define a hnmpPrivate subtree under the hnmp subtree. hnmpPrivate OBJECT IDENTIFIER ::= { hnmp 7 } Under the hnmpPrivate subtree, we define a node for each kind of device. Under the node we define all management objects that describe the attributes and actions peculiar to the kind of device. For example, we define an air-condition node for all air-condition devices under the hnmpPrivate subtree: air-condition OBJECT IDENTIFIER ::= { hnmpPrivate 1 } To describe the attribute "temperature" of air-condition devices, we define an object type under the air-condition node: OBJECT: ------- temperature { air-condition 1 } Syntax: INTEGER Definition: The temperature of air-condition devices. Access: read-write. Status: Mandatory. By operating the instance of the object type "temperature", we can control the temperature of air-condition devices remotely. 3.3 The hnmpEnterprises Subtree To identify devices in home network, we define a hnmpEnterprises subtree under the hnmp subtree: hnmpEnterprises OBJECT IDENTIFIER ::= { hnmp 8 } In order to provide an unambiguous identification mechanism, each enterprise that produces home network devices should register its home network products under this subtree,. For example, if "RedStar, Inc." produces home network devices, it should register a node under the hnmpEnterprises subtree. Such a node might be numbered: 1.3.6.1.2.1.12.8.42 Then "RedStar, Inc." may register its "RedStar Air-condition" under the name of: 1.3.6.1.2.1.12.8.42.1.1 3.4 References to Management Objects The scope of the management information exchanged within the HNMP is exactly represented by instances of all object types defined under the hnmp subtree. These object types are defined according to the conventions set forth in Internet-standard SMI [2]. To achieve simplicity, management information exchanged within the HNMP is represented according to a mere subset of the ASN.1 language [3][4]. The subset is specified for the definition of non-aggregate types in the SMI. The SMI requires that the definition of a conformant management protocol address: (1) the resolution of ambiguous MIB references, (2) the resolution of MIB references in the present multiple MIB versions, and (3) the identification of particular instances of object types defined in the MIB. 3.4.1 Resolution of Ambiguous MIB References Because the scope of any HNMP operation is confined to objects relevant to a single home device, and because all HNMP references to MIB objects are (implicitly or explicitly) by unique variable names, there is no possibility that any HNMP reference to any object type defined in the MIB could resolve to multiple instances of that type. 3.4.2 Resolution of References across MIB Versions The object instance referred to by any HNMP operation is exactly specified as part of the operation request, so a reference to an object as part of some version of the Internet-standard MIB can not be resolved to any object that is not part of the said version of the Internet-standard MIB. 3.4.3 Identification of Object Instances The names for all object types referred to by any HNMP operation are defined explicitly under the hnmp subtree. The SMI requires that conformant management protocols define mechanisms to identify individual instances of those object types for a particular network device. In HNMP operations, each instance of any object type defined under the hnmp subtree is identified by a unique name -- "variable name." The names of all HNMP variables are OBJECT IDENTIFIERs in the form x.y, where x is the name of the said object type in the MIB definition, and y is the number of the same kind of variable of an HNMP agent, beginning with 0. For example, suppose one wants to identify an instance of the variable hnmpSysDescr. The location of hnmpSysDescr in the MIB definition is: iso org dod internet mgmt mib-2 hnmp hnmpSysDescr 1 3 6 1 2 1 12 1 Hence, the object type, x, would be 1.3.6.1.2.1.12.1 to which is appended with an instance sub-identifier of 0. That is, 1.3.6.1.2.1.12.1.0 identifies the only instance of sysDescr. If an HNMP agent has two instance with the same object type, and x is the identifier of the object type in the MIB definition, then x.0 identifies the first instance and x.1 identifies the second one. 4. Protocol Specification The home network management protocol is an application protocol with which management information for a home network element may be managed and controlled by remote users. Communication among protocol entities is accomplished through the exchange of messages. Each message is entirely and independently represented within a single UDP [5] datagram by use of the basic encoding rules of ASN.1. A message consists of a version number and a protocol data unit (PDU). A protocol entity receives all messages except those which report traps (for example, messages that contain the Trap-PDU) at UDP port 161 on the host. Messages which report traps should be received on UDP port 162 for further processing. Note, the HNMP is independent of transport-level protocol. To implement the HNMP, we may use any transport-level protocol. However, because of the predominating position of TCP/IP, we recommend strongly using UDP to implement the HNMP. It's also to be noted that the UDP port numbers used by the HNMP are the same as the SNMP [6]. In fact, the HNMP is expected to be, as much as possible, compatible with the SNMP. In other words, we hope the existing SNMP managers should be able to manage and control the network devices at home. In this case, the HNMP manager is regarded as a SNMP agent. Draft-HNMP DEFINITIONS ::= BEGIN -- top-level message Message ::= SEQUENCE { version -- version-1 for this draft INTEGER { version-1(0) }, data -- PDUs PDUs } -- protocol data units PDUs ::= CHOICE { register Register-PDU, update Update-PDU, response Response-PDU, set Set-PDU, trap Trap-PDU } END It is mandatory that all implementations of the HNMP support the five PDUs: Register-PDU, Update-PDU, Response-PDU, Set-PDU and Trap-PDU. We will give the definitions of the individual PDUs and commonly used data types later. 4.1 Message Exchange This section describes the actions of HNMP protocol entities the HNMP. However, it is not intended to constrain the internal architecture of any conformant implementation. In the text that follows, the term transport address is used. In the case of the UDP, a transport address consists of an IP address along with a UDP port. However, other transport services may also be used to support the HNMP. In these cases, the definition of a transport address should be made accordingly. The actions of a protocol entity which sends a message are as follows: (1) It first constructs the appropriate PDU, e.g., the Update-PDU, as an ASN.1 object. (2) The protocol entity then constructs an ASN.1 message object, using the version number and the ASN.1 object. (3) This new ASN.1 object is then serialized, according to the basic encoding rules of ASN.1, and then sent through a transport service to the peer protocol entity. Similarly, the actions of a protocol entity which receives a message are as follows: (1) It performs a rudimentary parse on the incoming datagram to build an ASN.1 object corresponding to an ASN.1 message object. If the parse fails, it discards the datagram and performs no further actions. (2) It then verifies the version number of the HNMP message. If there is a mismatch, it discards the datagram and performs no further actions. (3) The protocol entity then performs a rudimentary parse on the ASN.1 message object to build an ASN.1 object corresponding to an ASN.1 PDUs object. If the parse fails, it discards the datagram and performs no further actions. Otherwise, the PDU is processed accordingly. If, as a result of this processing, a message is returned, the source transport address of the response message shall be identical to the destination transport address of the original message. 4.2 Common Constructs Before introducing the five PDU types of the protocol, let's define some commonly used data types firstly: -- request/response information RequestID ::= INTEGER ErrorStatus ::= INTEGER { noError(0), noSuchName(1), badValue(2), readOnly(3), noSuchEntry(4) genErr(5) } ErrorIndex ::= INTEGER -- variable bindings VarBind ::= SEQUENCE { name ObjectName, value ObjectSyntax } VarBindList ::= SEQUENCE OF VarBind RequestIDs are used to distinguish specific requests. By use of the RequestID, an HNMP application entity can pair incoming responses with specific requests. In cases where an unreliable datagram service is being used, the RequestID also provides a simple means of identifying messages duplicated by the network. A non-zero instance of ErrorStatus is used to indicate that an exception occurs when a request is processed. In these cases, ErrorIndex may provide additional information by indicating which variable in the VarBindList field causes the exception. The term variable refers to an instance of a managed object. A variable binding, or VarBind, refers to the pairing of a variable name with its value. 4.3 The Register-PDU The form of the Register-PDU is: Register-PDU ::= [0] IMPLICIT SEQUENCE { request-id RequestID, variable-bindings VarBindList } The Register-PDU is generated by a HNMP agent only when a device registers itself at the HNMP manager after bootup. The variable-bindings field of the Register-PDU must include two variables: hnmpIpAddress and hnmpSysObjectID. Upon receipt of the Register-PDU, the HNMP manager adds a new entry to its management information base, which is indexed according to the IP address of the managed device. Then, the HNMP manager will send a Response-PDU to the HNMP agent. The variable-bindings field of the Response-PDU is the IP address of the HNMP manager. The value of the error-status field is noError and the value of the error-index field is zero. If an entry has already existed in the HNMP manager's management base, whose IP address is identical with that in the received Register-PDU, the HNMP manager will delete the existing entry firstly, and then add a new one. If the HNMP agent doesn't receive a Response-PDU from the HNMP manager in a given period of time (for example, 30 seconds), it will send the Register-PDU again. 4.4 The Update-PDU The form of the Update-PDU is identical to that of the Register-PDU except for the PDU type. In the ASN.1 language: Update-PDU ::= [1] IMPLICIT SEQUENCE { request-id RequestID, variable-bindings VarBindList } Having registered itself, the HNMP agent will send Update-PDUs to the HNMP manager periodically (for example, every 30 seconds). You may put all the variables of the HNMP agent into the variable-bindings field of a Update-PDU, and you can also put them into several Update-PDUs to avoid a Update-PDU being too long. Upon receipt of the Update-PDU, the HNMP manager will update its management information base using the variables in the received Update-PDU. Then it will send a Response-PDU to the HNMP agent that sent the received Update-PDU. The request-id field and the variable-bindings field of the Response-PDU are identical with the received Update-PDU. The value of the error-status field is noError and the value of the error-index field is zero. If the HNMP manager can't find an entry whose IP address is identical with that of the received Update-PDU, it will send a Response-PDU to the HNMP agent that sent the received Update-PDU. The request-id field and the variable-bindings field of the Response-PDU are identical with the received Update-PDU, but the value of the error-status field is NoSuchEntry and the value of the error-index field is zero. If, in a given period of time (for example, 60 seconds), the HNMP manager doesn't receive any Update-PDU for an entry in the management information base, it will delete the entry. If the value of an important variable changes, a HNMP agent may send an Update-PDU immediately, without having to wait until the next sending time. 4.5 The Set-PDU The form of the Set-PDU is identical to that of the Register-PDU except for the PDU type. In the ASN.1 language: Set-PDU ::= [2] IMPLICIT SEQUENCE { request-id RequestID, variable-bindings VarBindList } The Set-PDU is generated by the HNMP manager only when a user wants to change the value of a variable. It is used by the HNMP manager to set the value of a variable of an HNMP agent. With the Set-PDU, we can control the home devices remotely. Upon receipt of the Set-PDU, the HNMP agent responds according to the rules in the list below: (1) If one of the objects named in the variable-bindings field is not available for set operation in the relevant MIB, the HNMP agent will send a Response-PDU to the HNMP manager. The request-id field and the variables-bindings field of the Response-PDU are identical with the received Set-PDU. The value of the error-status field is noSuchName, and the value of the error-index field is the index of the said object name in the received Set-PDU. (2) If, for an object named in the variable-bindings field, the contents of the value field does not, according to the ASN.1 language, manifest a type, length, and value that is consistent with that required for the variable, the HNMP agent will send a Response-PDU to the HNMP manager. The request-id field and the variables-bindings field of the Response-PDU are identical with the received Set-PDU. The value of the error-status field is badValue, and the value of the error-index field is the index of said object name in the received Set-PDU. (3) If, for an object named in the variable-bindings field, the ACCESS permission of the named object's type is "read-only", the HNMP agent will send a Response-PDU to the HNMP manager. The request-id field and the variables- bindings field of the Response-PDU are identical with the received Set-PDU. The value of the error-status field is readOnly, and the value of the error-index field is the index of said object name in the received Set-PDU. (4) If, for an object named in the variable-bindings field, the value of the named object cannot be altered for reasons not covered by any of the foregoing rules, the HNMP agent will send a Response-PDU to the HNMP manager. The request-id field and the variables-bindings field of the Response-PDU are identical with the received Set-PDU. The value of the error-status field is genErr, and the value of the error-index field is the index of said object name in the received Set-PDU. If none of the foregoing rules applies, for each object named in the variable-bindings field of the received Set-PDU, a value is assigned to the corresponding variable. Each variable assignment specified by the Set-PDU should be effected as if simultaneously set with respect to all other assignments specified in the same message. Note, an HNMP agent doesn't maintain a MIB in its memory and assigning a value to the corresponding variable means doing the actual work. For example, assigning the value "23" to the variable "temperature" means setting the temperature of a air-condition to degree 23. The HNMP agent then sends to the HNMP manager a Response-PDU. The request-id field and the variables-bindings field of the Response-PDU are identical with the received Set-PDU. The value of the error-status field is noError, and the value of the error-index field is zero. After the HNMP manager that sent the Set-PDU receives the Response-PDU sent by the HNMP agent, it will update its MIB with the content of the Set-PDU. 4.6 The Response-PDU In the ASN.1 language, the form of the Response-PDU is: Response-PDU ::= [3] IMPLICIT SEQUENCE { request-id RequestID, error-status ErrorStatus, error-index ErrorIndex, variable-bindings VarBindList } The Response-PDU is used by HNMP protocol entities to respond to the received messages. For HNMP manager, it responds the Register-PDU and the Update-PDU and for HNMP agent, to the Set-PDU. Upon receipt of a HNMP message, the receiving entity sends a Response-PDU to the originator of the received message. If the receiving entity can process the received message successfully, the value of the error-status field will be noError and the value of the error-index field will be zero, otherwise the value of the error- stauts field will indicate the particular exception which occurred and the value of the error-index field is the index of the name of the object that resulted in the exception in the received message. 4.7 The Trap-PDU The form of the Trap-PDU is: Trap-PDU ::= [4] IMPLICIT SEQUENCE { enterprise -- type of object generating -- trap, see hnmpSysObjectID OBJECT IDENTIFIER, generic-trap -- generic trap type INTEGER { restart(0), linkDown(1), linkUp(2), enterpriseSpecific(3) }, specific-trap -- specific code, present even INTEGER, -- if generic-trap is not -- enterpriseSpecific time-stamp -- time elapsed between the last TimeTicks, -- (re)initialization of the network -- entity and the generation of the trap } The Trap-PDU is used by an HNMP agent to report to the HNMP manager that a exception occurred on the managed device. Upon receipt of the Trap-PDU, it is implementation-specific how the HNMP manager processes the exception. Interpretations of the value of the generic-trap field are: 4.7.1 The restart Trap A restart(0) trap signifies that the HNMP agent is reinitializing itself such that the agent's configuration may be altered. 4.7.2 The linkDown Trap A linkDown(2) trap signifies that the HNMP agent recognizes a failure in its communication link. 4.7.3 The linkUp Trap A linkUp(3) trap signifies that the HNMP agent recognizes that its communication link has come up. 4.7.4 The enterpriseSpecific Trap A enterpriseSpecific(4) trap signifies that the HNMP agent recognizes that some enterprise-specific event has occurred. The specific-trap field identifies the particular trap which occurred. 5. Definitions 5.1 Definitions of Management Objects Draft-HNMP-MIB DEFINITIONS ::= BEGIN IMPORTS IpAddress, TimeTicks FROM RFC1155-SMI OBJECT-TYPE, mib-2, DisplayString FROM RFC-1213; -- HNMP management information base hnmp OBJECT IDENTIFIER ::= { mib-2 xx } -- common management objects -- Implementation of these common objects is mandatory for -- all systems. hnmpSysDescr OBJECT-TYPE SYNTAX DisplayString (SIZE (0..255)) ACCESS read-only STATUS mandatory ::= { hnmp 1 } hnmpSysObjectID OBJECT-TYPE SYNTAX OBJECT IDENTIFIER ACCESS read-only STATUS mandatory ::= { hnmp 2 } hnmpSysUpTime OBJECT-TYPE SYNTAX TimeTicks ACCESS read-only STATUS mandatory ::= { hnmp 3 } hnmpSysName OBJECT-TYPE SYNTAX DisplayString (SIZE (0..255)) ACCESS read-write STATUS mandatory ::= { hnmp 4 } hnmpSysStatus OBJECT-TYPE SYNTAX INTEGER { play(1), stop(2), pause(3) } ACCESS read-write STATUS mandatory ::= { hnmp 5 } hnmpIpAddress OBJECT-TYPE SYNTAX IpAddress ACCESS read-only STATUS mandatory ::= { hnmp 6 } -- subtrees hnmpPrivate OBJECT IDENTIFIER ::= { hnmp 7 } hnmpEnterprises OBJECT IDENTIFIER ::= { hnmp 8 } END 5.2 Definitions of the HNMP Draft-HNMP DEFINITIONS ::= BEGIN IMPORTS ObjectName, ObjectSyntax, TimeTicks FROM RFC1155-SMI; -- top-level message Message ::= SEQUENCE { version -- version-1 for this draft INTEGER { version-1(0) }, data PDUs } -- protocol data units PDUs ::= CHOICE { register Register-PDU, update Update-PDU, response Response-PDU, set Set-PDU, trap Trap-PDU } -- PDUs Register-PDU ::= [0] IMPLICIT SEQUENCE { request-id RequestID, variable-bindings VarBindList } Update-PDU ::= [1] IMPLICIT SEQUENCE { request-id RequestID, variable-bindings VarBindList } Set-PDU ::= [2] IMPLICIT SEQUENCE { request-id RequestID, variable-bindings VarBindList } Response-PDU ::= [3] IMPLICIT SEQUENCE { request-id RequestID, error-status ErrorStatus, error-index ErrorIndex, variable-bindings VarBindList } Trap-PDU ::= [4] IMPLICIT SEQUENCE { enterprise -- type of object generating -- trap, see hnmpSysObjectID OBJECT IDENTIFIER, generic-trap -- generic trap type INTEGER { restart(0), linkDown(1), linkUp(2), enterpriseSpecific(3) }, specific-trap -- specific code, present even INTEGER, -- if generic-trap is not -- enterpriseSpecific time-stamp -- time elapsed between the last TimeTicks, -- (re)initialization of the network -- entity and the generation of the -- trap } -- variable bindings VarBind ::= SEQUENCE { name ObjectName, value ObjectSyntax } VarBindList ::= SEQUENCE OF VarBind -- request/response information RequestID ::= INTEGER ErrorStatus ::= INTEGER { noError(0), tooBig(1), noSuchName(2), badValue(3), readOnly(4), noSuchEntry(5) genErr(6) } ErrorIndex ::= INTEGER END 6. Acknowledgements This draft is heavily influenced by the documents relative to the SNMP: J. Case, SNMP Research M. Fedor, Performance Systems International M. Schoffstall, Performance Systems International J. Davin, MIT Laboratory for computer Science K. Mccolghrie, Hughes LAN Systems, Inc. M. Rose, Performance Systems International 7. References [1] McCloghrie, K., and M. Rose, "Management Information Base for Network Management of TCP/IP-based Internets: MIB-II", RFC 1213, Hughes LAN Systems and Performance Systems International, March 1991. [2] Rose, M., and K. McCloghrie, "Structure and Identification of Management Information for TCP/IP-based Internets", RFC 1155, Performance Systems International and Hughes LAN Systems, May 1990. [3] Information processing systems - Open Systems Interconnection, "Specification of Abstract Syntax Notation One (ASN.1)", International Organization for Standardization, International Standard 8824, December 1987. [4] Information processing systems - Open Systems Interconnection, "Specification of Basic Encoding Rules for Abstract Notation One (ASN.1)", International Organization for Standardization, International Standard 8825, December 1987. [5] Postel, J., "User Datagram Protocol", RFC 768, USC/Information Sciences Institute, November 1980. [6] Case, J., M. Fedor, M. Schoffstall, and J. Davin, The Simple Network Management Protocol", RFC 1157, University of Tennessee at Knoxville, Performance Systems International, Performance Systems International, and the MIT Laboratory for Computer Science, May 1990. 8. Security Considerations Security issues are not discussed in this draft. 9. Author's Address Liu Yunxin Department of Computer Science and Technology Tsinghua University Beijing, 100084 China Phone: 86-10-6278-8076 E-mail: liuyunxin98@mails.tsinghua.edu.cn Zhang Yaoxue Department of Computer Science and Technology Tsinghua University Beijing, 100084 China Phone: 86-10-6278-2118