Network Working Group M. Sibley Category: Internet-Draft May 2002 Crosswire Industries Inc. Expires Distance Vectored Monitoring Protocol draft-sibley-dist-vect-monit-protocol-01.txt Status of this Memo: This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC 2026. 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. Abstract: Distance Vectored Monitoring Protocol (DVMP) is a inter-device communications protocol that merges the intelligence of routing protocol design with the ability to notify network management personnel of troubles experienced on managed devices. DVMP is intended to suppliment or replace conventional SNMP based monitoring systems in small to medium sized autonomous networks, require minimal planning or configuration overhead, and be familiar in configuration and operation to network administrators. Acknowledgements: TBA Table of Contents: 1. Scope 2. Introduction 3. Server Description 3.1 DVMP Extended Addressing 3.2 DVMP Message Transport 3.3 Metrics 3.4 Split Horizon 3.5 Hold Down Timers 3.6 Expiration 3.7 DVMP Routing Table 3.8 Import Filters 3.9 Default Disabled Broadcasts 4. Packet Format 4.1 DVMP Packet Diagram 4.2 DVMP Header 4.3 DVMP Message 5. Protocol Security 6. Summary 7. References 1. Scope: This document intends to describe a network monitoring protocol in sufficient detail for developers to construct independent interoperable server software packages. It assumes a basic knowledge of TCP/IP and network programming skills. A basic familiarity with routing protocols and SNMP is recommended. 2. Introduction: This memo describes a proposal for a new network monitoring protocol based on the Bellman-Ford (or distance vector) algorithm. In distance vectored protocols, hosts exchange information only with adjacent hosts. The information contained has historically been routing information. It can be demonstrated methematically that multiple hosts working together based on this algorithm will construct an optimized table of routing information, and will eventually converge such that the tables will require no further adjustment provided network paths remain the same. DVMP operates as if it were a routing protocol. However its primary function is the delivery of event information rather than routing information. DVMP does not break the distance vector algorithm, because it includes all the necessary information for routing to the host originating an announcement. It simply extends the address of its hosts device to allow pinpointing of the origins of events. This document is arranged in two parts. The first describes the behavior of the server processes that use DVMP. The second describes the packets that are transmitted between DVMP servers. 3. Server Description A DVMP Server process must originate, receive and process DVMP packets. The architecture of those packets is described in section 4. The following should define how a server evaluates those datagrams in transit. 3.1 DVMP Extended Addressing DVMP extends the addressing scheme already chosen on the host network to include specific software or hardware locations within hosts running DVMP. Where IPV4 has 32 bit address unique to the Internet routing environment, DVMP extends that for an additional 32 bits in its Event Identifier field. For instance: 192.168.1.1 is an IP address. 10.114.224.205 is a DVMP Event Identifier (or Event Origin). Since the host address is unique to the routing system, the fully qualified Event Address 192.168.1.1-104.114.224.205 is likewise unique to the routing system. The extension defines where on the origin host where a problem exists. This specification makes no attempt to define the significance or the contents of Event Identifiers. It only recommends that the development of these tables be used exclusively for LOCATIONS of events, such as shelf->slot->port relationships or process IDs. The relationship of a state change to the introduction of a message to the DVMP routing process should be left up to the implementor. Since DVMP routing tables are used primarily for notification, rather than processing for shortest path, it is expected that there will be implementor defined filtering mechanisms for this data. Additional features have been added to DVMP for that purpose. They are "DVMP Priority", and "Event Counter". These fields are mostly left up to the implementor for content population. The few requirements for the content of these fields are addressed in section 4. 3.2 DVMP Message Transport DVMP datagrams consist of a header, and a message part. These two parts are contained within a UDP Packet. Of the two parts the header content is only represented once, while the message part may consist of multiple messages. For communication DVMP relies on Broadcast packets. DVMP servers broadcast traffic to all hosts on DVMP enabled directly connected segments. Unlike routing protocols it IS likely that hosts having single gateways will run DVMP. This does not break the Distance Vectored model. For security purposes section 3.7 defines an additional feature called Disabled Default Broadcast. 3.3 Metrics Once a DVMP message is received by a DVMP daemon, it is evaluated against the DVMP routing table. It is then either suppressed, or appended to the table and distributed by broadcast. The decision between supression and readvertisement is based on the Metric contained in the DVMP packet. Metrics are a simple method for determining shortest path between two in a distance vectored routing environment. Two messages are evaluated. The one with the lower metric is entered into the routing table. The may be retained or discarded but not evaluated for routing unless the preferred route is revoked from the table. As a DVMP messages received by a DVMP enabled host its metric value incremented by one. Each subsequent receiving host of that message also increments that value by one until the metric value reaches 16. The value 16 is determined to be unreachable, and therefore no further advertisements after a Metric of 15 will occur. 3.4 Split Horizon with Poison Reverse Updates Split horizon is a feature of Distance Vectored protocols that reduces routing loops and reduces the time to full convergence. Split horizon with poison reverse updates is actually quite simple. If a DVMP message is received from a peer, a copy of that message is made. That copy has its metric set to 16 (infinity) and is then advertised back to the peer from which the advertisement was received. This causes routers to not advertise the same route back and forth until the metric reaches infinity. In the case of a failure the closer host between the pair will already see the downhill peer as having as not being able to reach the Event Address. 3.5 Hold Down Timers In order to reduce the amount of churn within the routing tables in a DVMP enabled network, DVMP implements hold down timers. DVMP messages specifying a previously unknown Event Address, or an Event Address's with a Metric value that precedes the existing Metric value may be propagated immediately to peer DVMP hosts. Those DVMP Event Addresses that are redundant to ones already contained in the DVMP routing table should be queued for announcement. The queuing interval should 30 seconds from the last announcement for that Event Address. 3.6 Expiration Due to the constant state of change in routed networks, it is required that information periodically time out. Entries in the routing table should be queued for 300 seconds. If an identical DVMP message is not received within that time the Server process should delete the Event Address from its tables. An additional feature may be implemented to permit manual clearing of events from the DVMP table. For that purpose the Command attribute of the DVMP packet retains a clearing feature. 3.6.1 False Expiration When a DVMP server receives a DVMP message with a clear command flag set, it should check its routing table for matching event addresses. If an address is matching ,and the receiving host originiated the event, the recieving host should clear that entry from its routing table and promptly announce an unreachable metric for that Event Address on all DVMP enabled interfaces. Events that are falsely expired by manual intervention may be repopulated to the routing table, and readvertised by the origin host. False expiration does not suppress future announcements. It only attempts to clear them from the current instance of the collective routing table. 3.7 The DVMP Routing Table A DVMP server process must maintain a routing table of event origins. This is similar to routing tables in other distance vectored routing protocols. DVMP has extended features that optimize it for carrying event traffic. DVMP must maintain a routing table including the following data: 3.7.1 The origin address. This may be loopback address or the address of a connected interface of the device where the event originated. 3.7.2 The gateway address: This is the IP address of a directly connected host whose is the next hop towards the origin host. 3.7.3 The gateway interface: This is the physical network which is used to reach the first gateway. 3.7.4 The metric: This is a count of the segments to the origin host. The metric is incremented by the host receiving the DVMP message. DVMP messages may be artificially inflated to control advertisement distance. A metric of 16 is considered infinity and designates an unreachable host. 3.7.5 The timer: This is the time since the entry was last updated. 3.7.6 The DVMP Priority: This is a numerically represented priority for the event that occurred that is set by the origin host. The DVMP Priority should not be interfered with during retransmission of the DVMP message. 3.7.7 The DVMP Identifier: This is a 32 bit value that uniquely identifies a condition that generated the event message. DVMP Identifiers should be arranged hierarchically similar to SNMP Object Identifiers. Unlike SNMP Object Identifiers DVMP ID's are fixed length. Extended requirements for DVMP Identifiers are discussed below. 3.8 Import Filters DVMP Implementations may include configurable bit masked filters for controlling introduction of messages into their local DVMP table. This applies to both DVMP identifiers and Origin Addresses. 3.9 Default Disabled Broadcasts Since DVMP is passing information that may be considered proprietary, DVMP implementations must not include interfaces as DVMP transport segments by default. All interfaces that broadcast DVMP messages should be explicitly enabled prior to any message being transmitted over those interfaces. 4. Packet Format A DVMP packet is a UDP packet containing one DVMP header and one or more DVMP messages. A DVMP header and message together are a minimum of 48 bytes long. DVMP packets can grown to the Maximum payload capabilities of UDP. DVMP server processes should listen for traffic on UDP port 720. 4.1 Typical DVMP Packet. (Bytes in Perenthesis) 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | command (1) | version (1) | Metric (1) | Auth Type (1) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Authorization Info (16) | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Expansion Field (4) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | DVMP Domain (2) | DVMP Priority (2) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IP Address (4) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Subnet Mask (4) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Hop (4) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Event Counter (4) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Event Identifier (4) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4.2 The DVMP Header consists of the first 26 bytes of the DVMP packet contents. It contains the fields: 4.2.1 Command The following numerical values and their associated functions are listed below. Values: 1 - request A request for a responding system to send all or part of its DVMP table. 2 - response A message containing all or part of the senders DVMP table. This message my be sent in response to a request or poll or it may be an update message generated by the sender. 8 - clear A management message telling a host with an event origin to clear the event with the included identifier from its DVMP table and advertise an unreachable metric for that event. 4.2.2 Version Values: 1 - Version 1. The current Version. 4.2.3 The Metric represents a value from 0 to 16. Only the first five bits of this field in the DVMP message are evaluated in version 1. The value 16 is a message the denotes an unreachable event. Setting a metric to 16 and waiting for expiration of the route is the normal method for removing a route from the routing table. 4.2.4 Authorization Type Value: 1 - Simple Password This indicates that the Authorization info field will include a plain text password. 4.2.5 Authorization Info This field contains the authenticator info. In version 1 this data is a password left justified, and null padded. 4.2.6 Expansion Field In version 1 this field is 4 bytes and contains only zeroes. This field is intended for use by future versions of the protocol. 4.2.7 DVMP Domain Similar to a routing domain in RIP this allows packets to be differentiated between DVMP daemon processes. If the server implementation permits event filtering, multiple DVMP daemon processes can be customized for different monitoring purposes. 4.3 DVMP Message The DVMP message is 22 bytes long. Multiple DVMP messages may be appended to a single DVMP header. DVMP messages contain the fields: 4.3.1 Event Priority This is a numerical value indicating a measure of importance. Lower numbers are higher priority. Event priorities 0 and 15 are reserved for future implimentations. 4.3.2 IP Address The Internet protocol address of the host originating a DVMP event. This may be the loopback of a host, or an interface. Addresses from interfaces other than loopbacks in this field may help to identify redundant messages. For example a point to point link failure may generate messages from both sides of a connection. 4.3.3 Subnet Mask This 32 bit field may be optionally populated with the subnet mask of the address announced in the IP Address field. All addresses announced with all zeros subnet mask field will be assumed to be hosts addresses. This field assists the origin device with an ability to point at a connected network. Server implementations may consolidate sub nets for representation or provide search facilities based on subnet. 4.3.4 Next Hop The address of the directly connected gateway that is the preferred route to the host originating a DVMP message. 4.3.5 Event Counter This is a 32 bit field that may optionally be populated by the origin host. It can represent the number of instances an event was recorded on the origin host. It may also represent some other counted condition, such as a bit-rate counter, or a binary True/False state. 4.3.6 Event Identifier This is 32 bit unique identifier that expresses a noteworthy condition. DVMP Identifiers are not directly responsible for representing a state. Instead they are intended to identify an additional layer of specificity for WHERE a problem exists. Not necessarily how it exists. Only in the instance that where and how a problem exists are indistinguishable from each other should a DVMP identifier indicate any sort of state. The normal function of DVMP is that the existence of the message alone indicates the noteworthy condition. The revocation of the message indicates that the condition is no longer noteworthy. DVMP does not presume to know what the origin device is thinking, only to provide transport and user access to the information the origin device finds important. Implimentations needing more specificity on what or how a problem exists rather than where it exists, should refer to the event counter field. 4.3.6.1 Reserved Event Indentifiers Event identifiers with the first octet numbering 1 are reserved for local use. Developers may provide a mechanism for implimentors to to inject their own events into the DVMP tables. The Reserved Event Identifiers should be the only Event Identifiers accessible by this mechanism. 4.3.6.2 Standard Event Identifiers Event identifiers with first octets numbering 2 - 15 are Standard Event Identifiers. Standard Event Identifiers are intended to provide a base framework for vendors of DVMP enabled devices to express events that are common across multivendor networks. Events numbered within the Standard Event Indentifier range may indicate redundantly to vendor specific event identifiers in the DVMP table. Developers may provide mapping mechanisms to translate vendor specific event identifiers to Standard Event Identifiers, to aid them in simplifiying their perception of the network. 5. Protocol Security DVMP impliments security in two ways 1. By transporting DVMP messages only on configured interfaces. This attempts to prevent leakage of information regarding the condition of the network. 2. By providing a per message authentication mechanism. In version 1 this is limited to a 16 byte plain password. Strong authentication is expected to be added in later versions. Multiple options are available for doing so and maintaining interoperability. The protocol is designed with an Expansion field adjacent to the Authentication Info field for precisely this reason. 6. Summary As distance vectored protocols in the IP routing arena move towards obsolescence, we may note that it is precisely the features that create obsolescence in the routing environment that make it functional in the monitoring environment. Slow convergence based on timeouts in the routing tables, can be adjusted or scaled to compliment the MTTR for Network monitoring teams. Peer to peer routing relationships are designed to circumvent transport failure for event messages without dependence on other routing protocols. Distance vectored metrics set by hop count, can create automatic regionalized triage for operations centers. Simply examining the metric for an event gives some information that is usefull for regionalizing symptoms. Relatively low quantity of configuration variables makes implementation in freshly installed unmonitored networks, a low investment proposition. Though DVMP may not be an optimal solution for monitoring large carrier class networks, it may be useful as a supplement to those environments, and would definately be usefull in newly constructed network infrastructure that does not have conventional monitoring in place. 7. References [1] C. Hedrick, RFC 1058 "Routing Information Protocol" [2] G. Malkin RFC 1388 "RIP Version 2 Carrying additional Information"