summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc5675.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc5675.txt')
-rw-r--r--doc/rfc/rfc5675.txt843
1 files changed, 843 insertions, 0 deletions
diff --git a/doc/rfc/rfc5675.txt b/doc/rfc/rfc5675.txt
new file mode 100644
index 0000000..1a8beba
--- /dev/null
+++ b/doc/rfc/rfc5675.txt
@@ -0,0 +1,843 @@
+
+
+
+
+
+
+Network Working Group V. Marinov
+Request for Comments: 5675 J. Schoenwaelder
+Category: Standards Track Jacobs University Bremen
+ October 2009
+
+
+ Mapping Simple Network Management Protocol (SNMP)
+ Notifications to SYSLOG Messages
+
+Abstract
+
+ This memo defines a mapping from Simple Network Management Protocol
+ (SNMP) notifications to SYSLOG messages.
+
+Status of This Memo
+
+ This document specifies an Internet standards track protocol for the
+ Internet community, and requests discussion and suggestions for
+ improvements. Please refer to the current edition of the "Internet
+ Official Protocol Standards" (STD 1) for the standardization state
+ and status of this protocol. Distribution of this memo is unlimited.
+
+Copyright Notice
+
+ Copyright (c) 2009 IETF Trust and the persons identified as the
+ document authors. All rights reserved.
+
+ This document is subject to BCP 78 and the IETF Trust's Legal
+ Provisions Relating to IETF Documents
+ (http://trustee.ietf.org/license-info) in effect on the date of
+ publication of this document. Please review these documents
+ carefully, as they describe your rights and restrictions with respect
+ to this document. Code Components extracted from this document must
+ include Simplified BSD License text as described in Section 4.e of
+ the Trust Legal Provisions and are provided without warranty as
+ described in the BSD License.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Marinov & Schoenwaelder Standards Track [Page 1]
+
+RFC 5675 Mapping SNMP Notifications to SYSLOG October 2009
+
+
+Table of Contents
+
+ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
+ 1.1. Conventions . . . . . . . . . . . . . . . . . . . . . . . 2
+ 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 3
+ 2.1. SNMP Notifications . . . . . . . . . . . . . . . . . . . . 3
+ 2.2. SYSLOG Notifications . . . . . . . . . . . . . . . . . . . 5
+ 3. Mapping SNMP Notifications to SYSLOG Messages . . . . . . . . 5
+ 3.1. SYSLOG Header . . . . . . . . . . . . . . . . . . . . . . 6
+ 3.2. Structured Data . . . . . . . . . . . . . . . . . . . . . 7
+ 3.3. MSG Data . . . . . . . . . . . . . . . . . . . . . . . . . 9
+ 4. Relationship to the SYSLOG-MSG-MIB . . . . . . . . . . . . . . 10
+ 5. Usage Example . . . . . . . . . . . . . . . . . . . . . . . . 10
+ 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
+ 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13
+ 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13
+ 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
+ 9.1. Normative References . . . . . . . . . . . . . . . . . . . 13
+ 9.2. Informative References . . . . . . . . . . . . . . . . . . 14
+
+1. Introduction
+
+ SNMP and SYSLOG are two widely used protocols to communicate event
+ notifications. Although co-existence of several management protocols
+ in one operational environment is possible, certain environments
+ require that all event notifications be collected by a single system
+ daemon, such as a SYSLOG collector or an SNMP notification receiver,
+ via a single management protocol. In such environments, it is
+ necessary to translate event notifications between management
+ protocols.
+
+ The latest version of SYSLOG, specified in [RFC5424], supports a
+ structured data element format. Structured data elements allow us to
+ map between SNMP notifications and SYSLOG messages without losing
+ information. In this memo, we specify a concrete mapping from SNMP
+ event notifications [RFC3416] into SYSLOG messages [RFC5424]. We
+ specify how the SYSLOG message format should be utilized to carry the
+ information contained in an SNMP notification message. A new SYSLOG
+ structured data element is defined, which carries the PDU portion of
+ an SNMP notification message.
+
+1.1. Conventions
+
+ A system that has the capability of receiving SNMP notification
+ messages from an SNMP notification originator and sending the SNMP
+ data contained inside in a SYSLOG message format to a SYSLOG
+ collector is referred to in this memo as an "SNMP-to-SYSLOG
+ translator". By definition, such a system should have an SNMP
+
+
+
+Marinov & Schoenwaelder Standards Track [Page 2]
+
+RFC 5675 Mapping SNMP Notifications to SYSLOG October 2009
+
+
+ notification receiver application and a SYSLOG originator running in
+ order to be able to perform the functions of an "SNMP-to-SYSLOG
+ translator".
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in [RFC2119].
+
+2. Background
+
+2.1. SNMP Notifications
+
+ A detailed introduction to the SNMP Management Framework can be found
+ in [RFC3410]. The SNMP Management Architecture is described in
+ [RFC3411]. Managed objects are accessed via a virtual information
+ store, termed the Management Information Base or MIB [RFC3418].
+ Objects in the MIB are defined using the mechanisms defined in the
+ Structure of Management Information (SMI) [RFC2578].
+
+ An SNMP notification message is generated and transmitted by an SNMP
+ entity on behalf of a notification originator application [RFC3413].
+ SNMP notifications are often used to notify a notification receiver
+ application at a logically remote SNMP entity that an event has
+ occurred or that a certain condition is present. There are two types
+ of SNMP protocol operations that are associated with SNMP
+ notification messages [RFC3416]:
+
+ o SNMPv2-Trap-PDU, an unconfirmed notification delivery mechanism
+
+ o InformRequest-PDU, a confirmed notification delivery mechanism
+
+ The scopedPDU portion of an SNMPv3 trap or inform message has the
+ following format [RFC3412]:
+
+ ScopedPDU ::= SEQUENCE {
+ contextEngineID OCTET STRING,
+ contextName OCTET STRING,
+ data ANY -- e.g., PDUs as defined in [RFC3416]
+ }
+
+ The data member of the SEQUENCE ScopedPDU carries an SNMPv2-Trap-PDU
+ or an InformRequest-PDU. They both have the same structure:
+
+
+
+
+
+
+
+
+
+Marinov & Schoenwaelder Standards Track [Page 3]
+
+RFC 5675 Mapping SNMP Notifications to SYSLOG October 2009
+
+
+ PDUs ::= [7] IMPLICIT SEQUENCE {
+ request-id INTEGER,
+ error-status INTEGER, -- ignored in notifications
+ error-index INTEGER, -- ignored in notifications
+ variable-bindings VarBindList
+ }
+
+ -- variable binding
+
+ VarBind ::= SEQUENCE {
+ name ObjectName,
+
+ CHOICE {
+ value ObjectSyntax,
+ unSpecified NULL, -- in retrieval requests
+ -- exceptions in responses
+ noSuchObject [0] IMPLICIT NULL,
+ noSuchInstance [1] IMPLICIT NULL,
+ endOfMibView [2] IMPLICIT NULL
+ }
+ }
+
+ -- variable-binding list
+
+ VarBindList ::= SEQUENCE (SIZE (0..max-bindings)) OF VarBind
+
+ The first two variable bindings in the variable binding list of an
+ SNMPv2-Trap-PDU or InformRequest-PDU are sysUpTime.0 [RFC3418] and
+ snmpTrapOID.0 [RFC3418], respectively. If the OBJECTS clause is
+ present in the invocation of the corresponding NOTIFICATION-TYPE
+ macro, then each corresponding variable, as instantiated by this
+ notification, is copied, in order, to the variable-bindings field.
+ If any additional variables are being included (at the option of the
+ generating SNMP entity), then each is copied to the variable-bindings
+ field.
+
+ In the case of SNMPv1 or SNMPv2c notifications, the contextEngineID
+ and the contextName parameters are not present in notification
+ messages.
+
+ This document assumes that notifications are in the format defined in
+ [RFC3416]. Notifications in the SNMPv1 notification format MUST be
+ translated as described in Section 3.1 of [RFC3584].
+
+
+
+
+
+
+
+
+Marinov & Schoenwaelder Standards Track [Page 4]
+
+RFC 5675 Mapping SNMP Notifications to SYSLOG October 2009
+
+
+2.2. SYSLOG Notifications
+
+ The SYSLOG protocol is defined in [RFC5424]. The message contains a
+ global header and a number of structured data elements. The ABNF
+ [RFC5234] representation of a SYSLOG message is defined in RFC 5424
+ [RFC5424]. The relevant productions for structured data elements
+ are:
+
+ STRUCTURED-DATA = NILVALUE / 1*SD-ELEMENT
+ SD-ELEMENT = "[" SD-ID *(SP SD-PARAM) "]"
+ SD-PARAM = PARAM-NAME "=" %d34 PARAM-VALUE %d34
+ SD-ID = SD-NAME
+ PARAM-NAME = SD-NAME
+ PARAM-VALUE = UTF-8-STRING ; characters '"', '\' and
+ ; ']' MUST be escaped.
+ SD-NAME = 1*32PRINTUSASCII
+ ; except '=', SP, ']', %d34 (")
+
+ UTF-8-STRING = *OCTET ; Any VALID UTF-8 String
+ ; "shortest form" MUST be used
+
+ OCTET = %d00-255
+ SP = %d32
+ PRINTUSASCII = %d33-126
+ NILVALUE = "-"
+
+3. Mapping SNMP Notifications to SYSLOG Messages
+
+ In this section, we define how the scopedPDU portion from an SNMP
+ notification message is used to generate a message in the SYSLOG
+ format. The notification receiver application at the SNMP-to-SYSLOG
+ translator is listening for incoming notifications. After a
+ notification is received by the SNMP engine, the data portion is
+ forwarded to the notification receiver application. The data portion
+ contains the scopedPDU of the message, which is used by the SYSLOG
+ originator on the SNMP-to-SYSLOG translator to generate a SYSLOG
+ message and send it to a SYSLOG collector (or proxy). Note that
+ every SNMP notification maps to exactly one SYSLOG message.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Marinov & Schoenwaelder Standards Track [Page 5]
+
+RFC 5675 Mapping SNMP Notifications to SYSLOG October 2009
+
+
+ +------------+ +------------------+
+ |snmp | snmp | | syslog +---------+
+ |notification| notification | +------------+ | message |syslog |
+ |originator |------------->| |syslog | |-------->|collector|
+ +------------+ | |originator | | +---------+
+ +------------+ | +------------+ |
+ |snmp | snmp | +------------+ | syslog +---------+
+ |notification| notification | |snmp | | message |syslog |
+ |originator |------------->| |notification| |-------->|collector|
+ +------------+ | |receiver | | +---------+
+ +------------+ | +------------+ |
+ |snmp | snmp | |
+ |notification| notification | SNMP-to-SYSLOG |
+ |originator |------------->| translator |
+ +------------+ +------------------+
+
+ Figure 1: SNMP-to-SYSLOG Translator Deployment
+
+ A common deployment scenario is shown in Figure 1. There can be many
+ SNMP notification originators that send SNMP event notifications to
+ an SNMP-to-SYSLOG translator. The SNMP-to-SYSLOG translator extracts
+ the data portion of the notification, generates a SYSLOG message, and
+ sends the SYSLOG message to a SYSLOG collector, which is responsible
+ for collecting and storing all notification messages. The arrows in
+ Figure 1 indicate message flows, not individual messages.
+
+ The SNMP-to-SYSLOG translator is not transparent for a SYSLOG
+ collector. The global header of the SYSLOG message generated by the
+ SNMP-to-SYSLOG translator is filled with parameters that are specific
+ for the system running the SNMP-to-SYSLOG translator, such as its
+ hostname, timestamp, etc. The data portion (scopedPDU for SNMPv3 or
+ PDU for SNMPv1/SNMPv2c) of the SNMP notification message is contained
+ in the structured data of the SYSLOG message.
+
+ Implementations MUST drop invalid SNMP messages before they are
+ passed to the SNMP-to-SYSLOG translator.
+
+3.1. SYSLOG Header
+
+ The SNMP-to-SYSLOG translator fills the HEADER field of a SYSLOG
+ message with parameters specific to the system on which it is
+ running. The default facility level for SYSLOG messages containing
+ SNMP notifications SHOULD be 3, which corresponds to messages
+ generated by system daemons. The default severity level SHOULD be 5,
+ which corresponds to "Notice: normal but significant condition". If
+ the SNMP-to-SYSLOG translator has a notion of the type of
+ notification that has been received, it might choose other values for
+ facility and severity level.
+
+
+
+Marinov & Schoenwaelder Standards Track [Page 6]
+
+RFC 5675 Mapping SNMP Notifications to SYSLOG October 2009
+
+
+ The VERSION, TIMESTAMP, HOSTNAME, APP-NAME, PROCID, and MSGID fields
+ in the SYSLOG message header are filled with values that are specific
+ to the system on which the SNMP-to-SYSLOG translator is running. The
+ character set used in the HEADER MUST be seven-bit ASCII in an eight-
+ bit field, as described in [RFC5424].
+
+3.2. Structured Data
+
+ The STRUCTURED-DATA field of a SYSLOG message carries the ScopedPDU
+ (or PDU) portion of an SNMP notification message. For the purpose of
+ carrying SNMP notification data, a new SD-ID element is defined. The
+ ABNF [RFC5234] representation of the new structured element is:
+
+ SNMP-SD-ELEMENT = "[" SNMP-SD-ID [CTX] *VARBIND "]"
+ SNMP-SD-ID = %x73.6E.6D.70 ; snmp
+ CTX = CTXENGINE CTXNAME
+ CTXENGINE = SP "ctxEngine=" %d34 HEXSTRING %d34
+ CTXNAME = SP "ctxName=" %d34 PARAM-VALUE %d34
+ VARBIND = SP VARNAME [SP VARLABEL] SP VARVALUE [SP VALSTRING]
+ VARNAME = %d118 NUM "=" %d34 OID %d34 ; "vN="
+ VARLABEL = %d108 NUM "=" %d34 PARAM-VALUE %d34 ; "lN="
+ VARVALUE = VALOID / VALHEXSTRING / VALCOUNTER32 / VALCOUNTER64
+ / VALUNSIGNED32 / VALINTEGER32 / VALIP / VALNULL
+ / VALOPAQUE / VALTIMETICKS / VALSTRING
+
+ VALOID = %d111 NUM "=" %d34 OID %d34 ; "oN="
+ VALHEXSTRING = %d120 NUM "=" %d34 HEXSTRING %d34 ; "xN="
+ VALCOUNTER32 = %d99 NUM "=" %d34 UNSIGNED32 %d34 ; "cN="
+ VALCOUNTER64 = %d67 NUM "=" %d34 UNSIGNED64 %d34 ; "CN="
+ VALUNSIGNED32 = %d117 NUM "=" %d34 UNSIGNED32 %d34 ; "uN="
+ VALINTEGER32 = %d100 NUM "=" %d34 INTEGER32 %d34 ; "dN="
+ VALIP = %d105 NUM "=" %d34 IPV4ADDRESS %d34 ; "iN="
+ VALNULL = %d110 NUM "=" %d34 %d34 ; "nN="
+ VALOPAQUE = %d112 NUM "=" %d34 HEXSTRING %d34 ; "pN="
+ VALTIMETICKS = %d116 NUM "=" %d34 UNSIGNED32 %d34 ; "tN="
+ VALSTRING = %d97 NUM "=" %d34 PARAM-VALUE %d34 ; "aN="
+
+ NUM = NONZERODIGIT 0*DIGIT
+
+ OID = OIDSTART *("." OIDSUBID)
+ OIDSTART = (("0." / "1.") [%d49-51] DIGIT) / ("2." OIDSUBID)
+ OIDSUBID = ZERO / (NONZERODIGIT *DIGIT)
+
+ PARAM-VALUE = UTF-8-STRING ; characters '"', '\' and
+ ; ']' MUST be escaped.
+ UTF-8-STRING = *OCTET ; Any VALID UTF-8 String
+ ; "shortest form" MUST be used
+ HEXSTRING = *HEX
+
+
+
+Marinov & Schoenwaelder Standards Track [Page 7]
+
+RFC 5675 Mapping SNMP Notifications to SYSLOG October 2009
+
+
+ INTEGER32 = ["-"] NONZERODIGIT 0*DIGIT
+ UNSIGNED32 = NONZERODIGIT 0*DIGIT
+ UNSIGNED64 = NONZERODIGIT 0*DIGIT
+ IPV4ADDRESS = d8 "." d8 "." d8 "." d8
+
+ d8 = DIGIT ; 0-9
+ / %d49-57 DIGIT ; 10-99
+ / "1" 2DIGIT ; 100-199
+ / "2" %d48-52 DIGIT ; 200-249
+ / "25" %d48-53 ; 250-255
+
+ HEX = DIGIT / %x41-46 / %x61-66 ; 0-9 / A-F / a-f
+ NONZERODIGIT = %d49-57
+ ZERO = %d48
+ DIGIT = ZERO / NONZERODIGIT
+ SP = %d32
+
+ Each SNMP-SD-ELEMENT starts with the SD-ID "snmp". The first two
+ SD-ID parameters are "ctxEngine" and "ctxName". The context MUST be
+ present in an SNMPv3 notification and therefore "ctxEngine" and
+ "ctxName" MUST be present in a SYSLOG message generated by an SNMP-
+ to-SYSLOG translator from an SNMPv3 notification. The
+ contextEngineID is encoded as an hexadecimal string while the
+ contextName is encoded as a UTF8 string.
+
+ The remaining parameters in the "snmp" SD-ID correspond to the
+ varbind list elements contained in the SNMP PDU. The name of a
+ varbind is encoded as an OID in dotted notation. The rendered OID is
+ carried in a "vN" parameter, where N identifies the position of the
+ varbind in the varbind list of the SNMP message (the first varbind
+ having the position 1). A MIB-aware implementation may in addition
+ generate a parameter "lN" carrying the descriptor of the associated
+ MIB object plus the instance identifier suffix (also called an OID
+ label). The number N again identifies the position of the varbind in
+ the varbind list of the SNMP message.
+
+ The value of a varbind is encoded depending on its type according to
+ the rules shown in Table 1, and type-specific parameter names are
+ used to convey the type information. The number N again identifies
+ the position of the varbind in the varbind list of the SNMP message.
+ A MIB-aware implementation may in addition generate a parameter "aN"
+ carrying an alternate textual representation of the value, which is
+ obtained by applying DISPLAY-HINTs and translating named numbers into
+ corresponding labels or OBJECT IDENTIFIER values to descriptors. For
+ SNMP object types that have a DISPLAY-HINT of the form 'Ma' or 'Mt',
+ where M is some number, a MIB-aware implementation can choose to
+ include the "aN" parameter and to suppress the corresponding "xN"
+ parameter. This special case saves space for textual objects. A
+
+
+
+Marinov & Schoenwaelder Standards Track [Page 8]
+
+RFC 5675 Mapping SNMP Notifications to SYSLOG October 2009
+
+
+ receiver receiving an "aN" parameter without a matching value at
+ position N can unambiguously convert the value carried in the "aN"
+ parameter back to an OCTET STRING value.
+
+ While the inclusion of additional parameters carrying OID labels or
+ alternate value representations increases human readability, this
+ comes at the cost of increased message size, which may cause
+ truncation of SYSLOG messages. Therefore, implementations SHOULD
+ provide a configuration mechanism to enable/disable the generation of
+ parameters carrying OID labels or alternate value representations.
+
+ +--------------------+------------+--------------------------+
+ | SNMP Type | PARAM-NAME | Value Encoding |
+ +--------------------+------------+--------------------------+
+ | OBJECT IDENTIFIER | oN | dotted-decimal notation |
+ | OCTET STRING | xN | hexadecimal string |
+ | Counter32 | cN | unsigned decimal number |
+ | Counter64 | CN | unsigned decimal number |
+ | Unsigned32 | uN | unsigned decimal number |
+ | INTEGER, Integer32 | dN | signed decimal number |
+ | IpAddress | iN | dotted quad notation |
+ | Opaque | pN | hexadecimal (BER) string |
+ | TimeTicks | tN | unsigned decimal number |
+ | NULL | nN | zero-length string |
+ +--------------------+------------+--------------------------+
+
+ Table 1: Mapping of SNMP Types to SD Params
+
+ The SYSLOG message generated by the SNMP-to-SYSLOG translator may, in
+ addition to the SNMP-SD-ELEMENT, include other structured data
+ elements in its structured data part. These additional structured
+ data elements MUST comply with the specification in [RFC5424].
+
+ In particular, the parameters in the "origin" SD-ID SHOULD identify
+ the originator of the SNMP notification. A suitable value for the
+ "ip" parameter MAY be taken from the snmpTrapAddress varbind if
+ present, and a suitable value for the "enterpriseId" parameter MAY be
+ extracted from the snmpTrapOID varbind.
+
+3.3. MSG Data
+
+ The MSG part of the SYSLOG message is optional and may contain a
+ free-form message that provides a textual description of the SNMP
+ event notification. According to [RFC5424], the character set used
+ in MSG SHOULD be Unicode, encoded using UTF-8 as specified in
+ [RFC3629]. If the originator cannot encode the MSG in Unicode, it
+
+
+
+
+
+Marinov & Schoenwaelder Standards Track [Page 9]
+
+RFC 5675 Mapping SNMP Notifications to SYSLOG October 2009
+
+
+ MAY use any other encoding. The originator MAY use the "language"
+ parameters defined in [RFC5424] to convey information about the
+ natural language used inside MSG.
+
+4. Relationship to the SYSLOG-MSG-MIB
+
+ A companion document [RFC5676] defines an SNMP MIB module to
+ represent SYSLOG messages and to send SYSLOG messages as SNMP
+ notifications to SNMP notification receivers. This section discusses
+ the possibilities of using both specifications in combination.
+
+ A SYSLOG collector implementing the SYSLOG-MSG-MIB module and the
+ mapping of SNMP notifications to SYSLOG messages may be configured to
+ translate received SYSLOG messages containing SNMP notifications back
+ into the original SNMP notification. In this case, the relevant
+ tables of the SYSLOG-MSG-MIB will not be populated for SYSLOG
+ messages carrying SNMP notifications. This configuration allows
+ operators to build a forwarding chain where SNMP notifications are
+ "tunneled" through SYSLOG messages. Due to size restrictions of the
+ SYSLOG transports and the more verbose textual encoding used by
+ SYSLOG, there is a possibility that SNMP notification content will
+ get truncated when tunneled through SYSLOG, and thus the resulting
+ SNMP notification may be incomplete.
+
+ An SNMP management application supporting the SYSLOG-MSG-MIB and the
+ mapping of SNMP notifications to SYSLOG messages may process
+ information from the SYSLOG-MSG-MIB in order to emit a SYSLOG message
+ representing the SYSLOG message recorded in the SYSLOG-MSG-MIB
+ module. This configuration allows operators to build a forwarding
+ chain where SYSLOG messages are "tunneled" through SNMP messages. A
+ notification receiver can determine whether a syslogMsgNotification
+ contained all structured data element parameters of a SYSLOG message.
+ In case parameters are missing, a forwarding application MUST
+ retrieve the missing parameters from the SYSLOG-MSG-MIB. Regular
+ polling of the SYSLOG-MSG-MIB can be used to take care of any lost
+ SNMP notifications.
+
+5. Usage Example
+
+ Here we provide an example of how an SNMP linkUp trap message is
+ mapped into a SYSLOG message by using the mappings defined in
+ Section 3.1 and Section 3.2.
+
+ The linkUp notification is defined in [RFC2863] as follows:
+
+ linkUp NOTIFICATION-TYPE
+ OBJECTS { ifIndex, ifAdminStatus, ifOperStatus }
+ STATUS current
+
+
+
+Marinov & Schoenwaelder Standards Track [Page 10]
+
+RFC 5675 Mapping SNMP Notifications to SYSLOG October 2009
+
+
+ DESCRIPTION
+ "A linkUp trap signifies that the SNMP entity, acting in an
+ agent role, has detected that the ifOperStatus object for
+ one of its communication links left the down state and
+ transitioned into some other state (but not into the
+ notPresent state). This other state is indicated by the
+ included value of ifOperStatus."
+ ::= { snmpTraps 4 }
+
+ The scopedPDU portion of an SNMP linkUp trap sent using the SNMPv3
+ message format is shown below (the left column shows the Basic
+ Encoding Rules (BER) encoding, while the right column indicates the
+ corresponding ASN.1 definitions):
+
+ 30:7C SEQUENCE {
+ 04:08:80:00:02:B8:04:61:62:63 800002b804616263
+ 04:04:63:74:78:31 "ctx1"
+ A7:6A SNMPv2-Trap-PDU {
+ 02:03:6D:08:67 INTEGER 7145575
+ 02:01:00 INTEGER 0
+ 02:01:00 INTEGER 0
+ 30:5D SEQUENCE OF {
+ 30:0F SEQUENCE {
+ 06:08:2B:06:01:02:01:01:03:00 sysUpTime.0
+ 43:03:01:72:8C 94860 }
+ 30:17 SEQUENCE {
+ 06:0A:2B:06:01:06:03:01:01:04:01:00 snmpTrapOID.0
+ 06:09:2B:06:01:06:03:01:01:05:04 linkUp }
+ 30:0F SEQUENCE {
+ 06:0A:2B:06:01:02:01:02:02:01:01:03 ifIndex.3
+ 02:01:03 3 }
+ 30:0F SEQUENCE {
+ 06:0A:2B:06:01:02:01:02:02:01:07:03 ifAdminStatus.3
+ 02:01:01 up(1) }
+ 30:0F SEQUENCE {
+ 06:0A:2B:06:01:02:01:02:02:01:08:03 ifOperStatus.3
+ 02:01:01 up(1) } } } }
+
+ The corresponding SYSLOG message generated by the SNMP-to-SYSLOG
+ translator is shown below. (SYSLOG examples should be considered to
+ be on one line. They are wrapped on multiple lines in this document
+ for readability purposes only.)
+
+ <29>1 2003-10-11T22:14:15.003Z mymachine.example.com snmptrapd - ID47
+ [snmp ctxEngine="800002b804616263" ctxName="ctx1"
+ v1="1.3.6.1.2.1.1.3.0" l1="sysUpTime.0" d1="94860"
+ v2="1.3.6.1.6.3.1.1.4.1.0" l2="snmpTrapOID.0"
+ o2="1.3.6.1.6.3.1.1.5.4" a2="linkUp"
+
+
+
+Marinov & Schoenwaelder Standards Track [Page 11]
+
+RFC 5675 Mapping SNMP Notifications to SYSLOG October 2009
+
+
+ v3="1.3.6.1.2.1.2.2.1.1.3" d3="3"
+ v4="1.3.6.1.2.1.2.2.1.7.3" d4="1" a4="up"
+ v5="1.3.6.1.2.1.2.2.1.8.3" d5="1" a5="up"]
+
+ The corresponding SYSLOG message has a priority value of 29, which
+ means a facility level of 3 (system daemons) and a severity level of
+ 5 (Notice: normal but significant condition) according to the
+ algorithm for calculation of priority value specified in Section
+ 6.2.1 of [RFC5424]. The rest of the fields in the header of the
+ SYSLOG message are parameters that are specific to the system running
+ the SNMP-to-SYSLOG translator. The SYSLOG version is 1 and the
+ message was generated at 22:14:15.003Z on 2003-10-11T by the host
+ "mymachine.example.com". The application on the SNMP-to-SYSLOG
+ translator that generated the message was "snmptrapd"; there is no
+ information about the process id, and the message on the SNMP-to-
+ SYSLOG system is identified with the MSGID of ID47.
+
+ The SYSLOG message contains one structured data element with an SD-ID
+ of "snmp", which means that this is the scopedPDU portion of an SNMP
+ event notification message. The data that is contained in the
+ notification is associated with the ContextEngineID "123456" and
+ ContextName "ctx1". The request-id of the SNMP notification message
+ was "7145575". Then follows the data portion of the scopedPDU. The
+ first two variables contained in the data portion are always the
+ sysUpTime.0 and snmpTrapOID.0. An snmpTrapOID.0 with a value of
+ "1.3.6.1.6.3.1.1.5.4" means that this is a linkUp trap. The
+ parameters v3="1.3.6.1.2.1.2.2.1.1.3" d3="3" mean that the SNMP
+ notification message is carrying the ifIndex object, which has a type
+ INTEGER and a value of 3. The parameters v4="1.3.6.1.2.1.2.2.1.7.3"
+ d4="1" mean that the SNMP notification message is carrying the object
+ ifAdminStatus, which has a type INTEGER and a value of 1. The
+ parameters v5="1.3.6.1.2.1.2.2.1.8.3" d5="1" mean that the SNMP
+ notification message is carrying the object ifOperStatus, which has a
+ type INTEGER and a value of "1".
+
+6. IANA Considerations
+
+ IANA registered the SD-ID value "snmp" together with the PARAM-NAME
+ values specified in Section 3.2 in the registry for SYSLOG Structured
+ Data ID Values according to Section 9 in [RFC5424]. The notation <N>
+ indicates a position number.
+
+ SD-ID PARAM-NAME
+ snmp OPTIONAL
+ ctxEngine OPTIONAL
+ ctxName OPTIONAL
+ v<N> OPTIONAL
+ l<N> OPTIONAL
+
+
+
+Marinov & Schoenwaelder Standards Track [Page 12]
+
+RFC 5675 Mapping SNMP Notifications to SYSLOG October 2009
+
+
+ o<N> OPTIONAL
+ x<N> OPTIONAL
+ c<N> OPTIONAL
+ C<N> OPTIONAL
+ u<N> OPTIONAL
+ d<N> OPTIONAL
+ i<N> OPTIONAL
+ n<N> OPTIONAL
+ p<N> OPTIONAL
+ t<N> OPTIONAL
+ a<N> OPTIONAL
+
+7. Security Considerations
+
+ The security considerations discussed in [RFC5424] apply to this
+ document.
+
+ The SNMP architecture supports an access control mechanism, ensuring
+ that SNMP notifications are only sent to receivers who are authorized
+ to receive the notification. Network operators using this mapping of
+ SNMP notifications to SYSLOG messages should enforce a consistent
+ policy, preventing people from accessing SNMP notifications via the
+ SYSLOG mapping that would otherwise not be accessible.
+
+8. Acknowledgments
+
+ The editors wish to thank the following individuals for providing
+ helpful comments on various versions of this document: Martin
+ Bjorklund, Washam Fan, Rainer Gerhards, Tom Petch, and Dan Romascanu.
+
+9. References
+
+9.1. Normative References
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An
+ Architecture for Describing Simple Network Management
+ Protocol (SNMP) Management Frameworks", STD 62, RFC 3411,
+ December 2002.
+
+ [RFC3412] Case, J., Harrington, D., Presuhn, R., and B. Wijnen,
+ "Message Processing and Dispatching for the Simple Network
+ Management Protocol (SNMP)", STD 62, RFC 3412,
+ December 2002.
+
+
+
+
+
+Marinov & Schoenwaelder Standards Track [Page 13]
+
+RFC 5675 Mapping SNMP Notifications to SYSLOG October 2009
+
+
+ [RFC3413] Levi, D., Meyer, P., and B. Stewart, "Simple Network
+ Management Protocol (SNMP) Applications", STD 62,
+ RFC 3413, December 2002.
+
+ [RFC3416] Presuhn, R., "Version 2 of the Protocol Operations for the
+ Simple Network Management Protocol (SNMP)", STD 62,
+ RFC 3416, December 2002.
+
+ [RFC3418] Presuhn, R., "Management Information Base (MIB) for the
+ Simple Network Management Protocol (SNMP)", STD 62,
+ RFC 3418, December 2002.
+
+ [RFC3584] Frye, R., Levi, D., Routhier, S., and B. Wijnen,
+ "Coexistence between Version 1, Version 2, and Version 3
+ of the Internet-standard Network Management Framework",
+ BCP 74, RFC 3584, August 2003.
+
+ [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
+ 10646", STD 63, RFC 3629, November 2003.
+
+ [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
+ Specifications: ABNF", RFC 5234, January 2008.
+
+ [RFC5424] Gerhards, R., "The Syslog Protocol", RFC 5424, March 2009.
+
+ [RFC5676] Schoenwaelder, J., Clemm, A., and A. Karmakar,
+ "Definitions of Managed Objects for Mapping SYSLOG
+ Messages to Simple Network Management Protocol (SNMP)
+ Notifications", RFC 5676, October 2009.
+
+9.2. Informative References
+
+ [RFC2578] McCloghrie, K., Perkins, D., and J. Schoenwaelder,
+ "Structure of Management Information Version 2 (SMIv2)",
+ RFC 2578, STD 58, April 1999.
+
+ [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group
+ MIB", RFC 2863, June 2000.
+
+ [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart,
+ "Introduction and Applicability Statements for Internet-
+ Standard Management Framework", RFC 3410, December 2002.
+
+
+
+
+
+
+
+
+
+Marinov & Schoenwaelder Standards Track [Page 14]
+
+RFC 5675 Mapping SNMP Notifications to SYSLOG October 2009
+
+
+Authors' Addresses
+
+ Vladislav Marinov
+ Jacobs University Bremen
+ Campus Ring 1
+ 28725 Bremen
+ Germany
+
+ EMail: v.marinov@jacobs-university.de
+
+
+ Juergen Schoenwaelder
+ Jacobs University Bremen
+ Campus Ring 1
+ 28725 Bremen
+ Germany
+
+ EMail: j.schoenwaelder@jacobs-university.de
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Marinov & Schoenwaelder Standards Track [Page 15]
+