Applicability of Standards Track MIBs to Management of World Wide Web Servers
RFC 2039
Document | Type |
RFC
- Informational
(November 1996)
Was
draft-kalbfleisch-www-track-mibs
(individual)
|
|
---|---|---|---|
Authors | |||
Last updated | 2013-03-02 | ||
RFC stream | Legacy stream | ||
Formats | |||
IESG | Responsible AD | (None) | |
Send notices to | (None) |
RFC 2039
Network Working Group C. Kalbfleisch Request for Comments: 2039 OnRamp Technologies, Inc. Category: Informational November 1996 Applicablity of Standards Track MIBs to Management of World Wide Web Servers Status of this Memo This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. Distribution of this memo is unlimited. 1. Abstract This document was produced at the request of the Network Management Area Director following the HTTP-MIB BOF at the 35th IETF meeting to report on the applicability of the existing standards track MIBs to management of WWW servers. Requirements for management of a World Wide Web (WWW) server are presented. The applicable existing standards track MIBs are then examined. Finally, an analysis of the additional groups of MIB attributes that are needed to meet the requirements is presented. Table of Contents 1. Abstract.................................................1 2. Overview.................................................2 3. Requirements.............................................3 3.1 Operational Model Requirements...........................3 3.1.1. Host specific and Application Monitoring.................3 3.1.2. Dependencies among applications..........................3 3.1.3. Error generation and reporting...........................3 3.1.4. Capacity planning........................................4 3.1.5. Log Digester.............................................4 3.2. Service Model Requirements...............................4 3.2.1. Retrieval services.......................................4 3.2.2. Document information store -- managing documents.........4 3.2.3. Server configuration.....................................4 3.2.4. Server Control...........................................4 3.2.5. Quality of Service.......................................4 4. Relationship to existing IETF efforts....................5 4.1. MIB-II [2]...............................................5 4.2. Host Resources MIB [3]...................................5 4.3. Network Services Monitoring MIB [4]......................6 4.4. Application MIB [5]......................................7 Kalbfleisch Informational [Page 1] RFC 2039 WWW Track MIBs November 1996 5. Summary of Existing Standards Track MIBs.................8 6. Definition of additional attributes......................9 7. Usage Scenarios.........................................11 8. Conclusion..............................................11 9. References..............................................13 10. Acknowledgments.........................................13 11. Further Information.....................................14 12. Security Considerations.................................14 13. Authors' Address........................................14 2. Overview The World Wide Web (WWW) is a network of information, accessible via a simple easy to use interface. The information is often presented in HyperText or multi-media. The information is provided by servers which are located all around the world. The usability of the web depends largely on the performance of these servers. WWW servers are typically monitored through log files. This becomes a difficult task when a single organization is responsible for a number of servers. Since many organizations currently use the Internet Standard SNMP to manage their network devices, it is desirable to treat these WWW servers as additional devices within this framework. This will allow a single Network Management Station (NMS) to automate the management of a number of WWW servers as well as the entire enterprise. Defining a standard for this purpose allows a single management application to manage a number of servers from a variety of vendors. Additionally, a formal definition of what has to be managed and how to manage it tends to lead to integrated and improved performance and fault management. Content providers are interested in the access statistics and configuration of their sites. The content provider may be the same or a different organization than the one that maintains the server as a whole. It may be possible to realize the new paradigm of "Customer Network Management" to provide this information to the content provider. This means that there exists a distinct organization different than the network operations center that is also interested in the management information from a device. Customer network management is desirable to allow each content provider on a server to access information about his own documents independent of the rest. Various organizations may be interested in SNMP manageable WWW clients and proxies as well. At this time, our focus is on WWW servers. A natural extension to this work could be a framework for managing WWW Clients and general information retrieval systems like WWW proxies, NNTP, GOPHER, FTP and WAIS. The focus of this document remains the management of WWW servers. Kalbfleisch Informational [Page 2] RFC 2039 WWW Track MIBs November 1996 3. Requirements WWW servers can be viewed from several perspectives when assigning management responsibilities. For the sake of discussion, these perspectives are named the Operational Model and the Service Model. The Operational Model views WWW servers as computers with hardware, disk, OS and web server software. This model represents the actual resources that make up the machine so that it can be monitored from the perspective of resource utilization. The Service Model views the WWW server as a black box that simply handles the responses to requests from clients located on the web. The two models compliment each other while providing distinct information about the server. Members of the organization responsible for the WWW server, may be interested in one and/or both of the management models. For this reason, the management information should be scalable, for one or both models to be implemented independent of the other. With this in mind, the requirements for WWW server management can are summarized below by expanding upon those generated at the HTTP-MIB BOF. 3.1 Operational Model Requirements 3.1.1. Host specific and Application Monitoring This includes monitoring the utilization of CPU, disk and network capacity. 3.1.2. Dependencies among applications. Some systems implement a number of services within a single piece of code. Others use multiple pieces of code to implement the same set of services. Because of this, dependencies develop among processes. These dependencies become critical when a particular process needs to be stopped, restarted or reconfigured. These dependencies need to be defined within the management information so that management applications can operate the systems correctly. 3.1.3. Error generation and reporting The WWW server generally reports errors via logging facilities. The format of the log file is not well defined. It is required that a standard facility for error reporting be utilized. Kalbfleisch Informational [Page 3] RFC 2039 WWW Track MIBs November 1996 3.1.4. Capacity planning It is required to obtain statistics which can be used for capacity planning purposes. This includes planning for increased network bandwidth, computing power, disk space, number of concurrent server threads, etc. 3.1.5. Log Digester WWW servers generally report status information by data generated in Common Log Format [1]. This information needs to be preserved as attributes in a MIB to facilitate remote monitoring providing a standard way to represent and retrieve the management information. 3.2. Service Model Requirements 3.2.1. Retrieval services Retrieval services are an abstract decoupling the information space from the underlying transport mechanism. The goal at this time is to focus on the requirements for management of WWW servers. There may be considerable overlap with other types of servers like (FTP, NNTP, GOPHER and WAIS). The term "retrieval services" is used here to retain this abstraction. It is required to get statistics about the usage and performance of the retrieval services. 3.2.2. Document information store -- managing documents. Information from a WWW server can be static (a file) or dynamic (the output of some processing). Management of these two types of information sources range from maintaining access statistics and access permissions to verifying the operational status of all applications that provide the dynamic information. 3.2.3. Server configuration. It is desirable to be able to centralize configuration management of the servers within an enterprise. 3.2.4. Server Control. WWW servers generally need to be controlled in regards to starting and stopping them as well as rotating log files. 3.2.5. Quality of Service Provide an indication of the quality of service the WWW server is providing. Kalbfleisch Informational [Page 4] RFC 2039 WWW Track MIBs November 1996 quot; state (Section 5.1). A HEADERS frame that is followed by CONTINUATION frames carries the flag that signals the end of a stream. A CONTINUATION frame cannot be used to terminate a stream. RESERVED (0x2): Bit 2 is reserved for future use. END_HEADERS (0x4): Bit 3 being set indicates that this frame ends the sequence of header block fragments necessary to provide a complete set of header fields. The payload for a complete header block is provided by a sequence of that starts with a HEADERS frame, followed by zero or more CONTINUATION frames. The sequence is terminated by a frame with the END_HEADERS flag set. Once the sequence terminates, the payload of all HEADERS and CONTINUATION frames are concatenated and interpreted as a single block. A HEADERS frame without the END_HEADERS flag set MUST be followed by a CONTINUATION frame for the same stream. A receiver MUST treat the receipt of any other type of frame or a frame on a different stream as a connection error (Section 5.4.1) of type PROTOCOL_ERROR. PRIORITY (0x8): Bit 4 being set indicates that the first four octets of this frame contain a single reserved bit and a 31-bit priority; see Section 5.3. If this bit is not set, the four bytes do not appear and the frame only contains a header block fragment. The payload of a HEADERS frame contains a header block fragment (Section 4.3). A header block that does not fit within a HEADERS frame is continued in a CONTINUATION frame (Section 6.10). Belshe, et al. Expires April 24, 2014 [Page 25] Internet-Draft HTTP/2.0 October 2013 HEADERS frames MUST be associated with a stream. If a HEADERS frame is received whose stream identifier field is 0x0, the recipient MUST respond with a connection error (Section 5.4.1) of type PROTOCOL_ERROR. The HEADERS frame changes the connection state as described in Section 4.3. 6.3. PRIORITY The PRIORITY frame (type=0x2) specifies the sender-advised priority of a stream. It can be sent at any time for an existing stream. This enables reprioritisation of existing streams. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |X| Priority (31) | +-+-------------------------------------------------------------+ PRIORITY Frame Payload The payload of a PRIORITY frame contains a single reserved bit and a 31-bit priority. The PRIORITY frame does not define any flags. The PRIORITY frame is associated with an existing stream. If a PRIORITY frame is received with a stream identifier of 0x0, the recipient MUST respond with a connection error (Section 5.4.1) of type PROTOCOL_ERROR. The PRIORITY frame can be sent on a stream in any of the "reserved (remote)", "open", "half-closed (local)", or "half closed (remote)" states, though it cannot be sent between consecutive frames that comprise a single header block (Section 4.3). Note that this frame could arrive after processing or frame sending has completed, which would cause it to have no effect. For a stream that is in the "half closed (remote)" state, this frame can only affect processing of the stream and not frame transmission. 6.4. RST_STREAM The RST_STREAM frame (type=0x3) allows for abnormal termination of a stream. When sent by the initiator of a stream, it indicates that they wish to cancel the stream or that an error condition has occurred. When sent by the receiver of a stream, it indicates that either the receiver is rejecting the stream, requesting that the Belshe, et al. Expires April 24, 2014 [Page 26] Internet-Draft HTTP/2.0 October 2013 stream be cancelled or that an error condition has occurred. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Error Code (32) | +---------------------------------------------------------------+ RST_STREAM Frame Payload The RST_STREAM frame contains a single unsigned, 32-bit integer identifying the error code (Section 7). The error code indicates why the stream is being terminated. The RST_STREAM frame does not define any flags. The RST_STREAM frame fully terminates the referenced stream and causes it to enter the closed state. After receiving a RST_STREAM on a stream, the receiver MUST NOT send additional frames for that stream. However, after sending the RST_STREAM, the sending endpoint MUST be prepared to receive and process additional frames sent on the stream that might have been sent by the peer prior to the arrival of the RST_STREAM. RST_STREAM frames MUST be associated with a stream. If a RST_STREAM frame is received with a stream identifier of 0x0, the recipient MUST treat this as a connection error (Section 5.4.1) of type PROTOCOL_ERROR. RST_STREAM frames MUST NOT be sent for a stream in the "idle" state. If a RST_STREAM frame identifying an idle stream is received, the recipient MUST treat this as a connection error (Section 5.4.1) of type PROTOCOL_ERROR. 6.5. SETTINGS The SETTINGS frame (type=0x4) conveys configuration parameters that affect how endpoints communicate. The parameters are either constraints on peer behavior or preferences. SETTINGS frames MUST be sent at the start of a connection, and MAY be sent at any other time by either endpoint over the lifetime of the connection. Implementations MUST support all of the settings defined by this specification and MAY support additional settings defined by extensions. Unsupported or unrecognized settings MUST be ignored. New settings MUST NOT be defined or implemented in a way that Belshe, et al. Expires April 24, 2014 [Page 27] Internet-Draft HTTP/2.0 October 2013 requires endpoints to understand them in order to communicate successfully. Each setting in a SETTINGS frame replaces the existing value for that setting. Settings are processed in the order in which they appear, and a receiver of a SETTINGS frame does not need to maintain any state other than the current value of settings. Therefore, the value of a setting is the last value that is seen by a receiver. This permits the inclusion of the same settings multiple times in the same SETTINGS frame, though doing so does nothing other than waste connection capacity. The SETTINGS frame defines the following flag: ACK (0x1): Bit 1 being set indicates that this frame acknowledges receipt and application of the peer's SETTINGS frame. When this bit is set, the payload of the SETTINGS frame MUST be empty. Receipt of a SETTINGS frame with the ACK flag set and a length field value other than 0 MUST be treated as a connection error (Section 5.4.1) of type FRAME_SIZE_ERROR. For more info, see Settings Synchronization (Section 6.5.3). SETTINGS frames always apply to a connection, never a single stream. The stream identifier for a settings frame MUST be zero. If an endpoint receives a SETTINGS frame whose stream identifier field is anything other than 0x0, the endpoint MUST respond with a connection error (Section 5.4.1) of type PROTOCOL_ERROR. The SETTINGS frame affects connection state. A badly formed or incomplete SETTINGS frame MUST be treated as a connection error (Section 5.4.1) of type PROTOCOL_ERROR. 6.5.1. Setting Format The payload of a SETTINGS frame consists of zero or more settings. Each setting consists of an 8-bit reserved field, an unsigned 24-bit setting identifier, and an unsigned 32-bit value. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved (8) | Setting Identifier (24) | +---------------+-----------------------------------------------+ | Value (32) | +---------------------------------------------------------------+ Setting Format Belshe, et al. Expires April 24, 2014 [Page 28] Internet-Draft HTTP/2.0 October 2013 6.5.2. Defined Settings The following settings are defined: SETTINGS_HEADER_TABLE_SIZE (1): Allows the sender to inform the remote endpoint of the size of the header compression table used to decode header blocks. The default value is 4096 bytes. SETTINGS_ENABLE_PUSH (2): This setting can be use to disable server push (Section 8.2). An endpoint MUST NOT send a PUSH_PROMISE frame if it receives this setting set to a value of 0. The default value is 1, which indicates that push is permitted. SETTINGS_MAX_CONCURRENT_STREAMS (4): Indicates the maximum number of concurrent streams that the sender will allow. This limit is directional: it applies to the number of streams that the sender permits the receiver to create. By default there is no limit. It is recommended that this value be no smaller than 100, so as to not unnecessarily limit parallelism. SETTINGS_INITIAL_WINDOW_SIZE (7): Indicates the sender's initial window size (in bytes) for stream level flow control. This settings affects the window size of all streams, including existing streams, see Section 6.9.2. SETTINGS_FLOW_CONTROL_OPTIONS (10): Indicates flow control options. The least significant bit (0x1) of the value is set to indicate that the sender has disabled all flow control. This bit cannot be cleared once set, see Section 6.9.4. All bits other than the least significant are reserved. 6.5.3. Settings Synchronization Most values in SETTINGS benefit from or require an understanding of when the peer has received and applied the changed setting values. In order to provide such synchronization timepoints, the recipient of a SETTINGS frame in which the ACK flag is not set MUST apply the updated settings as soon as possible upon receipt. The values in the SETTINGS frame MUST be applied in sequence, with no other frame processing between values. Once all values have been applied, the recipient MUST immediately emit a SETTINGS frame with the ACK flag set. If the sender of a SETTINGS frame does not receive an acknowledgement within a reasonable amount of time, it MAY issue a connection error Belshe, et al. Expires April 24, 2014 [Page 29] Internet-Draft HTTP/2.0 October 2013 (Section 5.4.1) of type SETTINGS_TIMEOUT. 6.6. PUSH_PROMISE The PUSH_PROMISE frame (type=0x5) is used to notify the peer endpoint in advance of streams the sender intends to initiate. The PUSH_PROMISE frame includes the unsigned 31-bit identifier of the stream the endpoint plans to create along with a minimal set of headers that provide additional context for the stream. Section 8.2 contains a thorough description of the use of PUSH_PROMISE frames. PUSH_PROMISE MUST NOT be sent if the SETTINGS_ENABLE_PUSH setting of the peer endpoint is set to 0. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |X| Promised-Stream-ID (31) | +-+-------------------------------------------------------------+ | Header Block Fragment (*) ... +---------------------------------------------------------------+ PUSH_PROMISE Payload Format The payload of a PUSH_PROMISE includes a "Promised-Stream-ID". This unsigned 31-bit integer identifies the stream the endpoint intends to start sending frames for. The promised stream identifier MUST be a valid choice for the next stream sent by the sender (see new stream identifier (Section 5.1.1)). Following the "Promised-Stream-ID" is a header block fragment (Section 4.3). PUSH_PROMISE frames MUST be associated with an existing, peer- initiated stream. If the stream identifier field specifies the value 0x0, a recipient MUST respond with a connection error (Section 5.4.1) of type PROTOCOL_ERROR. The PUSH_PROMISE frame defines the following flags: END_PUSH_PROMISE (0x4): The END_PUSH_PROMISE bit indicates that this frame ends the sequence of header block fragments necessary to provide a complete set of headers. The payload for a complete header block is provided by a sequence of frames that starts with a PUSH_PROMISE frame, followed by zero or more CONTINUATION frames. The sequence terminates by a PUSH_PROMISE frame with the END_PUSH_PROMISE flag set or a Belshe, et al. Expires April 24, 2014 [Page 30] Internet-Draft HTTP/2.0 October 2013 CONTINUATION frame with the END_HEADERS flag set. Once the sequence terminates, the payload of all frames in the sequence are concatenated and interpreted as a single block. A PUSH_PROMISE frame without the END_PUSH_PROMISE flag set MUST be followed by a CONTINUATION frame for the same stream. A receiver MUST treat the receipt of any other type of frame or a frame on a different stream as a connection error (Section 5.4.1) of type PROTOCOL_ERROR. Promised streams are not required to be used in order promised. The PUSH_PROMISE only reserves stream identifiers for later use. Recipients of PUSH_PROMISE frames can choose to reject promised streams by returning a RST_STREAM referencing the promised stream identifier back to the sender of the PUSH_PROMISE. The PUSH_PROMISE frame modifies the connection state as defined in Section 4.3. A PUSH_PROMISE frame modifies the connection state in two ways. The inclusion of a header block (Section 4.3) potentially modifies the compression state. PUSH_PROMISE also reserves a stream for later use, causing the promised stream to enter the "reserved" state. A sender MUST NOT send a PUSH_PROMISE on a stream unless that stream is either "open" or "half closed (remote)"; the sender MUST ensure that the promised stream is a valid choice for a new stream identifier (Section 5.1.1) (that is, the promised stream MUST be in the "idle" state). Since PUSH_PROMISE reserves a stream, ignoring a PUSH_PROMISE frame causes the stream state to become indeterminate. A receiver MUST treat the receipt of a PUSH_PROMISE on a stream that is neither "open" nor 4. Relationship to existing IETF efforts In general, a WWW server is made up of or depends upon the following components: -a general purpose workstation running some operating system -http server software to answers requests from the network -various support routines like CGI programs or external applications (like DBMS) used to access information -a document store on one or more storage devices The health and performance of each of the above components is of interest when managing a WWW server. There are a number of standards track MIB modules that are of interest to the above list of items. This list includes MIB-II [2], Host Resources MIB [3], Network Service Monitoring MIB [4] and Application MIB [5]. This creates an impressive list of attributes to be implemented. A definition of various levels of management of a WWW server is desired so that the implementor may scale his implementation in chunks which may include various components of each section. For instance, this may allow customer network management without requiring the other groups being implemented. 4.1. MIB-II [2] MIB-II defines the managed objects which should be contained within TCP/IP based devices. The WWW server should support the applicable portions of MIB-II. This set probably includes, as a minimum, the following groups: system, interfaces, udp, icmp, tcp and snmp. 4.2. Host Resources MIB [3] This MIB defines a uniform set of objects useful for the management of host computers independently of the operating system, network services, or any software application. The MIB is structured as six groups; each specified as either "mandatory" or "optional". If ANY "optional" group of the MIB is implemented, then ALL "mandatory" groups of the MIB must also be implemented. This may cause implementation problems for some developers since many of these attributes require intimate knowledge of the OS. Kalbfleisch Informational [Page 5] RFC 2039 WWW Track MIBs November 1996 The groups defined by the MIB are: -System Group Mandatory -Storage Group Mandatory -Device Group Mandatory -device types -device table -processor table -network table -printer table -disk storage table -partition table -file-system table -file-system types -Running Software Group Optional -Running Software Performance Group Optional -Installed Software Group Optional The system group provides general status information about the host. The storage and device groups define the information about the configuration and status of the resources which compose the host. It defines the resources which make up a generic host system and how they relate to each other. Much of this information is useful for managing various aspects of a WWW server, like the file system and CPU utilization. This information is useful for meeting the operational requirements. Much of this information is however more detailed than many WWW server managers require for service level requirements. The remaining groups define software components which are installed and/or running on the host. Performance information is defined which extends that defined for each running process. Unfortunately, the mapping between running software and installed software is difficult since it is related by a foreign key (Product ID) which does not appear to be required to exist in either table [6]. There is no provision to represent a group of processes which together perform some task (IE an application made up of multiple processes). The Applications MIB WG plans to address these deficiencies. 4.3. Network Services Monitoring MIB [4] This MIB is one of three documents produced by the MADMAN (Message And Directory MANagement) Working group. It defines a set of general purpose attributes which would be appropriate for a range of applications that provide network services. This definition is from the perspective of the service without considering the implementation in terms of host computers or processes. Attributes provide Kalbfleisch Informational [Page 6] RFC 2039 WWW Track MIBs November 1996 statistics and status on the in-bound and out-bound associations that are currently active, and which have been active. This MIB is intended to be the minimum set of attributes common across a number of Network Service Applications. Additional attributes are to be defined as necessary to manage specific network service applications. WWW servers clearly fall into the category of network service applications. All attributes in this MIB are relevant to WWW servers. The MIB consists of two tables: -applTable Mandatory -assocTable Optional The applTable describes applications that provide network services and keeps statistics of the current number of active associations and the total number of associations since application initialization. The assocTable contains more detailed information about active associations. The other two MIBs defined by MADMAN, MTA MIB [7] and DSA MIB [8], are not relevant to the management of WWW services. They do, however, demonstrate how to extend the Network Services Monitoring MIB for a specific set of applications. 4.4. Application MIB [5] The Application MIB WG is defining two separate MIBs: the sysApplMib and the applMib. The first defines attributes that can be monitored without instrumenting the applications. The second will define additional attributes requiring application instrumentation. The sysApplMIB allows for the description of applications as a collection of executables, and files installed and executing on a host computer. The objects support configuration, fault and performance management of some of the basic attributes of application software. Kalbfleisch Informational [Page 7] RFC 2039 WWW Track MIBs November 1996 The groups defined in the sysApplMIB are: -System Application Installed Group Mandatory -sysApplInstalledTable -sysApplCfgElmtTable -System Application Run Group Mandatory -sysApplRunTable -SysApplPastRunTable -sysApplElmtRunTable -sysApplElmtPastRunTable The sysApplInstalledTable captures what applications are installed on a particular host and the sysApplCfgElmtTable provides information regarding the executables and non executable files which collectively compose the application. The sysApplRunTable contains the application instances which are currently running and the sysApplPastRunTable contains a history about applications which have previously executed on the host. The sysApplElmtRunTable contains the process instances which are currently running and sysApplElmtPastRunTable contains a history about processes which have previously executed on the host. It should be noted that two implementations of the same set of network services may each define a different set of processes and files within this MIB. Ultimately enough management information is needed so that these different implementations can at least be managed similarly. WWW servers fall into the general category of application software. Therefore the attributes of this MIB are applicable if the process level detail is requested to meet the Operational Model requirements. The Application MIB WG is to resolve the problems described above with the relationship between the running and installed software of the Host Resources MIB. 5. Summary of Existing Standards Track MIBs The existing MIBs are largely orthogonal as demonstrated by the diagram below. Host Resources relates network information to the interfaces defined in MIB-II. The system application MIB relates its running element table to the equivalent entry in the Host Resources running software table. It should be noted that the running software of the Host Resources includes ALL software running on the host, while the running element table of the system application MIB only includes "interesting" processes of monitored applications. Kalbfleisch Informational [Page 8] RFC 2039 WWW Track MIBs November 1996 In the diagram below, "Other Services", "Application Specific MIBs" and "Application MIB" represent work to be done or in progress. +---------------+ | Application | | Specific MIBs | +---------------+ | +--------+ +---+ +---+ +---------------+ |Other | |MTA| |DSA| | Application | |services| |MIB| |MIB| | MIB | +--------+ +---+ +---+ +---------------+ | | | | +--------------------+ +---------------+ +--------------+ +------+ | Network Services | | System | |Host Resources| |MIB-II| | Monitoring MIB | |Application MIB|--| MIB |--| | +--------------------+ +---------------+ +--------------+ +------+ The stack of MIBs above "Network Services Monitoring MIB&"half-closed (local)" as a connection error (Section 5.4.1) of type PROTOCOL_ERROR. Similarly, a receiver MUST treat the receipt of a PUSH_PROMISE that promises an illegal stream identifier (Section 5.1.1) (that is, an identifier for a stream that is not currently in the "idle" state) as a connection error (Section 5.4.1) of type PROTOCOL_ERROR, unless the receiver recently sent a RST_STREAM frame to cancel the associated stream (see Section 5.1). 6.7. PING The PING frame (type=0x6) is a mechanism for measuring a minimal round-trip time from the sender, as well as determining whether an idle connection is still functional. PING frames can be sent from any endpoint. Belshe, et al. Expires April 24, 2014 [Page 31] Internet-Draft HTTP/2.0 October 2013 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Opaque Data (64) | | | +---------------------------------------------------------------+ PING Payload Format In addition to the frame header, PING frames MUST contain 8 octets of data in the payload. A sender can include any value it chooses and use those bytes in any fashion. Receivers of a PING frame that does not include a ACK flag MUST send a PING frame with the ACK flag set in response, with an identical payload. PING responses SHOULD given higher priority than any other frame. The PING frame defines the following flags: ACK (0x1): Bit 1 being set indicates that this PING frame is a PING response. An endpoint MUST set this flag in PING responses. An endpoint MUST NOT respond to PING frames containing this flag. PING frames are not associated with any individual stream. If a PING frame is received with a stream identifier field value other than 0x0, the recipient MUST respond with a connection error (Section 5.4.1) of type PROTOCOL_ERROR. Receipt of a PING frame with a length field value other than 8 MUST be treated as a connection error (Section 5.4.1) of type FRAME_SIZE_ERROR. 6.8. GOAWAY The GOAWAY frame (type=0x7) informs the remote peer to stop creating streams on this connection. It can be sent from the client or the server. Once sent, the sender will ignore frames sent on new streams for the remainder of the connection. Receivers of a GOAWAY frame MUST NOT open additional streams on the connection, although a new connection can be established for new streams. The purpose of this frame is to allow an endpoint to gracefully stop accepting new streams (perhaps for a reboot or maintenance), while still finishing processing of previously established streams. There is an inherent race condition between an endpoint starting new streams and the remote sending a GOAWAY frame. To deal with this Belshe, et al. Expires April 24, 2014 [Page 32] Internet-Draft HTTP/2.0 October 2013 case, the GOAWAY contains the stream identifier of the last stream which was processed on the sending endpoint in this connection. If the receiver of the GOAWAY used streams that are newer than the indicated stream identifier, they were not processed by the sender and the receiver may treat the streams as though they had never been created at all (hence the receiver may want to re-create the streams later on a new connection). Endpoints SHOULD always send a GOAWAY frame before closing a connection so that the remote can know whether a stream has been partially processed or not. For example, if an HTTP client sends a POST at the same time that a server closes a connection, the client cannot know if the server started to process that POST request if the server does not send a GOAWAY frame to indicate where it stopped working. An endpoint might choose to close a connection without sending GOAWAY for misbehaving peers. After sending a GOAWAY frame, the sender can discard frames for new streams. However, any frames that alter connection state cannot be completely ignored. For instance, HEADERS, PUSH_PROMISE and CONTINUATION frames MUST be minimally processed to ensure a consistent compression state (see Section 4.3); similarly DATA frames MUST be counted toward the connection flow control window. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |X| Last-Stream-ID (31) | +-+-------------------------------------------------------------+ | Error Code (32) | +---------------------------------------------------------------+ | Additional Debug Data (*) | +---------------------------------------------------------------+ GOAWAY Payload Format The GOAWAY frame does not define any flags. The GOAWAY frame applies to the connection, not a specific stream. The stream identifier MUST be zero. The last stream identifier in the GOAWAY frame contains the highest numbered stream identifier for which the sender of the GOAWAY frame has received frames on and might have taken some action on. All streams up to and including the identified stream might have been processed in some way. The last stream identifier is set to 0 if no streams were processed. Belshe, et al. Expires April 24, 2014 [Page 33] Internet-Draft HTTP/2.0 October 2013 Note: In this case, "processed" means that some data from the stream was passed to some higher layer of software that might have taken some action as a result. If a connection terminates without a GOAWAY frame, this value is effectively the highest stream identifier. On streams with lower or equal numbered identifiers that were not closed completely prior to the connection being closed, re-attempting requests, transactions, or any protocol activity is not possible (with the exception of idempotent actions like HTTP GET, PUT, or DELETE). Any protocol activity that uses higher numbered streams can be safely retried using a new connection. Activity on streams numbered lower or equal to the last stream identifier might still complete successfully. The sender of a GOAWAY frame might gracefully shut down a connection by sending a GOAWAY frame, maintaining the connection in an open state until all in- progress streams complete. The last stream ID MUST be 0 if no streams were acted upon. The GOAWAY frame also contains a 32-bit error code (Section 7) that contains the reason for closing the connection. Endpoints MAY append opaque data to the payload of any GOAWAY frame. Additional debug data is intended for diagnostic purposes only and carries no semantic value. Debug data MUST NOT be persistently stored, since it could contain sensitive information. 6.9. WINDOW_UPDATE The WINDOW_UPDATE frame (type=0x9) is used to implement flow control. Flow control operates at two levels: on each individual stream and on the entire connection. Both types of flow control are hop by hop; that is, only between the two endpoints. Intermediaries do not forward WINDOW_UPDATE frames between dependent connections. However, throttling of data transfer by any receiver can indirectly cause the propagation of flow control information toward the original sender. Flow control only applies to frames that are identified as being subject to flow control. Of the frame types defined in this document, this includes only DATA frame. Frames that are exempt from flow control MUST be accepted and processed, unless the receiver is unable to assign resources to handling the frame. A receiver MAY Belshe, et al. Expires April 24, 2014 [Page 34] Internet-Draft HTTP/2.0 October 2013 respond with a stream error (Section 5.4.2) or connection error (Section 5.4.1) of type FLOW_CONTROL_ERROR if it is unable accept a frame. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |X| Window Size Increment (31) | +-+-------------------------------------------------------------+ WINDOW_UPDATE Payload Format The payload of a WINDOW_UPDATE frame is one reserved bit, plus an unsigned 31-bit integer indicating the number of bytes that the sender can transmit in addition to the existing flow control window. The legal range for the increment to the flow control window is 1 to 2^31 - 1 (0x7fffffff) bytes. The WINDOW_UPDATE frame does not define any flags. The WINDOW_UPDATE frame can be specific to a stream or to the entire connection. In the former case, the frame's stream identifier indicates the affected stream; in the latter, the value "0" indicates that the entire connection is the subject of the frame. WINDOW_UPDATE can be sent by a peer that has sent a frame bearing the END_STREAM flag. This means that a receiver could receive a WINDOW_UPDATE frame on a "half closed (remote)" or "closed" stream. A receiver MUST NOT treat this as an error, see Section 5.1. A receiver that receives a flow controlled frame MUST always account for its contribution against the connection flow control window, unless the receiver treats this as a connection error (Section 5.4.1). This is necessary even if the frame is in error. Since the sender counts the frame toward the flow control window, if the receiver does not, the flow control window at sender and receiver can become different. 6.9.1. The Flow Control Window Flow control in HTTP/2.0 is implemented using a window kept by each sender on every stream. The flow control window is a simple integer value that indicates how many bytes of data the sender is permitted to transmit; as such, its size is a measure of the buffering capability of the receiver. Two flow control windows are applicable: the stream flow control window and the connection flow control window. The sender MUST NOT Belshe, et al. Expires April 24, 2014 [Page 35] Internet-Draft HTTP/2.0 October 2013 send a flow controlled frame with a length that exceeds the space available in either of the flow control windows advertised by the receiver. Frames with zero length with the END_STREAM flag set (for example, an empty data frame) MAY be sent if there is no available space in either flow control window. For flow control calculations, the 8 byte frame header is not counted. After sending a flow controlled frame, the sender reduces the space available in both windows by the length of the transmitted frame. The receiver of a frame sends a WINDOW_UPDATE frame as it consumes data and frees up space in flow control windows. Separate WINDOW_UPDATE frames are sent for the stream and connection level flow control windows. A sender that receives a WINDOW_UPDATE frame updates the corresponding window by the amount specified in the frame. A sender MUST NOT allow a flow control window to exceed 2^31 - 1 bytes. If a sender receives a WINDOW_UPDATE that causes a flow control window to exceed this maximum it MUST terminate either the stream or the connection, as appropriate. For streams, the sender sends a RST_STREAM with the error code of FLOW_CONTROL_ERROR code; for the connection, a GOAWAY frame with a FLOW_CONTROL_ERROR code. Flow controlled frames from the sender and WINDOW_UPDATE frames from the receiver are completely asynchronous with respect to each other. This property allows a receiver to aggressively update the window size kept by the sender to prevent streams from stalling. 6.9.2. Initial Flow Control Window Size When a HTTP/2.0 connection is first established, new streams are created with an initial flow control window size of 65,535 bytes. The connection flow control window is 65,535 bytes. Both endpoints can adjust the initial window size for new streams by including a value for SETTINGS_INITIAL_WINDOW_SIZE in the SETTINGS frame that forms part of the connection header. Prior to receiving a SETTINGS frame that sets a value for SETTINGS_INITIAL_WINDOW_SIZE, an endpoint can only use the default initial window size when sending flow controlled frames. Similarly, the connection flow control window is set to the default initial window size until a WINDOW_UPDATE frame is received. A SETTINGS frame can alter the initial flow control window size for Belshe, et al. Expires April 24, 2014 [Page 36] Internet-Draft HTTP/2.0 October 2013 quot; represent monitoring from the Service Model. The other stacks represent monitoring from the Operational Model. Neither of these stacks goes to the level of specific detail for any application. The author is of the opinion that HTTP or Web Server specific MIBs would exist at the top of each stack to represent the service and implementation view of the server respectively. There should be a relationship between these two perspectives defined so that the correlations between the two perspectives is possible. This relationship would be useful for general application and service monitoring in addition to just web servers. However, it is not of specific interest to either the MADMAN WG or the Application MIB WG. It is therefore suggested that such a relationship is defined in a general case outside of either of those groups that would be applicable for WWW servers as well as for other application to service mappings. 6. Definition of additional attributes The existing MIB attributes meet the Operational Model Requirement for tracking information specific to a host. Specifically, MIB-II, Host Resources and the Applications MIB address these items. The Network Services MIB addresses a portion of the service model requirement for the decoupling of the information space from the transport mechanism. Several sets of additional attributes are needed to meet the remaining requirements. These additional attributes may be generally applicable to other network information retrieval services (like FTP, NNTP, GOPHER and WAIS) as well as client and proxy management. Management of these services is not the scope of this document. Kalbfleisch Informational [Page 9] RFC 2039 WWW Track MIBs November 1996 These additional attributes can be classified as: 1) Definition of relationship between the Network Services Monitoring and Application MIBs. This allows the functional organization of the server to be known. It allows the management application to understand the effect of restarting specific processes on the services provided. This addresses the Operational Model requirement to model dependencies between applications. 2) Additions to generic Network Services Monitoring MIB. A draft [9] has already been circulated due to the work of a mailing list and a sample implementation. These attributes list a summary at the service level of the configuration and the health of the server. From this, performance metrics can be observed. In addition, the health of the server in terms of data timeouts is known. These attributes address the requirement for Operational Model tracking of specific activity and the requirement for Service Model retrieval services. 3) Document storage and access statistics are needed to address service model requirements. 4) Additions to Application MIB are required to address server configuration requirements in the service model. 5) Error and fault management attributes are required to address requirements for tracking specific activity of the web server. 6) Configuration and Control are items that may be able to be defined in a general way within the applications MIB. If not, a specific definition would be required here. Of the items listed above, (1) is needed on a general basis. The others appear to the author as WWW server specific unless the scope of the work is opened to WWW clients and proxies as well as other services (like NNTP, FTP, GOPHER and WAIS). Kalbfleisch Informational [Page 10] RFC 2039 WWW Track MIBs November 1996 7. Usage Scenarios The example scenario will be a single host computer which implements WWW services using the "virtual domain" concept. In this model, a single host performs as the WWW server for one or more addresses. For the purpose of example, we will specify that there are three domains being serviced from this host whose WWW servers are: -www.a.com -www.b.com -www.c.com Some implementations may implement these services as one set of processes that handle requests for each of the addresses. Others may implement these services as a set of processes for each address. This means that the relationship defined between the Network Services Monitoring MIB and Application MIB components of the management information may vary between different implementations of the same configuration. MIB-II and Host Resources would provide the information about the host including the CPU, disk and network. The Host Resource running table provide information on the processes in the system. There would be an entry in the Network Services Monitoring applTable for each virtual domain. In addition, the assocTable shows which connections are currently active. An extension to the association table would be helpful to provide information as to what is being transmitted. The sysApplMib would have entries in its installed software tables for the web server software and each "interesting" component. This should include the server binary, CGI programs, configuration files and possibly the server log files. Depending on the implementation of the server, the processes for each domain may show up in the same or different running software tables. Additional information as described in the previous section would round out the management information that would be available for the WWW server. 8. Conclusion A number of currently defined attributes are useful for management of a WWW server. Specifically, MIB-II and Host Resources should be considered for monitoring the health of the machine in terms of host and network configuration and capacity. The Network Services Monitoring MIB and the Application MIBs provide a general framework Kalbfleisch Informational [Page 11] RFC 2039 WWW Track MIBs November 1996 to represent the components of the WWW server from both a service and implementation perspective. The Network Services Monitoring MIB suggests that extensions are necessary to cover specific network application monitoring. A set of such attributes can be well defined to provide status information of the WWW server. The Application MIB suggests similar extensions. Some of these attributes may be generic to all applications, and thus be implemented within the scope of the applMib. It is the opinion of this author that there will still remain specific instrumentation for WWW servers that can not, and should not, be covered in the Network Services Monitoring and Application MIBs. Since the Network Services Monitoring MIB and the Applications MIB represent orthogonal efforts of management, it is desirable to define the relationship between the two in a standard way. This definition is probably more than a simple pointer from one table to another. Since it is outside the scope of either of those efforts, it is this author's opinion that that definition could and should be addressed within the scope of defining management of a specific application (IE WWW servers). This defintion although defined for a particular application, should be useful in a general way to describe the relationship between the Network Services Monitoring MIB and the Applications MIB. Additional attributes are needed in order to meet all of the requirements specified in this document. An IETF standard would prevent independent developments of this effort in many enterprise MIBs. It also allows management applications to control servers from multiple vendors. It is likely that as the work in this area progresses, the management information will be useful for other Network Information Retrieval services (like FTP, GOPHER, WAIS and NNTP) as well. Finally, the Operational Model and Service Model Requirements lead to two main uses of the management information. Design of the MIB including the usage of the existing MIBs should allow one or the other or both of these models to be implemented in a standard way. This may be desirable depending specifically on the audience of the data, the cost of instrumentation and the resources of the system. Kalbfleisch Informational [Page 12] RFC 2039 WWW Track MIBs November 1996 9. References [1] Anonymous, "Logging in the W3C httpd", http://www.w3.org/hypertext/WWW/Daemon/User/Config/Logging.html, W3C, July 1995. [2] McCloghrie, K., and M. Rose, Editors, "Management Information Base for Network Management of TCP/IP-based internets: MIB- II", STD 17, RFC 1213, Hughes LAN Systems, Performance Systems International, March 1991. [3] Grillo, P., and S. Waldbusser, "Host Resources MIB", RFC 1514, Network Innovations, Intel Corporation, Carnegie Mellon University, September 1993. [4] Kille, S., and N. Freed, "Network Services Monitoring MIB", RFC 1565, ISODE Consortium, Innosoft, January 1994. [5] Saperia, J., C. Krupczak, R. Sturm, and J. Weinstock, "Definition of Managed Objects for Applications", Work in Progress. [6] Krupczak, C. and S. Waldbusser, "Applicability of Host Resources MIB to Application Management", Empire Technologies, Inc., International Network Services, October 1995. [7] Kille, S., and N. Freed, "Mail Monitoring MIB", RFC 1566, ISODE Consortium, Innosoft, January 1994. [8] Mansfield, G., and S. Kille, "X.500 Directory Monitoring MIB", RFC 1567, AIC Systems Laboratory, ISODE Consortium, January 1994. [9] Hazewinkel, H., E. van Hengstum, A. Pras, "Definitions of Managed Objects for HTTP", Work in Progress. 10. Acknowledgments This document was produced at the request of the Network Management Area Director following the HTTP-MIB BOF at the 35th IETF meeting to report on the applicability of the existing standards track MIBs to management of WWW servers. Kalbfleisch Informational [Page 13] RFC 2039 WWW Track MIBs November 1996 The author gratefully acknowledges the comments of the following individuals: Ned Freed, ned@innosoft.com Innosoft, Inc. Harrie Hazewinkel, hazewink@cs.utwente.nl University of Twente Cheryl Krupczak, cheryl@empiretech.com Empire Technologies, Inc. Rui Meneses, rui.meneses@jrc.it Centre for Earth Observation Jon Saperia, saperia@bgs.com BGS Systems, Inc. Juergen Schoenwaelder, schoenw@cs.utwente.nl University of Twente Chris Wellens, chrisw@iwl.com InterWorking Labs, Inc. 11. Further Information The current status of the HTTP-MIB standardization can be found on the World Wide Web at <URL:http://http-mib.onramp.net/>. An email list is in operation for discussion of this topic. To subscribe, send email to "http-mib-request@onramp.net" with the message body of "subscribe HTTP-MIB". 12. Security Considerations Security issues are not discussed in this memo. 13. Authors' Address Carl W. Kalbfleisch OnRamp Technologies, Inc. Email: cwk@onramp.net 1950 Stemmons Frwy 2026 INFOMART Dallas, TX 75207, USA Tel: (214) 672-7246 cwk@onramp.net Fax: (214) 672-7275 Kalbfleisch Informational [Page 14]