draft-ietf-tsvwg-udplite-mib-03.txt   rfc5097.txt 
Transport Area Working Group G. Renker Network Working Group G. Renker
Internet-Draft G. Fairhurst Request for Comments: 5097 G. Fairhurst
Intended status: Standards Track University of Aberdeen Category: Standards Track University of Aberdeen
Expires: May 1, 2008 October 29, 2007 January 2008
MIB for the UDP-Lite protocol
draft-ietf-tsvwg-udplite-mib-03
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
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.
This Internet-Draft will expire on May 1, 2008. MIB for the UDP-Lite Protocol
Copyright Notice Status of This Memo
Copyright (C) The IETF Trust (2007). 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.
Abstract Abstract
This document specifies a Management Information Base (MIB) module This document specifies a Management Information Base (MIB) module
for the Lightweight User Datagram Protocol. It defines a set of new for the Lightweight User Datagram Protocol (UDP-Lite). It defines a
MIB objects to characterise the behaviour and performance of set of new MIB objects to characterise the behaviour and performance
transport layer endpoints deploying UDP-Lite. UDP-Lite resembles of transport layer endpoints deploying UDP-Lite. UDP-Lite resembles
UDP, but differs from the semantics of UDP by the addition of a UDP, but differs from the semantics of UDP by the addition of a
single option. This adds the capability for variable-length data single option. This adds the capability for variable-length data
checksum coverage, which can benefit a class of applications that checksum coverage, which can benefit a class of applications that
prefer delivery of (partially) corrupted datagram payload data in prefer delivery of (partially) corrupted datagram payload data in
preference to discarding the datagram. preference to discarding the datagram.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction ....................................................2
1.1. Relationship to the UDP-MIB . . . . . . . . . . . . . . . 3 1.1. Relationship to the UDP-MIB ................................2
1.2. Relationship to HOST-RESOURCES-MIB and SYSAPPL-MIB . . . . 5 1.2. Relationship to HOST-RESOURCES-MIB and SYSAPPL-MIB .........4
1.3. Interpretation of the MIB Variables . . . . . . . . . . . 5 1.3. Interpretation of the MIB Variables ........................5
1.4. Conventions . . . . . . . . . . . . . . . . . . . . . . . 8 1.4. Conventions ................................................8
2. The Internet-Standard Management Framework . . . . . . . . . . 9 2. The Internet-Standard Management Framework ......................8
3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 10 3. Definitions .....................................................8
4. Security Considerations . . . . . . . . . . . . . . . . . . . 23 4. Security Considerations ........................................19
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 5. IANA Considerations ............................................20
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 27 6. Acknowledgments ................................................20
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32 7. References .....................................................20
7.1. Normative References . . . . . . . . . . . . . . . . . . . 32 7.1. Normative References ......................................20
7.2. Informative References . . . . . . . . . . . . . . . . . . 32 7.2. Informative References ....................................21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 34
Intellectual Property and Copyright Statements . . . . . . . . . . 35
1. Introduction 1. Introduction
The Lightweight User Datagram Protocol (UDP-Lite) [RFC3828] (also The Lightweight User Datagram Protocol (UDP-Lite) [RFC3828] (also
known as UDPLite) is an IETF standards-track transport protocol. The known as UDPLite) is an IETF standards-track transport protocol. The
operation of UDP-Lite is similar to the User Datagram Protocol (UDP) operation of UDP-Lite is similar to the User Datagram Protocol (UDP)
[RFC0768], but can also serve applications in error-prone network [RFC768], but can also serve applications in error-prone network
environments that prefer to have partially damaged payloads delivered environments that prefer to have partially damaged payloads delivered
rather than discarded. This is achieved by changing the semantics of rather than discarded. This is achieved by changing the semantics of
the UDP Length field to that of a Checksum Coverage field. If this the UDP Length field to that of a Checksum Coverage field. If this
feature is not used, UDP-Lite is semantically identical to UDP. feature is not used, UDP-Lite is semantically identical to UDP.
The interface of UDP-Lite differs from that of UDP by the addition of The interface of UDP-Lite differs from that of UDP by the addition of
a single option, which communicates a length value. At the sender a single option, which communicates a length value. At the sender
this specifies the intended datagram checksum coverage; at the this specifies the intended datagram checksum coverage; at the
receiver it signifies a minimum coverage threshold for incoming receiver it signifies a minimum coverage threshold for incoming
datagrams. This length value may also be modified during the datagrams. This length value may also be modified during the
lifetime of a connection. UDP-Lite does not provide mechanisms to lifetime of a connection. UDP-Lite does not provide mechanisms to
negotiate the checksum coverage between the sender and receiver. negotiate the checksum coverage between the sender and receiver.
Where required, this needs to be communicated by another protocol. Where required, this needs to be communicated by another protocol.
DCCP [RFC4340] for instance includes a capability to negotiate The Datagram Congestion Control Protocol (DCCP) [RFC4340] for
checksum coverage values. instance includes a capability to negotiate checksum coverage values.
This document defines a set of runtime statistics (variables) that This document defines a set of runtime statistics (variables) that
facilitate both network management/monitoring as well as unified facilitate network management/monitoring as well as unified
comparisons between different protocol implementations and operating comparisons between different protocol implementations and operating
environments. To provide a common interface for users and environments. To provide a common interface for users and
implementors of UDP-Lite modules, the definitions of these runtime implementors of UDP-Lite modules, the definitions of these runtime
statistics are provided as a MIB module using the SMIv2 format statistics are provided as a MIB module using the SMIv2 format
[RFC2578]. [RFC2578].
1.1. Relationship to the UDP-MIB 1.1. Relationship to the UDP-MIB
The similarities between UDP and UDP-Lite suggest that the MIB module The similarities between UDP and UDP-Lite suggest that the MIB module
for UDP-Lite should resemble that of UDP [RFC4113], with extensions for UDP-Lite should resemble that of UDP [RFC4113], with extensions
skipping to change at page 4, line 12 skipping to change at page 3, line 12
o OutDatagrams o OutDatagrams
The following read-only variables have been added to the basic The following read-only variables have been added to the basic
structure used in the UDP-MIB module: structure used in the UDP-MIB module:
InPartialCov: The number of received datagrams, with a valid InPartialCov: The number of received datagrams, with a valid
format and checksum, whose checksum coverage is strictly less than format and checksum, whose checksum coverage is strictly less than
the datagram length. the datagram length.
InBadChecksum: The number of received datagrams with an invalid InBadChecksum: The number of received datagrams with an invalid
checksum (i.e. where the receiver-recalculated UDP-Lite checksum checksum (i.e., where the receiver-recalculated UDP-Lite checksum
does not match that in the Checksum field). Unlike NoPorts, this does not match that in the Checksum field). Unlike NoPorts, this
error type also counts as InErrors. error type also counts as InErrors.
OutPartialCov: The number of sent datagrams with a valid format OutPartialCov: The number of sent datagrams with a valid format
and checksum whose checksum coverage is strictly less than the and checksum whose checksum coverage is strictly less than the
datagram length. datagram length.
All non-error counters used in this document are 64-bit counters. All non-error counters used in this document are 64-bit counters.
This is a departure from UDP, which traditionally used 32-bit This is a departure from UDP, which traditionally used 32-bit
counters and mandates 64-bit counters only on fast networks counters and mandates 64-bit counters only on fast networks
skipping to change at page 4, line 50 skipping to change at page 3, line 50
rather than passed to the application. This object thus serves to rather than passed to the application. This object thus serves to
separate cases of violated coverage from other InErrors. separate cases of violated coverage from other InErrors.
The second entry is not required to manage the transport protocol and The second entry is not required to manage the transport protocol and
hence is not mandatory. It may be implemented to assist in debugging hence is not mandatory. It may be implemented to assist in debugging
application design and configuration. application design and configuration.
The UDP-Lite MIB module also provides a discontinuity object to help The UDP-Lite MIB module also provides a discontinuity object to help
determine whether one or more of its counters experienced a determine whether one or more of its counters experienced a
discontinuity event. This is an event, other than re-initialising discontinuity event. This is an event, other than re-initialising
the management system, which invalidates the management entity's the management system, that invalidates the management entity's
understanding of the counter values. understanding of the counter values.
For example, if UDP-Lite is implemented as a loadable operating For example, if UDP-Lite is implemented as a loadable operating
system module, a module load or unload would produce a discontinuity. system module, a module load or unload would produce a discontinuity.
By querying the value of udpliteStatsDiscontinuityTime, a management By querying the value of udpliteStatsDiscontinuityTime, a management
entity can determine whether or not a discontinuity event has entity can determine whether or not a discontinuity event has
occurred. occurred.
1.2. Relationship to HOST-RESOURCES-MIB and SYSAPPL-MIB 1.2. Relationship to HOST-RESOURCES-MIB and SYSAPPL-MIB
The UDP-Lite endpoint table contains one columnar object, The UDP-Lite endpoint table contains one columnar object,
udpliteEndpointProcess, reporting a unique value which identifies a udpliteEndpointProcess, reporting a unique value that identifies a
distinct piece of software associated with this endpoint. (When more distinct piece of software associated with this endpoint. (When more
than one piece of software is associated with this endpoint, a than one piece of software is associated with this endpoint, a
representative is chosen; so that consecutive queries consistently representative is chosen, so that consecutive queries consistently
refer to the same identifier, as long as the representative piece of refer to the same identifier. The reported value is then consistent,
software is running and still associated with the endpoint.) as long as the representative piece of software is running and still
associated with the endpoint.)
The value of udpliteEndpointProcess is reported as an Unsigned32; and The value of udpliteEndpointProcess is reported as an Unsigned32, and
it shares with the hrSWRunIndex of the HOST-RESOURCES-MIB [RFC2790] it shares with the hrSWRunIndex of the HOST-RESOURCES-MIB [RFC2790]
and the sysApplElmtRunIndex of the SYSAPPL-MIB [RFC2287] the and the sysApplElmtRunIndex of the SYSAPPL-MIB [RFC2287] the
requirement that, wherever possible, this should be the native and requirement that, wherever possible, this should be the native and
unique identification number employed by the system. unique identification number employed by the system.
If the SYSAPPL-MIB module is available, the value of If the SYSAPPL-MIB module is available, the value of
udpliteEndpointProcess should correspond to the appropriate value of udpliteEndpointProcess should correspond to the appropriate value of
sysApplElmtRunIndex. If not available, an alternative should be used sysApplElmtRunIndex. If not available, an alternative should be used
(e.g. the hrSWRunIndex of the HOST-RESOURCES-MIB module). (e.g., the hrSWRunIndex of the HOST-RESOURCES-MIB module).
1.3. Interpretation of the MIB Variables 1.3. Interpretation of the MIB Variables
Figure 1 shows an informal survey of the packet processing path, with Figure 1 shows an informal survey of the packet processing path, with
reference to counter names in brackets. reference to counter names in parentheses.
Received UDP-Lite Datagrams Received UDP-Lite Datagrams
| |
| +- Full Coverage ---------------------+-> Deliver | +- Full Coverage ---------------------+-> Deliver
| | | | | |
+- Valid Header--+ +- >= Rec. Coverage --+ +- Valid Header--+ +- >= Rec. Coverage --+
| (InDatagrams) | | | (InDatagrams) | |
| +- Partial -----+ | +- Partial -----+
| (InPartialCov) | | (InPartialCov) |
| +- < Rec. Coverage --+ | +- < Rec. Coverage --+
skipping to change at page 6, line 44 skipping to change at page 5, line 49
On the receiving side, InDatagrams, InPartialCov, and InErrors are On the receiving side, InDatagrams, InPartialCov, and InErrors are
monitored. If datagrams are received from the given sender, InErrors monitored. If datagrams are received from the given sender, InErrors
is close to zero, and InPartialCov is zero, no partial coverage is is close to zero, and InPartialCov is zero, no partial coverage is
employed. If no datagrams are received and InErrors increases employed. If no datagrams are received and InErrors increases
proportionally with the sending rate, a configuration error is likely proportionally with the sending rate, a configuration error is likely
(a wrong value of receiver minimum checksum coverage). (a wrong value of receiver minimum checksum coverage).
The InBadChecksum counter reflects errors that may persist following The InBadChecksum counter reflects errors that may persist following
end-host processing, router processing, or link processing (this end-host processing, router processing, or link processing (this
includes illegal coverage values as defined in [RFC3828], since includes illegal coverage values as defined in [RFC3828], since
checksum and checksum coverage are mutually inter-dependent). In checksum and checksum coverage are mutually interdependent). In
particular, InBadChecksum can serve as an indicator of the residual particular, InBadChecksum can serve as an indicator of the residual
link bit error rate: on links with higher bit error rates, a lower link bit error rate: on links with higher bit error rates, a lower
value of the checksum coverage may help to reduce both the values of value of the checksum coverage may help to reduce the values of both
InErrors and InBadChecksum. InErrors and InBadChecksum. By observing these values and adapting
the configuration, a setting may then be found that is more adapted
By observing these values and adapting the configuration, a setting to the specific type of link, and the type of payload. In
may then be found that is more adapted to the specific type of link, particular, a reduction in the number of discarded datagrams
as well as the type of payload; indicated by a reduction of the (InErrors), may indicate an improved performance.
number of discarded datagrams (InErrors), leading to an improved
performance.
The above statistics are elementary and can be used to derive the The above statistics are elementary and can be used to derive the
following information: following information:
o The total number of incoming datagrams is InDatagrams + InErrors + o The total number of incoming datagrams is InDatagrams + InErrors +
NoPorts NoPorts.
o The number of InErrors that were discarded due to problems other o The number of InErrors that were discarded due to problems other
than bad checksum is InErrors - InBadChecksum than a bad checksum is InErrors - InBadChecksum.
o The number of InDatagrams that have full coverage is InDatagrams - o The number of InDatagrams that have full coverage is InDatagrams -
InPartialCov. InPartialCov.
o The number of OutDatagrams that have full coverage is OutDatagrams o The number of OutDatagrams that have full coverage is OutDatagrams
- OutPartialCov. - OutPartialCov.
The following Case diagram [CASE] summarises the relationships The following Case diagram [CASE] summarises the relationships
between the counters on the input processing path. between the counters on the input processing path.
skipping to change at page 7, line 51 skipping to change at page 7, line 34
||------> InBadChecksum ------>| ||------> InBadChecksum ------>|
|| | || |
|| | || |
|| v || v
||------------------------> InErrors ||------------------------> InErrors
|| ||
|| ||
------------------------------------------------------------- -------------------------------------------------------------
Network Layer Interface Network Layer Interface
Figure 2: Counters for received UDP-Lite Datagrams Figure 2: Counters for Received UDP-Lite Datagrams
A configuration error may occur when a sender chooses a coverage A configuration error may occur when a sender chooses a coverage
value for the datagrams that it sends that is less than the minimum value for the datagrams that it sends that is less than the minimum
coverage configured by the intended recipient. The minimum coverage coverage configured by the intended recipient. The minimum coverage
is set on a per-session basis by the application associated with the is set on a per-session basis by the application associated with the
listening endpoint, and its current value is recorded in the listening endpoint, and its current value is recorded in the
udpliteEndpointTable. Reception of valid datagrams with a checksum udpliteEndpointTable. Reception of valid datagrams with a checksum
coverage value less than this threshold results in dropping the coverage value less than this threshold results in dropping the
datagram [RFC3828] and incrementing InErrors. To improve debugging datagram [RFC3828] and incrementing InErrors. To improve debugging
of such (misconfigured) cases, an implementer may choose to support of such (misconfigured) cases, an implementer may choose to support
the optional udpliteEndpointViolCoverage entry in the endpoint table the optional udpliteEndpointViolCoverage entry in the endpoint table
(Section 1.1.) that specifically counts datagrams falling in this (Section 1.1) that specifically counts datagrams falling in this
category. Without this feature, failure due to misconfiguration can category. Without this feature, failure due to misconfiguration can
not be distinguished from datagram processing failure. not be distinguished from datagram processing failure.
1.4. Conventions 1.4. Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in BCP 14, [RFC2119]. document are to be interpreted as described in BCP 14 [RFC2119].
2. The Internet-Standard Management Framework 2. The Internet-Standard Management Framework
For a detailed overview of the documents that describe the current For a detailed overview of the documents that describe the current
Internet-Standard Management Framework, please refer to section 7 of Internet-Standard Management Framework, please refer to section 7 of
RFC 3410 [RFC3410]. RFC 3410 [RFC3410].
Managed objects are accessed via a virtual information store, termed Managed objects are accessed via a virtual information store, termed
the Management Information Base or MIB. MIB objects are generally the Management Information Base or MIB. MIB objects are generally
accessed through the Simple Network Management Protocol (SNMP). accessed through the Simple Network Management Protocol (SNMP).
skipping to change at page 11, line 4 skipping to change at page 8, line 44
Counter32, Counter64 FROM SNMPv2-SMI -- [RFC2578] Counter32, Counter64 FROM SNMPv2-SMI -- [RFC2578]
TimeStamp FROM SNMPv2-TC -- [RFC2579] TimeStamp FROM SNMPv2-TC -- [RFC2579]
MODULE-COMPLIANCE, MODULE-COMPLIANCE,
OBJECT-GROUP FROM SNMPv2-CONF -- [RFC2580] OBJECT-GROUP FROM SNMPv2-CONF -- [RFC2580]
InetAddress, InetAddress,
InetAddressType, InetAddressType,
InetPortNumber FROM INET-ADDRESS-MIB; -- [RFC4001] InetPortNumber FROM INET-ADDRESS-MIB; -- [RFC4001]
udpliteMIB MODULE-IDENTITY udpliteMIB MODULE-IDENTITY
LAST-UPDATED "200712180000Z" -- 18 December 2007
ORGANIZATION "IETF TSV Working Group (TSVWG)" ORGANIZATION "IETF TSV Working Group (TSVWG)"
CONTACT-INFO CONTACT-INFO
"IETF TSV Working Group "IETF TSV Working Group
http://www.ietf.org/html.charters/tsvwg-charter.html http://www.ietf.org/html.charters/tsvwg-charter.html
Mailing List: tsvwg@ietf.org Mailing List: tsvwg@ietf.org
Gerrit Renker, Godred Fairhurst Gerrit Renker, Godred Fairhurst
Electronics Research Group Electronics Research Group
School of Engineering, University of Aberdeen School of Engineering, University of Aberdeen
Fraser Noble Building, Aberdeen AB24 3UE, UK" Fraser Noble Building, Aberdeen AB24 3UE, UK"
DESCRIPTION DESCRIPTION
"The MIB module for managing UDP-Lite implementations. "The MIB module for managing UDP-Lite implementations.
Copyright (C) The IETF Trust (2007). This version of Copyright (C) The IETF Trust (2008). This version of
this MIB module is part of RFC ZZZ; see the RFC this MIB module is part of RFC 5097; see the RFC
itself for full legal notices." itself for full legal notices."
-- RFC Ed.: replace ZZZ with actual RFC number & remove this note REVISION "200712180000Z" -- 18 December 2007
DESCRIPTION DESCRIPTION
"Initial SMIv2 revision, based on the format of the UDP "Initial SMIv2 revision, based on the format of the UDP
MIB module (RFC 4113) and published as RFC ZZZ." MIB module (RFC 4113) and published as RFC 5097."
::= { mib-2 170 }
-- RFC Ed.: replace ZZZ with actual RFC number & remove this note
::= { mib-2 XXX }
-- RFC Ed.: replace XXX with OBJECT-IDENTIFIER & remove this note
udplite OBJECT IDENTIFIER ::= { udpliteMIB 1 } udplite OBJECT IDENTIFIER ::= { udpliteMIB 1 }
udpliteInDatagrams OBJECT-TYPE -- as in UDP-MIB udpliteInDatagrams OBJECT-TYPE -- as in UDP-MIB
SYNTAX Counter64 SYNTAX Counter64
MAX-ACCESS read-only MAX-ACCESS read-only
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"The total number of UDP-Lite datagrams that were "The total number of UDP-Lite datagrams that were
delivered to UDP-Lite users. delivered to UDP-Lite users.
skipping to change at page 15, line 13 skipping to change at page 12, line 37
address/port, the udpliteEndpointRemote* values should address/port, the udpliteEndpointRemote* values should
be used to reflect this." be used to reflect this."
::= { udplite 8 } ::= { udplite 8 }
udpliteEndpointEntry OBJECT-TYPE udpliteEndpointEntry OBJECT-TYPE
SYNTAX UdpLiteEndpointEntry SYNTAX UdpLiteEndpointEntry
MAX-ACCESS not-accessible MAX-ACCESS not-accessible
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"Information about a particular current UDP-Lite endpoint. "Information about a particular current UDP-Lite endpoint.
Implementers need to pay attention to the sizes of Implementers need to pay attention to the sizes of
udpliteEndpointLocalAddress/RemoteAddress, as OIDs of udpliteEndpointLocalAddress/RemoteAddress, as Object
column instances in this table must have no more than Identifiers (OIDs) of column instances in this table must
128 sub-identifiers in order to remain accessible with have no more than 128 sub-identifiers in order to remain
SNMPv1, SNMPv2c, and SNMPv3." accessible with SNMPv1, SNMPv2c, and SNMPv3."
INDEX { udpliteEndpointLocalAddressType, INDEX { udpliteEndpointLocalAddressType,
udpliteEndpointLocalAddress, udpliteEndpointLocalAddress,
udpliteEndpointLocalPort, udpliteEndpointLocalPort,
udpliteEndpointRemoteAddressType, udpliteEndpointRemoteAddressType,
udpliteEndpointRemoteAddress, udpliteEndpointRemoteAddress,
udpliteEndpointRemotePort, udpliteEndpointRemotePort,
udpliteEndpointInstance } udpliteEndpointInstance }
::= { udpliteEndpointTable 1 } ::= { udpliteEndpointTable 1 }
UdpLiteEndpointEntry ::= SEQUENCE { UdpLiteEndpointEntry ::= SEQUENCE {
skipping to change at page 19, line 26 skipping to change at page 15, line 46
udpliteEndpointProcess OBJECT-TYPE udpliteEndpointProcess OBJECT-TYPE
SYNTAX Unsigned32 SYNTAX Unsigned32
MAX-ACCESS read-only MAX-ACCESS read-only
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"A unique value corresponding to a piece of software "A unique value corresponding to a piece of software
running on this endpoint. running on this endpoint.
If this endpoint is associated with more than one piece If this endpoint is associated with more than one piece
of software, the agent should choose one of these; such of software, the agent should choose one of these. As
that subsequent reads will consistently return the same long as the representative piece of software
value, as long as the representative piece of software is running and still associated with the endpoint,
is running and still associated with the endpoint. The subsequent reads will consistently return the same
implementation may use any algorithm satisfying these value. The implementation may use any algorithm
constraints (e.g. choosing the entity with the oldest satisfying these constraints (e.g., choosing the entity
start time). with the oldest start time).
This identifier is platform-specific. Wherever possible, This identifier is platform-specific. Wherever possible,
it should use the system's native, unique identification it should use the system's native, unique identification
number as value. number as the value.
If the SYSAPPL-MIB module is available, the value should If the SYSAPPL-MIB module is available, the value should
be the same as sysApplElmtRunIndex. If not available, an be the same as sysApplElmtRunIndex. If not available, an
alternative should be used (e.g. the hrSWRunIndex of the alternative should be used (e.g., the hrSWRunIndex of the
HOST-RESOURCES-MIB module). HOST-RESOURCES-MIB module).
If it is not possible to uniquely identify the pieces of If it is not possible to uniquely identify the pieces of
software associated with this endpoint, then the value software associated with this endpoint, then the value
zero should be used. (Note that zero is otherwise a zero should be used. (Note that zero is otherwise a
valid value for sysApplElmtRunIndex.)" valid value for sysApplElmtRunIndex.)"
::= { udpliteEndpointEntry 8 } ::= { udpliteEndpointEntry 8 }
udpliteEndpointMinCoverage OBJECT-TYPE -- new in UDP-Lite udpliteEndpointMinCoverage OBJECT-TYPE -- new in UDP-Lite
SYNTAX Unsigned32 SYNTAX Unsigned32
MAX-ACCESS read-only MAX-ACCESS read-only
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"The minimum checksum coverage expected by this endpoint. "The minimum checksum coverage expected by this endpoint.
A value of 0 indicates that only fully covered datagrams A value of 0 indicates that only fully covered datagrams
are accepted." are accepted."
REFERENCE "RFC 3828, section 3.1" REFERENCE "RFC 3828, section 3.1"
::= { udpliteEndpointEntry 9 } ::= { udpliteEndpointEntry 9 }
skipping to change at page 20, line 22 skipping to change at page 16, line 39
REFERENCE "RFC 3828, section 3.1" REFERENCE "RFC 3828, section 3.1"
::= { udpliteEndpointEntry 9 } ::= { udpliteEndpointEntry 9 }
udpliteEndpointViolCoverage OBJECT-TYPE -- new / optional in UDP-Lite udpliteEndpointViolCoverage OBJECT-TYPE -- new / optional in UDP-Lite
SYNTAX Counter32 SYNTAX Counter32
MAX-ACCESS read-only MAX-ACCESS read-only
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"The number of datagrams received by this endpoint whose "The number of datagrams received by this endpoint whose
checksum coverage violated the minimum coverage threshold checksum coverage violated the minimum coverage threshold
set for this connection (i.e. all valid datagrams whose set for this connection (i.e., all valid datagrams whose
checksum coverage was strictly smaller than the minimum, checksum coverage was strictly smaller than the minimum,
as defined in RFC 3828). as defined in RFC 3828).
Discontinuities in the value of this counter can occur Discontinuities in the value of this counter can occur
at re-initialisation of the management system, and at at re-initialisation of the management system, and at
other times as indicated by the value of other times as indicated by the value of
udpliteStatsDiscontinuityTime." udpliteStatsDiscontinuityTime."
::= { udpliteEndpointEntry 10 } ::= { udpliteEndpointEntry 10 }
udpliteStatsDiscontinuityTime OBJECT-TYPE udpliteStatsDiscontinuityTime OBJECT-TYPE
SYNTAX TimeStamp SYNTAX TimeStamp
MAX-ACCESS read-only MAX-ACCESS read-only
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"The value of sysUpTime at the most recent occasion at "The value of sysUpTime at the most recent occasion at
which one or more of the UDP-Lite counters suffered a which one or more of the UDP-Lite counters suffered a
discontinuity. discontinuity.
A value of zero indicates no such discontinuity has A value of zero indicates no such discontinuity has
occurred since the last re-initialisation of the local occurred since the last re-initialisation of the local
skipping to change at page 22, line 24 skipping to change at page 18, line 39
basic UDP-like statistics." basic UDP-like statistics."
::= { udpliteMIBGroups 1 } ::= { udpliteMIBGroups 1 }
udplitePartialCsumGroup OBJECT-GROUP -- specific to UDP-Lite udplitePartialCsumGroup OBJECT-GROUP -- specific to UDP-Lite
OBJECTS { udpliteInPartialCov, OBJECTS { udpliteInPartialCov,
udpliteInBadChecksum, udpliteInBadChecksum,
udpliteOutPartialCov } udpliteOutPartialCov }
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"The group of objects providing for counters of "The group of objects providing for counters of
transport-layer statistics exclusive to UDP-Lite." transport layer statistics exclusive to UDP-Lite."
::= { udpliteMIBGroups 2 } ::= { udpliteMIBGroups 2 }
udpliteEndpointGroup OBJECT-GROUP udpliteEndpointGroup OBJECT-GROUP
OBJECTS { udpliteEndpointProcess, udpliteEndpointMinCoverage } OBJECTS { udpliteEndpointProcess, udpliteEndpointMinCoverage }
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"The group of objects providing for the IP version "The group of objects providing for the IP version
independent management of UDP-Lite 'endpoints'." independent management of UDP-Lite 'endpoints'."
::= { udpliteMIBGroups 3 } ::= { udpliteMIBGroups 3 }
udpliteAppGroup OBJECT-GROUP udpliteAppGroup OBJECT-GROUP
OBJECTS { udpliteEndpointViolCoverage } OBJECTS { udpliteEndpointViolCoverage }
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"The group of objects that provide application-level "The group of objects that provide application-level
information for the configuration management of information for the configuration management of
UDP-Lite 'endpoints'." UDP-Lite 'endpoints'."
::= { udpliteMIBGroups 4 } ::= { udpliteMIBGroups 4 }
END END
skipping to change at page 23, line 21 skipping to change at page 19, line 31
module via direct SNMP SET operations. module via direct SNMP SET operations.
Some of the readable objects in this MIB module (i.e., objects with a Some of the readable objects in this MIB module (i.e., objects with a
MAX-ACCESS other than not-accessible) may be considered sensitive or MAX-ACCESS other than not-accessible) may be considered sensitive or
vulnerable in some network environments. It is thus important to vulnerable in some network environments. It is thus important to
control even GET and/or NOTIFY access to these objects and possibly control even GET and/or NOTIFY access to these objects and possibly
to even encrypt the values of these objects when sending them over to even encrypt the values of these objects when sending them over
the network via SNMP. These are the tables and objects and their the network via SNMP. These are the tables and objects and their
sensitivity/vulnerability: sensitivity/vulnerability:
The indices of the udpliteEndpointTable contain information about the
listeners on an entity. In particular, the udpliteEndpointLocalPort
index objects can be used to identify ports that are open on the
machine and which attacks are likely to succeed, without the attacker
having to run a port scanner. The table also identifies the
currently listening UDP-Lite ports.
The udpliteEndpointMinCoverage provides information about the
requirements of the transport service associated with a specific
UDP-Lite port. This provides additional detail concerning the type
of application associated with the port at the receiver.
Since UDP-Lite permits the delivery of (partially) corrupted data to Since UDP-Lite permits the delivery of (partially) corrupted data to
an end host, the counters defined in this MIB module may be used to an end host, the counters defined in this MIB module may be used to
infer information about the characteristics of the end-to-end path infer information about the characteristics of the end-to-end path
over which the datagrams are communicated. over which the datagrams are communicated. This information could be
used to infer the type of application associated with the port at the
The indices of the udpliteEndpointTable contain information about the receiver.
listeners on an entity. In particular, the udpliteEndpointLocalPort
and udpliteLocalPort objects in the indices can be used to identify
what ports are open on the machine and which attacks are likely to
succeed, without the attacker having to run a port scanner. The
table also identifies the currently listening UDP-Lite ports. This
could be used to infer the type of application associated with the
port at the receiver. The udpliteEndpointMinCoverage provides
information about the requirements of the transport service
associated with a specific UDP-Lite port. This provides additional
detail concerning the type of application associated with the port at
the receiver.
SNMP versions prior to SNMPv3 did not include adequate security. SNMP versions prior to SNMPv3 did not include adequate security.
Even if the network itself is secure (for example by using IPsec), Even if the network itself is secure (for example by using IPsec),
even then, there is no control as to who on the secure network is even then, there is no control as to who on the secure network is
allowed to access and GET/SET (read/change/create/delete) the objects allowed to access and GET/SET (read/change/create/delete) the objects
in this MIB module. in this MIB module.
It is RECOMMENDED that implementers consider the security features as It is RECOMMENDED that implementers consider the security features as
provided by the SNMPv3 framework (see RFC 3410 [RFC3410], section 8), provided by the SNMPv3 framework (see RFC 3410 [RFC3410], section 8),
including full support for the SNMPv3 cryptographic mechanisms (for including full support for the SNMPv3 cryptographic mechanisms (for
skipping to change at page 25, line 13 skipping to change at page 20, line 29
rights to indeed GET or SET (change/create/delete) them. rights to indeed GET or SET (change/create/delete) them.
5. IANA Considerations 5. IANA Considerations
The MIB module in this document uses the following IANA-assigned The MIB module in this document uses the following IANA-assigned
OBJECT IDENTIFIER values recorded in the SMI Numbers registry: OBJECT IDENTIFIER values recorded in the SMI Numbers registry:
+------------+-------------------------+ +------------+-------------------------+
| Descriptor | OBJECT IDENTIFIER value | | Descriptor | OBJECT IDENTIFIER value |
+------------+-------------------------+ +------------+-------------------------+
| udpliteMIB | { mib-2 XXX } | | udpliteMIB | { mib-2 170 } |
+------------+-------------------------+ +------------+-------------------------+
==> Note to the RFC Editor (to be removed prior to publication):
The IANA is requested to assign a value for "XXX" under the 'mib-2'
subtree and to record the assignment in the SMI Numbers registry.
When the assignment has been made, the RFC Editor is asked to replace
"XXX" (here and in the MIB module) with the assigned value and to
remove this note.
6. Acknowledgments 6. Acknowledgments
The design of the MIB module presented in this document owes much to The design of the MIB module presented in this document owes much to
the format of the module presented in [RFC4113]. the format of the module presented in [RFC4113].
==> NOTE TO THE RFC EDITOR: PLEASE REMOVE THIS LOG PRIOR TO PUBLICATION
Revision 00 of draft-ietf-tsvwg-udplite-mib was obsoleted by revision
01 due to a syntax error (quote transposed with full-stop) in the MIB
module, which is corrected in rev-01. Thanks to Magnus Westerlund
for identifying this.
Draft draft-ietf-tsvwg-udplite-mib-00 was published as a work item of
tsvwg, June 2007.
The following changelog lists the changes up to revision 02 (which
became rev-00/01 of this document) of the preceding individual draft
submission draft-renker-tsvwg-udplite-mib.
Changes introduced in rev-01:
o General:
- incremented revision number to 01
- updated date to November
- rephrased abstract
o Section 1:
- rephrased the beginning of the second paragraph
o Section 1.1:
- rephrased some items
- added missing InBadChecksum heading
- updated text to refer to 64bit counters
o Section 1.3:
- removed 'x' in 'datagrams'
- rephrased for clarity
- Figure 1: missing bracketed text should be InErrors
- Figure 1: correction - NoPorts are not counted as InDatagrams
o Section 2:
- made the "Editor's Note" stand out more
o Section 3 / MIB:
- upgraded 11 32bit counters to 64bit
- moved from experimental to mib-2
- updated revision date
o Section 4:
- some minor changes
o Section 5:
- again highlighted the Editor's Note by using `==>' to make it
consistent
Changes introduced in rev-02:
o General:
- updated month, date, and revision
- changed `transport layer entities' to `endpoints' in abstract
o Section 1:
- added missing comma after `option'
- split explanatory clause after colon into standalone clause
o Section 1.1:
- added a bullet list of standard counters known from the UDP
MIB
- added a note that NoPorts does not increment InErrors
- removed description of InBadCoverage (no longer in MIB, see
below)
- qualified note with on 64-bit counters wrt `non-error'
counters, reflecting the change that all error counters have
been changed to Counter32
- Nit: changed `fairly recent' -> `more recent'
- removed traces of InBadCoverage (see below)
o Section 1.3:
- corrected figure 1 (NoPorts was inconsistent with text; Rec
Coverage was incorrectly labelled, it didn't show
EndpointViolCoverage; slight reformatting)
- Nit: `wrong value' -> `a wrong value'
- clarified that InBadChecksum can also serve as indicator of
path bit error rate
- Nit: `which' -> `that' in `a setting may then ...' and `A
configuration error may ...'
- removed traces of InBadCoverage (see below)
o Section 3 (the MIB):
- updated LAST-UPDATED and REVISION to match the revision date
- updated the Copyright in DESCRIPTION from 2006 to 2007
- converted all error counters to Counter32, following IETF
input for rev-01
- added a required IMPORTS statement for Counter32 to UDPLITE-
MIB DEFINITIONS
- demoted the following error counters from Counter64 to
Counter32: udpliteNoPorts, udpliteInErrors,
updliteInBadChecksum, udpliteEndpointViolCoverage
- removed second, redundant MIB-2 number of udplite, following
suggestion by Bill Fenner.
- updated warning about maximum number of sub-identifiers in
udpliteEndpointEntry, to reflect new structure
- udplite now comes as entry number 1 in the udpliteMIB tree
- accordingly changed the identifier of udpliteMIBConformance
to 2
- updated all RFC editor notes with regard to the assignment of
mib-2 identifier numbers (now only a single one required)
- updated section `IANA Considerations' with regard to this
change
- removed the InBadCoverage counter since it is subsumed by
InBadChecksum (see below)
- updated the following identifier numbers for consistency
after removal: udpliteInBadChecksum (6 -> 5),
udpliteOutDatagrams (7 -> 6), udpliteOutPartialCov (8 -> 7),
udpliteEndpointTable (9 -> 8)
- removed udpliteInBadCoverage from udplitePartialCsumGroup
- extended the definition of InBadChecksum to include invalid
checksum coverage
- added RFC 3828 references for udpliteEndpointMinCoverage and
udpliteEndpointViolCoverage
- updated the description of udpliteEndpointInstance with
respect to draft-persson-v6ops-mib-issue-01.txt, section 3.2
o Section 7 (References):
- RFC 4113 (UDP MIB) becomes informative, not normative
o Note on the removal of InBadCoverage: Following rev-01, this
counter has been removed since - with the exception of obviously
buggy UDP-Lite stacks - it is subsumed by InBadChecksum. An
illegal checksum value which is not the cause of a buggy
implementation will in practically all cases lead to an incorrect
checksum value, so that one counter implies information inherent
in the other.
====> END OF NOTE TO THE RFC EDITOR <====
7. References 7. References
7.1. Normative References 7.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., [RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J.,
Rose, M., and S. Waldbusser, "Structure of Management Rose, M., and S. Waldbusser, "Structure of Management
Information Version 2 (SMIv2)", STD 58, RFC 2578, Information Version 2 (SMIv2)", STD 58, RFC 2578, April
April 1999. 1999.
[RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., [RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J.,
Rose, M., and S. Waldbusser, "Textual Conventions for Rose, M., and S. Waldbusser, "Textual Conventions for
SMIv2", STD 58, RFC 2579, April 1999. SMIv2", STD 58, RFC 2579, April 1999.
[RFC2580] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., [RFC2580] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J.,
Rose, M., and S. Waldbusser, "Conformance Statements for Rose, M., and S. Waldbusser, "Conformance Statements for
SMIv2", STD 58, RFC 2580, April 1999. SMIv2", STD 58, RFC 2580, April 1999.
[RFC3828] Larzon, L-A., Degermark, M., Pink, S., Jonsson, L-E., and [RFC3828] Larzon, L-A., Degermark, M., Pink, S., Jonsson, L-E., and
skipping to change at page 32, line 39 skipping to change at page 21, line 23
[RFC4001] Daniele, M., Haberman, B., Routhier, S., and J. [RFC4001] Daniele, M., Haberman, B., Routhier, S., and J.
Schoenwaelder, "Textual Conventions for Internet Network Schoenwaelder, "Textual Conventions for Internet Network
Addresses", RFC 4001, February 2005. Addresses", RFC 4001, February 2005.
7.2. Informative References 7.2. Informative References
[CASE] Case, J. and C. Partridge, "Case Diagrams: A First Step to [CASE] Case, J. and C. Partridge, "Case Diagrams: A First Step to
Diagrammed Management Information Bases", ACM Computer Diagrammed Management Information Bases", ACM Computer
Communications Review, 19(1):13-16, January 1989. Communications Review, 19(1):13-16, January 1989.
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, [RFC768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
August 1980. August 1980.
[RFC2287] Krupczak, C. and J. Saperia, "Definitions of System-Level [RFC2287] Krupczak, C. and J. Saperia, "Definitions of System-Level
Managed Objects for Applications", RFC 2287, Managed Objects for Applications", RFC 2287, February
February 1998. 1998.
[RFC2790] Waldbusser, S. and P. Grillo, "Host Resources MIB", [RFC2790] Waldbusser, S. and P. Grillo, "Host Resources MIB", RFC
RFC 2790, March 2000. 2790, March 2000.
[RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart,
"Introduction and Applicability Statements for Internet- "Introduction and Applicability Statements for Internet-
Standard Management Framework", RFC 3410, December 2002. Standard Management Framework", RFC 3410, December 2002.
[RFC4113] Fenner, B. and J. Flick, "Management Information Base for [RFC4113] Fenner, B. and J. Flick, "Management Information Base for
the User Datagram Protocol (UDP)", RFC 4113, June 2005. the User Datagram Protocol (UDP)", RFC 4113, June 2005.
[RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram
Congestion Control Protocol (DCCP)", RFC 4340, March 2006. Congestion Control Protocol (DCCP)", RFC 4340, March 2006.
Authors' Addresses Authors' Addresses
Gerrit Renker Gerrit Renker
University of Aberdeen University of Aberdeen
School of Engineering School of Engineering
Fraser Noble Building Fraser Noble Building
Aberdeen AB24 3UE Aberdeen AB24 3UE
Scotland Scotland
Email: gerrit@erg.abdn.ac.uk EMail: gerrit@erg.abdn.ac.uk
URI: http://www.erg.abdn.ac.uk URI: http://www.erg.abdn.ac.uk
Godred Fairhurst Godred Fairhurst
University of Aberdeen University of Aberdeen
School of Engineering School of Engineering
Fraser Noble Building Fraser Noble Building
Aberdeen AB24 3UE Aberdeen AB24 3UE
Scotland Scotland
Email: gorry@erg.abdn.ac.uk EMail: gorry@erg.abdn.ac.uk
URI: http://www.erg.abdn.ac.uk URI: http://www.erg.abdn.ac.uk
Full Copyright Statement Full Copyright Statement
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
skipping to change at page 35, line 44 skipping to change at line 995
attempt made to obtain a general license or permission for the use of attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
 End of changes. 52 change blocks. 
318 lines changed or deleted 103 lines changed or added

This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/